Re: Memec v4fx12lc - problem booting linux on ppc

[Andrei Konovalov <akonovalov@ru.mvista.com>]

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
>>
>>
> 
> 
>