Skip to contentSkip to conversation

configs: am43xx_evm: Merge in usbhost defconfig

PATCH New Andrew F. Davis 2 participants 5 messages Mar 10, 2017 – Mar 13, 2017

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 configs: am43xx_evm: Merge in usbhost defconfig

I was once again going to try to sync the mode specific defconfigs with the main AM43xx defconfig when I decided it may make more sense to merge in USB host boot support in to the main defconfig.

The reason we had separate defconfigs before was that SPL needs to be placed in OCMC SRAM by the ROM when booting from USB as it uses DMA and ARM internal SRAM space is not externally accessible. All this means is we need to have our SPL load address be greater than 0x4030_0000 when USB booting. For other cases we use 0x402F_0000, this gives us an extra 64kB of space in addition to the 256kB of OCMC RAM, as our SPL is not even half this size currently this is not strictly needed.

Make all boot modes load to 0x4030_0000+, add SPL USB host boot support to the main am43xx defconfig, and then remove am43xx_evm_usbhost_boot_defconfig. Allowing us one image that supports all AM43xx boot modes (-QSPI).

---
 configs/am43xx_evm_defconfig              |  3 ++
 configs/am43xx_evm_usbhost_boot_defconfig | 74 -------------------------------
 2 files changed, 3 insertions(+), 74 deletions(-)
 delete mode 100644 configs/am43xx_evm_usbhost_boot_defconfig
configs/am43xx_evm_defconfig +3 -0
index 6fb2053f33..849efbd011 100644
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_ISW_ENTRY_ADDR=0x40300350
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
@@ -13,6 +14,8 @@ CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
+CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
configs/am43xx_evm_usbhost_boot_defconfig deleted +0 -74

74 lines not on this page · raw message

Signature · 1 line
2.11.0
#1 lore raw

PATCH 2/2 configs: am43xx_hs_evm: Add USB Host boot mode support

Enable SPL_USB_HOST_SUPPORT in the default defconfig to allow booting from USB peripherals. Unlike the non-HS boards, we already load SPL to a 0x4030_0000+ address, so no other changes are needed.

---
 configs/am43xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)
configs/am43xx_hs_evm_defconfig +2 -0
index 8bb1b3535a..8df4e89722 100644
@@ -16,6 +16,8 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
Signature · 1 line
2.11.0
#2 lore raw

PATCH 2/2 configs: am43xx_hs_evm: Add USB Host boot mode support

Quoted 6 lines · Andrew F. Davis

Enable SPL_USB_HOST_SUPPORT in the default defconfig to allow booting from USB peripherals. Unlike the non-HS boards, we already load SPL to a 0x4030_0000+ address, so no other changes are needed.

Thanks and regards,
Lokesh

#3 lore raw

PATCH 1/2 configs: am43xx_evm: Merge in usbhost defconfig

In reply to Andrew F. Davis
Quoted 13 lines · Andrew F. Davis

I was once again going to try to sync the mode specific defconfigs with the main AM43xx defconfig when I decided it may make more sense to merge in USB host boot support in to the main defconfig.

The reason we had separate defconfigs before was that SPL needs to be placed in OCMC SRAM by the ROM when booting from USB as it uses DMA and ARM internal SRAM space is not externally accessible. All this means is we need to have our SPL load address be greater than 0x4030_0000 when USB booting. For other cases we use 0x402F_0000, this gives us an extra 64kB of space in addition to the 256kB of OCMC RAM, as our SPL is not even half this size currently this is not strictly needed.

Quoted 2 lines

Make all boot modes load to 0x4030_0000+, add SPL USB host boot support to the main am43xx defconfig, and then remove

This breaks all the supported peripheral boot modes. Have you tested UART/ethernet boot with this patch?

I specifically wanted a separate defconfig for usb_host as it is a special case and rest of the boot modes can be supported using a single defconfig. If you don't like this approach, please create separate defconfigs for peripheral and memory boot modes.

Thanks and regards,
Lokesh

#4 lore raw

PATCH 1/2 configs: am43xx_evm: Merge in usbhost defconfig

Quoted 16 lines · Lokesh Vutla
Quoted 13 lines · Andrew F. Davis

I was once again going to try to sync the mode specific defconfigs with the main AM43xx defconfig when I decided it may make more sense to merge in USB host boot support in to the main defconfig.

The reason we had separate defconfigs before was that SPL needs to be placed in OCMC SRAM by the ROM when booting from USB as it uses DMA and ARM internal SRAM space is not externally accessible. All this means is we need to have our SPL load address be greater than 0x4030_0000 when USB booting. For other cases we use 0x402F_0000, this gives us an extra 64kB of space in addition to the 256kB of OCMC RAM, as our SPL is not even half this size currently this is not strictly needed.

Quoted 6 lines
Quoted 2 lines

Make all boot modes load to 0x4030_0000+, add SPL USB host boot support to the main am43xx defconfig, and then remove

This breaks all the supported peripheral boot modes. Have you tested UART/ethernet boot with this patch?

Ahh, I tested memory modes only.

I must have misunderstood the datasheet. It claims when using peripheral boot modes on a GP device the image header (containing the desired relocation address) is "not required", but if this patch breaks peripheral boot then it really means it is ignored, even if it is included in the image.

Quoted 5 lines

I specifically wanted a separate defconfig for usb_host as it is a special case and rest of the boot modes can be supported using a single defconfig. If you don't like this approach, please create separate defconfigs for peripheral and memory boot modes.

I don't have any strong preference for how the non-HS devices are handled, so if you don't like this approach then this patch can be safely ignored. (2/2 is still valid)

Thanks,
Andrew

Quoted 3 lines

Thanks and regards,
Lokesh