u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566]

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!

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

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