etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] etherboot-5.1.2rc6

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

ke...@us... writes:

> Ok, I have put this at
> 
> 	http://www.etherboot.org/etherboot-5.1.2rc6.tar.bz2
> 
> I'm thinking perhaps this could be the last or next to last RC, what do
> you think Eric, do you have more patches to go in?

I have one change on my todo queue.  But it hasn't been written yet,
and is LinuxBIOS specific so it can easily go in later.
 
> I have not done any testing on it aside from verifying that it compiles
> (in the default configuration). Maybe I should make up a checklist of
> features to be checked (types of images, common NICs, commonly chosen
> defines) and post to this list and testers can report on success or
> failure, is this a good idea?

Sounds good to me.  This kind of thing probably works best against
a development release so it is easy to go back in cvs and verify the
code. 
 
> There are quite a few warnings from my gcc, mostly about unused
> variables, are these worth fixing Eric?

Probably.  What happened is someone a while ago turned off warnings
about unused variables.  I added a macro __unused (to supress the warning
in bogus places) and fixed the worst spurious reporters.  And then
I renabled the warnings.  If the variables are truly unused we can kill
them and make etherboot just a little bit smaller.

Eric

Re: [Etherboot-developers] serial.c

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

ke...@us... writes:

> Eric, thanks for serial.c, I'm stealing it for 5.0.8.
> 
> Thought: should the file be renamed pcserial.c for when Etherboot is
> ported to another platform with a different UART?

Leave it as serial.c for now.  If we rename it we should
name it uart16450_serial.c  or something like that.

A pc prefix just doesn't quite do it.
If/when we start collecting more console drivers in 5.1.2+ we really
need to set them up so probe() can find them.  That way have we can
cleanly multiplex between the hardware that is available.  And keep
the different drivers in different files.

Eric

Re: [Etherboot-developers] Make $500 for a working fix for the prism2 driver.

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

On Wed, 16 Oct 2002, Ken Yap wrote:
> >OK, this issue is now resolved.  A working version for 5.0 is in CVS.  The
> >fix has been ported to 5.1 and checked in but not yet tested (it's simple
> >enough that I don't expect any problems).
> Thanks Michael, good work. Will check out the source shortly.

There's one more fix in as well now.  I've just got a new access point (a
Linksys WAP11) and discovered that the Prism2 driver had problems doing
repeated autojoins.  The first join would succeed, subsequent attempts
would fail until the *access point* was reset.  Resetting (or even
powering down) the workstation containing the Prism2 card had no effect.

Eventually traced this down to a behavioural quirk of the Linksys WAP11:
when a card attempts to join to it, if the AP thinks the card is already
joined then it will send a "you are disconnected" notification and wait a
few seconds before sending the "you are now connected" notification.  The
Prism2 driver was receiving the "you are disconnected" notification and
assuming it represented a failure to join (the message that appears is
"Link not connected (status 0x0006)".

The Prism2 driver (in both 5.0 and 5.1) will now listen for up to
MAX_JOIN_INFO_COUNT INFO packets before finally giving up.  I've set
MAX_JOIN_INFO_COUNT to 2, which solves the problem for the Linksys WAP11.

I'm puzzled by the fact that no-one else seems to have reported this
problem.  Is this really a quirk of just this one model of access point?
I'm going to contact Linksys tomorrow, so it would be helpful to know if
anyone else has experienced similar "Link not connected (status 0x0006)"
problems and, if so, with which makes of access point.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Make $500 for a working fix for the prism2 driver.

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

>OK, this issue is now resolved.  A working version for 5.0 is in CVS.  The
>fix has been ported to 5.1 and checked in but not yet tested (it's simple
>enough that I don't expect any problems).

Thanks Michael, good work. Will check out the source shortly.

Re: [Etherboot-developers] Make $500 for a working fix for the prism2 driver.

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

On Wed, 2 Oct 2002, Boris wrote:
> Yes, its true. You can make $500can [Because I live in canada] just to
> get the Prism2_pci driver working properly. Yes, The prism2_pci driver
> works but *only* for small bootable images. Anything larger then
> around 18-20mb's causes errors to occur. Im sure you are asking why
> not just make smaller images but thats not what we want to do. The
> Realtek 8029 and Realtek 8139 driver boots up our 42mb images no
> problem but the Prism2_pci driver doesn't. We will pay for anyone to
> properly correct this issue. Not a quick hack but a proper fix. If the
> driver is working properly then what is causing it stop working.
> [Check out our specs]. More information can be found on our website
> [Just a quick website ].
> Check out http://www.thinovations.com/wireless/

OK, this issue is now resolved.  A working version for 5.0 is in CVS.  The
fix has been ported to 5.1 and checked in but not yet tested (it's simple
enough that I don't expect any problems).

The cause of the problem is that the Prism2 card receives a constant
stream of INFO events during the download.  The driver was ignoring these
events, since it isn't sophisticated to do anything with the information
that they contain anyway.  However, for each INFO event, the Prism2
allocates an internal buffer that holds the actual information.  It
expects the driver to read this buffer and then acknowledge the event,
thereby freeing up the buffer.  Since the Etherboot driver was completely
ignoring the INFO events, over the course of time the Prism2 would exhaust
its buffer space.  This was only visible on very large images (~20MB and
more).

The solution was simple: simply acknowledge the INFO events as they occur.
We still ignore the contents of the events, but acknowledging them frees
up the buffers and so the internal storage does not become exhausted.
Problem solved.

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] bin and bin32

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

What do you think of the idea of merging both directories as ia32?
(bin was for stuff that was neither bin16 nor bin32, usually auxiliary
binaries or prefixes, but there is no more bin16 so this distinction is
no longer necessary.) Other architectures, when ported to, would then
compile to binaries under the architecture name.

Just did a 2 minute experiment, s/bin(32)?/ia32/g in Makefile and
genrules.pl, rm Roms, and it builds fine.

[Etherboot-developers] etherboot-5.1.2rc6

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

Ok, I have put this at

	http://www.etherboot.org/etherboot-5.1.2rc6.tar.bz2

I'm thinking perhaps this could be the last or next to last RC, what do
you think Eric, do you have more patches to go in?

I have not done any testing on it aside from verifying that it compiles
(in the default configuration). Maybe I should make up a checklist of
features to be checked (types of images, common NICs, commonly chosen
defines) and post to this list and testers can report on success or
failure, is this a good idea?

There are quite a few warnings from my gcc, mostly about unused
variables, are these worth fixing Eric?

[Etherboot-developers] serial.c

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

Eric, thanks for serial.c, I'm stealing it for 5.0.8.

Thought: should the file be renamed pcserial.c for when Etherboot is
ported to another platform with a different UART?

[Etherboot-developers] There is something odd going on with eepro-100

[Ronald G M. <rmi...@la...>]

Here is the scenario. This is a pre-release etherboot from Eric that has
worked well on a number of platforms. The version is 5.1.2rc4.eb5.

I take two identical advantech PCM-5283-2 systems, and put in a linuxbios
flash that has worked fine for many months on a PCM-5823-1. The Etherboot
I have built will boot preferentially from Compact Flash, loading a kernel
and initrd which uses eepro100 to contact a server. If no flash is found,
then it does a boot over Ethernet.

		System A		System B
CF boot Linux	Works			Works

No CF, boot net	Works			Fails; sends DHCP but never sees
					reply. Packet is visible on
					network and dhcpd responds



So, we have an interface which seems to work, and works on linux. It's
basically the same board. etherboot correctly reads the MAC address from
ROM. dhcpd sees packets from etherboot in both cases and responds. But
System B never sees the reply ... this is really very odd.

Here is the best part of all. An older flash, running etherboot 5.0.6,
System B works fine. Yikes!

I have no idea what relationship this has, if any, to the Smartcore
problem I have been having, but it is at least pretty suspicious. The
symptoms are almost identical.

Anyway, I'm going to stick with CF for now but wanted to let the community
know what was up.

ron

Re: [Etherboot-developers] question on building

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> I'm on 5.1. The .ebi suffix seems to be gone; should I assume you build a
> linuxbios-loadable image as, e.g., bin32/eepro100.elf?

Right.  The .ebi suffix was redundant so I removed that case.

Eric

[Etherboot-developers] question on building

[Ronald G M. <rmi...@la...>]

I'm on 5.1. The .ebi suffix seems to be gone; should I assume you build a
linuxbios-loadable image as, e.g., bin32/eepro100.elf?

ron

[Etherboot-developers] Re: multicast

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> On 8 Oct 2002, Eric W Biederman wrote:
> 
> > Ron have you been able to reproduce the smart core problem with the
> > current etherboot-5.1 cvs tree?
> 
> I am giving that a shot tomorrow (he says with hope in his voice).
> 
> Do you recommend I cvs checkout the 5.1 tree or use that snapshot you sent
> me?

etherboot cvs the code should be fundamentally the same.

The only big difference I can think of I have a first pass of your
NOTIMER2 code in my tree, in timer.c but since it works so poorly, and
it looks nasty I haven't merged that. 

> I like the improvements to etherboot. Nice work!

Good.  We will see what happens.

Eric

[Etherboot-developers] Re: multicast

[Ronald G M. <rmi...@la...>]

On 8 Oct 2002, Eric W Biederman wrote:

> Ron have you been able to reproduce the smart core problem with the
> current etherboot-5.1 cvs tree?

I am giving that a shot tomorrow (he says with hope in his voice).

Do you recommend I cvs checkout the 5.1 tree or use that snapshot you sent
me?

I like the improvements to etherboot. Nice work!

ron

[Etherboot-developers] Re: multicast

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> Eric one thing to keep in mind: when we were still doing multicast with
> our stuff we found that our Black Diamond switch had much higher loss
> rates with multicast than with just sending broadcast. So we turned off
> the fancy multicast and just used broadcast packets.

Good point.  Most of the code should actually accomodate a broadcast
ip address.  Though I haven't tested that case.

What we found here was that when we went to half duplex communication
our switch drop rates for multicast packects appear to have gone down.
At the very least I have not observed a significant drop rate for
multicast packets so I will cross that bridge when I come to it.

Ron have you been able to reproduce the smart core problem with the
current etherboot-5.1 cvs tree?

Eric

[Etherboot-developers] multicast

[Ronald G M. <rmi...@la...>]

Eric one thing to keep in mind: when we were still doing multicast with
our stuff we found that our Black Diamond switch had much higher loss
rates with multicast than with just sending broadcast. So we turned off
the fancy multicast and just used broadcast packets.

ron

Re: [Etherboot-developers] latest greatest eboot with IDE boot

[Eric W B. <ebi...@ln...>]

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

> >And could we distinguish between what makes a release canidate and what
> >makes a development release?
> 
> For me a RC is just a snapshot and doesn't have any associated tag in
> CVS. If bugs are found in it, good, we fix them and make another RC. A
> release (development or production) is entered into the Sourceforge
> release page and gets distributed to mirrors. I make announcements to
> Freshmeat and a couple of other places. Marty makes an rom-o-matic
> version. If bugs are found, they go into the patches page and are held
> over for the next release. So a release is a big step.  Hopefully it's
> just the final RC with the version number changed.
> 
> >You delayed initially because there wasn't a multicast client, but I
> >have fixed that and a couple of other things.  I am pretty certain
> >etherboot is over the major hump and headed for another stable
> >release.
> 
> Ok, before we do that I'd like to do regression testing and also to
> check that the new features work. I guess though that for a development
> release the audience is different. Or should be. You will get the odd
> newbie who will ask how come it says gcc not found.
> 
> I'd like to make the release 5.1.2 and then when all the legacy
> implications are understood, release it as 5.2.0.

Sounds like a good plan.

Before 5.2.0 the current big issues still open are:
1) Which nics work with relocation.
2) Which nics work with multicast, support.
3) What to do with the old CAN_BOOT_DISK code.
4) Update the documentation.
5) Automatic generation of the NIC file.

I want to emphasise that I don't think the current code base is unstable.
I am shipping 5.1.x to customers, to get the new functionality.  Rather
there are still some cases where the new functionality does not work
with the old drivers, and needs integration testing and fixing.

To add multicast support it should be about a days work to go through
the Linux kernel find the bit in the driver that needs to be set to accept
all multicast packets, and update all of the drivers.

To be certain of relocation support is harder.  A pure pio driver is fine.
And in many cases a code review will catch it, but we do need someone to 
actually test the driver.  5.2.x looses functionality if all of the drivers
are not relocatable so this is something I would like to aim at having
looked at before 5.2.0 is released.  Which means it would probably be
good to have an development release or at least an rc where people
can test this stuff out and see how well 5.1.x is comming.

Eric

[Etherboot-developers] [COMMIT] e1000 + misc fixes

[Eric W B. <ebi...@ln...>]

O.k.  My next round of code is checked into the etherboot source repository.
The bit change is a major rewrite of the e1000 driver which is big and slow
(8K and the first dhcp seems to be always dropped) but works with the
new e1000 nics currently available.

Eric


mini-slamd.c
- Compile fixes

Makefile, genrules.pl
- Extra rules so all images can be built with the nrv2b compressor

NIC
- e1000 driver update

config.c
- Better status messages

misc Compile warning fixes

e1000 major driver update to handle new cards,
I wish it were smaller and faster but this works.


Add poll_interruptions function for the common idiom of trapping the escape key.

Add a serial_fini function to so cleanup waits until the serial buffers are flushed


Slightly improved linuxbios boot order support.

main.c
- Fix the boot order code to correctly find the next device.

osloader.c
- Attempt to get the checksum error to print out.
  I know I have had failures but I have never seen the correct error message :(

pci.c
- Remove the useless ROM address print statement.
- Add pci_bar_start|_len  helper functions so the size of pci memory regions may
  be computed.

Re: [Etherboot-developers] Re: Mknbi is the misbehaving when reloc'd

[Claudio G. <cla...@fa...>]

Alle Monday 07 October 2002 12:33, Ken Yap ha scritto:
>
> Ok, I found the problem. I was not copying enough arguments from the old
> stack to the new stack (first32.S). The fixed version is in
>
> 	www.etherboot.org/mknbi-1.2-10rc2.tar.bz2
>
> Also in CVS.  Please see if that works for you (reminder: relocation
> only works for --first32pm or mkelf-linux). Thanks for reporting the
> bug.

Ok!! I've tried it, and it works perfectly!
Thank you very much!

Bye!
Claudio
-- 
"Only two things are infinite: the universe and human stupidity,
and I'm not so sure about the Universe." Albert Einstein
----------------------------------------------------------------
//       Claudio Granatiero                        ICQ 16725435   
\\|soft  PGP: 74F0 52C0 75A1 4CAA B3E8 13CE DA7A C86E 2EBA 9F75   

[Etherboot-developers] Re: Mknbi is the misbehaving when reloc'd

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

>As I said, I've used the --first32pm option. I think the problem may be inside 
>the "first-linux.S", in function addkarg, where the data coming from 
>etherboot are passed to kernel, or there around... I'm only wildly guessing, 
>don't know enought the code to understand what's appening...

Ok, I found the problem. I was not copying enough arguments from the old
stack to the new stack (first32.S). The fixed version is in

	www.etherboot.org/mknbi-1.2-10rc2.tar.bz2

Also in CVS.  Please see if that works for you (reminder: relocation
only works for --first32pm or mkelf-linux). Thanks for reporting the
bug.

Re: [Etherboot-developers] Booting over Fast Ethernet

[Anselm M. H. <eth...@ho...>]

Hello Miguel A. Mota Jr,

Saturday, October 05, 2002, 9:55:35 PM, you wrote:
> [...]
> a Beowulf Cluster.  The Nodes boot a custom CD-based mini-Linux distribution
> and configure themselves via DHCP, thus making them quite inexpensive and
> plug-n-play.  I feel that this mixture of technologies makes cheap and yet
> efficient clusters.
> My understanding is that they booting their kernels from a Server.  I was
> wondering if it could be possible to have our Nodes boot an ISO image off
> our Server in a similar fashion?

Not quite, if you don't want to spend a fortune on RAM. The problem
with booting an CD-ISO-Image is that you have to transmit it first and
then place it somewhere inside your computers' memory. Transmitting it
would be vanilla standard configuration probably, but the point is the
high RAM usage. I recommend you going the usual way: Copy the
Root-Filesystem from that CD-ROM onto a hard disk on a "boot server"
(might be the same machine as your main server, but not neccessarily),
give it an entry to /etc/exports (nfsserver needed), and let the
machines boot with root-over-nfs, probably using a ramdisk and then
doing a chroot. You could even "export" the CD-ROM directly, but that
would probably render the access speed to it quite low on simultaneous
requests. You could be interested in having a look into the
Linux Terminal Server Project at www.ltsp.org, it works right that
way. Creating the RAM-Disk will be a bit of a difficulty, but there
should also be docs on what you need on that initrd (initial ramdisk)
with the LTSP. With some luck, all your machines to boot are based on
the same hardware (or at same networking cards, which will the only
part linux needs to be configured for specially in a computing
cluster, I think) so they can all use the same filesystem.

Of course you will have to use DHCP, as in other cases, the clients
could not be distinguished (same config files), but that will be the
case up to now, as the CD-ROMs used are exact copies of each other,
aren't they?

BTW not to forget the "trickiest part" (for beginners on etherboot at
least) - how to boot the machines? As they have fast ethernet, you
usually plug a boot rom onto the NIC boards (not to forget to enable
these with vendor specific software, some older models require an
explicitely enabled rom slot), configure DHCP and TFTPD and enjoy. For
the first tests, use www.rom-o-matic.net to generate a floppy bootable
ROM image for your NICs, RTfineM. Ask again if you have proceeded.

> This could allow us to bring the cost of
> Nodes down to $100 USD and utilize 486 DX PCs as well.

Hmmm... about 105€ per node, that's really cheap. Even having access
to resellers' prices, as a private question, what do you put into that
boxes? Of course, used 486 won't need that much investment.

Best regards,

 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service, Sankt Augustin DE
 mailto:eth...@ho...

[Etherboot-developers] Booting over Fast Ethernet

[Miguel A. M. Jr. <Cha...@Ho...>]

Dear Mailing list members,
    I'm Miguel A. Mota Jr., Co-Founder and President of the Woodrow Wilson
High School Science & Technology Club in Camden, New Jersey USA.  With a few
small grants from Lucent Technologies/Bell Labs, we have developed a
parallel-processing Linux Cluster based on openMosix cluster technology.  In
a attempt to make this new technology more useful and efficient, I have
integrated LAM-MPI and PVM into our cluster, giving it certain advantages of
a Beowulf Cluster.  The Nodes boot a custom CD-based mini-Linux distribution
and configure themselves via DHCP, thus making them quite inexpensive and
plug-n-play.  I feel that this mixture of technologies makes cheap and yet
efficient clusters.
    Our cluster is not that advanced in terms of hardware.  Its not much,
but its a modest start for a few minority teenagers in a urban city pushing
for the movement of Open Source software.  Its a star topology Fast Ethernet
TCP switched cluster with 7 nodes.  Here's a few key specs:

    -    Server: AMD 750Mhz Duron w/390MB PC133 SD-RAM
    -    Masternode AMD 750Mhz Duron w/128MB PC133 SD-RAM
    -    Nodes 1&2: Intel 800MHz Celerons w/128MB PC133 SD-RAM
    -    Nodes 3&4: AMD 650MHz Durons w/128MB PC133  SD-RAM
    -    Nodes 5-7: Intel 450MHz Pentiums w/128MB PC133 SD-RAM

    We are currently trying to expand, but Lucent's loses in the stock
market has affected our funding.  So now we are trying to find companies
willing to donate anything down to a 75Mhz PC, but no luck yet.  While
reading the paper, I came across an article on the clusters at Los Alamos.
My understanding is that they booting their kernels from a Server.  I was
wondering if it could be possible to have our Nodes boot an ISO image off
our Server in a similar fashion?  This could allow us to bring the cost of
Nodes down to $100 USD and utilize 486 DX PCs as well.  I appreciate
anyone's responses and thank you for your time.

Miguel A. Mota Jr.
Cha...@Ne...

Re: [Etherboot-developers] latest greatest eboot with IDE boot

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

>And could we distinguish between what makes a release canidate and what
>makes a development release?

For me a RC is just a snapshot and doesn't have any associated tag in
CVS. If bugs are found in it, good, we fix them and make another RC. A
release (development or production) is entered into the Sourceforge
release page and gets distributed to mirrors. I make announcements to
Freshmeat and a couple of other places. Marty makes an rom-o-matic
version. If bugs are found, they go into the patches page and are held
over for the next release. So a release is a big step.  Hopefully it's
just the final RC with the version number changed.

>You delayed initially because there wasn't a multicast client, but I
>have fixed that and a couple of other things.  I am pretty certain
>etherboot is over the major hump and headed for another stable
>release.

Ok, before we do that I'd like to do regression testing and also to
check that the new features work. I guess though that for a development
release the audience is different. Or should be. You will get the odd
newbie who will ask how come it says gcc not found.

I'd like to make the release 5.1.2 and then when all the legacy
implications are understood, release it as 5.2.0.

Re: [Etherboot-developers] latest greatest eboot with IDE boot

[Eric W B. <ebi...@ln...>]

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

> >where is this? I need to do a source build.
> 
> In CVS currently. If you want to tailgate you should probably learn to
> checkout from CVS. I should release another rc with Eric's recent work
> but I've been flat out this week and I'm planning to go to the Manly
> Jazz Festival to relax this long weekend. When I get a free moment I'll
> do a rc.

Relax.  

I have another round of code to checkin, but I won't get to it
until Monday as I am going home to relax as well.

I have just finished a rewrite of the e1000 support.  I imported
all of the NIC setup code from intels latest driver and bug fixed
intels the code enough so that it works for me.  There was 1 function
where when the code timed out waiting for the link to come up it
returned succes, and another what checks to see if the ethernet link
is up or down and then returns the same value in either branch of the
code.

The neat thing I have to checkin is that I have the pcibios code now
fully relocateable.  So there are a lot more images that it is reasonable
to build.

And could we distinguish between what makes a release canidate and what
makes a development release?

You delayed initially because there wasn't a multicast client, but I
have fixed that and a couple of other things.  I am pretty certain
etherboot is over the major hump and headed for another stable
release.

My next big step will be to port to other architectures, but I think
that is to much for one development release.

On the small step side, the plan is to get all of my code checked in
and start writing documentation.  But I have some kernel patches that
I need to push before the code freeze at the end of this month, or the
20th, or however far Linus moves the timeline up to scare people into
sending him the patches early instead of in one big blob.

Eric

Re: [Etherboot-developers] latest greatest eboot with IDE boot

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

>where is this? I need to do a source build.

In CVS currently. If you want to tailgate you should probably learn to
checkout from CVS. I should release another rc with Eric's recent work
but I've been flat out this week and I'm planning to go to the Manly
Jazz Festival to relax this long weekend. When I get a free moment I'll
do a rc.

[Etherboot-developers] latest greatest eboot with IDE boot

[Ronald G M. <rmi...@la...>]

where is this? I need to do a source build.

thanks

ron