[U-Boot] mpc8313 SPL, relocate_code, large page NAND

Joakim Tjernlund joakim.tjernlund at transmode.se
Tue Apr 20 15:30:56 CEST 2010


"Peter Vollmer" <pvollmer-u-boot at innominate.com> wrote on 2010/04/20 14:12:41:
>
> On Tue, 20 Apr 2010 11:57:09 +0200, Joakim Tjernlund
> <joakim.tjernlund at transmode.se> wrote:
> > Probably a BDI2000 issue. If memory serves right BDI2000 flushes the
> > cache when it hits a BP.
> >
> > Try this addin this to your BDI .cfg file:
> > TSZ4    0xe6000000   0xe60001100 ; init stack space for cache
> > ; needs a 'sap 0' in BDI
> >
> > Then reboot BDI 2000, telnet to it and enter "sap 0" at the cmd prompt.
> > Start debugging.
>
> Ok, but my problem is that it works with the BP enabled, so I can step

Oh, didn't read that carfully.

> through the whole relocate_code function, or simply continue, without a
> problem. It however does not work without the BP, or with the BP set too
> late, or if the board runs standalone without the emulator. So I guess I
> need to fix something in u-boot, not in the emulator configuration ...

Then I suspect that your DRAM isn't configured properly, perhaps burst access
is unreliable.

>
> But the bit about the BDI flushing the cache when a breakpoint gets hit,
> could that indicate that I have to flush the cache prior to entering the
> relocate_code loop? In case of a cache problem, wouldn't I just have to
> expect bogus data copied into RAM?
> Instead, the core is frozen, with the PC at 0xfff00ab0 , and it refuses to
> step any further afterwards. Would it maybe help to try to include the
> exception traps in the spl bootloader ?

Dunno, try running with any i/d cache for the DRAM. If that works
it is very likely you have misconfigured the DRAM



More information about the U-Boot mailing list