[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