AV-Portal 3.23.2 (82e6d442014116effb30fa56eb6dcabdede8ee7f)

Porting U-Boot to a Modular Device

Video in TIB AV-Portal: Porting U-Boot to a Modular Device

Formal Metadata

Title
Porting U-Boot to a Modular Device
Subtitle
Booting Linux via U-Boot on a board which can be composed of several different modules
Title of Series
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2019
Language
English

Content Metadata

Subject Area
Abstract
Currently, Das U-Boot and Linux use device tree to specify how the different hardware components are connected to each other on a board. If a board has a way via which the user can plug in another hardware component, unless we are talking about universal buses like USB or SDIO, the device tree has to be updated to corresponding to the change. There are several ways how this issue can be solved. One may, for example, have a different device tree for each configuration, or one can use device tree overlays. But what if you have a device which can, via one bus, connect several devices, and these may or may not be of the same kind? The number of different device trees would grow rapidly, and one could not use the same device tree overlay when the same device is connected more than one time without editing the overlay. Fortunately U-Boot can fixup the loaded device tree before booting. In this talk we shall describe how we used this fixup feature (hopefully in an elegant and upstreamable way) to solve this issue on Turris MOX, a modular SOHO router.
Loading...
Modul <Software> Whiteboard Modul <Software> Modul <Datentyp> Booting Booting
Torus Presentation of a group Software developer Connectivity (graph theory) Device driver PCI Express Angle Mereology Neuroinformatik Connected space Whiteboard Different (Kate Ryan album) Router (computing) Standard deviation Graph (mathematics) Projective plane Content (media) Plastikkarte Student's t-test Graph theory Component-based software engineering Type theory Category of being Kernel (computing) Computer science Interrupt <Informatik> Cycle (graph theory) Whiteboard Booting
Modul <Software> Topology Multiplication Topology Shift register Connectivity (graph theory) Interface (computing) Multiplication sign PCI Express PCI Express Barrelled space Shift register Disk read-and-write head Component-based software engineering Type theory Connected space Mathematics Network topology Network topology Operating system Bus (computing) System identification Modul <Datentyp> Booting
Overlay-Netz Modul <Software> Overlay-Netz Topology Modul <Software> Binary code Electronic mailing list Parameter (computer programming) Directory service Parameter (computer programming) Connected space Value-added network Kernel (computing) Network topology Network topology Normal (geometry) Modul <Datentyp> Vertex (graph theory) Whiteboard Booting
Code Multiplication sign Source code Connected space Mathematics Different (Kate Ryan album) Kernel (computing) Special functions Vertex (graph theory) Error message Position operator Scripting language Overlay-Netz Email Modul <Software> Electronic mailing list Parameter (computer programming) Shift register Befehlsprozessor Configuration space Modul <Datentyp> Whiteboard Metric system Resultant Spacetime Booting Modul <Software> Slide rule Topology Functional (mathematics) Line (geometry) Patch (Unix) PCI Express Transcodierung Number Latent heat Network topology Whiteboard Operating system Configuration space Booting Default (computer science) Default (computer science) Addition Topology Code Line (geometry) Device driver Kernel (computing) Pointer (computer programming) Function (mathematics) Network topology
Point (geometry) Slide rule Modul <Software> Presentation of a group Implementation Service (economics) Code Correspondence (mathematics) Multiplication sign 1 (number) Device driver Proper map 2 (number) Revision control Mathematics Telecommunication Kernel (computing) Implementation Booting Overlay-Netz Software developer Modul <Software> Code Line (geometry) Device driver Kernel (computing) Befehlsprozessor Pointer (computer programming) Repository (publishing) Network topology Telecommunication Whiteboard Booting
good afternoon my name is Marc Bohan and
I'm going to talk about what I have been working on for the last few months in at work and that is about porting you boot to a modular device a device which into which different modules can be plucked like USB or something like that but it doesn't work like USB so a different approach had to be chosen here we have
the contents about the presentation so first about me I was born in Slovakia 1991 using Linux from 14 currently I am studying computer science in prac and for the last two years I have been working at Caesars Nick on project torus and know the problem which this presentation is about was for solved for 2d smocks so now what is device three I don't know how people here are proficient in the woods so let's hope this is not too much for you device three mmm the operating system kernel has to know how different computer parts components are on a board are connected to each other and for this device three was the standard for device trip was created device three is a name suggests is a graph in which each node represents one device has properties about what what type of device it is which driver should be used and which into interrupt lines can are connected to the to the device and so on um actually it's not a three in graph theory because the edges can form a directed cycle sometimes so so it should be maybe called the device graph
well what if some components are plugable Oh for example USB is pluggable into into each device which supports USB if you have a router or a Raspberry Pi you can also plug PCI cards which are Express cards in computers and nowadays SDIO can be used so we can block a Wi-Fi card into the slot for SD cards but what if
the components which we are talking about aren't blocked by as such a bus that that supports such a change mmm then device three has to be changed if you have USB devices you don't you do not have to tell the operating system or which USB device is connected because USB supports or self identification so the operating system can can read from the USB device what type of device it is but and also from SDIO and PCI Express but if you have for example raspberry P with the heavy barrel shield or if you have a there are many many kinds of shield now now I read about TV head for full Raspberry Pi if there is something like that then you have to change the device tree which with which you boot boots the boots Linux so and our device or expose it several
interfaces yeah like USB PCI and Ethernet via one connector and there are several different modules which can be connected to the device and they can also be connected in some of them can be connected multiple times for example switch module can be connected more times and then you have multiple ports Ethernet ports the topology of how the topology of how these modules are connected can be read by a spi by a FB i-- shift register and the problem I was solving was how to let the cardinal know in an elegant elegant way which modules are connected
normally for this kind of thing there are device three-hour lays device three overlays are a special kind of device trees device three bond binaries which the bootloader can overlay over a normal device tree and it will somehow change the original device three binary it will for example it will add some devices or connect create some edges in the device tree so that the kernel will know that something is connected additionally here we here is a screenshot of listing of all the different device we otherwise supported by Raspberry Pi with you if you look into the /boot directory slash slash otherwise in on your Raspberry Pi you can find all these otherwise and more here are only 14 listed
so the question is can we use device three overlays for each module on our board and the answer is no because the parameters in the for the device three for each module are dependent not only on which module disease but also where in the topology it is connected so if it's if it is on the second place after some different module then the parameters have to change for for this module for example if I have a module for the Ford van for a zippy cage its
dependent on if it is on for example on the third place or if it is directly connected to the CPU module because there are GPIO s on the SSD cage and the GPIO s can be read via the SPI line wire which the the topology is also read
so so we can't use device three our lives for this problem really at first I actually use device three over our lives but but as you can see the number of different device trees if I say otherwise grows rapidly because of each each configuration has to have its own overlay so for example if I connect 303 switches of with chipset peridot then I have to have different device to three other way as when I connect only to oh and this will grow more rapidly because the SFP module can also will also multiply the number by a by two so so we could use device we are relays but it's not very nice and elegant fortunately he would has this feature that each board specific code can use so for different boards in the u-boot source you have a special code for booting them and one of the function one of the functions you can write for for your board is FD board setup which will change which will pass you the pointer to the device three loved it by the user or by the script booting the operating system and in this function you can change the device 3 fix it or something remove nodes create nodes and so on so at first I tried to create whole wall nodes for each module in in this function so the main device 3 in the kernel from 4 for the kernel didn't contain notes for for the modules only for the CPU module not for the pluggable modules and the my code in active board setup or created all the know all the nodes for all the connected modules but the result was almost five hundred fifteen hundred lines of ugly C code ugly if if I wanted to check for every possible error then it was ugly so and many times it was the same thing but something was different so you couldn't write a specific a special function for everything it couldn't be squashed instead of I by using functions so I asked myself how to do it more so the code how to do it so that the code will look more nice and I have decided that the right metric was minimizing number of the changes that the code in Ubud has to do or in the device 3 so that it can put correctly the device so I decided that I will write a note for every module inside the main device 3 in Linux but I I will use status disabled for those nodes so that kernel will ignore them on default and on boot time you boot in this FD board setup function will just look at the SP SPI line discover which modules are connected and it will just change status to ok on on those nodes which are connected and also sometimes it has to change something more because of what I've talked about some slides ago because for some some modules need need space special configuration about rhythm because of the position where where they are so the result from this was only under 250 lines of additional C code I have a screenshot here it looks in my opinion lot nicer than the original 1500 lines we also add 600 lines of device recode in the main device tree in kernel and the at the status of this is that the patches some of them are already reviewed on kernel mailing list so it looks like it will be accepted into kernel as well and it is it was already removed in you would hear in this screenshot you can see that I have to change the name of the node which which expo exposes GPIO s for the SFP module so the advantages and disadvantages of this solution well in my opinion the
advantages are that there is more there is less C code new C code it is also more readable I am I am I actually had the 1500 lines of code or a few months ago but I didn't know that I will be making this presentation and I removed it but if I had it you would see that the code was ugly and another advantage in my opinion is that when some developer makes a change in the in a driver in the kernel for example for the switch in the DSA subsystem and this change would have to also change device trees somehow then if the whole device tree is in the kernel in the kernel repository then the they will also change it and I I won't have to change it on my own the disadvantage is well where we are not using overlays and they are meant for this kind of thing but they couldn't be used in efficient ways of so I this I decided not to use them a bonus slide mmm one problem which I had to solve which I needed to find a solution for on our board or service lines so the driver for unity initialization of service lines is loaded before SPI driver this means that Celia's lines are initialized before and and when I initialize the service lines I have to know the speed for each line for example if SFP module is connected then the corresponding service line has to be for one gigabit but when when switch module is connected the corresponding line has to be at two point five gigabits per second and when the service initialization is done before the SPI then I cannot know which module is connected so there were two solutions for this one solution is was to write a proper driver for service initially initially sorry installation by proper I mean that the SFP node in your boot should indeed in the device 3 should have a pointer to the service line and the driver then will would have known which speed to use if it even is connected to the SSP line on in the device tree it would have known that it should enable the service line on one gigabit and if the switch node is connected then it would have known it should enable it on 2.5 but writing completely rewriting the service initialization code was too much work for my time so I decided that I will write off for I will solve this problem by by writing my own tiny implementation implementation of spi communication it is only for defined 35 lines of code I write to some registers directly on the CPU and then read some registers and I have read the first 10 bytes from the SPI so that then I know which modules are connected it is not this solution is not very elegant because because I have to there is a proper implementation of spi communication in a wood and I had to write my own so it is called the duplication but this can be removed when when we have a correct service in isolation driver okay that's all from me any questions [Applause] this is possible to get some kind of justification when another device is attached our device does not support unplugging only booting I have actually talked today with my colleague if it was possible if it were possible the problem is that our device if you connect something the voltage will drop for a little time and the CPU will reset but we have been thinking about if we could use we could do hot plugging and kernel supports device really changing online so it would have to work on it smooth I would have to write the drivers for for this but it could be working without our device does not support it now I'll devote I would have to be changed maybe maybe next version
questions okay
Loading...
Feedback
hidden