From nobody Mon Dec 18 22:15: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 4SvDfp4vB0z54B5F for ; Mon, 18 Dec 2023 22:15:46 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SvDfn5WX1z4Kg5 for ; Mon, 18 Dec 2023 22:15:45 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 3BIMFZVi042998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 00:15:35 +0200 (EET) (envelope-from titus@edc.ro) Received: from [192.168.1.5] (79-114-40-228.rdsnet.ro [79.114.40.228] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 3BIMFW7D059333 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 00:15:33 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1702937733; bh=7vc/Xhe/ZGMv2I0OAsWzZ3PnCp4TgnF/h8VQv5mtOS8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=4L/CTPjwCkFDVwJTK88ABudAoBDThHNgN8IjMauZQy3mPmD6e/GTndboHV5xFUiXp b41TPzDGbov0fy7CILKYB01fUXdiKkez/V30Ed/E5nWx9+F8pNNwquSy/kioLxOLnU u5Q0GHy5J/Z8kHdfuaYSLbBhVyY4po9AysaYS7YA= From: titus Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C" 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 13.4 \(3608.120.23.2.7\)) Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] Date: Tue, 19 Dec 2023 00:15:34 +0200 In-Reply-To: <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> Cc: Harry , freebsd-arm To: Mark Millard References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro 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:8708, ipnet:86.120.0.0/13, country:RO] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SvDfn5WX1z4Kg5 --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 wrote: >=20 > On Dec 18, 2023, at 10:22, Harry > wrote: >>=20 >> 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=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf >>> export >>> ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin >>=20 >> 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=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync >> dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync >> 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. >>=20 >> What am I missung after dd'ing? >> Any hints appreciated! >=20 > FYI: ubldr is no longer part of the standard/typical way of booting = these days, > at least for armv7 (and aarch64): >=20 > = https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=3D0d6e5081= eb00 = >=20 > reports (back in mid-2021): >=20 > QUOTE > author Emmanuel Vadot > = 2021-05-11 18:27:14 +0000 > committer Emmanuel Vadot > = 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=3Dy in the = Fragment as it's needed to have the cache flushed for us when loader.efi = is started. > END QUOTE >=20 > Any documentation indicating sny ubldr involvement likely predates = that > change. >=20 >> -harry >>=20 >> 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... >>=20 >> >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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> 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=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf
export
ROCKCHIP_TPL=3D/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=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync
dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync
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= =3D0d6e5081eb00

reports (back = in mid-2021):

QUOTEauthor 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=3Dy 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>



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

= --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C--