* Memec v4fx12lc - problem booting linux on ppc @ 2006-11-20 11:42 Olivier Goudard 2006-11-21 2:59 ` Yoshio Kashiwagi 0 siblings, 1 reply; 10+ messages in thread From: Olivier Goudard @ 2006-11-20 11:42 UTC (permalink / raw) To: linuxppc-embedded; +Cc: andy.gotz 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-20 11:42 Memec v4fx12lc - problem booting linux on ppc Olivier Goudard @ 2006-11-21 2:59 ` Yoshio Kashiwagi 2006-11-21 9:44 ` Olivier Goudard 0 siblings, 1 reply; 10+ messages in thread From: Yoshio Kashiwagi @ 2006-11-21 2:59 UTC (permalink / raw) To: goudard, linuxppc-embedded; +Cc: andy.gotz 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-21 2:59 ` Yoshio Kashiwagi @ 2006-11-21 9:44 ` Olivier Goudard 2006-11-21 11:38 ` Andrei Konovalov 0 siblings, 1 reply; 10+ messages in thread From: Olivier Goudard @ 2006-11-21 9:44 UTC (permalink / raw) To: Yoshio Kashiwagi; +Cc: andy.gotz, linuxppc-embedded 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 > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-21 9:44 ` Olivier Goudard @ 2006-11-21 11:38 ` Andrei Konovalov 2006-11-21 15:11 ` Olivier GOUDARD 0 siblings, 1 reply; 10+ messages in thread From: Andrei Konovalov @ 2006-11-21 11:38 UTC (permalink / raw) To: goudard; +Cc: linuxppc-embedded, andy.gotz 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@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-21 11:38 ` Andrei Konovalov @ 2006-11-21 15:11 ` Olivier GOUDARD 2006-11-21 16:34 ` Andrei Konovalov 0 siblings, 1 reply; 10+ messages in thread From: Olivier GOUDARD @ 2006-11-21 15:11 UTC (permalink / raw) To: Andrei Konovalov; +Cc: andy.gotz, linuxppc-embedded 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@ozlabs.org >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-21 15:11 ` Olivier GOUDARD @ 2006-11-21 16:34 ` Andrei Konovalov 2006-11-24 16:05 ` Olivier GOUDARD 0 siblings, 1 reply; 10+ messages in thread From: Andrei Konovalov @ 2006-11-21 16:34 UTC (permalink / raw) To: Olivier GOUDARD; +Cc: andy.gotz, linuxppc-embedded Olivier GOUDARD wrote: > 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. I meant a new board entry in the kernel configuration. Now I see - you are reusing the one for memec 2VPx. > 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. Pro 3.1 preview kit is rather old, and does not have a workaround required for Virtex4. This should not be a problem in your case though, as I believe the generated files in linux/arch should have it. Something like this hack: ---8<-------------------------------------------------------------- --- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1 +++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2 @@ -46,6 +46,11 @@ #endif start_: + /* PPC errata 213: only for Virtex-4 */ + mfccr0 0 + oris 0,0,0x50000000@h + mtccr0 0 + #if defined(CONFIG_FORCE) || defined(CONFIG_PPMC260) /* We have some really bad firmware. We must disable the L1 * icache/dcache now or the board won't boot. ---8<-------------------------------------------------------------- There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that, but the kernel tree you are using doesn't have Virtex4 config option (unlike e.g. community 2.6 tree or Montavista Pro 4.0) > 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 ? arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h The memec board uses this one (to find the addresses and the interrupt numbers). Make sure the defines there match your bitstream. > I will check my UART configuration which seems to be very wrong ! :-) Your UART is 16x50, not UART Lite, correct? > 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@ozlabs.org >>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded >> >> > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-21 16:34 ` Andrei Konovalov @ 2006-11-24 16:05 ` Olivier GOUDARD 2006-11-24 20:39 ` Andy Gotz 0 siblings, 1 reply; 10+ messages in thread From: Olivier GOUDARD @ 2006-11-24 16:05 UTC (permalink / raw) To: Andrei Konovalov; +Cc: andy.gotz, linuxppc-embedded Dear Andrei, Thanks to your advices we managed to view characters on the serial line. (I remind that we are trying to boot linux MontaVista 3.1 on V4FX12LC board of Memec.) It looks like we where using the wrong xparameters_2vpx.h file. We also applyied your patch in arch/ppc/boot/simple/head.S After modifications we obtained : ______________________________________________________________________________ loaded at: 00400000 004B61E4 board data at: 004B313C 004B3154 relocated to: 0040564C 00405664 zimage at: 00405C17 004B20B5 avail ram: 004B7000 04000000 Linux/PPC load: console=ttyS0,9600 ip=on nfsroot=192.168.219.54:/root/myDesign/rootfs rw Uncompressing Linux...done. Now booting the kernel . _______________________________________________________________________________ Which is remotivating us a lot !! I also managed to get a longer boot, but I encounter a kernel panic during the serial driver configuration... We are wondering what to do now ? Maybe we should try to find in xps why we are not using the right xparameterXX.h file and generate a new bit file ? Or maybe we should concentrate our efforts on Linux configuration ? Any comments are welcome that might help us in the ppc/linux boot quest ! Thanks again Andrei, Olivier At 17:34 21/11/2006, Andrei Konovalov wrote: >Olivier GOUDARD wrote: > > 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. > >I meant a new board entry in the kernel configuration. >Now I see - you are reusing the one for memec 2VPx. > > > 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. > >Pro 3.1 preview kit is rather old, and does not have a workaround >required for Virtex4. This should not be a problem in your case though, >as I believe the generated files in linux/arch should have it. >Something like this hack: > >---8<-------------------------------------------------------------- >--- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1 >+++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2 >@@ -46,6 +46,11 @@ > #endif > > start_: >+ /* PPC errata 213: only for Virtex-4 */ >+ mfccr0 0 >+ oris 0,0,0x50000000@h >+ mtccr0 0 >+ > #if defined(CONFIG_FORCE) || defined(CONFIG_PPMC260) > /* We have some really bad firmware. We must disable the L1 > * icache/dcache now or the board won't boot. >---8<-------------------------------------------------------------- > >There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that, >but the kernel tree you are using doesn't have Virtex4 config option >(unlike e.g. community 2.6 tree or Montavista Pro 4.0) > > > 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 ? > >arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h > >The memec board uses this one (to find the addresses and the interrupt >numbers). Make sure the defines there match your bitstream. > > > I will check my UART configuration which seems to be very wrong ! :-) > >Your UART is 16x50, not UART Lite, correct? ____________________________________________________ Olivier GOUDARD, European Synchrotron Radiation Facility Machine Division - Power Supply Group BP 220, F-38043 Grenoble Cedex, France Tel : +33 (0)4 76 88 24 69, Fax : +33 (0)4 76 88 20 54 ____________________________________________________ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-24 16:05 ` Olivier GOUDARD @ 2006-11-24 20:39 ` Andy Gotz 2006-11-25 11:33 ` Andrei Konovalov 0 siblings, 1 reply; 10+ messages in thread From: Andy Gotz @ 2006-11-24 20:39 UTC (permalink / raw) To: Olivier GOUDARD; +Cc: Andrei Konovalov, linuxppc-embedded Hi All, yes , as Olivier says we are highly motivated and have a feeling we are close to our goal. Here is the output from the boot just in case someone recognises our error : loaded at: 00400000 004B61E4 board data at: 004B313C 004B3154 relocated to: 0040564C 00405664 zimage at: 00405C17 004B20B5 avail ram: 004B7000 04000000 Linux/PPC load: console=ttyS0,9600 ip=on nfsroot=192.168.219.54:/root/myDesign/rootfs rw Uncompressing Linux...done. Now booting the kernel Linux version 2.4.20_mvl31-2vp7fg456_rev4 (root@l-cb312-1) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #16 Fri Nov 24 15:6Memec Virtex-II Pro Development Board Port (C) 2002-2004 MontaVista Software, Inc. (source@mvista.com) On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 ip=on nfsroot=192.168.219.54:/root/myDesign/rootfs rw Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000 hr_time_init: arch_to_nsec = 20971520, nsec_to_arch = 429496729 Calibrating delay loop... 99.73 BogoMIPS Memory: 63072k available (1228k kernel code, 400k data, 60k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket OCP uart ver 1.6.2 init complete LSP Revision 28 ikconfig 0.5 with /proc/ikconfig Starting kswapd Disabling the Out Of Memory Killer devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au) devfs:s boot_options: 1 JFFS version 1.0, (C) 1999, 2000 Axis Communications AB JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0xfdfff003 (irq = 26) is a 16450 xgpio #0 at 0x40000000 mapped to 0xC507D000 xgpio #1 at 0x40020000 mapped to 0xC508E000 xgpio #2 at 0x40040000 mapped to 0xC509F000 xgpio #3 at 0xC00BCA10 mapped to 0xC50B0A10 xilinx_char_lcd at 0xFE804800 (256 bytes) mapped to 0xC50C2800 Data machine check in kernel mode. Oops: machine check, sig: 7 NIP: C00BC860 XER: 00000040 LR: C00BC8F4 SP: C02DDF60 REGS: c02ddeb0 TRAP: 0200 Not tainted MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c02dc000[1] 'swapper' Last syscall: 120 last math 00000000 last altivec 00000000 GPR00: C00BC8F4 C02DDF60 C02DC000 00000038 00001030 00000001 000007C7 C0160A9F GPR08: 00000000 C50C2800 00000036 C0180000 C0180000 FFFFFBFF FFFFFFFF FFFFFFFF GPR16: C001658F 00400000 004B0000 004B3000 44000044 004B0000 004B3000 004B0000 GPR24: 00000000 00400000 00400000 6F6F7466 00000000 C0180000 C0178A44 C0178A04 Call backtrace: 00400000 C00BC8F4 C00BCBE8 C016A634 C000244C C0006E7C Kernel panic: Attempted to kill init! <0>Rebooting in 180 seconds..<NULL> Thanks again everyone for their help in getting us so far. The 2 important things were Andrei's patch which proved to be indispensable and the others who directed us to the xparameters_<something>.h files with the hardware addresses. For some strange reason XPS was updating the xparameters_ml300.h file with the correct addresses but not the xparameters_2vxp.h file. We copied the <xp>_ml300.h file to the <xp>_2vxp.h file and had to edit two variables which were referring to 32MB flash (we replaced them with the 16MB addresses ?!). Then things started looking up. Has anyone an explanation for this confusion in .h files ? Thanks Andy Olivier GOUDARD wrote: > Dear Andrei, > > Thanks to your advices we managed to view characters on the serial line. > (I remind that we are trying to boot linux MontaVista 3.1 on V4FX12LC > board of Memec.) > It looks like we where using the wrong xparameters_2vpx.h file. > > We also applyied your patch in arch/ppc/boot/simple/head.S > > After modifications we obtained : > ______________________________________________________________________________ > > loaded at: 00400000 004B61E4 > board data at: 004B313C 004B3154 > relocated to: 0040564C 00405664 > zimage at: 00405C17 004B20B5 > avail ram: 004B7000 04000000 > > Linux/PPC load: console=ttyS0,9600 ip=on > nfsroot=192.168.219.54:/root/myDesign/rootfs rw > Uncompressing Linux...done. > Now booting the kernel > . > _______________________________________________________________________________ > > > Which is remotivating us a lot !! > I also managed to get a longer boot, but I encounter a kernel panic > during the serial driver configuration... > > We are wondering what to do now ? > Maybe we should try to find in xps why we are not using the right > xparameterXX.h file and generate a new bit file ? > Or maybe we should concentrate our efforts on Linux configuration ? > > Any comments are welcome that might help us in the ppc/linux boot quest ! > Thanks again Andrei, > Olivier > > > > > At 17:34 21/11/2006, Andrei Konovalov wrote: >> Olivier GOUDARD wrote: >> > 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. >> >> I meant a new board entry in the kernel configuration. >> Now I see - you are reusing the one for memec 2VPx. >> >> > 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. >> >> Pro 3.1 preview kit is rather old, and does not have a workaround >> required for Virtex4. This should not be a problem in your case though, >> as I believe the generated files in linux/arch should have it. >> Something like this hack: >> >> ---8<-------------------------------------------------------------- >> --- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1 >> +++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2 >> @@ -46,6 +46,11 @@ >> #endif >> >> start_: >> + /* PPC errata 213: only for Virtex-4 */ >> + mfccr0 0 >> + oris 0,0,0x50000000@h >> + mtccr0 0 >> + >> #if defined(CONFIG_FORCE) || defined(CONFIG_PPMC260) >> /* We have some really bad firmware. We must disable the L1 >> * icache/dcache now or the board won't boot. >> ---8<-------------------------------------------------------------- >> >> There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that, >> but the kernel tree you are using doesn't have Virtex4 config option >> (unlike e.g. community 2.6 tree or Montavista Pro 4.0) >> >> > 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 ? >> >> arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h >> >> The memec board uses this one (to find the addresses and the interrupt >> numbers). Make sure the defines there match your bitstream. >> >> > I will check my UART configuration which seems to be very wrong ! :-) >> >> Your UART is 16x50, not UART Lite, correct? > > ____________________________________________________ > Olivier GOUDARD, > European Synchrotron Radiation Facility > Machine Division - Power Supply Group > BP 220, F-38043 Grenoble Cedex, France > > Tel : +33 (0)4 76 88 24 69, Fax : +33 (0)4 76 88 20 54 > ____________________________________________________ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc 2006-11-24 20:39 ` Andy Gotz @ 2006-11-25 11:33 ` Andrei Konovalov 0 siblings, 0 replies; 10+ messages in thread From: Andrei Konovalov @ 2006-11-25 11:33 UTC (permalink / raw) To: Andy Gotz; +Cc: Olivier GOUDARD, linuxppc-embedded Hi Andy, Andy Gotz wrote: <snip> > xilinx_char_lcd at 0xFE804800 (256 bytes) mapped to 0xC50C2800 > Data machine check in kernel mode. > Oops: machine check, sig: 7 ... Looks like the kernel tries accessing non-existing IP, or the IP triggers some error on the bus. Could you tell me what IP the xilinx_char_lcd driver is expected to work with in your design? Thanks, Andrei ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Memec v4fx12lc - problem booting linux on ppc
@ 2006-11-23 7:31 Jaap de Jong
0 siblings, 0 replies; 10+ messages in thread
From: Jaap de Jong @ 2006-11-23 7:31 UTC (permalink / raw)
To: linuxppc-embedded
> We created our own platform with xps.
Ram defaults to opb_ddr. You should select plb_ddr; at least that was
the trick that worked for me...
Jaap
^ permalink raw reply [flat|nested] 10+ messages in threadend of thread, other threads:[~2006-11-25 11:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-11-20 11:42 Memec v4fx12lc - problem booting linux on ppc Olivier Goudard 2006-11-21 2:59 ` Yoshio Kashiwagi 2006-11-21 9:44 ` Olivier Goudard 2006-11-21 11:38 ` Andrei Konovalov 2006-11-21 15:11 ` Olivier GOUDARD 2006-11-21 16:34 ` Andrei Konovalov 2006-11-24 16:05 ` Olivier GOUDARD 2006-11-24 20:39 ` Andy Gotz 2006-11-25 11:33 ` Andrei Konovalov -- strict thread matches above, loose matches on Subject: below -- 2006-11-23 7:31 Jaap de Jong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).