Signed-off-by: Leah Rowe <leah@libreboot.org>

We were previously not handling picotool at all, and
pico-sdk would download picotool itself, at build time.

This means that the source archive, if created, would
not contain picotool. While not strictly required, for
complete corresponding source, since it's a toolchain
and not the actual pico-serprog firmware, it is my policy
that releases must include full corresponding source code,
when it is feasible to do so.

I must say, I intensely dislike cmake, with such burning
passion; I am thoroughly displeased by how hacky this is,
but it works and now nothing is in my way for a Libreboot
20241206 rev8 release!

Signed-off-by: Leah Rowe <leah@libreboot.org>

See:
https://docs.python.org/3/library/sys.html#sys.version_info

The sys.version_info tuple is a more reliable way to
get the version. Our previous logic assumed that Python
would always output "Python versionnumber", but this may
not always be how it works. We've seen this for example
where Debian modifies some GNU toolchains to include Debian
something in the output.

Python has a standard method built in for outputting exact
the information we need. In my system, what I got was this:

(3, 11, 2, 'final', 0)

That output was from running this command:

python -c 'import sys; print(sys.version_info[:])'

This is much more robust, so use this instead.

Signed-off-by: Leah Rowe <leah@libreboot.org>

we already check the python version, and set a variable
for it, so that we can reliably use python3, even if
python in PATH doesn't correspond to python3. for
example if a system has python as python2 and python3
as python3

well, we use that when running deguard for example, but
various upstream projects that we use may need python,
and all of them use python3, not 2

so, re-use the python variable set up by lbmk, and
set it up in PATH accordingly. this now makes the note
about python3 obsolete, on docs/build.md in lbwww.git

Signed-off-by: Leah Rowe <leah@libreboot.org>

They may not actually always be binary blobs, at least not
software. I started referring to these as "vendor files" some
time ago, for this reason.

With this terminology, it applies properly to any sort of file
from the vendor. For example, it may be that in the future, we
start inserting the MFS section of an an Intel ME image, into
the Intel ME.

We already do that with deguard for example (set MFS config),
on MEv11 based setup. That is a vendor *file*, and though it
may still actually be a binary blob, it's not software, but
configuration.

The term "blob" normally means compiled software, in most people's
minds, but the term blob is technically accurate for any blob,
not just software; however, we have to keep people's perception
in mind.

Whereas, "vendor file" is also understood by most people to
include code supplied by the vendor.

We haven't done any releases yet with this ROM image file name
prefix, so it's perfectly OK to handle it now, without handling
the old one for backwards compatibility.

Signed-off-by: Leah Rowe <leah@libreboot.org>

Users running setmac on an X200 tarball for example, will
now see it being modified, if they didn't specify
setmac keep, so they might think vendor files are being
inserted, which they are not.

Therefore, a confirmation is provided at the end of the output.

Signed-off-by: Leah Rowe <leah@libreboot.org>

./mk inject libreboot-YYYYMMDD_board.tar.xz setmac restore

This does the same thing as a normal setmac command, except
that it does not alter the MAC address; it is also not the
same as "keep", which skips *writing* the GbE region in-ROM.

The *restore* argument writes the default, unmodified GbE file
kept by lbmk, unmodified because nvmutil is skipped when the
user specifies this argument.

This option is useful for debugging purposes, because it can
be used to verify whether anything else is being wrongly
modified by the script; the "nuke" command can be executed
afterward, and the hash file inspected versus release.

Signed-off-by: Leah Rowe <leah@libreboot.org>

MAC addresses are generic, inside Libreboot images where
an Intel GbE region is specified.

We commonly get users flashing multiple systems for their
own use, and sometimes they complain that they networking
broke, because they don't know that the MAC address is
identical on each machine.

This still doesn't work around the case where the same machine
is used, e.g. multiple T440p thinkpads, but if they have one
of each model, it can work nicely, because we do in fact
change it for various platforms.

This change will also reduce the number of people at conferences
in the future, where there are multiple Libreboot users, having
MAC address conflicts.

Changing the MAC address is a good practise, so we enforce good
practise. The user can still retain the old behaviour by
using this command:

./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac keep

The "keep" argument clears new_mac, which will then skip
changing the MAC address. They can also still set an arbitrary
MAC address as an argument for setmac, e.g.:

./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac 00:de:ad:c0:ff:ee

This change will be covered in the documentation.

Signed-off-by: Leah Rowe <leah@libreboot.org>

if the user ran this on an x60 tarball, the no-gbe
warning seems confusing since that one has intel gbe,
but pre-ifd, so no gbe region in the flash; on pre-ifd
systems e.g. ich7 southbridge, the mac address was baked
into a separate gbe nvm on mask rom, inaccessible to users

Signed-off-by: Leah Rowe <leah@libreboot.org>

setcfg already checks it, but it's good to check anyway

Signed-off-by: Leah Rowe <leah@libreboot.org>