于 2020年10月12日 GMT+08:00 下午8:02:25, Tiezhu Yang <yangtiezhu@xxxxxxxxxxx> 写到:
On 10/12/2020 06:38 PM, Thomas Bogendoerfer wrote:Hi Tiezhu,
On Sun, Oct 11, 2020 at 07:47:53AM +0800, Tiezhu Yang wrote:Hi Thomas,
Add /proc/boardinfo to get mainboard and BIOS info easily on the LoongsonWhy does Loongson64 need this extra file no other architecture or MIPS
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.
E.g. with this patch:
[loongson@linux ~]$ cat /proc/boardinfo
Board Info
Manufacturer : LEMOTE
Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family : LOONGSON3
BIOS Info
Vendor : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size : 4 KB
Release Date : 2020-04-14
platform need ? Do others provide this information via a different method ?
If yes, why can't Loongson64 do the same ?
This is related with the implementation of firmware.
Using dmidecode command can get the similar info if there exists SMBIOS
in firmware, but the fact is there is no SMBIOS on some machines, we can
see nothing when execute dmidecode, like this:
[root@linux loongson]# dmidecode
# dmidecode 2.12
# No SMBIOS nor DMI entry point found, sorry.
The following three structures are already defined in the interface
specification about firmware and kernel on the Loongson platform,
this is common requirement and specific for Loongson64, so add a
new boardinfo.c file in arch/mips/loongson64.
arch/mips/include/asm/mach-loongson64/boot_param.h
struct interface_info {
u16 vers; /* version of the specificition */
u16 size;
u8 flag;
char description[64];
} __packed;
struct board_devices {
char name[64]; /* hold the device name */
u32 num_resources; /* number of device_resource */
/* for each device's resource */
struct resource_loongson resource[MAX_RESOURCE_NUMBER];
/* arch specific additions */
struct archdev_data archdata;
};
struct loongson_special_attribute {
u16 vers; /* version of this special */
char special_name[64]; /* special_atribute_name */
u32 loongson_special_type; /* type of special device */
/* for each device's resource */
struct resource_loongson resource[MAX_RESOURCE_NUMBER];
};
Through I don't think touching top level of proc would be a good idea. It's all about API consistency.
If you intend to provide user an interface then I guess /sys/firmware/lefi
like what DMI did or somewhere less critical is better.
There is no guarantee that Loongson64 device would come with LEFI,
although it's mandatory for now.
Thanks.
- Jiaxun
Thanks,
Tiezhu
Thomas.