* [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
@ 2015-07-01 22:19 Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
` (7 more replies)
0 siblings, 8 replies; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
This looks good to me, please let me know if it can be merged before 2015.07 is
released.
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 a single omap3 device only. I would be very
glad to see board maintainers give a go at the changeset before it gets merged,
especially on devices like the Nokia RX-51 (N900) where some specific adaptation
was needed.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion Paul Kocialkowski
` (6 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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.
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 <contact@paulk.fr>
---
arch/arm/cpu/armv7/omap-common/Makefile | 2 -
arch/arm/cpu/armv7/omap-common/boot-common.c | 124 ++++++++++++++-----------
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, 141 insertions(+), 167 deletions(-)
delete mode 100644 arch/arm/include/asm/omap_boot.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile
index f3725b2..464a5d1 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -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
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 7fc0a56..d7e2e59 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -17,27 +17,28 @@
#include <asm/arch/sys_proto.h>
#include <watchdog.h>
#include <scsi.h>
+#include <i2c.h>
DECLARE_GLOBAL_DATA_PTR;
void save_omap_boot_params(void)
{
- u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
- u8 boot_device;
- u32 dev_desc, dev_data;
+ u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ struct omap_boot_parameters *omap_boot_params;
+ u32 boot_device;
+ u32 boot_mode;
- if ((rom_params < NON_SECURE_SRAM_START) ||
- (rom_params > NON_SECURE_SRAM_END))
+ if ((boot_params < NON_SECURE_SRAM_START) ||
+ (boot_params > NON_SECURE_SRAM_END))
return;
- /*
- * rom_params can be type casted to omap_boot_parameters and
- * used. But it not correct to assume that romcode structure
- * encoding would be same as u-boot. So use the defined offsets.
- */
- boot_device = *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+ omap_boot_params = (struct omap_boot_parameters *)boot_params;
+
+ /* Boot device */
-#if defined(BOOT_DEVICE_NAND_I2C)
+ boot_device = omap_boot_params->boot_device;
+
+#ifdef BOOT_DEVICE_NAND_I2C
/*
* Re-map NAND&I2C boot-device to the "normal" NAND boot-device.
* Otherwise the SPL boot IF can't handle this device correctly.
@@ -47,29 +48,6 @@ void save_omap_boot_params(void)
if (boot_device == BOOT_DEVICE_NAND_I2C)
boot_device = BOOT_DEVICE_NAND;
#endif
- gd->arch.omap_boot_params.omap_bootdevice = boot_device;
-
- gd->arch.omap_boot_params.ch_flags =
- *((u8 *)(rom_params + CH_FLAGS_OFFSET));
-
- if ((boot_device >= MMC_BOOT_DEVICES_START) &&
- (boot_device <= MMC_BOOT_DEVICES_END)) {
-#if !defined(CONFIG_AM33XX) && !defined(CONFIG_TI81XX) && \
- !defined(CONFIG_AM43XX)
- if ((omap_hw_init_context() ==
- OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
- gd->arch.omap_boot_params.omap_bootmode =
- *((u8 *)(rom_params + BOOT_MODE_OFFSET));
- } else
-#endif
- {
- dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
- dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
- gd->arch.omap_boot_params.omap_bootmode =
- *((u32 *)(dev_data + BOOT_MODE_OFFSET));
- }
- }
-
#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
/*
* We get different values for QSPI_1 and QSPI_4 being used, but
@@ -77,31 +55,70 @@ void save_omap_boot_params(void)
* mangle the later code, if we're coming in as QSPI_4 just
* change to the QSPI_1 value.
*/
- if (gd->arch.omap_boot_params.omap_bootdevice == 11)
- gd->arch.omap_boot_params.omap_bootdevice = BOOT_DEVICE_SPI;
+ if (boot_device == 11)
+ boot_device = BOOT_DEVICE_SPI;
+#endif
+
+ gd->arch.omap_boot_device = boot_device;
+
+ /* Boot mode */
+
+ boot_mode = MMCSD_MODE_UNDEFINED;
+
+ 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;
+ break;
+ case BOOT_DEVICE_MMC2:
+ boot_mode = MMCSD_MODE_RAW;
+ break;
+ }
+#else
+ boot_params = omap_boot_params->boot_device_descriptor;
+ if ((boot_params < NON_SECURE_SRAM_START) ||
+ (boot_params > NON_SECURE_SRAM_END))
+ return;
+
+ boot_params = *((u32 *)(boot_params + DEVICE_DATA_OFFSET));
+ if ((boot_params < NON_SECURE_SRAM_START) ||
+ (boot_params > NON_SECURE_SRAM_END))
+ return;
+
+ boot_mode = *((u32 *)(boot_params + BOOT_MODE_OFFSET));
+
+ if (boot_mode != MMCSD_MODE_FS &&
+ boot_mode != MMCSD_MODE_RAW)
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ boot_mode = MMCSD_MODE_EMMCBOOT
+#else
+ boot_mode = MMCSD_MODE_UNDEFINED;
+#endif
+#endif
+ }
+
+ gd->arch.omap_boot_mode = boot_mode;
+
+#if !defined(CONFIG_TI814X) && !defined(CONFIG_TI816X) && \
+ !defined(CONFIG_AM33XX) && !defined(CONFIG_AM43XX)
+
+ /* CH flags */
+
+ gd->arch.omap_ch_flags = omap_boot_params->ch_flags;
#endif
}
#ifdef CONFIG_SPL_BUILD
u32 spl_boot_device(void)
{
- return (u32) (gd->arch.omap_boot_params.omap_bootdevice);
+ return gd->arch.omap_boot_device;
}
u32 spl_boot_mode(void)
{
- u32 val = gd->arch.omap_boot_params.omap_bootmode;
-
- if (val == MMCSD_MODE_RAW)
- return MMCSD_MODE_RAW;
- else if (val == MMCSD_MODE_FS)
- return MMCSD_MODE_FS;
- else
-#ifdef CONFIG_SUPPORT_EMMC_BOOT
- return MMCSD_MODE_EMMCBOOT;
-#else
- return MMCSD_MODE_UNDEFINED;
-#endif
+ return gd->arch.omap_boot_mode;
}
void spl_board_init(void)
@@ -116,9 +133,12 @@ void spl_board_init(void)
/* Prepare console output */
preloader_console_init();
-#ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
gpmc_init();
#endif
+#ifdef CONFIG_SPL_I2C_SUPPORT
+ i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
+#endif
#if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW_SUPPORT)
arch_misc_init();
#endif
@@ -152,7 +172,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
debug("image entry point: 0x%X\n", spl_image->entry_point);
/* Pass the saved boot_params from rom code */
- image_entry((u32 *)&gd->arch.omap_boot_params);
+ image_entry((u32 *)*((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS));
}
#endif
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 6c8f3bc..80794f9 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -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 */
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 746df92..5283135 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -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
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index b064c0c..17cb5b7 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -18,7 +18,6 @@
*/
#include <common.h>
#include <dm.h>
-#include <mmc.h>
#include <spl.h>
#include <asm/io.h>
#include <asm/arch/sys_proto.h>
@@ -27,8 +26,6 @@
#include <asm/armv7.h>
#include <asm/gpio.h>
#include <asm/omap_common.h>
-#include <asm/arch/mmc_host_def.h>
-#include <i2c.h>
#include <linux/compiler.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -73,62 +70,6 @@ const struct gpio_bank *const omap_gpio_bank = gpio_bank_34xx;
#endif
-#ifdef CONFIG_SPL_BUILD
-/*
-* We use static variables because global data is not ready yet.
-* Initialized data is available in SPL right from the beginning.
-* We would not typically need to save these parameters in regular
-* U-Boot. This is needed only in SPL at the moment.
-*/
-u32 omap3_boot_device = BOOT_DEVICE_NAND;
-
-/* auto boot mode detection is not possible for OMAP3 - hard code */
-u32 spl_boot_mode(void)
-{
- switch (spl_boot_device()) {
- case BOOT_DEVICE_MMC2:
- return MMCSD_MODE_RAW;
- case BOOT_DEVICE_MMC1:
- return MMCSD_MODE_FS;
- break;
- default:
- puts("spl: ERROR: unknown device - can't select boot mode\n");
- hang();
- }
-}
-
-u32 spl_boot_device(void)
-{
- return omap3_boot_device;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- switch (spl_boot_device()) {
- case BOOT_DEVICE_MMC1:
- omap_mmc_init(0, 0, 0, -1, -1);
- break;
- case BOOT_DEVICE_MMC2:
- case BOOT_DEVICE_MMC2_2:
- omap_mmc_init(1, 0, 0, -1, -1);
- break;
- }
- return 0;
-}
-
-void spl_board_init(void)
-{
- preloader_console_init();
-#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
- gpmc_init();
-#endif
-#ifdef CONFIG_SPL_I2C_SUPPORT
- i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
-#endif
-}
-#endif /* CONFIG_SPL_BUILD */
-
-
/******************************************************************************
* Routine: secure_unlock
* Description: Setup security registers for access
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 2497613..1e58772 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -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:
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h
index e5c0b0d..47962da 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -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
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 7eacf27..91b614a 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -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);
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h
index 194b93b..537d13b 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 3e45ce1..cfa4d58 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap4/omap.h b/arch/arm/include/asm/arch-omap4/omap.h
index d43dc26..12b1a09 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h
index 68c6d6d..524fae4 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -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
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index bb24f33..4e3ea55 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -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;
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
deleted file mode 100644
index f77f9d6..0000000
--- a/arch/arm/include/asm/omap_boot.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * (C) Copyright 2013
- * Texas Instruments, <www.ti.com>
- *
- * Sricharan R <r.sricharan@ti.com>
- *
- * 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
diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h
index 5469435..084ea68 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -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_ */
diff --git a/arch/arm/include/asm/ti-common/sys_proto.h b/arch/arm/include/asm/ti-common/sys_proto.h
index d3ab75f..2bdb71c 100644
--- a/arch/arm/include/asm/ti-common/sys_proto.h
+++ b/arch/arm/include/asm/ti-common/sys_proto.h
@@ -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();
diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index fad0551..6d3b18a 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -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;
/*
diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h
index e966134..659b4c6 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -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 */
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value Paul Kocialkowski
` (5 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
This cleans up the SPL boot devices for omap platforms and introduces support
for missing boot devices.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
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(-)
diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h
index e756418..4ed8597 100644
--- a/arch/arm/include/asm/arch-am33xx/spl.h
+++ b/arch/arm/include/asm/arch-am33xx/spl.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap3/spl.h b/arch/arm/include/asm/arch-omap3/spl.h
index 8350532..a31b4ea 100644
--- a/arch/arm/include/asm/arch-omap3/spl.h
+++ b/arch/arm/include/asm/arch-omap3/spl.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap4/spl.h b/arch/arm/include/asm/arch-omap4/spl.h
index fb842a2..bace92d 100644
--- a/arch/arm/include/asm/arch-omap4/spl.h
+++ b/arch/arm/include/asm/arch-omap4/spl.h
@@ -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
diff --git a/arch/arm/include/asm/arch-omap5/spl.h b/arch/arm/include/asm/arch-omap5/spl.h
index f707998..468ff5a 100644
--- a/arch/arm/include/asm/arch-omap5/spl.h
+++ b/arch/arm/include/asm/arch-omap5/spl.h
@@ -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
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define Paul Kocialkowski
` (4 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c
index d7e2e59..38fa640 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -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
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
` (2 preceding siblings ...)
2015-07-01 22:19 ` [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
` (3 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
include/configs/siemens-am33x-common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/siemens-am33x-common.h b/include/configs/siemens-am33x-common.h
index 7e75797..8b49426 100644
--- a/include/configs/siemens-am33x-common.h
+++ b/include/configs/siemens-am33x-common.h
@@ -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
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
` (3 preceding siblings ...)
2015-07-01 22:19 ` [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-02 19:10 ` Tom Rini
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection Paul Kocialkowski
` (2 subsequent siblings)
7 siblings, 2 replies; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 51 ++++++++++++++++++++++++----
arch/arm/include/asm/omap_common.h | 4 +++
2 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 38fa640..59ee73a 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -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,38 @@ 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))
+ /*
+ * 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 +104,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 +129,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;
diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h
index 084ea68..056affc 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -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_ */
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
` (4 preceding siblings ...)
2015-07-01 22:19 ` [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 7/8] omap4: " Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 8/8] omap5: " Paul Kocialkowski
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
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
diff --git a/arch/arm/cpu/armv7/omap3/Makefile b/arch/arm/cpu/armv7/omap3/Makefile
index cf86046..b2fce96 100644
--- a/arch/arm/cpu/armv7/omap3/Makefile
+++ b/arch/arm/cpu/armv7/omap3/Makefile
@@ -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
diff --git a/arch/arm/cpu/armv7/omap3/boot.c b/arch/arm/cpu/armv7/omap3/boot.c
new file mode 100644
index 0000000..66576b2
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap3/boot.c
@@ -0,0 +1,58 @@
+/*
+ * OMAP3 boot
+ *
+ * Copyright (C) 2015 Paul Kocialkowski <contact@paulk.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/sys_proto.h>
+#include <spl.h>
+
+static u32 boot_devices[] = {
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC2_2,
+};
+
+u32 omap_sys_boot_device(void)
+{
+ struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
+ u32 sys_boot;
+
+ /* Grab the first 5 bits of the status register for SYS_BOOT. */
+ sys_boot = readl(&ctrl_base->status) & ((1 << 5) - 1);
+
+ if (sys_boot >= (sizeof(boot_devices) / sizeof(u32)))
+ return BOOT_DEVICE_NONE;
+
+ return boot_devices[sys_boot];
+}
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h
index cfa4d58..94f29fd 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -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);
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 7/8] omap4: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
` (5 preceding siblings ...)
2015-07-01 22:19 ` [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 8/8] omap5: " Paul Kocialkowski
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
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
diff --git a/arch/arm/cpu/armv7/omap4/Makefile b/arch/arm/cpu/armv7/omap4/Makefile
index 76a032a..564f1f6 100644
--- a/arch/arm/cpu/armv7/omap4/Makefile
+++ b/arch/arm/cpu/armv7/omap4/Makefile
@@ -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
diff --git a/arch/arm/cpu/armv7/omap4/boot.c b/arch/arm/cpu/armv7/omap4/boot.c
new file mode 100644
index 0000000..4b5aa77
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap4/boot.c
@@ -0,0 +1,60 @@
+/*
+ * OMAP4 boot
+ *
+ * Copyright (C) 2015 Paul Kocialkowski <contact@paulk.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/omap_common.h>
+#include <spl.h>
+
+static u32 boot_devices[] = {
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIPWAIT,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_ONENAND,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_MMC2_2,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC2_2,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_MMC2_2,
+ BOOT_DEVICE_MMC2_2,
+ BOOT_DEVICE_NONE,
+ BOOT_DEVICE_XIPWAIT,
+};
+
+u32 omap_sys_boot_device(void)
+{
+ u32 sys_boot;
+
+ /* Grab the first 5 bits of the status register for SYS_BOOT. */
+ sys_boot = readl((u32 *) (*ctrl)->control_status) & ((1 << 5) - 1);
+
+ if (sys_boot >= (sizeof(boot_devices) / sizeof(u32)))
+ return BOOT_DEVICE_NONE;
+
+ return boot_devices[sys_boot];
+}
diff --git a/arch/arm/cpu/armv7/omap4/prcm-regs.c b/arch/arm/cpu/armv7/omap4/prcm-regs.c
index 1ed146b..8698ec7 100644
--- a/arch/arm/cpu/armv7/omap4/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap4/prcm-regs.c
@@ -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,
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 8/8] omap5: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
` (6 preceding siblings ...)
2015-07-01 22:19 ` [U-Boot] [PATCH v4 7/8] omap4: " Paul Kocialkowski
@ 2015-07-01 22:19 ` Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
7 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-01 22:19 UTC (permalink / raw
To: u-boot
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 <contact@paulk.fr>
---
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
diff --git a/arch/arm/cpu/armv7/omap5/Makefile b/arch/arm/cpu/armv7/omap5/Makefile
index e709f14..f2930d5 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -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
diff --git a/arch/arm/cpu/armv7/omap5/boot.c b/arch/arm/cpu/armv7/omap5/boot.c
new file mode 100644
index 0000000..583becc
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/boot.c
@@ -0,0 +1,46 @@
+/*
+ * OMAP5 boot
+ *
+ * Copyright (C) 2015 Paul Kocialkowski <contact@paulk.fr>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/omap_common.h>
+#include <spl.h>
+
+static u32 boot_devices[] = {
+#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_SATA,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_SPI,
+ BOOT_DEVICE_SPI,
+#else
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_NAND,
+ BOOT_DEVICE_MMC1,
+ BOOT_DEVICE_SATA,
+ BOOT_DEVICE_XIP,
+ BOOT_DEVICE_MMC2,
+ BOOT_DEVICE_XIPWAIT,
+#endif
+};
+
+u32 omap_sys_boot_device(void)
+{
+ u32 sys_boot;
+
+ /* Grab the first 4 bits of the status register for SYS_BOOT. */
+ sys_boot = readl((u32 *) (*ctrl)->control_status) & ((1 << 4) - 1);
+
+ if (sys_boot >= (sizeof(boot_devices) / sizeof(u32)))
+ return BOOT_DEVICE_NONE;
+
+ return boot_devices[sys_boot];
+}
--
1.9.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-01 22:19 ` [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
@ 2015-07-02 19:10 ` Tom Rini
2015-07-02 19:53 ` Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
1 sibling, 1 reply; 24+ messages in thread
From: Tom Rini @ 2015-07-02 19:10 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> 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.
Can you elaborate on this more please? The normal flow is that you load
SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
then U-Boot via USB RNDIS. It sounds like you're changing things so
that you load first via UART and then via say SD (or whatever the pins
would be set for) unless you have the bits enabled for loading the next
stage via that peripheral, which is the default case.
Now, I know you didn't do this just for fun, so what's the use case you
have here exactly? Thanks!
--
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/20150702/9637b28a/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-02 19:10 ` Tom Rini
@ 2015-07-02 19:53 ` Paul Kocialkowski
2015-07-09 7:59 ` Lokesh Vutla
0 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-02 19:53 UTC (permalink / raw
To: u-boot
Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> > 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.
>
> Can you elaborate on this more please? The normal flow is that you load
> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
> then U-Boot via USB RNDIS. It sounds like you're changing things so
> that you load first via UART and then via say SD (or whatever the pins
> would be set for) unless you have the bits enabled for loading the next
> stage via that peripheral, which is the default case.
Well to be honest, I haven't tried loading the main U-Boot binary via
the USB ethernet gaget, after loading the U-Boot SPL via USB with the
omap bootrom. Perhaps this would have worked just as well, but it isn't
enabled for the OMAP3 and I thought it would be easier to just load from
e.g. the MMC.
> Now, I know you didn't do this just for fun, so what's the use case you
> have here exactly? Thanks!
My use case is a bit specific: the device I have only has UART Tx
available (so I cannot send anything) and USB available. Hence, I needed
a way to load the main U-Boot binary from a place I could easily reflash
(the external sdcard in my case).
Do you think it would be worth adding support for USB ethernet on omap
platforms?
By the way, this patch set doesn't conflict with anything, and could
still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
defined.
That is, provided that I make my code check for BOOT_DEVICE_USBETH and
not do anything if it is defined, so that we can have both
BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value)
and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or
not.
--
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/20150702/ef955aef/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-02 19:53 ` Paul Kocialkowski
@ 2015-07-09 7:59 ` Lokesh Vutla
2015-07-09 8:27 ` Paul Kocialkowski
0 siblings, 1 reply; 24+ messages in thread
From: Lokesh Vutla @ 2015-07-09 7:59 UTC (permalink / raw
To: u-boot
On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote:
> Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
>> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
>>> 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.
>>
>> Can you elaborate on this more please? The normal flow is that you load
>> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
>> then U-Boot via USB RNDIS. It sounds like you're changing things so
>> that you load first via UART and then via say SD (or whatever the pins
>> would be set for) unless you have the bits enabled for loading the next
>> stage via that peripheral, which is the default case.
>
> Well to be honest, I haven't tried loading the main U-Boot binary via
> the USB ethernet gaget, after loading the U-Boot SPL via USB with the
> omap bootrom. Perhaps this would have worked just as well, but it isn't
> enabled for the OMAP3 and I thought it would be easier to just load from
> e.g. the MMC.
No, this is not the normal convention.
Since you are able to load SPL via USB ethernet gadget,
you should be able to load u-boot also. USB ethernet gadget should be enabled in SPL.
>
>> Now, I know you didn't do this just for fun, so what's the use case you
>> have here exactly? Thanks!
>
> My use case is a bit specific: the device I have only has UART Tx
> available (so I cannot send anything) and USB available. Hence, I needed
> a way to load the main U-Boot binary from a place I could easily reflash
> (the external sdcard in my case).
>
> Do you think it would be worth adding support for USB ethernet on omap
> platforms?
>
> By the way, this patch set doesn't conflict with anything, and could
> still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
> defined.
Even though it does not conflict, this is not how omap platforms are being done.
SPL and u-boot are always loaded via the same boot device.
I would really not recommend this patch.
Thanks and regards,
Lokesh
>
> That is, provided that I make my code check for BOOT_DEVICE_USBETH and
> not do anything if it is defined, so that we can have both
> BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value)
> and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or
> not.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-09 7:59 ` Lokesh Vutla
@ 2015-07-09 8:27 ` Paul Kocialkowski
2015-07-14 19:17 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-09 8:27 UTC (permalink / raw
To: u-boot
Le jeudi 09 juillet 2015 ? 13:29 +0530, Lokesh Vutla a ?crit :
> On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote:
> > Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
> >> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> >>> 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.
> >>
> >> Can you elaborate on this more please? The normal flow is that you load
> >> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
> >> then U-Boot via USB RNDIS. It sounds like you're changing things so
> >> that you load first via UART and then via say SD (or whatever the pins
> >> would be set for) unless you have the bits enabled for loading the next
> >> stage via that peripheral, which is the default case.
> >
> > Well to be honest, I haven't tried loading the main U-Boot binary via
> > the USB ethernet gaget, after loading the U-Boot SPL via USB with the
> > omap bootrom. Perhaps this would have worked just as well, but it isn't
> > enabled for the OMAP3 and I thought it would be easier to just load from
> > e.g. the MMC.
>
> No, this is not the normal convention.
> Since you are able to load SPL via USB ethernet gadget,
The bootrom is not making any USB ethernet gadget available, it's using
its own USB bulk protocol that is defined on the TRM. But I reckon it's
"USB booting" either way.
> you should be able to load u-boot also. USB ethernet gadget should be
> enabled in SPL.
I'm not saying it should not. This would be a useful feature and loading
both parts via USB makes sense.
> >> Now, I know you didn't do this just for fun, so what's the use case you
> >> have here exactly? Thanks!
> >
> > My use case is a bit specific: the device I have only has UART Tx
> > available (so I cannot send anything) and USB available. Hence, I needed
> > a way to load the main U-Boot binary from a place I could easily reflash
> > (the external sdcard in my case).
> >
> > Do you think it would be worth adding support for USB ethernet on omap
> > platforms?
> >
> > By the way, this patch set doesn't conflict with anything, and could
> > still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
> > defined.
>
> Even though it does not conflict, this is not how omap platforms are being done.
> SPL and u-boot are always loaded via the same boot device.
> I would really not recommend this patch.
My patch simply adds a feature. Why does it matter if it's consistent or
not with the way people at TI thought it should be used?
Also, the behaviour my patch implements has nothing specific to the OMAP
and is a fallback mechanism. It will only be used when the device has no
other working boot method.
Are you suggesting we should let the device hang in that case?
I agree it could be useful to print some error message indicating that
the fallback is being used, so that users know there is something wrong
with the intended boot method.
> > That is, provided that I make my code check for BOOT_DEVICE_USBETH and
> > not do anything if it is defined, so that we can have both
> > BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value)
> > and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or
> > not.
--
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/20150709/ac3d26ee/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-09 8:27 ` Paul Kocialkowski
@ 2015-07-14 19:17 ` Tom Rini
2015-07-15 0:35 ` Paul Kocialkowski
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2015-07-14 19:17 UTC (permalink / raw
To: u-boot
On Thu, Jul 09, 2015 at 10:27:38AM +0200, Paul Kocialkowski wrote:
> Le jeudi 09 juillet 2015 ? 13:29 +0530, Lokesh Vutla a ?crit :
> > On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote:
> > > Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
> > >> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> > >>> 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.
> > >>
> > >> Can you elaborate on this more please? The normal flow is that you load
> > >> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
> > >> then U-Boot via USB RNDIS. It sounds like you're changing things so
> > >> that you load first via UART and then via say SD (or whatever the pins
> > >> would be set for) unless you have the bits enabled for loading the next
> > >> stage via that peripheral, which is the default case.
> > >
> > > Well to be honest, I haven't tried loading the main U-Boot binary via
> > > the USB ethernet gaget, after loading the U-Boot SPL via USB with the
> > > omap bootrom. Perhaps this would have worked just as well, but it isn't
> > > enabled for the OMAP3 and I thought it would be easier to just load from
> > > e.g. the MMC.
> >
> > No, this is not the normal convention.
> > Since you are able to load SPL via USB ethernet gadget,
>
> The bootrom is not making any USB ethernet gadget available, it's using
> its own USB bulk protocol that is defined on the TRM. But I reckon it's
> "USB booting" either way.
>
> > you should be able to load u-boot also. USB ethernet gadget should be
> > enabled in SPL.
>
> I'm not saying it should not. This would be a useful feature and loading
> both parts via USB makes sense.
>
> > >> Now, I know you didn't do this just for fun, so what's the use case you
> > >> have here exactly? Thanks!
> > >
> > > My use case is a bit specific: the device I have only has UART Tx
> > > available (so I cannot send anything) and USB available. Hence, I needed
> > > a way to load the main U-Boot binary from a place I could easily reflash
> > > (the external sdcard in my case).
> > >
> > > Do you think it would be worth adding support for USB ethernet on omap
> > > platforms?
> > >
> > > By the way, this patch set doesn't conflict with anything, and could
> > > still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
> > > defined.
> >
> > Even though it does not conflict, this is not how omap platforms are being done.
> > SPL and u-boot are always loaded via the same boot device.
> > I would really not recommend this patch.
>
> My patch simply adds a feature. Why does it matter if it's consistent or
> not with the way people at TI thought it should be used?
>
> Also, the behaviour my patch implements has nothing specific to the OMAP
> and is a fallback mechanism. It will only be used when the device has no
> other working boot method.
>
> Are you suggesting we should let the device hang in that case?
>
> I agree it could be useful to print some error message indicating that
> the fallback is being used, so that users know there is something wrong
> with the intended boot method.
So, I've been thinking about this a bit. The current default case is
IMHO the one we want things to continue to default to. And the code
does that, right? You're just adding in code to allow for "came via $X,
load next from SD" which is really handy on OMAP3 (and OMAP4 and
OMAP5/DRA7xx) where we have a USB gadget boot mode that U-Boot doesn't
also support. We could kludge it and say "came via ROM USB squirt,
start up USB RNDIS". Or we could kludge it and say "came via ROM USB
squirt, poke the SD slot". So long as the current cases are the default
for the boards that use them, and I believe they are, I'm OK with doing
what the people using the setup want.
--
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/20150714/4be486d5/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup
2015-07-01 22:19 ` [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
@ 2015-07-14 22:11 ` Tom Rini
2015-07-14 23:04 ` Paul Kocialkowski
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:11 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:37AM +0200, Paul Kocialkowski wrote:
[snip]
> @@ -152,7 +172,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
>
> debug("image entry point: 0x%X\n", spl_image->entry_point);
> /* Pass the saved boot_params from rom code */
> - image_entry((u32 *)&gd->arch.omap_boot_params);
> + image_entry((u32 *)*((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS));
OK, that's a bit too much casting in there.
--
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/20150714/2abfac92/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion
2015-07-01 22:19 ` [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion Paul Kocialkowski
@ 2015-07-14 22:11 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:11 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:38AM +0200, Paul Kocialkowski wrote:
> This cleans up the SPL boot devices for omap platforms and introduces support
> for missing boot devices.
>
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/c5e496f1/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value
2015-07-01 22:19 ` [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value Paul Kocialkowski
@ 2015-07-14 22:11 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:11 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:39AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/28e78169/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define
2015-07-01 22:19 ` [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define Paul Kocialkowski
@ 2015-07-14 22:11 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:11 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:40AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/684b6d20/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-01 22:19 ` [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
2015-07-02 19:10 ` Tom Rini
@ 2015-07-14 22:12 ` Tom Rini
1 sibling, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:12 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/58895341/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 ` [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection Paul Kocialkowski
@ 2015-07-14 22:12 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:12 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:42AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/3b026563/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 7/8] omap4: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 ` [U-Boot] [PATCH v4 7/8] omap4: " Paul Kocialkowski
@ 2015-07-14 22:12 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:12 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:43AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/295bb60c/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 8/8] omap5: Definitions for SYS_BOOT-based fallback boot device selection
2015-07-01 22:19 ` [U-Boot] [PATCH v4 8/8] omap5: " Paul Kocialkowski
@ 2015-07-14 22:12 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2015-07-14 22:12 UTC (permalink / raw
To: u-boot
On Thu, Jul 02, 2015 at 12:19:44AM +0200, Paul Kocialkowski wrote:
> 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 <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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/20150714/eb4575e7/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup
2015-07-14 22:11 ` Tom Rini
@ 2015-07-14 23:04 ` Paul Kocialkowski
0 siblings, 0 replies; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-14 23:04 UTC (permalink / raw
To: u-boot
Le mardi 14 juillet 2015 ? 18:11 -0400, Tom Rini a ?crit :
> On Thu, Jul 02, 2015 at 12:19:37AM +0200, Paul Kocialkowski wrote:
>
> [snip]
> > @@ -152,7 +172,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
> >
> > debug("image entry point: 0x%X\n", spl_image->entry_point);
> > /* Pass the saved boot_params from rom code */
> > - image_entry((u32 *)&gd->arch.omap_boot_params);
> > + image_entry((u32 *)*((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS));
>
> OK, that's a bit too much casting in there.
Well, I could separate this in a few lines with clearer casting indeed !
--
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/20150715/b0c7dd93/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
2015-07-14 19:17 ` Tom Rini
@ 2015-07-15 0:35 ` Paul Kocialkowski
0 siblings, 0 replies; 24+ messages in thread
From: Paul Kocialkowski @ 2015-07-15 0:35 UTC (permalink / raw
To: u-boot
Le mardi 14 juillet 2015 ? 15:17 -0400, Tom Rini a ?crit :
> On Thu, Jul 09, 2015 at 10:27:38AM +0200, Paul Kocialkowski wrote:
> > Le jeudi 09 juillet 2015 ? 13:29 +0530, Lokesh Vutla a ?crit :
> > > On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote:
> > > > Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :
> > > >> On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote:
> > > >>> 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.
> > > >>
> > > >> Can you elaborate on this more please? The normal flow is that you load
> > > >> SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and
> > > >> then U-Boot via USB RNDIS. It sounds like you're changing things so
> > > >> that you load first via UART and then via say SD (or whatever the pins
> > > >> would be set for) unless you have the bits enabled for loading the next
> > > >> stage via that peripheral, which is the default case.
> > > >
> > > > Well to be honest, I haven't tried loading the main U-Boot binary via
> > > > the USB ethernet gaget, after loading the U-Boot SPL via USB with the
> > > > omap bootrom. Perhaps this would have worked just as well, but it isn't
> > > > enabled for the OMAP3 and I thought it would be easier to just load from
> > > > e.g. the MMC.
> > >
> > > No, this is not the normal convention.
> > > Since you are able to load SPL via USB ethernet gadget,
> >
> > The bootrom is not making any USB ethernet gadget available, it's using
> > its own USB bulk protocol that is defined on the TRM. But I reckon it's
> > "USB booting" either way.
> >
> > > you should be able to load u-boot also. USB ethernet gadget should be
> > > enabled in SPL.
> >
> > I'm not saying it should not. This would be a useful feature and loading
> > both parts via USB makes sense.
> >
> > > >> Now, I know you didn't do this just for fun, so what's the use case you
> > > >> have here exactly? Thanks!
> > > >
> > > > My use case is a bit specific: the device I have only has UART Tx
> > > > available (so I cannot send anything) and USB available. Hence, I needed
> > > > a way to load the main U-Boot binary from a place I could easily reflash
> > > > (the external sdcard in my case).
> > > >
> > > > Do you think it would be worth adding support for USB ethernet on omap
> > > > platforms?
> > > >
> > > > By the way, this patch set doesn't conflict with anything, and could
> > > > still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not
> > > > defined.
> > >
> > > Even though it does not conflict, this is not how omap platforms are being done.
> > > SPL and u-boot are always loaded via the same boot device.
> > > I would really not recommend this patch.
> >
> > My patch simply adds a feature. Why does it matter if it's consistent or
> > not with the way people at TI thought it should be used?
> >
> > Also, the behaviour my patch implements has nothing specific to the OMAP
> > and is a fallback mechanism. It will only be used when the device has no
> > other working boot method.
> >
> > Are you suggesting we should let the device hang in that case?
> >
> > I agree it could be useful to print some error message indicating that
> > the fallback is being used, so that users know there is something wrong
> > with the intended boot method.
>
> So, I've been thinking about this a bit. The current default case is
> IMHO the one we want things to continue to default to. And the code
> does that, right?
That's correct, this is what I had in mind. This is just a fallback and
should only change something when the device would not be able to boot
at all otherwise.
> You're just adding in code to allow for "came via $X, load next from
> SD" which is really handy on OMAP3 (and OMAP4 and OMAP5/DRA7xx) where
> we have a USB gadget boot mode that U-Boot doesn't also support. We
> could kludge it and say "came via ROM USB squirt, start up USB RNDIS".
> Or we could kludge it and say "came via ROM USB squirt, poke the SD
> slot". So long as the current cases are the default for the boards
> that use them, and I believe they are, I'm OK with doing what the
> people using the setup want.
Great! I'll still make another version, with the few comments that have
developped in this discussion (see some of my previous emails) and I
think it'll be good to go. I didn't want to do it sooner in case I had
to drop the whole series.
Thanks for the review,
--
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/20150715/06e1e23d/attachment.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-07-15 0:35 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-01 22:19 [U-Boot] [PATCH v4 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 1/8] omap-common: Common boot code OMAP3 support and cleanup Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-14 23:04 ` Paul Kocialkowski
2015-07-01 22:19 ` [U-Boot] [PATCH v4 2/8] omap: SPL boot devices cleanup and completion Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 3/8] omap-common: Boot device define instead of hardcoded value Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 4/8] siemens-am33x-common: Hardcoded value instead of non-included define Paul Kocialkowski
2015-07-14 22:11 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot Paul Kocialkowski
2015-07-02 19:10 ` Tom Rini
2015-07-02 19:53 ` Paul Kocialkowski
2015-07-09 7:59 ` Lokesh Vutla
2015-07-09 8:27 ` Paul Kocialkowski
2015-07-14 19:17 ` Tom Rini
2015-07-15 0:35 ` Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 6/8] omap3: Definitions for SYS_BOOT-based fallback boot device selection Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 7/8] omap4: " Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
2015-07-01 22:19 ` [U-Boot] [PATCH v4 8/8] omap5: " Paul Kocialkowski
2015-07-14 22:12 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.