7/28/2014

PXE, iPXE macro problems


So porting of the code over to the iPXE code base was going really fast until I found the src/includes/ipxe/tables.h "Macro" library for defining __tables was redefined, and no longer accepted three parameters.

I'm still trying to grasp the significance of this while studying up on all the different ways a Macro can be used.

According to this (lots):

The C Preprocessor

Macros

A macro is a fragment of code which has been given a name. Whenever the name is used, it is replaced by the contents of the macro. There are two kinds of macros. They differ mostly in what they look like when they are used. Object-like macros resemble data objects when used, function-like macros resemble function calls.
So the Linker issue was a bad path to go down, it started in gPXE and the reason the table.h is different is probably not for that reason.

Both gPXE and iPXE however have some Doxygen Commenting in the code which can be used to generate documentation from the embedded doxygen comments.

# cd gPXE
# cd src
# make doc
# cd src/bin/doc/html
# firefox index.html

centos 5.9 only has doxygen 1.4.7-2 so it will not compile the 1.5.7.1 version of the latest iPXE doxygen.cfg

# wget ftp://ftp.stack.nl/pub/users/dimitri/doxygen-1.5.7.1.src.tar.gz
# tar -zxvf
# ./configure

# make install

# cd iPXE
# cd src
# make doc
# cd src/bin/doc/html
# firefox index.html

Etherboot documentation on how to write a driver (ancient)

Etherboot developers manual - one of the best

Another 2003 version of Etherboot Developers Manual

 iPXE page mostly criteria

Doxygen file for iPXE project

gPXE driver API documentation
Where do I start with developing a new driver?
Michael Decker's gPXE driver API documentation shows the interface that a driver must implement.
Study the code in gpxe/src/drivers/net. The rtl8139 and r8169 drivers are good examples. Note that some drivers are not written for the gPXE API but use a wrapper for the legacy Etherboot API instead. New drivers should use the gPXE API.
Linux Device Drivers is a good reference for understanding Linux drivers and learning general driver development concepts.
http://etherboot.org/wiki/appnotes
Slide show from a Course of Device Drivers

Related Links from Etherboot

http://netboot.sourceforge.net/english/index.shtml

MiT etherboot-4.4.5 info

netboot (packet driver days) -> etherboot (ISA probing days) -> gpxe -> ipxe

So end of the night.

As far as I can tell the old Etherboot criteria for a minimum of four or five functions stands, at least as legacy.c wrappered -- it looks like as time went on they kept adding requirements

The src/core/main.c file calls some init.c/h functions and starts up performs housekeeping and runs a "probe" function for each "linked in" driver to see if it detects its hardware. If it does it returns a structure with the mac address and other info and leaves the device in "ready to transmit" mode.

This is probably the opportunity to setup and start the USB bus, like the PCI bus, ect.. the latest iPXE seems to have a USB bus for storage devices.. I wonder if it will conflict, or be preferred since it must share the bus with storage and ethernet devices.
If they should share then it would make sense to adopt that USB communications provided for the EDD or storage bus and adapt the NIC-ish functions to that method. Otherwise two USB drivers for the same bus would not be good.  This tells me ipxe/src/drivers/net/rtl8139 and r8169 drivers might be good prototypes to study.. unless some legacy wrapping is going on to the new ipxe standard api.. whatever that might be.
The main loop then performs its other tasks and calls dhcp function which uses some tcp and network functions to "use" the netdevice to perform the communications.

I'm not entirely convinced the tables.h definition needs to be used by the driver code, it appears to be utility code to simplify things. Might be just as well to create second macro definition and use that, or embed what its trying to provide directly in the driver code.

Its really tough luck the two functions that won't compile are the "probe" functions for the detected hardware. They fillout or "sketch out" how to use the netdevice for the main routine.
Lots of confusion on my part, but in a vacuum it probably more efficient than doing nothing.
Posted by at