On 28 Dec 2018, at 00:36, Piotr Król piotr.krol@3mdeb.com wrote:
On 8/19/18 4:06 PM, John Keates wrote:
Hi,
Hi John,
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.
Qotom are definitely interesting platforms :) And there are some OEM that build on top of their designs.
I can't analyze whole your post, as probably most of people making coreboot professionally, but I have some pointers to you and would be glad to get some feedback from you if possible.
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
I'm not sure if killing ME at porting time is good idea it can cause more problems then gain at this point. I would leave it as it is to keep things stable.
Yeah, I figured I’d better start off with a working firmware first anyway, but BootGuard still prevents that AFAIK.
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.
This is normal situation, flash descriptor, ME and maybe some SMI protect access to some regions. You should have external programmer and read firmware when platform is off - that can be tricky depending on platform schematics around SPI.
What you should make sure:
- You have stock firmware version that can boot platform - this can be
just offline read that I described above, online read for sure will cause platform brick. 2. You should care about flashing only BIOS region of flash and leave ME as it is. 3. Reading offline (let's call it golden stock version) and writing offline is good first test - it is risky and may end up in brick, but that's porting work so risk have to be calculated. If platform boot after that it is very good indicator, more to that you can think about writing random binary to bios region and verify that it is not booting and finally recover with your golden stock firmware version. If platform boot after that your are good to go with development.
(…)
I did have a go at reading and writing the SPI flash offline (I’m used to embedded ARM and MIPS platforms), It’s located reasonably accessible, just take the case off and find it next to the CPU (often the RTC battery is taped on top of it). It has multiple footprint options it seems (or perhaps a socketed option), but the default SOIC-8 is easy enough to read, even with the cheap (and ever so fragile) pomona clip.
So at this point, I do have a few verified offline reads (so SMM, MMU, ME etc. don’t mess with it) which write back fine as well.
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
Probably hard to figure out without reverse engineering, schematics or experiments. The most scary thing is initial GPIO configuration which can cause hardware damage if set incorrectly. If you don't have schematics you should risk anyway - at least we do.
(…)
Yeah, for this work it is reasonable (as far as risks go). The platform doesn’t have a lot of peripherals, it seems only the SuperIO and the HDA chip have some sidecar components with attached GPIOs.
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. 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.
PEI is not important. ACPI defintely should be dumped, but if you can get back to golden stock firmware then it doesn't matter.
I got everything dumped, and I can go back, so that’s good.
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.
Here are couple problems with that hardware:
- It doesn't seem that Intel provide FSP for Broadwell-U, there is
something for Broadewll-DE: https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg 2. Always use Intel most recent FSP 3. 90% chance that your stock BIOS doesn't use FSP, this is BIOS built from Intel Reference Code that AMI gets directly 4. There is cool debug option that can wear SPI, but if you have external programmer you can dump logs to SPI and read it from there: https://mail.coreboot.org/pipermail/coreboot/2017-June/084538.html https://github.com/coreboot/coreboot/blob/master/src/console/Kconfig#L293
Ah, the SPI logging is pretty cool, didn’t know about that. I did look in to the CCA tool, which apparently is just an USB3 cable with the USB2 Data pins and VCC pin removed. This does seem to require cooperation from the ME, so probably not worth a try at this time.
Hope this will help.
The extra pointers are helpful indeed. I have started searches for ULV and mobile series single board computers that don’t have BootGuard enforcement enabled, but no luck so far. But if I find one, I can definitely continue.
Couple questions from me:
- What is the motivation behind this port?
Multiple; on one hand, I’m interested in the booting of more complex systems like x86 systems and large ARM SoCs, only scratched the surface on those, but it looks like fun.
On the other hand, I find the concept of hardware that you cannot boot with software of your own choice ridiculous, including low level boot roms and firmware. I do understand that if a large corporation has a business model based on secrets, it’s a hard problem to solve to give less than 1% of customers something they are happy with while exposing some of those secrets. Perhaps an option to get Intel to sign a FOSS ME engine with a key that is recognised by the on-die SoC/CPU boot ROM would be nice, but that is not likely to happen. Having only the on-die boot rom as a black box would be much more acceptable to me.
- Are you active in pfSense, OPNSense or any other UTM/firewall OS?
I’m active in OPNSense these days. I used to be rather active in pfSense, but the environment has gotten too toxic for me over the past years. I do have some side projects using Linux-based SDN setups on this type of hardware.
- Is this commercial activity or learning experience?
For me it is learning, but I imagine if I were to succeed, someone would be happy to make commercial use of it. Perhaps an integrator that takes Qotom whitelabel boxes and preloads them with an OS and firmware of choice. Plenty of people would like a local cache of hardware so they don’t have to wait for a china shipment (that said, Qotom usually arrives within 48hrs here in western europe), and have local people to talk to.
So on one hand, if some vendor would use it to make things better for everyone, that’d be cool. On the other hand, if a company like Sophos were to start blindly reselling Qotom boxes, slap a Sophos logo on it, preinstall the free UTM and sell it at 1000% the worth of the product, I’d probably have an opinion about that, but then again, so would most people building stuff in their spare time ;-)
As 3mdeb we are official maintainers of PC Engines and looking to support whole network appliance environment. Recently we working also on some support for Qotom based platforms.
I suspect you then have to get around the BootGuard issue, right? Because as far as I know, you cannot boot coreboot with BootGard fuses blown in enforcement mode. PC Engines is a pretty cool company, used a lot of ALIX boards in the past (the ones with the tinyBIOS) which had a few issues between versions but always turned out great in the end. I did switch to ARM based systems (often i.MX) and Intel based systems before the APU platforms became available locally because at that point, white label import became a real option.
Nice to see you guys on the list!
Best Regards,
Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
Regards, John