Memec v4fx12lc - problem booting linux on ppc
Olivier GOUDARD
olivier.goudard at esrf.fr
Wed Nov 22 02:11:35 EST 2006
Dear Andrei,
Thanks for all details provided in your mail. It looks like we have a
lot to understand about the boot sequence.
To answer your questions :
We created our own platform with xps.
We went throught the differents steps of the xps wizard to impelment
ppc, UART, EMAC, SDRAM and so on.
Then, we generated the Linux Support Package and compiled the
Montavista previewkit
with the generated files in linux/arch and linux/drivers from the
Linux Support Package.
The montavista previewkit used is :
insight_memec-2vp7fg456_rev4-previewkit-ppc_405
and this previewkit seems to be based on linux 2.4.20 version.
I'm not sure that we used propers xparameters<something_else>.h file
because I don't understand what you mean. I searched in my kernel
sources to find xparam* but I was not successful.
Can you enlighten my ignorance ?
I will check my UART configuration which seems to be very wrong ! :-)
Again many thanks you for your help,
Best regards,
Olivier Goudard
At 12:38 21/11/2006, Andrei Konovalov wrote:
>Olivier,
>
>As you haven't seen *any* output from UART, it looks like
>the problems start well before the bootwrapper passes
>control to the linux kernel.
>
> > XMD% dow zImage.embedded
> > section, .text: 0x00400000-0x004048b0
> > section, .data: 0x00405000-0x004af000
> > section, .bss: 0x004af000-0x004b21e4
>
>- these three sections are not from the linux kernel;
>this is the bootwrapper (see arch/ppc/boot/simple/).
>As you can see, the bootwrapper's code is 18kBytes or so
>(0x48b0) and is loaded 4MBytes above 0 (0x400000).
>700kBytes (0xaa000) of .data contain the compressed kernel
>plus some bootwrapper's stuff.
>
>The bootloader is linked together with the compressed kernel image
>(zvmlinux target in the arch/ppc/boot/simple/Makefile; vmlinux.gz
>is put into .image section which gets into .data according to
>arch/ppc/boot/ld.script). The bootwrapper uncompresses the kernel
>to 0x00000000 and then passes control to the kernel.
>
> > XMD%
> > Processor stopped at PC: 0x00401a10
>
>This address does not correspond to 0xc0001a10.
>This is inside the bootwrapper, and MMU is still off.
>You may want to disassemble zImage.embedded itself
>to check what is at this address.
>
>If you look at arch/ppc/boot/simple/misc-embedded.c, load_kernel()
>you will notice, that before uncompressing the kernel
>the bootwrapper sends the following to the 16x50-compatible UART
>(this may be not true for UART Lite):
>
> loaded at: 00400000 0053B13C
> board data at: 00539124 0053913C
> relocated to: 004051D4 004051EC
> zimage at: 00405A2D 00538651
> avail ram: 0053C000 04000000
>
> Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/nfs rw
> Uncompressing Linux...done
>
>Usually the board hangs after "Uncompressing Linux...done" :)
>I.e. right after control is passed to vmlinux.
>If you use 16x50-compatible UART, CONFIG_SERIAL_8250_CONSOLE
>is defined, and you don't see "loaded at:" et al, then the
>UART configuration in the kernel (and the bootwrapper) is
>very wrong.
>
>Have you created your own platform or use existing xilinx_ml<something>?
>Have you used the proper xparameters<something_else>.h file
>to build the kernel?
>And what kernel version is it BTW? (I was looking at 2.6 when
>writing this message; 2.4 shouldn't be very different).
>
>Thanks,
>Andrei
>
>Olivier Goudard wrote:
>>Yoshio San,
>>thank you for your reply. We tried what you suggest. Here is the output
>>from xmd :
>>XMD% dow zImage.embedded
>> section, .text: 0x00400000-0x004048b0
>> section, .data: 0x00405000-0x004af000
>> section, .bss: 0x004af000-0x004b21e4
>>Downloaded Program zImage.embedded
>>Setting PC with program start addr = 0x00400000
>>PC reset to 0x00400000, Clearing MSR Register
>>XMD% run
>>PC reset to 0x00400000, Clearing MSR Register
>>Processor started. Type "stop" to stop processor
>>RUNNING> stop
>>XMD%
>>XMD%
>>Processor stopped at PC: 0x00401180
>>XMD% run
>>PC reset to 0x00400000, Clearing MSR Register
>>Processor started. Type "stop" to stop processor
>>RUNNING> stop
>>XMD%
>>XMD%
>>Processor stopped at PC: 0x00401a18
>>XMD% run
>>PC reset to 0x00400000, Clearing MSR Register
>>Processor started. Type "stop" to stop processor
>>RUNNING> stop
>>XMD%
>>XMD%
>>Processor stopped at PC: 0x00401180
>>XMD% run
>>PC reset to 0x00400000, Clearing MSR Register
>>Processor started. Type "stop" to stop processor
>>RUNNING> stop
>>XMD%
>>XMD%
>>Processor stopped at PC: 0x00401a10
>>The two address where the processor stops correspond to this assembler
>>code :
>>c0001100 <DTLBMiss>:
>>c0001100: 7e 90 43 a6 mtsprg 0,r20
>>c0001104: 7e b1 43 a6 mtsprg 1,r21
>>c0001108: 7e d4 43 a6 mtsprg4 r22
>>c000110c: 7e f5 43 a6 mtsprg5 r23
>>c0001110: 7e a0 00 26 mfcr r21
>>c0001114: 7e d1 ea a6 mfpid r22
>>c0001118: 7e b7 43 a6 mtsprg7 r21
>>c000111c: 7e d6 43 a6 mtsprg6 r22
>>c0001120: 7e 95 f2 a6 mfdear r20
>>c0001124: 76 95 80 00 andis. r21,r20,32768
>>c0001128: 41 82 00 18 beq- c0001140 <DTLBMiss+0x40>
>>c000112c: 3e a0 c0 14 lis r21,-16364
>>c0001130: 62 b5 d0 00 ori r21,r21,53248
>>c0001134: 3a e0 00 00 li r23,0
>>c0001138: 7e f1 eb a6 mtpid r23
>>c000113c: 48 00 00 0c b c0001148 <DTLBMiss+0x48>
>>c0001140: 7e b3 42 a6 mfsprg r21,3
>>c0001144: 82 b5 00 0c lwz r21,12(r21)
>>c0001148: 3e b5 40 00 addis r21,r21,16384
>>c000114c: 52 95 65 3a rlwimi r21,r20,12,20,29
>>c0001150: 82 b5 00 00 lwz r21,0(r21)
>>c0001154: 56 b6 00 27 rlwinm. r22,r21,0,0,19
>>c0001158: 41 82 00 2c beq- c0001184 <DTLBMiss+0x84>
>>c000115c: 3e d6 40 00 addis r22,r22,16384
>>c0001160: 52 96 b5 3a rlwimi r22,r20,22,20,29
>>c0001164: 82 b6 00 00 lwz r21,0(r22)
>>c0001168: 72 b7 00 02 andi. r23,r21,2
>>c000116c: 41 82 00 18 beq- c0001184 <DTLBMiss+0x84>
>>c0001170: 62 b5 04 00 ori r21,r21,1024
>>c0001174: 92 b6 00 00 stw r21,0(r22)
>>c0001178: 3a c0 0c e2 li r22,3298
>>c000117c: 7e b5 b0 78 andc r21,r21,r22
>>c0001180: 48 00 0f e4 b c0002164 <finish_tlb_load>
>>c0001184: 7e d6 42 a6 mfspr r22,278
>>c0001188: 7e b7 42 a6 mfspr r21,279
>>c000118c: 7e d1 eb a6 mtpid r22
>>c0001190: 7e af f1 20 mtcr r21
>>c0001194: 7e f5 42 a6 mfspr r23,277
>>c0001198: 7e d4 42 a6 mfspr r22,276
>>c000119c: 7e b1 42 a6 mfsprg r21,1
>>c00011a0: 7e 90 42 a6 mfsprg r20,0
>>c00011a4: 4b ff f6 5c b c0000800 <DataAccess>
>>and this :
>>c0001a00 <Trap_1A>:
>>c0001a00: 7e 90 43 a6 mtsprg 0,r20
>>c0001a04: 7e b1 43 a6 mtsprg 1,r21
>>c0001a08: 7e 80 00 26 mfcr r20
>>c0001a0c: 7e b2 42 a6 mfsprg r21,2
>>c0001a10: 2c 15 00 00 cmpwi r21,0
>>c0001a14: 40 82 00 0c bne- c0001a20 <Trap_1A+0x20>
>>c0001a18: 3e a1 40 00 addis r21,r1,16384
>>c0001a1c: 3a b5 ff 40 addi r21,r21,-192
>>c0001a20: 92 95 00 a8 stw r20,168(r21)
>>c0001a24: 92 d5 00 68 stw r22,104(r21)
>>c0001a28: 92 f5 00 6c stw r23,108(r21)
>>c0001a2c: 7e 90 42 a6 mfsprg r20,0
>>c0001a30: 92 95 00 60 stw r20,96(r21)
>>c0001a34: 7e d1 42 a6 mfsprg r22,1
>>c0001a38: 92 d5 00 64 stw r22,100(r21)
>>c0001a3c: 7e 88 02 a6 mflr r20
>>c0001a40: 92 95 00 a0 stw r20,160(r21)
>>c0001a44: 7e c9 02 a6 mfctr r22
>>c0001a48: 92 d5 00 9c stw r22,156(r21)
>>c0001a4c: 7e 81 02 a6 mfxer r20
>>c0001a50: 92 95 00 a4 stw r20,164(r21)
>>c0001a54: 7e da 02 a6 mfsrr0 r22
>>c0001a58: 3e 80 00 04 lis r20,4
>>c0001a5c: 7e fb 02 a6 mfsrr1 r23
>>Unfortunately we are not linux kernel experts so we do not know what
>>these two routines correspond to. Do you are anyone have an idea. It
>>looks like the linux kernel is stopping almost immediately i.e. before
>>trying to do anything visible on the screen.
>>Has anyone seen similar behaviour ? We are stuck with this board and
>>before we abandon the project (or change boards) we would like to make a
>>final attempt.
>>Thanks for any help again
>>Olivier
>>
>>>Olivier San,
>>>
>>>The address of each device driver of LSP of MontaVista Linux and the
>>>address of each IP of the generated circuit match?
>>>
>>>Although your detailed environment is not known, the general way of
>>>investigating is as follows.
>>>
>>>Check where the processor was stopped by the stop command and the
>>>processor has stopped after runing from xmd.
>>>If compared with stopped address and the address of System.map or
>>>disassembling list of vmlinux, it should be able to be decided by
>>>which processing it has hangs.
>>>Disassembling of vmlinux can be displayed by powerpc-linux-objdump
>>>-D vmlinux.
>>>
>>>Best Regards,
>>>
>>>Yoshio Kashiwagi - Nissin Systems
>>>
>>>>Hi,
>>>>
>>>>we have a v4fx12lc fpga board from memec which we are trying to get
>>>>Linux to boot on the ppc processor. We have generated a linux kernel
>>>for
>>>>nfs using the MontaVista support package. We generate a bitfile with
>>>the
>>>>following hardware peripherals in it :
>>>>
>>>>RS232
>>>>Ethernet_MAC
>>>>Led_4bit
>>>>Push_buttons_3bits
>>>>DIP_switches_8bit
>>>>OPB_INTC_0
>>>>
>>>>When we download the linux image with xmd we see nothing on the screen.
>>>>When we type "run" nothing appears on the screen and Linux does not
>>>>boot.
>>>>
>>>>Has anyone had a similar problem ? We are stuck! Any ideas would be
>>>>appreciated.
>>>>
>>>>We can boot a linux ramdisk kernel provided by Memec on the same board
>>>>using their bitfile. So the board seems to be working in general.
>>>>
>>>>Thansk for any pointers and excuse us if we are posting to the wrong
>>>>list (this is the only list we could find which seemed useful) !
>>>>Olivier Goudard
>>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded at ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
More information about the Linuxppc-embedded
mailing list