This article has been rewritten and reorganized using artificial intelligence (AI) based on referenced technical documentation. The purpose is to present the content in a clearer and more accessible manner. For technical clarifications or further verification, readers are advised to consult the original documentation or contact relevant technical personnel.
Imagine you have a device with the latest Advantech hardware that needs a system or firmware update. In the past, this might have required specific tools or complex steps. But what if we could make this process as simple as using a USB flash drive, or even smarter? This is exactly what Advantech engineers recently achieved in an interesting experiment!
This time, our R&D team tackled a specific hardware scenario: where the hardware design uses a “General Purpose Input/Output pin” (GPIO) to act as the USB “Identification pin” (ID pin). This ID pin is like a small signal from the hardware to the software, telling it which mode the USB should operate in (e.g., as a host connecting to other devices, or as a device connected to a computer). In this specific design, how can we ensure that we can smoothly use UUU (Universal Update Utility), a powerful tool, to flash or update the Android operating system? This was the goal of our experiment!
Why This Is Important? Understanding UUU and the ID Pin #
In the world of embedded systems, “Flashing” refers to installing an operating system or firmware onto the hardware’s storage space, just like installing Windows or Linux on your computer. UUU is a tool developed by NXP that makes this flashing process faster and more reliable, especially during the development phase or when mass deployment is needed.
The ID pin, on the other hand, is a hardware design detail. In some USB connectors (especially Micro-USB or Type-C), there is a dedicated ID pin to determine the USB’s role. However, sometimes, for hardware design flexibility or circuit simplification, engineers might choose to use a regular GPIO pin to simulate the function of this ID pin. The advantage of this is more flexible hardware design, but the challenge is that the software (especially the underlying bootloader and operating system) must be able to correctly identify and handle the state of this ID pin simulated by the GPIO.
Our goal was to make the UUU flashing process work seamlessly on the Android system under this specific hardware design where a “GPIO is used as the ID pin”.
Experiment Revealed: From Bootloader to System Kernel #
To achieve this goal, our engineers delved into two key parts of the system: U-boot and the Linux Kernel.
First Stage: U-boot Bootloader #
U-boot is the first program executed when the device starts; it is responsible for initializing the hardware and loading the operating system. If U-boot cannot correctly identify the USB interface, subsequent flashing naturally cannot proceed.
In the experiment, we first modified U-boot’s configuration file (imx8mp_rsb3720a1_android_4G_uuu_defconfig) to ensure that the relevant USB settings were correct:
# CONFIG_USB_TCPC is not set
At the same time, we also adjusted the compilation settings (UbootKernelBoardConfig.mk under /\<BSP>/device/fsl) to specify the use of this new configuration file:
TARGET_BOOTLOADER_CONFIG += imx8mp-evk-uuu:imx8mp_rsb3720a1_android_4G_uuu_defconfig
During the experiment, we encountered a USB initialization failure error message (USB init failed: -22). At this point, the engineers, like detectives, used the commands provided by U-boot to check the USB status:
u-boot=> usb start
u-boot=> usb info
By observing the output messages, such as:
u-boot=> usb start
starting USB...
Bus usb@38100000: Failed to initialize board for imx8m USB
probe failed, error -22
Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38200000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
We found that the problem was with the usb@38100000 USB controller. Further checking the hardware’s “Device Tree Blob” (DTB) configuration file, the DTB is like a map and manual from the hardware to the software, telling the software where each hardware component is and what its attributes are. We checked the node corresponding to 38100000:
usb_dwc3_0: dwc3@38100000 {
compatible = "snps,dwc3";
reg = <0 0x38100000 0 0x10000>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usb3_phy0>, <&usb3_phy0>;
phy-names = "usb2-phy", "usb3-phy";
xhci-no-64bit-support;
usb3-resume-missing-cas;
snps,dis-u2-freeclk-exists-quirk;
snps,soft-itp-sync;
status = "disabled";
};
We found that status was set to "disabled"! This was the problem. After fixing this setting, U-boot was able to initialize the USB correctly.
Finally, the command used for UUU flashing is as follows:
$ ./uuu_imx_android_flash.sh -f imx8mp -a -e
This command will automatically complete the subsequent flashing process.
Second Stage: Linux Kernel System Core #
It’s not enough for just U-boot to recognize the USB; the operating system itself (Linux Kernel) must also know how to handle this GPIO-controlled ID pin, especially regarding functions related to OTG (On-The-Go) and ADB (Android Debug Bridge). OTG allows the device to switch between host and device modes, while ADB is a commonly used tool for Android development and debugging; both heavily rely on correct USB identification.
Based on our experience in the ROM-5722 project, modifications to the Kernel’s code were necessary. Specific changes can be referenced at this link: https://github.com/ADVANTECH-Corp/linux-imx/commit/f35c86e76abf7967b487800602ebf75e097fbf7c
The core of this code modification is to tell the Kernel how to read the state of that specific GPIO pin and configure the USB’s OTG function correctly based on this state, ensuring that ADB connections and other functions work properly.
Experiment Results and Value #
After the aforementioned modifications and verification of U-boot and the Kernel, we successfully achieved smooth UUU flashing of the Android system on the Advantech hardware platform that uses a GPIO as the ID pin!
This achievement represents:
- More Flexible Hardware Design: Our hardware designers can plan USB interfaces more freely, without being limited by traditional ID pin designs.
- More Comprehensive Software Support: Advantech’s BSP (Board Support Package) can perfectly support this special hardware configuration, ensuring seamless collaboration between software and hardware.
- More Convenient Customer Updates: For customers using relevant Advantech products, this means they can use efficient tools like UUU for system updates or restoration, simplifying the maintenance process.
This experiment not only solved a specific technical challenge but also demonstrated Advantech’s profound strength in hardware design, low-level software development, and system integration. We don’t just provide hardware; we invest resources to ensure that software can perfectly control every detail of the hardware.
Conclusion and Future Outlook #
This successful UUU flashing experiment supporting the GPIO ID pin is an important milestone on Advantech’s path to providing flexible and high-performance solutions. It proves that our engineering team has the capability to delve into the low-level details and solve complex hardware and software integration issues.
In the future, we will continue to invest in R&D, exploring more innovative hardware designs and software support solutions, ensuring that Advantech’s products always stay at the forefront of technology, providing customers with more stable, flexible, and easy-to-use industrial IoT solutions. Please look forward to more exciting technological breakthroughs from Advantech!