Quote:
Originally Posted by knc1
You are getting ahead of the work described in this thread.
ixtab described data written to DRAM before loading u-boot as not being able to be found at the same address as after loading u-boot.
So yes, looking at the TLB entries would give us some information with which to replace the guesses with.
And ixtab is correct, we don't need U-boot to do the DRAM initialization - sending i.ROM a CSF list of address, data, data size will get all of that I/O done before it executes the downloaded application.
For instance, the "RAM kernel" (that's en_Freescale for client command processor). It that case the off-chip resources are started by the files sent prior to downloading the "RAM kernel" itself.
And we got into this long thread because this suggested alternative code passes "null" for the DCD and then blindly uses some binary objects borrowed from Freescale utiliites.
|
OK, I could be wrong with MMU. It's most possibly enabled at system boot (according to chapter 6.4.1 and following NOTE and also chapter 6.4.5; I'm referring to i.MX50 Reference Manual). And it must be disabled by U-Boot on executing
bootm command. So this sequence theoretically (but not necessary) could introduce some problems (but only if MMU is really enabled on boot, because such a behaviour could be disabled by OEM is specific fuse is blown).
But CSF? RAM kernel? CSF is relevant only to secure boot of cryptographically signed code. HAB (i.e. secure booting) is disabled on Kindle Touch. And "RAM kernel" is a term of ATK, which isn't supporting i.MX50.
...Oh, MMU is disabled in early stage of U-Boot executing in
cpu/arm_cortexa8/start.S after
cpu_init_crit: label. And it's not enabled back, because CONFIG_ARCH_MMU isn't defined in any of yoshi board config.
@ixtab, BTW, MMU is disabled in U-Boot before executing of DRAM initialization code. Also some relocating code is present in
cpu/arm_cortexa8/start.S after
relocate: label. Also there is relevant define right before label.