Serial boot via the TAMP_REG[20] howto

[MVass.1]

Hi,

My bellow question is based on info read from:

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Configuration

and

https://wiki.st.com/stm32mpu/wiki/STM32MP15_backup_registers#Boot_mode_selection_feature

From those two links I understand that if ROM CODE sees "0xFF" in the BOOT_MODE register then it will not continue to TF-A and instead enter flashing mode.

The bellow is also mentioned:

"The Linux kernel can force a reboot mode by writing to the BOOT_MODE register.

This writing is done via the "reboot" Linux command,

which is configured via the compatible "syscon-reboot-mode" in the device tree."

What I want to achieve / understand if possible is to run a Linux userspace command to write 0xFF into BOOT_MODE and reboot the system.

I can't find a way to do this...

Also, just to make sure, If I am able to achieve the above, will the device boot into DFU mode ?

some background:

1. Playing with boot selection pins on the evaluation boards is easy, not so much on our production boards.
2. In addition I would like to remove support of stm32prog command from our U-boot and also remove the ability to stop u-boot with a key press (security reasons)

Thanks,

Michael

[Kevin HUBER · Accepted solution]

Hello @Community member​ ,

You understood well the behavior of TAMP_REG[20] alias BOOT_MODE. If the value put in this register backup is 0xFF, you will boot in serial mode at the next reboot.

Yes, this is possible to modify this register in a linux userspace context. For testing it easily, I recommend you to install devmem2 on your board:

https://wiki.st.com/stm32mpu/wiki/How_to_read_or_write_peripheral_registers

This wiki page will help you.

Then here the steps:

I - Find the address of the TAMP_REG[20] to modify it

1. To find the address of this register you have two way, the first one is from the Reference manual (v5.0 of ecosystem v3.1):

https://www.st.com/resource/en/reference_manual/DM00327659.pdf

Page 2532:

 

Since the base address of the TAMP Register is 0x5C00A000 (page 157):

 

The address of the backup register TAMP_REG[20] is:

0x5C00A000 + 0x100 + 0x04 * 0x14 = 0x5C00A150
0x14 because it's 20 in decimal

2 . Second way is to read the code of U-Boot directly

From the file: arch/arm/include/asm/arch/stm32.h

#define STM32_TAMP_BASE			0x5C00A000
 
/* TAMP registers */
#define TAMP_BACKUP_REGISTER(x)		(STM32_TAMP_BASE + 0x100 + 4 * x)
 
 
#define TAMP_BOOT_CONTEXT		TAMP_BACKUP_REGISTER(20)
 
Address of BOOT_MODE =  0x5C00A150

II - Be sure that the RCC clock is enabled

The bit 8 of register RCC_MP_APB5ENSETR must be enabled. You can find this information in page 831 of the refman:

 

By default this is normally the case with the ecosystem v3.1, but you can verify the value of the bit8 with devmem2:

root@stm32mp1:~# /usr/local/devmem2 0x50000208
/dev/mem opened.
Memory mapped at address 0xb6f17000.
Value at address 0x50000208 (0xb6f17208): 0x113900

III - Verify that the register is not protected in write operations

As explained in page 2512 of the reference manual, these registers are protected in write by two registers.

By DBP:

and BKPWDPROT:

 

I made the test on the stm32mp157C-DK2 with the linux 5.10.61 of the ecosystem v3.1 and by default these registers allows the edit of TAMP_REG 20.

IV - Write 0xFF in the TAMP_REG[20] register

Now that you are sure that everything is ok, you can write the value in the register:

root@stm32mp1:~# /usr/local/devmem2 0x5C00A150 w 0xFF
/dev/mem opened.
Memory mapped at address 0xb6f69000.
Value at address 0x5C00A150 (0xb6f69150): 0x1100
Written 0xFF; readback 0xFF
 
 
root@stm32mp1:~# /usr/local/devmem2 0x5C00A150
/dev/mem opened.
Memory mapped at address 0xb6f0e000.
Value at address 0x5C00A150 (0xb6f0e150): 0xFF

The second command allows to verify that the value was really wrote.

V - Reboot your board, you must be in serial boot mode

Just type "reboot".

The board must reboot and if you unplugged the usb cable you will see that the LD6 is blinking in red, which means you are in serial boot mode.

To go back in SD-Card mode, you just have to reboot again the board (with the reset button for example).

---------------------------

For you second question about u-boot:

In addition I would like to remove support of stm32prog command from our U-boot and also remove the ability to stop u-boot with a key press (security reasons)

• stm32prog

To remove the command stm32prog of U-Boot, you just have to open the menuconfig:

make menuconfig

Inside "ARM architecture" -> disable "command stm32prog for STM32CudeProgrammer", the configuration CMD_STM32PROG 

• Remove the ability to stop u-boot

This feature is managed by the command autoboot:

https://wiki.st.com/stm32mpu/wiki/U-Boot_overview#U-Boot_command_line_interface_-28CLI-29

You can read in the code of this command (file: common/autoboot.c) in the function "abortboot", that you can't abort the autoboot if the bootdelay value is 0:

static int abortboot(int bootdelay)
{
	int abort = 0;
 
	if (bootdelay >= 0) {

So you can edit the bootdelay value to 0 in the u-boot environment:

STM32MP> env set bootdelay 0
STM32MP> env save

Hope it helps,

Regards,

Kevin

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[Kevin HUBER]

Hi @Community member​ ,

For the latest point, about the bootdelay, I made a mistake. You must set it to "-2" to remove the "hit a key" feature:

STM32MP> env set bootdelay -2
STM32MP> env save

Regards,

Kevin

[MVass.1]

Hi @Kevin HUBER​ 

wow, an extremely detailed answer, thank you

I will check this on my boards

regarding removing stm32prog from u-boot & bootdelay= (-2)

I didn't ask about this, I just mentioned my reasoning behind needing to set TAMP[20] register.

I knew how to do this (and was about to correct you regarding the bootdelay = 0 first answer)

what I was not aware of, was Linux's feature to write to device registers from userspace with "devmem2".

Thanks,

Michael

[MVass.1]

It works, thanks again

IMO, you should add this info to the wiki page that mentions the TAMP_REG[20] info