etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Re: Via-rhine in etherboot 5.1.1 & misc

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

>Valid also, but what is the need for a ring in this case ? If you wait
>for the transmit to be finished each time you send a packet, then a
>single
>buffer is enough.
>With my proposed patch, you can have 2 packets waiting to be sent, and
>only
>have to wait if you want to send a third one... Am I wrong ?

The ring is a leftover from the Linux driver that whoever ported the
code left in there. There is in fact no advantage in having more than
one transmit buffer and a memory penalty for doing so because all the
protocols used by Etherboot are stop and wait protocols. Network loading
is fast enough as it is anyway.

>Does not break the specs : the specs remains valid, but you get an extra
>feature
>for Etherboot... ;-)
>Well, I can live with my own version for now, it was just an idea.

Yes it does. It means Etherboot is accepting something outside the specs
and that means people may come to rely on it, and then it has to stay.
That's how crud starts. In any case PXE does not guarantee that you can
load more than 32kB of image starting at 0x7c00 and I'm surprised you
can load a kernel. Maybe it's not a kernel you're loading then.

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[Christoph P. <chr...@gm...>]

Ok, I will think about writing the HOWTO ...

To come back (only for a short hint).

You high quality on PCI handling allows using the idea of
legacy ROM images. Why ?
The answer is simple. When Etherboot starts, it does the whole
setup on his own. Setting up and activating PCI devices,
searching for the devices, attaching the driver to them and
run the boopt/tftp stuff.

The PCI/PnP header is only needed (AFAIK, and tests have proven
that) that the BIOS following the BBS (BIOS BOOT SPEC) creates
an boot entry in a list of bootable devices. Therefore the 
ROM code is not simple executed, but it is started following 
the boot order.

If the ROM has not a PCI/PnP haeder following BBS, then the
ROM code is treated as "normal" ROM extension (maybe something
else, than a boot device), an the BIOS has to execute this code
anyway, before going to the "boot work".

And as mentioned above, etherboot is fully self-contained and
can run the code booting an OS, or if the user decides to boot
locally (or if something fails) the control is given back to the
BIOS and so the BIOS starts it's normal boot process.

So the user can really select between two well defined booting
methods !!

With friendly regard
Christoph Plattner



Ken Yap wrote:
> 
> >It is paradox. The old BIOS not able to handle PCI/PnP headers,
> >have no problems, but the user also misses the feature of a
> >define boot order including the net.
> >On very new BIOS the problem exists, if the user want to have
> >a selection without touching the BIOS setup 9for example
> >embedded boards using serial console with a BIOS without serial
> >console port ....).
> >
> >I hope I could explain the problem, I often use the wrong words ...
> 
> I don't think pure PCI BIOSes are even required to pay attention to
> legacy ROMs since they don't expect them to be on the bus. So it's
> somewhat accidental that you can subvert the PnP mechanism to get the
> behaviour you want.
> 
> I would rather that you wrote a small HOWTO, and I will add it to the
> contrib/ section. If I make it part of the official config, people will
> ask me questions about it and I don't want to spend time finding out
> about their strange BIOS situation.  If you write the HOWTO, you can
> answer the questions.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

[Etherboot-developers] Re: Via-rhine in etherboot 5.1.1 & misc

[Jean-Jacques M. <jjm...@li...>]

Ken Yap a écrit :
> 

> The fix is valid, but it's better to do this wait just after sending the
> packet. Try putting just before:
> 
>         tp->cur_tx++;
> 
> this code:
> 
>     /* Wait until transmit is finished */
>     while (tp->tx_ring[entry].tx_status.bits.own_bit != 0)
>         ;
> 

Valid also, but what is the need for a ring in this case ? If you wait
for the transmit to be finished each time you send a packet, then a
single
buffer is enough.
With my proposed patch, you can have 2 packets waiting to be sent, and
only
have to wait if you want to send a third one... Am I wrong ?

(In fact, I tested your proposal first when debugging)

> Sorry, I can't do this. It breaks the spec of NBI images. You are free
> to hack your copy all you want though.

Does not break the specs : the specs remains valid, but you get an extra
feature
for Etherboot... ;-)
Well, I can live with my own version for now, it was just an idea.

Best regards,

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

[Etherboot-developers] Re: Via-rhine in etherboot 5.1.1 & misc

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

>I am currently testing PXE & Etherboot related topics and
>I came to notice a bug that could appear in Etherboot under
>some conditions (lot of successive & fast TX) in the via-rhine code.
>Here is the patch I use :
>
>+    /* Before writing in the TX buffs, wait if previous frame was not
>yet flushed */
>+    while (tp->tx_ring[entry].tx_status.bits.own_bit !=0);
>+

The fix is valid, but it's better to do this wait just after sending the
packet. Try putting just before:

	tp->cur_tx++;

this code:

    /* Wait until transmit is finished */
    while (tp->tx_ring[entry].tx_status.bits.own_bit != 0)
        ;

Please test this and let us know if it works. Thanks, it will go into
the next version, which will be 5.0.6.

>As you may be aware of, PXE does not use any particular image format :
>it just
>loads raw binary to 0x7C00 and executes it.
>Unfortunately, the header of NBI images does not allow me to use the
>same file
>for both PXE & Etherboot, but I found it could be interesting to shift
>the NBI
>header by (let's say) 8 bytes, so that I can put a "jmp +512" code in
>the begining
>of my code.

Sorry, I can't do this. It breaks the spec of NBI images. You are free
to hack your copy all you want though.

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

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

>It is paradox. The old BIOS not able to handle PCI/PnP headers,
>have no problems, but the user also misses the feature of a
>define boot order including the net.
>On very new BIOS the problem exists, if the user want to have
>a selection without touching the BIOS setup 9for example
>embedded boards using serial console with a BIOS without serial
>console port ....).
>
>I hope I could explain the problem, I often use the wrong words ...

I don't think pure PCI BIOSes are even required to pay attention to
legacy ROMs since they don't expect them to be on the bus. So it's
somewhat accidental that you can subvert the PnP mechanism to get the
behaviour you want.

I would rather that you wrote a small HOWTO, and I will add it to the
contrib/ section. If I make it part of the official config, people will
ask me questions about it and I don't want to spend time finding out
about their strange BIOS situation.  If you write the HOWTO, you can
answer the questions.

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[Christoph P. <chr...@al...>]

You are right, it is a special case.

But this case is not only for ISA, but also for PCI !!
In my case it was a PCI device (eepro100) and a new embedded
Pentium board and a current BIOS version.

And especially for all users (also beginners), who want to use
the etherboot query instead of the BIOS boot order, all those
user will need this options (removing "-DPCI_PNP_HEADER").
So it is not so special ...

It is paradox. The old BIOS not able to handle PCI/PnP headers,
have no problems, but the user also misses the feature of a
define boot order including the net.
On very new BIOS the problem exists, if the user want to have
a selection without touching the BIOS setup 9for example
embedded boards using serial console with a BIOS without serial
console port ....).

I hope I could explain the problem, I often use the wrong words ...

Christoph Plattner



Ken Yap wrote:
> 
> >So could for example introduce a
> >
> >BBS_OPTIONS = -DPCI_PNP_HEADER   # is the default
> >
> >in the `Config' file, and the user can comment this line,
> >if the user wants to have a legacy extension ROM.
> >It would also be nice to have this as a "rom-o-matic" option.
> 
> Sounds like something that's rarely needed and people who know what they
> are doing can edit the Config file. I think putting it in rom-o-matic is
> bad idea, people who don't know what they are doing will fiddle with
> this option without reason.
> 
> I think the behaviour of PnP BIOSes to legacy ROMs is being phased out
> as motherboards stop having ISA slots.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

[Etherboot-developers] mknbi-1.2-7rc3 released

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

>Ah, ok I guess I was being lazy and assuming that the second segment
>would be above 1MB.
>
>Ok, I didn't realise that ramdisk_max was a cap rather than the actual
>top of memory. Makes sense. Will fix.

Sorry, the last posting went to Etherboot-users by mistake, mystifying
newbies no doubt, but I think I've got the code right now (famous last
words). Latest release is in:

	http://etherboot.sf.net/mknbi-1.2-7rc3.tar.gz

Here's the relevant segment:

	...
	get_memsizes();
	max = (setup->su_version >= 0x203) ? setup->ramdisk_max : 0x37FFFFFF;
	/* compute top of initrd only if user has not overridden it */
	if (top_of_initrd == 0) {
		struct e820entry	*e;
		/* look for highest E820_RAM that is under ramdisk_max
		   strictly speaking we should also check that
		   we have room for the ramdisk in the memory segment */
		for (i = 0; i < meminfo.map_count; i++) {
			e = &meminfo.map[i];
			if (e->type == E820_RAM
				&& e->addr < max
				&& (e->addr + e->size) > top_of_initrd)
				top_of_initrd = e->addr + e->size;
		}
	}
	if (top_of_initrd > max)
		top_of_initrd = max;
	/* Round down to next lower 4k boundary */
	top_of_initrd &= ~0xFFF;
	printf("Top of initrd is %dk\n", top_of_initrd >> 10);
	...

and top_of_initrd measures bytes now.

Re: [Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

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

>So could for example introduce a
>
>BBS_OPTIONS = -DPCI_PNP_HEADER   # is the default
>
>in the `Config' file, and the user can comment this line, 
>if the user wants to have a legacy extension ROM.
>It would also be nice to have this as a "rom-o-matic" option.

Sounds like something that's rarely needed and people who know what they
are doing can edit the Config file. I think putting it in rom-o-matic is
bad idea, people who don't know what they are doing will fiddle with
this option without reason.

I think the behaviour of PnP BIOSes to legacy ROMs is being phased out
as motherboards stop having ISA slots.

[Etherboot-developers] Small change request: make usage of PCI_PNP_HEADER configurable

[Christoph P. <chr...@al...>]

Hello Etherboot hackers.

Here is a small change request:
We have found a case, where we need for example eepro100.rom
on a BBS able BIOS, but we want to select the boot mode
("L"olcal or from "N"et) by the ASK_xxx option, and not
by modifying the boot order in the BIOS on an embedded machine.

On such a BBS able BIOS, this ASK_xxx is not working very
well, then the user has to press enter after an error, etc...

The only "clean" way to use this image is: make a LEGACY ROM
EXTENSION not including a PCI and PnP header. So network is
not seen as a real boot device, and the EXTENSION ROM is
executed before the normal boot sequence start.

To get such an image, I only removed the "-DPCI_PNP_HEADER"
from the build of the `pr(z)lodaer.bin' image.

The alternate usage of "NO_DELAYED_INT" instead of removing
the PCI/PNP haeder was not a good solution.

So could for example introduce a

BBS_OPTIONS = -DPCI_PNP_HEADER   # is the default

in the `Config' file, and the user can comment this line, 
if the user wants to have a legacy extension ROM.
It would also be nice to have this as a "rom-o-matic" option.

In the `Makefile' the lines become following:

bin/prloader.s: loader.S $(MAKEDEPS)
        $(CPP) $(LCONFIG) $(BBS_OPTIONS) -o $@ $<

bin/przloader.s:        loader.S $(MAKEDEPS)
        $(CPP) $(LCONFIG) $(BBS_OPTIONS) -DZLOADER -o $@ $<


I hope you like the idea,

Christoph Plattner

(I can also send this as a patch, but this is trival here !).




-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

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

> >Just doing a code review I can say that there are some serious logic bugs.
> >Usually there are at least 2 ram segments in the returned e820 information
> >which is a little screwy.
> 
> Can you elaborate?

Here is the e820 map from one of my test machines:
BIOS-e820: 0000000000000000 - 000000000009FC00 (ram)
BIOS-e820: 000000000009FC00 - 00000000000A0000 (ram)
BIOS-e820: 00000000000F0000 - 0000000000100000 (reserved)
BIOS-e820: 00000000FEC00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000000100000 - 000000001FFF0000 (ram)
BIOS-e820: 000000001FFF3000 - 0000000020000000 (ACPI data)
BIOS-e820: 000000001FFF0000 - 000000001FFF3000 (ACPI NVS)

Your code if I read it right would decide to use:
BIOS-e820: 000000000009FC00 - 00000000000A0000 (ram)
to compute the top of memory.  

There are no gaurantees that the e820 result will even be sorted.
 
> >But more interesting the following logic in first32.c is just wrong.
> >
> >		top_of_mem = ((setup->su_version >= 0x203) ?
> >			setup->ramdisk_max :
> >			(e->addr + e->size)
> >			) >> 10;
> >
> >setup->ramdisk_max is in bytes not kilobytes.
> >
> >And if you set the top_of_ram to just under 1GB on a 16M machine your
> >ramdisk will fail miserably.  Unless there is some magic that just
> >makes this code work...
> 
> But top_of_mem is measured in kB (I know, it's confusing, maybe I should
> rationalise that). Note the parentheses. ramdisk_max is at the same
> level as e->addr + e->size. If expanded it looks like this:
> 
> 	if (su_version >= 0x203)
> 		temp = ramdisk_max;
> 	else
> 		temp = e->addr + e->size;
> 	top_of_mem = temp >> 10;

O.k.  I missed that the >> applied to both parts of the assignment.

But the bigger issue that ramdisk_max =~ 1GB.  And you set
top_of_mem to that even when you only have 16MB of memory.  And then
you copy your ramdisk to just below top_of_mem is a real issue.

Better logic looks like:
ramdisk_max =  0x37FFFFFF >> 10;
if (su_version >= 0x203) {
        ramdisk_max = setup->ramdisk_max >> 10;
}

if (top_of_mem > ramdisk_max) {
        top_of_mem = ramdisk_max;
}

Eric

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>Just doing a code review I can say that there are some serious logic bugs.
>Usually there are at least 2 ram segments in the returned e820 information
>which is a little screwy.

Can you elaborate?

>But more interesting the following logic in first32.c is just wrong.
>
>		top_of_mem = ((setup->su_version >= 0x203) ?
>			setup->ramdisk_max :
>			(e->addr + e->size)
>			) >> 10;
>
>setup->ramdisk_max is in bytes not kilobytes.
>
>And if you set the top_of_ram to just under 1GB on a 16M machine your
>ramdisk will fail miserably.  Unless there is some magic that just
>makes this code work...

But top_of_mem is measured in kB (I know, it's confusing, maybe I should
rationalise that). Note the parentheses. ramdisk_max is at the same
level as e->addr + e->size. If expanded it looks like this:

	if (su_version >= 0x203)
		temp = ramdisk_max;
	else
		temp = e->addr + e->size;
	top_of_mem = temp >> 10;

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

ke...@us... writes:

> I have placed mknbi-1.2-7rc2 at
> http://etherboot.sf.net/mknbi-1.2-7rc2.tar.gz
> 
> The only change from rc1 is that it now detects setup version 0x203
> (kernel 2.4.18 onwards) and uses the ramdisk_max variable as the default
> top of initrd.  This should help people with large amounts of RAM who
> currently have to set rdbase themselves. Please report problems to this
> list.

Just doing a code review I can say that there are some serious logic bugs.
Usually there are at least 2 ram segments in the returned e820 information
which is a little screwy.

But more interesting the following logic in first32.c is just wrong.

		top_of_mem = ((setup->su_version >= 0x203) ?
			setup->ramdisk_max :
			(e->addr + e->size)
			) >> 10;

setup->ramdisk_max is in bytes not kilobytes.

And if you set the top_of_ram to just under 1GB on a 16M machine your
ramdisk will fail miserably.  Unless there is some magic that just
makes this code work...

Eric

[Etherboot-developers] Problems with Multiboot BIOS and Etherboot ....

[Christoph P. <chr...@gm...>]

Integrating Etherboot to a Phoenix BIOS of an embedded Pentium
board make some problems. See Email below.

Further we have following problem:
The board has 3 ethernet chips (82559ER). Now the Etherboot image
using "NO_DELAYED_INT" starts 3 times (booting "L"ocal after
3 seconds), then it writes "No SYSTEM found, press any key",
after a ENTER, the BIOS boots normally.

How can the Extension be integrated (with the constraints descirbed
	below).

How can Etherboot be built, that the ROM boot loades is activaed
and the PCI devices are found, but WITHOUT beeing a BBS compliant
image (not comming in the boot order of boot devices) ?

I hope, anybody can help here !

With friendly regards
Christoph Plattner


Christoph Plattner wrote:
> 
> Hello Etherboot hackers !
> 
> For a special embedded board I have following problem:
> 
> We want to have a BIOS setup, which must never be changed during
> operation and both should be possible: booting local and from net.
> 
> I configured a `etherboot' for default=local, timout=3sec and
> the usage of serial console (in normal operation the board is
> used haedless (=without screen and keyboard).
> 
> Now the problem: As the BIOS is multiboot compliant, the BIOS
> sees etherboot as one "bootable device" (under normal circumstances
> a very good thing ....). The etherboot is the first in the boot
> order. After the timeout of 3 secs is over, the BIOS should boot
> local, but loads again `etherboot' (so the BIOS tries to simple
> boot always the normal order ....).
> 
> On other machines not having mulitboot BIOS, etherboot is simple
> executed before the normal BIOS boots up with local disks.
> How can I tell the BIOS to run etherboot before booting local
> disk and not to have etherboot as one selectable device ?
> Can this be done with the `-DNO_DELAYED_INT' to have etherboot
> run before ... and then BIOS is trying to boot locally (of course
> then etherboot has to be not the first in the boot order, if
> etherboot is seen as boot device also).
> 
> Is there another way ? Again, the BIOS (boot order) must not (cannot)
> be changed, as no screen/keyboard is present ....
> The default should be a local boot, but pressing "N" while the
> first 3 seconds (or whatever configured), the machine should also
> boot from net.
> 
> By the way, the BIOS is a PhoenixBios customized to this embedded
> board.
> 
> With friendly regards
> Christoph Plattner
> 
> --
> -------------------------------------------------------
> private:        chr...@gm...
> company:        chr...@al...
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Rohit J. <ro...@pr...>]

Greetings,

On Wed, Feb 27, 2002 at 11:20:53AM +1100, Ken Yap wrote:
> >Heh, you just got patches to do some of that in the context of the
> >PXE patches to emulate PXE enough for the FreeBSD PXE boot loader to
> >work!  Maybe grub could be re-worked to access the hardware via PXE and
> >not just look like a PXE image.  Randoms thoughts are what if
> >Etherboot had a PXE network driver writen in terms the PXE stuff
> >that was sent in?  That would seem to get us most of the way there.
> >"pxegrub" could use the Etherboot "PXE network driver" to talk
> >to the Etherboot PXE emulation layer.
> 
> At first glance I don't think it can be modified to do pxelinux. The
> FreeBSD patches just do "PXE-style" booting, which means a small
> secondary loader is loaded starting at 0x7c00 and this loads the main
> image. There is no requirement for it to go through the "official" PXE
> interrupts, in fact this one just does a longjmp to the Etherboot
> routines. Now that's not necessarily a bad thing, but it means you can't
> take pxelinux and use that. So either:

Actually the PXE API entry point is a 'C' function defined in main.c.

int pxeemu_entry(struct v86 *x_v86_p, int *x_pxeemu_v86_flag,
	  	 int x_pxeemu_func_nr, vm_offset_t x_pxeemu_func_arg)

Its address is contained in the PXENV+ structure (pxenv->PMOffset). The
nbp (network boot program) uses this address to invoke PXE calls. This is 
analogous to the real mode PXE API calling mechanism. This facility
is non-standard and had to be invented as the PXE standard provides no
way (at least none I could figure out) to access the PXE API from 32bit 
protected mode.

The address of the PXENV+ structure is passed to the nbp in the %ebx register
as required by the standard. The nbp is loaded and executes at 0x7c00 again as 
required by the standard.

The *jmp magic is to allow the emulation code to utilize the nbp 
infrastructure to make vm86 calls, as _real_to_prot and _prot_to_real are 
unusable once the nbp switches to protected mode. The idea is that when we 
want to make a vm86 call we fill in the v86 structure, set the v86_flag, save
our state (setjmp) and return immediately. The caller checks this flag on 
return from the API call, if set it executes the vm86 action defined by the 
v86 structure and calls the API function again with the flag set. The API 
entry function notices that the flag is set and does a longjmp to return to 
the saved state. 

For this to work correctly the emulation code and the nbp must not use the 
same stack, which is no problem as the nbp defines its own stack area as 
does ETHERBOOT. We switch stacks on API entry and exit (using *jmp routines). 

Currenty the v86 facility is used only by console_putc to provide video
console feedback.

IMO it should be relatively easy to modify pxelinux to use this PXE emulation,
especially so if we are willing  do away with all the v86/*jmp stuff. This
would mean no video console output (com console is ok) from the emulation 
layer once the nbp is running. Should be okay as the nbp will provide feedback
using its own mechanisms.


regards, 

rohit

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>I have it on my plan, that if I find a config with a combination
>of current driver, which do not work (hang at probing), and I can
>fix this in the NIC driver, then I will send a patch to you.
>For PCI there should not be any problem (I have a config with
>TULIP plus EEPRO100). For ISA devices (NE2K or similar) there
>may be a problem, but I think, we can find the problem in the
>driver not to loop endless. In case of Etherboot, if NIC probing
>fails, the etherboot may give back control to the BIOS to load
>locally installed systems (only an idea, ...).

Fine. All useful bug fixes accepted.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Christoph P. <chr...@gm...>]

Oh I have got your point, I only react to the first part with
"another copy...".

In the second part, you are right. GRUB can take more than one
driver at the same time, but some drivers have difficulties
while probing, the hung up.

I have it on my plan, that if I find a config with a combination
of current driver, which do not work (hang at probing), and I can
fix this in the NIC driver, then I will send a patch to you.
For PCI there should not be any problem (I have a config with
TULIP plus EEPRO100). For ISA devices (NE2K or similar) there
may be a problem, but I think, we can find the problem in the
driver not to loop endless. In case of Etherboot, if NIC probing
fails, the etherboot may give back control to the BIOS to load
locally installed systems (only an idea, ...).

But IMO it is not primary a GRUB problem.

But Eric has right. A disadvantage of GRUB is the x86 dependency !

With friendly regards
Christoph Plattner



Ken Yap wrote:
> 
> >It's new, but GRUB has now the current state of Etherboot !
> >Not only some drivers of an old state. Since some week, we have
> >5.0.5 driver with the current PCI init (inclusive bus master
> >enabling,etc).
> >
> >When GRUB is up, BOOTP and TFTP is working, where is the problem
> >you mention, why PXE ?
> 
> If you don't understand, don't worry be happy.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>It's new, but GRUB has now the current state of Etherboot !
>Not only some drivers of an old state. Since some week, we have
>5.0.5 driver with the current PCI init (inclusive bus master
>enabling,etc).
>
>When GRUB is up, BOOTP and TFTP is working, where is the problem
>you mention, why PXE ?

If you don't understand, don't worry be happy.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

Christoph Plattner <chr...@gm...> writes:

> GRUB loads the standard build linux image (default vmlinuz !).
> 
> Again, I do not want a GRUB vs. Etherboot competition !
> I like both in conjunction !

Well I certainly won't stop you.  My problem with GRUB is
that I can't use it under LinuxBIOS or on non-x86 platforms.  So
Grub is unusable for me.

Eric

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Christoph P. <chr...@gm...>]

Hello !

I do not see a need for that. GRUB was modified some weeks ago,
to copy in all the current etherboot drivers. GRUB is on the same
state as Etherboot (the number of drivers and the version of the
drivers). GRUB has now the state of 5.0.5.

Using PXE drivers for GRUB may be an idea, but there must be a 
special support in the BIOS AFAIK.
But GRUB should also run on NON-PXE BIOS or without Etherboot.

Bye
Christoph

PS: It should not come out a GRUB vs. Etherboot competition.....


Doug Ambrisko wrote:
> 
> Ken Yap writes:
> | >Sorry to say this again, but I prefer using GRUB together with
> | >`etherboot', and so nobody has to deal with `mknbi' in connection
> | >with UNIX systems (for DOS mknbi is already needed so far).
> |
> | There's no accounting for taste. :-)
> |
> | GRUB suffers from the problem that it uses another copy of the network
> | driver so you have to decide ahead of time which hardware you want to
> | support when building GRUB. Ideally secondary loaders should be able to
> | use the boot ROMs network driver. Hmm, sounds very much like PXE. I wish
> | I had the time to rework Etherboot's architecture to allow callbacks so
> | that secondary loaders can do network operations. Not necessarily PXE
> | style, just having callbacks would be nice.
> 
> Heh, you just got patches to do some of that in the context of the
> PXE patches to emulate PXE enough for the FreeBSD PXE boot loader to
> work!  Maybe grub could be re-worked to access the hardware via PXE and
> not just look like a PXE image.  Randoms thoughts are what if
> Etherboot had a PXE network driver writen in terms the PXE stuff
> that was sent in?  That would seem to get us most of the way there.
> "pxegrub" could use the Etherboot "PXE network driver" to talk
> to the Etherboot PXE emulation layer.
> 
> This sounds interesting to me.
> 
> Doug A.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Christoph P. <chr...@gm...>]

GRUB loads the standard build linux image (default vmlinuz !).

Again, I do not want a GRUB vs. Etherboot competition !
I like both in conjunction !

Christoph P.


"Eric W. Biederman" wrote:
> 
> Christoph Plattner <chr...@gm...> writes:
> 
> > Hello !
> >
> > Sorry to say this again, but I prefer using GRUB together with
> > `etherboot', and so nobody has to deal with `mknbi' in connection
> > with UNIX systems (for DOS mknbi is already needed so far).
> 
> I agree that not necesarily needing mknbi is a good thing which
> is why I am working on cleaning up the linux kernel build, so
> it build ELF bootable kernels.
> 
> > GRUB can direclty load images and has currently the SAME network
> > driver state as etherboot (full 5.0.5 driver compatible).
> 
> But the images still must be built.
> 
> > I like really both, especially both in conjunction.
> > Etherboot+GRUB is one of the best BIOS "Extensions" to get a feeling
> > of a full boot monitor like on SUN or HP (even better !!!!).
> 
> And reply to me on this is definentily talking to the wrong crowd.
> For the most part I figure todays BIOS's are way to complex to be
> maintainable.  And I don't care how far you extend a pile of rubble
> you just get more rubble.
> 
> As for GRUB I see a lot of design issues with it, and it's whole
> multiboot format.  I will agree for purposes of argument that
> it may get experience right but that is about it.
> 
> Eric

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Christoph P. <chr...@gm...>]

It's new, but GRUB has now the current state of Etherboot !
Not only some drivers of an old state. Since some week, we have
5.0.5 driver with the current PCI init (inclusive bus master
enabling,etc).

When GRUB is up, BOOTP and TFTP is working, where is the problem
you mention, why PXE ?

Bye
Christoph P.

PS: Again, I do not want to have a competition between Etherboot and
GRUB. I like both in conjuntion !



Ken Yap wrote:
> 
> >Sorry to say this again, but I prefer using GRUB together with
> >`etherboot', and so nobody has to deal with `mknbi' in connection
> >with UNIX systems (for DOS mknbi is already needed so far).
> 
> There's no accounting for taste. :-)
> 
> GRUB suffers from the problem that it uses another copy of the network
> driver so you have to decide ahead of time which hardware you want to
> support when building GRUB. Ideally secondary loaders should be able to
> use the boot ROMs network driver. Hmm, sounds very much like PXE. I wish
> I had the time to rework Etherboot's architecture to allow callbacks so
> that secondary loaders can do network operations. Not necessarily PXE
> style, just having callbacks would be nice.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>As first is the entry point of the image, and as it assumes it is called
>with a specific set of arguments and with an initial stack breaking that
>those assumptions might be a little tricky.

We probably have to develop a variant output format or merge your
mkelfimage into mknbi.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

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

> >I have a smallish problem.  We can talk more about it but essentially 
> >mkelf-linux fails if it wasn't loaded with the etherboot ``generic''
> >ELF loader.  It should be able to continue to work and just loose
> >some features if it is loaded by an unrecognized ELF loader.
> 
> Ok. There's probably some dependency I'll have to look into.

O.k. I just confirmed the problem still exists.  The assumption comes
is from first32.c demonstrated here:

#ifdef  FIRST32RM
int first(union infoblock *header, struct bootp_t *bootp)
#else
int first(struct ebinfo *eb, union infoblock *header, struct bootp_t *bootp)
#endif

And here:

        /* Sanity checks */
#ifdef  FIRST32ELF
        if (header->img.magic != ELF_MAGIC)
#else
        if (header->img.magic != TAG_MAGIC)
#endif
                quit();


As first is the entry point of the image, and as it assumes it is called
with a specific set of arguments and with an initial stack breaking that
those assumptions might be a little tricky.

Eric

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>Heh, you just got patches to do some of that in the context of the
>PXE patches to emulate PXE enough for the FreeBSD PXE boot loader to
>work!  Maybe grub could be re-worked to access the hardware via PXE and
>not just look like a PXE image.  Randoms thoughts are what if
>Etherboot had a PXE network driver writen in terms the PXE stuff
>that was sent in?  That would seem to get us most of the way there.
>"pxegrub" could use the Etherboot "PXE network driver" to talk
>to the Etherboot PXE emulation layer.

At first glance I don't think it can be modified to do pxelinux. The
FreeBSD patches just do "PXE-style" booting, which means a small
secondary loader is loaded starting at 0x7c00 and this loads the main
image. There is no requirement for it to go through the "official" PXE
interrupts, in fact this one just does a longjmp to the Etherboot
routines. Now that's not necessarily a bad thing, but it means you can't
take pxelinux and use that. So either:

1. Develop an analogous stub to what FreeBSD is using, but for Linux.
But is that much improvement than doing mknbi on the image?

2. Do the full PXE interrupt thing in Etherboot. This would allow
Etherboot to use pxelinux, bpbatch and other PXE utils. But I think the
PXE spec is ugly.

3. A crazy idea I tossed around for a while, a tftpd that does a mknbi
on the fly.

4. What Eric is doing: Fix the kernel build process, so that netbootable
and diskbootable images are generated directly.

I like 4, but it doesn't do anything for other OSes. But then I don't
have other OSes, save FreeDOS, hence my inaction.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

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

> >Sorry to say this again, but I prefer using GRUB together with
> >`etherboot', and so nobody has to deal with `mknbi' in connection
> >with UNIX systems (for DOS mknbi is already needed so far).
> 
> There's no accounting for taste. :-)
> 
> GRUB suffers from the problem that it uses another copy of the network
> driver so you have to decide ahead of time which hardware you want to
> support when building GRUB. Ideally secondary loaders should be able to
> use the boot ROMs network driver. Hmm, sounds very much like PXE. I wish
> I had the time to rework Etherboot's architecture to allow callbacks so
> that secondary loaders can do network operations. Not necessarily PXE
> style, just having callbacks would be nice.


My take on the hardware support issue is a little different.  For
the most part I just want to load kernels instead of reinventing
hardware abstraction layers.  And kernels also have the issue of needing
hardware drivers.  

The only downside to having all of your drivers built in (disregarding devices
that cannot be reliably probed for) is that you need to have enough
memory to support them.   Currently for linux this is about 10MB.
Which is a substanial system requirement.  When I looked at the growth
it feels linear with time (though exponential with kernel major
revision).   So in my long term plan is to label a kernel with where
all of it's drivers are and to have a bootloader that can
decide not to load the unnecessary drivers in a generic kernel image.
For small machines at least that could be really beneficial.

Beyond that I intend to get booting linux from linux into the
mainstream kernel so something like GRUB (if you want it).  Can be
written as a user space application.

Eric