cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
10,972 Views
Registered: ‎01-19-2009

first-level bootloader to load u-boot on ML507 dies with TLB exception

Jump to solution

I am trying to write a first-level bootloader (to be in BRAM) that will load u-boot.  I have a u-boot.bin that I can load via XMD dow -data and I know where the entry point currently is.

 

I've burned the u-boot.bin image into flash @ 0xFC000000.

 

I've taken the EDK sample code (bootloader_bclinux) and changed it to do:

{

     void (*laddr)();          
     print("Copying to RAM...\r\n");
     memcpy((void *)0x02000000, (void *)0xFC000000, 0x100000);
     laddr = (void *) 0x02022f14;
     (*laddr)();

}

 

When I step through the code I find that the TLB exception is taken right after the tlb entries are invalidated in u-boot/cpu/ppc4xx/start.S. 

 

        /*----------------------------------------------------------------*/
        /* Clear all TLB entries -- TID = 0, TS = 0 */
        /*----------------------------------------------------------------*/
        addis   r0,0,0x0000
        li      r1,0x003f       /* 64 TLB entries */
        mtctr   r1
rsttlb: tlbwe   r0,r1,0x0000    /* Invalidate all entries (V=0)*/
        tlbwe   r0,r1,0x0001
        tlbwe   r0,r1,0x0002
        subi    r1,r1,0x0001
        bdnz    rsttlb

        bl      tlbtab          /* Get tlbtab pointer */     <-- exception occurs at the fetch of the instruction at tlbtab

 

 

This makes sense since all of the TLB entries are invalid.  My questions are:

1)  Is it wrong to invalidate all the TLBs and pull the rug out from it?

2) Why does this work from XMD?

3) Is there something I need to do before the (*laddr)() to put the mmu/tlbs in a different state?

 

This has to be common to have a first-level bootloader in BRAM.  Any suggestions would be appreciated.

 

Thanks.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
12,655 Views
Registered: ‎01-19-2009

I figured out what seems to be going on.

 

EDK sets up 32 tlb entries (16 with TS=0 and 16 with TS=1).    The EDK code runs with MSR[DS]=1.  U-boot only sets up 16 tlb entries (all with TS=0) so it crashes with MSR[DS]=1.

 

I added the line

    mtmsr(0);

 

to my code just prior to jumping into the u-boot entry point and uboot now comes up.

 

 

View solution in original post

0 Kudos
7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
10,963 Views
Registered: ‎09-10-2008

I'm certainly no expert on this topic, but I think XMD setups up the MMU for a flat mapping and you never see that happen.  That way it can load memory when you tell it.

 

Thanks,

John

0 Kudos
Highlighted
Observer
Observer
10,960 Views
Registered: ‎01-19-2009

I can believe that XMD sets up the map more completely since it does have the mhs to work from.  I know that the 440 sets up a single entry at reset for the lower 4K (FFFFF000 - FFFFFFFF) and the EDK startup code appears to map the whole space (virtual = physical).

 

I don't really understand why that code doesn't break when executing from XMD because it would seem to have the same problem.

 

I don't think I saw the other PPC processors clearing the TLB entries in their u-boot init code.  And I don't think the kernel does that.

 

Is it possible that u-boot was never tried loading from flash in such a way?  Maybe the init code of u-boot was overly agressive.

 

Is the 440 unique in that you can't turn off the MMU?

 

Clearly there needs to be some understanding between u-boot/kernel and the loader in BRAM.

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
10,953 Views
Registered: ‎09-10-2008

I'll ask someone else to take a quick look that knows the stand alone code and what XMD is doing maybe.

 

I'll be tommorrow.

 

-- John

0 Kudos
Highlighted
Explorer
Explorer
10,929 Views
Registered: ‎08-14-2007
IIRC, from my previous experience w/ the 440GX, our FLASH-based bootloader had to setup the initial TLB entries to map in the SDRAM. Our 440GX processor had the FLASH physically connected on the peripheral bus and mapped in at 0xFxxxxxxx-0xFFFFFFFF for the bootloader/reset vector.

If you're trying run uBoot from RAM and uBoot has now just flushed all of the TLB-mappings, then I would expect it to bomb out.
0 Kudos
Highlighted
Observer
Observer
12,656 Views
Registered: ‎01-19-2009

I figured out what seems to be going on.

 

EDK sets up 32 tlb entries (16 with TS=0 and 16 with TS=1).    The EDK code runs with MSR[DS]=1.  U-boot only sets up 16 tlb entries (all with TS=0) so it crashes with MSR[DS]=1.

 

I added the line

    mtmsr(0);

 

to my code just prior to jumping into the u-boot entry point and uboot now comes up.

 

 

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
8,641 Views
Registered: ‎09-18-2009

Using a xilinx ml507 development board, and using the provided uboot from xilinx ml507 web site, I am trying to run uboot from flash. I am able to run it from RAM, but from flash it crashes.

I did compile uboot to run from flash address 0xfc000000, and save u-boot.bin to flash at 0xfc000000.

I see a note here that you did a mtmsr(0);, I would like to add this line to cpu_init.c just before "bl      tlbtab", what do I need to type in to accomplished what you did. I am confused about what you did with "mtmsr(0);".

 

When I run uboot from 0xfc000100 I get the following:

go fc000100

## Starting application at 0xFC000100 ...

**bleep**: 00002B64 XER: 20000000 LR: 00002308 REGS: 0fe9d510 TRAP: 0700 DEAR: FC0027C0

MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00

 

GPR00: 0FFAA934 0FE9D600 0FE9DB48 0FE9D610 0FE9D734 0FE9D734 00000010 00000000

GPR08: FFFFFFFF 00000020 00000000 00000000 0000000F F8BF7FFA 0FFCFE00 0FFC28E0

GPR16: 0FFC2904 0FFC2910 0FE9D974 0FE9D874 00000000 0FE9D600 00000000 00002308

GPR24: 00002B64 00000000 00000000 000000F5 0FE9D734 FC000100 0FFD03F8 00000002

** Illegal Instruction **

Call backtrace:

00000002 FC000100 0FFAA934 0FFA7848 0FFA7E08 0FFA15E0 0FFA0678

Program Check Exception

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,634 Views
Registered: ‎09-10-2008

It almost sounds like you didn't get it built right for flash.  I have not put it into flash myself so I can't tell you exactly what to do.

 

I was thinking that u-boot would relocate itself from flash to ram if built for flash.  But another part of me says that a small boot loader is needed in BRAM to load from flash to ram and start it.

 

You might look at the Xilinx app notes as there's one on a boot loader.  Sorry but I typically stop all my work before that.

 

Have you tried to look up the address in the link map for that core dump you got as that might help you diagnose the problem?

 

You could also try to just dump the registers in XMD if you're using a Xilinx probe to execute the code.

 

-- John

0 Kudos