etherboot-developers Mailing List for Etherboot (Page 266)
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: BHARATHWAJ M. <mb...@co...> - 2001-12-20 20:39:18
|
On Fri, 21 Dec 2001, Ken Yap wrote: > >Unfortunately, I am getting timing issues. For instance, if I keep adding > >printfs in the do loop in the function do_eeprom_cmd in eepro100.c, the > >loop advances, if not it doesn't. Here is my do_eeprom_cmd in eepro100.c: > > It could be that the timing requirements of recent chips require a > larger delay now. You could try increasing the value in udelay (but only > up to max of about 50, due to the way udelay works). Also have a look at > what values they're using in Linux drivers these days. > > Also udelay relies on the hardware timer. Do you have this timer on your > motherboard? Looking at timer.h, I see u use the 8254. My motherboard has a PIIX4 southbridge, and I see in its datasheet it is the 82C54, I will look into this.. > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: BHARATHWAJ M. <mb...@co...> - 2001-12-20 20:35:34
|
On Fri, 21 Dec 2001, Ken Yap wrote: > >Unfortunately, I am getting timing issues. For instance, if I keep adding > >printfs in the do loop in the function do_eeprom_cmd in eepro100.c, the > >loop advances, if not it doesn't. Here is my do_eeprom_cmd in eepro100.c: > > It could be that the timing requirements of recent chips require a > larger delay now. You could try increasing the value in udelay (but only > up to max of about 50, due to the way udelay works). Also have a look at > what values they're using in Linux drivers these days. Hmmm...ok, I will try that. The maximum value I tried in udelay was 8, I will go further :). > Also udelay relies on the hardware timer. Do you have this timer on your > motherboard? I will have to verify this. Right now I am thinking no, because I noticed that although -DASK_BOOT=3, there is no waiting at all, just flies right through using the default value. I tried setting it to 10, didnt work, no waiting at all! I am going to try increasing the udelay value, and check out the Linux drivers. Bharath > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: <ke...@us...> - 2001-12-20 20:30:17
|
>Unfortunately, I am getting timing issues. For instance, if I keep adding >printfs in the do loop in the function do_eeprom_cmd in eepro100.c, the >loop advances, if not it doesn't. Here is my do_eeprom_cmd in eepro100.c: It could be that the timing requirements of recent chips require a larger delay now. You could try increasing the value in udelay (but only up to max of about 50, due to the way udelay works). Also have a look at what values they're using in Linux drivers these days. Also udelay relies on the hardware timer. Do you have this timer on your motherboard? |
|
From: BHARATHWAJ M. <mb...@co...> - 2001-12-20 17:41:59
|
Hello, I am trying to use etherboot with linuxBIOS (www.linuxbios.org), Intel 82559ER ethernet controller on a digital logic's smartcore-P5 (430TX) Unfortunately, I am getting timing issues. For instance, if I keep adding printfs in the do loop in the function do_eeprom_cmd in eepro100.c, the loop advances, if not it doesn't. Here is my do_eeprom_cmd in eepro100.c: static int do_eeprom_cmd(int cmd, int cmd_len) { unsigned retval = 0; long ee_addr = ioaddr + SCBeeprom; outw(EE_ENB, ee_addr); printf("DEBUGGING -> Before udelay in " __FUNCTION__ "\n"); udelay(2); printf("DEBUGGING -> After udelay in " __FUNCTION__ "\n"); outw(EE_ENB | EE_SHIFT_CLK, ee_addr); printf("DEBUGGING -> After outw in " __FUNCTION__ "\n"); udelay(2); /* Shift the command bits out. */ printf("DEBUGGING -> Before shifting command bits in " __FUNCTION__ "\n"); do { short dataval = (cmd & (1 << cmd_len)) ? EE_WRITE_1 : EE_WRITE_0; printf("DEBUGGING -> cmd_len: %d\n", cmd_len); outw(dataval, ee_addr); printf("DEBUGGING -> After outw(dataval, ee_addr) in " __FUNCTION__ "\n"); udelay(2); printf("DEBUGGING -> After udelay(2)\n"); outw(dataval | EE_SHIFT_CLK, ee_addr); printf("DEBUGGING -> After outw(dataval | EE_SHIFT_CLK, ee_addr)\n"); udelay(2); printf("DEBUGGING -> After udelay(2)\n"); retval = (retval << 1) | ((inw(ee_addr) & EE_DATA_READ) ? 1 : 0); printf("DEBUGGING -> After assigning value for retval in " __FUNCTION__ "\n"); } while (--cmd_len >= 0); printf("DEBUGGING -> After shifting command bits in " __FUNCTION__ "\n"); outw(EE_ENB, ee_addr); udelay(2); /* Terminate the EEPROM access. */ outw(EE_ENB & ~EE_CS, ee_addr); return retval; } Depending on the number of printfs inside the do loop, cmd_len decrements. Can anyone help me resolve this timing issue, at least point me in the correct debugging direction :) ? I am totally lost at the present... Bharath |
|
From: <ke...@us...> - 2001-12-20 02:40:16
|
>I am "christopher_li" at sourceforge. > >> Also Christopher, if you wish to register as a Sourceforge user, I can >> add you to the developers group and then you can check your driver into >> CVS. Ok, you're in. There might or might not be a delay before Sourceforge updates their permissions, I forget. |
|
From: Christopher Li <ch...@gn...> - 2001-12-20 02:00:43
|
I am "christopher_li" at sourceforge. Chris On Thu, 20 Dec 2001, Ken Yap wrote: > >Christopher, > > > >Is this the version you sent to Ken a little while ago? I have a couple > >of these cards and might find time to work on the driver over the > >holidays. > > > >Marty > > Also Christopher, if you wish to register as a Sourceforge user, I can > add you to the developers group and then you can check your driver into > CVS. > > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: Christopher Li <ch...@gn...> - 2001-12-20 01:58:59
|
The version I send to you should work with most e1000 cards. If you want to do some test. that is a good starting point because it can operate on some different e1000 cards. It use almost the same link setup code that was used in intel's driver e1000-3.1.23. Of course, I take the Adaptor struct out. Besides the size and massy debug message this version should be fine. I would suggest try this version with floopy first. The version which I am working on try to isolate the code relate to different chip set and put it under #ifdef etc. So you can make the driver smaller but support less card in one single driver. The card I am playing with is 82543GC. BTW, Ken, Can you explain a little bit about the force speed options[]? There is not place mention it in the develope guide. Thanks Chris On Wed, 19 Dec 2001, Marty Connor wrote: > On 12/19/2001 2:52 PM Eric W. Biederman ebi...@ln... wrote: > >Christopher Li <ch...@gn...> writes: > >> Eric, if you want, I can send you the version I have. > >Thanks, I'd appreciate it. At this point I probably won't do anything > >with it immediately but having a copy would mean that if you get > >busy later I have something to work with. > > Christopher, > > Is this the version you sent to Ken a little while ago? I have a couple > of these cards and might find time to work on the driver over the > holidays. > > 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/ > > > > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: <ke...@us...> - 2001-12-20 00:28:03
|
>Christopher, > >Is this the version you sent to Ken a little while ago? I have a couple >of these cards and might find time to work on the driver over the >holidays. > >Marty Also Christopher, if you wish to register as a Sourceforge user, I can add you to the developers group and then you can check your driver into CVS. |
|
From: Marty C. <md...@th...> - 2001-12-20 00:21:02
|
On 12/19/2001 2:52 PM Eric W. Biederman ebi...@ln... wrote:
>Christopher Li <ch...@gn...> writes:
>> Eric, if you want, I can send you the version I have.
>Thanks, I'd appreciate it. At this point I probably won't do anything
>with it immediately but having a copy would mean that if you get
>busy later I have something to work with.
Christopher,
Is this the version you sent to Ken a little while ago? I have a couple
of these cards and might find time to work on the driver over the
holidays.
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: <ke...@us...> - 2001-12-19 21:28:19
|
>When you use the same CVS tree downloaded to compile, you have to inform >what files is automatic generated by your source on compile time and >have to be ignored by CVS update. This files will not be syncronized >with CVS. > >This is an .cvsignore example for src/bin32/.cvsignore >*.o >*.rom >*.lzrom >*.tmp >*.huf Ok. I guess I never used one because I always do a make clean before doing a commit. |
|
From: <ebi...@ln...> - 2001-12-19 19:52:36
|
Christopher Li <ch...@gn...> writes: > On Tue, 18 Dec 2001, Ken Yap wrote: > > > One developer has sent me a pre-release of a working Intel E1000 driver. > > He promised to announce after he has cleaned it up. If there is interest > > I could ask him if he could release sooner or later. C, if you are > Yes, that is me. I am busy with other stuff right now, can't work on > it this week. Basicly I have port the Intel's driver to etherboot and > it can boot now. There are still some place need to cleanup. The last > version I build was smaller than tulip, but still big. > > Eric, if you want, I can send you the version I have. Thanks, I'd appreciate it. At this point I probably won't do anything with it immediately but having a copy would mean that if you get busy later I have something to work with. Eric |
|
From: Christopher Li <ch...@gn...> - 2001-12-19 19:02:26
|
On Tue, 18 Dec 2001, Ken Yap wrote: > One developer has sent me a pre-release of a working Intel E1000 driver. > He promised to announce after he has cleaned it up. If there is interest > I could ask him if he could release sooner or later. C, if you are Yes, that is me. I am busy with other stuff right now, can't work on it this week. Basicly I have port the Intel's driver to etherboot and it can boot now. There are still some place need to cleanup. The last version I build was smaller than tulip, but still big. Eric, if you want, I can send you the version I have. Chris > reading this, perhaps you could announce it yourself, you're the hero > after all. Or get Eric to help you test it, maybe? > > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: Gustavo J. A. <al...@co...> - 2001-12-19 17:22:34
|
When you use the same CVS tree downloaded to compile, you have to inform what files is automatic generated by your source on compile time and have to be ignored by CVS update. This files will not be syncronized with CVS. This is an .cvsignore example for src/bin32/.cvsignore *.o *.rom *.lzrom *.tmp *.huf Gustavo Junior Alves al...@co... Ken Yap wrote: >>The cvs tree doesn't have any .cvsignore files, neither 5.0 or 5.1 >>branch. It's correct? >> > >I'm afraid I don't know what a .cvsignore file does. Please explain? > >_______________________________________________ >Etherboot-developers mailing list >Eth...@li... >https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: <ke...@us...> - 2001-12-19 17:07:34
|
>The cvs tree doesn't have any .cvsignore files, neither 5.0 or 5.1 >branch. It's correct? I'm afraid I don't know what a .cvsignore file does. Please explain? |
|
From: Gustavo J. A. <al...@co...> - 2001-12-19 17:01:47
|
Hi, The cvs tree doesn't have any .cvsignore files, neither 5.0 or 5.1 branch. It's correct? Thanks. Gustavo Junior Alves al...@co... |
|
From: <ebi...@ln...> - 2001-12-18 21:21:31
|
I have just completed writing up the major components of what I believe is a solid specification for booting using the ELF format. The parameter formant is slightly incopatible with what I have currently running with LinuxBIOS. This is for two reasons. The first is I confused BIOS parameter tables with bootloader paramters in my first implementation. And secondly because the implementation I currently have changes type sizes when switching architectures a feature I do not believe is robust during conversions between 32 bit and 64bit cpus. Please review this and give me feedback. At ftp://download.linuxnetworx.com/pub/src/linuxbios/specifications/draft1_elf_boot_proposal.txt While I let this sit for a little while I am going to be working on specifications for LinuxBIOS specific tables that can be found by scanning memory, instead of needing to be passed to the application. Eric |
|
From: <ebi...@ln...> - 2001-12-18 18:57:48
|
ke...@us... (Ken Yap) writes: > >It looks like gigabit ethernet is just on the verge of becomming > >inexpensive and I was wondering if anyone was actively working to > >support any of the current or soon to be release gigabit ethernet > >cards? > > > >I'm hoping I won't have to write a driver once I find a good > >inexpensive card but... > > One developer has sent me a pre-release of a working Intel E1000 driver. Nice. I'd love to see something besides an intel driver, but something is better than nothing. > He promised to announce after he has cleaned it up. If there is interest > I could ask him if he could release sooner or later. C, if you are > reading this, perhaps you could announce it yourself, you're the hero > after all. Or get Eric to help you test it, maybe? I could probably help but not until January. I'm pretty booked this week, and I'm going on vacation after that. Eric |
|
From: <ke...@us...> - 2001-12-18 08:26:18
|
>It looks like gigabit ethernet is just on the verge of becomming >inexpensive and I was wondering if anyone was actively working to >support any of the current or soon to be release gigabit ethernet >cards? > >I'm hoping I won't have to write a driver once I find a good >inexpensive card but... One developer has sent me a pre-release of a working Intel E1000 driver. He promised to announce after he has cleaned it up. If there is interest I could ask him if he could release sooner or later. C, if you are reading this, perhaps you could announce it yourself, you're the hero after all. Or get Eric to help you test it, maybe? |
|
From: <ebi...@ln...> - 2001-12-17 20:23:04
|
It looks like gigabit ethernet is just on the verge of becomming inexpensive and I was wondering if anyone was actively working to support any of the current or soon to be release gigabit ethernet cards? I'm hoping I won't have to write a driver once I find a good inexpensive card but... Eric |
|
From: <ke...@us...> - 2001-12-17 07:23:05
|
> it seems i just can't get my ethernet cad dlink 538tx to boot through >etherboot. the documentation says 530tx should work with via-rhine or >realtek(rtl8139) but unfortunatly 538tx dosen't work with any of them. any >ideas folks...... Via Rhine and RTL8139 are actually quite different chips, but I suppose it seems normal for Dlink to make very similar sounding NICs that have different hardware. Probably the best thing to do is to find out the PCI IDs of the NIC, either look at the BIOS display of the PCI devices at power-on self-test, or run lspci after Linux has booted. From disk of course. Then match the IDs against the list in the file NIC. Also the name of the Linux driver that works is a good clue. PS: This is a users list question, not a developers list question. |
|
From: Gunjan G. <gan...@ho...> - 2001-12-17 05:58:45
|
hi folks,
it seems i just can't get my ethernet cad dlink 538tx to boot through
etherboot. the documentation says 530tx should work with via-rhine or
realtek(rtl8139) but unfortunatly 538tx dosen't work with any of them. any
ideas folks......
jhquest.
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
From: <ke...@us...> - 2001-12-08 22:45:41
|
>What you implement at your site is your business. If you want it badly >enough, you can patch the source yourself, maybe as part of the >rom-o-matic process. If experience shows that this is of use to a >significant portion of the user population, I'll consider it for >inclusion. Incidentally it should be noted that you, Peter, have developer privileges at Sourceforge Etherboot so if you wanted you could even post your own patch and automatically fetch it as part of the rom-o-matic build process. Eric has added an $EXTRAVERSION portion to the version number and I will retain that. So you could post -pl1, -pl2, etc, nothing's stopping you. |
|
From: <ke...@us...> - 2001-12-08 22:31:39
|
>I have in mind a "PXE nuker" bootable image which runs on new COTS >hardware; it registers the new box with the local admin database, >reports which nics and other hardware are there and performs any local >tweaking that we'd like, e.g. flash nic and/or system rom with LinuxBIOS >and or Etherboot, and insert whatever is needed in the way of local >state. Then it would run tests and exercisers, report that everything's >OK and initiate an appropriate system install. Why not have a local >rom-o-matic on the server which magics up a bespoke image for the system >at install? Indeed, why not check for updates (and reflash if needed) at >*every* reboot? What you implement at your site is your business. If you want it badly enough, you can patch the source yourself, maybe as part of the rom-o-matic process. If experience shows that this is of use to a significant portion of the user population, I'll consider it for inclusion. |
|
From: Peter L. <P.L...@sy...> - 2001-12-08 20:01:42
|
> It's a special option because it requires server side handling and > will not work with a generic DHCP setup. Fair enough - as you have probably gathered, our DHCP config is decidely non-trivial. :) > But it's the same NIC with the same ROM. In one machine it boots using > itself. I move it to another machine that has a second NIC of the same > model and it tries to boot the other NIC. Huh? This is predictable > behaviour, whether it manages to boot depends on whether the second NIC > is plugged in or not? I interpret predictable behaviour, meaning systematic, not identical. After all, I just opened the case of a machine, and rejigged the nics (plural). Presumably I know why I did so, and indeed presumably I also know why I have 2 or more nics? > Therein lies the difference between our POVs. You treat the EEPROM on > the NIC as extra BIOS storage. You probably don't have any EPROMs. Astute observation, Ken. You correctly guess that I treat the (E)EPROMS as non-volatile software storage, and wouldn't dirty my hands with anything I couldn't flash. A degree in computing and electronics taught me early on that the smell of solder and burning ICs was NOT my forte. Whether one treats firmware as hard software or soft hardware is down to personal experience. If one has physically put a PROM in a programmer, fitted it in a nic and then installed the nic, one is more likely to view a "boot enabled nic" - and by extension the software it contains - as a single lump of hardware, so tying the nic and software makes "obvious" sense. If one runs cromutil, it's just as "obviously" non-volatile software. Both views are valid, but I predict that trends in manufacturing and e.g. JFFS will make the latter the "normal" view very soon. |
|
From: Peter L. <P.L...@sy...> - 2001-12-08 19:54:23
|
> Marty, I'm sorry, I'll have to strongly disagree with you here. I think > this cure is worse than the disease. While this is nice for bespoke ROMs > for NICs, it makes it necessary for the user to find out the MAC > address, have it put into the ROM, and put the ROM on the right NIC. It > makes mass programming of ROMs impossible. I know it would do wonders > for the stock price of rom-o-matic though. :-) Impossible? Ken, I'm sorry, I'll have to strongly disagree with you here. :) I have in mind a "PXE nuker" bootable image which runs on new COTS hardware; it registers the new box with the local admin database, reports which nics and other hardware are there and performs any local tweaking that we'd like, e.g. flash nic and/or system rom with LinuxBIOS and or Etherboot, and insert whatever is needed in the way of local state. Then it would run tests and exercisers, report that everything's OK and initiate an appropriate system install. Why not have a local rom-o-matic on the server which magics up a bespoke image for the system at install? Indeed, why not check for updates (and reflash if needed) at *every* reboot? > I think the outline solution we arrived at is acceptable. No argument from me. These are 2 useful defaults which will cover most of the bases for the near future; as such it's just right as a medium term solution for Etherboot. However, I think that the awkward squad will find lots of fun things to do with flash rom which probably aren't suitable for those of a nervous disposition, or who just want to install 100 LTSP instance. |
53 messages has been excluded from this view by a project administrator.
