| Message ID | 1435789184-6815-6-git-send-email-contact@paulk.fr |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
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!
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.
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. >
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.
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.
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>
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,
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_ */
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(-)