coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

by A. Veek

1 year, 11 months

KGPE-D16/KCMA-D8 TPM support?

by Taiidan＠gmx.com

Does anyone know what TPM's are compatible? I also want to know what coreboot's tpm support is like these days, such as how can you perform an erase/reset like one could with a standard OEM bios. - Thanks in advance

3 years, 1 month

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

3 years, 2 months

Berlin Usergroup Meeting 10. August Thursday (different location)

by Alexander Couzens

tldr; 10.08.2017 18:30 (open end) AfRA (different location!) Hi, the Berlin Usergroup Meeting in August will taken place on 10.08.2017 in the rooms of the Department Of Redundancy Department (AfRA). Abteilung für Redundanz Abteilung Margaretenstraße 30 10317 Berlin https://afra-berlin.de/ best, lynxis Ps. If you want to flash your laptop, send me a notice in advance. Certain things might need to prepared for your device. -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 years, 2 months

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?

by Nico Huber

On 10.08.2017 16:36, Zheng Bao wrote: > Thanks. Your advice is quite helpful. > > > I got the BMP and BSF, created a vBIOS which enables the DDI2 as DP. The vBIOS has been > > validated by IBV(AMI) BIOS. > > > But the VBIOS can not enable DDI2 in Coreboot. I assume I still miss something. There used to be a priority list which display is preferably initia- lized. It was in a weird notation LFP (local flat panel) would be the eDP port and EFP2 (external flat panel 2) might be DDI2. Some- where you have to set that EFP2 is preferred, I suppose. (All what I remember from an Ivy Bridge VBT.) Nico > > > Zheng > > ________________________________ > From: Nico Huber <nico.h(a)gmx.de> > Sent: Wednesday, August 9, 2017 6:29 PM > To: Zheng Bao; coreboot(a)coreboot.org > Subject: Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled? > > On 08.08.2017 05:39, Zheng Bao wrote: >> In text mode, >> only one display can be enabled. >> >> >> Can this enabled display port be DDI1 or DDI2? >> >> I just extracted VBIOS from BIOS provided on board. I assume the display ports are enabled based on the board settings. >> >> Can I just set register "gpu_panel_port_select" = "2" to enable DDI1? > > No, unfortunately not. This setting only affects the panel power sequen- > cer (i.e. which port needs special care because it hosts a panel whose > power is controlled by us). It shouldn't affect the VBIOS. > > Again, the VBIOS has many options, set in the binary. I know free tools > to dump them partially, but none to set them. The regular way is to ask > Intel for their Binary Modification Program (BMP, may be compatible with > Intel's Binary Configuration Tool [1]) *and* a description file for the > Video BIOS Table format (.bsf IIRC). That .bsf file is specific to the > chipset generation (I can't find one for Broadwell, sadly), though, one > for another generation might work too. Sometimes these files can be > found in graphics driver packages or FSP [2]. > > If you happen to get the Intel tool running, I advice to double check > the result in a hex editor (e.g. there should be only the change you > made, plus about two checksums). > > Nico > > [1] https://github.com/IntelFsp/BCT > [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/BCT> > > GitHub - IntelFsp/BCT: Binary Configuration Tool for Intel ...<https://github.com/IntelFsp/BCT> > github.com > BCT - Binary Configuration Tool for Intel(R) FSP > > > [2] Here is one for Kabylake (the closest I could find, might be > incompatible though): > > https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/… > [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/…> > > IntelFsp/FSP<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/…> > github.com > Repository of FSP binaries posted by Intel > > >

3 years, 2 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, 2 months

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

by Taiidan＠gmx.com

I can't download the .pdf file for some reason (maybe the tla's got to it?) http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf can someone send it to me? Thanks Thoughts: Sad this is still not an actual method of disablement, but it doesn't really matter as anyone who buys *new* x86 hardware is still supporting wintel's development of newer and better anti-features, DRM and surveillance technology - one that can't even be me-cleaner/hap/etc nerfed will be released some day. I wish people spent their energy popularizing owner controlled arches instead of beating a dead horse. While IBM also makes surveillance tech they make POWER which as the last performance owner controlled arch that sells for attainable prices goes a long way to offset that. Heres to hoping IBM starts selling POWER workstations... I find it hard to believe that the NSA uses made in china intel stuff with ME chips present for their high security stuff (hap nerfed or not), I imagine top secret things are done on POWER (which has a USA cpu fab and no black boxes).

3 years, 2 months

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, 2 months

Re: [coreboot] REPLY: INT 13H

by Peter Stuge

Zoran, Vincenzo, BIOS and UEFI have higher privilege in the system than the OS kernel, which has higher privilege than userland processes, which have higher privilege than the user. Any component with higher privilege can override, circumvent or contradict parts of the system and users with lower privilege levels. BIOS is x86-specific. UEFI is arguably not technically superior to BIOS. UEFI has sadly infected other platforms than x86. Interrupt services were introduced with the BIOS, and will continue to always be available on x86 platforms, for compatibility. Compatibility is the only actual value of x86. UEFI on x86 does not neccessarily have to, but in practice generally does include a CSM, which provides BIOS-compatible interrupt services also on systems with UEFI. Regardless of whether that's a 32 or 64 bit UEFI, the CSM always provides the legacy 16 bit interface. Vincenzo, if you are creating a secure system, you must first establish what is secure *enough* for your use case. Risk assessment and a threat model are essential, or you will never reach a working reliable system, because they define your goal. Security issues can exist pretty much everywhere, so an "ideal" secure system is not very practical. //Peter

3 years, 2 months

Unable to build futility on 32-bit userspace

by Paul Menzel

Dear coreboot folks, Trying to run `make test-abuild` on my system with a 32-bit userspace, it looks like quite some boards require the program futility from `util/futility`, but that fails to build with the error below. ``` /dev/shm/coreboot/util/futility(master) $ git describe 4.6-1292-g5bf3457bc4 /dev/shm/coreboot/util/futility(master) $ LANG= make MAKE futility/build/futility/futility unset CFLAGS LDFLAGS; make -C /dev/shm/coreboot/3rdparty/vboot \ BUILD=/dev/shm/coreboot/util/futility/build \ CC="cc" \ V= \ /dev/shm/coreboot/util/futility/build/futility/futility make[1]: Entering directory '/dev/shm/coreboot/3rdparty/vboot' CC futility/futility.o CC futility/cmd_dump_fmap.o CC futility/cmd_gbb_utility.o CC futility/misc.o CC futility/ryu_root_header.o CC futility/cmd_bdb.o CC futility/cmd_create.o CC futility/cmd_dump_kernel_config.o CC futility/cmd_load_fmap.o CC futility/cmd_pcr.o CC futility/cmd_show.o CC futility/cmd_sign.o CC futility/cmd_validate_rec_mrc.o CC futility/cmd_vbutil_firmware.o CC futility/cmd_vbutil_kernel.o CC futility/cmd_vbutil_key.o CC futility/cmd_vbutil_keyblock.o CC futility/file_type.o CC futility/file_type_bios.o CC futility/file_type_rwsig.o CC futility/file_type_usbpd1.o CC futility/vb1_helper.o CC futility/vb2_helper.o CC futility/bdb_helper.o GEN gen/futility_cmds.c CC gen/futility_cmds.o CC cgpt/cgpt_create.o CC cgpt/cgpt_add.o CC cgpt/cgpt_boot.o CC cgpt/cgpt_show.o CC cgpt/cgpt_repair.o CC cgpt/cgpt_prioritize.o CC cgpt/cgpt_common.o CC futility/dump_kernel_config_lib.o make[1]: *** No rule to make target '/dev/shm/coreboot/util/futility/build/host/arch/i686/lib/crossystem_arch.o', needed by '/dev/shm/coreboot/util/futility/build/libvboot_util.a'. Stop. make[1]: Leaving directory '/dev/shm/coreboot/3rdparty/vboot' Makefile.inc:4: recipe for target '/dev/shm/coreboot/util/futility/build/futility/futility' failed make: *** [/dev/shm/coreboot/util/futility/build/futility/futility] Error 2 ``` I haven’t tested this yet with a 64-bit userspace, but assume that works. Does somebody have a fix? Thanks, Paul

3 years, 2 months

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2017