[OpenWrt-Devel] RFC: add metadata to buildroot
chunkeey at gmail.com
Sat May 18 05:49:54 PDT 2019
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 <mail at aparcar.org> [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*, mostly based on the official
> >> LineageOS Wiki, 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. Most parts
> >> of the metadata are scraped from the current ToH, 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. 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 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...
> >> : https://aparcar.github.io/openwrt-devices/devices/tp-link_archer_c5_ac1200_v1/
> >> : http://wiki.lineageos.org/devices/
> >> : https://github.com/aparcar/openwrt-devices/blob/master/_data/devices/tp-link_archer_c5_ac1200_v1.yml
> >> : https://openwrt.org/toh/hwdata/tp-link/tp-link_archer_c5_ac1200_v1
> >> : https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=43e8c37cb4da64a12a3cb88a84b19db7f2fc640c
> >> : https://github.com/aparcar/openwrt-devices
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > 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
Because with something like that, you could just "nudge" people to do
it by pointing to it.
More information about the openwrt-devel