This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RedBoot porting


>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I've decided to try to get RedBoot running on our custom
Grant> platform to see if it would make a suitable basis for a boot
Grant> loader.  After reading through the RedBoot porting docs, I'm a
Grant> bit confused.

Jifl already addressed your questions, I think, but I just want to add
something.

Grant> There are several statements in hal-calling-if.html from which
Grant> I infer that eCos is headed towards dependence on RedBoot (or a
Grant> similar ROM monitor) for various services and that in the
Grant> future eCos apps will not be stand-alone as they are now:

I'll be rewriting that part of the docs. We've just had a good and
enlightening discussion on this very subject. 

In short, the present implementation is too rigid - it requires either
the ROM monitor or the RAM application to provide all of the services
in the virtual vector table.

That's silly for a lot of reasons - and I'll be making some changes
shortly to address that, so the RAM application can easily provide a
subset of the services, for instance the IO routines, while still
relying on other services provided by the ROM monitor such as reset.

The virtual vector table is a method to detach caller from service so
that these can live in different address ranges (e.g., caller is in
RAM, service is implemented in ROM). This is required for
RedBoot. However, virtual vectors do not require RedBoot.

Basically, we want the code to consistently use virtual vectors (even
if both caller and service is in the same address range) so we always
use the same code / mechanism - and thereby ensure it is always
properly tested (i.e., the rare stubs/RedBoot builds do not use
special mechanism that can easily get broken and remain broken for a
long time without anyone finding out).

Um, it's basically a story about our heroes Mechanism and Policy which
I managed to muddle into one big ol' nightmare. I'm on a quest to turn
it into a nice fairy tale with a happy ending and all that. I'll be
sure to post something on the list as I make progress.

Thanks,
Jesper

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]