Re: [ECOS] Creating a drop in replacement for the pcmb package

[Jonathan Larmour <jlarmour at redhat dot com>]

Ian Campbell wrote:
> 
> Thanks for the reply (and apologies for my delay in replying, I have
> been away)
> 
> On Fri, 2001-09-21 at 16:09, Nick Garnett wrote:
> > Ian Campbell <icampbell@arcom.co.uk> writes:
> >
> > > Hi,
> > >
> > > I would like to create a drop in replacement for the pcmb package to
> > > support one of our products and would like some advice on a couple of
> > > matters.
> > >
> > > My first problem is that the pcmb header files are hard coded in several
> > > places in the pc package.
> >
> > The idea of the PCMB package is that it collects together all the
> > common PC device and HAL support for both standard PCs and PC-like
> > embedded boards. If your board is so unlike a PC that you do not need
> > to use the PCMB package, then you should not really use the PC
> > platform package either, but make a new one of your own.
> 
> This is probably my fault for not being very clear, but the board is
> based around a 386ex chip and is almost exactly like a PC. The changes
> which were required are things such as memory layout, boot process, no
> PCI or IDE, a slightly different RTC period, no A20 gating and a hard
> coded memory size. Apart from memory layout and booting these seem to be
> the sort of things that can be configured via the CDL (or at least
> should/could be configurable, even if the option isn't implemented yet).
> 
> The reason I was attempting to create a package which replaced pcmb was
> that I had the impression that the PC package contained support for PC
> and PC-like embedded systems in general while the PCMB package abstracts
> away the variations in the different PC-like and embedded PC boards
> (which is why I thought that romboot and the memory files really
> belonged in pcmb). I'm still quite confused as to the distinction and
> what goes where, perhaps I have misunderstood something?

The idea is more that the PCMB package collects together those parts common
to PC-like boards. It doesn't itself provide an abstraction - instead it
provides those facilities which the underlying platform HAL (the PC HAL)
would use.

In your case, by the sound of it, you would still use the pcmb HAL _with_ a
new merlin platform HAL. That merlin platform HAL would do the equivalent
of the PC HAL (i.e. hal/i386/pc) for your merlin board.

But all the abstractions may not be at the right level just yet, e.g. as
you commented, the romboot.S code which is certainly not common to all
architectures. Perhaps more stuff in the PC HAL should be in the PCMB HAL
and vice versa. Perhaps more of the stuff in the PCMB HAL should be
configurable (or turn off-able) using CDL options.
 
> Is it possible to create a template target of some sort which simply
> uses the PC/PCMB packages and enforces (or at least sets up the correct
> initial values for) the options required for a particular board (ie so
> that ecosconfig new merlin <xxx> will force the correct options for the
> merlin variant? IDE=0, PCI=0 etc). It seems that packages can't override
> or place constraints on options in other packages (I get errors about
> redefining the option name)

You certainly can do that. You would set values for options in e.g. the
PCMB or arch HALs just by using the appropriate "requires" statements using
CDL.

> but maybe there is a way to create a target
> template? What I would really like is to be able to have a merlin.epk
> which people can install without applying patches or anything to the
> main tree and then use 'ecosconfig new merlin xxx' to generate a working
> project.

Sure. Although right now the abstractions may not be quite right to support
this. We need to make sure the main tree is in a state where this _can_
work. Even better though, would be to get your board support into our main
tree though. In either case you should probably consider looking at the
various legal technicalities for contributing to the main tree:
http://sources.redhat.com/ecos/faq.html#contrib_assign
 
> I'm cagey about creating a new platform HAL alongside the PC one, since
> the vast majority of the code would be unchanged and I would very much
> like to pickup bug fixes etc made to the PC package, simply creating a
> new package and copying the files over (with minor changes) makes this
> quite hard. In an ideal world I think I would also like to use the PCMB
> package, since the majority of the code which made it into the merlin
> package from here was also unchanged.

Keep the PCMB package certainly, and if you think "PC-like" boards have
things that are currently only in the PC HAL, we should consider moving
them to the PCMB package instead. But you'll need to come up with concrete
suggestions.

> Surely it should be possible to support fairly minor variants to a
> platform without having to define a whole new platform with 99% copied
> code.

That's exactly what the existence of the pcmb support HAL is trying to
avoid.
 
> This message has been checked for all viruses by MessageLabs Virus Control Centre.

I'm always amused by these lines.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine