[U-Boot] uboot redundancy.
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
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
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@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
resending this.
Please do reply
-Sagar
On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar sagar.heroorkar@gmail.comwrote:
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@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.comwrote:
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
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@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.comwrote:
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
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@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
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@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@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@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
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@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@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
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@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@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
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@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@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
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
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@denx.de Do not follow where the path may lead....go instead where there is no path and leave a trail.
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
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@denx.de You got to learn three things. What's real, what's not real, and what's the difference." - Terry Pratchett, _Witches Abroad_
participants (4)
-
Graeme Russ -
Joakim Tjernlund -
Sagar Heroorkar -
Wolfgang Denk