Hi Rob, On Wed, 3 Nov 2021 at 16:42, Rob Herring <robh@xxxxxxxxxx> wrote: > > On Wed, Nov 3, 2021 at 2:56 PM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, 3 Nov 2021 at 13:17, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > On Wed, Nov 3, 2021 at 10:59 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Nov 2, 2021 at 11:42 PM David Gibson > > > > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 08:29:53PM -0500, Rob Herring wrote: > > > > > > On Wed, Oct 13, 2021 at 1:26 AM David Gibson > > > > > > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > On Mon, Oct 11, 2021 at 08:22:54AM -0500, Rob Herring wrote: > > > > > > > > On Mon, Oct 11, 2021 at 2:19 AM David Gibson > > > > > > > > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > On Tue, Jul 27, 2021 at 12:30:22PM -0600, Rob Herring wrote: > > > > > > > > > > YAML output was restricted to dts input as there are some dependencies > > > > > > > > > > on source annotations which get lost with other input formats. With the > > > > > > > > > > addition of markers by the checks, YAML output from dtb format becomes > > > > > > > > > > more useful. > > > > > > > > Heh. Ok, but there's no reason you couldn't bundle a dtb->yaml > > > > > preprocessor written in C (or Rust, or Go) with the rest of the > > > > > validation tools. Then it would be colocated with the rest of the > > > > > binding information and can be updated in lockstep. > > > > > > > > That's a great idea. I found some code on the internet written in C > > > > that already does dtb->yaml conversion, so I can use that. Do you > > > > think it is any good[1]? ;) > > > > > > > > > Or better yet, > > > > > write a preprocessor that goes direct from dtb to Python native data > > > > > types, avoiding the problems with YAML. > > > > > > > > That's exactly what the plugin did. Maybe the last patch should have > > > > been removing YAML output. You seemed fairly lukewarm on the whole > > > > thing, so it seemed like it was going to take more time than I had to > > > > spend on it. > > > > > > > > Maybe using pylibfdt could work here though it doesn't already > > > > unflatten the tree into dictionaries. Maybe that already exists > > > > somewhere. Simon? > > > > > > dtoc in u-boot is one though it unpacks into custom classes rather > > > than pure dict I need. But implementing unpacking was quite simple. > > > The harder part seems to be the lack of any packaging for pylibfdt. > > > > Packaging? > > In PyPi: pip install libfdt > > Or packaged by the distro. Then I can just add it as a dependency to > dtschema and it all just works for users. > > > Yes dtoc has some Python classes for reading the DT and updating it > > (with a separate 'commit' step). I am not entirely happy with the > > state of it though. If you want to tidy it up and upstream it, that > > would be great. If you me some pointers as to what you need, I could > > try it. I need to get back to the fdtgrep stuff in the next week or > > do, so the timing is right. > > I've got something working. The Node and Prop classes didn't really > work for me as I need the DT represented as a dict. (And using it > would be a licensing issue too as dtschema is BSD). OK, sounds good. Regards, Simon
