[U-Boot] uboot redundancy.

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi All,

I am planning to implement uboot redundancy.
This means having the following idea which we thought.

Golden-Uboot which is flashed in the NOR-FLASH. This is not field
upgradable.
This golden uboot is going to have logic to pick the other uboot based on
certain flags or env vriables

As i mentioned i wanted the uboot to be redundant.
So i will have 2 copies of uboot now.
Uboot1
Uboot2

Golden uboot will pick either of one uboots mentioned above. If the uboot1
which is picked fails to boot, then we will have uboot2 as back up to boot.
vice versa.

Golden uboot recides in the address fffa0000 (start.s).
There is a relocation code which copies the code from flash to ram. if the
uboot which i have picked addressess will change , hence how can i do the
relocation?

Any pointers will help me if any one already did this kind of approach
making uboot redundant.

-Sagar

[U-Boot] uboot redundancy.

[Graeme Russ]

On 10/07/10 00:03, Sagar Heroorkar wrote:
> Hi All,
> 
> I am planning to implement uboot redundancy.
> This means having the following idea which we thought.
> 
> Golden-Uboot which is flashed in the NOR-FLASH. This is not field
> upgradable.
> This golden uboot is going to have logic to pick the other uboot based on
> certain flags or env vriables
> 
> As i mentioned i wanted the uboot to be redundant.
> So i will have 2 copies of uboot now.
> Uboot1
> Uboot2

I have a similar plan for x86 although the rationale was to enable rapid
load-reset-test(-write to boot ROM on pass).

The x86 port has the ability to load a new version of U-Boot into an
arbitrary location in RAM and 'boot-strap' directly into it. I was planning
on doing something similar to what you propose - All that is needed is a
little bit of code in the low-level boot-strap to choose whether to
continue loading the main image, or a secondary image. Note that at this
point, there is no environment and no CFI driver so any decision would need
to be based on NVRAM data.

> 
> Golden uboot will pick either of one uboots mentioned above. If the uboot1
> which is picked fails to boot, then we will have uboot2 as back up to boot.
> vice versa.
> 
> Golden uboot recides in the address fffa0000 (start.s).
> There is a relocation code which copies the code from flash to ram. if the
> uboot which i have picked addressess will change , hence how can i do the
> relocation?

x86 port has 'proper' relocation. It does not matter where the target image
resides, it will reload itself into the highest available memory location
and run from there.

> 
> Any pointers will help me if any one already did this kind of approach
> making uboot redundant.
> 

There were some posts a little while ago (search for posts by Joakim
Tjernlund - he was working on a 100% position independent U-Boot)

My work on U-Boot has been very slow of late, but I would be really
interested in working through this idea in a platform independent way.

--
Graeme

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi Joakim,

Graeme referred me to contact you for this.

I am working on U-boot making it PIC for ppc 405ex based boards.
I see in the following link
http://www.mail-archive.com/u-boot at lists.denx.de/msg26918.html
that you have implemented similar thing on 83xx board.

I have downloaded latest u-boot from ftp server of denx. I dont see the
functions what you have modified like LINKF_OFF() etc.
 I would like to know where is the source code for that. Also is there any
document other than the mail thread that explains what you have chagned.

Thanks in advance.

-Sagar


On Sat, Jul 10, 2010 at 7:11 AM, Graeme Russ <graeme.russ@gmail.com> wrote:

> On 10/07/10 00:03, Sagar Heroorkar wrote:
> > Hi All,
> >
> > I am planning to implement uboot redundancy.
> > This means having the following idea which we thought.
> >
> > Golden-Uboot which is flashed in the NOR-FLASH. This is not field
> > upgradable.
> > This golden uboot is going to have logic to pick the other uboot based on
> > certain flags or env vriables
> >
> > As i mentioned i wanted the uboot to be redundant.
> > So i will have 2 copies of uboot now.
> > Uboot1
> > Uboot2
>
> I have a similar plan for x86 although the rationale was to enable rapid
> load-reset-test(-write to boot ROM on pass).
>
> The x86 port has the ability to load a new version of U-Boot into an
> arbitrary location in RAM and 'boot-strap' directly into it. I was planning
> on doing something similar to what you propose - All that is needed is a
> little bit of code in the low-level boot-strap to choose whether to
> continue loading the main image, or a secondary image. Note that at this
> point, there is no environment and no CFI driver so any decision would need
> to be based on NVRAM data.
>
> >
> > Golden uboot will pick either of one uboots mentioned above. If the
> uboot1
> > which is picked fails to boot, then we will have uboot2 as back up to
> boot.
> > vice versa.
> >
> > Golden uboot recides in the address fffa0000 (start.s).
> > There is a relocation code which copies the code from flash to ram. if
> the
> > uboot which i have picked addressess will change , hence how can i do the
> > relocation?
>
> x86 port has 'proper' relocation. It does not matter where the target image
> resides, it will reload itself into the highest available memory location
> and run from there.
>
> >
> > Any pointers will help me if any one already did this kind of approach
> > making uboot redundant.
> >
>
> There were some posts a little while ago (search for posts by Joakim
> Tjernlund - he was working on a 100% position independent U-Boot)
>
> My work on U-Boot has been very slow of late, but I would be really
> interested in working through this idea in a platform independent way.
>
> --
> Graeme
>

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

resending this.

Please do reply

-Sagar

On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar
<sagar.heroorkar@gmail.com>wrote:

> Hi Joakim,
>
> Graeme referred me to contact you for this.
>
> I am working on U-boot making it PIC for ppc 405ex based boards.
> I see in the following link
> http://www.mail-archive.com/u-boot at lists.denx.de/msg26918.html
> that you have implemented similar thing on 83xx board.
>
> I have downloaded latest u-boot from ftp server of denx. I dont see the
> functions what you have modified like LINKF_OFF() etc.
>  I would like to know where is the source code for that. Also is there any
> document other than the mail thread that explains what you have chagned.
>
> Thanks in advance.
>
> -Sagar
>
>
> On Sat, Jul 10, 2010 at 7:11 AM, Graeme Russ <graeme.russ@gmail.com>wrote:
>
>> On 10/07/10 00:03, Sagar Heroorkar wrote:
>> > Hi All,
>> >
>> > I am planning to implement uboot redundancy.
>> > This means having the following idea which we thought.
>> >
>> > Golden-Uboot which is flashed in the NOR-FLASH. This is not field
>> > upgradable.
>> > This golden uboot is going to have logic to pick the other uboot based
>> on
>> > certain flags or env vriables
>> >
>> > As i mentioned i wanted the uboot to be redundant.
>> > So i will have 2 copies of uboot now.
>> > Uboot1
>> > Uboot2
>>
>> I have a similar plan for x86 although the rationale was to enable rapid
>> load-reset-test(-write to boot ROM on pass).
>>
>> The x86 port has the ability to load a new version of U-Boot into an
>> arbitrary location in RAM and 'boot-strap' directly into it. I was
>> planning
>> on doing something similar to what you propose - All that is needed is a
>> little bit of code in the low-level boot-strap to choose whether to
>> continue loading the main image, or a secondary image. Note that at this
>> point, there is no environment and no CFI driver so any decision would
>> need
>> to be based on NVRAM data.
>>
>> >
>> > Golden uboot will pick either of one uboots mentioned above. If the
>> uboot1
>> > which is picked fails to boot, then we will have uboot2 as back up to
>> boot.
>> > vice versa.
>> >
>> > Golden uboot recides in the address fffa0000 (start.s).
>> > There is a relocation code which copies the code from flash to ram. if
>> the
>> > uboot which i have picked addressess will change , hence how can i do
>> the
>> > relocation?
>>
>> x86 port has 'proper' relocation. It does not matter where the target
>> image
>> resides, it will reload itself into the highest available memory location
>> and run from there.
>>
>> >
>> > Any pointers will help me if any one already did this kind of approach
>> > making uboot redundant.
>> >
>>
>> There were some posts a little while ago (search for posts by Joakim
>> Tjernlund - he was working on a 100% position independent U-Boot)
>>
>> My work on U-Boot has been very slow of late, but I would be really
>> interested in working through this idea in a platform independent way.
>>
>> --
>> Graeme
>>
>
>

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi Wlfgang,


> resending this.
>
> Please do reply
>
> -Sagar
>
>   On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <
> sagar.heroorkar at gmail.com> wrote:
>
>> Hi Joakim,
>>
>> Graeme referred me to contact you for this.
>>
>> I am working on U-boot making it PIC for ppc 405ex based boards.
>> I see in the following link
>> http://www.mail-archive.com/u-boot at lists.denx.de/msg26918.html
>> that you have implemented similar thing on 83xx board.
>>
>> I have downloaded latest u-boot from ftp server of denx. I dont see the
>> functions what you have modified like LINKF_OFF() etc.
>>  I would like to know where is the source code for that. Also is there
>> any document other than the mail thread that explains what you have chagned.
>>
>> Thanks in advance.
>>
>> -Sagar
>>
>>
>> On Sat, Jul 10, 2010 at 7:11 AM, Graeme Russ <graeme.russ@gmail.com>wrote:
>>
>>> On 10/07/10 00:03, Sagar Heroorkar wrote:
>>> > Hi All,
>>> >
>>> > I am planning to implement uboot redundancy.
>>> > This means having the following idea which we thought.
>>> >
>>> > Golden-Uboot which is flashed in the NOR-FLASH. This is not field
>>> > upgradable.
>>> > This golden uboot is going to have logic to pick the other uboot based
>>> on
>>> > certain flags or env vriables
>>> >
>>> > As i mentioned i wanted the uboot to be redundant.
>>> > So i will have 2 copies of uboot now.
>>> > Uboot1
>>> > Uboot2
>>>
>>> I have a similar plan for x86 although the rationale was to enable rapid
>>> load-reset-test(-write to boot ROM on pass).
>>>
>>> The x86 port has the ability to load a new version of U-Boot into an
>>> arbitrary location in RAM and 'boot-strap' directly into it. I was
>>> planning
>>> on doing something similar to what you propose - All that is needed is a
>>> little bit of code in the low-level boot-strap to choose whether to
>>> continue loading the main image, or a secondary image. Note that at this
>>> point, there is no environment and no CFI driver so any decision would
>>> need
>>> to be based on NVRAM data.
>>>
>>> >
>>> > Golden uboot will pick either of one uboots mentioned above. If the
>>> uboot1
>>> > which is picked fails to boot, then we will have uboot2 as back up to
>>> boot.
>>> > vice versa.
>>> >
>>> > Golden uboot recides in the address fffa0000 (start.s).
>>> > There is a relocation code which copies the code from flash to ram. if
>>> the
>>> > uboot which i have picked addressess will change , hence how can i do
>>> the
>>> > relocation?
>>>
>>> x86 port has 'proper' relocation. It does not matter where the target
>>> image
>>> resides, it will reload itself into the highest available memory location
>>> and run from there.
>>>
>>> >
>>> > Any pointers will help me if any one already did this kind of approach
>>> > making uboot redundant.
>>> >
>>>
>>> There were some posts a little while ago (search for posts by Joakim
>>> Tjernlund - he was working on a 100% position independent U-Boot)
>>>
>>> My work on U-Boot has been very slow of late, but I would be really
>>> interested in working through this idea in a platform independent way.
>>>
>>> --
>>> Graeme
>>>
>>
>>
>

[U-Boot] uboot redundancy.

[Joakim Tjernlund]

Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/19 15:26:20:
>
> Hi Wlfgang,
>
> resending this.
>
> Please do reply
>
> -Sagar

> On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote:
> Hi Joakim,
>
> Graeme?referred me to contact you for this.
>
> I am working on U-boot making it PIC for ppc 405ex based boards.
> I see in the following link http://www.mail-archive.com/u-boot at lists.denx.de/
> msg26918.html
> that you have implemented similar thing on 83xx board.
>
> I have downloaded latest u-boot from ftp server of denx. I dont see the
> functions what you have modified like LINKF_OFF() etc.
> I?would like to know where is the source code for that. Also is there any
> document other than the mail thread that explains what you have chagned.

Hi Sagar

The source isn't in u-boot. It is only available as the patches I sent at the time.
I don't have the patches handy as I am on vacation for 2 more weeks.

>
> Thanks in advance.
>
> -Sagar
>

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi All,

Before i start using your ( Joakim )approach. I would like to get some tips
from Wolfgang or someone who can assist me here.

I am working on nor flash which is 128 mb flash for the PPC4XX.

My  goal is to make uboot redundant. having other copy of uboot if one fails
to boot.
Architechure follows like this.

Totally there will be 3 uboots. *Golden uboot *is the one which has
basic logic to pick which uboot from *uboot 1 or uboot 2 (different copy)*.
uboot 1 and uboot 2 is flashed into some location of 16mb nor flash.

Steps follows like this.

1)G-boot picks up uboot1/uboot2 based on environment variable. Basically we
jumps to that uboot and start booting it from there.

When i analysed the approach what Joakim implemented in
http://www.mail-archive.com/u-boot at lists.denx.de/msg26918.html.
He uses something like link_off() for each of the global data.

* There will be too many link_offs() i have to use in uboot to make sure
each of the global data.
* As i will have 2 uboots which resides into seperate partitions. This
requies to build 2 uboots with different relotate_code logic/something .

I have read comments about this approach in the link what i pasted above.

I would really appriciate if anyone replies (especially Wolfgang ) about
whether to go head with this approach before i spent much time on this.
Also if anyone has already done similar implentation for any of the boards
let me know.

-Sagar
On Mon, Jul 19, 2010 at 4:36 PM, Joakim Tjernlund <
joakim.tjernlund@transmode.se> wrote:

>
>
> Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/19 15:26:20:
> >
> > Hi Wlfgang,
> >
> > resending this.
> >
> > Please do reply
> >
> > -Sagar
>
> > On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <
> sagar.heroorkar at gmail.com> wrote:
> > Hi Joakim,
> >
> > Graeme referred me to contact you for this.
> >
> > I am working on U-boot making it PIC for ppc 405ex based boards.
> > I see in the following link
> http://www.mail-archive.com/u-boot at lists.denx.de/
> > msg26918.html
> > that you have implemented similar thing on 83xx board.
> >
> > I have downloaded latest u-boot from ftp server of denx. I dont see the
> > functions what you have modified like LINKF_OFF() etc.
> > I would like to know where is the source code for that. Also is there any
> > document other than the mail thread that explains what you have chagned.
>
> Hi Sagar
>
> The source isn't in u-boot. It is only available as the patches I sent at
> the time.
> I don't have the patches handy as I am on vacation for 2 more weeks.
>
> >
> > Thanks in advance.
> >
> > -Sagar
> >
>
>

[U-Boot] uboot redundancy.

[Joakim Tjernlund]

Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/21 17:21:31:
>
> Hi All,
>
> Before i start using your (?Joakim )approach. I would like to get some tips
> from Wolfgang or someone who can assist me here.
>
> I am working on nor flash which is 128 mb flash for the PPC4XX.
>
> My? goal is to make uboot redundant. having other copy of uboot if one fails to boot.
> Architechure follows like this.
>
> Totally there will be 3 uboots. Golden uboot is the one which has basic?logic
> to pick which uboot from uboot 1 or uboot 2 (different copy).
> uboot 1 and uboot 2 is flashed into some location of 16mb nor flash.

Seems sane.

>
> Steps follows like this.
>
> 1)G-boot picks up uboot1/uboot2 based on environment variable. Basically we
> jumps to that uboot and start booting it from there.

Doesn't need to be an env var. I image one could mark each image (uboot 1 or
uboot 2) with a flag instead. That way you don't need to parse the env.

>
> When i analysed the approach what Joakim implemented in http://www.mail-
> archive.com/u-boot at lists.denx.de/msg26918.html.
> He uses something like link_off() for each of the global data.
>
> * There will be too many link_offs() i have to use in uboot to make sure each
> of the global data.

There are a few link_offs() but not too many IMHO. Remember that my patches
were complete for my board.

> * As i will have 2 uboots which resides into seperate partitions. This requies
> to build 2 uboots with different relotate_code logic/something .

Yes, this is the other way, you need to build two images linked to different
addresses and select the right one at install.

>
> I have read comments about this approach in the link what i pasted above.
>
> I would really appriciate if anyone replies (especially Wolfgang ) about
> whether to go head with this approach before i spent much time on this.
> Also if anyone has already done similar implentation for any of the boards let me know.
>
> -Sagar
> On Mon, Jul 19, 2010 at 4:36 PM, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
>
> Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/19 15:26:20:
> >
> > Hi Wlfgang,
> >
> > resending this.
> >
> > Please do reply
> >
> > -Sagar
>
> > On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote:
> > Hi Joakim,
> >
> > Graeme?referred me to contact you for this.
> >
> > I am working on U-boot making it PIC for ppc 405ex based boards.
> > I see in the following link http://www.mail-archive.com/u-boot at lists.denx.de/
> > msg26918.html
> > that you have implemented similar thing on 83xx board.
> >
> > I have downloaded latest u-boot from ftp server of denx. I dont see the
> > functions what you have modified like LINKF_OFF() etc.
> > I?would like to know where is the source code for that. Also is there any
> > document other than the mail thread that explains what you have chagned.

> Hi Sagar
>
> The source isn't in u-boot. It is only available as the patches I sent at the time.
> I don't have the patches handy as I am on vacation for 2 more weeks.
>
> >
> > Thanks in advance.
> >
> > -Sagar
> >

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi,

Is there a other way that without building the 2 different linking address
for the uboot to make the 2 uboots PIC in the same nor flash.

-Sagar

On Wed, Jul 21, 2010 at 12:27 PM, Joakim Tjernlund <
joakim.tjernlund@transmode.se> wrote:

> Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/21 17:21:31:
> >
> > Hi All,
> >
> > Before i start using your ( Joakim )approach. I would like to get some
> tips
> > from Wolfgang or someone who can assist me here.
> >
> > I am working on nor flash which is 128 mb flash for the PPC4XX.
> >
> > My  goal is to make uboot redundant. having other copy of uboot if one
> fails to boot.
> > Architechure follows like this.
> >
> > Totally there will be 3 uboots. Golden uboot is the one which has
> basic logic
> > to pick which uboot from uboot 1 or uboot 2 (different copy).
> > uboot 1 and uboot 2 is flashed into some location of 16mb nor flash.
>
> Seems sane.
>
> >
> > Steps follows like this.
> >
> > 1)G-boot picks up uboot1/uboot2 based on environment variable. Basically
> we
> > jumps to that uboot and start booting it from there.
>
> Doesn't need to be an env var. I image one could mark each image (uboot 1
> or
> uboot 2) with a flag instead. That way you don't need to parse the env.
>
> >
> > When i analysed the approach what Joakim implemented in http://www.mail-
> > archive.com/u-boot at lists.denx.de/msg26918.html.
> > He uses something like link_off() for each of the global data.
> >
> > * There will be too many link_offs() i have to use in uboot to make sure
> each
> > of the global data.
>
> There are a few link_offs() but not too many IMHO. Remember that my patches
> were complete for my board.
>
> > * As i will have 2 uboots which resides into seperate partitions. This
> requies
> > to build 2 uboots with different relotate_code logic/something .
>
> Yes, this is the other way, you need to build two images linked to
> different
> addresses and select the right one at install.
>
> >
> > I have read comments about this approach in the link what i pasted above.
> >
> > I would really appriciate if anyone replies (especially Wolfgang ) about
> > whether to go head with this approach before i spent much time on this.
> > Also if anyone has already done similar implentation for any of the
> boards let me know.
> >
> > -Sagar
> > On Mon, Jul 19, 2010 at 4:36 PM, Joakim Tjernlund <
> joakim.tjernlund at transmode.se> wrote:
> >
> >
> > Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/19
> 15:26:20:
> > >
> > > Hi Wlfgang,
> > >
> > > resending this.
> > >
> > > Please do reply
> > >
> > > -Sagar
> >
> > > On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <
> sagar.heroorkar at gmail.com> wrote:
> > > Hi Joakim,
> > >
> > > Graeme referred me to contact you for this.
> > >
> > > I am working on U-boot making it PIC for ppc 405ex based boards.
> > > I see in the following link
> http://www.mail-archive.com/u-boot at lists.denx.de/
> > > msg26918.html
> > > that you have implemented similar thing on 83xx board.
> > >
> > > I have downloaded latest u-boot from ftp server of denx. I dont see the
> > > functions what you have modified like LINKF_OFF() etc.
> > > I would like to know where is the source code for that. Also is there
> any
> > > document other than the mail thread that explains what you have
> chagned.
>
> > Hi Sagar
> >
> > The source isn't in u-boot. It is only available as the patches I sent at
> the time.
> > I don't have the patches handy as I am on vacation for 2 more weeks.
> >
> > >
> > > Thanks in advance.
> > >
> > > -Sagar
> > >
>
>

[U-Boot] uboot redundancy.

[Joakim Tjernlund]

Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/21 19:09:50:
>
> Hi,
>
> Is there a other way that without building the 2 different linking address for
> the uboot to make the 2 uboots PIC in the same nor flash.

The only other way is to modify gcc so you don't need so many link_offs() calls.

 Jocke

> On Wed, Jul 21, 2010 at 12:27 PM, Joakim Tjernlund <joakim.tjernlund@transmode.se
> > wrote:
> Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/21 17:21:31:
> >
> > Hi All,
> >
> > Before i start using your (?Joakim )approach. I would like to get some tips
> > from Wolfgang or someone who can assist me here.
> >
> > I am working on nor flash which is 128 mb flash for the PPC4XX.
> >
> > My? goal is to make uboot redundant. having other copy of uboot if one fails to boot.
> > Architechure follows like this.
> >
> > Totally there will be 3 uboots. Golden uboot is the one which has basic?logic
> > to pick which uboot from uboot 1 or uboot 2 (different copy).
> > uboot 1 and uboot 2 is flashed into some location of 16mb nor flash.

> Seems sane.
>
> >
> > Steps follows like this.
> >
> > 1)G-boot picks up uboot1/uboot2 based on environment variable. Basically we
> > jumps to that uboot and start booting it from there.

> Doesn't need to be an env var. I image one could mark each image (uboot 1 or
> uboot 2) with a flag instead. That way you don't need to parse the env.
>
> >
> > When i analysed the approach what Joakim implemented in http://www.mail-
> > archive.com/u-boot at lists.denx.de/msg26918.html.
> > He uses something like link_off() for each of the global data.
> >
> > * There will be too many link_offs() i have to use in uboot to make sure each
> > of the global data.

> There are a few link_offs() but not too many IMHO. Remember that my patches
> were complete for my board.
>
> > * As i will have 2 uboots which resides into seperate partitions. This requies
> > to build 2 uboots with different relotate_code logic/something .

> Yes, this is the other way, you need to build two images linked to different
> addresses and select the right one at install.
>
> >
> > I have read comments about this approach in the link what i pasted above.
> >
> > I would really appriciate if anyone replies (especially Wolfgang ) about
> > whether to go head with this approach before i spent much time on this.
> > Also if anyone has already done similar implentation for any of the boards
> let me know.
> >
> > -Sagar
> > On Mon, Jul 19, 2010 at 4:36 PM, Joakim Tjernlund <joakim.tjernlund@transmode.se
> > wrote:
> >
> >
> > Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote on 2010/07/19 15:26:20:
> > >
> > > Hi Wlfgang,
> > >
> > > resending this.
> > >
> > > Please do reply
> > >
> > > -Sagar
> >
> > > On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <sagar.heroorkar@gmail.com> wrote:
> > > Hi Joakim,
> > >
> > > Graeme?referred me to contact you for this.
> > >
> > > I am working on U-boot making it PIC for ppc 405ex based boards.
> > > I see in the following link http://www.mail-archive.com/u-boot at lists.denx.de/
> > > msg26918.html
> > > that you have implemented similar thing on 83xx board.
> > >
> > > I have downloaded latest u-boot from ftp server of denx. I dont see the
> > > functions what you have modified like LINKF_OFF() etc.
> > > I?would like to know where is the source code for that. Also is there any
> > > document other than the mail thread that explains what you have chagned.
>
> > Hi Sagar
> >
> > The source isn't in u-boot. It is only available as the patches I sent at the time.
> > I don't have the patches handy as I am on vacation for 2 more weeks.
> >
> > >
> > > Thanks in advance.
> > >
> > > -Sagar
> > >

[U-Boot] uboot redundancy.

[Wolfgang Denk]

Dear Sagar Heroorkar,

In message <AANLkTil0NvpGAegE9G05JvepTqKTPKNvARfkG-tED3SF@mail.gmail.com> you wrote:
>
> 1)G-boot picks up uboot1/uboot2 based on environment variable. Basically we
> jumps to that uboot and start booting it from there.

You should not do that. Environment is not reliable enough for such a
thing.

You should use a boot counter in combination with a hardware watchdog.
After N failing attempts to boot image 1 you switch to image 2.

> * As i will have 2 uboots which resides into seperate partitions. This
> requies to build 2 uboots with different relotate_code logic/something .

Actually you will have 3 of these.

I told you before that I consider this approach screwed.

> I would really appriciate if anyone replies (especially Wolfgang ) about
> whether to go head with this approach before i spent much time on this.

I've sent a few replies in the past; I have little or nothing new to
add.


Viele Gr??e,

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
Do not follow where the path may lead....go instead where there is no
path and leave a trail.

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Wolfgang,

Appriciate & Thanks for your reply.

Is there any other way to make the u-boot redundant  other than what i have
sent in the email earliar.

Your reply will help me to decide in what direction i should go.

-Sagar

On Wed, Jul 21, 2010 at 2:25 PM, Wolfgang Denk <wd@denx.de> wrote:

> Dear Sagar Heroorkar,
>
> In message <AANLkTil0NvpGAegE9G05JvepTqKTPKNvARfkG-tED3SF@mail.gmail.com>
> you wrote:
> >
> > 1)G-boot picks up uboot1/uboot2 based on environment variable. Basically
> we
> > jumps to that uboot and start booting it from there.
>
> You should not do that. Environment is not reliable enough for such a
> thing.
>
> You should use a boot counter in combination with a hardware watchdog.
> After N failing attempts to boot image 1 you switch to image 2.
>
> > * As i will have 2 uboots which resides into seperate partitions. This
> > requies to build 2 uboots with different relotate_code logic/something .
>
> Actually you will have 3 of these.
>
> I told you before that I consider this approach screwed.
>
> > I would really appriciate if anyone replies (especially Wolfgang ) about
> > whether to go head with this approach before i spent much time on this.
>
> I've sent a few replies in the past; I have little or nothing new to
> add.
>
>
> Viele Gr??e,
>
> 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
> Do not follow where the path may lead....go instead where there is no
> path and leave a trail.
>

[U-Boot] uboot redundancy.

[Wolfgang Denk]

Dear Sagar Heroorkar,

In message <AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF@mail.gmail.com> you wrote:
>
> Is there any other way to make the u-boot redundant  other than what i have
> sent in the email earliar.

I still fail to understand where your requirements are coming from,
resp. which exact goal you are trying to achieve.

If it's all about reliability, you should consider never updating /
replacing U-Boot at all, and then a single copy is all you need in
most cases.

If you have really paranoid reliability requirements, you cannot do
without adequate support from the hardware design. Tyically such
systems come with two separate, identical banks of NOR flash that are
attached through some switch logic to two different chip select
signals. In addition, they need a hardware watchdog (I mean a real
one, that starts automatically and that cannot be stopped by
software), and logic that allows to detect the a watchdog reset.


Assume in "normal" position the switch connects flash bank 1 as boot
device (say, chip select CS0), and flash bank 2 to another device
(say, chip select 1).

You would then install the same copy of U-Boot into both flash banks 1
and 2.

Upon power-on, the watchdog starts running, and the system will boot
from the image in flash bank 1. If it's working fine, it will trigger
the watchdog, and everything is fine.

In case of errors (image corrupt, flash broken, ...) the watchdog will
time out and cause a watchdog reset, which gets detected by the board
logic. After a predetermined number of such watchdog resets (N=1 is of
course also an option) the board logic will flip the switch, so the
next reset will see flach bank 2 connected to CS0 and thus being the
boot device, i. e. the alternative image will be booted.

This is simple, reliable, and doe snot require any special measures in
the software, which is completly agnostic to such toggeling.

You may even locate several copies of the environment in both flash
banks, so that you have a fully redundant system.

Whether the switch can also be controlled by software or not etc. are
details that allow for fine tuning, but I think you get the idea.

But you need a certain level of hardware support - all attempts of
nested first and second and third stage loaders and toggeling in
software is error prone, because you can be pretty sure that the
first problem that will bite you once the systems have been shipped
to customers all over the world is not in one of the redundant
images, but in the "golden" master copy...


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
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."           - Terry Pratchett, _Witches Abroad_

[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Dear Wolfgang,

Thanks you for the reply.

-Sagar

On Wed, Jul 21, 2010 at 3:37 PM, Wolfgang Denk <wd@denx.de> wrote:

> Dear Sagar Heroorkar,
>
> In message <AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF@mail.gmail.com>
> you wrote:
> >
> > Is there any other way to make the u-boot redundant  other than what i
> have
> > sent in the email earliar.
>
> I still fail to understand where your requirements are coming from,
> resp. which exact goal you are trying to achieve.
>
> If it's all about reliability, you should consider never updating /
> replacing U-Boot at all, and then a single copy is all you need in
> most cases.
>
> If you have really paranoid reliability requirements, you cannot do
> without adequate support from the hardware design. Tyically such
> systems come with two separate, identical banks of NOR flash that are
> attached through some switch logic to two different chip select
> signals. In addition, they need a hardware watchdog (I mean a real
> one, that starts automatically and that cannot be stopped by
> software), and logic that allows to detect the a watchdog reset.
>
>
> Assume in "normal" position the switch connects flash bank 1 as boot
> device (say, chip select CS0), and flash bank 2 to another device
> (say, chip select 1).
>
> You would then install the same copy of U-Boot into both flash banks 1
> and 2.
>
> Upon power-on, the watchdog starts running, and the system will boot
> from the image in flash bank 1. If it's working fine, it will trigger
> the watchdog, and everything is fine.
>
> In case of errors (image corrupt, flash broken, ...) the watchdog will
> time out and cause a watchdog reset, which gets detected by the board
> logic. After a predetermined number of such watchdog resets (N=1 is of
> course also an option) the board logic will flip the switch, so the
> next reset will see flach bank 2 connected to CS0 and thus being the
> boot device, i. e. the alternative image will be booted.
>
> This is simple, reliable, and doe snot require any special measures in
> the software, which is completly agnostic to such toggeling.
>
> You may even locate several copies of the environment in both flash
> banks, so that you have a fully redundant system.
>
> Whether the switch can also be controlled by software or not etc. are
> details that allow for fine tuning, but I think you get the idea.
>
> But you need a certain level of hardware support - all attempts of
> nested first and second and third stage loaders and toggeling in
> software is error prone, because you can be pretty sure that the
> first problem that will bite you once the systems have been shipped
> to customers all over the world is not in one of the redundant
> images, but in the "golden" master copy...
>
>
> 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
> You got to learn three things. What's  real,  what's  not  real,  and
> what's the difference."           - Terry Pratchett, _Witches Abroad_
>