Re: [Amforth-devel] Protected Amforth

[Matthias T. <mt...@we...>]

Am 26.05.2010 17:48, schrieb an...@ki...:
> Guys
> 
> Been doing some thinking on bits of the conversations going off recently 
> about protecting the Amforth Core from accidental overwrite. (Useful in 
> some cases, particularly teaching scenarios and new starters). Thought I 
> should throw them into the ring for discussion.
> 
> Creating protection is as I understand it a three step process.
> 
> 1. Rearrange the core words (or at least everything needed to compile 
> and load the rest. etc into the boot-loader area as if it were a large 
> boot-loader.
> 
> 2. Tweak the interrupts and reset vectors (maybe the reset ISR too) and 
> code to deal with the new location and prepare for a boot-loader start 
> (That is actually the Amforth core system).

My ideas go into the same direction. the amforth system in the
bootloader section can be seen either as the "real" system or as a
BIOS like utility that only checks the setup and than hand over
the execution to the "real" code, which may be another amforth
system or something completly different.

> This pseudo boot loader does 
> in fact boot but doesn't pass off execution to anything unless turnkey 
> is setup to do so. Turnkey or a rewritable template turnkey would have 
> to live in the normal flash area so it could be rewritten if necessary.

turnkey is a deferred word, and as such it is easy to give it
new code to execute.

> 3. Set the boot vector option in the fuses to make it boot from the top 
> of flash (boot loader boot) rather than the bottom (Usual or non boot 
> loader boot).

thats a technical need.

>
> Activating protection is a case of setting the appropriate fuses etc to 
> lock down the boot-loader/upper flash area.

The undestroyable amforth does not need to be protected with fuses (at
least not per se). It is from the fact that the bootload area cannot be
overwritten with anything that runs on the same controller. Just like a
bootloader cannot overwrite itself. Using some fuses may be an add-on,
but I doubt that it is that useful.

> Notes/thoughts.
> 
> 
> C. Issues I can see with this is that not all devices have as big a boot 
> loader area. (Don't quote me on this, I could be wrong and would have to 
> go through all the data sheets to be sure)

thats right. Only the bigger controller types have the 8K+ bootloader
section. On smaller systems, sorry. No way.

> 
> D. It may be worth considering creating a word like "FactoryReset" or 
> something that lives in the core/Boot-loader section and after 
> confirmation wipes/purges/re-initializes the non core/Boot-loader 
> section. Restoring the board/chip to a clean state. (Good for classroom 
> scenarios and new starters)

you are right, thats absolutly neccessairy. It need to reset the
essential EEPROM cells as well.

> E. Making the ability to clone the current state of the device ie a 
> "clone" word, part of the protected core/boot-loader would be optimal. 

I dont see the clone word in the bootloader section. Cloning a
malfunctioning system image is useless. The cloning may clone
the bootloader section only, the remaining flash may be transferred
separatly. And putting the clone word into the normal flash area gives
much more code space to make it a comfortable tool.

> There are arguments for not doing this and making it optional. 
> Personally I favor the idea that it becomes an intrinsic part of all 
> Amforth implementations. (Today forthduino, tomorrow the world, "Go 
> forth and multiply" is a mangled biblical quote that springs to mind)

It may be part of the distribution but never ever part of the
default configuration.

> 
> F. Given all of the above we could be struggling in 8k of boot-loader 
> unless something or other could me done with the current core set to 
> make space.

There is still room for optimization, no doubt. But 8K is not that
little space.

Matthias