Re: [ECOS] Variants and subvariants

[Mark Salter <msalter at redhat dot com>]

Also, the hal/arm/xscale hierarchy divides support into core,
cpu, and platform parts. 

--Mark

>>>>> Doyle, Patrick writes:

> 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



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