On Tue, 23 Jan 2024 at 18:02, Bjorn Andersson <quic_bjorande@xxxxxxxxxxx> wrote: > > 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. Yes, up to some point. Because then DT gets incorporated into U-Boot... > 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. -- With best wishes Dmitry
