<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi, <div class=""><br class=""></div><div class="">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.</div><div class="">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).</div><div class=""><br class=""></div><div class="">Looking at the coreboot archives, this board might have been mentioned before: <a href="https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html" class="">https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html</a> but that was HTML formatted in an attachment for some reason.</div><div class=""><br class=""></div><div class="">Board specs:</div><div class=""><br class=""></div><div class="">- CPU: i5-5250U</div><div class="">- SuperIO: IT8784E-I <br class="">- HDA: ALC662</div><div class="">- Flash: 8MByte Winbond SPI SOIC8 (but flashrom detects it as opaque when using internal programmer on-device, works correctly using external SPI flasher)</div><div class="">- 4x Intel I211 Ethernet controllers</div><div class=""><br class=""></div><div class="">more specifically, inteltool sees:</div><div class=""><br class=""></div><div class="">CPU: ID 0x306d4, Processor Type 0x0, Family 0x6, Model 0x3d, Stepping 0x4<br class="">Northbridge: 8086:1604 (5th generation (Broadwell family) Core Processor ULT)<br class="">Southbridge: 8086:9cc3 (unknown)<br class="">IGD: 8086:1626 (unknown)</div><div class=""><br class=""></div><div class="">Linux itself sees it as Wildcat Point-LP and Broadwell-U which makes sense.</div><div class=""><br class=""></div><div class="">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):</div><div class=""><br class=""></div><div class="">MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1<br class=""><br class="">ME Status : 0x1e040185<br class="">ME Status 2 : 0x10522106<br class=""><br class="">ME: FW Partition Table : OK<br class="">ME: Bringup Loader Failure : NO<br class="">ME: Firmware Init Complete : NO<br class="">ME: Manufacturing Mode : NO<br class="">ME: Boot Options Present : NO<br class="">ME: Update In Progress : NO<br class="">ME: Current Working State : Normal<br class="">ME: Current Operation State : Bring up<br class="">ME: Current Operation Mode : Security Override via Jumper<br class="">ME: Error Code : No Error<br class="">ME: Progress Phase : BUP Phase<br class="">ME: Power Management Event : Clean Moff->Mx wake<br class="">ME: Progress Phase State : 0x52</div><div class=""><br class=""></div><div class="">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.</div><div class="">There are exposed pads near the Realtek ALC chip which makes it really easy to pull GPIO33 to DVDD and disable flash descriptor security. </div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.</div><div class="">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:</div><div class=""><br class=""></div><div class="">- 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</div><div class="">- there is fadt.c which seems rather generic as well. </div><div class="">- gpio.h is probably depending on the PCH used? Seems to be generic for this PCH as well</div><div class="">- 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</div><div class="">- 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</div><div class="">- romstage.c initialises the GPIOs does some PEI data copy/memset and then romstage_common (which probably is around or before the CAR stage?)</div><div class="">- acpi/mainboard.asl is empty, not sure what part of the existing ACPI I should dump in there</div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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 write it into a new mainboard definition.</div><div class="">I’ll probably need to get the GbE region from the old firmware, ME too, but what other parts of data (ACPI tables? PEI data?)I need to get and how to fill out that data into the mainboard definition isn’t very clear to me.</div><div class=""><br class=""></div><div class="">This device has a GPIO header, and two serial ports (one external DB9, one internal header), so getting debug data out should be possible, but just randomly building an image and flashing it in to the SPI chip probably gets me nothing until I have at least configured the serial port for coreboot to spit out debug data. I’m not sure if I need to get the FSP from Intel or if I should extract the one from the current firmware.</div><div class=""><br class=""></div><div class="">Any guidance would be appreciated.</div><div class=""><br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">Regards,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">John</div>
</div>
<br class=""></div></body></html>