| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The added files are mostly the same as their BIOS target 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.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The produced GRUB image now has a more generalized name for
applicability to disparate platform builds (e.g. EFI vs. bootable
floppy image).
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
'keymap' isn't included as a target yet due to it needing further
work done to it.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous build function definition only allowed for a
one-size-fits-all build process for any given target. The function
was rewritten to allow for different build processes based on the
target passed to it (e.g. building GRUB keylayouts is very different
from building GRUB images).
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Without this module the GRUB can't find devices--as in, 'ls' literally
lists nothing, not even the device GRUB booted from.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since the majority of GRUB modules will be placed into CBFS instead of
the GRUB image itself, the modules-install and modules-preload files
no longer have any use as-is. However, they serve as a useful
reference to which modules should be retained for later
processing (thus the addition to the new install file).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This file should only contain the minimum of modules necessary to
create a working, bootable image able to source other modules and
files from CBFS and/or a separate device.
(module dependencies are installed automatically)
By including as few modules as possible into the GRUB image, selective
addition/removal of modules to/from CBFS is now possible. In
addition, modules can be reloaded without issue (modules included in
the GRUB image can't be reloaded).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A GRUB image will be produced on a target-specific basis so the
target will need its own copy of the modules to include in either the
GRUB image itself or CBFS.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It's fairly obvious that the files refer to _GRUB_ modules considering
the files are located in the GRUB project's configuration directory.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The purpose of each new file is as follows:
* arch -- CPU architecture to target when building images
* config -- embedded GRUB configuration
* format -- GRUB output format
* platform -- the platform GRUB should build images for
* prefix -- where GRUB should search for modules by default
* size -- the size of the floppy image to produce, in KiB
|
| |/ / / |
|
| |\ \ \ |
|
| |/ / /
| | |
| | |
| | |
| | | |
they're not the first libre OEM, but they are the first one to produce libre
hardware that is also high-end (IBM POWER9 competes with Intel on performance)
|
| |\ \ \ |
|
| |/ / / |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| |/ / / |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The command 'loadfont' was removed because the environment variable
'gfxterm_font' is inspected by GRUB and automatically sets the font to
its value if 'gfxterm' is in the list of active output terminals.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In order to mitigate issues concerning end-users making their system
unbootable by misconfiguring grub.cfg, an environment file is provided
with the intent being to direct users to edit that file instead of
grub.cfg. Thus, consequences of misconfiguration are lessened.
Of course, users looking to make more extensive changes than setting
environment variables used by either GRUB (internally) or in grub.cfg
will still need to edit their grub.cfg.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Having the keymaps compiled into the GRUB executable is convenient but
may end up taking up too much room for systems with constrained flash
space (e.g. those limited to 2048kB).
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
this concerns an entry on the suppliers page, for a product from my own
company. Pull request therefore not required
I've decided to take D16 off of minifree, in order to reduce competition for
the TALOS II product that Raptor Engineering launched today. The world needs
libre OEMs, and Raptor Engineering is the first one.
|
| |\ \ \
| | | |
| | | |
| | | | |
master
|
| |/ / / |
|
| |\ \ \ |
|
| |/ / / |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
