etherboot-developers — Discussion of developer issues

[Etherboot-developers] [Etherboot-users] Re: rtl_disable and random kernel crash.

[Ken Y. <ke...@nl...>]

|Hello.
|
|My name is Hyun-Joon Cha, a Korean engineer of embedded Linux.
|
|I'm working on multiple booting of several industrial SBCs with your great et
>herboot.
|
|Network controllers of the SBCs are various such as 82559ER, RTL8139B and 813
>9C and all SBCs booted quite well except RTL8139B and C thing. SBCs with RTL8
>139B and C couldn't boot normally and they were crashed at random place of Li
>nux kernel and random time.
|
|So, me and my HW co-worker were trying to find the source of problem and we'v
>e been concluded that HW design is the culprit.
|
|After several times of HW rebuild, BIOS and kernel modification, we almost ga
>ve up and as a final attempt, we simulated same situation with 10 PCs equippe
>d RTL8139B NIC. And the result was same.
|
|So I've been starting walk around etherboot and found that there are no code 
>within rtl_disable but eepro100_disable. And I've found your comment on *_dis
>able at ChangLog.
|
|Now, all SBCs boot well with rtl_disable and I thought that I have to report 
>this. If you add a few lines of code - copied ;) - about  rtl_disable at next
> release there will be no people meet the danger.
|
|
|-------------------------------------------
|static void rtl_disable(struct nic *nic)
|{
|        int i;
|
|        /* reset the chip */
|        outb(CmdReset, ioaddr + ChipCmd);
|
|        /* Check that the chip has finished the reset. */
|        for (i = 1000; i > 0; i--)
|                if ((inb(ioaddr + ChipCmd) & CmdReset) == 0)
|                        break;
|}
|-------------------------------------------
|
|Thanks and have a nice day.

Great, that confirms it. I will get it added to rom-o-matic.net. Thanks
Hyun-Joon!

_______________________________________________
Etherboot-users mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-users

[Etherboot-users] Re: [Etherboot-developers] Re: rtl_disable and random kernel crash.

[Ken Y. <ke...@nl...>]

||static void rtl_disable(struct nic *nic)
||{
||        int i;
||
||        /* reset the chip */
||        outb(CmdReset, ioaddr + ChipCmd);
||
||        /* Check that the chip has finished the reset. */
||        for (i = 1000; i > 0; i--)
||                if ((inb(ioaddr + ChipCmd) & CmdReset) == 0)
||                        break;
||}

Actually I would make that:

static void rtl_disable(struct nic *nic)
{
	/* reset the chip */
	outb(CmdReset, ioaddr + ChipCmd);

	/* 10 ms timeout */
	load_timer2(10*TICKS_PER_MS);
	while ((inb(ioaddr + ChipCmd) & CmdReset) != 0 && timer2_running())
		/* wait */;
}

and add #include "timer.h" near the top. The hardware timer is more
consistent than a counting loop.

_______________________________________________
Etherboot-users mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-users

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

[Ken Y. <ke...@nl...>]

|And the roms do decompress properly which confirms that the one or
|two extra bytes are just tacked onto the end of the image.
|
|At first uneducated glance the PXE rom appears to be a normal rom.
|Here are the first couple of bytes.  For reference I was using
|a rom built with etherboot 4.6.10.  If someone could provide
|some insight I would appreciate it.

There's a Perl script, disrom.pl, to help interpret the header. It's in
recent distributions. Heck, it's short enough to include here.

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

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

Ken Yap <ke...@nl...> writes:

> |What I do know is the interface for plugin roms in the BIOS isn't 100%
> |the same as it is for plugin cards.  Because with a flashed NIC it
> |all worked fine.  And I replaced the PXE module in location, name, and
> 
> Yes, that could explain a thing or two with BIOS plugins. This should be
> interesting. I look forward to further developments.

O.k. I've played around a little more and dug up a copy of lha
for unix.  From the comp.compression faq:

      lha for Unix.
        ftp://oak.oakland.edu/pub/misc/unix/lha101u.tar.Z
        ftp://garbo.uwasa.fi/unix/arcers/lha101u.tar.Z
          Contact: lha...@ok... or ok...@fs...

And the roms do decompress properly which confirms that the one or
two extra bytes are just tacked onto the end of the image.

At first uneducated glance the PXE rom appears to be a normal rom.
Here are the first couple of bytes.  For reference I was using
a rom built with etherboot 4.6.10.  If someone could provide
some insight I would appreciate it.


What was there.
From: 82559.026
000000 55 aa 6c e8 3c 22 cb 39 9d 02 00 00 00 00 00 00
000010 00 00 00 00 00 00 20 00 40 00 60 00 80 03 8b c0
000020 55 4e 44 49 16 60 00 00 01 02 08 0e 00 08 30 4d
000030 70 1e 50 43 49 52 2e 8b c0 2e 8b c0 2e 8b c0 90
000040 50 43 49 52 86 80 29 12 00 00 18 00 00 02 00 00
000050 6c 00 01 02 00 80 00 00 2e 8b c0 2e 8b c0 8b c0
000060 24 50 6e 50 01 02 00 00 00 08 00 00 00 00 b4 00
000070 c6 00 02 00 00 e4 00 00 00 00 56 0d 00 00 00 00
000080 0d 0a 43 6f 70 79 72 69 67 68 74 20 28 43 29 20
000090 31 39 39 37 2c 31 39 39 38 2c 31 39 39 39 20 20
0000a0 49 6e 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f
0000b0 6e 0d 0a 00 49 6e 74 65 6c 20 43 6f 72 70 6f 72
0000c0 61 74 69 6f 6e 00 49 6e 74 65 6c 20 55 4e 44 49
0000d0 2c 20 50 58 45 2d 32 2e 30 20 28 62 75 69 6c 64
0000e0 20 30 37 31 29 00 00 00 00 00 00 00 00 00 00 00
0000f0 f2 e6 00 f0 b4 00 cd 16 0a c0 74 02 32 e4 c3 b4

What I tried.
From: eepro100.lzrom
000000 55 aa 20 eb 4f 37 e9 8c 00 45 74 68 65 72 62 6f
000010 6f 74 00 00 00 00 00 00 1c 00 34 00 50 43 49 52
000020 86 80 29 12 00 00 18 00 00 00 00 02 20 00 01 00
000030 00 80 00 00 24 50 6e 50 01 02 00 00 00 61 00 00
000040 00 00 00 00 00 00 00 00 02 14 00 00 00 00 54 00
000050 00 00 00 00 50 1e 31 c0 8e d8 a1 04 03 3d 4c e4
000060 74 1d a1 64 00 a3 00 03 a1 66 00 a3 02 03 b8 82
000070 00 a3 64 00 8c c8 a3 66 00 b8 4c e4 a3 04 03 1f
000080 58 cb 31 c0 8e d8 a3 04 03 a1 02 03 a3 66 00 a1
000090 00 03 a3 64 00 31 c9 2e 8a 2e 02 00 fc 89 ca b8
0000a0 00 80 31 f6 8e c0 31 ff 2e f3 a5 89 d1 ea b2 00
0000b0 00 80 b8 c0 07 8e d8 8c c8 a3 fa 01 89 0e fc 01
0000c0 bb 00 98 8e d8 b8 00 90 8e c0 cd 12 b1 06 d3 e0
0000d0 29 d8 a9 00 f0 74 05 78 fe b8 00 00 b1 04 d3 e0
0000e0 8e d3 89 c4 fc be c0 02 bf 00 00 b2 06 b6 20 30
0000f0 ff ac 88 c3 88 f1 30 ed 88 f8 f3 aa fe c7 fe cb

Eric

Re: [Etherboot-developers] Re: rtl_disable and random kernel crash.

[Ken Y. <ke...@nl...>]

||static void rtl_disable(struct nic *nic)
||{
||        int i;
||
||        /* reset the chip */
||        outb(CmdReset, ioaddr + ChipCmd);
||
||        /* Check that the chip has finished the reset. */
||        for (i = 1000; i > 0; i--)
||                if ((inb(ioaddr + ChipCmd) & CmdReset) == 0)
||                        break;
||}

Actually I would make that:

static void rtl_disable(struct nic *nic)
{
	/* reset the chip */
	outb(CmdReset, ioaddr + ChipCmd);

	/* 10 ms timeout */
	load_timer2(10*TICKS_PER_MS);
	while ((inb(ioaddr + ChipCmd) & CmdReset) != 0 && timer2_running())
		/* wait */;
}

and add #include "timer.h" near the top. The hardware timer is more
consistent than a counting loop.

[Etherboot-developers] Re: rtl_disable and random kernel crash.

[Ken Y. <ke...@nl...>]

|Hello.
|
|My name is Hyun-Joon Cha, a Korean engineer of embedded Linux.
|
|I'm working on multiple booting of several industrial SBCs with your great et
>herboot.
|
|Network controllers of the SBCs are various such as 82559ER, RTL8139B and 813
>9C and all SBCs booted quite well except RTL8139B and C thing. SBCs with RTL8
>139B and C couldn't boot normally and they were crashed at random place of Li
>nux kernel and random time.
|
|So, me and my HW co-worker were trying to find the source of problem and we'v
>e been concluded that HW design is the culprit.
|
|After several times of HW rebuild, BIOS and kernel modification, we almost ga
>ve up and as a final attempt, we simulated same situation with 10 PCs equippe
>d RTL8139B NIC. And the result was same.
|
|So I've been starting walk around etherboot and found that there are no code 
>within rtl_disable but eepro100_disable. And I've found your comment on *_dis
>able at ChangLog.
|
|Now, all SBCs boot well with rtl_disable and I thought that I have to report 
>this. If you add a few lines of code - copied ;) - about  rtl_disable at next
> release there will be no people meet the danger.
|
|
|-------------------------------------------
|static void rtl_disable(struct nic *nic)
|{
|        int i;
|
|        /* reset the chip */
|        outb(CmdReset, ioaddr + ChipCmd);
|
|        /* Check that the chip has finished the reset. */
|        for (i = 1000; i > 0; i--)
|                if ((inb(ioaddr + ChipCmd) & CmdReset) == 0)
|                        break;
|}
|-------------------------------------------
|
|Thanks and have a nice day.

Great, that confirms it. I will get it added to rom-o-matic.net. Thanks
Hyun-Joon!

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

[Ken Y. <ke...@nl...>]

|What I do know is the interface for plugin roms in the BIOS isn't 100%
|the same as it is for plugin cards.  Because with a flashed NIC it
|all worked fine.  And I replaced the PXE module in location, name, and

Yes, that could explain a thing or two with BIOS plugins. This should be
interesting. I look forward to further developments.

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

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

Ken Yap <ke...@nl...> writes:

> |The logical next step to do after what I have done is to find a working
> |copy of lharc and decompress images that are already in the BIOS, and
> |see what kind of entry point and headers they have.  So etherboot could
> |be modified to work nicely.
> 
> Oh dear, I hope they haven't gone off and implemented Yet Another
> Standard.

I doubt it.  But I wouldn't put it past the BIOS developers to have
their internal interfaces a little off standard.  I was testing with
4.6.10 so I obviously didn't have all of the most recent bugfixes.

What I do know is the interface for plugin roms in the BIOS isn't 100%
the same as it is for plugin cards.  Because with a flashed NIC it
all worked fine.  And I replaced the PXE module in location, name, and
type.  But as I didn't decompress the PXE module I don't have a clue
what it's rom header looked like.

Eric

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

[Ken Y. <ke...@nl...>]

|The logical next step to do after what I have done is to find a working
|copy of lharc and decompress images that are already in the BIOS, and
|see what kind of entry point and headers they have.  So etherboot could
|be modified to work nicely.

Oh dear, I hope they haven't gone off and implemented Yet Another
Standard.

Re: [Etherboot-users] Re: [Etherboot-developers] Some info on award bios organization.

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

Ken Yap <ke...@nl...> writes:

> |The chain of images must should not break.  So if you replace a larger
> |image with a smaller one you need to move all of the following images
> |up.
> 
> Another possibility is to pad the Etherboot image to the right size, if
> it's smaller. You can specify a size to makerom.

Close except that it is compressed size that matters here, and so it
would have to be fancy padding that makes the compressed size exactly the same
as something else.

The logical next step to do after what I have done is to find a working
copy of lharc and decompress images that are already in the BIOS, and
see what kind of entry point and headers they have.  So etherboot could
be modified to work nicely.

Eric

Re: [Etherboot-developers] 4.7.23 problems

[Ken Y. <ke...@nl...>]

|Now the bad news:
|Linux hangs immediately after "Loading Linux...".
|DOS loads seemingly fine but crashes after pressing any key.
|If one tries to do a local boot (by pressing "L") machine hangs.
|All those things happen even if I put the network card 
|with Etherboot flashed on it to a different motherboard 
|(on which Etherboot always worked fine): Intel L440GX+.

What happens with 4.7.22? If that also crashes in the same way then it's
not a .23 problem per se but something else unresolved.  I know this
doesn't help you much but it at least narrows down the problem.  If .22
works (the EEPRO100 driver didn't change in between) then I want to know
about it.

Re: [Etherboot-developers] Some info on award bios organization.

[Ken Y. <ke...@nl...>]

|The chain of images must should not break.  So if you replace a larger
|image with a smaller one you need to move all of the following images
|up.

Another possibility is to pad the Etherboot image to the right size, if
it's smaller. You can specify a size to makerom.

[Etherboot-developers] 4.7.23 problems

[Tomasz B. <to...@Za...>]

Hi,

I tried Etherboot version 4.7.23 on Intel Pro100+ Management Fast Ethernet
card.
I did it by flashing the code to the flash ROM available on the card.
I got the code from rom-o-matic.

First the good news:
The code was properly recognized on Tyan Thunder LE S2510 motherboard.
Version 4.7.17 (compiled by me, not from rom-o-matic) was not recognized.

Now the bad news:
Linux hangs immediately after "Loading Linux...".
DOS loads seemingly fine but crashes after pressing any key.
If one tries to do a local boot (by pressing "L") machine hangs.
All those things happen even if I put the network card 
with Etherboot flashed on it to a different motherboard 
(on which Etherboot always worked fine): Intel L440GX+.

Tomasz.

Re: [Etherboot-developers] eepro/100 problems

[Alexei A.R. <A.A...@in...>]

On Wed, 4 Apr 2001, Marty Connor wrote:

> On 4/4/01 3:08 AM Alexei A.Romanenko A.A...@in... wrote:
> >I compile ROM image using etherboot-4.6.12 for my network card
> >and place it as binary data into  AM27c512-120JI chip (eprom, 512 
> >Kbit, 64Kx8, 120ns)
> 
> I would try a 27C256-100, which is a smaller, faster EPROM.  It could be 
> that your card is not capable of seeing that size/speed of EPROM.
  
   Intel declare, that ROM for the card must be 150ns, or faster.
So, i don't think the reason in speed of EPROM

> 
> >when i turn pc on it says nothing refered to booting via LAN
> >(first boot from LAN is set in BIOS), although after installing
> >bootstrap for LILO, computer boots well.
> 
> Get the DOS debug program, and search for the contents of the ROM in 
> memory.
> 
> (by the way, could someone please send an actual DOS debugging session 
> showing how to find EPROM contents in memory?  I am writing documentation 
> for Etherboot, and would like to give an example for novices.  I guess I 
> could define LPT to COM1 with some DOS mode command and capture the 
> output of the serial port in a buffer, but if anyone knows a better way, 
> I'd sure appreciate it.)

Where can I find that DOS debug program?
how it is possible to find contents of the ROM in memory? It will
be rewriten by something else (by command.com for example) 

> 
> Anyway, I generally find problems with having ROMs recognized these days 
> seems often to have to do with speed.  If the card doesn't insert enough 
> wait states, then the CPU may try to read the ROM too fast, and think it 
> is not there.
> 
> Maybe someone who knows more intimate details can be of more assistance.
> 
> 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...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

    Alex
-------------------
    A.A...@in...

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

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

Ken Yap <ke...@nl...> writes:

> |You are free to do whatever you want within your initrd
> |image.  
> 
> Correct. A network loaded initrd is no different from one loaded from
> disk. What it does depends on its internals and the kernel parameters.
> 
> |I think that once you exit the shell that is running, it will turn
> |around and run /bin/init.  There's good docs in the /Documentation
> |directory for the Linux kernel.
> 
> More correctly, linuxrc should exec /sbin/init because there is an
> implicit assumption in Unix that init has pid 1. This init should never
> exit. If you are not execing init, then linuxrc should never exit, or
> run/exec something that "never" exits, e.g. sleep 2^32-1.

If you have an initrd && exists /linuxrc on the initrd  && root!=/dev/ram 
Then 
      It is expected that /linuxrc will do some early setup and then exit.
      In this case the /linuxrc script will not run with pid 1.

      In this case the kernel continues on execs /sbin/init with pid 1.

Eric

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[Ken Y. <ke...@nl...>]

|You are free to do whatever you want within your initrd
|image.  

Correct. A network loaded initrd is no different from one loaded from
disk. What it does depends on its internals and the kernel parameters.

|I think that once you exit the shell that is running, it will turn
|around and run /bin/init.  There's good docs in the /Documentation
|directory for the Linux kernel.

More correctly, linuxrc should exec /sbin/init because there is an
implicit assumption in Unix that init has pid 1. This init should never
exit. If you are not execing init, then linuxrc should never exit, or
run/exec something that "never" exits, e.g. sleep 2^32-1.

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[Mark A. <mr...@po...>]

"David L. Parsley" <pa...@li...> writes:
> Mark Atwood wrote:
> 
> > And isn't the kernel still in "initrd mode", wanting to do a
> > pivot/init instead of halting the system as soon as that "initial
> > process" dies?
> 
> No, by supplying a root device of /dev/ram, the kernel assumes that the
> initrd ramdisk is the true root filesystem, and either uses the
> command-line supplied init or looks for /sbin/init.  Then, using
> pivot_root, you can change the root filesystem whenever you like - but
> usually just once during boot.

Excellent. This needs to be documented somewhere better. (Well, with
mailling list archives, I guess it just was!)

> 
> Let me know if you want my tftp patches.  It makes about a 10k
> dynamically-linked binary, but that's not too bad.

Please.

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mr...@po... | http://www.pobox.com/~mra

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[David L. P. <pa...@li...>]

Mark Atwood wrote:
> 
> "David L. Parsley" <pa...@li...> writes:
> >
> > Sure, just don't make a 'linuxrc' file, instead:
> > root=/dev/ram init=/whatever/you/like (/sbin/init even).
> > This is the right way to do things now
> > I use a shell script init which later exec's the real init - still pid=1.
> 
> Where does you specify those kernel cmdline parameters. As a bootp
> resource?

I supply them with mknbi-linux:
mknbi-linux --param="root=/dev/ram (etc...)"

> And isn't the kernel still in "initrd mode", wanting to do a
> pivot/init instead of halting the system as soon as that "initial
> process" dies?

No, by supplying a root device of /dev/ram, the kernel assumes that the
initrd ramdisk is the true root filesystem, and either uses the
command-line supplied init or looks for /sbin/init.  Then, using
pivot_root, you can change the root filesystem whenever you like - but
usually just once during boot.

> > > Or am I stuck with having to construct an initrd that tftp's a
> > > rootdisk image down and mounts and pivots to that?
> >
> > I use userspace tftp quite a bit for my work; what tftp are you using?
> > I've patched RedHat's tftp-0.17 for command-line operation, and like it
> > pretty well.  The tftp included with busybox wasn't very robust and
> > would frequently time out and fail.
> 
> Thanks for the advanced warning on that.

Let me know if you want my tftp patches.  It makes about a 10k
dynamically-linked binary, but that's not too bad.

regards,
	David
-- 
David L. Parsley
Network Administrator
Roanoke College

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[Mark A. <mr...@po...>]

"David L. Parsley" <pa...@li...> writes:
> 
> Sure, just don't make a 'linuxrc' file, instead:
> root=/dev/ram init=/whatever/you/like (/sbin/init even).
> This is the right way to do things now
> I use a shell script init which later exec's the real init - still pid=1.

Where does you specify those kernel cmdline parameters. As a bootp
resource? And isn't the kernel still in "initrd mode", wanting to do a
pivot/init instead of halting the system as soon as that "initial
process" dies?

> > Or am I stuck with having to construct an initrd that tftp's a
> > rootdisk image down and mounts and pivots to that?
> 
> I use userspace tftp quite a bit for my work; what tftp are you using? 
> I've patched RedHat's tftp-0.17 for command-line operation, and like it
> pretty well.  The tftp included with busybox wasn't very robust and
> would frequently time out and fail.

Thanks for the advanced warning on that.

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mr...@po... | http://www.pobox.com/~mra

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[David L. P. <pa...@li...>]

Mark Atwood wrote:
> 
> I can use mknbi-linux to make a netbootable linux kernel image with an
> initrd. That works fine.
> 
> Is their a way I can make a Linux NBI that has an "ordinary" root
> filesystem ramdisk, one that does /bin/init instead of the
> linuxrc/privot_root deal?

Sure, just don't make a 'linuxrc' file, instead:

root=/dev/ram init=/whatever/you/like (/sbin/init even).

This is the right way to do things now, see
linux/Documentation/initrd.txt.

I use a shell script init which later exec's the real init - still
pid=1.

> Or am I stuck with having to construct an initrd that tftp's a
> rootdisk image down and mounts and pivots to that?

I use userspace tftp quite a bit for my work; what tftp are you using? 
I've patched RedHat's tftp-0.17 for command-line operation, and like it
pretty well.  The tftp included with busybox wasn't very robust and
would frequently time out and fail.

regards,
	David

-- 
David L. Parsley
Network Administrator
Roanoke College

Re: [Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[Jim M. <ja...@Mc...>]

Mark,

You are free to do whatever you want within your initrd
image.  

I think that once you exit the shell that is running, it will turn
around and run /bin/init.  There's good docs in the /Documentation
directory for the Linux kernel.

Hope that helps,

Jim McQuillan
ja...@lt...

Mark Atwood wrote:
> 
> I can use mknbi-linux to make a netbootable linux kernel image with an
> initrd. That works fine.
> 
> Is their a way I can make a Linux NBI that has an "ordinary" root
> filesystem ramdisk, one that does /bin/init instead of the
> linuxrc/privot_root deal?
> 
> Or am I stuck with having to construct an initrd that tftp's a
> rootdisk image down and mounts and pivots to that?
> 
> --
> Mark Atwood   | I'm wearing black only until I find something darker.
> mr...@po... | http://www.pobox.com/~mra
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] Can mknbi-linux with "regular" root fs ramdisk?

[Mark A. <mr...@po...>]

I can use mknbi-linux to make a netbootable linux kernel image with an
initrd. That works fine.

Is their a way I can make a Linux NBI that has an "ordinary" root
filesystem ramdisk, one that does /bin/init instead of the
linuxrc/privot_root deal?

Or am I stuck with having to construct an initrd that tftp's a
rootdisk image down and mounts and pivots to that?

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mr...@po... | http://www.pobox.com/~mra

Re: [Etherboot-developers] eepro/100 problems

[Marty C. <md...@th...>]

On 4/4/01 3:08 AM Alexei A.Romanenko A.A...@in... wrote:
>I compile ROM image using etherboot-4.6.12 for my network card
>and place it as binary data into  AM27c512-120JI chip (eprom, 512 
>Kbit, 64Kx8)

I would try a 27C256-100, which is a smaller, faster EPROM.  It could be 
that your card is not capable of seeing that size/speed of EPROM.

>when i turn pc on it says nothing refered to booting via LAN
>(first boot from LAN is set in BIOS), although after installing
>bootstrap for LILO, computer boots well.

Get the DOS debug program, and search for the contents of the ROM in 
memory.

(by the way, could someone please send an actual DOS debugging session 
showing how to find EPROM contents in memory?  I am writing documentation 
for Etherboot, and would like to give an example for novices.  I guess I 
could define LPT to COM1 with some DOS mode command and capture the 
output of the serial port in a buffer, but if anyone knows a better way, 
I'd sure appreciate it.)

Anyway, I generally find problems with having ROMs recognized these days 
seems often to have to do with speed.  If the card doesn't insert enough 
wait states, then the CPU may try to read the ROM too fast, and think it 
is not there.

Maybe someone who knows more intimate details can be of more assistance.

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/

Re: [Etherboot-developers] Re: [Etherboot-users] RTL8139 EEPROM (SOLVED)

[Ken Y. <ke...@nl...>]

>Incidentally, while I was checking all sorts of things,  I found a couple of
>small things in the driver that didn't look right.  I'll mention them here in
>case they may be important to someone, but since everything works ok as it is
> I
>wouldn't worry about them otherwise.  (These comments apply to rtl8139.c in
>Etherboot 4.7.20, please ignore if they have already been fixed).
>
>1.  The write to Config1 (register offset 0x52)  in rtl8139_probe() under the
>comment "Bring the chip out of low-power mode" probably is not having any eff
>ect
>since bits EEM1-0 in Cfg9346 (register offset 0x50) need to be set first to
>unlock the Config1 register for write.
>
>2.  The MultiIntr register (offset 0x5C) should be cleared, according to the
>RTL8139C data sheet.
>
>
>One other thing.  I needed to reset the chip in rtl_disable(), which original
>ly
>was empty.  Without doing this I got "Unable to handle kernel paging request"
>panics when booting Linux after Etherboot.  I had USE_INTERNAL_BUFFER defined
>.
>The following code (just copied from elsewhere in the driver) worked for me:
>
>static void rtl_disable(struct nic *nic)
>{
>...
>}

Thanks for that. I'll add the disable routine in. Can some RTL8139
expert comment on the other two fixes?

[Etherboot-developers] eepro/100 problems

[Alexei A.R. <A.A...@in...>]

I compile ROM image using etherboot-4.6.12 for my network card
and place it as binary data into  AM27c512-120JI chip (eprom, 512 
Kbit, 64Kx8)

100bootp program (under win32) tells, that ROM is enabled, and
when I try to emulate renovation ROM content (eprom is nat a
flash) I get file 64MB size 8-\

when i turn pc on it says nothing refered to booting via LAN
(first boot from LAN is set in BIOS), although after installing
bootstrap for LILO, computer boots well.

    Alex
-------------------
    A.A...@in...