Visitor II

Solved

Change default tf-a and u-boot serial linux console.

Forum|Forum|4 years ago
October 25, 2021
15 replies
11016 views

Hello, my main seriale console should be USART2 instead of UART4. I modified the kernel dts as follows:

	chosen {
		stdout-path = "serial0:115200n8";
	};
 
	aliases {
		ethernet0 = &ethernet0;
		mmc0 = &sdmmc1;
		mmc1 = &sdmmc2;
		serial0 = &usart2;
	};

and it configures correctly the kernel console.

If I try the same modification in tf-a and u-boot dts, at boot i see the log starting on uart4, but it blocks at this point

Preparing exit to normal world 
No serial driver found

Should I modify some boot env too?

This topic has been closed for replies.

Best answer by Lmoio.1

Hi,

For the uboot project , I added CONFIG_DEBUG_UART_BASE=0x4000E000 (usart2 base address) in the defconfig, I added

chosen {

stdout-path = "serial0:115200n8";

};

aliases {

ethernet0 = &ethernet0;

mmc0 = &sdmmc1;

mmc1 = &sdmmc2;

serial0 = &usart2;

serial1 = &uart4;

};

&pinctrl {

usart2_pins_d: usart2-2 {

pins1 {

pinmux = <STM32_PINMUX('D', 5, AF7)>; /* USART2_TX */

bias-disable;

drive-push-pull;

slew-rate = <3>;

};

pins2 {

pinmux = <STM32_PINMUX('D', 6, AF7)>; /* USART2_RX */

bias-disable;

bias-pull-up;

};

usart2_idle_pins_d: usart2-idle-2 {

pins1 {

pinmux = <STM32_PINMUX('D', 5, ANALOG)>; /* USART2_TX */

};

pins2 {

pinmux = <STM32_PINMUX('D', 6, AF7)>; /* USART2_RX */

bias-disable;

};

usart2_sleep_pins_d: usart2-sleep-2 {

pins {

pinmux = <STM32_PINMUX('D', 5, ANALOG)>, /* USART2_TX */

<STM32_PINMUX('D', 6, ANALOG)>; /* USART2_RX */

};

&usart2 {

pinctrl-names = "default", "sleep", "idle";

pinctrl-0 = <&usart2_pins_d>;

pinctrl-1 = <&usart2_sleep_pins_d>;

pinctrl-2 = <&usart2_idle_pins_d>;

status = "okay";

};

in the .dts.

I added this part also in the dts of the tf-a project.

Then i generated the fip bianary file. When flashing, I see cubeprogrammer Logs on usart2.

Show previous replies

G

gianlucarenzi

Visitor II

@Lmoio.1 I did not write that, but my dts has the same descriptions/settings for the usart1 pins:

&usart1{
	u-boot,dm-pre-reloc;
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&usart1_pins_z_mx>;
	pinctrl-1 = <&usart1_sleep_pins_z_mx>;
	status = "okay";
};

and for the pinmux section:

&pinctrl_z {
	u-boot,dm-pre-reloc;
 
	usart1_pins_z_mx: usart1_mx-0 {
		pins1 {
			u-boot,dm-pre-reloc;
			pinmux = <STM32_PINMUX('Z', 6, AF7)>; /* USART1_RX */
			bias-disable;
		};
		pins2 {
			u-boot,dm-pre-reloc;
			pinmux = <STM32_PINMUX('Z', 7, AF7)>; /* USART1_TX */
			bias-disable;
			drive-push-pull;
			slew-rate = <0>;
		};
	};
 
	usart1_sleep_pins_z_mx: usart1_sleep_mx-0 {
		u-boot,dm-pre-reloc;
		pins {
			pinmux = <STM32_PINMUX('Z', 6, ANALOG)>, /* USART1_RX */
					 <STM32_PINMUX('Z', 7, ANALOG)>; /* USART1_TX */
		};
	};
 
};

Actually, STM32CubeMX does not include any _idle sections as yours, but I think it's not an issue. Using the following config for build u-boot:

CONFIG_DEBUG_UART=y

CONFIG_DEBUG_UART_BASE=0x5C000000

CONFIG_LOG=y

CONFIG_LOG_CONSOLE=y

CONFIG_SPL_LOG=y

CONFIG_SPL_LOG_CONSOLE=y

and modifying accordingly the spl.c file to be adapted for usart1, I can clearly see the output in my serial terminal, so I suppose it's not a serial issue, but something else. Clocks? Initialization? During relocation?

Any ideas?

Regards,

Gianluca

L

Lmoio.1Author

Visitor II

Hi,

have you added in the tf-a dts the following:

DECPROT(STM32MP1_ETZPC_USART1_ID, DECPROT_NS_RW, DECPROT_UNLOCK).

Maybe it could be a problem related to GPIOZ pins assigned to the secure context? Can you post your log?

Lidia

G

gianlucarenzi

Visitor II

I am not using TF-A, just normal SPL & u-boot load fsbl1 & fsbl2 and ssbl.

Is there any chance on JTAG debugging without having boot from SD Card? Just to know if there is a quick way to check whats happening.

I tried with openocd and gdb, and having break points in _start and _main it hangs on a cpu.c where security_init manage some busy loop tests. If I commented out the security_init, it crashes with undefined instruction in the update_bootmode() function.

I am very close to have a running custom board with it, but it is hard to find out what's going on. Anyway the low level serial output *IS ON THE RIGHT USART1* as I am seeing it crashing and resetting. So I suppose something about the relocation of the device-tree or not so well initialized device-tree structure in static RAM.

If I compile the u-boot & spl for STM32MP157C-DK2 (the EVK I own) it runs very good. And the differences are very little:

CPU 157C instead of 151A
DeviceTree wise the pin, clocks configuration nodes are naturally different,
All the rest of code is identical

The devicetree from my point-of-view is automatically generated by STMCubeMX (latest version as today's) and the u-boot,dm-pre-reloc are in every node I need to use in the SPL.

Here is the configuration I am using in u-boot 2021-01-rc1:

CONFIG_ARM=y
CONFIG_ARCH_STM32MP=y
CONFIG_SYS_MALLOC_F_LEN=0x3000
CONFIG_SYS_MEMTEST_START=0xc0000000
CONFIG_SYS_MEMTEST_END=0xc4000000
CONFIG_ENV_OFFSET=0x280000
CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_SPL_DM_SPI=y
CONFIG_DEFAULT_DEVICE_TREE="stm32mp151a-ek440-mx"
CONFIG_SPL_TEXT_BASE=0x2FFC2500
CONFIG_SPL_MMC=y
CONFIG_SPL=y
CONFIG_TARGET_ST_STM32MP15x=y
CONFIG_CMD_STM32KEY=y
CONFIG_CMD_STM32PROG=y
CONFIG_ENV_OFFSET_REDUND=0x2C0000
CONFIG_TYPEC_STUSB160X=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI=y
# CONFIG_ARMV7_VIRT is not set
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0xc2000000
CONFIG_FIT=y
CONFIG_BOOTDELAY=1
CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
CONFIG_SPL_LOG=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_I2C=y
CONFIG_SPL_MTD_SUPPORT=y
CONFIG_SPL_DM_SPI_FLASH=y
CONFIG_SPL_POWER=y
CONFIG_SPL_SPI_FLASH_MTD=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x80000
CONFIG_SYS_PROMPT="STM32MP> "
CONFIG_CMD_ADTIMG=y
CONFIG_CMD_ERASEENV=y
CONFIG_CMD_NVEDIT_EFI=y
CONFIG_CMD_MEMINFO=y
CONFIG_CMD_MEMTEST=y
CONFIG_CMD_UNZIP=y
CONFIG_CMD_ADC=y
CONFIG_CMD_CLK=y
CONFIG_CMD_DFU=y
CONFIG_CMD_FUSE=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_MMC=y
CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
CONFIG_CMD_BMP=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_EFIDEBUG=y
CONFIG_CMD_TIME=y
CONFIG_CMD_RNG=y
CONFIG_CMD_TIMER=y
CONFIG_CMD_PMIC=y
CONFIG_CMD_REGULATOR=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_LOG=y
CONFIG_CMD_UBI=y
# CONFIG_SPL_DOS_PARTITION is not set
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-names interrupts-extended interrupt-controller \\\#interrupt-cells interrupt-parent dmas dma-names assigned-clocks assigned-clock-rates assigned-clock-parents hwlocks"
CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_IS_IN_UBI=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_ENV_UBI_PART="UBI"
CONFIG_ENV_UBI_VOLUME="uboot_config"
CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_SYS_MMC_ENV_DEV=-1
# CONFIG_SPL_ENV_IS_NOWHERE is not set
# CONFIG_SPL_ENV_IS_IN_SPI_FLASH is not set
CONFIG_STM32_ADC=y
CONFIG_SET_DFU_ALT_INFO=y
CONFIG_USB_FUNCTION_FASTBOOT=y
CONFIG_FASTBOOT_BUF_ADDR=0xC0000000
CONFIG_FASTBOOT_BUF_SIZE=0x02000000
CONFIG_FASTBOOT_USB_DEV=1
CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=1
CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y
CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0"
CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1"
CONFIG_FASTBOOT_MMC_USER_SUPPORT=y
CONFIG_FASTBOOT_MMC_USER_NAME="mmc1"
CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y
CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y
CONFIG_GPIO_HOG=y
CONFIG_DM_HWSPINLOCK=y
CONFIG_HWSPINLOCK_STM32=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_STM32F7=y
CONFIG_LED=y
CONFIG_LED_GPIO=y
CONFIG_DM_MAILBOX=y
CONFIG_STM32_IPCC=y
CONFIG_STM32_FMC2_EBI=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_STM32_SDMMC2=y
CONFIG_MTD=y
CONFIG_DM_MTD=y
CONFIG_SYS_MTDPARTS_RUNTIME=y
CONFIG_MTD_RAW_NAND=y
CONFIG_NAND_STM32_FMC2=y
CONFIG_SYS_NAND_ONFI_DETECTION=y
CONFIG_MTD_SPI_NAND=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_WINBOND=y
# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
CONFIG_SPI_FLASH_MTD=y
CONFIG_PHY_REALTEK=y
CONFIG_DM_ETH=y
CONFIG_DWC_ETH_QOS=y
CONFIG_PHY=y
CONFIG_PHY_STM32_USBPHYC=y
CONFIG_PINCONF=y
# CONFIG_SPL_PINCTRL_FULL is not set
CONFIG_PINCTRL_STMFX=y
CONFIG_DM_PMIC=y
# CONFIG_SPL_PMIC_CHILDREN is not set
CONFIG_PMIC_STPMIC1=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_DM_REGULATOR_STM32_VREFBUF=y
CONFIG_DM_REGULATOR_STPMIC1=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_DM_RNG=y
CONFIG_RNG_STM32MP1=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_STM32_SPI=y
CONFIG_USB=y
CONFIG_DM_USB_GADGET=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
CONFIG_USB_GADGET_VENDOR_NUM=0x0483
CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
CONFIG_USB_GADGET_DWC2_OTG=y
CONFIG_DM_VIDEO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
CONFIG_VIDEO_BMP_RLE8=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
CONFIG_WDT=y
CONFIG_WDT_STM32MP=y
CONFIG_ERRNO_STR=y
CONFIG_FDT_FIXUP_PARTITIONS=y
# CONFIG_LMB_USE_MAX_REGIONS is not set
CONFIG_LMB_MEMORY_REGIONS=2
CONFIG_LMB_RESERVED_REGIONS=16
CONFIG_DEBUG_UART=y
CONFIG_DEBUG_UART_STM32=y
CONFIG_DEBUG_UART_BASE=0x5C000000
CONFIG_LOG=y
CONFIG_LOG_CONSOLE=y
CONFIG_SPL_LOG=y
CONFIG_SPL_LOG_CONSOLE=y

Can anybody out-there give me an hint on to proceed further?

Regards,

Gianluca

O

Olivier GALLIEN

Technical Moderator

Hi @gianlucarenzi ,

"The devicetree from my point-of-view is automatically generated by STMCubeMX (latest version as today's) "

This sentence put me on the track of 2 possible issues:

First, latest STM32CubeMX support only latest DV3.0 and related BSP component. In this release U-boot SPL is no longer supported, except for DDR Utility.
STM32CubeMX generate a ready to boot DT for DK board project .. but not for MP151A project. You have to pay attention to complete it by filling USER SECTION.You can use the DK one as reference.

Hope it help

Olivier

G

gianlucarenzi

Visitor II

At the moment, I am digging more carefully at the device-tree stuff, and adapting from others stm32mp1 based board dts files in the u-boot git (2022.01.rc1) and using uart4 as the stm32157c-dk2 I have, now the prompt appear on the console, so it looks like somewhere there is a *hardcoded* configuration (I am supposing something related to usart1 clocks initialization) that it brings the card to resetting on booting. Anyway now I am looking for the correct device-tree initialization stuff, accessing to devices (pmic) and others directly to u-boot prompt. As soon as everything is working good, I will jump to Linux.

Anyway I had to have 4 more files ( .dts, .dtsi, -u-boot.dtsi and ddr3 setup ) to enable all stuff correctly in u-boot. Now I tested 512MB with mtest and it takes more than 5 minutes. Is it normal?

The console output is giving me those informations:

U-Boot SPL 2022.01-rc1 (Nov 17 2021 - 18:31:57 +0100)

RAM: EK440 DDR3-DDR3L 16bits 533000kHz

WDT: Started watchdog@5a002000 with servicing (32s timeout)

U-Boot 2022.01-rc1 (Nov 17 2021 - 18:31:57 +0100)

CPU: STM32MP151AAA Rev.Z

Model: Eurek EK440

Board: stm32mp1 in basic mode (eurek,ek440)

DRAM: 512 MiB

Clocks:

- MPU : 650 MHz

- MCU : 208.878 MHz

- AXI : 266.500 MHz

- PER : 24 MHz

- DDR : 533 MHz

WDT: Started watchdog@5a002000 with servicing (32s timeout)

NAND: 0 MiB

MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1

Loading Environment from MMC... *** Warning - bad CRC, using default environment

In: serial

Out: serial

Err: serial

invalid MAC address in OTP 00:00:00:00:00:00

Net:

Error: ethernet@5800a000 address not set.

No ethernet found.

Hit any key to stop autoboot: 0

After that I can stop the booting process and the uboot commands help me out to find what's working and what's not.

In attachment the device-tree files I was talking about before.

Can you check if there is some strange issue?

Regards,

Gianluca

O

Olivier GALLIEN

Technical Moderator

Hi @gianlucarenzi ,

First, u-boot git (2022.01.rc1) is not a version part of the delivered ST ecosystem.

The latest, part of the release DV3.1 done yesterday, is v2020.10-stm32mp1-r2

I advise you to use consistent DV3.1 BSP components for your development.

Then, we are here far from the initial post topic.

In case you would like further support from Community please post a new question.

Thanks,

Olivier

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded