OK, I've got bootloader/IAP code for the user to
update the main application code. (IAR EWARM, LPC2144)
I am wondering if there is a good reason to
put the bootloader in one place in memory vs.
another spot in memory... i.e. top or bottom ??
I could locate the code protected bootloader (and
INTVECtors) at 000000 and during a normal boot, pass
execution to the application code at, say, 0x1000 in
sector 1. OR, I could put the bootloader up at the
top of memory and have location 000000 jump to the
beginning of the bootloader which would pass
execution to the application at lower memory when
an update is not required.
I guess my question is how would you handle the
interrupt vectors and which spot would you put
the bootloader code ? My application code
needs the IRQ interrupt vector at 0x0018 of
course. Also, that 0x0001fc CRP word is at the
bottom of memory and I would rather not touch
that if possible after it is set to 0x87654321
The bootloader code does not use any IRQs.
Any typical preferences or reasons that I should
be aware of in determining where to put which code
segment ?
Thanks,
boB
BootLoader and application code location suggestions?
Started by ●March 15, 2007
Reply by ●March 15, 20072007-03-15
--- In l..., "bobtransformer" wrote:
> OK, I've got bootloader/IAP code for the user to
> update the main application code. (IAR EWARM, LPC2144)
>
> I am wondering if there is a good reason to
> put the bootloader in one place in memory vs.
> another spot in memory... i.e. top or bottom ??
>
> I could locate the code protected bootloader (and
> INTVECtors) at 000000 and during a normal boot, pass
> execution to the application code at, say, 0x1000 in
> sector 1. OR, I could put the bootloader up at the
> top of memory and have location 000000 jump to the
> beginning of the bootloader which would pass
> execution to the application at lower memory when
> an update is not required.
>
> I guess my question is how would you handle the
> interrupt vectors and which spot would you put
> the bootloader code ? My application code
> needs the IRQ interrupt vector at 0x0018 of
> course. Also, that 0x0001fc CRP word is at the
> bottom of memory and I would rather not touch
> that if possible after it is set to 0x87654321
> The bootloader code does not use any IRQs.
>
> Any typical preferences or reasons that I should
> be aware of in determining where to put which code
> segment ?
>
> Thanks,
> boB
>
Hi Bob,
Some thoughts.
Putting your loader anywhere other than top or bottom will fragment
flash into two segments, something I would not recommend.
Bottom of memory (user flash sector 0) means:
* Additional (expensive?) branch to interrupt service.
* Users must remember to relocate interrupt vectors.
* Users cannot use CRP, and new CRP paradigms will not work.
* Defeats ARM's cycle saving FIQ service routine paradigm.
Top of Memory (just below NXP's Boot Loader) means:
* You cannot prevent your loader from being erased/scribbled.
* Users only need to know of two things: use reset vector you supply,
and start code at location (say 0x200) that you specify.
This IMO the second option is preferable to the first.
However I would recommend you patch NXP's Boot Loader (I have seen it
done many times, albeit some for nefarious purposes) to invoke your
boot loader rather than the reset vector, and let your loader dispatch
the right reset vector in user flash or external memory.
This way the user code does not even have to be aware of your loader.
Your loader will be transparent with respect to CRP, ISP, IAP and
everything else in NXP's user manual except for how the added upgrade API.
Hope this helps.
Jaya
> OK, I've got bootloader/IAP code for the user to
> update the main application code. (IAR EWARM, LPC2144)
>
> I am wondering if there is a good reason to
> put the bootloader in one place in memory vs.
> another spot in memory... i.e. top or bottom ??
>
> I could locate the code protected bootloader (and
> INTVECtors) at 000000 and during a normal boot, pass
> execution to the application code at, say, 0x1000 in
> sector 1. OR, I could put the bootloader up at the
> top of memory and have location 000000 jump to the
> beginning of the bootloader which would pass
> execution to the application at lower memory when
> an update is not required.
>
> I guess my question is how would you handle the
> interrupt vectors and which spot would you put
> the bootloader code ? My application code
> needs the IRQ interrupt vector at 0x0018 of
> course. Also, that 0x0001fc CRP word is at the
> bottom of memory and I would rather not touch
> that if possible after it is set to 0x87654321
> The bootloader code does not use any IRQs.
>
> Any typical preferences or reasons that I should
> be aware of in determining where to put which code
> segment ?
>
> Thanks,
> boB
>
Hi Bob,
Some thoughts.
Putting your loader anywhere other than top or bottom will fragment
flash into two segments, something I would not recommend.
Bottom of memory (user flash sector 0) means:
* Additional (expensive?) branch to interrupt service.
* Users must remember to relocate interrupt vectors.
* Users cannot use CRP, and new CRP paradigms will not work.
* Defeats ARM's cycle saving FIQ service routine paradigm.
Top of Memory (just below NXP's Boot Loader) means:
* You cannot prevent your loader from being erased/scribbled.
* Users only need to know of two things: use reset vector you supply,
and start code at location (say 0x200) that you specify.
This IMO the second option is preferable to the first.
However I would recommend you patch NXP's Boot Loader (I have seen it
done many times, albeit some for nefarious purposes) to invoke your
boot loader rather than the reset vector, and let your loader dispatch
the right reset vector in user flash or external memory.
This way the user code does not even have to be aware of your loader.
Your loader will be transparent with respect to CRP, ISP, IAP and
everything else in NXP's user manual except for how the added upgrade API.
Hope this helps.
Jaya
Reply by ●March 15, 20072007-03-15
Thanks Jaya, however, the bootloader in this case is actually for
the customer of the product to download ~MY~ new code in the
field. The code that the customer downloads to the LPC2144 is
encrypted before the customer receives it so the bootloader will not
change. Of course I will use FIQ in the main app. but I am only using
the IRQ handler for UARTs, etc. at present. No IRQs used for the
bootloader itself of course.
Another thing that came to mind is that 0x001fC (CRP) is also down
at the bottom and could be in my bootloader code. I could
"prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
IRQs etc OR I could just always have a specified absolute address
vector there and expect it to be some particular place I suppose. I
~could~ patch the NXP bootloader too if I have to (as I know you're
pretty good at now) but I would rather not if I don't have to.
Right now I am looking at my two cstartup.c files for the bootloader
and application code and trying to decide the best way to
have the two programs play nicely with each other.
Sorry, I was not quite clear on my use of this bootloader.
Maybe this helps on my question a little.
Then again, maybe I'm thinking and trying too hard on a non-issue, but
the two pieces still have to co-exist peacefully together.
Thanks,
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > OK, I've got bootloader/IAP code for the user to
> > update the main application code. (IAR EWARM, LPC2144)
> >
> > I am wondering if there is a good reason to
> > put the bootloader in one place in memory vs.
> > another spot in memory... i.e. top or bottom ??
> >
> > I could locate the code protected bootloader (and
> > INTVECtors) at 000000 and during a normal boot, pass
> > execution to the application code at, say, 0x1000 in
> > sector 1. OR, I could put the bootloader up at the
> > top of memory and have location 000000 jump to the
> > beginning of the bootloader which would pass
> > execution to the application at lower memory when
> > an update is not required.
> >
> > I guess my question is how would you handle the
> > interrupt vectors and which spot would you put
> > the bootloader code ? My application code
> > needs the IRQ interrupt vector at 0x0018 of
> > course. Also, that 0x0001fc CRP word is at the
> > bottom of memory and I would rather not touch
> > that if possible after it is set to 0x87654321
> > The bootloader code does not use any IRQs.
> >
> > Any typical preferences or reasons that I should
> > be aware of in determining where to put which code
> > segment ?
> >
> > Thanks,
> > boB
> > Hi Bob,
>
> Some thoughts.
>
> Putting your loader anywhere other than top or bottom will fragment
> flash into two segments, something I would not recommend.
>
> Bottom of memory (user flash sector 0) means:
>
> * Additional (expensive?) branch to interrupt service.
> * Users must remember to relocate interrupt vectors.
> * Users cannot use CRP, and new CRP paradigms will not work.
> * Defeats ARM's cycle saving FIQ service routine paradigm.
>
> Top of Memory (just below NXP's Boot Loader) means:
>
> * You cannot prevent your loader from being erased/scribbled.
> * Users only need to know of two things: use reset vector you supply,
> and start code at location (say 0x200) that you specify.
>
> This IMO the second option is preferable to the first.
>
> However I would recommend you patch NXP's Boot Loader (I have seen it
> done many times, albeit some for nefarious purposes) to invoke your
> boot loader rather than the reset vector, and let your loader dispatch
> the right reset vector in user flash or external memory.
>
> This way the user code does not even have to be aware of your loader.
> Your loader will be transparent with respect to CRP, ISP, IAP and
> everything else in NXP's user manual except for how the added
upgrade API.
>
> Hope this helps.
>
> Jaya
>
the customer of the product to download ~MY~ new code in the
field. The code that the customer downloads to the LPC2144 is
encrypted before the customer receives it so the bootloader will not
change. Of course I will use FIQ in the main app. but I am only using
the IRQ handler for UARTs, etc. at present. No IRQs used for the
bootloader itself of course.
Another thing that came to mind is that 0x001fC (CRP) is also down
at the bottom and could be in my bootloader code. I could
"prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
IRQs etc OR I could just always have a specified absolute address
vector there and expect it to be some particular place I suppose. I
~could~ patch the NXP bootloader too if I have to (as I know you're
pretty good at now) but I would rather not if I don't have to.
Right now I am looking at my two cstartup.c files for the bootloader
and application code and trying to decide the best way to
have the two programs play nicely with each other.
Sorry, I was not quite clear on my use of this bootloader.
Maybe this helps on my question a little.
Then again, maybe I'm thinking and trying too hard on a non-issue, but
the two pieces still have to co-exist peacefully together.
Thanks,
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > OK, I've got bootloader/IAP code for the user to
> > update the main application code. (IAR EWARM, LPC2144)
> >
> > I am wondering if there is a good reason to
> > put the bootloader in one place in memory vs.
> > another spot in memory... i.e. top or bottom ??
> >
> > I could locate the code protected bootloader (and
> > INTVECtors) at 000000 and during a normal boot, pass
> > execution to the application code at, say, 0x1000 in
> > sector 1. OR, I could put the bootloader up at the
> > top of memory and have location 000000 jump to the
> > beginning of the bootloader which would pass
> > execution to the application at lower memory when
> > an update is not required.
> >
> > I guess my question is how would you handle the
> > interrupt vectors and which spot would you put
> > the bootloader code ? My application code
> > needs the IRQ interrupt vector at 0x0018 of
> > course. Also, that 0x0001fc CRP word is at the
> > bottom of memory and I would rather not touch
> > that if possible after it is set to 0x87654321
> > The bootloader code does not use any IRQs.
> >
> > Any typical preferences or reasons that I should
> > be aware of in determining where to put which code
> > segment ?
> >
> > Thanks,
> > boB
> > Hi Bob,
>
> Some thoughts.
>
> Putting your loader anywhere other than top or bottom will fragment
> flash into two segments, something I would not recommend.
>
> Bottom of memory (user flash sector 0) means:
>
> * Additional (expensive?) branch to interrupt service.
> * Users must remember to relocate interrupt vectors.
> * Users cannot use CRP, and new CRP paradigms will not work.
> * Defeats ARM's cycle saving FIQ service routine paradigm.
>
> Top of Memory (just below NXP's Boot Loader) means:
>
> * You cannot prevent your loader from being erased/scribbled.
> * Users only need to know of two things: use reset vector you supply,
> and start code at location (say 0x200) that you specify.
>
> This IMO the second option is preferable to the first.
>
> However I would recommend you patch NXP's Boot Loader (I have seen it
> done many times, albeit some for nefarious purposes) to invoke your
> boot loader rather than the reset vector, and let your loader dispatch
> the right reset vector in user flash or external memory.
>
> This way the user code does not even have to be aware of your loader.
> Your loader will be transparent with respect to CRP, ISP, IAP and
> everything else in NXP's user manual except for how the added
upgrade API.
>
> Hope this helps.
>
> Jaya
>
Reply by ●March 15, 20072007-03-15
--- In l..., "bobtransformer" wrote:
> Thanks Jaya, however, the bootloader in this case is actually for
> the customer of the product to download ~MY~ new code in the
> field.
Okay, I get a better picture now.
> The code that the customer downloads to the LPC2144 is
> encrypted before the customer receives it so the bootloader will not
> change.
I suggest you keep the keys in a sector that you will overwrite (eg
with the application code) and not in the sector where your loader
resides. This allows you to change or use chained keys.
> Of course I will use FIQ in the main app. but I am only using
> the IRQ handler for UARTs, etc. at present. No IRQs used for the
> bootloader itself of course.
In this case I think you are better off locating your loader in sector
0 and simply re-map vectors them to sector where your application is.
> Another thing that came to mind is that 0x001fC (CRP) is also down
> at the bottom and could be in my bootloader code.
NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
what has been said so far, I foresee problems with CRP1 and CRP3 and
it pays to be extremely careful with what you put in 0x1fc.
Furthermore, I do not recommend you erase sector 0 in the field. It
creates a security loop hole.
> I could
> "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> IRQs etc OR I could just always have a specified absolute address
> vector there and expect it to be some particular place I suppose.
I dont understand what you mean by re-write? Dont you have to erase
first? If erasing, see comment above.
I think re-mapping the vectors to the start of the application sector
is a better way to go if you are not concerned with the cost of extra
branch on each interrupt. I dont but I know some who will fight tooth
and nail against this :)
> I ~could~ patch the NXP bootloader too if I have to (as I know you're
> pretty good at now) but I would rather not if I don't have to.
Actually I prefer replacing the NXP Boot Loader to patching it. It is
difficult to know what is in the Boot Loader on your particular part
or board and what it does outside what it is supposed to do.
> Right now I am looking at my two cstartup.c files for the bootloader
> and application code and trying to decide the best way to
> have the two programs play nicely with each other.
I do not see any problems with this approach.
> Sorry, I was not quite clear on my use of this bootloader.
> Maybe this helps on my question a little.
Yes it did.
> Then again, maybe I'm thinking and trying too hard on a non-issue, but
> the two pieces still have to co-exist peacefully together.
>
> Thanks,
> boB
Jaya
> Thanks Jaya, however, the bootloader in this case is actually for
> the customer of the product to download ~MY~ new code in the
> field.
Okay, I get a better picture now.
> The code that the customer downloads to the LPC2144 is
> encrypted before the customer receives it so the bootloader will not
> change.
I suggest you keep the keys in a sector that you will overwrite (eg
with the application code) and not in the sector where your loader
resides. This allows you to change or use chained keys.
> Of course I will use FIQ in the main app. but I am only using
> the IRQ handler for UARTs, etc. at present. No IRQs used for the
> bootloader itself of course.
In this case I think you are better off locating your loader in sector
0 and simply re-map vectors them to sector where your application is.
> Another thing that came to mind is that 0x001fC (CRP) is also down
> at the bottom and could be in my bootloader code.
NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
what has been said so far, I foresee problems with CRP1 and CRP3 and
it pays to be extremely careful with what you put in 0x1fc.
Furthermore, I do not recommend you erase sector 0 in the field. It
creates a security loop hole.
> I could
> "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> IRQs etc OR I could just always have a specified absolute address
> vector there and expect it to be some particular place I suppose.
I dont understand what you mean by re-write? Dont you have to erase
first? If erasing, see comment above.
I think re-mapping the vectors to the start of the application sector
is a better way to go if you are not concerned with the cost of extra
branch on each interrupt. I dont but I know some who will fight tooth
and nail against this :)
> I ~could~ patch the NXP bootloader too if I have to (as I know you're
> pretty good at now) but I would rather not if I don't have to.
Actually I prefer replacing the NXP Boot Loader to patching it. It is
difficult to know what is in the Boot Loader on your particular part
or board and what it does outside what it is supposed to do.
> Right now I am looking at my two cstartup.c files for the bootloader
> and application code and trying to decide the best way to
> have the two programs play nicely with each other.
I do not see any problems with this approach.
> Sorry, I was not quite clear on my use of this bootloader.
> Maybe this helps on my question a little.
Yes it did.
> Then again, maybe I'm thinking and trying too hard on a non-issue, but
> the two pieces still have to co-exist peacefully together.
>
> Thanks,
> boB
Jaya
Reply by ●March 15, 20072007-03-15
Quite an interesting read so far, just as an aside in terms of the CRP
issues, could you not simply set the scatter file to force the linker to
reserve use of the address 0x1FC for a code protect value?
I've done this with both RV and Carm compilers in Keil's uvision IDE and it
certainly makes life simple for turning CRP on and off and should allow you
to circumvent any issues with code surrounding the address.
I think Reinhart Keil has published the RV method on the Keil website now
actually as it wasn't as straightforward as first thought.
BTW Jaya, I tried an LPC2129 part with 0x43218765 at 0x1FC and found it also
enforced CRP as you found on your LPC2468. Has there been any further info
on that?
Andy
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
jayasooriah
Sent: 15 March 2007 10:40
To: l...
Subject: [lpc2000] Re: BootLoader and application code location
suggestions?
--- In l..., "bobtransformer" wrote:
>
>
> Thanks Jaya, however, the bootloader in this case is actually for
> the customer of the product to download ~MY~ new code in the
> field.
Okay, I get a better picture now.
> The code that the customer downloads to the LPC2144 is
> encrypted before the customer receives it so the bootloader will not
> change.
I suggest you keep the keys in a sector that you will overwrite (eg
with the application code) and not in the sector where your loader
resides. This allows you to change or use chained keys.
> Of course I will use FIQ in the main app. but I am only using
> the IRQ handler for UARTs, etc. at present. No IRQs used for the
> bootloader itself of course.
In this case I think you are better off locating your loader in sector
0 and simply re-map vectors them to sector where your application is.
> Another thing that came to mind is that 0x001fC (CRP) is also down
> at the bottom and could be in my bootloader code.
NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
what has been said so far, I foresee problems with CRP1 and CRP3 and
it pays to be extremely careful with what you put in 0x1fc.
Furthermore, I do not recommend you erase sector 0 in the field. It
creates a security loop hole.
> I could
> "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> IRQs etc OR I could just always have a specified absolute address
> vector there and expect it to be some particular place I suppose.
I dont understand what you mean by re-write? Dont you have to erase
first? If erasing, see comment above.
I think re-mapping the vectors to the start of the application sector
is a better way to go if you are not concerned with the cost of extra
branch on each interrupt. I dont but I know some who will fight tooth
and nail against this :)
> I ~could~ patch the NXP bootloader too if I have to (as I know you're
> pretty good at now) but I would rather not if I don't have to.
Actually I prefer replacing the NXP Boot Loader to patching it. It is
difficult to know what is in the Boot Loader on your particular part
or board and what it does outside what it is supposed to do.
> Right now I am looking at my two cstartup.c files for the bootloader
> and application code and trying to decide the best way to
> have the two programs play nicely with each other.
I do not see any problems with this approach.
> Sorry, I was not quite clear on my use of this bootloader.
> Maybe this helps on my question a little.
Yes it did.
> Then again, maybe I'm thinking and trying too hard on a non-issue, but
> the two pieces still have to co-exist peacefully together.
>
> Thanks,
> boB
Jaya
issues, could you not simply set the scatter file to force the linker to
reserve use of the address 0x1FC for a code protect value?
I've done this with both RV and Carm compilers in Keil's uvision IDE and it
certainly makes life simple for turning CRP on and off and should allow you
to circumvent any issues with code surrounding the address.
I think Reinhart Keil has published the RV method on the Keil website now
actually as it wasn't as straightforward as first thought.
BTW Jaya, I tried an LPC2129 part with 0x43218765 at 0x1FC and found it also
enforced CRP as you found on your LPC2468. Has there been any further info
on that?
Andy
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
jayasooriah
Sent: 15 March 2007 10:40
To: l...
Subject: [lpc2000] Re: BootLoader and application code location
suggestions?
--- In l..., "bobtransformer" wrote:
>
>
> Thanks Jaya, however, the bootloader in this case is actually for
> the customer of the product to download ~MY~ new code in the
> field.
Okay, I get a better picture now.
> The code that the customer downloads to the LPC2144 is
> encrypted before the customer receives it so the bootloader will not
> change.
I suggest you keep the keys in a sector that you will overwrite (eg
with the application code) and not in the sector where your loader
resides. This allows you to change or use chained keys.
> Of course I will use FIQ in the main app. but I am only using
> the IRQ handler for UARTs, etc. at present. No IRQs used for the
> bootloader itself of course.
In this case I think you are better off locating your loader in sector
0 and simply re-map vectors them to sector where your application is.
> Another thing that came to mind is that 0x001fC (CRP) is also down
> at the bottom and could be in my bootloader code.
NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
what has been said so far, I foresee problems with CRP1 and CRP3 and
it pays to be extremely careful with what you put in 0x1fc.
Furthermore, I do not recommend you erase sector 0 in the field. It
creates a security loop hole.
> I could
> "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> IRQs etc OR I could just always have a specified absolute address
> vector there and expect it to be some particular place I suppose.
I dont understand what you mean by re-write? Dont you have to erase
first? If erasing, see comment above.
I think re-mapping the vectors to the start of the application sector
is a better way to go if you are not concerned with the cost of extra
branch on each interrupt. I dont but I know some who will fight tooth
and nail against this :)
> I ~could~ patch the NXP bootloader too if I have to (as I know you're
> pretty good at now) but I would rather not if I don't have to.
Actually I prefer replacing the NXP Boot Loader to patching it. It is
difficult to know what is in the Boot Loader on your particular part
or board and what it does outside what it is supposed to do.
> Right now I am looking at my two cstartup.c files for the bootloader
> and application code and trying to decide the best way to
> have the two programs play nicely with each other.
I do not see any problems with this approach.
> Sorry, I was not quite clear on my use of this bootloader.
> Maybe this helps on my question a little.
Yes it did.
> Then again, maybe I'm thinking and trying too hard on a non-issue, but
> the two pieces still have to co-exist peacefully together.
>
> Thanks,
> boB
Jaya
Reply by ●March 15, 20072007-03-15
bobtransformer wrote:
> OK, I've got bootloader/IAP code for the user to
> update the main application code. (IAR EWARM, LPC2144)
>
> I am wondering if there is a good reason to
> put the bootloader in one place in memory vs.
> another spot in memory... i.e. top or bottom ??
>
> I could locate the code protected bootloader (and
> INTVECtors) at 000000 and during a normal boot, pass
> execution to the application code at, say, 0x1000 in
> sector 1. OR, I could put the bootloader up at the
> top of memory and have location 000000 jump to the
> beginning of the bootloader which would pass
> execution to the application at lower memory when
> an update is not required.
>
> I guess my question is how would you handle the
> interrupt vectors and which spot would you put
> the bootloader code ? My application code
> needs the IRQ interrupt vector at 0x0018 of
> course. Also, that 0x0001fc CRP word is at the
> bottom of memory and I would rather not touch
> that if possible after it is set to 0x87654321
> The bootloader code does not use any IRQs.
>
This the approach that I have taken. This is for a commercial product
which will replace / upgrade an existing 8051 design. There are several
considerations, things which we have learned about our customers over
the years... Due to non-disclosure, I will call the LPC2214 design
"widget".
1. NO special software is to be installed on their laptop computers to
update the software. We have found that once you give them software to
install on their computer, YOU own that computer! There are some that
will call you and insist that it was YOUR software which screwed
Lotus-123 or other program.
2. We need absolute control over what software is installed onto what
widget. There are various optional levels of software, with differing
prices. The widget they purchase must be limited as to what it can
run. IOW, if you purchase the basic unit, you cannot take software from
the advanced unit and install it onto the basic unit.
3. We need logging. Not only for exception crash-dumps, but they need
to do data captures so that we can see what is going on when things
don't work correctly.
4. Software should be easily installed using commonly available computer
software / interfaces. Also, we need to be able to email the customer
their software, or, have them download it from our website. This was,
the most current version of the software is available at all times.
Following that criteria, I have come up with an LPC2214 design with an
SD card and 512K of external RAM. The bootstrap resides in the first
64K of Flash (0x00000000..0x0000FFFF) and the loader can occupy the next
128K of Flash (0x00010000..0x0002FFFF). All remaining Flash (8K
sectors) is to be used for current config data and unused sectors left
for future use (0x00030000..0x0003DFFF).
The bootstrap contains a SerialNumber and a SiteNumber. The bootstrap
never will be field upgraded. All other software binaries reside on the
SD card and are loaded / run on demand. The loader program is like the
backend of the bootstrap, it is the field replaceable part of it. The
bootstrap code authenticates the files using an algorithm that I've come
up with. If the file passes the authentication, it is loaded into RAM
and executed.
All the customer has to do is to have a camera media reader and
software installed onto their computer. They copy the files we give
them onto the SD card, then insert the card into the widget. The
bootstrap checks the current version of the loader image in Flash, if it
is out of date, it replaces it.
An interesting point is that we do have installations with several
hundred widgets (a Site) where the customer would need a "site wide copy
of software". This is what the embedded SiteNumber is for, they order
the widgets with for a particular Site and then one copy of the software
will run on all units.
The software authentication scheme will only allow a binary that has
been encoded for either a match to the SerialNumber or SiteNumber that
is stored inside the widget.
Loading the runtime executable binary from the SD card does take a
couple of seconds before the system boots. It does have to bootstrap
itself, check the loader version, execute the loader, then the loader
identifies the appropriate executeable, then asks the bootstrap code if
that binary image is ok to run. However, once the system is up and
running, they usually run for months and months without requiring a reset.
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
> OK, I've got bootloader/IAP code for the user to
> update the main application code. (IAR EWARM, LPC2144)
>
> I am wondering if there is a good reason to
> put the bootloader in one place in memory vs.
> another spot in memory... i.e. top or bottom ??
>
> I could locate the code protected bootloader (and
> INTVECtors) at 000000 and during a normal boot, pass
> execution to the application code at, say, 0x1000 in
> sector 1. OR, I could put the bootloader up at the
> top of memory and have location 000000 jump to the
> beginning of the bootloader which would pass
> execution to the application at lower memory when
> an update is not required.
>
> I guess my question is how would you handle the
> interrupt vectors and which spot would you put
> the bootloader code ? My application code
> needs the IRQ interrupt vector at 0x0018 of
> course. Also, that 0x0001fc CRP word is at the
> bottom of memory and I would rather not touch
> that if possible after it is set to 0x87654321
> The bootloader code does not use any IRQs.
>
This the approach that I have taken. This is for a commercial product
which will replace / upgrade an existing 8051 design. There are several
considerations, things which we have learned about our customers over
the years... Due to non-disclosure, I will call the LPC2214 design
"widget".
1. NO special software is to be installed on their laptop computers to
update the software. We have found that once you give them software to
install on their computer, YOU own that computer! There are some that
will call you and insist that it was YOUR software which screwed
Lotus-123 or other program.
2. We need absolute control over what software is installed onto what
widget. There are various optional levels of software, with differing
prices. The widget they purchase must be limited as to what it can
run. IOW, if you purchase the basic unit, you cannot take software from
the advanced unit and install it onto the basic unit.
3. We need logging. Not only for exception crash-dumps, but they need
to do data captures so that we can see what is going on when things
don't work correctly.
4. Software should be easily installed using commonly available computer
software / interfaces. Also, we need to be able to email the customer
their software, or, have them download it from our website. This was,
the most current version of the software is available at all times.
Following that criteria, I have come up with an LPC2214 design with an
SD card and 512K of external RAM. The bootstrap resides in the first
64K of Flash (0x00000000..0x0000FFFF) and the loader can occupy the next
128K of Flash (0x00010000..0x0002FFFF). All remaining Flash (8K
sectors) is to be used for current config data and unused sectors left
for future use (0x00030000..0x0003DFFF).
The bootstrap contains a SerialNumber and a SiteNumber. The bootstrap
never will be field upgraded. All other software binaries reside on the
SD card and are loaded / run on demand. The loader program is like the
backend of the bootstrap, it is the field replaceable part of it. The
bootstrap code authenticates the files using an algorithm that I've come
up with. If the file passes the authentication, it is loaded into RAM
and executed.
All the customer has to do is to have a camera media reader and
software installed onto their computer. They copy the files we give
them onto the SD card, then insert the card into the widget. The
bootstrap checks the current version of the loader image in Flash, if it
is out of date, it replaces it.
An interesting point is that we do have installations with several
hundred widgets (a Site) where the customer would need a "site wide copy
of software". This is what the embedded SiteNumber is for, they order
the widgets with for a particular Site and then one copy of the software
will run on all units.
The software authentication scheme will only allow a binary that has
been encoded for either a match to the SerialNumber or SiteNumber that
is stored inside the widget.
Loading the runtime executable binary from the SD card does take a
couple of seconds before the system boots. It does have to bootstrap
itself, check the loader version, execute the loader, then the loader
identifies the appropriate executeable, then asks the bootstrap code if
that binary image is ok to run. However, once the system is up and
running, they usually run for months and months without requiring a reset.
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
Reply by ●March 15, 20072007-03-15
--- In l..., Tom Walsh wrote:
> This the approach that I have taken. This is for a commercial
product
> which will replace / upgrade an existing 8051 design. There are
several
> considerations, things which we have learned about our customers
over
> the years... Due to non-disclosure, I will call the LPC2214 design
> "widget".
>
> 1. NO special software is to be installed on their laptop computers
to
> update the software. We have found that once you give them
software to
> install on their computer, YOU own that computer! There are some
that
> will call you and insist that it was YOUR software which screwed
> Lotus-123 or other program.
>
> 2. We need absolute control over what software is installed onto
what
> widget. There are various optional levels of software, with
differing
> prices. The widget they purchase must be limited as to what it can
> run. IOW, if you purchase the basic unit, you cannot take software
from
> the advanced unit and install it onto the basic unit.
>
> 3. We need logging. Not only for exception crash-dumps, but they
need
> to do data captures so that we can see what is going on when things
> don't work correctly.
>
> 4. Software should be easily installed using commonly available
computer
> software / interfaces. Also, we need to be able to email the
customer
> their software, or, have them download it from our website. This
was,
> the most current version of the software is available at all times.
>
> Following that criteria, I have come up with an LPC2214 design with
an
> SD card and 512K of external RAM. The bootstrap resides in the
first
> 64K of Flash (0x00000000..0x0000FFFF) and the loader can occupy the
next
> 128K of Flash (0x00010000..0x0002FFFF). All remaining Flash (8K
> sectors) is to be used for current config data and unused sectors
left
> for future use (0x00030000..0x0003DFFF).
>
> The bootstrap contains a SerialNumber and a SiteNumber. The
bootstrap
> never will be field upgraded. All other software binaries reside
on the
> SD card and are loaded / run on demand. The loader program is like
the
> backend of the bootstrap, it is the field replaceable part of it.
The
> bootstrap code authenticates the files using an algorithm that I've
come
> up with. If the file passes the authentication, it is loaded into
RAM
> and executed.
>
> All the customer has to do is to have a camera media reader and
> software installed onto their computer. They copy the files we
give
> them onto the SD card, then insert the card into the widget. The
> bootstrap checks the current version of the loader image in Flash,
if it
> is out of date, it replaces it.
>
> An interesting point is that we do have installations with several
> hundred widgets (a Site) where the customer would need a "site wide
copy
> of software". This is what the embedded SiteNumber is for, they
order
> the widgets with for a particular Site and then one copy of the
software
> will run on all units.
>
> The software authentication scheme will only allow a binary that
has
> been encoded for either a match to the SerialNumber or SiteNumber
that
> is stored inside the widget.
>
> Loading the runtime executable binary from the SD card does take a
> couple of seconds before the system boots. It does have to
bootstrap
> itself, check the loader version, execute the loader, then the
loader
> identifies the appropriate executeable, then asks the bootstrap
code if
> that binary image is ok to run. However, once the system is up and
> running, they usually run for months and months without requiring a
reset.
>
> Regards,
> TomW
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net http://cyberiansoftware.com
http://openzipit.org
> "Windows? No thanks, I have work to do..."
> ----------------
>
Tom,
Sounds like a good approach. As you point out there are loads of
issues around in-field upgrades, not all technical.
My inclination is to keep the boot loader part (i.e. the bit that's
never changed), really, really simple:
- boot from cold
- check locations where images are held
- see which is the one to run and make sure its runable (i.e. CRC is
good)
- if necessary load it from where it is (e.g. external EEPROM or CF
card or whatever) to where it needs to be (e.g. internal Flash)
- go run it
- if not runable, revert to the backup image
The key thing with this approach is that the bootloader never gets
upgraded (in the field), the thing that downloads the application
images is not part of that bootloader and there's always two images
held locally (one possibly damaged).
If that setup is used, it's quite easy to implement on the LPC2xxx:
the bootloader can be anywhere in memory. In most cases, it's just a
few lines of extra code that gets executed out of reset (i.e.
directly after the built-in bootloader).
Brendan
> This the approach that I have taken. This is for a commercial
product
> which will replace / upgrade an existing 8051 design. There are
several
> considerations, things which we have learned about our customers
over
> the years... Due to non-disclosure, I will call the LPC2214 design
> "widget".
>
> 1. NO special software is to be installed on their laptop computers
to
> update the software. We have found that once you give them
software to
> install on their computer, YOU own that computer! There are some
that
> will call you and insist that it was YOUR software which screwed
> Lotus-123 or other program.
>
> 2. We need absolute control over what software is installed onto
what
> widget. There are various optional levels of software, with
differing
> prices. The widget they purchase must be limited as to what it can
> run. IOW, if you purchase the basic unit, you cannot take software
from
> the advanced unit and install it onto the basic unit.
>
> 3. We need logging. Not only for exception crash-dumps, but they
need
> to do data captures so that we can see what is going on when things
> don't work correctly.
>
> 4. Software should be easily installed using commonly available
computer
> software / interfaces. Also, we need to be able to email the
customer
> their software, or, have them download it from our website. This
was,
> the most current version of the software is available at all times.
>
> Following that criteria, I have come up with an LPC2214 design with
an
> SD card and 512K of external RAM. The bootstrap resides in the
first
> 64K of Flash (0x00000000..0x0000FFFF) and the loader can occupy the
next
> 128K of Flash (0x00010000..0x0002FFFF). All remaining Flash (8K
> sectors) is to be used for current config data and unused sectors
left
> for future use (0x00030000..0x0003DFFF).
>
> The bootstrap contains a SerialNumber and a SiteNumber. The
bootstrap
> never will be field upgraded. All other software binaries reside
on the
> SD card and are loaded / run on demand. The loader program is like
the
> backend of the bootstrap, it is the field replaceable part of it.
The
> bootstrap code authenticates the files using an algorithm that I've
come
> up with. If the file passes the authentication, it is loaded into
RAM
> and executed.
>
> All the customer has to do is to have a camera media reader and
> software installed onto their computer. They copy the files we
give
> them onto the SD card, then insert the card into the widget. The
> bootstrap checks the current version of the loader image in Flash,
if it
> is out of date, it replaces it.
>
> An interesting point is that we do have installations with several
> hundred widgets (a Site) where the customer would need a "site wide
copy
> of software". This is what the embedded SiteNumber is for, they
order
> the widgets with for a particular Site and then one copy of the
software
> will run on all units.
>
> The software authentication scheme will only allow a binary that
has
> been encoded for either a match to the SerialNumber or SiteNumber
that
> is stored inside the widget.
>
> Loading the runtime executable binary from the SD card does take a
> couple of seconds before the system boots. It does have to
bootstrap
> itself, check the loader version, execute the loader, then the
loader
> identifies the appropriate executeable, then asks the bootstrap
code if
> that binary image is ok to run. However, once the system is up and
> running, they usually run for months and months without requiring a
reset.
>
> Regards,
> TomW
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net http://cyberiansoftware.com
http://openzipit.org
> "Windows? No thanks, I have work to do..."
> ----------------
>
Tom,
Sounds like a good approach. As you point out there are loads of
issues around in-field upgrades, not all technical.
My inclination is to keep the boot loader part (i.e. the bit that's
never changed), really, really simple:
- boot from cold
- check locations where images are held
- see which is the one to run and make sure its runable (i.e. CRC is
good)
- if necessary load it from where it is (e.g. external EEPROM or CF
card or whatever) to where it needs to be (e.g. internal Flash)
- go run it
- if not runable, revert to the backup image
The key thing with this approach is that the bootloader never gets
upgraded (in the field), the thing that downloads the application
images is not part of that bootloader and there's always two images
held locally (one possibly damaged).
If that setup is used, it's quite easy to implement on the LPC2xxx:
the bootloader can be anywhere in memory. In most cases, it's just a
few lines of extra code that gets executed out of reset (i.e.
directly after the built-in bootloader).
Brendan
Reply by ●March 15, 20072007-03-15
> > Maybe this helps on my question a little.
> Yes it did.
Aha ! Thanks Guys ! Now we're all on the same page !
Jaya Said:
> I suggest you keep the keys in a sector that you will overwrite (eg
> with the application code) and not in the sector where your loader
> resides. This allows you to change or use chained keys.
I will have to think on this one. I may be able to do this on a
later full revision since I've got a lot (but not all) of this thing
working already.
> In this case I think you are better off locating your loader in
>sector 0 and simply re-map vectors them to sector where your
>application is.
I was hoping you'd say that. It just seems easier on my brain.
> NXP has gone silent on status of CRP1/2/3 on existing parts. Based
>on what has been said so far, I foresee problems with CRP1 and CRP3
>and it pays to be extremely careful with what you put in 0x1fc.
> Furthermore, I do not recommend you erase sector 0 in the field. It
> creates a security loop hole.
I agree. This boot code shouldn't change actually, and with IAP I
don't have to clear that CRP word to write from within the part.
And to change any of it, I have to write at least 256 bytes at
a time without your Jaya bootloader.
> I dont understand what you mean by re-write? Dont you have to erase
> first? If erasing, see comment above.
Good question ! I've been looking at the documentation and I do
NOT see anything that says you have to actually erase a sector
before writing to it... Just have to "prepare" it. Does Preparing
a sector for erasing or writing just tell the flasher that it's
OK to write there ?? Or does it actually un-CRP that sector ??
It doesn't quite say that I can find what it exactly means....
Tom said:
>1. NO special software is to be installed on their laptop computers
>to update the software. We have found that once you give them
>software to install on their computer, YOU own that computer! There
>are some that will call you and insist that it was YOUR software
>which screwed >Lotus-123 or other program.
Now THAT's probably a very good lesson, Tom.
Maybe my PC/MAC code could actually be JAVA code or script
instead (eventually) since it's universal and not really an
installed program. However, so far, all I have on the PC side
is an .exe file and a code file.
Thanks guys. This is exactly the kind of stuff I was looking for.
It's new and interesting and should work well.
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > Thanks Jaya, however, the bootloader in this case is actually for
> > the customer of the product to download ~MY~ new code in the
> > field.
>
> Okay, I get a better picture now.
>
> > The code that the customer downloads to the LPC2144 is
> > encrypted before the customer receives it so the bootloader will not
> > change.
>
> I suggest you keep the keys in a sector that you will overwrite (eg
> with the application code) and not in the sector where your loader
> resides. This allows you to change or use chained keys.
>
> > Of course I will use FIQ in the main app. but I am only using
> > the IRQ handler for UARTs, etc. at present. No IRQs used for the
> > bootloader itself of course.
>
> In this case I think you are better off locating your loader in sector
> 0 and simply re-map vectors them to sector where your application is.
>
> > Another thing that came to mind is that 0x001fC (CRP) is also down
> > at the bottom and could be in my bootloader code.
>
> NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
> what has been said so far, I foresee problems with CRP1 and CRP3 and
> it pays to be extremely careful with what you put in 0x1fc.
>
> Furthermore, I do not recommend you erase sector 0 in the field. It
> creates a security loop hole.
>
> > I could
> > "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> > IRQs etc OR I could just always have a specified absolute address
> > vector there and expect it to be some particular place I suppose.
>
> I dont understand what you mean by re-write? Dont you have to erase
> first? If erasing, see comment above.
>
> I think re-mapping the vectors to the start of the application sector
> is a better way to go if you are not concerned with the cost of extra
> branch on each interrupt. I dont but I know some who will fight tooth
> and nail against this :)
>
> > I ~could~ patch the NXP bootloader too if I have to (as I know you're
> > pretty good at now) but I would rather not if I don't have to.
>
> Actually I prefer replacing the NXP Boot Loader to patching it. It is
> difficult to know what is in the Boot Loader on your particular part
> or board and what it does outside what it is supposed to do.
>
> > Right now I am looking at my two cstartup.c files for the bootloader
> > and application code and trying to decide the best way to
> > have the two programs play nicely with each other.
>
> I do not see any problems with this approach.
>
> > Sorry, I was not quite clear on my use of this bootloader.
> > Maybe this helps on my question a little.
>
> Yes it did.
>
> > Then again, maybe I'm thinking and trying too hard on a non-issue, but
> > the two pieces still have to co-exist peacefully together.
> >
> > Thanks,
> > boB
>
> Jaya
>
> Yes it did.
Aha ! Thanks Guys ! Now we're all on the same page !
Jaya Said:
> I suggest you keep the keys in a sector that you will overwrite (eg
> with the application code) and not in the sector where your loader
> resides. This allows you to change or use chained keys.
I will have to think on this one. I may be able to do this on a
later full revision since I've got a lot (but not all) of this thing
working already.
> In this case I think you are better off locating your loader in
>sector 0 and simply re-map vectors them to sector where your
>application is.
I was hoping you'd say that. It just seems easier on my brain.
> NXP has gone silent on status of CRP1/2/3 on existing parts. Based
>on what has been said so far, I foresee problems with CRP1 and CRP3
>and it pays to be extremely careful with what you put in 0x1fc.
> Furthermore, I do not recommend you erase sector 0 in the field. It
> creates a security loop hole.
I agree. This boot code shouldn't change actually, and with IAP I
don't have to clear that CRP word to write from within the part.
And to change any of it, I have to write at least 256 bytes at
a time without your Jaya bootloader.
> I dont understand what you mean by re-write? Dont you have to erase
> first? If erasing, see comment above.
Good question ! I've been looking at the documentation and I do
NOT see anything that says you have to actually erase a sector
before writing to it... Just have to "prepare" it. Does Preparing
a sector for erasing or writing just tell the flasher that it's
OK to write there ?? Or does it actually un-CRP that sector ??
It doesn't quite say that I can find what it exactly means....
Tom said:
>1. NO special software is to be installed on their laptop computers
>to update the software. We have found that once you give them
>software to install on their computer, YOU own that computer! There
>are some that will call you and insist that it was YOUR software
>which screwed >Lotus-123 or other program.
Now THAT's probably a very good lesson, Tom.
Maybe my PC/MAC code could actually be JAVA code or script
instead (eventually) since it's universal and not really an
installed program. However, so far, all I have on the PC side
is an .exe file and a code file.
Thanks guys. This is exactly the kind of stuff I was looking for.
It's new and interesting and should work well.
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > Thanks Jaya, however, the bootloader in this case is actually for
> > the customer of the product to download ~MY~ new code in the
> > field.
>
> Okay, I get a better picture now.
>
> > The code that the customer downloads to the LPC2144 is
> > encrypted before the customer receives it so the bootloader will not
> > change.
>
> I suggest you keep the keys in a sector that you will overwrite (eg
> with the application code) and not in the sector where your loader
> resides. This allows you to change or use chained keys.
>
> > Of course I will use FIQ in the main app. but I am only using
> > the IRQ handler for UARTs, etc. at present. No IRQs used for the
> > bootloader itself of course.
>
> In this case I think you are better off locating your loader in sector
> 0 and simply re-map vectors them to sector where your application is.
>
> > Another thing that came to mind is that 0x001fC (CRP) is also down
> > at the bottom and could be in my bootloader code.
>
> NXP has gone silent on status of CRP1/2/3 on existing parts. Based on
> what has been said so far, I foresee problems with CRP1 and CRP3 and
> it pays to be extremely careful with what you put in 0x1fc.
>
> Furthermore, I do not recommend you erase sector 0 in the field. It
> creates a security loop hole.
>
> > I could
> > "prepare" (unlock) sector 0 to re-write the 0x0018 etc INT VECTORS for
> > IRQs etc OR I could just always have a specified absolute address
> > vector there and expect it to be some particular place I suppose.
>
> I dont understand what you mean by re-write? Dont you have to erase
> first? If erasing, see comment above.
>
> I think re-mapping the vectors to the start of the application sector
> is a better way to go if you are not concerned with the cost of extra
> branch on each interrupt. I dont but I know some who will fight tooth
> and nail against this :)
>
> > I ~could~ patch the NXP bootloader too if I have to (as I know you're
> > pretty good at now) but I would rather not if I don't have to.
>
> Actually I prefer replacing the NXP Boot Loader to patching it. It is
> difficult to know what is in the Boot Loader on your particular part
> or board and what it does outside what it is supposed to do.
>
> > Right now I am looking at my two cstartup.c files for the bootloader
> > and application code and trying to decide the best way to
> > have the two programs play nicely with each other.
>
> I do not see any problems with this approach.
>
> > Sorry, I was not quite clear on my use of this bootloader.
> > Maybe this helps on my question a little.
>
> Yes it did.
>
> > Then again, maybe I'm thinking and trying too hard on a non-issue, but
> > the two pieces still have to co-exist peacefully together.
> >
> > Thanks,
> > boB
>
> Jaya
>
Reply by ●March 15, 20072007-03-15
Brendan Murphy wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> > This the approach that I have taken. This is for a commercial
> product
> > which will replace / upgrade an existing 8051 design. There are
> several
> > considerations, things which we have learned about our customers
> over
> > the years... Due to non-disclosure, I will call the LPC2214 design
> > "widget".
> >
> > 1. NO special software is to be installed on their laptop computers
> to
> > update the software. We have found that once you give them
> software to
> > install on their computer, YOU own that computer! There are some
> that
> > will call you and insist that it was YOUR software which screwed
> > Lotus-123 or other program.
> >
> > 2. We need absolute control over what software is installed onto
> what
> > widget. There are various optional levels of software, with
> differing
> > prices. The widget they purchase must be limited as to what it can
> > run. IOW, if you purchase the basic unit, you cannot take software
> from
> > the advanced unit and install it onto the basic unit.
> >
> > 3. We need logging. Not only for exception crash-dumps, but they
> need
> > to do data captures so that we can see what is going on when things
> > don't work correctly.
> >
> > 4. Software should be easily installed using commonly available
> computer
> > software / interfaces. Also, we need to be able to email the
> customer
> > their software, or, have them download it from our website. This
> was,
> > the most current version of the software is available at all times.
> >
> > Following that criteria, I have come up with an LPC2214 design with
> an
> > SD card and 512K of external RAM. The bootstrap resides in the
> first
> > 64K of Flash (0x00000000. .0x0000FFFF) and the loader can occupy the
> next
> > 128K of Flash (0x00010000. .0x0002FFFF) . All remaining Flash (8K
> > sectors) is to be used for current config data and unused sectors
> left
> > for future use (0x00030000. .0x0003DFFF) .
> >
> > The bootstrap contains a SerialNumber and a SiteNumber. The
> bootstrap
> > never will be field upgraded. All other software binaries reside
> on the
> > SD card and are loaded / run on demand. The loader program is like
> the
> > backend of the bootstrap, it is the field replaceable part of it.
> The
> > bootstrap code authenticates the files using an algorithm that I've
> come
> > up with. If the file passes the authentication, it is loaded into
> RAM
> > and executed.
> >
> > All the customer has to do is to have a camera media reader and
> > software installed onto their computer. They copy the files we
> give
> > them onto the SD card, then insert the card into the widget. The
> > bootstrap checks the current version of the loader image in Flash,
> if it
> > is out of date, it replaces it.
> >
> > An interesting point is that we do have installations with several
> > hundred widgets (a Site) where the customer would need a "site wide
> copy
> > of software". This is what the embedded SiteNumber is for, they
> order
> > the widgets with for a particular Site and then one copy of the
> software
> > will run on all units.
> >
> > The software authentication scheme will only allow a binary that
> has
> > been encoded for either a match to the SerialNumber or SiteNumber
> that
> > is stored inside the widget.
> >
> > Loading the runtime executable binary from the SD card does take a
> > couple of seconds before the system boots. It does have to
> bootstrap
> > itself, check the loader version, execute the loader, then the
> loader
> > identifies the appropriate executeable, then asks the bootstrap
> code if
> > that binary image is ok to run. However, once the system is up and
> > running, they usually run for months and months without requiring a
> reset.
> >
> > Regards,
> >
> >
> > TomW
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware .net
> http://cyberiansoft ware.com
> http://openzipit. org
> > "Windows? No thanks, I have work to do..."
> > ------------ --------- --------- --------- --------- ----
> > Tom,
>
> Sounds like a good approach. As you point out there are loads of
> issues around in-field upgrades, not all technical.
>
> My inclination is to keep the boot loader part (i.e. the bit that's
> never changed), really, really simple:
>
> - boot from cold
> - check locations where images are held
> - see which is the one to run and make sure its runable (i.e. CRC is
> good)
> - if necessary load it from where it is (e.g. external EEPROM or CF
> card or whatever) to where it needs to be (e.g. internal Flash)
> - go run it
> - if not runable, revert to the backup image
>
> The key thing with this approach is that the bootloader never gets
> upgraded (in the field), the thing that downloads the application
> images is not part of that bootloader and there's always two images
> held locally (one possibly damaged).
>
Correct, you have it. The "loader" is a self contained image that uses
the SWI to call down into the bootstrap to get authentication
performed. The bootstrap, loader and runtime images all have their own
stack space and RAM so they don't collide. Took me a while to realize
that if I kept the bootstrap in Supervisor mode that the stack
management was a lot simpler if all the other apps ran in System mode.
The bootstrap is very simple:
1. start system and connect external RAM.
2. update loader if not current version.
3. execute loader.
I use the SWI to invoke the authenticator within the bootstrap.
regards,
TomW
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> > This the approach that I have taken. This is for a commercial
> product
> > which will replace / upgrade an existing 8051 design. There are
> several
> > considerations, things which we have learned about our customers
> over
> > the years... Due to non-disclosure, I will call the LPC2214 design
> > "widget".
> >
> > 1. NO special software is to be installed on their laptop computers
> to
> > update the software. We have found that once you give them
> software to
> > install on their computer, YOU own that computer! There are some
> that
> > will call you and insist that it was YOUR software which screwed
> > Lotus-123 or other program.
> >
> > 2. We need absolute control over what software is installed onto
> what
> > widget. There are various optional levels of software, with
> differing
> > prices. The widget they purchase must be limited as to what it can
> > run. IOW, if you purchase the basic unit, you cannot take software
> from
> > the advanced unit and install it onto the basic unit.
> >
> > 3. We need logging. Not only for exception crash-dumps, but they
> need
> > to do data captures so that we can see what is going on when things
> > don't work correctly.
> >
> > 4. Software should be easily installed using commonly available
> computer
> > software / interfaces. Also, we need to be able to email the
> customer
> > their software, or, have them download it from our website. This
> was,
> > the most current version of the software is available at all times.
> >
> > Following that criteria, I have come up with an LPC2214 design with
> an
> > SD card and 512K of external RAM. The bootstrap resides in the
> first
> > 64K of Flash (0x00000000. .0x0000FFFF) and the loader can occupy the
> next
> > 128K of Flash (0x00010000. .0x0002FFFF) . All remaining Flash (8K
> > sectors) is to be used for current config data and unused sectors
> left
> > for future use (0x00030000. .0x0003DFFF) .
> >
> > The bootstrap contains a SerialNumber and a SiteNumber. The
> bootstrap
> > never will be field upgraded. All other software binaries reside
> on the
> > SD card and are loaded / run on demand. The loader program is like
> the
> > backend of the bootstrap, it is the field replaceable part of it.
> The
> > bootstrap code authenticates the files using an algorithm that I've
> come
> > up with. If the file passes the authentication, it is loaded into
> RAM
> > and executed.
> >
> > All the customer has to do is to have a camera media reader and
> > software installed onto their computer. They copy the files we
> give
> > them onto the SD card, then insert the card into the widget. The
> > bootstrap checks the current version of the loader image in Flash,
> if it
> > is out of date, it replaces it.
> >
> > An interesting point is that we do have installations with several
> > hundred widgets (a Site) where the customer would need a "site wide
> copy
> > of software". This is what the embedded SiteNumber is for, they
> order
> > the widgets with for a particular Site and then one copy of the
> software
> > will run on all units.
> >
> > The software authentication scheme will only allow a binary that
> has
> > been encoded for either a match to the SerialNumber or SiteNumber
> that
> > is stored inside the widget.
> >
> > Loading the runtime executable binary from the SD card does take a
> > couple of seconds before the system boots. It does have to
> bootstrap
> > itself, check the loader version, execute the loader, then the
> loader
> > identifies the appropriate executeable, then asks the bootstrap
> code if
> > that binary image is ok to run. However, once the system is up and
> > running, they usually run for months and months without requiring a
> reset.
> >
> > Regards,
> >
> >
> > TomW
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware .net
> http://cyberiansoft ware.com
> http://openzipit. org
> > "Windows? No thanks, I have work to do..."
> > ------------ --------- --------- --------- --------- ----
> > Tom,
>
> Sounds like a good approach. As you point out there are loads of
> issues around in-field upgrades, not all technical.
>
> My inclination is to keep the boot loader part (i.e. the bit that's
> never changed), really, really simple:
>
> - boot from cold
> - check locations where images are held
> - see which is the one to run and make sure its runable (i.e. CRC is
> good)
> - if necessary load it from where it is (e.g. external EEPROM or CF
> card or whatever) to where it needs to be (e.g. internal Flash)
> - go run it
> - if not runable, revert to the backup image
>
> The key thing with this approach is that the bootloader never gets
> upgraded (in the field), the thing that downloads the application
> images is not part of that bootloader and there's always two images
> held locally (one possibly damaged).
>
Correct, you have it. The "loader" is a self contained image that uses
the SWI to call down into the bootstrap to get authentication
performed. The bootstrap, loader and runtime images all have their own
stack space and RAM so they don't collide. Took me a while to realize
that if I kept the bootstrap in Supervisor mode that the stack
management was a lot simpler if all the other apps ran in System mode.
The bootstrap is very simple:
1. start system and connect external RAM.
2. update loader if not current version.
3. execute loader.
I use the SWI to invoke the authenticator within the bootstrap.
regards,
TomW
Reply by ●March 15, 20072007-03-15
--- In l..., Tom Walsh wrote:
> 1. NO special software is to be installed on their laptop computers to
> update the software. We have found that once you give them
software to
> install on their computer, YOU own that computer! There are some that
> will call you and insist that it was YOUR software which screwed
> Lotus-123 or other program.
Agreed. Absolutely! To add to this ... there are two methods people
use with subtle differences.
One is having to "install" software which in the Windows environment
gives rise to all sorts of real and perceived problems. I never do this.
The second method is to have the user run a program that does not
require any installation. This can be EXE, Java etc. Historically
this has not caused problems with customer perception.
However I personally do not accept this because of the potential of
malice, intended or unintended. Besides, just running the program can
do all the nasty things an "install" does.
> 2. We need absolute control over what software is installed onto what
> widget. There are various optional levels of software, with differing
> prices. The widget they purchase must be limited as to what it can
> run. IOW, if you purchase the basic unit, you cannot take software
from
> the advanced unit and install it onto the basic unit.
>
> 3. We need logging. Not only for exception crash-dumps, but they need
> to do data captures so that we can see what is going on when things
> don't work correctly.
>
> 4. Software should be easily installed using commonly available
computer
> software / interfaces. Also, we need to be able to email the customer
> their software, or, have them download it from our website. This was,
> the most current version of the software is available at all times.
[ digression mode ]
In the context of embedded targets, I found software upgrades using
HyperTerm or Minicom (for both Windows and Linux) to be very
convenient. It requires a level of computer literacy that does not
appear to be a problem.
I send (or they fetch) encrypted binaries as plain text Intel hex
files. This way, the operation of the upgrade in relation to Terminal
and my Intel Hex decoder can be verified as complete independently
without worrying about the contents which is handled within the appliance.
Decryption and customisation takes place within the appliance. Some
of these use public key. Others use minimal embedded crypto safe
algorithms. Almost always chained keys are used.
Locking update to serial numbers, group numbers, version numbers and
so on is supported according to client policy for the particular customer.
This decrypt and update process is logged on the terminal as it
happens immediately following the download. The logs do not need to
make sense to the customer although this helps. In some cases the
logs provide data private data (eg MIME format) the customer sends back.
All of the exchanges are through email and WWW and can be done
off-line. So there is no requirement for any computer to be on-line.
[ end digression ]
Jaya
> 1. NO special software is to be installed on their laptop computers to
> update the software. We have found that once you give them
software to
> install on their computer, YOU own that computer! There are some that
> will call you and insist that it was YOUR software which screwed
> Lotus-123 or other program.
Agreed. Absolutely! To add to this ... there are two methods people
use with subtle differences.
One is having to "install" software which in the Windows environment
gives rise to all sorts of real and perceived problems. I never do this.
The second method is to have the user run a program that does not
require any installation. This can be EXE, Java etc. Historically
this has not caused problems with customer perception.
However I personally do not accept this because of the potential of
malice, intended or unintended. Besides, just running the program can
do all the nasty things an "install" does.
> 2. We need absolute control over what software is installed onto what
> widget. There are various optional levels of software, with differing
> prices. The widget they purchase must be limited as to what it can
> run. IOW, if you purchase the basic unit, you cannot take software
from
> the advanced unit and install it onto the basic unit.
>
> 3. We need logging. Not only for exception crash-dumps, but they need
> to do data captures so that we can see what is going on when things
> don't work correctly.
>
> 4. Software should be easily installed using commonly available
computer
> software / interfaces. Also, we need to be able to email the customer
> their software, or, have them download it from our website. This was,
> the most current version of the software is available at all times.
[ digression mode ]
In the context of embedded targets, I found software upgrades using
HyperTerm or Minicom (for both Windows and Linux) to be very
convenient. It requires a level of computer literacy that does not
appear to be a problem.
I send (or they fetch) encrypted binaries as plain text Intel hex
files. This way, the operation of the upgrade in relation to Terminal
and my Intel Hex decoder can be verified as complete independently
without worrying about the contents which is handled within the appliance.
Decryption and customisation takes place within the appliance. Some
of these use public key. Others use minimal embedded crypto safe
algorithms. Almost always chained keys are used.
Locking update to serial numbers, group numbers, version numbers and
so on is supported according to client policy for the particular customer.
This decrypt and update process is logged on the terminal as it
happens immediately following the download. The logs do not need to
make sense to the customer although this helps. In some cases the
logs provide data private data (eg MIME format) the customer sends back.
All of the exchanges are through email and WWW and can be done
off-line. So there is no requirement for any computer to be on-line.
[ end digression ]
Jaya
