[U-Boot-Users] My board doesn't boot - ram controller problem?

Peter Asemann peter.asemann at web.de
Thu Jun 2 16:56:38 CEST 2005


Hi there!

I've made tests to make sure my hardware boots before trying to run the 
u-boot. I found out it doesn't boot. So this question isn't that u-boot 
related; but it's close.

To test booting I wrote a very small assembler program (9 lines) which 
switches on a LED on my custom MPC875 powererd board and then loops forever.

I had the following assumptions:

1. The MPC875 will try to boot from 0xfff00100 due to my HRCW settings, 
which cause MSR[IP] to be "1".
2. The whole memory is tiled with the first 64K of the flash due to the 
fact that OR0 is 0x00000ff4 when the board boots, which should mask out 
the first 16 Bit of any address, so 0xffffxxxx addresses the same memory 
location as 0x0000xxxx.

I succeeded flashing my testprogram to 0x100 in the flash. The program 
run within flash by the telling the debugger to jump to 0x100. Switching 
off and on the board, nothing happened.

So I took a closer look on the memory in the debugger to make sure my 
assumptions were correct, and found out that assumption 2 seem not to 
fit the real world.
Though the OR0 should mask the whole first 16Bit of the address (so 
0xffff0100 should be the same as 0x00000100), it doesn't really do that.
Only the first 8 bit of the address are completely ignored, so 
0xff000100 is the same as 0x00000100. But 0xff800100 isn't, it seems to 
show empty flash (0xffffffff), I found out when looking into memory 
using the debugger.

Actually I have no idea what's wrong. I didn't find a hint in the MPC 
manual this could happen. I feel like maybe I'd understand that if I 
already had read the comment about relocating memory and the MPC manual 
often enough as I was told... but I didn't do that yet.

Maybe the fact that my flash is 16MB (0x1000000) big kind of disables 
the OR-masking-mechanism?

That could mean I need to put my "boot code" at 0xf00100 in my flash or 
change the board's setup so that IMMR is at 0xff000000 (instead of 0x0) 
and MSR[IP] is "0" instead of "1", so the board will really boot from 0x100.

Whatever. Any hints?

Best regards,

Peter Asemann




More information about the U-Boot mailing list