Improve TPM v2.0 support in U-Boot. This internship will allow to implement some missing TPM v2.0 mechanisms to allow for a secure measured boot in U-Boot, and to contribute this new code to the official version of the project.
Support the SquashFS filesystem in U-Boot. This internship will allow to add support for the SquashFS filesystem to U-Boot. SquashFS is very widely used in embedded projects. This way, you will allow U-Boot to load files (kernel, initramfs, etc) from a SquashFS partition. As usual, you will also have to contribute this new code to the mainline version of U-Boot.
As you can see, all these topics propose both a challenging technical opportunity, but also require strong interaction with the community of users and developers of free and open-source software used in embedded projects.
More details are available in the descriptions. The internships can start from February 2020, for a minimum duration of 4 months. These internships will take place either in our offices in Toulouse, Lyon or Orange, in France, depending on the topics. These internships are open to all students from the European Union.
Today, the three Raspberry Pis that we have on our network went down. They were all running Raspbian (Debian for Raspberry Pi) Stretch.
While this issue can be solved, it is serious enough to require to remove the micro-SD card and manually fix the the root filesystem. Therefore, it seems you cannot fix this issue unless you have physical access to your system.
Here are details to attract attention to this issue…
As I started telling you, our systems were down, well almost. Some services were still running, as they were still responding to ping through our VPN. However, SSH access was no longer available:
$ ssh scan
ssh_exchange_identification: Connection closed by remote host
After connecting a serial cable to one of the Pis, and adding init=/bin/sh to the /boot/cmdline.txt file. I found that I couldn’t seem to execute at least some executables. Everything I tried to execute was causing a segmentation fault.
It was time to remove the micro-SD card and look at system logs. Inspecting /var/log/apt/history.log revealed that the raspi-copies-and-fills package was updated yesterday (March. 11, 2019). This allowed me to make a search for issue reports with this package name. Indeed, before having such a lead, I couldn’t find what I was looking for, as there are too many discussions about the use of the Raspberry Pi! So, here’s what I quickly found following this lead:
These posts have all details. All you need to do is take away the micro-SD card, repair the second partition with e2fsck -f /dev/mmcblk0p2 and remove the etc/ld.so.preload file inside this partition.
Note, that at the time of this writing, this issue has already been fixed, so it is safe to upgrade your Pi if it is still up and running, or right after repairing your Raspbian root filesystem.
This incident is very unfortunate, as you need to physically access your board to recover from it. I hope you don’t run updates as frequently as we do (or right after the time when the update was issued), and that your Pis are not impacted, otherwise possibly forcing you to travel or to crawl into difficult to access places to reach your boards.
However, I don’t want blame the community volunteers running Raspbian. They have made a terrific job maintaining this distro which had been flawlessly running for more many years on our systems. This seems as good as what we get from commercial distributions.
I hope that not too many services ran by Raspberry Pis will be disrupted because of this issue. However, that may be yet another way to prove how popular such devices are.
At Bootlin, we owe a lot to the Free Software community, and we’re doing our best to give back as much as we can.
One way of doing that is welcoming community contributors in our public training sessions organized in France. We’ve done that multiple times several years back, and this allowed us to meet very interesting people (who even had very valuable experience and points of view to share with the other course participants), while of course giving them extra knowledge that they can use for further contributions.
Here are the next sessions in which we can offer a free seat:
We’ve started to use Mastodon (in addition to Twitter and LinkedIn) to share quick news with you: new blog posts, contributions to Free Software projects, photos at events, etc.
Did you know Mastodon? I’ll like Twitter, but better, decentralized and really free (as in Free Software). I discovered it by attending one of the conferences we sponsor (Capitole du Libre in Toulouse, France) and by following the efforts of Framasoft to provide decentralized Internet services.
Being Free Software and not biased by the need to maximize revenue for its investors
It’s decentralized and therefore controlled by its users. You are free to join an instance that matches your interests and sensibility, but of course you can follow anyone on any other instance. It’s also easy to move to another instance or even host your own one
There are no Retweets but Boosts. Retweets allow to share a post with your own comments to all your followers. This creates flame wars in the best interest of Twitter. Twitter needs its users to spend as much time as possible viewing the content they host (and therefore their promoted content at the same time). Instead, Mastodon only allows to “boost” the visibility of someone else’s post, without allow you to add your own comments. Mastodon has no interest in making you stay as long as possible by creating flame wars. It just lets you focus on the content your are interested in.
In a nutshell, using Mastodon contributes to a better world in which users are in control of their data, interests and time.
Here are details about booting the Beagle Bone Black Wireless board through NFS. I’m writing this here because it doesn’t seem to be documented anywhere else (except in our Linux kernel and driver development course, for which I had to support this feature).
Booting a board on a root filesystem that is a directory on your workstation (development PC) or on a server, shared through the network, is very convenient for development purposes.
For example, you can update kernel modules or programs by recompiling them on your PC, and the target board will immediately “see” the updates. There’s no need to transfer them in some way.
Doing this is quite straightforward on boards that have an Ethernet port, and well documented throughout the Internet (see our instructions). However, things get more complicated with boards that have no such port, such as the Beagle Bone Black Wireless or the Pocket Beagle.
The Beagle Bone Black Wireless board has WiFi support, but booting on NFS directly from the kernel (instead of using an initramfs) is another kind of challenge.
Something easier to use is networking over USB device (also called USB gadget as our operating system is running on the USB device side), which is supported by both Linux and U-Boot.
Note that the below instructions also work on the original Beagle Bone Black, bringing the convenience of not having to use an RJ45 cable. All you need is the USB device cable that you’re using for power supply too.
These instructions should also support the Pocket Beagle board, which is similar, though much simpler.
This part may just work out of the box if the U-Boot version on your board is recent and was built using the default configuration for your board.
If that’s not the case, you can reflash U-Boot on your board using our instructions.
These instructions have been tested on Ubuntu 18.04, but they should be easy to adapt on other GNU/Linux distributions.
To configure your network interface on the workstation side, we need to know the name of the network interface connected to your board.
However, you won’t be able to see the network interface corresponding to the Ethernet over USB device connection yet, because it’s only active when the board turns it on, from U-Boot or from Linux. When this happens, the network interface name will be enx. Given the value we gave to usbnet_hostaddr, it will therefore be enxf8dc7a000001.
Then, instead of configuring the host IP address from NetWork Manager’s graphical interface, let’s do it through its command line interface, which is so much easier to use:
nmcli con add type ethernet ifname enxf8dc7a000001 ip4 192.168.0.1/24
To download the kernel and device tree blob which are also on your PC, let’s install a TFTP server on it:
sudo apt install tftpd-hpa
You can then test the TFTP connection, which is also a way to test that USB networking works. First, put a small text file in /var/lib/tftpboot.
Then, from U-Boot, do:
tftp 0x81000000 textfile.txt
The tftp command should have downloaded the textfile.txt file from your development workstation into the board’s RAM at location 0x81000000. You can verify that the download was successful by dumping the contents of memory:
We are now ready to load and boot a Linux kernel!
These instructions were tested with Linux 4.19
Configuring and cross-compiling the Linux kernel for the board is outside the scope of this article, but again, such information is easy to find (such as in our training slides).
Here, we’re just sharing the Linux kernel configuration settings that are needed for networking over USB device. Since they are not supported by the default configuration file for the omap2plus CPU family (for several reasons that were discussed on the Linux kernel mainling list), it took a bit of time to figure out which ones were needed. Here they are:
Add the below options to support networking over USB device:
CONFIG_USB_MUSB_HDRC=y: Driver for the USB OTG controller
CONFIG_USB_MUSB_GADGET=y: Use the USB OTG controller in device (gadget) mode
Check the dependencies of CONFIG_AM335X_PHY_USB. You need to set CONFIG_NOP_USB_XCEIV=y to be able to set CONFIG_AM335X_PHY_USB=y
Find the ”USB Gadget precomposed configurations” menu and set it to static instead of module so that CONFIG_USB_ETH=y
How did I found out which settings were needed? I had to check the device tree to find the USB device controller. Then, using git grep, I found the driver that was supporting the corresponding compatible string. Then, looking at the Makefile in the driver directory, I found which kernel configuration settings were needed.
When compiling is over, copy the zImage and am335x-boneblack-wireless.dtb files to the TFTP server home directory (/var/lib/tftpboot).
You also need an NFS server on your workstation:
sudo apt install nfs-kernel-server
Then edit the /etc/exports file as root to add the following line, assuming that the IP address of your board will be 192.168.0.100:
Now check the kernel log and make sure an IP address is correctly assigned to your board by Linux. If NFS booting doesn’t work yet, that could be because of NFS server or client issues. If that’s the case, you should find details in the NFS server logs in /var/log/syslog on your PC.