| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
bucts is now merged in-tree, so the download() and download_check()
actions are no longer necessary.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Considering bucts is no longer maintained by
Peter Stuge--its original author--and it being integral to
Librebooting the X60/T60, it seems best for bucts to be merged into
the main Libreboot repository.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The upstream repository from which bucts is pulled has changed,
necessitating a different revision pointing to HEAD.
|
| |
|
|
| |
This is the latest release of SeaBIOS.
|
| | |
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS flashmap's remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS vboot's remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS vpd's remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS mosys' remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS hdctools' remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS-EC's remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in CrOS flashrom's remote
repository corresponding to the latest release.
|
| |
|
|
|
| |
"release-R63-10032.B" is a branch name in Depthcharge's remote
repository corresponding to the latest release.
|
| |
|
|
|
|
| |
stuge.se is, seemingly, down indefinitely which means users can no
longer automatically clone bucts using the build scripts; by changing
the repo URI to Libreboot's mirror this issue is resolved.
|
| |
|
|
|
|
|
|
|
| |
This is likely one of the very last changes necessary to make the
Libreboot build system more cohesive in appearance.
Hopefully from this point forward it won't be as readily apparent as
to who wrote which parts of the build system (i.e. won't look like a
patchwork quilt any longer).
|
| |
|
|
|
|
|
|
|
|
| |
There's no benefit to using the POSIX-style '[' test builtin
considering its '-a' and '-o' operators are unused in the Libreboot
build system. Plus, '[[' is safer with respect to any containing file
redirections (for example).
Prior, both '[' and '[[' were used throughout the codebase--a
disparity in usage which this change aims to eliminate.
|
| | |
|
| |
|
|
| |
Signed-off-by: Alessandro Grassi <alessandro@aggro.it>
|
| |
|
|
|
| |
Helps keep projects modular and easier to maintain if each project
only builds itself.
|
| |
|
|
|
| |
Helps keep projects modular and easier to maintain if each project
only builds itself.
|
| |
|
|
|
|
|
|
| |
'project_action' does not carry out the given action for a project,
contrary to that which the naming may seem to imply.
Replacing the usage of the aforementioned with
'project_action_arguments' provides the intended behavior.
|
| |
|
|
|
|
|
|
|
| |
These are necessary so that the build action for depthcharge can
locate the correct configuration for veyron targets in the
depthcharge source repository.
Prior, the build action was looking for 'veyron' instead of
'veyron_minnie' or 'veyron_speedy', causing it to fail.
|
| |
|
|
|
|
|
|
|
| |
In order to avoid additional, fragile, complexity for building
depthcharge, libpayload must be built for the minnie/speedy veyron
subtargets; this is the simplest way to avoid making special cases in
either the depthcharge scripts or the libpayload scripts with respect
to ensuring the depthcharge build action can locate the proper
libpayload build directory.
|
| |
|
|
|
|
|
| |
'config' was renamed to 'config_name' to better convey its purpose.
Additionally, 'config_path' had its associated string value modified
to contain the correct path to the libpayload configuration file.
|
| |
|
|
|
| |
Helps keep complexity down as well as making scripts easier to
maintain if each project only builds itself.
|
| |
|
|
|
|
| |
It seems like 'project_action_arguments' was the intended function to
use, as 'project_action' does not actually /carry out/ the action
given as its first argument.
|
| |
|
|
|
| |
Makes things easier to maintain if a project only builds itself--less
moving parts, etc.
|
| |
|
|
|
|
| |
The prefix action is a quality-of-life addition which helps a user
locate the relevant compiler binaries for a given target once built.
This change simply extends it for the i386 target.
|
| | |
|
| |
|
|
|
|
|
|
| |
It's possible that a compilation failure will occur if there's a
difference in major versions between the host GCC compiler and the one
being built. To avoid this, bootstrapping can be used. The method
for bootstrapping is simply passing the '-b' flag to Make; the
Makefile takes care of the rest.
|
| | |
|
| |
|
|
|
|
|
| |
'project_action' was used instead of the intended
'project_action_arguments' function, I presume, as project_action does
not actually carry out the argument action--contrary to what the name
may seem to imply.
|
| |
|
|
|
|
|
| |
Helps keeps things more modular if each project only builds itself
rather than, for example, Coreboot's build action also building
crossgcc and an embedded controller firmware; this makes it possible
to rebuild only one project if its compilation fails.
|
| |
|
|
|
|
| |
* projects/seabios/seabios
ditto
|
| |
|
|
|
|
| |
* projects/memtest86plus/memtest86plus
ditto
|
| |
|
|
|
|
|
| |
* projects/grub/grub
* projects/grub/grub-helper
ditto
|
