etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] tidy ups

[<ke...@us...>]

>I think it works in 2.95, and the syntax is
>__attribute__ ((unused))

Ok thanks will give it a shot.

>They are there because the definition of
>strlen/strcmp is non static, but the declaration in
>the hedaer file is static. If you change "static" to
>"extern" in the header file, the warnings go away. I
>wonder why the "static" is in the header file at all?

Ah, missed the fact that there are two, well three, string.h files and
one has the prototype and the second the body. All is well now.

Re: [Etherboot-developers] tidy ups

[Georg B. <Geo...@po...>]

----- Original Message -----
From: ke...@us...
Date: Monday, March 17, 2003 2:24 am
Subject: [Etherboot-developers] tidy ups

> Does anybody know how to declare the unused
attribute on function
> parameters, and just as important, does it work
with older gcc 
> versionslike 2.95?

I think it works in 2.95, and the syntax is
__attribute__ ((unused))
 
> Does anybody know how to get rid of these
warnings? I assume this is
> because they are now predeclared in gcc 3.x?
> 
> arch/i386/include/bits/string.h:254: warning:
static declaration 
> for `strncmp' follows non-static
> arch/i386/include/bits/string.h:277: warning:
static declaration 
> for `strlen' follows non-static

They are there because the definition of
strlen/strcmp is non static, but the declaration in
the hedaer file is static. If you change "static" to
"extern" in the header file, the warnings go away. I
wonder why the "static" is in the header file at all?

Georg

[Etherboot-developers] compile errors with -DAOUT_IMAGE

[<ke...@us...>]

Eric, did you mean for astate and members from aout_loader.c to be
visible to freebsd_loader.c? Not sure how you intended to split things
up.

In file included from core/osloader.c:92:
arch/i386/core/freebsd_loader.c: In function `aout_freebsd_probe':
arch/i386/core/freebsd_loader.c:348: structure has no member named `a_midmag'
arch/i386/core/freebsd_loader.c:354: `info' undeclared (first use in this function)
arch/i386/core/freebsd_loader.c: In function `aout_freebsd_boot':
arch/i386/core/freebsd_loader.c:367: warning: assignment makes pointer from integer without a cast
arch/i386/core/freebsd_loader.c:370: `entry' undeclared (first use in this function)

[Etherboot-developers] tidy ups

[<ke...@us...>]

I've just checked in a bunch of tidy ups to source files to remove
unused variable warnings. I've also got rid of line that was causing the
shell to barf on a FP number in arch/i386/Makefile.

Does anybody know how to declare the unused attribute on function
parameters, and just as important, does it work with older gcc versions
like 2.95?

Does anybody know how to get rid of these warnings? I assume this is
because they are now predeclared in gcc 3.x?

arch/i386/include/bits/string.h:254: warning: static declaration for `strncmp' follows non-static
arch/i386/include/bits/string.h:277: warning: static declaration for `strlen' follows non-static

[Etherboot-developers] 3C905CX-TXM flashing with cromutil hangs

[Robb M. <ma...@ac...>]

I just checked the AMD site for info on the flash you mentioned (AMD
AM29F002BT-70JC) - the datasheet can be obtained here:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/2152
7d.pdf

Two things to note:
- The part is a 256KB x 8 part, with a "top boot-sector". This means that
the top page of the flash is normally visible on release of system reset.
Since you mention your card is located at 0xD800, it is likely to have no
larger than a 32KB active image, but could have either 16KB or 8KB. If 3-Com
parts support paging the flash in a "windowed" interface, and your update
utility supports this, the utility may have written your code into a page at
the 'bottom' of the flash, instead of the top.

- This part supports sector level write/erase protection. If 3-Com
implemented this, you will have to pull the RESET line up to Vid (+5V from
the datasheet) to (temporarily) unlock write protected pages in order to
perform the update. It is possible they tied a GPIO to the reset line to
allow their update utility to override the sector lock. (There are other
ways to override the lock, but they are only suitable for a manufacturing /
test environment, and don't apply here).

I think the second is the most likely of the two scenarios.

Good luck,
Robb Main.

Re: [Etherboot-developers] 3C905CX-TXM flashing with cromutil hangs

[Hans-Peter J. <hp...@ur...>]

[CCed vo...@sc..., because of failure of vortex-diag]

Thanks, Ken, for responding.

On Saturday 15 March 2003 00:36, Ken Yap wrote:
> >I just tried to flash etherboot onto this NIC, but failed. cromutil sa=
ys,
> >it erases the flash successfully, but it doesn't. Factory boot image
> > can still be read, and booted from. Flash chip is an AMD
> > AM29F002BT-70JC.
> >
> >Searching the web reveals some similar problems, but no solutions yet.
> >Does anybody succeed in this. The former model 3C905C-TX-M (which isn'=
t
> >manufactured anymore) doesn't have those problems.
>
> Doesn't Donald Becker's site have some utilities for dealing with

I've now also tried vortex-diag. Since it hangs on save of flash, I=20
haven't tried flashing with it:

vortex-diag.c:v2.09 9/18/2002 Donald Becker (be...@sc...)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xd800.
Hmmm, no response to the ID command, trying again..
ACKKK, this may not be a programmable Flash part!
Unknown BIOS ROM ID 55 AA.
Saving the boot flash ROM into file '../../3c905cxtxm.bootrom'...
<fullstop>

vortex-diag -ee says:
vortex-diag.c:v2.09 9/18/2002 Donald Becker (be...@sc...)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xd800.
EEPROM format 64x16, configuration table at offset 0:
    00: 000a 0dd4 77d7 9200 036c 0048 5a53 6d50
  0x08: 2940 0800 000a 0dd4 77d7 0010 0000 00aa
  0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7
  0x18: 1000 000a 0002 6300 ffb7 b7b7 0000 0000
  0x20: 009d 1234 5600 0000 0000 0000 0000 0000
  0x28: 0000 0000 0000 0000 0000 0000 0000 0000
  0x30: ffff ffff ffff ffff ffff ffff ffff ffff
      ...

 The word-wide EEPROM checksum is 0xb700.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
 3Com Node Address 00:0A:0D:D4:77:D7 (used as a unique ID only).
 OEM Station address 00:0A:0D:D4:77:D7 (used as the ethernet address).
  Device ID 9200,  Manufacturer ID 6d50.
  Manufacture date (MM/DD/YYYY) 11/12/2001, division H, product SZ.
  A BIOS ROM of size 0Kx8 is expected.
 Options: negotiated duplex, link beat required.
  Vortex format checksum is incorrect (0b vs. 10b7).
  Cyclone format checksum is incorrect (0x9b vs. 0x9d).
  Hurricane format checksum is incorrect (0xb2 vs. 0x9d).

The BIOS ROM size looks bogus. Maybe 128KB(?) isn't expected here.

I also peeked into the public accessible (after registration) documentati=
on
from 3com, but this seems not to cover this specific model at all :-(.

> flashing? Also if the chips are plug in you could flash them somewhere
> else. But they may be soldered down or this may not be practical for a

No way, it's soldered.

> large number of NICs. Sounds like 3Com don't want people installing
> their own images. Patronise another vendor. Tulip and Via-Rhine chips

I don't think, 3com locks us out on purpose. They even packaged some DOS/=
Win=20
bootware tools here: http://support.3com.com/infodeli/tools/nic/mba.htm.=20
Needless to say, mbflash.exe from this package fails to detect this flash=
,=20
too :-(.

> are just as good performance wise.

If I fail to get this setup working, I will consider it. Given the variet=
y
of different tulip designs, I'm not very keen on it.

> >Alternatively, how far is PXE support on linux? What disadvantages I
> >need to deal with (kernel boot parameter, initrd)?
>
> I believe it works well, I haven't tried it, check H. Peter Anvin's
> site.

I try to stay on my etherboot setup, which is working really nice for all=
=20
my machines. Thanks for the effort of you all. And the necessary imggen=20
utility for PXE is binary only :-(. Hopefully I can get it to work someho=
w.

Thanks again,
Pete

Re: [Etherboot-developers] 3C905CX-TXM flashing with cromutil hangs

[<ke...@us...>]

>I just tried to flash etherboot onto this NIC, but failed. cromutil says,
>it erases the flash successfully, but it doesn't. Factory boot image can=20
>still be read, and booted from. Flash chip is an AMD AM29F002BT-70JC.
>
>Searching the web reveals some similar problems, but no solutions yet.=20
>Does anybody succeed in this. The former model 3C905C-TX-M (which isn't=20
>manufactured anymore) doesn't have those problems.

Doesn't Donald Becker's site have some utilities for dealing with
flashing? Also if the chips are plug in you could flash them somewhere
else. But they may be soldered down or this may not be practical for a
large number of NICs. Sounds like 3Com don't want people installing
their own images. Patronise another vendor. Tulip and Via-Rhine chips
are just as good performance wise.

>Alternatively, how far is PXE support on linux? What disadvantages I=20
>need to deal with (kernel boot parameter, initrd)?=20

I believe it works well, I haven't tried it, check H. Peter Anvin's
site.

[Etherboot-developers] 3C905CX-TXM flashing with cromutil hangs

[Hans-Peter J. <hp...@ur...>]

Hi,

I just tried to flash etherboot onto this NIC, but failed. cromutil says,
it erases the flash successfully, but it doesn't. Factory boot image can=20
still be read, and booted from. Flash chip is an AMD AM29F002BT-70JC.

Searching the web reveals some similar problems, but no solutions yet.=20
Does anybody succeed in this. The former model 3C905C-TX-M (which isn't=20
manufactured anymore) doesn't have those problems.

Alternatively, how far is PXE support on linux? What disadvantages I=20
need to deal with (kernel boot parameter, initrd)?=20

TIA,
Pete

Re: [Etherboot-developers] Adding more device ids to drivers

[<ebi...@ln...>]

Georg Baum <Geo...@po...> writes:

> Now that adding new vendor/device ids require only one change: Does it make 
> sense to add combinations that are missing in etherboot, but present in 
> linux?
> I think it is safe to add them if the linux driver handles the missing ids 
> exactly like the existing ones. If there are no objections, I will do this.

If you are real ambitious while you are going through you could
grab the multicast support enable code from the linux drivers
as well.  Usually it amounts to a line or two of code change needed
per driver.

I keep intending to do it but never actually getting around to it. 

Eric

[Etherboot-developers] =?ks_c_5601-1987?B?KLGksO0pIDIwMDOz4sf8ILbzuqdTL1cguau34SEhQA==?=

[<ad...@la...>]

Ojo6tOuxuMH2x8/DtiDC/LvnILvntvvAxyC4sbe5wMw6OjogICAgICAgICAgICAgICAgICAgIAkJ
CQkJCQkgICAgICAgICAgICAgICAgICAgICAgIAkJCQkJCQkJCQ0KICAgICAgICAgICAgICAiICC8
+7i3x/QsIL72uLYgu+y3wcHgLiAiICIgu+e2+8fRtNkuIiAgIiC+1rXpwLsgus7FucfYv+QuIiAi
ILOquKYgIMCnx9ggseK1tcfYweAiDQogtOuxuCDB9sfPw7Ygwvy75yDI8bv9wNq16cDMILOyseQg
uLbB9ri3IMD8yK0guN68vMH2sKEgsKG9v8C7ICC5zL7uwfaw1CDH1bTPtNkuDQogtOvH0MDUx9DA
uyC+0LXQIMD+wLogw7vD4bXpLMG5vvfAxyCx4rvdwLsgsLDAzCDHz7fBIMfftPggILvntve16Syw
ocG3wMcgu/2w6LimIMCnx9ggDQogudm72rDUILy6vcfHz7DUILvstPggu+e297XpLiCx17XpwLog
wMzBpiDH0bz4sKO/oSDC/LTcx9EgIMDnsKEgtcew7SC4u77SvcC0z7TZLg0KIMDMwaYgv8Igsbm5
zsDMILTrsbjAxyC+xsfEsPogvb3HxMC7IMfUsrIgs6q0qb7uvt8gx9IgtqcgIMDUtM+02S4NCiC0
57vnv6G8rbTCIMDMufggwvy757fOIMDOx9gguLnAuiC+7rfBv/LAuyCw3rDtILDovcW60LXpsrIg
IMG2sd3AzLbztbUgDQogtbW/8sC7ILXluK6w7cDaILvntvvAxyC4sbe5wMwgx+C757imIL3Dx+DH
z7/AtM8guLnAuiDC/L+pICC52bb4tM+02S4NCiAgICAgICAgIA0KICAgICAgICAgICAgICAgILHN
x88osc275ynAxyDAzLjewM8gwda80rTCIMDOxc2z3bvzwMcgsNS9w8bHte6/obytILz2wf3Hz7+0
wLi45ywNCiDAzLjewM8gwda80iC/3L+htMIgvu62sMfRIMGkuri1tSCwocH2sO0gwNbB9iC+yr3A
tM+02S4NCiC6uyC43sDPwLogud+9xcD8v+vA1LTPtNkuILT1wMy78yC43sDPwLsgv/jEoSC+ysC4
vcO46SC+xrehwMcgvPYgvcUgsMUgus64piDFrLivIMfYwda8vL/kLiANCiDBwcC6IMfPt+cguriz
u7y8v+QuDQogSWYgeW91IGRvbid0IHdhbnQgdGhpcyB0eXBlIG9mIGluZm9ybWF0aW9uIG9yIGUt
bWFpbCwgcGxlYXNlIGNsaWNrIHRoZSdyZWZ1c2UnIGJ1dHRvbi4gIA0KIFu89r3FsMW6zihyZWZ1
c2UpXQ0KICAgICAgICAgICAgICAgICAgICAgDQogICA=

Re: [Etherboot-developers] boot1a.s hacked to take .z?img directly

[<ke...@us...>]

>> Actually I think I know what it is.  I don't think the EDD packet
>> interrupt that boot1a calls can handle > 64kB transfers.
>
>Ah.  Being 16bit code that makes a lot of sense.
>And I suspect with a little care it is solvable with a little loop.

My brain hurtz after all that assembly. I'll take a stab at it when I
have recovered. :-)

Re: [Etherboot-developers] Adding more device ids to drivers

[<ke...@us...>]

>Now that adding new vendor/device ids require only one change: Does it make 
>sense to add combinations that are missing in etherboot, but present in linux?
>I think it is safe to add them if the linux driver handles the missing ids 
>exactly like the existing ones. If there are no objections, I will do this.

Yes, please do. If they don't work, we can fix them, but if they are
never added, they are never tested. Thanks.

[Etherboot-developers] Adding more device ids to drivers

[Georg B. <Geo...@po...>]

Now that adding new vendor/device ids require only one change: Does it make 
sense to add combinations that are missing in etherboot, but present in 
linux?
I think it is safe to add them if the linux driver handles the missing ids 
exactly like the existing ones. If there are no objections, I will do this.

Georg

Re: [Etherboot-developers] boot1a.s hacked to take .z?img directly

[Georg B. <Geo...@po...>]

Am Montag, 10. M=E4rz 2003 13:47 schrieb ke...@us...=
t:
> I've hacked boot1a.s so that it can be prepended to .z?img's instea=
d of
> .z?rom's. It also takes the block count from the word at location 2=
 of
> the boot block, which is written into by the build script,
> util/builddsk.pl (new file). As a bonus, it only loads as many bloc=
ks as
> needed, not the next standard size of EPROM.
>
> Stuff in CVS. Testers appreciated.

Works (only floppy tested), both compressed and uncrompessed single-d=
river=20
images.

Georg

Re: [Etherboot-developers] boot1a.s hacked to take .z?img directly

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >It boots a single NIC driver, but when given etherboot.zimg, it fails
> >with a Rd err. It was trying to read 0x9B blocks. I don't know if this
> >is a media error, or a limitation of the packet interrupt that boot1a.s
> >calls.
> 
> Actually I think I know what it is.  I don't think the EDD packet
> interrupt that boot1a calls can handle > 64kB transfers.

Ah.  Being 16bit code that makes a lot of sense.
And I suspect with a little care it is solvable with a little loop.

At least the strange failures are starting to make sense.

I think we are finally on the downhill path towards 5.2.

The only outstanding thing I have remaining on my todo list
is to enable multicast support in the rest of the drivers.

Eric

Re: [Etherboot-developers] Re: Etherboot Broadcom driver

[<ebi...@ln...>]

<rant> Have discussions on the mailing list please </rant>

Jin Mazumdar <maz...@co...> writes:

> Eric,
> 
> Here is what I have so far.
> 
> I used the production 5.0.8 source to compile a floppy for linux and was able to
> 
> boot linux off it successfully.
> 
> I was able to use the same to compile a floppy for FreeBSD and was able to load
> the kernel but was unable to boot the FreeBSD kernel.  It stopped after printing
> 
> done after the set of dots it prints while loading the kernel.  I need to look
> into this to see what I am missing.
> 
> I was able to compile a floppy for booting linux with the etherboot development
> version 5.1.6 but was unable to load etherboot from the floppy.  The message I
> get is 00000 Err.  Things seem to have changed from the production release.  I
> built a floppy by catting the bin/boot1a.bin and the bin/tulip.img files.  I am
> using a AN983 ethernet card.  Is this this the correct process?

Not quite:

make bin/tulip.fd0 
or
make bin/tulip.dsk

To cat it together manually you need to include whatever $(START16) expands
to in the makefile.
 
> Did not see the tg3 driver.  Please let me know where it is.

In CVS and I believe in 5.1.8.

> 
> Thanks.
> 
> -Jin

Re: genrules.pl and prism2, was: Re: [Etherboot-developers] pxe and lilo prefix on i386

[Georg B. <Geo...@po...>]

Am Montag, 10. M=E4rz 2003 14:28 schrieb Ken Yap:
> >But I do know now. The problem is that prism2_pci.c and prism2_plx=
.c do
> > not contain any PCI_ROM macro, because the real driver file is pr=
ism2.c
> > that gets included. A possible solution would be to move the pci_=
id and
> > pci_driver structs out of prism2.c and into prism2_p*.c.
>
> Go ahead if you feel like hacking the CVSed sources again. Thanks.

Done.

Georg

Re: [Etherboot-developers] boot1a.s hacked to take .z?img directly

[<ke...@us...>]

>It boots a single NIC driver, but when given etherboot.zimg, it fails
>with a Rd err. It was trying to read 0x9B blocks. I don't know if this
>is a media error, or a limitation of the packet interrupt that boot1a.s
>calls.

Actually I think I know what it is.  I don't think the EDD packet
interrupt that boot1a calls can handle > 64kB transfers.

Re: genrules.pl and prism2, was: Re: [Etherboot-developers] pxe and lilo prefix on i386

[<ke...@us...>]

>But I do know now. The problem is that prism2_pci.c and prism2_plx.c do not
>contain any PCI_ROM macro, because the real driver file is prism2.c that 
>gets included. A possible solution would be to move the pci_id and
>pci_driver structs out of prism2.c and into prism2_p*.c.

Go ahead if you feel like hacking the CVSed sources again. Thanks.

[Etherboot-developers] boot1a.s hacked to take .z?img directly

[<ke...@us...>]

I've hacked boot1a.s so that it can be prepended to .z?img's instead of
.z?rom's. It also takes the block count from the word at location 2 of
the boot block, which is written into by the build script,
util/builddsk.pl (new file). As a bonus, it only loads as many blocks as
needed, not the next standard size of EPROM.

It boots a single NIC driver, but when given etherboot.zimg, it fails
with a Rd err. It was trying to read 0x9B blocks. I don't know if this
is a media error, or a limitation of the packet interrupt that boot1a.s
calls.

Anyway that's one win and one not won yet. It could be that for large
drivers, the reliable method is to go through a proper loader like LILO,
GRUB or SYSLINUX.

Stuff in CVS. Testers appreciated.

Re: genrules.pl and prism2, was: Re: [Etherboot-developers] pxe and lilo prefix on i386

[Michael B. <mb...@fe...>]

> >But I do know now. The problem is that prism2_pci.c and prism2_plx.c =
> >do not=20
> >contain any PCI_ROM macro, because the real driver file is prism2.c t=
> >hat=20
> >gets included. A possible solution would be to move the pci_id and=
> >=20
> >pci_driver structs out of prism2.c and into prism2_p*.c.
> Or maybe declare the driver as prism2.c in the family line? I don't know
> the answer because they could be two drivers with a common file (in
> which case your solution is the right one), or the same driver with two
> variations and tables should be merged.  You there Michael?

Two drivers with a common file.  Actually, all that prism2_*.c do is
define the interface type (_pci or _plx) and then #include prism2.c.
This is not my first choice of architecture; it's done because I wanted to
be able to use the header files from linux-wlan-ng without modifications
and this is the way that linux-wlan-ng is structured.

Moving PCI_ROM into prism2_*.c is the correct solution, at least until a
full PCMCIA subsystem gets written.  ;-)

Michael

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >It also computes the checksum of the rom image at least that is
> >what I recall. 
> 
> I think you mean genrom, which computes the checksum of the RUM image
> and stores it in a byte in the ROM header. This will be out of the
> picture if we bypass the ROM header.

Hmm. I looked again I thought the floppy loader was actually verifing that
checksum but I don't see that currently.  Oh well.

Eric

Re: genrules.pl and prism2, was: Re: [Etherboot-developers] pxe and lilo prefix on i386

[<ke...@us...>]

>But I do know now. The problem is that prism2_pci.c and prism2_plx.c =
>do not=20
>contain any PCI_ROM macro, because the real driver file is prism2.c t=
>hat=20
>gets included. A possible solution would be to move the pci_id and=
>=20
>pci_driver structs out of prism2.c and into prism2_p*.c.

Or maybe declare the driver as prism2.c in the family line? I don't know
the answer because they could be two drivers with a common file (in
which case your solution is the right one), or the same driver with two
variations and tables should be merged.  You there Michael?

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ke...@us...>]

>It also computes the checksum of the rom image at least that is
>what I recall. 

I think you mean genrom, which computes the checksum of the RUM image
and stores it in a byte in the ROM header. This will be out of the
picture if we bypass the ROM header.

genrules.pl and prism2, was: Re: [Etherboot-developers] pxe and lilo prefix on i386

[Georg B. <Geo...@po...>]

Am Donnerstag, 6. M=E4rz 2003 23:10 schrieb Ken Yap:
> Entries in NIC are not looked at any more except to provide the
> families. In the new scheme the Rom entries are generated by scanni=
ng
> the driver source. I don't know what happened for prism2_pci.

But I do know now. The problem is that prism2_pci.c and prism2_plx.c =
do not=20
contain any PCI_ROM macro, because the real driver file is prism2.c t=
hat=20
gets included. A possible solution would be to move the pci_id and=
=20
pci_driver structs out of prism2.c and into prism2_p*.c.

Georg