[U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash

Russell McGuire rmcguire at videopresence.com
Fri Dec 21 11:45:57 CET 2007


Maybe somebody can help me understand what I am seeing.

Dealing with the printf causing crashes problem.

This only occurs if printfs are caleed from within the uec_phy.c file, and
only them within functions that are mapped as part of a phy specific call,
i.e. a function that was within a specific part, marvell, national, etc... 

So when a read_status call is called, of course depending on your
configuration it might get redirected to call genmii_read_status or

However, this once inside the phy mapped functions, printfs are illegal.
And causing BAD trap errors, in this case it is causing an unhandled
exception on Vector 400 on my system, which is a static storage handler
error. Not entirely sure on WHY, but looking at the back trace and several
pointers, I have noticed this.

Up till the call to any phy specific function, U-boot is happily running
from the top of DDR Ram, but as soon as we traverse into phy specific
handlers, it jumps BACK INTO FLASH! and starts executing! On my system this
means the backtrace will contain a lot of calls around the 256MB boundary
i.e. 0x0ffxxxxx and then suddently I will see return address being pushed at
0xE00xxxxx.  My guess is that when printf or similar gets called, it tries
to do a relative pop/push to the stack or something or tries to relatively
access RAM and BOMBS.

My base system has the following setup
DDR2 RAM: 0x00000000 - 0x1FFFFFFF (512MB)
FLASH: 0xE0000000 - 0xEFFFFFFF (128MB physical, 128MB reserved for future)
SOCL: 0xF0000000 - 0xF1000000 (IMMR SPACE)

When I get the error, I see the PC register is pointing at 0xFBFe7ee4????

This would make perfect sense, if the stack were placed at the top of ram,
and I was executing 'accidently' from flash, i.e. it the PC was assumed to
be at 0x0fxxxxxx and it somehow got shifted to the 0xE0xxxxxx block, and
then tried to relatively add 256MB to get to the stack. It would end up at
the 0xFxxxxxxx area??? 

Am I way off base here??  WHY is the UEC_Driver accessing flash after U-boot
is running from RAM?


More information about the U-Boot mailing list