The U-Boot Driver Model Project =============================== Project introduction ==================== 2012-04-05 I) Overview ----------- The U-Boot bootloader is a widely used software in the domain of embedded solutions. It was initially developed on the PowerPC architecture and later ported to MIPS, SPARC and the ARM architecture which is very popular today. The U-Boot provides the user with a monitor-like command line interface, allowing the user to perform certain actions with hardware. This is very useful especially in early phases of platform development and bootstrap. To this date, U-Boot contains drivers and command interfaces for myriads of peripherals and hardware components, as well as the support for a wide range of processors and architectures. II) Goals --------- The goal of this project is to augment the current implementation of the U-Boot bootloader by a driver model. As of now, there is no driver model in the U-Boot bootloader, which causes several problems. In this project, we will tackle the problem 1) and 2) and outline solution for problem 3). 1) Preprocessor based configuration ----------------------------------- Currently, the configuration of various features of drivers is done via preprocessor macros. This makes run-time reconfiguration impossible. Also, this makes it impossible for a single U-Boot binary to contain support for multiple boards with a particular driver configured differently. Especially the second problem is often solved by introducing ad-hoc functions. The solution is to allow the board definition files to pass filled-in configuration structures to the drivers. These configuration structures can be generated at run-time or be static data created at compile time, though it will always be the responsibility of the programmer to make sure correct structure is passed to the driver. Furthermore, in order to support multiple boards with a single U-Boot binary, the decision as of which structure to pass would have to be done at run-time. 2) Incapability to support multiple devices ------------------------------------------- Many drivers in U-Boot obey some kind of predefined API, which in turn is called by commands. The commands implement interface between user's command line input and the driver. The API creates a 1:1 mapping between functions called by commands and their implementation in the drivers. This causes trouble, because with current implementation, only one driver can be compiled in at a time, to avoid collision amongst function names. Such situation makes it impossible for two different drivers using the same API to control two different devices. The solution is to implement a driver core, which will in turn relay control structure of a particular device to a command which wants to control this particular device. 3) Incapability to support multiple boards with single binary ------------------------------------------------------------- This problem is tightly related to problem 1). The solution to this problem, though, is not quite simple. Sometimes, it is not possible to tell two boards apart and at that point. Those two boards simply cannot be supported by a single U-Boot binary. The unifying concept for solving problems number 1) and 2) will be the implementation of a model usually called a device tree. The device tree is a tree-like representation of the whole system, that is busses as nexus nodes and devices as leaf nodes. Such a tree-like structure will be constructed at run-time, during the bootloader initialization stage, in order to allow support for multiple boards in a single U-Boot binary. Support for multiple boards will not be part of this project. Also in later stages of bootloader operation, having run-time constructed device tree will allow dynamic addition and removal of devices. This is especially important for dynamic busses, like USB or PCI, where the devices can be added and removed even at run-time. It is also important to allow programmer to remove and/or deinitialize devices before booting the operating system. By implementing the driver model into the U-Boot bootloader, the code will become much less ad-hoc. Many non-systematic hacks in the code will also disappear, allowing the code to obey common well established software engineering practices and recommendations as well as a high level of abstraction unlike now. On a final note, we will make the driver model as flexible as possible and we will convert all the boards listed below to support it. The rest of the boards within the source tree of U-Boot bootloader will be converted as well, though some of the boards will have to be omitted. This is because U-Boot also supports hardware that is not manufactured anymore and there is no known person that owns such a hardware to test our changes. Such cases of hardware will not be converted and support for it will be scheduled for removal from the U-Boot bootloader source tree. The final demonstration of the work made on this project will be held on multiple distinct boards physically available to our team. These boards will be fully converted to the new driver model. This includes the following boards: Virtual devices: - QEMU-x86 (coreboot-x86 x86/32 device) - QEMU-mips (qemu_mips MIPS device) - QEMU-zipitz2 (zipitz2 ARM/pxa device) - QEMU-versatile (versatile ARM device) Real hardware devices: - DENX M28EVK (ARM/i.MX28 device -- multiple ethernet devices) - Genesi EfikaMX (ARM/i.MX51 device -- multiple USB hosts) - Voipac Vpac270 (ARM/PXA270 device -- IDE port) - HP T5000 (x86/VIA C3 device -- x86 demonstration device) - Freescale MX53QSB (common high-end ARM board) III) Time and risk analysis --------------------------- Due to the already established nature of the U-Boot project and the project being Free Software, there will be a need to discuss the design of the driver model with the upstream U-Boot developers in the preparation stage. This puts extra time constraints on this particular stage: 0) Preparation stage (1 month) ------------------------------ In this stage, part of the team will properly familiarize itself with the U-Boot bootloader internals. 1) Design stage (1 month) ------------------------- This stage encompasses the actual design of the driver core, the binding mechanism of the drivers with it and with the commands. The result will be a set of documents directing the further implementation. 2) Implementation stage of the driver core (1 month) ---------------------------------------------------- At this stage, the driver core will be implemented and thoroughly debugged. Only sample drivers will be used at this stage to demonstrate and test the core. 3) Conversion stage of the actual drivers (3 months) ---------------------------------------------------- This stage will involve actual hardware testing and conversion of all reasonable drivers to the driver core implemented in the previous stage. 4) Debug stage (1 months) ------------------------- Due to the distinct nature of various hardware platforms, it is to be expected multiple bugs will be found throughout the process of implementing and conversion. At this stage, the team will try to remove most of the bugs. 5) Documentation stage (1 month) -------------------------------- Finalizing the documentation of previous efforts will be done at this stage. The risk of unexpected problem arising throughout this project is relatively low. There are team members already very familiar with the U-Boot bootloader, and also very skilled programmers, leading me to believe the project will turn out successfully. IV) List of involved people --------------------------- Project supervisor: Martin Decky Project members: Marek Vasut Pavel Herrmann Viktor Krivak Tomas Hlavacek