Librem coreboot Utility Script: usage, discussion, and help

Firmware Coreboot
61

that is possible via menuconfig

you can just build from Purism’s branch as well - see below

sounds like a SeaBIOS bug to me

  • run Purism coreboot utility script
  • choose option to build from source
  • proceed thru menus until prompted to flash, then choose N
  • exit script
  • cd coreboot
  • cp configs/config.librem_mini_v2-uefi .config
  • make menuconfig
  • change HT and other configs as desired; save and exit menuconfig
  • rm -rf ./build; make
  • flash compiled ./build/coreboot.rom using flashrom
62

Using coreboot_util.sh (which works when I choose prebuilt images) takes me into something called detached HEAD state after cloning into ‘coreboot’
(…)
Resolving deltas (…) done
Note: switching to ‘7e8b…9c’
You are in a detached HEAD mode, you can look around (…)
Please configure your name and email in git:
(…)

I have no idea what to do about this…

63

I’m not sure what you mean. The build from source option does checkout the current branch in a detached head state, this is not a problem in any way. Are you say it’s stalling or waiting for input in some way? If so, your repo might be in a bad state, in which case blowing it away and starting from scratch might be easiest.

Are you building under PureOS or?

64

Hmm. Building from live PureOS(updated) booted from your UEFI firmware. I’m not well versed in building anything from source so I didn’t know what to do when the script stopped in detached head mode (its not clear what it expects me to do)

I did not choose a branch or anything like that. Just pressed 1-2-3-4 (as needed) when the script asked me to choose something.

So it is waiting for input, should I type in checkout?

Edit: After that message pops up it seems like nothing is happening (?). Then it abruptly takes me to the normal terminal state where I can see “pureos@pureos: ~$”
Edit2: Oh I think I’m messing it up when I try to do stuff at that stage. Sorry my bad.
Anyway, am I going to make a UEFI version of this like the one on your website?

65

if you follow my instructions, yes

66

I’m getting there, hang on. I got this error after I did rm -rf ./build; make

Payloads/…/tianocore/build/UEFIPAYLOAD.fd no such file or directory
E: could not load file ‘payloads/…tianocore/tianocore/build/UEFIPAYLOAD.fd
make: [makefile.inc:1105: build/coreboot.pre] error 1

Looking at my tianocore folder it’s 958.7 mb and there’s no folder called ‘build’ in it.

67

you’re likely missing a dependency needed to build Tianocore; the Purism script doesn’t check for/install those because it’s not an option that will ever be used with the script currently. You’ll need to scroll up and see what dependencies are missing and install them. Off the top of my head, probably nasm and uuid.

68

Right, it was distutils so apt install python3-distutils solved the problem.

By the way, since I was not able to find a toggle in make menuconfig for HT, I just wrote this inside .config with nano:

# config_fsp_hyperthreading is not set

Ok like that?

Now to the last critical bit,

I have the right sized rom in /build/

OS has flashrom v1.2. Should I update it to a newer version before flashing? (I’ve read somewhere 1.2 being old)

Can you be so kind as to writing down the command for flashrom? :slight_smile:

All the best.

69

that’s not a valid Kconfig symbol, it will be ignored.

looking at the coreboot source code, there is no way currently to disable hyperthreading for Cometlake-based devices like the Mini v2 and L14. You’d need to edit src/soc/intel/cannonlake/romstage/fsp_params.c as such:

@@ -151,6 +151,8 @@ void platform_fsp_memory_init_params_cb(FSPM_UPD *mupd, uint32_t version)
        /* Set HECI1 PCI BAR address */
        m_cfg->Heci1BarAddress = HECI1_BASE_ADDRESS;
 
+       m_cfg->HyperThreading = 0;
+
mainboard_memory_init_params(mupd);
 }

there is no newer release. You’ll need to compile from source like the Purism script does (or, run thru the script and let it flash, so that flashrom gets compiled, then use it)

assuming you are in the coreboot_util script directory,
sudo tools/flashrom/flashrom -p internal -w coreboot/build/coreboot.rom

70

That’s exactly how I compiled and used flashrom and it worked. And like you said ht is still on. Let me do the edit you mentioned. Your help is much appreciated!

By the way, can you explain like I’m five how to edit that file? That - + symbols give me a clue to remove/add the lines but a clearer explanation would be appreciated.

Edit: This is not something that would possibly brick my device when done right, is it?
Edit2: I think (manually doing it with sudo nano?) the only thing thats gonna change is the line 152
m_cfg->Heci1BarAddress = HECI1_BASE_ADDRESS;

To this: m_cfg->HyperThreading = 0;

71

no, the diff I posted shows the line being added below, it’s for positional reference only. Don’t touch the HECI line

72

This is brilliant. It worked! Feels like a good achievement. What a peculiar thing to do. Many thanks and blessings to you and the Librem Team.

1 Like
73

Even though XAPIC was selected (as default) under APIC operation mode, OS shows me X2APIC mode is enabled.

Is this expected behaviour?

Also do you see any advantages or disadvantages of the following security measures?

  • Protect Flash Regions > Lock ME/TXE section (or we can use a preset to lock other regions)
  • Boot media protection mechanism > Lock boot media using the controller / Lock boot media using the chip
  • Boot media only writable in SMM
74

different SoCs have different defaults/supported modes, I’d have to see. It could also be a bug in coreboot 4.15.

this will prevent you from writing the IFD or ME without an external programmer. No harm in enabling

this will effectively prevent you from writing the BIOS region of the flash chip (coreboot+payload) without an external programmer. Means no one can tamper with it, but you can’t easily update it either

75

A microphone popped up in my device manager after I flashed my handmade coreboot. Seems like realtek driver is claiming it even though there’s none.

While on topic, I wasn’t able to make my librem mini’s front panel 3.5mm work with any headphones’ mic (on windows).

76

I don’t run, use, or support Windows in any way. The firmware is YMMV in that regard

77

this will prevent you from writing the IFD or ME without an external programmer. No harm in enabling

Should I expect a change in ME in upcoming firmware releases? I don’t use an external programmer but if me is not gonna change or get any smaller I might just write protect it. Don’t know what locking IFD would cause (firmware descriptor?)

78

no, the ME has not changed at all to this point, and I have no reason to suspect that will change in the future. Locking the IFD prevents you from unlocking the ME w/o an external programmer

79

I used to reset cmos by removing the cmos battery after I flashed a new BIOS. It just felt good to erase stuff that could be left over, even if it’s just time/date.

Do you think that’s unnecessary?

Also, can I get away with not including /or only including the header files of CPU microcode? Would the machine boot?

Reason being I’ve read they disabled voltage control via a microcode on 10th gen cpu’s. I’d like to see if I can get it unlocked this way.

80

there’s no CMOS settings to reset

no. All recent (6th gen+) Intel CPUs require microcode to be loaded as part of the boot process. It happens before coreboot is even started. If you don’t include microcode, the device will almost certainly hang during FSP init.