On 06/17/2014 01:12 AM, Christian Gmeiner wrote:
2014-06-16 19:05 GMT+02:00 Rafael Vanoni rafael.vanoni@pluribusnetworks.com:
On 06/13/2014 09:40 AM, Marc Jones wrote:
Rafael,
i don't think that you can update them once the OS loads. The OS would have already made decisions based on the settings.
Marc
On Tue, Jun 10, 2014 at 7:41 PM, Rafael Vanoni rafael.vanoni@pluribusnetworks.com wrote:
Hi folks, first time posting here. I was wondering if it would be possible to modify smbios values once a system is up and running. Has anyone ever looked into that? If not, any pointers on how to implement this would be greatly appreciated. I'm fairly new to coreboot but would like to look into this.
This is with coreboot + seabios, btw.
Thanks, Rafael
Hi Marc,
That's true, but my intention is to modify more 'informational' fields like version, sn, etc. Nothing that would break the OS.
Wrong: http://lxr.free-electrons.com/ident?i=DMI_MATCH
You can modify dmi values in coreboot - see bachmann/ot205
greets
Christian Gmeiner, MSc
Ok, is there a tool or library to edit DMI values ?
Thanks, Rafael
Rafael Vanoni wrote:
is there a tool or library to edit DMI values ?
No.
Please explain why you want to modify these values at run time?
//Peter
On 06/19/2014 12:25 PM, Peter Stuge wrote:
Rafael Vanoni wrote:
is there a tool or library to edit DMI values ?
No.
Please explain why you want to modify these values at run time?
//Peter
Like I said in a previous post, I'd like to set fields like version, serial number on a per system basis. This is partially an experiment, fwiw.
Thanks, Rafael
Rafael Vanoni wrote:
Please explain why you want to modify these values at run time?
Like I said in a previous post, I'd like to set fields like version, serial number on a per system basis.
That's not the why, that's the what. Indeed you already wrote what you want.
I'm asking *why* you want it, because what you ask for doesn't make sense, so either I don't understand your situation (not at all unlikely) or there might be a better approach to get what you want (also possible).
This is partially an experiment, fwiw.
Again, why modify the values at run time?
Why isn't setting these values at build time enough?
Kind regards
//Peter
On 06/20/2014 01:25 AM, Peter Stuge wrote:
Rafael Vanoni wrote:
Please explain why you want to modify these values at run time?
Like I said in a previous post, I'd like to set fields like version, serial number on a per system basis.
That's not the why, that's the what. Indeed you already wrote what you want.
I'm asking *why* you want it, because what you ask for doesn't make sense, so either I don't understand your situation (not at all unlikely) or there might be a better approach to get what you want (also possible).
This is partially an experiment, fwiw.
Again, why modify the values at run time?
Why isn't setting these values at build time enough?
Kind regards
//Peter
Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale.
Thanks, Rafael
Am 20.06.2014 22:01, schrieb Rafael Vanoni:
Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale.
We have an .id section just below the 16bit entry point - that can (easily) be extended to host more fields, and our smbios table generator could fetch a number from there, overriding a compile time default.
To start, see src/arch/x86/lib/id.inc. It's really two tables: one containing the offsets, one containing the data (strings are 0-terminated). Both tables need to be prepended with new fields, since we're in a top-aligned world here.
Patches accepted :-)
Patrick
On 20.06.2014 20:08, Patrick Georgi wrote:
Am 20.06.2014 22:01, schrieb Rafael Vanoni:
Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale.
We have an .id section just below the 16bit entry point - that can (easily) be extended to host more fields, and our smbios table generator could fetch a number from there, overriding a compile time default.
To start, see src/arch/x86/lib/id.inc. It's really two tables: one containing the offsets, one containing the data (strings are 0-terminated). Both tables need to be prepended with new fields, since we're in a top-aligned world here.
I think it's more sound to have a CBFS plain-text file with serial numbers and other runtime configs. There is a fair number of board and chipset-specific config that should be modifiable without recompilation but are probably inappropriate for CMOS for various reasons as CMOS size shortage or the need for persistance even across RTC power well failure [aka bad clock battery] (think MAC address). having fixed indexes doesn't scale.
Patches accepted :-)
Patrick
Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
(think MAC address).
I guess PC technology is finally beyond requiring those at fixed magic offsets. Some of our chipsets still need it that way.
having fixed indexes doesn't scale.
Neither do text files.
Patrick
realistically, though, it's hard for me to see how setting the serial # at firmware image build time scales. And setting it after boot makes no real sense either -- it's not really a serial number if you're changing it at that point.
But some way to customize the binary images with a serial number seems most workable, if you're going to put the serial number in the firmware image at all (which never made sense to me either --serial #s are supposed to be indelible, and firmware images are not indelible).
ron
On 20.06.2014 20:43, Patrick Georgi wrote:
Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
(think MAC address).
I guess PC technology is finally beyond requiring those at fixed magic offsets. Some of our chipsets still need it that way.
having fixed indexes doesn't scale.
Neither do text files.
I disagree. If you have a file named e.g. config.txt with a syntax like:
southbridge/ibexpeak/thermal_correction: 0x1222
one value per line, it perfectly scales.
Patrick
On Fri, Jun 20, 2014 at 1:01 PM, Rafael Vanoni < rafael.vanoni@pluribusnetworks.com> wrote:
Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale.
You might want to check out the VPD spec for ChromeOS devices: https://docs.google.com/document/d/1d2l5obmBYxgaJQvltEJD-oiLTb0M-RXG-pujG5VD...
Essentially what we do is reserve a region (or two) in the firmware ROM to store an SMBIOS table with an added OEM-type table. That table stores data that's useful for manufacturing and RMAs, but can be used for other product-specific data such as ethernet MAC for some devices (coreboot/src/mainboard/google/butterfly/mainboard.c, for example), wifi antennae and display calibration info, initial language setting, etc. The utility to manage it is here: http://git.chromium.org/gitweb/?p=chromiumos/platform/vpd.git;a=summary
It should be easy to use this to populate SMBIOS tables in memory. Let me know if this looks useful, I'm sure there are some better docs floating around somewhere...
That said, I should point out that the scheme used on Chromebooks is designed explicitly to avoid exposing any information that can be traced to an individual machine. One must switch over to developer mode in order to access anything beyond what is exposed in chrome://system. Here's an example: "initial_locale"="en-US" "initial_timezone"="America/Los_Angeles" "keyboard_layout"="xkb:us::eng" "model_name"="TOSHIBA CB35-A" "region"="us" "sku_number"="PLM01U-002005" "ActivateDate"="2014-17"
-
David Hendricks -
Patrick Georgi -
Peter Stuge -
Rafael Vanoni -
ron minnich -
Vladimir 'φ-coder/phcoder' Serbinenko