Bugzilla – Bug 1144161
openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.07.31-Build1.1 not bootable
Last modified: 2019-12-16 11:25:09 UTC
Hello, I am running openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.07.31-Build1.1.raw on BeagleBone Board and see the following: U-Boot SPL 2019.04 (Apr 09 2019 - 12:46:27 +0000) Trying to boot from MMC1 Loading Environment from FAT... Unable to use mmc 0:1... U-Boot 2019.04 (Apr 09 2019 - 12:46:27 +0000) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 0:1... <ethaddr> not set. Validating first E-fuse MAC Net: eth0: ethernet@4a100000 Warning: usb_ether MAC addresses don't match: Address in ROM is de:ad:be:ef:00:01 Address in environment is 6c:ec:eb:8a:a2:46 , eth1: usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... 86206 bytes read in 7 ms (11.7 MiB/s) ** Invalid partition 3 ** ** Unrecognized filesystem type ** switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 8292704 bytes read in 533 ms (14.8 MiB/s) data abort pc : [<9ffb0e68>] lr : [<9ffb0ea5>] reloc pc : [<80849e68>] lr : [<80849ea5>] sp : 9df3b0d8 ip : 00000000 fp : 00000001 r10: 00000002 r9 : 9df46eb8 r8 : 9ffd384c r7 : 9ffd3848 r6 : 00000000 r5 : 9ffd37a8 r4 : 00000000 r3 : 00000010 r2 : 00000010 r1 : 9df3b0e4 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 Code: 7883d114 f0135cd3 d00f0f44 600b2310 (2b307803) Resetting CPU ... resetting ...
openSUSE-Leap-15.1-ARM-JeOS-beaglebone.armv7l-2019.05.17-Build1.14.raw boots ok
Andreas seems to be playing with armv*s. Any ideas?
You are failing with u-boot 2019.04, but what was the version of working u-boot? Could you try with latest Tumbleweed image running u-boot 2019.10, please?
It seems that openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.10.25-Build1.27.raw have broken EFI partition currently. u-boot image overlapped with the partitions for some reason.
Guillaume, could this because if the grub issue we are seeing with armv7?
(In reply to Matwey Kornilov from comment #4) > It seems that > openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.10.25-Build1.27.raw have > broken EFI partition currently. u-boot image overlapped with the partitions > for some reason. So, u-boot image is too big? For Beagleboard xM, I already disabled ubifs to keep the u-boot image small. Maybe we need to do that for beaglebone as well? (In reply to Matthias Brugger from comment #5) > Guillaume, could this because if the grub issue we are seeing with armv7? No, Tumbleweed ARM still uses grub2.02 until kernel 5.4 lands. So, there is no problem with grub in Tumbleweed.
@Matwey, could you try to build a JeOS image with a u-boot built without LTO. Add in spec: %define _lto_cflags %{nil} Not sure if it will be enough or not.
I've tried, but no difference in the loader size. Also I see that LTO affects only HOSTCC (i.e tools): make %{?_smp_mflags} CROSS_COMPILE= HOSTCFLAGS="$RPM_OPT_FLAGS" \
I removed some features to be below the 640K limit to not overwrite the 1st partition (EFI). PR: https://github.com/openSUSE/u-boot/commit/f0deddd8100d62928b9d6a69a89557565314f7bd SR on the way to Factory: https://build.opensuse.org/request/show/754445
Next TW snapshot will be fine.