# Motivation

At different times we have noted that in U-Boot device model and the EFI subsystem we have parallel structures. The most recent being Takahiro's patch series [1].

Before adding any more dependencies I think we should develop a sound architectural vision. We should end up with a design specification on which we can base our future development.

This year hopefully all block devices will be eliminated in U-Boot that are not following the device model. This gives us the chance to clean up our code base.

Topics of this mail are:

- how devices and drivers are modeled in EFI - how devices and drivers are modeled in U-Boot - how both are related - the state of block devices and drivers in U-Boot - first thoughts on joining the two worlds

# Devices and drivers in EFI

An overview of devices and drivers in EFI is given in doc/README.uefi.

A device is represented by a handle (struct efi_obj *) exposing the device path protocol. This device path protocol is a sequence of device path nodes. The device tree is modeled via the device path protocol.

A driver (also called controller) is represented by a handle exposing the EFI_DRIVER_BINDING_PROTOCOL.

Drivers are attached to a device by calling the ConnectController service. Drivers are removed from a device by calling the DisconnectController service.

The ConnectController service iterates over all handles exposing the driver binding protocol and calls the Supported() method of the protocol. For each driver supporting the device it calls the Start() method of the protocol.

The driver now installs its own protocol on the device handle with its own handle referenced as the controller and setting an attribute indicating if it is binding exclusively (no other driver may be connected to the device).

The driver may create additional handles representing sub-devices in the StartService. The ConnectController service can recursively bind drivers to these.

The DisconnectController service iterates of all protocols on the device handle which are marked as being controlled by a driver and calls the Stop() method of the driver binding protocol.

The driver now uninstalls its protocol.

There can be handles that are neither drivers nor devices.

Devices may be created by the sub-system without any pre-existing U-Boot device, e.g. an iSCSI drive may be set up as a handle exposing the EFI_BLOCK_IO_PROTOCOL, or a VPN tunnel may be created as a virtual network interface with the EFI_SIMPLE_NETWORK_PROTOCOL installed.

# Devices and drivers in U-Boot

doc/driver-model/README.txt has an overview.

A driver has a U_BLOCK_DRIVER entry linking it to a uclass. In the ops pointer U_BLOCK_DRIVER it exposes the available operations.

A uclass represents a group of drivers exposing the same interface.

A device is represented by a udevice structure. It has a pointer to its uclass. It is connected to a driver by calling the bind() function of its uclass and can be disconnected by calling the unbind() function of the uclass. All devices have a parent device except for the top level device. These relationships make up the device tree.

Some devices to be created are defined in the device tree. Other devices are detected by scanning hardware buses.

New devices may be found at runtime, e.g. when a USB device is connected.

# Relationship between EFI and U-Boot devices

ConnectController in EFI is the equivalent to bind(), ofdata_to_platdata(), and probe() in U-Boot.

DisconnectController in EFI is the equivalent to unbind() in U-Boot.

We have discovered a single case where objects are devices in EFI but not in U-Boot. EFI partitions are block io devices where the disk is the parent. A block device exposes the EFI_BLOCK_IO_PROTOCOL. If the partition is formatted the EFI device additionally exposes the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.

In U-Boot partitions and file systems are not following the device model.

We have devices in U-Boot where there is no protocol existing in EFI to access it. We could represent them in EFI as a handle with a device path protocol.

As described above the EFI subsystem may create (virtual) devices. For block io devices we have integrated the two worlds. When ConnectController is called for a block io device we create a U-Boot block device marked as being of type UCLASS_EFI. The unbinding of the driver is not yet implemented.

# How we can tie the worlds together

Every device in the EFI world should have an equivalent in the U-Boot world. This requires modeling partitions as U-Boot devices.

Every U-Boot device relevant for EFI and all its ancestors should have an EFI handle with the EFI_DEVICE_PATH_PROTOCOL installed.

For convenient look up a pointer to the device in the EFI handle (struct efi_obj) would be helpful.

When trying to join the EFI and the U-Boot driver model the best abstraction level would be uclasses having EFI handles exposing the EFI_DRIVER_BINDING_PROTOCOL.

EFI handles should be created when bind() is called for the U-Boot device.

Block devices seem to be the best starting point for the exercise.

[1] [PATCH v2 0/3] efi_loader: add removable device support https://lists.denx.de/pipermail/u-boot/2018-November/347491.html