From nobody Sun Nov 05 03:04:48 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SNK920mT2z4ynXx for ; Sun, 5 Nov 2023 03:05:10 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from ppp150-101-221-139.static.internode.on.net (2001-44b8-4170-0a00-0000-0000-0000-0002.static.ipv6.internode.on.net [IPv6:2001:44b8:4170:a00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "150.101.221.139", Issuer "Bunya Technology Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SNK9124tjz4Kwf for ; Sun, 5 Nov 2023 03:05:08 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Authentication-Results: mx1.freebsd.org; none Received: from localhost (localhost [127.0.0.1]) by cope.tawonga.bunyatech.com.au (8.15.2/8.15.2) with ESMTPS id 3A534oRA094467 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Nov 2023 14:04:52 +1100 (AEDT) (envelope-from bscott@bunyatech.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunyatech.com.au; s=tawonga211; t=1699153492; bh=6LCyppGH6ajEDQsCa2QAJc1P8TJtcv86sEORlXrYTxk=; h=Date:Subject:To:References:From:In-Reply-To; b=O2zKSZ+UQo2Wbl7pLS3gkukMtyUup6/XGvesFXSCZ/IKIT3ColHqFZ3FI3D9FeMF+ o2lGVEJN5zEpyMR184VUP1dW7rX5DOREFmjX0f0khF3IW3GvasW6UcB4d7MbuT0xkC QvvHOtO0LDiybGQSflWr0nr2yS26Bpb1KbOGG4Zw= X-Clacks-Overhead: GNU Terry Pratchett Received: from [IPV6:2001:44b8:4170:aff:6940:e709:7837:2bcc] (2001-44b8-4170-0aff-6940-e709-7837-2bcc.static.ipv6.internode.on.net [IPv6:2001:44b8:4170:aff:6940:e709:7837:2bcc]) (authenticated bits=0) by localhost (8.15.2/8.15.2/MSA) with ESMTPSA id 3A534oMK094464 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sun, 5 Nov 2023 14:04:50 +1100 (AEDT) (envelope-from bscott@bunyatech.com.au) Message-ID: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> Date: Sun, 5 Nov 2023 14:04:48 +1100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: NanoBSD on Raspberry Pi3 To: Guido Falsi , freebsd-arm References: Content-Language: en-GB From: Brian Scott In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:4739, ipnet:2001:44b8::/32, country:AU] X-Rspamd-Queue-Id: 4SNK9124tjz4Kwf On 5/11/2023 3:50 am, Guido Falsi wrote: > Hi all! > > I am trying to build a NanoBSD image for a spare RPi3. > > I started from an existing configuration I am using for a PCEngine > APU2 board, I use as an internal DNS and DHCP server. I'd like to > replace it. > > I'd also like to be able to upgrade using the altroot partition and > then switching the default one, but am not sure how to do that, maybe > I can play with efi variables, anyway I'm going to investigate this > once I get at least FreeBSD booting. > > Unluckily I am unable to make my image properly boot. One of the keys to doing the dual system in my case has been to create a loader.env file telling the loader which partition to boot. # more EFI/freebsd/loader.env rootdev=disk0s3a > > I have reworked my scripts to replicate how the official release > images are made in structure. (copying a lot from src/release) > > I got t the point where loader_lua.efi (renamed as the standard > `/EFI/BOOT/bootaa64.efi` in the fat partition) loads, looks like it is > scanning disks but then says: > > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. The loader.env should be read by the bootaa64.efi program. > > > It gives me a prompt, but even if I do have a working USB keyboard > plugged in I am unable to interact (maybe this is normal at this stage?) No idea, sorry. > > I guess it is failing to find the root filesystem but I don't know > why. There is a valid root partition. Do I need to put some boot code > in it to make loader recognize it? > > Where could I find some more detailed information about u-boot and > UEFI boot? Maybe I can help by creating some configuration file in the > UEFI partition? > > Thanks in advance for any indication. > > > Output of `gpart show` (fromthe image mounted as md): > > =>     63  8617921  md1  MBR  (4.1G) >        63      961       - free -  (481K) >      1024    65536    1  fat32lba  [active]  (32M) >     66560   131072    2  freebsd  (64M) >    197632  4194304    3  freebsd  (2.0G) >   4391936  4194304    4  freebsd  (2.0G) >   8586240    31744       - free -  (16M) > > =>      0  4194304  md1s3  BSD  (2.0G) >         0      128         - free -  (64K) >       128  4194176      1  freebsd-ufs  (2.0G) > > > (it looks quite similar to the official image one, as far as I can see) I'm using: # gpart show =>       1  62357503  mmcsd0  MBR  (30G)          1     65536       1  fat32lba  [active]  (32M)      65537     65536       2  freebsd  (32M)     131073  31113215       3  freebsd  (15G)   31244288  31113216       4  freebsd  (15G) =>       0  31113215  mmcsd0s3  BSD  (15G)          0        16            - free -  (8.0K)         16  31113199         1  freebsd-ufs  (15G) =>       0  31113216  mmcsd0s4  BSD  (15G)          0      8192            - free -  (4.0M)       8192  31105024         1  freebsd-ufs  (15G) And it works really well. This is taken from a running rpi3. I also have the same layout on a pi3 at $work, an original 256MB pi (forever stuck on version13 now), and a 8GB pi4. My modified update script toggles the loader.env file after updating the alternate file system and running the growfs magic on it. It looks like you have that organised properly. > > > Not sure what other information I can share, but I will send anything > that can help shed some light. > > Cheers, Brian