etherboot-developers — Discussion of developer issues

[Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

[Doug A. <amb...@wh...>]

FYI, when the "kernel" variable was changed this occurance was missed which
causes it to fail to compile.

Doug A.

*** osloader.c.orig	Wed Feb 21 12:41:03 2001
--- osloader.c	Wed Feb 21 12:41:29 2001
***************
*** 321,327 ****
  			info.bsdinfo.bi_extmem = memsize();
  			info.bsdinfo.bi_memsizes_valid = 1;
  			info.bsdinfo.bi_version = BOOTINFO_VERSION;
! 			info.bsdinfo.bi_kernelname = kernel;
  			info.bsdinfo.bi_nfs_diskless = NULL;
  			info.bsdinfo.bi_size = sizeof(info.bsdinfo);
  			(*entry)(freebsd_howto, NODEV, 0, 0, 0, &info.bsdinfo, 0, 0, 0);
--- 321,327 ----
  			info.bsdinfo.bi_extmem = memsize();
  			info.bsdinfo.bi_memsizes_valid = 1;
  			info.bsdinfo.bi_version = BOOTINFO_VERSION;
! 			info.bsdinfo.bi_kernelname = KERNEL_BUF;
  			info.bsdinfo.bi_nfs_diskless = NULL;
  			info.bsdinfo.bi_size = sizeof(info.bsdinfo);
  			(*entry)(freebsd_howto, NODEV, 0, 0, 0, &info.bsdinfo, 0, 0, 0);

[Etherboot-developers] Etherboot 4.7.20 (development) released

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

I have released Etherboot 4.7.20 at http://etherboot.sourceforge.net/

We can probably start the 5.0 release candidate countdown from .21 so
please give this a good workout. I'd like to work on the documentation
now so send in any patches you like to see to the text.

Innovations, sorry changes, in this release:

+ Donald Christensen completed the translation of loader.S and all the
other .S files in the src directory that previously required as86 or
nasm. No more futzing around with precompiled versions. Yipee!

+ Luigi Rizzo contributed a slightly hacked FreeBSD loader that works on
floppy or hard disk. See boot1a.s for details. Makefile rules edited.
Targets renamed .dsk and .lzdsk to indicate they're not floppy specific
now. Documentation updated. I note that the loader is smart enough to
figure out exactly how many sectors have to be read.

+ Renamed comload.S to comprefix.S which describes it better.

+ mknbi tools split out into separate package for independent
development.

+ Use A32 instead of Z32 in unpack format in disrom.pl in case we
encounter old Perl versions (< 5.005).

+ Vendor Class Identifier string that's sent out is now of the form
Etherboot-x.y (13 bytes long).

+ Reduced size of ee_data in davicom.c to 32 bytes because we only need
to access the MAC address in bytes 20:25.

+ Changed type of formal arguments to pci.[ch] routines to unsigned int
except for the last argument, because in ANSI C parameter passing is
like assignment and extra dummy variables and code may need to be
generated if the formal argument type is not the the same size as the
actual argument that gets pushed on the stack. Not insignificant
overhead, reduction from 1853 to 1727 bytes due to change. Changed devfn
and bus members of struct pci_device to unsigned char to enforce limit
on type. Surprisingly this reduced the size further to 1667 bytes.
Probably the compilier could do more optimisations after the last
change.

+ Some drivers hardwired 0 for bus number in calls to pcibios_*
functions. Changed to pci->bus, which is set in scan_bus. Only
people with NICs not on bus 0 would have noticed.

+ Found a couple more old-style pre-ANSI C function declarations. Turned
on -ansi and -pedantic for kicks and fixed some non-ANSIness, e.g.
// comment in #define, text after #endif, casting memcpy arguments to
void *, using void * instead of char *. Some char declarations changed
to unsigned char.

MD5 sums:

28b4d02424c79eb59de5300be8835e4b  etherboot-4.7.20.tar.bz2
017c064357241538b870557c5b94f679  etherboot-4.7.20.tar.gz

RE: [Etherboot-developers] why does scan_bus() in pci.c ....?

[Eno C. <Eno...@Mi...>]

On this we are in sync. I have done precisely as you suggest.
Eno

 -----Original Message-----
From: 	Ken Yap [mailto:ke...@nl...] 
Sent:	Monday, February 19, 2001 6:11 PM
To:	eth...@li...
Subject:	Re: [Etherboot-developers] why does scan_bus() in pci.c
....? 

|I am corrected. The fault is mine. It derives from my project requirement
to
|identify, not just the first, rather all the ethernet adapters on the bus.

What you probably want to do is pass an array of addresses and an array
PCI structures instead of just one, say limited to 2 or some compile
time constant. Then you can pass these arrays from the caller in
config.c.  (Etherboot has no support for heap allocation, keeps things
simple and avoids problems with memory allocation.) The number of
candidate NICs found can be indicated by terminating the pci_addr array
with a 0.

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

Re: [Etherboot-developers] Wake-on-LAN patch

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

I have not followed this discussion. But if there is a good code
and only the site specific address is a problem, then I have following
suggestion:
	The option can be enabled by this config file of the
built process (`Config'), and the MAC address *must* be given as
make variable in the built. The make has to stop with error, if
the variable is not set AND the option is selected, like

	make MAC_ADDR="xx:xx:xx:xx:xx:xx"

or whatever the MAC address should be to use it in the code....

Cheers
	Christoph P.



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



Markus Gutschke wrote:
> 
> > I'm not interested in incorporating the patch into the mainstream
> > because it requires that the MAC address of the server be hardwired into
> > the ROM, making the ROM very site specific.
> 
> I share Ken's sentiment about not making the ROM site-specific, but
> I think there is a workaround, that might be acceptable to some users.
> I have not been able to find an authoratitive specification for the
> Wake-On-Lan protocol, but it does appear that both broadcast and
> multicast packages are supported. How about sending broadcast packages
> from within etherboot, whenever we fail to detect a running BOOTP/DHCP
> server?
> 
> I guess, multicast requests would be even better, but not only does
> this seem to be a feature that only few NICs support, it is also not
> quite clear to me, how you'd set it up so that a particular NIC joins
> a multicast group. Also, which group should we use? Is there a
> standard? If not, how difficult is it these days to have IANA allocate
> a group for us?
> 
> Markus
> 
> --
> Markus Gutschke                                Resonate, Inc.
> 3637 Fillmore Street #106                      385 Moffett Park Drive
> San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
> +1-415-567-8449                                +1-408-548-5528
> ma...@gu...                            mgu...@re...
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Wake-on-LAN patch

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

|6) tulip.com is an etherboot .com file patched to search
|   ram for the block of memory placed there by the ipconf program.
|   Once it finds it, it constructs a dhcp reply packet in memory
|   and continues on, just as if it had received the packet from
|   the network server.

Change this to

|6) tulip.com is an etherboot .com file patched to call a BIOS service
|   to look for your flash data.
|   Once it finds it, it constructs a dhcp reply packet in memory
|   and continues on, just as if it had received the packet from
|   the network server.

What I'm saying is: don't patch Etherboot to search flash or whatever.
Rather, implement those services as new BIOS calls, then modify
Etherboot to make those calls. If those calls don't exist, then
Etherboot can proceed as normal. And it would work for .rom and .lzrom
ROM images too. Not everyone is willing to buy a 4 MB flash to boot from
.com files this way.  Encapsulating this capability in a BIOS call
allows for compatible solutions to the general problem posed by the TFTP
server and WOL extensions.

It's like the BIOS call to write a character to the console. Every BIOS
extension code could conceivably write directly to the video card.
Rather this is encapsulated in BIOS calls so that all programs can use
the service.

Re: [Etherboot-developers] Wake-on-LAN patch

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

Ken,

I'm not sure I understand what you've said.

Let me explain the boot process, maybe you didn't understand
me.

The flash disk appears as a ide disk.  I've loaded freedos on
it.

So,

1) Freedos boots up.
2) It runs the autoexec.bat file.
3) The autoexec.bat file runs my ipconf.exe program.
4) The ipconf.exe program looks for the data file containing
   the config info.
5) If it finds the config file, it reads the config info and
   constructs a block in memory. then calls the etherboot
   module.  Such as 'tulip.com' (depending on chipset).
6) tulip.com is an etherboot .com file patched to search
   ram for the block of memory placed there by the ipconf program.
   Once it finds it, it constructs a dhcp reply packet in memory
   and continues on, just as if it had received the packet from
   the network server.

If the config file isn't found, or if the user presses a key
sequence, they can get into the configuration screen, where they
can enter/edit any of the config info.

This would work exactly the same way, whether they used
a flash disk, hard disk, floppy disk, or presumably a DOC.

It's basically just a dos program (ipconf.exe) that executes
another dos program (tulip.com) which takes total control
of the system and sucks a kernel from the server.

Jim.

Ken Yap wrote:
> 
> |The patch to etherboot is a change only to main.c, to make it search
> |through ram, looking for the magic number and construct
> |the dhcp reply, rather than send a query.  I'll send you the patch
> |as soon as I get a chance to clean it up a little more.  I'd like for
> |it to be included in etherboot as a compile time option, but obviously,
> |that is up to you.
> 
> Excellent. One thing I would suggest is that rather than patch Etherboot
> to look for this ROM, this flash register itself as an extension BIOS
> and provide its services via BIOS calls (I'm sure you can find some
> suitable numbers). Etherboot (and any other software for that matter,
> can then test the existence of and access these services via BIOS calls,
> rather than hardwiring knowledge of this flash into the software. Then
> this BIOS call can be generalised for other non-volatile devices instead
> of having device specific code in every piece of software.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Wake-on-LAN patch

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

|The patch to etherboot is a change only to main.c, to make it search
|through ram, looking for the magic number and construct
|the dhcp reply, rather than send a query.  I'll send you the patch
|as soon as I get a chance to clean it up a little more.  I'd like for
|it to be included in etherboot as a compile time option, but obviously,
|that is up to you.

Excellent. One thing I would suggest is that rather than patch Etherboot
to look for this ROM, this flash register itself as an extension BIOS
and provide its services via BIOS calls (I'm sure you can find some
suitable numbers). Etherboot (and any other software for that matter,
can then test the existence of and access these services via BIOS calls,
rather than hardwiring knowledge of this flash into the software. Then
this BIOS call can be generalised for other non-volatile devices instead
of having device specific code in every piece of software.

Re: [Etherboot-developers] Wake-on-LAN patch

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

Ken,

I'll take you up on that challenge.

I've got a 4mb ide flash disk where I've loaded freedos and a
configuration program that I've written.

This config program allows a user to enter a whole slew of IP
information, including IP address, etherboot driver name, boot server,
kernel args and anything else that you can return in a bootp or
dhcp reply.  And, it also allows you to just say 'Use DHCP' and
not enter all of that info.

This information is then placed in memory, preceded by a magic
number and a checksum.

Then, the etherboot .com file is executed which will scan through
memory, looking for the magic number.  If it finds the magic, it
then calculates it's own idea of the checksum and compares it with
what was found.  Assuming it finds valid configuration info, it then
constructs a dhcp reply in memory and skips the call to send a dhcp
request.  At this point, it doesn't need to send a dhcp request, it
already has all of the info it needs. 

I've got it working pretty well, although there are still some
rough edges I'd like to clean up.

We call this little device the 'netAble'  and we'll be selling it
at DisklessWorkstations.Com.

The software is of coarse free.

This provides several things:

  1)  It plugs into the IDE header on the motherboard, and looks 
      just like a hard drive to the system.

  2)  For those sites that simply cannot setup a DHCP server,
      they can enter static info.

  3)  For network cards that don't have a bootrom socket, you can
      use this.

  4)  For motherboards with embedded NIC's and you don't want to,
      or can't flash the bios.

  5)  You can still use dhcp/bootp.  All you need to enter in the
      config screen is which etherboot driver to run.

  6)  Support for all of the etherboot supported chipsets.

  7)  Once Linux is running on the workstation, you can mount the
      flash disk as an ide hard drive and update it.  Or, you can
      dd a new image to it.

  8)  Instead of a flash disk, the code can be put on a floppy or
      hard drive if desired.  Some workstations already include a
      flash disk, which will also work.  (Iopener,ThinkNic)

The patch to etherboot is a change only to main.c, to make it search
through ram, looking for the magic number and construct
the dhcp reply, rather than send a query.  I'll send you the patch
as soon as I get a chance to clean it up a little more.  I'd like for
it to be included in etherboot as a compile time option, but obviously,
that is up to you.

The config program is written in C, using curses.  It's entirely
free software, and I'll either make it available on the ltsp site
or create a separate project on sourceforge for the config software.

One last issue I need to deal with is allowing a sysadmin to password
protect the config screen.

Also, based on the converstations today, I'd like to add the ability
to deal with wake-on-lan servers.

So, that's my response to your challenge.

Jim McQuillan
ja...@lt...

Ken Yap wrote:
> 
> Let me suggest a challenge to those developers who want to inject
> various pieces of information into Etherboot prior to the DHCP/BOOTP
> query (server MAC address, TFTP server address, whatever). Come up with
> a more elegant solution of where to store such information other than in
> the ROM code itself. Maybe there are hooks in modern BIOSes to store and
> recall user-defined information from the CMOS, I don't know.  Dedicated
> X-terminals (e.g. NCD, Labtam) had this advantage that there was storage
> for such info and could also rewrite this info from the BOOTP reply if
> the config said to do so.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Wake-on-LAN patch

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

Let me suggest a challenge to those developers who want to inject
various pieces of information into Etherboot prior to the DHCP/BOOTP
query (server MAC address, TFTP server address, whatever). Come up with
a more elegant solution of where to store such information other than in
the ROM code itself. Maybe there are hooks in modern BIOSes to store and
recall user-defined information from the CMOS, I don't know.  Dedicated
X-terminals (e.g. NCD, Labtam) had this advantage that there was storage
for such info and could also rewrite this info from the BOOTP reply if
the config said to do so.

Re: [Etherboot-developers] Wake-on-LAN patch

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

> Well, as I understand it, broadcast is only in the sense of the
> encapsulating packet. A WOL packet can be embedded in any type of
> packet, even non-IP packets.  However the WOL packet itself has to
> contain the MAC address of the targetted server. If it were not
> specified that way a broadcast WOL packet would wake up all sleeping
> servers on the network segment, whether you intended to or not.

For some users, that might be acceptable. It really depends on how
you set up your network. Also, a multicast packet (if we can figure
out how to set that up) would avoid the problem of waking up
everybody. Now, whether broadcasting and multicasting the WOL
information works is something that I cannot really tell without
access to the official documentation -- and probably testing whether
anybody bothers to implement the full specs. Intel's web site made
it sound as if their NICs could listen for broadcast WOL packets,
but didn't handle multicast. Again, all of this is only useful to
users who are in the (admittedly unusual) situation of wanting the
client to wake up the server. I think, offering the option of doing
this is interesting (either as a patch in contrib, or as part of the
official tree), but only if it can be done in a generic way. Consider
all of the above as me brainstorming about how to offer a generically
useful solution.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

RE: [Etherboot-developers] Flashing EB in BIOS with CBROM

[Wolf, P. <Wo...@Ul...>]

I was able to get EB working in the BIOS ROM, using CBROM124.exe I had =
to
load it at 4012:0000.  That is were PXE was loaded in the BIOS.

Thanks Ken and Christoph for your help.

Paul



-----Original Message-----
From: Ken Yap [mailto:ke...@nl...]
Sent: Thursday, February 15, 2001 9:44 PM
To: eth...@li...
Subject: Re: [Etherboot-developers] Flashing EB in BIOS with CBROM=20


|I am using 82559 EB, with Intel 810 chipset. I have everything working =
on
|Pro 100 Lan card with FLASH.=A0 I want to put EB in the BIOS flash so =
I can
|use the on board LAN controller but there is not enough room.=A0 Below =
is
|the original CBROM dump.=A0 I removed item 7. OEM0 CODE for 82559.026 =
to
|make space in the ROM.=A0 I flashed the new BIOS without the OEM0 and =
it
|works, then I put EB in 82559er.rom by following the Etherboot
|suggestions on the web site, which are install as /PCI 82559er.rom
|D000:0=A0 after flashing the BIOS is out-to-lunch no booting. Any =
ideas?

Try swapping the Device type IDs around in the ROM image using the
swapdevids.pl script in 4.7.19 to see if it makes any difference. =
(There
is an ambiguity in the original spec.) Also dump the info in the OEM =
and
the Etherboot image using disrom.pl, also in 4.7.19, and compare the
fields.

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

Re: [Etherboot-developers] why does scan_bus() in pci.c ....?

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

|I am corrected. The fault is mine. It derives from my project requirement to
|identify, not just the first, rather all the ethernet adapters on the bus.

What you probably want to do is pass an array of addresses and an array
PCI structures instead of just one, say limited to 2 or some compile
time constant. Then you can pass these arrays from the caller in
config.c.  (Etherboot has no support for heap allocation, keeps things
simple and avoids problems with memory allocation.) The number of
candidate NICs found can be indicated by terminating the pci_addr array
with a 0.

Re: [Etherboot-developers] Wake-on-LAN patch

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

|I share Ken's sentiment about not making the ROM site-specific, but
|I think there is a workaround, that might be acceptable to some users.
|I have not been able to find an authoratitive specification for the
|Wake-On-Lan protocol, but it does appear that both broadcast and
|multicast packages are supported. How about sending broadcast packages
|from within etherboot, whenever we fail to detect a running BOOTP/DHCP
|server?

Well, as I understand it, broadcast is only in the sense of the
encapsulating packet. A WOL packet can be embedded in any type of
packet, even non-IP packets.  However the WOL packet itself has to
contain the MAC address of the targetted server. If it were not
specified that way a broadcast WOL packet would wake up all sleeping
servers on the network segment, whether you intended to or not.

Re: [Etherboot-developers] Wake-on-LAN patch

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

> I'm not interested in incorporating the patch into the mainstream
> because it requires that the MAC address of the server be hardwired into
> the ROM, making the ROM very site specific.

I share Ken's sentiment about not making the ROM site-specific, but
I think there is a workaround, that might be acceptable to some users.
I have not been able to find an authoratitive specification for the
Wake-On-Lan protocol, but it does appear that both broadcast and
multicast packages are supported. How about sending broadcast packages
from within etherboot, whenever we fail to detect a running BOOTP/DHCP
server?

I guess, multicast requests would be even better, but not only does
this seem to be a feature that only few NICs support, it is also not
quite clear to me, how you'd set it up so that a particular NIC joins
a multicast group. Also, which group should we use? Is there a
standard? If not, how difficult is it these days to have IANA allocate
a group for us?


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

Re: [Etherboot-developers] Wake-on-LAN patch

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

|please find enclosed a patch to optionally enable etherboot to start the 
|server it is booting from by sending a magic wake-on-lan packet to the 
|sleeping server first.
|
|Are the authors of etherboot willing to accept this patch for inclusion? 
|Please note, that the wake-on-lan code is only compiled in, when setting 
|appropriate flags in src/Config.
|
|If you don't want to include the patch, should I change anything of the 
|implementation or do you dislike the idea at all?

I'm not interested in incorporating the patch into the mainstream
because it requires that the MAC address of the server be hardwired into
the ROM, making the ROM very site specific. However I will put it into
the contrib section and you can handle all questions about it. Better
still, if you could put it on your web site, if you have one, I can put
a link from the docs, and you can update your patch as you wish.

[Etherboot-developers] Wake-on-LAN patch

[Tilmann B. <bu...@th...>]

Hello!

please find enclosed a patch to optionally enable etherboot to start the 
server it is booting from by sending a magic wake-on-lan packet to the 
sleeping server first.

This is very important for an etherboot-server, which is not running all the 
time and is not easily accessible from the etherboot machine (e.g. because it 
is installed in the basement of the house and one must climb several stairs to 
switch the server on...)

Are the authors of etherboot willing to accept this patch for inclusion? 
Please note, that the wake-on-lan code is only compiled in, when setting 
appropriate flags in src/Config.

If you don't want to include the patch, should I change anything of the 
implementation or do you dislike the idea at all?
 
Thanks!
   Till

+-------+--------------------------------------------------------------+
|       | dr. tilmann bubeck               think@work it consulting    |
|       |                                  professional services       |
| think | cell.: +49 172 8842972           widmaierstrasse 58          |
| @work | fax  : +49 711 7227734           70567 stuttgart             |
|       | email: bu...@th...   http://www.think-at-work.de |
+-------+ -------------------------------------------------------------+

RE: [Etherboot-developers] why does scan_bus() in pci.c ....?

[Eno C. <Eno...@Mi...>]

I am corrected. The fault is mine. It derives from my project requirement to
identify, not just the first, rather all the ethernet adapters on the bus.

Thanks
Eno

 -----Original Message-----
From: 	Ken Yap [mailto:ke...@nl...] 
Sent:	Saturday, February 17, 2001 2:38 AM
To:	eth...@li...
Subject:	Re: [Etherboot-developers] why does scan_bus() in pci.c
....? 

>4. clears the least significant two bits from the i/o space base address,
>and
>5. reads base address double word 1 into a cell called membase, and
>6. reads the rom base address double word into a cell called romaddr, and
>7. continues with some other stuff that isn't germane to this topic, and
>8. CONTINUES WITH THE LOOP
>
>This last step confuses me. Am I missing something about how pci works?
>Ought not the code break from the loop when it has detected the address
data
>it needs to access the device?

Where do you see that it continues with the loop? The comment indicates
that the test is to "take first one or if ROM address matches". So if a
candidate has not been previously found, as indicated by pci_ioaddr ==
0, it assigns information to the structure and then RETURNS from the
function, thereby exiting all loops. In practice it seems that the ROM
address is not what one expects it to be so the second condition is
never true. But it does return after finding the first one. For your
purposes you probably want it to continue enumerating all candidates.

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

[Etherboot-developers] Fallback tftp-server (patch)

[Hannu M. <mar...@pe...>]

Hei,

Here is a patch (against etherboot-4.7.19), which adds option for
overriding the tftp-server address (from bootp/dhcp).

It is very simple change and works well for me.

This is usefull for testing and (large) environments where you don't have
access to dhcp/bootp-servers. You can use the same option in environments
where you really want to specify the TFTP-server, no matter what the
dhcp/bootp servers says (security).

- Goodi
"The linuX Files -- The Source is Out There."
=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=
=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8=A4=BA=B0`=B0=
=BA=A4=F8,=B8=B8,=F8=A4=BA=B0

Re: [Etherboot-developers] a new boot sector for rom images which works from hard disks

[Luigi R. <ri...@ac...>]

> On 2/17/2001 10:17 PM Luigi Rizzo ri...@ac... wrote:
> >While i have your attention -- how much work do you think it is
> >necessary to remove the dependency on nasm and let the code compile
> >just using the standard assembler (as i believe ?) which comes with
> >FreeBSD/Linux/cygnus tools for windows ?
> >Is it just a matter of replacing the .S files with equivalent ones
> >in gcc syntax in case hey are not yet ?
> 
> It's funny you should mention that.  Someone recently contributed 
> translations that do this.  I think we would certainly like to get rid of 
> the remaining dependencies on NASM/AS86, and I imagine the translation 
> will be aided by having an example. So my guess is that we're close to 
> this goal.

ok so here is my contribution for comload.s ...

	cheers
	luigi

# as comload.s -o comload.o
# ld -Ttext 0 -o comload.out comload.o
# objcopy -S -O binary comload.out comload

	.text
	.globl _start
	.code16

# Cheat a little with the relocations: .COM files are loaded at 0x100
_start:
	pushw	%cs			# generate return address
	movw	$retaddr + 0x100, %ax
	pushw	%ax

# Intel didn''t specify an indirect far call that loads the address from
# a near operand - it seems like nobody does computed far calls.  So do it
# the ugly way - dump it on the stack and "return" to the destination.

	movw	%cs, %ax		# calculate start address of loader
	movw	$_body + 0x100, %bx
	movb	$4, %cl
	shrw	%cl, %bx
	addw	%bx, %ax
	pushw	%ax			# new code segment
	movw	$6, %ax
	pushw	%ax			# new offset

	lret
retaddr:
	int	$0x19			# should never reach this

	.align 16, 0
_body:

Re: [Etherboot-developers] a new boot sector for rom images which works from hard disks

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

On 2/17/2001 10:17 PM Luigi Rizzo ri...@ac... wrote:
>While i have your attention -- how much work do you think it is
>necessary to remove the dependency on nasm and let the code compile
>just using the standard assembler (as i believe ?) which comes with
>FreeBSD/Linux/cygnus tools for windows ?
>Is it just a matter of replacing the .S files with equivalent ones
>in gcc syntax in case hey are not yet ?

It's funny you should mention that.  Someone recently contributed 
translations that do this.  I think we would certainly like to get rid of 
the remaining dependencies on NASM/AS86, and I imagine the translation 
will be aided by having an example. So my guess is that we're close to 
this goal.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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] a new boot sector for rom images which works from hard disks

[Luigi R. <ri...@ac...>]

> >floppyload.S does not do the job. With a bit of hacking to
> >the FreeBSD's boot1.s code, i managed to obtain a boot sector
> >which works both for floppies and hard disks
> 
> Luigi, this is great!  Thanks so much for doing this.  There have been a 

glad you find it useful.

While i have your attention -- how much work do you think it is
necessary to remove the dependency on nasm and let the code compile
just using the standard assembler (as i believe ?) which comes with
FreeBSD/Linux/cygnus tools for windows ?

Is it just a matter of replacing the .S files with equivalent ones
in gcc syntax in case hey are not yet ?

	cheers
	luigi

> lot of people asking about how to use compact flash based IDE drives to 
> boot Etherboot, and this would work really nicely for that, and the 
> ability to use a single file for either floppy or hd loading means people 
> don't have to do SYSLINUX or LILO if they don't need them.  This is sweet.
> 
> Regards,
> 
> Marty
> 
> ---
>     Try: http://rom-o-matic.net/ to make Etherboot images instantly.
> 
>    Name: Martin D. 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] a new boot sector for rom images which works from hard disks

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

On 2/17/2001 8:49 AM Luigi Rizzo ri...@ac... wrote:
>i recently had the problem of downloading the etherboot code
>from a hard disk partition instead of a floppy, and noticed that
>floppyload.S does not do the job. With a bit of hacking to
>the FreeBSD's boot1.s code, i managed to obtain a boot sector
>which works both for floppies and hard disks

Luigi, this is great!  Thanks so much for doing this.  There have been a 
lot of people asking about how to use compact flash based IDE drives to 
boot Etherboot, and this would work really nicely for that, and the 
ability to use a single file for either floppy or hd loading means people 
don't have to do SYSLINUX or LILO if they don't need them.  This is sweet.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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] a new boot sector for rom images which works from hard disks

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

Luigi,

Thanks for that great contribution, I'll give it a whirl.

>one thing -- what execution environment (in term of register content
>and machine status) do .rom/.lzrom image expect ? I just guessed
>something looking at floppyloader.S, but am not 100% sure...

Nothing special, CS = bootrom image segment, IP = 6, real mode. What you
have looks ok.

[Etherboot-developers] a new boot sector for rom images which works from hard disks

[Luigi R. <ri...@ac...>]

Hello,

i recently had the problem of downloading the etherboot code
from a hard disk partition instead of a floppy, and noticed that
floppyload.S does not do the job. With a bit of hacking to
the FreeBSD's boot1.s code, i managed to obtain a boot sector
which works both for floppies and hard disks -- basically you
do something like

	cat boot1a bin32/<yourcard>.lzrom > /dev/ad0s4

(or whatever is the HD partition you are using, i am using slice
4 on FreeBSD) and you are up and running.
Then with "fdisk" you have to mark your partition as having type "1"
(which is listed as DOS-- but basically it must be something matching
the variable PRT_BSD in the assembly source below).

I am trying to make this code go into the freebsd tree, however
it might be of some use to other etherboot users as well, so
feel free to test and use it. The modified boot1.s is attached,
you will see that the diffs from the standard boot1.s code in
FreeBSD are very small.

one thing -- what execution environment (in term of register content
and machine status) do .rom/.lzrom image expect ? I just guessed
something looking at floppyloader.S, but am not 100% sure...

	cheers
	luigi

----------------------------------+-----------------------------------------
 Luigi RIZZO, lu...@ie...  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

#
# Copyright (c) 1998 Robert Nordier
# All rights reserved.
# Very small bootrom changes by Luigi Rizzo
#
# Redistribution and use in source and binary forms are freely
# permitted provided that the above copyright notice and this
# paragraph and the following disclaimer are duplicated in all
# such forms.
#
# This software is provided "AS IS" and without any express or
# implied warranties, including, without limitation, the implied
# warranties of merchantability and fitness for a particular
# purpose.
#
# Makefile:
#boot1a: boot1a.out
#	objcopy -S -O binary boot1a.out boot1a
#
#boot1a.out: boot1a.o
#	ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1a.out} boot1a.o
#
#boot1a.o: boot1a.s
#	as --defsym FLAGS=0x80 boot1a.s -o boot1a.o
#
#

# $FreeBSD: src/sys/boot/i386/boot2/boot1.s,v 1.10.2.2 2000/07/07 21:12:32 jhb Exp $

# Memory Locations
		.set MEM_REL,0x700		# Relocation address
		.set MEM_ARG,0x900		# Arguments
		.set MEM_ORG,0x7c00		# Origin
		.set MEM_BUF,0x8c00		# Load area
		.set MEM_BTX,0x9000		# BTX start
		.set MEM_JMP,0x9010		# BTX entry point
		.set MEM_USR,0xa000		# Client start
		.set BDA_BOOT,0x472		# Boot howto flag
	
# Partition Constants 
		.set PRT_OFF,0x1be		# Partition offset
		.set PRT_NUM,0x4		# Partitions
		.set PRT_BSD,0x1		# Partition type

# Flag Bits
		.set FL_PACKET,0x80		# Packet mode

# Misc. Constants
		.set SIZ_PAG,0x1000		# Page size
		.set SIZ_SEC,0x200		# Sector size

		.globl start
		.globl xread
		.code16

start:		jmp main			# Start recognizably

		.org 0x4,0x90
# 
# Trampoline used by boot2 to call read to read data from the disk via
# the BIOS.  Call with:
#
# %cx:%ax	- long    - LBA to read in
# %es:(%bx)	- caddr_t - buffer to read data into
# %dl		- byte    - drive to read from
# %dh		- byte    - num sectors to read
# 

xread:		push %ss			# Address
		pop %ds				#  data
#
# Setup an EDD disk packet and pass it to read
# 
xread.1:					# Starting
		pushl $0x0			#  absolute
		push %cx			#  block
		push %ax			#  number
		push %es			# Address of
		push %bx			#  transfer buffer
		xor %ax,%ax			# Number of
		movb %dh,%al			#  blocks to
		push %ax			#  transfer
		push $0x10			# Size of packet
		mov %sp,%bp			# Packet pointer
		callw read			# Read from disk
		lea 0x10(%bp),%sp		# Clear stack
		lret				# To far caller
# 
# Load the rest of boot2 and BTX up, copy the parts to the right locations,
# and start it all up.
#

#
# Setup the segment registers to flat addressing (segment 0) and setup the
# stack to end just below the start of our code.
# 
main:		cld				# String ops inc
		xor %cx,%cx			# Zero
		mov %cx,%es			# Address
		mov %cx,%ds			#  data
		mov %cx,%ss			# Set up
		mov $start,%sp			#  stack
#
# Relocate ourself to MEM_REL.  Since %cx == 0, the inc %ch sets
# %cx == 0x100.
# 
		mov %sp,%si			# Source
		mov $MEM_REL,%di		# Destination
		incb %ch			# Word count
		rep				# Copy
		movsw				#  code
#
# If we are on a hard drive, then load the MBR and look for the first
# FreeBSD slice.  We use the fake partition entry below that points to
# the MBR when we call nread.  The first pass looks for the first active
# FreeBSD slice.  The second pass looks for the first non-active FreeBSD
# slice if the first one fails.
# 
		mov $part4,%si			# Partition
		cmpb $0x80,%dl			# Hard drive?
		jb main.4			# No
		movb $0x1,%dh			# Block count
		callw nread			# Read MBR
		mov $0x1,%cx	 		# Two passes
main.1: 	mov $MEM_BUF+PRT_OFF,%si	# Partition table
		movb $0x1,%dh			# Partition
main.2: 	cmpb $PRT_BSD,0x4(%si)		# Our partition type?
		jne main.3			# No
		jcxz main.5			# If second pass
		testb $0x80,(%si)		# Active?
		jnz main.5			# Yes
main.3: 	add $0x10,%si	 		# Next entry
		incb %dh			# Partition
		cmpb $0x1+PRT_NUM,%dh		# In table?
		jb main.2			# Yes
		dec %cx				# Do two
		jcxz main.1			#  passes
#
# If we get here, we didn't find any FreeBSD slices at all, so print an
# error message and die.
# 
		mov $msg_part,%si		# Message
		jmp error			# Error
#
# Floppies use partition 0 of drive 0.
# 
main.4: 	xor %dx,%dx			# Partition:drive
#
# Ok, we have a slice and drive in %dx now, so use that to locate and load
# boot2.  %si references the start of the slice we are looking for, so go
# ahead and load up the first 16 sectors (boot1 + boot2) from that.  When
# we read it in, we conveniently use 0x8c00 as our transfer buffer.  Thus,
# boot1 ends up at 0x8c00, and boot2 starts at 0x8c00 + 0x200 = 0x8e00.
# The first part of boot2 is the disklabel, which is 0x200 bytes long.
# The second part is BTX, which is thus loaded into 0x9000, which is where
# it also runs from.  The boot2.bin binary starts right after the end of
# BTX, so we have to figure out where the start of it is and then move the
# binary to 0xb000.  Normally, BTX clients start at MEM_USR, or 0xa000, but
# when we use btxld create boot2, we use an entry point of 0x1000.  That
# entry point is relative to MEM_USR; thus boot2.bin starts at 0xb000.
# 
main.5:		mov %dx,MEM_ARG			# Save args
		movb $0x10,%dh			# Sector count
		callw nread			# Read disk
		cmpw $0xaa55, MEM_BUF+0x200	# rom signature ?
		jnz load_btx
		movb MEM_BUF+0x202,%dh		# Sector count
		incb %dh
		mov $0x7e00, %bx
		callw nreadbx			# Read disk
		ljmp $0x800,$6			# enter the rom code

load_btx:
		mov $MEM_BTX,%bx		# BTX
		mov 0xa(%bx),%si		# Get BTX length and set
		add %bx,%si			#  %si to start of boot2.bin
		mov $MEM_USR+SIZ_PAG,%di	# Client page 1
		mov $MEM_BTX+0xe*SIZ_SEC,%cx	# Byte
		sub %si,%cx			#  count
		rep				# Relocate
		movsb				#  client
		sub %di,%cx			# Byte count
		xorb %al,%al			# Zero assumed bss from
		rep				#  the end of boot2.bin
		stosb				#  up to 0x10000
		callw seta20			# Enable A20
		jmp start+MEM_JMP-MEM_ORG	# Start BTX
# 
# Enable A20 so we can access memory above 1 meg.
# 
seta20: 	cli				# Disable interrupts
seta20.1:	inb $0x64,%al			# Get status
		testb $0x2,%al			# Busy?
		jnz seta20.1			# Yes
		movb $0xd1,%al			# Command: Write
		outb %al,$0x64			#  output port
seta20.2:	inb $0x64,%al			# Get status
		testb $0x2,%al			# Busy?
		jnz seta20.2			# Yes
		movb $0xdf,%al			# Enable
		outb %al,$0x60			#  A20
		sti				# Enable interrupts
		retw				# To caller
# 
# Trampoline used to call read from within boot1.
# 
nread:		mov $MEM_BUF,%bx		# Transfer buffer
nreadbx:					# same but address is in bx
		mov 0x8(%si),%ax		# Get
		mov 0xa(%si),%cx		#  LBA
		push %cs			# Read from
		callw xread.1	 		#  disk
		jnc return			# If success, return
		mov $msg_read,%si		# Otherwise, set the error
						#  message and fall through to
						#  the error routine
# 
# Print out the error message pointed to by %ds:(%si) followed
# by a prompt, wait for a keypress, and then reboot the machine.
# 
error:		callw putstr			# Display message
		mov $prompt,%si			# Display
		callw putstr			#  prompt
		xorb %ah,%ah			# BIOS: Get
		int $0x16			#  keypress
		movw $0x1234, BDA_BOOT		# Do a warm boot
		ljmp $0xffff,$0x0		# reboot the machine
# 
# Display a null-terminated string using the BIOS output.
# 
putstr.0:	mov $0x7,%bx	 		# Page:attribute
		movb $0xe,%ah			# BIOS: Display
		int $0x10			#  character
putstr: 	lodsb				# Get char
		testb %al,%al			# End of string?
		jne putstr.0			# No

#
# Overused return code.  ereturn is used to return an error from the
# read function.  Since we assume putstr succeeds, we (ab)use the
# same code when we return from putstr. 
# 
ereturn:	movb $0x1,%ah			# Invalid
		stc				#  argument
return: 	retw				# To caller
# 
# Reads sectors from the disk.  If EDD is enabled, then check if it is
# installed and use it if it is.  If it is not installed or not enabled, then
# fall back to using CHS.  Since we use a LBA, if we are using CHS, we have to
# fetch the drive parameters from the BIOS and divide it out ourselves.
# Call with:
#
# %dl	- byte     - drive number
# stack - 10 bytes - EDD Packet
#
read:	 	push %dx			# Save
		movb $0x8,%ah			# BIOS: Get drive
		int $0x13			#  parameters
		movb %dh,%ch			# Max head number
		pop %dx				# Restore
		jc return			# If error
		andb $0x3f,%cl			# Sectors per track
		jz ereturn			# If zero
		cli				# Disable interrupts
		mov 0x8(%bp),%eax		# Get LBA
		push %dx			# Save
		movzbl %cl,%ebx			# Divide by
		xor %edx,%edx			#  sectors
		div %ebx			#  per track
		movb %ch,%bl			# Max head number
		movb %dl,%ch			# Sector number
		inc %bx				# Divide by
		xorb %dl,%dl			#  number
		div %ebx			#  of heads
		movb %dl,%bh			# Head number
		pop %dx				# Restore
		cmpl $0x3ff,%eax		# Cylinder number supportable?
		sti				# Enable interrupts
		ja read.7			# No, try EDD
		xchgb %al,%ah			# Set up cylinder
		rorb $0x2,%al			#  number
		orb %ch,%al			# Merge
		inc %ax				#  sector
		xchg %ax,%cx	 		#  number
		movb %bh,%dh			# Head number
		subb %ah,%al			# Sectors this track
		mov 0x2(%bp),%ah		# Blocks to read
		cmpb %ah,%al			# To read
		jb read.2			#  this
		movb %ah,%al			#  track
read.2: 	mov $0x5,%di	 		# Try count
read.3: 	les 0x4(%bp),%bx		# Transfer buffer
		push %ax			# Save
		movb $0x2,%ah			# BIOS: Read
		int $0x13			#  from disk
		pop %bx				# Restore
		jnc read.4			# If success
		dec %di				# Retry?
		jz read.6			# No
		xorb %ah,%ah			# BIOS: Reset
		int $0x13			#  disk system
		xchg %bx,%ax	 		# Block count
		jmp read.3			# Continue
read.4: 	movzbw %bl,%ax	 		# Sectors read
		add %ax,0x8(%bp)		# Adjust
		jnc read.5			#  LBA,
		incw 0xa(%bp)	 		#  transfer
read.5: 	shlb %bl			#  buffer
		add %bl,0x5(%bp)		#  pointer,
		sub %al,0x2(%bp)		#  block count
		ja read				# If not done
read.6: 	retw				# To caller
read.7:		testb $FL_PACKET,%cs:MEM_REL+flags-start # LBA support enabled?
		jz ereturn			# No, so return an error
		mov $0x55aa,%bx			# Magic
		push %dx			# Save
		movb $0x41,%ah			# BIOS: Check
		int $0x13			#  extensions present
		pop %dx				# Restore
		jc return			# If error, return an error
		cmp $0xaa55,%bx			# Magic?
		jne ereturn			# No, so return an error
		testb $0x1,%cl			# Packet interface?
		jz ereturn			# No, so return an error
		mov %bp,%si			# Disk packet
		movb $0x42,%ah			# BIOS: Extended
		int $0x13			#  read
		retw				# To caller

# Messages

msg_read:	.asciz "Read"
msg_part:	.asciz "Boot"

prompt: 	.asciz " error\r\n"

flags:		.byte FLAGS			# Flags

		.org PRT_OFF,0x90

# Partition table

		.fill 0x30,0x1,0x0
part4:		.byte 0x80
		.byte 0x00	# start head
		.byte 0x01	# start sector (6 bits) + start cyl (2 bit)
		.byte 0x00	# start cyl (low 8 bits)
		.byte 0x1	# part.type
		.byte 0xff	# end head
		.byte 0xff	# end sect (6) + end_cyl(2)
		.byte 0xff	# end cyl
		.byte 0x00, 0x00, 0x00, 0x00	# explicit start
		.byte 0x50, 0xc3, 0x00, 0x00	# 50000 sectors long, bleh

		.word 0xaa55			# Magic number

Re: [Etherboot-developers] why does scan_bus() in pci.c ....?

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

>4. clears the least significant two bits from the i/o space base address,
>and
>5. reads base address double word 1 into a cell called membase, and
>6. reads the rom base address double word into a cell called romaddr, and
>7. continues with some other stuff that isn't germane to this topic, and
>8. CONTINUES WITH THE LOOP
>
>This last step confuses me. Am I missing something about how pci works?
>Ought not the code break from the loop when it has detected the address data
>it needs to access the device?

Where do you see that it continues with the loop? The comment indicates
that the test is to "take first one or if ROM address matches". So if a
candidate has not been previously found, as indicated by pci_ioaddr ==
0, it assigns information to the structure and then RETURNS from the
function, thereby exiting all loops. In practice it seems that the ROM
address is not what one expects it to be so the second condition is
never true. But it does return after finding the first one. For your
purposes you probably want it to continue enumerating all candidates.