| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
i left this here by accident when testing something
during work on a prior revision
|
|
the old code was specifing an absolute offset for
insertion of mrc.bin - cbfstool interprets anything
above 0x80000000 as top-aligned memory address in
x86, and anything below as an obsolute offset in
the flash, like with the old number
where a top-aligned address is provided to cbfstool,
the absolute position is calculated for the flash,
and cbfstool inserts it in the correct rom location
the benefit of this change is that the absolute
offset is now calculated automatically, which means
that the code will be correct even if the flash
size changes. for example, if 16MB flash is used
whereas 12MB is currently the default an support
haswell hardware
coreboot does not provide anything readably like
Kconfig, for extracting this value. it's baked
into the source code of coreboot, so you have to
find it. the correct location is hardcoded for
each platform, and always the same on each platform,
regardless of mainboard
|
|
|
|
top-down function order, with specific functions for
each type of blob. startup logic moved into main(),
also split into smaller functions
"write one program that does one thing well"
blobutil is like that, and has this added philosophy:
"write one function that does one thing well"
during the course of this re-factoring, several bugs
and issues were found, that are pre-existing. these
will be corrected in follow-up revisions
|
|
For Nvidia GPU models of Dell Latitude E6400
|
|
|
|
|
|
|
|
|
|
libre mrc on haswell is quite buggy for now, but works in
a limited fashion
this patch re-adds the old configs, but as _mrc for example
t440p_12mb_mrc instead of t440p_12mb
and t440p_12mb (without _mrc) still uses the libre mrc code
|
|
courtesy of Angel Pons from the coreboot project
this uses the following patch set from gerrit, as yet
unmerged (in coreboot master) on this date:
https://review.coreboot.org/c/coreboot/+/64198/5
logic for downloading mrc blobs has been deleted from
lbmk, as this is now completely obsolete (for haswell
boards)
if other platforms are added later that need mrc.bin,
then logic will be re-added again for that
|
|
some checks check for specific utils, which are
then used to indicate the existence of other utils,
which means that building them singularly, as is
currently done, may result in errors later if another
tool doesn't exist compiled yet
this is an obscure bug, fixed by this patch. more of a
workaround really. a dirty hack. when checking for any
of the coreboot utilities required, build all coreboot
utilities that are possibly required
the utilities are small enough that this does not add
much extra time to build, and in most cases, all of them
will be needed anyway
|
|
|
|
Part 2
Signed-off-by: Ferass 'Vitali64' EL HAFIDI <vitali64pmemail@protonmail.com>
|
|
|
|
|
|
|
|
the intended use-case scenario was one in which vga rom initialisation
would be used, on desktop configurations, but without coreboot itself
handling vga rom initialisation, instead leaving that task to seabios
it was assumed that grub, when running on the bare metal with
build option "--with-platform=coreboot" would be able to display
like this, but it is not so when tested
in such setups (add-on gpu with grub payload), it is necessary to
extract the video bios and insert it into the coreboot rom, having
coreboot handle such execution. this is beyond the scope of lbmk,
in context of automated building, because we cannot reliably predict
things such as PCI IDs
do away with this build option entirely, for it does not serve the
intended purpose. it will be necessary to run PC GRUB instead (build
option --with-platform=i386-pc). PC GRUB can still read from CBFS,
and you could provide it as a floppy image file inside CBFS for
SeaBIOS to execute. in this setup, GRUB would function as originally
intended by the seabios_withgrub option; such a configuration is
referred to as "SeaGRUB" by the libreboot project, and experimentation
was done with it in the past, to no avail
it's better to keep things simple, in the libreboot project. simpler
for users, that is
|
|
|
|
|
|
osboot is now part of libreboot, and will soon shut down.
libreboot now conforms to osboot policy.
|
