[U-Boot-Users] Protect an area in RAM
Markus Malmgren
markus.malmgren at enea.com
Fri Aug 24 12:38:28 CEST 2007
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 at denx.de [mailto:wd at denx.de]
Sent: den 23 augusti 2007 21:22
To: Markus Malmgren
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Protect an area in RAM
In message <DC6F86A94046A64094043D44A3A708F7A14AFA at 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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If today is the first day of the rest of your life, what the hell was
yesterday?
More information about the U-Boot
mailing list