coreboot December 2015

coreboot@coreboot.org

26 participants
42 discussions

by Patrick Georgi

Hey coreboot folks, people were nagging me to set up a bug tracker for the project. Last time we dicussed that, we mostly quibbled over the UI and data model (whether the tracker should feature free form vs. structured data bug entry), and that's a discussion I don't want to participate in, so I'm staying out of the decision which bug tracker it should be. My offer is: Figure out (collectively) what issue tracker is suitable for coreboot, promise you'll help keeping it clean (so it doesn't become a graveyard like our trac instance), and I'll set it up. Only four constraints as far as I'm concerned: 1. It must be somewhat CPU efficient. Funnily that rules out trac. 2. It must be maintained. I have no interest in watching out for XSS issues myself. 3. It must be OSI friendly licensed. Jira and similar "special license for open source projects we like" stuff doesn't count. 4. It must run on Linux (since that's what the server uses) It also shouldn't be too esoteric. I reserve the right to simply give up if installing the tracker involves having to figure out how to set up an S/360 emulator, then build the open source issue tracker using a K compiler that can only be found on Abandonware websites that are written in scripts (as in character sets) that I can't read. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

5 years, 2 months

Wiki Link is dead

by Gerhard Gappmeier

On the coreboot main page https://www.coreboot.org/ when you click on Wiki the link is dead: https://www.coreboot.org/Welcome_to_coreboot 502 Bad Gateway regards, Gerhard

5 years, 2 months

5 basic features provided by CSM, which SeaBIOS does provide?

by Stojsavljevic, Zoran

Hello both lists, Jiming, There are 5 basic features, provided by CSM SeaBIOS payload, and I am looking to list of these features. Could you, please, provide to me list of these features, and some description, and/or pointer to these descriptions? Thank you in advance, Zoran Stojsavljevic _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928

5 years, 2 months

Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?

by Testerman, Brett (US COM)

Ben, You are fighting all the things I had to go through 5 months ago. Not fun. Learned the hard way things like the first steppings of the processor would boot in non-descriptor mode the later ones will not. Even the docs state it one way then correct themselves a few sentences later. And that the processor will boot without a TXE image but like I said before, XDP is disabled. And good luck getting information on writing a SPI driver. The register map is there but nothing on how to use it. Closest equivalent I could find was a PXA270 which is an ARM chip but they obviously reused the IP for the silicon. We are an embedded product so things like Secure Boot does nothing but get in our way. Was finally able to get it down to just loading the 'SLIM' TXE but making no other changes. Pretty much just zeroed all the TXE setting in the FITC tool for things like the UUID and ODM ID. I did not have to configure any hash's nor do I have to issue any FMI commands. Like you say, by the time you could issue a command coreboot has long since completed. I use an Asset XDP debugger and it catches a power cycle perfectly, halting the CPU as it is about to fetch the reset vector. I didn't do the hardware design so it would take me quite a while to figure out which GPIO get mapped to the XDP port, especially since they go through a bunch of muxes. If you had something specific I could look early next week as I am out tomorrow. I know the hardware guy did try to follow all the Intel recommendations for the Hooks and such. We did not make any changes to the GPIO settings the Coreboot defaults to. We do that in the custom payload we load. Brett -----Original Message----- From: Ben Gardner [mailto:gardner.ben@gmail.com] Sent: Thursday, December 17, 2015 10:30 AM To: Testerman, Brett (US COM) Cc: coreboot Subject: Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot? ** Please note that the Sender of this email is from outside the Cobham NA IT Hub ** Hi Brett, If you don't mind, I have a few more questions about your setup. On Thu, Dec 17, 2015 at 10:25 AM, Testerman, Brett (US COM) <Brett.Testerman(a)cobham.com> wrote: > I have a custom E38xx design (Baytrail) that I ported Coreboot on to. > XDP works fine but you must install the TXE image in the boot flash > else the port is locked out. We don't need secure boot, so we are chose the 'SLIM' TXE image. Did you have to do anything to configure the TXE image, like setting FUSE_FILE_OEM_KEY_HASH_1? The Intel System Debugger indicates that the "JTAG connection was established but the target appears to have security-restricted JTAG. Please try disabling JTAG security in the platform firmware." (That was with FSP Gold v3. I haven't yet tested with FSP Gold v4. The XDP hardware is at another location, so testing is a bit difficult.) Out Intel rep says that we have to send the "Set Debug State" FMI command to the TXE engine to enable debug. The problem I ran into with that is that the FspInitEntry (Goldv4) call hides the TXE PCI device (1a.0) and it doesn't seem like I can send a FMI command without RAM first being initialized. Does any of that sound familiar? Or did it "just work" for your board? I would expect it to "just work" if secure boot was disabled. Last question about your gpio.c file: It looks like GPIO_S5[22-30] are used for XDP. Minnowmax has GPIO_S5[22] as GPIO_NC and GPIO_S5[23-30] set as GPIO_FUNC(0, PULL_UP, 20K). Is that how you configured the XDP-related pins? If not, would you mind sending you gpio.c file so I can compare? Thanks, Ben

5 years, 2 months

Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?

by Ben Gardner

Hi Brett, If you don't mind, I have a few more questions about your setup. On Thu, Dec 17, 2015 at 10:25 AM, Testerman, Brett (US COM) <Brett.Testerman(a)cobham.com> wrote: > I have a custom E38xx design (Baytrail) that I ported Coreboot on to. XDP > works fine but you must install the TXE image in the boot flash else the > port is locked out. We don't need secure boot, so we are chose the 'SLIM' TXE image. Did you have to do anything to configure the TXE image, like setting FUSE_FILE_OEM_KEY_HASH_1? The Intel System Debugger indicates that the "JTAG connection was established but the target appears to have security-restricted JTAG. Please try disabling JTAG security in the platform firmware." (That was with FSP Gold v3. I haven't yet tested with FSP Gold v4. The XDP hardware is at another location, so testing is a bit difficult.) Out Intel rep says that we have to send the "Set Debug State" FMI command to the TXE engine to enable debug. The problem I ran into with that is that the FspInitEntry (Goldv4) call hides the TXE PCI device (1a.0) and it doesn't seem like I can send a FMI command without RAM first being initialized. Does any of that sound familiar? Or did it "just work" for your board? I would expect it to "just work" if secure boot was disabled. Last question about your gpio.c file: It looks like GPIO_S5[22-30] are used for XDP. Minnowmax has GPIO_S5[22] as GPIO_NC and GPIO_S5[23-30] set as GPIO_FUNC(0, PULL_UP, 20K). Is that how you configured the XDP-related pins? If not, would you mind sending you gpio.c file so I can compare? Thanks, Ben

5 years, 2 months

Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?

by Testerman, Brett (US COM)

I have a custom E38xx design (Baytrail) that I ported Coreboot on to. XDP works fine but you must install the TXE image in the boot flash else the port is locked out. Brett From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Ben Gardner Sent: Thursday, December 17, 2015 9:17 AM To: coreboot Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot? ** Please note that the Sender of this email is from outside the Cobham NA IT Hub ** I'm trying to get the XDP debug port working with a custom board that is very similar to the Minnowmax board. Has anyone used the XDP connection with the Minnowmax board with coreboot? Thanks, Ben -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot<http://www.coreboot.org/mailman/listinfo/coreboot>

5 years, 2 months

Minnowmax: Has anyone used the XDP debug port with coreboot?

by Ben Gardner

I'm trying to get the XDP debug port working with a custom board that is very similar to the Minnowmax board. Has anyone used the XDP connection with the Minnowmax board with coreboot? Thanks, Ben

5 years, 2 months

Re: [coreboot] baytrail + fsp_baytrail

by Peter Stuge

ron minnich wrote: > > > nobody cared enough to really do the work > > > > That's the problem - not the solution. Don't build infrastructure to > > support complacency, build infrastructure to support desirable activity. > > I'm not even sure what this means :-) It means that code needs to be structured well so that it is easy and natural to consistently use good structure. As opposed to the code being less well structured and having a lot of scaffolding to compensate for that lack of structure. As the code gets messier the scaffolding grows increasingly powerful, and thus encourages doing further wrong things in new code. //Peter

5 years, 2 months

Fwd: Your stand proposal for FOSDEM 2016 has been accepted

by Carl-Daniel Hailfinger

Hello everyone, let's make this our best FOSDEM stand presence ever! https://www.coreboot.org/FOSDEM_2016 Please fill in https://www.coreboot.org/Talk:FOSDEM_2016 if you're coming. Regards, Carl-Daniel -------- Forwarded Message -------- From: FOSDEM Stands Team <stands(a)fosdem.org> To: Carl-Daniel <c-d.hailfinger.devel.2006(a)gmx.net> Subject: Your stand proposal for FOSDEM 2016 has been accepted Message-Id: <20151214195515.C04A3CB582(a)mailhost.gletsjer.net> Date: Mon, 14 Dec 2015 20:54:56 +0100 (CET) Hi Carl-Daniel, The FOSDEM stands team is glad to be able to inform you that your request for a stand for 'coreboot_flashrom' has been accepted. There will be two tables reserved for you. Like most years, we received roughly twice as many requests for stands as we have tables available. We have aimed to grant as many requests as feasible and to increase the diversity of the accepted stands. Because of this, we have unfortunately had to reduce the space available for a number of regular attendees, as well as reject some projects that have been present in previous years years. You will receive further information about what's expected of you closer to the event date. Looking forward to seeing you at FOSDEM 2016! Kind regards, Wynke Stulemeijer FOSDEM stands team

5 years, 2 months

Lenovo Carbon X1

by Gerhard Gappmeier

Hi, I want to start a port on the Lenovo Carbon X1. I'm a BIOS newbie and don't know much about chipsets, so I'll need your support here. But I've enough C programming experience to get the job done with your help (I hope). At the moment I'm collecting information about the hardware: The mainboard has two flash chips: EN25QH64: 8MB Flash MX25L3206E: 4MB Flash I know already from IRC that "Intel Corporation 3rd Gen Core processor" means Ivy bridge. That's all for now. Hopefully somebody can help me with identifying all necessary chipset info from the lspci and dmidecode output below. Then I've a lot of questions: 1.) What is the minimum configuration to get started and a linux kernel booted? northbridge, southbridge, RAM init? what else? Because the kernel can be a payload in the flash even SATA controller is not necessary, right? Advanced stuff as network boot is not necessary. 2.) From my basic understanding I believe as soon as the kernel gets executed everything else gets initialized by the kernel and the BIOS is not needed anymore. Is that right? 3.) For diagnostics I think VGA output is necessary. This board has no UART, only USB, and this would require initializing USB controller and communicating using a usb/serial converter. What do you think is the easier way for debug output? I've already read this article here: http://www.coreboot.org/VGA_support[1] And it seems like extracting the VGA ROM via the kernel works here: lspci -tv: -[0000:00]-+-00.0 Intel Corporation 3rd Gen Core processor DRAM Controller +-02.0 Intel Corporation 3rd Gen Core processor Graphics ... ls -l /sys/devices/pci0000:00/0000:00:02.0/rom -rw------- 1 root root 131072 Dec 13 12:16 /sys/devices/pci0000:00/0000:00:02.0/rom echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom cp /sys/devices/pci0000:00/0000:00:02.0/rom vgabios.bin hexdump -C vgabios.bin > vgabios.bin.hex Here are the 1st 10 lines of the vgabios hexdump: 00000000 55 aa 80 e9 78 ea 30 30 30 30 30 30 30 30 30 30 | U...x.0000000000| 00000010 30 30 40 25 e9 59 24 97 40 00 b0 0a 30 30 49 42 | 00@%.Y$.@...00IB| 00000020 4d 20 56 47 41 20 43 6f 6d 70 61 74 69 62 6c 65 |M VGA Compatible| 00000030 20 42 49 4f 53 2e 20 03 6e 00 7e 00 8c 00 8b c0 | BIOS. .n.~.....| 00000040 50 43 49 52 86 80 06 01 1c 00 1c 00 03 00 00 03 | PCIR............| 00000050 80 00 00 00 00 80 80 00 00 00 00 00 06 01 16 01 |................| 00000060 26 01 56 01 66 01 76 01 86 01 00 00 6e 03 00 c0 | &.V.f.v.....n...| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 88 00 00 c0 |................| 00000080 00 00 00 00 00 00 00 00 1a 00 37 03 00 c0 00 00 |..........7.....| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| looks promising ;-) More info about the HW comes here: lspci output: 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 96) lsusb output: Bus 002 Device 003: ID 0bdb:1926 Ericsson Business Mobile Networks BV Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 04f2:b315 Chicony Electronics Co., Ltd Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 003: ID 147e:2020 Upek TouchChip Fingerprint Coprocessor (WBF advanced mode) Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub dmidecode output: # dmidecode 2.12 SMBIOS 2.7 present. 71 structures occupying 2762 bytes. Table at 0xDAE9D000. Handle 0x0000, DMI type 134, 16 bytes OEM-specific Type Header and Data: 86 10 00 00 00 53 54 4D 20 01 01 00 00 03 01 02 Strings: TPM INFO System Reserved Handle 0x0001, DMI type 4, 42 bytes Processor Information Socket Designation: CPU Socket - U3E1 Type: Central Processor Family: Core i7

5 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2015