Quoting Bjorn Andersson (2018-03-07 11:02:49) > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > As such I think you should just describe only the 0x85fe0000 + 0x20000 > > > region here and to support the dynamic aspect of this from a system > > > point of view you can have the boot loader read the information at > > > 0xc3f000c and adjust the reserved memory. (Or just keep the step of > > > manually update the dts without caring about the indirection) > > > > > It would be incorrect and very board specific to just use the 0x85fe000 > > as the address. It is not how the SoC defines the location. Upon request > > earlier, this memory location was added in DT and the location is > > typical reference platform usage only. > > > > The problem is that as the db resides in a chunk of memory in the middle > of what Linux considers System RAM the DTS must specify this region as > reserved. Which means that as you, like described above, update the > dictionary something (in your scheme a person) has to update the > reserved-memory region as well. > > That's why I'm proposing that the appropriate implementation for this > is to have the boot loader to the dictionary part of this and Linux only > care about the actual reserved-memory region. This way you would still > implement the dictionary lookup on a system level, but the Linux > part no longer depend on a human updating the DTS to match the values of > the dictionary. Agreed. I thought SMEM had a similar design of a cookie in IMEM to indicate location and size because coordinating changes across all the various software images is a hard problem. But coordinating between linux and the linux bootloader shouldn't be as hard. > > > But if we stick with the approach of describing both these and hoping > that the values in the first region matches the second (or should we add > a sanity check in probe?). The memory reserve defined as 0xc3f000c + 8 > looks strange, is this system ram as well and what other things resides > in that same page? > Doesn't look like it could be RAM, the address is not very close to the other one so I would guess it's something like IMEM. And there are two 32-bit numbers to describe address and size? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
