Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images
Date: Sat, 16 Dec 2023 03:30:21 UTC
> From: Emmanuel Vadot <manu_at_bidouilliste.com> > Date: Fri, 15 Dec 2023 15:56:40 UTC > > Hi, > > On Fri, 15 Dec 2023 12:06:02 +0100 > Harry <freebsd@omnilan.de> wrote: > >> On 10/12/23 18:44, Emmanuel Vadot wrote: >> >> can this be merged to 14-STABLE >> >> /sys/dev/iicbus/pmic/rockchip/rk8xx_clocks.c >> >> this seems to cause a panic >> >> clkidef.name = (nclks = 2) ? clknames[0] : "clk32kout1"; >> >> >> > It's a bit too late tbh, also I don't consider rk356x stable even in >> > 15-CURRENT, so this will be merged in stable/14 at some point but for >> > now if you want to run on rk356x please use 15-CURRENT. >> >> >> Hi Emmanuel, >> >> thanks for your great FreeBSD contributions! Highly appreciate the >> Porting-FreeBSD-to-a-new-ARM-Board publication too! > > Thanks. > >> Quick question - I'm new to arm/u-boot, but some FreeBSD src & ports >> experience here... >> >> In u-boot-2023.10 there's (master/)configs/nanopi-r5c-rk3568_defconfig >> added. >> Simply copy'n'paste the ports/sysutils/u-boot-nanopi-r4s to >> u-boot-nanopi-r5c isn't enough... (after updating u-boot-master from >> 2023.07 to 2023.10, done that) >> >> I don't understand sysutils/atf-master resp. sysutils/atf-rk3399. >> Simply creating new rk3568 slave ports doesn't work since PLAT rk3568 >> isn't implemenmted upstream... I guess I would have to adjust >> sysutils/u-boot-nanopi-r5c to get rid of the AT-F dependency first... but > > Yes upstream TF-A doesn't have rk356x support right now so we have to > use the ones provided at https://github.com/rockchip-linux/rkbin > >> You mention running 15-CURRENT on rk356x >> >> How to boot? >> >> Would highly appreciate links - I'm currently trying to deploy >> FriendlyELEC R5C here - I could successfully start 14-stable, but just >> by try'n'error metgod, gluing lots of different loader blobs onto >> SDcard. I need to learn a lot, so I'm trying to do it a little bit >> smarter than try'n'error... >> >> >> Thanks in advance, >> >> -harry >> >> > > 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 > > Cheers, > > -- > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> Hary, I can see you are testing and setting up a build environment for the Nano Pi R5C SBC. Look at Sleep Walkers work over at https://personalBSD.org and Telegram Group t.me/personalbsd https://personalbsd.org/images/FreeBSD-aarch64-14.0-CURRENT-NanoPi-R5C-20230522.img.xz Give this image a test run on your hardware NanoPi r5c. Then read register settings and save. See what settings and values (ie binary blobs NOT LOADED ) exist in your kernel boot image. Then modify your own sources and build another new image again. Chat with SleepWalker and maybe get a working build environment? ExtroWerk user, was porting FreeBSD to a GeniaTech RK3566 SBC board. https://t.me/PersonalBSD/11146 I see ExtroWerk was asking me to build an image for him. https://extrowerk.com/2023-10-30/Geniatech-XPI-3566-ZERO-SBC.html https://github.com/extrowerk Yes, Harry, I want to see you successfully build a FreeBSD kernel from source to run and execute on the NanoPi r5c single board computer. Ie Get all the "little ducks in a row." like binary blobs, makefiles, KERNCONF=GENERIC-NANOPIR5C . Best of luck to you, Harry. -- Fred Finster GhostBSD-Arm64.blogspot.com t.me/ghostbsd Telegram Channel GhostBSD.org website