On Thu, Oct 13, 2022 at 11:36 AM Quentin Kaiser <quentin.kaiser@xxxxxxxxxx> wrote: > > Hi, > > We identified a “regression” between dtc 1.6.0 and 1.6.1 introduced by commit 9d7888cbf19c2930992844e69a097dc71e5a7354. It's always good practice to Cc the author of the commit and quote the subject. > As part of a firmware extraction framework that we built and open sourced (https://unblob.org), we have integration test files making sure our changes do not modify the way we extract specific file types. > We do so by extracting integration test files and identifying changes using diff. Within this extraction framework, we have a handler that convert DTBs to DTS using the dtc command line tool. > > The test suite was failing on one of our colleague’s machine but not on ours, and we identified that the only difference was the DTC version (1.5.0 vs 1.6.1). > > You can reproduce it with the iMX6 Sabrelite DTB file available at https://github.com/FAlinux-SoftwareinLife/silfa/blob/master/OS/kernel/imx6q-sabrelite.dtb using this command: > > dtc -I dtb -O dts imx6q-sabrelite.dtb 2>/dev/null | grep min-voltage > > Here’s a diff showing the difference between the two generated DTS (one with 1.5.0, the other with 1.6.1): > > diff /tmp/1.5.0.dts /tmp/1.6.1.dts > 852c852 > < regulator-min-microvolt = <0xc3500>; > --- > > regulator-min-microvolt = "\0\f5"; > 859c859 > < min-voltage = <0xc3500>; > --- > > min-voltage = "\0\f5"; .dts output encoding from a dtb is a guess at best and is not reliable. Anything that looks like ascii is going to get output that way. That said, while a \0 at the start is a valid string in dts, it's probably not likely in practice and we should not decode the data as ascii in that case. Rob
