[ECOS] hal/i386/pc prerelease.

[ECOS] hal/i386/pc prerelease.

[Patrick O'Grady]

Hi, all--

Just wanted to let you all know that I've posted a *very early* but actually
functional version of a hal for running eCos on a standard '386 or better PC.
Here's a quick rundown:

1) How do I get it?
Try ftp://sourceware.cygnus.com/pub/ecos/contrib/hal/i386/i386-pc-0.1.tgz .

2) Um, you say *very early release*.  What exactly do you mean?
It means that there is a basic version of the GDB stub which boots from a 3.5"
floppy; after the stub is booted, then applications can be downloaded through
the target PC's COM1 port.  So far I have verified ISR and DSR support, basic
debugging capability (breakpoints work great) and multithreading.  I'm using
FreeBSD for my development environment; it is very likely that this port will
break the linux synthetic target, and this port is guranteed *not* to work
straight out of the box for people using W/NT for development.  Now that I
think about it, it's probably not even going to work under Linux without a tweek
or two.

3) Sounds like there's a lot missing.
Yep.  The GDB stub needs to be finished, which should be just adding in the
thread-awareness stuff;  and a lot of the test programs need to be ran.
Some brave soul is encouraged to step up and help the configuration so that
W/NT can be used for development.  Shoot--I even need someone to go back and
try this under Linux.  The system only boots from 3.5" disks, so that needs
to be fixed eventually, the ISR handler needs to be able to switch to an 
independent ISR stack (it currently uses whoever was running when the ISR was
invoked), serial port drivers need to be enabled, and, well, everything else
needs to be done.

A question for Cygnus: there was a lot of platform-specific initialization I had
to put in the file vectors.S--since the linker is told to put that module first.
Unfortunately vectors.S is stored in the 'arch' tree rather than the platform
tree.  Is there any plans to separate this?  I'd suggest doing a careful audit
of that file in order to split it into a platform specific part (for PCs
which boot from a floppy or other PC-type boards which boot out of ROM) and an
architecture part (for all 386's).  I think that the first file in the linker
script should be stored in the platform tree, not the arch tree.

Anyway, I've been working on this for the past couple of weeks, and now that I've
got the threading to work, I'm going to move over and start doing some actual
applications work...  which means that I'll be slowing down as far as completing
the port.  Anyone who cares to get involved is encouraged to tinker with this...
I'm sure that I'll be posting updates fairly frequently, so if you're at all
timid about dealing with the stuff that's missing here, just hang tight.
Post any questions or observations to ecos-discuss@sourceware.cygnus.com...
I'll try to answer any questions which come up there.

Cheers--and good luck!
-patrick

Patrick O'Grady
patrick@plasticgrape.com

Re: [ECOS] hal/i386/pc prerelease.

[Jesper Skov]

>>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:
Patrick> Just wanted to let you all know that I've posted a *very
Patrick> early* but actually functional version of a hal for running
Patrick> eCos on a standard '386 or better PC.

Nice one! :)

Patrick> A question for Cygnus: there was a lot of platform-specific
Patrick> initialization I had to put in the file vectors.S--since the
Patrick> linker is told to put that module first.  Unfortunately
Patrick> vectors.S is stored in the 'arch' tree rather than the
Patrick> platform tree.  Is there any plans to separate this?  I'd
Patrick> suggest doing a careful audit of that file in order to split
Patrick> it into a platform specific part (for PCs which boot from a
Patrick> floppy or other PC-type boards which boot out of ROM) and an
Patrick> architecture part (for all 386's).  I think that the first
Patrick> file in the linker script should be stored in the platform
Patrick> tree, not the arch tree.

The vectors.S should contain mostly platform neutral code. When
there's a need for platform specific stuff, it should be handled via
macros/calls defined by platform files.

The current i386 HAL is a bit out of shape in this regard. The ARM HAL
is a better example of how things should be handled for multiple
platforms.

Patrick> Anyway, I've been working on this for the past couple of
Patrick> weeks, and now that I've got the threading to work, I'm going
Patrick> to move over and start doing some actual applications work...
Patrick> which means that I'll be slowing down as far as completing
Patrick> the port.  Anyone who cares to get involved is encouraged to
Patrick> tinker with this...  I'm sure that I'll be posting updates
Patrick> fairly frequently, so if you're at all timid about dealing
Patrick> with the stuff that's missing here, just hang tight.  Post
Patrick> any questions or observations to
Patrick> ecos-discuss@sourceware.cygnus.com...  I'll try to answer any
Patrick> questions which come up there.

I'd like (obviously) to have a look at this, but it's unclear when I
will get the time to actually "tinker" with it. Unlikely to be within
the next couple of weeks though.

Jesper

Re: [ECOS] hal/i386/pc prerelease.

[Nick Garnett]

Jesper Skov <jskov@cygnus.co.uk> writes:

> The vectors.S should contain mostly platform neutral code. When
> there's a need for platform specific stuff, it should be handled via
> macros/calls defined by platform files.
> 
> The current i386 HAL is a bit out of shape in this regard. The ARM HAL
> is a better example of how things should be handled for multiple
> platforms.

Even better, look at the MIPS HAL. This is the way all future HALs
will be built, with architecture, variant and platform sub-HALs with
well-defined ways for them to pass information to each other and
override things.



-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk