Introduction to Embedded Linux Part 5 - Patch Device Tree for I2C in Yocto | Digi-Key Electronics

preview_player
Показать описание
Linux is a powerful operating system that can be compiled for a number of platforms and architectures. One of the biggest draws is its ability to be customized for an application. Tools like Buildroot, OpenWRT, and Yocto Project help us create custom Linux distributions for embedded systems.

In this video series, we will explore Buildroot and the Yocto Project. We also demonstrate how you might develop applications for embedded Linux. We will not dive into the specifics of how each of these systems work but give you a good starting place so you can read or watch more advanced material about working with embedded Linux.

In this episode, we look at enabling ports and peripherals on the microprocessor by creating a custom Linux kernel patch for the device tree. Specifically, we enable I2C port 5 on the STM32MP157D-DK1 so that we can use it to talk to a temperature sensor.

We also include the “i2cdetect” tool by enabling it in busybox.

We build the new kernel and device tree, flash the SD card, and boot our board. We connect the temperature sensor and probe it using i2cdetect.

Product Links:

Related Videos:

Related Project Links:

Related Articles:

Learn more:
Рекомендации по теме
Комментарии
Автор

Amazing watch. Would definitely like to see driver writing as well!!!

PerryScott-rh
Автор

Loving the series! Also wanted to say it would be awesome to see driver writing in the future!

Lukosite
Автор

Can't wait for the next one, This is gold!

exosdel
Автор

could you please explain about SPI interfacing in the device tree? and also explain register mapping and its settings.

janardhanacharikella
Автор

any idea why when I run the bitbake -c menuconfig busybox that I end up getting a warning: do_compile tained warnings

TerryBiberdorf
Автор

Free knowledge. Wow!
I wish all universities taught students like that 😁🤣😂

byteslee
Автор

One thing to mention is that when you edit the .config file via menuconfig you need to create a fragment file or save the defconfig, because if, for some reason, the linux recipe gets cleaned or unpacked again, your edit will be lost, and you will need to run menuconfig again.

techleef-tn
Автор

Hey, where can i read about this Linux I2C problem?! I was able to use i2c. And wondered what is the difference between library and driver. Can use both in my project. 😊

aleXelaMec
Автор

Hi do you know what is the new syntax for FILESEXTRAPATHS_prepend

Its giving me an error that I'm using older syntax

AbdulRehman-eqns
Автор

Can't wait for the next one! When will we write our own drivers?! For example for the SPI peripherals?! :D

GA
Автор

If this is a hack, what’s the right way to change the i2c clock speed? I’m using boot2qt on a Toradex SoM. I tracked down the imx8mp-verdin.dts file in the same directory you are using but changed the clock speed right there. I then used dtc to create a new dtb file which I copied to the /boot/ dir, however, it hasn’t changed the bus speed. Where is the kernel told which dtb file to load?

lusher
Автор

you would only change the status label to be equal "okay"

ahmedzain
Автор

Ugh! You've created the patch the really hard way. It is far easier to go to the git repository where the sources came from (down under tmp/work/....) and make your edits there. Then do one of the following:

"git diff" - which will make the diff file, that you can use as your patch

commit your change to your local git repo. Then use the "git format-patch" command against the new commit to let it generate the patch file, including its filename. You don't have to worry about messing up the git repository where the sources came from because it's all local and Bitbake will blow it away once you integrate the patch with your layer. Once it sees the patch, it will re-fetch the git repo (via a do_fetch step) and will then apply your patch (via a do_patch step) before compilation.

Using "git format-patch" is actually the best, because the resulting patch file will have information from the commit you made, including your e-mail address, its timestamp and the full commit message. So when bitbake later applies the patch, it should (using "git am" internally) apply it as a local commit, which you can then see in your local git clone's log.

Manually constructing a patch file is just painful and error prone for all but the most trivial instances.

Shamino
Автор

What is the reason for using a patch instead of modifying the original dts file?

viwx
Автор

I think I lost the plot in this part of the series.

優さん-nm