[OpenWrt-Devel] [PATCH 0/8, RFC] RouterBOARD sysfs driver for RouterBoot data

Thibaut VARÈNE hacks at slashdirt.org
Fri Apr 3 14:20:48 EDT 2020

Following a conversation on IRC, this patchset introduces a sysfs interface to
access routerboot "hard_config" data (as stored in the flash segment of the
same name) in a consistent, platform-independent manner.

The rationale for this patchset is threefold:
 1/ Make "hard_config" data accessible in a platform-agnostic way
 2/ Reduce the amount of processing for wlan calibration data
 3/ Lay the groundwork for single image support on RouterBOARD devices

In more details:
 1/ "hard_config" data platform-agnostic accessors
The MikroTik RouterBOARD "hard_config" flash segment contains encoded data such
as the board code, name, serial number, memory size, mac address base, booter
version, hardware features, product name, WLAN calibration data and more. This
driver presents all known datapoints via sysfs in a machine and human friendly
way. This makes it possible for userspace to process that information, in
particular for the two cases further detailed below.

 2/ Simplify the processing of wlan calibration data
On ar71xx, ath9k calibration data was directly fed to the driver in the code
while ath10k was typically exposed in binary form in sysfs, to be then loaded
by the corresponding driver.
On ath79 and other DTS-based devices, the sysfs file is not available (as the
original code that exposed it was apparently deemed unsuitable for inclusion or
upstreaming), so these devices resort to a userspace utility ("rbextract") that
fetches the data from the flash and uncompresses/decodes it. The result is then
copied back to the flash upon first boot, wasting space there.
This driver makes it possible to entirely get rid of rbextract (which has a
number of issues of its own, as it ported into userspace the code issues of the
original ar71xx kernel driver), and use the common "caldata_from_file()"
routine to extract the relevant calibration data.
It doesn't (yet) remove the need to use flash space to store that extracted
data, however should this driver be accepted, it would be technically be possible
to implement direct DTS-based accessors (I have been pointed at nvmem).

 3/ Groundwork for single image support
Assuming it ever becomes desirable to offer a single-image for all supported
RouterBOARD devices (per arch, of course), a la ar71xx, this driver will
simplify this task as it will be possible to update e.g. the actual product
name or perform further device setup based on the information exposed in sysfs.

This driver doesn't (yet) offer OF capabilities, it seemed unnecessary at this
stage, this also makes it possible to use the driver on ar71xx (it's been tested
successfully there too), in case a backport is desirable (for instance to
address PR#2729). Adding OF support is nevertheless possible if required.

The driver currently lives in drivers/platform for lack of a better idea, it
can certainly be moved elsewhere if necessary. Likewise for the sysfs basedir

The driver does not reuse any code from the ar71xx bits, it is a write from
scratch based on my analysis of several flash dumps across multiple RouterBOARD
devices. It can coexist with the ar71xx code (tested sucessfully in this

The code currently allocates a buffer the size of the hard_config flash
partition, but it's been written in a way that makes it possible to switch to
reading directly from the flash without ever allocating permanent RAM
(obviously at a performance cost).

The code for handling the new-style "LZOR" WLAN calibration compression scheme
has been left as a separate patch for two main reasons:
 - I couldn't test it on hardware that would exert that code path
 - The required binary blob LZO prefix might pose licensing issues
Should this latter point materialize, an alternative option would be to expose
the raw, compressed/encoded data in sysfs and rewrite "rbextract" so that its
only job becomes decoding. This moves the questionable bits from kernel to user
space, if that makes a difference. The blob is nevertheless necessary to
decompress the data.

Finally, should this driver be accepted, I intend to also expose the so-called
"soft_config" data in an incremental patch, making it possible to drastically
simplify if not remove entirely the "rbcfg" utility (whose job could then be
implemented directly in a luci app for instance).

I once again grouped the kernel config edits for simplicity. This patchset is
orthogonal to my previous series ("MTD parser for RouterBoot partitions") and
can be tested independently. There are a few "XXX" comments in the code which
are pending feedback from this submission and will be cleaned up in the final

This patch series has been successfully tested on BE (ath79, ar71xx) and LE
(ipq40xx) hardware.

I guess that sums it up, I hope this helps; looking forward to comments :)

Thibaut VARÈNE (8):
  generic: routerboot sysfs platform driver
  generic: mikrotik platform build bits (4.14)
  generic: mikrotik platform build bits (4.19)
  generic: CONFIG_MIKROTIK is not set
  ath79: enable mikrotik platform driver
  ar71xx: enable mikrotik platform driver
  ramips: enable mikrotik platform driver
  generic: platform/mikrotik: support LZOR encoding

 target/linux/ar71xx/mikrotik/config-default        |   2 +
 target/linux/ath79/mikrotik/config-default         |   2 +
 target/linux/generic/config-4.14                   |   1 +
 target/linux/generic/config-4.19                   |   1 +
 target/linux/generic/config-5.4                    |   1 +
 .../files/drivers/platform/mikrotik/Kconfig        |  17 +
 .../files/drivers/platform/mikrotik/Makefile       |   4 +
 .../drivers/platform/mikrotik/rb_hardconfig.c      | 742 +++++++++++++++++++++
 .../files/drivers/platform/mikrotik/routerboot.c   | 185 +++++
 .../files/drivers/platform/mikrotik/routerboot.h   |  32 +
 .../270-platform-mikrotik-build-bits.patch         |  36 +
 .../270-platform-mikrotik-build-bits.patch         |  36 +
 target/linux/ramips/mt7621/config-4.14             |   2 +
 13 files changed, 1061 insertions(+)
 create mode 100644 target/linux/generic/files/drivers/platform/mikrotik/Kconfig
 create mode 100644 target/linux/generic/files/drivers/platform/mikrotik/Makefile
 create mode 100644 target/linux/generic/files/drivers/platform/mikrotik/rb_hardconfig.c
 create mode 100644 target/linux/generic/files/drivers/platform/mikrotik/routerboot.c
 create mode 100644 target/linux/generic/files/drivers/platform/mikrotik/routerboot.h
 create mode 100644 target/linux/generic/pending-4.14/270-platform-mikrotik-build-bits.patch
 create mode 100644 target/linux/generic/pending-4.19/270-platform-mikrotik-build-bits.patch


openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list