[PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[Rafał Miłecki]

On 08.07.2020 21:41, mail at adrianschmutzler.de wrote:
>> -----Original Message-----
>> From: Paul Spooren [mailto:mail at aparcar.org]
>> Sent: Mittwoch, 8. Juli 2020 21:34
>> To: Rafał Miłecki <zajec5 at gmail.com>; openwrt-devel at lists.openwrt.org
>> Cc: Rafał Miłecki <rafal at milecki.pl>; Adrian Schmutzler
>> <freifunk at adrianschmutzler.de>; Petr Štetiar <ynezz at true.cz>; Moritz
>> Warning <moritzwarning at web.de>; Daniel Golle <daniel at makrotopia.org>
>> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
>> profiles.json
>>
>> I think the question is therefore more on how to deal with devices that do
>> not use DT? If we use a per device rootfs a line could be added to /etc/os-
>> release containing something like OPENWRT_PROFILE="SpEcIaL-CaSEv100",
>> which is then shown via `ubus call system borad`.
> 
> Well, one could just use something like this, which we had before the compatible was used:
> 
> https://github.com/openwrt/openwrt/blob/openwrt-19.07/target/linux/ramips/base-files/lib/ramips.sh

That's exactly what I was thinking about. That file does:
echo "$name" > /tmp/sysinfo/board_name
which means device-specific identifier will appear as $(board_name)


> There, one could just use the "profile names" instead, with "_" replaced by "," for the few non-DT targets.
> However, this assumes a 1-to-1 relation between boards and profiles, and I'm not sure whether that always exists.
> And somebody would have to create that by hand.

Right. That list should be easy to verify by looking at Makefile and
platform.sh / ramips.sh.


> But I somehow lost track what's the ultimate goal of the proposed changes here, so maybe I'm not going into the right direction with this.

I described it shortly in commit message as:

 > The purpose of "board_name" in JSON is matchine OpenWrt running device
 > with JSON profile entry.

More details: we are working on firmware updating apps that find device
appropriate firmware automatically. See luci-app-attendedsysupgrade for
example.

We need a way for such apps to:
1. Get device identifier (like $(board_name))
2. Easily find matching firmware in profiles.json using above identifier