etherboot-developers Mailing List for Etherboot (Page 198)
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: Samuel C. <scl...@li...> - 2003-04-30 02:02:20
|
>Does that one work under Linux? The early EEPRO100As are not even >supported under Linux. I don't believe so. Its not an EEPRO100A. It is based off of the 82557 chipset, but it has an i960 CPU on card for offloading... Supported under NT at one time as I recall... -Sam |
|
From: <ke...@us...> - 2003-04-30 01:53:25
|
>well and if your really looking for obscure cards, I have an Intel PRO100 >Intelligent Server 10/100 card that's up for grabs for anyone brave enough >to try it... Does that one work under Linux? The early EEPRO100As are not even supported under Linux. |
|
From: Samuel C. <scl...@li...> - 2003-04-30 01:36:44
|
>I prefer to pay less that 10 bucks for my NICs, especially since my >collection far exceeds the number of PCs that I have (and probably free >slots). Of course if I come across a cheap source of GB cards I will >pitch in on that. well and if your really looking for obscure cards, I have an Intel PRO100 Intelligent Server 10/100 card that's up for grabs for anyone brave enough to try it... -Sam |
|
From: <ke...@us...> - 2003-04-30 01:22:08
|
>I prefer to pay less that 10 bucks for my NICs, especially since my >collection far exceeds the number of PCs that I have (and probably free >slots). Of course if I come across a cheap source of GB cards I will >pitch in on that. Ok I found the number of the chip that Natsemi made, it's 83820 and the driver is ns83820.c in the Linux tree. According to the comments, these are the boards that use it: * Cameo SOHO-GA2000T SOHO-GA2500T * D-Link DGE-500T * PureData PDP8023Z-TG * SMC SMC9452TX SMC9462TX * Netgear GA621 But I have only seen one board with it, the 8139s have swamped the cheap NIC market. :-( But the other day I saw a cheap AN983 (Tulip). :-) If you collect ISA cards, occasionally someone asks about the Intel EtherExpress, and the Digital Etherworks series. >> Then of course there are the wireless NICs which are very popular. > >Are the wireless pci cards any different from standard pci NICs? I should think they look just like any other PCI NIC on the bus, but there is the encryption key setting. Anybody know different? |
|
From: Samuel C. <scl...@li...> - 2003-04-30 01:14:06
|
>Sam I forget the issue that you are having. Is this a version of a card >that has a driver or are you trying to port the driver? This is is a port of the linux e1000 driver for the 82547EI. There are changes in the linux driver and I've been working with Georg Baum doing testing and we have the card detected, but no traffic leaves the card... I'd be happy to send you what we have... -Sam |
|
From: Timothy L. <tl...@ro...> - 2003-04-30 00:52:29
|
> Well, I've been trying my best on getting this new Intel Gig nic working > to > no avail... Thats going to be a real popular one, real quick as it'll be > coming as a gig LOM solution on a bunch of new Intel boards... Sam I forget the issue that you are having. Is this a version of a card that has a driver or are you trying to port the driver? |
|
From: Timothy L. <tl...@ro...> - 2003-04-30 00:50:48
|
> If you're looking for new frontiers there are the gigabit Ethernet > boards, don't know which ones are widespread other than the Intel e1000. I prefer to pay less that 10 bucks for my NICs, especially since my collection far exceeds the number of PCs that I have (and probably free slots). Of course if I come across a cheap source of GB cards I will pitch in on that. > Then of course there are the wireless NICs which are very popular. Are the wireless pci cards any different from standard pci NICs? Tim |
|
From: <ke...@us...> - 2003-04-29 22:35:16
|
>I thought it might be a good idea to get a list of NIC drivers that are >in demand but Etherboot does not yet support. If we had this list >somewhere (task list on the project page?) we may be able to get them >conquered. > >Right now I know of: > >1) pcnet32 (I am currently working on this one) >2) tlan > >Are there any other ones that are in demand? I've just looked at Donald Becker's web page. There was another Natsemi 100 Mb chip (not the 8381x) that appeared on cheap boards but that seems to have sunk without a trace. I can't think of any other PCI NICs. If you're looking for new frontiers there are the gigabit Ethernet boards, don't know which ones are widespread other than the Intel e1000. Then of course there are the wireless NICs which are very popular. |
|
From: Samuel C. <scl...@li...> - 2003-04-29 21:27:42
|
Well, I've been trying my best on getting this new Intel Gig nic working to no avail... Thats going to be a real popular one, real quick as it'll be coming as a gig LOM solution on a bunch of new Intel boards... -Sam At 06:19 PM 4/29/2003 -0300, Timothy Legge wrote: >Hi All > >I thought it might be a good idea to get a list of NIC drivers that are >in demand but Etherboot does not yet support. If we had this list >somewhere (task list on the project page?) we may be able to get them >conquered. > >Right now I know of: > >1) pcnet32 (I am currently working on this one) >2) tlan > >Are there any other ones that are in demand? > >Tim > > > >------------------------------------------------------- >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: Timothy L. <tl...@ro...> - 2003-04-29 21:19:53
|
Hi All I thought it might be a good idea to get a list of NIC drivers that are in demand but Etherboot does not yet support. If we had this list somewhere (task list on the project page?) we may be able to get them conquered. Right now I know of: 1) pcnet32 (I am currently working on this one) 2) tlan Are there any other ones that are in demand? Tim |
|
From: <ebi...@ln...> - 2003-04-29 02:43:41
|
"Ashish anand" <ash...@in...> writes: > Hello, > > I am not getting any tftp response from tftp sever which otherwise works > perfectly well with other tftp clients. > > I am using etherbot-5.1.7. > > followinmg is the tftp read request packet sent to tftp server on my pc > displayed by tcpdump. > bu not a single reply sent to tftp client running on my target. > > 16:52:16.061310 eth0 < 150.1.20.50.2001 > shashiha.tftp: 32 RRQ > "linux.srec" > 4500 003c 0000 0000 3c11 2a6e 9601 1432 > 9601 140f 07d1 0045 0028 ed46 0001 6c69 > 6e75 782e 7372 6563 006f 6374 6574 0062 > 6c6b 7369 7a65 0031 3433 3200 0100 0000 > > what can be the possible reasons .. > Is the packet being discarded. Have you verified you have proper IP and UDP checksums? I seem to recall something about a non-standard environment. So it is possible that something basic like the IP or UDP checksum, is broken. Eric |
|
From: <ke...@us...> - 2003-04-29 02:42:47
|
>For the most part I have come to a halt on working with memtest86. It >works fairly well, and I find more problems by logging ECC errors >under Linux with a machine at high stress levels. > >The prime advantage of merging memtest86 into etherboot would be a >portability increase. If anybody is brave enough, have a go... >Although if we go that direction we might wind up merging in GRUB >next. Arrgh no. (Makes the sign of the cross.) :-) |
|
From: <ebi...@ln...> - 2003-04-29 02:39:54
|
ke...@us... (Ken Yap) writes: > >I'd like to know which RAM regions I can use safely during etherboot > >runs. I cannot use -DRELOCATE at the moment as this crashes my virtual > >machine with the lance driver, but one day it probably should work. > >Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? > > Why not a normal BSS buffer within Etherboot itself? A major point of relocation is that etherboot occupies no memory < 1MB, as that memory is in high demand. So a normal buffer allocated like: static unsigned char buffer[1024]; should work, and because it has no initializer gcc will put it in the bss section so it won't consume memory until runtime. Keeping the memory in etherboot will mean that etherboot will verify that it is not stomped by a loaded image. Anything like a static location is up for grabs by the image that is being loaded. When you get something working I will find it interesting. This definitely calls for an extension to mkelf or similar. Eric |
|
From: <ebi...@ln...> - 2003-04-29 02:32:20
|
ke...@us... (Ken Yap) writes: > >How difficult would it be to hack memtest86 to use the etherboot codebase to > >generate UDP packets to send to a syslog server? The syslog service can be > >setup to log to a different file based on IP address. This would allow > >testing of a large array of PCs, and logging of the test results for > >record-keeping purposes. > > > >The syslog facility might also be of use to debug driver issues - ones that > >did not prevent sending of UDP packets. > > It would probably be easier to make memtest86 an optional piece of code > that can be compiled in for Etherboot. Reason is because of the NIC > driver and support routines. If you put those in memtest86, they have to > be maintained and may diverge. Memtest86 is I think the simpler codebase > and easier to absorb. I don't know how this will play with memtest86's > author or licensing (I think it's GPL). Embrace and extend? Another > compelling use for Etherboot? :-) Yes memtest86 is GPL'd. It would take some work but finding the infrastructure to do a merger is an interesting feet. memtets86 currently does relocation as well but of a different sort, and handling all of the issues the relocation creates could be an interesting issue going in either direction. > >The NIC.C file in the current tree seems a prime candidate for further > >splitting to multiple files based on protocol (i.e., one for DHCP, one for > >TFTP, one for UDP, etc.), this also affects the Makefiles, but the advantage > >would be ease of (ab)use to implement etherboot routines for other purposes, > >such as the memtest86 hack. > > Have you had a look at 5.1? A lot has been cleaned up. Also 5.1 runs > relocated from the top of memory and I'm guessing that it will be easy > to exclude that area from testing. memtest86 periodically relocates itself during testing so that all of memory may be tested. There may be some sense in splitting nic.c I have not thought about it. For the most part I have come to a halt on working with memtest86. It works fairly well, and I find more problems by logging ECC errors under Linux with a machine at high stress levels. The prime advantage of merging memtest86 into etherboot would be a portability increase. Although if we go that direction we might wind up merging in GRUB next. Eric |
|
From: <ke...@us...> - 2003-04-29 02:14:19
|
>How difficult would it be to hack memtest86 to use the etherboot codebase to >generate UDP packets to send to a syslog server? The syslog service can be >setup to log to a different file based on IP address. This would allow >testing of a large array of PCs, and logging of the test results for >record-keeping purposes. > >The syslog facility might also be of use to debug driver issues - ones that >did not prevent sending of UDP packets. It would probably be easier to make memtest86 an optional piece of code that can be compiled in for Etherboot. Reason is because of the NIC driver and support routines. If you put those in memtest86, they have to be maintained and may diverge. Memtest86 is I think the simpler codebase and easier to absorb. I don't know how this will play with memtest86's author or licensing (I think it's GPL). Embrace and extend? Another compelling use for Etherboot? :-) >The NIC.C file in the current tree seems a prime candidate for further >splitting to multiple files based on protocol (i.e., one for DHCP, one for >TFTP, one for UDP, etc.), this also affects the Makefiles, but the advantage >would be ease of (ab)use to implement etherboot routines for other purposes, >such as the memtest86 hack. Have you had a look at 5.1? A lot has been cleaned up. Also 5.1 runs relocated from the top of memory and I'm guessing that it will be easy to exclude that area from testing. |
|
From: Robb M. <ma...@ac...> - 2003-04-29 01:02:36
|
Hi Eric, You did extensive restructuring of the Etherboot codebase, and also did major surgery on memtest86. There is a natural (?) extension of the two applications that I have been pondering for some time. Etherbooting memtest86 is great, and a great way to test / burn-in test new PCs, with one exception - it requires a screen to view output and that does not provide a way to record failures. I realize you can redirect the console via the serial port, but that is not very useful, and still requires another working IO channel (a UART, instead of video). Given that memtest86 is most useful to validate untrusted hardware, it would make sense to minimize the requirements of the hardware to test. Since Ethernet is already required to etherboot, it is assumed to be a basic requirement. How difficult would it be to hack memtest86 to use the etherboot codebase to generate UDP packets to send to a syslog server? The syslog service can be setup to log to a different file based on IP address. This would allow testing of a large array of PCs, and logging of the test results for record-keeping purposes. The syslog facility might also be of use to debug driver issues - ones that did not prevent sending of UDP packets. The NIC.C file in the current tree seems a prime candidate for further splitting to multiple files based on protocol (i.e., one for DHCP, one for TFTP, one for UDP, etc.), this also affects the Makefiles, but the advantage would be ease of (ab)use to implement etherboot routines for other purposes, such as the memtest86 hack. What do you think? Robb. |
|
From: Ashish a. <ash...@in...> - 2003-04-28 11:21:12
|
Hello,
I am not getting any tftp response from tftp sever which otherwise works
perfectly well with other tftp clients.
I am using etherbot-5.1.7.
followinmg is the tftp read request packet sent to tftp server on my pc
displayed by tcpdump.
bu not a single reply sent to tftp client running on my target.
16:52:16.061310 eth0 < 150.1.20.50.2001 > shashiha.tftp: 32 RRQ
"linux.srec"
4500 003c 0000 0000 3c11 2a6e 9601 1432
9601 140f 07d1 0045 0028 ed46 0001 6c69
6e75 782e 7372 6563 006f 6374 6574 0062
6c6b 7369 7a65 0031 3433 3200 0100 0000
what can be the possible reasons ..
Is the packet being discarded.
Best Regards,
Ashish Anand
|
|
From: <ke...@us...> - 2003-04-28 00:22:12
|
>I'd like to know which RAM regions I can use safely during etherboot >runs. I cannot use -DRELOCATE at the moment as this crashes my virtual >machine with the lance driver, but one day it probably should work. >Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? Why not a normal BSS buffer within Etherboot itself? |
|
From: Anselm M. H. <an...@ho...> - 2003-04-28 00:01:17
|
Hello Ken, Saturday, April 26, 2003, 5:20:16 PM, you wrote: > Which is why you want a conceptual layer in between to separate out how > the key is fetched, it may not be with the image, e.g. it may be in a > smart card. But that can come later. Just some status report: I added one Config option (not in CVS, local only) called SAFEBOOTMODE which currently can only be set to "1" (which means key is prepended to image). Assuming you have image.nbi and want it transferred to new "SafeBoot" format (hey, perhaps later someone implements elf block or nbi part=key support... for now, it's easier this way), go like this: If you don't have a 512bit key yet: openssl genrsa -out rsa.key 512 chmod 400 rsa.key temp1.txt Create the checksum: dd if=/dev/zero of=md5sum.bin bs=32 count=1 md5sum < image.nbi | sed s/.$// > mdsum.bin Encrypt the md5 sum with the private key: openssl rsautl -in md5sum.bin -out mdsum.sig -inkey rsa.key -sign -raw Prepend block to image: dd if=/dev/zero of=temp bs=32 count=15 cat md5sum.sig temp image.nbi > image.snbi rm temp md5sum.bin md5sum.sig MD5 digesting yet works perfect and I hope I'm more than half way through this ugly public key stuff :-) I'd like to know which RAM regions I can use safely during etherboot runs. I cannot use -DRELOCATE at the moment as this crashes my virtual machine with the lance driver, but one day it probably should work. Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? Best regards, Anselm Martin Hoffmeister Stockholm Projekt Computer-Service <an...@ho...> -- Merke: Nicht das OS macht dich zu einem interessanteren Gespraechs- partner, sondern das, was du darueber weisst. Und die Toleranz macht dich dann noch zu einem liebenswerten Gespraechspartner. (Buelent Caliskan in de.org.ccc) |
|
From: <ke...@us...> - 2003-04-27 13:47:58
|
>I am using eepro100.c for 82557 for tftp booting and after comparing >with log of tcpdump on other remote hosts , >i found that i am losing some broadcast packets .. >Is it normal and expected in polling mode mode driver with only one >receive descriptor ..? >Is it because of some packets arriving between intervals of eth_poll.? > >if this is the case how tftp will hansle loss of packets..in case >interval between eth_poll() somehow gets enlarged further. 1. tftp does not use broadcast packets 2. tftp is a stop and wait protocol, if a packet is lost it is retried 3. the caller of eth_poll controls how often it is called, in Etherboot as soon as the last packet has been dealt with |
|
From: Ashish a. <ash...@in...> - 2003-04-27 08:55:42
|
Hello, I am using eepro100.c for 82557 for tftp booting and after comparing with log of tcpdump on other remote hosts , i found that i am losing some broadcast packets .. Is it normal and expected in polling mode mode driver with only one receive descriptor ..? Is it because of some packets arriving between intervals of eth_poll.? if this is the case how tftp will hansle loss of packets..in case interval between eth_poll() somehow gets enlarged further. Best Regards, Ashish Anand |
|
From: Georg B. <gb...@us...> - 2003-04-27 08:49:24
|
I have put a port of the Linux driver at the patch manager at sourceforge. Sam tried it, and it goes as far as detecting the chip, but it does not send/receive anything. So if anybody wants to play with this, look at the patch manager. I did not commit the port into cvs, since I am not sure if it breaks something. I also noticed that the pci device ids of the "e1000-82540ep-lp" and "e1000-82540ep" roms in current cvs are swapped, this is also corrected in the patch. Georg |
|
From: Timothy L. <tl...@ro...> - 2003-04-27 01:50:25
|
> > The docs need work, especially the developer manual. I am documenting > > the process of porting a Linux driver as I go through the pcnet32 port. > > A good starting point would be src/drivers/net/sis900.txt from Marty. > Unfortunately it does not apply completely to 5.1 anymore. Damn, that doc would have saved me a number of grep commands when I added sundance to 5.0. I am attempting to add more detail to the process, along the lines of what to add, what to remove when porting a Linux driver. If I complete the document, it should be easier to understand the process. |
|
From: Anselm M. H. <an...@ho...> - 2003-04-26 23:46:09
|
Hello Ken & Eric,
Sunday, April 27, 2003, 1:28:36 AM, Ken wrote:
>>> Which is why you want a conceptual layer in between to separate out how
>>> the key is fetched, it may not be with the image, e.g. it may be in a
>>> smart card. But that can come later.
>>
>>Though if it is a public key it is safe to store it with etherboot,
>>which is a reasonable assertion.
> Wasn't thinking that it's unsafe with Etherboot but that there may be
> uses where you want to separate the key and be able to give the client
> one of multiple identities.
Just in case one day USB support would become real, one could
implement not only SafeBoot but even the possibilty to require an USB
flash or thumb storage to contain the key... but that's future dreams.
Hey, who knows, perhaps etherboot could gain a palladium signature for
the Microshit/OutTel/BigBlue/${BADBOY} secure booting concept :-)
Off for today, good night,
Anselm mailto:an...@ho...
|
|
From: <ke...@us...> - 2003-04-26 23:28:41
|
>> Which is why you want a conceptual layer in between to separate out how >> the key is fetched, it may not be with the image, e.g. it may be in a >> smart card. But that can come later. > >Though if it is a public key it is safe to store it with etherboot, >which is a reasonable assertion. Wasn't thinking that it's unsafe with Etherboot but that there may be uses where you want to separate the key and be able to give the client one of multiple identities. |
53 messages has been excluded from this view by a project administrator.
