Bug 241388 - The snapshot images of CURRENT for RPi-B do not boot till login-prompt any more
Summary: The snapshot images of CURRENT for RPi-B do not boot till login-prompt any more
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Some People
Assignee: freebsd-arm (Nobody)
Keywords: regression
Depends on:
Reported: 2019-10-21 07:52 UTC by iz-rpi03
Modified: 2019-10-29 13:33 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description iz-rpi03 2019-10-21 07:52:55 UTC
Due to an unfortunate update of an RPi-B (processes are terminated with
signal 4 during boot) I noticed, that the newer images provided at
shows the same problem.

The last image which is booting fine is
Booting the newer images looks always like this:

uhub1: 3 ports with 2 removable, self powered
Growing root partition to fill device
pid 37 (awk), jid 0, uid 0: exited on signal 4
Illegal instruction
pid 40 (awk), jid 0, uid 0: exited on signal 4
Illegal instruction
Don't know how to grow root filesystem type: 
ugen0.3: <vendor 0x0424 product 0xec00> at usbus0
smsc0 on uhub1
smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
smsc0: chip 0xec00, rev. 0002
miibus0: <MII bus> on smsc0
smscphy0: <SMC LAN8700 10/100 interface> PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> on smsc0
ue0: xxxxxxx
pid 46 (logger), jid 0, uid 0: exited on signal 4
Illegal instruction
/etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating
a new one
pid 47 (sleep), jid 0, uid 0: exited on signal 4
Illegal instruction
Setting hostuuid: a-b-c-d.
Setting hostid: 0xabcd.
No suitable dump device was found.
ugen0.4: <Fujitsu Fujitsu Keyboard> at usbus0
ukbd0 on uhub1
ukbd0: <Fujitsu Fujitsu Keyboard, class 0/0, rev 1.10/1.09, addr 4> on usbus0
kbd1 at ukbd0
Starting file system checks:
/dev/ufs/roopid 68 (fsck_ufs), jid 0, uid 0: exited on signal 4
fsck: /dev/ufs/rootfs: Illegal instruction
Unknown error 1; help!

With a disabled fsck in /etc/fstab, my unfortunate update shows a login-prompt.
But a successful login is not possible due to signal 4.

Comment 1 Emmanuel Vadot freebsd_committer 2019-10-22 12:53:38 UTC
We've been discussing this on irc, here's what we've found :

This seems to be a regression from the LLVM9 import.
Some of the generated code use the d17 VFP register which doesn't exists for vfpv2.
Some patch in LLVM might fix this : https://reviews.llvm.org/D67375
Setting -mfpu=vfp2d16sp to cpuflags might also fix this
diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk
index 8a72368babb..25b2a2ae5f5 100644
--- a/share/mk/bsd.cpu.mk
+++ b/share/mk/bsd.cpu.mk
@@ -128,7 +128,7 @@ _CPUCFLAGS = -march=${CPUTYPE}
 #      arm1176jzf-s, generic-armv7-a, cortex-a5, cortex-a7, cortex-a8,
 #      cortex-a9, cortex-a12, cortex-a15, cortex-a17, cortex-a53, cortex-a57,
 #      cortex-a72, exynos-m1
+_CPUCFLAGS = -mcpu=${CPUTYPE} -mfpu=vfp2d16sp
 . endif
 . elif ${MACHINE_ARCH} == "powerpc"
 .  if ${CPUTYPE} == "e500"

mmel@ and I thinks that we should backport the LLVM commit into the tree and test what is the default vfp usage when we do not use -mfpu.
Comment 2 iz-rpi03 2019-10-24 13:45:53 UTC
(In reply to Emmanuel Vadot from comment #1)
> Setting -mfpu=vfp2d16sp to cpuflags might also fix this

Unfortunately no, it does not fix it for me.

Made buildworld and buildkernel from base r353962.
Build started with empty object path/directory.
The resulting system shows the same symptoms.
Comment 3 Glen Barber freebsd_committer 2019-10-25 15:36:45 UTC
Confirmed that this is still an issue with this week's snapshots of 13.0-CURRENT.  I had presumed the problem to be the builder needed to be updated (i.e., new system call added or some such thing), but I see the same boot-time failure as is in this report.
Comment 4 iz-rpi03 2019-10-29 13:33:29 UTC
After updating cross-compilation system and the RPi-B to base r354130 (a little
bit newer than base r354097, which contains the related llvm/clang fixes),
I can announce that the issue is gone.

Thank you.