Hi Christopher, On Thursday, 31 August 2023 15:54:49 CEST Christopher Obbard wrote: > Sorry, our mails collided and I didn't see your previous reply.
Ha! I thought about sending you a private mail about that, but chose not to as they weren't conflicting. > 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: > 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. Thanks! Then it looks like I'm closer to understanding then I initially thought. It gives a 405 since yesterday, but I have been studying https://opensource.rock-chips.com/wiki_Boot_option > 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 AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to me that all that's needed is to "dot the i's" and the right people pushing the right 'buttons' (in the right sequence). AFAIC we can wait for that to happen. The situation is different and therefor long(er) term when it comes to TF-A for rk3588 based devices. I'd like to see support for that in Debian 'eventually' too, but strictly speaking that's not the goal of this bug report. The tricky thing is TPL/DRAM training. > 2) package rkbin for Debian in non-free-firmware (I will happily do that) Thanks :-) AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free- firmware and *IF* that's allowed in 'main'. If not, what then? Create an u-boot-nff package, with (exact?) the same contents as u-boot, but just in a different archive area? So that it can then be combined to create an u-boot-rockchip-nff package (in n-f-f)? > 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 :-)) My goal is to have all the parts *in* Debian as packages, so that I don't need to run a script to get/build u-boot for rk356x devices, but can just do `apt-get install <u-boot-for-rk356x>` So the image-building is just used to build/'assemble' the image ;-) > > https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next Just like the goal of that branch is to 'disappear' as all the needed parts have (then) become part of the official Debian kernel. We're not there yet, but that is my goal (for the Trixie release). Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
