coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/14/2013 12:59 AM, ron minnich wrote: > On Fri, Dec 13, 2013 at 10:46 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > >> You can't have a working build on a bunch of recent hardware without >> blobs. So the assumption that you can build without blobs is false. >> Pure and simple. > > ok, so you are upset that "clueless" (your word, not mine :-) people > complain about blobs, and in response you move a bunch of .h files > from one place to another? With no real change, mind you, since they > still have to use them. Nothing is more 'free'. > > What's the point? Why not just enlighten them? I just can not understand this. > Have you tried to enlighten them? Once they boot without microcode (and they are willing to spend weeks removing the microcode just so they can try this), and they see that their system works, they don't care if they have to reboot every other week. > Again, the intent of the blobs directory was to be a place into which > to fetch binary blobs, for those things we could not include in the > main tree. The microcode .h files don't fit that category, given that > they are already in the tree. So I still don't see a point to all this > extra effort. > The fact that we have them does not necessarily mean it's kosher to include them. Whould you think differently if intel provided them as binary, not C-arrays? They are redistributable, but no modification or reverse engineering is permitted. We have CBFS to get around that. Now, since we have the trick CBFS available, we can include things like mrc.bin in the tree. We just can't link them to any stage. They end up as CBFS files that we asm("jmp") to or asm("call"). However, mrc.bin and friends reside in blobs. There is a hidden advantage to moving microcode to blobs, especially on the AMD site. AMD releases a binary container where they put not only the updates, but a CPUID to revid mapping table. Right now, that table is hardcoded in the tree, which makes its maintenance so much harder. If we add support for that container format, including microcodes is as simple as including the AMD provided file in CBFS. I'm also working on a tool to purge that container of unneeded microcode, and only leave updates relevant to the installed CPU (think boards with soldered CPU). If we want to maintain microcode updates for AMD, in their current form, (I'm thinking non-AGESA), we need to tear down that container, extract the updates, extract the mapping table, and convert them to C arrays -- every time AMD releases a new update (those updates fix important rare crashes, so we must include them as soon as possible). I don't have such a strong argument for the intel side of things. Consistency is definitely one. > Anyway, if you can convince me I'm happy to remove the -2 but I'm not > yet convinced. > There's a long way until the set of changes gets to where I envision it. The patches you so hastily rushed to block are probably the quarter marker. The idea of compiling a microcode_blob.c, so that we may later pass it through the linker, only to then objcopy the .data section, is broken. It's unnecessarily complex. It's better to just save the microcode updates as binary files (in blobs repo), then cat >> them together. It's also a micro-optimization for abuild. Or would you rather hear all this from someone clueless, who will understand nothing of what I just said, and who will also demand that you make these changes? > ron > Oh, did I mention we should enable blobs by default?

1 0

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/13/2013 11:24 PM, Gabe Black wrote: > If you don't want to hear it, ignore it. We shouldn't break things just > so people with mistaken opinions are happy, nor how long it took to > rearrange things into a broken state. > What exactly are we breaking?

3 2

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/13/2013 11:35 PM, Gabe Black wrote: > Defaults should work. Why should I have to know about a magic option > that will make my computer not crash at random? If you don't want your > computer to work that badly, you should also be motivated enough to find > the magic switch that will break it. Breaking people by default in > mysterious and unpredictable ways is a terrible idea. > And defaults work. They will continue to work. > > On Fri, Dec 13, 2013 at 9:33 PM, mrnuke <mr.nuke.me(a)gmail.com > <mailto:mr.nuke.me@gmail.com>> wrote: > > On 12/13/2013 11:30 PM, Gabe Black wrote: > > Processors which need microcode updates? > > > And how are we breaking them when the defaults don't change? You already > have the option, today, to not include microcode updates. It's just not > on by default. > > > On Fri, Dec 13, 2013 at 9:28 PM, mrnuke <mr.nuke.me(a)gmail.com > <mailto:mr.nuke.me@gmail.com> > > <mailto:mr.nuke.me@gmail.com <mailto:mr.nuke.me@gmail.com>>> wrote: > > > > On 12/13/2013 11:24 PM, Gabe Black wrote: > > > If you don't want to hear it, ignore it. We shouldn't break > things > > just > > > so people with mistaken opinions are happy, nor how long it > took to > > > rearrange things into a broken state. > > > > > What exactly are we breaking? > > > > > >

2 1

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/13/2013 11:30 PM, Gabe Black wrote: > Processors which need microcode updates? > And how are we breaking them when the defaults don't change? You already have the option, today, to not include microcode updates. It's just not on by default. > On Fri, Dec 13, 2013 at 9:28 PM, mrnuke <mr.nuke.me(a)gmail.com > <mailto:mr.nuke.me@gmail.com>> wrote: > > On 12/13/2013 11:24 PM, Gabe Black wrote: > > If you don't want to hear it, ignore it. We shouldn't break things > just > > so people with mistaken opinions are happy, nor how long it took to > > rearrange things into a broken state. > > > What exactly are we breaking? > >

2 1

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/13/2013 09:44 PM, ron minnich wrote: > I guess I don't understand why people feel better being able to build > a firmware image which will boot the CPU in a broken mode. > I have no idea either. However, what I do have is chronic fatigue from hearing clueless people complain and moan about having microcode in their coreboot. I want my time with the coreboot community to be fun. I like talking about silly mistakes that cost me hours or days. I like being made fun of when that happens. I like doing fun stuff. I like playing with hardware. I do NOT like litter from useless philosophical discussions about which blob is more acceptable than the other. I spend a few weeks now completing the change, and in exchange, I get a lifetime of peace on the matter. We all do. It's a win-win. The change will be mostly transparent to the average coreboot user. What's there not to like? Alex

2 1

EDK2 Duet (UEFI) payload for coreboot
by Scott Duplichan 14 Dec '13

14 Dec '13

The UEFI payload project I have been working on is usable now, though it has been tested on a single board only (ASRock E350M1). In a few days I will setup an AMD family 10h board and try it there. Though true flash-backed NVRAM support has not been added yet, it is quite usable with the emulated NVRAM substitute it uses. Probably the most visible effect of the emulated NVRAM is inability to maintain boot order when multiple operating systems are installed. The emulated NVRAM does allow the Windows 8 reboot to UEFI shell or UEFI setup to work. The payload has been tested with major UEFI capable operating systems (Ubuntu 13.10, Windows 7, Windows 8.1) on real E350M1 hardware and it is working well. http://notabs.org/coreboot/duet-payload/ Thanks, Scott

2 3

Re: [coreboot] PCI MMCONF on amdfam10
by Kyösti Mälkki 13 Dec '13

13 Dec '13

On 12/13/2013 03:46 AM, ron minnich wrote: > Which is why I always worry about global changes of this sort when > they can't be tested. > > Things like this that *should* work, and look very reasonable, can at > times get nasty. > > ron To keep the conversation on amdfam10: I was relying on information in commits 90ca14d7 (and its fix 79cfe7e0): Use MMCONF for all AMD family 10 CPUs. This fixes problems in AP init when multiple APs are trying to access PCI config space. All Fam10 CPUs setup and support MMCONF. That patch would have originally failed if MMCONF_SUPPORT_DEFAULT behaved they way it was meant to, to use MMCONF unless IO is explicitly defined. Kyösti > > On Thu, Dec 12, 2013 at 3:34 PM, Stefan Reinauer > <stefan.reinauer(a)coreboot.org> wrote: >> * Kyösti Mälkki <kyosti.malkki(a)gmail.com> [131212 16:02]: >>> Hi >>> >>> After commit 872c922 there is some trouble on PCI configuration >>> access with Asus M4A785-M. This could apply to other amdfam10 too, >>> although I have not yet received such reports. >>> >>> As the commit message stated, I had discovered that in the beginning >>> of ramstage all PCI configuration access used the IO (0xcf8) method >>> even though Kconfig specified MMCONF_SUPPORT_DEFAULT which should >>> imply all PCI config access is done with MMCONF unless IO is >>> explicitly requested. >> >> Not sure if this is relevant, but on i945 not all PCI devices are >> visible in MMCONF space. So enabling MMCONF_SUPPORT_DEFAULT there will >> break the system. >> >> Stefan >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] PCI MMCONF on amdfam10
by Aaron Durbin 13 Dec '13

13 Dec '13

On Thu, Dec 12, 2013 at 5:46 PM, ron minnich <rminnich(a)gmail.com> wrote: > Which is why I always worry about global changes of this sort when > they can't be tested. > > Things like this that *should* work, and look very reasonable, can at > times get nasty. To be fair, those static pci devices should have their access mode fixed (a la pci_bus_operations) to the appropriate type instead of relying on a global assumption. I think missing some corner cases is vastly different than breaking a build. That said, I have a feeling the probing method probably needs to be tweaked to accommodate these cases in some manner. > > ron > > On Thu, Dec 12, 2013 at 3:34 PM, Stefan Reinauer > <stefan.reinauer(a)coreboot.org> wrote: >> * Kyösti Mälkki <kyosti.malkki(a)gmail.com> [131212 16:02]: >>> Hi >>> >>> After commit 872c922 there is some trouble on PCI configuration >>> access with Asus M4A785-M. This could apply to other amdfam10 too, >>> although I have not yet received such reports. >>> >>> As the commit message stated, I had discovered that in the beginning >>> of ramstage all PCI configuration access used the IO (0xcf8) method >>> even though Kconfig specified MMCONF_SUPPORT_DEFAULT which should >>> imply all PCI config access is done with MMCONF unless IO is >>> explicitly requested. >> >> Not sure if this is relevant, but on i945 not all PCI devices are >> visible in MMCONF space. So enabling MMCONF_SUPPORT_DEFAULT there will >> break the system. >> >> Stefan >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] INTEL FSP support coreboot-v4.0-4966
by Marc Jones 13 Dec '13

13 Dec '13

Hi Zoran, On Thu, Dec 5, 2013 at 7:44 AM, Stojsavljevic, Zoran < zoran.stojsavljevic(a)intel.com> wrote: > Hello, > > I just noticed new patches/drops into Coreboot (Cougar Canyon 2 board > added). I did take git snapshot, and tried to see few things (what was > added there). Talking about snapshot v4.0-4966 . > > It seems that Emerald Lake 2 (EL2) and Cougar Canyon 2 (CC2) support two > slightly different concepts. I switched from EL2 to CC2 (since I have EL2 > and CC2 here in lab, but only tried EL2 board with CC2 FSP context). > Thanks for the report. Yes EL2 uses a mrc/systemagent binary contributed by Google. CC2 uses the FSP from Intel (and Sage). The FSP is new and we are still working on making the coreboot side of the interface better. > I needed to have 10+ adaptation building for CC2, and in this process I > noticed the following: > [1] CC2 has several parameters hard coded (in <chipset>); > Like? Send a patch. > [2] The new directory added: src/cpu/intel/fsp_model_206ax (there is > already model_206ax); > We would like to support both, but each binary has some different setup requirements and assumptions. [3] This directory is out of sync (does not compile), so I added IVB > microcode patches files (microcode_m2xxx_000000yy.h) and modified > microcode_blob.h file; > This should match the microcode the is available with the FSP. The date of current/best/working microcode is always an issue. > [4] Added vbios (latest 2170.dat); > [5] Did not noticed Management Engine (new concept for all other non-INTEL > embedded folks, which suddenly popped up from nowhere) addendum (path) for > CC2, which EL2 does have; > This is a chipset dependency. Even different versions of the chipset may require it or not. > [6] Did not see/find descriptor.bin definition file and path definition > (should be included somewhere); > Comes witht he FSP and/or you need to genterate it. > [7] Used standard seabios from git as payload. > > And, yes, the whole Coreboot-v4.0-4966 does correctly compile with native > gcc (NO cross-compiler) on my Fedora 18+ (Fedora 20) VM on my SNB DT: > > coreboot.rom: 8192 kB, bootblocksize 864, romsize 8388608, offset 0x400000 > alignment: 64 bytes > > Name Offset Type Size > cmos_layout.bin 0x400000 cmos_layout 1164 > pci8086,0166.rom 0x4004c0 optionrom 65536 > cpu_microcode_blob.bin 0x410500 microcode 32832 > fallback/romstage 0x4185c0 stage 31082 > fallback/coreboot_ram 0x41ff80 stage 75924 > fallback/payload 0x432880 payload 55177 > config 0x440080 raw 4426 > pci8086,1502.rom 0x441200 raw 67584 > (empty) 0x451a40 null 3335512 > fsp.bin 0x77ffc0 (unknown) 393216 > (empty) 0x7e0000 null 130072 > > Here is the question for thinking: both CC2 and EL2 choices should be > unified, to reflect one steady procedure for INTEL FSP, right? > We are trying to figure that out, but there are currently different solutions for different needs. > > I sent this email not in negative connotation, just trying to understand > how better to approach Coreboot configuration procedure. Since there are > more than few paths to be selected and IDF tool to be used to generate > descriptor.bin . > We are working on some documentation, and some also comes with the FSP. Regards, Marc -- http://se-eng.com

1 0

coreboot 4772 & PCI ROM's errors and warnings
by Gelip 12 Dec '13

12 Dec '13

I noticed a strange debug serial log. I have cloned and make crossgcc coreboot 4772 on debian 6.0.5. - if build coreboot with default payload (SeaBIOS 1.7.2.1) have no errors and warnings - if build coreboot with set payload to None then have errors and warnings: ======================================================================================== CBFS: ERROR: No file header found at 0x3fc80 - try next aligned address: 0x3fcc0. CBFS: WARNING: 'pci10ec,8139.rom' not found. CBFS: Could not find file 'pci10ec,8139.rom'. Option ROM address for PCI: 00:11.0 = f8100000 PCI expansion ROM, signature 0xf8f8, INIT size 0x1f000, data ptr 0xf8f8 Incorrect expansion ROM header signature f8f8 PCI: 01:00.0 init CBFS: ERROR: No file header found at 0x3fc80 - try next aligned address: 0x3fcc0. CBFS: WARNING: 'pci5333,8a20.rom' not found. CBFS: Could not find file 'pci5333,8a20.rom'. Option ROM address for PCI: 01:00.0 = f8000000 PCI expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x01bc PCI ROM image, vendor ID 5333, device ID 8a20, PCI ROM image, Class Code 000003, Code Type 00 Class Code mismatch ROM 00000003, dev 00030000 Copying VGA ROM Image from f8000000 to 0xc0000, 0xa000 bytes Real mode stub @00000600: 867 bytes Calling Option ROM... Unknown INT10 function 1201! int10 call returned error. 0xb102: return 0x100 ... Option ROM returned. ======================================================================================== - if build coreboot with set payload to None and manually add SeaBIOS (the same version or new) like this: ./build/cbfstool build/coreboot.rom add-payload -f build/seabios/out/bios.bin.elf -n fallback/payload -c lzma still the same errors and warnings. What is it ??? I use make distclean to test new build. Although errors WinXP boot and working OK, my NIC RTL8139 working OK

2 1

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013