omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device

PATCH Superseded Paul Kocialkowski 3 participants 22 messages Jul 15, 2015 – Aug 25, 2015

Subsystems (2)

Arm (32-bit) Arm/actions semi architecture

lore

Share & tools

lore

Paul Kocialkowski

author

2015-07-15 14:02 UTC #0 lore raw

v5 cover omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device

Changes since v4:
* Take care of BOOT_DEVICE_USBETH and don't use the fallback when it's defined and active. This way, we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB defined to the same value and use USB eth or not based on CONFIG_SPL_USBETH_SUPPORT.
* boot_params casting clarification.

Changes since v3:
* Tested on the OMAP5 uEVM, adjusted SYS_BOOT interpretation.
* Typo fixup, other minor cleanups.

Changes since v2:
* ifdef save_boot_params definition and save_omap_boot_params calls with CONFIG_SPL to only use all this when U-Boot is loaded from the U-Boot SPL. This was always the case on != omap3 omap platforms, but is no longer the case with omap3 support (since some devices like the RX-51 are OMAP HS and have proprietary bootloaders loading U-Boot, and might even need some specific code instead).

The first part of this changeset introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code.

First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs.

The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot.

The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data.

The second part of this changeset adds support for reading the SYS_BOOT pins on omap devices (no am33xx support yet) in order to fallback to the memory-preferred boot device described by the pins when peripheral booting is used. In particular, this allows loading the U-Boot SPL through either UART or USB and still having it to load U-Boot from memory when UART or USB are not valid boot devices.

This whole changeset was build-tested on all omap boards (omap3, omap4, omap5, am33xx) and tested at run-time on the Nokia RX-51 (N900), the LG Optimus Black (not supported yet) and the OMAP5 EVM.

Paul Kocialkowski

author

2015-07-15 14:02 UTC #1 lore raw

PATCH v5 1/8 omap-common: Common boot code OMAP3 support and cleanup

This introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code.

All of this is only relevant when the U-Boot SPL is used. In cases it is not, save_boot_params should fallback to its weak (or board-specific) definition. save_omap_boot_params should not be called in that context either.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap-common/Makefile        |   2 -
 arch/arm/cpu/armv7/omap-common/boot-common.c   | 126 +++++++++++++++----------
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   2 +
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   3 +-
 arch/arm/cpu/armv7/omap3/board.c               |  59 ------------
 arch/arm/cpu/armv7/omap3/lowlevel_init.S       |  10 --
 arch/arm/include/asm/arch-am33xx/omap.h        |  11 +++
 arch/arm/include/asm/arch-am33xx/sys_proto.h   |   1 -
 arch/arm/include/asm/arch-omap3/omap.h         |  13 +++
 arch/arm/include/asm/arch-omap3/sys_proto.h    |   2 +
 arch/arm/include/asm/arch-omap4/omap.h         |  11 +++
 arch/arm/include/asm/arch-omap5/omap.h         |  12 +++
 arch/arm/include/asm/global_data.h             |  10 +-
 arch/arm/include/asm/omap_boot.h               |  34 -------
 arch/arm/include/asm/omap_common.h             |   9 ++
 arch/arm/include/asm/ti-common/sys_proto.h     |   2 +-
 board/compulab/cm_t54/cm_t54.c                 |   2 +-
 include/configs/ti_omap4_common.h              |   1 +
 18 files changed, 143 insertions(+), 167 deletions(-)
 delete mode 100644 arch/arm/include/asm/omap_boot.h

arch/arm/cpu/armv7/omap-common/Makefile +0 -2

index f3725b2..464a5d1 100644
@@ -26,9 +26,7 @@ ifeq ($(CONFIG_SYS_DCACHE_OFF),)
 obj-y	+= omap-cache.o
 endif
 
-ifeq ($(CONFIG_OMAP34XX),)
 obj-y	+= boot-common.o
-endif
 obj-y	+= lowlevel_init.o
 
 obj-y	+= mem-common.o

arch/arm/cpu/armv7/omap-common/boot-common.c +74 ~~-52~~

179 lines not on this page · raw message

arch/arm/cpu/armv7/omap-common/hwinit-common.c +2 -0

index 6c8f3bc..80794f9 100644
@@ -90,7 +90,9 @@ void __weak srcomp_enable(void)
  */
 int arch_cpu_init(void)
 {
+#ifdef CONFIG_SPL
 	save_omap_boot_params();
+#endif
 	return 0;
 }
 #endif /* CONFIG_ARCH_CPU_INIT */

arch/arm/cpu/armv7/omap-common/lowlevel_init.S +2 -1

index 746df92..5283135 100644
@@ -16,8 +16,9 @@
 #include <asm/arch/spl.h>
 #include <linux/linkage.h>
 
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_SPL
 ENTRY(save_boot_params)
+
 	ldr	r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
 	str	r0, [r1]
 	b	save_boot_params_ret

arch/arm/cpu/armv7/omap3/board.c +0 ~~-59~~

77 lines not on this page · raw message

arch/arm/cpu/armv7/omap3/lowlevel_init.S +0 ~~-10~~

index 2497613..1e58772 100644
@@ -16,16 +16,6 @@
 #include <asm/arch/clocks_omap3.h>
 #include <linux/linkage.h>
 
-#ifdef CONFIG_SPL_BUILD
-ENTRY(save_boot_params)
-	ldr	r4, =omap3_boot_device
-	ldr	r5, [r0, #0x4]
-	and	r5, r5, #0xff
-	str	r5, [r4]
-	b	save_boot_params_ret
-ENDPROC(save_boot_params)
-#endif
-
 /*
  * Funtion for making PPA HAL API calls in secure devices
  * Input:

arch/arm/include/asm/arch-am33xx/omap.h +11 -0

index e5c0b0d..47962da 100644
@@ -33,4 +33,15 @@
 #define AM4372_BOARD_VERSION_END	SRAM_SCRATCH_SPACE_ADDR + 0x14
 #define QSPI_BASE              0x47900000
 #endif
+
+/* Boot parameters */
+#ifndef __ASSEMBLY__
+struct omap_boot_parameters {
+	unsigned int reserved;
+	unsigned int boot_device_descriptor;
+	unsigned char boot_device;
+	unsigned char reset_reason;
+};
+#endif
+
 #endif

arch/arm/include/asm/arch-am33xx/sys_proto.h +0 -1

index 7eacf27..91b614a 100644
@@ -11,7 +11,6 @@
 #ifndef _SYS_PROTO_H_
 #define _SYS_PROTO_H_
 #include <linux/mtd/omap_gpmc.h>
-#include <asm/ti-common/sys_proto.h>
 #include <asm/arch/cpu.h>
 
 u32 get_cpu_rev(void);

arch/arm/include/asm/arch-omap3/omap.h +13 -0

index 194b93b..537d13b 100644
@@ -142,6 +142,7 @@ struct gpio {
 
 #define NON_SECURE_SRAM_START		0x40208000 /* Works for GP & EMU */
 #define NON_SECURE_SRAM_END		0x40210000
+#define SRAM_SCRATCH_SPACE_ADDR		0x4020E000
 
 #define LOW_LEVEL_SRAM_STACK		0x4020FFFC

@@ -245,4 +246,16 @@ struct gpio {
 /* ABB tranxdone mask */
 #define OMAP_ABB_MPU_TXDONE_MASK	(0x1 << 26)
 
+/* Boot parameters */
+#ifndef __ASSEMBLY__
+struct omap_boot_parameters {
+	unsigned int boot_message;
+	unsigned char boot_device;
+	unsigned char reserved;
+	unsigned char reset_reason;
+	unsigned char ch_flags;
+	unsigned int boot_device_descriptor;
+};
+#endif
+
 #endif

arch/arm/include/asm/arch-omap3/sys_proto.h +2 -0

index 3e45ce1..cfa4d58 100644
@@ -75,4 +75,6 @@ void get_dieid(u32 *id);
 void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
 void omap3_set_aux_cr_secure(u32 acr);
 u32 warm_reset(void);
+
+void save_omap_boot_params(void);
 #endif

arch/arm/include/asm/arch-omap4/omap.h +11 -0

index d43dc26..12b1a09 100644
@@ -124,4 +124,15 @@ struct s32ktimer {
 /* ABB tranxdone mask */
 #define OMAP_ABB_MPU_TXDONE_MASK	(0x1 << 7)
 
+/* Boot parameters */
+#ifndef __ASSEMBLY__
+struct omap_boot_parameters {
+	unsigned int boot_message;
+	unsigned int boot_device_descriptor;
+	unsigned char boot_device;
+	unsigned char reset_reason;
+	unsigned char ch_flags;
+};
+#endif
+
 #endif

arch/arm/include/asm/arch-omap5/omap.h +12 -0

index 68c6d6d..524fae4 100644
@@ -235,4 +235,16 @@ struct ctrl_ioregs {
 };
 
 #endif /* __ASSEMBLY__ */
+
+/* Boot parameters */
+#ifndef __ASSEMBLY__
+struct omap_boot_parameters {
+	unsigned int boot_message;
+	unsigned int boot_device_descriptor;
+	unsigned char boot_device;
+	unsigned char reset_reason;
+	unsigned char ch_flags;
+};
+#endif
+
 #endif

arch/arm/include/asm/global_data.h +4 -6

index bb24f33..4e3ea55 100644
@@ -8,10 +8,6 @@
 #ifndef	__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
-#ifdef CONFIG_OMAP
-#include <asm/omap_boot.h>
-#endif
-
 /* Architecture-specific global data */
 struct arch_global_data {
 #if defined(CONFIG_FSL_ESDHC)

@@ -45,8 +41,10 @@ struct arch_global_data {
 	unsigned long tlb_size;
 #endif
 
-#ifdef CONFIG_OMAP
-	struct omap_boot_parameters omap_boot_params;
+#ifdef CONFIG_OMAP_COMMON
+	u32 omap_boot_device;
+	u32 omap_boot_mode;
+	u8 omap_ch_flags;
 #endif
 #ifdef CONFIG_FSL_LSCH3
 	unsigned long mem2_clk;

arch/arm/include/asm/omap_boot.h deleted +0 ~~-34~~

deleted file mode 100644
index f77f9d6..0000000
@@ -1,34 +0,0 @@
-/*
- * (C) Copyright 2013
- * Texas Instruments, <www.ti.com>
- *
- * Sricharan R <[email protected]>
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK	0xFF
-#define BOOT_DEVICE_OFFSET	0x8
-#define DEV_DESC_PTR_OFFSET	0x4
-#define DEV_DATA_PTR_OFFSET	0x18
-#define BOOT_MODE_OFFSET	0x8
-#define RESET_REASON_OFFSET	0x9
-#define CH_FLAGS_OFFSET		0xA
-
-#define CH_FLAGS_CHSETTINGS	(0x1 << 0)
-#define CH_FLAGS_CHRAM		(0x1 << 1)
-#define CH_FLAGS_CHFLASH	(0x1 << 2)
-#define CH_FLAGS_CHMMCSD	(0x1 << 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
-	char *boot_message;
-	unsigned int mem_boot_descriptor;
-	unsigned char omap_bootdevice;
-	unsigned char reset_reason;
-	unsigned char ch_flags;
-	unsigned long omap_bootmode;
-};
-#endif

arch/arm/include/asm/omap_common.h +9 -0

index 5469435..084ea68 100644
@@ -688,4 +688,13 @@ static inline u8 is_dra72x(void)
 #define OMAP_SRAM_SCRATCH_BOOT_PARAMS	(SRAM_SCRATCH_SPACE_ADDR + 0x24)
 #define OMAP5_SRAM_SCRATCH_SPACE_END	(SRAM_SCRATCH_SPACE_ADDR + 0x28)
 
+/* Boot parameters */
+#define DEVICE_DATA_OFFSET	0x18
+#define BOOT_MODE_OFFSET	0x8
+
+#define CH_FLAGS_CHSETTINGS	(1 << 0)
+#define CH_FLAGS_CHRAM		(1 << 1)
+#define CH_FLAGS_CHFLASH	(1 << 2)
+#define CH_FLAGS_CHMMCSD	(1 << 3)
+
 #endif /* _OMAP_COMMON_H_ */

arch/arm/include/asm/ti-common/sys_proto.h +1 -1

index d3ab75f..2bdb71c 100644
@@ -36,7 +36,7 @@ static inline u8 uboot_loaded_by_spl(void)
 	 * variable by both SPL and u-boot.Check out for CHSETTINGS, which is a
 	 * mandatory section if CH is present.
 	 */
-	if ((gd->arch.omap_boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS))
+	if (gd->arch.omap_ch_flags & CH_FLAGS_CHSETTINGS)
 		return 0;
 	else
 		return running_from_sdram();

board/compulab/cm_t54/cm_t54.c +1 -1

index fad0551..6d3b18a 100644
@@ -82,7 +82,7 @@ static int cm_t54_palmas_regulator_set(u8 vreg, u8 vval, u8 creg, u8 cval)
 #ifdef CONFIG_SYS_MMC_ENV_PART
 uint mmc_get_env_part(struct mmc *mmc)
 {
-	u32 bootmode = gd->arch.omap_boot_params.omap_bootmode;
+	u32 bootmode = gd->arch.omap_boot_mode;
 	uint bootpart = CONFIG_SYS_MMC_ENV_PART;
 
 	/*

include/configs/ti_omap4_common.h +1 -0

index e966134..659b4c6 100644
@@ -171,6 +171,7 @@
 /* No need for i2c in SPL mode as we will use SRI2C for PMIC access on OMAP4 */
 #undef CONFIG_SYS_I2C
 #undef CONFIG_SYS_I2C_OMAP24XX
+#undef CONFIG_SPL_I2C_SUPPORT
 #endif
 
 #endif /* __CONFIG_TI_OMAP4_COMMON_H */

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:58 UTC #2 lore raw

PATCH v5 1/8 omap-common: Common boot code OMAP3 support and cleanup

Quoted 20 lines · Paul Kocialkowski

This introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data.

Quoted 5 lines

All of this is only relevant when the U-Boot SPL is used. In cases it is not, save_boot_params should fallback to its weak (or board-specific) definition. save_omap_boot_params should not be called in that context either.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/015f5129/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #3 lore raw

PATCH v5 2/8 omap: SPL boot devices cleanup and completion

In reply to Paul Kocialkowski

This cleans up the SPL boot devices for omap platforms and introduces support for missing boot devices.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/include/asm/arch-am33xx/spl.h | 94 +++++++++++++++++++---------------
 arch/arm/include/asm/arch-omap3/spl.h  | 18 ++++---
 arch/arm/include/asm/arch-omap4/spl.h  | 20 ++++----
 arch/arm/include/asm/arch-omap5/spl.h  | 23 +++++----
 4 files changed, 88 insertions(+), 67 deletions(-)

arch/arm/include/asm/arch-am33xx/spl.h +54 ~~-40~~

index e756418..4ed8597 100644
@@ -7,51 +7,65 @@
 #ifndef	_ASM_ARCH_SPL_H_
 #define	_ASM_ARCH_SPL_H_
 
-#if defined(CONFIG_TI816X)
-#define BOOT_DEVICE_XIP		2
-#define BOOT_DEVICE_NAND	3
-#define BOOT_DEVICE_MMC1	6
-#define BOOT_DEVICE_MMC2	5
+#define BOOT_DEVICE_NONE	0x00
+#define BOOT_DEVICE_MMC2_2	0xFF
+
+#if defined(CONFIG_TI814X)
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_XIPWAIT	0x02
+#define BOOT_DEVICE_NAND	0x05
+#define BOOT_DEVICE_NAND_I2C	0x06
+#define BOOT_DEVICE_MMC2	0x08 /* ROM only supports 2nd instance. */
+#define BOOT_DEVICE_MMC1	0x09
+#define BOOT_DEVICE_SPI		0x15
+#define BOOT_DEVICE_UART	0x41
+#define BOOT_DEVICE_USBETH	0x44
+#define BOOT_DEVICE_CPGMAC	0x46
+
+#define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC2
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC1
+#elif defined(CONFIG_TI816X)
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_XIPWAIT	0x02
+#define BOOT_DEVICE_NAND	0x03
+#define BOOT_DEVICE_ONENAD	0x04
+#define BOOT_DEVICE_MMC2	0x05 /* ROM only supports 2nd instance. */
+#define BOOT_DEVICE_MMC1	0x06
 #define BOOT_DEVICE_UART	0x43
-#elif defined(CONFIG_AM43XX)
-#define BOOT_DEVICE_NOR		1
-#define BOOT_DEVICE_NAND	5
-#define BOOT_DEVICE_MMC1	7
-#define BOOT_DEVICE_MMC2	8
-#define BOOT_DEVICE_SPI		10
-#define BOOT_DEVICE_USB     13
-#define BOOT_DEVICE_UART	65
-#define BOOT_DEVICE_CPGMAC	71
-#else
-#define BOOT_DEVICE_XIP       	2
-#define BOOT_DEVICE_NAND	5
-#define BOOT_DEVICE_NAND_I2C	6
-#if defined(CONFIG_AM33XX)
-#define BOOT_DEVICE_MMC1	8
-#define BOOT_DEVICE_MMC2	9	/* eMMC or daughter card */
-#elif defined(CONFIG_TI814X)
-#define BOOT_DEVICE_MMC1	9
-#define BOOT_DEVICE_MMC2	8	/* ROM only supports 2nd instance */
-#endif
-#define BOOT_DEVICE_SPI		11
-#define BOOT_DEVICE_UART	65
-#define BOOT_DEVICE_USBETH	68
-#define BOOT_DEVICE_CPGMAC	70
-#endif
-#define BOOT_DEVICE_MMC2_2      0xFF
+#define BOOT_DEVICE_USB		0x45
 
-#if defined(CONFIG_AM33XX)
-#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
-#define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2
+#define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC2
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC1
+#elif defined(CONFIG_AM33XX)
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_XIPWAIT	0x02
+#define BOOT_DEVICE_NAND	0x05
+#define BOOT_DEVICE_NAND_I2C	0x06
+#define BOOT_DEVICE_MMC1	0x08
+#define BOOT_DEVICE_MMC2	0x09
+#define BOOT_DEVICE_SPI		0x15
+#define BOOT_DEVICE_UART	0x41
+#define BOOT_DEVICE_USBETH	0x44
+#define BOOT_DEVICE_CPGMAC	0x46
+
+#define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC1
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC2
 #elif defined(CONFIG_AM43XX)
-#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
+#define BOOT_DEVICE_NOR		0x01
+#define BOOT_DEVICE_NAND	0x05
+#define BOOT_DEVICE_MMC1	0x07
+#define BOOT_DEVICE_MMC2	0x08
+#define BOOT_DEVICE_SPI		0x0A
+#define BOOT_DEVICE_UART	0x41
+#define BOOT_DEVICE_USB		0x45
+#define BOOT_DEVICE_CPGMAC	0x47
+
+#define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC1
 #ifdef CONFIG_SPL_USB_SUPPORT
-#define MMC_BOOT_DEVICES_END   BOOT_DEVICE_USB
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_USB
 #else
-#define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC2
 #endif
-#elif defined(CONFIG_TI81XX)
-#define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC2
-#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC1
 #endif
+
 #endif

arch/arm/include/asm/arch-omap3/spl.h +10 -8

index 8350532..a31b4ea 100644
@@ -7,14 +7,16 @@
 #ifndef	_ASM_ARCH_SPL_H_
 #define	_ASM_ARCH_SPL_H_
 
-#define BOOT_DEVICE_NONE	0
-#define BOOT_DEVICE_XIP		1
-#define BOOT_DEVICE_NAND	2
-#define BOOT_DEVICE_ONENAND	3
-#define BOOT_DEVICE_MMC2	5 /*emmc*/
-#define BOOT_DEVICE_MMC1	6
-#define BOOT_DEVICE_XIPWAIT	7
-#define BOOT_DEVICE_MMC2_2      0xFF
+#define BOOT_DEVICE_NONE	0x00
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_NAND	0x02
+#define BOOT_DEVICE_ONENAND	0x03
+#define BOOT_DEVICE_MMC2	0x05
+#define BOOT_DEVICE_MMC1	0x06
+#define BOOT_DEVICE_XIPWAIT	0x07
+#define BOOT_DEVICE_MMC2_2      0x08
+#define BOOT_DEVICE_UART	0x10
+#define BOOT_DEVICE_USB		0x11
 
 #define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC2
 #define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC1

arch/arm/include/asm/arch-omap4/spl.h +11 -9

index fb842a2..bace92d 100644
@@ -7,15 +7,17 @@
 #ifndef	_ASM_ARCH_SPL_H_
 #define	_ASM_ARCH_SPL_H_
 
-#define BOOT_DEVICE_NONE	0
-#define BOOT_DEVICE_XIP		1
-#define BOOT_DEVICE_XIPWAIT	2
-#define BOOT_DEVICE_NAND	3
-#define BOOT_DEVICE_ONENAND	4
-#define BOOT_DEVICE_MMC1	5
-#define BOOT_DEVICE_MMC2	6
-#define BOOT_DEVICE_MMC2_2	0xFF
+#define BOOT_DEVICE_NONE	0x00
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_XIPWAIT	0x02
+#define BOOT_DEVICE_NAND	0x03
+#define BOOT_DEVICE_ONENAND	0x04
+#define BOOT_DEVICE_MMC1	0x05
+#define BOOT_DEVICE_MMC2	0x06
+#define BOOT_DEVICE_MMC2_2	0x07
+#define BOOT_DEVICE_UART	0x43
+#define BOOT_DEVICE_USB		0x45
 
 #define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC1
-#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC2
+#define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC2_2
 #endif

arch/arm/include/asm/arch-omap5/spl.h +13 ~~-10~~

index f707998..468ff5a 100644
@@ -7,17 +7,20 @@
 #ifndef	_ASM_ARCH_SPL_H_
 #define	_ASM_ARCH_SPL_H_
 
-#define BOOT_DEVICE_NONE        0
-#define BOOT_DEVICE_XIP         1
-#define BOOT_DEVICE_XIPWAIT     2
-#define BOOT_DEVICE_NAND        3
-#define BOOT_DEVICE_ONENAND    4
-#define BOOT_DEVICE_MMC1        5
-#define BOOT_DEVICE_MMC2        6
-#define BOOT_DEVICE_MMC2_2	7
-#define BOOT_DEVICE_SATA	9
-#define BOOT_DEVICE_SPI		10
+#define BOOT_DEVICE_NONE	0x00
+#define BOOT_DEVICE_XIP		0x01
+#define BOOT_DEVICE_XIPWAIT	0x02
+#define BOOT_DEVICE_NAND	0x03
+#define BOOT_DEVICE_ONENAND	0x04
+#define BOOT_DEVICE_MMC1	0x05
+#define BOOT_DEVICE_MMC2	0x06
+#define BOOT_DEVICE_MMC2_2	0x07
+#define BOOT_DEVICE_SATA	0x09
+#define BOOT_DEVICE_SPI		0x0A
+#define BOOT_DEVICE_QSPI_1	0x0A
+#define BOOT_DEVICE_QSPI_4	0x0B
 #define BOOT_DEVICE_UART	0x43
+#define BOOT_DEVICE_USB		0x45
 
 #define MMC_BOOT_DEVICES_START	BOOT_DEVICE_MMC1
 #define MMC_BOOT_DEVICES_END	BOOT_DEVICE_MMC2_2

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #4 lore raw

PATCH v5 2/8 omap: SPL boot devices cleanup and completion

Quoted 4 lines · Paul Kocialkowski

This cleans up the SPL boot devices for omap platforms and introduces support for missing boot devices.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/db4a3e7e/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #5 lore raw

PATCH v5 3/8 omap-common: Boot device define instead of hardcoded value

In reply to Paul Kocialkowski

Now that SPL boot devices are clearly defined, we can use BOOT_DEVICE_QSPI_4 instead of a hardcoded value.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap-common/boot-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/cpu/armv7/omap-common/boot-common.c +2 -2

index 3e67d62..f2a25dc 100644
@@ -48,14 +48,14 @@ void save_omap_boot_params(void)
 	if (boot_device == BOOT_DEVICE_NAND_I2C)
 		boot_device = BOOT_DEVICE_NAND;
 #endif
-#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
+#ifdef BOOT_DEVICE_QSPI_4
 	/*
 	 * We get different values for QSPI_1 and QSPI_4 being used, but
 	 * don't actually care about this difference.  Rather than
 	 * mangle the later code, if we're coming in as QSPI_4 just
 	 * change to the QSPI_1 value.
 	 */
-	if (boot_device == 11)
+	if (boot_device == BOOT_DEVICE_QSPI_4)
 		boot_device = BOOT_DEVICE_SPI;
 #endif

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #6 lore raw

PATCH v5 3/8 omap-common: Boot device define instead of hardcoded value

Quoted 4 lines · Paul Kocialkowski

Now that SPL boot devices are clearly defined, we can use BOOT_DEVICE_QSPI_4 instead of a hardcoded value.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/eaca2dec/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #7 lore raw

PATCH v5 4/8 siemens-am33x-common: Hardcoded value instead of non-included define

In reply to Paul Kocialkowski

The config file for the siemens-am33x-common was using OMAP_I2C_STANDARD, which is defined in a header that is not included in the config header. In most cases, it was being included by the code using CONFIG_SYS_OMAP24_I2C_SPEED, but it might not always be the case.

In particular, when introducing I2C SPL support in omap-common's boot-common.c, the header is missing and including it breaks other devices.

Signed-off-by Paul Kocialkowski <[email protected]>

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

include/configs/siemens-am33x-common.h +1 -1

index f33f9b4..f7bef70 100644
@@ -133,7 +133,7 @@
 #define CONFIG_I2C
 #define CONFIG_CMD_I2C
 #define CONFIG_SYS_I2C
-#define CONFIG_SYS_OMAP24_I2C_SPEED	OMAP_I2C_STANDARD
+#define CONFIG_SYS_OMAP24_I2C_SPEED	100000
 #define CONFIG_SYS_OMAP24_I2C_SLAVE	1
 #define CONFIG_SYS_I2C_OMAP24XX

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #8 lore raw

PATCH v5 4/8 siemens-am33x-common: Hardcoded value instead of non-included define

Quoted 9 lines · Paul Kocialkowski

The config file for the siemens-am33x-common was using OMAP_I2C_STANDARD, which is defined in a header that is not included in the config header. In most cases, it was being included by the code using CONFIG_SYS_OMAP24_I2C_SPEED, but it might not always be the case.
In particular, when introducing I2C SPL support in omap-common's boot-common.c, the header is missing and including it breaks other devices.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/a2341899/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #9 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

In reply to Paul Kocialkowski

OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device.

This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location.

Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap-common/boot-common.c | 52 ++++++++++++++++++++++++----
 arch/arm/include/asm/omap_common.h           |  4 +++
 2 files changed, 49 insertions(+), 7 deletions(-)

arch/arm/cpu/armv7/omap-common/boot-common.c +45 -7

index f2a25dc..5ec46fa 100644
@@ -21,6 +21,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+__weak u32 omap_sys_boot_device(void)
+{
+	return BOOT_DEVICE_NONE;
+}
+
 void save_omap_boot_params(void)
 {
 	u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);

@@ -34,9 +39,10 @@ void save_omap_boot_params(void)
 
 	omap_boot_params = (struct omap_boot_parameters *)boot_params;
 
-	/* Boot device */
-
 	boot_device = omap_boot_params->boot_device;
+	boot_mode = MMCSD_MODE_UNDEFINED;
+
+	/* Boot device */
 
 #ifdef BOOT_DEVICE_NAND_I2C
 	/*

@@ -58,16 +64,39 @@ void save_omap_boot_params(void)
 	if (boot_device == BOOT_DEVICE_QSPI_4)
 		boot_device = BOOT_DEVICE_SPI;
 #endif
+#if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \
+    (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \
+    (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT))
+	/*
+	 * When booting from peripheral booting, the boot device is not usable
+	 * as-is (unless there is support for it), so the boot device is instead
+	 * figured out using the SYS_BOOT pins.
+	 */
+	switch (boot_device) {
+#ifdef BOOT_DEVICE_UART
+	case BOOT_DEVICE_UART:
+#endif
+#ifdef BOOT_DEVICE_USB
+	case BOOT_DEVICE_USB:
+#endif
+		boot_device = omap_sys_boot_device();
+
+		/* MMC raw mode will fallback to FS mode. */
+		if ((boot_device >= MMC_BOOT_DEVICES_START) &&
+		    (boot_device <= MMC_BOOT_DEVICES_END))
+			boot_mode = MMCSD_MODE_RAW;
+
+		break;
+	}
+#endif
 
 	gd->arch.omap_boot_device = boot_device;
 
 	/* Boot mode */
 
-	boot_mode = MMCSD_MODE_UNDEFINED;
-
+#ifdef CONFIG_OMAP34XX
 	if ((boot_device >= MMC_BOOT_DEVICES_START) &&
 	    (boot_device <= MMC_BOOT_DEVICES_END)) {
-#ifdef CONFIG_OMAP34XX
 		switch (boot_device) {
 		case BOOT_DEVICE_MMC1:
 			boot_mode = MMCSD_MODE_FS;

@@ -76,7 +105,16 @@ void save_omap_boot_params(void)
 			boot_mode = MMCSD_MODE_RAW;
 			break;
 		}
+	}
 #else
+	/*
+	 * If the boot device was dynamically changed and doesn't match what
+	 * the bootrom initially booted, we cannot use the boot device
+	 * descriptor to figure out the boot mode.
+	 */
+	if ((boot_device == omap_boot_params->boot_device) &&
+	    (boot_device >= MMC_BOOT_DEVICES_START) &&
+	    (boot_device <= MMC_BOOT_DEVICES_END)) {
 		boot_params = omap_boot_params->boot_device_descriptor;
 		if ((boot_params < NON_SECURE_SRAM_START) ||
 		    (boot_params > NON_SECURE_SRAM_END))

@@ -92,12 +130,12 @@ void save_omap_boot_params(void)
 		if (boot_mode != MMCSD_MODE_FS &&
 		    boot_mode != MMCSD_MODE_RAW)
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
-			boot_mode = MMCSD_MODE_EMMCBOOT
+			boot_mode = MMCSD_MODE_EMMCBOOT;
 #else
 			boot_mode = MMCSD_MODE_UNDEFINED;
 #endif
-#endif
 	}
+#endif
 
 	gd->arch.omap_boot_mode = boot_mode;

arch/arm/include/asm/omap_common.h +4 -0

index 084ea68..056affc 100644
@@ -697,4 +697,8 @@ static inline u8 is_dra72x(void)
 #define CH_FLAGS_CHFLASH	(1 << 2)
 #define CH_FLAGS_CHMMCSD	(1 << 3)
 
+#ifndef __ASSEMBLY__
+u32 omap_sys_boot_device(void);
+#endif
+
 #endif /* _OMAP_COMMON_H_ */

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #10 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

Quoted 9 lines · Paul Kocialkowski

OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location.

Quoted 5 lines

Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/3f412f4c/attachment.sig>

Schmelzer Hannes

2015-08-25 08:40 UTC #11 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

Hi Paul, Tom,

i am failing bring up my AM335x boards (tseries, kwb) with bare UART connection since introducing this change.

--
U-Boot SPL 2015.10-rc2-00079-g35f2192-dirty (Aug 25 2015 - 07:34:24) boot device - 0
SPL: Unsupported Boot Device (0)!
### ERROR ### Please RESET the board ###
---

The source of my problem is the __weak function in omap-common/boot-common.c

__weak u32 omap_sys_boot_device(void)

{
     return BOOT_DEVICE_NONE;
}

which one is called on line #82

For my understanding this function should be called allways if chip has basically support for some BOOT_DEVICE_x __AND__ there is no implementation for it - the function should prevent target from stalling with selecting another (hopefully working) boot-device. Right ?

I am not sure at this time how to deal with the facts ... i see several possibilities:

a)
i have to implement some "omap_sys_boot_device" function in my boards - this would maybe sometimes comfortable but i think this is not inventors mind. It would be more convenient to implement it in some common place for AM335x or OMAP. But what do with the information about SYS_BOOT pins ? they always represent a boot-order ... which boot-device should it take ?

b) and/or something is wrong with the #ifdef ... construct at line #67 - In fact there is a problem with
/
defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)/

basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so the following switch/case calls in case of BOOT_DEVICE_UART this weak function.

further i think that this construct isn't complete yet, because it wants to handle all peripheral booting on AM335x or OMAP in general.

following peripherals are currently handled:

BOOT_DEVICE_UART
BOOT_DEVICE_USB
BOOT_DEVICE_USBETH

but there is also
BOOT_DEVICE_CPGMAC

Summary i think this changeset isn't complete.

How we want to deal with this facts ?

best regards,
Hannes

Quoted 24 lines · Tom Rini

Quoted 9 lines · Paul Kocialkowski
OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location.
Quoted 5 lines
Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling.
Signed-off-by Paul Kocialkowski <[email protected]>
Applied to u-boot/master, thanks!
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Paul Kocialkowski

author

2015-08-25 12:27 UTC #12 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

Le mardi 25 ao?t 2015 ? 10:40 +0200, Schmelzer Hannes a ?crit :

Quoted 4 lines

Hi Paul, Tom,
i am failing bring up my AM335x boards (tseries, kwb) with bare UART connection since introducing this change.

Does this mean that you're trying to get the device to load the full U-Boot binary over UART?

Quoted 5 lines

For my understanding this function should be called allways if chip has basically support for some BOOT_DEVICE_x __AND__ there is no implementation for it - the function should prevent target from stalling with selecting another (hopefully working) boot-device. Right ?

This is a fallback mechanism that allows selecting the boot device from the SYS_BOOT pins when the U-Boot SPL was loaded from peripheral booting (USB or UART) by the bootrom and that the U-Boot SPL has no support for continuing boot through that same peripheral (USB or UART).

It does require omap_sys_boot_device to be implemented for each platform (currently, only am33xx doesn't have a proper one). The point is that it selects another *memory* (read, not peripheral) boot device that the U-Boot SPL may be able to handle.

In any case, it offers a way to *maybe* put the U-Boot SPL on the right track instead of being unable to boot at all.

Quoted 10 lines

I am not sure at this time how to deal with the facts ... i see several possibilities:
a)
i have to implement some "omap_sys_boot_device" function in my boards
- this would maybe sometimes comfortable but i think this is not inventors mind. It would be more convenient to implement it in some common place for AM335x or OMAP. But what do with the information about SYS_BOOT pins ? they always represent a boot-order ... which boot-device should it take ?

That function is not supposed to be board-specific at all, but to be platform-specific. This is not the way to select the proper boot device, which is done by reading the boot info structure passed by the bootrom (first thing in omap-common/lowlevel_init.S).

Quoted 9 lines

b) and/or something is wrong with the #ifdef ... construct at line #67 -
In fact there is a problem with
defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)
basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so the following switch/case calls in case of BOOT_DEVICE_UART this weak function.

If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented.

The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT.

UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT.

Quoted 5 lines

further i think that this construct isn't complete yet, because it wants to handle all peripheral booting on AM335x or OMAP in general.
following peripherals are currently handled:

Quoted 8 lines

BOOT_DEVICE_UART
BOOT_DEVICE_USB
BOOT_DEVICE_USBETH
but there is also
BOOT_DEVICE_CPGMAC
Summary i think this changeset isn't complete.

Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx.

Quoted 18 lines · Tom Rini

Quoted 17 lines · Paul Kocialkowski
Quoted 15 lines
OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location.
Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling.
Signed-off-by Paul Kocialkowski <[email protected]>

Quoted 9 lines

Quoted 8 lines
Applied to u-boot/master, thanks!
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150825/f6ae12e5/attachment.sig>

Hannes Schmelzer

2015-08-25 12:52 UTC #13 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

Hi Paul,
thanks for answer.

Quoted 7 lines · Paul Kocialkowski

Le mardi 25 ao?t 2015 ? 10:40 +0200, Schmelzer Hannes a ?crit :
Quoted 4 lines
Hi Paul, Tom,
i am failing bring up my AM335x boards (tseries, kwb) with bare UART connection since introducing this change.
Does this mean that you're trying to get the device to load the full U-Boot binary over UART?

Yes i do so. On at least one BuR board this is the only possibility for very first startup.
Once U-Boot is loaded via UART we fetch the rest from TFTP and burn it into eMMC flash connected to MMC1.

Quoted 10 lines

Quoted 5 lines
For my understanding this function should be called allways if chip has basically support for some BOOT_DEVICE_x __AND__ there is no implementation for it - the function should prevent target from stalling with selecting another (hopefully working) boot-device. Right ?
This is a fallback mechanism that allows selecting the boot device from the SYS_BOOT pins when the U-Boot SPL was loaded from peripheral booting (USB or UART) by the bootrom and that the U-Boot SPL has no support for continuing boot through that same peripheral (USB or UART).

Quoted 7 lines

It does require omap_sys_boot_device to be implemented for each platform (currently, only am33xx doesn't have a proper one). The point is that it selects another *memory* (read, not peripheral) boot device that the U-Boot SPL may be able to handle.
In any case, it offers a way to *maybe* put the U-Boot SPL on the right track instead of being unable to boot at all.

Okay, i understand - this keeps track with my understanding.

Quoted 20 lines

Quoted 10 lines
I am not sure at this time how to deal with the facts ... i see several possibilities:
a)
i have to implement some "omap_sys_boot_device" function in my boards
- this would maybe sometimes comfortable but i think this is not inventors mind. It would be more convenient to implement it in some common place for AM335x or OMAP. But what do with the information about SYS_BOOT pins ? they always represent a boot-order ... which boot-device should it take ?
That function is not supposed to be board-specific at all, but to be platform-specific. This is not the way to select the proper boot device, which is done by reading the boot info structure passed by the bootrom (first thing in omap-common/lowlevel_init.S).
Quoted 5 lines
b) and/or something is wrong with the #ifdef ... construct at line #67 -
In fact there is a problem with
defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)

Quoted 7 lines

Quoted 4 lines
basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so the following switch/case calls in case of BOOT_DEVICE_UART this weak function.
If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented.

I don't think, there is everything right. Have a closer look to the #ifdef.

#if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \
     (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \
     (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT))

I have enabled CONFIG_SPL_YMODEM_SUPPORT, look at bur_am335x_common.h.

Quoted 4 lines

The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT.
UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT.

No, due to the fact that defined(BOOT_DEVICE_USBETH) is allways true (spl.h) and i don't have
CONFIG_SPL_USBETH_SUPPORT enabled, the #ifdef above:

defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)

becomes true and the followed switch/case does the rest.

Quoted 12 lines

Quoted 12 lines
further i think that this construct isn't complete yet, because it wants to handle all peripheral booting on AM335x or OMAP in general.
following peripherals are currently handled:
BOOT_DEVICE_UART
BOOT_DEVICE_USB
BOOT_DEVICE_USBETH
but there is also
BOOT_DEVICE_CPGMAC

Quoted 7 lines

Quoted 1 line
Summary i think this changeset isn't complete.
Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx.

Yes, thats possible von AM335x.
I will have a close look if it is necessary to implement here some fallback. But probably not, because the most likely case is that "full" U-Boot supports Ethernet and the SPL doesn't and not otherwise :-)

best regards,
Hannes

Paul Kocialkowski

author

2015-08-25 14:44 UTC #14 lore raw

PATCH v5 5/8 omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot

Quoted 14 lines

Quoted 3 lines
If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented.
I don't think, there is everything right. Have a closer look to the #ifdef.
#if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \
     (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \
     (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT))
I have enabled CONFIG_SPL_YMODEM_SUPPORT, look at bur_am335x_common.h.
Quoted 3 lines
The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT.

Quoted 8 lines

Quoted 1 line
UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT.
No, due to the fact that defined(BOOT_DEVICE_USBETH) is allways true (spl.h) and i don't have
CONFIG_SPL_USBETH_SUPPORT enabled, the #ifdef above:
defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)
becomes true and the followed switch/case does the rest.

Oh you're right, I hadn't thought this through.

I'll think about how to solve this in the cleanest way (I wouldn't want to duplicate the ifdef logic too much). Thanks for bringing this up.

Quoted 19 lines

Quoted 12 lines
Quoted 12 lines
further i think that this construct isn't complete yet, because it wants to handle all peripheral booting on AM335x or OMAP in general.
following peripherals are currently handled:
BOOT_DEVICE_UART
BOOT_DEVICE_USB
BOOT_DEVICE_USBETH
but there is also
BOOT_DEVICE_CPGMAC
Quoted 7 lines
Quoted 1 line
Summary i think this changeset isn't complete.
Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx.

Quoted 4 lines

Yes, thats possible von AM335x.
I will have a close look if it is necessary to implement here some fallback. But probably not, because the most likely case is that "full" U-Boot supports Ethernet and the SPL doesn't and not otherwise :-)

Alright then, that's fine with me. It's okay if the fallback mechanism doesn't handle all use cases, too.

Signature · 16 lines

Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150825/1c871ac1/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #15 lore raw

PATCH v5 6/8 omap3: Definitions for SYS_BOOT-based fallback boot device selection

In reply to Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP3, as well as the memory-preferred scheme for the interpretation of each value.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap3/Makefile           |  1 +
 arch/arm/cpu/armv7/omap3/boot.c             | 58 +++++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap3/sys_proto.h |  1 -
 3 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/omap3/boot.c

arch/arm/cpu/armv7/omap3/Makefile +1 -0

index cf86046..b2fce96 100644
@@ -8,6 +8,7 @@
 obj-y	:= lowlevel_init.o
 
 obj-y	+= board.o
+obj-y	+= boot.o
 obj-y	+= clock.o
 obj-y	+= sys_info.o
 ifdef CONFIG_SPL_BUILD

arch/arm/cpu/armv7/omap3/boot.c new file +58 -0

58 lines not on this page · raw message

arch/arm/include/asm/arch-omap3/sys_proto.h +0 -1

index cfa4d58..94f29fd 100644
@@ -52,7 +52,6 @@ void set_muxconf_regs(void);
 u32 get_cpu_family(void);
 u32 get_cpu_rev(void);
 u32 get_sku_id(void);
-u32 get_sysboot_value(void);
 u32 is_gpmc_muxed(void);
 u32 get_gpmc0_type(void);
 u32 get_gpmc0_width(void);

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #16 lore raw

PATCH v5 6/8 omap3: Definitions for SYS_BOOT-based fallback boot device selection

Quoted 4 lines · Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP3, as well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/9eaa0a7b/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #17 lore raw

PATCH v5 7/8 omap4: Definitions for SYS_BOOT-based fallback boot device selection

In reply to Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP4, as well as the memory-preferred scheme for the interpretation of each value.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap4/Makefile    |  1 +
 arch/arm/cpu/armv7/omap4/boot.c      | 60 ++++++++++++++++++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/prcm-regs.c |  1 +
 3 files changed, 62 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap4/boot.c

arch/arm/cpu/armv7/omap4/Makefile +1 -0

index 76a032a..564f1f6 100644
@@ -5,6 +5,7 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+obj-y	+= boot.o
 obj-y	+= sdram_elpida.o
 obj-y	+= hwinit.o
 obj-y	+= emif.o

arch/arm/cpu/armv7/omap4/boot.c new file +60 -0

60 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/prcm-regs.c +1 -0

index 1ed146b..8698ec7 100644
@@ -279,6 +279,7 @@ struct prcm_regs const omap4_prcm = {
 };
 
 struct omap_sys_ctrl_regs const omap4_ctrl = {
+	.control_status				= 0x4A0022C4,
 	.control_id_code			= 0x4A002204,
 	.control_std_fuse_opp_bgap		= 0x4a002260,
 	.control_status				= 0x4a0022c4,

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #18 lore raw

PATCH v5 7/8 omap4: Definitions for SYS_BOOT-based fallback boot device selection

Quoted 4 lines · Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP4, as well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/72c1dbcb/attachment.sig>

Paul Kocialkowski

author

2015-07-15 14:02 UTC #19 lore raw

PATCH v5 8/8 omap5: Definitions for SYS_BOOT-based fallback boot device selection

In reply to Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP5, as well as the memory-preferred scheme for the interpretation of each value.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 arch/arm/cpu/armv7/omap5/Makefile |  1 +
 arch/arm/cpu/armv7/omap5/boot.c   | 46 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap5/boot.c

arch/arm/cpu/armv7/omap5/Makefile +1 -0

index e709f14..f2930d5 100644
@@ -5,6 +5,7 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+obj-y	+= boot.o
 obj-y	+= hwinit.o
 obj-y	+= emif.o
 obj-y	+= sdram.o

arch/arm/cpu/armv7/omap5/boot.c new file +46 -0

46 lines not on this page · raw message

Signature · 1 line

1.9.1

Tom Rini

2015-07-28 14:59 UTC #20 lore raw

PATCH v5 8/8 omap5: Definitions for SYS_BOOT-based fallback boot device selection

Quoted 4 lines · Paul Kocialkowski

This introduces code to read the value of the SYS_BOOT pins on the OMAP5, as well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by Paul Kocialkowski <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/43e7f002/attachment.sig>

Paul Kocialkowski

author

2015-07-26 16:29 UTC #21 lore raw

v5 cover omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device

In reply to Paul Kocialkowski

Le mercredi 15 juillet 2015 ? 16:02 +0200, Paul Kocialkowski a ?crit :

Quoted 6 lines

Changes since v4:
* Take care of BOOT_DEVICE_USBETH and don't use the fallback when it's defined and active. This way, we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB defined to the same value and use USB eth or not based on CONFIG_SPL_USBETH_SUPPORT.
* boot_params casting clarification.

Tom, it's been more than a week since we last discussed this series.

Anything holding it back at this point, with the changes introduced in v5?

Thanks!

Quoted 39 lines

Changes since v3:
* Tested on the OMAP5 uEVM, adjusted SYS_BOOT interpretation.
* Typo fixup, other minor cleanups.
Changes since v2:
* ifdef save_boot_params definition and save_omap_boot_params calls with CONFIG_SPL to only use all this when U-Boot is loaded from the U-Boot SPL. This was always the case on != omap3 omap platforms, but is no longer the case with omap3 support (since some devices like the RX-51 are OMAP HS and have proprietary bootloaders loading U-Boot, and might even need some specific code instead).
The first part of this changeset introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data.
The second part of this changeset adds support for reading the SYS_BOOT pins on omap devices (no am33xx support yet) in order to fallback to the memory-preferred boot device described by the pins when peripheral booting is used. In particular, this allows loading the U-Boot SPL through either UART or USB and still having it to load U-Boot from memory when UART or USB are not valid boot devices.

Quoted 8 lines

This whole changeset was build-tested on all omap boards (omap3, omap4, omap5, am33xx) and tested at run-time on the Nokia RX-51 (N900), the LG Optimus Black (not supported yet) and the OMAP5 EVM.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot