Re: [ECOS] probably a FAQ, but: how many x86 ports are in motion out there?

Re: [ECOS] probably a FAQ, but: how many x86 ports are in motion out there?

[Roland Schwarz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Hi,
    the x86, pc104 platform still is not on the list of supported
targets. As the toolchain is hosted on x86 I suppose it will be
straightforward to target to this platform.
Is this true?

Thank you,
Roland
-----Original Message-----
From: Bart Veer <bartv@cygnus.co.uk>
To: utz@serv.net <utz@serv.net>
Cc: ecos-discuss@cygnus.com <ecos-discuss@cygnus.com>
Date: Dienstag, 02. März 1999 23:32
Subject: Re: [ECOS] probably a FAQ, but: how many x86 ports are in motion
out there?


>>>>>> "John" == The Utz Family <utz@serv.net> writes:
>
>    John> whats the status on x86? x86/pc103/4? amd-sc400?
>
>Currently there is no port of eCos to embedded x86 platforms, but such
>a port by Cygnus is now under consideration. This would target
>processors from the 386 upwards - support for earlier processors would
>be difficult because of compiler issues.
>
>Please see the section on porting in the sourceware FAQ for more
>details, http://sourceware.cygnus.com/ecos/faq.html
>
>Bart Veer // eCos net maintainer
>

Re: [ECOS] probably a FAQ, but: how many x86 ports are in motionout there?

[Patrick O'Grady]

On Thu, 7 Oct 1999, Roland Schwarz wrote:

> >>>>>> "John" == The Utz Family <utz@serv.net> writes:
> >
> >    John> whats the status on x86? x86/pc103/4? amd-sc400?
> >
> >Currently there is no port of eCos to embedded x86 platforms, but such
> >a port by Cygnus is now under consideration. This would target
> >processors from the 386 upwards - support for earlier processors would
> >be difficult because of compiler issues.
> >


Hi, all--

I've been working on this port over the past couple of weeks...  I've
added a 'pc' platform, which supports 'floppy' and 'ram' startups.  Here's
a quick status report:

- I have a prototype 'floppy' startup which allows an application to be
written on a 3.5" diskette.  This is how I've been running the GDB stub.

- The GDB stub is about 75% in place.  It doesn't know anything about
threads yet, and some of the exceptions aren't supported properly.
However, the breakpoint exception, is working great.

- I've just yesterday been able to get the clock ISR to work, so the 
threading support is next on the list.

- 'make tests' works fine, but only the hal tests (intr, context,
and cache) have been ran.  I'm sure that context still needs some work.

I'm hoping to have the threading stuff figured out by the end of next
week--I'll post it as soon as I feel like it's usable!  Stay tuned...

-patrick

Re: [ECOS] probably a FAQ, but: how many x86 ports are in motion out there?

[Jesper Skov]

>>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:

[snip]
Patrick> - The GDB stub is about 75% in place.  It doesn't know
Patrick> anything about threads yet, and some of the exceptions aren't
Patrick> supported properly.  However, the breakpoint exception, is
Patrick> working great.

Patrick> - I've just yesterday been able to get the clock ISR to work,
Patrick> so the threading support is next on the list.
[snip]
Patrick> I'm hoping to have the threading stuff figured out by the end
Patrick> of next week--I'll post it as soon as I feel like it's
Patrick> usable!  Stay tuned...


Is it kernel thread support or GDB thread debugging support you want
to implement? The latter should come pretty much free with the
hal/common stub code.

Jesper

[ECOS] hal/i386/pc...

[Patrick O'Grady]

On 8 Oct 1999, Jesper Skov wrote:

> >>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:
> 
> [snip]
> Patrick> - The GDB stub is about 75% in place.  It doesn't know
> Patrick> anything about threads yet, and some of the exceptions aren't
> Patrick> supported properly.  However, the breakpoint exception, is
> Patrick> working great.
> 
> Patrick> - I've just yesterday been able to get the clock ISR to work,
> Patrick> so the threading support is next on the list.
> [snip]
> Patrick> I'm hoping to have the threading stuff figured out by the end
> Patrick> of next week--I'll post it as soon as I feel like it's
> Patrick> usable!  Stay tuned...
> 
> 
> Is it kernel thread support or GDB thread debugging support you want
> to implement? The latter should come pretty much free with the
> hal/common stub code.
> 
> Jesper
> 

I've been running with CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT turned off;
after I understand more about eCos' thread contexts I'll play with this a
bit--so the current stub is incomplete.  I'm also having a problem updating
the values of the CPU registers:  if I stop a program, and 'print $eip', it
prints the right value; but when I 'print $eip=0x55aa', followed by a 'c',
it resumes from the breakpoint instead of my new address...  so I've got some
kind of register assignment problem.  It's kinda odd that I can read the
current values, but not modify them in a way that sticks.  I'm sure that
it's something simple...  so far it's been easier to just reboot the target
PC after finding bugs than to debug the stub itself!

The next thing I want to look over is the HAL code supporting context
switching:  The linux synthetic HAL_THREAD_SWITCH_CONTEXT macro works great
in the target PC when called as a function; but I'm not exactly sure how an
ISR (specifically the clock ISR) can create a preemptive context switch.  Since
the macro itself doesn't save all the registers (eax, ecx, edx), there seems
to be some other call which will save these registers (and maybe more) too.
It's quite likely that context switching code may be responsible for the
register amnesia noted above.  I also want to learn more about how DSRs are
called.

I've got a question about ISR stacks--what stack should ISRs switch to?  And
where is the proper place to define this--does the kernel reserve a stack, or
should I have the HAL do it transparently?  Is there a standard macro for
configuring it's length?  And finally, do you include any utility functions 
for detecting the actual amount of stack used--this is usually a very simple
routine which fills the stack buffer with some value (VxWorks uses 0xEE), and
later on searches through the buffer for the lowest point where it was
modified...  any clues here would be helpful.

Cheers...
-patrick

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

[Jesper Skov]

>>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:

Patrick> I've been running with CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
Patrick> turned off; after I understand more about eCos' thread
Patrick> contexts I'll play with this a bit--so the current stub is
Patrick> incomplete.  I'm also having a problem updating the values of

That's what I meant by "comes for free with hal common". There should
be no need for thread related handling in the architecture/platform
stub code.

Patrick> the CPU registers: if I stop a program, and 'print $eip', it
Patrick> prints the right value; but when I 'print $eip=0x55aa',
Patrick> followed by a 'c', it resumes from the breakpoint instead of
Patrick> my new address...  so I've got some kind of register
Patrick> assignment problem.  It's kinda odd that I can read the
Patrick> current values, but not modify them in a way that sticks.
Patrick> I'm sure that it's something simple...  so far it's been
Patrick> easier to just reboot the target PC after finding bugs than
Patrick> to debug the stub itself!

Hard to say what the problem is - but personally, I'd put that high on
the list of things to get fixed. Nothing beats a good debugging
environment when you have to nail those last bugs.

Patrick> The next thing I want to look over is the HAL code supporting
Patrick> context switching: The linux synthetic
Patrick> HAL_THREAD_SWITCH_CONTEXT macro works great in the target PC
Patrick> when called as a function; but I'm not exactly sure how an
Patrick> ISR (specifically the clock ISR) can create a preemptive
Patrick> context switch.  Since the macro itself doesn't save all the
Patrick> registers (eax, ecx, edx), there seems to be some other call
Patrick> which will save these registers (and maybe more) too.  It's
Patrick> quite likely that context switching code may be responsible
Patrick> for the register amnesia noted above.  I also want to learn
Patrick> more about how DSRs are called.

Indeed, the other architectures rely on the interrupt handler to save
part of the register set - the context save/restore functions really
only have to save the callee-save registers; all other registers
should be saved prior to function entry (by virtue of the ABI).

Patrick> I've got a question about ISR stacks--what stack should ISRs
Patrick> switch to?  And where is the proper place to define
Patrick> this--does the kernel reserve a stack, or should I have the
Patrick> HAL do it transparently?  Is there a standard macro for
Patrick> configuring it's length?  And finally, do you include any
Patrick> utility functions for detecting the actual amount of stack
Patrick> used--this is usually a very simple routine which fills the
Patrick> stack buffer with some value (VxWorks uses 0xEE), and later
Patrick> on searches through the buffer for the lowest point where it
Patrick> was modified...  any clues here would be helpful.

If you look in some of the other architectures' arch/../vectors.S
files, you'll see that the HAL defines an interrupt stack - there's
also a configuration variable for defining its size.

There's a simple implementation of a stack monitor in
kernel/.../include/tests, but I don't think it fills the stack
initially.

Jesper