From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: Grant Edwards Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 00:08:00 -0000 Message-id: References: <20010105115220.A2486@visi.com> X-SW-Source: 2001-01/msg00060.html >>>>> "Grant" == Grant Edwards 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