Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566]
- In reply to: titus : "Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 18 Dec 2023 23:32:00 UTC
On Dec 18, 2023, at 14:15, titus <titus@edc.ro> wrote: > if u-boot is configured with EFI support then > u-boot loads loader.efi directly (bootaa64.efi) which is already on aarch64 images Up to detailed naming conventions, armv7 also works via a renamed loader.efi for FreeBSD's way of setting things up (such as via sysutils/u-boot-* ports) and has for years. The name is bootarm.efi for armv7. For example, each of: FreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20231216-ca39f23347e1-266973.img.xz FreeBSD-14.0-STABLE-arm-armv7-GENERICSD-20231216-2ef9079ece5a-266002.img.xz FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20231216-9986fd59d855-256898.img.xz from the http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/?C=M&O=D area are that way. >> On 18 Dec 2023, at 20:44, Mark Millard <marklmi@yahoo.com> wrote: >> >> On Dec 18, 2023, at 10:22, Harry <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 >> >> reports (back in mid-2021): >> >> QUOTE >> author Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 18:27:14 +0000 >> committer Emmanuel Vadot <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