On 17.02.24 12:36, Alexander Sverdlin wrote: > Hi Jan! > > On Sat, 2024-02-17 at 09:42 +0100, Jan Kiszka wrote: >>> U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) >>> >>> SoC: AM62X SR1.0 HS-FS >>> Model: Texas Instruments AM625 SK >>> DRAM: 2 GiB >>> Core: 56 devices, 23 uclasses, devicetree: separate >>> MMC: mmc@fa10000: 0, mmc@fa00000: 1 >>> Loading Environment from nowhere... OK >>> In: serial@2800000 >>> Out: serial@2800000 >>> Err: serial@2800000 >>> Net: eth0: ethernet@8000000port@1 >>> Hit any key to stop autoboot: 0 >>> switch to partitions #0, OK >>> mmc1 is current device >>> SD/MMC found on device 1 >>> Failed to load 'uEnv.txt' >>> Scanning for bootflows in all bootdevs >>> Seq Method State Uclass Part Name Filename >>> --- ----------- ------ -------- ---- ------------------------ >>> ---------------- >>> Scanning global bootmeth 'efi_mgr': >>> No EFI system partition >>> No EFI system partition >>> Failed to persist EFI variables >>> Scanning bootdev 'mmc@fa00000.bootdev': >>> Scanning bootdev 'mmc@fa10000.bootdev': >>> Unknown uclass 'usb' in label >>> link up on port 1, speed 100, full duplex >>> BOOTP broadcast 1 >>> BOOTP broadcast 2 >>> BOOTP broadcast 3 >>> ... >>> --- >>> >>> I suppose TI's BSP has older U-Boot... So it's not providing necessary >>> script for BOOTSTD, I suppose? >>> >> >> You can make the BeagleBone boot via EFI, but it requires a hybrid >> partition table (ROM loader want DOS, EFI needs GPT). A Debian >> integration with this can be found for Isar [1] in this series [2]. It's >> only using upstream sources (plus still one u-boot patch to get wifi >> working). >> >> If you want legacy script booting, I suspect you need to flip some extra >> switches explicitly by now. > > Thanks for the hints! > I'm wondering, if this was a deliberate "let's stop booting all the > pre-existing embedded distros" decision? (buildroot, yocto/meta-ti...) >
FWIW, I'm not seeing other boot methods being specifically disabled in beagleplay in 2024.01 or even newer. I didn't try the result, but this may actually be some other issue and real bug, nothing obviously intended. My personal observation is that continuous integration testings with all-upstream components is not really a common thing. I saw that with multiple active SoCs from various vendors. Jan -- Siemens AG, Technology Linux Expert Center
