Lpc2000

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