[Etherboot-developers] subscribe
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
[Etherboot-developers] subscribe
|
From: <M68...@li...> - 2002-03-01 19:56:11
|
----- 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 |
