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

[Ian Campbell <icampbell at arcom dot co dot uk>]

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? 

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) 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.

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.

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.

Regards,
Ian.
 
-- 
Ian Campbell
Design Engineer

Arcom Control Systems Ltd,
Clifton Road,
Cambridge CB1 7EA
United Kingdom

Tel: +44 (0)1223 411200 ext. 3204
E-Mail: icampbell@arcom.co.uk
Web: http://www.arcomcontrols.com


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

This message has been checked for all viruses by MessageLabs Virus Control Centre. 

Company registered in England No. 1608562.
Registered Office: Unit 8, Clifton Road, Cambridge, CB1 7EA, United Kingdom, Tel: 01223 411200.