Re: [ECOS] Variants and subvariants

[Nick Garnett <nickg at ecoscentric dot com>]

"Doyle, Patrick" <WPD@dtccom.com> writes:

> Hi folks!
> 
> The current design of the eCos HAL moves from Architecture, to Variant, to
> Platform.  The OMAP device from Texas Instrumentshas an ARM9 core, a pile o'
> peripherals (UARTS, USB client & host, camera interface, keyboard interface,
> etc...) and a DSP core all in one device.  When I created the HAL for the
> Innovator board, I simply created it as a platform that used the ARM9
> variant of the ARM Architecture.
> 
> Now that Mike Beymer has ported eCos to the Minno board and I am starting to
> port it to a custom board, I want to minimize the amount of code that simply
> gets cut and pasted from one platform to the next.  Right now, I can think
> of two options and I am seeking opinions and guidance on what is the best
> solution:
> 
> 1) Create an OMAP variant of the ARM.  Basically, cut and paste the current
> ARM9 variant as an OMAP variant and modify the Innovator and Minno ports to
> use that variant instead of the ARM9 variant.  Then as we go forward, we can
> migrate all of the common code into the variant tree and leave the platform
> trees very sparse in what they need to customize.  This fits in with the way
> other ports have been done, but it requires that I do something that I hate
> -- cut and paste code.  (I don't mind copying and modifying code, but simply
> copying from one place to another simply doubles the amount of work that
> needs to be done when maintaining the code).
> 
> 2) Create an OMAP subvariant of the ARM9.  Since the concept of subvariants
> doesn't exist, this would require more up front work.  Probably I would
> create it as if it were a platform, and have it include "omap_plf*.h" files
> that define 'OMAP_PLF' type macros.
> 
> Ultimately, I would like to be able to build a very generic RedBoot that was
> guaranteed to run on any board that had an OMAP on it (by virtue of using
> only the internal RAM on the OMAP, and talking to the outside world via
> internal UART) that would simplify initial "bring-up" of an OMAP based
> board.  The more code I can place in the OMAP HAL, the less I have to place
> in the platform HAL, provided that there are enough hooks to allow the
> platform HAL to override the (sub)variant.
> 
> It seems to me that the PowerPC devices based on the 603 core could benefit
> from a subvariant strategy as well.
> 
> What are folks opinions?
> 

Your second option is the correct way to go. This sort of thing has
been done in a few places before.

The PC HAL is divided into the i386 architecture HAL, a generic i386
variant HAL, the PC platform HAL and a PC Motherboard HAL. The PCMB
HAL defines devices that are found in all standard PCs: serial
devices, the PICs, PITs etc. The idea here was to try and separate
those things that might be found on an embedded PC-like board and
from those things that are only present on a desktop PC. This is very
similar to what you want to do -- separate the on-chip stuff from the
on-board stuff.

QUICC based PowerPC devices use a quicc HAL package to include common
on-chip stuff.

The vrc4373 and vrc4375 HALs both defer to an additional vrc437x HAL
for the actual work and definitions.


My suggestion is to keep the ARM9 HAL as it is and add an omap HAL
containing all the OMAP stuff. You can then add various platform HALs,
whose plf_*.h files include equivalent omap_*.h files. One of these
platforms HALs can be a generic/minimal OMAP HAL that allows you to
manufacture a generic RedBoot.

Take a look at the way in which we allow platforms to override
variant and architecture definitions in the MIPS and i386 HALs. This
sort of thing doesn't happen as much in the ARM HAL so you may not
have seen it.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss