etherboot-developers — Discussion of developer issues

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

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

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

> >The floppy loader was checking checksums etc, and it was non-trivial
> >enough that I simply have not done the work to make that case work.
> 
> Hmm, I think you mean the bit where it's looking for signature 55AA at
> the beginning of the file? I think that and getting the block count from
> the third byte are the only things it expects in the ROM image.

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

> I had a look at it and it uses dh,dl to pass the block count,drive
> number) to the xread.1 subroutine. We'll have to find a way to pass a
> word.

Interesting...

If we can get etherboot.dsk to work reliably we will definitely have
something.

Eric

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

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

>The floppy loader was checking checksums etc, and it was non-trivial
>enough that I simply have not done the work to make that case work.

Hmm, I think you mean the bit where it's looking for signature 55AA at
the beginning of the file? I think that and getting the block count from
the third byte are the only things it expects in the ROM image.

I had a look at it and it uses dh,dl to pass the block count,drive
number) to the xread.1 subroutine. We'll have to find a way to pass a
word.

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

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

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

> >Older code like the floppy loader always builds the .rom files and looks like
> >:
> >floppyprefix rom_header start16 .img
> >
> >Things are simpler in the makefile for .dsk images because it happens
> >in two separate steps instead of just one.  
> 
> Hmm, that suggests that it's possible to remove the rom_header from this
> chain and have boot1a.s load the rest, perhaps with the help from an
> auxiliary script to set a word in boot1a.s indicating how many blocks to
> load. Then boot1a.s would not be subject to the 127.5 kiB limitation of
> ROM images.

Yep.  That is the direction I have been going in 5.1.x.

The floppy loader was checking checksums etc, and it was non-trivial
enough that I simply have not done the work to make that case work.

I would have to check but I think the floppy loader may actually be the
last holdout.
 
> In the past the floppy loader was used to check that the ROM image would
> work, but I think the production process is reliable enough that we can
> believe that prepending loader.S will produce a valid ROM.

And also note that loader.S is now very much simpler, as the 16->32 bit
code and the decompresser have been move out of it.

Eric

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

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

>Older code like the floppy loader always builds the .rom files and looks like
>:
>floppyprefix rom_header start16 .img
>
>Things are simpler in the makefile for .dsk images because it happens
>in two separate steps instead of just one.  

Hmm, that suggests that it's possible to remove the rom_header from this
chain and have boot1a.s load the rest, perhaps with the help from an
auxiliary script to set a word in boot1a.s indicating how many blocks to
load. Then boot1a.s would not be subject to the 127.5 kiB limitation of
ROM images.

In the past the floppy loader was used to check that the ROM image would
work, but I think the production process is reliable enough that we can
believe that prepending loader.S will produce a valid ROM.

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

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

>Actually saying start16.S is still needed is exactly backwards.
>
>To clarify.
>A binary image is built by first building .img and the taking things
>in front of it.

Thanks, that's saved me some work when it comes to documenting how it
all works. I was under the impression that the .img files had a 16-bit
entry point.

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

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

ke...@us... writes:

> I have released Etherboot 5.1.7 at http://www.etherboot.org Please try
> it out.
> 
> Changes from 5.1.6:
> 
> + Broadcomm TG3 support by Eric Biederman.
> 
> + Georg Baum found that the start16.S prefix is still needed for LILO
> and PXE images, those formats were broken. He also migrated the PCI IDs
> into the driver files. Those formats should work again.

Actually saying start16.S is still needed is exactly backwards.

To clarify.
A binary image is built by first building .img and the taking things
in front of it.

So for pxe we have:
pxeprefix start16 .img

And similiarly for lilo:
liloprefix start16 .img

start16 just performs the transition from 16 to 32bit mode.

For zpxe and similary for zlilo we have:
pxeprefix start16 unnrv2b .zimg 
And .zimg is just .img compressed using the nrv2b algorithm.

Older code like the floppy loader always builds the .rom files and looks like:
floppyprefix rom_header start16 .img

Things are simpler in the makefile for .dsk images because it happens
in two separate steps instead of just one.  

So in summary start16 is needed whenever we are starting in 16bit mode
and things like the pxe loader and the lilo loader can take advantage
of that by skipping the need to be a .rom image first.

Eric

[Etherboot-developers] Etherboot 5.1.7 (development) released

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

I have released Etherboot 5.1.7 at http://www.etherboot.org Please try
it out.

Changes from 5.1.6:

+ Broadcomm TG3 support by Eric Biederman.

+ Georg Baum found that the start16.S prefix is still needed for LILO
and PXE images, those formats were broken. He also migrated the PCI IDs
into the driver files. Those formats should work again.

+ Reworked genrules.pl. Family declarations now in here document inside
genrules.pl. NIC is now an output file, for use by rom-o-matic.

MD5 sum:

0c15be8f3574a22438bf9e798ae2cf06  etherboot-5.1.7.tar.bz2

SHA1 sum:

464efe175959eeac1160ee8a85601b77ee109bf3  etherboot-5.1.7.tar.bz2

Re: [Etherboot-developers] changes to genrules.pl

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

ke...@us... writes:

> Eric,
> 
> I'm going to make some changes to genrules.pl in the next day or so.
> 
> 1. I'm moving the info now in NIC (mostly family declarations now) into
> genrules.pl as a here document.

O.k  As long as we can still do non family declarations that should
work.  I kept NIC fully working so we could have a gradual change,
and it worked :)  

> 2. I'm making NIC an output file instead of an input file, in the same
> format (minus the comments), for the sake of rom-o-matic.

That sounds reasonable.

> 3. I can then compare NIC with 5.1.6 NIC and see what aliases have been
> eliminated. If necessary some other way of providing the user with the
> aliases can be devised.

Eric

[Etherboot-developers] changes to genrules.pl

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

Eric,

I'm going to make some changes to genrules.pl in the next day or so.

1. I'm moving the info now in NIC (mostly family declarations now) into
genrules.pl as a here document.

2. I'm making NIC an output file instead of an input file, in the same
format (minus the comments), for the sake of rom-o-matic.

3. I can then compare NIC with 5.1.6 NIC and see what aliases have been
eliminated. If necessary some other way of providing the user with the
aliases can be devised.

Re: [Etherboot-developers] Descriptor alignment question

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

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

> >I have not looked at the sundance driver in a bit, but I seem to be
> >still wondering why it is so slow.  I was never sure whether the
> >descriptor was properly aligned.
> 
> I think your alignment looks ok. 

Note: Etherboot currently cannot promise more than 16 byte alignment.
This needs to be documented somewhere.  

I'm not certain it ever did promise more but with the code living in
a fixed location it was not a big deal.  Once -DRELOCATION can be made
unconditional we may be able to do better but not right now.

> Usually it will not work if misaligned.
> What I suspect is that the method for determining if a packet is
> available is not reliable.  There should be a bit that indicates there
> is something in the receive buffer. If necessary you may have to look at
> a different register, maybe RxStatus. This is the main difference
> between interrupt and polled operation.

That sounds like a good diagnosis.

Note in interrupt mode it is still a good idea to check to see if
a packet has received an interrupt.  You may be sharing an interrupt
with another device, an interrupt can in before the last one was
serviced, or there may be some kind of interrupt mitigation strategy
in place.  So a robust driver using interrupts will also check the polling
bits.

Eric

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

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

ke...@us... writes:
> >I find myself with some spare time and would like to take a shot at 
> >writing (leveraging) a driver.  I have not written a device driver 
> >before.  I am comfortable with C.  I have no microprocessor experience 
> >but fortunately the source code for the OS driver is available under 
> >linux.  I have read your developers doc and somewhere you mention that 
> >you are willing to assist in such ventures. Could you let me know if it 
> >is a reasonable project and the best starting point?
> 
> It is a good idea but Eric Biederman has already started one and if Eric
> cannot get a driver to work, nobody can. It's in the 5.1 CVS tree,
> tg3.c. You can help us test it when it's further along.

The driver should be useful at the moment.  More testing could not hurt. 
The tg3 nic has an unreasonable amount of state that must be initialized
and maintained so even after some very heavy whacking of the code it is
by far the largest driver in etherboot.

Since getting the tg3 driver working I have been off on other things
I keep an eye out but mostly I am ignoring the world and writing
a compiler that does not use static variables or a stack, to make
LinuxBIOS easier to cope with.  So I am little distracted at the
moment.

But if you have some of that free time messing testing the tg3 driver
would be good.   The tg3 is actually a terrible place to start writing
drivers as there is no documentation readily available.  I wrote
the whole driver by reading the source of the linux driver and
stripping it down.

Eric

[Etherboot-developers] Re: Etherboot Broadcom driver

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

>Second, I did not have much success with FreeBSD.  Although the 
>documentation says that I do not need a tagged image for freeBSD, when I 
>try to boot FreeBSD it says something about not fitting in any segment 
>or something to that effect and goes into a retry loop.  Could you shed 
>some light on this?

You need to compile with -DIMAGE_FREEBSD. This happens automatically
under FreeBSD but needs to be set when compiling under Linux.

>Third, my reason for using the diskless boot is to have both linux and 
>freeBSD available.  I have put together a new machine with hardware some 
>of which have linux drivers but not FreeBSD and vice versa.  An example 
>is a Broadcomm 1000Mb ethernet driver.  I believe it has something to do 
>with the Tigon TG3 ( chip ?).  There is a driver for this under linux 
>and it works well after the system is booted.  However, there is no 
>etherboot driver for it.  I have put in another common ethernet card to 
>get around this.
>
>I find myself with some spare time and would like to take a shot at 
>writing (leveraging) a driver.  I have not written a device driver 
>before.  I am comfortable with C.  I have no microprocessor experience 
>but fortunately the source code for the OS driver is available under 
>linux.  I have read your developers doc and somewhere you mention that 
>you are willing to assist in such ventures. Could you let me know if it 
>is a reasonable project and the best starting point?

It is a good idea but Eric Biederman has already started one and if Eric
cannot get a driver to work, nobody can. It's in the 5.1 CVS tree,
tg3.c. You can help us test it when it's further along.

Further discussion moved to Etherboot developer mailing list.

Re: [Etherboot-developers] pxe and lilo prefix on i386

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

>But I agree to your other mail that we should only have one rom for e=
>very=20
>vendor/device id combination. Probably somebody should check wether I=
> moved=20
>the right rom names to the .c files before deleting the remaining NIC=
>=20
>entries.

Say a NIC manufacturer is the first to use a particular controller chip,
using a PCI ID tuple. The particular combination gets named by that
model. Later the chip is sold to other manufacturers and they continue
to use the same ID tuple. NIC used to handle this by aliases. Ideally
Etherboot should only care about PCI IDs and not the name, but people
are used to asking for binaries by name. But there should be only one
Etherboot name for that tuple. If it happens to be the first
manufacturer's model name, well they get the glory.

I know Marty will hate me for this, but maybe the alias information
should be maintained by rom-o-matic (and/or maybe the NIC DB) since it's
there that most people look for a matching entry. Maybe a query box
where people type in free-format and it comes up with a suggestion. It
would also help people who ask about rtl8019 for example. From there it
would take the user back to the generate-a-rom dialogue with the right
entry selected.

Re: [Etherboot-developers] Descriptor alignment question

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

>I have not looked at the sundance driver in a bit, but I seem to be
>still wondering why it is so slow.  I was never sure whether the
>descriptor was properly aligned.

I think your alignment looks ok. Usually it will not work if misaligned.
What I suspect is that the method for determining if a packet is
available is not reliable.  There should be a bit that indicates there
is something in the receive buffer. If necessary you may have to look at
a different register, maybe RxStatus. This is the main difference
between interrupt and polled operation.

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.

My experience is that the entries in NIC still work: You can add an e=
ntry to=20
a family, and genrules.pl will spit out some rules for it.

But I agree to your other mail that we should only have one rom for e=
very=20
vendor/device id combination. Probably somebody should check wether I=
 moved=20
the right rom names to the .c files before deleting the remaining NIC=
=20
entries.


Georg

Re: [Etherboot-developers] pxe and lilo prefix on i386

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

>- Some drivers had multiple entries in NIC for the same vendor/device=
> ids,=20
>but with different image names. I moved the first one into the .c fil=
>e, but=20
>left the others in NIC.

I think we'll just have to give up all except one name.

There's one thing more that needs to be done and that is to somehow
extract a list of IDs for Marty to use for rom-o-matic.

Thanks for the work!

RE: [Etherboot-developers] pxe and lilo prefix on i386

[Timothy L. <tl...@ro...>]

> A few notes:
> - The sundance driver has an ISA like entry in NIC. For what purpose?
I
> left

I was probably mistaken when I created that entry.  There is no logical
reason to have it.  



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003
 

[Etherboot-developers] Descriptor alignment question

[Timothy L. <tl...@ro...>]

Hi

I have not looked at the sundance driver in a bit, but I seem to be
still wondering why it is so slow.  I was never sure whether the
descriptor was properly aligned.

The following is in the spec for the sundance st201 chip:

Transmit Next Pointer, the first double word in the TFD contains the
physical address of the next TFD in the TxDMAList. The value of zero
accompanies the last frame of the list and it indicates there are no
more TFD=92s in the TxDMAList. All TFD=92s must be aligned on 8-byte
physical address boundaries, requiring Bits [2..0] of TxDMANextPtr to
be zero.

The first dword in the RFD contains the physical address of the next
RFD in the RxDMAList. If this is the last RFD in the RxDMAList, then
this value must be zero. RFDs must be aligned on 8-byte physical
address boundaries.


Does the following code do this alignment correctly?  Is there any need
to align the buffers?

/* The Rx and Tx buffer descriptors.
*/
struct netdev_desc {
    u32 next_desc;
    u32 status;
    u32 addr;
    u32 length;
};

/* Define the TX Descriptor */
static struct netdev_desc tx_ring[TX_RING_SIZE]
    __attribute__ ((aligned(8)));

/* Create a static buffer of size PKT_BUF_SZ for each
TX Descriptor.  All descriptors point to a
part of this buffer */
static unsigned char txb[PKT_BUF_SZ * TX_RING_SIZE];
    __attribute__ ((aligned(8)));


/* Define the RX Descriptor */
static struct netdev_desc rx_ring[RX_RING_SIZE]
    __attribute__ ((aligned(8)));

/* Create a static buffer of size PKT_BUF_SZ for each
RX Descriptor   All descriptors point to a
part of this buffer */
static unsigned char rxb[RX_RING_SIZE * PKT_BUF_SZ];
    __attribute__ ((aligned(8)));

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003
=20

Re: [Etherboot-developers] pxe and lilo prefix on i386

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

>Ok, it is checked in now.
>
>A few notes:
>- The sundance driver has an ISA like entry in NIC. For what purpose?=
> I left=20
>it in.

This is probably a mistake as it's a PCI NIC.

>- Some drivers had multiple entries in NIC for the same vendor/device=
> ids,=20
>but with different image names. I moved the first one into the .c fil=
>e, but=20
>left the others in NIC.
>- Comparison of src/bin/Roms before and after the changes showed that=
> the=20
>generation of rules for the "prism2_pci" rom did not work. I don't kn=
>ow=20
>why, but I left this entry also in NIC.
>- Finally, I found quite a few device ids in the driver files that ha=
>d no=20
>corresponding entry in NIC. This shows that storing these things only=
> once=20
>is important!

Entries in NIC are not looked at any more except to provide the
families. In the new scheme the Rom entries are generated by scanning
the driver source. I don't know what happened for prism2_pci.

Re: [Etherboot-developers] pxe and lilo prefix on i386

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

Am Mittwoch, 5. M=E4rz 2003 12:43 schrieb Ken Yap:
> >BTW, I can convert the other drivers to your new PCI_ROM macro if =
you
> > don't want to do it yourself.
>
> Just go ahead and do it, that and the prefix fixes will give me an
> excuse to release 5.1.7. Thanks.

Ok, it is checked in now.

A few notes:
- The sundance driver has an ISA like entry in NIC. For what purpose?=
 I left=20
it in.
- Some drivers had multiple entries in NIC for the same vendor/device=
 ids,=20
but with different image names. I moved the first one into the .c fil=
e, but=20
left the others in NIC.
- Comparison of src/bin/Roms before and after the changes showed that=
 the=20
generation of rules for the "prism2_pci" rom did not work. I don't kn=
ow=20
why, but I left this entry also in NIC.
- Finally, I found quite a few device ids in the driver files that ha=
d no=20
corresponding entry in NIC. This shows that storing these things only=
 once=20
is important!


Georg

Re: [Etherboot-developers] rtl-8019 isa card help

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

>I need support on the rtl8019 isa card. The rom-o-matic site does not match 
>exactly to this. Please help.

The 8019 is a NE2000 clone therefore the ne.rom image supports it. This
is not a developer question. If you had posted to the users list,
somebody for sure would have told you this. Some (all?) 8019s are PnP so
you may need the vendor utility to manually set the I/O address.

[Etherboot-developers] rtl-8019 isa card help

[Aravamudhan R. <r_a...@ho...>]

Hi
I need support on the rtl8019 isa card. The rom-o-matic site does not match 
exactly to this. Please help.
Thanks
Arav






_________________________________________________________________
Cricket World Cup 2003- News, Views and Match Reports. 
http://server1.msn.co.in/msnspecials/worldcup03/

Re: [Etherboot-developers] pxe and lilo prefix on i386

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

>Eric, I think you removed $(START16). What is wrong with that? Could we add 
>it back, or do you plan to change something else?

It may have been me. I have to get to the bottom of why they are still
needed and how to fix that when I have a moment.

>BTW, I can convert the other drivers to your new PCI_ROM macro if you don't 
>want to do it yourself.

Just go ahead and do it, that and the prefix fixes will give me an
excuse to release 5.1.7. Thanks.

[Etherboot-developers] pxe and lilo prefix on i386

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

Hi,

as I wrote in a mail on the users list, the pxe and lilo images don't work 
on i386. As described in the mail, they do if one adds $(START16) to the 
make rules.
We had this issue at least with lilo last year, and I thought that the 
changes that Ken made to liloprefix.S:

jmp     $SYSSEG, $0x0

instead of

jmp     $SYSSEG, $0x06

made the trick. However, it appears that $(START16) is still needed.

Is this only broken for me, or is nobody else using 5.1.x with x >=4 and pxe 
or lilo?

Eric, I think you removed $(START16). What is wrong with that? Could we add 
it back, or do you plan to change something else?
BTW, I can convert the other drivers to your new PCI_ROM macro if you don't 
want to do it yourself.

Georg

[Etherboot-developers] [±¤°í]ºÎ¾÷Á¤º¸¡ØÀÎÅͳݿ¡ °¡ÀÔÇϽøé ÃÖ´ë»çÀºÇ°À» µå¸³´Ï´Ù.!!!

[ÀÎÅͳÝ<ttl...@ya...>]

<HTML>
<a href="http://ip.infomaster.co.kr/?GEOPIAFROM=life21">부업정보
<img src="http://ad.infomaster.co.kr/infomaster/division_img/135x51_01.gif" border="0">문의사항</a>
<BR><BR>※인터넷에 가입하시면 최대사은품을 드립니다.!!!
<BR><BR> * 설치비/가입비 무료
<BR><BR> * 3개월 사용료 무료
<BR><BR> * 최저: 25,500부터~
<BR><BR> * 상품도 다양합니다.
<BR><BR>
------------ 아   래 ------------
<BR><BR>
*** 옥매트(2인용)/자전거 (21단,접이식) <--둘중 택일
<BR><BR>******* <아래 상품 모두 공짜> *******
<BR><BR> *** sk정수기, 디지털카메라 상품권, 랜카드, 헤드셋,
<BR><BR> *** 제주도/필리핀여행 무료숙박권, 구두전문 런던소마 상품권
<BR><BR><BR>
<A href="mailto:to...@ha...">수신거부</A></HTML>