[OpenWrt-Devel] RFC: add metadata to buildroot
chunkeey at gmail.com
Sat May 18 08:49:54 EDT 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.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel