AM623: custom board not rebooting

I'm also attaching the system-controller node of the device tree:

	dmsc: system-controller@44043000 {
		compatible = "ti,k2g-sci";
		ti,host-id = <12>;
		mbox-names = "rx", "tx";
		mboxes = <&secure_proxy_main 12>,
			 <&secure_proxy_main 13>;
		reg-names = "debug_messages";
		reg = <0x00 0x44043000 0x00 0xfe0>;
		ti,system-reboot-controller;

		k3_pds: power-controller {
			compatible = "ti,sci-pm-domain";
			#power-domain-cells = <2>;
		};

		k3_clks: clock-controller {
			compatible = "ti,k2g-sci-clk";
			#clock-cells = <2>;
		};

		k3_reset: reset-controller {
			compatible = "ti,sci-reset";
			ti,system-reboot-controller;
			#reset-cells = <2>;
		};
	};

Hi Leonardo,

Does your board boot from eMMC or any other interface?

Leonardo Dutra said:

I would not like to reset only the eMMC to do so.

Can you please explain this? I am not sure what exactly do you mean.

Hello,

Yes, the board is booting from and eMMC device. About that comment: I know I could reboot Linux by resetting only the eMMC, but I would like to do so by resetting the system at all.

Yes, the reset pins and functionality in Linux are properly set.

Another thing I was attempting to make is to use the syscon-reboot driver. According to section 14.2.1.1.1.473.1 of the am62x reference manual, it is decribed the RST_CTRL register, which has the RST_CTRL_SW_MAIN_POR bit field ([7:4]). the absolute address for this register is 43018170. It is said that if I write "0110" to those bit fields, I can cause a POR reset. I used the devmem tool to test and indeed it causes a proper reboot to my system. So I tried to map it to my device tree to attach this register to the syscon-reboot driver as follows:

	reboot {
		compatible = "syscon-reboot";
		regmap = <&wkup_conf>;
		offset = <0x00018170>;
		value = <0x60>;
		mask = <0xF0>;
	};

But it did not work. I checked and the POWER_RESET_SYSCON driver is enabled in my kernel.

Leonardo Dutra said:

Another thing I was attempting to make is to use the syscon-reboot driver.

I am not sure this is a right thing to do. Do you understand the root cause of the reboot issue yet? You suppose to not need to modify kernel code for reboot to work.

I'm not sure if I get the point about the eMMC reset function. If I run "mmc hwreset enable /dev/mmcblk0" and run "reboot", what exactly is going to happen? only the emmc is resetting or the entire system is going to POR state?

Okay, here is one way to prove if eMMC reset is the problem causing reboot failure, at Linux prompt,

- run command 'devmem2 0x43000030 w 0x3b', then

- run command 'reboot'.

After Linux is shutdown, do you see 'CCCCCC...' characters on the console?

Actually I can't see any "C" character on the console

Please run the following commands instead then let me know if you see 'C' chars on the console?

# devmem2 0x43000030 w 0x3b
# devmem2 0x43018170 w 0x6

Here is what I see on my SK evm, which means reboot is succeeded and started with UART boot mode:

am62xx-evm login: root
Last login: Thu Apr 28 17:42:39 UTC 2022 on ttyS2
root@am62xx-evm:~# devmem2 0x43000030 w 0x3b
/dev/mem opened.
Memory mapped at address 0xffff935b8000.
Read at address  0x43000030 (0xffff935b8030): 0x00000243
Write at address 0x43000030 (0xffff935b8030): 0x0000003B, readback 0x0000003B
root@am62xx-evm:~# devmem2 0x43018170 w 0x6
/02000000011a0000616d3632780000000000000048534653010001000100010002a6000000000000d68ecb2c055dff11ade95bd927e837d2a53bc23b0a2800cebce4f106bcf309df2213912d77a157a8b7c2df40672a06a918034aa4c7d603e462481475225d49b8ad0bc40b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000296d207de04fdb90b38aa5d862e8e892e22e9274a3d27
ff4f3577ecb32bcf5feCCCCCC

The last char 'C' prints one per second.

After running these commands, my terminal only freezes and does not reboot nor prints the "C" characters.

Hmm, this basically means software triggered warmreset doesn't reboot the device.

Leonardo Dutra said:

I know I could reboot Linux by resetting only the eMMC

Can you please explain what exactly you do which can reboot Linux? Please show the log if necessary.

Well, linux has the command "mmc hwreset enable /dev/mmcblk<x>" which will enable the reset of the eMMC device. If I run this command on my custom board, the "reboot" command starts working, but I'm not sure if its causing a proper POR or if only the eMMC is resetting.

Do you mean you always have to run *both* commands to make Linux to reboot properly?

The "mmc hwreset enable ..." command is supposed to only run *once* on a completely new eMMC device, this command does a permanent change in the ECSD register. Running this command multiple times shouldn't do anything.

The situation is as follows: I have one board which a ran this emmc command *once* and it's rebooting Linux and one board that I did not ran this command. My doubt is if the first board is rebooting the system at all or *only* the eMMC device. I'm currently checking the POR signals of the board, but I want to be sure that my board is resetting all the hardware (including eMMC, PHYs, RAM, MPU, etc.) properly and not only the eMMC. Also I'd like to understand, if that's the case, why this "mmc hwreset enable" command enables all the system to reset.

Some update: I've checked the signals on my board and conclude that Linux is triggering a warm reset to the board, but what I need is a proper POR reset. How could I proceed?

Why do you need POR reset?

Linux reboot command always trigger warm reset. The SoC warm reset signal should be connected to all external components on the board which require reset.

I need a POR triggered by "reboot", because I want to guarantee that all external components are totally reset and to be sure that, if a bug occurs on some place of the overall system, I do not need to eletrically reset the board, because I may not have access to the product when its installed in field. Also, according to the am62x reference manual, IO is not affected on main domain warm reset.

Yes, the board has a PMIC of this model. I checked the menuconfig and this driver is already enabled in my kernel, but its not mapped in device tree. How can I write a node in device tree to make it work properly?

dev@ula:ti$ git grep tps65219
k3-am62-lp-sk.dts:      tps65219: pmic@30 {
k3-am62-lp-sk.dts:              compatible = "ti,tps65219";
k3-am625-beagleplay.dts:        tps65219: pmic@30 {
k3-am625-beagleplay.dts:                compatible = "ti,tps65219";

I am not a PMIC expert, but you might check kernel k3-am62-lp-sk.dts or k3-am625-beagleplay.dts as an example to enable TPS65219 in kernel device tree.

I've mapped the TPS on device tree, got some errors on the device driver, fixed them and now the driver should be working, but I'm still getting a warm reset instead of a cold reset. How can I configure the driver or device tree to achieve a proper cold reset when running "reboot"?

Please try to add debug print (pr_info(), or pr_warning()...) in tps65219_restart() to see if it is called in reboot.

Note this function checks a condition to decide to warm reset or cold reset. Please check how this condition is set. I never looked into this section of the kernel code. But I will check it when I get a chance, likely not in this week.

According to my checking, the tps65219_restart function is not being called on reboot, but there's no error message related to TPS I could find on running "dmesg"

Okay, let me check the same on my AM62x Beagleplay board to see it has the same problem. I might not be able to get into this until later next week.

Hello,

I double checked it and the MODE/RESET pin is indeed connected to the RESETSTATz pin, but a cold reset is still not happening in my custom board.

I support AM62x devices but am not a PMIC expert. Please check the PMIC datasheet, this MODE/RESET pin requires multiple configurations to work in cold reset mode to trigger power sequence down and up. Please ensure the PMIC is configured correctly before the Linux reboot command.