head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both
Mark Millard
marklmi at yahoo.com
Sat Feb 1 19:02:18 UTC 2020
On 2020-Feb-1, at 07:38, Klaus Küchemann <maciphone2 at googlemail.com> wrote:
>
>> Am 01.02.2020 um 12:58 schrieb Mark Millard via freebsd-arm <freebsd-arm at freebsd.org>:
>>
>> I had a working head -r356426 based microSD card that booted
>> both the Rock64 and the RPi4.
>>
>>
> that’s interesting ….
> Which u-boot version?
I described the original sequence that made the originally
-r356426 based Rock64 microSD card also bootable on the
RPi4 in:
https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021117.html
No changes to sysutils/rpi-firmware or sysutils/u-boot-rpi4
or to the copies of the materials on the msdosfs partition
after that.
As for the sysutils/rpi-firware and the sysutils/u-boot-rpi4
versions that I used:
# pkg info rpi-firmware
rpi-firmware-1.20190925.g20200109
Name : rpi-firmware
Version : 1.20190925.g20200109
Installed on : Thu Jan 30 01:35:01 2020 PST
Origin : sysutils/rpi-firmware
Architecture : FreeBSD:13:amd64
Prefix : /usr/local
Categories : sysutils
Licenses : BROADCOM
Maintainer : uboot at FreeBSD.org
WWW : https://github.com/raspberrypi/firmware
Comment : Firmware for RaspberryPi Single Board Computer
Annotations :
FreeBSD_version: 1300075
repo_type : binary
repository : custom
Flat size : 41.9MiB
Description :
Firmware files for RaspberryPi Single Board Computer
. . .
# pkg info u-boot-rpi4
u-boot-rpi4-2019.10
Name : u-boot-rpi4
Version : 2019.10
Installed on : Mon Dec 2 22:22:30 2019 PST
Origin : sysutils/u-boot-rpi4
Architecture : FreeBSD:13:*
Prefix : /usr/local
Categories : sysutils
Licenses : GPLv2
Maintainer : uboot at FreeBSD.org
WWW : UNKNOWN
Comment : Cross-build das u-boot for model rpi4
Annotations :
repo_type : binary
repository : custom
Flat size : 454KiB
Description :
U-Boot loader and related files for the RPi4
. . .
The only thing changed was FreeBSD being updated
to head -r357356 from -r356426 .
> Or did you pick up a standard- image and if so which one?
I buildworld buildkernel and installkernel installworld
and such myself. Likewise, I did the partitioning, the
file system initialization, and glabel labeling myself.
But that was earlier than this update.
> Did you make changes to uSD, if so which?
Relative to the previously working context,
I just installed head -r357356 (kernel and world),
using mergemaster in the process. (It was not
done on the RPi4.)
> Which kernel did you boot from (e.g. GENERIC) ?
My kernel config file in use is:
# more /usr/src/sys/arm64/conf/GENERIC-NODBG
#
# GENERIC -- Custom configuration for the arm64/aarch64
#
include "GENERIC"
ident GENERIC-NODBG
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
options ALT_BREAK_TO_DEBUGGER
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
#options KDB_TRACE # Print a stack trace for a panic
options DDB # Enable the kernel debugger
# Extra stuff:
#options VERBOSE_SYSINIT # Enable verbose sysinit messages
#options BOOTVERBOSE=1
#options BOOTHOWTO=RB_VERBOSE
#options KTR
#options KTR_MASK=KTR_TRAP
##options KTR_CPUMASK=0xF
#options KTR_VERBOSE
# Disable any extra checking for. . .
nooptions DEADLKRES # Enable the deadlock resolver
nooptions INVARIANTS # Enable calls of extra sanity checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect deadlocks and cycles
nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
nooptions DIAGNOSTIC
nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
nooptions BUF_TRACKING
nooptions FULL_BUF_TRACKING
> The cam/mmc-issue is known on the RPI4,
I'm unclear on what the above is trying to tell
me. Any messages produced both by -r356426 and
-r357356 are not likely to be relevant and I
showed that the mmc1 message was in both the
-r356426 and the -r357356 based contexts. So I
doubt that the mmc1 message indicates a
contribution to the distinct behaviors.
> which kernel did you boot from (e.g. GENERIC) ?
This question was repeated twice. Answered earlier.
>> Release APs...Trying to mount root from ufs:/dev/label/RPi4root [rw,noatime]...
>> APs not started
>> CPU 0: ARM Cortex-A72 r0p3 affinity: 0
>> . . .
>>
>
> If you reach the mountroot-console could you please try:
> ufs:/dev/ufs/rootfs
The system hangs, no way to do anything analogous,
nor does it prompt for such.
"APs not started" is a problem not tied to the
"mount root": it happens in parallel.
I do not have any ufs file systems labeled with
"rootfs". It would be /dev/ufs/RPi4rootfs in my
case.
But I also have a glabel label assigned so there is
/dev/label/RPi4root for the partition that has the
ufs file system as well. When the card was at
-r357426 that worked fine in the RPi4 and its still
works fine with the microSD card put in the Rock64.
For reference (done on the Rock64):
# gpart show -p
=> 63 249737153 mmcsd0 MBR (119G)
63 32705 - free - (16M)
32768 102312 mmcsd0s1 fat32lba [active] (50M)
135080 28760 - free - (14M)
163840 241172480 mmcsd0s2 freebsd (115G)
241336320 8400896 - free - (4.0G)
=> 0 241172480 mmcsd0s2 BSD (115G)
0 230686720 mmcsd0s2a freebsd-ufs (110G)
230686720 7340032 mmcsd0s2b freebsd-swap (3.5G)
238026752 2097152 mmcsd0s2d freebsd-swap (1.0G)
240123904 1048576 - free - (512M)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list