From nobody Sun Nov 5 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 From nobody Sun Nov 5 09:13:36 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 4SNTLK4Pl7z4ydd0 for ; Sun, 5 Nov 2023 09:13:45 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [IPv6:2a01:4f8:1c1c:11e5::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SNTLK2210z3HnH for ; Sun, 5 Nov 2023 09:13:45 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by mail.madpilot.net (Postfix) with ESMTP id 4SNTLF6yR2z6gLr; Sun, 5 Nov 2023 10:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1699175618; x= 1700990019; bh=JWHptH2R+gKSVh1tO45LFOIpIUJqEq3xsdwwsX47hNw=; b=D jzxcDhHanUoO6RKT2/c8oauhplcwzOkhJcUFiWfhMfzgNIiJHcv/zUXdpQVZWVe0 pDCA/KE2Dqg/oSc6xqVrgz3bhFZXN2K8YaRojSbkEjhYvgxdjBO0W4KxEkpZohOz 2ZnscF0r/scIRAnoIdL8mkmZ8NXFIs3urBPWId3mUW1A63pU9sbT2vFazGe9tu14 Cs+nR0qWlY+aiw9dai8q2Pt1z0amgBtZOBT5vYqEzi10PvAbk50STPeP/tzvRvBc 5x7juvJ3J7Zl1kIkpOcg3WNpRfX8XeLAPdABgie08BRcAaoSRp7NnmsD/4IZFBmQ MfNMgqu67eIw3056RVT9Q== Received: from mail.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (mail.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id ELk81FTOOolF; Sun, 5 Nov 2023 10:13:38 +0100 (CET) Message-ID: <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> Date: Sun, 5 Nov 2023 10:13:36 +0100 Subject: Re: NanoBSD on Raspberry Pi3 To: Brian Scott , freebsd-arm References: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> Content-Language: en-US, it From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy In-Reply-To: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> 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:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Queue-Id: 4SNTLK2210z3HnH 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 On 05/11/23 04:04, Brian Scott wrote: > > 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 > Thanks a lot! This made it boot successfully! Obviously the boot spilled a bunch of errors, most just because I'm testing not connected to the network and the configuration expects networking to be available, but this is just a test. Really thanks a lot, this piece of information never turned out in any searches I did and I did not notice it in any man page/README etc. In fact I think this should be documented, if it is not already. Do you know if it is already in some manual page or readme or at least the wiki? If not I think it should be described in loader.efi(8), I'd like to propose a patch to this effect. Maybe also add a note in our wiki in the arm and/or uefi pages. Have you got some pointer to some documentation elsewhere about this so I can write an informed paragraph for the man page about this? >> >> 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. Yes this was the key to making it work. Maybe if I used a gpt partition scheme it would have worked OOB, while mbr requires this kind of help. Not sure if it is worth using gpt or could cause even more issues though. >> >> >> 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. Keyboard works fine once kernel starts, looks like a u-boot issue. Not too worried about it though, as long as FreeBSD boots. >> >> 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. Yes I'll adapt my nanobsd update script to take advantage of the .env file and I should be ready to go. I'm actually skipping the grow part, since I'm never writing to the OS partitions, I'm using them like a firmware, only writing to the cfg partition (or the ramdisks obviously). > > It looks like you have that organised properly. > Thanks a lot again for your help! Really appreciated. Cheers! -- Guido Falsi From nobody Sun Nov 5 11:05:01 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 4SNWq05shlz503mY for ; Sun, 5 Nov 2023 11:05:16 +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 4SNWq00Qhxz3VDF for ; Sun, 5 Nov 2023 11:05:15 +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 3A5B577P057756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Nov 2023 22:05:07 +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=1699182308; bh=6EtfQxf3lJ0DrZD1AirfHBiTcKWYG5vW2Va9St1LhUw=; h=Date:Subject:To:References:From:In-Reply-To; b=FPDwvY/a9PaHZ79FWKDtiQwD32vseGgf3Q3ZUz618A5d6MrPrCRs5MSg33PjwM2xn vQu8D9QBBTpR4R8oKE8jrAppXKiWjMiyXYXzRRhxEgDs1cYFPoPnFgOgzbVucUvv51 tIG0NS9OwKRaTU2RyzkkM5kGvK/nGUPq8KVrADxA= 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 3A5B57tB057753 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sun, 5 Nov 2023 22:05:07 +1100 (AEDT) (envelope-from bscott@bunyatech.com.au) Message-ID: Date: Sun, 5 Nov 2023 22:05:01 +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 Content-Language: en-GB To: Guido Falsi , freebsd-arm References: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> From: Brian Scott In-Reply-To: <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> 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: 4SNWq00Qhxz3VDF On 5/11/2023 8:13 pm, Guido Falsi wrote: > On 05/11/23 04:04, Brian Scott wrote: >> >> 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 >> > > Thanks a lot! This made it boot successfully! > > Obviously the boot spilled a bunch of errors, most just because I'm > testing not connected to the network and the configuration expects > networking to be available, but this is just a test. > > Really thanks a lot, this piece of information never turned out in any > searches I did and I did not notice it in any man page/README etc. > > In fact I think this should be documented, if it is not already. Do > you know if it is already in some manual page or readme or at least > the wiki? If not I think it should be described in loader.efi(8), I'd > like to propose a patch to this effect. Maybe also add a note in our > wiki in the arm and/or uefi pages. > > Have you got some pointer to some documentation elsewhere about this > so I can write an informed paragraph for the man page about this? I found it a couple of years ago after a lot of searching. No idea where I found it even though I normally try to keep notes. It would be nice to see some doco on it. > >>> >>> 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. > > Yes this was the key to making it work. Maybe if I used a gpt > partition scheme it would have worked OOB, while mbr requires this > kind of help. Not sure if it is worth using gpt or could cause even > more issues though. As I understand it, the RPi firmware requires MBR partitioning. Haven't confirmed it recently but it does limit what you can do with nanobsd. > >>> >>> >>> 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. > > Keyboard works fine once kernel starts, looks like a u-boot issue. Not > too worried about it though, as long as FreeBSD boots. > >>> >>> 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. > > Yes I'll adapt my nanobsd update script to take advantage of the .env > file and I should be ready to go. > > I'm actually skipping the grow part, since I'm never writing to the OS > partitions, I'm using them like a firmware, only writing to the cfg > partition (or the ramdisks obviously). Good point. I just like it to look neat and tidy. Probably says more about me than anything else. > >> >> It looks like you have that organised properly. >> > > Thanks a lot again for your help! Really appreciated. > > Cheers! > From nobody Sun Nov 5 21:00:33 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 4SNn1s5w9cz50RKL for ; Sun, 5 Nov 2023 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SNn1s3Xbzz4P7j for ; Sun, 5 Nov 2023 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699218033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FFYPJQuyARlhg/e7Hv8NYozTIVkz1A8wV+R7NvRjJ88=; b=i3icYuZrs0JVBC+IArgMQeAj7qEddfpffl9ryhbY8pqFsCrTuLlmagw2078q0nChRATtDe lJcf24XT1hGZquyUBrn6bjnN8Hn0XjQ5y5o6oIlxrmoRB9kUZThiTgfbsLjDmWcgEKicaT OJVxKIB5fWIywVjtCnqHeEQyGm/EUU6xxJH3UWtnPeZRxi1b/3L1C4MV7fph6L9c8XUom8 hNAiA27g0D6ud4MoxqzTCkN5DCx7noPxNwPGcEKGntWpJsLOBgJTbzVKJXz4huylijE0z/ Kg+7h9YDtR+vcOOkxPk6yp5E9dPPRQ3QzlH/6SDUN5riF2VZwjn8Xf/v2qYiMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699218033; a=rsa-sha256; cv=none; b=Z8bW9xkMTxKdp2kctMdnKiJZE3tp5KM9lK9dbZBKcw+MEfrUdmYwmOSkbW9dLJHyAvUNZc jHyLZ5POv+iYHluENbSckWT7xpac2qOQzPNXM0kkdFzpbqTmVRnHwKncOop1lwAKBXK/Qg Puafekop7u701rwfMUIr7gYIQoC70uNyWznAgInkUouqvIgrHj4uicCLQb/CPDVMrH6n2d 6X/9V72v1SaY3cdbjRNPOlxFEj600quZYA2XnHZwrT0U46wnP/QSpCEdLewtTTAce0q3o/ Al+oh2suYGmOOKwhrngmYFzOVH58Qiu6eM0G7DzE3h+lPuW3lU0jWVrz+t0g9A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SNn1s2ff3zgFj for ; Sun, 5 Nov 2023 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3A5L0XZw011451 for ; Sun, 5 Nov 2023 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3A5L0Xnh011450 for freebsd-arm@FreeBSD.org; Sun, 5 Nov 2023 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202311052100.3A5L0Xnh011450@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 5 Nov 2023 21:00:33 +0000 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 Content-Type: multipart/alternative; boundary="16992180332.aC6C.9223" Content-Transfer-Encoding: 7bit --16992180332.aC6C.9223 Date: Sun, 5 Nov 2023 21:00:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16992180332.aC6C.9223 Date: Sun, 5 Nov 2023 21:00:33 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16992180332.aC6C.9223-- From nobody Mon Nov 6 10:06:22 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 4SP6Sm73Xkz506lQ for ; Mon, 6 Nov 2023 10:06:32 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SP6Sm3QVbz4RP6 for ; Mon, 6 Nov 2023 10:06:32 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by mail.madpilot.net (Postfix) with ESMTP id 4SP6Sd1lqJz6gtt; Mon, 6 Nov 2023 11:06:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1699265183; x= 1701079584; bh=ewffs/4vfxV54wRK0zK56Ktk2IdOw/YfAUTcWC+Hfs0=; b=M NcbtcWqnsVTyfbS9DqJblQd9paep+SfropE2EO9rPhp69nynKCFXE8Iz7UehoeEZ CSLLo99y+OoP0SIOvT0QgcGgv3N4uQB7vI+YyJ34J6dChz7uWA5TdMgBXv2Tanuy 1WAamtoAEXSOQA+zDe7TgfCl26hlzjZcqnQ14by0+0+8PlKYQOe8nNS5Xk+oYG9/ vQakSYuFS9PgncRhHoUbFZg3OMeqRbLgzHDzJsHb+KndO+1g0EPenVsYq+9Ik27Z BfjK/t2bpXU8pjuVjPzT07p3IkYiDYR4hUu1/LTccIJvAGCaI1B4x0qLkKXOt5CB 3pDXys1Zv4RKTNQuMCaog== Received: from mail.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (mail.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id OIwmpX9M9OS1; Mon, 6 Nov 2023 11:06:23 +0100 (CET) Message-ID: <9036ce5f-f3b8-4c83-a569-aa4d86436e6b@madpilot.net> Date: Mon, 6 Nov 2023 11:06:22 +0100 Subject: Re: NanoBSD on Raspberry Pi3 To: Brian Scott , freebsd-arm References: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> Content-Language: en-US, it From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:24940, ipnet:159.69.0.0/16, country:DE] X-Rspamd-Queue-Id: 4SP6Sm3QVbz4RP6 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 On 05/11/23 12:05, Brian Scott wrote: > > On 5/11/2023 8:13 pm, Guido Falsi wrote: >> On 05/11/23 04:04, Brian Scott wrote: >>> >>> 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 >>> >> >> Thanks a lot! This made it boot successfully! >> >> Obviously the boot spilled a bunch of errors, most just because I'm >> testing not connected to the network and the configuration expects >> networking to be available, but this is just a test. >> >> Really thanks a lot, this piece of information never turned out in any >> searches I did and I did not notice it in any man page/README etc. >> >> In fact I think this should be documented, if it is not already. Do >> you know if it is already in some manual page or readme or at least >> the wiki? If not I think it should be described in loader.efi(8), I'd >> like to propose a patch to this effect. Maybe also add a note in our >> wiki in the arm and/or uefi pages. >> >> Have you got some pointer to some documentation elsewhere about this >> so I can write an informed paragraph for the man page about this? > I found it a couple of years ago after a lot of searching. No idea where > I found it even though I normally try to keep notes. It would be nice to > see some doco on it. I created a code review to update loader.env(8) man page. I really did the bare minimum there, but it would be better than nothing anyway: https://reviews.freebsd.org/D42476 >> >>>> >>>> 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. >> >> Yes this was the key to making it work. Maybe if I used a gpt >> partition scheme it would have worked OOB, while mbr requires this >> kind of help. Not sure if it is worth using gpt or could cause even >> more issues though. > As I understand it, the RPi firmware requires MBR partitioning. Haven't > confirmed it recently but it does limit what you can do with nanobsd. I see. Well I have no special preference for EFI over MBR as long it gets the system booting properly, so I'll stay with MBR. -- Guido Falsi From nobody Mon Nov 6 10:08:04 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 4SP6Vk6qtbz5070y for ; Mon, 6 Nov 2023 10:08:14 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [IPv6:2a01:4f8:1c1c:11e5::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SP6Vj5XGPz4RnR for ; Mon, 6 Nov 2023 10:08:13 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="f j0SMYr"; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 2a01:4f8:1c1c:11e5::1 as permitted sender) smtp.mailfrom=mad@madpilot.net; dmarc=pass (policy=quarantine) header.from=madpilot.net Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by mail.madpilot.net (Postfix) with ESMTP id 4SP6VZ4LLgz6gQJ; Mon, 6 Nov 2023 11:08:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:from:from:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1699265284; x= 1701079685; bh=UPr+8JZ9mIhW2IjhCv8ehImaH9QgXpDYpmaQTwnZkAQ=; b=f j0SMYrII7mLjkNQdxoKj1Kv4JzC1PN9cg/gVIhqGwdlrR8FypqKO1eA6P/hbSquf N3mNleugaP+SO+Yn5EZYXOZZs0bzUjh87TYa4xi7N76FlQD8MtkfOyiviPX3sY6m /zaFQTJXR0Ay1IsIVyw0Z3FrErghqmh7Z5hT51kz+VYx3VtIy7dvhCB6JMfMl/JU x5G5GAtW69ccx5eQY/unsTBw4YbdLZAGDWZDng9GLFDPgUpQGmLZKDI/PofzIja4 GgqoWRMri4puLsKSOH3+y0Y/Knnv7UKrF04g2Gs7nAvaIOeeAKVijcwD7ylg1UO7 8PoQOaxmwllLqGGZtrdng== Received: from mail.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (mail.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id 0GbQ9nleUEm8; Mon, 6 Nov 2023 11:08:04 +0100 (CET) Message-ID: Date: Mon, 6 Nov 2023 11:08:04 +0100 Subject: Re: NanoBSD on Raspberry Pi3 Content-Language: en-US, it From: Guido Falsi To: Brian Scott , freebsd-arm References: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> <9036ce5f-f3b8-4c83-a569-aa4d86436e6b@madpilot.net> Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy In-Reply-To: <9036ce5f-f3b8-4c83-a569-aa4d86436e6b@madpilot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.99 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SP6Vj5XGPz4RnR X-Spamd-Bar: - 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 On 06/11/23 11:06, Guido Falsi wrote: > On 05/11/23 12:05, Brian Scott wrote: >> >> On 5/11/2023 8:13 pm, Guido Falsi wrote: >>> Have you got some pointer to some documentation elsewhere about this >>> so I can write an informed paragraph for the man page about this? >> I found it a couple of years ago after a lot of searching. No idea >> where I found it even though I normally try to keep notes. It would be >> nice to see some doco on it. > > I created a code review to update loader.env(8) man page. I really did I obviously meant loader.efi(8) here. -- Guido Falsi From nobody Tue Nov 7 00:32:39 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 4SPThf5PGvz50rNH for ; Tue, 7 Nov 2023 00:33:06 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SPThd3VFTz3Bng for ; Tue, 7 Nov 2023 00:33:05 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailgate.us header.s=mail header.b=KtzHklyZ; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 72F1D58B50 for ; Tue, 7 Nov 2023 03:32:56 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1699317177; bh=5c/nLlINliggNCPUBn46V1fR4IFnEqAtnSKp4RTrbe0=; h=From:Subject:To:References:Date; b=KtzHklyZv5YU5ayK5dPOMiwl4x8/VIoQ9Wznu+0R46G5wo22W6DWP6f34gh3soBIh oqz+lbllBOx/vHaTxZ8hFEo5m2LwE/pyZOZmjkCaIC5xiA4G8TleHu2fwwugmjFSvW mGMzdmlSmkiuHOjykye+EHxFhqVFvM8bKyskge98= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-16993171663830.45670279701976546" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: reply To: "freebsd-arm" User-Agent: Desktop Message-Id: <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 07 Nov 2023 00:32:39 +0000 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 X-Spamd-Result: default: False [0.74 / 15.00]; URI_COUNT_ODD(1.00)[23]; R_DKIM_REJECT(1.00)[mailgate.us:s=mail]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; NEURAL_HAM_SHORT(-0.97)[-0.971]; SUBJ_ALL_CAPS(0.75)[10]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; NEURAL_SPAM_LONG(0.13)[0.126]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:-]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mailgate.us]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SPThd3VFTz3Bng X-Spamd-Bar: / ------sinikael-?=_1-16993171663830.45670279701976546 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> > //Oskar ------sinikael-?=_1-16993171663830.45670279701976546 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
my current progress of STM32MP1xx port attempt:

Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.

Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with 

control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:

    /* prepare to use LED @ GPIOA 13*/
    ldr r0, =0x50002014
    ldr r1, =0xFFFFDFFF
    ldr r2, [r0]
    and r2, r1, r2

/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB

    /* turn on GPIO LED */
    str r2, [r0]

Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...

I thought it was due to security access control from TF-A, but it behaves the same w/o.

Any clues or expertise from other platforms are highly appreciated.

Stan

Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.

As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?

The u-boot loads ubldr this way in my current setup:

  // FreeBSD version of environment
  env_set("baudrate", "115200");
  env_set("console", "ttyS0,115200");
  env_set("stderr", "serial");
  env_set("stdin", "serial");
  env_set("stdout", "serial");
  env_set("autostart", "yes");
  env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
  env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");

then ubldr leads the kernel from mmc and passes it the control:

Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)

Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.

So, just need to understand what is best option to load ubldr to? Will it affect further routines?

Stan


Stanislav Silnicki wrote:


OK, I got the idea!

As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.

My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).

The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ;try to post PR's in those repos... Not sure, anyway.

So far I'm struggling with uart and early_printf...

I'm mixing this activity with my current occupation, so I don't expect rapid progress.

Thank you for clarifications! I'll try to do my best!

Stan

Oskar Holmlund wrote:


Hi Stanislav,

Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.

You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.

Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.

Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?


1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.

//Oskar

2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:

quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan



> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.

kquote>

>> //Oskar
------sinikael-?=_1-16993171663830.45670279701976546-- From nobody Tue Nov 7 16:44:07 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 4SPvF40Xyhz50jnK for ; Tue, 7 Nov 2023 16:44:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SPvF349hTz3XF1 for ; Tue, 7 Nov 2023 16:44:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699375447; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Zx347eakh+sVCclSspoX2BhpgXJ/9sroiNGpx3/JE6M=; b=o0l4WThcK7Zj8ubcspvxGKzU+5TQAmKL2ecYu1/SjcCbrYCo8ZZUyiUadqB7GwzWbHFeHv sCgOgFgM64EnLPd0FbJFQ8kqbJEU8XOjlVjKcUsVbjGUaP1jBnRFEMG4JPzq2crAiEOAT7 ITLz455asbHGw3Euyz8e1VgN7S46dTnFrQF9JdoMs61d8PEe3y0FEqPadBKraHkU8vZ1v1 XtjUWWHzYhUMzgBP3PnUH3HdIBWmE2TJZfMGHN0UlDXNlszT0d9DkRdeeLXL+RwHXGYVPh OZNJdIjYekxcf07yHkwWIjaBPX4V9bO71QM0xewat5REoOJNwxo+s3ZmuMD4fg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699375447; a=rsa-sha256; cv=none; b=YucO2/2J07WYE9m62wspbXt/rGuK7lG4aXqscNkeRQx6+dPN83QjACsX93AJte1eS5ipLu AuT42ig4uWClPgOUhxyE4s3QQ2Srtm10517qIWQUcogqBIn/L3J+ffqB0rr9SStLEKNcUD 34Ph2teZIywLpqNmEz0onOYOVDbsxk4UVr6TmGBZ66aG7LDxrXW7HIriqMAwre1tpJFOXF xsRIyvAnDcc+Up3rjfobDS2pFLW36TRFltilceZTO+vJIr9sUnQeR7Jt9xO19IPNHb5he0 imMniOzWKvQnmczXg7suZ44/0HkJQwTvSg54Bses0yRXNTKm7AF4a4pxSrnDFg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SPvF33FDdzxSt for ; Tue, 7 Nov 2023 16:44:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3A7Gi7lM016419 for ; Tue, 7 Nov 2023 16:44:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3A7Gi789016418 for freebsd-arm@FreeBSD.org; Tue, 7 Nov 2023 16:44:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 274956] Kernel panic at mountroot prompt Date: Tue, 07 Nov 2023 16:44:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: paul.reynolds@redcom.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274956 Bug ID: 274956 Summary: Kernel panic at mountroot prompt Product: Base System Version: 15.0-CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: paul.reynolds@redcom.com I am attempting to boot FreeBSD on an i.MX 8M Plus EVK from NXP (https://www.nxp.com/design/development-boards/i-mx-evaluation-and-developm= ent-boards/evaluation-kit-for-the-i-mx-8m-plus-applications-processor:8MPLU= SLPD4-EVK). The kernel is loading successfully and boots up to the point where it is tr= ying to mount the root filesystem, at which point it panics. I have tried local builds of FreeBSD 13.2, and 14.0-RC2 as well as the 20231026 build of 15-CURRENT all with similar results. I am attempting to boot a USB installer image with the u-boot install shipp= ed on the board. u-boot commands: run loadfdt usb start fatload usb 0:1 ${loadaddr} /EFI/BOOT/bootaa64.efi bootefi ${loadaddr} ${fdt_addr} I have attached the initial kernel output along with the panic from the att= empt using the 20231026 build of 15-CURRENT. Any hints as to what might be going on here are greatly appreciated. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Nov 8 08:57:01 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 4SQJqw401lz50dwH for ; Wed, 8 Nov 2023 08:57:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SQJqv1Jwzz4YW4 for ; Wed, 8 Nov 2023 08:57:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=oLZykjw8; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=qJu8lalYn+B2mIxDnrspUl4svXfhZ0jf7P+ABoQXp34=; b=oLZykjw81NJ1HNuTEfOGNU3mwdiTnoCL/5IVUxLe/dttySvr1YIPmuTi42lJNky77XVzG+LfTbvbr4Y7U0jdiEJs7MGDAA4gFvVTzPheTzvGMR3wdyEo16q2yFINH224BGTgivrhh0z09OAYBahCndVpwtqBFyEM0Zt9b9VIFnlmakzzHILaOjpdLCLPR9LSdpMEiuSVsvAhDlrzkKnrGdRVzkIkitHKJQZgLiXlhrPEyufCBCLOvdxkLxP+7SCnUMTdNqBm1EhQ7/5KKhXy8/LUzhw9wXp8Z1dVDgknZ6tjMHcDAJ5J7kCTH2jhWox43bQwqgqq1VMOgMr5GsgU/A==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1r0eMw-00023i-1Q; Wed, 08 Nov 2023 10:57:02 +0200 Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: NanoBSD on Raspberry Pi3 From: Daniel Braniss In-Reply-To: Date: Wed, 8 Nov 2023 10:57:01 +0200 Cc: Brian Scott , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> <9036ce5f-f3b8-4c83-a569-aa4d86436e6b@madpilot.net> To: Guido Falsi X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4SQJqv1Jwzz4YW4 X-Spamd-Bar: --- > On 6 Nov 2023, at 12:08, Guido Falsi wrote: >=20 > On 06/11/23 11:06, Guido Falsi wrote: >> On 05/11/23 12:05, Brian Scott wrote: >>>=20 >>> On 5/11/2023 8:13 pm, Guido Falsi wrote: >>>> Have you got some pointer to some documentation elsewhere about = this so I can write an informed paragraph for the man page about this? >>> I found it a couple of years ago after a lot of searching. No idea = where I found it even though I normally try to keep notes. It would be = nice to see some doco on it. >> I created a code review to update loader.env(8) man page. I really = did=20 >=20 > I obviously meant loader.efi(8) here. >=20 >=20 > --=20 > Guido Falsi >=20 >=20 just a me too: have 2 rpi3,=20 works with the official image: model b v1.2 2015, but B+ 2017 = nothing, nada= From nobody Wed Nov 8 16:49:34 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 4SQWK01rpLz50Q9j for ; Wed, 8 Nov 2023 16:49:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SQWJz3tDNz3DWW for ; Wed, 8 Nov 2023 16:49:39 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=CLwQgscJ; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=GLTjvH3D; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2112E5C0176 for ; Wed, 8 Nov 2023 11:49:38 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 08 Nov 2023 11:49:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1699462178; x=1699548578; bh=HPhT9IkzkZ4YVt2gocTalAmJq N8Cl4vU+kZEOhUybYM=; b=CLwQgscJVTuIQ8L1viOhCpu9ZjP4ClGfoBtwpIKDB xh+b+Fz9bQSHZkcIZB86R5E9WPOmDWflZscS5OgEjuzEgzCrxSjk922fcWKcNbGu C5Zv6CwqCq/DK7HYr34ol8R8r9G8gXUo/itbSWusSHUDCLrmJzZmuOpEM4NLa9qh X8rkaQXDw1N1PJ4pagei0LXrlYfLG2nt6j6qXQbfNEgu/rH2zL8KnJVATg6r/JJd zw3p+ZBGGEmbk7y1xgnNgzmMX5VW3NZ8Deu6guAdASEkHA41UbEt3D1WxyPQ7RMh TxTZF974otFwWSZvCBxsyi+o7ovPXDSDzcMKsMH0d7NJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699462178; x=1699548578; bh=HPhT9IkzkZ4YVt2gocTalAmJqN8Cl4vU+kZ EOhUybYM=; b=GLTjvH3DJTCZaF/NKB9OjB9CAurpeJTrV3/Jae6QyJbAHGcuo8m TzWjnZ43ZnOHTCRZ48C0D5vRFtIOc3B46RP8rnVcF04hMg/WN/RitUitynbhJLC4 Yi0lKHJsuPIVWs8CSdzMzg+g3EoZ2KkSH6REQ3Pg3KAR0m3Z/PM684E3cxCK7nYA qU6tWwdVYS7Q9YmJVGhP7CxsBjhgIywRBDvDlUkRsZh5ITyoGguOHHkxLkRV6qDz xg2eyf3lmlRYz3TzQJRMg9kpswyw2bHUjIjrY7yYUAogdMHtiVeGCW9FZcs78iZx GwYG3fgw7LlSgZ6Q5kl4i60uHTVqm2oNFig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 8 Nov 2023 11:49:37 -0500 (EST) Date: Wed, 8 Nov 2023 16:49:34 +0000 From: void To: freebsd-arm@freebsd.org Subject: where to permanently set console output Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.74 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.74)[-0.743]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.27:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SQWJz3tDNz3DWW X-Spamd-Bar: ---- Since upgrading to 14-stable, I have found that when viewing through the serial console (rpi2b-provided), in the beastie menu, 5. Cons resets itself to Dual (Video primary), every reboot, regardless of what I then set it to. The behaviour before the upgrade was once it was set to Serial, it remained at Serial over multiple reboots. What do I need to change to make it stay Serial? This is a rpi4b running headless, stable/14-n265566 --