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. 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. > 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. -- 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
