Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
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
Re: [coreboot] setting smbios values from the OS
I believe the request is about filling SMBIOS Table Type 1 – System Information. Fields like Manufacturer, Product Name, Version, Serial Number, UUID, SKU Number, Family…. Some fields are unique per platform / system like Serial Number, UUID. -Giri From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of ron minnich Sent: Friday, June 20, 2014 11:24 PM To: Patrick Georgi Cc: coreboot Subject: Re: [coreboot] setting smbios values from the OS On Fri, Jun 20, 2014 at 11:20 PM, Patrick Georgi patr...@georgi-clan.de mailto:patr...@georgi-clan.de wrote: In the end, I pose the question why a serial number must be exported to the OS in the first place - this looks like a potential privacy issue to me, while doing nothing for servicing the part (if it's sent back, read the bar code). There I also agree. I don't like electronically readable serial numbers in general on computers. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
