Forums

Firmware architecture for firmware update

Started by alacky3 May 20, 2011
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