AM625: How to enable usb_ether in u-boot

Hi,

usb_ether is not enabled or validated on any of the TI ARM64 processors.

Do you need it in your production or development environment?

Hi,

I need this for both, but it is really required for the production environment

I can understand you use it in development, and I might have an alternative solution. But can you please explain your use case in production? why can you not add the env variables to the U-Boot binaries and directly use them, instead modify the variables through bootscript.scr at runtime?

Hi,

At present I need to send below configuration from Host PC to am625 u-boot prompt, for these use case I need the usb ether. 

1. configure MLC eMMC to pseudo SLC mode using boot script

 => mmc hwpartition user enh 0 4328945 wrrel on complete

2. configure the eMMC boot partitions using boot script

=> mmc partconf 0 1 1 1
=> mmc bootbus 0 2 0 0

3. partition the eMMC using gpt write using boot script

Can you please suggest how do I send some script from Host to u-boot and to run those in u-boot.
 

Hi, thank you for letting know about sending via UART console, but we don't have UART connected in our production environment, so sending commands via UART is not possible for us.

It was meant for development environment.

For production, can you please explain your procedure? why can you not add the env variables to the U-Boot at build time and directly use them, instead modify the variables through bootscript.scr at runtime?

For Production environment as I replied in above use case

to configure the emmc MLC mode to emmc pseudo SLC mode, partition the emmc, we can do at runtime only and to set the boot partitions. 

In production, before sending these MMC commands, how are the U-Boot binaries transferred to the board and booted, using DFU or other method?

Yes, for now, we are sending the U-Boot binaries using USB DFU boot method.

One more use case, I forgot to mention it,

booting the board via USB TFTP Linux load and NFS rootfs mount 

Each use case would require different solution. To avoid confusion, please let's focus on one use case at a time, maybe on production use case first, please explain all the requirements of your production procedure so that we can come out with a solution. I don't believe you will use NFS rootfs mount in production, correct?

Basically U-Boot USB-Ether is not validated/supported in the Processor SDK. We need to find different solution for your usecases, if any.

Maybe I can help to clarify the use cases. I think it makes sense to describe all of them to get an overview why we came to this solution and to see if there would be an alternative.

There are basically three use cases which we need to fulfill with this solution.

1. NFS like boot from Windows (boot without flashing). This is needed for the function test at PCBA level. Here we have access to boot pins and UART console. U-boot shall be flashed to the device and then Linux shall be booted. However, as machine execution time is critical we search for a solution without flashing Linux. So one solution could be to mount it from an NFS to reduce boot time. OTP writer needs to be booted / executed on this station as well.
2. Flashing on the flashing station from Windows. Without access to UART / boot pins (closed device). U-boot is already present in this stage and will normally not be flashed. Linux may or may not be present on those devices before flashing (depending on rework status). We only have access to one GPIO, which we could e.g. use to decide inside U-Boot what exactly to do. In the past we used this to force the loading of boot scripts over TFTP.
3. Flashing from our own Linux SDK. Without access to UART / boot pins. U-boot / Linux may be present or not and need to be flashable in the closed device as described in 2.

Hi Christian,

Appreciate the clarification. It really helps me understand the requirement.

For the U-Boot binaries in all the 3 use cases, do you have to use/flash a single U-Boot build or each case could have a different U-Boot build with different default/hardcoded ENV variables? If you could use different U-Boot binaries for each case, I think you can use DFU in all 3 cases.

I assume you only have USB0 interface (in device mode) on your board, no Ethernet? Not a big issue without an Ethernet port though, it just would be easier for NFS in Linux, but it is doable using usb ethernet gadget in Linux for NFS.

Hi. We actually cannot use different U-boots with hardcoded ENV variables. We e.g. use the ENV to store manufacturing status information (e.g. pass / fail) and serial numbers, etc.

We do not have Ethernet. We used USB RNDIS for this in the past. Basically by using tftp and boot scripts. We intend to use USB0 interface in device mode.

If we have to go with DFU instead of tftp, my major concern is how to switch between DFU and normal (user) boot? Can we do this with the GPIO pin? Can we do something similar like NFS boot via DFU as well?

As described before we have this GPIO which is basically a "FactoryPin" to recognize the device being in manufacturing and not at the user site. U-boot itself shall not be reflashed on the flashing station after the functional test on PCBA level. 

Christian Amann said:

Hi. We actually cannot use different U-boots with hardcoded ENV variables. We e.g. use the ENV to store manufacturing status information (e.g. pass / fail) and serial numbers, etc.

The U-Boot ENV has a variable called DFU_ALT_INFO, which determines how DFU downloads/flashes once U-Boot is running. I meant can you have different DFU_ALT_INFO value in U-Boot build in the 3 use cases?

Christian Amann said:

We do not have Ethernet. We used USB RNDIS for this in the past. Basically by using tftp and boot scripts. We intend to use USB0 interface in device mode.

AM62x ROM doesn't support USB RNDIS boot mode, ROM has to use DFU to download/flash U-Boot, then we can decide how U-Boot to download/boot Linux kernel. Since DFU has to be use at the first place, this is the reason I try to avoid switching to USB RNDIS in U-Boot, not to mention USB RNDIS in U-Boot is not supported in current SDK.

Christian Amann said:

If we have to go with DFU instead of tftp, my major concern is how to switch between DFU and normal (user) boot? Can we do this with the GPIO pin?

I don't have a clear picture of this case yet, haven't thought about it, my first guess would be the same as how you switch between USB RNDIS and normal boot?

Christian Amann said:

Can we do something similar like NFS boot via DFU as well?

Using NFS shouldn't be an issue, NFS only comes to the picture after kernel is booted and when mounting the rootfs, so even if DFU is used in U-Boot, kernel can still have all the relevant USB drivers built in and use g_ether driver for NFS in Linux.

I did some more reading on U-boots DFU documentation and reworked our manufacturing flow in the assumption we will have to use DFU instead of RNDIS. I have one questions left:

We plan to force the device to start in DFU mode when it is on the machine. However on some machines, we will not need DFU. I saw that there is a timeout that can be provided to the DFU command. Can this be somehow used to proceed with normal booting into Linux from eMMC, if no DFU host is responding?

Hi Christian,

Yes, in the BOOTMODE pin setting, you can set DFU as the primary and eMMC as the backup boot mode. The DFU boot timeout is about 66 seconds in both cases that the USB port is connected and not connected to the USB host. I measured it on AM62x SK EVM.

Hi. We have updated our manufacturing flow and did some small checks. At the moment it looks like we can use DFU for all the use cases. We plan to enter the DFU mode via the FactoryPin (BOOTMODE pin in your terms) and exit it via configurable timeout (we want ~10sec). This seems to work. We will next create some proof of concepts for the flashing and NFS booting. If this works properly, we will not need the USB RNDIS support in U-boot.

Thanks for your help!

Hi Christian,

Glad to hear the progress. Thanks for the update.