yodaldevoid/dts_viewer

A viewer for DTS files to aid in debugging.

dts_viewer's Issues

Print labels when `Display`ing

impl Display and Error for all error types

• ParseError
• BoundsError
• IncludeError

Mark aliased blocks when printing

Implement binary include

Use root file's root directory as current dir while including

Hello. How does this work?

Hi. When I run this tool and point it to a .dts file, I get the following:

test/system-device-tree-zynq.dts: CPP
|- : CPP
|- |- : CPP

Enter alias or path:

What is this suppost to be? I thought this tool would somehow traverse includes and produce an easy way to understand the whole picture.

Run `iter_dts_files` on all dts directories in the Linux kernel

• arch/metag/boot/dts
• arch/mips/boot/dts
• arch/powerpc/boot/dts
• arch/arm/boot/dts
• arch/nios2/boot/dts
• arch/h8300/boot/dts
• arch/arc/boot/dts
• arch/cris/boot/dts
• arch/arm64/boot/dts
• arch/sh/boot/dts
• arch/microblaze/boot/dts
• arch/openrisc/boot/dts
• arch/c6x/boot/dts
• arch/xtensa/boot/dts

Add way to perform secondary checks on parsed tree

definitely:

• duplicate node names
• duplicate property names
• node name format (only one @)
• unit addr vs reg/ranges property
• duplicate labels -- handled by creation of alias store
• duplicate explicit phandles
• name property does not match name
• check if X is cell only
  • #address-cells
  • #size-cells
  • #interrupt-cells
• check if X is string only
  • device_type
  • model
  • status
• fixup addr size cells
• check reg property format
• check ranges property format
• avoid default addr size?
• obsolete chosen iterrupt controller

maybe:

• fixup phandle refs
• fixup path refs

Reason for Property and Node to be enums?

I am using the device_tree_source library and I was wondering what your reasons were for making Property and Node enums?

My use case is to parse the device tree to create some structs of my own to be consumed by another tool. I am finding it fairly difficult to keep parsing these nested enums while looking for specific information.

Consider a function where I expect a node to have a property where the value is a single string:

fn get_node_prop_string(n: &Node, prop: &str) -> Option<String> {
     match n {
        Node::Existing { proplist, .. } => 
        {
            match proplist.get(prop)? {
                Property::Existing { val, .. } => {
                    val.as_ref()?.iter().next().map(|z| match z {
                        Data::String(s) => Some(s.clone()),
                        _ => None,
                    }).flatten()
                },
                Property::Deleted { .. } => None,
            }
        },
        Node::Deleted { name, .. } => None,
     }
}

I need to have 3 matches in there, because there are 3 nested enums. I can make it cleaner with some other helper functions:

fn get_node_proplist(n: &Node) -> Option<&HashMap<String, Property>> {
    match n {
        Node::Existing { proplist, .. } => Some(proplist),
        Node::Deleted { .. } => None,
    }
}

fn get_property_val(p: &Property) -> &Option<Vec<Data>> {
    match p {
        Property::Existing { val, .. } => val,
        Property::Deleted { .. } => &None,
    }
}

fn get_node_prop_string(n: &Node, prop: &str) -> Option<String> {
    let p = get_node_proplist(n)?.get(prop)?;
    let vals = get_property_val(p).as_ref()?;
    match &vals[0] {
        Data::String(s) => Some(s.clone()),
        _ => None,
    }
}

But I need to write those functions myself.

Here is an alternative approach:

#[derive(PartialEq, Eq, Debug, Clone)]
pub struct PropertyInner {
    val: Option<Vec<Data>>,
    labels: Vec<String>,
}

#[derive(PartialEq, Eq, Debug, Clone)]
pub struct Property {
    name: String,
    offset: usize,
    exists: Option<PropertyInner>,
}

#[derive(PartialEq, Eq, Debug, Clone)]
pub struct NodeInner {
    proplist: HashMap<String, Property>,
    children: HashMap<String, Node>,
    labels: Vec<String>,
}

#[derive(PartialEq, Eq, Debug, Clone)]
pub struct Node {
    name: NodeName,
    offset: usize,
    exists: Option<NodeInner>,
}

Then my function becomes a lot cleaner by default:

fn node_get_prop_string_by_name(node: &Node, prop: &str) -> Option<String> {
    let vals = node.exists.as_ref()?
        .proplist.get(prop)?
        .exists.as_ref()?
        .val.clone()?;
    
    match &vals[0] {
        Data::String(s) => Some(s.clone()),
        _ => None,
    }
}

This simplifies my use case, but also still lets you tell if a node or property is deleted. You just need to check the exists option.

I am fairly new to rust so I may be missing something here.

Give more detailed error messages when failing to parse

Implement trinary operator in math expression parsing

Implement labels on Data

This is labels within property data as labels on properties is already implemented.

Set the boot CPU ID in BootInfo at parsing time

It is currently set to 0 and never changed.