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,