Hello!
Yesterday I tried coreboot again, and it worked fine so far.
But I faced a nasty problem, like the last time I tried it with the MAC address on MCP55. This is nothing serious as you can change it by editing the romcache.inc from the southbridge, but it's nasty.
I was thinking about fixing this in a decent way. I'd love to see a KConfig value to enter in the configure process to get this done, or even to copy the mac address of the board.
As of now the MAC is stored in the romcache.inc file of the southbridge, and as far as I guess, this value is read in the mcp55_nic.c and used. There is as of now in the bugtracker a script to apply the new mac after compiling the image, but I think this is not a really good solution.
If my guess is right, readout from romcache.inc and usage in mcp55_nic.c it should be possible to solve this via KConfig, and not read the value from the romcache.inc, but store it a config value and take this value. Possibly with a fallback on the romcache.inc value.
My questions on this suggestion are: Would there be any good reason not to do it that way? Is my guess right? (Until now I didn't look that careful into the code of mcp55_nic.c.)
If my guess is right, and there is no problem to do as suggested, I'd prepare a patch for it. Any comments are welcome.
Kind regards, Harald
On Thu, Nov 4, 2010 at 11:55 AM, Harald Gutmann harald.gutmann@gmx.net wrote:
Hello!
Yesterday I tried coreboot again, and it worked fine so far.
But I faced a nasty problem, like the last time I tried it with the MAC address on MCP55. This is nothing serious as you can change it by editing the romcache.inc from the southbridge, but it's nasty.
I was thinking about fixing this in a decent way. I'd love to see a KConfig value to enter in the configure process to get this done, or even to copy the mac address of the board.
As of now the MAC is stored in the romcache.inc file of the southbridge, and as far as I guess, this value is read in the mcp55_nic.c and used. There is as of now in the bugtracker a script to apply the new mac after compiling the image, but I think this is not a really good solution.
If my guess is right, readout from romcache.inc and usage in mcp55_nic.c it should be possible to solve this via KConfig, and not read the value from the romcache.inc, but store it a config value and take this value. Possibly with a fallback on the romcache.inc value.
My questions on this suggestion are: Would there be any good reason not to do it that way? Is my guess right? (Until now I didn't look that careful into the code of mcp55_nic.c.)
If my guess is right, and there is no problem to do as suggested, I'd prepare a patch for it. Any comments are welcome.
Hi Harald,
It seems like a Kconfig option would be a good idea. It can alway default to a reasonable value. Another idea I have seen floating around is to have the value stored in cbfs. Then it could be updated post coreboot build.
Marc
Am 05.11.2010 17:27, schrieb Marc Jones:
It seems like a Kconfig option would be a good idea. It can alway default to a reasonable value. Another idea I have seen floating around is to have the value stored in cbfs. Then it could be updated post coreboot build.
Not sure, but don't some chipsets handle MAC addresses via the romstrap area? If so, kconfig might be a better place (for all boards), so the MAC can be compiled into the romstrap as part of the build process.
The only question is the format the MAC should be in. The Makefile could rewrite 1:23:45:67:89:ab to a set of #defines (MAC1, .., MAC6 with a byte each?), so whatever the romstrap format for MAC addresses is could be modelled in code.
Patrick
On Thu, Nov 04, 2010 at 06:55:28PM +0100, Harald Gutmann wrote:
Hello!
Yesterday I tried coreboot again, and it worked fine so far.
But I faced a nasty problem, like the last time I tried it with the MAC address on MCP55. This is nothing serious as you can change it by editing the romcache.inc from the southbridge, but it's nasty.
I was thinking about fixing this in a decent way. I'd love to see a KConfig value to enter in the configure process to get this done, or even to copy the mac address of the board.
Look at the romstrap of the vendor-provided firmware update image for a nvidia board. You'll find it doesn't contain your board's address.
IMO this issue would be best solved in the vicinity of flashrom.
It's trivial to follow the romstrap pointers and copy over the address.
Attached is a utility to do just that.
Jonathan Kollasch
On Friday 05 November 2010 17:48:43 Jonathan A. Kollasch wrote:
Look at the romstrap of the vendor-provided firmware update image for a nvidia board. You'll find it doesn't contain your board's address.
I know that point, and it is definitely a good idea to solve that part via flashrom. Also as I just found a tread on the LinuxBios ML [1] which discussed that topic, and the main point why it would be a better solution to treat this in flashrom is, that you can use the same image for different mainboards without compiling the image for every single board.
Just for my personal interest, could someone explain me what actually is called romstrap? Google was not really informative on that point, except some "romstrap overrides" during graphic card bios flashing.
Further the question arises for me if following the romstrap pointer would also work on proprietary bios, or if this could only be managed correctly with coreboot images?
Otherwise I'd suggest to create a flashrom option which copies the actual MAC on flashing the new image.
IMO this issue would be best solved in the vicinity of flashrom.
It's trivial to follow the romstrap pointers and copy over the address.
Attached is a utility to do just that.
Thanks you for the utility, there is also one (perl script) in the bugtracker (#135) [2] which does a similar operation, but with a supplied mac. I think that both utilities are not "perfect", because as I've seen yours needs a second rom image which contains the right mac, and on the script in the bugtracker you need to supply it.
Personally I'd prefer to read the actual running mac from the system. (Which could be done by your utility - but needs a full read cycle of the bios flash.) Is there any fast method to read the onboards NIC mac address "faster"?
Jonathan Kollasch
Kind regards, Harald Gutmann
[1] http://www.mail-archive.com/linuxbios@linuxbios.org/msg11462.html [2] http://tracker.coreboot.org/trac/coreboot/attachment/ticket/135/change- mcp55-mac.pl
Harald Gutmann wrote:
Just for my personal interest, could someone explain me what actually is called romstrap?
It's a horrible name for permanent settings that are stored in the boot flash.
Is there any fast method to read the onboards NIC mac address "faster"?
ip l sh eth0|grep link/ether|awk '{print $2}'
//Peter
On Monday 08 November 2010 15:30:44 Peter Stuge wrote:
Harald Gutmann wrote:
Just for my personal interest, could someone explain me what actually is called romstrap?
It's a horrible name for permanent settings that are stored in the boot flash.
I thought that these things are permanently stored. But is it just a name for fixed values in the flash, or do those values need to be stored at a "special" address in the flash?
Is there any fast method to read the onboards NIC mac address "faster"?
ip l sh eth0|grep link/ether|awk '{print $2}'
I know that this is possible via commands on the shell, but you can't be sure that you select the onboard NIC with that method, because when a second NIC is used in that board on PCI this one could also be eth0, and therefore you could end up with the wrong one getting copied.
//Peter
Regards, Harald
Is there any fast method to read the onboards NIC mac address
"faster"?
ip l sh eth0|grep link/ether|awk '{print $2}'
I know that this is possible via commands on the shell, but you can't be sure that you select the onboard NIC with that method, because when a second NIC is used in that board on PCI this one could also be eth0, and therefore you could end up with the wrong one getting copied.
I thought you could tell the vendor by looking at the MAC Address.
Thanks, Myles
-
Harald Gutmann -
Jonathan A. Kollasch -
Marc Jones -
Myles Watson -
Patrick Georgi -
Peter Stuge