Re: Nanobsd for RPI4

Andrew Hankinson <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>

> On 16 Jan 2024, at 10:03, Guido Falsi <[email protected]> wrote:
> 
> On 16/01/24 09:52, Andrew Hankinson wrote:
>> Hello,
>> I saw a recent posting to this list about nanobsd for RPI3:
>> Re: Nanobsd builds for rpi3 out of embedded blow up during build <https://lists.freebsd.org/archives/freebsd-arm/2024-January/003509html>
>> lists.freebsd.org <https://lists.freebsd.org/archives/freebsd-arm/2024-January/003509.html>
>> favicon.ico <https://lists.freebsd.org/archives/freebsd-arm/2024-January/003509.html>
>> <https://lists.freebsdorg/archives/freebsd-arm/2024-January/003509.html>
>> I just wanted to chime in to say I am seeing the exact same thing for a RPI4 build with both 14.0 release and 15.0 current. I asked about it on the forums, but there didn’t seem to be any solution.
>> Has anyone here managed to get a nanobsd build working?
> 
> I am using nanobsd with RPi3. Never tried RPi4. I did some customization to the nanobsd scripts and configuration to get it working though.
> 
> Last time I rebuilt my image was in mid december. I'm going to build a new image in the next pair of weeks.
> 
> Is the problem limited to the boot code?

I haven't been able to get past the boot code bit, but up until this point it works OK. I've simply copied the RPI3.cfg file and changed a few variables.

My build stops with the following logs:

# cat /usr/embedded/rpi4/_.cust.dos_boot_part
+ dos_boot_part
+ local 'd=/usr/local/share/u-boot/u-boot-rpi4'
+ local 'f=/usr/embedded/rpi4/_.fat'
+ rm -rf /usr/embedded/rpi4/_.fat
+ mkdir /usr/embedded/rpi4/_.fat
+ chdir /usr/embedded/rpi4/_.fat
+ cp /usr/local/share/u-boot/u-boot-rpi4/README /usr/local/share/u-boot/u-boot-rpi4/metadata /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin .
+ touch uEnv.txt
+ cp '/usr/embedded/rpi4/_.w/boot/dtb/*.dtb' .
cp: /usr/embedded/rpi4/_.w/boot/dtb/*.dtb: No such file or directory

This seems to be a problem with the dos_boot_part() function in /usr/src/tools/tools/nanobsd/embedded/common. 

Your code seems to bypass this and uses the rpi-firmware package .dtbo files. 

So I guess my questions are:

1. What changed that the .dtb files are no longer created in the regular build?
2. Should the dos_boot_part() function be changed to take the files from the rpi-firmware pkg instead?

Not being familiar with the nanobsd building process, I'm not really sure what is the best way to go.



> 
> I have this code to create that partition:
> 
> populate_boot_part ( ) (
>    MNT=$1
> 
>    UBOOT_DIR="/usr/local/share/u-boot/${NANO_BOOT_PKG}"
>    FIRMW_DIR="/usr/local/share/rpi-firmware"
>    FIRMO_DIR="${FIRMW_DIR}/overlays"
> 
>    # Required files
>    UBOOT_FILES="README u-boot.bin"
>    DTB="bcm2710-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb bcm2710-rpi-cm3.dtb bcm2711-rpi-4-b.dtb"
>    OVERLAYS="mmc.dtbo pwm.dtbo disable-bt.dtbo"
>    DTB_FILES="armstub8.bin armstub8-gic.bin bootcode.bin fixup_cd.dat \
>        fixup_db.dat fixup_x.dat fixup.dat LICENCE.broadcom \
>        start_cd.elf start_db.elf start_x.elf start.elf \
>        fixup4.dat fixup4cd.dat fixup4db.dat fixup4x.dat start4.elf \
>        start4cd.elf start4db.elf start4x.elf ${DTB}"
> 
>    for _F in ${UBOOT_FILES}; do
>        cp ${UBOOT_DIR}/${_F} ${MNT}/${_F}
>    done
>    for _F in ${DTB_FILES}; do
>        cp ${FIRMW_DIR}/${_F} ${MNT}/${_F}
>    done
>    cp -p ${FIRMW_DIR}/config_arm64.txt ${MNT}/config.txt
>    mkdir -p ${MNT}/overlays
>    for _F in ${OVERLAYS}; do
>        cp -p ${FIRMO_DIR}/${_F} ${MNT}/overlays/${_F}
>    done
> 
>    mkdir -p ${MNT}/EFI/BOOT
>    cp -p ${NANO_WORLDDIR}/boot/loader_lua.efi \
>        ${MNT}/EFI/BOOT/bootaa64.efi
> 
>    cp -R ${NANO_WORLDDIR}/boot/dtb ${MNT}
> 
>    # tell loader what partition to startup from
>    mkdir -p ${MNT}/EFI/freebsd
>    echo "rootdev=disk0s3a" >${MNT}/EFI/freebsd/loader.env
> )
> 
> Hope this helps.
> 
> -- 
> Guido Falsi <[email protected]>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.