[U-Boot] [BUG] display_options() fails on Raspberry Pi 3B+
Hello Matthias,
Tom reported:
Since patch 143256b353c4d2ad1cf5e5e63b38410188b35e49 fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
the console no longer shows the initial message, e.g. "U-Boot 2020.01-rc1-00159-g73b6e6ad25-dirty". This leads to a failure in automated testing.
To find out what is happening I applied the following code change:
diff --git a/drivers/serial/serial_bcm283x_mu.c b/drivers/serial/serial_bcm283x_mu.c index bd1d89ec83..395c49c60a 100644 --- a/drivers/serial/serial_bcm283x_mu.c +++ b/drivers/serial/serial_bcm283x_mu.c @@ -171,8 +171,11 @@ static int bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev) fdt_addr_t addr;
/* Don't spawn the device if it's not muxed */ - if (!bcm283x_is_serial_muxed()) + if (!bcm283x_is_serial_muxed()) { + sprintf((void *)0x02400000, "muxed4 false\n"); return -ENODEV; + } + sprintf((void *)0x02400010, "muxed5 true");
addr = devfdt_get_addr(dev); if (addr == FDT_ADDR_T_NONE) diff --git a/lib/display_options.c b/lib/display_options.c index ec16d75e0e..9d44f49731 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -45,6 +45,7 @@ int display_options(void)
display_options_get_banner(true, buf, sizeof(buf)); printf("%s", buf); + sprintf((void *)0x02400009, "disp5options");
return 0; }
And see:
02400000: 6d 75 78 65 64 34 20 66 61 64 69 73 70 35 6f 70 muxed4 fadisp5op 02400010: 6d 75 78 65 64 35 20 74 72 75 65 00 05 07 06 01 muxed5 true.....
bcm283x_mu_serial_ofdata_to_platdata() is obviously called twice.
The first call is in serial_init(). At that time the GPIOs are not correctly set up to use the serial port. So display_options() fails. After relocation another call call occurs after the GPIOs are set up and this call succeeds.
Do you have an idea how to proceed?
Best regards
Heinrich
Hi Heinrich,
adding Alex just in case he knows better, as he wrote the initial code.
On 06/11/2019 01:57, Heinrich Schuchardt wrote:
Hello Matthias,
Tom reported:
Since patch 143256b353c4d2ad1cf5e5e63b38410188b35e49 fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
the console no longer shows the initial message, e.g. "U-Boot 2020.01-rc1-00159-g73b6e6ad25-dirty". This leads to a failure in automated testing.
To find out what is happening I applied the following code change:
diff --git a/drivers/serial/serial_bcm283x_mu.c b/drivers/serial/serial_bcm283x_mu.c index bd1d89ec83..395c49c60a 100644 --- a/drivers/serial/serial_bcm283x_mu.c +++ b/drivers/serial/serial_bcm283x_mu.c @@ -171,8 +171,11 @@ static int bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev) fdt_addr_t addr;
/* Don't spawn the device if it's not muxed */ - if (!bcm283x_is_serial_muxed()) + if (!bcm283x_is_serial_muxed()) { + sprintf((void *)0x02400000, "muxed4 false\n"); return -ENODEV; + } + sprintf((void *)0x02400010, "muxed5 true");
addr = devfdt_get_addr(dev); if (addr == FDT_ADDR_T_NONE) diff --git a/lib/display_options.c b/lib/display_options.c index ec16d75e0e..9d44f49731 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -45,6 +45,7 @@ int display_options(void)
display_options_get_banner(true, buf, sizeof(buf)); printf("%s", buf); + sprintf((void *)0x02400009, "disp5options");
return 0; }
And see:
02400000: 6d 75 78 65 64 34 20 66 61 64 69 73 70 35 6f 70 muxed4 fadisp5op 02400010: 6d 75 78 65 64 35 20 74 72 75 65 00 05 07 06 01 muxed5 true.....
bcm283x_mu_serial_ofdata_to_platdata() is obviously called twice.
The first call is in serial_init(). At that time the GPIOs are not correctly set up to use the serial port. So display_options() fails. After relocation another call call occurs after the GPIOs are set up and this call succeeds.
Do you have an idea how to proceed?
After digging a bit, my guess is: in the mentioned devicetree commit you change the stdout-path from serial0 (pl011) to serial1 (aux-uart).
My guess is, that the FW sets the pin mux to ALT0 which leads bcm283x_is_serial_muxed() to fail.
I wasn't able to find where the pinctrl is initialized. Shouldn't that happen before we call serial_init()?
Regards, Matthias
Hi Heinrich and all,
On 07/11/2019 12:44, Matthias Brugger wrote:
Hi Heinrich,
adding Alex just in case he knows better, as he wrote the initial code.
On 06/11/2019 01:57, Heinrich Schuchardt wrote:
Hello Matthias,
Tom reported:
Since patch 143256b353c4d2ad1cf5e5e63b38410188b35e49 fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
the console no longer shows the initial message, e.g. "U-Boot 2020.01-rc1-00159-g73b6e6ad25-dirty". This leads to a failure in automated testing.
To find out what is happening I applied the following code change:
diff --git a/drivers/serial/serial_bcm283x_mu.c b/drivers/serial/serial_bcm283x_mu.c index bd1d89ec83..395c49c60a 100644 --- a/drivers/serial/serial_bcm283x_mu.c +++ b/drivers/serial/serial_bcm283x_mu.c @@ -171,8 +171,11 @@ static int bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev) fdt_addr_t addr;
/* Don't spawn the device if it's not muxed */ - if (!bcm283x_is_serial_muxed()) + if (!bcm283x_is_serial_muxed()) { + sprintf((void *)0x02400000, "muxed4 false\n"); return -ENODEV; + } + sprintf((void *)0x02400010, "muxed5 true");
addr = devfdt_get_addr(dev); if (addr == FDT_ADDR_T_NONE) diff --git a/lib/display_options.c b/lib/display_options.c index ec16d75e0e..9d44f49731 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -45,6 +45,7 @@ int display_options(void)
display_options_get_banner(true, buf, sizeof(buf)); printf("%s", buf); + sprintf((void *)0x02400009, "disp5options");
return 0; }
And see:
02400000: 6d 75 78 65 64 34 20 66 61 64 69 73 70 35 6f 70 muxed4 fadisp5op 02400010: 6d 75 78 65 64 35 20 74 72 75 65 00 05 07 06 01 muxed5 true.....
bcm283x_mu_serial_ofdata_to_platdata() is obviously called twice.
The first call is in serial_init(). At that time the GPIOs are not correctly set up to use the serial port. So display_options() fails. After relocation another call call occurs after the GPIOs are set up and this call succeeds.
Do you have an idea how to proceed?
After digging a bit, my guess is: in the mentioned devicetree commit you change the stdout-path from serial0 (pl011) to serial1 (aux-uart).
My guess is, that the FW sets the pin mux to ALT0 which leads bcm283x_is_serial_muxed() to fail.
I wasn't able to find where the pinctrl is initialized. Shouldn't that happen before we call serial_init()?
That was not correct. I found the issue. The patch deletes the reference to bcm283x-uboot.dtsi which sets soc, uart[01] and pinctrl nodes as dm-pre-reloc.
I'll send a patch for that.
Regards, Matthias
participants (2)
-
Heinrich Schuchardt -
Matthias Brugger