Message-ID: <20241022165413.2156-1-shimrrashai@gmail.com>
Date: Tue, 22 Oct 2024 11:53:46 -0500
From: Shimrra Shai <shimrrashai@...il.com>
To: linux-kernel@...r.kernel.org
Cc: linux-rockchip@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Thinking about firmware and hardware description for latest Rockchip platforms

Hi.

I was writing this because most of my attempts to contribute to this
site (also with older email shimmyshai00@...il.com) have been
motivated by the fact that newer fast ARM SoCs like the Rockchip
RK3588 and perhaps now the even better Snapdragon X Elite are potent
enough to be used as at least a low- to moderate-grade desktop
machine. And because of that, my ideal has been to try and help
coordinate the development of both the Linux kernel and a suitable
firmware package to make it possible for a user to load a Linux
distribution ideally from a USB stick in the "normal" way that is as
easy to do as on a regular x86 PC, and not to be merely constrained
to vendor-provided images.

Particularly, in regard to the Rockchip RK3588, I think it really
cool how far the support has progressed and that's very good news on
that front, but one thing I'm starting to think more about (and have
thought of before) is the firmware/boot loader situation, in
particular with regard to the hardware description given to the
kernel.

As you know, the kernel currently uses a separately-provided Device
Tree Blob (DTB) file for configuration, and the kernel source code
basically has to know every board and device that exists. From my
reading of discussions on this topic, this is often pointed out as
being due to the fact that ideally one would want to have "good
firmware" on a device that delivers a clean hardware description, and
typically one deals with "bad" vendor-provided firmware with bad
description methods, while the kernel DTBs provide a good idea of what
such a hypothetical good firmware "should" provide. However, because
of the need to have a specific device tree blob file for each board
along with the kernel, one cannot just use the typical USB stick and
install process at least with the commonly used bootloaders assuming
a PC architecture.

But obviously, that equation changes when you DO have good firmware.
And that's the rub. Because this puts me in a situation that it
doesn't seem hardly ever is discussed, probably because it so rarely
exists - having simultaneous open-source control over the development
of both firmware AND kernel. Namely, I've also been helping maintain a
package for some of the RK3588 boards using the EDK2 Tianocore UEFI
framework, which can be found here:

https://github.com/edk2-porting/edk2-rk3588

This type of firmware seems close to ideal; but it puts one in now an
awkward kind of situation because of the HW description process
mentioned. Namely, this firmware has the option to pass either a
Device Tree Blob (DTB) to the kernel, OR use ACPI configuration as is
used on x86 PC machines.

Now it would seem, then, that the most straightforward approach would
be to simply bake a DTB in for the hardware, but the problem is that
it appears that DTBs are continually revised in kernel development
even for long-supported chips (e.g. the RK3568 and earlier). And that
creates the possibility of breaking backward compatibility, so it
seems there's a chance that if one were to just include a mainline
.DTB into a firmware package there is no guarantee it will remain
compatible forever with every future kernel version. And having a
user have to upgrade firmwares all the time just because new kernels
came out also seems kind of to defeat the purpose of having a
firmware-provided HW description.

And to this I can think only of two options. The first would be to
have a "political change" on the part of the kernel developer team to
agree to "freeze" in some part the DTBs for these platforms (I also
seek to work on firmwares for the earlier RK3568 platform and perhaps
also other RK35xx variants) so that they remain continuously
backwards-compatible indefinitely. But I am not sure that would be
something that'd go over well here.

So that gives the alternative option, which is to do like on x86
systems and start to add some form of ACPI support to the entire
Rockchip driver stack, because the ACPI tables are maintained on the
firmware side. However, it likely will still require a fair bit of
back-and-forth here to do the initial establishment of a full
"standard" of such tables for this kind of setup viz. my discussions
in an early attempt at this on the I2C subsystem, e.g.:

https://lore.kernel.org/lkml/20240321173447.15660-1-shimmyshai00@gmail.com/
https://lore.kernel.org/linux-arm-kernel/20240414000355.10984-1-shimmyshai00@gmail.com/T/

but I never really got through to fleshing it all out, though now I'd
be definitely more interested in reviving the project if that's what
you would be interested in.

So I want to ask you: how should one go about this, or is it not
possible at all?

Thanks,
Shimrra SHAI.

Powered by blists - more mailing lists