coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region
by Hal Martin 28 May '18

28 May '18

Hi Nico and Julius, Copying the fmd file from siemens/mc_apl1 is enough to build a coreboot image: Created CBFS (capacity = 12179416 bytes) CBFS fallback/romstage CBFS cpu_microcode_blob.bin CBFS fallback/ramstage CBFS config CBFS revision CBFS fspm.bin CBFS fsps.bin CBFS fallback/postcar CBFS fallback/dsdt.aml CBFS fallback/payload Compile IFDTOOL HOSTCC util/ifdfake/ifdfake DD Adding Intel Firmware Descriptor IFDTOOL Unlocking Management Engine File build/coreboot.pre is 16777216 bytes Writing new image to build/coreboot.pre.new CBFS coreboot.rom UPDATE-FIT CBFSLAYOUT coreboot.rom This image contains the following sections that can be manipulated with this tool: 'SI_DESC' (size 4096) 'IFWI' (size 3141632) 'COREBOOT' (CBFS, size 12179456) 'RECOVERY_MRC_CACHE' (size 65536) 'RW_MRC_CACHE' (size 65536) 'RW_VAR_MRC_CACHE' (size 4096) 'BIOS_UNUSABLE' (size 262144) 'DEVICE_EXTENSION' (size 1048576) 'UNUSED_HOLE' (size 4096) It is possible to perform either the write action or the CBFS add/remove actions on every section listed above. To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 28228 none cpu_microcode_blob.bin 0x6f00 microcode 0 none fallback/ramstage 0x6f80 stage 71536 none config 0x18740 raw 630 none revision 0x18a00 raw 575 none fspm.bin 0x18c80 fsp 364544 none fallback/dsdt.aml 0x71cc0 raw 99 none (empty) 0x71d80 null 2584 none fsps.bin 0x727c0 fsp 172032 none fallback/postcar 0x9c800 stage 17204 none fallback/payload 0xa0b80 payload 633503 none (empty) 0x13b680 null 10854680 none bootblock 0xb957c0 bootblock 32768 none HOSTCC cbfstool/ifwitool.o HOSTCC cbfstool/ifwitool (link) Built compulab/fitlet2 (Fitlet2) compulab/fitlet2 is a copy of intel/apollolake_rvp with RVP2 removed as it uses LPDDR3 and the Fitlet2 uses DDR3L (RVP1). Apparently the vendor used Oxbow Hill CRB, but this platform was never added to coreboot. The resulting image does not appear to boot, there is no output on the uart. I can inspect it with ifdtool, but not with ifwitool. Is it expected that ifwitool will not work on the coreboot generated image? Or does this indicate I've made a mistake somewhere? Thanks, Hal On Tue, May 22, 2018 at 9:04 PM, Hal Martin <hal.martin(a)gmail.com> wrote: > Hi Nico and Julius, > > Thank you for the helpful tips. I will look into the fmd files in the tree > and see if I can come up with something sensible for this board. > > I'll update you on any progress (or lack thereof). > > Cheers, > Hal > > On Sat, May 19, 2018 at 4:57 PM, Nico Huber <nico.h(a)gmx.de> wrote: > >> Hi, >> >> On 19.05.2018 02:27, Julius Werner wrote: >> > Apollolake looks quite different, and I don't really know all the >> details, >> > but somehow the reset vector is interwoven with that IFWI thing near the >> > front of the ROM. You can see an example Chrome OS Apollolake FMAP in >> > src/mainboard/google/reef/chromeos.fmd, and compare it to a normal >> Chrome >> > OS x86 FMAP like src/mainboard/google/glados/chromeos.fmd . The >> Apollolake >> > support was added by Chrome OS folks, so maybe they didn't bother >> adapting >> > the default-x86.fmd mechanism to work with it because all the Chrome OS >> > boards have their own FMAP anyway. You may be able to get further in >> your >> > build if you copy the reef/chromeos.fmd file, adapt it to your >> mainboard if >> > necessary, and then point to it with CONFIG_FMDFILE. >> >> I'm not an expert for Apollo Lake either, but I know other Intel plat- >> forms and my way around their documentation. >> >> I too believe that adding an .fmd file like Julius described, will >> fix your problem. Though, there are already some non-CrOS boards in >> the tree. Might be more worth looking at their (simpler) .fmd (e.g. >> `src/mainboard/siemens/mc_apl1/mc_apl1.fmd`). >> >> Regarding the details, I've digged around a little. Here is what I found >> out so far (stop reading here unless you really want to know, it might >> confuse you even more): >> >> Apollo Lake uses a Firmware Descriptor (IFD) like other Intel platforms, >> but the IFD's layout is used much less. One region amidst this layout >> is the IFWI. The IFWI is partitioned by other means and contains code >> for some integrated controllers and also what used to be the BIOS. The >> latter is divided into IBB and OBB. The IBB partition is used for core- >> boot's bootblock. The OBB partition for everything else in coreboot. The >> OBB is the last part of the IFWI. >> >> To make the situation even more confusing, somebody had the great idea >> to use the same term, IFWI, for something slightly different. I guess to >> separate the read-only from updateable parts better, IFWI in the notion >> of coreboot's .fmd files is the actual IFWI minus the OBB. I will refer >> to it as the RO_CORE_IFWI (might not be the worst idea to rename it like >> this in coreboot). So what happens during build (cf. `soc/intel/ >> apollolake/Makefile.inc:125`): >> >> - coreboot is provided an IFWI image (that has to contain all the >> coreboot-unrelated code for the extra chipset controllers, those >> are just passed through by our build system). >> >> - Our build system crafts the RO_CORE_IFWI with the provided IFWI: >> o The OBB is stripped off. >> o The IBB is replaced with coreboot's bootblock. >> >> - The final image is build with >> o the RO_CORE_IFWI in place of IFWI in the .fmd and >> o all other coreboot parts in their respective place in the .fmd. >> >> Looking at the `mc_apl1.fmd` again: >> >> - SI_DESC is like the Intel Firmware Descriptor. >> - IFWI is the RO_CORE_IFWI (IFWI minus OBB with replaced IBB). >> - Everything else before DEVICE_EXTENSION is the OBB. >> - DEVICE_EXTENSIONS is another partition in the IFD, that I've just >> learned about. >> >> Nico >> >> PS. This is how I would have written such .fmd (currently not compatible >> to `apollolake/Makefile.inc`): >> >> FLASH 16M { >> SI_DESC@0x0 0x1000 >> IFWI@0x1000 0xefe000 { >> RO_CORE_IFWI@0x0 0x2ff000 >> OBB@0x2ff000 0xbff000 { >> FMAP@0x0000 0x800 >> COREBOOT(CBFS)@0x800 0xb9d800 >> UNIFIED_MRC_CACHE@0xb9e000 0x21000 { >> RECOVERY_MRC_CACHE@0x0 0x10000 >> RW_MRC_CACHE@0x10000 0x10000 >> RW_VAR_MRC_CACHE@0x20000 0x1000 >> } >> BIOS_UNUSABLE@0xbbf000 0x40000 >> } >> } >> DEVICE_EXTENSION@0xeff000 0x100000 >> UNUSED_HOLE@0xfff000 0x1000 >> } >> > >

1 0

w520 coreboot
by geza herr 27 May '18

27 May '18

Hello coreboot team, i hope the following attachments can be a help of improving coreboot and reverse engineer for w520 machines. These are some dumps of my factory bios v1.45 updated in may 2018. Files can be downloaded here: https://drive.google.com/drive/folders/1ykastK9gVCQE-xbGqNU1Oly5H5tgh1UZ coreboot team you are the BEST! Have a nice day Geza Herr

1 0

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Taiidan＠gmx.com 27 May '18

27 May '18

AMD has at long last coughed up the stuff to the linux-firmware people https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git… The fam15h microcode update adds IBPB * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: YES * CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit) The question is what about the other stuff? IBRS, STIBP? This is confusing due to zero documentation on these updates from amd...Why don't they have those in this update? Would it be possible to easily add the support flags without microcode for those who use libreboot? Would it still be a good idea to add the lfence msr as rmarek mentioned? As this is all above my pay-grade I would very much appreciate one of the experts to chime in.

5 6

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by ron minnich 26 May '18

26 May '18

laptops are just about all I use, and the 238 cols on my macbook does the trick. On Fri, May 25, 2018 at 5:01 PM Vadim Bendebury <vbendeb(a)chromium.org> wrote: > On Fri, May 25, 2018 at 8:24 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > >> Am Fr., 25. Mai 2018 um 17:05 Uhr schrieb Vadim Bendebury < >> vbendeb(a)chromium.org>: >> > limiting width to 80 columns helps greatly when one wants to see several >> screens side by side. >> >> $ echo $COLUMNS >> 274 >> >> Two terminals of 120 + metadata (linenumbers, window frames, ...) fit >> well, >> and that's just a plain old Full HD display. >> I heard 4K is all the rage now ;-) >> > > one other thing I forgot to mention: I often look at this through a > terminal on my Chromebook, I know many others use laptops for work all the > time. > > -v > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Vadim Bendebury 26 May '18

26 May '18

On Fri, May 25, 2018 at 8:24 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > Am Fr., 25. Mai 2018 um 17:05 Uhr schrieb Vadim Bendebury < > vbendeb(a)chromium.org>: > > limiting width to 80 columns helps greatly when one wants to see several > screens side by side. > > $ echo $COLUMNS > 274 > > Two terminals of 120 + metadata (linenumbers, window frames, ...) fit well, > and that's just a plain old Full HD display. > I heard 4K is all the rage now ;-) > one other thing I forgot to mention: I often look at this through a terminal on my Chromebook, I know many others use laptops for work all the time. -v

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Jonathan Neuschäfer 25 May '18

25 May '18

> Who is still using a 1980's tty for coreboot development? On Fri, May 25, 2018 at 10:15:02AM +0200, Patrick Georgi via coreboot wrote: > That is, who would unbearably suffer from 132 characters per line of code? It's not just about the truly old setups with terminals that can't show longer lines. I, for example, often have two windows of about 90 characters side by side, so I am in favor of the classic 80 column limit. That said, maybe the limit should just be enforced less stringently in cases where breaking a line doesn't help readability; for example when there's a long string that can't fit within that limit, but also when there's a table-like structure in the code where two lines of 80 characters per entry clearly makes it less readable than one line of 120 characters per entry. Another point to consider is that a limited line length penalizes complexity (because indentation takes up space, too), which might be a good thing. To quote from the Linux kernel coding style[1]: Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program. Enough bike shedding from me, Jonathan Neuschäfer [1]: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by ron minnich 25 May '18

25 May '18

I've just done an exercise with clang-format and tried 80, 100, 120, and 132 column formatting on the riscv arch code, see here: https://review.coreboot.org/#/c/coreboot/+/26512/ overall, after staring at it a bit, I found 132 the most readable. I find breaking strings and folding parameters to adhere to 80 column limits very irritating. I don't think that's just me. if you look at the changes, it's not huge. In some cases, e.g. https://review.coreboot.org/#/c/coreboot/+/26512/2/src/arch/riscv/mcall.c, IMHO the result is a dramatic improvement in readability and use of vertical space. Note that in one place I turned formatting off. I don't think we want to make a habit of this, but thought the demo was useful. ron

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Vadim Bendebury 25 May '18

25 May '18

Two windows side by side is nothing, if you ask me ;) Also, IMHO having function signatures longer than 80 cols is a serious problem, it needs to be fixed, and not by widening the terminal. -v On Fri, May 25, 2018 at 8:24 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > Am Fr., 25. Mai 2018 um 17:05 Uhr schrieb Vadim Bendebury < > vbendeb(a)chromium.org>: > > limiting width to 80 columns helps greatly when one wants to see several > screens side by side. > > $ echo $COLUMNS > 274 > > Two terminals of 120 + metadata (linenumbers, window frames, ...) fit well, > and that's just a plain old Full HD display. > I heard 4K is all the rage now ;-) > > > And of course implicitly keeps the code cleaner - if so much indentation > is needed, the code is likely ripe for refactoring. > Several of our function signatures are longer than a line. > > Two levels of indentation (function level + if clause), plus > 'printk(BIOS_ERROR, "\n");' is already more than half an 80 column screen. > Breaking up messages means that they're harder to find with a git grep. > > > Regards, > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Patrick Georgi 25 May '18

25 May '18

Am Fr., 25. Mai 2018 um 17:05 Uhr schrieb Vadim Bendebury < vbendeb(a)chromium.org>: > limiting width to 80 columns helps greatly when one wants to see several screens side by side. $ echo $COLUMNS 274 Two terminals of 120 + metadata (linenumbers, window frames, ...) fit well, and that's just a plain old Full HD display. I heard 4K is all the rage now ;-) > And of course implicitly keeps the code cleaner - if so much indentation is needed, the code is likely ripe for refactoring. Several of our function signatures are longer than a line. Two levels of indentation (function level + if clause), plus 'printk(BIOS_ERROR, "\n");' is already more than half an 80 column screen. Breaking up messages means that they're harder to find with a git grep. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Vadim Bendebury 25 May '18

25 May '18

limiting width to 80 columns helps greatly when one wants to see several screens side by side. And of course implicitly keeps the code cleaner - if so much indentation is needed, the code is likely ripe for refactoring. I don't write much coreboot code, but I stare at it quite often ;) -vb On Fri, May 25, 2018 at 1:17 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > That is, who would unbearably suffer from 132 characters per line of code? > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2018