[ECOS] Patch for x86 bootstrap

[ECOS] Patch for x86 bootstrap

[elf]

I made a patch to the platform.inc code so that the x86 gdb stub can
boot from a device with geometry other than the default floppy
geometry.  It also changes the handling of the _start address such
that a) it can be aligned on any byte boundary, and b) it can be over
64k--for what it's worth.

  < ftp://ftp.buici.com/pub/ecos/bootstrap >

-- Marc Singer

[ECOS] Re: Patch for x86 bootstrap

[Fabrice Gautier]

On Tue, 24 Apr 2001 19:17:59 -0700
elf@florence.buici.com wrote:

> I made a patch to the platform.inc code so that the x86 gdb stub can
> boot from a device with geometry other than the default floppy
> geometry.  It also changes the handling of the _start address such
> that a) it can be aligned on any byte boundary, and b) it can be over
> 64k--for what it's worth.
> 
>   < ftp://ftp.buici.com/pub/ecos/bootstrap >

I just want to point at this note your patch is deleting:

-	/* destination pointer es:bx */
-	/* With correct alignement, bx should be 0 and es should be a multiple
-         * of 32. If not it may cause the "buffer cross 64k boundary" problem
-         * (cf above)
-	 */   


We patched this code loader about six month ago in order to avoid this
problem for floppy. I hope you did notice the problem and that it is not
reintroduced by your patch. 
(I've not read your patch enough nor tested anything...)

Good work anyway, and good to see someone working with the x86 platform...

Regards,

-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Re: Patch for x86 bootstrap

[elf]

If the patch was made a while ago, where is it?

I changed to code so that the problem you describe is no longer
relevent.  In fact, there are a couple of bugs in the loader that I
fixed.  For example, the loader only works when loading to addresses <
64K.

On Wed, Apr 25, 2001 at 02:56:56PM +0200, Fabrice Gautier wrote:
> 
> On Tue, 24 Apr 2001 19:17:59 -0700
> elf@florence.buici.com wrote:
> 
> > I made a patch to the platform.inc code so that the x86 gdb stub can
> > boot from a device with geometry other than the default floppy
> > geometry.  It also changes the handling of the _start address such
> > that a) it can be aligned on any byte boundary, and b) it can be over
> > 64k--for what it's worth.
> > 
> >   < ftp://ftp.buici.com/pub/ecos/bootstrap >
> 
> I just want to point at this note your patch is deleting:
> 
> -	/* destination pointer es:bx */
> -	/* With correct alignement, bx should be 0 and es should be a multiple
> -         * of 32. If not it may cause the "buffer cross 64k boundary" problem
> -         * (cf above)
> -	 */   
> 
> 
> We patched this code loader about six month ago in order to avoid this
> problem for floppy. I hope you did notice the problem and that it is not
> reintroduced by your patch. 
> (I've not read your patch enough nor tested anything...)
> 
> Good work anyway, and good to see someone working with the x86 platform...
> 
> Regards,
> 
> -- 
> Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Re: Patch for x86 bootstrap

[Fabrice Gautier]

On Wed, 25 Apr 2001 10:05:30 -0700
elf@florence.buici.com wrote:

> If the patch was made a while ago, where is it?

This one has been incorporated in the RedHat CVS back then.
> 
> I changed to code so that the problem you describe is no longer
> relevent.  In fact, there are a couple of bugs in the loader that I
> fixed.  For example, the loader only works when loading to addresses <
> 64K.

So everything is fine, I sure trust you for that.

Regards,

-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Re: Patch for x86 bootstrap

[elf]

On Wed, Apr 25, 2001 at 07:52:04PM +0100, Jonathan Larmour wrote:
> > I have been unable to make redboot work.  I'm told there are some
> > patches to fix this that are out of date.  When I enabled posix for
> > x86 on the current version in cvs, the configuration (ecosconfig)
> > fails with an unresolved constraint.
> 
> Make sure you are using the ecosconfig off of
> http://sources.redhat.com/ecos/anoncvs.html . If you already are, then I'd
> be interested to know the problem.

I'm attaching the typescript from a session where I attempt to
configure posix.  Note that my repository is attached to the anoncvs
repository.

> > I'm told that the bootstrap loader was patched a while back.  I don't
> > know if they added support for partition tables.  If they did, I'd
> > like to see the patch.  If they didn't, then IMHO, my patch is better
> > because it fixes other bugs in the loader code.
> 
> The patch Fabrice was talking about was the patch that made loading over
> 64K boundaries work. That patch was in the code you had editted, and he was
> querying why you removed it.

I believe there was some bugs in the patch.  There was some code to
make sure that the destination pointer was properly aligned to prevent
writing past the end of a segment.  However, after it rereads the
first sector and writes it to _start, there is a long jump

  jmp $0,$_start

This means that the symbol _start must exist within the first 64K of
the real address space.  

My patch eliminates both of these problems in two ways.  First, it
converts the destination pointer to es:bx just before every read
operation.  This means that it can write anywhere with any alignment
within the first megabyte of address space.  Second, I copy the first
block to _start before reading anything from the floppy, and then do
an indirect jump to _start.

Furthermore, I believe that the previous code wasn't clearing bx
before every read sector interrupt.  This may not have been a problem,
but it seems risky to depend on the BIOS to maintain this register's
value.

I made these changes incidentally, since my primary interest was in
booting to flash on my given platform.  I'm told there has been a
patch to make this work.  Do you have it?

> > I'm glad to contribute to eCos as long as the work is put back into
> > the source tree.  I'll look at the assignment links and take care of
> > what needs to be done.
> 
> I can guarantee that if your change is useful it will appear. It may not
> appear instantaneously, but it will. We've already done quite a bit on the
> x86 internally, but for various reasons we are unable to release it yet. We
> hope to work it out soon.

Have you fixed the bootstrap to boot from hard drives?

> 
> 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] Re: Patch for x86 bootstrap

[elf]

On Wed, Apr 25, 2001 at 08:54:30PM +0200, Fabrice Gautier wrote:
> 
> On Wed, 25 Apr 2001 10:05:30 -0700
> elf@florence.buici.com wrote:
> 
> > If the patch was made a while ago, where is it?
> 
> This one has been incorporated in the RedHat CVS back then.

I am confused.  The code that I can now fetch from anoncvs doesn't
respect the floppy drive geometry.  Are you saying that a patch for
this has already been incorporated into RedHat CVS?  And that they
haven't released it?

> > I changed to code so that the problem you describe is no longer
> > relevent.  In fact, there are a couple of bugs in the loader that I
> > fixed.  For example, the loader only works when loading to addresses <
> > 64K.
> 
> So everything is fine, I sure trust you for that.

I appreciate your confidence.  :-)

Cheers,
  Marc

Re: [ECOS] Re: Patch for x86 bootstrap

[Jonathan Larmour]

elf@florence.buici.com wrote:
> 
> On Wed, Apr 25, 2001 at 07:52:04PM +0100, Jonathan Larmour wrote:
> > > I have been unable to make redboot work.  I'm told there are some
> > > patches to fix this that are out of date.  When I enabled posix for
> > > x86 on the current version in cvs, the configuration (ecosconfig)
> > > fails with an unresolved constraint.
> >
> > Make sure you are using the ecosconfig off of
> > http://sources.redhat.com/ecos/anoncvs.html . If you already are, then I'd
> > be interested to know the problem.
> 
> I'm attaching the typescript from a session where I attempt to
> configure posix.  Note that my repository is attached to the anoncvs
> repository.

No you haven't :-).

> Have you fixed the bootstrap to boot from hard drives?

No-one has I believe.

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] Re: Patch for x86 bootstrap

[Fabrice Gautier]

On Wed, 25 Apr 2001 12:25:04 -0700
elf@florence.buici.com wrote:

> On Wed, Apr 25, 2001 at 08:54:30PM +0200, Fabrice Gautier wrote:
> > 
> > On Wed, 25 Apr 2001 10:05:30 -0700
> > elf@florence.buici.com wrote:
> > 
> > > If the patch was made a while ago, where is it?
> > 
> > This one has been incorporated in the RedHat CVS back then.
> 
> I am confused.  The code that I can now fetch from anoncvs doesn't
> respect the floppy drive geometry.  Are you saying that a patch for
> this has already been incorporated into RedHat CVS?  And that they
> haven't released it?

Yes and No ! 

This patch has been in CVS for a long time, and is in the version you're
are working on. One comment you're deleting in your patch was introduced
with the very patch i'm talking about.

I just say that Back in November a patch to handle a problem from floppy
loading, the one described by the comment I quoted, was incorporated
into CVS.

Your patch sure add something  else, and is more genreic. But as you were
deleting the comment from the code, I just wanted to be sure that you
had not as the same time reintroduced the problem. 

Well to not confuse you and others more i should explain more precisely:

The problem was that before November, the code would have tried,
with one call to int 13h, to load a full track (18 sectors), across a
64k boundary. The BIOS would not handle that case, some kind of DMA
problem, I think. By loading sector by sector the problem was solved.

I've look at your patch a little more closely, and I don't think it
reintroduce the problem since you are still loading sector by sector. So At
least for loading to an adress aligned on sector size (512b) should be
Okay. 

But, I'm not sure what would happen when your code try to load a sector
across a 64Ko boundary, ie: not a Sector size aligned size, but anyway
the loader has never been designed to handle such a case before.


A+
-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Re: Patch for x86 bootstrap

[elf]

> This patch has been in CVS for a long time, and is in the version you're
> are working on. One comment you're deleting in your patch was introduced
> with the very patch i'm talking about.
> 
> I just say that Back in November a patch to handle a problem from floppy
> loading, the one described by the comment I quoted, was incorporated
> into CVS.

Very fair. 

> Your patch sure add something  else, and is more genreic. But as you were
> deleting the comment from the code, I just wanted to be sure that you
> had not as the same time reintroduced the problem. 
> 
> Well to not confuse you and others more i should explain more precisely:
> 
> The problem was that before November, the code would have tried,
> with one call to int 13h, to load a full track (18 sectors), across a
> 64k boundary. The BIOS would not handle that case, some kind of DMA
> problem, I think. By loading sector by sector the problem was solved.
> 
> I've look at your patch a little more closely, and I don't think it
> reintroduce the problem since you are still loading sector by sector. So At
> least for loading to an adress aligned on sector size (512b) should be
> Okay. 
> 
> But, I'm not sure what would happen when your code try to load a sector
> across a 64Ko boundary, ie: not a Sector size aligned size, but anyway
> the loader has never been designed to handle such a case before.

I believe that I didn't reintroduce this error.  If you look at the
int13 call to read the sector, you can see that I am computing the
load address there.  Since we are in real-mode, I load the segment
register (es) with the destination_address>>4 and the offset (bx) with
the destination_address&0xf.  I believe that this will always load
correctly.

Had I known the problem you were trying to solve, I might have
reimplemented the multi-sector read.  I thought about it, but I wasn't
sure if it was due to potential BIOS problems.  I'll make it an
option.

> 
> 
> A+
> -- 
> Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Re: Patch for x86 bootstrap

[Jonathan Larmour]

elf@florence.buici.com wrote:
> 
> > No you haven't :-).
> 
> Oops.  Let me try again.

Ah yes, of course. I forgot that one. You have to do a "ecosconfig remove
libc_signals".

The reason is that there are two signals implementations: the default one
is simple, small and fast. The POSIX one is fully POSIX compatible, but
carries with it the concomitant baggage.

Oh, and CC ecos-discuss please.

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] Re: Patch for x86 bootstrap

[elf]

On Thu, Apr 26, 2001 at 04:11:20AM +0100, Jonathan Larmour wrote:
> Ah yes, of course. I forgot that one. You have to do a "ecosconfig remove
> libc_signals".

And how am I supposed to guess this?

> The reason is that there are two signals implementations: the default one
> is simple, small and fast. The POSIX one is fully POSIX compatible, but
> carries with it the concomitant baggage.
> 
> Oh, and CC ecos-discuss please.

Do you mean  this time, or simply 'please don't forget to'? 


> 
> 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] Re: Patch for x86 bootstrap

[Jonathan Larmour]

elf@florence.buici.com wrote:
> 
> On Thu, Apr 26, 2001 at 04:11:20AM +0100, Jonathan Larmour wrote:
> > Ah yes, of course. I forgot that one. You have to do a "ecosconfig remove
> > libc_signals".
> 
> And how am I supposed to guess this?

Not every consequence of changing your configuration can be documented!
Although the more tractable course of action would be to choose either the
"posix" or "elix" template instead of the default one, using
Build->Templates. That way the conflict doesn't arise.

> > The reason is that there are two signals implementations: the default one
> > is simple, small and fast. The POSIX one is fully POSIX compatible, but
> > carries with it the concomitant baggage.
> >
> > Oh, and CC ecos-discuss please.
> 
> Do you mean  this time, or simply 'please don't forget to'?

The latter, that's all. Thanks!

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] Re: Patch for x86 bootstrap

[elf]

On Thu, Apr 26, 2001 at 06:55:09PM +0100, Jonathan Larmour wrote:
> elf@florence.buici.com wrote:
> > 
> > On Thu, Apr 26, 2001 at 04:11:20AM +0100, Jonathan Larmour wrote:
> > > Ah yes, of course. I forgot that one. You have to do a "ecosconfig remove
> > > libc_signals".
> > 
> > And how am I supposed to guess this?
> 
> Not every consequence of changing your configuration can be documented!
> Although the more tractable course of action would be to choose either the
> "posix" or "elix" template instead of the default one, using
> Build->Templates. That way the conflict doesn't arise.

I think you are missing my point.  The ecosconfig error message
doesn't indicate the type of problem.  This is two-fold.

  C CYGPKG_POSIX, "requires" constraint not satisfied: CYGBLD_ISO_SIGNAL_NUMBERS_HEADER ==  "<cyg/posix/signal.h>" 
  C CYGPKG_POSIX, "requires" constraint not satisfied: CYGBLD_ISO_SIGNAL_IMPL_HEADER ==  "<cyg/posix/signal.h>" 
  C CYGINT_ISO_SIGNAL_NUMBERS, "requires" constraint not satisfied:  1 >= CYGINT_ISO_SIGNAL_NUMBERS 
  C CYGINT_ISO_SIGNAL_IMPL, "requires" constraint not satisfied:  1 >= CYGINT_ISO_SIGNAL_IMPL 

These errors don't give any hint that this might be a problem with
multiple implementations.  I'd expect something like the Debian DEB
format such as 

  'signals' implementations conflict in 
    posix
    libc_signals

Second, it is unclear where these constants are defined so that I can
discover the source of the unsatisfied constraints.  These are not
present in the .ecc file, nor is there an indication of where to look.

Re: [ECOS] Re: Patch for x86 bootstrap

[Robin Farine]

elf@florence.buici.com writes:

> On Thu, Apr 26, 2001 at 06:55:09PM +0100, Jonathan Larmour wrote:
> > elf@florence.buici.com wrote:
> > > 
> > > On Thu, Apr 26, 2001 at 04:11:20AM +0100, Jonathan Larmour wrote:
> > > > Ah yes, of course. I forgot that one. You have to do a "ecosconfig
> > > > remove libc_signals".
> > > 
> > > And how am I supposed to guess this?
> > 
> > Not every consequence of changing your configuration can be documented!
> > Although the more tractable course of action would be to choose either the
> > "posix" or "elix" template instead of the default one, using
> > Build->Templates. That way the conflict doesn't arise.
> 
> I think you are missing my point.  The ecosconfig error message doesn't
> indicate the type of problem.  This is two-fold.
> 
>   C CYGPKG_POSIX, "requires" constraint not satisfied:
>   CYGBLD_ISO_SIGNAL_NUMBERS_HEADER == "<cyg/posix/signal.h>" C CYGPKG_POSIX,
>   "requires" constraint not satisfied: CYGBLD_ISO_SIGNAL_IMPL_HEADER ==
>   "<cyg/posix/signal.h>" C CYGINT_ISO_SIGNAL_NUMBERS, "requires" constraint
>   not satisfied: 1 >= CYGINT_ISO_SIGNAL_NUMBERS C CYGINT_ISO_SIGNAL_IMPL,
>   "requires" constraint not satisfied: 1 >= CYGINT_ISO_SIGNAL_IMPL
> 
> These errors don't give any hint that this might be a problem with multiple
> implementations.  I'd expect something like the Debian DEB format such as
> 
>   'signals' implementations conflict in
>     posix libc_signals

Right, this would help.

> 
> Second, it is unclear where these constants are defined so that I can discover
> the source of the unsatisfied constraints.  These are not present in the .ecc
> file, nor is there an indication of where to look.

From the package directory, you could try something like:

 find . \( -name '*.cdl' -exec grep CYGINT_ISO_SIGNAL_NUMBERS {} \; \) -exec ls \
 -ld {} \;

which produces:

      implements     CYGINT_ISO_SIGNAL_NUMBERS
  -rw-rw-r--    1 user  group      10116 Apr  9 15:48 \
  packages/compat/posix/current/cdl/posix.cdl
      requires        CYGINT_ISO_SIGNAL_NUMBERS
      default_value   { CYGINT_ISO_SIGNAL_NUMBERS != 0 && \
  -rw-rw-r--    1 user  group       4436 Mar  8 09:57 \
  packages/io/serial/current/cdl/termios.cdl
          cdl_interface CYGINT_ISO_SIGNAL_NUMBERS {
              requires      { 1 >= CYGINT_ISO_SIGNAL_NUMBERS }
  -rw-rw-r--    1 user  group      37273 Apr  9 15:50 \
  packages/isoinfra/current/cdl/isoinfra.cdl
      implements    CYGINT_ISO_SIGNAL_NUMBERS
  -rw-rw-r--    1 user  group      11273 Mar  8 09:57 \
  packages/language/c/libc/signals/current/cdl/signals.cdl

and then look in ecos.ecc to see which *active* package/component implements
CYGINT_ISO_SIGNAL_NUMBERS.


Robin