etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Driver probing twice in latest 5.1 cvs

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

"Timothy Legge" <tim...@us...> writes:

> > Not enough detail.  What when is it getting probed?
> 
> Sorry.  I had boot from the floppy and hit the N for Network. (Also
> happened when I didn't hit N).  I noticed right away, that the screen
> looked weird.  The PC bios dump/info was not in the screen and there was
> no way the driver should spew enough info to get rid of it.

Ah.  So it would take a serial console to capture everything, and understand
what is going on...

> I thought first that the sundance_reset was getting called twice, but
> when I looked at the messages closely, it seems that the code is probing
> the nic twice.

Hmm.  I can't think of a normal case without errors where that should
happen.  When ever it retries it reprobes as to be as safe as possible.

And having a boot menu will get a reprobe to reinitialize the card.
 
> Not much more I can tell you on that one.  Try renaming the file you are
> tftping without updating the dhcpd.conf file and you shoud see two lots
> of probe/reset messages.

This later case is intended.

The sequence displayed should be:
probe
DHCP
TFTP (get an error)
reset
<abort> (and sleep one second)
(restart or give up depending on the compile options).

Eric

RE: [Etherboot-developers] Driver probing twice in latest 5.1 cvs

[Timothy L. <tim...@us...>]

> Not enough detail.  What when is it getting probed?

Sorry.  I had boot from the floppy and hit the N for Network. (Also
happened when I didn't hit N).  I noticed right away, that the screen
looked weird.  The PC bios dump/info was not in the screen and there was
no way the driver should spew enough info to get rid of it.

I thought first that the sundance_reset was getting called twice, but
when I looked at the messages closely, it seems that the code is probing
the nic twice.

Not much more I can tell you on that one.  Try renaming the file you are
tftping without updating the dhcpd.conf file and you shoud see two lots
of probe/reset messages.

Tim

Re: [Etherboot-developers] Driver probing twice in latest 5.1 cvs

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

"Timothy Legge" <tim...@us...> writes:

> Hi
> 
> I was fooling around with the sundance driver once again after a cvs
> update an hour ago.  It seems that the driver is being probed twice.
> Any thoughts?

Not enough detail.  What when is it getting probed?

Eric

Re: [Etherboot-developers] Driver probing twice in latest 5.1 cvs

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

>I was fooling around with the sundance driver once again after a cvs
>update an hour ago.  It seems that the driver is being probed twice.
>Any thoughts?

Yes I've seen this with my 3c509 driver, and I wondered if it was real.
It went by so fast that I thought perhaps I misjudged the lines on the
screen.

[Etherboot-developers] Driver probing twice in latest 5.1 cvs

[Timothy L. <tim...@us...>]

Hi

I was fooling around with the sundance driver once again after a cvs
update an hour ago.  It seems that the driver is being probed twice.
Any thoughts?

Tim

[Etherboot-developers] Re: etherboot

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

>Sending you email directly since I don't wanna look like
>a complete moron on the list.

No, actually you really should mail to the list because Timothy Legge
has been having a similar problem so maybe it's related. Besides I'm
going on holidays soon and you won't get any reply for a couple of
weeks. As I point out in the web page, I'm not the only one who can
answer questions.

>I am eager to help testing 5.1.x; I have a stack of many
>different cards and a test rig ready to go, but have
>been stumbling over how to work with 5.1.x
>
>Here is what I do:
>
>cd src ; make
>make bin/dc21041.zrom
>mknbi-rom bin/dc21041.zrom >dc21041.nb
>cp dc21041.nb /tftpboot/etherboot.nb
>Boot and test using my test system ... I get a single 'R'
>
>make bin/dc21041.rom
>mknbi-rom bin/dc21041.rom >dc21041.nb
>cp dc21041.nb /tftpboot/etherboot.nb
>Boot and test using my test system ... I get a single 'R'
>
>My test system has a wd8013 card that has a verified
>etherboot 5.0.8 in an EPROM.  I use this to boot the
>image for whatever card I want to test.  Right now,
>it also has a tulip card with an actual DEC dc21041
>tulip chip (although the card is made by trendnet).
>I am trying to use the scheme you suggested of
>using a working etherboot to test a new version.
>
>I dunno if the single 'R' is because I am out in the weeds
>not comprehending how to set up 5.1.x, or because there are
>actual problems with the tulip card/driver.  I have been
>spending some time getting familiar with the Makefiles
>and basic lay of the land with etherboot.
>
>In short, I have 4 files that I don't grog what they
>are all about:
>
>tulip.img
>tulip.zimg
>dc21041.rom
>dc21041.zrom
>
>If I just wanted to boot an actual rom could I use either of
>.rom or .zrom?  Is it possible that mknbi is not 5.1.x aware??
>
>whatdya think?  Trolling for clues I am.

Me too, software's like this. :-)

[Etherboot-developers] [COMMIT] Makefile-version

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

Currently because of dependencies on bin/Roms getting the version
of etherboot potentially modifies files (it generates bin/Roms) which
is annoying.  

I have added a dummy architecture ``version'' which does not include
bin/Roms and a file Makefile-version which uses that architecture to
get the version safely without changing any files.

Eric

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

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

> >> Ok that works better now, it can successfully load an image after
> >> returning from a menu. Now the next problem:
> >
> >Is this problem independent of menus?
> 
> I haven't tested it without a menu actually, now that you mention it but
> it shouldn't matter if the image is successfully loaded no?
> 
> >The Linux code should not have a20 problems.  It has been a little
> >while since I tested mkelf but it was working at the time I made the
> >patch to generate the checksums.
> >
> >And note some machines have a20 set permanently on.  So while we may
> >confuse some machine's BIOS's by not restoring a20 that should be all
> >we confuse.
> 
> I think you're right there. BTW the Linux image was generated by a
> recent mkelf so should have checksumming.

Interesting. It definitely needs some tracking down.  

An interesting data point with respect to booting linux would
be to try mkelfImage
ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.0.tar.gz

It does fewer bios calls, than the standard linux kernel, or none at
all when running under LinuxBIOS, and in general the images it makes
tend to work in more difficult situations.

With the checksum in place that should at least confirm the data was
in memory correctly at one point.  Hopefully I can reproduce this and
give some amount of comment.

Eric

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

Timothy Legge <tl...@ro...> writes:

> > I haven't tested it without a menu actually, now that you mention it but
> > it shouldn't matter if the image is successfully loaded no?
> 
> When I was working on the sundance driver, the client would reboot after getting
> its image from tftp.  At the time I thought it was aa driver issue, but now...
>
> I was not using menus.

So far the bugs that have been confirmed were exclusively not reinitializing
the drivers after the menu returned.

If there is something beyond that it will be hopefully tracked in
the next little bit.

Eric

Re: Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

> I haven't tested it without a menu actually, now that you mention it but
> it shouldn't matter if the image is successfully loaded no?

When I was working on the sundance driver, the client would reboot after getting its image from tftp.  At the time I thought it was aa driver issue, but now...

I was not using menus.

Tim

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

>> Ok that works better now, it can successfully load an image after
>> returning from a menu. Now the next problem:
>
>Is this problem independent of menus?

I haven't tested it without a menu actually, now that you mention it but
it shouldn't matter if the image is successfully loaded no?

>The Linux code should not have a20 problems.  It has been a little
>while since I tested mkelf but it was working at the time I made the
>patch to generate the checksums.
>
>And note some machines have a20 set permanently on.  So while we may
>confuse some machine's BIOS's by not restoring a20 that should be all
>we confuse.

I think you're right there. BTW the Linux image was generated by a
recent mkelf so should have checksumming.

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

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

> >It looks like I mangled the logic to reinitialize things after calling
> >cleanup.
> >
> >So I suspect after we returned to either boot returned neither:
> >dev->probe(PROBE_AWAKE) was being called, nor was console_init();
> >
> >I have just checked in the fix and hopefully it does the correct thing now.
> 
> Ok that works better now, it can successfully load an image after
> returning from a menu. Now the next problem:

Is this problem independent of menus?

> Real mode images (DOS, ROM) jump off and reset the machine. May have
> something to do with the not-yet implemented A20 line restore when
> leaving Etherboot to run a RM image.
> 
> Protected mode image (Linux) gets to run the third stage, prints out the
> location of the ramdisk and then fails to start the kernel. Again maybe
> something to do with A20.

The Linux code should not have a20 problems.  It has been a little
while since I tested mkelf but it was working at the time I made the
patch to generate the checksums.

And note some machines have a20 set permanently on.  So while we may
confuse some machine's BIOS's by not restoring a20 that should be all
we confuse.

Eric

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

>It looks like I mangled the logic to reinitialize things after calling
>cleanup.
>
>So I suspect after we returned to either boot returned neither:
>dev->probe(PROBE_AWAKE) was being called, nor was console_init();
>
>I have just checked in the fix and hopefully it does the correct thing now.

Ok that works better now, it can successfully load an image after
returning from a menu. Now the next problem:

Real mode images (DOS, ROM) jump off and reset the machine. May have
something to do with the not-yet implemented A20 line restore when
leaving Etherboot to run a RM image.

Protected mode image (Linux) gets to run the third stage, prints out the
location of the ramdisk and then fails to start the kernel. Again maybe
something to do with A20.

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

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

> >On my system, etherboot 5.1.5 loads from floppy (rtl8139.zdsk), then loads
> >an NFL tagged image. When a selection is made from NFL, an attempt is made
> >to load the selected file (I see the TFTP request at server), and etherboot
> >puts out a single DOT, then pauses for a period of time, then spews a large
> >number of dots, followed by a reboot.
> 
> Ah well the good news is that the 8139 driver is confirmed working at
> least.  Your problems sound similar to mine in that 5.1.5 cannot boot
> from a menu choice.

It looks like I mangled the logic to reinitialize things after calling
cleanup.

So I suspect after we returned to either boot returned neither:
dev->probe(PROBE_AWAKE) was being called, nor was console_init();

I have just checked in the fix and hopefully it does the correct thing now.

Eric

Re: [Etherboot-developers] 5.1.5 Menu & Console problems

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

>On my system, etherboot 5.1.5 loads from floppy (rtl8139.zdsk), then loads
>an NFL tagged image. When a selection is made from NFL, an attempt is made
>to load the selected file (I see the TFTP request at server), and etherboot
>puts out a single DOT, then pauses for a period of time, then spews a large
>number of dots, followed by a reboot.

Ah well the good news is that the 8139 driver is confirmed working at
least.  Your problems sound similar to mine in that 5.1.5 cannot boot
from a menu choice.

[Etherboot-developers] 5.1.5 Menu & Console problems

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

On my system, etherboot 5.1.5 loads from floppy (rtl8139.zdsk), then loads
an NFL tagged image. When a selection is made from NFL, an attempt is made
to load the selected file (I see the TFTP request at server), and etherboot
puts out a single DOT, then pauses for a period of time, then spews a large
number of dots, followed by a reboot.

I also noticed (when trying to gather more diagnostics on the above), that
setting CONSOLE_DUAL provides serial output when etherboot loads NFL, but
not after the selection is made in NFL and it returns control back to
etherboot. I looked for some code path, that might not call console_init()
on return of the secondary program (NFL in this case), but it escapes me.

I tested both of the above issues with 5.0.7, and both operate as expected
(NFL loads fine, selected image loads fine, and serial console is retained
after NFL returns).

Cheers,
Robb Main.

Re: [Etherboot-developers] 5.1.6pre1 cannot load images chosen from menu

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

ke...@us... writes:

> One thing I've noticed in 5.1.6pre1 is that I cannot load anything
> further from a menu. The booting path:
> 
> 5.0.7 (ROM) -> NFL menu image -> 5.1.6pre1 (NBI) -> NFL menu image ->
> anything
> 
> At the last step it prints out Loading <ipaddress>:<imagename> then
> hangs.  The log file on the TFTP server shows no request for
> <imagename>.
> 
> I think this used to work in 5.1.3, something may have broken in the
> split up into arch specific directories, possibly the place where the
> image name is obtained (or not) from the DHCP structure for TFTP to
> request.

I don't think I did anything bad but splitting up osloader.c into separate
files per image type could quite easily have done it, by accident.

Eric

[Etherboot-developers] 5.1.6pre1 cannot load images chosen from menu

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

One thing I've noticed in 5.1.6pre1 is that I cannot load anything
further from a menu. The booting path:

5.0.7 (ROM) -> NFL menu image -> 5.1.6pre1 (NBI) -> NFL menu image ->
anything

At the last step it prints out Loading <ipaddress>:<imagename> then
hangs.  The log file on the TFTP server shows no request for
<imagename>.

I think this used to work in 5.1.3, something may have broken in the
split up into arch specific directories, possibly the place where the
image name is obtained (or not) from the DHCP structure for TFTP to
request.

Re: [Etherboot-developers] 5.1.5+: WD80x3 driver working and CVSed

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

>Interesting.  Could you try loading an ELF image.  If you got
>a checksum error that could easily answer why you flew off into hyperspace.

Will do, but I won't see that machine again until next month. Both
images were NBI, one was just another ROM image.

Re: [Etherboot-developers] 5.1.5+: WD80x3 driver working and CVSed

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

ke...@us... writes:

> Finally got the bus_to_virt thing sorted out. Finishes loading, says
> done, but jumps into hyperspace. May not be a driver problem now.

Interesting.  Could you try loading an ELF image.  If you got
a checksum error that could easily answer why you flew off into hyperspace.

Eric

Re: [Etherboot-developers] 5.1 will not boot on 486

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

"Timothy Legge" <tim...@us...> writes:

> > I still think it's the printf itself that's blocking after printing
> one
> > character. I still think the serial port is being written to somehow.
> > Even though the serial port may be present, if the handshake lines are
> > not enabled, the write to the port may block.
> > 
> > What happens if you put another printf ahead the current one, this
> time
> > with a different first character?
> 
> I thought that as well.  I wanted to see what was going on, so I put a
> single printf before the current one.  That printf also failed after
> outputting the first character.  I followed up with an infinite while
> loop to printf a word.  That also failed after printing the first
> character of the first iteration.

It might be worth it to try using a serial console, and disable output
through the BIOS.  That would at least give you a clue about what is going
on.

Eric

[Etherboot-developers] Re: Geode + Etherboot + Syslinux + DiskOnChip + RTL8139C help

[Ralph B. <cy...@hq...>]

> No BIOS32 means that your BIOS isn't a standard PCI PnP BIOS which
> Etherboot can ask for the details of the devices on the bus. This is
> often the case with embedded BIOSes which don't try to emulate desktop
> BIOSes. You may have to figure out how to get that PCI information.

Thanks - that helped :)  I set RELOCADDR=0x84000 and -DCONFIG_PCI_DIRECT and it
worked fine using etherboot 5.0.8

-- 
--^-^--^-^-^---^--^-^--^-^-^--^---^-^--^-^-^--^-^--^-^-^--
 Ralph Bonnell @ Linux Friendly, Inc.
 - CISSP, LPIC-2, CCSI, CCSE+, CCNA, CSFE, MCSE 2000
 +1-954-931-7388   http://ralph.cx   ra...@ra...
--^-^--^-^-^---^--^-^--^-^-^--^---^-^--^-^-^--^-^--^-^-^--

Re: [Etherboot-developers] tulip fix...

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

>So, the previous change to the tulip driver was one virt_to_le32desc short
>:)  This makes it work (better) on my tulip based cpu card.
>
>--- etherboot-5.1.5/src/drivers/net/tulip.c      Thu Jan  9 07:37:05 2003
>+++ etherboot-5.1.5-diff/src/drivers/net/tulip.c Thu Jan  9 19:23:24 2003
>@@ -1087,7 +1087,7 @@
>     tx_ring[0].status = cpu_to_le32(0x80000000);
>
>     /* Point to transmit descriptor */
>-    outl((u32)&tx_ring[0], ioaddr + CSR4);
>+    outl(virt_to_le32desc(&tx_ring[0]), ioaddr + CSR4);
>
>     /* Enable Tx */
>     outl(csr6 | 0x00002000, ioaddr + CSR6);

Great! Thanks for spotting that one.

[Etherboot-developers] tulip fix...

[Michael G. <mge...@so...>]

So, the previous change to the tulip driver was one virt_to_le32desc short
:)  This makes it work (better) on my tulip based cpu card.

--- etherboot-5.1.5/src/drivers/net/tulip.c      Thu Jan  9 07:37:05 2003
+++ etherboot-5.1.5-diff/src/drivers/net/tulip.c Thu Jan  9 19:23:24 2003
@@ -1087,7 +1087,7 @@
     tx_ring[0].status = cpu_to_le32(0x80000000);

     /* Point to transmit descriptor */
-    outl((u32)&tx_ring[0], ioaddr + CSR4);
+    outl(virt_to_le32desc(&tx_ring[0]), ioaddr + CSR4);

     /* Enable Tx */
     outl(csr6 | 0x00002000, ioaddr + CSR6);

[Etherboot-developers] Re: [ANNOUNCE] mkelfImage 2.0

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

ollie lho <ol...@si...> writes:

> Eric,
> 	Something off topic, the elfImage made by mkelfImage 1.1x can 
> not be recognized by 'objdump' but can be dumped by 'readelf'. Is there
> any reason for this ? 

Yes.  This is a bug in some versions of objdump.  On my current
system this bug does not occur.  It can be worked around by putting
in a dummy symbol table, but this increases the size by a few bytes.
Possibly a problem in an embedded situation.

>Is this fixed by ver. 2.0 ?

No.

And my version objdump which does not show the problem is:

eric@maxwell:~$ objdump --version
GNU objdump 2.13.90.0.10 20021010 Debian GNU/Linux
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no
warranty.

Eric