coreboot July 2017

coreboot@coreboot.org

54 participants
131 discussions

by A. Veek

1 year, 9 months

Unable to fetch from git server: `fatal: protocol error: bad pack header`

by Paul Menzel

Dear coreboot administrators, Currently, I am unable to fetch the newest commits/objects(?) from the coreboot git server. ``` $ LANG=C git fetch -vv origin […] have ccbaabe5cf6b7eaa20fc323858680a404383537b got ack 3 dee643a360ad75787f2982a013c62a4d49352121 got ack 3 a1de1a0810892c3c3a22ed6e2868fbef3bde8134 got ack 3 6a720e16e7e966b034c462242ccdf99e371a1ad7 got ack 3 5d5fb1402be06cacc45d4785201b719e8c3501d1 got ack 3 eb9b2c8105642ba99c34bd727e26483ffc6a0b57 got ack 3 9e882dfff180a75c28a01c49d80e27f545bddb3a got ack 3 26ee056a55ee835a9c3bfc8b18854cb121e9371c got ack 3 27c8b82d09083e1733bcd60bb42fc52693615ce8 got ack 3 fec58518a57f67e6e1186a573503ccaec7bcf8e6 got ack 3 4d4286faa0b5e134c71c65e0e3a3a7480ca0d79d got ack 3 907a0831fb4ac4dc491656d68191274411c65944 got ack 3 30796a481fb752d63bb9b2f939595a29cb18c823 got ack 3 bdcf664a03ef6a4a17b1b367c9ab2fbf34aea244 got ack 3 4be4ad343aa40deaf627ef02da7c07dfcad47b6c got ack 4 91ec3f1264a85aa57715e059276d96bfbc178c80 done got ack (4) ccbaabe5cf6b7eaa20fc323858680a404383537b got ack (1) 4be4ad343aa40deaf627ef02da7c07dfcad47b6c fatal: internal server error remote: internal server error fatal: protocol error: bad pack header ``` Aaron reported the same problem in the IRC channel some days ago, and I remember having this problem some months ago too. Could you please take a look on the server? Kind regards, Paul

2 years, 12 months

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

3 years

About Paging, Realmode and what is going on

by Philipp Stanner

Dear folks and techpriests, the more I want to contribute and learn about low-level-code the less I understand, it seems. 1. cb switches the CPU immediately to Protected Mode, yet Payloads like seaBIOS work in Real Mode. Does coreboot switch the CPU always back to RM before jumping to the payload? 2. When CB switches to PM - who generates and administrates the Page Tables and where? 3. Gustavo Duarte writes <http://duartes.org/gustavo/blog/post/how-computers-boot-up/> that GRUB switches from protected mode to real mode and vice versa all the time to address >1MiB of RAM and also use the BIOS-calls. If this is true using GRUB as payload would not work, as GRUB needs to call the non-existent BIOS, right? 4. Once CB is in PM it can't access physical addresses anymore? It doesn't need to, too? 5. PM means RAM-access is only possible through virtual addresses which are translated by the MMU using the Page Tables. This question is similar to [2.]: If coreboot generates the Page Tables and the payload would start in PM as well (is this even possible? At least the Linux-Kernel has entry points for RM and PM) this would mean the payload needs to use the Page Tables generated by CB. That wouldn't be a problem as they're linked in the register CR3 anyways? And an unimportant bonus question: * Why does every modern CPU still start in RM? I do get the compatibility problem, but on the other hand: Do you need it for anything beside booting MS-DOS on your Ryzen? Is it really impossible for AMD and Intel to create a new CPU-generation with the x86-instruction set without RM, 16-bit-registers and 20-bit-mode registers like CS, SS etc. No modern OS uses bios calls. No CPU is ever switched to RM again after booting up. They should get rid of this old stuff. Would be cool if someone could put this in its true light. Thanks, Philipp

3 years

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

by Daniel Kulesz

Hi, I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line: > allow_config_restore = 0; However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables? Cheers, Daniel P.S. Hope this time I've set the Reply-To header correctly. > On 03/02/2017 02:17 PM, Paul Menzel wrote: > > Dear Arthur, dear Timothy, > > > > > > Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson: > >> On 03/02/2017 01:30 PM, Arthur Heymans wrote: > >>> Paul Menzel writes: > >>> > >>>> I think most of the time is spent in RAM initialization. > >>>> > >>>> 1. Do board owners with similar amount of memory (independent of the > >>>> board) have similar numbers? > >>>> 2. What are the ways to improve that? Is it possible? For example, can > >>>> the modules be probed in parallel (if that isn?t done already)? > >>>> > >>> > >>> I'm not the right person to answer this since I don't know this > >>> code/hardware that well, but on modern Intel hardware native code uses > >>> the MRC cache to store dram training results and restore those on > >>> next boots (and resume from suspend) if no change in dimm configuration > >>> was detected. > >>> > >>> Maybe something like this could also be applied here (or maybe it's already > >>> the case since it includes code to access spi flash)? > >> > >> Yes, this is already implemented as an option, and it does a fairly > >> decent job of reducing training overhead to almost nothing, > > > > Interesting. What option is that? > > > > Also, besides the file `s3nv` I don?t see anything else in CBFS. Where > > is the training data cached? > > That's it. The cache is mandatory for S3 resume, and optional at boot. > > That being said, the pathways are present but are deactivated due to > historical instability and are not tied in to an nvram variable at this > time. If you want to test, you'll need to edit the source file > "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see > a FIXME comment and this line: > > allow_config_restore = 0; > > Comment that line out and recompile to test. I strongly suggest running > memtest across multiple warm and cold boots (and reboots) before > determining the functionality is stable enough for use.

3 years, 1 month

ASUS KGPE-D16 Automated Test Failure [master]

by Raptor Engineering Automated Coreboot Test Stand

The ASUS KGPE-D16 fails verification for branch master as of commit ba973bd2de8bf91cc83431333519124bf0f1fd72 The following tests failed: BOOT_FAILURE Commits since last successful test: ba973bd util/abuild: Set exit status on failure 6c1c9d5 Update vboot submodule to upstream master 8f1e1bd Update arm-trusted-firmware submodule to upstream master See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

3 years, 1 month

Len. X1 carbon (3460) Graphics init.

by Jo

Hello, im currently following the "Build_Howto" instructions for Coreboot for a Lenovo X1 Carbon 1gen (3460) and do have a Question: Do ich have to check "Use native Graphics init", and if not, which one is the correct configuration? Sorry for my horrible english, cheers and greetings from Germany Jo

3 years, 1 month

Re: [coreboot] Broadwell-U hangs at VGA init

by Matt DeVillier

you want to extract the refcode blob as so: cbfstool shellball.rom extract -r BOOT_STUB -n fallback/refcode -f refcode.elf -m x86 then add it into your build On Mon, Jul 31, 2017 at 8:43 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > Thanks. That really helps. > > > About the REFCODE_BLOB, the BLOB I extracted from ball-rom is BIN, > instead of ELF which is required by current CBFS and rmodule in source. > (And revision in ball-rom is not in main tree of repository.) > > Any idea to get REFCODE_BLOB? > > > Thanks. > > > Zheng > ------------------------------ > *From:* Nico Huber <nico.huber(a)secunet.com> > *Sent:* Monday, July 31, 2017 10:52 AM > *To:* Zheng Bao; coreboot(a)coreboot.org; Matt DeVillier; > stefan.reinauer(a)coreboot.org > *Subject:* Re: [coreboot] Broadwell-U hangs at VGA init > > Hi Zheng, > > On 30.07.2017 16:13, Zheng Bao wrote: > > I have got the mrc.bin and mem init has got passed. > > Now the new problem is that it hangs at VGA init. > > > > static void igd_setup_panel(struct device *dev) > > { > > config_t *conf = dev->chip_info; > > u32 reg32; > > > > /* Setup Digital Port Hotplug */ > > reg32 = gtt_read(PCH_PORT_HOTPLUG); <------- It hangs here. > > if (!reg32) { > > reg32 = (conf->gpu_dp_b_hotplug & 0x7) << 2; > > reg32 |= (conf->gpu_dp_c_hotplug & 0x7) << 10; > > reg32 |= (conf->gpu_dp_d_hotplug & 0x7) << 18; > > gtt_write(PCH_PORT_HOTPLUG, reg32); > > } > > > > It turns out as soon as i access VGA bar0+0xc4030, it hangs. > > while accessing bar0 + 0xa00a is ok. > > sounds like the PCH part of the display engine isn't operational (pro- > bably not all, but most register offsets with bit 19 set reside in the > PCH). There are few steps to enable it [1], yet the Broadwell port seems > to rely on the blob to do it. The datasheet [2] suggests that the same > settings should be done for Broadwell too, but I can't find it in the > source. So that leads to the conclusion: You forgot to add the second > blob (HAVE_REFCODE_BLOB, it's BS, it's annoying, but you need it). > > That publicly documented settings move from the open source code into > blobs is a very bad sign, IMO. Now, anybody tell me again, that things > with Intel are getting better and they might become more open (the sta- > tistics seem to say the opposite: the blobs get bigger, weirder, take > over more responsibilities _and_ do a lot of stuff we already had open > source for earlier platforms). > > Nico > > [1] src/southbridge/intel/lynxpoint/lpc.c:725 > [2] Intel Document Number: 330837 >

3 years, 1 month

Re: [coreboot] Digging Into The Core of Boot

by Taiidan＠gmx.com

I thought SMI/SMM was disabled in the majority of coreboot ports?

3 years, 1 month

Digging Into The Core of Boot

by Shawn

Slide: https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoT… Speaking of attack surfaces reduction at runtime, this script might be a workaround: https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/scri… https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs… Have fun! -- GNU powered it... GPL protect it... God blessing it... regards Shawn

3 years, 1 month

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2017