[U-Boot] [PATCH v2 0/2] 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(-)
Adjust the configuration to use the driver model version of the pl01x serial driver. Add the required platform data.
Signed-off-by: Simon Glass sjg@chromium.org ---
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(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index aaded88..5ebafd7 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -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; diff --git a/include/configs/rpi.h b/include/configs/rpi.h index 71d605c..bef6062 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -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
On 11/24/2014 06:08 PM, Simon Glass wrote:
Adjust the configuration to use the driver model version of the pl01x serial driver. Add the required platform data.
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.
Signed-off-by: Simon Glass sjg@chromium.org ---
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(-)
diff --git a/include/configs/rpi.h b/include/configs/rpi.h index bef6062..deef450 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -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" \
On 11/24/2014 06:08 PM, Simon Glass wrote:
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.
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,
On 24 November 2014 at 21:06, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/24/2014 06:08 PM, Simon Glass wrote:
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.
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.
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
On 11/24/2014 09:10 PM, Simon Glass wrote:
Hi Stephen,
On 24 November 2014 at 21:06, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/24/2014 06:08 PM, Simon Glass wrote:
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.
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.
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?
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,
On 24 November 2014 at 21:22, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/24/2014 09:10 PM, Simon Glass wrote:
Hi Stephen,
On 24 November 2014 at 21:06, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/24/2014 06:08 PM, Simon Glass wrote:
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.
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.
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?
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)
Ah! Well good that you know the platform. I just saw what looked like vectors and thought nothing of it.
Regards, Simon
participants (2)
-
Simon Glass -
Stephen Warren