07:37 <naoki> oh I didn't notice collabora's TF-A for rk3588... then, how about TF-A for rk356x?

07:37 <naoki> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952 just waiting for code cleanup?

07:39 <naoki> btw it seems collabora's rkbin repo is a little older than https://github.com/rockchip-linux/rkbin

07:39 <naoki> (I don't know which binary is the best)

09:12 <diederik> probably only waiting for a 'Done' response which will mark the issue as solved

09:13 <diederik> and I guess it also needs a Maintainer Review

13:18 <diederik> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952 ("feat(rockchip): add RK3566/RK3568 Socs support") has been merged \o/

13:25 <qschulz> \o/ fingers crossed for rk3588 :)

13:32 <diederik> there was a lot of activity wrt rk3568 in the last 2 weeks, so maybe they'll do rk3588 next (it now has a merge conflict, I guess due to the rk3566 merge)

15:07 <sigmaris> on that topic, anyone know why Linux (via /proc/cpuinfo) thinks the RK3588 has no ARMv8 crypto extensions when I boot with the opensource TF-A?

15:07 <sigmaris> whereas when booted with the rkbin TF-A it has support for them

15:09 <sigmaris> I was looking if there was some CPU feature register that could be masked or intercepted by EL3 firmware, but didn't get very far

15:09 <sigmaris> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840?tab=comments

16:05 <rah> I'm a bit confused by the presence of binary blobs for RK3399 DDR training in the (or at least Arbian's) rkbin repository: https://github.com/armbian/rkbin/tree/master/rk33

16:06 <rah> I was under the impression that the RK3399 didn't need binary blobs for DDR initialisation, is that really the case?

16:07 <rah> does u-boot have free code for RK3399 DDR initialisation?

16:09 <sigmaris> for RK3399, yes

16:11 <rah> sigmaris: any idea where that code is?

16:12 <sigmaris> in here mostly: https://github.com/u-boot/u-boot/blob/master/drivers/ram/rockchip/sdram_rk3399.c

16:13 <rah> great, thanks

16:15 <rah> that's wierd though, "(C) Copyright 2016-2017 Rockchip Inc."

16:16 <rah> they release blobs for DDR initialisation with no source but then add DDR initialisation to u-boot, via coreboot

16:17 <rah> anyone know how that came about?

16:17 <rah> and why they don't do it for other chips?

16:31 <sigmaris> I don't know as I wasn't involved. My guess, though, would be due to Chromium's upstream-first philosophy, Google encouraged Rockchip to open and upstream as much code as possible, as a condition of partnering with them to produce Chromebooks based on RK3399. Hence support appearing in Coreboot first as Chromebooks use it.

16:52 <rah> :-/

16:53 <rah> that would make sense, there's a google copyright notice in e.g. https://github.com/u-boot/u-boot/blob/master/drivers/ram/rockchip/sdram_rk3066.c

16:54 <rah> unfortunately I guess that means it's unlikely we'll see free DDR initialisation for any particular chip unless Google is making Chromebooks with it

16:59 <CounterPillow> Correct, Rockchip is likely to not even be allowed to disclose sources for the DDR init due to the terms they've licensed the DDR hardware from

17:00 <CounterPillow> thankfully, DDR init is just shoving magic values into magic registers even when you have the source, so it's not like we're missing out on much. The binaries are fairly small, run once at boot, and can be disassembled to see what registers they touch

17:02 <rah> I'd love to believe that reverse engineering DDR initialisation would be a small job but unfortunately I'm highly skeptical of that :-)

17:02 <rah> "I'll just RE the DDR initialisation on the RK3376.. shouldn't take long"

17:02 <CounterPillow> I didn't say it's a small job, I said it's a small binary and you can easily see which registers it writes, doesn't mean you understand what the values mean

17:04 <rah> same difference: the RK3399 is unlikely to be unseated as the best that can be supported with entirely free software

17:04 <rah> alas

17:05 <CounterPillow> You're probably one of the types that would be completely okay with the binary if it was stored in read-only-memory, like the FSF is.

17:07 <rah> that's a bit disingenuous; I'm sure the FSF is not "okay" with proprietary binaries, regardless of where they're stored

17:08 <rah> like myself

17:08 <CounterPillow> They are

17:08 <CounterPillow> it's in their official certified free guidelines.

17:08 <CounterPillow> Also, RK3399 has maskrom on ROM, which is a binary.

17:08 <CounterPillow> So basically you seemingly already are okay with this?

17:09 <rah> I'd be very surprised if they said that they are "okay" with binaries in ROM

17:10 <rah> they draw a line for RYF hardware but just because they certify hardware for their programme, doesn't mean they're necessarily "okay" with it containing binaries in ROM for which the source is unavailable

17:11 <rah> I'm not "okay" with proprietary maskrom in any chips

17:12 <rah> can you really imagine Stallman going around telling companies that make hardware with ROM binaries "what you're doing is okay"?

17:13 <rah> I can't

17:13 <rah> what I imagine he'd do is try to convinced them to release the source code for the ROM binaries

17:15 <CounterPillow> I can't imagine rms doing anything useful or effective in general, no.

17:16 <rah> O_o

17:16 <rah> you realise rms wrote gcc?

17:18 <CounterPillow> sure, he wrote a compiler decades ago, that's not what gcc is today.

17:19 <rah> wow

17:20 <rah> you're being really disrespectful

17:23 <psydroid2> what is the situation with RK3588? are there still blobs for DDR init?

18:30 <CounterPillow> yes