| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Missing trivia that can cause a brick
|
| |\ \ \ \ |
|
| | | | | |\
| | |_|_|/
| |/| | | |
|
| |/ / / / |
|
| | | | | |
|
| | |_|/
|/| | |
|
| |\ \ \ |
|
| |/ / / |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As an example, do this:
[[ -n $revision ]]
instead of this:
! [[ -z $revision ]]
Makes the code easier to read.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The source builtin provided by Bash is easier to read than '.' (a lone
period). Conforming to POSIX wasn't and isn't a goal of the Libreboot
build system and as such it's fine to deviate from the standard where
it makes sense, such as now.
|
| |/ / / |
|
| |\ \ \
| | |/
| |/| |
|
| |/ /
| |
| |
| | |
Added some info about WIP
|
| |\ \ |
|
| |/ /
| |
| |
| | |
Signed-off-by: Alessandro Grassi <alessandro@aggro.it>
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Fixed typos and markup
|
| |\| | |
|
| | | | |
|
| |\| | |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
• match grub.cfg of current release and naming scheme of this guide (rootvol)
• add stub section about generating grub.cfg
• make section about ODD issues generic (happens to every device with native sata)
• formatting fixes/workarounds
|
| |\ \ \ \ |
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ |
|
