Kernel initialization problem - timeouts

[fpoussin]

Hi,

I'm trying to make a custom board boot, using buildroot with all the official ST releases (tf-a, u-boot, kernel) but it's getting blocked at some point.

[    0.911310] stm32mp1_rcc 50000000.rcc: deferred probe timeout, ignoring dependency
[    0.922691] stm32-usart 40010000.serial: deferred probe timeout, ignoring dependency
[    0.930944] stm32-usart 40019000.serial: deferred probe timeout, ignoring dependency
[    0.940229] mmci-pl18x 58005000.sdmmc: deferred probe timeout, ignoring dependency
[    0.948062] mmci-pl18x 58007000.sdmmc: deferred probe timeout, ignoring dependency
[    0.957626] Warning: unable to open an initial console.
[    0.963738] Waiting for root device /dev/mmcblk0p6...

Full boot logs + full kernel (decompiled) dts + other dts:

https://gist.github.com/fpoussin/1201546cb9875be12528d363687e0a93

It looks like it's waiting on pincontrol, but my DTS is identical to the discovery kits in this regard...

Maybe trustzone is blocking? I've tried to copy the etzpc node from the DK board but that didn't help.

Maybe clocks? exti?

I've tried the multi_v7 + fragments config, it gets the same error.

Also tried the demo kernel, u-boot and tf-a bins with my DTBs without success...

Same with different GCC toolchains. (9.3, 10.2...)

I don't use a PMIC.

Any ideas?

Thank you

[Olivier GALLIEN]

Hi @fpoussin​ ,

Can it be same issue than in https://community.st.com/s/question/0D50X0000CCpjAgSQJ/after-rebuild-kernel-then-machine-stop-to-waiting-for-here-root-device-devmmcblk0p6 ?

Hope it help

Olivier

[fpoussin]

Sadly no, I've tried this already.

It's a completely different issue.

The only other reference I've found is this:

https://forum.digikey.com/t/stm32mp157d-dk1-unrecognized-filesystem-type/16096/4

But he was using SPL, not TF-A like here.

That makes it look like something is wrong with TF-A...

[fpoussin]

After digging a little bit more in kernel code, it seems to be blocking here:

drivers/pinctrl/stm32/pinctrl-stm32.c:

pctl->domain = stm32_pctrl_get_irq_domain(np);
	if (IS_ERR(pctl->domain))
		return PTR_ERR(pctl->domain);

 For this node:

exti: interrupt-controller@5000d000 {
			compatible = "st,stm32mp1-exti", "syscon";
			interrupt-controller;
			#interrupt-cells = <2>;
			reg = <0x5000d000 0x400>;
			hwlocks = <&hsem 1 1>;
 
			/* exti_pwr is an extra interrupt controller used for
			 * EXTI 55 to 60. It's mapped on pwr interrupt
			 * controller.
			 */
			exti_pwr: exti-pwr {
				interrupt-controller;
				#interrupt-cells = <2>;
				interrupt-parent = <&pwr_irq>;
				st,irq-number = <6>;
			};
		};

 Bypassing this shows that it will block on getting the clocks when calling of_clk_get_by_name()

Seems like it's on the HSEM (spinlock) clock side...

[fpoussin]

Found the problem: it is caused by a bug in the rcc code.

I'm using MCO1 for an external peripheral, and it seems to create a cyclic redundancy:

pinctrl needs rcc, but rcc has some pins to configure...

&rcc{
	u-boot,dm-pre-reloc;
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&rcc_pins_mx>;
	pinctrl-1 = <&rcc_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN rcc */
	/* USER CODE END rcc */
};

Disabling (deleting) this fixed the problem and the board now boots.

Sadly this prevents me from using the MCO output...

One note, while it's blocking boot, the MCO output is activated and working.

I've tried to work around this by enabling the MCO pins from TF-A (with custom code) but the kernel resets it once it's booting...

[Olivier GALLIEN · Accepted solution]

Hi @fpoussin​ ,

Well catch and apology from ST.

This is actually on known issue.

We are working to deliver fix and clean solution in a coming releases. ( probably delegate MCO configuration to OPTEE)

For the time being, we recommend to add MCO pins in the Linux driver which need them. I.e. if MCO is needed to provide a clock to the Camera, then MCO pin has to be added to Camera pinctrl group in kernel device tree.

Hope it help

Olivier

[fpoussin]

Actually, I had tried this without success, even when specifying the MCO1 clock. (boots OK but no clock output)

The clock source (LSE) is already active for RTC.

&uart8{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&uart8_pins_mx>, <&rcc_pins_mx>;
	pinctrl-1 = <&uart8_sleep_pins_mx>, <&rcc_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN uart8 */
	clocks = <&rcc UART8_K>, <&rcc CK_MCO1>;
	/* Note: HW flow control is broken, hence using custom CTS/RTS gpios */
	/delete-property/st,hw-flow-ctrl;
	cts-gpios = <&gpioe 14 GPIO_ACTIVE_LOW>;
	rts-gpios = <&gpioe 15 GPIO_ACTIVE_LOW>;
	bluetooth {
		compatible = "qcom,qca9377-bt";
		/* enable-gpio = <&gpioc 6 GPIO_ACTIVE_LOW>; */ // WL_NRST
		max-speed = <2000000>;
		vbat-supply = <&reg_wlan>;
		vddio-supply = <&reg_vdd>;
	};
	/* USER CODE END uart8 */
};
 
&rcc{
	status = "okay";
	secure-status = "okay";
 
	/* USER CODE BEGIN rcc */
	/* USER CODE END rcc */
};

 I've also tried to add the RCC pin definitions to the UART ones, but it makes no difference.