Porting U-Boot to a Modular Device
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 561 | |
| 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 | 10.5446/44487 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2019391 / 561
1
9
10
15
18
19
23
24
27
29
31
33
34
35
38
39
40
43
47
49
52
53
54
55
58
59
60
63
65
67
69
70
78
80
82
87
93
95
97
102
103
104
107
110
111
114
116
118
120
122
123
126
127
131
133
136
137
139
141
142
148
153
155
157
159
163
164
168
169
170
171
172
173
174
181
183
185
187
188
193
196
197
198
199
200
201
205
207
208
209
211
213
214
218
221
223
224
226
230
232
234
235
236
244
248
250
251
252
253
255
256
257
262
263
264
268
269
271
274
275
276
278
280
281
283
284
288
289
290
293
294
296
297
300
301
304
309
311
312
313
314
315
317
318
321
322
327
332
333
334
335
336
337
338
339
340
343
345
346
352
353
355
356
357
359
360
362
369
370
373
374
375
376
377
378
383
384
387
388
389
390
391
393
394
395
396
406
408
409
412
413
414
415
419
420
425
426
431
432
433
434
435
436
438
439
440
441
445
446
447
448
453
455
457
459
466
467
471
473
474
475
476
479
480
484
485
486
489
491
492
496
499
500
502
505
507
508
512
515
517
518
529
531
533
534
535
536
539
540
546
550
551
552
553
554
555
557
558
559
560
561
00:00
Modul <Datentyp>BootingWhiteboardModul <Software>Software developerStudent's t-testComponent-based software engineeringConnected spaceAnglePCI ExpressNetwork topologyTopologyShift registerOverlay-NetzVertex (graph theory)Parameter (computer programming)Modul <Software>Router (computing)Connectivity (graph theory)Operating systemCategory of beingKernel (computing)Network topologyGraph theoryGraph (mathematics)Overlay-NetzElectronic mailing listBinary codeExpressionCycle (graph theory)WhiteboardNormal (geometry)BootingType theoryPCI ExpressPlastikkarteFlow separationPresentation of a groupContent (media)Bus (computing)MultiplicationOcean currentDisk read-and-write headParameter (computer programming)NeuroinformatikDifferent (Kate Ryan album)Shift operatorComputer scienceMultiplication signTopologyDevice driverInterrupt <Informatik>Standard deviationSystem identificationShift registerConnected spaceDirectory serviceBarrelled spaceProjective planeInterface (computing)TorusMathematicsMereologyComputer animation
07:31
PCI ExpressConnected spaceTopologyModul <Datentyp>Shift registerNetwork topologyWhiteboardFunction (mathematics)Modul <Software>CodeLine (geometry)Vertex (graph theory)BootingParameter (computer programming)Configuration spaceDefault (computer science)TranscodierungDefault (computer science)Line (geometry)Functional (mathematics)CodePointer (computer programming)AdditionDifferent (Kate Ryan album)BootingKernel (computing)TopologyScripting languagePatch (Unix)WhiteboardMathematicsNumberOverlay-NetzParameter (computer programming)Network topologyError messageElectronic mailing listModul <Software>ResultantPosition operatorEmailSlide ruleBefehlsprozessorValue-added networkConfiguration spaceMultiplication signOperating systemLatent heatSpecial functionsSpacetimeMetric systemSource codeConnected spaceOperator (mathematics)Computer animation
14:54
CodeDevice driverKernel (computing)TelecommunicationImplementationModul <Software>BootingLine (geometry)Service (economics)MathematicsModul <Software>Device driverCodeBefehlsprozessorImplementationNetwork topologyPoint (geometry)TelecommunicationProper mapKernel (computing)Multiplication signRevision control2 (number)Presentation of a groupSlide ruleRepository (publishing)Software developerPointer (computer programming)Overlay-NetzWhiteboardCorrespondence (mathematics)Booting1 (number)Computer animation
22:17
Computer animation
Transcript: English(auto-generated)
00:05
Good afternoon. My name is Marek Behun and I'm going to talk about what I have been working on for the last few months at work. That is about porting U-Boot to a modular device, a device into which different modules
00:28
can be plugged, like USB or something like that, but it doesn't work like USB so a different approach had to be chosen.
00:41
Here we have the contents of the presentation. First about me. I was born in Slovakia, 1991, using Linux from 14. Currently I am studying computer science in Prague and for the last two years I have been
01:03
working at CZNIC on Project Turis. The problem which this presentation is about was solved for Turismox.
01:23
What is device tree? I don't know how people here are proficient in U-Boot, so let's hope this is not too much for you. The operating system kernel has to know how different computer parts, components on
01:49
a board are connected to each other. For this, the standard for device tree was created.
02:01
Device tree is a, as the name suggests, is a graph in which each node represents one device, has properties about what type of device it is, which driver should be used and which interrupt lines are connected to the device and so on.
02:28
Actually it's not a tree in graph theory because the edges can form a directed cycle sometimes, so it should be maybe called the device graph.
02:47
Well, what if some components are pluggable? For example, USB is pluggable into each device, which supports USB.
03:00
If you have a router or a Raspberry Pi, you can also plug PCI cards, PCI express cards in computers, and nowadays SDIO can be used. We can plug a Wi-Fi card into the slot for SD cards.
03:23
What if the components which we are talking about aren't plugged via such a bus that supports such a change?
03:41
Then device tree has to be changed. If you have USB devices, you do not have to tell the operating system which USB device is connected because USB supports self-identification, so the operating system can read from the
04:03
USB device what type of device it is, and also from SDIO and PCI express. But if you have, for example, Raspberry Pi with the HIFI berry shield, or if you have, there are many kinds of shield, now I have read about TV head for Raspberry Pi,
04:27
if you have something like that, then you have to change the device tree with which U-Boot boots Linux.
04:45
And our device exposes several interfaces, like USB, PCI, and Ethernet via one connector.
05:01
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, the switch module can be connected more times, and then you have multiple ports, Ethernet ports.
05:24
The topology of how these modules are connected can be read via SPI, via a SPI shift register. The problem I was solving was how to let the kernel know in an elegant way which modules
05:49
are connected. Normally, for this kind of thing, there are device tree overlays.
06:03
Device tree overlays are a special kind of device trees, device tree binaries, which the bootloader can overlay over a normal device tree, and it will somehow change
06:23
the original device tree binary. For example, it will add some devices or create some edges in the device tree, so that the kernel will know that something is connected additionally.
06:41
Here is a screenshot of a listing of all the different device tree overlays supported by Raspberry Pi. If you look into the slash boot directory, slash overlays on your Raspberry Pi, you can find all these overlays and more.
07:03
Here are only 14 listed. The question is, can we use device tree overlays for each module on our board? The answer is no, because the parameters for the device tree for each module are
07:28
dependent not only on which module this is, but also where in the topology it is connected. If it is in the second place after some different module, then the parameters have
07:42
to change for this module. For example, if I have a module for the fourth one, for an SFP cage, it's dependent on if it is, for example, in the third place or if it is directly connected to the
08:05
CPU module, because there are GPIOs on the SFP cage, and the GPIOs can be read via the SPI line via which the topology is also read.
08:25
So we can't use device tree overlays for this problem, really. At first I actually used device tree overlays, but as you can see, the number of different
08:44
device trees, device tree overlays, grows rapidly because each configuration has its own overlay. For example, if I connect three switches with chipset Peridot, then I have to have
09:08
different device tree overlays as when I connect only two. This will grow more rapidly because the SFP module will also multiply the number
09:25
by two. So we could use device tree overlays, but it's not very nice and elegant. Fortunately, U-Boot has this feature that each board-specific code can use.
09:49
So for different boards in the U-Boot source, you have a special code for booting them, and one of the functions you can write for your board is FT board setup, which
10:08
will pass you the pointer to the device tree loaded by the user or by the script booting the operating system, and in this function you can change the device tree, fix it or
10:25
something, remove nodes, create nodes, and so on. At first I tried to create whole nodes for each module in this function.
10:44
The main device tree for the kernel didn't contain nodes for the modules, only for the CPU module, not for the pluggable modules. And my code in FT board setup created all the nodes for all the connected modules.
11:06
But the result was almost 1,500 lines of ugly C code. Ugly. If I wanted to check for every possible error, then it was ugly.
11:27
Many times it was the same thing, but something was different, so you couldn't write a special function for everything. It couldn't be squashed by using functions.
11:49
I asked myself how to do it so that the code will look more nice, and I have decided
12:03
that the right metric was minimizing the number of changes that the code in U-Boot has to do in the device tree so that it can boot correctly the device.
12:21
I decided that I will write nodes for every module inside the main device tree in Linux, but I will use status disabled for those nodes so that the kernel will ignore them on default. And on boot time, U-Boot in this FT board setup function will just look at the SPI
12:48
line, discover which modules are connected, and it will just change status to OK on those nodes which are connected.
13:01
And also sometimes it has to change something more because of what I talked about some slides ago, because some modules need special configuration because of the position where they are.
13:29
The result from this was only under 250 lines of additional C code. I have a screenshot here.
13:43
It looks, in my opinion, a lot nicer than the original 1500 lines. We also add 600 lines of device tree code in the main device tree in kernel, and the
14:07
status of this is that the patches, some of them are already reviewed on kernel mailing lists, so it looks like it will be accepted into kernel as well, and it was already reviewed
14:21
in U-Boot. Here in this screenshot you can see that I have to change the name of the node which
14:41
exposes GPIOs for the SFP module.
15:01
The advantages and disadvantages of this solution, in my opinion, the advantages are that there is less C code, new C code. It is also more readable.
15:26
I actually had the 1500 lines of code 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.
15:46
Another advantage, in my opinion, is that when some developer makes a change in a driver in the kernel, for example for the switch in the DSA subsystem, and this change would
16:04
have to also change device trees somehow. Then if the whole device tree is in the kernel, in the kernel repository, then they will also change it and I won't have to change it on my own.
16:25
The disadvantages, well, we are not using overlays and they are meant for this kind of thing, but they couldn't be used in an efficient way, so I decided not to use them.
16:48
A bonus slide, one problem which I had to solve, which I needed to find a solution for, on our board, SerDes lines, the driver for the initialization of SerDes lines is
17:09
loaded before SPI driver. This means that SerDes lines are initialized before, and when I initialize the SerDes
17:25
lines, I have to know the speed for each line. For example, if SFP module is connected, then the corresponding SerDes line has to be for one gigabit, but when switch module is connected, the corresponding line has
17:47
to be at 2.5 gigabits per second. When the SerDes initialization is done before the SPI, then I cannot know which module is connected.
18:02
There were two solutions for this. One solution was to write a proper driver for SerDes initialization. By proper, I mean that the SFP node in your boot, in the device 3, should have a pointer
18:34
to the SerDes line, and the driver then would have known which speed to use.
18:41
If it is connected to the SFP line in the device 3, it would have known that it should enable the SerDes line on one gigabit. If the switch node is connected, then it would have known it should enable it on 2.5.
19:01
But writing, completely rewriting the SerDes initiation code was too much work for my time. I decided that I will solve this problem by writing my own tiny implementation of
19:24
SPI communication. It is only 35 lines of code. I write to some registers directly on the CPU and then read some registers and I have
19:44
read the first 10 bytes from the SPI so that then I know which modules are connected. This solution is not very elegant because there is a proper implementation of SPI communication
20:13
in your boot and I had to write my own. So we discovered the duplication, but this can be removed when we have the correct SerDes
20:26
installation driver. Thank you. Okay, that's all from me. Any questions?
20:51
Yes? Is it possible to get some kind of notification when another device is attached? Our device does not support hot plugging, only booting.
21:02
I have actually talked today with a 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 do hot plugging and kernel supports device
21:29
is mostly changing online, so we would have to work on it. I would have to write drivers for this, but it could be working.
21:42
Our device does not support it. Or not. The board would have to be changed. Maybe next version. Okay, thank you. Welcome. Questions?
22:03
Okay.