Hi Diederik, Sorry, our mails collided and I didn't see your previous reply.
On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote: > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote: > > This is the case for some other devices (e.g. rk3588) currently where there > > is support in U-Boot mainline but there is no arm-trusted-firmware support > > _or_ DDR bringup in U-Boot as yet. > > I do follow the linux-rockchip ML and it looks like kernel 6.6 is getting > rather interesting for rk3588 support. > I'm less 'in the loop' wrt rk3588 on u-boot and TF-A although I did post this: > https://forum.pine64.org/showthread.php?tid=14432&pid=117094#pid117094 There are a few open pull requests from Rockchip to add support but it is likely to take a while to be merged. > I do expect for TF-A support to land upstream for rk3588 (eventually), but do > you know (or suspect) that DRAM init will be open sourced too? I am not entirely sure of Rockchip's plans here. I have added Kever to the thread who can hopefully suggest when DRAM init code and TF-A support for various Rockchip processors will be submitted to mainline? > Note that I don't _fully_ understand these things, so if what I'm saying > doesn't make any sense, feel free to point that out :-) So far so good ;-). The only clarification I would like to make is the DDR init code is standalone, part of the TPL and is not anything to do with TF-A. It really is the first-stage boot code that runs after the maskrom. We could use Rockchip's closed implementation of that OR U-Boot's implementation, it's only real job is to train the DDR and handoff to U-Boot SPL. > > It'd be great to get Debian running on some of this more recent Rockchip > > hardware > > I'm currently working on that. Although it's initially for Quartz64 Model A+B > and PineTab2 (all rk3566) devices, I don't see why it wouldn't be usable for > rk3588 devices too as (long as) they're all arm64. > > AFAICT (now), I can just make 1 image as the only differentiator would be the > specific u-boot binary that needs to be put in place and I can just make an > instruction to `dd` the right u-boot binary onto sector 64 of the image file. > > Thus https://github.com/Kwiboo/u-boot-build/#flashing with `/dev/mmcblk0` > replaced by my image file. To build U-Boot in Debian for these "new" targets we'd need to: 1) build and distribute U-Boot for these "new" targets without the TPL/TF-A 2) package rkbin for Debian in non-free-firmware (I will happily do that) 3) have some scripts to collate the various bits into proper images (that probably should go inside the image-building tool rather than in a Debian package like flash-kernel, since it will be hopefully obsolete one day :-)) > > https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next is the > kernel I (currently) use, which is based (and periodically rebased up) on the > Debian kernel (with the intend to 'upstream' it to Debian's kernel when > that's > appropriate). Great! I am interested in bringing up more of these boards in Debian too. I have some custom Debos recipes to build some images for these boards, but the recipes really aren't yet ready to go anywhere until we get kernel and bootloader sorted out. Thanks! Chris
