Date: Sun, 17 Feb 2019 13:53:21 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= <freebsdnewbie@freenet.de> To: freebsd-arm@freebsd.org Subject: [BBB] NanoBSD ubldr problems Message-ID: <20190217125321.GA30529@freebsd-t450.fritz.box>
next in thread | raw e-mail | index | archive | help
Hi,
I'm having some trouble getting plain NanoBSD running on an beaglebone
black. Eventually I've got it working by making these two changes:
1. switch partitions NANO_SLICE_CFG from s2 to s3 and NANO_SLICE_ROOT
from s3 to s2 in nanobsd/embedded/common
2. mark fat-partition active during mkimg for std-embedded NANO_LAYOUT
The switch of partitions is necessary, because ubldr seems to not boot
kernels from partitions other than ${DISK}s2 out of the box. Setting
loaderdev does not help because ubldr has some issues; by using two
different structs (disk_devdesc and uboot_devdesc) synonymously for
providing slice and partition information down a call stack and not
defining them as packed, padding prevents correct information transport.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233097
Even with these changes applied, ubldr does not boot the s3-slice which
contains the rootfs in default nanobsd-config, but tries s2 (conf) which
fails because conf does not contain any kernel. I read in the source
comments that ubldr will prioritise those partitions containing active
flag in mbr-based disks over those without, but it is neccessary to mark
the FAT-slice active because the BBB-ROM-loader will not boot u-boot
because it checks for an active FAT-partition to find MLO and stuff.
Setting loaderdev to "disk 0:3.0" in uboot helps, but trying to make it
permanent via uEnv.txt does not work. Isn't uEnv.txt evaluated?
As far as I understand, the boot does only work if the rootfs is located
in the first slice to probe by ubldr, correct?
How does the described update procedure (image-ping-pong) for arm
NanoBSD work then?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190217125321.GA30529>