Is it possible with uboot drives digital output? I need that my board turn on some led during uboot and during torizon boot. I need to wait a minute (IMX6ULL systemd and containers) before my application starts and i haven’t information during this time from my carrier board.
My questions are
- Can I drive output when uboot starts
- How can I drive this output also during torizon boot (maybe with some application but it should be start before systemd and containers and how can access to IO with torizon I/O libraries work only in the container)
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Driving a digital output, such as turning on an LED during the boot process, can indeed be achieved both during the U-Boot phase and while Torizon is booting. Here’s how you can accomplish this for a board based on the iMX6ULL processor:
During U-Boot
-
Modify U-Boot Source Code: To drive an output during U-Boot, you would typically modify the board initialization code in the U-Boot source specific to your board. This involves identifying the GPIO pin connected to the LED and configuring it as an output, then setting the pin to the desired state (high or low) to turn the LED on or off.
-
Compile and Flash U-Boot: After making the necessary changes, recompile U-Boot and flash it onto your device. This process is specific to your hardware and the development setup you are using.
During Torizon Boot
For driving the output during the Torizon boot process, before systemd and containers are fully up and running, you have a couple of options:
-
Early Userspace Script: Implement an early userspace script or program that runs at the earliest possible point in the boot process. This can be achieved by integrating your script with initramfs. Your script would need to directly access the GPIO sysfs interface or use a minimal C program to manipulate the GPIOs. Note that with the introduction of the newer GPIO character device interface (/dev/gpiochip*), you might prefer using libgpiod, which is a C library and tools for interacting with the GPIO character device.
-
Modify Systemd Service Dependencies: If you need the output to be driven slightly later in the boot process but before your main application starts, you could create a custom systemd service. This service would run a script or program that drives the GPIO. You would set this service to start early in the boot process by carefully managing its dependencies, ensuring it starts before the Docker daemon and your application containers.
Accessing I/O in Torizon
In Torizon, GPIO access is typically managed within containers using the TorizonCore I/O libraries or direct access to the GPIO sysfs or GPIO character device interface. For early boot scenarios, since your application would be running outside of a container, you would directly use the sysfs interface or libgpiod from your early userspace script or systemd service.
Please note, modifying U-Boot and integrating custom scripts into the boot process requires a good understanding of your hardware and the boot
Please, also check if these links can help you solve your problem:
Torizon OS Boot Time Optimization | Toradex Developer Center.
How can I create initramfs script?
How can I add libgpiod to torizon outside of the container?
Hello @fabrizio.camagna,
I am not so sure if using sysfs interface is a good approach since this is a deprecated method of controlling gpios anyway. What I would recommend doing in your case is to use GPIO hogging. You need to modify your device tree or write a device tree overlay file to enable this feature. This is a simple example of how you can hog a pin high:
gpio_hog_led {
gpio-hog;
gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "led-on-boot";
};
Thank you but I have an issue
this work properly with tcb (SODIMM_104)
&gpio1 {
gpio_hog_led
{
gpio-hog;
gpios = <7 0>;
output-high;
line-name = “led-red-on-boot”;
};
};
but this during tcb build give me not applicable (SODIMM_102)
&gpio0 {
gpio_hog_led
{
gpio-hog;
gpios = <15 0>;
output-high;
line-name = “led-green-on-boot”;
};
};
this the error
=> Selecting custom device-tree ‘linux/arch/arm/boot/dts/imx6ull-colibri-emmc-eval-v3.dts’
‘imx6ull-colibri-emmc-eval-v3.dts’ compiles successfully.
warning: removing currently applied device tree overlays
Device tree imx6ull-colibri-emmc-eval-v3.dtb successfully applied.
=> Adding device-tree overlay ‘device-trees/overlays/colibri-imx6ull_sert_overlay.dts’
‘colibri-imx6ull_sert_overlay.dts’ compiles successfully.
Failed to apply ‘/tmp/tmpqir_svli’: FDT_ERR_NOTFOUND
error: cannot apply device tree overlays [‘/tmp/tmpqir_svli’] against device tree /storage/dt/usr/lib/modules/6.1.111-6.8.0-devel+git.e526b12bf916/dtb/imx6ull-colibri-emmc-eval-v3.dtb.
error: overlay ‘device-trees/overlays/colibri-imx6ull_sert_overlay.dts’ is not applicable
Hello @fabrizio.camagna,
The error you see is likely because the node gpio0 is not found.
As you can see on imx6ull-colibri-emmc-nonwifi.dtsi, SODIMM_104 is part of gpio2 and SODIMM_102 is part of gpio1.
Therefore, your device tree overlay needs to be adjusted accordingly.
It is surprising that the configuration for SODIMM_104 worked, have you verified this on an actual device?
Best Regards,
Bruno
Hi
when i use
gpiod_ctxless_find_line(“SODIMM_104”, bank, sizeof(bank), &line);
I have gpiochip1 line=7
gpiod_ctxless_find_line(“SODIMM_102”, bank, sizeof(bank), &line);
gpiochip0 line=15
and I’m sure because I’m using 2 led and they work properly, maybe these names are not the same?
Hello @fabrizio.camagna,
The numbering in terms of gpiochip on Linux and the device tree usually differs, as the device tree starts counting from 1.
This can be confusing, but in this case the file I pointed to should make the numbering clear for the device tree.
Best Regards,
Bruno
ok thank you but the following overlay works properly but when linux starts I can’t drive leds anymore, they stay on and my application can’t drives.
// SODIMM_102 GREEN LED
&gpio1 {
pinctrl-names = “default”;
gpio_hog_led
{
gpio-hog;
gpios = <15 0>;
output-low;
line-name = “led-green-on-boot”;
};
};
// SODIMM_104 RED LED
&gpio2 {
pinctrl-names = “default”;
gpio_hog_led
{
gpio-hog;
gpios = <7 0>;
output-low;
line-name = “led-red-on-boot”;
};
};
Hello @fabrizio.camagna,
You see this behavior because the gpio-hog sets the GPIO pin to a specific state, which cannot be changed.
What could be done alternatively is to set those pins to the desired value early, in u-boot or/and in Linux.
Best Regards,
Bruno
Hello @fabrizio.camagna,
Do you need further support with this topic?
Best Regards,
Bruno
