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

[Dragan Simic <dsimic@manjaro.org>]

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.