Thinking about firmware and hardware description for latest Rockchip platforms

Thinking about firmware and hardware description for latest Rockchip platforms

[Shimrra Shai]

Hi.

I was writing this because most of my attempts to contribute to this
site (also with older email shimmyshai00@gmail.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.

Re: Thinking about firmware and hardware description for latest Rockchip platforms

[Jonas Karlman]

Hi,

On 2024-10-22 18:53, Shimrra Shai wrote:

[snip]

> 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.

U-Boot now use latest Linux device tree for all RK35xx boards (and older
Rockchip aarch64 SoCs). With the EFI feature of U-Boot you can already
boot any distro raw aarch64 image, as long as the kernel is new enough.

E.g. for RK356x you can use latest debian, ubuntu, opensuse and freebsd
aarch64 raw/uefi image and boot into the installer from a USB stick.

However, there is no display support in U-Boot for RK35xx so you will
have to use serial console to do the installation, and be sure to leave
around 16 MiB of space on SD-card/eMMC before first partition to not
overwrite any existing bootloader.

Btw, regarding the EDK2 RK35xx port, please consider to update to use
mainline U-Boot SPL and not a vendor SPL blob, you could also benefit
from using binman to generate the final firmware image, bundling the
ddr init blob, U-Boot SPL and EDK2 in a firmware package.

Regards,
Jonas

[snip]

Re: Thinking about firmware and hardware description for latest Rockchip platforms

[Dragan Simic]

Hello Shimrra,

On 2024-10-22 18:53, Shimrra Shai wrote:
> 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.

As you noted already, the DT definitions are fixed and improved
all the time, which is actually great.  However, the backward
compatibility is ensured, because newer kernels are guaranteed
to work with older DTs, which doesn't mean that the board DTs
provided through firmware should become frozen in any way, as
explained further below.

> 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.

Freezing anything would be simply wrong.  It might look good from
the perspective of having something "stable", which is similar to
how x86_64 firmware works on PC motheboards, but the continual
bugfixes and improvements are actually extremely good, because
they prevent various ARM boards from effectively becoming abandoned,
which is unfortunately rather usual with x86_64 motherboards that
become so "stable" that some nasty firmware bugs are never fixed
and their users are left high and dry.

> 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.:

So, there would be never any updates or fixes to the ACPI tables?
That goes back to the above-mentioned abandonware.

Re: Re: Thinking about firmware and hardware description for latest Rockchip platforms

[Shimrra Shai]

On 2024-10-23  2:46, Dragan Simic wrote:
> As you noted already, the DT definitions are fixed and improved
> all the time, which is actually great.  However, the backward
> compatibility is ensured, because newer kernels are guaranteed
> to work with older DTs, which doesn't mean that the board DTs
> provided through firmware should become frozen in any way, as
> explained further below.

Thanks - my concern was about backward compatibility so that if some
user did not upgrade their FW but then tried to install a *newer*
Linux found things mysteriously breaking due to that some DT revision
in code had broken the backwards compatibility. Of course that could
also be considered a bug, even while new FWs could/would still be
rolled out.

> Freezing anything would be simply wrong.  It might look good from
> the perspective of having something "stable", which is similar to
> how x86_64 firmware works on PC motheboards, but the continual
> bugfixes and improvements are actually extremely good, because
> they prevent various ARM boards from effectively becoming abandoned,
> which is unfortunately rather usual with x86_64 motherboards that
> become so "stable" that some nasty firmware bugs are never fixed
> and their users are left high and dry.

Yes, I'm not against new FW upgrades, just the idea of users *having*
to upgrade their FW simply because a new kernel came out when nothing
like that is typical on x86 or at least in my experience using it over
many years).

Note that the situation of a DT upgrade that is obtained by FW
upgrade breaking older kernels, i.e. broken *forward* compatibility of
the older kernel with later DT, isn't so much a problem because we can
simply keep the older DT in the FW when issuing the FW upgrade, as I
believe there is a facility for supporting multiple, versioned DTs in
that UEFI package [and if not, it could easily be added]. It's the
backward compatibility that is my issue because reflashing FW, even
though not too hard on these boards, is perhaps more heady for your
average PC or smartphone user.

That is to say, I'm imagining the case of bundled computers
pre-shipped with the loaded FW and OS installed as usual and someone
says "hey they got a new Ubuntu [or whatever], let's install it!" BAM,
devices stop working because they did not upgrade FW, forcing an FW
upgrade in a way an x86 user would not be similarly forced. Though of
course, that could then be reasonably called a regression bug (as it
would appear from the user's perspective, not knowing about the FW
change), if backwards compatibility is indeed already a long-standing
policy (and is really what I was after with that "freeze" suggestion
even if it itself would not be the way to get it).

 - Shimrra Shai

Re: Thinking about firmware and hardware description for latest Rockchip platforms

[Dragan Simic]

Hello Shimrra,

On 2024-10-23 19:35, Shimrra Shai wrote:
> On 2024-10-23  2:46, Dragan Simic wrote:
>> As you noted already, the DT definitions are fixed and improved
>> all the time, which is actually great.  However, the backward
>> compatibility is ensured, because newer kernels are guaranteed
>> to work with older DTs, which doesn't mean that the board DTs
>> provided through firmware should become frozen in any way, as
>> explained further below.
> 
> Thanks - my concern was about backward compatibility so that if some
> user did not upgrade their FW but then tried to install a *newer*
> Linux found things mysteriously breaking due to that some DT revision
> in code had broken the backwards compatibility. Of course that could
> also be considered a bug, even while new FWs could/would still be
> rolled out.

That's a valid concern, but such scenarios shouldn't happen by
design, unless there's some bug, of course.

>> Freezing anything would be simply wrong.  It might look good from
>> the perspective of having something "stable", which is similar to
>> how x86_64 firmware works on PC motheboards, but the continual
>> bugfixes and improvements are actually extremely good, because
>> they prevent various ARM boards from effectively becoming abandoned,
>> which is unfortunately rather usual with x86_64 motherboards that
>> become so "stable" that some nasty firmware bugs are never fixed
>> and their users are left high and dry.
> 
> Yes, I'm not against new FW upgrades, just the idea of users *having*
> to upgrade their FW simply because a new kernel came out when nothing
> like that is typical on x86 or at least in my experience using it over
> many years).

Yes, users don't _have_ to upgrade their firmware, as described
above in more detail, but they actually _should_ upgrade.  In fact,
they should be happy and eager to upgrade. :)

> Note that the situation of a DT upgrade that is obtained by FW
> upgrade breaking older kernels, i.e. broken *forward* compatibility of
> the older kernel with later DT, isn't so much a problem because we can
> simply keep the older DT in the FW when issuing the FW upgrade, as I
> believe there is a facility for supporting multiple, versioned DTs in
> that UEFI package [and if not, it could easily be added]. It's the
> backward compatibility that is my issue because reflashing FW, even
> though not too hard on these boards, is perhaps more heady for your
> average PC or smartphone user.

Hmm, I don't think that keeping older DTs around is a good idea.
Instead, we should simply document the required kernel version,
or even better, make some kind of a dependency between the firmware
version and the version of the kernel packages.  The latter is,
of course, a much more complex option, but also better.

For the record, please note that I have zero interest whatsoever
in any kind of "full-fat" UEFI firmware implementation.

> That is to say, I'm imagining the case of bundled computers
> pre-shipped with the loaded FW and OS installed as usual and someone
> says "hey they got a new Ubuntu [or whatever], let's install it!" BAM,
> devices stop working because they did not upgrade FW, forcing an FW
> upgrade in a way an x86 user would not be similarly forced. Though of
> course, that could then be reasonably called a regression bug (as it
> would appear from the user's perspective, not knowing about the FW
> change), if backwards compatibility is indeed already a long-standing
> policy (and is really what I was after with that "freeze" suggestion
> even if it itself would not be the way to get it).

Well, it's perfectly reasonable to expect the users to install
different Linux distributions, etc.  However, as already described
above, running a newer kernel version without updating the firmware
should never lead to such issues.

I think we should raise the awareness of the actual benefits coming
from the openness of firmware on various ARM boards, and the available
choice of _not_ having to use "full-fat" UEFI firmware, instead of
trying to make the whole thing be more like x86_64 UEFI firmware.