Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566]
Date: Mon, 18 Dec 2023 22:15:34 UTC
if u-boot is configured with EFI support then u-boot loads loader.efi directly (bootaa64.efi) which is already on aarch64 images > On 18 Dec 2023, at 20:44, Mark Millard <marklmi@yahoo.com> wrote: > > On Dec 18, 2023, at 10:22, Harry <freebsd@omnilan.de <mailto:freebsd@omnilan.de>> wrote: >> >> On 12/15/23 16:56, Emmanuel Vadot wrote: >>> U-Boot also doesn't support the DRAM controller so we also need an >>> external blob from rkbin. >>> That's the main reason I haven't done ports for u-boot on rk356x so >>> one have to compile u-boot themselve. >>> It can be simply done like any other u-boot targets and only needs two >>> env variable : >>> export BL31=/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf >>> export >>> ROCKCHIP_TPL=/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin >> >> Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I came up with so far :-) >> I'm trying to understand what happens with the help of this: >> http://opensource.rock-chips.com/wiki_Boot_option >> The attached diff (updates sysutils/linux-rkbin (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and adds sysutils/u-boot-nanopi-r5c) >> allows me to build u-boot, supposedly supporting R5C(rk3568). >> After putting these onto SD-card with >> dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/idbloader.img of=/dev/da1 seek=8 bs=4k conv=sync >> dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-boot.itb of=/dev/da1 seek=2048 bs=4k conv=sync >> my nanopi-R5C boots from eMMC instead of SD. >> I downloaded a NANOPI-R5C_EFI.itb elsewhere. >> I can get the TianoCore port booting... >> But I'm missing the part, where ubldr, the FreeBSD post-u-boot-loader, is supposed to take over - and how... >> I simply created a freebsd-ufs partition and put /boot along with a loader.conf onto it, which works using the foreign TianoCore port, but not my newly created u-boot. >> >> What am I missung after dd'ing? >> Any hints appreciated! > > FYI: ubldr is no longer part of the standard/typical way of booting these days, > at least for armv7 (and aarch64): > > https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=0d6e5081eb00 <https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=0d6e5081eb00> > > reports (back in mid-2021): > > QUOTE > author Emmanuel Vadot <manu@FreeBSD.org <mailto:manu@FreeBSD.org>> 2021-05-11 18:27:14 +0000 > committer Emmanuel Vadot <manu@FreeBSD.org <mailto:manu@FreeBSD.org>> 2021-05-11 20:22:54 +0000 > commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch) > . . . > sysutils/u-boot-*: Remove ubldr support > We have been using loader.efi on armv7 for a long time now. Remove support for booting with ubldr and the needed patches that were never upstreamed. While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=y in the Fragment as it's needed to have the cache flushed for us when loader.efi is started. > END QUOTE > > Any documentation indicating sny ubldr involvement likely predates that > change. > >> -harry >> >> P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff attached, the I used the commented nanopi-r5c-rk3568_defconfig! evb-rk3568_defconfig is a leftover... >> >> <FE-r5c_ports.diff.xz> > > > > === > Mark Millard > marklmi at yahoo.com <http://yahoo.com/>