Project

General

Profile

Packaging Request #3208

[coreboot-util][libreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot.

wael - 8 months ago - . Updated 4 months ago.

Status:
fixed
Priority:
wish
Assignee:
% Done:

100%


Description

ECtool is GPLv2-only free software as part of the Coreboot project for managing the embedded controller.
It is mostly useful for Laptops, especially since Coreboot doesn't implement SM-API (being a security hole and proprietary spec).
Thus, through EC-tool users can still get the same functionality without dangerous and potentially non-free SM-API code.

I've written and attached a PKGBUILD file for it, and tested it on my Librebooted T400 Parabola system.


Files

PKGBUILD (1.21 KB) PKGBUILD wael, 2022-04-12 11:19 AM
PKGBUILD (1.21 KB) PKGBUILD wael, 2022-04-21 01:38 PM
PKGBUILD (2.53 KB) PKGBUILD wael, 2022-04-22 11:03 AM
PKGBUILD (2.79 KB) PKGBUILD wael, 2022-04-29 05:18 PM
PKGBUILD (3.07 KB) PKGBUILD wael, 2022-04-29 06:26 PM

Subtasks

Bug #3248: [nvramtool] conflicts with coreboot-utilduplicateGNUtoo

Actions

History

#1

Updated by bill-auger 8 months ago

at first look, i can make some suggestions

  • there is no parabola port for 'aarch64'; so {libre,}makepkg would never use it - it would be useful only on an archlinuxarm system
  • regarding the license, 'GPL2' means GPL2-only - if it is GPL2-or-later, use 'GPL'
  • 'make' and 'gcc' do not need to be in makedepends - those are included in base-devel - the arch convention/policy is that all PKGBUILDs assume 'base' and 'base-devel' to be installed - base-devel is always installed in librechroots
#2

Updated by bill-auger 8 months ago

WRT BR #2885 - should this package be a dependency of 'tp_smapi' and 'tp_smapi-lts' ? - #2885 suggests that it is essential for them (broken without it)

or vice-versa? - does this program expect that one of 'tp_smapi' or 'tp_smapi-lts' is installed ?

#3

Updated by wael 8 months ago

GPL2 is intentional.
I'll fix the rest later today and update it.

#4

Updated by bill-auger 8 months ago

is there any relationship with 'tp_smapi', or does this program replace some functionality of 'tp_smapi'?

if they cooperate, one or both may be optdepends of the other, even if they are not essential to one another

#5

Updated by wael 8 months ago

They're incompatible:
tp-smapi requires that the SMAPI be implemented, which Coreboot doesn't implement.
Conversely, ectool is almost useless for a system that doesn't run (some distro of) Coreboot.

#6

Updated by wael 8 months ago

  • File PKGBUILD added

Hello, this should be the final file, I've removed the aarch64 build option.
I've tested this again, it installs and runs without issue on my system.
Once this gets approved I'll template the PKGBUILD for other Coreboot utils.

#7

Updated by bill-auger 8 months ago

if the other tools are made from the same sources (https://coreboot.org/releases/coreboot-${pkgver}.tar.xz), it would be best as one single split-package PKGBUILD

see /usr/share/pacman/PKGBUILD-split.proto

#8

Updated by wael 8 months ago

  • File PKGBUILD added

After discussion on the IRC channel, I have made a coreboot-util package, I've tested it to be working and all the software has been checked to be GPLv2-only.
This will install ectool, cbfstool, nvramtool, superiotool and cbmem.
ectool is used to control the EC of the device (as detailed earlier).
cbfstool is used to configure the CoreBoot File System.
nvramtool is used to read from and write to nvram to change firmware settings.
superiotool is used to detect SuperIO devices.
And cbmem is used to parse cbmem, such as for timestamps and logs (useful in conjunction with the others).

The whole package clocks in at 316K, installed at 3.84MiB.

#9

Updated by bill-auger 8 months ago

some notes:

WRT pkgrel:

pkgrel=1.parabola${PARABOLA_RELEASE_COUNT}

PKGBUILDS should not depend on anything in the local environment - PARABOLA_RELEASE_COUNT is guaranteed to be undefined in librechroots

the '.parabola' extension to pkgrel is to indicate a replacement for a package in arch - replacement packages would never be in the PCR repo - for a PCR package, pkgrel is a single number:

pkgrel=1

like 'make' and 'gcc' before, 'pciutils' does not need to be in makedepends - pciutils is included in base - the arch convention/policy is that all PKGBUILDs may assume 'base' and 'base-devel' to be installed - 'base' and 'base-devel' are always installed in librechroots

WRT source filenames:

source=("coreboot-${pkgver}.tar.gz::https://coreboot.org/releases/coreboot-${pkgver}.tar.xz")

there are two thing wrong with that line - the filename preceding '::' is needed only when it is desired to rename the downloaded file - tarballs from github for example, either do not indicate the project name, or do not indicate the version - every one of them will be named like: foo-master.tar.gz or v0.1.2.tar.gz -
that makes it very difficult to distinguish from others in the sources cache, or simply over-writes the last downloaded github file with the same (non-unique) filename

in this case, the name of the file being downloaded is: coreboot-4.15.tar.xz, which is uniquely identifiable; so there is no reason to rename it

secondly, it is being renamed from .xz to .gz, which is technically incorrect

#10

Updated by bill-auger 8 months ago

  • Priority changed from bug to wish
  • Assignee set to bill-auger
  • Status changed from open to in progress
  • Subject changed from Package ectool from coreboot for controlling the EC on coreboot and libreboot. to [coreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot.

the arch convention/policy is that all PKGBUILDs may assume 'base' and 'base-devel' to be installed

'base' and 'base-devel' are always installed in librechroots

at least one of those statements is incorrect

the arch convention/policy is not actually obvious - it says only that 'base-devel' may be assume installed - i have always assumed that 'base' is not explicitly mentioned; because 'base' is assumed to be installed implicitly, on all supported arch-like systems

however, 'pciutils' is not installed in librechroots (because neither is 'base') - i had forgotten that - i consider it to be a bug, even if it was intentional - my guess is that 'base' was avoided, because the original 'base' package group always installed a kernel, which was useless in the build chroot

#11

Updated by wael 8 months ago

  • File PKGBUILD added

Here's the new PKGBUILD with the applied fixes, I've also bumped the coreboot version to 4.16.

#12

Updated by bill-auger 8 months ago

did you try building this for i686? - it fails to build for me

#13

Updated by bill-auger 8 months ago

  • File deleted (PKGBUILD)
#14

Updated by bill-auger 8 months ago

  • File deleted (PKGBUILD)
#15

Updated by bill-auger 8 months ago

  • File deleted (PKGBUILD)
#16

Updated by bill-auger 8 months ago

  • File deleted (PKGBUILD)
#17

Updated by wael 8 months ago

I just ran linux32 libremakepkg and linux32 makepkg (the latter to account for a chroot running as x86_64) and it compiled fine in both cases.

#18

Updated by bill-auger 8 months ago

that is not a 32bit build - AFAIK, linux32 (setarch) only tricks the environment into believing that a foreign-arch kernel is running - it would not cross-compile for a foreign arch - there is a big difference, which this situation is illuminating

you can verify that yourself by interrogating the binary

$ linux32 makepkg -sr
$ file pkg/coreboot-util/usr/bin/ectool
pkg/coreboot-util/usr/bin/ectool: ELF 64-bit LSB pie executable, x86-64, ....

also, the filename of the produced package is coreboot-util-4.15-1-x86_64.pkg.tar.xz; librerelease would put it in the x86_64 repo - but even if it were installed on a i686 system, it would not run, because it is a 64bit binary

anything that is destined for the parabola repos, must be built with libretools; so we attempt to ensure that is possible, or to leave a 'FIXME:' note in the PKGBUILD, describing the failure

create an i686 chroot:

$ sudo librechroot -n i686 -A i686 make

build a package for i686:
$ sudo libremakepkg -n i686

bear in mind that arch32 is less than perfect - some of the dependencies will be in a non-standard repos: testing, staging or build-support; and often a build will need to downgrade a dependency manually from the archive - usually one of those combinations will work; but there is often nothing we can do about failures, other than report them to arch32

iceweasel is one example currently (and anything else written in rust) - the current i686 rust package is useless - v96 was the last version that i was able to compile - in other words, with i686 and armv7h, give it a reasonable try, but dont try too hard

#19

Updated by bill-auger 8 months ago

it looks like there are multiple versions of the EC firmware to consider - is this compatible with the firmware upgrade mentioned on the libreboot website (and whatever version it was replacing)?

https://libreboot.org/docs/hardware/#ec-update-on-i945-x60-t60-and-gm45-x200-x301-t400-t500-r400-w500-r500

#20

Updated by wael 8 months ago

When it comes to i686 and armv7h, I'll give it a shot now.
And as for the EC firmware itself, there are two distinctions to be made here:
On the x86 targets supported by Libreboot, all EC firmware is proprietary, but can only be updated through the official proprietary BIOS only anyway, in effect, once the machine has Libreboot installed that firmware is basically stuck in ROM, to quote from the RYF guidelines:
"However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
https://ryf.fsf.org/about/criteria

ECtool merely provides a free as in freedom way to interface with that code, much like one can say that an HDD's or SSD's firmware is proprietary but the Linux (Libre) kernel still provides an interface (in this case over SATA) to that firmware.
ECtool does not allow updating or replacing said firmware, and as such in no way does it aid in the installation of potentially non-free software.

#21

Updated by bill-auger 7 months ago

  • Related to Bug #3248: [nvramtool] conflicts with coreboot-util added
#22

Updated by wael 7 months ago

So, I fixed the compilation by nuking the cbmem tools part.
I couldn't get it to compile no matter what, and to be honest, it is of minimal use in general - unless someone is building Coreboot ROMs.
I can confirm that the package compiles fine under i686 and x86_64.

#23

Updated by bill-auger 7 months ago

ok thats progress - i deleted the source package - we need to
work on either using the libreboot sources, or pre-cleaning the
coreboot sources in a mksource() function

if that takes too long, we should pull the binary package too;
because we really should not have it without sources

#24

Updated by wael 7 months ago

Solved by using Libreboot's sources, I've also packaged bucts this time around (needed by x60(s) and t60(s)).
Credit to GNUtoo as I've based this off of the nvramtool package.
Tested on x86_64 and i686.
Sidenote: the upstream URL is pulled from Libreboot's testing release but the packaged software is stable, "testing" in this case refers to Libreboot's ROMs (which we aren't dealing with here).

#25

Updated by GNUtoo 7 months ago

Hi,

Thanks a lot for the work on this package.

Before merging the PKGBUILD, it would be easier for us if you could attach a git patch (This can be done with git format-patch -1). This way we could have the proper authorship and so on in the patch.

Since the various utilities are independent but come from the same source release, if it's easy for you, it would be a good idea to split the utilities in several packages inside that PKGBUILD. If not it can also be done later on in subsequent patches.

Splitting in various packages would also enable to upgrade from the nvramtool package I made to the nvramtool built from your package more easily. For that you'll also need to increase the pkgrel from 1 to 2 and to delete the nvramtool PKGBUILD in your patch. This way people and 'git show' will also understand that the coreboot-utils PKGBUILD is the "next version" of the nvramtool PKGBUILD.

In addition, splitting packages would also allow to have more precise licensing information (if PKGBUILDs support that): all the packaged utilities but superiotool are GPLv2-only. superiotools is GPLv2-or-later. So if adding a license in a package works, it would be nice to have that change too.

In addition some of the utilities like me_cleaner or bucts have several upstreams: me_cleaner is available both on github in a separate repository and in Coreboot. Bucts is also available separately. So if we need to change upstream later on, having split packages would make the upgrade totally transparent.

Denis.

edit1: added rationale with me_cleaner

#26

Updated by GNUtoo 7 months ago

wael wrote:
[...]

Sidenote: the upstream URL is pulled from Libreboot's testing release but the packaged software is stable, "testing" in this case refers to Libreboot's ROMs (which we aren't dealing with here).

It's also possible to send patches in Libreboot upstream to add support for releasing a deblobbed coreboot tarball. For instance we could have one tarball for each coreboot release in the same spirit of what linux-libre does. I did something similar for u-boot as Libreboot is also interested in using u-boot for supporting some computers.

The downside of going that route is that not only it would probably take a lot more time and work but also, if instead we stick to the Libreboot releases that people are using, it increases a lot the probability of having the tools work well with these Libreboot releases.

And supporting Libreboot well is more important than supporting Coreboot well.

That makes me think that having this package named libreboot-utils instead of coreboot-utils would make that more clear.

Supporting both could also be done but it would increase a lot the complexity and the time and work needed.

edit1: added rename

#27

Updated by bill-auger 7 months ago

if this package produces the same 'nvramtool' binary, then it
is the obvious option to delete the 'nvramtool' package; but
i would not be too concerned with the upgrade path - the
'nvramtool' package is only a few days old - it is not likely
that anyone knows it exists yet

otherwise, we end up carrying a 'replaces' entry that will
probably never be removed

a split package was considered - i suggested not doing it, only
for simplicity - this package is also very new - we could just
split it without any 'replaces' or 'provides' litter

i think the priority here is to get it to build from pre-cleaned
sources

im not sure if wael is comfortable with git - the pagure repo
could also be used though - whatever workflow is best for the
packager, is fine by me - if even just dumping another PKGBUILD
to this ticket

#28

Updated by bill-auger 7 months ago

im not sure if wael is comfortable with git - the pagure repo could also be used though - whatever workflow is best for the packager, is fine by me - if even just dumping another PKGBUILD to this ticket

#29

Updated by bill-auger 7 months ago

Supporting both could also be done but it would increase a lot the complexity and the time and work needed.

which reminds me, i forgot to mention that having multiple packages, built from the same sources, doubles the disk space used in the repos - that is the best reason to merge the PKGBUILDs (and to choose only one of libreboot or coreboot)

#30

Updated by wael 7 months ago

I agree with bill-auger on the splitting part, these binaries are all inter-related anyway (chances are, if you use one you're going to use the others), the only exception is bucts (it is x60(s)/t60(s) specific) but that is small anyway.
If you want I can post a git patch of the PKGBUILD to the mailing list.

#31

Updated by GNUtoo 7 months ago

If you want I can post a git patch of the PKGBUILD to the mailing list.

Yes, that would be great.

As for the upgrade path, I also agree with bill auger. I also wanted to avoid keep custom (replace= conflict=) code forever.

As for splitting the package, while I find it useful, it can also be done later on.

I may give it a try at some point if I can find the time.

#32

Updated by bill-auger 7 months ago

  • Subject changed from [coreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot. to [coreboot-util][libreboot-util]: Package ectool from coreboot for controlling the EC on coreboot and libreboot.

seeing as there are multiple program in the package, and a small number of them, i add the names to pkgdesc - i figure that will make them easier to find, eg:

$ pacman -Ss nvramtool
pcr/libreboot-util 4.15.libreboot.20211122
    Misc. Coreboot/Libreboot utils (bucts, ECtool, nvramtool, superiotool)

i also changed the license header to use the SPDX format

# SPDX-License-Identifier: CC0-1.0

i noticed that 'coreboot-util' installed some programs which 'libreboot-util] does not - whats the deal on that?
  • cbmem
  • cbfstool
  • rmodtool

also, the source package is about 500MB (the binary package is only 76KB) - maybe you could try deleting everything except the 'utils' directory and the makefile - if that is not too difficult, it would be worth doing, to save space on the mirrors

#33

Updated by bill-auger 7 months ago

libreboot-util is in pcr now - please do try it out

#34

Updated by wael 7 months ago

I've based this PKGBUILD off of the one in the repos.
I added man pages where applicable.
As for cbmem and rmodtool, I checked the use cases earlier and apparently they're mostly useful for more of a development workflow, in which case the person using them would acquire the whole coreboot source tree, which makes packaging them quite redundant.
As for cbfstool, it can be quite useful, but I cannot get it to compile under i686 (some issue with memcpy exceeding bounds), for now, I commented it out in the PKGBUILD - in the hopes that it can be added at a later date when I manage to figure out how Libreboot deals with this.

#35

Updated by bill-auger 7 months ago

if it has a problem on one arch you can still build it for the other arches

[[ "${CARCH}" != i686 ]] && do_something

or
case "${CARCH}" in
armv7h) do_something
#i686)  do_nothing   # this is broken today
x86_64) do_something_else_maybe
done

#36

Updated by wael 7 months ago

Now it does conditional compilation.
Should I submit the patch to the mailing list?

#37

Updated by bill-auger 7 months ago

i dont care how the patches come in - i watch everything - gnutoo asked for it on the mailing list - i thought he was going to review it - the package is already published now so theres no urgency

just let me know if the package in libre is good; and the ticket can be closed - i have a thinkpad but i dont know how to use these tools to test them - would these be useful for a T500 ?

try to work on deleting as much of the unused sources as possible - it may be easy - take your time - i dont know how often libreboot releases; but youd have at least that much time before a new PKGBUILD would be needed

#38

Updated by wael 7 months ago

I tested the package that's currently in the repos, all seems fine.
As for usefulness for a T500: if it is currently librebooted/corebooted, then ectool can be used to directly communicate with the EC (instead of using SM-API, which coreboot doesn't implement), I've detailed some examples in the Wiki (T400 article).
Some of the stuff that can be done through that is setting charge thresholds, toggling the thinklight on and off (I use it in a notification script for example), or changing mute button status.
The rest of the tools are more specific for certain tasks: nvramtool for changing data in the NV-RAM, cbfstool for modifying the CoreBoot File System within a Coreboot ROM, superiotool for detecting and modifying superio ports, and bucts is strictly useful for X60 ThinkPads as far as I can tell (needed to flash a modified ROM, e.g.: when installing/upgrading Libreboot).
As for the sources, I added a few lines that attempt to remove payloads, board configs and docs (all useless for this package's purpose), but I'll check later if I can just do a sparse clone from Libreboot sources, though it isn't very straightforward as there are some inter-dependencies (otherwise I would've just left the util directory and deleted everything else).

#39

Updated by wael 4 months ago

  • Status changed from in progress to fixed
#40

Updated by wael 4 months ago

I'm adding this here even though it might warrant a different thread down the road:
https://notabug.org/osboot/nvmutil
As this should allow one to more easily set a libreboot/coreboot system.

Also available in: Atom PDF