U-Boot early init problem (InstructionTLB Trap) booting P1022 from NOR Flash

[caryo_brien]

We have a board with a P1022 and 256MB of NOR Flash.

I can program U-Boot with CodeWarrior, and step through

a lot of the initialization.

It gets through a lot of start.S and into cpu_init_early_f.

Near the end of cpu_init_early_f it calls

invalidate_tlb(1)

disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB);

init_tlbs(); /* NEVER GETS HERE */

During the disable_tlb() there is an InstructionTLB trap, indicating that

the TLB for the code has been removed.

I check the TLB1 entries, just before and after.  There are two entries

covering the boot area before, (LMMU2_CAM2 and LMMU2_CAM15)

and only 1 (LMMU2_CAM15) after

Interestingly, the only difference is the TS (Address Space?) value.

Any idea how I can solve this problem?

Also, I have some general questions about booting from NOR:

1) Do I need CONFIG_SPL to boot from NOR?

2) There don't seem to be any TLB entries after reset.  How does

    the cpu access the code without these?

3) Does Code Warrior, through a USB tap, go through the MMU when

    it accesses memory, or is this bypassed.

Thanks in Advance

Cary O'Brien

[scottwood]

You can't step over the code after the debug TLB entry is removed, until the debug handler is once again covered by a TLB entry (this happens when switching to AS=0 after returning from cpu_init_early_f).  Set a breakpoint after reaching AS=0.  If code doesn't reach that point, use other techniques to debug (e.g. halt the core and see what the contents of the TLB are).

For your other questions:

1. No, don't use CONFIG_SPL with NOR boot.

2. There is one TLB entry after reset, that maps only the 4K page containing the reset vector.

3. On e500v2-based chips I believe all such accesses are physical memory, unless the CodeWarrior GUI is doing TLB lookups itself to translate.

[caryo_brien]

Just to follow up

Finally got u-boot in flash to start.  There were several problems.

1) Only 4k of the boot code was mapped, so when it tried to jump

   out of that area it got the InstructionTLB error.  I think I had

   settings from a NAND boot config that used a pre-loader that

   had to fit in 4k?  Not 100% sure.

2) I had memory overlap between NOR flash mapped regions and
     the L1 cache being used as ram during u-boot flash startup.
     The P1022 has a L2 cache that can be used for ram, but there
     didn't seem to be any way to enable it.   It took me a while
     to figure out how to use the CW cache display to look into the 'ram'
     that was being used at startup.

3) I had Pin Muxing config sequences that briefly left things disconnected,
     this worked running out of ram, but not out of flash.

3) I did not fully understand the limitations of CodeWarrior and the USB Tap
     for debugging in flash.  Sometimes I thought there was a problem when
     it was just not possible to step through certain sequences of code.  Also
     sometimes CW could see memory that wasn't mapped by the CPU.  I understand
     why that happens but did not expect it.

Currently I am still having some problems with the flash.
The flash is mapped to F000 0000.  This may conflict with
the mutli-processor boot block mapped by U-boot.  I tried
to move it to C000 0000 using the mmu table entries
in tbl.c, but some of those are overwritten.

When exactly I can remap flash from F000 0000 to, say
C000 0000 isn't clear.

Also only half the DDR is detected.  I'm not sure exactly how
the configuration in ddr.c has to be set up to detect the
second bank.

Anyhow, a lot of progress today and I thought I'd include what I had to

fix in case anyone else runs into similar problems.

Cary O'Brien

[scottwood]

1. The normal U-boot code should deal with this fine, by creating a larger mapping before jumping out of the 4K page.  Again, you should not be using SPL when booting from NOR.

2. Regardless of whether you use L1 or L2 for early storage, you need to make sure there's no overlap with any I/O.

3 (the first). Don't do that. :-)  If it ever works it's by chance.  If you absolutely must do it, then make sure you are executing out of locked cache lines.

3 (the second). Yes, due to hardware limitations I don't recommend stepping/breakpointing as a way of debugging early U-Boot code.

I'm not sure what you mean by "some of those are overwritten".  If you change the address of flash in the board config file, that should propagate to the TLB setup code.

For DDR, do you mean half is detected, or half is mapped?  At most 2 GiB will be mapped by U-Boot, because it needs to leave some effective address space free for I/O.  If it's not all being detected, are you using SPD or hardcoded DDR info?