Hi Diederik,
On Thu, 2023-08-31 at 17:46 +0100, Christopher Obbard wrote:
> 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.
Sorry, I was wrong. We set BL31 (which is TF-A from rkbin) and ROCKCHIP_TPL
(which is TPL from rkbin)
e.g:
- export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.27.elf
- export
ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin
That was misleading. Apologies.
> > 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?
That was wrong. I believe we can use TF-A from rkbin and combine things into an
image later.
>
> > 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.
That was wrong. I believe we can use TF-A from rkbin and combine things into an
image later.
>
> > > 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
Thanks!
Chris
