etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Ken I finally had a chance to look at this patch.  The updated
> >support code for LinuxBIOS didn't make it in.  Do you need
> >me to resend the patch?.   The code presently in etherboot no longer
> >works so this is important.
> 
> Yes, please.

OK it is sent. I sent it directly because the list message
filter didn't like it.  Too many ifdefs..

Eric

[Etherboot-developers] Re: [Etherboot-users] On-board eepro100

[<ke...@us...>]

>Today I decided enough is enough, and after many hours of testing,
>managed to boot both etherboot 5.0.5 and grub 0.91 on my on-board
>eepro100.
>
>The only fix I made, in the end, was to add a 'udelay(4000)' just
>before 'whereami ("set stats addr.");' in eepro100.c (line 533).

Ok, have changed it to udelay(10000). Evidently 10 us is not enough.
Maybe someone miswrote or misread a data sheet. Nobody will notice 10
ms during initialisation.  Thanks very much for the detective work.

>BTW: the etherboot-5.0.5+megapatch (5.0.6 rc 2) didn't work at all.
>The machine has frozen during boot with a cleared screen.

The problem seems to have been found, hopefully.

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Ken I finally had a chance to look at this patch.  The updated
> >support code for LinuxBIOS didn't make it in.  Do you need
> >me to resend the patch?.   The code presently in etherboot no longer
> >works so this is important.
> 
> Yes, please.
...
> Yes, please.

OK OK I'll have it in just a moment.  I just discovered a regression
in build with LinuxBIOS support.  set_gateA20 calls int15.  When
running under LinuxBIOS we shouldn't need it anyway so...

Eric

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ke...@us...>]

>Ken I finally had a chance to look at this patch.  The updated
>support code for LinuxBIOS didn't make it in.  Do you need
>me to resend the patch?.   The code presently in etherboot no longer
>works so this is important.

Yes, please.

Re: [Etherboot-developers] Patch for 5.0.6rc2 : eepro100 no more working

[<ke...@us...>]

>The change made in pci.c for e1000 makes my eepro100 unhappy :
>
>- the eepro100 is most of the time no more recognized ([EEPRO100]No
>adapter found)
>- or when recognized, the ioaddr is 0xdd100000 which is it first memory
>location, not
>  its IO address...
>
>Adding the removed condition in the "if" (i.e. || ((ioaddr &
>PCI_BASE_ADDRESS_SPACE_IO)==0) )
>and it's fine again...

Ah, we shall have to resolve this somehow. Christopher Li, are you
reading this?

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ke...@us...>]

>Ken I finally had a chance to look at this patch.  The updated
>support code for LinuxBIOS didn't make it in.  Do you need
>me to resend the patch?.   The code presently in etherboot no longer
>works so this is important.

Yes, please.

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ebi...@ln...>]

ke...@us... writes:

> We've got enough changes and new bits to move towards releasing 5.0.6.
> The change list is rather long, please look at the LOG file.  I've put a
> megapatch of all the changes from 5.0.5 to 5.0.6rc2 at
> http://sf.net/projects/etherboot under Patch Manager. Please test if you
> can.
> 
> For those of you who can't or don't compile from source, it will be up
> at rom-o-matic.net in due time.

Ken I finally had a chance to look at this patch.  The updated
support code for LinuxBIOS didn't make it in.  Do you need
me to resend the patch?.   The code presently in etherboot no longer
works so this is important.

Eric

[Etherboot-developers] Patch for 5.0.6rc2 : eepro100 no more working

[Jean-Jacques M. <jjm...@li...>]

The change made in pci.c for e1000 makes my eepro100 unhappy :

- the eepro100 is most of the time no more recognized ([EEPRO100]No
adapter found)
- or when recognized, the ioaddr is 0xdd100000 which is it first memory
location, not
  its IO address...

Adding the removed condition in the "if" (i.e. || ((ioaddr &
PCI_BASE_ADDRESS_SPACE_IO)==0) )
and it's fine again...

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

[Etherboot-developers] mknbi-1.2-7rc4 released

[<ke...@us...>]

>Sorry, the last posting went to Etherboot-users by mistake, mystifying
>newbies no doubt, but I think I've got the code right now (famous last
>words). Latest release is in:
>
>	http://etherboot.sf.net/mknbi-1.2-7rc3.tar.gz

Sure enough, there was an off by 1 meg bug in it. Try again

	http://etherboot.sf.net/mknbi-1.2-7rc4.tar.gz

[Etherboot-developers] subscribe

[<M68...@li...>]

----- Original Message -----
From: <eth...@li...>
To: <eth...@li...>
Sent: Friday, March 01, 2002 7:48 AM
Subject: Etherboot-developers digest, Vol 1 #267 - 18 msgs


> Send Etherboot-developers mailing list submissions to
> eth...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> or, via email, send a message with subject or body 'help' to
> eth...@li...
>
> You can reach the person managing the list at
> eth...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Etherboot-developers digest..."
>
>
> Today's Topics:
>
>    1. Re: Small change request: make usage of
>        PCI_PNP_HEADER configurable (Christoph Plattner)
>    2. Re: Re: Via-rhine in etherboot 5.1.1 & misc (Ken Yap)
>    3. Re: Small change request: make usage of PCI_PNP_HEADER configurab=
le
(Ken Yap)
>    4. Re: Small change request: make usage of  PCI_PNP_HEADER configura=
ble
(Eric W. Biederman)
>    5. Re: Small change request: make usage of
>        PCI_PNP_HEADER configurable (Christoph Plattner)
>    6. Re: Small change request: make usage of PCI_PNP_HEADER configurab=
le
(Ken Yap)
>    7. Patch for RTL8139 due to compiler optimisations... (Jean-Jacques
Michel)
>    8. Patch for RTL8139 due to compiler optimisations...
>        : forgot the patch itself... (Jean-Jacques Michel)
>    9. Re: Patch for RTL8139 due to compiler optimisations... (Ken Yap)
>   10. Re: Patch for RTL8139 due to compiler
>        optimisations... (Jean-Jacques Michel)
>   11. Re: Patch for RTL8139 due to compiler optimisations... (Ken Yap)
>   12. Re: Patch for RTL8139 due to compiler
>        optimisations... (Jean-Jacques Michel)
>   13. Re: Patch for RTL8139 due to compiler  optimisations... (Eric W.
Biederman)
>
> --__--__--
>
> Message: 1
> Date: Thu, 28 Feb 2002 23:31:17 +0100
> From: Christoph Plattner <chr...@gm...>
> Organization: private
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Small change request: make usage of
>  PCI_PNP_HEADER configurable
>
> Ok, I will think about writing the HOWTO ...
>
> To come back (only for a short hint).
>
> You high quality on PCI handling allows using the idea of
> legacy ROM images. Why ?
> The answer is simple. When Etherboot starts, it does the whole
> setup on his own. Setting up and activating PCI devices,
> searching for the devices, attaching the driver to them and
> run the boopt/tftp stuff.
>
> The PCI/PnP header is only needed (AFAIK, and tests have proven
> that) that the BIOS following the BBS (BIOS BOOT SPEC) creates
> an boot entry in a list of bootable devices. Therefore the
> ROM code is not simple executed, but it is started following
> the boot order.
>
> If the ROM has not a PCI/PnP haeder following BBS, then the
> ROM code is treated as "normal" ROM extension (maybe something
> else, than a boot device), an the BIOS has to execute this code
> anyway, before going to the "boot work".
>
> And as mentioned above, etherboot is fully self-contained and
> can run the code booting an OS, or if the user decides to boot
> locally (or if something fails) the control is given back to the
> BIOS and so the BIOS starts it's normal boot process.
>
> So the user can really select between two well defined booting
> methods !!
>
> With friendly regard
> Christoph Plattner
>
>
>
> Ken Yap wrote:
> >
> > >It is paradox. The old BIOS not able to handle PCI/PnP headers,
> > >have no problems, but the user also misses the feature of a
> > >define boot order including the net.
> > >On very new BIOS the problem exists, if the user want to have
> > >a selection without touching the BIOS setup 9for example
> > >embedded boards using serial console with a BIOS without serial
> > >console port ....).
> > >
> > >I hope I could explain the problem, I often use the wrong words ...
> >
> > I don't think pure PCI BIOSes are even required to pay attention to
> > legacy ROMs since they don't expect them to be on the bus. So it's
> > somewhat accidental that you can subvert the PnP mechanism to get the
> > behaviour you want.
> >
> > I would rather that you wrote a small HOWTO, and I will add it to the
> > contrib/ section. If I make it part of the official config, people wi=
ll
> > ask me questions about it and I don't want to spend time finding out
> > about their strange BIOS situation.  If you write the HOWTO, you can
> > answer the questions.
> >
> > _______________________________________________
> > Etherboot-developers mailing list
> > Eth...@li...
> > https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>
> --
> -------------------------------------------------------
> private: chr...@gm...
> company: chr...@al...
>
>
>
> --__--__--
>
> Message: 2
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Re: Via-rhine in etherboot 5.1.1 &
misc
> Reply-To: Etherboot developers list
<eth...@li...>
> From: ke...@us... (Ken Yap)
> Date: Fri, 01 Mar 2002 13:43:40 +1100
>
> >Valid also, but what is the need for a ring in this case ? If you wait
> >for the transmit to be finished each time you send a packet, then a
> >single
> >buffer is enough.
> >With my proposed patch, you can have 2 packets waiting to be sent, and
> >only
> >have to wait if you want to send a third one... Am I wrong ?
>
> The ring is a leftover from the Linux driver that whoever ported the
> code left in there. There is in fact no advantage in having more than
> one transmit buffer and a memory penalty for doing so because all the
> protocols used by Etherboot are stop and wait protocols. Network loadin=
g
> is fast enough as it is anyway.
>
> >Does not break the specs : the specs remains valid, but you get an ext=
ra
> >feature
> >for Etherboot... ;-)
> >Well, I can live with my own version for now, it was just an idea.
>
> Yes it does. It means Etherboot is accepting something outside the spec=
s
> and that means people may come to rely on it, and then it has to stay.
> That's how crud starts. In any case PXE does not guarantee that you can
> load more than 32kB of image starting at 0x7c00 and I'm surprised you
> can load a kernel. Maybe it's not a kernel you're loading then.
>
>
> --__--__--
>
> Message: 3
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Small change request: make usage of
PCI_PNP_HEADER configurable
> Reply-To: Etherboot developers list
<eth...@li...>
> From: ke...@us... (Ken Yap)
> Date: Fri, 01 Mar 2002 13:49:19 +1100
>
> >If the ROM has not a PCI/PnP haeder following BBS, then the
> >ROM code is treated as "normal" ROM extension (maybe something
> >else, than a boot device), an the BIOS has to execute this code
> >anyway, before going to the "boot work".
>
> You don't seem to have read what I wrote. There is no guarantee that Pn=
P
> BIOSes will continue to handle legacy ROMs. If there is no ISA bus then
> all devices are on the PCI bus and thus have to be PnP.
>
> I don't want this change in the official configuration.  But anybody ca=
n
> edit the Config file as you have done. Nobody is stopping anybody from
> making a legacy ROM.  The matter is closed. You can submit the HOWTO or
> not, as you wish.
>
>
> --__--__--
>
> Message: 4
> To: Christoph Plattner <chr...@gm...>
> Cc: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Small change request: make usage of
PCI_PNP_HEADER configurable
> From: ebi...@ln... (Eric W. Biederman)
> Date: 01 Mar 2002 00:14:13 -0700
>
> Christoph Plattner <chr...@gm...> writes:
>
> > Ok, I will think about writing the HOWTO ...
>
> Currently etherboot asks the question
> Boot from the network or (L) local.
>
> And if you press L etherboot exits and the boot continues.
>
> Are you asking for a way to say boot locally with an
> ethernet packet.  Something like filename=3D"/dev/hda";
> But with the BIOS doing the actual loading?
>
> So if you have a BBS compliant bios you set etherboot up
> first in the boot order and this works (assuming you
> don't loose your cmos options.)
>
> A dhcp option to tell etherboot to give up sounds sane.
>
> Potentially an option to disable just BBS support but not PCI PnP suppo=
rt
> may also be sane.  Though I would have to research that a little
> more to see.
>
> Eric
>
>
> --__--__--
>
> Message: 5
> Date: Fri, 01 Mar 2002 08:54:44 +0100
> From: Christoph Plattner <chr...@al...>
> Organization: AAA
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Small change request: make usage of
>  PCI_PNP_HEADER configurable
>
> Ok, I see your concern ...
>
> My change was done in the `Makefile' not `Config' file. My suggestion
> was to move this to the config file.
>
> So should I describe it to change in the Makefile or do we move
> this time (only the setting of the MACRO) to the `Config' file ?
>
> In both ways, a small change would be convinient. If we let it in
> the Makefile, we should extract the option to one central point
> like this, to easier handle that case:
>
> :
> BBS_OPTS =3D # -DPCI_PNP_HEADER
>
> :
> :
> bin/prloader.s: loader.S $(MAKEDEPS)
> $(CPP) $(LCONFIG) $(BBS_OPTS) -o $@ $<
>
> bin/przloader.s: loader.S $(MAKEDEPS)
> $(CPP) $(LCONFIG) $(BBS_OPTS) -DZLOADER -o $@ $<
>
> And the second method is to move the "BBS_OPTS =3D xxxx" to the
> `Config' file.
>
> Or do we change nothing, and the HOTWO really says: delete the DEFINES
> on this two lines ... ?
>
> With friendly regards
> Christoph Plattner
>
>
> Ken Yap wrote:
> >
> > >If the ROM has not a PCI/PnP haeder following BBS, then the
> > >ROM code is treated as "normal" ROM extension (maybe something
> > >else, than a boot device), an the BIOS has to execute this code
> > >anyway, before going to the "boot work".
> >
> > You don't seem to have read what I wrote. There is no guarantee that =
PnP
> > BIOSes will continue to handle legacy ROMs. If there is no ISA bus th=
en
> > all devices are on the PCI bus and thus have to be PnP.
> >
> > I don't want this change in the official configuration.  But anybody =
can
> > edit the Config file as you have done. Nobody is stopping anybody fro=
m
> > making a legacy ROM.  The matter is closed. You can submit the HOWTO =
or
> > not, as you wish.
> >
> > _______________________________________________
> > Etherboot-developers mailing list
> > Eth...@li...
> > https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>
> --
>   +--------V--------+ Chr...@al...
>   |  A L C A T E L  | -----------------------------
>   +-----------------+ Phone: +43 1 27722 3706
>          T A S Fax:   +43 1 27722 3955
>
>
> --__--__--
>
> Message: 6
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Small change request: make usage of
PCI_PNP_HEADER configurable
> Reply-To: Etherboot developers list
<eth...@li...>
> From: ke...@us... (Ken Yap)
> Date: Fri, 01 Mar 2002 20:28:54 +1100
>
> >So should I describe it to change in the Makefile or do we move
> >this time (only the setting of the MACRO) to the `Config' file ?
>
> Neither. Because then you are making prloader a rloader, and przloader =
a
> rzloader and that's a sort of a lie. The simplest way to achieve what
> you want is to edit the rules for the target NIC in Roms and change
> PRLOADER to RLOADER, and PRZLOADER to RZLOADER. Only 4 lines need to be
> changed for a given NIC.  Then you will prepend a legacy ROM header whe=
n
> you make that NIC's .rom and .lzrom images.  Only don't let the file
> Roms be regenerated from the file NIC.
>
> If you are keen, then you can figure out what needs to be changed in
> genrules.pl so that it will not prepend PCI headers in the absence of
> PCI IDs for that NIC, even if it's a PCI NIC. Then you can just delete
> the IDs from the line in NIC and it will generate a rule for a legacy
> ROM.
>
> If you are really keen you could work out a way of generating the table=
s
> in config.c from NIC. Then adding a new variant of a supported
> controller should only require one edit. The genrules.pl script has
> served well, but is showing its age.  Now that would be a truly useful
> contribution.
>
>
> --__--__--
>
> Message: 7
> Date: Fri, 01 Mar 2002 15:18:40 +0100
> From: Jean-Jacques Michel <jjm...@li...>
> Organization: Linbox SA
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: [Etherboot-developers] Patch for RTL8139 due to compiler
optimisations...
>
> After the via-rhine, here is something weird about the
> Realtek driver :
>
> I had Etherboot stop after the "(DHCP)..." and
> the frames were "malformed" due to the type in the
> mac header being 0x0000.
>
> Cause :
>
> In "rtl_transmit", the variable nstype is updated only AFTER
> the memcpy is done !
> Moving the "nstype =3D htons(type)" far from the "memcpy" makes
> the problem disappear.
>
> The assembly output (Gcc 3.0.3) :
>
> 00000248 <rtl_transmit>:
>  248:   55                      push   %ebp
>  249:   57                      push   %edi
>  24a:   56                      push   %esi
>  24b:   53                      push   %ebx
>  24c:   83 ec 0c                sub    $0xc,%esp
>  24f:   8b 4c 24 24             mov    0x24(%esp,1),%ecx
>  253:   8b 01                   mov    (%ecx),%eax
>  255:   8b 6c 24 20             mov    0x20(%esp,1),%ebp
>  259:   a3 20 00 00 00          mov    %eax,0x20
>  25e:   66 8b 41 04             mov    0x4(%ecx),%ax
>  262:   8b 4d 18                mov    0x18(%ebp),%ecx
>  265:   66 a3 24 00 00 00       mov    %ax,0x24
>  26b:   8b 01                   mov    (%ecx),%eax
>  26d:   8b 5c 24 2c             mov    0x2c(%esp,1),%ebx
>  271:   8b 54 24 28             mov    0x28(%esp,1),%edx ;Here is
> "type", from the function parameters
>  275:   a3 26 00 00 00          mov    %eax,0x26
>  27a:   86 d6                   xchg   %dl,%dh ;htons(type)
>  27c:   66 8b 41 04             mov    0x4(%ecx),%ax
>  280:   66 a3 2a 00 00 00       mov    %ax,0x2a
>  286:   0f b7 d2                movzwl %dx,%edx ;extend %edx
>  289:   8b 44 24 08             mov    0x8(%esp,1),%eax ; %eax=3Dnstype
> (!!!Uninitialized!!!)
>  28d:   85 db                   test   %ebx,%ebx
>  28f:   8b 74 24 30             mov    0x30(%esp,1),%esi
>  293:   89 54 24 08             mov    %edx,0x8(%esp,1)
> ;nstype=3Dhtons(type)
>  297:   66 a3 2c 00 00 00       mov    %ax,0x2c ; !!! We are using
> %ax, not %dx !!!
> ; Thus the tx_buffer.mactype is WRONG !
>
>
> Let's hope it does not appear at other places in the code !!!
>
> Not that easy to trace !
>
> Regards,
>
> --
> Jean-Jacques Michel mailto:jjm...@li...
> Hardware Engineer - Linbox http://www.linbox.com
> Technop=F4le Metz 2000 - 152 rue de Grigy - 57070 Metz - France
> Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26
>
>
> --__--__--
>
> Message: 8
> Date: Fri, 01 Mar 2002 15:20:57 +0100
> From: Jean-Jacques Michel <jjm...@li...>
> Organization: Linbox SA
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: [Etherboot-developers] Patch for RTL8139 due to compiler
optimisations...
>  : forgot the patch itself...
>
> Il s'agit d'un message multivolet au format MIME.
> --------------F09C5D10BB502FE6257EE666
> Content-Type: text/plain; charset=3Diso-8859-1
> Content-Transfer-Encoding: 8bit
>
> Ooops,
>
> --
> Jean-Jacques Michel mailto:jjm...@li...
> Hardware Engineer - Linbox http://www.linbox.com
> Technop=F4le Metz 2000 - 152 rue de Grigy - 57070 Metz - France
> Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26
> --------------F09C5D10BB502FE6257EE666
> Content-Type: text/plain; charset=3Dus-ascii;
>  name=3D"diff.rtl8139"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename=3D"diff.rtl8139"
>
> --- rtl8139.c.orig Fri Mar  1 15:02:21 2002
> +++ rtl8139.c Fri Mar  1 15:02:30 2002
> @@ -339,9 +339,9 @@
>   unsigned int status, to, nstype;
>   unsigned long txstatus;
>
> + nstype =3D htons(type);
>   memcpy(tx_buffer, destaddr, ETH_ALEN);
>   memcpy(tx_buffer + ETH_ALEN, nic->node_addr, ETH_ALEN);
> - nstype =3D htons(type);
>   memcpy(tx_buffer + 2 * ETH_ALEN, (char*)&nstype, 2);
>   memcpy(tx_buffer + ETH_HLEN, data, len);
>
>
> --------------F09C5D10BB502FE6257EE666--
>
>
>
> --__--__--
>
> Message: 9
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Patch for RTL8139 due to compiler
optimisations...
> Reply-To: Etherboot developers list
<eth...@li...>
> From: ke...@us... (Ken Yap)
> Date: Sat, 02 Mar 2002 01:28:03 +1100
>
> >In "rtl_transmit", the variable nstype is updated only AFTER
> >the memcpy is done !
> >Moving the "nstype =3D htons(type)" far from the "memcpy" makes
> >the problem disappear.
>
> Ok, will patch, many thanks. Will you submit a gcc3 bug report?
>
>
> --__--__--
>
> Message: 10
> Date: Fri, 01 Mar 2002 15:41:33 +0100
> From: Jean-Jacques Michel <jjm...@li...>
> Organization: Linbox SA
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Patch for RTL8139 due to compiler
>  optimisations...
>
> Ken Yap a =E9crit :
> >
> > >In "rtl_transmit", the variable nstype is updated only AFTER
> > >the memcpy is done !
> > >Moving the "nstype =3D htons(type)" far from the "memcpy" makes
> > >the problem disappear.
> >
> > Ok, will patch, many thanks. Will you submit a gcc3 bug report?
>
> I don't really know if you can consider this as a GCC bug :
>
> If you work with a "char *ptr",
> there is nothing the compiler can know about *ptr when you use ptr
> as a parameter of a function.From my point of view, you cannot blame
> the compiler for this.
>
> --
> Jean-Jacques Michel mailto:jjm...@li...
> Hardware Engineer - Linbox http://www.linbox.com
> Technop=F4le Metz 2000 - 152 rue de Grigy - 57070 Metz - France
> Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26
>
>
> --__--__--
>
> Message: 11
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Patch for RTL8139 due to compiler
optimisations...
> Reply-To: Etherboot developers list
<eth...@li...>
> From: ke...@us... (Ken Yap)
> Date: Sat, 02 Mar 2002 01:49:29 +1100
>
> >> Ok, will patch, many thanks. Will you submit a gcc3 bug report?
> >
> >I don't really know if you can consider this as a GCC bug :
> >
> >If you work with a "char *ptr",
> >there is nothing the compiler can know about *ptr when you use ptr
> >as a parameter of a function.From my point of view, you cannot blame
> >the compiler for this.
>
> In fact the char* cast is unnecessary as the corresponding formal
> argument is void* which is convertible from any pointer. So I removed
> it. Does the bug still happen if you remove the char* cast? The other
> thing is, it's not actually a function call but an inline function
> expansion. So it looks like the compiler was confused.
>
>
> --__--__--
>
> Message: 12
> Date: Fri, 01 Mar 2002 16:16:35 +0100
> From: Jean-Jacques Michel <jjm...@li...>
> Organization: Linbox SA
> To: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Patch for RTL8139 due to compiler
>  optimisations...
>
> Ken Yap a =E9crit :
>
> > In fact the char* cast is unnecessary as the corresponding formal
> > argument is void* which is convertible from any pointer. So I removed
> > it. Does the bug still happen if you remove the char* cast?
>
> Still happens without the cast (char*).
>
> > The other
> > thing is, it's not actually a function call but an inline function
> > expansion. So it looks like the compiler was confused.
>
> To be safe, an alternative would be to use : "*(unsigned
> short)(tx....)=3Dnstype;"
>
> I also had a look at the objdump output of "tulip.c" which use a simila=
r
> construction
> and it looks OK without any change. This is really optimisation
> dependant !
>
> Nearly time to quit, TGIF ;-) ,
>
> Have a nice week-end,
>
> --
> Jean-Jacques Michel mailto:jjm...@li...
> Hardware Engineer - Linbox http://www.linbox.com
> Technop=F4le Metz 2000 - 152 rue de Grigy - 57070 Metz - France
> Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26
>
>
> --__--__--
>
> Message: 13
> To: Jean-Jacques Michel <jjm...@li...>
> Cc: Etherboot developers list <eth...@li....n=
et>
> Subject: Re: [Etherboot-developers] Patch for RTL8139 due to compiler
optimisations...
> From: ebi...@ln... (Eric W. Biederman)
> Date: 01 Mar 2002 08:46:27 -0700
>
> Jean-Jacques Michel <jjm...@li...> writes:
>
> > Ken Yap a =3DE9crit :
> > >=3D20
> > > >In "rtl_transmit", the variable nstype is updated only AFTER
> > > >the memcpy is done !
> > > >Moving the "nstype =3D3D htons(type)" far from the "memcpy" makes
> > > >the problem disappear.
> > >=3D20
> > > Ok, will patch, many thanks. Will you submit a gcc3 bug report?
> >=3D20
> > I don't really know if you can consider this as a GCC bug :
> >=3D20
> > If you work with a "char *ptr",
> > there is nothing the compiler can know about *ptr when you use ptr
> > as a parameter of a function.From my point of view, you cannot blame
> > the compiler for this.
>
> Exactly there is nothing the compiler can know so it must
> be conservative.  The compiler can only take this kind of
> action if the types are definenitely different, so they cannot alias.
> I haven't explicitly heard about void * but I know it must assume=3D20
> char * pointers can alias with any type.
>
> It might be worth trying with: -fno-strict-aliasing and see
> if the problem persists.
>
> Eric
>
>
>
> --__--__--
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>
>
> End of Etherboot-developers Digest

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[<ebi...@ln...>]

Christoph Plattner <chr...@gm...> writes:

> As I mentioned in another mail, we write and work on a safety critical
> OS. For this we also must validate the compilers (assessment), and we
> know from our experiments and analysis, that we MUST use the option
> `-fno-strict-aliasing' (we must not deliver software without this
> option). 

Then it is likely your software is buggy.  

> We also found strange constructions using optimizing.
> 
> Further I heard, that the GCC team also discuss, if
> `-fno-strict-aliasing'
> should become the default, but I do not know more about this discussion.

The default in 2.95.2 is -fno-strict-aliasing
The default afterwards is -fstrict-aliasing.

Eric

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[Christoph P. <chr...@gm...>]

As I mentioned in another mail, we write and work on a safety critical
OS. For this we also must validate the compilers (assessment), and we
know from our experiments and analysis, that we MUST use the option
`-fno-strict-aliasing' (we must not deliver software without this
option). We also found strange constructions using optimizing.

Further I heard, that the GCC team also discuss, if
`-fno-strict-aliasing'
should become the default, but I do not know more about this discussion.

Bye
Christoph P.


"Eric W. Biederman" wrote:
> 
> Jean-Jacques Michel <jjm...@li...> writes:
> 
> > Ken Yap a écrit :
> > >
> > > >In "rtl_transmit", the variable nstype is updated only AFTER
> > > >the memcpy is done !
> > > >Moving the "nstype = htons(type)" far from the "memcpy" makes
> > > >the problem disappear.
> > >
> > > Ok, will patch, many thanks. Will you submit a gcc3 bug report?
> >
> > I don't really know if you can consider this as a GCC bug :
> >
> > If you work with a "char *ptr",
> > there is nothing the compiler can know about *ptr when you use ptr
> > as a parameter of a function.From my point of view, you cannot blame
> > the compiler for this.
> 
> Exactly there is nothing the compiler can know so it must
> be conservative.  The compiler can only take this kind of
> action if the types are definenitely different, so they cannot alias.
> I haven't explicitly heard about void * but I know it must assume
> char * pointers can alias with any type.
> 
> It might be worth trying with: -fno-strict-aliasing and see
> if the problem persists.
> 
> Eric
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[Christoph P. <chr...@gm...>]

Hello ,

"Eric W. Biederman" wrote:
> 
> Christoph Plattner <chr...@gm...> writes:
> 
> > Ok, I will think about writing the HOWTO ...
> 
> Currently etherboot asks the question
> Boot from the network or (L) local.
> 
> And if you press L etherboot exits and the boot continues.

On that Phoenix-Bios we had problems. BBS loads the etherboot
(first device in the boot order), after the timeout (3sec)
it exits, but then it loads etherboot again, and again ....

What I do not know now, was, if etherboot was called only
3 times (as 3 NIC of the same type was installed), or
endless, as the BIOS always stars the boot order from the
first entry.

Using NO_DELAYED_INT has shown following:
1. Etherboot was started 3 times (perhaps for 3 NICs), independent,
	of the NIC BootROMs wer activated or not (the etherboot
	image was written to an extra ROM on the ISA bus on 0xD0000
2. After the third etherboot has exited, the mesaage "No System found,
	press ENTER ..."
	After pressing ENTER, the system boots locally.

So my further idea was: Let boot etherboot as "normal" ("legacy" is 
here a missleading word ....) without following the BBS (no BBS 
header structure including PCI and Pnp$ structure), but etherboot
itself is not changed (done by removing "-DPCI_PNP_HEADER").
After this, the image runs correctly. It was executed first, and
after exiting, the normal boot sequence continouses. 

May be, this BIOS is buggy or some intergration steps were done in
the wrong way (the etherboot image will be embedded into the BIOS),
but I think it is a nice feature, to setup such a etherboot image.

> 
> Are you asking for a way to say boot locally with an
> ethernet packet.  Something like filename="/dev/hda";
> But with the BIOS doing the actual loading?
> 

No, this is not suitable for our setup. The goal is to have
embedded machines in high safety critical applications, and
this machines must boot locally. But in the lab, the machines
should also be able to boot from net, without touching the BIOS
settings (the BIOS does not support serial console, and we do
not support screen and keyboard !).


> So if you have a BBS compliant bios you set etherboot up
> first in the boot order and this works (assuming you
> don't loose your cmos options.)
> 
> A dhcp option to tell etherboot to give up sounds sane.
> 
> Potentially an option to disable just BBS support but not PCI PnP support
> may also be sane.  Though I would have to research that a little
> more to see.
> 
> Eric

With friendly regards
Christoph P.

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

[Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

[<ke...@us...>]

We've got enough changes and new bits to move towards releasing 5.0.6.
The change list is rather long, please look at the LOG file.  I've put a
megapatch of all the changes from 5.0.5 to 5.0.6rc2 at
http://sf.net/projects/etherboot under Patch Manager. Please test if you
can.

For those of you who can't or don't compile from source, it will be up
at rom-o-matic.net in due time.

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[<ebi...@ln...>]

Jean-Jacques Michel <jjm...@li...> writes:

> Ken Yap a =E9crit :
> >=20
> > >In "rtl_transmit", the variable nstype is updated only AFTER
> > >the memcpy is done !
> > >Moving the "nstype =3D htons(type)" far from the "memcpy" makes
> > >the problem disappear.
> >=20
> > Ok, will patch, many thanks. Will you submit a gcc3 bug report?
>=20
> I don't really know if you can consider this as a GCC bug :
>=20
> If you work with a "char *ptr",
> there is nothing the compiler can know about *ptr when you use ptr
> as a parameter of a function.From my point of view, you cannot blame
> the compiler for this.

Exactly there is nothing the compiler can know so it must
be conservative.  The compiler can only take this kind of
action if the types are definenitely different, so they cannot alias.
I haven't explicitly heard about void * but I know it must assume=20
char * pointers can alias with any type.

It might be worth trying with: -fno-strict-aliasing and see
if the problem persists.

Eric

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[Jean-Jacques M. <jjm...@li...>]

Ken Yap a écrit :

> In fact the char* cast is unnecessary as the corresponding formal
> argument is void* which is convertible from any pointer. So I removed
> it. Does the bug still happen if you remove the char* cast?

Still happens without the cast (char*).

> The other
> thing is, it's not actually a function call but an inline function
> expansion. So it looks like the compiler was confused.

To be safe, an alternative would be to use : "*(unsigned
short)(tx....)=nstype;"

I also had a look at the objdump output of "tulip.c" which use a similar
construction
and it looks OK without any change. This is really optimisation
dependant !

Nearly time to quit, TGIF ;-) ,

Have a nice week-end,

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[<ke...@us...>]

>> Ok, will patch, many thanks. Will you submit a gcc3 bug report?
>
>I don't really know if you can consider this as a GCC bug :
>
>If you work with a "char *ptr",
>there is nothing the compiler can know about *ptr when you use ptr
>as a parameter of a function.From my point of view, you cannot blame
>the compiler for this.

In fact the char* cast is unnecessary as the corresponding formal
argument is void* which is convertible from any pointer. So I removed
it. Does the bug still happen if you remove the char* cast? The other
thing is, it's not actually a function call but an inline function
expansion. So it looks like the compiler was confused.

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[Jean-Jacques M. <jjm...@li...>]

Ken Yap a écrit :
> 
> >In "rtl_transmit", the variable nstype is updated only AFTER
> >the memcpy is done !
> >Moving the "nstype = htons(type)" far from the "memcpy" makes
> >the problem disappear.
> 
> Ok, will patch, many thanks. Will you submit a gcc3 bug report?

I don't really know if you can consider this as a GCC bug :

If you work with a "char *ptr",
there is nothing the compiler can know about *ptr when you use ptr
as a parameter of a function.From my point of view, you cannot blame
the compiler for this.

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

Re: [Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[<ke...@us...>]

>In "rtl_transmit", the variable nstype is updated only AFTER
>the memcpy is done !
>Moving the "nstype = htons(type)" far from the "memcpy" makes
>the problem disappear.

Ok, will patch, many thanks. Will you submit a gcc3 bug report?

[Etherboot-developers] Patch for RTL8139 due to compiler optimisations... : forgot the patch itself...

[Jean-Jacques M. <jjm...@li...>]

Ooops,

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

[Etherboot-developers] Patch for RTL8139 due to compiler optimisations...

[Jean-Jacques M. <jjm...@li...>]

After the via-rhine, here is something weird about the
Realtek driver :

I had Etherboot stop after the "(DHCP)..." and
the frames were "malformed" due to the type in the
mac header being 0x0000.

Cause :

In "rtl_transmit", the variable nstype is updated only AFTER
the memcpy is done !
Moving the "nstype = htons(type)" far from the "memcpy" makes
the problem disappear.

The assembly output (Gcc 3.0.3) :

00000248 <rtl_transmit>:
 248:   55                      push   %ebp
 249:   57                      push   %edi
 24a:   56                      push   %esi
 24b:   53                      push   %ebx
 24c:   83 ec 0c                sub    $0xc,%esp
 24f:   8b 4c 24 24             mov    0x24(%esp,1),%ecx
 253:   8b 01                   mov    (%ecx),%eax
 255:   8b 6c 24 20             mov    0x20(%esp,1),%ebp
 259:   a3 20 00 00 00          mov    %eax,0x20
 25e:   66 8b 41 04             mov    0x4(%ecx),%ax
 262:   8b 4d 18                mov    0x18(%ebp),%ecx
 265:   66 a3 24 00 00 00       mov    %ax,0x24
 26b:   8b 01                   mov    (%ecx),%eax
 26d:   8b 5c 24 2c             mov    0x2c(%esp,1),%ebx
 271:   8b 54 24 28             mov    0x28(%esp,1),%edx		;Here is
"type", from the function parameters
 275:   a3 26 00 00 00          mov    %eax,0x26
 27a:   86 d6                   xchg   %dl,%dh				;htons(type)
 27c:   66 8b 41 04             mov    0x4(%ecx),%ax
 280:   66 a3 2a 00 00 00       mov    %ax,0x2a
 286:   0f b7 d2                movzwl %dx,%edx				;extend %edx
 289:   8b 44 24 08             mov    0x8(%esp,1),%eax			; %eax=nstype
(!!!Uninitialized!!!)
 28d:   85 db                   test   %ebx,%ebx
 28f:   8b 74 24 30             mov    0x30(%esp,1),%esi
 293:   89 54 24 08             mov    %edx,0x8(%esp,1)		
;nstype=htons(type)
 297:   66 a3 2c 00 00 00       mov    %ax,0x2c 			; !!! We are using
%ax, not %dx !!! 
									; Thus the tx_buffer.mactype is WRONG !


Let's hope it does not appear at other places in the code !!!

Not that easy to trace !

Regards,

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[<ke...@us...>]

>So should I describe it to change in the Makefile or do we move
>this time (only the setting of the MACRO) to the `Config' file ?

Neither. Because then you are making prloader a rloader, and przloader a
rzloader and that's a sort of a lie. The simplest way to achieve what
you want is to edit the rules for the target NIC in Roms and change
PRLOADER to RLOADER, and PRZLOADER to RZLOADER. Only 4 lines need to be
changed for a given NIC.  Then you will prepend a legacy ROM header when
you make that NIC's .rom and .lzrom images.  Only don't let the file
Roms be regenerated from the file NIC.

If you are keen, then you can figure out what needs to be changed in
genrules.pl so that it will not prepend PCI headers in the absence of
PCI IDs for that NIC, even if it's a PCI NIC. Then you can just delete
the IDs from the line in NIC and it will generate a rule for a legacy
ROM.

If you are really keen you could work out a way of generating the tables
in config.c from NIC. Then adding a new variant of a supported
controller should only require one edit. The genrules.pl script has
served well, but is showing its age.  Now that would be a truly useful
contribution.

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[Christoph P. <chr...@al...>]

Ok, I see your concern ...

My change was done in the `Makefile' not `Config' file. My suggestion
was to move this to the config file.

So should I describe it to change in the Makefile or do we move
this time (only the setting of the MACRO) to the `Config' file ?

In both ways, a small change would be convinient. If we let it in
the Makefile, we should extract the option to one central point
like this, to easier handle that case:

:
BBS_OPTS = # -DPCI_PNP_HEADER

:
:
bin/prloader.s:	loader.S $(MAKEDEPS)
	$(CPP) $(LCONFIG) $(BBS_OPTS) -o $@ $<

bin/przloader.s:	loader.S $(MAKEDEPS)
	$(CPP) $(LCONFIG) $(BBS_OPTS) -DZLOADER -o $@ $<

And the second method is to move the "BBS_OPTS = xxxx" to the
`Config' file.

Or do we change nothing, and the HOTWO really says: delete the DEFINES
on this two lines ... ?

With friendly regards
Christoph Plattner
 

Ken Yap wrote:
> 
> >If the ROM has not a PCI/PnP haeder following BBS, then the
> >ROM code is treated as "normal" ROM extension (maybe something
> >else, than a boot device), an the BIOS has to execute this code
> >anyway, before going to the "boot work".
> 
> You don't seem to have read what I wrote. There is no guarantee that PnP
> BIOSes will continue to handle legacy ROMs. If there is no ISA bus then
> all devices are on the PCI bus and thus have to be PnP.
> 
> I don't want this change in the official configuration.  But anybody can
> edit the Config file as you have done. Nobody is stopping anybody from
> making a legacy ROM.  The matter is closed. You can submit the HOWTO or
> not, as you wish.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[<ebi...@ln...>]

Christoph Plattner <chr...@gm...> writes:

> Ok, I will think about writing the HOWTO ...

Currently etherboot asks the question 
Boot from the network or (L) local.

And if you press L etherboot exits and the boot continues.

Are you asking for a way to say boot locally with an
ethernet packet.  Something like filename="/dev/hda";
But with the BIOS doing the actual loading?

So if you have a BBS compliant bios you set etherboot up
first in the boot order and this works (assuming you
don't loose your cmos options.)

A dhcp option to tell etherboot to give up sounds sane.

Potentially an option to disable just BBS support but not PCI PnP support
may also be sane.  Though I would have to research that a little
more to see.

Eric

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[<ke...@us...>]

>If the ROM has not a PCI/PnP haeder following BBS, then the
>ROM code is treated as "normal" ROM extension (maybe something
>else, than a boot device), an the BIOS has to execute this code
>anyway, before going to the "boot work".

You don't seem to have read what I wrote. There is no guarantee that PnP
BIOSes will continue to handle legacy ROMs. If there is no ISA bus then
all devices are on the PCI bus and thus have to be PnP.

I don't want this change in the official configuration.  But anybody can
edit the Config file as you have done. Nobody is stopping anybody from
making a legacy ROM.  The matter is closed. You can submit the HOWTO or
not, as you wish.