Changing board info model in LuCI

For Developers
1

Hi all,

I've been trying to change the default 'Model' value (boardinfo.model) on LuCI from 'Raspberry Pi Compute Module 4 Rev 1.0' to 'Raspberry Pi Compute Module 4 Rev 1.0 - Custom v.1.0'

There's a board.json file located at /etc root and the information for the board is there. If I manually change this file, nothing happens in the front-end. LuCI remains with the old model name.

Here is the content for that board.json file

{
	"model": {
		"id": "raspberrypi,4-compute-module",
		"name": "Raspberry Pi Compute Module 4 Rev 1.0 - Custom v.1.0"
	},
	"network": {
		"lan": {
			"device": "eth0",
			"protocol": "static"
		}
	}
}

And here is how the front-end looks.

image
image1075×297 22.7 KB

What am I missing here? Isn't this the proper way to achieve this?

2

The luci value is derived from the dts/dtb afaik

cat /proc/cpuinfo | grep '^Model'

it's typically not something a user want's to mess with...

2 Likes
3

Thank you for your prompt response @anon50098793
This file is empty if I run 'vi /proc/cpuinfo' but it does return the model board if I type the command you suggested.
Do you know how can I change this information on the system?

4

The question is, why do you need to?
(what makes your model different)

answered in my above reply

5

Right.
I'm creating different images from the same raspberry pi boards. The difference is that one is using eMMC storage and the other an SD card. I would like to easily peek at LuCI and see on the "Model" row which board version is that (like Raspberry pi compute module 4 rev 1.0 - emmc or Raspberry pi compute module 4 rev 1.0 - SD).

Getting back to my question, thank you for your answer. When I try to edit the file at /proc/cpuinfo, the file is empty, but if I do "cat" I can see the model name there. Do you know why this is happening?

6

As stated model info is derived from dts

For what you need any minor http code modification to display storage in use seems more direct, given the need is to serve user level purposes...

Other paths get tricky as you are talking about build time and device definition changes which can effect the upgrade process...

it technically does apply to the Model field tho' ( rpi Revision from cpuinfo allows you to derive the 'sub-board' type ) but there are no delineations in OpenWrt for this kind of thing...

The "rpi-foundation" sort of fixes it all up inside the kernel rather than supply several separate dts files... which on many ways makes the whole thing really extensible... but in some instances as you see here... does not fit into typical ways of doing things...

1 Like
7

Awesome!
Thank you very much @anon50098793 !

BTW, thank you again for the very detailed instructions from this post.
I have used this a lot since I'm still learning how to deal with OpenWRT. Very useful.

8

Well if you search through commits in the main/luci repo... you might find some that inform the user an initramfs is running they may be of use...

As would some of the code in the 'luci-app-advancedreboot'

you can backup the file below and run a simple sed to whack something semi-static around that spot quickly if you want a hacky quick fix...

sed -i "s/boardinfo\.system/\'Rockchip\ RK3328\ 1.3GHz\ Quad-Core\ Cortex-A53\ \(aarch64\)\'/g" /www/luci-static/resources/view/status/include/10_system.js

edit: suppose in the context of this I should point out two recent additions to master (not sure about 21.02.2) semi designed for similar purposes

### uci show system
system.@system[0].description='a description of something good'
system.@system[0].notes='some notes about the router'

makes sense and perhaps at a later date someone will adapt the main overview page to print description there probably near the hostname...

2 Likes
9

If the purpose is just visually distinguishing the machine (or making it pretty*) in LuCI, you can just use

echo "Whatever you want to have it called" > /tmp/sysinfo/model

and also put that into rc.local.

This value is collected very early at bootup and later used by LuCI and a few other scripts. From what I gather this is a purely visual identifier that isn't used for any critical purposes anywhere.

With one noteworthy exception: For reasons, the bcm47xx platform -- and only the bcm47xx platform -- uses it to identify the model during sysupgrade. So it's best to leave it alone on those devices.

*) My X86 based firewall puts "To be filled by O.E.M. To be filled by O.E.M." there, which is not especially nice to look at.

4 Likes
10

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