| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ /
| |
| |
| |
| | |
All tools currently in the build system should be represented
in these files now.
|
|\ \
| |/
|/| |
|
|/
|
|
|
| |
Turns out people mislabel them, most likely candidate for those boards are
Wistron RP-1/RP-4 in several variants. See #589
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\ |
|
|/ |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Projects listed in projects/coreboot/configs/dependencies
are the minimum required by all boards.
Dependencies required by a target in addition to those
specified in parent dependencies files may be declared in the target's
directory, e.g:
projects/coreboot/configs/x200/dependencies
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Projects may now declare other projects it depends upon through
the file "dependencies" located in a project's $CONFIGS directory.
This file requires that each dependency listed, one per line,
correspond to a project in the $PROJECTS directory; the dependency
may be in any form accepted by the libreboot script, e.g:
./libreboot build $dependency
Multiple dependencies files, one per target, are read provided
they are located in target directories and those targets were
included in the list of arguments passed to the libreboot script.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
|/
|
|
|
|
|
|
| |
The intent is to create a simple rule of thumb where arguments
are given beginning with those that relate to the device's physical
attributes, such as flash chip size, continuing with arguments
on how to use the hardware (e.g. display mode), and ending with
anything else.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
D945GCLF ROMs can now be built with either SeaBIOS or GRUB as
a default payload for use with a 1MiB flash, e.g.:
'./libreboot build coreboot d945gclf textmode 1mb seabios'
|
|/
|
|
|
|
|
|
|
| |
Previously it was thought that only boards with 512KiB flash chips
were produced but JohnMH (in #libreboot) ran across one with an
SST25LF080A 1MiB flash.
D945GCLF Coreboot ROMs can be built with, e.g.:
'./libreboot build coreboot d945gclf textmode 1mb'
|
|\ |
|
| | |
|
|/
|
|
|
| |
Makes things simpler if piping the usage output to less,
for example.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I have pointed out the various version of this board
("standard", 2S, iKVM, iKVM/IST, SAS, SAS/iKVM and SAS/iKVM/IST),
and specified their differences and which CPUs they do support,
also providing a link to the official ASUS website and to the board manual.
Also I've tested the board with the text mode ROM and it's not usable
(because it's jittery), so I'm suggesting to flash with the vesafb ROM.
|
|\ \
| | |
| | |
| | | |
into master
|
| | | |
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Related issue #570
The markdown file extension was not consistently replaced with an
HTML extension due to a bug in the regexps used in www/publish.sh
caused by the A-Z character range not being included in the
character alternative.
Along with correcting the aforementioned, this patch allows for more
robust link anchor capturing by allowing the use and replacement of
characters within the ranges a-z, A-Z, 0-9, _ (underscore),
and - (hyphen).
|