This is similar to the 9020SFF, but this board has ECC support.
However, the native raminit isn't used here, even though it is
otherwise compatible, because the native init doesn't do ECC yet.
The broadwell mrc.bin has ECC support, which is also used on the
HP EliteBook 820 G2. The MRC for broadwell can be used on haswell
boards such as the T1700.
Add both the SFF and MT variants. Since these are identical to the
9020 variants, except for slightly different PCH enabling ECC, we
can just re-use the 9020 port without issue.
We *could* add a variant to coreboot, for T1700, but there is not
really any pressing need. It is simply the 9020sff/mt with mrc.bin
Signed-off-by: Leah Rowe <leah@libreboot.org>
these functions make more sense in lib.sh
i made mk link lib.sh first, so that the
functions on init.sh can still use them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Many users report bugs, so I'm reverting lbmk back to only
supporting the rp2040 dongles for the time being. The
documentation will be updated to reflect this.
Pico2 support will be re-added at a later date, once more
testing has been done, and fixes made if necessary.
it's not necessary, and was the cause of a recent issue,
which i mitigated, but why mitigate it?
prevent bugs. don't use eval unless absolutely necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
see:
commit f0c629dcc6
Author: Leah Rowe <leah@libreboot.org>
Date: Sat Apr 12 13:51:49 2025 +0100
lib.sh: write version/versiondate to dotfiles
and this bug report:
https://codeberg.org/libreboot/lbmk/issues/284
The report indicates that the above commit broke bash,
when sh (on the user's system) is bash.
I know sometimes when using bash, I need to use the
back slash when dealing with dots, e.g. when grepping
something.
Also double quote references to dotfiles, e.g. when
directing the output of printf.
I never noticed the issue myself, since I use dash.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the command -v check has been removed, since this function
already calls git immediately, which would accomplish the
same thing since that causes an error if git isn't there.
Signed-off-by: Leah Rowe <leah@libreboot.org>
setvars is always invoked with eval, so make the error
condition a message for eval, to ensure that it is reliably
handled, in case of error condition.
Signed-off-by: Leah Rowe <leah@libreboot.org>
one function, for one task. skeleton functions for
performing multiple tasks. that is the basic coding
style guideline for lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
On initialisation of the child instance, ./mk is
executed, but an error from it won't reveal what
command was actually executed.
This change makes that the case, since x_ does
print the command that caused an error.
This is useful for debugging. However, we don't
want x_ to cause a real exit, because we still
need to handle the lock file from the parent
instance.
Therefore, the first child instance is executed
inside a subshell, and xbmk_rval is set if that
subshell returns non-zero.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this matches cbmk, where inject.sh is the file name
this will make future cherry-picks of lbmk->cbmk easier
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is in prep for the next change, where non-init
functions will be moved to another file, again named
include/lib.sh
Signed-off-by: Leah Rowe <leah@libreboot.org>
a lot of init code was handled outside of any function. the
coding style used in the rest of the build system has now
been introduced, with xbmk_init being the main function.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was used alongside the xgcc linking, so that coreboot
trees could specify that another tree was to be downloaded.
since this variable will no longer be used, it should be
removed, to avoid dead code bloat.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the "xtree" variable is used by projects such as u-boot,
to export a CROSS_COMPILE variable specifying prefix for
gnu compilers, and for building the named coreboot tree.
for example, xtree can be "default", which is then the
coreboot tree downloaded, for use of crossgcc.
however, it is also used to symlink identical versions
of crossgcc between coreboot trees. this latter feature
was only needed for fam15h boards which were previously
split between two mostly identical coreboot trees, that
were later merged into a single tree, and this feature
is therefore no longer used.
remove this dead code, to reduce bloat in the build system.
Signed-off-by: Leah Rowe <leah@libreboot.org>
In the previous revision, I make hardcoded use of
/usr/local/bin and /usr/bin as search locations, instead
of relying on PATH, when the user has a python venv, because
in those cases, we cannot rely on PATH so we use a python
command to detect the venv and then force use of the
normal system path for python.
However, there's no guarantee that the real Python will
indeed live at these locations. For example, some distros
like Nix or Guix will use many locations for different
versions of a given package, and it's for the birds as to
what given package version the user might be running.
Therefore, this patch retains that current hardcoded
assumption of /usr/local/bin and /usr/bin but *only* as
a fallback solution, instead checking realpath first.
The "realpath" command isn't technically POSIX standard,
but in practise it is available on GNU coreutils, Busybox,
and the various BSD userlands.
I could perhaps *import* a realpath utility, and use that,
but this should be fine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
If the user has a virtual environment, the current logic
will cause lbmk to hang. A useful workaround is to force
use of the direct path to the system binary of python.
This works by detecting a virtual environment first, and
deferring to the old behaviour if no venv is found. If one
is found, then it will not rely on PATH, but instead only
search the standard locations /usr/local/bin and /usr/bin.
Signed-off-by: Leah Rowe <leah@libreboot.org>
alper made a fix to this file a few hours ago, but
forgot to update the copyright header
i'm doing it for alper, as a courtesy
Signed-off-by: Leah Rowe <leah@libreboot.org>
Properly set $pyver to "3" when we detect we can use python3. In the
following version checks, use the $python we detected instead of a
'python' from PATH because the latter might be a python2 while still
co-existing with a python3.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
initialising variables, setting PWD, setting version,
this is all unnecessary before the root check, because
the dependencies commands use none of these.
Signed-off-by: Leah Rowe <leah@libreboot.org>
