| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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'
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
The fc-lang symlink has been added to the .gitignore file in order
to allow creating the symlink once after the initial download of
dejavu-fonts. This avoids the otherwise necessary step of
recreating the symlink before each build (as it could have been
removed by the project's clean() action).
|
|
|
|
|
|
|
|
|
|
| |
The path contained in the symlink has been made relative for
reproducibility reasons.
Also, it just makes more sense to create the symlink during the
download() action vs. build(). The `-f` flag was added to avoid
an error if the link already exists (i.e., download() has been
executed previously).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the dejavu-fonts script pulled in the latest versions
of UnicodeData.txt and Blocks.txt files from
https://www.unicode.org/Public/UNIDATA/ which are unversioned.
This is an issue because the files at this URI will change over time
as new UCD versions are released, making reproducible builds of
dejavu-fonts impossible.
The solution to this issue is to simply download the requisite files
from https://www.unicode.org/Public/$ucd_version/ucd/ where
$ucd_version is the version specified in
projects/dejavu-fonts/configs/unicode/ucd-version
|
|
|
|
|
|
|
|
|
| |
fontforge was not able to create fonts in a reproducible manner
until upstream revision 69e561773b91e37096a855f0353b1d6781a61250
Requiring at minimum a fontforge built from source on 2017-12-20
(the date the aforementioned revision was made) ensures that dejavu
fonts are reproducible in Libreboot's build system.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
(fd0) should be the proper device for SeaGRUB. $prefix is set using
(fd0) as the device considering modules will be placed onto the
floppy image--not in CBFS.
grub.cfg is still sourced from (cbfsdisk)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Module "biosdisk" is necessary for GRUB to boot from the floppy
image we're working to create. If this module is not included in
core.img it will simply not load.
Module "minicmd" has been added in order to provide the commands
"lsmod" and "rmmod" which are useful for listing loaded modules
and unloading them, respectively (especially great for testing).
|
| |
| |
| |
| |
| | |
All modules listed in a given target's modules-minimal file are
preloaded so there's no need to specifically load any.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
If quoted and $bootstrap_flag expands to an empty string, make
interprets it as an invalid file name and errors out.
|
| |
| |
| |
| |
| | |
Paul Kocialkowski was not retained as the original author due
to the triviality of the patch.
|