All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Firmware upgrade possibilites technikes in uboot.
@ 2010-08-05 13:41 Lasse Skov
  2010-08-05 14:22 ` Bas Mevissen
  0 siblings, 1 reply; 5+ messages in thread
From: Lasse Skov @ 2010-08-05 13:41 UTC (permalink / raw)
  To: u-boot

Hi

Im working on a target where I use the u-boot and think a little about
good techniques for upgrade the BSP on the target and to make it fails saft.

Is ther any helpeful things I can use in uboot for this.?

My plan is to split my flash I 4 levels.

High
           Filesystem
           BSP_2
           BSP_1
           uBoot
Low

And then let uBoot make a checksum on BSP_2 and boot this.
If it's not is possible then boot BSP_1.

Another option is to build in a telnet session or something in the bootloader so ist possible to upgrade remote on only a Ethernet connection.
But it think the best is to keep the bootloader "simple".

/Lasse

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] Firmware upgrade possibilites technikes in uboot.
  2010-08-05 13:41 [U-Boot] Firmware upgrade possibilites technikes in uboot Lasse Skov
@ 2010-08-05 14:22 ` Bas Mevissen
  2010-08-05 15:02   ` Albert ARIBAUD
  0 siblings, 1 reply; 5+ messages in thread
From: Bas Mevissen @ 2010-08-05 14:22 UTC (permalink / raw)
  To: u-boot


On Thu, 5 Aug 2010 15:41:35 +0200, Lasse Skov <lasko@kk-electronic.com>
wrote:
> Hi
> 
> Im working on a target where I use the u-boot and think a little about
> good techniques for upgrade the BSP on the target and to make it fails
> saft.
> 
> Is ther any helpeful things I can use in uboot for this.?
> 
> My plan is to split my flash I 4 levels.
> 
> High
>            Filesystem
>            BSP_2
>            BSP_1
>            uBoot
> Low
> 
> And then let uBoot make a checksum on BSP_2 and boot this.
> If it's not is possible then boot BSP_1.
> 
> Another option is to build in a telnet session or something in the
> bootloader so ist possible to upgrade remote on only a Ethernet
connection.
> But it think the best is to keep the bootloader "simple".
> 
> /Lasse

You could add a command to u-boot to do checksum stuff and store the
result in an environment variable. 
Then you have the boot command be something like:

bootcmd='check_boot; bootm $(pref_bsp_addr)'

-- 
Bas.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] Firmware upgrade possibilites technikes in uboot.
  2010-08-05 14:22 ` Bas Mevissen
@ 2010-08-05 15:02   ` Albert ARIBAUD
  2010-08-05 15:31     ` Bas Mevissen
  0 siblings, 1 reply; 5+ messages in thread
From: Albert ARIBAUD @ 2010-08-05 15:02 UTC (permalink / raw)
  To: u-boot

Le 05/08/2010 16:22, Bas Mevissen a ?crit :
>
> On Thu, 5 Aug 2010 15:41:35 +0200, Lasse Skov<lasko@kk-electronic.com>
> wrote:
>> Hi
>>
>> Im working on a target where I use the u-boot and think a little about
>> good techniques for upgrade the BSP on the target and to make it fails
>> saft.
>>
>> Is ther any helpeful things I can use in uboot for this.?
>>
>> My plan is to split my flash I 4 levels.
>>
>> High
>>             Filesystem
>>             BSP_2
>>             BSP_1
>>             uBoot
>> Low
>>
>> And then let uBoot make a checksum on BSP_2 and boot this.
>> If it's not is possible then boot BSP_1.
>>
>> Another option is to build in a telnet session or something in the
>> bootloader so ist possible to upgrade remote on only a Ethernet
> connection.
>> But it think the best is to keep the bootloader "simple".
>>
>> /Lasse
>
> You could add a command to u-boot to do checksum stuff and store the
> result in an environment variable.
> Then you have the boot command be something like:
>
> bootcmd='check_boot; bootm $(pref_bsp_addr)'

If the BSPs are in uImage format (i.e., supposed to be copied to RAM 
then booted), for which integrity checking already exists. A dirty test 
on my edminiv2 says that the bollowing u-boot command:

	bootm 200000; bootm 300000

tries to boot an uImage from address 200000 and if it fails, tries to 
boot from 300000. Of course there may be smarter ways, but the basics 
are there already. Note that this does not protect agains the first BSP 
being buggy once booted, though, but there's little one can do against this.

As for the remote telnet, the existing netconsole might fit the bill.

Amicalement,
-- 
Albert.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] Firmware upgrade possibilites technikes in uboot.
  2010-08-05 15:02   ` Albert ARIBAUD
@ 2010-08-05 15:31     ` Bas Mevissen
  2010-08-05 18:13       ` Wolfgang Denk
  0 siblings, 1 reply; 5+ messages in thread
From: Bas Mevissen @ 2010-08-05 15:31 UTC (permalink / raw)
  To: u-boot


On Thu, 05 Aug 2010 17:02:31 +0200, Albert ARIBAUD

wrote:

> Note that this does not protect agains the first BSP 
> being buggy once booted, though, but there's little one can do against
> this.
> 

Even then, there is a lot you can do. For example, U-Boot can detect being
started by a watchdog reset, find out what image was started previously,
mark it
invalid and take the other one.

It is just a matter of how much effort one wants to spend. U-Boot is a
rich boot loader that can easily be extended to your needs.

-- 
Bas.
(currently working on boot software for an automotive ECU)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot] Firmware upgrade possibilites technikes in uboot.
  2010-08-05 15:31     ` Bas Mevissen
@ 2010-08-05 18:13       ` Wolfgang Denk
  0 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Denk @ 2010-08-05 18:13 UTC (permalink / raw)
  To: u-boot

Dear Bas Mevissen,

In message <79b14f2465df4acec1e67a710d13ce63@localhost> you wrote:
> 
> > Note that this does not protect agains the first BSP 
> > being buggy once booted, though, but there's little one can do against
> > this.
> > 
> 
> Even then, there is a lot you can do. For example, U-Boot can detect being
> started by a watchdog reset, find out what image was started previously,
> mark it
> invalid and take the other one.
> 
> It is just a matter of how much effort one wants to spend. U-Boot is a
> rich boot loader that can easily be extended to your needs.

Actually you don;t even have to extend if for this - it's supported
out of the box (at least on several architectures); see the
"bootcount" feature =>
http://www.denx.de/wiki/view/DULG/UBootBootCountLimit

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_

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-08-05 18:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-05 13:41 [U-Boot] Firmware upgrade possibilites technikes in uboot Lasse Skov
2010-08-05 14:22 ` Bas Mevissen
2010-08-05 15:02   ` Albert ARIBAUD
2010-08-05 15:31     ` Bas Mevissen
2010-08-05 18:13       ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.