bootlin / training-materials Goto Github PK

[Michael's idea]
Either update the mainline code or use another board

Current example ends up in an assembly memcpy routine. This is difficult to explain. Instead of that, try to end up in a C routine to be able to get back to the C code from the oops location.

Gregory think we should simplify this chapter.
Michael think we should develop this chapter.

Sometimes modules is used to designate a driver. Rework that to be coherent. A module is a loadable module and a driver car be compiled as a module or built-in

I've just realized that some SVG diagrams have lost their text because of the Courier 10 Pitch font, at least on Ubuntu 20.04.
An example is common/strace-c-output.svg
I tried to install the font again on my system, in $HOME/.fonts, but it didn't help.
LibreOffice can use this font, but not inkscape.
A consequence is that the generated documents have diagrams without text.

Ideally, we should have two sections: one for systems built by Buildroot, one for systems built by Yocto.

[Michael's idea]

The idea would be to cover more extensively the device tree in the embedded Linux training, and possibly share the slides with the kernel training.

The use of SAM-BA is a significant source of problems for people doing labs remotely. This could be a learning opportunity, but this is only relevant in the context of Microchip boards.

Instead, I propose to instruct people to prepare an MMC/SD card and compile U-Boot for booting from MMC from the start. This is much more generic and we already do this in the STM32 and QEMU labs. If we want to keep the flash labs, we will still be able to flash U-Boot on NAND flash using U-Boot on MMC.

What do you think?

All the proposed books are pretty old, there should be at least a disclaimer or perhaps newer books to reference.

Setup:
Go to $HOME/yocto-labs/ directory
Directory does not exist, we just created / were told that it is yocto-stm32-labs
I renamed it to yocto-labs...

Download Yocto:
As setup.

git am $HOME/yocto-labs/bootlin-lab-data/0001-u-boot-update-config.patch
fails to apply:

~/yocto-stm32-labs/meta-st-stm32mp$ git am $HOME/yocto-stm32-labs/bootlin-lab-data/0001-u-boot-update-config.patch
Applying: u-boot: update config
.git/rebase-apply/patch:57: trailing whitespace.
-- 
error: patch failed: recipes-bsp/u-boot/u-boot-stm32mp-common_2018.11.inc:24
error: recipes-bsp/u-boot/u-boot-stm32mp-common_2018.11.inc: patch does not apply
.git/rebase-apply/patch:59: new blank line at EOF.
+
Patch failed at 0001 u-boot: update config
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Michael's idea]
Would it work with the nunchuk? If not, why do we tell people to prefer using smbus helpers?

Add a slide to explain the endianness handling: where and why

This was suggested by at least one participant and this makes sense...

The idea is to reduce the time spent in explaining the UNIX packages, administrator rights, sudo access, frustrating people expecting more embedded Linux specific topics.

Anyway, our lab instructions are explicit enough to let participants install packages, configure their environment.
I'm suggesting to reduce, not completely eliminate.

Use a single board instead of the Crystalfontz + Marvell combo.

Avoid misleading questions, simplify some of them, drop useless ones to have a shorter yet more useful quiz.
Examples:

• do not talk about ABI in one question API in the other
• do not use open answers such as ARCH/CROSS_COMPILE
• drop the I2C question
• drop the scanner/printer questions

This is covered more widely in the Embedded Linux training but could potentially be covered in the Linux kernel training as well.

Should it be developed and moved in the standard slide deck? (currently an "if time" topic)

slides/yocto-bsp/yocto-bsp.tex shows an example machine config that defines SERIAL_CONSOLE, which is deprecated and should be replaced with SERIAL_CONSOLES.

We should find another machine config that uses SERIAL_CONSOLES and is also simple and short enough to fit in a slide.

[Michael's idea]
https://wkz.github.io/ply/

Our current agendas for online sessions, at least the embedded Linux one, says:
"For people interested in our optional practical labs, an installation of VirtualBox and about 30 GB of free disk space."

Shouldn't instead say?
"For people interested in our optional practical labs, Ubuntu 20.04 in a native installation or in a VirtualBox instance, with about 30 GB of free disk space."

A native installation is much better and it's good to propose the GNU/Linux distro and version that we officially support.
Would you agree with this change?

https://fr.wikipedia.org/wiki/Appel_syst%C3%A8me#/media/Fichier:Linux_kernel_interfaces.svg

• Remove useless directories (certs/etc)
• Present some subsystems that are present in drivers/.

For on-site courses, the board setup is already done by Bootlin trainers, before the training course.

For on-line courses in which we want the participants to do the labs by themselves, they need to prepare their boards. Therefore, we should have a "board setup" lab that goes through the process of reflashing the board with the appropriate U-Boot version/configuration. This must be added to our lab instructions.

I have followed all the instructions as per this slides : https://bootlin.com/doc/training/embedded-linux-qemu/embedded-linux-qemu-labs.pdf to build the cross-compiler, but after that while building u-boot, I am getting this error, can anyone help me share the cross-compiler .config file such that I can tally, as I think the problem is with compiler only, but I have followed all the instructions while building compiler.
Here is my u-boot building error, I have also followed all steps for making the u-boot, but it is not working !

{standard input}: Assembler messages:
{standard input}:43: Error: selected processor does not support `dsb sy' in ARM mode
{standard input}:47: Error: selected processor does not support `isb sy' in ARM mode
{standard input}:240: Error: selected processor does not support `dsb sy' in ARM mode
{standard input}:244: Error: selected processor does not support `isb sy' in ARM mode
{standard input}:367: Error: selected processor does not support `dsb sy' in ARM mode
{standard input}:459: Error: selected processor does not support `dsb sy' in ARM mode
{standard input}:463: Error: selected processor does not support `isb sy' in ARM mode
{standard input}:596: Error: selected processor does not support `dsb sy' in ARM mode
make[1]: *** [scripts/Makefile.build:279: arch/arm/cpu/armv7/cache_v7.o] Error 1
make: *** [Makefile:1727: arch/arm/cpu/armv7] Error 2

Perhaps this part should be made much smaller now that the device tree has been broadly accepted. We could still have a couple of slides about "how it was done before" but that is all.

Should we talk about the interaction with the firmware? With ACPI?

Instead of presenting the links between all the structures and never show how to retrieve that effectively in the slides, add example with various framework interfaces to retrieve data (foo_get_privdata(), container_of, etc)

First, thank you guys so much for putting together these embedded linux slides and labs and making them freely available. They have been a tremendous help in better understanding all the nuances of the embedded linux development ecosystem.

In the latest embedded-linux-lab.pdf (7/22/21) when talking about using UBIFS and UBI images on p. 28, you say:

"Also remove the SD card, to resume to the former way of booting. That’s important because
there is currently an issue with U-Boot compiled from the MMC configuration, which causes
UBI incompatibilities between U-Boot and Linux."

Would you please consider adding a footnote here to provide some additional information about this issue similar to footnote 13 in which you give an excellent description about needing to use the trimffs option with nand write to prevent running into ECC issues when writing the UBI images. My confusion with the existing information is whether or not this is a quirk of the particular hardware platform, a particular version of u-boot, or if this is a general issue with trying to pass a ubifs to linux when u-boot is using an environment located in mmc.

The first few times I tried to work through this section I glanced right over the line that mentioned removing the SD card and I kept getting strange ubi read errors related to bad ecc values when booting my kernel ubi_io_read: error -74 (ECC error). I dug through the config and .dts files for both u-boot and the kernel looking for anything related to NAND, ECC, and/or UBI trying to diagnose the issue, but I was unable to locate the source of the problem.

This is something really specific on tooling and it does not add any valuable information.

The LICENSE strings have been modified in OE-core, so that license strings are obsolete now in our slides. They should use the SPDX license names.

Example of a change:
LICENSE = "GPLv2"
should be replaced by
LICENSE = "GPL-2.0-only"

This doesn't impact our labs yet (based on Dunfell), but the next release (3.5 Kirstone) will make our slides obsolete.
Keep this as a reminder.

[Grogory's idea]
Too much time spent explaining system-wide features?

Share Yocto Projects resources for reducing space and therefore boot-time:
https://docs.yoctoproject.org/dev-manual/common-tasks.html#building-a-tiny-system

Some of the scripts, such as ksize.py, also apply outside of the scope of the Yocto project.

It landed in the middle of the DT slides like "a cheveux sur la soupe".

I am using BBB and Linux kernel and driver development training. Steps in the material are unclear on how to config the kernel for BBB board! Is arch/arm/configs/omap2plus_defconfig the file that needs to used as .config? OR is there any target in kernel's make to pick corresponding target for am335x boards?

The "atime" based technique used to detect which files are accessed during the boot process doesn't work any more.
The files accessed during the boot process don't get an access time in 1970 any more, which allowed to distinguish them from other files.
That's probably because the root filesystem is mounted with the "relatime" mount option by default. How to change the rootfs mount options from the kernel command line?
Otherwise, any other (simple) idea for detecting files accessed at boot time? Or the ones not accessed at boot time?

These arguments were worth spending time on when the course was created.
They are still relevant, but people need less convincing.
This could save valuable time for technical topics.
At least, we could fit them in a single slide.

Should it be developed and moved in the standard slide deck? (currently an "if time" topic)

The slides after the explanation of the LTS are more explaining Git than the contribution workflow. It would be nice to update these slides as Git is now quite popular and does not need to be explained in details anymore.

The lab in which a kernel boot graph is generated is currently broken.
The information needed by scripts/bootgraph.pl is no longer available in the dmesg output.
Because of this, this part of the kernel optimization lab is no longer available.
An idea is to test with a more recent kernel.

Rather than making copies of Buildroot sources, use instead out of tree building to compile multiple rootfs and toolchains from the same sources, while keeping the ability to switch between them without having to rebuild everything.

I wasnt able install dependency: latex-beamer in Ubuntu20.04.

In addition, I had to install texlive-plain-generic, it complains missing file: ulem.sty, otherwise.