etherboot-developers Mailing List for Etherboot (Page 219)
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers — Discussion of developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
| 2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
| 2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
| 2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
| 2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
| 2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
| 2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
| 2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
| 2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ke...@us...> - 2003-01-07 10:41:51
|
>However, should I make the ISAPNP a compile time option so it does not >increase the size of the compiled code for drivers that do not require >it? If so, what is the preferred way of doing that? Just put the .o in in bootlib.a and it will be pulled in by the linker only when it's needed, like pci.o. |
|
From: Timothy L. <tl...@ro...> - 2003-01-07 03:02:20
|
> FWIW, I thought about adding PCMCIA support a few months back. My > strategy was going to be to start by adding ISAPNP support to the core of > Etherboot (using the code currently in 3c515.c), since 16-bit PCMCIA I took a quick look at the isapnp code that I used in the 3c515 driver. It is very easy to isolate and pull out to separate isapnp.c file. I did that updated the Makefile and was able to compile the driver without any issues. As per my previous email, I would recommend a major rewrite of the isapnp code if you believe that there is merit in enabling this code for something other than the 3c515 driver. The current code is a hack of the ISAPNPTOOLS and the Linux isapnp code. If no one objects, I can finish cleaning up the 3c515, moving all the ISAPNP code to isapnp.c and isapnp.h (the 3c515 would still specifically need to call the ISAPNP code until someone implements isapnp as). However, should I make the ISAPNP a compile time option so it does not increase the size of the compiled code for drivers that do not require it? If so, what is the preferred way of doing that? Tim |
|
From: Timothy L. <tl...@ro...> - 2003-01-05 17:53:53
|
Hi Michael > Seconded. Having a multiple-bus infrastructure would also make it easier > to add PCMCIA support in the future. > > FWIW, I thought about adding PCMCIA support a few months back. My > strategy was going to be to start by adding ISAPNP support to the core of > Etherboot (using the code currently in 3c515.c), since 16-bit PCMCIA I had planned to start cleaning up the 3c515 driver after the sundance driver is finished. On of my first steps would have been to pull the ISAPNP outside the driver. Since I was only working on getting the 3c515 to work, I may left out some of the additional configuration that is required under ISAPNP (The card is never assigned an interrupt etc.). It might have some merit to implement the entire ISAPNP. Have you started anything yet? Tim |
|
From: Michael B. <mb...@fe...> - 2003-01-05 12:36:20
|
On Thu, 2 Jan 2003, Boris Reisig wrote: > > > In summary: feel free to commit changes to the header files, hold off on > > > the changes to prism2.c. I will edit the patch and check in the changes > > > to prism2.c some time after Christmas: someone please remind me if I > > > haven't done it by New Year's Day. > > O.k. I just did a cvs update and I don't see a prims2_reset. So > > here is your reminder. > I made some changes in my last patch submitted [prism2a.diff]. It seems that > in my last prism2 patch, my delay handling in the prism2_reset wasn't > correct. It seems that I reset the device too fast which causes my linksys > wmp11 to not get a DHCP request if it doesn't catch it the first attempt. > [Even though it looks like everything is working]. I'll upload a patch with > a newer patch. :-) OK, will wait for the newer patch before doing anything. Michael Brown http://www.fensystems.co.uk |
|
From: Michael B. <mb...@fe...> - 2003-01-05 12:35:21
|
On 4 Jan 2003, Eric W. Biederman wrote:
> > Being a sucker for punishment and the owner of an unsupported NIC, the
> > Pegasus based Linksys adapter, I keep giving some thought to what would
> > be required to implement USB support for Etherboot.
> > So far I have been merely brave enough download some of the USB Specs.
> > Any thoughts on what would be required, the practicality of porting the
> > Linux code, etc. With the limited number of usb NICS (most are Pegasus
> > based I believe) would implementing a full usb subsystem make sense, or
> > would implementing the required code within the driver itself be more
> > desirable.
> > Any comments would be most welcome.
> I think implementing the required code as a usb subsystem is a reasonable
> way to go. usb is a lot like pci so all of the plug and play goodies
> for detecting which nic to use come into play. So it should
> be reasonably clean.
Seconded. Having a multiple-bus infrastructure would also make it easier
to add PCMCIA support in the future.
FWIW, I thought about adding PCMCIA support a few months back. My
strategy was going to be to start by adding ISAPNP support to the core of
Etherboot (using the code currently in 3c515.c), since 16-bit PCMCIA
devices look pretty much like ISAPNP devices once you have initialised
them. I'm guessing that the overall structure should be something like:
a) Scan all known buses for bus adapters.
b) Initialise any bus adapters found and add new buses to list of known
buses.
c) Repeat steps (a) & (b) until no new adapters are found (this is
necessary to cope with the case of e.g. a PCMCIA USB adapter).
d) Scan all known buses for network devices - similar to the PCI scan
that now takes place but more general.
Michael Brown
http://www.fensystems.co.uk
|
|
From: <ebi...@ln...> - 2003-01-05 05:14:58
|
"Timothy Legge" <tl...@ro...> writes: > Hi > > Being a sucker for punishment and the owner of an unsupported NIC, the > Pegasus based Linksys adapter, I keep giving some thought to what would > be required to implement USB support for Etherboot. > > So far I have been merely brave enough download some of the USB Specs. > Any thoughts on what would be required, the practicality of porting the > Linux code, etc. With the limited number of usb NICS (most are Pegasus > based I believe) would implementing a full usb subsystem make sense, or > would implementing the required code within the driver itself be more > desirable. > > Any comments would be most welcome. I think implementing the required code as a usb subsystem is a reasonable way to go. usb is a lot like pci so all of the plug and play goodies for detecting which nic to use come into play. So it should be reasonably clean. There are a number of other cases that could be fun like a usb disk driver that could be useful as well. Eric |
|
From: <ke...@us...> - 2003-01-05 05:02:29
|
>I am trying to compile the sundance driver with 5.0. I am getting an >unresolved reference to sundance_probe. Any idea what I am missing. In 5.0 you have to make sundance_probe public as it's called from config.c. |
|
From: Timothy L. <tl...@ro...> - 2003-01-05 04:37:38
|
Hi > > Have you also tried it with 5.0? To make a 5.1 driver work on 5.0 > > do #define virt_to_bus(x) x > > I have started that process...damn config and make files... I am trying to compile the sundance driver with 5.0. I am getting an unresolved reference to sundance_probe. Any idea what I am missing. Tim |
|
From: Timothy L. <tl...@ro...> - 2003-01-05 02:15:03
|
> Have you also tried it with 5.0? To make a 5.1 driver work on 5.0 > do #define virt_to_bus(x) x I have started that process...damn config and make files... > >For some reason, it is extremely slow, taking 5 minutes to obtain its > >own driver from the dhcp server. I have not been able to track down the > >issue. Any thoughts? > > Maybe you're polling the wrong bit? It should be a register or memory > bit that indicates there is at least one complete packet in the buffer, > not an interrupt bit or anything interrupt related. I believe so, but I could be mistaken. I have looked at the poll process so many times I no longer know. > >Once I updated to the most recent version of the cvs, the PC reboots > >after it obtains its own rom. I have not yet had the time to figure it > >out. > > Possibly the relocation? Possibly, I tried it with the 3c515 as well and it froze after retrieving its file. However since I wrote that driver, I may be the common link... > Try it on 5.0 first. Then you won't have 5.1 issues confounding the > debugging. I will let you know how it goes. Tim |
|
From: <ke...@us...> - 2003-01-04 23:29:41
|
>I have committed the initial implementation of the sundance driver to >the 5.1 cvs. Have you also tried it with 5.0? To make a 5.1 driver work on 5.0 do #define virt_to_bus(x) x >For some reason, it is extremely slow, taking 5 minutes to obtain its >own driver from the dhcp server. I have not been able to track down the >issue. Any thoughts? Maybe you're polling the wrong bit? It should be a register or memory bit that indicates there is at least one complete packet in the buffer, not an interrupt bit or anything interrupt related. >Once I updated to the most recent version of the cvs, the PC reboots >after it obtains its own rom. I have not yet had the time to figure it >out. Possibly the relocation? Try it on 5.0 first. Then you won't have 5.1 issues confounding the debugging. |
|
From: Anselm M. H. <an...@ho...> - 2003-01-04 12:12:08
|
Hello Timothy, TL> So far I have been merely brave enough download some of the USB Specs. TL> Any thoughts on what would be required, the practicality of porting the TL> Linux code, etc. With the limited number of usb NICS (most are Pegasus TL> based I believe) There seem to be several wireless USB models out there. Having kind of "usb stack" could simplify implementation of those. TL> would implementing a full usb subsystem make sense, or TL> would implementing the required code within the driver itself be more TL> desirable. I'm no pro on usb implementations, but I remember there are two or three different drivers for USB chipsets in the linux kernel. Just for this fact, hardware abstraction could make sense. Another idea: For some time, there has been (never tested, only read about it) support to have multiple-driver-etherboot-files, especially useful for floppy-boot. Imagine the case there are four or five USB-drivers on it, that made a lot of reinitializations necessary. Not quite senseful, IMHO. My line of thought: Make a switch "WITHUSB" for initialization of USB mainboard ressources. This one should be as hardware independant as possible, having in best cast support for UHCI and OHCI (what was EHCI the acronym for?), so ALI and INTEL.... chipsets. Then read in a list of (I believe this is somehow possible) USB-IDs hanging on the bus. Store this list somewhere in RAM. That should have been done when initializing etherboot. When a USB driver is loaded (which lies within 3 seconds mostly, so no too great risk someone would unplug the network device just in that moment), it just checks for any USB-IDs it is capable of handling. Important step: When exiting etherboot (no matter where and to where it is exited), the USB device probably MUST be uninitialized. That's a task, to find all that exit points :-) (probably Ken and Eric did a well job there as everywhere and doc'ed it in the source, Luke) Would be quite interesting. Keep us posted. TL> Any comments would be most welcome. TL> Tim Legge Best regards, Anselm mailto:an...@ho... STANDARD DISCLAIMER: Sometimes, my memory goes bad. If defective bits make me write rubbish, throw it into the bin. Any opinions expressed are my personal one, except stated otherwise. |
|
From: Timothy L. <tl...@ro...> - 2003-01-04 01:30:31
|
Hi Being a sucker for punishment and the owner of an unsupported NIC, the Pegasus based Linksys adapter, I keep giving some thought to what would be required to implement USB support for Etherboot. So far I have been merely brave enough download some of the USB Specs. Any thoughts on what would be required, the practicality of porting the Linux code, etc. With the limited number of usb NICS (most are Pegasus based I believe) would implementing a full usb subsystem make sense, or would implementing the required code within the driver itself be more desirable. Any comments would be most welcome. Regards Tim Legge |
|
From: Boris R. <bo...@bo...> - 2003-01-03 04:50:35
|
I made some changes in my last patch submitted [prism2a.diff]. It seems that in my last prism2 patch, my delay handling in the prism2_reset wasn't correct. It seems that I reset the device too fast which causes my linksys wmp11 to not get a DHCP request if it doesn't catch it the first attempt. [Even though it looks like everything is working]. I'll upload a patch with a newer patch. :-) Boris Reisig (bo...@bo...) ----- Original Message ----- From: "Eric W. Biederman" <ebi...@ln...> To: "Michael Brown" <mb...@fe...> Cc: "Etherboot developers list" <eth...@li...> Sent: Thursday, January 02, 2003 6:02 PM Subject: Re: [Etherboot-developers] [Commit] Prism2 CVS Update. > Michael Brown <mb...@fe...> writes: > > > In summary: feel free to commit changes to the header files, hold off on > > the changes to prism2.c. I will edit the patch and check in the changes > > to prism2.c some time after Christmas: someone please remind me if I > > haven't done it by New Year's Day. > > O.k. I just did a cvs update and I don't see a prims2_reset. So > here is your reminder. > > Eric > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: <ebi...@ln...> - 2003-01-02 23:55:40
|
Michael Brown <mb...@fe...> writes: > In summary: feel free to commit changes to the header files, hold off on > the changes to prism2.c. I will edit the patch and check in the changes > to prism2.c some time after Christmas: someone please remind me if I > haven't done it by New Year's Day. O.k. I just did a cvs update and I don't see a prims2_reset. So here is your reminder. Eric |
|
From: <ke...@us...> - 2003-01-02 09:17:24
|
>I downloaded Etherboot 5.1.4rc1 and tried to build, but was unable to >generate ROM files - the makerom.pl script complained the ROM signature was >not 55 AA. > There is no rule for "PRLOADER" (the PCI version of ROM prefix code) in >arch/i386/Makefile. All PCI targets in bin/Roms (generated by genrules.pl) >depend on PRLOADER. I think you can confirm this by doing a "make clean" >first, then trying to build any ROM file. Thanks for that bug report, I think I've fixed that. You can find the next release at www.etherboot.org/etherboot-5.1.4rc2.tar.bz2 Note that the targets are .rom and .zrom, etc etc, the .lz* targets are gone. This includes Timothy Legge's sundance driver for more eyes to look at. |
|
From: Robb M. <ma...@ac...> - 2003-01-02 03:11:12
|
I downloaded Etherboot 5.1.4rc1 and tried to build, but was unable to generate ROM files - the makerom.pl script complained the ROM signature was not 55 AA. There is no rule for "PRLOADER" (the PCI version of ROM prefix code) in arch/i386/Makefile. All PCI targets in bin/Roms (generated by genrules.pl) depend on PRLOADER. I think you can confirm this by doing a "make clean" first, then trying to build any ROM file. Keep up the good work. Robb. |
|
From: Marty C. <md...@et...> - 2003-01-01 16:39:15
|
On Wednesday, January 1, 2003, at 11:18 AM, Timothy Legge wrote:
> I have committed the initial implementation of the sundance driver to
> the 5.1 cvs.
Congratulations! Many thanks for your work.
> Issues:
> For some reason, it is extremely slow, taking 5 minutes to obtain its
> own driver from the dhcp server. I have not been able to track down
> the
> issue. Any thoughts?
tcpdump and/or ethereal coupled with some detective work will likely
help.
I don't think I have a sundance card, but if you tell me where I can
get one, I could help you. If you can suggest a vendor (web/online is
fine), I'll be happy to order one.
I'd probably try to get it working in 5.0.8 before 5.1.x, just because
the code is a bit more tested, but with drivers, one bit in a bitmask
being off can significantly affect the result. I bet a few more pairs
of eyes on the code will quickly find the problem. Thanks again for you
help.
Regards,
Marty
--
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
Cambridge, MA 02139; USA
Voice: (617) 491-6935; Fax: (617) 491-7046
Email: md...@et...
Web: http://www.etherboot.org/
|
|
From: Timothy L. <tl...@ro...> - 2003-01-01 16:18:23
|
Hi All I have committed the initial implementation of the sundance driver to the 5.1 cvs. Issues: For some reason, it is extremely slow, taking 5 minutes to obtain its own driver from the dhcp server. I have not been able to track down the issue. Any thoughts? Once I updated to the most recent version of the cvs, the PC reboots after it obtains its own rom. I have not yet had the time to figure it out. Thanks to Donald Becker (Linux sundance.c) and Marty Connor (Etherboot tulip.c) for their prior work. Regards Tim Legge |
|
From: Timothy L. <tl...@ro...> - 2003-01-01 16:18:08
|
Hi All I have committed the initial implementation of the sundance driver to the 5.1 cvs. Issues: For some reason, it is extremely slow, taking 5 minutes to obtain its own driver from the dhcp server. I have not been able to track down the issue. Any thoughts? Once I updated to the most recent version of the cvs, the PC reboots after it obtains its own rom. I have not yet had the time to figure it out. Thanks to Donald Becker (Linux sundance.c) and Marty Connor (Etherboot tulip.c) for their prior work. Regards Tim Legge |
|
From: Timothy L. <tl...@ro...> - 2002-12-31 12:37:10
|
> Maybe you are not successfully reinitialising the hardware for the next > incoming packet? Getting a DHCP reply proves you can get one packet, now > you have to make it keep getting packets for the TFTP. That kind of what I thought. I will have to take a look at it later today. Thanks Tim |
|
From: <ke...@us...> - 2002-12-31 12:23:08
|
>The sundance driver is quite close now. It will transmit and poll. However, > etherboot determines the IP address and the file name from the server, it st >ops at > >Loading lts/sundance > >I loaded the same sundance file that is currently trying to load another copy > of itself from the server via a 3c515 card, so I the file is OK. > >I suspect that I still have a poll issue. Any thoughts? Maybe you are not successfully reinitialising the hardware for the next incoming packet? Getting a DHCP reply proves you can get one packet, now you have to make it keep getting packets for the TFTP. |
|
From: Timothy L. <tl...@ro...> - 2002-12-31 12:16:43
|
Hi All The sundance driver is quite close now. It will transmit and poll. However, etherboot determines the IP address and the file name from the server, it stops at Loading lts/sundance I loaded the same sundance file that is currently trying to load another copy of itself from the server via a 3c515 card, so I the file is OK. I suspect that I still have a poll issue. Any thoughts? Tim |
|
From: <ebi...@ln...> - 2002-12-30 18:15:55
|
Marty Connor <md...@et...> writes: > Anybody want to take a crack at this? It seems that the FreeBSD PXE > emulation support doesn't compile properly in 5.1.3. He seems to be > doing a standard build except for the option "-DFREEBSD_PXEEMU". Are > there any FreeBSD hackers around? That code has never compiled except on FreeBSD as it depends on some FreeBSD headers. Fixing it so that it compiles on Linux is desirable as it could host syslinux almost as easily as it hosts FreeBSD, and the code would stop bitrotting. Most of what is required is to track down the definitions needed from the FreeBSD headers and creating a header that can be included in etherboot. It should be possible to get the deffinitions from the PXE spec as well as FreeBSD. At that point it would provide enough PXE support that most users would not care about the difference. Eric |
|
From: Marty C. <md...@et...> - 2002-12-30 17:43:21
|
Anybody want to take a crack at this? It seems that the FreeBSD PXE=20 emulation support doesn't compile properly in 5.1.3. He seems to be=20 doing a standard build except for the option "-DFREEBSD_PXEEMU". Are=20 there any FreeBSD hackers around? Thanks, Marty Begin forwarded message: > From: Martin Jackson <Mar...@sm...> > Date: Mon Dec 30, 2002 3:26:49 AM US/Eastern > To: "'web...@en...'" <web...@en...> > Subject: Emailing:=20 > build.phpversion=3D5.1.3&F=3Dignore&nic=3Drtl8029+-+ns8390+%5=20 > B0x10ec%2C0x8029%5D&ofmt=3DFloppy+Bootable+ROM+Image+%28.htm > > Hi there, I was trying to get a rtl8029 with PXE Emulation enabled. > Cheers > =A0 > Martub > rtl8029.lzdsk Build Failed > Build failed. Status =3D 2. > > Following is the output from make: > > make: Entering directory `/tmp/ROMa14tx8' > Makefile:252: Roms: No such file or directory > ./genrules.pl NIC > Roms > make: Leaving directory `/tmp/ROMa14tx8' > make: Entering directory `/tmp/ROMa14tx8' > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 =20 > -DINCLUDE_NS8390 -o bin32/ns8390.o -c ns8390.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > ns8390.c: In function `nepci_probe': > ns8390.c:573: warning: unused variable `brd' > ns8390.c:574: warning: unused variable `chksum' > pci.h: At top level: > ns8390.c:38: warning: `eth_laar' defined but not used > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o=20 > bin32/config.o -c config.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > config.c: In function `probe': > config.c:170: warning: comparison between signed and unsigned > config.c:171: warning: assignment discards qualifiers from pointer=20 > target type > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o = bin32/pci.o=20 > -c pci.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o = bin32/main.o=20 > -c main.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > main.c: In function `main': > main.c:143: warning: `type' might be used uninitialized in this=20 > function > main.c:143: warning: variable `type' might be clobbered by `longjmp'=20= > or `vfork' > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o=20 > bin32/osloader.o -c osloader.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > osloader.c: In function `tagged_download': > osloader.c:564: warning: passing arg 3 of `xstart16' makes pointer=20 > from integer without a cast > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o = bin32/nfs.o=20 > -c nfs.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > gcc -DASK_BOOT=3D3 -DCONGESTED -DBACKOFF_LIMIT=3D7 = -DTRY_FLOPPY_FIRST=3D0=20 > -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=3D0x3F8=20= > -DCONSPEED=3D9600 -DCOMPARM=3D0x03 -DPCBIOS -DBOOT_FIRST=3DBOOT_NIC=20 > -DBOOT_SECOND=3DBOOT_NOTHING -DBOOT_THIRD=3DBOOT_NOTHING = -DFREEBSD_PXEEMU=20 > -DCONFIG_PCI -DCONFIG_ISA -Os -ffreestanding -fstrength-reduce=20 > -fomit-frame-pointer -mcpu=3Di386 -malign-jumps=3D1 -malign-loops=3D1=20= > -malign-functions=3D1 -Wall -W -Wno-format -DVERSION_MAJOR=3D5=20 > -DVERSION_MINOR=3D1 -DVERSION=3D\"5.1.3\" -DRELOC=3D0x20000 -o = bin32/pxe.o=20 > -c pxe.c > cc1: warning: -malign-loops is obsolete, use -falign-loops > cc1: warning: -malign-jumps is obsolete, use -falign-jumps > cc1: warning: -malign-functions is obsolete, use -falign-functions > pxe.c:15: parse error before "vm_offset_t" > pxe.c:15: warning: `struct v86' declared inside parameter list > pxe.c:15: warning: its scope is only this definition or declaration,=20= > which is probably not what you want > pxe.c:17: parse error before "pxenv" > pxe.c:17: warning: type defaults to `int' in declaration of `pxenv' > pxe.c:18: warning: braces around scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:18: warning: excess elements in scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:18: warning: excess elements in scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:18: warning: excess elements in scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:18: warning: excess elements in scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:18: warning: excess elements in scalar initializer > pxe.c:18: warning: (near initialization for `pxenv') > pxe.c:19: warning: excess elements in scalar initializer > pxe.c:19: warning: (near initialization for `pxenv') > pxe.c:20: `pxenv_t' undeclared here (not in a function) > pxe.c:20: warning: excess elements in scalar initializer > pxe.c:20: warning: (near initialization for `pxenv') > pxe.c:21: warning: excess elements in scalar initializer > pxe.c:21: warning: (near initialization for `pxenv') > pxe.c:22: warning: braces around scalar initializer > pxe.c:22: warning: (near initialization for `pxenv') > pxe.c:22: warning: excess elements in scalar initializer > pxe.c:22: warning: (near initialization for `pxenv') > pxe.c:22: warning: excess elements in scalar initializer > pxe.c:22: warning: (near initialization for `pxenv') > pxe.c:23: warning: excess elements in scalar initializer > pxe.c:23: warning: (near initialization for `pxenv') > pxe.c:24: warning: excess elements in scalar initializer > pxe.c:24: warning: (near initialization for `pxenv') > pxe.c:25: warning: excess elements in scalar initializer > pxe.c:25: warning: (near initialization for `pxenv') > pxe.c:26: warning: excess elements in scalar initializer > pxe.c:26: warning: (near initialization for `pxenv') > pxe.c:27: warning: excess elements in scalar initializer > pxe.c:27: warning: (near initialization for `pxenv') > pxe.c:28: warning: excess elements in scalar initializer > pxe.c:28: warning: (near initialization for `pxenv') > pxe.c:29: warning: excess elements in scalar initializer > pxe.c:29: warning: (near initialization for `pxenv') > pxe.c:30: warning: excess elements in scalar initializer > pxe.c:30: warning: (near initialization for `pxenv') > pxe.c:31: warning: excess elements in scalar initializer > pxe.c:31: warning: (near initialization for `pxenv') > pxe.c:32: warning: excess elements in scalar initializer > pxe.c:32: warning: (near initialization for `pxenv') > pxe.c:33: warning: excess elements in scalar initializer > pxe.c:33: warning: (near initialization for `pxenv') > pxe.c:34: warning: excess elements in scalar initializer > pxe.c:34: warning: (near initialization for `pxenv') > pxe.c:35: warning: braces around scalar initializer > pxe.c:35: warning: (near initialization for `pxenv') > pxe.c:35: warning: excess elements in scalar initializer > pxe.c:35: warning: (near initialization for `pxenv') > pxe.c:35: warning: excess elements in scalar initializer > pxe.c:35: warning: (near initialization for `pxenv') > pxe.c:36: warning: data definition has no type or storage class > pxe.c:60: parse error before "pxeemu_func_arg" > pxe.c:60: warning: type defaults to `int' in declaration of=20 > `pxeemu_func_arg' > pxe.c:60: warning: data definition has no type or storage class > pxe.c: In function `pxe_probe': > pxe.c:72: warning: return from incompatible pointer type > pxe.c:68: warning: unused parameter `len' > pxe.c: In function `pxe_download': > pxe.c:86: request for member `Length' in something not a structure or=20= > union > pxe.c:89: request for member `Checksum' in something not a structure=20= > or union > pxe.c:103: `vm_offset_t' undeclared (first use in this function) > pxe.c:103: (Each undeclared identifier is reported only once > pxe.c:103: for each function it appears in.) > pxe.c: In function `await_udp_pxe': > pxe.c:111: `t_PXEENV_UDP_READ' undeclared (first use in this function) > pxe.c:111: `s' undeclared (first use in this function) > pxe.c:108: warning: unused parameter `ival' > pxe.c:109: warning: unused parameter `ptype' > pxe.c: At top level: > pxe.c:122: parse error before "vm_offset_t" > pxe.c: In function `pxeemu_entry': > pxe.c:124: `x_v86_p' undeclared (first use in this function) > pxe.c:125: `x_pxeemu_v86_flag' undeclared (first use in this function) > pxe.c:126: `x_pxeemu_func_nr' undeclared (first use in this function) > pxe.c:127: `x_pxeemu_func_arg' undeclared (first use in this function) > pxe.c:145: `PXENV_GET_CACHED_INFO' undeclared (first use in this=20 > function) > pxe.c:147: `t_PXENV_GET_CACHED_INFO' undeclared (first use in this=20 > function) > pxe.c:147: `s' undeclared (first use in this function) > pxe.c:148: parse error before ')' token > pxe.c:152: `PXENV_PACKET_TYPE_BINL_REPLY' undeclared (first use in=20 > this function) > pxe.c:159: `vm_offset_t' undeclared (first use in this function) > pxe.c:149: warning: unused variable `buf' > pxe.c:166: `PXENV_UDP_OPEN' undeclared (first use in this function) > pxe.c:168: `t_PXENV_UDP_OPEN' undeclared (first use in this function) > pxe.c:168: parse error before ')' token > pxe.c:174: `PXENV_UDP_WRITE' undeclared (first use in this function) > pxe.c:176: `t_PXENV_UDP_WRITE' undeclared (first use in this function) > pxe.c:176: parse error before ')' token > pxe.c:200: `PXENV_UDP_READ' undeclared (first use in this function) > pxe.c:202: `t_PXENV_UDP_READ' undeclared (first use in this function) > pxe.c:202: parse error before ')' token > pxe.c:226: `PXENV_UDP_CLOSE' undeclared (first use in this function) > pxe.c:228: `t_PXENV_UDP_CLOSE' undeclared (first use in this function) > pxe.c:228: parse error before ')' token > pxe.c:233: `PXENV_UNLOAD_STACK' undeclared (first use in this = function) > pxe.c:235: `t_PXENV_UNLOAD_STACK' undeclared (first use in this=20 > function) > pxe.c:235: parse error before ')' token > pxe.c:240: `PXENV_UNDI_SHUTDOWN' undeclared (first use in this=20 > function) > pxe.c:242: `t_PXENV_UNDI_SHUTDOWN' undeclared (first use in this=20 > function) > pxe.c:242: parse error before ')' token > pxe.c:243: warning: implicit declaration of function `eth_reset' > pxe.c: In function `pxeemu_console_putc': > pxe.c:262: dereferencing pointer to incomplete type > pxe.c:263: dereferencing pointer to incomplete type > pxe.c:264: dereferencing pointer to incomplete type > pxe.c:265: dereferencing pointer to incomplete type > make: *** [bin32/pxe.o] Error 1 > make: Leaving directory `/tmp/ROMa14tx8' > > Please let us know that this happened. |
|
From: <ke...@us...> - 2002-12-30 05:38:59
|
>Think we might want to find a shorter suffix than nrv2b? Say just >'z'. > >nrv2b is quiet descriptive and unique but it I think its length may >get a little cumbersome. And if we only have one compression >algorithm we have no need to distinguish between the two. z sounds good to me. Do you want me to make the changes to the Makefiles and genrules.pl or do you want to do it yourself. |
53 messages has been excluded from this view by a project administrator.
