[U-Boot-Users] Protect an area in RAM

[U-Boot-Users] Protect an area in RAM

[Markus Malmgren]

Hi,

 

Many hardware manufactures provide their development platform with
u-boot. I was wondering if there is a feature (did not find anything) in
u-boot to protect a specific area in the RAM from being overwritten when
u-boot boots a microcontroller? The reason for this is that we store
debug information between restarts from our software and using u-boot
this is destroyed.

 

If this feature does not exist, one general solution would be to add a
system parameter in which areas that are not to be destroyed could be
added as a default feature of u-boot. Would this be a feature that
others need as well? If so I will start to investigate what could be
done.

 

Regards,

Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070823/73d145ec/attachment.htm 

[U-Boot-Users] Protect an area in RAM

[Matthias Fuchs]

Hi Markus,

perhaps CONFIG_PRAM (protected RAM) is what you need.
See README for details.

Matthias

On Thursday 23 August 2007 10:30, Markus Malmgren wrote:
> Hi,
> 
>  
> 
> Many hardware manufactures provide their development platform with
> u-boot. I was wondering if there is a feature (did not find anything) in
> u-boot to protect a specific area in the RAM from being overwritten when
> u-boot boots a microcontroller? The reason for this is that we store
> debug information between restarts from our software and using u-boot
> this is destroyed.
> 
>  
> 
> If this feature does not exist, one general solution would be to add a
> system parameter in which areas that are not to be destroyed could be
> added as a default feature of u-boot. Would this be a feature that
> others need as well? If so I will start to investigate what could be
> done.

[U-Boot-Users] Protect an area in RAM

[Wolfgang Denk]

In message <DC6F86A94046A64094043D44A3A708F7A148D4@sestoex02.enea.se> you wrote:
> 
> Many hardware manufactures provide their development platform with
> u-boot. I was wondering if there is a feature (did not find anything) in
> u-boot to protect a specific area in the RAM from being overwritten when
> u-boot boots a microcontroller? The reason for this is that we store
> debug information between restarts from our software and using u-boot
> this is destroyed.

I'm seriously surprised that you  did  not  find  anything.  Did  you
actually search for "protected RAM"?

-> grep -ir 'protected ram' *
README:- Protected RAM:
README:         "protected RAM", i. e. RAM which is not overwritten
README: ...             eventually: pRAM (Protected RAM - unchanged by reset)
board/netstal/hcu5/README.txt:   *  - protected RAM
include/configs/CCM.h:#define   CONFIG_PRAM             512     /* reserve 512kB "protected RAM"*/
include/configs/CMS700.h:#undef  CONFIG_PRAM                    /* no "protected RAM"           */
include/configs/DP405.h:#define CONFIG_PRAM             2       /* reserve 2 kB "protected RAM" */
include/configs/PCI405.h:#define CONFIG_PRAM            2048    /* reserve 2 MB "protected RAM" */
include/configs/PN62.h:#define CONFIG_PRAM              1024            /* reserve 1 MB protected RAM*/
include/configs/VOM405.h:#undef  CONFIG_PRAM                    /* no "protected RAM"           */
include/configs/pcu_e.h:#define CONFIG_PRAM             2048    /* reserve 2 MB "protected RAM" */
lib_m68k/board.c:        *      - protected RAM
lib_m68k/board.c:        * reserve protected RAM
lib_m68k/board.c:       debug ("Reserving %ldk for protected RAM at %08lx\n", reg, addr);
lib_m68k/board.c:        * taking into account the protected RAM at top of memory
lib_ppc/board.c:         *  - protected RAM
lib_ppc/board.c:         * reserve protected RAM
lib_ppc/board.c:        debug ("Reserving %ldk for protected RAM at %08lx\n", reg, addr);
lib_ppc/board.c:         * taking into account the protected RAM at top of memory


> If this feature does not exist, one general solution would be to add a
> system parameter in which areas that are not to be destroyed could be
> added as a default feature of u-boot. Would this be a feature that
> others need as well? If so I will start to investigate what could be
> done.

This feature has been available for a long, long time, as well  as  a
log  driver  which  is  intended  to  pass  for  example  U-Boot POST
information to the OS (Linux), or to allow U-Boot to dump Linux'  log
buffer after a crash.

I guess you should refine your search methods.

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
I'm frequently appalled by the low regard you Earthmen have for life.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] Protect an area in RAM

[Markus Malmgren]

Hi!

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 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?

Thanks,
Markus




-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: den 23 augusti 2007 12:42
To: Markus Malmgren
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Protect an area in RAM

In message <DC6F86A94046A64094043D44A3A708F7A148D4@sestoex02.enea.se>
you wrote:
> 
> Many hardware manufactures provide their development platform with
> u-boot. I was wondering if there is a feature (did not find anything)
in
> u-boot to protect a specific area in the RAM from being overwritten
when
> u-boot boots a microcontroller? The reason for this is that we store
> debug information between restarts from our software and using u-boot
> this is destroyed.

I'm seriously surprised that you  did  not  find  anything.  Did  you
actually search for "protected RAM"?

-> grep -ir 'protected ram' *
README:- Protected RAM:
README:         "protected RAM", i. e. RAM which is not overwritten
README: ...             eventually: pRAM (Protected RAM - unchanged by
reset)
board/netstal/hcu5/README.txt:   *  - protected RAM
include/configs/CCM.h:#define   CONFIG_PRAM             512     /*
reserve 512kB "protected RAM"*/
include/configs/CMS700.h:#undef  CONFIG_PRAM                    /* no
"protected RAM"           */
include/configs/DP405.h:#define CONFIG_PRAM             2       /*
reserve 2 kB "protected RAM" */
include/configs/PCI405.h:#define CONFIG_PRAM            2048    /*
reserve 2 MB "protected RAM" */
include/configs/PN62.h:#define CONFIG_PRAM              1024
/* reserve 1 MB protected RAM*/
include/configs/VOM405.h:#undef  CONFIG_PRAM                    /* no
"protected RAM"           */
include/configs/pcu_e.h:#define CONFIG_PRAM             2048    /*
reserve 2 MB "protected RAM" */
lib_m68k/board.c:        *      - protected RAM
lib_m68k/board.c:        * reserve protected RAM
lib_m68k/board.c:       debug ("Reserving %ldk for protected RAM at
%08lx\n", reg, addr);
lib_m68k/board.c:        * taking into account the protected RAM at top
of memory
lib_ppc/board.c:         *  - protected RAM
lib_ppc/board.c:         * reserve protected RAM
lib_ppc/board.c:        debug ("Reserving %ldk for protected RAM at
%08lx\n", reg, addr);
lib_ppc/board.c:         * taking into account the protected RAM at top
of memory


> If this feature does not exist, one general solution would be to add a
> system parameter in which areas that are not to be destroyed could be
> added as a default feature of u-boot. Would this be a feature that
> others need as well? If so I will start to investigate what could be
> done.

This feature has been available for a long, long time, as well  as  a
log  driver  which  is  intended  to  pass  for  example  U-Boot POST
information to the OS (Linux), or to allow U-Boot to dump Linux'  log
buffer after a crash.

I guess you should refine your search methods.

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
I'm frequently appalled by the low regard you Earthmen have for life.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] Protect an area in RAM

[Wolfgang Denk]

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

-- 
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?

[U-Boot-Users] Protect an area in RAM

[Markus Malmgren]

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 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@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?

[U-Boot-Users] Protect an area in RAM

[Wolfgang Denk]

In message <DC6F86A94046A64094043D44A3A708F7A1507F@sestoex02.enea.se> you wrote:
> 
> 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? 

No. If you don't enable the feature in the configuration, you cannot
use it.

> -----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

Please don't top post / full quote.

Please read http://www.netmeister.org/news/learn2quote.html

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
All these theories, diverse as they are, have two things  in  common:
they explain the observed facts, and they are completeley and utterly
wrong.                       - Terry Pratchett, _The Light Fantastic_