Lpc2000

I suggest a formal request be made to Philips with regard to their 
bootloader for the following minor enhancements.

None of these suggestions are strictly necessasry. The suggestions 
would simply make working with the LPC slightly easier. The 
suggestions are to enable a programmable flash space and interrupt 
remap location modelled on the ATMEL AVR system while retaining their 
current bootloader (which I have never had a problem with) which 
would of course carry out the required security processing before 
handing over control. The current IAP features could still be called.

For example the CRP flash memory location could have bits read 
similar to ATMEL fuse bits to decide 
1. size of a special 'boot sector' at top of flash (AVRs typically 
allow four fixed sizes)
2. whether interrupt vectors and so startup remaps to the start of 
the special boot sector.

It would also be healthy to allow MEMMAP have another value to 
indcate another remapped location for interrupt vectors.

There is clearly a lot of motivation for independent bootloaders. It 
would make my programming tasks slightly easier. It could also solve 
another problem by allowing independent assignment of the 'boot load' 
pin, instead of pin 0.14 (which interferes with DCD input is used and 
can be solved currently with the use of a hardware single logic OR 
gate).

John Heenan

Hi John,

I think you have a good point. If we can agree how the bootloader
should be improved, and it remains compatible with existing
hardware*, perhaps they will find the time to do it.

One point though: I think the MEMMAP is done in hardware,
location 0xE01FC040 on lpc2292. So I don't see how a
bootloader rewrite can add an extra option here.
(It makes no sense to tell the bootloader to select the
RAM vectors since RAM could contain rubbish).

*this constraint could be a serious limitation. But Philips will
not want to break products made to their existing data sheets.

Regards,
Danish
--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:

>
> I suggest a formal request be made to Philips with regard to their 
> bootloader for the following minor enhancements.
> 
> None of these suggestions are strictly necessasry. The suggestions 
> would simply make working with the LPC slightly easier. The 
> suggestions are to enable a programmable flash space and interrupt 
> remap location modelled on the ATMEL AVR system while retaining their 
> current bootloader (which I have never had a problem with) which 
> would of course carry out the required security processing before 
> handing over control. The current IAP features could still be called.
> 
> For example the CRP flash memory location could have bits read 
> similar to ATMEL fuse bits to decide 
> 1. size of a special 'boot sector' at top of flash (AVRs typically 
> allow four fixed sizes)
> 2. whether interrupt vectors and so startup remaps to the start of 
> the special boot sector.
> 
> It would also be healthy to allow MEMMAP have another value to 
> indcate another remapped location for interrupt vectors.
> 
> There is clearly a lot of motivation for independent bootloaders. It 
> would make my programming tasks slightly easier. It could also solve 
> another problem by allowing independent assignment of the 'boot load' 
> pin, instead of pin 0.14 (which interferes with DCD input is used and 
> can be solved currently with the use of a hardware single logic OR 
> gate).
> 
> John Heenan
>

Even without MEMMAP modifcation we could still use interrupt vectors!

You are right to clarify the MEMMAP point, although I had meant 
modifying whatever is behind MEMMAP at the register action level 
also. While memory remapping is implemented with pure hardware, the 
hardware required is minimal.

Without an additional MEMMAP option it is still possible to use 
interrupt vectors as long as no interrupt handlers within the 
bootloader are required after main application start. Bootloader 
interrupt instructions and their load addresses can be copied to RAM 
before the bootloader enables interrupts with MEMAP set for RAM 
interrupts. Of course these RAM locations would be overwritten after 
main program start. 

In fact even the above issues can be worked around by saving the 
start of RAM on the stack, as well as the contents of VIC registers, 
if a rentry into a bootloader function wanted to use interrupts.

The attraction of a bootloader code only modifcation approach is that 
we could upgrade our existing parts.

Think of it: USB bootloaders on our existing LPC214x parts that we 
write ourselves!  Bootloader pin on whatever port we want or none at 
all! Telling whiners to go away and produce something useful!

John Heenan


--- In lpc2000@yahoogroups.com, "Danish Ali" <danish@...> wrote:
>
> Hi John,
> 
> I think you have a good point. If we can agree how the bootloader
> should be improved, and it remains compatible with existing
> hardware*, perhaps they will find the time to do it.
> 
> One point though: I think the MEMMAP is done in hardware,
> location 0xE01FC040 on lpc2292. So I don't see how a
> bootloader rewrite can add an extra option here.
> (It makes no sense to tell the bootloader to select the
> RAM vectors since RAM could contain rubbish).
> 
> *this constraint could be a serious limitation. But Philips will
> not want to break products made to their existing data sheets.
> 
> Regards,
> Danish
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> >
> > I suggest a formal request be made to Philips with regard to 
their 
> > bootloader for the following minor enhancements.
> > 
> > None of these suggestions are strictly necessasry. The 
suggestions 
> > would simply make working with the LPC slightly easier. The 
> > suggestions are to enable a programmable flash space and 
interrupt 
> > remap location modelled on the ATMEL AVR system while retaining 
their 
> > current bootloader (which I have never had a problem with) which 
> > would of course carry out the required security processing before 
> > handing over control. The current IAP features could still be 
called.
> > 
> > For example the CRP flash memory location could have bits read 
> > similar to ATMEL fuse bits to decide 
> > 1. size of a special 'boot sector' at top of flash (AVRs 
typically 
> > allow four fixed sizes)
> > 2. whether interrupt vectors and so startup remaps to the start 
of 
> > the special boot sector.
> > 
> > It would also be healthy to allow MEMMAP have another value to 
> > indcate another remapped location for interrupt vectors.
> > 
> > There is clearly a lot of motivation for independent bootloaders. 
It 
> > would make my programming tasks slightly easier. It could also 
solve 
> > another problem by allowing independent assignment of the 'boot 
load' 
> > pin, instead of pin 0.14 (which interferes with DCD input is used 
and 
> > can be solved currently with the use of a hardware single logic 
OR 

> > gate).
> > 
> > John Heenan
> >
>

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:

> For example the CRP flash memory location could have bits read 
> similar to ATMEL fuse bits to decide 
> 1. size of a special 'boot sector' at top of flash (AVRs typically 
> allow four fixed sizes)
> 2. whether interrupt vectors and so startup remaps to the start of 
> the special boot sector.

I can see why Philips may not be in a position to acceed to this request:

1/  This requires hardware change to flash blocking.

2/  The boot sectors (I have seen) appear pretty full.

Unless they radically change their boot loader structure to something
like SILL (which is 2600 bytes), they are not likely to be able to get
their boot loader down in size without removing a lot of (extraneous?)
functionality.

Jaya

PS:  I am not saying the request is unreasonable.  I just cannot see
how it can be met if LPC boot loader structure is to be retained.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> 
> > For example the CRP flash memory location could have bits read 
> > similar to ATMEL fuse bits to decide 
> > 1. size of a special 'boot sector' at top of flash (AVRs 
typically 
> > allow four fixed sizes)
> > 2. whether interrupt vectors and so startup remaps to the start 
of 
> > the special boot sector.
> 
> I can see why Philips may not be in a position to acceed to this 
request:
> 
> 1/  This requires hardware change to flash blocking.

No. I guess you don't really get the point. I am not proposing 
replacing the exising boot loader, just providing an option to 'opt 
out' and continue booting elsewhere. The option to opt out and and 
where to opt out decided according to bit choices at the CRP flash 
location and before pin 0.14 is read. It would also be nice if we had 
a documented 'opt in' again facility which bypassed their own pin 
0.14 test.


> 2/  The boot sectors (I have seen) appear pretty full.

See above. I am not suggesting it is used for any custoim boot loaders

> PS:  I am not saying the request is unreasonable.  I just cannot see
> how it can be met if LPC boot loader structure is to be retained.


For someone who is so full of praise for ATMEL your knowledge of 
their well known techniques is very weak. There also appears to be an 
industry wide consensus that unless you buy a lot of ATMEL product 
you will get zero support. The fact that as a non production oriented 
participant that you got any support from Philips is praiseworthy. If 
you want support without buying prodcut try moving to PICs, Microchip 
get consistent praise for their high level of support.

We know what is normal and we accept it. You don't.

With regard to REMAP issue, I have already indicated no changes are 
necessary and so exising parts could have their bootloaders upgraded.

Additionally if Philips did not want all their parts to ship with 
bootloader opt out options, they could provide us with a patched 
version which could be massaged into production bootloading.

John Heenan

John,

ATMEL fuse bits relating to boot block size are for purposes of
determining the size of the block at the top of memory that is locked
down as boot block, and which is used to determine address to branch
to upon taking a reset.

I am the author of SAIL, the boot loader for ATMEL AVR series of
processors  and can find more information about this at

  http://www.cse.unsw.edu/~jayas/esdk/sail.html

It would be ludicrous suggest one could write a boot loader for AVRs
without intimate knowledge of ATMEL boot sector options and related
fuse bits.

Your (what appears to be a revised) enhancement request requires the
boot sector code to branch and then back.

As one who has been providing boot loaders for a variety of targets. I
know for a fact that boot loader designers frown on such a request. 
The biggest problem is state preservation when the boot loader is
re-entered from user code.

A more sensible approach would be to have the methods implemented in
the boot loader itself and let the user select like in the case of CRP.

Me thinks getting Philips to patch boot loaders for your production is
quite queer.  Why patch when you can replace it.

Jaya


--- In lpc2000@...m, "John Heenan" <l10@...> wrote:

> No. I guess you don't really get the point. I am not proposing 
> replacing the exising boot loader, just providing an option to 'opt 
> out' and continue booting elsewhere. The option to opt out and and 
> where to opt out decided according to bit choices at the CRP flash 
> location and before pin 0.14 is read. It would also be nice if we had 
> a documented 'opt in' again facility which bypassed their own pin 
> 0.14 test.
> 
> 
> > 2/  The boot sectors (I have seen) appear pretty full.
> 
> See above. I am not suggesting it is used for any custoim boot loaders
> 
> > PS:  I am not saying the request is unreasonable.  I just cannot see
> > how it can be met if LPC boot loader structure is to be retained.
> 
> 
> For someone who is so full of praise for ATMEL your knowledge of 
> their well known techniques is very weak. There also appears to be an 
> industry wide consensus that unless you buy a lot of ATMEL product 
> you will get zero support. The fact that as a non production oriented 
> participant that you got any support from Philips is praiseworthy. If 
> you want support without buying prodcut try moving to PICs, Microchip 
> get consistent praise for their high level of support.
> 
> We know what is normal and we accept it. You don't.
> 
> With regard to REMAP issue, I have already indicated no changes are 
> necessary and so exising parts could have their bootloaders upgraded.
> 
> Additionally if Philips did not want all their parts to ship with 
> bootloader opt out options, they could provide us with a patched 
> version which could be massaged into production bootloading.
> 
> John Heenan

You have descended into rambling, confusion and irrelevancy again. I 
will post a specific copy of a draft to Philips on the newsgroup 
under a different subject title.

John Heenan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> John,
> 
> ATMEL fuse bits relating to boot block size are for purposes of
> determining the size of the block at the top of memory that is 
locked
> down as boot block, and which is used to determine address to branch
> to upon taking a reset.
> 
> I am the author of SAIL, the boot loader for ATMEL AVR series of
> processors  and can find more information about this at
> 
>   http://www.cse.unsw.edu/~jayas/esdk/sail.html
> 
> It would be ludicrous suggest one could write a boot loader for AVRs
> without intimate knowledge of ATMEL boot sector options and related
> fuse bits.
> 
> Your (what appears to be a revised) enhancement request requires the
> boot sector code to branch and then back.
> 
> As one who has been providing boot loaders for a variety of 
targets. I
> know for a fact that boot loader designers frown on such a request. 
> The biggest problem is state preservation when the boot loader is
> re-entered from user code.
> 
> A more sensible approach would be to have the methods implemented in
> the boot loader itself and let the user select like in the case of 
CRP.
> 
> Me thinks getting Philips to patch boot loaders for your production 
is
> quite queer.  Why patch when you can replace it.
> 
> Jaya
> 
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> > No. I guess you don't really get the point. I am not proposing 
> > replacing the exising boot loader, just providing an option 
to 'opt 
> > out' and continue booting elsewhere. The option to opt out and 
and 
> > where to opt out decided according to bit choices at the CRP 
flash 
> > location and before pin 0.14 is read. It would also be nice if we 
had 
> > a documented 'opt in' again facility which bypassed their own pin 
> > 0.14 test.
> > 
> > 
> > > 2/  The boot sectors (I have seen) appear pretty full.
> > 
> > See above. I am not suggesting it is used for any custoim boot 
loaders
> > 
> > > PS:  I am not saying the request is unreasonable.  I just 
cannot see
> > > how it can be met if LPC boot loader structure is to be 
retained.
> > 
> > 
> > For someone who is so full of praise for ATMEL your knowledge of 
> > their well known techniques is very weak. There also appears to 
be an 
> > industry wide consensus that unless you buy a lot of ATMEL 
product 
> > you will get zero support. The fact that as a non production 
oriented 
> > participant that you got any support from Philips is 
praiseworthy. If 
> > you want support without buying prodcut try moving to PICs, 
Microchip 
> > get consistent praise for their high level of support.
> > 
> > We know what is normal and we accept it. You don't.
> > 
> > With regard to REMAP issue, I have already indicated no changes 
are 
> > necessary and so exising parts could have their bootloaders 
upgraded.

> > 
> > Additionally if Philips did not want all their parts to ship with 
> > bootloader opt out options, they could provide us with a patched 
> > version which could be massaged into production bootloading.
> > 
> > John Heenan
>