Re: [Amforth-devel] Protected Amforth

[<an...@ki...>]

Mathias

I have just been doing a comparison of a hand full of Atmegas and their 
boot loader/protected flash sizes. Principaly aimed at forthduino as 
they are mostly the types used for the most common of the arduino boards 
plus the sanguino (greatly favored by the maker-bot community within the 
reprap project)

1280, 168, 328, 644

The largest common size really is 1K.

So I guess this ends up being as you suggest, bootloader/bios territory, 
plus as many of the primitives as can be got into the 1k.

Did someone get the 168 to actualy work or do I need to put some time 
into this again ??

Just ordering up a duemilanove (328) for testing. I have 168's and 644's 
left over from reprap work and 16mhz crystals, so can bread board those.

I will rename the forthduino asm file to be mega and add in definitions 
for Duemilanove, Deicimilla and Sanguino. A bit like the Polin 
boards/definitions. That should pretty much be the full set of major 
Arduino boards then. I can't see the point of doing any more than those.

Cheers

Andy Kirby





On 26/05/10 18:50, Matthias Trute wrote:
> 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
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>