RE: [ECOS] Variants and subvariants

["Doyle, Patrick" <WPD at dtccom dot com>]

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