Re: [coreboot] setting smbios values from the OS
On Fri, Jun 20, 2014 at 1:01 PM, Rafael Vanoni < rafael.van...@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-pujG5VDa_A/pub 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" -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
This whole microcode issue caused us a couple of weeks of delay. Here's the basics of what I found - I don't know if any of this is fixed, I'll check with Intel and report back: There are 2 different microcode load routines, one for the BSP, and one for the APs. The BSP's routine will load the microcode without checking that the SKU is correct. The AP's loading routine won't load if the microcode SKU is wrong. Unfortunately, it doesn't report this, it just doesn't load the microcode and carries on as if nothing happened. The hang is caused due to an MSR access that isn't valid unless the microcode is loaded. Accessing this MSR hangs the APs. The system will then hang waiting for the AP init to complete. I believe you'll find that if you comment out the final FSP call, the system will boot, but you'll probably only have one core running. The issue with the correct microcode is that apparently there were no Bay Trail I SKUs released for the B0 rev - they were released as a "super-Sku" that is identified as a Bay Trail T. There is, however, for some reason, still a microcode patch available for the Bay Trail I B0/B1. I *believe* that the correct microcode patch for the B0 parts is the Bay Trail T patch that's in the FSP package. If this microcode patch isn't working for anyone on their B0, please let me know. We (Intel and Sage) had initially decided that only the B3 silicon was going to be supported for this release. I'm still not sure that wasn't the correct choice, but it was later requested to add the support for the B0 part as well. I'd really urge anyone using a B0 to just upgrade to a B3 part. On an unrelated note, after heavy use of the Bayley Bay and Bakersport boards, we noticed that the boot was halting in memory init, when nothing on the board had changed. I finally figured out that this was due to a bad board connection with the processor. Since the processors are not soldered to the board, it seems like sometimes the connection would develop issues. Tightening the adapter holding the processor to the board fixed all the issues we were having. Martin On Sat, Jun 21, 2014 at 5:37 PM, Giri wrote: > Regarding below two items > > 1) The microcode that is being included is not a part of coreboot, so it > needs to be disabled for the default build so that abuild doesn't fail. > Intel wants to release the microcode as part of the FSP package and not > include it in the coreboot repo so that the microcode vs FSP versions can be > matched up. > > Microcode is not part of FSP but just consumes the pointer and length. > Microcode and FSP versions doesn't need to match but the microcode needs to > match the CPU on that platform. > > 2) The microcode that's included for the intel FSP is for B2/B3 silicon, but > it seems like many users are still using B0 silicon, which requires a > different microcode patch. This shouldn't be a problem but since there are > 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* > to work, but cause issues later, the microcode can cause massive amounts of > confusion. > > Please check if the microcode is loaded by reading MSR 0x8B > > -Giri > > -Original Message- > From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Peter > Stuge > Sent: Friday, June 6, 2014 2:57 AM > To: coreboot@coreboot.org > Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output > > Martin Roth wrote: >> Eh, it's code... It's going to have issues and bugs. > > I disagree with that attitude. A platform vendor writing platform init code > doesn't really have a valid excuse for producing buggy code. > > "Release early, release often" can't be an excuse to push the consequences > of one's own shortcomings onto others. That's just poor programmer's moral. > > I obviously disagree with letting shortcomings in other code generate issues > in coreboot. > > >> We're all interested in getting these things to the highest quality, > > It doesn't seem to me that Intel is interested in that at all. > > They're making themselves the only actor in the world capable of producing > correct platform init code for their platforms, yet they don't. My guess as > to why is that time to market is quite short. > > >> They're still actively developing the code and working to improve >> things, so in that way it's definitely better than getting a single >> source code drop that never gets updated again. > > That's a joke, right? > > Source code without updates is clearly better than no source code. > > Maybe I'm getting too old to waste my life on closed source nonsense? > > > //Peter > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
Hi Martin, I hope you are using the torque screwdriver and not tightening them beyond the recommended ft-lbs. If you go too tight, you can damage the board. Cheers, Sean On 06/23/2014 02:53 AM, Martin Roth wrote: This whole microcode issue caused us a couple of weeks of delay. Here's the basics of what I found - I don't know if any of this is fixed, I'll check with Intel and report back: There are 2 different microcode load routines, one for the BSP, and one for the APs. The BSP's routine will load the microcode without checking that the SKU is correct. The AP's loading routine won't load if the microcode SKU is wrong. Unfortunately, it doesn't report this, it just doesn't load the microcode and carries on as if nothing happened. The hang is caused due to an MSR access that isn't valid unless the microcode is loaded. Accessing this MSR hangs the APs. The system will then hang waiting for the AP init to complete. I believe you'll find that if you comment out the final FSP call, the system will boot, but you'll probably only have one core running. The issue with the correct microcode is that apparently there were no Bay Trail I SKUs released for the B0 rev - they were released as a "super-Sku" that is identified as a Bay Trail T. There is, however, for some reason, still a microcode patch available for the Bay Trail I B0/B1. I *believe* that the correct microcode patch for the B0 parts is the Bay Trail T patch that's in the FSP package. If this microcode patch isn't working for anyone on their B0, please let me know. We (Intel and Sage) had initially decided that only the B3 silicon was going to be supported for this release. I'm still not sure that wasn't the correct choice, but it was later requested to add the support for the B0 part as well. I'd really urge anyone using a B0 to just upgrade to a B3 part. On an unrelated note, after heavy use of the Bayley Bay and Bakersport boards, we noticed that the boot was halting in memory init, when nothing on the board had changed. I finally figured out that this was due to a bad board connection with the processor. Since the processors are not soldered to the board, it seems like sometimes the connection would develop issues. Tightening the adapter holding the processor to the board fixed all the issues we were having. Martin On Sat, Jun 21, 2014 at 5:37 PM, Giri wrote: Regarding below two items 1) The microcode that is being included is not a part of coreboot, so it needs to be disabled for the default build so that abuild doesn't fail. Intel wants to release the microcode as part of the FSP package and not include it in the coreboot repo so that the microcode vs FSP versions can be matched up. Microcode is not part of FSP but just consumes the pointer and length. Microcode and FSP versions doesn't need to match but the microcode needs to match the CPU on that platform. 2) The microcode that's included for the intel FSP is for B2/B3 silicon, but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later, the microcode can cause massive amounts of confusion. Please check if the microcode is loaded by reading MSR 0x8B -Giri -Original Message- From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Peter Stuge Sent: Friday, June 6, 2014 2:57 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output Martin Roth wrote: Eh, it's code... It's going to have issues and bugs. I disagree with that attitude. A platform vendor writing platform init code doesn't really have a valid excuse for producing buggy code. "Release early, release often" can't be an excuse to push the consequences of one's own shortcomings onto others. That's just poor programmer's moral. I obviously disagree with letting shortcomings in other code generate issues in coreboot. We're all interested in getting these things to the highest quality, It doesn't seem to me that Intel is interested in that at all. They're making themselves the only actor in the world capable of producing correct platform init code for their platforms, yet they don't. My guess as to why is that time to market is quite short. They're still actively developing the code and working to improve things, so in that way it's definitely better than getting a single source code drop that never gets updated again. That's a joke, right? Source code without updates is clearly better than no source code. Maybe I'm getting too old to waste my life on closed source nonsense? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreb