etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Fragmented packets....

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

ebi...@ln... (Eric W. Biederman) writes:

> ke...@us... (Ken Yap) writes:
> 
> > >I have just started some serious tests on my multicast implementation,
> > >and the fragmetted packet warning is triggering a lot.  What is happening
> > >is that there is other broadcast traffic that is transmitting fragmented
> > >packets.  The problem is that with errors at 9600 baud seeing lots of
> > >warnings cause a major slowdown in etherboot.
> > 
> > Just make -DMULTICAST discard fragments silently would be the fix I
> > guess.
> 
> Depending on the network we might see this with broadcast packets as
> well.  The solution I plan to implement now that I have slept is to 
> first drop packets that are not to a mac we are listening on.  So
> it must be our mac, broadcast, or a multicast mac we are listening to.
> And then if it occurs set a timer and limit the reporting rate to once
> a second.
> 
> If the message is at all useful arbitrarily disabling it is bad.
> 
> This is more a busy network problem than a multicast problem in
> particular.  I just happened to trigger it.

Actually what I have implemented is to just warn once.  

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

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

Anselm Martin Hoffmeister <an...@ho...> writes:

> > Right the code is already doing this correct.  But thanks for the catch.
> 
> You wrote about putting public your code. Did you? Where can I get it, is the 
> CVS always the uptodate source (I never worked with CVS before)?

I'm getting there.  I'm so busy working on it that I haen't had a free moment
to do that yet.  Hopefully I can get that done later today. 

> As now minor changes to some (sooner or later most/all) hardware drivers 
> arise (though only triggered when MULTICAST is enabled) perhaps 5.0.7-rc 
> should stay rc for some days, so that these changes can make their way to the 
> next release. The opposite argumentation would be to release stable and 
> old-fashioned, giving the multicast out to public retarded. That's not what I 
> (my two cents, you know, thanks to Peter Billson for explaning me that 
> phrase) like, the more public the better the testing. We don't force anyone 
> to enable that configuration switch.

There are pieces that could make 5.0.7-rc but I have enough changes in
other parts of the code with hard driver booting etc, that I'd rather
push it to 5.0.8. 
 
> To Eric:
> What about the standard protocol (or less-standard?) you want to have for 
> multicast? Do you have documentation at hand? 

Yes I have one but I'm not going to fix anything in stone until I get
some successful large scale testing.  My biggest hold up is someone
let the test environment at work get into a sorry state.  And I have
been rebuilding it.

> Else I would like to start 
> adding tftp-mcast support as my quickly hacked daemon for that protocol at 
> least runs, on low-load-testing with two clients stably. Perhaps if ready I 
> could have a mass-test (ok, 15 clients is not much, but better that nothing) 
> the after-next weekend at my "private testing laboratory", until then I 
> should have made a release out of it, announce will follow. But of course, if 
> you have a better protocol at hand, please let me know.

Given that I will definentily see what I can push into the 5.1 tree in
cvs.

> An*getting CVS to work right now*selm

Good luck on that.  CVS works as a pretty good distribution
mechanism.  If you prefer patches I can go that route to.

Eric

Re: [Etherboot-developers] Fragmented packets....

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

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

> >I have just started some serious tests on my multicast implementation,
> >and the fragmetted packet warning is triggering a lot.  What is happening
> >is that there is other broadcast traffic that is transmitting fragmented
> >packets.  The problem is that with errors at 9600 baud seeing lots of
> >warnings cause a major slowdown in etherboot.
> 
> Just make -DMULTICAST discard fragments silently would be the fix I
> guess.

Depending on the network we might see this with broadcast packets as
well.  The solution I plan to implement now that I have slept is to 
first drop packets that are not to a mac we are listening on.  So
it must be our mac, broadcast, or a multicast mac we are listening to.
And then if it occurs set a timer and limit the reporting rate to once
a second.

If the message is at all useful arbitrarily disabling it is bad.

This is more a busy network problem than a multicast problem in
particular.  I just happened to trigger it.

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

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

>As now minor changes to some (sooner or later most/all) hardware drivers 
>arise (though only triggered when MULTICAST is enabled) perhaps 5.0.7-rc 
>should stay rc for some days, so that these changes can make their way to the

It's too early to worry about that, it's only rc1 and usually it takes
up to rc4 or 5 before I'm happy with it. So it could go either way,
multicast might make it into 5.0.7. Or not.

Re: [Etherboot-developers] [RFC] Multicast reception....

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

> Right the code is already doing this correct.  But thanks for the catch.

You wrote about putting public your code. Did you? Where can I get it, is the 
CVS always the uptodate source (I never worked with CVS before)?

As now minor changes to some (sooner or later most/all) hardware drivers 
arise (though only triggered when MULTICAST is enabled) perhaps 5.0.7-rc 
should stay rc for some days, so that these changes can make their way to the 
next release. The opposite argumentation would be to release stable and 
old-fashioned, giving the multicast out to public retarded. That's not what I 
(my two cents, you know, thanks to Peter Billson for explaning me that 
phrase) like, the more public the better the testing. We don't force anyone 
to enable that configuration switch.

To Eric:
What about the standard protocol (or less-standard?) you want to have for 
multicast? Do you have documentation at hand? Else I would like to start 
adding tftp-mcast support as my quickly hacked daemon for that protocol at 
least runs, on low-load-testing with two clients stably. Perhaps if ready I 
could have a mass-test (ok, 15 clients is not much, but better that nothing) 
the after-next weekend at my "private testing laboratory", until then I 
should have made a release out of it, announce will follow. But of course, if 
you have a better protocol at hand, please let me know.

An*getting CVS to work right now*selm

Re: [Etherboot-developers] Fragmented packets....

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

>I have just started some serious tests on my multicast implementation,
>and the fragmetted packet warning is triggering a lot.  What is happening
>is that there is other broadcast traffic that is transmitting fragmented
>packets.  The problem is that with errors at 9600 baud seeing lots of
>warnings cause a major slowdown in etherboot.

Just make -DMULTICAST discard fragments silently would be the fix I
guess.

[Etherboot-developers] Fragmented packets....

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

I have just started some serious tests on my multicast implementation,
and the fragmetted packet warning is triggering a lot.  What is happening
is that there is other broadcast traffic that is transmitting fragmented
packets.  The problem is that with errors at 9600 baud seeing lots of
warnings cause a major slowdown in etherboot.

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

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

Donald J Christensen <dj...@ci...> writes:

> "Eric W. Biederman" wrote:
> > 
> > "Anselm Martin Hoffmeister" <an...@ho...> writes:
> ...
> > > As you might have read already, multicast packets are addressed to special
> > > ethernet addresses (00:50:5f:xx:yy:zz or so, no docs at hand), leaving away
> > > the top 8 bit of the Multicast IP address.
> ...
> 
> Just a slight correction here.  The least significant bit of the most
> significant byte of the MAC address needs to be a one for multicast.
> Ie, 01.00.5e.xx.yy.zz is typically used for addresses managed by IGMP.

Right the code is already doing this correct.  But thanks for the catch.

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

[Donald J C. <dj...@ci...>]

"Eric W. Biederman" wrote:
> 
> "Anselm Martin Hoffmeister" <an...@ho...> writes:
...
> > As you might have read already, multicast packets are addressed to special
> > ethernet addresses (00:50:5f:xx:yy:zz or so, no docs at hand), leaving away
> > the top 8 bit of the Multicast IP address.
...

Just a slight correction here.  The least significant bit of the most
significant byte of the MAC address needs to be a one for multicast.
Ie, 01.00.5e.xx.yy.zz is typically used for addresses managed by IGMP.

-Don

-- 
Don Christensen       Senior Software Development Engineer
dj...@ci...         Cisco Systems, Santa Cruz, CA
  "It was a new day yesterday, but it's an old day now."

Re: [Etherboot-developers] [RFC] Booting from disk....

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

>To make this work under LinuxBIOS I need to do the following things.
>1) Move the code for booting an x86 bootsector into osloader.c
>   So I can boot ELF image directly from disk.
>
>2) Modify bootdisk to take a download_kernel parameter.  If
>   only a stock x86 bootsector is present it will be used see 1.
>
>3) Modify bootdisk to call my polled drivers.

Should be ok. I've had a look and the code around loadkernel is a bit of
a mess.  Probably what should be done is:

1. downloadkernel is misnamed. It probably did the downloading ages ago,
but really it should be called handleblock. In fact I've just done that
name change in my version. The symbol's static and so has no ripple on
effects.

2. loadkernel is either a macro or a routine depending on whether
CAN_BOOT_DISK is defined. It should be taken out and shot.  Ok, ok, just
taken out. Into another file. Say it's called load.c. It should handle
the sequencing of bootable devices. It would also separate the kernel
name from the device name, which I assume is what you mean in 2.

3. floppy.c is also misnamed since it also handles hard disks now. The
code there should be integrated into some disk driving routines, which
is what I assume you are creating. I would like to see the disk modules
optional so that those who don't use them don't have to pay for it.

3. Not sure how osloader comes into this. os_download is called from
handleblock (formerly downloadkernel). Does it have to be involved?

The convention for specifying the driver type, partition and filename is
another can of worms. However, it's delegated to the disk driver. All
load.c has to know is which driver to call and to pass the tail of the
path to it.

Re: [Etherboot-developers] [RFC] Booting from disk....

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

Hmm.  The more I look at this the more I want to do:

file:///driver/disk/partition/.....
Where I would have driver choices of:
bios_disk
ide
floppy
idecd
plus various scsi controllers some day.

With an extra driver disk, that would walk through all of drivers
is some order and give you the specified disk.  Or possibly
a extra drivers fixed and removable that walk through the various kinds
of disk in the specified order.

With the exact driver match you can trivially go directly to the disk
you are looking for, without worrying about spinning up unnecessary
disks.  And the alias drivers would allow for simple configurations.

Eric

Re: AW: [Etherboot-developers] Splashimage / Bootlogo

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

>> Nope, no callbacks are involved, only a return address and a returned

The return address is just a normal return from subroutine.

>> long in EAX.
>
>Which is almost a callback, but it easier to deal with.  The PXEEMU
>case definitely requires callbacks :(  How is the boot filename specified? 

The menu program alters the DHCP structure.

Re: AW: [Etherboot-developers] Splashimage / Bootlogo

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

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

> >Sounds sane.  One thing I would like to do in conjunction with this
> >is to figure out what we need to do to relocate etherboot.  Allowing
> >arbitrary to be down loaded.  If you don't have to support callbacks
> >this is trivial, with callbacks this becomes a more interesting
> >challenge.
> 
> Nope, no callbacks are involved, only a return address and a returned
> long in EAX.

Which is almost a callback, but it easier to deal with.  The PXEEMU
case definitely requires callbacks :(  How is the boot filename specified? 
 
> >Mostly I think etherboot can be moved to the highest available address
> >below 4G, with just a touch of care.  The challenges are keeping the
> >overhead down, and still allowing dos BIOS calls.  Because that needs
> >a small chunk below 1MB.
> 
> That'll be great.

Right that is ideal.  But I keep looking for something a little easier
to code up.

Eric

[Etherboot-developers] [RFC] Booting from disk....

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

I am currently integrating some polling disk drivers into etherboot.  One
for IDE and another for standard floppies.  And if it works out
polling cd drivers and polling scsi drivers may be in the future.  I am
doing this because I need a general purpose bootloader for LinuxBIOS.
And if I can keep everything small I can use the code on systems even
without LinuxBIOS present.

The current syntax for booting off of disk is to specify:
filename "/dev/fd0"
or
filename "/dev/sda" / filename "/dev/hda"
or
filename "/dev/sda1" / filename "/dev/sda1"

With hda && sda specifying the same disk device.

To make this work under LinuxBIOS I need to do the following things.
1) Move the code for booting an x86 bootsector into osloader.c
   So I can boot ELF image directly from disk.

2) Modify bootdisk to take a download_kernel parameter.  If
   only a stock x86 bootsector is present it will be used see 1.

3) Modify bootdisk to call my polled drivers.

For ISA devices with architecturally specified fixed I/O address a
fixed name makes sense. fd0 && fd1.  For devices like scsi which
are auto-detectable mapping to just something like disk0 makes some
sense.  For ide which is somewhere in the middle we can go either way
on the naming convention.

I am tempted to just change the convention to something like:
file:///floppy0/
file:///ide0/
file:///scsi0/
file:///bios_disk00/
file:///bios_disk80/

Or possibbly:
file:///floppy0/
file:///cd0/
file:///disk0/
Where we loose the ability to connect disks to drivers trivially,
and so we much enumerate the drivers when looking for them, so
this is a slower solution.

A third alternative is:
file:///floppy0/
file:///pci00:07.01/1/
file:///bios_disk00/
file:///bios_disk80/

With partitions information coming after the slash.  Perhaps,
file:///disk/parition/

And if we start supporting filesystems and I have seen solid 
arguments that filesystem code is small enough not to cause to many
problems we could continue the url as:
file:///disk/partition/fs/file 
or
file:///disk/partition/file
if we can auto-detect the fs type.

The URL syntax makes it obvious that we are overloading the contents
of the DHCP filename field.  Plus it makes the breaks in the kind of
data obvious.  Compactness of notation does suffer a little though.

Comments? Thoughts?

My goal is to get this working in the next day or two, and then in
July to setup some configuration alternatives besides DHCP.  And in
specifying boot order I really don't want to think of much besides:
removable-media, internal-media, network.

Eric

Re: [Etherboot-developers] Splashimage / Bootlogo

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

>Within a few days I will release mknbi-1.2.8pre1, which will contain an
>external menu program that has the code that does the menuing in
>Etherboot. In tests, the menu loaded instantly and all the initial text

What the heck, release early, at least before I have to go back to work
:-). It's in

	http://etherboot.sourceforge.net/mknbi-1.2-8rc1.tar.bz2

Note that it unpacks into mknbi-1.2 so hope you don't have an older
version in the target directory.

Re: AW: [Etherboot-developers] Splashimage / Bootlogo

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

>Sounds sane.  One thing I would like to do in conjunction with this
>is to figure out what we need to do to relocate etherboot.  Allowing
>arbitrary to be down loaded.  If you don't have to support callbacks
>this is trivial, with callbacks this becomes a more interesting
>challenge.

Nope, no callbacks are involved, only a return address and a returned
long in EAX.

>Mostly I think etherboot can be moved to the highest available address
>below 4G, with just a touch of care.  The challenges are keeping the
>overhead down, and still allowing dos BIOS calls.  Because that needs
>a small chunk below 1MB.

That'll be great.

Re: [Etherboot-developers] [RFC] Multicast reception....

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

"Anselm Martin Hoffmeister" <an...@ho...> writes:

> > To address that address that I am implemeting a reliable multicast
> > download protocol in etherboot.
> 
> How far have you got? I'm just working on something similar (not to grab you
> the price, it was your idea) and would like to save work.

I have a functioning client.  I still need to test multiple clients at
once and implement support in more NICs but the core work is done.
 
> > Transmitting multicast packets is trivial and I have completed the
> > implemetation in 10 lines of code.  Receiving multicast packets is
> > more interesting.
> 
> On hardware level, especially. This would have to be implemented for each
> card type on its own, if possible using the hardware filter.

Right.  Since most cards implement a filter for multicast packets opening
up that wide instead of to everything that promiscuous mode allows looks fine.
 
> > Implementing IGMP and filtering for multicast addresses we are waiting
> > for looks like about the same amount of work as ARP.
> 
> I was not concerned with arp. Let's assume - just for now - that we need no
> IGMP, as any client hangs on the same subnet as the multicasting server,
> which anyway sends its packets out to the first hardware network (doesn't
> it?)

Nope switches need IGMP.  Besides I already have it implemtned. :)
 
> > My understanding of the guts of NIC is limited, so please check me.  I
> > believe NICs have a hardware filter that allows them to receive just
> > broadcast packets, and packets to their own mac address.  So to
> > receive multicast packets I need open up or disable the filter all
> > together.  The simplest solution appears to be disabling the hardware
> > filter and go into promiscous mode, and then replace the hardware
> > filter with a software filter in await_reply.
> 
> That's quite right. But afaik it's not that much more work to implement the
> hardware filter with
> some cards (e.g. via-rhine seems to have one that is programmable easily) so
> one {you, me, we} should intend any code changes to implement the hardware
> filter as well- if the nic supports it.
> 
> As I learned from the packet driver specifiactions (somewhere at
> crynwr.com), there are different states a card can be in, listed (missing
> one? not sure)
> 1/ accept no input packets (not interesting for us)
> 2/ accept packets for our MAC-address
> 3/ like 2/ plus accept broadcast packets (standard etherboot modus?)
> 4/ like 3/ plus accept multicast packets to a list of mc. addresses
> 5/ like 3/ plus accept all multicast packets
> 6/ accept any packets travelling by
> 
> As you might have read already, multicast packets are addressed to special
> ethernet addresses (00:50:5f:xx:yy:zz or so, no docs at hand), leaving away
> the top 8 bit of the Multicast IP address. So in any case we need a filter
> to differentiate between multicast packets to 235.12.45.67 and 228.12.45.67.
> BTW, the developers seem to be not too sure wether the topmost bit of [xx]
> always has to be zero (so that 228.12.45.67 maps to the same MAC as
> 228.140.45.67).
> 
> Most (all?) cards seem to have support for mode 1, 2, 3, 6 so (in case)
> having no hardware filter is the general solution. Some cards (the more
> expensive ones like via-rhine :-) have at least support for mode 4 too,
> which is the most desirable.

And 5/ is even more common than 4/ from skimming the kernel.  Only very
old cards don't seem to have ti implemented.  That is what I think I
would like to make the new default etherboot mode.  For most
practicial purposes it is what we have today but it allows us to
receive multicast packets as well.

 > > Does anyone know if there is any communication between NICs and
> > switches about what a NIC is listening for that would make promiscous
> > mode a bad state to put NICs into?
> 
> Switches are dumb, aren't they? They forward (afaik) multicast and broadcast
> packets to any device connected. If they don't work with multicast, you're
> lost of course. My switch works fine (test yours with issuing a "route
> add -net 224.0.0.0 netmask 240.0.0.0 dev eth0" on two PCs on the switch and
> pinging to 224.0.0.1 - every packet should be dup'ed, no matter which host
> you ping from). As I see it, no packet may have a multicast address as
> originator - that would break the concepts of retransmission on that OSI
> level etc pp. So the switch will treat packets to the multicast MAC
> addresses like these where it doesn't know the port of the destination -
> just dump it to all ports.
> That is not always what you want, as too much multicast packets will fill
> the bandwith even of parts of your structured network where they are not
> needed. That's where routers are for!

But there are lots of various levels of inteligence in switches.  So a
smarter switch will sneak up to level 3 to do igmp to see where
multicast packets should go. 
 
> What I wanted to find out:
> Did you in the meantime implement the card driver multicast code
> portion?
For the eepro100 yes.  More to come.

> Let's make a standard for it, e.g. a function in the driver code for
> "listen_for_multicast (1=on, 0=off)" or even better the chance to listen for
> some addresses only... what the specific card driver makes out of it, no
> matter, a software filter is neccessary anyway and should be implemented
> *outside* the drivers (as it would be the same code in all of that
> drivers).

Unless someone can show me that listening for all multicast packets as
the come along is decidely bad.  I'm just going to turn it on by
default, and have a compile time option during the transition period.
Etherboot doesn't need super high performance drivers, just drivers
that are good enough.  And if a card really cares I guess it can spy
on the igmp table.  But I would be really suprised if that mattered.

> Let me know if you have - specifically - drivers for ne2k-isa (ns8390.[ch])
> and via-rhine (via-rhine.c) as these are the cards I'm working with.

Grep through the linux drivers for ALLMULTI it looks like a single
additional outb in most cases.

> AMD-home-pna stands on this list as the next, as that is the card vmware
> simulates and can be tested more easily - rebooting is more commode, and you
> don't need the second screen and keyboard. If you have any of those, less
> work for me, more honor for you - else I will take off my gloves and grab
> right into the dustiest code.

I will see if I can get my code checked in the next couple of hours so
you can see where I have gone.  No promises until tomorrow though.

Eric

Re: AW: [Etherboot-developers] Splashimage / Bootlogo

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

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

> >Since tftp'ing is relatively slow and most boot/splashscreens are not 
> >very complex graphics, i'd like to append, that boot/splashcreen-images
> >should/could be compressed. 
> 
> I should also add that I don't intend to develop this version of the
> external menu program very far. I will just make it resemble the
> internal menuing as far as possible and then any improvements are up to
> you hackers. My goal here is to remove crud from Etherboot.
> 
> The external program chaining mechanism is general and has been in
> Etherboot for over a year.  It's documented in the developers guide and
> there are comments in the sample program.  So you could start from
> scratch and create any fancy program you like. Lots of possibilities,
> use the mouse for input, animation, fractals, etc. etc.

Sounds sane.  One thing I would like to do in conjunction with this
is to figure out what we need to do to relocate etherboot.  Allowing
arbitrary to be down loaded.  If you don't have to support callbacks
this is trivial, with callbacks this becomes a more interesting
challenge.

Mostly I think etherboot can be moved to the highest available address
below 4G, with just a touch of care.  The challenges are keeping the
overhead down, and still allowing dos BIOS calls.  Because that needs
a small chunk below 1MB.

Eric

Re: [Etherboot-developers] Splashimage / Bootlogo

[Markus G. <ma...@gu...>]

Anselm Martin Hoffmeister wrote:
> Now it is, provided you can make your kernel boot completely without text 
> output. The only kernel nbi I have here insists on putting a string like 
> "Uncompressing kernel..." on the screen and complaining about my pci 
> subsystem although I supplied "quiet" as command line option. No matter, if 
> you can have a silent boot, an image can be displayed which will last until 
> the first process writes to console.

The "Uncompressing kernel" message is printed by 
linux/arch/i386/boot/compressed/misc.c (which happens before the code in 
linux/init/main.c enables quiet mode). Try taking out the "puts" statements and 
see if that addresses your problem. If it does, then you might want to write a 
patch that looks at the command line and disables the messages if "quiet" was 
passed as an option. I am sure, Ken would accept this patch in the "contrib" 
area of etherboot, and I wouldn't be surprised if Marcello and/or Linus were 
willing to introduce it into the main kernel.


Markus


-- 
Markus Gutschke
3637 Fillmore Street #106
San Francisco, CA 94123-1600
+1-415-567-8449
ma...@gu...

Re: [Etherboot-developers] Splashimage / Bootlogo

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

> I would prefer that effort was put into an external splash/menu program
> instead of patching Etherboot. The stuff inside bootmenu.c and ansiesc.c
> is ugly and hard to update as binaries are in boot ROMs.

Correct. I'd like that too, but as my site anyway uses chaining (etherboot
5.05 loads etherboot 5.06) - we burnt the roms before exactly knowing what
we wanted :-( - updating roms is not our problem.
I wanted to tell you about a not-to-difficult solution. Just dump it, that's
ok. It was a hint.

> Within a few days I will release mknbi-1.2.8pre1, which will contain an
> external menu program that has the code that does the menuing in
> Etherboot. In tests, the menu loaded instantly and all the initial text
> were cleared off. When control is handed back to Etherboot you get more
> loading messages,

What my patch could hinder Etherboot from.

>but in my opinion that's not to great a drawback.

It's an issue if you want the graphics to stay 'til X starts up; originally
I think that was the task.

> If it's an issue, some sort of VT switching might be devised so that the
> splash/logo remains on the screen. The main thing is a user-friendly
> screen and with an external program you are free of size limits on
> Etherboot, you have all of the lower 512kB if you wish.

At this point, it is probably much easier to user -DSILENTFORSPLASH (which
keeps any output after loading e.g. the menu.nbi from appearing) than
implementing VT switching - see, many old 386 consoles will happily run with
640x350x16, but there is not enough RAM on them to have a second console of
that format at hand. VESA will be no question if you want to display boot
graphics on these machines too.

> So I will not be accepting this patch as it will be obsoleted or at
> least be interfered with by developments on the external program.

But please keep it in mind, just in case!

> [...] and nested TFTP files [...]

Are not used here. I don't use any RAM neither (except the buffer from tftp,
but that is handled by the download code or ansiesc, not by my patch) as the
graphics is immediately output' to ansiesc.

No matter, if boot program does the image output, my patch would keep the
screen clear afterwards. And that's what <devzero>, who originated that
thread, asked for.

Anselm

AW: AW: [Etherboot-developers] Splashimage / Bootlogo

[devzero <de...@we...>]

Ken,
shure, i didn`t expect that YOU would do so.
But for me, it will be VERY difficult to do because I have not
very good experience in programming - so why not ask for that
feature, make people "think" about and perhaps find someone
with better skills who says: mhh, bootlogo? wait a minute....
:)
regards
Roland

PS:
gonna search for some demoscene-guys, they will go laughing and make
an mindblowing 3d boot-menu for us...... ;)

You really should give ftp://ftp.jp.scene.org/pub/demos/demos/1997/s/snc_omni.zip
a try. (The first level of well known game "descent" - squeezed into 4 KILOBYTES :)))






-----Ursprüngliche Nachricht-----
Von: eth...@li...
[mailto:eth...@li...]Im Auftrag von
Ken Yap
Gesendet: Sonntag, 9. Juni 2002 16:17
An: Etherboot developers list
Betreff: Re: AW: [Etherboot-developers] Splashimage / Bootlogo


>Since tftp'ing is relatively slow and most boot/splashscreens are not
>very complex graphics, i'd like to append, that boot/splashcreen-images
>should/could be compressed.

I should also add that I don't intend to develop this version of the
external menu program very far. I will just make it resemble the
internal menuing as far as possible and then any improvements are up to
you hackers. My goal here is to remove crud from Etherboot.

The external program chaining mechanism is general and has been in
Etherboot for over a year.  It's documented in the developers guide and
there are comments in the sample program.  So you could start from
scratch and create any fancy program you like. Lots of possibilities,
use the mouse for input, animation, fractals, etc. etc.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

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

Re: AW: [Etherboot-developers] Splashimage / Bootlogo

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

>Since tftp'ing is relatively slow and most boot/splashscreens are not 
>very complex graphics, i'd like to append, that boot/splashcreen-images
>should/could be compressed. 

I should also add that I don't intend to develop this version of the
external menu program very far. I will just make it resemble the
internal menuing as far as possible and then any improvements are up to
you hackers. My goal here is to remove crud from Etherboot.

The external program chaining mechanism is general and has been in
Etherboot for over a year.  It's documented in the developers guide and
there are comments in the sample program.  So you could start from
scratch and create any fancy program you like. Lots of possibilities,
use the mouse for input, animation, fractals, etc. etc.

AW: [Etherboot-developers] Splashimage / Bootlogo

[devzero <de...@we...>]

Hello developers, 
many thanks for putting effort in this feature.
I also think, that ken's approach by moving menu-code "extern" is good.

Since tftp'ing is relatively slow and most boot/splashscreens are not 
very complex graphics, i'd like to append, that boot/splashcreen-images
should/could be compressed. 

maybe, grub gives some hints here:
http://hints.linuxfromscratch.org/hints/grub-howto.txt
http://linuxfromscratch.org/~gerard/
http://mail.gnu.org/pipermail/bug-grub/2002-March/006808.html
http://rpmfind.net/linux/RPM/PLD/dists/ra/PLD/i386/PLD/RPMS/grub-0.91-6.i386.html
 
Actually, using gzipped xpm`s as bootlogo in GRUB works.
regards
Roland

PS:
i have attached a (btw very nice!) sample xpm, which is ~8K compressed
and ~300K uncompressed - just to see, what`s possible.


------------------------------------------------------------------------
Mail from Ken Yap
>I just used ansiesc, which is inside etherboot.
>You can download the .diff file and an example ansi graphics file from
>  http://feldhausnetz.de/splash.tar.gz
>Then enable option -DSILENTFORSPLASH

I would prefer that effort was put into an external splash/menu program
instead of patching Etherboot. The stuff inside bootmenu.c and ansiesc.c
is ugly and hard to update as binaries are in boot ROMs.

Within a few days I will release mknbi-1.2.8pre1, which will contain an
external menu program that has the code that does the menuing in
Etherboot. In tests, the menu loaded instantly and all the initial text
were cleared off. When control is handed back to Etherboot you get more
loading messages, but in my opinion that's not to great a drawback. If
it's an issue, some sort of VT switching might be devised so that the
splash/logo remains on the screen. The main thing is a user-friendly
screen and with an external program you are free of size limits on
Etherboot, you have all of the lower 512kB if you wish.

So I will not be accepting this patch as it will be obsoleted or at
least be interfered with by developments on the external program.

Two things that won't work in the external program: the server and
gateway arguments in the image specs (which I think are of little use),
and nested TFTP files (which can be implemented instead by data in a
segment that accompanies the menu program).
-------------------------------------------------------------------------------------
Mail from Anselm Martin Hoffmeister
> >i'm looking for an option in etherboot that i can have
> > splashscreen/bootlogo when booting from the net.

Now it is, provided you can make your kernel boot completely without text 
output. The only kernel nbi I have here insists on putting a string like 
"Uncompressing kernel..." on the screen and complaining about my pci 
subsystem although I supplied "quiet" as command line option. No matter, if 
you can have a silent boot, an image can be displayed which will last until 
the first process writes to console.

> If you were a coder you could work on the chaining facikity that allows
> Etherboot to download a intermediate program which can display whatever
> it wants and then specify which image to load next and return to
> Etherboot. See mknbi-menu from the mknbi package.

I just used ansiesc, which is inside etherboot.
You can download the .diff file and an example ansi graphics file from
  http://feldhausnetz.de/splash.tar.gz
Then enable option -DSILENTFORSPLASH
and put an ansi graphics file so that tftp can reach it as /splash.ans
In that tar gz file, there is an example. If you want to disable it, just put 
a zero-size file to the same location as splash.ans (e.g. "rm splash.ans; 
touch splash.ans") or disable the -DSILENTFORSPLASH option in your config 
file.
Please tell me if it really works, as I said before, I cannot make my kernel 
really shut up.
BTW: I implemented this starting from a bare etherboot 5.0.6.
BTW2: Image size is still too much. This should become much better with a 
multicast downloading option. In development.


Documentation:
-DSILENTFORSPLASH
This option disables any etherboot-side output beginning at the moment the 
kernel download is started. Instead, it loads the file '/splash.ans' (from 
the same location it would load a kernel '/vmlinuz') and displays its 
contents. This option requires -DANSIESC and -DGFX to work properly.

Anselm

Re: [Etherboot-developers] Splashimage / Bootlogo

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

>I just used ansiesc, which is inside etherboot.
>You can download the .diff file and an example ansi graphics file from
>  http://feldhausnetz.de/splash.tar.gz
>Then enable option -DSILENTFORSPLASH

I would prefer that effort was put into an external splash/menu program
instead of patching Etherboot. The stuff inside bootmenu.c and ansiesc.c
is ugly and hard to update as binaries are in boot ROMs.

Within a few days I will release mknbi-1.2.8pre1, which will contain an
external menu program that has the code that does the menuing in
Etherboot. In tests, the menu loaded instantly and all the initial text
were cleared off. When control is handed back to Etherboot you get more
loading messages, but in my opinion that's not to great a drawback. If
it's an issue, some sort of VT switching might be devised so that the
splash/logo remains on the screen. The main thing is a user-friendly
screen and with an external program you are free of size limits on
Etherboot, you have all of the lower 512kB if you wish.

So I will not be accepting this patch as it will be obsoleted or at
least be interfered with by developments on the external program.

Two things that won't work in the external program: the server and
gateway arguments in the image specs (which I think are of little use),
and nested TFTP files (which can be implemented instead by data in a
segment that accompanies the menu program).

Re: [Etherboot-developers] Splashimage / Bootlogo

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

On Friday, 7. June 2002 23:46, Ken Yap wrote:
> >i'm looking for an option in etherboot that i can have
> > splashscreen/bootlogo when booting from the net.

Now it is, provided you can make your kernel boot completely without text 
output. The only kernel nbi I have here insists on putting a string like 
"Uncompressing kernel..." on the screen and complaining about my pci 
subsystem although I supplied "quiet" as command line option. No matter, if 
you can have a silent boot, an image can be displayed which will last until 
the first process writes to console.

> If you were a coder you could work on the chaining facikity that allows
> Etherboot to download a intermediate program which can display whatever
> it wants and then specify which image to load next and return to
> Etherboot. See mknbi-menu from the mknbi package.

I just used ansiesc, which is inside etherboot.
You can download the .diff file and an example ansi graphics file from
  http://feldhausnetz.de/splash.tar.gz
Then enable option -DSILENTFORSPLASH
and put an ansi graphics file so that tftp can reach it as /splash.ans
In that tar gz file, there is an example. If you want to disable it, just put 
a zero-size file to the same location as splash.ans (e.g. "rm splash.ans; 
touch splash.ans") or disable the -DSILENTFORSPLASH option in your config 
file.
Please tell me if it really works, as I said before, I cannot make my kernel 
really shut up.
BTW: I implemented this starting from a bare etherboot 5.0.6.
BTW2: Image size is still too much. This should become much better with a 
multicast downloading option. In development.


Documentation:
-DSILENTFORSPLASH
This option disables any etherboot-side output beginning at the moment the 
kernel download is started. Instead, it loads the file '/splash.ans' (from 
the same location it would load a kernel '/vmlinuz') and displays its 
contents. This option requires -DANSIESC and -DGFX to work properly.

Anselm