On Wed, Apr 04, 2018 at 07:41:25AM -0500, Rob Herring wrote: > On Wed, Apr 4, 2018 at 5:30 AM, David Gibson > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Apr 03, 2018 at 01:49:46PM -0500, Rob Herring wrote: > >> On Mon, Apr 2, 2018 at 4:15 AM, Yuan, Linyu (NSB - CN/Shanghai) > >> <linyu.yuan@xxxxxxxxxxxxxxx> wrote: > >> > Hi all, > >> > > >> > When use dtc to compile dtb to dts, always lost integer format, > >> > For example, clock frequency, normally it should not print as hexadecimal, other issue from my view is integer lower than 255, normally should not print as hexadecimal too. > >> > > >> > Any good method to solve this issue ? > >> > >> No. The dtb format doesn't have type information, nor formatting > >> information. > > > > Right. In the dtb format the properties are just bytestrings. Like > > any decompilation process the results won't exactly match the original > > input. > > > >> Adding this is certainly desired, > > > > That's not really true. We're looking at adding temporary type > > information so that -I dts -O dts will give a better approximation to > > the input, but that's just types, not formatting down to the level of > > decimal vs. hex representation. I don't think there's any reason to > > do that or any plans to do so. > > Right, I meant type info is desired. > > > Plus that's talking about adding type information as a temporary, and > > possibly translating it into a yaml based format. Actually putting > > the type information into the dtb is a different matter entirely. > > Yep. > > >> but no one has come up > >> with a way to add the information in a backwards compatible way. > > > > Adding type information to the dtb really doesn't make sense, the > > format simply isn't designed for it. Adding type information > > essentially means creating an entirely new device information format. > > If you wanted to add information in band then you are right. However, > we could possibly add an OOB table to the dtb of property offsets and > type information. Wouldn't be pretty, but would be backwards > compatible. Sure, there's a bunch of ways it could be encoded, but is it worth doing so. If it's just there as essentially debug information, then are there really enough cases where that would be useful, and you don't have access to the dts, and the dtb won't have been stripped for space anyway? If the OS client is actually expected to parse and make use of the type information, then you're making a fundamental change to the format and you'd be better off with something else that incorporates the data naturally (UBJSON or something, maybe). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
