On Wednesday, May 15, 2019 5:18:05 PM CEST Alberto Bursi wrote: > > On 14/05/19 16:49, Petr Štetiar wrote: > > [adding Thomas and Alberto to the Cc loop] > > > > Paul Spooren <[email protected]> [2019-05-04 17:48:03]: > > > > Hi, > > > >> from my point of view the current OpenWrt device documentation lacks > >> some unity, meaning the table of hardware is partly incomplete or > >> inconsistent. Also documentations are often rewritten with different > >> precision and "tongue". > >> > >> To unify things I created a *PoC*[0], mostly based on the official > >> LineageOS Wiki[1], as they have a similar situation regarding devices. > >> > >> The idea is to define templates describing common information and fill > >> them with device metadata. > >> > >> The *PoC* above is based on the following metadata here[2]. Most parts > >> of the metadata are scraped from the current ToH[3], however some small > >> pieces are added and later rendered in something useful: > >> > >> tftp_image: ArcherC5v1_tp_recovery.bin > >> tftp_ip: 192.168.0.66 > >> > >> Result in a small text to explain how to use the TFTP recovery. > >> > >> switch_ports: > >> 0: ETH1 > >> 1: WAN > >> 2: LAN1 > >> 3: LAN2 > >> 4: LAN3 > >> 5: LAN4 > >> 6: ETH0 > >> > >> Creates a table with the switch port messing. > >> > >> Same could be done with the flash layout, LEDs, etc. > >> > >> All these information are (hopefully) available to the developer adding > >> a new device, therefore easy to supply such a `yaml` metadata file as > >> well. Often these information are (re-formulated) in commit messages > >> anyway[4]. Meaning, somewhere in the buildroot could be a store of > >> `yaml` files, which could even be reused for building itself. > >> > >> A second repository like openwrt-device.git[5] could be added to render > >> the wiki pages and organize the templates. > >> > >> I'd be happy to hear your opinions. > > I really like, it's nice and I applaud your effort. Thanks! > > > >> Best, > >> Paul > >> > >> PS: I'm afraid I don't know the mail address of tmomas... > >> > >> [0]: > >> https://aparcar.github.io/openwrt-devices/devices/tp-link_archer_c5_ac1200_v1/ > >> [1]: http://wiki.lineageos.org/devices/ > >> [2]: > >> https://github.com/aparcar/openwrt-devices/blob/master/_data/devices/tp-link_archer_c5_ac1200_v1.yml > >> [3]: https://openwrt.org/toh/hwdata/tp-link/tp-link_archer_c5_ac1200_v1 > >> [4]: > >> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=43e8c37cb4da64a12a3cb88a84b19db7f2fc640c > >> [5]: https://github.com/aparcar/openwrt-devices > > _______________________________________________ > > openwrt-devel mailing list > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > I'm always in favor of more automation, although the TOH is mostly > tmomas's thing. > > The point here is that before we can enforce this on commits there needs > to be: > > -a consensus between core devs
Nah, If there's a script in a (devel) package that could extract some of the information by running it on the device and leave blanks for stuff that it can't detect that would be great. From what I can tell, such a script should be able to grab the openwrt target and arch via /etc/os-release or /etc/openwrt_release. The device name via /etc/board.json including the default switch configuration. The SoC's cpu type and number of cpu cores is available through /proc/cpuinfo (or the external lscpu tool) and the available memory is printed by free or can be parsed from /proc/meminfo. What's more tricky would be to get the leds and wifi. It's possible to extract some information about the LEDs from /sys/class/leds/* . While iwinfo phy[0123..] htmodelist/freqlist/info can extract the supported HT modes, channels and (if provided) the device type. Because with something like that, you could just "nudge" people to do it by pointing to it. Regards, Christian _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
