RPI2 boot hangs with red light on
Mark Millard
markmi at dsl-only.net
Wed Jan 3 00:17:30 UTC 2018
[My example here is for a non-debug kernel based
on -r327485 --and also based on modern ports
materials. The material is for reference only.
I do not know what is happening in your context.]
On 2018-Jan-2, at 2:27 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> An RPI2 with sources at 327493
> and kernel at 322520 makes and installs world and kernel, but
> boot fails with the red LED stuck on. Starting with the reboot
> command, the console reports
>
> login: Jan 2 14:16:39 www shutdown: reboot by bob:
> Stopping cron.
> Waiting for PIDS: 624.
> Stopping sshd.
> Waiting for PIDS: 614.
> Stopping devd.
> Waiting for PIDS: 341.
> Writing entropy file:.
> Writing early boot entropy file:.
> .
> Terminated
> Jan 2 14:16:50 www syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop... done
>
> Syncing disks, vnodes remaining... 3 Waiting (max 60 seconds) for system process `syncer' to stop... 4 3 2 1 0 0 1 0 0 done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
> All buffers synced.
> lock order reversal:
> 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271
> 2nd 0xc4828274 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2764
> stack backtrace:
> lock order reversal:
> 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271
> 2nd 0xc4365814 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1410
> stack backtrace:
> Uptime: 14h18m53s
> Rebooting...
> c�
>
> U-Boot 2015.04 (Jun 26 2017 - 22:31:06)
This is older than is in ports these days
[U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)].
> DRAM: 944 MiB
> WARNING: Caches not enabled
> RPI 2 Model B
> MMC: bcm2835_sdhci: 0
> reading uboot.env
>
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
>
> In: serial
> Out: lcd
> Err: lcd
> Net: Net Initialization Skipped
> No ethernet found.
> Hit any key to stop autoboot: 0
> Booting from: mmc 0 ubldr
> reading ubldr
> 293073 bytes read in 235 ms (1.2 MiB/s)
> ## Starting application at 0x02000098 ...
> Consoles: U-Boot console
> Compatible U-Boot API signature found @0x3ab4b4c8
>
> FreeBSD/armv6 U-Boot loader, Revision 1.2
> (Mon Jun 26 22:46:48 UTC 2017 root at releng3.nyi.freebsd.org)
[Note that armv6 above.]
What I get based on modern material is
(and use of ubldr.bin instead of ubldr):
Found FreeBSD U-Boot Loader (bin)
reading ubldr.bin
231872 bytes read in 32 ms (6.9 MiB/s)
## Starting application at 0x01000000 ...
Consoles: U-Boot console
Compatible U-Boot API signature found @0x3af5d988
FreeBSD/armv7 U-Boot loader, Revision 1.2
I do not know if mixing older armv6 materials
and newer armv7 materials has any problems. My
context is all armv7 (cortex-a7 targeted).
> DRAM: 944MB
> Number of U-Boot devices: 1
> U-Boot env: loaderdev='mmc 0'
> Found U-Boot device: disk
> Checking unit=0 slice=<auto> partition=<auto>... good.
> Booting from disk0s2a:
> /boot/kernel/kernel data=0x69ab94+0x1d946c syms=[0x4+0x72bd0+0x4+0xa6299]
>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> Using DTB provided by U-Boot at address 0x100.
Using modern materials indicated:
/boot/dtb/bcm2836-rpi-2-b.dtb size=0x346b
Loaded DTB from file 'bcm2836-rpi-2-b.dtb'.
> Kernel entry at 0x2200100...
> Kernel args: (null)
And I see on what I use:
Kernel entry at 0x1200100...
Kernel args: (null)
I do not know if the vintage of
materials has such a "Kernel entry"
difference expected or not.
After that I get:
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT r327485M arm
FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1)
. . .
> At this point the only recourse seems to be cycling power.
>
>
> It was necessary to comment out the crossbuild tests in
> /usr/src/makefile.inc1 thus
I have had no such issue with my amd64 -> cortex-a7
cross builds for armv7. (Or for cortex-a53 for
aarch64 as the target, or for powerpc64 or for
powerpc.)
I've not done self-hosted for the rpi2 in a long
time. (I'm looking into other issues at this
point and, so, will not start such a build at
this time.)
> #.if make(buildworld)
> #BUILD_ARCH!= uname -p
> #.if ${MACHINE_ARCH} != ${BUILD_ARCH}
> #.error To cross-build, set TARGET_ARCH.
> #.endif
> #.endif
>
> to avoid stopping on the demand to set TARGET_ARCH error.
> In the past this practice caused no problems, but its necessity
> is puzzling.
>
> /etc/make.conf contains
> NO_CLEAN=yes
I do not explicitly control NO_CLEAN.
(Why here and in src.conf ?)
> KERNCONF=RPI2
I use a file that includes GENERIC.
As far as I know at this point RPI2 is
no longer maintained.
(Why here and in src.conf ?)
> TARGET=arm
> TARGET_ARCH=armv7
> DESTDIR=/
For self hosted to the root file system
I do not explicitly list/control DESTDIR.
(Why here and in src.conf ?)
> #FORCE_PKG_REGISTER=yes
> DISABLE_VULNERABILITIES=yes
> MAKE_JOBS_UNSAFE=yes
>
> /etc/src.conf contains
> NO_CLEAN=yes
I do not explicitly control NO_CLEAN.
> KERNCONF=RPI2
I use a file that includes GENERIC.
As far as I know at this point RPI2 is
no longer maintained.
(I normally disable various debugging
modes that GENERIC lists.)
> TARGET=arm
> TARGET_ARCH=armv7
> DESTDIR=/
For self hosted to the root file system
I do not explicitly list/control DESTDIR.
> Thanks for reading, and any guidance!
I boot with kernel, dtb file that the kernel
uses, etc. being from a USB SSD stick on a
powered hub. (u-boot uses a dtb file from a
different place.)
The text sequence for booting starts with. . .
U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)
DRAM: 948 MiB
RPI 2 Model B (0xa21041)
MMC: sdhci at 7e300000: 0
reading uboot.env
** Unable to read "uboot.env" from mmc0:1 **
Using default environment
In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
USB0: Core Release: 2.80a
scanning bus 0 for devices... 5 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found FreeBSD U-Boot Loader (bin)
reading ubldr.bin
231872 bytes read in 32 ms (6.9 MiB/s)
## Starting application at 0x01000000 ...
Consoles: U-Boot console
Compatible U-Boot API signature found @0x3af5d988
FreeBSD/armv7 U-Boot loader, Revision 1.2
DRAM: 948MB
Number of U-Boot devices: 2
U-Boot env: loaderdev not set, will probe all devices.
Found U-Boot device: disk
Probing all disk devices...
Checking unit=0 slice=<auto> partition=<auto>... good.
Booting from disk0p1:
/boot/kernel/kernel data=0x83a6dc+0x181924 syms=[0x4+0x93900+0x4+0xd68cc]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
/boot/dtb/bcm2836-rpi-2-b.dtb size=0x346b
Loaded DTB from file 'bcm2836-rpi-2-b.dtb'.
Kernel entry at 0x1200100...
Kernel args: (null)
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT r327485M arm
FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1)
. . .
Note: The last time that I tried self hosted on
an armv7 I used (not tailored to your intent,
just for reference):
# more /root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host
TO_TYPE=armv7
#
KERNCONF=GENERIC-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
#
#CPUTYPE=soft
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
#
# Linking lldb fails for armv7
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
WITHOUT_LIBSOFT=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
# Use of the .clang 's here avoids
# interfering with other C<?>FLAGS
# usage, such as ?= usage.
CFLAGS.clang+= -mcpu=cortex-a7
CXXFLAGS.clang+= -mcpu=cortex-a7
CPPFLAGS.clang+= -mcpu=cortex-a7
(Direct use of -mcpu is not recommended
but I happen to do so.)
# more /root/src.configs/make.conf
CFLAGS.gcc+= -v
(Yep: essentially empty unless
experimenting with gcc. Also ports
use a separate /etc/make.conf . I
do not use /etc/src.conf . See below.)
# more ~/sys_build_scripts.armv7-host/make_rpi2_nodebug_clang_bootstrap-armv7-host.sh
kldload -n filemon && \
script ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-armv7-host-$(date +%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host" \
WITH_META_MODE=yes \
MAKEOBJDIRPREFIX="/usr/obj/rpi2_clang/arm.armv7" \
make $*
So my builds point to specific src.conf and make.conf files
that are not in the default places. I normally use META_MODE.
(Implicit NO_CLEAN involvement.)
The modern ports involved are:
sysutils/rpi-firmware
sysutils/u-boot-rpi2
ubldr.bin for the fat file system is copied
from the built /boot/ubldr.bin that is tied
to the world build.
rpi2.dtb for the fat file is from the kernel
build's /boot/dtb/ .
A way to see what comes from where and what
goes to the fat file system is to look
in the likes of:
# more /usr/src/release/arm/RPI2.conf
#!/bin/sh
#
# $FreeBSD: head/release/arm/RPI2.conf 325950 2017-11-17 17:36:45Z gjb $
#
EMBEDDED_TARGET_ARCH="armv7"
EMBEDDED_TARGET="arm"
EMBEDDEDBUILD=1
EMBEDDEDPORTS="sysutils/u-boot-rpi2 sysutils/rpi-firmware"
FAT_SIZE="50m"
FAT_TYPE="16"
IMAGE_SIZE="3072M"
KERNEL="GENERIC"
MD_ARGS="-x 63 -y 255"
NODOC=1
PART_SCHEME="MBR"
export BOARDNAME="RPI2"
arm_install_uboot() {
UBOOT_DIR="/usr/local/share/u-boot/u-boot-rpi2"
RPI_FIRMWARE_DIR="/usr/local/share/rpi-firmware"
UBOOT_FILES="u-boot.bin"
RPI_FIRMWARE_FILES="bootcode.bin config.txt \
fixup.dat fixup_cd.dat fixup_db.dat fixup_x.dat \
start.elf start_cd.elf start_db.elf start_x.elf"
FATMOUNT="${DESTDIR%${KERNEL}}/fat"
UFSMOUNT="${DESTDIR%${KERNEL}}/ufs"
chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}"
chroot ${CHROOTDIR} mount_msdosfs /dev/${mddev}s1 ${FATMOUNT}
chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT}
for _UF in ${UBOOT_FILES}; do
chroot ${CHROOTDIR} cp -p ${UBOOT_DIR}/${_UF} \
${FATMOUNT}/${_UF}
done
for _UF in ${RPI_FIRMWARE_FILES}; do
chroot ${CHROOTDIR} cp -p ${RPI_FIRMWARE_DIR}/${_UF} \
${FATMOUNT}/${_UF}
done
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
${FATMOUNT}/ubldr.bin
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/dtb/rpi2.dtb \
${FATMOUNT}/rpi2.dtb
chroot ${CHROOTDIR} touch ${UFSMOUNT}/firstboot
sync
umount_loop ${CHROOTDIR}/${FATMOUNT}
umount_loop ${CHROOTDIR}/${UFSMOUNT}
chroot ${CHROOTDIR} rmdir ${FATMOUNT}
chroot ${CHROOTDIR} rmdir ${UFSMOUNT}
return 0
}
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-arm
mailing list