[En-Nut-Discussion] Nut/OS 4.8

[Thiago A. Corrêa]

On Mon, Mar 2, 2009 at 9:04 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Thiago A. Corrêa wrote:
>> A boot folder would be nice, we could arrange things better. I
>> personaly would call it bootloader instead though.
>
> The boot directory exists already.

Hmmm my bad, I don't use bootmon very often. I guess I only used it once.

>> Then we could move appmon and eboot there as well, and make it more
>> evident what they are.
>
> Moving directories with CVS is painful, so I'd recommend to leave it to
> the new version control.

Sure, no problem.

>> I remember when I was a newbie with ethernut I
>> wasn't even aware there were bootloaders there for quite a while.
>
> Since long time I planned to move them to a new project, because the
> existing ones do not need Nut/OS and may be helpful for other projects
> as well. However, Ole always had been an advocate of Nut/OS based boot
> loaders, which is somewhat contrary.
>

That would be nice. Even if we kept them independent, at least making
them share code would be a good thing.
appload for instance have some code size optimizations that can't be
found on eboot.

>> It would be nice if we made them a little more production aware as
>> well, add optional crypto or something. Should make things easier for
>> new comers and reduce the necessity of forking the bootloaders into
>> private projetcs. It doesn't have to be super strong, and we could
>> make the keys configurable :)
>> Just a thought anyway.
>
> Such boot loaders exist, but the companies that created them or paid for
> their development are not enthusiastic in publishing that work.
>

Yeah, I know. But that shouldn't prevent us from doing that right? :)
I wouldn't have a problem with publishing the bootloader I used,
provided that the keys would be configurable. Also, there is no
guarantee that I'm using vanilla published and not modified published,
therefore we could have obscurity and easy of use/avaiability.

If we did bootloaders that depend on ethernut libraries, we could also
introduce a generic aes framework, with both c implemented aes (can be
found everywhere) and MCU specific, for those MCUs that has hardware
for AES calculation.

Well, nothing critical or anything, I'm just shooting ideas :)

Kind Regards,
   Thiago A. Correa