| 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.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \ \ |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The SeaGRUB floppy image has a FAT12 filesystem and GRUB needs
to be able to read it in order to load modules stored there.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Related issue #553
Determining the byte offset of core.img on the SeaGRUB floppy
is accomplished using grub_bo(), though it is memory bound as it
requires reading hex dumps for the pattern and comparand into memory.
The blocklists that are stored in the boot record and core.img are
sector numbers. Of particular note is the blocklist written
to core.img is always the location of its *second*
sector--not the first.
Blocklists are used because floppy disks DO NOT have an MBR or
MBR gap as the filesystem spans the entire disk. Consequently, the
core.img cannot be stored in the usual ~1MiB gap. Unfortunately,
using blocklists means they will have to be updated whenever
core.img is moved.
New functions added to grub-helper:
* grub_bo
* grub_bo_dump
* grub_bo_search
* grub_blocklist_format
* grub_blocklist_generate
* grub_floppy_image_make_bootable
* grub_floppy_image_update_blocklists
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Related issue #553
Previously, the GRUB boot image and core image were concatenated
together and padding added to create a (pseudo) floppy image.
However, testing revealed that GRUB has issues dynamically loading
modules from $prefix if $prefix is not located on the same device
from which GRUB booted.
In order to get around this issue, a proper 2.88MiB floppy image is
created using mkfs.fat with GRUB modules copied to directories on
the filesystem (i.e, /boot/grub/i386-pc). The 2.88MiB filesystem
size is necessary to be able to fit all modules onto the image.
New functions added to grub-helper:
* grub_floppy_image_mmd (create directories on image using mtools mmd)
* grub_floppy_image_mcopy (copy files to image using mtools mcopy)
|