Coldfire 547x, Linux and big memory.

[comio]

HI Freescale People,

I already posted this message on u-boot-users ML:

Hi List,
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
(16M)
- modify the code of do_bootm function in order to limitate mem_size to
16M
- 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
guilt).


Best regards,

luigi

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.

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.

Best regards.

Luigi Mantellini


Message Edited by comio on 2008-06-07 02:05 PM

[kmahan]

The previously mentioned 2.6.24 patchset for M547x/M548x has been pushed out to Bitshrine.  These correspond to the kernel spec file:

    kernel-2.6.24-m547x_8x.spec.in
   
Note that this is NOT the current code.  This was an internal release.  One major bug exists in this code drop -- ioremap has some serious issues that have been fixed in the 2.6.25 version.  Also not much in the way of drivers are handled.  Please remember that this was just an internal snapshot of my dev tree.  It isn't a supported release.

If you do find bugs please drop me a message.

The upcoming BSP is on the 2.6.25 codebase.

[comio]

Hi kmahan,

thanks for the upload.
By a fast check, I make the same changes on my port. Anyway the patch "kernphys" is very interesting. I will integrate this on my kernel asap... waiting for the next Freescale release.

I have a simple question: Why Doesn't Freescale share the source code on kernel.org repositories?

Thanks again,

luigi

[kmahan]

Hi Luigi,

The plan is to get patches submitted after this next series of BSP releases.  I've been working on a set of patches, just need more time in the day.  Part of the problem is that I have to maintain multiple kernel versions -- since the BSPs are currently targetted against 2.6.25 but the patchset has to be against the head (currently 2.6.26, but that shifts).

So yes -- I intend to get v4 coldfire into mainline -- hopefully later this year.

--Kurt

[comio]

This a great news.

Thanks a lot for your answer.

luigi

[kmahan]

For the next BSP release the memory mapping has changed.  The kernel now has virt mapped to phys for ram, and ACRs setup to map sdram.  So there is no longer a need for TLB mappings of the first 16M in kernel space.  The kernel base address 0xC0000000 has now moved to SDRAM_BASE.

--Kurt

[comio]

This is a good news for us. Can Freescale provide me a snapshot of the current source code?
I'm working on the kernel development and I like to avoid to replicate the effort.

Thanks and best regards,

luigi