dm: rpi: Move Raspberry Pi to use driver model

This series adds driver model support to the GPIO and serial drivers used by Raspberry Pi, and moves Raspberry Pi over to driver model.

This requires adding driver model support to the pl01x serial driver, and replacing the bcm2835 GPIO driver with a driver model version (since there are no longer clients that don't use driver model).

See u-boot-dm.git branch rpi-working for the tree this is based on.

Changes in v2:
- Adjust header file include to dm/platform_data/...
- Add new patch to move script load address to 0x8000

Simon Glass (2):
dm: rpi: Move serial to driver model
dm: rpi: Move script load address to 0x8000

 board/raspberrypi/rpi/rpi.c | 12 ++++++++++++
 include/configs/rpi.h       |  8 ++++----
 2 files changed, 16 insertions(+), 4 deletions(-)

2.1.0.rc2.206.gedb03e5

Adjust the configuration to use the driver model version of the pl01x serial driver. Add the required platform data.

---

Changes in v2:
- Adjust header file include to dm/platform_data/...

 board/raspberrypi/rpi/rpi.c | 12 ++++++++++++
 include/configs/rpi.h       |  6 +++---
 2 files changed, 15 insertions(+), 3 deletions(-)

index aaded88..5ebafd7 100644
@@ -24,6 +24,7 @@
 #include <asm/arch/mbox.h>
 #include <asm/arch/sdhci.h>
 #include <asm/global_data.h>
+#include <dm/platform_data/serial_pl01x.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 

@@ -36,6 +37,17 @@ U_BOOT_DEVICE(bcm2835_gpios) = {
 	.platdata = &gpio_platdata,
 };
 
+static const struct pl01x_serial_platdata serial_platdata = {
+	.base = 0x20201000,
+	.type = TYPE_PL011,
+	.clock = 3000000,
+};
+
+U_BOOT_DEVICE(bcm2835_serials) = {
+	.name = "serial_pl01x",
+	.platdata = &serial_platdata,
+};
+
 struct msg_get_arm_mem {
 	struct bcm2835_mbox_hdr hdr;
 	struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;

index 71d605c..bef6062 100644
@@ -35,6 +35,7 @@
 #define CONFIG_DM
 #define CONFIG_CMD_DM
 #define CONFIG_DM_GPIO
+#define CONFIG_DM_SERIAL
 
 /* Memory layout */
 #define CONFIG_NR_DRAM_BANKS		1

@@ -52,6 +53,7 @@
 					 CONFIG_SYS_SDRAM_SIZE - \
 					 GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_MALLOC_LEN		SZ_4M
+#define CONFIG_SYS_MALLOC_F_LEN		(1 << 10)
 #define CONFIG_SYS_MEMTEST_START	0x00100000
 #define CONFIG_SYS_MEMTEST_END		0x00200000
 #define CONFIG_LOADADDR			0x00200000

@@ -93,9 +95,7 @@
 #endif
 
 /* Console UART */
-#define CONFIG_PL011_SERIAL
-#define CONFIG_PL011_CLOCK		3000000
-#define CONFIG_PL01x_PORTS		{ (void *)0x20201000 }
+#define CONFIG_PL01X_SERIAL
 #define CONFIG_CONS_INDEX		0
 #define CONFIG_BAUDRATE			115200
 

2.1.0.rc2.206.gedb03e5

This basically seems to work, but I'll withhold any tested-by/acked-by until we can work out why writes to address 0 cause U-Boot to fail, with this patch applied.

The current load address of 0 seems to cause problems when driver model is used. There doesn't seem to be any reason why the script needs to load to 0, so move it.

---

Changes in v2:
- Add new patch to move script load address to 0x8000

 include/configs/rpi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index bef6062..deef450 100644
@@ -171,7 +171,7 @@
  *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
-	"scriptaddr=0x00000000\0" \
+	"scriptaddr=0x00008000\0" \
 	"pxefile_addr_r=0x00100000\0" \
 	"kernel_addr_r=0x01000000\0" \
 	"fdt_addr_r=0x02000000\0" \

2.1.0.rc2.206.gedb03e5

I'm not particularly tied to the specific $scriptaddr value, but I think we should find out why writing to address 0 causes failures, rather than just papering over the issue.

Hi Stephen,

I had the same thought, but I have no documentation and have spent quite a bit of time on it. Do you have any suggestions? Where are the CPU vectors kept on this platform?

Regards,
Simon

I think I found the issue; see my latest message in thread "Re:
Raspberry Pi with driver model".

(I should mention I originally started looking at that code since I dumped the memory at address 0 immediately after boot, and noticed the UART address was there for some unexpected reason)

Hi Stephen,

Ah! Well good that you know the platform. I just saw what looked like vectors and thought nothing of it.

Regards,
Simon