Cudy WR3000S vs cpuinfo vs dmesg

For Developers
1

NOTA: Not sure it is a purely DEV topic, if better place, let me know.

Hello,

I use personal script to deploy (and maintain) OpenWRT (currently 24.10.2 upgraded using owut upgrade) on new device.
In order to manage different platform, I wanted to "retrieve" which "device type" the script is running on.
This is mainly to adapt network port numbering, so I really need to take in account type of device.
ie: WZR-600DHP have eth0 for switch then a switch config for each of the 4 ports. WR3000S have ports LAN1 to LAN4 and no switch.

On Buffalo WZR-600DHP, I'm able to get the relevant value in /proc/cpuinfo as :

system type : Atheros AR7161 rev 2
machine : Buffalo WZR-600DHP
processor : 0
cpu model : MIPS 24Kc V7.4
BogoMIPS : 452.19
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16
Options implemented : tlb 4kex 4k_cache prefetch mcheck ejtag llsc dc_aliases perf_cntr_intr_bit perf mm_full
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available

On Cudy WR3000S (AX3000), the /proc/cpuinfo only provide :

processor : 0
BogoMIPS : 26.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
BogoMIPS : 26.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

I don't know if it is a "bug" or not that cpuinfo on WR3000S device is not formatted with similar info than on WZR-600DHP (ie like : system type or machine ).

If it is a bug, I can try to open a bug/issue, let me know.

If it is "normal" (not a bug) that /proc/cpuinfo have different output, what is the command/source that I can try to rely on to identify what device the script is running on ?

Thanks for any advice.
Nicolas

1 Like
2

Why are you looking at such generic info and what use is it to you?

Files like `/etc/openwrt_release` contain relevant info about architecture, /tmp/sysinfo/board_name contains the device name OpenWrt uses.

2 Likes
3

Thanks @Borromini,

I didn't know about /tmp/sysinfo/board_name.
This fit perfectly what I'm looking for :

cudy,wr3000s-v1
buffalo,wzr-600dhp

I can now identify what device the script is running on and so apply the correct network config.

My use case is :
Deploy 4x SSID dual band, each with it's on VLAN.
VLAN must be split on different physical port (each device have 4 ports).

WZR-600DHP have "switch0" that have switch/switch_vlan config, instead WR3000S have 4x single ports (LAN1, 2, 3, 4). I need to adapt my deployment script to take in account this hardware change.
Goal is to deploy "same solution" whatever it is device 'A' or 'B'. Just running the script will allow simple hardware replacement when issue/failure, upgrade, ...

1 Like
4

And that's reflected in the board ubus call, too, if that's more convenient:

$ ubus call system board | jsonfilter -e '$.release.target' -e '$.board_name'
mediatek/filogic
zyxel,nwa50ax-pro

Capture it into shell variables:

$ eval $(ubus call system board | jsonfilter -e 'target=$.release.target' -e 'board=$.board_name')
$ echo "$target"
mediatek/filogic
$ echo "$board"
zyxel,nwa50ax-pro

Or in ucode which spills over into easy access from LuCI:

$ cat board.uc
#!/usr/bin/env ucode

import * as ubus from "ubus";

u = ubus.connect();
b = u.call("system", "board");
u.disconnect();

printf("%s %s\n", b.release.target, b.board_name);

$ ./board.uc
mediatek/filogic zyxel,nwa50ax-pro
3 Likes
5

@efahl thanks for pointing ubus call system board.

This provide some good information as well :slight_smile:
Either "model" or "board_name" will be the one I'll use.

Just for my knowledge, is ubus output based on either :

  • the board embedded info (like some value in some chipset) then converted to "human readable value"
  • some info stored in the firmware or in some configuration file

I'm just wondering which of ubus call system board or /tmp/sysinfo/board_name is "more reliable" (or more close to the hardware).
ie: file in /tmp can be easily created, written, modified on purpose or by error....
If ubus rely on something that is "cast in some silicium chipset", then it is less prone to human error :wink:

6

The system board call attempts to read its data from files (but will fall back to DTS info some times), so you can hack up an install without recompiling. This is particularly useful when doing sysupgrade over a major release if the target or board got renamed (I think this has happened twice in the last 2-3 years, so although rare, it does happen). See https://github.com/openwrt/procd/blob/master/system.c#L122 for the gory details.

Short version: the board_name primary source is /tmp/sysinfo/board_name; the target comes from /etc/openwrt_release...

1 Like
7

Based on this if I'm correctly reading the code, then ubus call system board is provided based on :

  1. /proc/cpuinfo
  2. /tmp/sysinfo/model
  3. /proc/device-tree/model

So I will rely on ubus as it looks like it "try many way" in order to grab the info, so... will be likely always providing some value :slight_smile:
More or less same spirit than uci for config, I'll let OpenWRT dev team to deal with each box's specific and will rely on the "common framework" to make my script "portable", in this case ubus :mechanical_arm:

If due to some major release one board I deploy should "change" in the way it will be "identified", then I will just have to update one value in my script, no a big deal for me, it is not a high availability mission critical solution :wink:
I just want to be "as ready as possible" in case a device broke and I have to re-install. In this case I want to avoid remembering all I did in previous install.
Now I need board info to adapt due to both swconfig and DSA. My current use-case I have to deal with, WZR-600DHP that rely on swconfig and WR3000S that rely on DSA, not the same way to configure VLANs thru uci...

8

Yeah, exactly right; I forgot to add a comment to that effect. I rely on the ubus call as it's the "source of record" irrespective of any changes to underlying details or target-specific info or whatever...

1 Like
9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.