Date: Thu, 24 Nov 2016 13:17:01 -0800 From: Mark Millard <markmi@dsl-only.net> To: Michael Sperber <sperber@deinprogramm.de> Cc: freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 Message-ID: <B52515F6-0145-4DE7-BD2F-F484A6783E47@dsl-only.net> In-Reply-To: <y9l7f7t2smo.fsf@jellaby.local> References: <y9l7f7t2smo.fsf@jellaby.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Nov-24, at 12:23 AM, Michael Sperber <sperber at = deinprogramm.de> wrote: > I'm new to this list (and to FreeBSD on ARM), so forgive me if I'm > asking something trivial: >=20 > I built a FreeBSD 11.0-RELEASE image for my BPI M3 using Crochet, by = the > book as far as I can tell. The result doesn't boot, and I see no > external indication that anything is happening. (I.e. no LEDs = blinking, > as they usually do when a working image boots up.) >=20 > This thread: >=20 > http://permalink.gmane.org/gmane.os.freebsd.devel.arm/14466 >=20 > ... led me to believe uboot might currently be broken. Is that indeed > the case? Any instructions I could follow to get a working version. >=20 > Any help would be much appreciated! >=20 > --=20 > Regards, That link is about the BPi-M2 (not BPI-M3). As far as u-boot goes there = is: # ls -ld /usr/ports/sysutils/u-boot-*m[0-9] drwxr-xr-x 2 root wheel 4 Jul 24 17:02 = /usr/ports/sysutils/u-boot-bananapim2 drwxr-xr-x 3 root wheel 6 Jul 24 17:02 = /usr/ports/sysutils/u-boot-sinovoip-bpi-m3 I've successfully used the second with a BPi-M3 (as it was at the time anyway). I've access to a BPi-M3 V1.2 board with the power barrel connector instead of a small cell-phone-USB style power connector. I have a heatsink and a 3.3V fan. A 10 W (5V 2A) power supply was not enough so I'm using a 15 W (5V 3A) power supply so far. Trying to use a fan on the 5V always prevented booting, even with the 15 W power supply. The vintage of crochet that I used only allowed using head (CURRENT). I changed it to not check for that so that I could use stable/11 : diff --git a/lib/board.sh b/lib/board.sh index 98f54bc..926813c 100644 --- a/lib/board.sh +++ b/lib/board.sh @@ -83,7 +83,7 @@ strategy_add $PHASE_POST_CONFIG board_defined =20 # TODO: Not every board requires -CURRENT; copy this into all the # board setups and remove it from here. -strategy_add $PHASE_CHECK freebsd_current_test +#strategy_add $PHASE_CHECK freebsd_current_test =20 board_check_image_size_set ( ) { # Check that IMAGE_SIZE is set. Crochet makes the mistake of using a file in the file system as the swap-space when creating a swap-space is enabled. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 on why this is currently not a good idea --it can hang/lock-up. The swap space should be a separate partition instead because things are not working correctly for file based swap-spaces. So I avoided this. (The issue is not likely to stop a BPi-M3 from booting.) If one wants to create a swap partition after the basic install it is likely best to avoid the automatic growfs option: That would lead to needing to shrink a partition to make room for the swap-space partition. Growing to less than the full space available is easier, leaving room to add the swap partition as well. Initially not having a swap-space should be fine: it should still boot and operate, allowing one to do the rest of the steps to create a swap-space and set up to use it if one wants such. Soft updates journaling is also enabled by crochet. This has some tradeoffs according to: http://www.wonkity.com/~wblock/docs/html/ssd.html (The page is not about crochet, just about the author's recommendations for FreeeBSD generally.) Quoting: > Soft updates journaling (SUJ) is not used for two reasons: there > have been problems with SUJ that prevent the use of dump(8) to > back up filesystems, and SUJ=E2=80=99s killer feature is dramatically=20= > reduced fsck(8) times. But SSDs provide dramatically reduced > fsck(8) times anyway. So adjustments for this are another possibility. I sometimes use dump and restore so I wanted to avoid SUJ. Also after the initial boot of the BPi-M3 I changed things to have the root file system on a USB SSD where the SDHC performance does not matter after the kernel is loaded. I knew up front that I was going to do that. (The gpart create's -n figure below is way larger than I need on the SDHC but it is what I used.) diff --git a/lib/disk.sh b/lib/disk.sh index 53dfb10..507d28e 100644 --- a/lib/disk.sh +++ b/lib/disk.sh @@ -386,7 +386,7 @@ disk_ufs_create ( ) { NEW_UFS_SLICE=3D`gpart add -t freebsd -a 512k ${SIZE_ARG} = ${DISK_MD} | sed -e 's/ .*//'` || exit 1 NEW_UFS_SLICE_NUMBER=3D`echo ${NEW_UFS_SLICE} | sed -e = 's/.*[^0-9]//'` =20 - gpart create -s BSD ${NEW_UFS_SLICE} + gpart create -s BSD -n 20 ${NEW_UFS_SLICE} NEW_UFS_PARTITION=3D`gpart add -t freebsd-ufs -a 64k = ${NEW_UFS_SLICE} | sed -e 's/ .*//'` || exit 1 =20 NEW_UFS_DEVICE=3D/dev/${NEW_UFS_PARTITION} @@ -398,7 +398,7 @@ disk_ufs_create ( ) { # This makes reboots tolerable if you just pull power # Note: A slow SDHC reads about 1MB/s, so a 30MB # journal can delay boot by 30s. - tunefs -j enable -S 4194304 ${NEW_UFS_DEVICE} + #tunefs -j enable -S 4194304 ${NEW_UFS_DEVICE} # Turn on NFSv4 ACLs tunefs -N enable ${NEW_UFS_DEVICE} =20 As for "pulling power": the power switch shuts down like "shutdown -p now" so I just do not pull out the power cord. I either type the command or push the button. I'm not doing things for which those would be likely to fail or to be unavailable. [FYI: The index of recommendation articles is at: http://www.wonkity.com/~wblock/docs/ ] Note: After the initial boot via crochet I've used normal FreeBSD cross-build techniques to update instead of using crochet. (I did confirm the ability to buildworld buildkernel on the BPi-M3. That is part of how I judge "stable enough that I'll use it".) Note: It is not obvious from the various related FreeBSD web pages and the like but so far FreeBSD only uses 4 of the 8 cores in the A83T that the BPi-M3 has. =46rom what I've been told the "pmap" implementation would need a lot of work even though all the cores are of the same time. For one each cluster of 4 cores has a shared cache but there is no cache spanning both clusters. So context swapping the core in use has variable criteria depending on the from vs. to target (or a very sub-optimal implementation that gets less advantages from the cache sharing that is possible). Unless someone with a personal interest and the right background knowledge decides to do the work, it seems likely it will stay limited to 4 cores. Also some might take the point of view "do not bother unless you also handle the bigLITTLE combinations of cores of different types as well". That likely would make things much more complicated. Note: -n for "gpart create" is described as (in "man 8 gpart"): > -n entries The number of entries in the partition = table. > Every partitioning scheme has a minimum = and > maximum number of entries. This option = allows > tables to be created with a number of = entries > that is within the limits. Some = schemes have a > maximum equal to the minimum and some = schemes > have a maximum large enough to be = considered > unlimited. By default, partition = tables are > created with the minimum number of = entries. I did not find what the minimum was so I was explicit instead. =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?B52515F6-0145-4DE7-BD2F-F484A6783E47>