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

[snip]

arch/arm/cpu/armv7/omap-common/boot-common.c void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) · line 175

Quoted 6 lines

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

@@ -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.

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

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

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

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

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

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

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

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.

Quoted 4 lines

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

Quoted 8 lines

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 :

Quoted 14 lines · Paul Kocialkowski

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 22 lines

Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :

Quoted 20 lines · Paul Kocialkowski

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 11 lines

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 5 lines

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 :

Quoted 23 lines · Paul Kocialkowski

Quoted 22 lines

Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :

Quoted 20 lines · Paul Kocialkowski

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 2 lines

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?

Quoted 7 lines

Quoted 3 lines

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.

Quoted 71 lines

Le jeudi 09 juillet 2015 ? 13:29 +0530, Lokesh Vutla a ?crit :

Quoted 23 lines · Paul Kocialkowski

Quoted 22 lines

Le jeudi 02 juillet 2015 ? 15:10 -0400, Tom Rini a ?crit :

Quoted 20 lines · Paul Kocialkowski

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 11 lines

Quoted 11 lines

Quoted 2 lines

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?

Quoted 7 lines

Quoted 3 lines

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?

Quoted 3 lines

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.

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

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

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

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

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

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

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

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

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

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