ST Distribution Image on OSD32MP1-BRK board

This topic has 2 replies, 2 voices, and was last updated 4 years, 1 month ago by Mo.Elhawy.

Viewing 2 reply threads

Author
Posts

August 30, 2020 at 9:31 pm #10619
Mo.Elhawy
Participant
Hello,
I am new to the embedded Linux world, I was working on a project on STM32mp157c-DK2 board and I found an example on ST wiki that helped me quite a lot. I was able to modify the Linux user space application and the firmware of the example to suit my needs. Then I wanted access to more GPIO pins, so I got the OSD32MP1-BRK board but I now am having difficulties to run the system on the OSD32MP1-BRK board (which is already running on the STM32mp157c-DK2).
I used to flash the image using the STM32CubeProgrammer using the .tsv file from the distribution package, this doesn’t seem to be the case with the OSD32MP1-BRK as it is recommended in the getting started page to use balenaEtcher application to flash a provided image directly on the SDcard, the provided image is a .zip file and doesn’t have a .tsv file like ST distribution package ones.
I tried to use the SDcard flashed by STM32CubeProgrammer with the ST starter package on the OSD32MP1-BRK but that didn’t work (the log file is attached). The boot loader stops and doesn’t load the kernel from the SDcard and tries to boot over usb. Another interesting line in the log is “Fastboot key pressed, STM32Programmer key pressed, entering download mode…”, please consider that I have set the boot mode switches correctly and everything is working just fine if I am using the image provided by OCTAVO.
My question is how to run an image that is running on another st board on the OSD32MP1-BRK, what exactly should I change?, or is there a distribution package based also on yocto project that can generate an image configured for the OSD32MP1-BRK board?
Best regards,
ELhawy
Attachments:
1. Log.txt
September 2, 2020 at 5:02 pm #10650
Neeraj Dantu
Moderator
ELhawy,
There are multiple ways to run images from other development boards on the BRK. But, before doing that, there are important changes you need to make to the board configuration as the hardware is not the same on the DK2 and the BRK.
Notably, the BRK does not have the USB-C configuration of the DK-2. The error you are experiencing is because on the DK2, U-Boot(second stage bootloader) performs checks for the USB-C configuration and stops because it cannot verify the configuration.
Ideally, you would need to change the device trees for TF-A, U-Boot and the Kernel to modify the image to boot from the BRK. Because the BRK has the same SD-card configuration as the DK2 (minus the card detect pin), it is possible to run DK2 images with minor modifications. Mainly, you will need to change the following configurations:
Get rid of the ADC configuration here: https://github.com/STMicroelectronics/u-boot/blob/v2020.01-stm32mp/arch/arm/dts/stm32mp15xx-dkx.dtsi#L100
Get rid of fastboot and adc configuration here: https://github.com/STMicroelectronics/u-boot/blob/v2020.01-stm32mp/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi#L21.
Altering or recompiling can be done by use of Developer Package: https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package.
Please make sure you are working on the appropriate kernel version as ST has recently updated the BSP. The current BRK device tree image and device tree is for 4.19 Kernel, while work on support for Kernel 5.4 is on the way.
Best,
Neeraj

September 10, 2020 at 9:13 am #10728

Participant

Thanks Neeraj,
Your reply was quite clear and helpful, but applying only these modifications to u-boot device tree wasn’t enough to get the Kernel to be booted, the second stage boot loader (u-boot) still checks for Stm32CubeProgrammer pin and if it is active the boot loader doesn’t load the Kernel. I found some solutions to overcome this problem for any image that is configured for DK2 board.

Modifying stm32mp1.c file in u-boot source to stop the boot loader from checking the Stm32CubeProgrammer pin (PA14), this check is on board_key_check() function in the below lines:

if (gpio_request_by_name_nodev(node, "st,stm32prog-gpios", 0,
			       &amp;gpio, GPIOD_IS_IN)) {
	debug("%s: could not find a /config/st,stm32prog-gpios\n",
	      __func__);
} else {
	if (dm_gpio_get_value(&amp;gpio)) {
		puts("STM32Programmer key pressed, ");
		boot_mode = BOOT_STM32PROG;
	}
	dm_gpio_free(NULL, &amp;gpio);
}

I have also attached the modified file with these lines commented (lines 147 to 159)

if (gpio_request_by_name_nodev(node, "st,stm32prog-gpios", 0,

&gpio, GPIOD_IS_IN)) {

debug("%s: could not find a /config/st,stm32prog-gpios\n",

__func__);

} else {

if (dm_gpio_get_value(&gpio)) {

puts("STM32Programmer key pressed, ");

boot_mode = BOOT_STM32PROG;

}

dm_gpio_free(NULL, &gpio);

}

I have also attached the modified file with these lines commented (lines 147 to 159)

Connecting PA14 pin on the board to logic high.
Changing PA14 configuration in the device tree from active low to active high. (stm32mp157a-dk1-u-boot.dtsi line 22), I am not sure if removing the configuration for PA14 by removing this line may cause any problems.

ST Distribution Image on OSD32MP1-BRK board

Attachments: