I already posted this message on u-boot-users ML:
Hi List,I think that the Head.S code should be re-written in order to manage the memory in a more flexible manner. In addition to my consideration (posted on U-Boot list) I modified the stack initialization and the parameters pointers management in order to copy (before to start the memory management) the parameters pointers from the passed stack (that U-Boot initializes on the end of the memory) to the early stack initialized by Head.S code. This avoid to lost the visibility of the pointers if them are placed at the end of memory (with address>16M). This doesn't resolve all the problems, of course.
Hi Tsi-Ching Liew,
I'm using u-boot 1.3.2 (trunk) on my application in order to boot the
freescale linux kernel for mcf547x cpus. My application has a lot of
memory (256MB) and this causes difficulties to start the linux kernel.
The Head.S code of the mcf547x Linux Kernel allows a one-to-one TLB map
for the first 16MB of memory (mcf547x can use up to 1M for page). From
this observation it is mandatory that U-BOOT should call the kernel
allowing all structures (board descr., intrd, env and command line) onto
the first 16M of physical RAM.
The solutions can be:
- to use the env variables bootm_low = 0 and bootm_size = 0x1000000
- modify the code of do_bootm function in order to limitate mem_size to
- Pray the Freescale to modify the kernel code in order to use a better
and more flexible initialization code.
I'm studying for smart modifications for Kernel and U-Boot (that hasn't
I see a serious limitation on the ramdisk management... anyway the freescale kernel code (for mcf5445x) ignores the parameters passed by boot-loader except the cmdline... (it fill a local static structure that seems not used by other code).
I hope that my comments and Federico's comments (that has discovered a lot of these issues) help Freescale to provide a more reliable and better linux kernel for mcf547x and mcf544xx CPUs.
My 2 cents.
Message Edited by comio on 2008-06-07 02:05 PM