Hi again,
The OS supports moving the log memory area so that is not a problem. The reason why it would be good to be able to protect a memory area, independent of where it is located, without recompilation is to simplify the use for customers that have a hardware that are delivered with u-boot and no knowledge about u-boot. It would be very simple for them to just add a system parameter in order to protect a part of the RAM. It could be in the end of RAM and work as CONFIG_PRAM does, but the goal would be to remove the need for recompilation.
It seems like this feature already exists in some way, I misinterpreted this yesterday when I looked at the readme and source. Is it like this? If I have a compilation of u-boot that does not define CONFIG_PRAM, is still possible to add the environment parameter 'pram' to add protection of the upper X KB?
Thanks, Markus
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: den 23 augusti 2007 21:22 To: Markus Malmgren Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Protect an area in RAM
In message DC6F86A94046A64094043D44A3A708F7A14AFA@sestoex02.enea.se you wrote:
Thanks for you answer! I have found that one, but I need to be able to specify exactly what memory range that shall be protected. I did find
The pRAM area is always at the very upper end of the RAM. If you want to pass it unchanged between U-Boot and an OS and back there are not many options.
the CONFIG_PRAM-parameter but I did not figure out how to tell u-boot exactly what range not to whipe-out. Such as do not destroy 0x1000-0x2000. Also the solution that I would like to find/create is
to
have the possibility to set a protect area using a system parameter in order to be able to change the protection zone without recompilation. Would that be a good feature?
I have never seen a need for this, and, given the things you have to keep in mind (memory resizing coee after reset, eventually ECC initialization, making sure that both U-Boot and the OS agree on exactly the same memory area, etc., I don;t see an easy way to do what you want, either.
Why do you have to use a specific memory range? It sounds as if this was a restriction that comes from the OS - how about fixing the problem there?
Best regards,
Wolfgang Denk