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

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

[Ian Campbell]

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. 

I have attempted to work some magic in the CDL files by making the name
of the header files a set of cdl_options but I had to jump through some
hoops and it seems rather ugly to me.

Perhaps the correct path would be to define a cdl_interface something
like CYGHWR_HAL_I386_PC_MOTHERBOARD and require it from the pc package
and provide it in the pcmb and merlin packages, then rename the merlin
header files to have the same names as their pcmb counterparts (and use
define_header to rename the config header).

Maybe someone has a better idea, or can tell me what the preferred
solution is, to give maximum chance of acceptance for whatever patches I
need to pass upstream?

My second query is to do with romboot.S which currently resides in
hal/i386/arch. Unfortunately the merlin boards do not have exactly the
same boot sequence, although they are fairly similar. I don't think I
can override which files are compiled in another module with my own, so
I think that either romboot.S really belongs in pcmb or else some level
of abstraction could be added, for example factoring out some
functionality into macros such as hal_i386_setup_gdt,
hal_i386_setup_mem, etc in pcmb/merlin packages. I would be happy to do
the work necessary to factor these things out.

My third question is about the memory layout files (pc package
include/pkgconf/mlt_i386_pc_rom.{h,ldi}). Again I need to override
these. They claim to be generated, but I gather this is by the config
tool rather than at build time from cdl options. Since these are header
files, can I simply include my own copies in the merlin package and
arrange for these to go into the build tree in preference to the ones in
the pc package? or otherwise influence the values of
CYGHWR_MEMORY_LAYOUT_{LDI,H} from the merlin cdl file? Perhaps these
files are another candidate for moving to pcmb?

Sorry for the long mail, but I thought it would be better to go through
it all in one go.

Thanks in advance, especially for any advice with regard to what would
be most acceptable to upstream.

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.

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

[Nick Garnett]

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.

> Maybe someone has a better idea, or can tell me what the preferred
> solution is, to give maximum chance of acceptance for whatever patches I
> need to pass upstream?

Best bet is a totally new platform package. That would make it almost
totally orthogonal to the current packages, and would give it a much
greater chance of finding its way into the mainline sources.

> 
> My second query is to do with romboot.S which currently resides in
> hal/i386/arch. Unfortunately the merlin boards do not have exactly the
> same boot sequence, although they are fairly similar. I don't think I
> can override which files are compiled in another module with my own, so
> I think that either romboot.S really belongs in pcmb or else some level
> of abstraction could be added, for example factoring out some
> functionality into macros such as hal_i386_setup_gdt,
> hal_i386_setup_mem, etc in pcmb/merlin packages. I would be happy to do
> the work necessary to factor these things out.

You can always supply your own equivalent of romboot.S
(merlinboot.S ?). The CYGBLD_BUILD_REDBOOT_BIN_ROM option in the
architecture CDL file should really move to the PC packages CDL, and
your platform package should then have its own version to build the
ROM image your board needs. 

> 
> My third question is about the memory layout files (pc package
> include/pkgconf/mlt_i386_pc_rom.{h,ldi}). Again I need to override
> these. They claim to be generated, but I gather this is by the config
> tool rather than at build time from cdl options. Since these are header
> files, can I simply include my own copies in the merlin package and
> arrange for these to go into the build tree in preference to the ones in
> the pc package? or otherwise influence the values of
> CYGHWR_MEMORY_LAYOUT_{LDI,H} from the merlin cdl file? Perhaps these
> files are another candidate for moving to pcmb?
>

Again, if you make your own platform HAL, then you can redefine these
as you need.


Executive summary: Make a platform HAL of your own, start by just copying
the PC package and renaming everything. Then add any device support
you need to that package. If there's any stuff you need from the PCMB
package, just copy it over.

Hope this helps.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

[Ian Campbell]

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.

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

[Jonathan Larmour]

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

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

[Ian Campbell]

On Fri, 2001-09-28 at 18:52, Jonathan Larmour wrote:
> 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.

Aaah, I see. I got it backwards. Happily, once I started thinking this
way round things were much simpler ;-)

Most of the abstraction seems to be in place already and the attached
'pc-dependency-fixes.patch' includes two tiny little patches which
remove the two dependencies from pcmb and arch on the pc package which I
tripped over. There might be others but they haven't bitten me as yet.
There's even ChangeLog entries this time..

The other attached patch (memsize-fixes.patch - which I am posting more
for comment than inclusion since it may not be the correct approach) is
to allow the memory size to be hardcoded. The display attributes in the
CDL have FIXMEs because I am not entirely sure how to describe what they
are. I'm also not convinced by my choice of option names.

I would like to be able to change the value of CYGNUM_HAL_RTC_PERIOD in
hal_i386_pcmb.cdl, however it is defined using a 'calculated' statement.
Is there any problem with making this into a 'default_value'?

My last change is to move romboot.S + associated CDL into the pc package
but I've not gotten round to it yet. I'll post a patch when I have.

[snip]

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

This works just great, thank you!

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

This is something which I will need to discuss with my boss at some
point. Hopefully the attached patches are trivial enough not to warrant
it (He said with his fingers crossed...)

> > This message has been checked for all viruses by MessageLabs Virus Control Centre.
> 
> I'm always amused by these lines.

Our mail server just started adding them recently, I wonder how many
it's caught so far...

Thanks for your help,
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.
Index: packages/hal/i386/arch/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/arch/current/ChangeLog,v
retrieving revision 1.24
diff -u -r1.24 ChangeLog
--- packages/hal/i386/arch/current/ChangeLog	2001/09/12 00:59:23	1.24
+++ packages/hal/i386/arch/current/ChangeLog	2001/10/01 15:08:45
@@ -1,3 +1,9 @@
+2001-10-01  Ian Campbell  <icampbell@arcom.co.uk>
+
+	* src/vectors.S: include CYGBLD_HAL_PLATFORM_H rather than
+	<pkgconf/hal_i386_pc.h>
+	
+
 2001-09-05  Jonathan Larmour  <jlarmour@redhat.com>
 
 	* src/vectors.S (__default_interrupt_vsr): Adjust saved stack pointer
Index: packages/hal/i386/pcmb/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/pcmb/current/ChangeLog,v
retrieving revision 1.5
diff -u -r1.5 ChangeLog
--- packages/hal/i386/pcmb/current/ChangeLog	2001/09/12 00:59:23	1.5
+++ packages/hal/i386/pcmb/current/ChangeLog	2001/10/01 15:08:56
@@ -1,3 +1,9 @@
+2001-10-01  Ian Campbell  <icampbell@arcom.co.uk>
+
+	* include/pcmb_io.h: Include CYGBLD_HAL_PLATFORM_H rather than
+	<pkgconf/hal_i386_pc.h>. Also include <pkgconf/system.h> so the
+	define is available.
+
 2001-08-22  Nick Garnett  <nickg@redhat.com>
 
 	* src/pcmb_misc.c: Added spinlock to clock read operation.

Index: packages/hal/i386//arch/current/src/vectors.S
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/arch/current/src/vectors.S,v
retrieving revision 1.8
diff -u -r1.8 vectors.S
--- packages/hal/i386/arch/current/src/vectors.S	2001/09/12 00:59:23	1.8
+++ packages/hal/i386/arch/current/src/vectors.S	2001/10/01 14:33:19
@@ -47,7 +47,7 @@
 
 #include <pkgconf/system.h>
 #include <pkgconf/hal.h>
-#include <pkgconf/hal_i386_pc.h>
+#include CYGBLD_HAL_PLATFORM_H
 
 #ifdef CYGPKG_KERNEL
 #include <pkgconf/kernel.h>
Index: packages/hal/i386//pcmb/current/include/pcmb_io.h
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/pcmb/current/include/pcmb_io.h,v
retrieving revision 1.3
diff -u -r1.3 pcmb_io.h
--- packages/hal/i386/pcmb/current/include/pcmb_io.h	2001/09/12 00:59:23	1.3
+++ packages/hal/i386/pcmb/current/include/pcmb_io.h	2001/10/01 14:33:19
@@ -45,7 +45,8 @@
 //
 //==========================================================================
 
-#include <pkgconf/hal_i386_pc.h>
+#include <pkgconf/system.h>
+#include CYGBLD_HAL_PLATFORM_H
 
 #include <cyg/hal/pcmb_io.h>
 

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

[Jonathan Larmour]

Ian Campbell wrote:
> 
> On Fri, 2001-09-28 at 18:52, Jonathan Larmour wrote:
> > 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.
> 
> Aaah, I see. I got it backwards. Happily, once I started thinking this
> way round things were much simpler ;-)

Phew :-).

> Most of the abstraction seems to be in place already and the attached
> 'pc-dependency-fixes.patch' includes two tiny little patches which
> remove the two dependencies from pcmb and arch on the pc package which I
> tripped over. There might be others but they haven't bitten me as yet.
> There's even ChangeLog entries this time..

Cool! I've applied this.
 
> The other attached patch (memsize-fixes.patch - which I am posting more
> for comment than inclusion since it may not be the correct approach) is
> to allow the memory size to be hardcoded. The display attributes in the
> CDL have FIXMEs because I am not entirely sure how to describe what they
> are. I'm also not convinced by my choice of option names.

That's very good for a CDL newbie though! I think CYGNUM_HAL_MEMSIZE would
be better as CYGPKG_HAL_I386_PCMB_MEMSIZE. 

I suppose there's one bit of rationale for the pcmb package I'm not 100%
about, which is that a few of the things it does are tied to the existence
of a BIOS, which I would have thought is rather PC specific. I strongly
suspect the idea really is to make common those bits that may be common
between many PC-like bits of hardware, but for specific cases, we would
need to make the pcmb package configurable (as you've done).  Hopefully
Nick (who is on holiday right now) might give more insight, but for now,
work on the assumption that this is the case :-). 

> I would like to be able to change the value of CYGNUM_HAL_RTC_PERIOD in
> hal_i386_pcmb.cdl, however it is defined using a 'calculated' statement.
> Is there any problem with making this into a 'default_value'?

Yeah, for now; although I'd be tempted just to move it down into the
platform. I take it the merlin doesn't use an 8253 compatible PIT then?
 
> My last change is to move romboot.S + associated CDL into the pc package
> but I've not gotten round to it yet. I'll post a patch when I have.

> > 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
> 
> This is something which I will need to discuss with my boss at some
> point. Hopefully the attached patches are trivial enough not to warrant
> it (He said with his fingers crossed...)

Yes, these ones are.

> > > This message has been checked for all viruses by MessageLabs Virus Control Centre.
> >
> > I'm always amused by these lines.
> 
> Our mail server just started adding them recently, I wonder how many
> it's caught so far...

Except obviously any new virii it doesn't recognise would also have this
line appended :-).
 
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

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

[Ian Campbell]

On Tue, 2001-10-02 at 21:50, Jonathan Larmour wrote:
> Ian Campbell wrote:
> > The other attached patch (memsize-fixes.patch - which I am posting more
> > for comment than inclusion since it may not be the correct approach) is
> > to allow the memory size to be hardcoded. The display attributes in the
> > CDL have FIXMEs because I am not entirely sure how to describe what they
> > are. I'm also not convinced by my choice of option names.
> 
> That's very good for a CDL newbie though! I think CYGNUM_HAL_MEMSIZE would
> be better as CYGPKG_HAL_I386_PCMB_MEMSIZE. 

I've attached a new version of the patch with this new name, and what I
hope are more correct descriptions. Patch also includes the RTC_PERIOD
change below (they were v. close in the source, which makes splitting
the two patches a pain..)

> 
> > I would like to be able to change the value of CYGNUM_HAL_RTC_PERIOD in
> > hal_i386_pcmb.cdl, however it is defined using a 'calculated' statement.
> > Is there any problem with making this into a 'default_value'?
> 
> Yeah, for now; although I'd be tempted just to move it down into the
> platform. I take it the merlin doesn't use an 8253 compatible PIT then?

As I understand it, the PIT is 8253 compatible, but the crystal is not
PC standard frequency. The 386EX has a pre-scale register which scales
the clock input for the PIT. The upshot is that PIT0 needs a
non-standard count to generate the 18.2Hz clock.

Cheers,
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.
Index: packages/hal/i386/pcmb/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/pcmb/current/ChangeLog,v
retrieving revision 1.7
diff -u -r1.7 ChangeLog
--- packages/hal/i386/pcmb/current/ChangeLog	2001/10/05 15:31:49	1.7
+++ packages/hal/i386/pcmb/current/ChangeLog	2001/10/08 12:47:28
@@ -1,3 +1,12 @@
+2001-10-08  Ian Campbell  <icampbell@arcom.co.uk>
+
+	* cdl/hal_i386_pcmb.cdl: Add cdl_options for
+	CYGPKG_HAL_I386_PCMB_MEMSIZE to allow configuration of how memory
+	is detected. Change CYGNUM_HAL_RTC_PERIOD to use default_value
+	rather than calculated (so it can be overridden in the platform).
+	* src/pcmb_misc.c: Implement CYGPKG_HAL_I386_PCMB_MEMSIZE
+	configuration options.
+	
 2001-10-01  Ian Campbell  <icampbell@arcom.co.uk>
 
 	* include/pcmb_io.h: Include CYGBLD_HAL_PLATFORM_H rather than
Index: packages/hal//i386/pcmb/current/cdl/hal_i386_pcmb.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/pcmb/current/cdl/hal_i386_pcmb.cdl,v
retrieving revision 1.3
diff -u -r1.3 hal_i386_pcmb.cdl
--- packages/hal/i386/pcmb/current/cdl/hal_i386_pcmb.cdl	2001/09/12 00:59:23	1.3
+++ packages/hal/i386/pcmb/current/cdl/hal_i386_pcmb.cdl	2001/10/08 12:36:54
@@ -83,11 +83,36 @@
         cdl_option CYGNUM_HAL_RTC_PERIOD {
             display       "Real-time clock period"
             flavor        data
-           calculated     11932
+	    default_value 11932
         }
     }
 
-    
+    cdl_component CYGPKG_HAL_I386_PCMB_MEMSIZE {
+	display       "How to discover the size of available RAM."
+	flavor        data
+	legal_values  {"BIOS" "HARDCODE"}
+	default_value {"BIOS"}
+	description   "It is possible for the HAL to discover the 
+	               size of RAM In several ways. Currently this
+                       can be done by querying the BIOS or by 
+                       hardcoding the values into the executable."
+
+	cdl_option CYGPKG_HAL_I386_PCMB_MEMSIZE_BASE {
+	    display       "Amount of Base RAM available."
+	    flavor        data
+	    default_value 0x000F0000
+	    active_if     { CYGPKG_HAL_I386_PCMB_MEMSIZE == "HARDCODE" }
+	}
+
+	cdl_option CYGPKG_HAL_I386_PCMB_MEMSIZE_EXTENDED {
+	    display       "Amount of Extended RAM available."
+	    flavor        data
+	    default_value 0x00100000
+	    active_if     { CYGPKG_HAL_I386_PCMB_MEMSIZE == "HARDCODE" }
+	}
+
+    }
+
     cdl_interface CYGINT_HAL_I386_PCMB_SCREEN_SUPPORT {
 	display       "Enable PC screen support"
 	compile       pcmb_screen.c
Index: packages/hal//i386/pcmb/current/src/pcmb_misc.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/i386/pcmb/current/src/pcmb_misc.c,v
retrieving revision 1.3
diff -u -r1.3 pcmb_misc.c
--- packages/hal/i386/pcmb/current/src/pcmb_misc.c	2001/09/12 00:59:23	1.3
+++ packages/hal/i386/pcmb/current/src/pcmb_misc.c	2001/10/08 12:36:54
@@ -70,6 +70,12 @@
 
 void hal_pcmb_init(void)
 {
+#ifdef CYG_HAL_MEMSIZE_HARDCODE
+    cyg_hal_pcmb_memsize_base = CYGPKG_HAL_I386_PCMB_MEMSIZE_BASE;
+    cyg_hal_pcmb_memsize_extended = CYGPKG_HAL_I386_PCMB_MEMSIZE_EXTENDED;
+#endif
+
+#ifdef CYG_HAL_MEMSIZE_BIOS
     cyg_uint8 lo,hi;
     
     HAL_READ_CMOS( 0x15, lo );
@@ -89,7 +95,7 @@
 #endif
 
     cyg_hal_pcmb_memsize_extended = ((hi<<8)+lo)*1024;
-
+#endif
 }
 
 /*------------------------------------------------------------------------*/