| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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).
|
|\ \ \
| |/ /
|/| | |
|
|/ / |
|
|\ \ |
|
|/ / |
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Bios Parameter Block (BPB) is 51 bytes, not 52. As-is, the
first byte of executable code from the floppy image boot record
is copied along with the BPB to boot.img; this extra byte
isn't harmful to leave in since execution begins at offset 0x63+2
rather than 0x3C+2, but is a little messy.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
grep, mkfs.fat, mmd, and mcopy are used to make a bootable
GRUB floppy image. Quotes were removed to salvage some space
in order to avoid going over 80 characters.
|
| | | |
|
| | | |
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2017-12-20 was not the initial date from which fontforge could
build fonts deterministically--builds of the DejaVu LGC subset were
reproducible for some time before then. Though, it wasn't until that
date that fontforge could reproducibly build the full
DejaVu family of fonts (including DejaVuSansMono, which we use).
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
|\ \ \ |
|
|/ / /
| | |
| | |
| | | |
This modification has been made to both build systems.
|
|\ \ \ |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
|