On 1/25/24 07:05, Trilok Soni wrote:
On 1/22/2024 10:23 PM, Dmitry Baryshkov wrote:
On Tue, 23 Jan 2024 at 04:58, Trilok Soni <quic_tsoni@xxxxxxxxxxx> wrote:
On 1/22/2024 12:02 PM, Bjorn Andersson wrote:
On Mon, Jan 22, 2024 at 08:45:51AM -0500, Brian Masney wrote:
Hi Dmitry,
On Fri, Jan 19, 2024 at 10:35:43PM +0200, Dmitry Baryshkov wrote:
This kind of change sets a very bad precedent. This way old kernels
become incompatible with the updated firmware. For me it looks like
Linux kernel suddenly being unable to boot after the BIOS upgrade.
Generally memory map updates should be disallowed after the board hits
the production and the DT is published and merged. There can be other
users of DT. BSD systems, U-Boot. We spend sensible efforts in making
sure that DT is an ABI: newer kernel remain compatible with older DT
files. We expect the same kind of efforts from device manufacturers.
I think unless there is a good reason, the memory map update should be
reverted on the Qualcomm side as a breaking change.
If this kind of update is absolutely necessary, it might be better to
define a new set of board files utilising the new memory map, marking
existing DT files as legacy.
This is on a development board that's not in production yet, so
personally I think this change is fine. It's in all of our best
interests to have SoC vendors push their code upstream early, even if
it means that later on we need to make memory map changes like this.
The problem I have with the patch is that I don't know which precedence
it sets, because the commit message indicates that we have a new
firmware version, while Eric's report lacks this information.
As long as everyone with access to the hardware agrees that breaking
backwards compatibility is the right thing to do, I'm not against it.
But then again, if the support is under active development, why would
anyone run a stable@ kernel on this thing?
Or are you asking for it to be included in v6.8-rc, so that you guys
have a "stable" tree to do further development (with this patch) on?
I agree with what Bjorn is mentioning here. Why we are freezing the kernel version
here/commit of it here. Memory map can change during the active development
and this target is under active development.
New board file approach doesn't work - since how do you select the new
board file? Both old and new board file will still point to the same
platform type and version.
The developer knows which firmware version is used. So the user can
select the correct DT file manually. There is no need to pack all
files together.
Also it might be nice to bump the platform version when performing
such drastic changes.
Well - we can do that and pick the DT we want, but please understand
that as a community we don't allow such memory map changes it will
be going to stop SOC vendors from contributing early for the ARM platforms,
which is a regression in my view.
This will also make SOC vendors to move the memory maps out of the
DT to some bootloader code which we won't be able to access due
to the location on their websites and versions. We may not want to
be in such situation as well.
We also saw recently that IOT SOCs which are similar to in some
sense Mobile SOCs are having the different map. The same almost
same SOCs used in the different product segments like Chrome
and Mobile and IOT can have different memory map as well. The good
part there was that they had different soc-id and it will be easier
to differentiate them.
Having device-specific memory maps is also fine.
As Brian M mentioned earlier, we want soc vendors to submit the support
for their SOCs and platforms on top it as early as possible and it means
such memory map changes will continue. Even memory map changes
continue even few months after the commercial s/w release in certain cases
due to critical bugs were found in some usecases which warrants the changes.
So, can one handle such changes? Are we going to publish a list of
kernels to be used with the corresponding firmware images? Then what
if the developer wants to update just the kernel? Just to get this or
that non-platform-related feature. Or vice versa, what if the user is
stuck with an older kernel because some driver gets broken in the main
branch (which unfortunately happens sometimes) Or what if the memory
map patch gets backported via the AUTOSEL process?
Unlike the Qualcomm binary distributions, the firmware and the kernel
version are no longer connected.
That's why I keep on saying that memory map is an ABI. If it gets
changed, it is a completely new, incompatible platform.
I don't think that in-development platform should be treated it such. Like
other ABIs we can mark the board as experimental before they get frozen.
I see ABIs in the kernel which starts w/ the EXPERIMENTAL before they
get stable state, so why not these platforms? I don't want to discourage
SOC vendor developers from submitting their platforms.
Trilok, Dmitry,
I believe the best solution for in-dev platforms would be to introduce
a concept of "staging" dt-bindings and devicetrees, so that both
developers and users will expect that things may break, as they are still
being figured out. That way, we can have the cake and eat it too.
Konrad
