Re: [ECOS] RedBoot porting

[Jonathan Larmour <jlarmour@redhat.com>]

Grant Edwards wrote:
> 
> I've decided to try to get RedBoot running on our custom
> platform to see if it would make a suitable basis for a boot
> loader.  After reading through the RedBoot porting docs, I'm a
> bit confused.
> 
> Is the virtual vector table used to make calls in both
> directions (user-app calling ROM and ROM calling user-app)?

It can be. Most uses are for the app calling into ROM. But the point is
that it also allows a way for the app to override the virtual vector table
entry to make it point into itself, if need be. e.g. to override the choice
of diagnostic port. If the app changes the diagnostic port, the ROM monitor
should also then use it, if the monitor comes into play again.
 
> Once an eCos app is running, are there one or two virtual
> vector tables?

One.

> If I do not want RedBoot to provide any services to user
> applications, do I still need to implement virtual vector
> support in my HAL?  [Having application code depend on services
> available in the boot loader is way too high-risk, since there
> isn't going to be any way to upgrade the boot loader in the
> field.]

No HAL _has_ to use virtual vectors. But then you won't be able to use
things like ethernet debugging, ctrl-c support, etc. unless you want to
support them yourself the way they used to happen.

But what you could easily do is make your app override all the virtual
vectors it cares about itself if need be.
 
> There are several statements in hal-calling-if.html from which
> I infer that eCos is headed towards dependence on RedBoot (or a
> similar ROM monitor) for various services and that in the
> future eCos apps will not be stand-alone as they are now:
> 
>   "The use of this service is controlled by the option
>    CYGSEM_HAL_VIRTUAL_VECTOR_DIAG which is disabled per default
>    on most older platforms (thus preserving backwards
>    compatibility with older stubs). On newer ports, this option
>    should always be set."
> 
>   "Note: On old ports the hardwired HAL_DIAG_INIT,
>    HAL_DIAG_WRITE_CHAR and HAL_DIAG_READ_CHAR implementations
>    will also contain code to O-packetize the output for GDB.
>    This should not be adopted for new ports! On new ports the
>    ROM monitor is guaranteed to provide the necessary mangling
>    via the vector table."
> 
> I don't know that I can guarantee that a ROM monitor will be
> available for use by my eCos applications. If eCos must be
> guaranteed a ROM monitor, this could be a serious problem for
> me.

Virtual vector support is included in GDB stub ROMs in eCos too - it's not
specific to Redboot. And virtual vectors only really apply to debugging
activities - ctrl-c, source level debugging, breakpoints, diagnostic
output, etc.

It should also not stop you blowing your app into ROM if that's what you'd
prefer. But I'm not entirely sure about what you actually _want_ to go into
ROM.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine