Forums

Bootloader enhancment: draft of a possible sensible formal request to Philips

Started by John Heenan May 2, 2006
Below is a draft of a possible sensible formal request we could make
to Philips with regard to bootloader enhancement. It is simple and
practical.

If Philips agrees we can use interrupts by copying interrupt
instructions and constant addresses to the start of RAM and setting
MEMMAP to RAM mode. We can still use IAP features of the bootloader.

There is no sense in replacing the bootloader if you accept it does
its job as is: why chuck IAP when it works great and can be used to
advantage in an enhancement, such as with USB enhanced bootloading?

John Heenan
Dear Philips

This is a formal request with regard to the bootloader of the LPC2xxx
series of microcontrollers.

We are requesting a small enhancement to the bootloader whose end
functionality is to
- give us an option to bypass the pin 0.14 test by the bootloader
when there has been an external reset
- perform our own bootload tasks taking advantage of IAP if we want to
- rejoin the bootloader informing the bootloader what we now want it
to do or what we have done

For existing LPC2xxx parts with flash based bootloaders we are
requesting you make an upgrade to the bootloader available to us.

For the bootloader to decide to bypass four items of information are
necessary
1. Whether to bypass
2. Where to bypass to (in supervisor mode expecting ARM instructions)
3. Where we need to return to if we want to return ('BX LR' is a good
option)
4. What should be specified in a register on return

On return perhaps R0 could have a value to indicate one of the above

- conduct a normal pin 0.14 test
- bypass pin 0.14 test as if test is true
- bypass pin 0.14 test as if test was false
- we have used IAP functions to conduct our own bootloading: please
restart the bootloader as if there was an external reset

Currently address 0x1FC is used to store the CRP value. If this value
is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is
enabled.

If CRP is not enabled then we request that if the CRP value is 0x4321-
--- or 0x----4321 where ---- represents four hexadecimal digits then
these hexadecimal digits be used to decide a multiple of 4kB to jump
to. For example if the CRP value is 0x4321 001E or 0x001E 4321 then
this is interpreted to call address 0x1E (decimal 30) times 4kB 0x0007 B000. This is the start of sector 25 on the LPC2148 and is the
start of the last 8kB of flash on the LPC2148.

Given that no flash sector can be less than 4kB for erase purposes
(they are either 4kB or 32kB) then there is no advantage in
specifying a finer resolution than 4kB as a multiple for call purposes

This request has the support of the following members of the LPC2000
newsgroup on http://groups.yahoo.com/group/lpc2000/

John Heenan
Add your name if you support such a request!

An Engineer's Guide to the LPC2100 Series

John,

Interesting idea. Although simple in theory, I think you're actually
asking quite a lot of Philips. Just think of all the documentation
that would have to be updated to reflect the change. This all takes
time, effort and cost that would have to be justified (ongoing costs
as well in terms of updated training, support materials etc.)

Can you give some specific examples of what features and functions
could be implemented if the loader were changed as you suggest? I
think it would help both others and Philips to support such a move
if there was more information on what could be achieved by such a
change.

Brendan

--- In l..., "John Heenan" wrote:
>
> Below is a draft of a possible sensible formal request we could
make
> to Philips with regard to bootloader enhancement. It is simple and
> practical.
>
> If Philips agrees we can use interrupts by copying interrupt
> instructions and constant addresses to the start of RAM and
setting
> MEMMAP to RAM mode. We can still use IAP features of the
bootloader.
>
> There is no sense in replacing the bootloader if you accept it
does
> its job as is: why chuck IAP when it works great and can be used
to
> advantage in an enhancement, such as with USB enhanced bootloading?
>
> John Heenan
> Dear Philips
>
> This is a formal request with regard to the bootloader of the
LPC2xxx
> series of microcontrollers.
>
> We are requesting a small enhancement to the bootloader whose end
> functionality is to
> - give us an option to bypass the pin 0.14 test by the bootloader
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we
want to
> - rejoin the bootloader informing the bootloader what we now want
it
> to do or what we have done
>
> For existing LPC2xxx parts with flash based bootloaders we are
> requesting you make an upgrade to the bootloader available to us.
>
> For the bootloader to decide to bypass four items of information
are
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM
instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a
good
> option)
> 4. What should be specified in a register on return
>
> On return perhaps R0 could have a value to indicate one of the
above
>
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading:
please
> restart the bootloader as if there was an external reset
>
> Currently address 0x1FC is used to store the CRP value. If this
value
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is
> enabled.
>
> If CRP is not enabled then we request that if the CRP value is
0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits
then
> these hexadecimal digits be used to decide a multiple of 4kB to
jump
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321
then
> this is interpreted to call address 0x1E (decimal 30) times 4kB > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is
the
> start of the last 8kB of flash on the LPC2148.
>
> Given that no flash sector can be less than 4kB for erase purposes
> (they are either 4kB or 32kB) then there is no advantage in
> specifying a finer resolution than 4kB as a multiple for call
purposes
>
> This request has the support of the following members of the
LPC2000
> newsgroup on http://groups.yahoo.com/group/lpc2000/
>
> John Heenan
> Add your name if you support such a request!
>
Brendan

Number of issues with scheme proposed so far.

1. For parts with an enhanced bootloader, if Philips declared CRP
address 0x1FC to be a reserved address that may only contain 0x8765
4321, 0x1234 8765 or default flash erase value of 0xFFFF FFFF and
that anything else may lead to unpredictable results then Philips
does not have to document anything further, no matter what bootloader
enhancements are made. This would give time to iron out issues,
prepare documentation and even withdraw the enhancement if so decided.

2. For a bootloader upgrade to existing LPC2xxx parts the same
declaration would apply

3. Even if it was ensured the range of values in address 0x1FC all
resolved to undefined ARM and Thumb instructions for the purpose of
bootloader enhancement this is not good enough because it is
legitimate to use address 0x1FC to contain any data value.

4. In a sense Philips has already sacrificed address 0x1FC. Given
that there are two legitimate data values that cannot be placed at
address 0x1FC if CRP is not to be enabled (0x8765 4321 and 0x4321
8765).

4. The single biggest problem is the potential to lock an LPC2xxx
part up permanently without an erase mechanism. However Philips would
be covered by the simple statement 0x1FC is a reserved address that
can only contain three values and that anything else may lead to
unpredictable results including locking up the part.

5. The single biggest issue is the pin 0.14/DCD issue that currently
requires a hardware solution. This can be solved in software by the
proposal. The proposal also allow pin 0.14 functionality to be
relocated.

6. With regard to other enhancements enabled by the proposal (such as
independent bootloading using IAP and interrupts) none of them
require the proposal. Bootloading through USB or any other data
source can be done right now. The proposal simply makes programming
and management slightly easier.

Basically it is just a proposal that would provide extra flexibility.
I don't need it as I have no use for the DCD pin. I am not going to
make it a cause and don't really want to spend time on making it a
cause! There are marketing advantages. ATMEL gets a lot of mileage
form its AVR bootload sectors with some extra hardware issues thrown
in!

In summary
- The proposed bootloader enhancements are easy to implement, add
minor programming convenience and can relocate the bootload pin.
- Philips does not need to provide any further documentation with
such an enhanced bootloader other than stating address 0x1FC is
reserved and can only contain three values.
- Philips has already sacrificed address 0x1FC anyway from some
legitimate data values.
- There are marketing advantages.

John Heenan
--- In l..., "brendanmurphy37"
wrote:
> John,
>
> Interesting idea. Although simple in theory, I think you're
actually
> asking quite a lot of Philips. Just think of all the documentation
> that would have to be updated to reflect the change. This all takes
> time, effort and cost that would have to be justified (ongoing
costs
> as well in terms of updated training, support materials etc.)
>
> Can you give some specific examples of what features and functions
> could be implemented if the loader were changed as you suggest? I
> think it would help both others and Philips to support such a move
> if there was more information on what could be achieved by such a
> change.
>
> Brendan
>
> --- In l..., "John Heenan" wrote:
> >
> > Below is a draft of a possible sensible formal request we could
> make
> > to Philips with regard to bootloader enhancement. It is simple
and
> > practical.
> >
> > If Philips agrees we can use interrupts by copying interrupt
> > instructions and constant addresses to the start of RAM and
> setting
> > MEMMAP to RAM mode. We can still use IAP features of the
> bootloader.
> >
> > There is no sense in replacing the bootloader if you accept it
> does
> > its job as is: why chuck IAP when it works great and can be used
> to
> > advantage in an enhancement, such as with USB enhanced
bootloading?
> >
> > John Heenan
> >
> >
> > Dear Philips
> >
> > This is a formal request with regard to the bootloader of the
> LPC2xxx
> > series of microcontrollers.
> >
> > We are requesting a small enhancement to the bootloader whose end
> > functionality is to
> > - give us an option to bypass the pin 0.14 test by the bootloader
> > when there has been an external reset
> > - perform our own bootload tasks taking advantage of IAP if we
> want to
> > - rejoin the bootloader informing the bootloader what we now want
> it
> > to do or what we have done
> >
> > For existing LPC2xxx parts with flash based bootloaders we are
> > requesting you make an upgrade to the bootloader available to us.
> >
> > For the bootloader to decide to bypass four items of information
> are
> > necessary
> > 1. Whether to bypass
> > 2. Where to bypass to (in supervisor mode expecting ARM
> instructions)
> > 3. Where we need to return to if we want to return ('BX LR' is a
> good
> > option)
> > 4. What should be specified in a register on return
> >
> > On return perhaps R0 could have a value to indicate one of the
> above
> >
> > - conduct a normal pin 0.14 test
> > - bypass pin 0.14 test as if test is true
> > - bypass pin 0.14 test as if test was false
> > - we have used IAP functions to conduct our own bootloading:
> please
> > restart the bootloader as if there was an external reset
> >
> > Currently address 0x1FC is used to store the CRP value. If this
> value
> > is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )
is
> > enabled.
> >
> > If CRP is not enabled then we request that if the CRP value is
> 0x4321-
> > --- or 0x----4321 where ---- represents four hexadecimal digits
> then
> > these hexadecimal digits be used to decide a multiple of 4kB to
> jump
> > to. For example if the CRP value is 0x4321 001E or 0x001E 4321
> then
> > this is interpreted to call address 0x1E (decimal 30) times 4kB > > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is
> the
> > start of the last 8kB of flash on the LPC2148.
> >
> > Given that no flash sector can be less than 4kB for erase
purposes
> > (they are either 4kB or 32kB) then there is no advantage in
> > specifying a finer resolution than 4kB as a multiple for call
> purposes
> >
> > This request has the support of the following members of the
> LPC2000
> > newsgroup on http://groups.yahoo.com/group/lpc2000/
> >
> > John Heenan
> > Add your name if you support such a request!
>
John,

I normally ask that one includes in the requirement only what one
wants, not how one wants it done. If you do this, then you are not
likely to introduce undesirable side effects.

You want alternate boot loader intercepts like I said I wanted in the
free boot loader proposal. I can see that the way you want it done
adds another method to how the LPC part can be locked out by software.

As it stands, the LPC can be locked out by software if the boot loader
is corrupted in way what it disables JTAG and then spin loops.

Consider your enhanced bootloader in which the the user enables CRP
*and* boot loader intercept, the intercept call does not return or
unconditionally returns "bypass as if P0.14 is false".

The part is now locked out by software and is as good as a OTP with
the application code as loaded and without boot loader functionality.

I would be surprised if Philips would implement your method and
introduce yet another software method by which users could lockout
their parts.

There are other issues but I have to explain these the context of what
the current boot loader on-chip does on startup, and why it is not a
good idea to branch to user code then back in the context of CRP.

Regards,

Jaya

--- In l..., "John Heenan" wrote:
>
> Below is a draft of a possible sensible formal request we could make
> to Philips with regard to bootloader enhancement. It is simple and
> practical.
>
> If Philips agrees we can use interrupts by copying interrupt
> instructions and constant addresses to the start of RAM and setting
> MEMMAP to RAM mode. We can still use IAP features of the bootloader.
>
> There is no sense in replacing the bootloader if you accept it does
> its job as is: why chuck IAP when it works great and can be used to
> advantage in an enhancement, such as with USB enhanced bootloading?
>
> John Heenan
> Dear Philips
>
> This is a formal request with regard to the bootloader of the LPC2xxx
> series of microcontrollers.
>
> We are requesting a small enhancement to the bootloader whose end
> functionality is to
> - give us an option to bypass the pin 0.14 test by the bootloader
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we want to
> - rejoin the bootloader informing the bootloader what we now want it
> to do or what we have done
>
> For existing LPC2xxx parts with flash based bootloaders we are
> requesting you make an upgrade to the bootloader available to us.
>
> For the bootloader to decide to bypass four items of information are
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a good
> option)
> 4. What should be specified in a register on return
>
> On return perhaps R0 could have a value to indicate one of the above
>
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading: please
> restart the bootloader as if there was an external reset
>
> Currently address 0x1FC is used to store the CRP value. If this value
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is
> enabled.
>
> If CRP is not enabled then we request that if the CRP value is 0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits then
> these hexadecimal digits be used to decide a multiple of 4kB to jump
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321 then
> this is interpreted to call address 0x1E (decimal 30) times 4kB > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is the
> start of the last 8kB of flash on the LPC2148.
>
> Given that no flash sector can be less than 4kB for erase purposes
> (they are either 4kB or 32kB) then there is no advantage in
> specifying a finer resolution than 4kB as a multiple for call purposes
>
> This request has the support of the following members of the LPC2000
> newsgroup on http://groups.yahoo.com/group/lpc2000/
>
> John Heenan
> Add your name if you support such a request!

Count me out!
John,

just wanted to acknowledge we got the message and are looking into
it. Will provide feedback once it is through internal evaluation.

Philips Apps
--- In l..., "John Heenan" wrote:
>
> Below is a draft of a possible sensible formal request we could
make
> to Philips with regard to bootloader enhancement. It is simple and
> practical.
>
> If Philips agrees we can use interrupts by copying interrupt
> instructions and constant addresses to the start of RAM and
setting
> MEMMAP to RAM mode. We can still use IAP features of the
bootloader.
>
> There is no sense in replacing the bootloader if you accept it
does
> its job as is: why chuck IAP when it works great and can be used
to
> advantage in an enhancement, such as with USB enhanced bootloading?
>
> John Heenan
> Dear Philips
>
> This is a formal request with regard to the bootloader of the
LPC2xxx
> series of microcontrollers.
>
> We are requesting a small enhancement to the bootloader whose end
> functionality is to
> - give us an option to bypass the pin 0.14 test by the bootloader
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we
want to
> - rejoin the bootloader informing the bootloader what we now want
it
> to do or what we have done
>
> For existing LPC2xxx parts with flash based bootloaders we are
> requesting you make an upgrade to the bootloader available to us.
>
> For the bootloader to decide to bypass four items of information
are
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM
instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a
good
> option)
> 4. What should be specified in a register on return
>
> On return perhaps R0 could have a value to indicate one of the
above
>
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading:
please
> restart the bootloader as if there was an external reset
>
> Currently address 0x1FC is used to store the CRP value. If this
value
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is
> enabled.
>
> If CRP is not enabled then we request that if the CRP value is
0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits
then
> these hexadecimal digits be used to decide a multiple of 4kB to
jump
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321
then
> this is interpreted to call address 0x1E (decimal 30) times 4kB > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is
the
> start of the last 8kB of flash on the LPC2148.
>
> Given that no flash sector can be less than 4kB for erase purposes
> (they are either 4kB or 32kB) then there is no advantage in
> specifying a finer resolution than 4kB as a multiple for call
purposes
>
> This request has the support of the following members of the
LPC2000
> newsgroup on http://groups.yahoo.com/group/lpc2000/
>
> John Heenan
> Add your name if you support such a request!
>
As a total newbie, maybe it's not my place, but wouldn't it be more
desirable if Philips were to just Open-source the bootloader code? I
mean, business issues aside, it sounds like we could make these
modifications ourselves, if the code were made available.

--- In l..., "jayasooriah" wrote:
>
> John,
>
> I normally ask that one includes in the requirement only what one
> wants, not how one wants it done. If you do this, then you are not
> likely to introduce undesirable side effects.
>
> You want alternate boot loader intercepts like I said I wanted in the
> free boot loader proposal. I can see that the way you want it done
> adds another method to how the LPC part can be locked out by software.
>
> As it stands, the LPC can be locked out by software if the boot loader
> is corrupted in way what it disables JTAG and then spin loops.
>
> Consider your enhanced bootloader in which the the user enables CRP
> *and* boot loader intercept, the intercept call does not return or
> unconditionally returns "bypass as if P0.14 is false".
>
> The part is now locked out by software and is as good as a OTP with
> the application code as loaded and without boot loader functionality.
>
> I would be surprised if Philips would implement your method and
> introduce yet another software method by which users could lockout
> their parts.
>
> There are other issues but I have to explain these the context of what
> the current boot loader on-chip does on startup, and why it is not a
> good idea to branch to user code then back in the context of CRP.
>
> Regards,
>
> Jaya
>
> --- In l..., "John Heenan" wrote:
> >
> > Below is a draft of a possible sensible formal request we could make
> > to Philips with regard to bootloader enhancement. It is simple and
> > practical.
> >
> > If Philips agrees we can use interrupts by copying interrupt
> > instructions and constant addresses to the start of RAM and setting
> > MEMMAP to RAM mode. We can still use IAP features of the bootloader.
> >
> > There is no sense in replacing the bootloader if you accept it does
> > its job as is: why chuck IAP when it works great and can be used to
> > advantage in an enhancement, such as with USB enhanced bootloading?
> >
> > John Heenan
> >
> >
> > Dear Philips
> >
> > This is a formal request with regard to the bootloader of the LPC2xxx
> > series of microcontrollers.
> >
> > We are requesting a small enhancement to the bootloader whose end
> > functionality is to
> > - give us an option to bypass the pin 0.14 test by the bootloader
> > when there has been an external reset
> > - perform our own bootload tasks taking advantage of IAP if we want to
> > - rejoin the bootloader informing the bootloader what we now want it
> > to do or what we have done
> >
> > For existing LPC2xxx parts with flash based bootloaders we are
> > requesting you make an upgrade to the bootloader available to us.
> >
> > For the bootloader to decide to bypass four items of information are
> > necessary
> > 1. Whether to bypass
> > 2. Where to bypass to (in supervisor mode expecting ARM instructions)
> > 3. Where we need to return to if we want to return ('BX LR' is a good
> > option)
> > 4. What should be specified in a register on return
> >
> > On return perhaps R0 could have a value to indicate one of the above
> >
> > - conduct a normal pin 0.14 test
> > - bypass pin 0.14 test as if test is true
> > - bypass pin 0.14 test as if test was false
> > - we have used IAP functions to conduct our own bootloading: please
> > restart the bootloader as if there was an external reset
> >
> > Currently address 0x1FC is used to store the CRP value. If this value
> > is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is
> > enabled.
> >
> > If CRP is not enabled then we request that if the CRP value is 0x4321-
> > --- or 0x----4321 where ---- represents four hexadecimal digits then
> > these hexadecimal digits be used to decide a multiple of 4kB to jump
> > to. For example if the CRP value is 0x4321 001E or 0x001E 4321 then
> > this is interpreted to call address 0x1E (decimal 30) times 4kB > > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is the
> > start of the last 8kB of flash on the LPC2148.
> >
> > Given that no flash sector can be less than 4kB for erase purposes
> > (they are either 4kB or 32kB) then there is no advantage in
> > specifying a finer resolution than 4kB as a multiple for call purposes
> >
> > This request has the support of the following members of the LPC2000
> > newsgroup on http://groups.yahoo.com/group/lpc2000/
> >
> > John Heenan
> > Add your name if you support such a request!
>
> Count me out!
>

--- In l..., "philippe.desrosiers"
wrote:
>
> As a total newbie, maybe it's not my place, but wouldn't it be more
> desirable if Philips were to just Open-source the bootloader code? I
> mean, business issues aside, it sounds like we could make these
> modifications ourselves, if the code were made available.

You are absolutely right. As one who supports custom configurable
boot loaders for LPC out in the field, I think so too.

I like to take this opportunity to make a pre-annoucement and I have
changed the topic to reflect this.

[Brendan, I like to make this very special requiest to you to spare a
thought hold back your attacks at least until I make my release
annoucement. It will addressss some of your (unique) concerns that
you have been so forcefully been defending in this forum.]

When I get back in a week, I shall be releasing up my EnkOS boot
loader for LPC that is end user customizable. Initially it will be a
binary only release (like Philips LPC boot loader) but it can be
loaded and customized by the end user using standard off-the-shelf
tools and utilities available on any platform, not just Windows.

Open source is possible if Philps agrees not to contest my opening up
the source on grounds that it may infringe on Philips desire to keep
boot loader internals a secret.

As indicated, once you have my my boot loader on your part, you no
longer need Philips ISP Flash Loader Utility. It also does away with
the need for Martin Maurer's open source utility. Sorry Martin :)

While I commend Martin's efforts in supporting his utility especially
for the Linux community, I prefer to make the LPC a product that does
not require on-going support of yet another custom download utility.

We already have too many of these on the different platforms that we
could use.

Bye for now.

Jaya