RPi: Properly handle dynamic serial configuration

Currently our serial device search chokes on the fact that the serial probe function could fail. If it does, instead of searching for the next usable serial device, it just quits.

This patch changes the fallback logic so that even when a serial device was not probed correctly, we just try the next ones until we find one that works.

Signed-off-by Alexander Graf <[email protected]>

---

v1 -> v2:

- Make search logic easier to follow

Currently our serial device search chokes on the fact that the serial probe function could fail. If it does, instead of searching for the next usable serial device, it just quits.

This patch changes the fallback logic so that even when a serial device was not probed correctly, we just try the next ones until we find one that works.

Signed-off-by Alexander Graf <[email protected]>

---

v1 -> v2:

- Make search logic easier to follow

---
 drivers/serial/serial-uclass.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

Quoted 10 lines · Alexander Graf

Currently our serial device search chokes on the fact that the serial probe function could fail. If it does, instead of searching for the next usable serial device, it just quits.

This patch changes the fallback logic so that even when a serial device was not probed correctly, we just try the next ones until we find one that works.

Signed-off-by Alexander Graf <[email protected]>

Quoted 8 lines

---

v1 -> v2:

- Make search logic easier to follow

---
 drivers/serial/serial-uclass.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

Reviewed-by Simon Glass <[email protected]>

The fallback logic is getting more complicated. How come the DT does not specify the correct console?

On some boards, serial devices may or may not be muxed properly to actual pins, depending on firmware configuration. To determine whether we should use a serial device for U-Boot in-/output, we need to check whether it is muxed properly.

This is something only the board file can do, so let's expose a weak function that a board can override to explicitly allow or disallow usage of certain serial devices.

Signed-off-by Alexander Graf <[email protected]>

---
 drivers/serial/serial-uclass.c | 11 +++++++++++
 include/serial.h               | 11 +++++++++++
 2 files changed, 22 insertions(+)

Hi Alex,

Quoted 9 lines · Alexander Graf

On some boards, serial devices may or may not be muxed properly to actual pins, depending on firmware configuration. To determine whether we should use a serial device for U-Boot in-/output, we need to check whether it is muxed properly.

This is something only the board file can do, so let's expose a weak function that a board can override to explicitly allow or disallow usage of certain serial devices.

Quoted 6 lines

Signed-off-by Alexander Graf <[email protected]>

---
 drivers/serial/serial-uclass.c | 11 +++++++++++
 include/serial.h               | 11 +++++++++++
 2 files changed, 22 insertions(+)

Can we please figure out how handle this in the serial driver / driver model itself? I want to avoid weak functions with driver model.

Quoted 19 lines · Simon Glass

Hi Alex,

Quoted 15 lines · Alexander Graf

On some boards, serial devices may or may not be muxed properly to actual pins, depending on firmware configuration. To determine whether we should use a serial device for U-Boot in-/output, we need to check whether it is muxed properly.

This is something only the board file can do, so let's expose a weak function that a board can override to explicitly allow or disallow usage of certain serial devices.

Signed-off-by Alexander Graf <[email protected]>

---
 drivers/serial/serial-uclass.c | 11 +++++++++++
 include/serial.h               | 11 +++++++++++
 2 files changed, 22 insertions(+)

Quoted 2 lines

Can we please figure out how handle this in the serial driver / driver model itself? I want to avoid weak functions with driver model.

I'm very happy to see suggestions :). The reason I went with the weak function is really because I couldn't think of anything better.

Hi Alex,

Quoted 25 lines · Alexander Graf

Quoted 21 lines · Simon Glass

Hi Alex,

Quoted 9 lines · Alexander Graf

On some boards, serial devices may or may not be muxed properly to actual pins, depending on firmware configuration. To determine whether we should use a serial device for U-Boot in-/output, we need to check whether it is muxed properly.

This is something only the board file can do, so let's expose a weak function that a board can override to explicitly allow or disallow usage of certain serial devices.

Quoted 6 lines

Signed-off-by Alexander Graf <[email protected]>

---
 drivers/serial/serial-uclass.c | 11 +++++++++++
 include/serial.h               | 11 +++++++++++
 2 files changed, 22 insertions(+)

Can we please figure out how handle this in the serial driver / driver model itself? I want to avoid weak functions with driver model.

Quoted 2 lines

I'm very happy to see suggestions :). The reason I went with the weak function is really because I couldn't think of anything better.

The serial driver is proprietary so you should be able to put a call into the pinctrl driver from that. The pinctrl driver can return the state of a pin - maybe get_gpio_mux() or a new pinmux_get()?

Quoted 31 lines · Simon Glass

Hi Alex,

Quoted 27 lines · Alexander Graf

Quoted 19 lines · Simon Glass

Hi Alex,

Quoted 9 lines · Alexander Graf

On some boards, serial devices may or may not be muxed properly to actual pins, depending on firmware configuration. To determine whether we should use a serial device for U-Boot in-/output, we need to check whether it is muxed properly.

This is something only the board file can do, so let's expose a weak function that a board can override to explicitly allow or disallow usage of certain serial devices.

Quoted 6 lines

Signed-off-by Alexander Graf <[email protected]>

---
 drivers/serial/serial-uclass.c | 11 +++++++++++
 include/serial.h               | 11 +++++++++++
 2 files changed, 22 insertions(+)

Quoted 2 lines

Can we please figure out how handle this in the serial driver / driver model itself? I want to avoid weak functions with driver model.

I'm very happy to see suggestions :). The reason I went with the weak function is really because I couldn't think of anything better.

Quoted 3 lines

The serial driver is proprietary so you should be able to put a call into the pinctrl driver from that. The pinctrl driver can return the state of a pin - maybe get_gpio_mux() or a new pinmux_get()?

The SoC has 2 serial drivers: a proprietary one and a pl011. Would you think it's ok to put an architecture specific hack into the generic pl011 code with an #ifdef?

Now that we have all infrastructure in place to dynamically determine whether a serial device is actually usable (read: routed to user accessible pins), we can wire it up to the board.

This patch adds support to determine whether the pl011 or mini-uart or no serial is routed to the UART RX/TX pins on the Raspberry Pi family of boards.

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c | 69 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

board/raspberrypi/rpi/rpi.c +21 -0

index a96d5d8952..b0cdad70f7 100644
@@ -24,9 +24,16 @@
 #include <asm/armv8/mmu.h>
 #endif
 #include <watchdog.h>
+#include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * This is the GPIO pin that the user facing UART RX line is attached to.
+ * We use this pin to determine which serial device is available.
+ */
+#define BCM2835_GPIO_RX                15
+
 /* From lowlevel_init.S */
 extern unsigned long fw_dtb_pointer;
 

@@ -419,6 +426,68 @@ static void get_board_rev(void)
        printf("RPI %s (0x%x)\n", model->name, revision);
 }
 
+/*
+ * We may get called before the device model is initialized, so we can not
+ * rely on the GPIO driver.
+ */
+int get_func_id(unsigned gpio)
+{
+       u32 val;
+       u32 node;
+       u32 *gpfsel;
+       fdt_addr_t addr;
+       fdt_size_t size;
+
+       node = fdt_node_offset_by_compatible(gd->fdt_blob, -1, "brcm,bcm2835-gpio");
+       if (node < 0)

Hi Alex,

Quoted 55 lines · Alexander Graf

Now that we have all infrastructure in place to dynamically determine whether a serial device is actually usable (read: routed to user accessible pins), we can wire it up to the board.

This patch adds support to determine whether the pl011 or mini-uart or no serial is routed to the UART RX/TX pins on the Raspberry Pi family of boards.

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c | 69 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

board/raspberrypi/rpi/rpi.c +25 -0

index a96d5d8952..b0cdad70f7 100644
@@ -24,9 +24,16 @@
 #include <asm/armv8/mmu.h>
 #endif
 #include <watchdog.h>
+#include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * This is the GPIO pin that the user facing UART RX line is attached to.
+ * We use this pin to determine which serial device is available.
+ */
+#define BCM2835_GPIO_RX                15
+
 /* From lowlevel_init.S */
 extern unsigned long fw_dtb_pointer;
 

@@ -419,6 +426,68 @@ static void get_board_rev(void)
        printf("RPI %s (0x%x)\n", model->name, revision);
 }
 
+/*
+ * We may get called before the device model is initialized, so we can not
+ * rely on the GPIO driver.
+ */
+int get_func_id(unsigned gpio)
+{
+       u32 val;
+       u32 node;
+       u32 *gpfsel;
+       fdt_addr_t addr;
+       fdt_size_t size;
+
+       node = fdt_node_offset_by_compatible(gd->fdt_blob, -1, "brcm,bcm2835-gpio");
+       if (node < 0)
+               return -EINVAL;
+
+       addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, node, "reg",
+                                                 0, &size, true);

board/raspberrypi/rpi/rpi.c static void get_board_rev(void) · line 452

Quoted 6 lines

board/raspberrypi/rpi/rpi.c +6 -0

+       gpfsel = (void*)addr;
+
+       val = readl(&gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]);
+
+       return (val >> BCM2835_GPIO_FSEL_SHIFT(gpio) & BCM2835_GPIO_FSEL_MASK);
+}

Ick, this should be done in the GPIO driver and use gpio_get_function().

Quoted 58 lines · Simon Glass

Hi Alex,

Quoted 55 lines · Alexander Graf

Now that we have all infrastructure in place to dynamically determine whether a serial device is actually usable (read: routed to user accessible pins), we can wire it up to the board.

This patch adds support to determine whether the pl011 or mini-uart or no serial is routed to the UART RX/TX pins on the Raspberry Pi family of boards.

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c | 69 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

board/raspberrypi/rpi/rpi.c +25 -0

index a96d5d8952..b0cdad70f7 100644
@@ -24,9 +24,16 @@
 #include <asm/armv8/mmu.h>
 #endif
 #include <watchdog.h>
+#include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * This is the GPIO pin that the user facing UART RX line is attached to.
+ * We use this pin to determine which serial device is available.
+ */
+#define BCM2835_GPIO_RX                15
+
 /* From lowlevel_init.S */
 extern unsigned long fw_dtb_pointer;
 

@@ -419,6 +426,68 @@ static void get_board_rev(void)
        printf("RPI %s (0x%x)\n", model->name, revision);
 }
 
+/*
+ * We may get called before the device model is initialized, so we can not
+ * rely on the GPIO driver.
+ */
+int get_func_id(unsigned gpio)
+{
+       u32 val;
+       u32 node;
+       u32 *gpfsel;
+       fdt_addr_t addr;
+       fdt_size_t size;
+
+       node = fdt_node_offset_by_compatible(gd->fdt_blob, -1, "brcm,bcm2835-gpio");
+       if (node < 0)
+               return -EINVAL;
+
+       addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, node, "reg",
+                                                 0, &size, true);

Quoted 8 lines

board/raspberrypi/rpi/rpi.c static void get_board_rev(void) · line 452

Quoted 6 lines

board/raspberrypi/rpi/rpi.c +6 -0

+       gpfsel = (void*)addr;
+
+       val = readl(&gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]);
+
+       return (val >> BCM2835_GPIO_FSEL_SHIFT(gpio) & BCM2835_GPIO_FSEL_MASK);
+}

Ick, this should be done in the GPIO driver and use gpio_get_function().

Yes, but what if users specify the serial device to be pre-reloc and don't do that for the GPIO (or really pinctrl) one? Then we'd not have the driver around to determine whether serial is active, right?

The serial devices on the raspberry pi are based on clocks we can't easily read and influence in U-Boot. However, the serial devices are always already properly set up when coming up, so all we need to do is leave them alone.

The way to do that is to specify "skip-init" in device tree usually, but if we set CONFIG_OF_BOARD to get the device tree from the RPi firmware, that does not have skip-init properly set.

So instead we just force it in board specific code. That way serial devices also work fine when skip-init is not passed explicitly in DT.

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c        | 7 +++++++
 drivers/serial/serial_bcm283x_mu.c | 2 +-
 drivers/serial/serial_pl01x.c      | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

Hi Alex,

Quoted 11 lines · Alexander Graf

The serial devices on the raspberry pi are based on clocks we can't easily read and influence in U-Boot. However, the serial devices are always already properly set up when coming up, so all we need to do is leave them alone.

The way to do that is to specify "skip-init" in device tree usually, but if we set CONFIG_OF_BOARD to get the device tree from the RPi firmware, that does not have skip-init properly set.

So instead we just force it in board specific code. That way serial devices also work fine when skip-init is not passed explicitly in DT.

Quoted 6 lines

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c        | 7 +++++++
 drivers/serial/serial_bcm283x_mu.c | 2 +-
 drivers/serial/serial_pl01x.c      | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

Would you mind converting these drivers to livetree before adding these patches?

Quoted 21 lines · Simon Glass

Hi Alex,

Quoted 17 lines · Alexander Graf

The serial devices on the raspberry pi are based on clocks we can't easily read and influence in U-Boot. However, the serial devices are always already properly set up when coming up, so all we need to do is leave them alone.

The way to do that is to specify "skip-init" in device tree usually, but if we set CONFIG_OF_BOARD to get the device tree from the RPi firmware, that does not have skip-init properly set.

So instead we just force it in board specific code. That way serial devices also work fine when skip-init is not passed explicitly in DT.

Signed-off-by Alexander Graf <[email protected]>

---
 board/raspberrypi/rpi/rpi.c        | 7 +++++++
 drivers/serial/serial_bcm283x_mu.c | 2 +-
 drivers/serial/serial_pl01x.c      | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

Quoted 1 line

Would you mind converting these drivers to livetree before adding these patches?

Uh, why? I don't quite see how it's related - and I'm not sure I'll make the rc1 cut-off even with just the pile I have right now :)