[U-Boot] Dual boot Images in Flash

[U-Boot] Dual boot Images in Flash

[pshambhu]

Hi,

      I am a new-bee for the u-boot environment, and i am trying to
implement/customize the u-boot code for Dual boot loading from the flash.
U-boot1 will be the primary Image and U-boot2 will be the Fallback image /
backup image. For any situation if my primary image gets corrupted while
updating the firmware, then in that case Fallback image should boot from the
flash, without any problem.

As per previous posting i got to know that, there will be only one reset
entry point, can't i have the another entry point in it.
  -  Why i can't have multiple entry points ? and what will be effect if i
introduced ? 
  -  Where the reset entry points are defined in the u-boot code ?
  -  and, which are the files i need to consider for customization ?

Thanks & Regards
Pradeep S





--
View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Dual boot Images in Flash

[Wolfgang Denk]

Dear pshambhu,

In message <1380547665536-164381.post@n7.nabble.com> you wrote:
> 
> As per previous posting i got to know that, there will be only one reset
> entry point, can't i have the another entry point in it.

You can talk to your chip vendor to provide you with some kind of
logic to detect failed boot attempts and provide an alternative reset
vecotr then.  Guess your chances to gett that are extremely small,
though.

You can, of course, throw hardware at it, and for example provide
duplicate storage . memory devices for booting from, so you only have
to swap chip select resp. address lines to select the alternative boot
device.

>   -  Why i can't have multiple entry points ? and what will be effect if i
> introduced ? 

You can't, because your processor only has one.

>   -  Where the reset entry points are defined in the u-boot code ?

They are not defined in U-Boot, they are defined in the processor
silicon or ROM code.

Disclaimer: of course things get even more complicated when you keep
in mind that there is a multiverse of different hardware solutions,
some of them with special, and others with truely exotic features.

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
A bore is someone who persists in holding his own views after we have
enlightened him with ours.

[U-Boot] Dual boot Images in Flash

[Gupta, Pekon]

> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> Dear pshambhu,
> 
> In message <1380547665536-164381.post@n7.nabble.com> you wrote:
> >
> > As per previous posting i got to know that, there will be only one reset
> > entry point, can't i have the another entry point in it.
> 
> You can talk to your chip vendor to provide you with some kind of
> logic to detect failed boot attempts and provide an alternative reset
> vecotr then.  Guess your chances to gett that are extremely small,
> though.
> 
> You can, of course, throw hardware at it, and for example provide
> duplicate storage . memory devices for booting from, so you only have
> to swap chip select resp. address lines to select the alternative boot
> device.
> 
> >   -  Why i can't have multiple entry points ? and what will be effect if i
> > introduced ?
> 
> You can't, because your processor only has one.
> 
> >   -  Where the reset entry points are defined in the u-boot code ?
> 
> They are not defined in U-Boot, they are defined in the processor
> silicon or ROM code.
> 
> Disclaimer: of course things get even more complicated when you keep
> in mind that there is a multiverse of different hardware solutions,
> some of them with special, and others with truely exotic features.
> 
you can tweak your hardware to split it, and many micro-controllers
do it (especially for safety critical applications). Example:
Suppose 'default' entry-point (or reset entry-point) = 0x0000_0000,
Now OR your MSB bit with the fault-signal or boot-error-flag.
reset-addr[31] = reset-addr_internal[31] | boot_error_flag;
So in case when you primary boot fails, and boot_error_flags is set,
next time when you boot, the address transforms into 0x1000_0000

This can also be done at board-level, where you can always re-route
your default chip-select to some different memory by ORing it with
boot_error_flag. But yes, you need a way to determine that your
first boot failed, which is usually done by having a on-board watchdog,
which timeout if system doesn't boot  within given time.


with regards, pekon

[U-Boot] Dual boot Images in Flash

[Wolfgang Denk]

Dear "Gupta, Pekon",

In message <20980858CB6D3A4BAE95CA194937D5E73EA186A6@DBDE04.ent.ti.com> you wrote:
>
> you can tweak your hardware to split it, and many micro-controllers
> do it (especially for safety critical applications). Example:
> Suppose 'default' entry-point (or reset entry-point) = 0x0000_0000,
> Now OR your MSB bit with the fault-signal or boot-error-flag.

Define "fault-signal" and "boot-error-flag".  Thise may exist on your
chip, but they don't on the overwhelming majority of systems.

> reset-addr[31] = reset-addr_internal[31] | boot_error_flag;
> So in case when you primary boot fails, and boot_error_flags is set,
> next time when you boot, the address transforms into 0x1000_0000

This will only work on very specific hardware.


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
In Nature there are neither rewards nor punishments, there are conse-
quences.                                            -- R.G. Ingersoll

[U-Boot] Dual boot Images in Flash

[Gupta, Pekon]

Hi,

> From: Wolfgang Denk [mailto:wd at denx.de]
> Dear "Gupta, Pekon",
> 
> In message
> <20980858CB6D3A4BAE95CA194937D5E73EA186A6@DBDE04.ent.ti.com>
> >
> > you can tweak your hardware to split it, and many micro-controllers
> > do it (especially for safety critical applications). Example:
> > Suppose 'default' entry-point (or reset entry-point) = 0x0000_0000,
> > Now OR your MSB bit with the fault-signal or boot-error-flag.
> 
> Define "fault-signal" and "boot-error-flag".  Thise may exist on your
> chip, but they don't on the overwhelming majority of systems.
> 
No, these do not exist on my chip either :-).
But you can have such functionality on-board using basic components
like watchdog timers. Like some of Automobile safety systems have
a separate on-board watchdog timer (apart from on-chip ones).
And it is periodically patted via GPIO pins, by the software running on
the system. But suppose a boot failed then this watchdog timer would
expire and that timeout signal can be latched as boot_error_flag.

Case-1: This boot_error_flag can be used for re-routing chip-selects
to other devices like (NAND), etc. Good part is such as this logic sits on
board, it is independent of SoC. Bad part is it adds to your BOM cost.

Case-2:  You can re-route boot_error_flag back to your SoC connecting
it to NMI or external reset (most SoC would atleast have reset). And
then a corrective action can be taken in your reset-entry handler, or
exception handler.
Jumps to exception-handlers and reset-handler will mostly execute
because these branching are hard-coded in processor hardware.

Though I fully agree with you it's more difficult to do these things in
actual than just describing the concept here.


with regards, pekon

[U-Boot] Dual boot Images in Flash

[pshambhu]

Thanks Wolfgang Denk and Pekon for the lots of info.

Thanks & Regards
Pradeep S



--
View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164434.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Dual boot Images in Flash

[pshambhu]

Hi Wolfgang,

                 With respect to previous mail, i have one small doubt. I
have two three u-boots,
                                                             
                                                                  
u-boot_stub
                                                                        _
_|_ _ _ _ _ _ _
                                                                       |                     
|
                                                                   u-boot1               
u-boot2

Can i have a small uboot_stub in the reset entry table, which will boot
initially, and while booting it should select the default booting location
(u-boot1).But if the default booting location fails to boot up then
u-boot_stub should select bootloader u-boot2.

u-boot_stub will do CRC checksum on the u-boot1, if CRC checksum fails on
that, then u-boot2 will be considered for bootup.


Since its the software, i think it can be done and If it is possible, can
you please tell me which are the files need to be taken care for the file
changes.

please guide me if i am wrong

Thanks & Regards
Pradeep S



--
View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164443.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Dual boot Images in Flash

[Wolfgang Denk]

Dear pshambhu,

In message <1380633558849-164443.post@n7.nabble.com> you wrote:
>
> Can i have a small uboot_stub in the reset entry table, which will boot
> initially, and while booting it should select the default booting location
> (u-boot1).But if the default booting location fails to boot up then
> u-boot_stub should select bootloader u-boot2.
> 
> u-boot_stub will do CRC checksum on the u-boot1, if CRC checksum fails on
> that, then u-boot2 will be considered for bootup.

That would be pretty straight-forward (and I'm even tempted to write:
trivial) to implement.  Just add the CRC checking and selecting part
to SPL...

> Since its the software, i think it can be done and If it is possible, can
> you please tell me which are the files need to be taken care for the file
> changes.

On the other hand, it does not really solve your problem - how do you
fix problems or perform reliable updates of this "small uboot_stub"?

I recommend to face the real situation: yes, you can implement all
levels of complicated multi-stage boot procedures that promise to
provide all kinds of features and reliability - but in the end you
still have that small, central critical piece of code, and guess where
the nasty bug will be found?   Without hardware support (switching
boot devices etc.) you cannot implement a 100% reliable solution.  And
if it's less than 100%, then what's the difference between 99.999% and
99% ?  If things go wrong, your're stuck.  And I bet Murphy is looking
over your right shoulder right when you can't have it.

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
Imagination was given to man to compensate him for what he is not;  a
sence of humor to console him for what he is.          - Fancis Bacon

[U-Boot] Dual boot Images in Flash

[pshambhu]

Hi Wolfgang Denk,

                            Thanks for the feedback, for the customization
of u-boot_stub, the main file start.S needs to be changed i guess, the
u-boot_stub has to perform only CRC check. after performing it should goto
u_boot1/u_boot2 address and then it should start booting. 

How can i customize the u-boot_stub or generate the start.S file which
perform only CRC calculation and switching address of u_boot1/u_boot2 ,
which performs booting.


Thanks & Regards
Pradeep S



--
View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164588.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Dual boot Images in Flash

[Wolfgang Denk]

Dear pshambhu,

In message <1380783611628-164588.post@n7.nabble.com> you wrote:
> 
>                             Thanks for the feedback, for the customization
> of u-boot_stub, the main file start.S needs to be changed i guess, the
> u-boot_stub has to perform only CRC check. after performing it should goto
> u_boot1/u_boot2 address and then it should start booting. 

I think you still fail to see the real issues with any such approach.

What makes you think the fact that the CRC checksum is correct could
actually mean that the image is really working?

It only means that there is a pretty good chance that it has not been
corrupted - it does NOT give you any additional reason to trust it
would be "good".

> How can i customize the u-boot_stub or generate the start.S file which
> perform only CRC calculation and switching address of u_boot1/u_boot2 ,
> which performs booting.

Well, just implement what you think needs to be done...

Note that I don't think that you could get what you want this way.

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
A list is only as strong as its weakest link.            -- Don Knuth