Date: Tue, 2 Jan 2018 15:50:40 -0800 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPI2 boot hangs with red light on Message-ID: <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> In-Reply-To: <20180102222730.GB10596@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
>=20
> login: Jan 2 14:16:39 www shutdown: reboot by bob:=20
> 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
>=20
> 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=EF=BF=BD
>=20
> 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
>=20
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
>=20
> In: serial
> Out: lcd
> Err: lcd
> Net: Net Initialization Skipped
> No ethernet found.
> Hit any key to stop autoboot: 0=20
> 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 =20
> Compatible U-Boot API signature found @0x3ab4b4c8
>=20
> FreeBSD/armv6 U-Boot loader, Revision 1.2
> (Mon Jun 26 22:46:48 UTC 2017 root@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 =20
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=3D'mmc 0'
> Found U-Boot device: disk
> Checking unit=3D0 slice=3D<auto> partition=3D<auto>... good.
> Booting from disk0s2a:
> /boot/kernel/kernel data=3D0x69ab94+0x1d946c =
syms=3D[0x4+0x72bd0+0x4+0xa6299]
>=20
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]... =20
> Using DTB provided by U-Boot at address 0x100.
Using modern materials indicated:
/boot/dtb/bcm2836-rpi-2-b.dtb size=3D0x346b
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.
>=20
>=20
> 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!=3D uname -p
> #.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH}
> #.error To cross-build, set TARGET_ARCH.
> #.endif
> #.endif
>=20
> to avoid stopping on the demand to set TARGET_ARCH error.=20
> In the past this practice caused no problems, but its necessity=20
> is puzzling.=20
>=20
> /etc/make.conf contains
> NO_CLEAN=3Dyes
I do not explicitly control NO_CLEAN.
(Why here and in src.conf ?)
> KERNCONF=3DRPI2
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=3Darm
> TARGET_ARCH=3Darmv7
> DESTDIR=3D/
For self hosted to the root file system
I do not explicitly list/control DESTDIR.
(Why here and in src.conf ?)
> #FORCE_PKG_REGISTER=3Dyes
> DISABLE_VULNERABILITIES=3Dyes
> MAKE_JOBS_UNSAFE=3Dyes
>=20
> /etc/src.conf contains
> NO_CLEAN=3Dyes
I do not explicitly control NO_CLEAN.
> KERNCONF=3DRPI2
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=3Darm
> TARGET_ARCH=3Darmv7
> DESTDIR=3D/
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@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=20
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 =20
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=3D0 slice=3D<auto> partition=3D<auto>... good.
Booting from disk0p1:
/boot/kernel/kernel data=3D0x83a6dc+0x181924 =
syms=3D[0x4+0x93900+0x4+0xd68cc]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]... =20
/boot/dtb/bcm2836-rpi-2-b.dtb size=3D0x346b
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=3Darmv7
#
KERNCONF=3DGENERIC-NODBG
TARGET=3Darm
.if ${.MAKE.LEVEL} =3D=3D 0
TARGET_ARCH=3D${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=3D
WITH_SYSTEM_COMPILER=3D
#
#CPUTYPE=3Dsoft
WITH_LIBCPLUSPLUS=3D
WITH_BINUTILS_BOOTSTRAP=3D
WITH_ELFTOOLCHAIN_BOOTSTRAP=3D
#WITHOUT_CLANG_BOOTSTRAP=3D
WITH_CLANG=3D
WITH_CLANG_IS_CC=3D
WITH_CLANG_FULL=3D
WITH_CLANG_EXTRAS=3D
WITH_LLD=3D
#
# Linking lldb fails for armv7
WITHOUT_LLDB=3D
#
WITH_BOOT=3D
WITHOUT_LIB32=3D
WITHOUT_LIBSOFT=3D
#
WITHOUT_GCC_BOOTSTRAP=3D
WITHOUT_GCC=3D
WITHOUT_GCC_IS_CC=3D
WITHOUT_GNUCXX=3D
#
NO_WERROR=3D
#WERROR=3D
MALLOC_PRODUCTION=3D
#
WITH_REPRODUCIBLE_BUILD=3D
WITH_DEBUG_FILES=3D
#
# Use of the .clang 's here avoids
# interfering with other C<?>FLAGS
# usage, such as ?=3D usage.
CFLAGS.clang+=3D -mcpu=3Dcortex-a7
CXXFLAGS.clang+=3D -mcpu=3Dcortex-a7
CPPFLAGS.clang+=3D -mcpu=3Dcortex-a7
(Direct use of -mcpu is not recommended
but I happen to do so.)
# more /root/src.configs/make.conf
CFLAGS.gcc+=3D -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-hos=
t.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=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" =
SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos=
t" \
WITH_META_MODE=3Dyes \
MAKEOBJDIRPREFIX=3D"/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=20
#!/bin/sh
#
# $FreeBSD: head/release/arm/RPI2.conf 325950 2017-11-17 17:36:45Z gjb $
#
EMBEDDED_TARGET_ARCH=3D"armv7"
EMBEDDED_TARGET=3D"arm"
EMBEDDEDBUILD=3D1
EMBEDDEDPORTS=3D"sysutils/u-boot-rpi2 sysutils/rpi-firmware"
FAT_SIZE=3D"50m"
FAT_TYPE=3D"16"
IMAGE_SIZE=3D"3072M"
KERNEL=3D"GENERIC"
MD_ARGS=3D"-x 63 -y 255"
NODOC=3D1
PART_SCHEME=3D"MBR"
export BOARDNAME=3D"RPI2"
arm_install_uboot() {
UBOOT_DIR=3D"/usr/local/share/u-boot/u-boot-rpi2"
RPI_FIRMWARE_DIR=3D"/usr/local/share/rpi-firmware"
UBOOT_FILES=3D"u-boot.bin"
RPI_FIRMWARE_FILES=3D"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=3D"${DESTDIR%${KERNEL}}/fat"
UFSMOUNT=3D"${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}
=20
return 0
}
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EE68320-8359-495D-AFCE-098A2220C6AE>