Firmware architecture for firmware update

On May 20, 11:56=A0am, Marc Jet <jetm...@hotmail.com> wrote:
> 256KB on GPRS is not excessive. =A0It will finish in less than 4 minutes
> worst case (2G single timeslot).

I wish this was true. In real world conditions I can tell you from
bitter personal experience that it is more like two hours
"worst" [observed] case with an average more like 30-45 minutes.
That's for a gzipped image that was originally 256K pre-compression,
too. Tested in many many sites.

larwe skrev 2011-05-21 04:33:
> On May 20, 11:56 am, Marc Jet<jetm...@hotmail.com>  wrote:
>> 256KB on GPRS is not excessive.  It will finish in less than 4 minutes
>> worst case (2G single timeslot).
>
> I wish this was true. In real world conditions I can tell you from
> bitter personal experience that it is more like two hours
> "worst" [observed] case with an average more like 30-45 minutes.
> That's for a gzipped image that was originally 256K pre-compression,
> too. Tested in many many sites.
>

Normally, you pay per bit and not per minute,
so is the time important?
In Sweden, to download 256 kB would cost about $0.50.

BR
Ulf Samuelsson

Nobody wrote:
> On Fri, 20 May 2011 11:19:19 -0700, John Speth wrote:
>>I think (not sure) the shared library approach is slow only the first time 
>>the library is demand loaded.  After that, use of the library is the same as 
>>if it was statically linked.  Isn't that the extent of the slowness of shard 
>>libraries?
> 
> The global offset table (GOT) and procedure linkage table (PLT) have to be
> generated each time a program is executed. The use of position-independent
> code means that relocations don't have to be performed within the actual
> code. The PLT can either be generated at startup or be generated lazily,
> i.e. each entry is generated the first time that the function is called.
> The GOT is always generated at startup.

The thread starter was talking about a firmware image of 256 kByte
total. I doubt he's using a full off-the-book System V shared object
implementation. There's plenty of room for optimisation.

For example, the GOT and PLT can be generated at the time of the
firmware update. The shared object can be stored in fully-relocated
form. It doesn't have to use position-independant code if we can patch
the binary code. Essentially, this is what MS Windows does. It's called
"binding":
http://blogs.msdn.com/b/oldnewthing/archive/2010/03/18/9980802.aspx

> Linking against static libraries results in the use of fixed addresses.
> This reduces startup time, as no GOT/PLT entries are required, and
> increases execution speed slightly (a typical estimate is 4%) as a level
> of indirection is removed.

This is what happens when you load a Linux kernel module. Up to kernel
2.4.x, a module is a standard .o file, which is statically linked
against the running kernel (in 2.6 it's slightly different but the basic
process, as far as I know, is the same).


  Stefan

On May 21, 12:19=A0am, Ulf Samuelsson <u...@a.com> wrote:

> > I wish this was true. In real world conditions I can tell you from
> > bitter personal experience that it is more like two hours
> > "worst" [observed] case with an average more like 30-45 minutes.
>
> Normally, you pay per bit and not per minute,
> so is the time important?

Sure, it is per-byte payment here in the USA also (except for lucky
people like me who kept some old iPhone account SIMs active to be
grandfathered into unlimited data ;) but the problem is downtime, and
sequencing.

Downtime can be removed if you have enough space to store a redundant
image, but the sequencing/scheduling issue is very important. Our
equipment for instance may need for legal reasons to have a technician
must be on site when the upgrade is rebooted to test the system and
certify it operation. The ideal scenario would be for tech to arrive,
push "upgrade", wait for the code to arrive (a few minutes is ok),
then test the system and leave. Since the time is so unpredictable and
always LONG, this workflow doesn't work.

Also bear in mind we are deploying to hundreds of thousands, if not
millions of units.

On 20/05/11 13:17, alacky3 wrote:
> Hello.
>
> I am implementing a program to be updated via GPRS channel. The total size
> of the firmware reaches about 256 kB which makes it somewhat costly
> upgrades. I considered the idea of dividing the firmware into independent
> parts that can be updated independently and upgrade only the changed parts,
> but I don't know how to begin. Does anyone has had a similar problem? How
> do you have solved it?
>
> Thanks.
>

Can you separate code and data?  Maybe the 256K contains tables, images, 
fonts, or something that is relatively fixed, and can be separated. 
It's a lot easier to add a little indirection to the access of such 
tables than to have more general dynamically linked libraries.

Can you patch the firmware, so that the user downloads a delta from one 
version to the next?

In article <YdOdnaRiVOFc0EvQnZ2dnUVZ_j6dnZ2d@giganews.com>,
alacky3 <sr.alacran@n_o_s_p_a_m.gmail.com> wrote:
>Hello.
>
>I am implementing a program to be updated via GPRS channel. The total size
>of the firmware reaches about 256 kB which makes it somewhat costly
>upgrades. I considered the idea of dividing the firmware into independent
>parts that can be updated independently and upgrade only the changed parts,
>but I don't know how to begin. Does anyone has had a similar problem? How
>do you have solved it?

A straightforward solution is to have two sections for each library.
One section contains addresses of subroutines in the other section.
The main program and the libraries are linked to the section with
the addresses.
The linking can be difficult, but I blame those linkers,
because this is conceptually simple.

Each pair of sections must be put in a fixed place.
A pair of sections can be exchanged without affecting linking.
The overhead is very small, an extra indirection.

In assembler it is a snap, especially with macro's.
In c it looks bad.
An instrumented c-compiler could handle it transparently.

The details are much dependant on the tools you have available.

>Thanks.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst