SK-AM64: Is there some step-by-step procedure available to prepare a boot image to be used on an USB flash drive?

Hello Bin,

thanks a lot! So things seem to be more simple than anticipated. Though it is not working yet and I almost already tried what is written there.

One point I'm missing here:

https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

(in section 3.2.1.3.8) is to build the "Cadence USB3 Dual-Role Controller" into the Kernel. I did this as well now.

However, it still does not want to boot.

The documentation you linked me to says that I have to press any key to stop autoboot. I have no chance to do that.

I also do not see a message like "Hit any key to stop autoboot".

Might it be that this is only working in junction with the AM64-GPEVM? I'm trying with the SK-AM64 here. I have also the AM64-GPEVM,

but to test here I first need this adapter.

Any ideas?

Greetings,

Mario

Hi Mario,

I don't have AM64x SK board, so I only tested it on the GPEVM. But I expect this should work on SK too.

Do you see any message on the SK uart console at all (I want to know if UBoot ever runs from USB thumb drive)?

Hello Bin,

I also think that there should be no difference, since there is the same processor. However, there might be some difference with the USB port and USB 2.0 vs. USB 3.0.

And yes, U-Boot is being definitely booted from the drive. Those are the messages:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

U-Boot SPL 2021.01-g15769936a5 (Jan 17 2022 - 20:40:34 +0000)
EEPROM not available at 80, trying to read at 81
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
SPL initial stack usage: 13392 bytes
Trying to boot from USB
Bus usb@f400000: Register 2000840 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@f400000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
init_env from device 42 not supported!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.01.00.006-dirty
NOTICE:  BL31: Built : 20:34:54, Jan 17 2022

U-Boot SPL 2021.01-g15769936a5 (Jan 17 2022 - 20:39:22 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
Trying to boot from USB
Bus usb@f400000: cdns-usb3-host usb@f400000: set 1 has failed, back to 0
scanning bus usb@f400000 for devices... The request port(0) exceeds maximum port nur
The request port(1) exceeds maximum port number
The request port(0) exceeds maximum port number
The request port(1) exceeds maximum port number
The request port(0) exceeds maximum port number
The request port(1) exceeds maximum port number
The request port(0) exceeds maximum port number
The request port(1) exceeds maximum port number
The request port(0) exceeds maximum port number

1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

These "The request port(0) exceeds maximum port number" messages repeat many times (I snipped this here).

Greetings,

Mario

As an Update: I just did test this with an USB 2.0 drive and the behavior is the same.

Hi Mario,

Mario Trams said:

Bus usb@f400000: cdns-usb3-host usb@f400000: set 1 has failed, back to 0

This message tells the USB controller failed to switch to host mode which causes booting from USB device failed.

I will file a bug report to our dev team to get the issue solved, meanwhile can you please get a USB adapter and use USB boot on the GPEVM?

Hi Bin,

ok, getting the USB adapter will take some time. As a quick-hack I'll try to make one by myself from an microUSB cable and USB-A socket. Is there a realistic/theoretical chance that this issue is not present for the GPEVM?

Hi Mario,

USB host boot feature has been validated on the GPEVM. I have tested it on GPEVM too and created the doc linked in my first post above. So I don't expect it will fail on your GPEVM.

BTY, the dev team has confirmed the function wasn't tested on the AM64x SK EVM.

Ok. There we go....

Guess what: I found such adapter here - by accident.... And, indeed, it is working. Linux is booting now :-)

However, next stop is that it hangs later in the boot process. These are the last messages I get:

[    2.751213] mmc1: Command Queue Engine enabled
[    2.755683] mmc1: new HS400 MMC card at address 0001
[    2.761401] mmcblk1: mmc1:0001 S0J56X 14.8 GiB
[    2.766211] mmcblk1boot0: mmc1:0001 S0J56X partition 1 31.5 MiB
[    2.772353] mmcblk1boot1: mmc1:0001 S0J56X partition 2 31.5 MiB
[    2.778503] mmcblk1rpmb: mmc1:0001 S0J56X partition 3 4.00 MiB, chardev (237:0)
[    4.177861] sdhci-am654 fa00000.mmc: Power on failed
[    4.213546] mmc0: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[    4.221744] Waiting for root device PARTUUID=f95fa140-02...
[   33.867755] vdd_mmc1: disabling
[  160.985767] random: crng init done

Interesting, it failed to mount the rootfs.

During the boot process, did you stop the uboot and run command "run usbboot" at the uboot prompt?

Hi Mario,

Let me test it again and get back to you.

Hi Bin,

I just made some other test. I took an USB flash drive with the default SD image on it. I did boot from the USB flash drive but with the microSD card inserted as well. I did stop the U-Boot and then entered "run usbboot". This did also boot up the system normally - although the kernel did not include the drivers we need for USB.

This makes me believe that U-Boot is actually not booting the right Linux image.

However, just for double-checking this I did delete "Image" from /root/boot of the SD card. This does not change anything when I'm doing the USB boot procedure. On the other hand, I can not boot any more from the SD card, which is as expected. So the "run usbboot" does definitely fetch the Image from the USB flash drive.

So I'm not sure what else can fail here. Applying these changes to the kernel and recompile it is not a big deal, actually, and I don't know what I could have made wrong there. Perhaps there is something else needed. Might it be that when you did test this, you had plugged an microSD card by accident and did not notice that the file system has been silently mounted from the SD card rather than the USB flash drive?

Greetings,

Mario

Hi Mario,

I tested this function some time ago, I remember I didn't create a bootable USB flash drive, rather used the SD card plugged into a USB card reader, with updated kernel Image which has all required USB drivers built in.

I won't have time to test it again today, but I will see if I have time tomorrow or early next week to validate it again on the GPEVM.

Meanwhile can you please attach the entire console boot log here? Maybe I can spot some hint from it.

Hi Bin,

formally it should be the same whether there is used an USB card reader with an USB card or an USB flash drive directly, since both appear as an abstract USB mass storage device on USB. But I'll try as well tu use an USB card reader....

In the mean time, this is the complete console output until the hangup:

U-Boot SPL 2021.01-g15769936a5 (Jan 17 2022 - 20:40:34 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
SPL initial stack usage: 13392 bytes
Trying to boot from USB
Bus usb@f400000: Register 2000840 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@f400000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
init_env from device 42 not supported!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.01.00.006-dirty
NOTICE:  BL31: Built : 20:34:54, Jan 17 2022

U-Boot SPL 2021.01-g15769936a5 (Jan 17 2022 - 20:39:22 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
Trying to boot from USB
Bus usb@f400000: Register 2000840 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@f400000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found


U-Boot 2021.01-g15769936a5 (Jan 17 2022 - 20:39:22 +0000)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev A
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000
Hit any key to stop autoboot:  0
=> run usbboot
starting USB...
Bus usb@f400000: Register 2000840 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@f400000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
19270144 bytes read in 396 ms (46.4 MiB/s)
54542 bytes read in 2 ms (26 MiB/s)
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 000000008ffef000, end 000000008ffff50d ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.10.65-gdcc6bedb2c (oe-user@oe-host) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profi2
[    0.000000] Machine model: Texas Instruments AM642 EVM
[    0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
[    0.000000] printk: bootconsole [ns16550a0] enabled
[    0.000000] efi: UEFI not found.
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a0000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a0100000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a1000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a1100000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a2000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a2100000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a3000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node r5f-dma-memory@a3000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a3100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node r5f-memory@a3100000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a4000000, size 1 MiB
[    0.000000] OF: reserved mem: initialized node m4f-dma-memory@a4000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0x00000000a4100000, size 15 MiB
[    0.000000] OF: reserved mem: initialized node m4f-memory@a4100000, compatible id shared-dma-pool
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x000000009e7fffff]
[    0.000000]   node   0: [mem 0x000000009e800000-0x00000000a57fffff]
[    0.000000]   node   0: [mem 0x00000000a5800000-0x00000000ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000ffffffff]
[    0.000000] cma: Reserved 512 MiB at 0x00000000c0000000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.2
[    0.000000] percpu: Embedded 2 pages/cpu s49880 r8192 d73000 u131072
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] Built 1 zonelists, mobility grouping off.  Total pages: 32736
[    0.000000] Kernel command line: console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 mtdparts=fc40000.spi.0:512k(ost
[    0.000000] Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes, linear)
[    0.000000] Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 1432320K/2097152K available (10880K kernel code, 1346K rwdata, 4288K rodata, 1856K init, 757K bss, 140)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2.
[    0.000000]  Trampoline variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GICv3: 256 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000001840000
[    0.000000] ITS [mem 0x01820000-0x0182ffff]
[    0.000000] GIC: enabling workaround for ITS: Socionext Synquacer pre-ITS
[    0.000000] ITS@0x0000000001820000: allocated 1048576 Devices @a6000000 (flat, esz 8, psz 64K, shr 0)
[    0.000000] ITS: using cache flushing for cmd queue
[    0.000000] GICv3: using LPI property table @0x00000000a58c0000
[    0.000000] GIC: using cache flushing for LPI property table
[    0.000000] GICv3: CPU0: using allocated LPI pending table @0x00000000a58d0000
[    0.000000] random: get_random_bytes called from start_kernel+0x31c/0x4c4 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2e2049d3e8, max_idle_ns: 440795210634 ns
[    0.000005] sched_clock: 56 bits at 200MHz, resolution 5ns, wraps every 4398046511102ns
[    0.008533] Console: colour dummy device 80x25
[    0.013122] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=800000)
[    0.023799] pid_max: default: 32768 minimum: 301
[    0.028604] LSM: Security Framework initializing
[    0.033412] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
[    0.041002] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
[    0.051330] rcu: Hierarchical SRCU implementation.
[    0.056589] Platform MSI: msi-controller@1820000 domain created
[    0.062957] PCI/MSI: /bus@f4000/interrupt-controller@1800000/msi-controller@1820000 domain created
[    0.072242] EFI services will not be available.
[    0.077225] smp: Bringing up secondary CPUs ...
[    0.082934] Detected VIPT I-cache on CPU1
[    0.082970] GICv3: CPU1: found redistributor 1 region 0:0x0000000001860000
[    0.082985] GICv3: CPU1: using allocated LPI pending table @0x00000000a58e0000
[    0.083051] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.083192] smp: Brought up 1 node, 2 CPUs
[    0.112579] SMP: Total of 2 processors activated.
[    0.117392] CPU features: detected: 32-bit EL0 Support
[    0.122666] CPU features: detected: CRC32 instructions
[    0.135967] CPU: All CPU(s) started at EL2
[    0.140172] alternatives: patching kernel code
[    0.145940] devtmpfs: initialized
[    0.157410] KASLR disabled due to lack of seed
[    0.162254] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.172220] futex hash table entries: 512 (order: -1, 32768 bytes, linear)
[    0.181412] pinctrl core: initialized pinctrl subsystem
[    0.187414] DMI not present or invalid.
[    0.192026] NET: Registered protocol family 16
[    0.204408] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
[    0.212073] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.220103] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.228821] thermal_sys: Registered thermal governor 'step_wise'
[    0.228828] thermal_sys: Registered thermal governor 'power_allocator'
[    0.235501] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.249194] ASID allocator initialised with 65536 entries
[    0.284290] HugeTLB registered 16.0 GiB page size, pre-allocated 0 pages
[    0.291169] HugeTLB registered 512 MiB page size, pre-allocated 0 pages
[    0.297928] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.306761] cryptd: max_cpu_qlen set to 1000
[    0.315014] k3-chipinfo 43000014.chipid: Family:AM64X rev:SR1.0 JTAGID[0x0bb3802f] Detected
[    0.324270] vsys_5v0: supplied by evm_12v0
[    0.329155] vsys_3v3: supplied by evm_12v0
[    0.333920] vddb_3v3_display: supplied by vsys_3v3
[    0.340221] iommu: Default domain type: Translated
[    0.345624] SCSI subsystem initialized
[    0.350186] mc: Linux media interface: v0.10
[    0.354589] videodev: Linux video capture interface: v2.00
[    0.360287] pps_core: LinuxPPS API ver. 1 registered
[    0.365360] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.374706] PTP clock support registered
[    0.378747] EDAC MC: Ver: 3.0.0
[    0.382786] omap-mailbox 29020000.mailbox: omap mailbox rev 0x66fc9100
[    0.389700] omap-mailbox 29040000.mailbox: omap mailbox rev 0x66fc9100
[    0.396508] omap-mailbox 29060000.mailbox: omap mailbox rev 0x66fc9100
[    0.404002] FPGA manager framework
[    0.407599] Advanced Linux Sound Architecture Driver Initialized.
[    0.415031] clocksource: Switched to clocksource arch_sys_counter
[    0.421790] VFS: Disk quotas dquot_6.6.0
[    0.425936] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
[    0.439572] NET: Registered protocol family 2
[    0.444296] IP idents hash table entries: 32768 (order: 2, 262144 bytes, linear)
[    0.453337] tcp_listen_portaddr_hash hash table entries: 4096 (order: 0, 65536 bytes, linear)
[    0.462233] TCP established hash table entries: 16384 (order: 1, 131072 bytes, linear)
[    0.470462] TCP bind hash table entries: 16384 (order: 2, 262144 bytes, linear)
[    0.478184] TCP: Hash tables configured (established 16384 bind 16384)
[    0.485086] UDP hash table entries: 2048 (order: 0, 65536 bytes, linear)
[    0.492025] UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes, linear)
[    0.499565] NET: Registered protocol family 1
[    0.504644] RPC: Registered named UNIX socket transport module.
[    0.510735] RPC: Registered udp transport module.
[    0.515575] RPC: Registered tcp transport module.
[    0.520383] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.526977] PCI: CLS 0 bytes, default 64
[    0.531801] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    0.545016] Initialise system trusted keyrings
[    0.549903] workingset: timestamp_bits=46 max_order=15 bucket_order=0
[    0.561519] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.568299] NFS: Registering the id_resolver key type
[    0.573528] Key type id_resolver registered
[    0.577819] Key type id_legacy registered
[    0.581993] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.588841] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.596722] 9p: Installing v9fs 9p2000 file system support
[    0.646987] Key type asymmetric registered
[    0.651193] Asymmetric key parser 'x509' registered
[    0.656231] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    0.663796] io scheduler mq-deadline registered
[    0.668426] io scheduler kyber registered
[    0.675150] pinctrl-single f4000.pinctrl: 180 pins, size 720
[    0.682204] pinctrl-single a40000.timesync-router: 512 pins, size 2048
[    0.698979] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[    0.722813] brd: module loaded
[    0.734047] loop: module loaded
[    0.738124] megasas: 07.714.04.00-rc1
[    0.745160] libphy: Fixed MDIO Bus: probed
[    0.750838] tun: Universal TUN/TAP device driver, 1.6
[    0.756793] igbvf: Intel(R) Gigabit Virtual Function Network Driver
[    0.763211] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    0.769317] sky2: driver version 1.30
[    0.774354] VFIO - User Level meta-driver version: 0.3
[    0.780733] i2c /dev entries driver
[    0.785495] sdhci: Secure Digital Host Controller Interface driver
[    0.791830] sdhci: Copyright(c) Pierre Ossman
[    0.796667] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.803761] ledtrig-cpu: registered to indicate activity on CPUs
[    0.810366] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....
[    0.818366] optee: probing for conduit method.
[    0.822993] optee: revision 3.12 (3d47a131)
[    0.823701] optee: initialized driver
[    0.834397] NET: Registered protocol family 17
[    0.839152] 9pnet: Installing 9P2000 support
[    0.843590] Key type dns_resolver registered
[    0.848204] Loading compiled-in X.509 certificates
[    0.869065] ti-sci 44043000.dmsc: ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
[    0.933741] random: fast init done
[    0.943449] omap-gpmc 3b000000.memory-controller: GPMC revision 6.0
[    0.949909] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    0.958362] omap_i2c 20000000.i2c: bus 0 rev0.12 at 100 kHz
[    0.966169] pca953x 1-0022: supply vcc not found, using dummy regulator
[    0.973120] pca953x 1-0022: using AI
[    1.028539] Console: switching to mono frame buffer device 12x2
[    1.063421] ssd1307fb 1-003c: fb0: Solomon SSD1307 framebuffer device registered, using 192 bytes of video memory
[    1.074129] omap_i2c 20010000.i2c: bus 1 rev0.12 at 400 kHz
[    1.081393] omap_i2c 20020000.i2c: bus 2 rev0.12 at 100 kHz
[    1.088443] omap_i2c 20030000.i2c: bus 3 rev0.12 at 100 kHz
[    1.094720] ti-sci-intr bus@f4000:bus@4000000:interrupt-controller1: Interrupt Router 5 domain created
[    1.104658] ti-sci-intr bus@f4000:interrupt-controller0: Interrupt Router 3 domain created
[    1.113498] ti-sci-inta 48000000.interrupt-controller: Interrupt Aggregator domain 28 created
[    1.134949] j721e-pcie f102000.pcie: host bridge /bus@f4000/pcie@f102000 ranges:
[    1.142630] j721e-pcie f102000.pcie:       IO 0x0068001000..0x0068010fff -> 0x0068001000
[    1.150922] j721e-pcie f102000.pcie:      MEM 0x0068011000..0x006fffffff -> 0x0068011000
[    1.159218] j721e-pcie f102000.pcie:   IB MEM 0x0000000000..0x0fffffffff -> 0x0000000000
[    2.179860] j721e-pcie f102000.pcie: PCI host bridge to bus 0000:00
[    2.186300] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.191914] pci_bus 0000:00: root bus resource [io  0x0000-0xffff] (bus address [0x68001000-0x68010fff])
[    2.201606] pci_bus 0000:00: root bus resource [mem 0x68011000-0x6fffffff]
[    2.208677] pci 0000:00:00.0: [104c:b010] type 01 class 0x060400
[    2.214833] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0xfffffffff 64bit pref]
[    2.222380] pci 0000:00:00.0: supports D1
[    2.226479] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[    2.235062] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    2.237449] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    2.252207] pci 0000:00:00.0: BAR 0: no space for [mem size 0x1000000000 64bit pref]
[    2.260125] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x1000000000 64bit pref]
[    2.268405] pci 0000:00:00.0: PCI bridge to [bus 01]
[    2.274025] pcieport 0000:00:00.0: PME: Signaling with IRQ 44
[    2.280697] ti-bcdma 485c0100.dma-controller: Number of rings: 68
[    2.288447] ti-bcdma 485c0100.dma-controller: Channels: 24 (bchan: 12, tchan: 6, rchan: 6)
[    2.298744] ti-pktdma 485c0000.dma-controller: Number of rings: 288
[    2.313922] ti-pktdma 485c0000.dma-controller: Channels: 44 (tchan: 29, rchan: 15)
[    2.325208] printk: console [ttyS2] disabled
[    2.329678] 2800000.serial: ttyS2 at MMIO 0x2800000 (irq = 16, base_baud = 3000000) is a 8250
[    2.338445] printk: console [ttyS2] enabled
[    2.338445] printk: console [ttyS2] enabled
[    2.346888] printk: bootconsole [ns16550a0] disabled
[    2.346888] printk: bootconsole [ns16550a0] disabled
[    2.362016] spi-nor spi0.0: s28hs512t (65536 Kbytes)
[    2.367080] 7 cmdlinepart partitions found on MTD device fc40000.spi.0
[    2.373602] Creating 7 MTD partitions on "fc40000.spi.0":
[    2.378999] 0x000000000000-0x000000080000 : "ospi.tiboot3"
[    2.385930] 0x000000080000-0x000000280000 : "ospi.tispl"
[    2.392522] 0x000000280000-0x000000680000 : "ospi.u-boot"
[    2.399237] 0x000000680000-0x0000006c0000 : "ospi.env"
[    2.405641] 0x0000006c0000-0x000000700000 : "ospi.env.backup"
[    2.412591] 0x000000800000-0x000003fc0000 : "ospi.rootfs"
[    2.419285] 0x000003fc0000-0x000004000000 : "ospi.phypattern"
[    2.483042] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[    2.490642] libphy: 8000f00.mdio: probed
[    2.496830] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver TI DP83867
[    2.505068] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA00903, cpsw version 0x6BA80903 Ports2
[    2.518463] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 16
[    2.525317] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.4
[    2.532463] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512
[    2.539243] pps pps0: new PPS source ptp0
[    2.543695] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1
[    2.557106] am65-cpts 39000000.cpts: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:0
[    2.568589] mmc1: CQHCI version 5.10
[    2.572667] gpio-mux mux-controller: 2-way mux-controller registered
[    2.587989] vdd_mmc1: supplied by vsys_3v3
[    2.593729] libphy: mdio_mux: probed
[    2.606218] mmc0: CQHCI version 5.10
[    2.606410] debugfs: Directory 'pd:114' with parent 'pm_genpd' already present!
[    2.617233] mmc1: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
[    2.634635] ALSA device list:
[    2.637635]   No soundcards found.
[    2.713171] mmc1: Command Queue Engine enabled
[    2.717646] mmc1: new HS400 MMC card at address 0001
[    2.723392] mmcblk1: mmc1:0001 S0J56X 14.8 GiB
[    2.728149] mmcblk1boot0: mmc1:0001 S0J56X partition 1 31.5 MiB
[    2.734279] mmcblk1boot1: mmc1:0001 S0J56X partition 2 31.5 MiB
[    2.740426] mmcblk1rpmb: mmc1:0001 S0J56X partition 3 4.00 MiB, chardev (237:0)
[    4.127342] sdhci-am654 fa00000.mmc: Power on failed
[    4.162961] mmc0: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[    4.171259] Waiting for root device PARTUUID=f95fa140-02...

Hi Mario,

I didn't mean you to test SD card with card reader. It is basically the same as booting from a thumb drive. I just wanted to say that I booted from a card reader so the SD card slot was empty.

I seems it boots kernel from usb but tries to mount the rootfs from sdcard...

Let me find some time later to test it again on my side.

Hi Mario,

Please try this (with the kernel having all required usb drivers built in):

instead of "run usbboot", please run the this command instead on uboot prompt:

=> env default -f -a; run usbboot

Ok, I see - provided you just had a single microSD card, chances were dim that there was one left in the microSD slot...

The other U-Boot command is not working at all. It gives me:

>>>>>>>>>>>>>>>>>>>>>>>>>>

Hit any key to stop autoboot:  0
=> env default -f -a; run usbboot
## Resetting to default environment
starting USB...
Bus usb@f400000: Register 2000840 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@f400000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
WARNING: Could not determine device tree to use
19270144 bytes read in 396 ms (46.4 MiB/s)
Failed to load '/boot/'
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
=>

<<<<<<<<<<<<<<<<<<<<<<<<<<

I believe there is needed some other driver to be built into the kernel instead as module....

At least the Kernel image I'm using has a different size compared with the original SD image and is also larger. So I'm definitely using some other kernel than the default here.

I also want to remind this page:

https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

especially section 3.2.1.3.8. According to this, there are a few more things to be done in order to prepare the USB flash drive. But I'm not (yet) an expert in these things and for some of them I don't even know how to accomplish them (that was my initial intention for my original posting). So I'm a bit unsure here....

Mario,

Please run this quick test:

=> env default -f -a
=> saveenv

Then power cycle the board and do "run usbboot".

If this doesn't work either, wait for me to test it again.

It's already failing there. I mean the "saveenv". It tells me that it cannot be done because there is no SD card present. So it seems that U-Boot itself is somehow fixed on the SD slot....

Hi Mario,

I just looked into it, it appears the USB drivers are not turning on the USB host controllers to enumerate the USB device. The following board DTS change can solve the issue. I validated it on my GPEVM, it can boot from the sdcard reader all the way to Linux login prompt.

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 0664d2244de8..063f4051fdfa 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -603,7 +603,7 @@
 };

 &usb0 {
-       dr_mode = "otg";
+       dr_mode = "host";
        maximum-speed = "high-speed";
        pinctrl-names = "default";
        pinctrl-0 = <&main_usb0_pins_default>;

Hi Bin,

I tried this, but the behavior is still the same, unfortunately.

But I'm not sure whether I made everything right. Just to list what I did:

1. I put a fresh SD image (tisdk-default-image-am64xx-evm.wic.xz) onto an USB flash drive.

2. In arch/arm64/boot/dts/ti/k3-am642-evm.dts in the kernel source tree I changed "otg" into "host" as indicated in the patch you provided.

3. I did execute "make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dtbs" in the kernel source tree. This did create a new k3-am642-evm.dtb.

4. My changed kernel image from the previos attempts was already there (so far I assume that I did prepare it correctly).

5. From the kernel source tree, I did copy both arch/arm64/boot/Image and arch/arm64/boot/dts/ti/k3-am642-evm.dtb into rootfs/boot of the USB flash drive (hence overwriting the original files).

Then I did try to boot as usual by stopping the normal boot process and then entering "run usbboot".

Anyway, I'm still wondering what are these other changes for that are listed in https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html and how they can be applied. Maybe they are meant for executing them one by one and then writing them back to the storage device with this "saveenv" command. However, actually I would assume that these settings would have to be done in preparation for the whole U-Boot so that there are not needed some changes afterwards (which would be important, when the U-Boot resides in some kind of read-only memory).

It's also strange that this "saveenv" command in U-Boot is always attempting to access the SD card. 

Referring to the original guide I did also try to enter the U-Boot commands after stopping the boot process. I.e. first "usb start", then "setenv mmcroot /dev/sda2 ro", then "run mmcargs". However "run mmcargs" is failing with: Error: "mmcargs" not defined

I will also continue to make more experiments. Perhaps also building the kernel from a fresh SDK installation.

Greetings,

Mario

Hi Bin!

Great! I get a shell now :-)

Though, it's not quite clear for me why. If I understand correctly, with

./ti_config_fragments/defconfig_builder.sh -t ti_sdk_arm64_release
make ti_sdk_arm64_release_defconfig

there has been overwritten my old kernel configuration.

I should have been done "make ti_sdk_arm64_release_defconfig" earlier because I did follow the guideline for building the kernel.

However, what I did not was this 

./ti_config_fragments/defconfig_builder.sh -t ti_sdk_arm64_release
make ti_sdk_arm64_release_defconfig

Instead I made only

make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- tisdk_am64xx-evm_defconfig

as the kernel build guideline said that these other tasks are only for the case when the kernel sources have been downloaded from the GIT repository, which was not the case for me (I'm using the kernel that came with the SDK).

So my guess is that there are some other configuration settings in the standard-configuration that is coming along with the SDK that are causing trouble here.

Anyway, it's very nice that linux is booting from USB now and I can proceed with my actual plans. Would also be nice if that will work on the SK-AM64, perspectively, but the GPEVM is also ok so far.

So thanks a lot for help, Bin!

Hi Mario,

Mario Trams said:

make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- tisdk_am64xx-evm_defconfig

I just tried this method, it works too on my GPEVM.

The options I missed in my test last week was "Cadence USB3 device controller ("CONFIG_USB_CDNS3_GADGET=y") which was hidden in kernel menuconfig when option "USB Gadget Support  --->" set to '[M]' by default. That was why I changed "dr_mode = 'host'" in DTS to overcome it.

At the end please ensure these options are set to 'y' in .config:

    CONFIG_USB=y
    CONFIG_USB_XHCI_HCD=y
    CONFIG_USB_XHCI_PLATFORM=y
    CONFIG_USB_STORAGE=y
    CONFIG_USB_GADGET=y
    CONFIG_USB_CDNS3=y
    CONFIG_USB_CDNS3_GADGET=y
    CONFIG_USB_CDNS3_HOST=y
    CONFIG_USB_CDNS3_TI=y

Regarding the USB boot function on SK-AM64, I have filed a bug report to our dev team, but it is already too late for Processor SDK v8.2 release. Hopefully the issue is fixed in v8.3.

Hi Bin,

I can confirm that I also had not set "CONFIG_USB_CDNS3_GADGET=y" in my last tries. I did change that also by enabling the "USB Gadget Support" for direct kernel integration and then checking the according selection in menuconfig. However, I still need to set "dr_mode = 'host'" in DTS rather than "dr_mode = 'otg'". Not sure what this is, but right now it does not matter for my tasks.....

Something else that seems worth noting: When I boot from the USB flash drive, but I've inserted a microSD card with a valid root filesystem (i.e. a microSD card directly prepared from the standard image), the root filesystem is being mounted from the microSD card and not from the USB flash drive.

And some other ridiculous behavior I did spot: I was not able to boot from the USB flash drive with an inserted microSD card that did just contain some "scrap" (no filesystem or valid paritioning, just random data). In this case even U-Boot did not load properly. But even more ridiculous: When I removed the microSD card, U-Boot still did not want to load any more in multiple subsequent attempts. On top of that, the system did boot again when I just plugged the USB flash drive into the development system (running Ubuntu 18.04LTS), did not change anything but "ejecting" the USB flash drive again and then attached it to the GPEVM again. so it seemed as if the the GPEVM did damage something on the USB flash drive which has been "healed" by inserting the USB flash drive into the Ubuntu machine. Very strange.... I'm afraid that I can't really reproduce this. Just for testing I forced the random data on the microSD card at the beginning to zero and I'm not seeing this effect any more. This behavior is also not affecting my tasks. However, I think that this is a sign that there's probably still something going wrong under some circumstances and it seems worth having a closer look on that.....

As for the SK-AM64 and the delayed SDK fix, that's not an issue for me right now.

Greetings,

Mario

Hi Mario,

How do you conclude the rootfs is from the micro SD card?

I inserted another SD card on my GPEVM, and I believe the rootfs is till from the USB card reader. Please see the boot log below.

[    2.775010] mmc0: CQHCI version 5.10                   
[    2.779474] gpio-mux mux-controller: 2-way mux-controller registered                             
[    2.794725] vdd_mmc1: supplied by vsys_3v3                    
[    2.809112] mmc1: CQHCI version 5.10               
[    2.809346] debugfs: Directory 'pd:114' with parent 'pm_genpd' already present!    
[    2.820063] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
[    2.845320] ALSA device list:                                                          
[    2.848326]   No soundcards found.                                             
[    2.860917] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[    2.869333] Waiting for root device PARTUUID=f95fa140-02...   
[    2.925826] mmc0: Command Queue Engine enabled                                         
[    2.930298] mmc0: new HS400 MMC card at address 0001                
[    2.936030] mmcblk0: mmc0:0001 S0J56X 14.8 GiB     
[    2.940793] mmcblk0boot0: mmc0:0001 S0J56X partition 1 31.5 MiB
[    2.946930] mmcblk0boot1: mmc0:0001 S0J56X partition 2 31.5 MiB
[    2.953072] mmcblk0rpmb: mmc0:0001 S0J56X partition 3 4.00 MiB, chardev (237:0)
[    2.961208] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[    2.969306]  mmcblk0: p1                                      
[    2.978228] mmc1: new SDHC card at address e624              
[    2.983596] mmcblk1: mmc1:e624 SU04G 3.69 GiB                      
[    3.001791]  mmcblk1: p1 p2                               
[    3.116379] usb 1-1: New USB device found, idVendor=8564, idProduct=4000, bcdDevice= 0.3a
[    3.124573] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=5
[    3.131702] usb 1-1: Product: Transcend                       
[    3.135536] usb 1-1: Manufacturer: TS-RDF5         
[    3.139716] usb 1-1: SerialNumber: 000000000037                                                  
[    3.145467] usb-storage 1-1:1.0: USB Mass Storage device detected
[    3.152218] scsi host0: usb-storage 1-1:1.0         
[    4.186876] scsi 0:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS3A PQ: 0 ANSI: 6
[    4.561012] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)               
[    4.569522] sd 0:0:0:0: [sda] Write Protect is off          
[    4.575243] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or
FUA                                                               
[    4.594063]  sda: sda1 sda2                                                                
[    4.600471] sd 0:0:0:0: [sda] Attached SCSI removable disk    
[    4.633097] EXT4-fs (sda2): recovery complete                                                    
[    4.637589] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    4.645313] VFS: Mounted root (ext4 filesystem) on device 8:2.

I also took the SD card from the USB card reader to my PC, and created a dummy file in /home/root/ folder. Then confirmed the dummy file does exist on the EVM once booted from USB, this confirms the rootfs is from USB not the SD card slot.

am64xx-evm login: root
root@am64xx-evm:~# ls
usb-drive
root@am64xx-evm:~#

I'm seeing this with the mount command. It tells me that the rootfs is not mounted from sda but from mmcblk1 while the USB flash drive partitions are mounted under /run/media. I'm also seeing that the content is different (similar to your last test). So if you are not seeing this behavior, there must be some other differences between our setups. Maybe these U-Boot environment variables? I don't know.....

Here is my uboot bootargs:

root@am64xx-evm:~# cat /proc/cmdline
console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 mtdparts=fc40000.spi.0:1m(ospi.tiboot3),2
m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.
phypattern) root=PARTUUID=f95fa140-02 rw rootfstype=ext4 rootwait

Mine are not different, it seems:

root@am64xx-evm:~# cat /proc/cmdline
console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 mtdparts=fc40000.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.phypattern);omap2-nand.0:512k(nand.tiboot3),2m(nand.tispl),4m(nand.u-boot),256k(nand.env),256k(nand.env.backup),-(nand.rootfs) root=PARTUUID=f95fa140-02 rw rootfstype=ext4 rootwait

But I merely meant some stuff that might have been saved with this "saveenv" command in U-Boot.

Btw., I'm seeing multiple references to the OSPI here. I don't know what all this means, but is there some information/setting stored in the OSPI as well? The same actually applies for the NAND flash, which is also being cited there.

These ospi.* and nand.* are passed to kernel to define the partitions of OSPI and NAND.

Hi Bin,

ok, so assuming that no settings are beeing stored in the OSPI and/or NAND Flashes, then this would be not relevant. Are there some other places where settings could be stored? Maybe this U-Boot saveenv?

To cite this again:

https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

There is stated at the end of the USB section the following among others:

setenv args_usb 'setenv bootargs ${bootargs} rootdelay=3 rootfstype=ext4 root=/dev/sda2 rw'

This is to be saved with "saveenv" what is not working for me as it tries to write to the microSD card.  But at least there is specified a dedicated root device (/dev/sda2). So my (uneducated) guess would be that in case this specific root device specification is missing, Linux picks the first it finds reasonable, which is the microSD card in case it is present. However, according to your /proc/cmdline there is no root device specification either in your case.....

Greetings,

Mario

Hi Mario,

Mario Trams said:

https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

I am wondering how you get this URL? It has "am64x/latest" in there, but it actually points to the documentation for Processor SDK v7.2 which is not the latest. My apologies, I didn't catch this in your very first post, I had assumed you used the correct version of the documentation...

When I just checked the AM64x product page on ti.com, all the documentation URLs have 'AM64X/08_01_00_39' which points to the latest documentation.

https://www.ti.com/tool/PROCESSOR-SDK-AM64X

Anyway, the documentation you pointed to (for v7.2) is not applicable for AM64x in terms of USB host boot mode, which wasn't supported in SDK v7.2 yet.

Please use one of the following documentation for USB host boot mode for AM64x.

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_01_00_39/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

https://dev.ti.com/tirex/explore/node?a=7qm9DIS__8.1.0.0%20v1&node=AA4FLMdfwF7aK5Frgfq-sA__7qm9DIS__8.1.0.0%20v1

Note the later document is missing the information of CONFIG_USB_CDNS3_GADGET as we discovered recently. It will be corrected in the next documentation update.

Now back to your question about U-Boot ENV, the U-Boot binary has built in the env for USB host boot, running 'run usbboot' will set the proper env for it. It actually doesn't use 'root=/dev/sda2', rather set the boot device to USB then read the UUID of the USB device second partition.  You can capture all the U-Boot ENV settings by U-Boot command 'print', then exam it. (I know it is not easy to follow though...)

I am not an U-Boot expert, but by default U-Boot saveenv command saves the ENV to the SD card. (So if the SD card slot is empty, saveenv command would fail.) To change the saveenv target, U-Boot has to be modified and re-compiled.

So if the SD card has saved ENV which modifies the default ENV, it is possible that it would affect USB boot mode, if any relevant ENV has been modified. To correct this, you can either use a different SD card which you know you didn't run 'saveenv' to it, or run the following U-Boot command to reset the saved ENV to default:

env default -f -a
saveenv

Hi Bin,

urg.... I see the point. I'm also sorry that I did not recognize that I did base my work on an outdated documentation. I did also spot this "latest" in the URL and did assume it's the latest. But I did not care about the SDK version number shown top/left. So this is explaining a few things... I think I came across Google onto that page. Not sure whether I'm kind of blind and just did not spot this, but on the primary SDK website (https://www.ti.com/tool/PROCESSOR-SDK-AM64X) I did not find a link to the documentation.

As for the rest: So it really seems that actually there would have to be build a new U-Boot in order to do things correctly, while the U-Boot built for the SD card is working to some extend (and to some extend sufficiently). Though, it does not explain why in your case root is mounted from the USB in case a microSD card with a valid image is present, and in my case it mounts from the microSD card. But I think we should leave it to that. Actually I just wanted to mention this by means of providing some observation that might be used for optimization. I myself am happy with the situation as it is. I just needed a free microSD slot in order to do some analysis there, and I can achieve that now.

Greetings,

Mario

Hi Mario,

The UBoot prebuilt in the SDK is meant for evaluating on the EVM from SD card boot. Any other use cases might require modifying and recompiling UBoot, for example changing the target of saved env.

It is indeed interesting why the rootfs is mounted from the SD card in your setup when boot from USB.

Anyway, glad to see you can move forward now. Let us know whenever you need support from TI.