On Fri 21 Oct 17:07 PDT 2016, Stephen Boyd wrote: > On 10/21, Arnd Bergmann wrote: > > On Friday, October 21, 2016 1:04:09 PM CEST Stephen Boyd wrote: > > > I'm pushing the bootloader team to do the deep scan of the dtb to > > > match up board compatible and pmic compatible strings so that we > > > don't have to keep these numbers around. Basically put what > > > dtbtool is doing into the bootloader so we don't have to post > > > process the dtb anymore. We're currently discussing how to > > > implement it and how to move the internal codebase to the new > > > scheme. > > > > > > At least for 96boards I think we can update the lk bootloaders on > > > there to adopt this code. For other platforms like nexus though I > > > don't see a way we can update those bootloaders, and those > > > bootloaders require these properties exist in the dtbs, so we > > > should just throw the numbers into the dts files there and be > > > done with post processing. For bootloaders that require the QCDT > > > header, we'll have to keep running dtbtool there to generate the > > > header. Having the ids in the dts file or not doesn't really > > > matter there. > > > > I think part of the problem here is the way that the bootloader > > expects multiple dtbs to be appended to the kernel binary, and > > then pick one of them based on its contents. That doesn't really > > change at all when changing the parser from looking at nonstandard > > properties to looking at the compatible strings. > > > > It still breaks the last-resort workaround for broken bootloaders > > that we have in the form of appending the DT to the kernel > > with CONFIG_ARM_APPENDED_DTB. > > That can be "fixed" by having the bootloader use the single > appended DTB regardless of the properties existing or not. That's > a few lines of code to count the number of appended blobs and > then special case there being one. > This is already the case on at least 8974; if the ids are present they must be the right ones, otherwise it will just pick the dtb that's there. [..] > > Ideally this is done > > by storing all files on a file system that can also be mounted > > to /boot, but there are probably other options that work equally well. > > > > Some bootloaders *cough* LK *cough* aren't always able to read > filesystems. All they can do is read raw data from partitions. > That's probably why nobody has thought about reading files from > some place like /boot (which doesn't even exist in android) > because these bootloaders don't have filesystem support. > Well, your version of LK has ext2 support - just not in the code path that loads the kernel. But that's still only a different way to represent what we today have in QCDT, it doesn't change anything related to these ids. Regards, Bjorn -- 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
