Hi Diederik, To stay on-topic here, I also have a Pine64 Quartz64 model A - I'd be happy to be added as a board maintainer in Debian.
I didn't yet manage to build U-Boot mainline for it, see https://lists.denx.de/pipermail/u-boot/2023-August/526625.html I still owe a reply on that topic to Jonas' suggestions, I will hope to get to that next week. On Thu, 2023-08-31 at 17:50 +0200, Diederik de Haas 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. No problem, on-list is probably best anyway so it is archived ;-) > > 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 Yeah, I also got stuck with the vendor documentation and eventually just *had a go* and eventually manged to get things working ;-). > > 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. I'm not entirely sure about that. In any case, for the rk3588 in U-Boot mainline we just boot with vendor TPL & leave out TF-A entirely ;-). Maybe that could even be possible with this board, to just run without TF-A ? If you want to do that, see how we do it for rk3588 here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588-rock5b/.gitlab-ci.yml I don't know if it will work for Quartz64, but please try it and see. My fingers are crossed. > 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. Right, see my comment above. Maybe we can just ignore TF-A on these devices *for now* until upstream is merged? > The tricky thing is TPL/DRAM training. Right, that is common between all of these "modern" devices, so I am really trying to not derail this into a rk3588 support thread, but that should be in a separate bug report. In theory, if we skip TF-A, the only thing we need is TPL from rkbin for both boards. > > 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 ;-) Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot for these devices *without* any closed bits and ship rkbin in non-free-firmware in non-free-firmware. We need to simply combine those into an image file to flash to the device, that could be done in flash-kernel (or as my original suggestion in a script in the image building process but I am not fussy). So that script would "just" combine rkbin and the "open" parts of u-boot-rockchip into idbloader.img and u-boot.itb. And once the DDR init and AT-F bits are merged into mainline, we can remove those bits from flash-kernel and u-boot-rockchip package can be extended to use the mainline code. @Vagrant, does that sound like a solution which you'd be interested in? I could try to carve out some time to post a patch for u-boot, flash-kernel and package rkbin if so ;-). > > > > 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). Fingers crossed! Thanks, Chris
