On Tue, Jan 23, 2024 at 08:23:37AM +0200, 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: [..] > > 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. This is only a problem because we think the DeviceTree is a part of the kernel. If we actually tied the DeviceTree to the firmware - as it was intended - different firmware versions could come with different memory map. The one exception would be any remoteproc/pil firmware that is not relocatable, as these are distributed together with the OS (in some form) and not the boot/security/etc firmware. Regards, Bjorn
