Bug 1144161 - openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.07.31-Build1.1 not bootable
openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-2019.07.31-Build1.1 not bootable
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
armv7 Other
: P5 - None : Normal (vote)
: ---
Assigned To: Guillaume GARDET
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-03 18:45 UTC by Matwey Kornilov
Modified: 2019-12-16 11:25 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jslaby: needinfo? (afaerber)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matwey Kornilov 2019-08-03 18:45:01 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 ...
Comment 1 Matwey Kornilov 2019-08-03 18:54:38 UTC
openSUSE-Leap-15.1-ARM-JeOS-beaglebone.armv7l-2019.05.17-Build1.14.raw boots ok
Comment 2 Jiri Slaby 2019-11-04 12:35:02 UTC
Andreas seems to be playing with armv*s. Any ideas?
Comment 3 Guillaume GARDET 2019-11-18 07:41:55 UTC
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?
Comment 4 Matwey Kornilov 2019-11-20 18:00:46 UTC
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.
Comment 5 Matthias Brugger 2019-11-21 11:39:58 UTC
Guillaume, could this because if the grub issue we are seeing with armv7?
Comment 6 Guillaume GARDET 2019-11-21 12:20:40 UTC
(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.
Comment 7 Guillaume GARDET 2019-11-21 14:52:36 UTC
@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.
Comment 8 Matwey Kornilov 2019-11-21 18:00:17 UTC
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" \
Comment 9 Guillaume GARDET 2019-12-05 14:53:26 UTC
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
Comment 10 Guillaume GARDET 2019-12-10 13:40:45 UTC
Next TW snapshot will be fine.