This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Variants and subvariants
- From: "Doyle, Patrick" <WPD at dtccom dot com>
- To: "'Nick Garnett'" <nickg at ecoscentric dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 5 Jun 2003 08:48:18 -0400
- Subject: RE: [ECOS] Variants and subvariants
Great... That sounds exactly like what I was looking for. Thanks for the
pointer.
--wpd
> -----Original Message-----
> From: Nick Garnett [mailto:nickg@ecoscentric.com]
> Sent: Thursday, June 05, 2003 6:19 AM
> To: Doyle, Patrick
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Variants and subvariants
>
>
> "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