etherboot-developers Mailing List for Etherboot (Page 264)
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...> - 2002-02-09 00:34:36
|
>I just add the intel e1000 drive to cvs tree, etherboot-5.0. Great job thanks, it'll go into the next release. Hope lots of people can test it. |
|
From: Christopher Li <ch...@gn...> - 2002-02-09 00:25:33
|
Hi, I just add the intel e1000 drive to cvs tree, etherboot-5.0. The link setup code is copy from intel's linux driver 3.1.23 , with some modification to cut down the size. This driver should work with serveral different chipset. I can only test livengood though. Chris |
|
From: Marty C. <md...@th...> - 2002-02-06 20:05:17
|
Hello Etherboot Nation :) I just wanted to let everyone know that LinuxWorld Expo went great, and I wanted to express my gratitude to the other members of the Etherboot booth team, Markus Gutschke and my assistant Peter Vitello. You guys made the work a lot of fun. All told we did 22 hours of meeting, greeting, and demoing Etherboot and ROM burning last Wednesday through Friday. I'd also like to thank Compaq, the sponsor of the .ORG Pavillion for providing the booth space, which is worth many thousands of dollars. There were a lot of .ORGs at the show and the pavillion was very lively. The LTSP.org folks were in attendance and we sent people to each other's booths. There were the usual oh's and ah's over network booting, and a lot of people came by to say "thanks" for some project where Etherboot made a difference. The biggest requests were for wireless and pcmcia support, and also gigabit. So hopefully by the August show we'll have something in those areas. Lots of folks from IBM and other companies came by to see our demo and were impressed by the maturity and number of cards and booting methods we support, and of course the stats for rom-o-matic.net (http://rom-o-matic.net/stats/ were off the charts for January. There are some pictures from the show up at http://www.thinguin.org/linuxworldexpo/ We'll be working on the page as time goes by. Let's see, I guess in summary all I can say is that it was a good time, and that I think this Etherboot stuff may be catching on ;) 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...@th... Web: http://www.thinguin.org/ |
|
From: <ebi...@ln...> - 2002-02-05 23:43:23
|
ke...@us... (Ken Yap) writes: > Another issue is what to do with multiple drivers. Some kind of dynamic > linking would allow pulling in the right driver from storage to execute > in the limited memory. Dynamic linking would also pave the way for > callbacks. But memory constraints make implementation difficult. Perhaps > we should just grab all of low memory and give up on zImages. People > with unsufficient memory would have to stay with 5.0 and people with > enough memory could use 5.2. On the grab all of low memory side an easy trick is to allocate a bounce buffer at the top of memory. Put everything that would go in low memory there, and then copy it low, just before jumping to low memory. I have this working already in LinuxBIOS. I have just been to consumed with other things to port that to etherboot. That should make things much more flexible. The tricky part with etherboot is that there are so many exit points in the code. Eric |
|
From: <ke...@us...> - 2002-02-05 21:36:46
|
>> The issue of what to do with multiple NICs needs more thinking. The code >> in config.c is not flexible enough. > >Attempts to find the one true nic are ultimately doomed to failure - >one could use the first nic scanned which Etherboot can support, but >this wouldn't reliably match Linux's eth0 where multiple nic types are >present (Linux orders nics from the lowest to highest slot number of >nics which a driver recognises, but the order of driver installation >is essentially arbitrary). If this isn't what you need, then at build >time one might choose... There are lots of polciies one can adopt, including trying all interfaces. The current point is the current adhoc decision should be taken out of pci.c, pci.c should just enumerate the NICs and the pplicy can be implemented somewhere else. Eric's patches are a first step. If somebody wants to develop an architecture that allows flexible policies, I'd look upon that favaourably. As usual, submissions of working code get a head start. |
|
From: Peter L. <P.L...@sy...> - 2002-02-05 20:44:47
|
I don't think there's a single right way (and definitely no "obvious" right way) to cope with multiple nics; to add confusion I've just realised something about PXE that's been puzzled me for ages. > Yes, it's a bug, or rather, incomplete code. As the comment indicates it > was also to prefer the NIC that the bootrom is on (and it's probably > doing it wrong anyway), but as you point out, the first candidate always > wins. I noticed some time ago that with multiple NICs, PXE seems to prefer the *last* NIC in the scan order. Then it hit me - when you have multiple PXE NICs, the BIOS *initialises* PXE for *all* NICS starting (on all systems we have) from zero and counting up - but there is only one PXE context, so each new initialisation overwrites the last one. Then the BIOS initiates PXE - using the nic of *last* PXE rom to initialise... and, yes, if I wipe PXE from the last nic, PXE uses the last *initialised* nic, *not* the last *scanned*. I haven't tried mixing PXE nic types but I'll bet that this is true regardless. So for multiple NICs, Etherboot chained via PXE is usually guaranteed to use a different nic from PXE; this is inconvenient where nics are not connected to the same LAN and can't all see the same dhcp server. Vasil has a locally hacked Etherboot which scans backwards to fix this. So Etherboot is started by PXE, it might be a useful short term fix to scan backwards by default. > The issue of what to do with multiple NICs needs more thinking. The code > in config.c is not flexible enough. Attempts to find the one true nic are ultimately doomed to failure - one could use the first nic scanned which Etherboot can support, but this wouldn't reliably match Linux's eth0 where multiple nic types are present (Linux orders nics from the lowest to highest slot number of nics which a driver recognises, but the order of driver installation is essentially arbitrary). If this isn't what you need, then at build time one might choose... Scan... 0 up to 0xff 0xff down to 0 start at X, up or down as per a flag Arbitrary list of slot IDs [ for highly predictable hardware ] Prompt the user to choose. My feeling is still that it's "right" to DISCOVER on all available nics and choose between the replies, certainly for method of running Etherboot (modular bios, linuxbios, disk) which are "nic agnostic". If one really wants to associate an image with a nic (maybe then one it is installed in, but that's not a requirement), encode a preference for the nic's MAC address. This is reliable - unlike slot number (fails if the nic is moved) or second guessing a slot scan algorithm (fails if another nic is inserted); each image would prefer its "own" nic, but fall back to one of the default algorithms above if it is not present. The association of image with nic is, after all, made at install time. Actually, it occurs to me that one can ask PXE which MAC address UNDI is using, so that Etherboot chained from PXE can prefer the nic with that MAC address (but still fall through to the others). Got an hour or two spare, Vasil? |
|
From: Peter <pet...@we...> - 2002-02-04 22:56:44
|
hi, today I tried to boot a 850 MHz athlon system with a K7S5A SIS 735 chipset and a rtl8139 network controller with etherboot. ROM seg. 0x0800 length 0x4000 reloc 0x9400 5.0.5 (GPL) Tagged ELF for [RTL8139] Found Realtek 8139 at 0xd400, ROM adress 0xff40 Probing [RTL8139] - ioaddr 0XD400, addr 00:E0:7D:8C:12:AB 100Mbps full-duplex Searching for server .... .... then nothing more happens I realized that etherboot puts a wrong number in the type field of the ethernet header. When I put a printf (..); or a for(i=0; i<10; i++) in the rtl_transmit in rtl8139.c everything is fine. I`m useing etherboot 5.0.5 and gcc 3.0.3 1st packet: 590 Bytes source: 00:E0:7D:8C:12:AB dest: ff:ff:ff:ff:ff:ff protocol: LLC info: IEEE802.3 --- snip --- 0000 ff ff ff ff ff ff 00 e0 7d 8c 12 ab 00 00 45 00 ÿÿÿÿÿÿ.à }..«..E. 0010 02 40 00 00 00 00 3c 11 7c ae 00 00 00 00 ff ff .@....<. |®....ÿÿ 0020 ff ff 00 44 00 43 02 2c fa 21 01 01 06 00 7d 9e ÿÿ.D.C., ú!....}. 0030 c8 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 È8...... ........ 0040 00 00 00 00 00 00 00 e0 7d 8c 12 ab 00 00 00 00 .......à }..«.... 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0110 00 00 00 00 00 00 63 82 53 63 35 01 01 39 02 05 ......c. Sc5..9.. 0120 dc 3c 0d 45 74 68 65 72 62 6f 6f 74 2d 35 2e 30 Ü<.Ether boot-5.0 0130 37 04 01 03 0c 2b ff 00 00 00 00 00 00 00 00 00 7....+ÿ. ........ 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ...... --- snip --- .. 10 seconds .. 2nd packet: 590 Bytes source: 00:E0:7D:8C:12:AB dest: ff:ff:ff:ff:ff:ff protocol: 0xc8f8 info: Ethernet II --- snip --- 0000 ff ff ff ff ff ff 00 e0 7d 8c 12 ab c8 f8 45 00 ÿÿÿÿÿÿ.à }..«ÈøE. 0010 02 40 00 00 00 00 3c 11 7c ae 00 00 00 00 ff ff .@....<. |®....ÿÿ 0020 ff ff 00 44 00 43 02 2c fa 17 01 01 06 00 7d 9e ÿÿ.D.C., ú.....}. 0030 c8 38 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 È8...... ........ 0040 00 00 00 00 00 00 00 e0 7d 8c 12 ab 00 00 00 00 .......à }..«.... 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0110 00 00 00 00 00 00 63 82 53 63 35 01 01 39 02 05 ......c. Sc5..9.. 0120 dc 3c 0d 45 74 68 65 72 62 6f 6f 74 2d 35 2e 30 Ü<.Ether boot-5.0 0130 37 04 01 03 0c 2b ff 00 00 00 00 00 00 00 00 00 7....+ÿ. ........ 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ...... --- snap --- .. 20 seconds .. 3rd packet: 590 Bytes source: 00:E0:7D:8C:12:AB dest: ff:ff:ff:ff:ff:ff protocol: 0xc8f8 info: Ethernet II --- snip --- 0000 ff ff ff ff ff ff 00 e0 7d 8c 12 ab c8 f8 45 00 ÿÿÿÿÿÿ.à }..«ÈøE. 0010 02 40 00 00 00 00 3c 11 7c ae 00 00 00 00 ff ff .@....<. |®....ÿÿ 0020 ff ff 00 44 00 43 02 2c fa 03 01 01 06 00 7d 9e ÿÿ.D.C., ú.....}. 0030 c8 38 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 È8...... ........ 0040 00 00 00 00 00 00 00 e0 7d 8c 12 ab 00 00 00 00 .......à }..«.... 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0110 00 00 00 00 00 00 63 82 53 63 35 01 01 39 02 05 ......c. Sc5..9.. 0120 dc 3c 0d 45 74 68 65 72 62 6f 6f 74 2d 35 2e 30 Ü<.Ether boot-5.0 0130 37 04 01 03 0c 2b ff 00 00 00 00 00 00 00 00 00 7....+ÿ. ........ 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ...... --- snap --- Peter Koegel |
|
From: <ke...@us...> - 2002-02-04 12:45:42
|
>I agree that in the general case more thought needs to be put into how >to handle multiple NICs. However, in my case, I have a (mostly) known >environment that I need to support up to five NICs in, where all the >NICs are the same - almost (there is a mixture of Intel 82557s, >82558s, & 82559s.) All the same submit your patches when they work and they can be generalised later. It's probably the case the pci.c should not be deciding which NIC to use, and should return the list for config.c to deal with. This can be done without breaking any code, pci.c returns results using a pointer to a structure, it just needs to be a pointer to an array for multiple NICs. |
|
From: Preston W. <pw...@ra...> - 2002-02-04 12:36:08
|
First, I apologize for sending the first post to the users list. I know better; I just wasn't thinking. >The issue of what to do with multiple NICs needs more thinking. The code >in config.c is not flexible enough. The developers list is probably a >better place to discuss this, hence posting is redirected there. There >have been an exchange of opinions in the past but no code came out of >that. > >Another issue is what to do with multiple drivers. Some kind of dynamic >linking would allow pulling in the right driver from storage to execute >in the limited memory. Dynamic linking would also pave the way for >callbacks. But memory constraints make implementation difficult. Perhaps >we should just grab all of low memory and give up on zImages. People >with unsufficient memory would have to stay with 5.0 and people with >enough memory could use 5.2. I agree that in the general case more thought needs to be put into how to handle multiple NICs. However, in my case, I have a (mostly) known environment that I need to support up to five NICs in, where all the NICs are the same - almost (there is a mixture of Intel 82557s, 82558s, & 82559s.) What I'm trying out is this. Build a list of available NICs, and then have Etherboot try the NICs in order. In the environment I'm working under, I've set up one DHCP server to reply with the VCI "Etherboot", so the system will always boot from a given network regardless of which physical NIC is plugged into it. All other interfaces are configured via DHCP as well. Obviously, I have -DREQUIRE_VCI_ETHERBOOT enabled. -Preston |
|
From: <ke...@us...> - 2002-02-04 11:57:42
|
>The if statement below will always evaluate to true, since pci_ioaddr
>is always zero. I searched for all references to pci_ioaddr, and the
>two shown below are the only two.
>
>Etherboot source code version 5.0.5
>In pci.c:scan_bus()
>
>...
> unsigned int pci_ioaddr = 0;
>...
> if (pci_ioaddr == 0 || romaddr == ((unsigned long) rom.rom_segment << 4))
> {
>...
> }
>...
Yes, it's a bug, or rather, incomplete code. As the comment indicates it
was also to prefer the NIC that the bootrom is on (and it's probably
doing it wrong anyway), but as you point out, the first candidate always
wins.
The issue of what to do with multiple NICs needs more thinking. The code
in config.c is not flexible enough. The developers list is probably a
better place to discuss this, hence posting is redirected there. There
have been an exchange of opinions in the past but no code came out of
that.
Another issue is what to do with multiple drivers. Some kind of dynamic
linking would allow pulling in the right driver from storage to execute
in the limited memory. Dynamic linking would also pave the way for
callbacks. But memory constraints make implementation difficult. Perhaps
we should just grab all of low memory and give up on zImages. People
with unsufficient memory would have to stay with 5.0 and people with
enough memory could use 5.2.
|
|
From: Gregg C L. <dr...@wo...> - 2002-02-02 05:18:09
|
Hello from Gregg C Levine normally with Jedi Knight Computers (Explanation first, then the question.) I have created two lilo bootable images from the http://rom-o-matic.net/ site, and installed them, on my other computer. I use GRUB to boot it, and since I had already confirmed the obvious about those images, I decided to find out, if the booatloader could launch them. It could do that. I have Internet Connection Sharing installed here, it uses a DHCP server to set the IP address of this one, and any others connected to it. This one is running Windows 98SE, I was unsure if the DHCP client on the other one, a Linux box would be able to read it. It can. It also reacted to the server when the images were booted. But complained about the TFTP server, and the selected images. (Now the question.) I have installed a TFTP server here. To send a kernel, to the requesting machine, I believe I need to run the NBI program against it, so Ether Boot can read it, and launch it? Correct? I am using the kernel, and the initial root image from Red Hat 7.2. For that image, do I need to do anything else?=20 ------------------- Gregg C Levine han...@wo... ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."=A0 Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) |
|
From: Gregg C L. <dr...@wo...> - 2002-01-31 01:31:48
|
Hello from Gregg C Levine normally with Jedi Knight Computers News! Grub will bring up a ROM image created from the pages that Marty has created. It is for a 3C905C card. Further details to be provided later. ------------------- Gregg C Levine dr...@wo... ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."=A0 Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) |
|
From: Marty C. <md...@th...> - 2002-01-30 18:55:15
|
We (Marty, Markus, Peter) made it to LinuxWorld and the webcam is up: http://www.thinguin.org/linuxworldexpo/webcam/ We've met lots of Etherboot users and a lot people are discovering the technology and enjoying it. It's great fun and we're happy to be here. 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...@th... Web: http://www.thinguin.org/ |
|
From: Marty C. <md...@th...> - 2002-01-30 06:13:35
|
On 1/29/2002 9:31 AM Hanna James P Civ AFRL/IFTC Jam...@rl... wrote: >Thanks for the suggestion Ken. I downloaded the boot image for the SMC >1211 >and burned a new CD. The CD booted and DHCP'd and loaded the kernel. Excellent! You're on your way. You've made me think of something, and I wanted to mention it in case anyone wants to do some further investigation: One of the main manifestation of GCC bugs when compiling Etherboot is that the packet transmission buffer is corrupted. I think the bug has something to do with certain versions of GCC not respecting alignment requests. For example, here is the directive to allocate the transmit buffer in rtl8139.c: static unsigned char tx_buffer[TX_BUF_SIZE] __attribute__((aligned(4))); I'm wondering if GCC 2.96 (and possibly other versions) fail to align this buffer properly, which makes the card unable to properly do DMA with it. I can reliably get this to occur by trying to compile an rtl8139 lzrom image with gcc 2.96. Curiously the floppy version will work, but when I burn a ROM with the .lzrom file, it fails. I'd love to know that the difference is. I am betting that it is something we could work around by doing our own pointer arithmetic and saying something (roughly) like: static unsigned char tx_buffer[TX_BUF_SIZE+4]; (char *) tx_buffer &= 0xFFFFFFF0; This is a guess, but the kind of bugs we're seeing seem to suggest possibly blown alignment. >The problem that I am having now is that when the kernel tries to bring up >the network interface it can't. A message is printed about the 3c59x >network >driver with a link to scyld software. It seems to be expecting the box to >have a 3COM card in it even though it mentions the RTL8138 before the >successful DHCP???!!!!??? >Am I still doing something wrong??? >SIGHUH This looks like the wrong kernel. Try the one at: http://prdownloads.sourceforge.net/ltsp/lts_kernel_rtl8139-2.2.tgz There is a vmlinuz.all kernel that does not work with rtl8139 cards, though it seems like it ought to. If you haven't already, you should check out: http://www.ltsp.org/ where there is a wealth of information on setting up network booted workstations. Once the kernel is loaded, Etherboot has mostly completed its work, and that's where other projects do their magic. I hope this is helpful to you, and let us (the list) know how things go. 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...@th... Web: http://www.thinguin.org/ |
|
From: <ebi...@ln...> - 2002-01-27 01:39:21
|
ke...@us... (Ken Yap) writes: > >Ken you also want to look at the changes for the linux boot protocol > >version 2.3. The kernel cannot handle ramdisk loaded above 890MB or > >so. And with 2.3 it tells you exactly how high in memory the kernel > >can cope with the ramdisk. > > > >The kernel side of that has gone into the latest prepatches of both > >2.5 & 2.4. > > Good idea, I'll hack 2.3 support in sometime. By the way do you know why > the kernel can't handle ramdisk immediately after it? First the reasons for the problem are mostly historical. The Linux kernel that first supported initrd's allocated some memory for page tables immediately after the kernel image. And the bootloaders were made to work around that problem. And no one has pushed back and asked that question yet of the kernel developers. I want to fix that during the 2.5 development cycle but we will see what happens. For 2.4.10+ it is always safe to load the initrd at 8M, (but not everyone has that much ram...) Other pieces of the puzzle are: Since the kernel is compressed you have to load the ramdisk after the decompressed kernel image. Which makes it a little trickier. Also currently the kernel allocates the bootmem bitmap that tells it what memory it can allocate immediately after it's kernel image. With 2.4.10+ this is the only data structures that would need to be allocated differently to allow loading immediately after the kernel image. Eric |
|
From: <ke...@us...> - 2002-01-27 01:07:27
|
>Ken you also want to look at the changes for the linux boot protocol >version 2.3. The kernel cannot handle ramdisk loaded above 890MB or >so. And with 2.3 it tells you exactly how high in memory the kernel >can cope with the ramdisk. > >The kernel side of that has gone into the latest prepatches of both >2.5 & 2.4. Good idea, I'll hack 2.3 support in sometime. By the way do you know why the kernel can't handle ramdisk immediately after it? |
|
From: <ebi...@ln...> - 2002-01-27 00:58:06
|
ke...@us... writes: > Some people may be having problems with initrd on BIOSes that implement > the E820 memory size function. One problem is that mknbi didn't use the > E820 function and in some cases overestimages memory. This in turn > causes the kernel to complain that the initrd is loaded too high. I've > added the E820 capability to mknbi, using Eric Biederman's code in > Etherboot. You can get a test version of mknbi-1.2-7 from: > > http://etherboot.sourceforge.net/mknbi-1.2-7rc1.tar.gz > > It would appreciated if affected users give this a whirl and report > if this solves the problem. Ken you also want to look at the changes for the linux boot protocol version 2.3. The kernel cannot handle ramdisk loaded above 890MB or so. And with 2.3 it tells you exactly how high in memory the kernel can cope with the ramdisk. The kernel side of that has gone into the latest prepatches of both 2.5 & 2.4. > A temporary workaround available to 1.2-6 users is to use the kernel > parameter mem= to specify the real top of memory. mknbi 1.2-6 takes note > of that. Eric |
|
From: <ke...@us...> - 2002-01-27 00:52:51
|
Some people may be having problems with initrd on BIOSes that implement the E820 memory size function. One problem is that mknbi didn't use the E820 function and in some cases overestimages memory. This in turn causes the kernel to complain that the initrd is loaded too high. I've added the E820 capability to mknbi, using Eric Biederman's code in Etherboot. You can get a test version of mknbi-1.2-7 from: http://etherboot.sourceforge.net/mknbi-1.2-7rc1.tar.gz It would appreciated if affected users give this a whirl and report if this solves the problem. A temporary workaround available to 1.2-6 users is to use the kernel parameter mem= to specify the real top of memory. mknbi 1.2-6 takes note of that. |
|
From: <ke...@us...> - 2002-01-25 23:41:15
|
>here's a patch (against etherboot 5.0.5) of mkQNXnbi, which I >contributed a couple of years ago. Thanks, it will go in the next version. |
|
From: Anders L. <an...@al...> - 2002-01-25 22:31:02
|
Hi, here's a patch (against etherboot 5.0.5) of mkQNXnbi, which I contributed a couple of years ago. In the meantime, I've installed it at two sites for a total of appr. 30 diskless QNX4 workstations. I've also had to answer questions from a surprisingly high number of other Etherboot users and thereby learned that my documentation was slightly flawed. Here's my attempt to fix the docs and examples. cheers Anders Larsen |
|
From: Chris T. <chr...@io...> - 2002-01-25 13:11:22
|
Hello Etherboot people -
We have successfully Etherbooted a PC fitted with a Kingston KNE2021LC =
card (=3DDM9008 chip on 16-bit ISA) with 4.6.12, initially from the =
brilliant Rom-o-matic site and now by working from the source. The =
DM9008 is billed by Davicom as "fully compliant with NE2000 software" =
and Etherboot on a PC bears this out.
Our goal is to Etherboot a diskless 386EX design with the DM9008. The =
architecture is broadly AT-compatible, but with no kbd or VGA (we use a =
serial console), and there is RAM all the way up to E000:0. Etherboot =
correctly detects an NE2000 at 0x280, with the correct MAC address. The =
board then emits valid DHCP request packets, (as monitored by Wild =
Packets' EtherPeek tool), and our server sends a valid DHCP offer. =
However, Etherboot never recognises a response, and loops on "No server =
found" and "<sleep>".
As an experiment, I instrumented the poll() routine in ns8390.c to =
indicate Overrun conditions [using putchar('V')] and show the value of =
rstat [using printf("%b ", rstat)]. Our board sees continuous Overruns, =
with rstat =3D 0x21, even with no patch lead in the RJ-45. (There is no =
noise on the TPRX+ and TPRX- pins.)
We would be grateful for any clues as to why the 9008 is not receiving =
correctly, and would dearly like NOT to have to mess with the code (!).
One weirdness - when the instrumented code is blown into ROM for the PC =
NIC, it fails to boot the PC, instead printing endless 0x21's. Is there =
some critical timing in the await_reply() stuff that I've missed?
TIA...
- Chris Tucker
Engineering Director
Io Limited
CB5 0HT
UK
+44 (0)1638 742 390 (voice)
www.ioltd.co.uk
This email may contain confidential information. If you are not a named =
recipient, or believe it may have been sent to you in error, please =
inform Io Limited at once. All outbound email is scanned for viruses, =
but we cannot guarantee that it is virus-free when you receive it.
|
|
From: <ebi...@ln...> - 2002-01-16 22:56:04
|
ke...@us... (Ken Yap) writes: > >> No, all memory use is confined to 0x90000 to 0x9ffff, except for a > >> couple of locations in the floppy boot block. > > > >O.k. Cool that is what it felt like. If that is the case > >then it ``should be'' fairly straight forward to implement. I'll > >give it a look in a little bit. > > But also the loader/decompressor that moves Etherboot from ROM to its > execution address uses temporary memory at 0x80000 upwards. I just looked at it to see what it would take. The nasty part with etherboot are the multiple exit points. With each exit point passing data with a different format. So I would probably need to modify each exit point out of the way... So at this point if I implemented it I would probably implement a different elf loader. And then let those who cared about their weird modifications to the elf loader either use the old one or merge with me. Eric |
|
From: <ke...@us...> - 2002-01-15 21:29:30
|
>> No, all memory use is confined to 0x90000 to 0x9ffff, except for a >> couple of locations in the floppy boot block. > >O.k. Cool that is what it felt like. If that is the case >then it ``should be'' fairly straight forward to implement. I'll >give it a look in a little bit. But also the loader/decompressor that moves Etherboot from ROM to its execution address uses temporary memory at 0x80000 upwards. |
|
From: <ebi...@ln...> - 2002-01-15 21:19:23
|
ke...@us... (Ken Yap) writes: > >Ken does etherboot use anything besides statics variables and a stack? > > No, all memory use is confined to 0x90000 to 0x9ffff, except for a > couple of locations in the floppy boot block. O.k. Cool that is what it felt like. If that is the case then it ``should be'' fairly straight forward to implement. I'll give it a look in a little bit. Eric |
|
From: <ke...@us...> - 2002-01-15 21:14:09
|
>Ken does etherboot use anything besides statics variables and a stack? No, all memory use is confined to 0x90000 to 0x9ffff, except for a couple of locations in the floppy boot block. |
53 messages has been excluded from this view by a project administrator.
