etherboot-developers Mailing List for Etherboot (Page 182)
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: Timothy L. <tl...@ro...> - 2003-08-28 02:43:57
|
> That is a noticeable corruption. > > Looking at the code it was never changed to use allot, because it was > written before relocation. So it currently puts a magic buffer at the > end of memory and assumes nothing is there. So I would strongly > recommend disabling relocation when testing it. And if that works > modifying the code to use allot and forget. proto_slam.c gets this > correct. > Thanks Eric. It never crossed my mind to look at relocation. I started to use allot from slam, but I didn't look all that far. As you can see from the attached capture file disabling relocation fixed the issue. Of course, it instantly reboots the machine but I have an NBI and done so that's progress. I will look at proto_slam to see how it does the file creation in memory. Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003 |
|
From: <ebi...@ln...> - 2003-08-28 02:22:07
|
"Timothy Legge" <tl...@ro...> writes: > > > I am now able to download the file, but I think there are some bugs > in > > > the code to allocate and reassemble the file since I get an invalid > > > file. > > > > Are you getting a bad ELF checksum or is it some other problem? > > > > See the attached minicom.cap file. I believe that the code to place the > packets in memory has problems. I will be looking at that next. I am > not quite over my head yet but it is close. ;-) Ok. So the error is the load_block in osloader.c cannot even identify the file type. That is a noticeable corruption. Looking at the code it was never changed to use allot, because it was written before relocation. So it currently puts a magic buffer at the end of memory and assumes nothing is there. So I would strongly recommend disabling relocation when testing it. And if that works modifying the code to use allot and forget. proto_slam.c gets this correct. Eric |
|
From: Timothy L. <tl...@ro...> - 2003-08-28 02:12:48
|
> > I am now able to download the file, but I think there are some bugs in > > the code to allocate and reassemble the file since I get an invalid > > file. > > Are you getting a bad ELF checksum or is it some other problem? > See the attached minicom.cap file. I believe that the code to place the packets in memory has problems. I will be looking at that next. I am not quite over my head yet but it is close. ;-) Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003 |
|
From: Timothy L. <tl...@ro...> - 2003-08-28 02:10:34
|
> There is one large difference between a multicast download and a normal > download. > When doing multicast the data packets potentially arrive in a random order > so there > is not enough information to place them where they need to go immediately. Ah yes, there is that. > tftp code to use two passes to load a file. So there is a reasonable > justification for You are probably correct. I wasn't thinking about the need to reorder the data packets. Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003 |
|
From: <ke...@et...> - 2003-08-28 02:09:38
|
>Now that you mention it, it was unclear. Yes, I was referring to >Anselm's current multicast tftp code in proto_mftm.c. I think my >changes bring it closer to supporting taftp (and the RFC if atftp >implements it correctly) however it needs some work particularly around >error handling. > >However, its seems to me that the only real difference that RFC 2090 >means for tftp is the way a file is requested and the servers >acknowledgment to the client. I may be way off base here (especially >since I have not even looked at how Etherboot currently communicates >with a now-multicast server), but I think if multicast tftp is compiled >in we should (with minor changes to etherboot's standard tftp process): I think Eric has replied also, but I concur with his cautions. If you want to start with the current tftp code. I suggest you make a copy of the tftp code and modify that to support RFC 2090. Then when you think you have it working well, go back and factor out the common stuff. Otherwise you may end up with two broken clients. At least if you don't get RFC 2090 working, you still have one good client. |
|
From: Timothy L. <tl...@ro...> - 2003-08-28 01:54:09
|
> Your referents are a bit unclear: What current implementation do you > mean? Anselm's? Which standard tftp code do you mean? The one in > Etherboot, and not the tftpd? Now that you mention it, it was unclear. Yes, I was referring to Anselm's current multicast tftp code in proto_mftm.c. I think my changes bring it closer to supporting taftp (and the RFC if atftp implements it correctly) however it needs some work particularly around error handling. However, its seems to me that the only real difference that RFC 2090 means for tftp is the way a file is requested and the servers acknowledgment to the client. I may be way off base here (especially since I have not even looked at how Etherboot currently communicates with a now-multicast server), but I think if multicast tftp is compiled in we should (with minor changes to etherboot's standard tftp process): 1) Request the file in multicast mode. 2) The server will either respond in multicast, display an error or not reply (I think) 3) If the server responds in multicast, the EB simply acknowledges the server's response as normal 4) If the server responds with an error or does not respond, EB would re transmit the request in unicast mode. I could be wrong, but it seems fairly doable and could allow people to take advantage of multicast with very little effort. Set up the atftp server and burn new roms (well maybe a little effort). It would be able to use the standard dhcpd.conf settings no changes would be required there. Just a thought Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003 |
|
From: <ebi...@ln...> - 2003-08-28 01:35:15
|
"Timothy Legge" <tl...@ro...> writes: > > > Is it possible that a proto_atftp.c needs to be written for atftp? > > > > It is more likely that proto_tftm.c or possibly atftp needs to be bug > > fixed. I don't know that either of them has had any interoperability > > testing. > > > > Yes, you are correct. It looks like the server Anselm used was fairly > simple. There were a number of issues that had to be resolved related > to the way that server was responding. It looks like the server kept > the port that it was initially contacted on so the code did not extract > the src port from the udp). > > I am now able to download the file, but I think there are some bugs in > the code to allocate and reassemble the file since I get an invalid > file. Are you getting a bad ELF checksum or is it some other problem? > I should sort it out fairly soon. Since my code is a hack of the > current code, I would recommend either a rewrite of the current > implementation or IMO a better solution: adding the multicast option to > the standard tftp code. If I understand what I have seen so far, it > should be a fairly minor change. > > Comments? There is one large difference between a multicast download and a normal download. When doing multicast the data packets potentially arrive in a random order so there is not enough information to place them where they need to go immediately. Because of this for a multicast transmission we need to allocate memory for the file we are downloading and them move it to the correct location in memory as a second pass. For low memory machines that can be a problem, so I would not recommend changing the tftp code to use two passes to load a file. So there is a reasonable justification for keeping two separate code paths. This does not mean that subroutines cannot be reused just that they must be reused carefully. Eric |
|
From: <ke...@et...> - 2003-08-28 01:29:49
|
>I should sort it out fairly soon. Since my code is a hack of the >current code, I would recommend either a rewrite of the current >implementation or IMO a better solution: adding the multicast option to >the standard tftp code. If I understand what I have seen so far, it >should be a fairly minor change. Your referents are a bit unclear: What current implementation do you mean? Anselm's? Which standard tftp code do you mean? The one in Etherboot, and not the tftpd? |
|
From: Timothy L. <tl...@ro...> - 2003-08-28 00:24:39
|
> > Is it possible that a proto_atftp.c needs to be written for atftp? > > It is more likely that proto_tftm.c or possibly atftp needs to be bug > fixed. I don't know that either of them has had any interoperability > testing. > Yes, you are correct. It looks like the server Anselm used was fairly simple. There were a number of issues that had to be resolved related to the way that server was responding. It looks like the server kept the port that it was initially contacted on so the code did not extract the src port from the udp). I am now able to download the file, but I think there are some bugs in the code to allocate and reassemble the file since I get an invalid file. I should sort it out fairly soon. Since my code is a hack of the current code, I would recommend either a rewrite of the current implementation or IMO a better solution: adding the multicast option to the standard tftp code. If I understand what I have seen so far, it should be a fairly minor change. Comments? Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003 |
|
From: <ebi...@ln...> - 2003-08-27 07:08:35
|
Timothy Legge <tl...@ro...> writes: > Hi Anselm > > On 07/03/2002 you posted a patch for TFTP-multicast. Do you know if it was > applied to 5.1/2? As I recall that is pretty much the code you are running now. I believe I put that in proto_tftm.c ... > Which server did you test it with? He had a home brew one. > I spent a late night last night testing atftp. To my untrained eye, > it looks like the current code for DURI_SUPPORT_TFTM will not work > with atftpd. It looks like the info.data is structured differently > when atftp is used. Hmm.. That sounds peculiar but bugs are certainly possible. > Is that possible? I would have thought that the RFC would have specified a > standard structure. I believe we are talking about RFC2090... And except for a little bit of option negotiation to put the data on the multicast channel it is exactly like normal tftp protocol wise... > Is it possible that a proto_atftp.c needs to be written for atftp? It is more likely that proto_tftm.c or possibly atftp needs to be bug fixed. I don't know that either of them has had any interoperability testing. Eric |
|
From: Timothy L. <tl...@ro...> - 2003-08-26 11:37:47
|
Hi Anselm On 07/03/2002 you posted a patch for TFTP-multicast. Do you know if it was applied to 5.1/2? Which server did you test it with? I spent a late night last night testing atftp. To my untrained eye, it looks like the current code for DURI_SUPPORT_TFTM will not work with atftpd. It looks like the info.data is structured differently when atftp is used. Is that possible? I would have thought that the RFC would have specified a standard structure. Is it possible that a proto_atftp.c needs to be written for atftp? Tim |
|
From: Timothy L. <tl...@ro...> - 2003-08-26 08:18:42
|
Hi I compiled in support for multicast tftp and received an tow errors. The patch below resolved it, but I was unsure whether it is correct because I don't seem to be able to find a multicast enabled tftp server. (If you know where to find one, please let me know). Tim Index: include/etherboot.h =================================================================== RCS file: /cvsroot/etherboot/etherboot/etherboot-5.3/src/include/etherboot.h,v retrieving revision 1.3 diff -r1.3 etherboot.h 126c126,127 < #define MAX_ARP ARP_GATEWAY+1 --- > #define ARP_TFTM 3 > #define MAX_ARP ARP_TFTM+1 233a235,237 > > /* proto_tftm.c */ > extern int url_tftm P((const char *name, int (*fnc)(unsigned char *, unsigned int, unsigned int, int))); --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003 |
|
From: Timothy L. <tl...@ro...> - 2003-08-26 00:48:18
|
Hi I compiled in support for multicast tftp and received two errors. The patch below resolved it, but I was unsure whether it is correct because I don't seem to be able to find a multicast enabled tftp server. (If you know where to find one, please let me know). Tim Index: include/etherboot.h =================================================================== RCS file: /cvsroot/etherboot/etherboot/etherboot-5.3/src/include/etherboot.h,v retrieving revision 1.3 diff -r1.3 etherboot.h 126c126,127 < #define MAX_ARP ARP_GATEWAY+1 --- > #define ARP_TFTM 3 > #define MAX_ARP ARP_TFTM+1 233a235,237 > > /* proto_tftm.c */ > extern int url_tftm P((const char *name, int (*fnc)(unsigned char *, unsigned int, unsigned int, int))); |
|
From: <ebi...@ln...> - 2003-08-25 23:38:28
|
"Timothy Legge" <tl...@ro...> writes: > Hi > > I compiled in support for multicast tftp and received two errors. The > patch below resolved it, but I was unsure whether it is correct because > I don't seem to be able to find a multicast enabled tftp server. (If > you know where to find one, please let me know). Your fix should work. But I believe we can just use ARP_SERVER, instead of ARP_TFTM... Recent versions of atftp have multicast support, and that should inter-operate with the etherboot, implementation. They were coded against the same RFC. I don't know if someone has tested them against each other. Eric |
|
From: Timothy L. <tl...@ro...> - 2003-08-24 13:05:28
|
Hi I have implemented multicast support in the 3c595 driver but I don't have a card to test. The change is relatively minor, but I would like to get it confirmed. The instructions for testing Multicast are at: http://etherboot.augustinnetz.de/wiki.pl?MulticastHowto If you have the card, please let me know whether it works both with and without multicast support compiled in. Regards Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003 |
|
From: Timothy L. <tl...@ro...> - 2003-08-24 11:46:11
|
> Works fine for my rev 48 card. Great, it fixed Tony's problem as well. I will back port the changes to 5.2 and 5.0 Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003 |
|
From: <ke...@et...> - 2003-08-24 10:52:04
|
>I have committed a new version of the driver to 5.3 and asked Tony to >try out the new driver. Ken and Marty I believe you have tlan cards. >Can you try the version in the 5.3 cvs? Works fine for my rev 48 card. |
|
From: Timothy L. <tl...@ro...> - 2003-08-24 03:33:36
|
Hi The Etherboot Multicast HowTo is available at: http://etherboot.augustinnetz.de/wiki.pl?MulticastHowto The via-rhine and pcnet32 are now multicast enabled. The tulip and the 3c595 are the last of the major drivers still outstanding (if I have missed an important one let me know). Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003 |
|
From: Timothy L. <tl...@ro...> - 2003-08-24 01:40:05
|
Hi I have been working with Tony White to figure out a problem he is having with the tlan driver. I have modified the transmit function quite a bit and I believe that it should work better. I had been plagued by the fact that revision 35 and 48 worked differently when the Linux driver only differentiates between revisions less than 30. Well today I noticed that the 30 had a 0x in front of it. Yes, the Linux driver was right all along. If the revision < 0x30 (48), the chip works differently. I have committed a new version of the driver to 5.3 and asked Tony to try out the new driver. Ken and Marty I believe you have tlan cards. Can you try the version in the 5.3 cvs? Tim |
|
From: <ja...@Mc...> - 2003-08-23 13:36:33
|
On Sat, 23 Aug 2003, Marty Connor wrote:
> On Friday, August 22, 2003, at 07:17 PM, Marty Connor wrote:
> > On Wednesday, August 20, 2003, at 04:41 PM, Paolo Salvan wrote:
> >> The new etherboot should allow to build auto-detecting floppy
> >> ("etherboot", "etherboot-pci"); can this feature be usable also from
> >> the
> >> rom-o-matic web site?
>
> > Anyway, thanks for your suggestion, and I'll see what my staff thinks
> > of it.
I just figured you were talking about Pete :)
Keep up the great work Marty.
Jim.
>
> I should have put a big smiley :) behind that. Or better a wink ;)
>
> Lest people actually think there is a department of people here working
> on Etherboot, rather than a globally distributed dedicated group of
> professionals who give of their copious free time to support Free
> Software and make the world a better place (as well as work on a really
> cool project! ;)
>
> I was just writing to Ken:
>
> "... When I do the LinuxWorld shows, knowing that there are people in
> the world who respect and depend on Etherboot is a great source of
> comfort and strength. I missed the mingling and non-directed thinking I
> used to do before at shows. But being in the booth and making direct
> contact with our "customers" is such an important thing that even after
> 3 years and six shows, I always look forward to the next one, and what
> improvements we can bring to the table. "
>
> I probably should write more. I often find email (and writing in
> general) a dissatisfyingly uni-dimensionsal half-duplex, and
> unexpressive medium, in general. But it is what it is, and I do my best
> with it. It has its good points too.
>
> As a wrap-up to LinuxWorld Expo (pictures at http://www.thinguin.org/ )
> I'd like to thank everyone who is associated with the Etherboot project
> for your support. I'd like to thank Markus for taking time from work to
> help in the booth and hack on the http: download stuff. So many people
> come up to the booth and say nice things about us. BIOS vendors are
> getting interested in adding Etherboot as an option. I need to
> follow-up with them.
>
> In the four years I have been helping with Etherboot, we've seen some
> really excellent things happen, and it's worth checking out
> http://www.etherboot.org/doc/html/userman/acknowledgements.html to see
> all the people who have given a little (or much more) of themselves to
> make Etherboot as useful as it is.
>
> Ken is good at modestly thanking others, but let me say that the last
> four years of Etherboot hacking have been a great privilege, and
> hopefully, people appreciate both the code and the sense of fun.
>
> Thanks to everyone, and I can't wait to see what we come up with next!
>
> Marty
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>
--
|
|
From: Marty C. <ma...@et...> - 2003-08-23 10:46:13
|
On Friday, August 22, 2003, at 07:17 PM, Marty Connor wrote:
> On Wednesday, August 20, 2003, at 04:41 PM, Paolo Salvan wrote:
>> The new etherboot should allow to build auto-detecting floppy
>> ("etherboot", "etherboot-pci"); can this feature be usable also from
>> the
>> rom-o-matic web site?
> Anyway, thanks for your suggestion, and I'll see what my staff thinks
> of it.
I should have put a big smiley :) behind that. Or better a wink ;)
Lest people actually think there is a department of people here working
on Etherboot, rather than a globally distributed dedicated group of
professionals who give of their copious free time to support Free
Software and make the world a better place (as well as work on a really
cool project! ;)
I was just writing to Ken:
"... When I do the LinuxWorld shows, knowing that there are people in
the world who respect and depend on Etherboot is a great source of
comfort and strength. I missed the mingling and non-directed thinking I
used to do before at shows. But being in the booth and making direct
contact with our "customers" is such an important thing that even after
3 years and six shows, I always look forward to the next one, and what
improvements we can bring to the table. "
I probably should write more. I often find email (and writing in
general) a dissatisfyingly uni-dimensionsal half-duplex, and
unexpressive medium, in general. But it is what it is, and I do my best
with it. It has its good points too.
As a wrap-up to LinuxWorld Expo (pictures at http://www.thinguin.org/ )
I'd like to thank everyone who is associated with the Etherboot project
for your support. I'd like to thank Markus for taking time from work to
help in the booth and hack on the http: download stuff. So many people
come up to the booth and say nice things about us. BIOS vendors are
getting interested in adding Etherboot as an option. I need to
follow-up with them.
In the four years I have been helping with Etherboot, we've seen some
really excellent things happen, and it's worth checking out
http://www.etherboot.org/doc/html/userman/acknowledgements.html to see
all the people who have given a little (or much more) of themselves to
make Etherboot as useful as it is.
Ken is good at modestly thanking others, but let me say that the last
four years of Etherboot hacking have been a great privilege, and
hopefully, people appreciate both the code and the sense of fun.
Thanks to everyone, and I can't wait to see what we come up with next!
Marty
|
|
From: Marty C. <ma...@et...> - 2003-08-22 23:17:13
|
On Wednesday, August 20, 2003, at 04:41 PM, Paolo Salvan wrote:
> The new etherboot should allow to build auto-detecting floppy
> ("etherboot", "etherboot-pci"); can this feature be usable also from
> the
> rom-o-matic web site?
I'm sure we can do something. Since it's not in the Roms file, we'd
probably have to hack a special case for it. I'll take a look at it
next chance I get. The suggestion has also been made that we support
compound-Rom building. (that is images with more than one target NIC in
them). It's an interesting idea, and might work from floppy and lilo,
there may be BIOS issues, where the BIOS needs the PCI IDs of the image
on the ROM to match. There is a possible way to deal with this in the
BSS BIOS spec, but then some BIOSes might not support it.
Anyway, thanks for your suggestion, and I'll see what my staff thinks
of it.
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: <ebi...@ln...> - 2003-08-22 10:48:03
|
"Timothy Legge" <tl...@ro...> writes: > Hi Eric > > I was working on the rtl8139 driver and it seems to continue to loop. > That is, it downloads via mini-slamd, acknowledges, prints 0-20 (an > Etherboot rom) and continues to receive again. > > Any idea why Etherboot would request the file again? The NACK lists the packets that have not been received so if you are seeing 0-20 it looks like nothing was received. It does look like the communication by the unicast side band channel is working so etherboot is getting the size of the image to download. Good luck finding the unicast enable for the rtl8139. Eric |
|
From: Timothy L. <tl...@ro...> - 2003-08-22 07:46:50
|
Hi Eric I was working on the rtl8139 driver and it seems to continue to loop. That is, it downloads via mini-slamd, acknowledges, prints 0-20 (an Etherboot rom) and continues to receive again. Any idea why Etherboot would request the file again? Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003 |
|
From: Paolo S. <al...@io...> - 2003-08-22 04:20:49
|
Hi all!
The new etherboot should allow to build auto-detecting floppy
("etherboot", "etherboot-pci"); can this feature be usable also from the
rom-o-matic web site?
It would be really useful to produce auto-detecting boot floppy! (ie
"etherboot.zdsk")
Bye!
Paolo
|
53 messages has been excluded from this view by a project administrator.
