ast2500 reboot got stuck in timeriomem_rng_probe()

ast2500 reboot got stuck in timeriomem_rng_probe()

[Tao Ren]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hi,

I’m upgrading facebook cmm-bmc (ast2500) from 4.1 to openbmc linux 4.17.2, and when I tried to reboot linux 4.17, system got stuck in  timeriomem_rng_probe() function during boot up. Did anyone hit the similar issue before? What would be the recommended solution?


Thanks,

Tao

[-- Attachment #2: Type: text/html, Size: 2234 bytes --]

Re: ast2500 reboot got stuck in timeriomem_rng_probe()

[Andrew Jeffery]

Hi Tao,

On Thu, 2 Aug 2018, at 02:38, Tao Ren wrote:
> Hi,
> 
> I’m upgrading facebook cmm-bmc (ast2500) from 4.1 to openbmc linux 
> 4.17.2, and when I tried to reboot linux 4.17, system got stuck in  
> timeriomem_rng_probe() function during boot up. Did anyone hit the 
> similar issue before? What would be the recommended solution?
> 

Can you show us your devicetree patch? The only things I can think of are
if you didn't specify the 'quality' attribute (if you don't the quality defaults
to 0, which marks the device as disabled in the hwrng device list), or if
you set a really long period (but I assume you could have sorted that out
yourself :)).

Cheers,

Andrew

Re: ast2500 reboot got stuck in timeriomem_rng_probe()

[Tao Ren]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

> Can you show us your devicetree patch? The only things I can think of are
> if you didn't specify the 'quality' attribute (if you don't the quality defaults
> to 0, which marks the device as disabled in the hwrng device list), or if
 > you set a really long period (but I assume you could have sorted that out
 > yourself :)).

Thank you Andrew for the response. I'm using the default settings in aspeed-g5.dtsi:
    - period = <1>;
    - quality = <100>;

After some investigation, I highly suspect it's because some part(s) of the chip are not reset properly, because:
   1) the problem only happens during warn reboot: cold boot works fine.
   2) bootup hangs at a different place if I disable HW_RANDOM_TIMERIOMEM.
   3) the issue is gone if I update aspeed watchdog reset type to system (aspeed,reset-type = "system") in dts file.

Attached the device tree for your reference, and I will refine the file and send out review soon.


Thanks,

Tao

On 8/1/18, 6:41 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:

    Hi Tao,
    
    On Thu, 2 Aug 2018, at 02:38, Tao Ren wrote:
    > Hi,
    > 
    > I’m upgrading facebook cmm-bmc (ast2500) from 4.1 to openbmc linux 
    > 4.17.2, and when I tried to reboot linux 4.17, system got stuck in  
    > timeriomem_rng_probe() function during boot up. Did anyone hit the 
    > similar issue before? What would be the recommended solution?
    > 
    
    Can you show us your devicetree patch? The only things I can think of are
    if you didn't specify the 'quality' attribute (if you don't the quality defaults
    to 0, which marks the device as disabled in the hwrng device list), or if
    you set a really long period (but I assume you could have sorted that out
    yourself :)).
    
    Cheers,
    
    Andrew
    


[-- Attachment #2: aspeed-bmc-fb-cmm.dts --]
[-- Type: application/octet-stream, Size: 1927 bytes --]

// SPDX-License-Identifier: GPL-2.0+
/dts-v1/;

#include "aspeed-g5.dtsi"

/ {
	model = "Facebook Galaxy Chassis Management Module";
	compatible = "aspeed,ast2500";

	aliases {
		/*
		 * Override the default serial aliases in aspeed-g5.dtsi
		 * to make sure /dev/ttyS* are mapped to the same uart
		 * with cmm kernel 4.1.
		 */
		serial0 = &uart5;
		serial1 = &uart1;
		serial2 = &uart3;
		serial3 = &uart4;

		/*
		 * The purpose of adding "i2c15" alias is to make sure
		 * dynamic bus number (assigned to i2c-muxes) starts
		 * from 16, and this is because we have too many user
		 * level applications assuming i2c-mux-bus-num starts
		 * from 16.
		 */
		i2c15 = &i2c10;
	};

	chosen {
		stdout-path = &uart1;
		bootargs = "console=ttyS1,9600n8 root=/dev/ram rw earlyprintk";
	};

	memory@80000000 {
		device_type = "memory";
		reg = <0x80000000 0x20000000>;
	};
};

/*
 * Both wdt1 and wdt2 are enabled in aspeed-g5.dtsi but we just need
 * the first watchdog (wdt1); thus let's disable wdt2 explicitly.
 */
&wdt2 {
	status = "disabled";
};

&fmc {
	status = "okay";
	flash@0 {
		status = "okay";
		m25p,fast-read;
		label = "bmc";
#include "fb-bmc-flash-layout.dtsi"
	};
};

&uart1 {
	status = "okay";
};

&uart3 {
	status = "okay";
};

&uart4 {
	status = "okay";
};

&uart5 {
	status = "okay";
};

/*
 * Note mac1 is actually the second mac controller (0x1e680000) because
 * mac label is 0-based (mac0 mapping to 0x1e660000) in aspeed-g5.dtsi.
 */
&mac1 {
	status = "okay";

	no-hw-checksum;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
};

&i2c0 {
	status = "okay";
};

&i2c1 {
	status = "okay";
};

&i2c2 {
	status = "okay";
};

&i2c3 {
	status = "okay";
};

&i2c4 {
	status = "okay";
};

&i2c5 {
	status = "okay";
};

&i2c6 {
	status = "okay";
};

&i2c7 {
	status = "okay";
};

&i2c8 {
	status = "okay";
};

&i2c13 {
	status = "okay";
};

&adc {
	status = "okay";
};