Task: U-Boot Ethernet driver conversion

Task:

U-Boot commit ecf1d2741d95 ("net: Remove smc91111 ethernet driver") removed an Ethernet driver from the U-Boot tree, on the grounds that it did no longer comply with the U-Boot standard for Ethernet drivers, which requires to implement them according to the U-Boot newer driver model (DM_ETH).

Bring that driver back into the U-Boot source tree, and convert it to the new driver model. The platform specific data should be taken from the devicetree supplied to U-Boot at runtime. Make the driver compile for the "vexpress_aemv8a_semi" U-Boot platform. Create a patch series out of that work and send it via email to andre.przywara@arm.com , cc Hemendra.dassanayake@arm.com, using the U-Boot/Linux kernel email based contribution process (please don't send it to mailing list). We are looking for a cover letter, meaningful commit messages and code as one would expect in an actual submission.

You can reach out to Andre for technical questions, either via email or via IRC, "apritzel" at OFTC and Libera.

Background:

The Arm FVP is a software model that emulates multiple Arm CPU cores alongside the required system IP like an interconnect, timers and a GIC interrupt controller. It also emulates several platform peripherals like UARTs, SD card controllers and a network interface. The latter is modelled after an SMSC 91C111 network chip. The U-Boot bootloader for the Arm FVP used to have a driver for this network chip, which was controlled and initialised using build time variables, set in header files or in Kconfig variables. About a decade ago U-Boot introduced a newer "driver model" (DM), which mostly does away with build time configuration, and introduces a common and more modern way to find, enumerate and initialise devices and their associated drivers. It takes some inspirations from the Linux driver model, but differs significantly in some areas. Since the U-Boot SMC 91C111 driver was never converted to use the driver model, and the very generous conversion deadline passed, the driver was removed from the tree.

While modern FVP models employ a virtio based network device, which is generally preferable over the emulation of that legacy Ethernet chip, it would be good to have that driver back, to support older FVPs and to have a second or alternative Ethernet interface.

Limitations:

To not unnecessarily complicate this task, it is not required to actually make the driver fully work. Testing on the FVP software model is possible, but complex, and NOT REQUIRED FOR THIS EXERCISE. However, it should compile without warnings, though, and the code should be in roughly the correct shape. There is no need to support every feature of the device, especially any EEPROM related code can be disabled or removed for now. Also the MAC address programming can be basic, or even only sketched out. Focus on the basic initialisation, sending and receiving of packets.

Documentation:

There is documentation in the doc/ directory in the source tree. This is available in rendered form at https://docs.u-boot.org/en/latest/. Of particular interest is surely the develop/driver-model/ethernet.{rst,html} document, and the files in that same directory. Also a useful source of information are other network drivers. The git history should also provide examples of conversions from the old model to DM_ETH.

U-Boot quickstart guide:

To compile U-Boot for the FVP model on an x86 machine, you need an aarch64 cross compiler, modern distributions package that:

# apt install crossbuild-essential-aarch64

The U-Boot repository can be found at: https://source.denx.de/u-boot/u-boot.git. Clone the repo and use the latest code base from the master branch, then build U-Boot for the FVP:

$ export ARCH=arm64
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make vexpress_aemv8a_semi_defconfig
$ make -j8

There will be some more software packages required by U-Boot's build system, please install them as needed. doc/build/gcc.rst and nearby files describe the build process and its prerequisites. The final make command would generate the binary file "u-boot.bin", without warning messages. To deploy this on an actual FVP model, this binary would need to be fed to a Trusted-Firmware-A build process as the BL33 component, however this step is NOT REQUIRED for that task.

If you have access to an arm64 based Linux machine, you can of course compile U-Boot natively, with any system provided compiler.