[U-Boot] CONFIG_BOOTCOUNT_LIMIT

[U-Boot] CONFIG_BOOTCOUNT_LIMIT

[Sridhar Addagada]

I' need to enable CONFIG_BOOTCOUNT_LIMIT, which is based one MPC8377ERDB,? and am looking for recommended address for CONFIG_BOOTCOUNT_ADDR, any suggestions.

Thanks
S

[U-Boot] CONFIG_BOOTCOUNT_LIMIT

[Sridhar Addagada]

Any recommendations for the scratch pad memory area.? I noticed in bootcount.c that even though the configured memory area is updated, even the environment variable is also being update.? My question is that will it got lost when the kernel takes control.


Thanks
S



________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Friday, November 25, 2011 5:24 PM
Subject: CONFIG_BOOTCOUNT_LIMIT
 

I' need to enable CONFIG_BOOTCOUNT_LIMIT, which is based one MPC8377ERDB,? and am looking for recommended address for CONFIG_BOOTCOUNT_ADDR, any suggestions.

Thanks
S

[U-Boot] CONFIG_BOOTCOUNT_LIMIT

[Sridhar Addagada]

Sorry! my mistake, the code is in main.c

:
:

bootcount_store(bootcount);
sprintf (bcs_set, "%lu", bootcount);
setenv("bootcount", bcs_set);
:
:



________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Tuesday, November 29, 2011 9:03 AM
Subject: Re: CONFIG_BOOTCOUNT_LIMIT
 

Any recommendations for the scratch pad memory area.? I noticed in bootcount.c that even though the configured memory area is updated, even the environment variable is also being update.? My question is that will it got lost when the kernel takes control.


Thanks
S



________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Friday, November 25, 2011 5:24 PM
Subject: CONFIG_BOOTCOUNT_LIMIT
 

I' need to enable CONFIG_BOOTCOUNT_LIMIT, which is based one MPC8377ERDB,? and am looking for recommended address for CONFIG_BOOTCOUNT_ADDR, any suggestions.

Thanks
S

[U-Boot] uboot to load uboot

[Sridhar Addagada]

Here is a scenario, i have a working version of the u-boot on my board, and am trying my changes.? Am not sure it is going to freeze the board, so would like the present version to load the new version for testing before it can be burned to flash.? Is it possible to do this or is it already done?

Thanks
S

[U-Boot] uboot to load uboot

[Mike Frysinger]

On Tuesday 29 November 2011 00:38:40 Sridhar Addagada wrote:
> Here is a scenario, i have a working version of the u-boot on my board, and
> am trying my changes.  Am not sure it is going to freeze the board, so
> would like the present version to load the new version for testing before
> it can be burned to flash.  Is it possible to do this or is it already
> done?

i think it depends on the architecture.  most cannot do this.  what 
arch/cpu/SoC/board exactly are you using ?

please fix your e-mail client to wrap long lines
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/98ccea81/attachment.pgp>

[U-Boot] uboot to load uboot

[Wolfgang Denk]

Dear Sridhar Addagada,

In message <1322545120.45725.YahooMailNeo@web120206.mail.ne1.yahoo.com> you wrote:
> 
> Here is a scenario, i have a working version of the u-boot on my
> board, and am trying my changes.? Am not sure it is going to freeze
> the board, so would like the present version to load the new version
> for testing before it can be burned to flash.? Is it possible to do
> this or is it already done?

In the strict sense, this usually cannot be done - one of the most
critical parts (that most oftenly is incorrect and thus bricks your
system) is the low-level initialization, like initializing the memory
controller.  And you usually cannot re-do this while already running
from RAM.

Note that this is covered in the FAQ:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

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
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.

[U-Boot] uboot to load uboot

[Mike Frysinger]

On Tuesday 29 November 2011 02:00:38 Wolfgang Denk wrote:
> Sridhar Addagada you wrote:
> > Here is a scenario, i have a working version of the u-boot on my
> > board, and am trying my changes.  Am not sure it is going to freeze
> > the board, so would like the present version to load the new version
> > for testing before it can be burned to flash.  Is it possible to do
> > this or is it already done?
> 
> In the strict sense, this usually cannot be done - one of the most
> critical parts (that most oftenly is incorrect and thus bricks your
> system) is the low-level initialization, like initializing the memory
> controller.  And you usually cannot re-do this while already running
> from RAM.
> 
> Note that this is covered in the FAQ:
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte
> dInRAM

i like this one:
	Answer: Well, yes. Of course this is possible. This is software, so 
*everything* is possible.

not to keep harping, but the Blackfin arch does support this.  and does so 
stable-ly/cleanly imo.  the cpu offers a few advantages though that most cores 
don't (afaik) which makes it possible: dedicated on-chip L1 SRAM that can be 
directly accessed (which is not cache).  and since the majority of the code we 
have to have anyways for normal booting, the additional "i'm being booted from 
external RAM" logic adds like ~6 insns of overhead.  so when we detect we're 
in RAM, we copy the initcode to on-chip memory, put external memory into self 
refresh, reprogram everything, take external memory out of self refresh, and 
then resume execution from RAM.

only caveat i know of is that you can't change some addressing modes (like # 
of cols used to program the SDRAM chips).  otherwise, this changes how bytes 
are laid out in RAM, so you end up having stride-ed data.  what was:
	0xab 0xcd 0xef 0x00 ...
is now something like:
	0xab <garbage> 0xcd <garbage> 0xef <garbage> 0x00 <garbage>
(the specifics here are probably wrong, but you get the general idea)

in this case, we aren't about to kick off a DMA to re-pack the data, so that is 
unsupported.  but we find that's significantly less of an issue compared to what 
people actual want: to play with memory/clock timings.

</braindump>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/86071a18/attachment.pgp>

[U-Boot] uboot to load uboot

[Sridhar Addagada]

The board is based on MPC8377ERDB

S



________________________________
 From: Mike Frysinger <vapier@gentoo.org>
To: u-boot at lists.denx.de; Sridhar Addagada <sridhar_a@yahoo.com> 
Sent: Tuesday, November 29, 2011 11:20 AM
Subject: Re: [U-Boot] uboot to load uboot
 
On Tuesday 29 November 2011 00:38:40 Sridhar Addagada wrote:
> Here is a scenario, i have a working version of the u-boot on my board, and
> am trying my changes.? Am not sure it is going to freeze the board, so
> would like the present version to load the new version for testing before
> it can be burned to flash.? Is it possible to do this or is it already
> done?

i think it depends on the architecture.? most cannot do this.? what 
arch/cpu/SoC/board exactly are you using ?

please fix your e-mail client to wrap long lines
-mike

[U-Boot] Boot Count Support for MPC8377E

[Sridhar Addagada]

It's been almost a month and have not heard any suggestions from anyone..

Can Freescale folks on the list suggest some reg's or memory location where boot count value can be saved across reboots.

Thanks
S



________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Friday, November 25, 2011 5:24 PM
Subject: CONFIG_BOOTCOUNT_LIMIT
 

I' need to enable CONFIG_BOOTCOUNT_LIMIT, which is based one MPC8377ERDB,? and am looking for recommended address for CONFIG_BOOTCOUNT_ADDR, any suggestions.

Thanks
S

[U-Boot] Boot Count Support for MPC8377E

[Sridhar Addagada]

Freescale folks! no suggestions:(


________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Tuesday, December 20, 2011 8:59 AM
Subject: Boot Count Support for MPC8377E
 

It's been almost a month and have not heard any suggestions from anyone..

Can Freescale folks on the list suggest some reg's or memory location where boot count value can be saved across reboots.

Thanks
S



________________________________
 From: Sridhar Addagada <sridhar_a@yahoo.com>
To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
Sent: Friday, November 25, 2011 5:24 PM
Subject: CONFIG_BOOTCOUNT_LIMIT
 

I' need to enable CONFIG_BOOTCOUNT_LIMIT, which is based one MPC8377ERDB,? and am looking for recommended address for CONFIG_BOOTCOUNT_ADDR, any suggestions.

Thanks
S

[U-Boot] Boot Count Support for MPC8377E

[Wolfgang Denk]

Dear Sridhar Addagada,

In message <1324466163.95750.YahooMailNeo@web120204.mail.ne1.yahoo.com> you wrote:
> 
> Freescale folks! no suggestions:(

Please try and contact your local Freescale FAE.

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
Every program has at least one bug and can be shortened by  at  least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.

[U-Boot] Boot Count Support for MPC8377E

[Scott Wood]

On 12/21/2011 05:16 AM, Sridhar Addagada wrote:
> Freescale folks! no suggestions:(
> 
> 
> ________________________________
>  From: Sridhar Addagada <sridhar_a@yahoo.com>
> To: "u-boot at lists.denx.de" <u-boot@lists.denx.de> 
> Sent: Tuesday, December 20, 2011 8:59 AM
> Subject: Boot Count Support for MPC8377E
>  
> 
> It's been almost a month and have not heard any suggestions from anyone..
> 
> Can Freescale folks on the list suggest some reg's or memory location where boot count value can be saved across reboots.

It's quite likely that no such thing exists (other than
flash/EEPROM/etc.), that you can rely on.  If it does exist, it's most
likely an accident that few if any people know about (especially on a
mailing list populated by people who do software, not hardware).  I
forwarded your mail to an internal Freescale list a couple days ago
(also software -- the hardware people don't have mailing lists that I
know of), and got no responses.

Note that this time of year a lot of people are out on vacation, so all
types of inquiries are less likely to be answered promptly, especially
in a forum such as this which is not an official support channel.

You could try e-mailing support at freescale.com.

-Scott