Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images

> 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 <[email protected]> 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 <[email protected]> <[email protected]>
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