Hi Paul,
Hi Martin,
On Sun, Jan 12, 2020 at 10:13:42PM -1000, Paul Spooren wrote:
> Hi,
>
> On 1/12/20 1:05 PM, Martin Blumenstingl wrote:
> > Hi Paul,
> >
> > On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren <m...@aparcar.org> wrote:
> > > Hi all,
> > >
> > > some time ago I created a (now outdated) device overview[0] based on
> > > YAML meta data. This approach could simplify maintaining an device
> > > overview and device specific pages[1].
> > >
> > > All commits adding new devices already include most relevant information
> > > for creating the overview. However it would be convenient if developers
> > > would format their commit messages in a generic format, therefore I'd
> > > propose the following:
> > >
> > > Every commit message for newly added devices must contain a number of
> > > hardware information and steps for an initial installation.
> > > The hardware information should contain at least the following
> > > information, maybe more:
> > >
> > > SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device
> > > tree ID, Ethernet ports
> > can we automate this somehow?
> > the device tree files already contain most of that information.
>
> If you have a tool to extract such data or ideas on how to create such,
> that'd be great.
>
> As an alternative I could also create a shell script that extracts data on a
> running machine, but that might miss some details.
I think that's the better idea, because device-tree doesn't necessarily
cover everything. at runtime we can access /sys/devices/... to get most
relevant info. some things (like the type of the flash chip) are more
tricky apparently, I do this to extract (NOR) flash-chip from dmesg for
example:
for fc in $(for fp in /sys/class/mtd/mtd*/device; do basename $(readlink $fp);
done | grep -v mtd | sort -u); do dmesg | grep -o "${fc}:.*bytes.*"; done
(works only straight after boot, once the logbuffer run full this info
is no longer available)
some things, such as the number of USB ports is really tricky, because
many times there are USB hub chips involved and simply not all ports of
the hub are exposed...
Just my 2 cents...
Cheers
Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
