Dear Heiko Schocher,

In message 4A66A86D.7070200@denx.de you wrote:

Andreas Huber wrote:

...

We are using the pRAM feature (CONFIG_PRAM) on the PPC architecture. As we are switching to an ARM architecture (Kirkwood) I am wondering if there is an equivalent U-Boot feature for this (CONFIG_PRAM did not work).

As this functionality uses RAM at the end of RAM, it should be possible to add this also to ARM plattforms. Jean-Christophe, Prafulla, are there any objections on it?

Well, if you want to do it Right (TM) that means we would take this chance and fix the ARM memory map, which implies to implement relocation to a dynamicalle detemined relocation address.

Best regards,

Wolfgang Denk

Dear Holger,

In message 4A671863.9040303@keymile.com you wrote:

...

Well, if you want to do it Right (TM) that means we would take this chance and fix the ARM memory map, which implies to implement relocation to a dynamicalle detemined relocation address.

can you explain this a little bit more in detail? Sounds like, that this is a larger chunk of work?

The ARM port of U-Boot is seriously broken in several respects. When the ARMBoot project was forked off the PPCBoot (as it was caled by then), the implementors did not care for compatibility, and decided in fevour for minimal porting effort by giving up some features that we considered essential when designing PPCBoot / U-Boot on PowerPC.

Just to give one example: on PowerPC, we normally use code to automatically determine the memory sizes on a board. One binary image of U-Boot can run unchanged on boards with for example different sizes of flash and RAM. U-Boot will always relocate itself to the end of the available RAM, thus leavin the maximum possible amount of RAM available for the user, for example to load Linux kernel and root file system.

If we need to reserve memory, like for protected RAM, or for a frame buffer we can shared between U-Boot and Linux (so you can have a splash screen right after power-on which does not even flicker when Linux boots), or for a shared log buffer (so you can for example process U-Boots Power-On Self Test messages in Linux using standard syslog tools, or you can use U-Boot to dump the Linux kernel's crash messages post mortem in U-Boot or in Linux after rebooting the system), we just shift the relocation address for U-Boot down by the required amount.

If you need a different amount of pRAM, just "setenv" the "pram" environment variable, and U-Boot will auto-adjust at the next reboot.

On ARM, we don't do any such relocation, we link the image for a fixed address in RAM. So assum you have a board that can come with 32 MB or with 64 MB of RAM. You will have to link U-Boot close to the end of the 32 MB border - say to run at 31 MB. On a 64 MB board this means it sits right in the middle of availabel RAM - you have some 63+ MB of RAm free, but you cannot find more than 32 MB contiguous space. If you need pRAM or framebuffer or log buffer, you will have to configure sizes at compile time, and then you cannot change it at run time. Systems with variable RAM sizes will always suffer from the same restrictions like on the board with the smallest RAM configuration.

And so on and on...

That's why I think that the ARM memory map needs to be put from top on it's feet where we can make use of many of the nice features we have in U-Boot.

Best regards,

Wolfgang Denk