RE: integer lost format from dtb to dts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




> -----Original Message-----
> From: Rob Herring [mailto:robh@xxxxxxxxxx]
> Sent: Wednesday, April 04, 2018 8:41 PM
> To: David Gibson
> Cc: Yuan, Linyu (NSB - CN/Shanghai); devicetree-spec@xxxxxxxxxxxxxxx; Jon
> Loeliger; Devicetree Compiler
> Subject: Re: integer lost format from dtb to dts
> 
> 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.
I agree.
> 
> Rob
��.n��������+%������w��{.n����z�{��z��^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux