[coreboot] Coffee Lake FSP Released

[Desimone, Nathaniel L]

Hi All,

Intel is pleased to announce that Coffee Lake FSP is now available on 
https://github.com/IntelFsp/FSP. In addition, the previously discussed 
reorganization to move all FSP binaries in the master branch has been completed.

With Best Regards,

Nate

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

[John Keates]

Hi, 

I’m new at the board porting game but I’m interested in making a port for a 
single board computer that is running very similar hardware to the Librem 13 
laptop and the Google Pixel 2015.
It seems this board is also rather close to Intel’s own Eval Kit  hardware 
setup, both in hardware and software regard (almost bare defaults AMI Aptio 
firmware).

Looking at the coreboot archives, this board might have been mentioned before: 
https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html 
 but that 
was HTML formatted in an attachment for some reason.

Board specs:

- CPU: i5-5250U
- SuperIO: IT8784E-I 
- HDA: ALC662
- Flash: 8MByte Winbond SPI SOIC8 (but flashrom detects it as opaque when using 
internal programmer on-device, works correctly using external SPI flasher)
- 4x Intel I211 Ethernet controllers

more specifically, inteltool sees:

CPU: ID 0x306d4, Processor Type 0x0, Family 0x6, Model 0x3d, Stepping 0x4
Northbridge: 8086:1604 (5th generation (Broadwell family) Core Processor ULT)
Southbridge: 8086:9cc3 (unknown)
IGD: 8086:1626 (unknown)

Linux itself sees it as Wildcat Point-LP and  Broadwell-U which makes sense.

It has a running ME, but there is an unpopulated header (ME1) which when 
shorted seems to kill it or put it in manufacturing mode (soldered in a pin 
header and plugged in a jumper):

MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1

ME Status   : 0x1e040185
ME Status 2 : 0x10522106

ME: FW Partition Table  : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode  : NO
ME: Boot Options Present: NO
ME: Update In Progress  : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Security Override via Jumper
ME: Error Code  : No Error
ME: Progress Phase  : BUP Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State: 0x52

When not using the jumper, flashrom can’t read anything using the internal 
programmer mode, but when plugging the jumper in, it can read it. Output is not 
the same as reading the SPI flash chip offline externally, so some of the flash 
it probably still hidden by the PCH as it always does.
There are exposed pads near the Realtek ALC chip which makes it really easy to 
pull GPIO33 to DVDD and disable flash descriptor security. 

So far so good, the hardware has easy-to-reach points to get to the flash, ME 
jumper and PCH straps. The firmware isn’t very custom, and neither is the board 
(except the four ethernet controllers/ports).

My next steps were: cp -R the Purism directory to Qotom, remove all the 
Librem15 stuff, rename the Librem13 to Q3XXG4 and remove the EC references as 
this board doesn’t have an EC.
At this point, I’m not sure what to do next, besides the text in board_info.txt 
(both the vendor directory and the variant directories) I’ll probably have to 
make sure:

- acpi_tables.c has the correct tables, unless I can use the (generic looking) 
contents the Librem 13 uses, which doe acpi_init_gnvs, and 
acpi_create_madt_lapics + acpi_create_madt_ioapic
- there is fadt.c which seems rather generic as well. 
- gpio.h is probably depending on the PCH used? Seems to be generic for this 
PCH as well
- hda_verb.c seems to relate to the audio system, but I don’t care about it all 
that much at this time. The Librem 13 uses the ALC269 which has some 
differences to the ALC662, configuring it wrong probably just makes the chip 
sad and audio pin routing not work
- mainboard.c contains mainboard_enable and some calls for the GMA chip 
(install_intel_vga_int15_handler and some constants), probably the same accross 
this broadwell series
- romstage.c initialises the GPIOs does some PEI data copy/memset and then 
romstage_common (which probably is around or before the CAR stage?)
- acpi/mainboard.asl is empty, not sure what part of the existing ACPI I should 
dump in there

I turned the board into a variant, because Qotom has a number of boards that 
mostly differ in i3 vs i5 and more ethernet ports vs. more serial ports models. 
I named the variant q3xxg4 but I think we can do better as the PCB has a 
revision number printed on it, indicating more variants.
It looks like I’ll need to build some sort of devicetree.cb, perhaps by hand or 
converted from a ACPI dump from a running system? Then there is pei_data.c 
which seems to set the specifics for the hardware, the labels and locations.
While it is pretty close to the Librem 13 there as well (USB3 ports, USB2 
ports) some of the locations need to be changed, and the camera, bluetooth, and 
speakers removed). Not sure how this relates to what is in the device tree and 
any *.asl files.

The old wiki and it’s porting guide isn’t up to date as far as I know, but I 
haven’t found a new guide or set of docs that shows how to read/source 
information from a running system and 

Re: [coreboot] USB cannot work

[Sumo]

USB works a charm using CorebootPayloadPkg from Tianocore/EDK2 instead of
using GRUB2 as payload (you can use grub anyway to load linux later on, or
use any other bootloader without sticking this in the SPI flash image).


Em qua, 22 de ago de 2018 às 07:45, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> escreveu:

> Hi Nico,
>
> Confused.
> 1. I saw " pch: usb_xhci_init" in the boot up log and I think xHCI
> controller was initialized by coreboot
> 2. I have used coreboot with grub for Intel Rangeley and BDX-DE platform,
> the USB interface were working with xHCI controller. That means grub has
> its own xHCI driver.
> 3. I am trying u-boot as payload now.
>
> Sorry I really don't well understand coreboot and grub :P
>
> -Hilbert
>
> -Original Message-
> From: Nico Huber [mailto:nico.hu...@secunet.com]
> Sent: Wednesday, August 22, 2018 4:38 PM
> To: Hilbert Tu(杜睿哲_Pegatron); coreboot@coreboot.org
> Subject: Re: [coreboot] USB cannot work
>
> Hi Hilbert,
>
> Am 22.08.18 um 03:24 schrieb Hilbert Tu(杜睿哲_Pegatron):
> > Maybe you are right. But as I know, CRB Harcuvar is one of supported
> > board of Coreboot and it includes xHCI controller and USB interfaces.
>
> Harcuvar is indeed supported by coreboot. But coreboot only initializes
> the hardware up to a point where an OS or bootloader can use it. The OS
> or bootloader still needs its own driver for the hardware. This is very
> different as in the legacy BIOS/UEFI case (a BIOS would provide a driver
> but coreboot doesn't).
>
> So if you want to use GRUB as a coreboot payload and use USB, GRUB needs
> its own driver for the xHCI. I would first try to confirm if or if not
> the xHCI works with other payloads (e.g. SeaBIOS, Tianocore, libpayload
> based) or an OS.
>
> Nico
> This e-mail and its attachment may contain information that is
> confidential or privileged, and are solely for the use of the individual to
> whom this e-mail is addressed. If you are not the intended recipient or
> have received it accidentally, please immediately notify the sender by
> reply e-mail and destroy all copies of this email and its attachment.
> Please be advised that any unauthorized use, disclosure, distribution or
> copying of this email or its attachment is strictly prohibited.
>
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB cannot work

[杜睿哲_Pegatron]

Hi Nico,

Confused.
1. I saw " pch: usb_xhci_init" in the boot up log and I think xHCI controller 
was initialized by coreboot
2. I have used coreboot with grub for Intel Rangeley and BDX-DE platform, the 
USB interface were working with xHCI controller. That means grub has its own 
xHCI driver.
3. I am trying u-boot as payload now.

Sorry I really don't well understand coreboot and grub :P

-Hilbert

-Original Message-
From: Nico Huber [mailto:nico.hu...@secunet.com]
Sent: Wednesday, August 22, 2018 4:38 PM
To: Hilbert Tu(杜睿哲_Pegatron); coreboot@coreboot.org
Subject: Re: [coreboot] USB cannot work

Hi Hilbert,

Am 22.08.18 um 03:24 schrieb Hilbert Tu(杜睿哲_Pegatron):
> Maybe you are right. But as I know, CRB Harcuvar is one of supported
> board of Coreboot and it includes xHCI controller and USB interfaces.

Harcuvar is indeed supported by coreboot. But coreboot only initializes
the hardware up to a point where an OS or bootloader can use it. The OS
or bootloader still needs its own driver for the hardware. This is very
different as in the legacy BIOS/UEFI case (a BIOS would provide a driver
but coreboot doesn't).

So if you want to use GRUB as a coreboot payload and use USB, GRUB needs
its own driver for the xHCI. I would first try to confirm if or if not
the xHCI works with other payloads (e.g. SeaBIOS, Tianocore, libpayload
based) or an OS.

Nico
This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB cannot work

[Nico Huber]

Hi Hilbert,

Am 22.08.18 um 03:24 schrieb Hilbert Tu(杜睿哲_Pegatron):
> Maybe you are right. But as I know, CRB Harcuvar is one of supported
> board of Coreboot and it includes xHCI controller and USB interfaces.

Harcuvar is indeed supported by coreboot. But coreboot only initializes
the hardware up to a point where an OS or bootloader can use it. The OS
or bootloader still needs its own driver for the hardware. This is very
different as in the legacy BIOS/UEFI case (a BIOS would provide a driver
but coreboot doesn't).

So if you want to use GRUB as a coreboot payload and use USB, GRUB needs
its own driver for the xHCI. I would first try to confirm if or if not
the xHCI works with other payloads (e.g. SeaBIOS, Tianocore, libpayload
based) or an OS.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot