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

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?

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.

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

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

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.

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.

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. The main performance downside is that, if
multiple processes are running different programs which use the same
library, each program will have its own copy of the library, which
increases the demand for memory.

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?

The 256kB is not much; looks like a monolitic application to me. 
Breaking it into the chunks would be difficult and inconvenient.

The good way to deal with this problem is DIFF. I.e. a compressed format 
which uses the current application as a dictionary for the compression. 
Only the references to the current dictionary and the changes have to be 
transmitted.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>>> Under windows you'd do this with dll's.  Even though I use Linux, I
>>> can't remember the name of the same concept, but the file suffix is .so.
>>
>> It's either Dynamic Linking Loader (dll) or Dynamic Loading Linker
>> (dll) for Shared Objects (so).  However, there are quite a bit of run-
>> time overheads using them.  For firmware, it might be easier to just
>> separate the library into "ROM" code and calls, traps or soft intr.
>> into it.
>
> Yes, anything that's dynamically linking is going to be slow -- I was 
> trying to get some concepts and search terms to the guy as much as make 
> specific recommendations.

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?

I'm not sure of the memory resource usage at load time.  I'll bet it's 
temporary (extra memory released after loading happens).

JJS

On 05/20/2011 10:27 AM, linnix wrote:
> On May 20, 8:15 am, Tim Wescott<t...@seemywebsite.com>  wrote:
>> On 05/20/2011 04:17 AM, 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?
>>
>> Under windows you'd do this with dll's.  Even though I use Linux, I
>> can't remember the name of the same concept, but the file suffix is .so.
>
> It's either Dynamic Linking Loader (dll) or Dynamic Loading Linker
> (dll) for Shared Objects (so).  However, there are quite a bit of run-
> time overheads using them.  For firmware, it might be easier to just
> separate the library into "ROM" code and calls, traps or soft intr.
> into it.

Yes, anything that's dynamically linking is going to be slow -- I was 
trying to get some concepts and search terms to the guy as much as make 
specific recommendations.

Certainly if size and speed were a concern, I'd want to do this with 
something more statically linked (although I can't see how to avoid jump 
tables or the equivalent).  I can think of several ways to do this right 
off the bat, but in the end you're going to have to sacrifice some 
combination of speed, versatility, or design time.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html