| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
(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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cbfs module must be loaded before trying to source grub.cfg
from CBFS, for obvious reasons.
The test module is bundled into all images in order to avoid the
situation where grub gets stuck in a loop trying to locate the
module during parsing of grub.cfg. This could happen if a user
removes the module or moves it, so it's best to avoid a brick
by just bundling it into the image.
For the bios target, biosdisk has been removed as it doesn't seem
to provide any benefit and memdisk has been added to eliminate
an error printed by GRUB upon load.
|
|
|
|
|
| |
The new build system just applies all patches in the directory, so
we can't have a properly organized structure.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
* projects/grub/grub
* projects/grub/grub-helper
ditto
|
|
|
|
|
| |
Dumps CBMEM console log to stdout; this is useful for
development/troubleshooting purposes.
|
|
|
|
|
| |
As of right now setting/unsetting the variable does nothing as this
functionality will be added later.
|
|
|
|
|
|
|
|
|
| |
The grub.cfg to be included in the GRUB image is located in each
target's directory in 'projecs/grub/configs' now, which means
'projects/grub/configs/grub.cfg' no longer has any use.
Ditto with 'projects/grub/configs/modules-install' and
'projects/grub/configs/modules-preload'
|
|
|
|
|
|
| |
The check for an existing, non-directory file as $keymap_out_path was
added to prevent the (unlikely) scenario of attempting writing a file
to a file as if it were a directory.
|
|
|
|
|
|
| |
Out of: the image itself, keylayouts, and font, the image takes the
longest to build so it would be best to attempt its build first to
avoid wasted time and resources, however little, if the build fails.
|
|
|
|
| |
Forgot about that flag when that was written. Somehow.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
'font-file' contains the filename (not path) of the font to use when
making a PF2-format GRUB font.
'font-project' contains the name of the project which built the
original font file.
These files are necessary to avoid hard-coding the font and/or the
path to the font as an argument to grub-mkfont.
|
|
|
|
|
| |
A more flexible way of handling font files will be introduced in later
commits.
|
|
|
|
|
|
| |
The idea is to build a font from source and then make a PF2 format
file from it using grub-mkfont. This cuts down on the number of
binary files committed to history in the repository.
|
|
|
|
|
| |
Saving typing on one letter isn't really worth the trade-off in
readability.
|
| |
|
|
|
|
|
|
|
| |
Since backgrounds aren't included in the GRUB image it would make more
sense to move them to the GRUB install directory at
projects/grub/install/corebootfb instead (textmode ROMs won't have a
background image included, for obvious reasons).
|
|
|
|
| |
Plurality is nice, sometimes.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Keylayouts are now compiled as part of the build process--keeping
binary keylayouts in the repo is unnecessary as a result.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
grub-mklayout was the intended program to use for generating compiled
GRUB keylayouts. Somewhere along the way grub-kbdcomp was erroneously
substituted in its place.
|
|
|
|
|
|
|
| |
By building keymaps whenever a GRUB image is produced, there will be a
significant reduction in total time spent compiling Libreboot ROMs.
The previous build process for keymaps was hugely inefficient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As with the BIOS/Coreboot targets, the modules listed in this file
will later be added to CBFS in order to avoid issues inherent to
bundling modules into the GRUB image.
Several modules have been excluded from the install list for reasons
of non-applicability to UEFI GRUB; namely:
* cmosdump
* cmostest
* efiemu
* mda_text
* pci
|
|
|
|
|
|
|
| |
As with the BIOS/Coreboot targets' modules-minimal files, this file
lists the minimum necessary to complement a working, bootable image so
that it can read from other devices in addition to halting/rebooting
the machine.
|
|
|
|
|
|
| |
Since GRUB images will be produced on a target-specific basis, the
target will need its own copy of the modules to include in either the
GRUB image itself or CBFS.
|
|
|
|
|
|
|
|
|
| |
The added files (and, later, module lists) are mostly the same as
their BIOS/Coreboot targets counterparts because the base
configuration for each GRUB image produced is intended to be quite
similar (for greater malleability down the line).
The purpose of each file remains the same.
|
|
|
|
|
| |
Without these modules, the GRUB Coreboot target image can't access
devices other than cbfsdisk. Adds support for HDD/USB drives.
|
| |
|
|
|
|
|
|
| |
As with the BIOS target, the modules listed in this file will later be
added to CBFS in order to avoid issues inherent to bundling modules
into the GRUB image.
|
|
|
|
|
|
|
| |
As with the BIOS target's modules-minimal file, this file lists the
minimum necessary to complement a working, bootable image so that it
can read from other devices in addition to halting/rebooting the
machine.
|
|
|
|
|
|
| |
Since GRUB images will be produced on a target-specific basis the
target will need its own copy of the modules to include in either the
GRUB image itself or CBFS.
|