molejar / pyfdt Goto Github PK

Given a signed FIT configuration created by mkimage, if you read it in with pyFDT and then write it out again (no changes), the signature will no longer validate.

The reason is that mkimage choses a rather strange order to write out the strings at the end of the itb/dtb, and these strings are included in the data that is signed.

I have a fix which involves reading the strings buffer out of the original file, and passing this into FDT.write_dtb as an initial value of the strings buffer for the output. This disadvantage of using this, is that if a string is no longer used in the output file, it will still be written to the output file. There is actually no way to avoid this if the string data is part of the signed data.

This is a rather esoteric use case, and it may be reasonable to WONTFIX the issue

Problem 1:

first DTS includes labels like
spiA: spi0: spi { ... };

second DTS includes labels like
spi0: spiA: spi { ... };

Then diff shows them like 2 different nodes

Problem 2

Additional labels for node

first DTS includes labels like
spi0: spi { prop = "1"; };

second DTS includes labels like
spiA: spi0: spi { prop = "2"; };

Then diff shows something strange and lose all labels which are related to node:

first DTS
spi0 { prop = "1"; };

second DTS
spiA { prop = "2"; };

I'm using this module on an uboot its file, which is the same syntex as device tree dts
I understand this is not the intented usage for this module, but the purpose for this issue apply to both

I have a node like this, when I read it from file as txt, then parse by parse_dts, it will fail because kernel/arch/arm64/boot/dts/rk3568-evb1-ddr4-v10-linux.dtb is not exist yet.

    images {
        fdt {
            data = /incbin/("kernel/arch/arm64/boot/dts/rk3568-evb1-ddr4-v10-linux.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            load = <0xffffff00>;

            hash {
                algo = "sha256";
            };
        };
    };

It may not seems useful when the required file is missing
But actually there is a need for, which is for patching the source before it get used

It would be nice if we could have an option to stop it from parsing further than a given layer number/count

Example of incorrect behavior:

dt = fdt.parse_dtb(image)
ddd = dt.get_node("/aaa/bbb/ccc/ddd")
print("ddd.path =", ddd.path)
#> ddd.path = /aaa/bbb/ccc
ddd = dt.get_node(ddd.path)
print("ddd.name =", ddd.name)
#> ddd.name = ccc
print("ddd.path =", ddd.path)
#> ddd.path = /aaa/bbb

Here's a way to fix this behavior: openwrt-xiaomi/xmir-patcher@b782ca1

Hi there, will there be a 2021 0.3.X release to pypi ? many thanks!

Is pyFDT capable of parsing phandlers?

I get the following error:

ValueError: invalid literal for int() with base 10: '&pctl_uart0'

For the following file: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arc/boot/dts/abilis_tb100_dvk.dts

And design an interface between parts, probably using python entry points for discovery and selection.

Reasons:

• these serialization formats may have standalone uses outside of area of system programming;
• there may be different impls of parsers and serializers (i.e. ones handcoded and ones generated from grammars (and different generators and different classes of grammars here), ones in python and ones in C, C++ or Rust) and there should be a possibility to change the impl easily.

PropWords.to_dtb contains the code:

        blob = pack('>III', DTB_PROP, len(self.data) * 4, strpos)
        for word in self.data:
            blob += pack('>I', word)

This ends up allocating O(n**2) space. If you are writing a full blown image (.itb) rather than a device tree the program appears to hang.

I have a patch which uses bytes.join of a list comprehension. It also uses struct.Struct to avoid compiling the format millions of time. This makes loading a large DTB noticeably snappier. I now need to find out if my employer will allow me to submit a PR.

Hi,

Since you took some parts of the code from pyfdt (https://github.com/superna9999/pyfdt), please add my copyright line along yours and rename the project into something else.

Thanks,
Neil

Currently, parse_dtb raises an Exception with message "Unknown Tag: 4", which is DTB_NOP.
I believe the fix is as simple as adding this to parse_dtb:

elif tag == DTB_NOP:
    continue

Due to the above line and the use of f strings, I am unable to utilize this package with python 3.5. At this time, I am unable to update the infrastructure surrounding the use of this package to utilize 3.6 or newer where the f string feature is present.

Would it be possible to change this line to allow for usage with python 3.5?

Parsing a dts containing a binary include (/incbin/) gives me the following exception using python 3.7 and pyFDT 0.3.3:

Traceback (most recent call last):
  File "./test.py", line 9, in <module>
    tree = fdt.parse_dts(dts)
  File "<...>/python3.7/site-packages/fdt/__init__.py", line 505, in parse_dts
    prop_obj = PropIncBin(prop_name, prop_data, os.path.split(file_path)[1])
  File "<...>/python3.7/site-packages/fdt/items.py", line 469, in __init__
    super().__init__(name, data)
  File "<...>/site-packages/fdt/items.py", line 378, in __init__
    self.data = bytearray(args)
TypeError: 'bytes' object cannot be interpreted as an integer

Code to reproduce:

import fdt

dts = """/dts-v1/;

/ {
  data = /incbin/("data.bin");
};
"""

tree = fdt.parse_dts(dts)