I noticed that there's a patch (resources/grub/patches/0001-mitigate-grub-s-missing-characters-for-borders-arrow.patch) whose purpose is to prevent the border and arrow characters from being drawn. Presumably this is there because without a suitable font these glyphs show up as question marks, not because including the font is a license issue or for some other reason (space?).
If that is the case, one can compile the font into the grub binary and instruct it to use it as follows. First delete the patch, then include unicode in the fonts list for grub building:
I have tested this and confirmed on x200_8mb at commit 8888b2b777f42a9d208ce4c1deb987c7037ea18f.
Thanks for your attention, and apologies if i've told you something you already know!
Hi there, thanks for your work on Libreboot!
I noticed that there's a patch (`resources/grub/patches/0001-mitigate-grub-s-missing-characters-for-borders-arrow.patch`) whose purpose is to prevent the border and arrow characters from being drawn. _Presumably_ this is there because without a suitable font these glyphs show up as question marks, not because including the font is a license issue or for some other reason (space?).
If that is the case, one can compile the font into the grub binary and instruct it to use it as follows. First delete the patch, then include `unicode` in the fonts list for grub building:
diff --git a/resources/scripts/build/payload/grub b/resources/scripts/build/payload/grub
--- a/resources/scripts/build/payload/grub
+++ b/resources/scripts/build/payload/grub
@@ -54,14 +54,14 @@ for keylayoutfile in resources/grub/keymap/*.gkb; do
-O i386-coreboot \
-o payload/grub/grub_${keymap}.elf \
-d grub/grub-core/ \
- --fonts= --themes= --locales= \
+ --fonts="unicode" --themes= --locales= \
--modules="${grub_modules}" \
--install-modules="${grub_install_modules}" \
/boot/grub/grub.cfg=resources/grub/config/grub_memdisk.cfg \
/boot/grub/layouts/${keymap}.gkb=${keylayoutfile}
then direct grub, in `grub.cfg`, to load this font
loadfont (memdisk)/boot/grub/fonts/unicode.pf2
I have tested this and confirmed on x200_8mb at commit `8888b2b777f42a9d208ce4c1deb987c7037ea18f`.
Thanks for your attention, and apologies if i've told you something you already know!
i actually did it to save space. i want to save as much space as possible in the rom. so i made grub not display any characters that got messed up when doing that
i actually did it to save space. i want to save as much space as possible in the rom. so i made grub not display any characters that got messed up when doing that
however, nicer fonts may be desirable. i have a favour to request of you.
build it with lbmk as-is, where no font is added, and do:
cbfstool your.rom print
show me the output of that.
then compile the same rom for the same machine, but with this change that you specified, adding the font. show me cbfstool again
i wish to compare the difference in size
edit:
cbfstool is under util/cbfstool/ in coreboot.git. just type make in there
you can do this in lbmk:
./build module cbutils
with that, you will have the binary:
coreboot/default/util/cbfstool/cbfstool
however, nicer fonts may be desirable. i have a favour to request of you.
build it with lbmk as-is, where no font is added, and do:
`cbfstool your.rom print`
show me the output of that.
then compile the same rom for the same machine, but with this change that you specified, adding the font. show me cbfstool again
i wish to compare the difference in size
edit:
cbfstool is under `util/cbfstool/` in coreboot.git. just type make in there
you can do this in lbmk:
`./build module cbutils`
with that, you will have the binary:
`coreboot/default/util/cbfstool/cbfstool`
GRUB is actually quite flexible. The only problem is, I'm not sure how to modify the contents of memdisk on an existing GRUB build. This is why I suggest building it again.
However, GRUB doesn't take much time to compile. GCC and other requirements of coreboot take time to compile, so the user might want to rely on the above guidance alone.
At present, the bootblocks on all boards in lbmk are configured as follows: always load fallback.
Coreboot has a fallback/normal mechanism, where you can load two payloads into CBFS. What I could do in the future is modify the coreboot configs in lbmk to permit normal/fallback, and provide guidance on the documentation.
The benefit to this is to provide an easier recovery mechanism, in case the user messes up their GRUB build.
by the way, lbmk builds rom images without a payload, and then inserts them afterwards. do this:
`./build payload grub`
well, what i'm thinking is this:
if someone does wish to modify grub, they could use advice such as yours. they could even add themes
you can simply deleted `fallback/payload` in the rom, using cbfstool:
`cbfstool your.rom remove -n fallback/payload/`
then you can insert the new grub.elf from payload/grub/ when running the above command. like this:
`cbfstool your.rom add-payload -n new.grub.elf -f fallback/payload -c lzma`
The lzma option is important, because it compresses the payload.
You can also change the grub.cfg, using those instructions:
https://libreboot.org/docs/gnulinux/grub_cbfs.html
GRUB is actually quite flexible. The only problem is, I'm not sure how to modify the contents of memdisk on an existing GRUB build. This is why I suggest building it again.
However, GRUB doesn't take much time to compile. GCC and other requirements of coreboot take time to compile, so the user might want to rely on the above guidance alone.
At present, the bootblocks on all boards in lbmk are configured as follows: always load fallback.
Coreboot has a fallback/normal mechanism, where you can load two payloads into CBFS. What I could do in the future is modify the coreboot configs in lbmk to permit normal/fallback, and provide guidance on the documentation.
The benefit to this is to provide an easier recovery mechanism, in case the user messes up their GRUB build.
Here's the comparison you had asked for, note that memtest does not compile for me (a separate issue) so i omitted it from the board config for x200_8mb.
Building from head on master:
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 56920 none
fallback/ramstage 0xdf80 stage 110592 LZMA (241860 decompressed)
config 0x29000 raw 483 none
revision 0x29240 raw 718 none
build_info 0x29540 raw 107 none
fallback/dsdt.aml 0x29600 raw 14861 none
cmos.default 0x2d040 cmos_default 256 none
cmos_layout.bin 0x2d180 cmos_layout 1696 none
fallback/postcar 0x2d880 stage 21068 none
data_ccfl.vbt 0x32b40 raw 1501 LZMA (3854 decompressed)
data_led.vbt 0x33180 raw 1439 LZMA (3863 decompressed)
seabios.elf 0x33780 simple elf 63601 none
etc/ps2-keyboard-spinup 0x43040 raw 8 none
etc/pci-optionrom-exec 0x43080 raw 8 none
etc/optionroms-checksum 0x430c0 raw 8 none
etc/only-load-option-roms 0x43100 raw 8 none
vgaroms/seavgabios.bin 0x43140 raw 25600 none
fallback/payload 0x49580 simple elf 625720 none
grub.cfg 0xe2200 raw 6792 none
grubtest.cfg 0xe3cc0 raw 6780 none
background.png 0xe5780 raw 12221 none
(empty) 0xe8780 null 7351140 none
bootblock 0x7eb300 bootblock 19120 none
with the changes detailed above:
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 56920 none
fallback/ramstage 0xdf80 stage 110592 LZMA (241860 decompressed)
config 0x29000 raw 483 none
revision 0x29240 raw 718 none
build_info 0x29540 raw 107 none
fallback/dsdt.aml 0x29600 raw 14861 none
cmos.default 0x2d040 cmos_default 256 none
cmos_layout.bin 0x2d180 cmos_layout 1696 none
fallback/postcar 0x2d880 stage 21068 none
data_ccfl.vbt 0x32b40 raw 1501 LZMA (3854 decompressed)
data_led.vbt 0x33180 raw 1439 LZMA (3863 decompressed)
seabios.elf 0x33780 simple elf 63601 none
etc/ps2-keyboard-spinup 0x43040 raw 8 none
etc/pci-optionrom-exec 0x43080 raw 8 none
etc/optionroms-checksum 0x430c0 raw 8 none
etc/only-load-option-roms 0x43100 raw 8 none
vgaroms/seavgabios.bin 0x43140 raw 25600 none
fallback/payload 0x49580 simple elf 1388530 none
grub.cfg 0x19c5c0 raw 6839 none
grubtest.cfg 0x19e0c0 raw 6827 none
background.png 0x19fbc0 raw 12221 none
(empty) 0x1a2bc0 null 6588196 none
bootblock 0x7eb300 bootblock 19120 none
It appears that there's quite a difference in fallback/payload, going from 625720 to 1388530 (bytes? EDIT: what are the units?).
That's a big difference, and i would completely understand forgoing this in general.
Here's the comparison you had asked for, note that `memtest` does not compile for me (a separate issue) so i omitted it from the board config for `x200_8mb`.
Building from head on master:
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 56920 none
fallback/ramstage 0xdf80 stage 110592 LZMA (241860 decompressed)
config 0x29000 raw 483 none
revision 0x29240 raw 718 none
build_info 0x29540 raw 107 none
fallback/dsdt.aml 0x29600 raw 14861 none
cmos.default 0x2d040 cmos_default 256 none
cmos_layout.bin 0x2d180 cmos_layout 1696 none
fallback/postcar 0x2d880 stage 21068 none
data_ccfl.vbt 0x32b40 raw 1501 LZMA (3854 decompressed)
data_led.vbt 0x33180 raw 1439 LZMA (3863 decompressed)
seabios.elf 0x33780 simple elf 63601 none
etc/ps2-keyboard-spinup 0x43040 raw 8 none
etc/pci-optionrom-exec 0x43080 raw 8 none
etc/optionroms-checksum 0x430c0 raw 8 none
etc/only-load-option-roms 0x43100 raw 8 none
vgaroms/seavgabios.bin 0x43140 raw 25600 none
fallback/payload 0x49580 simple elf 625720 none
grub.cfg 0xe2200 raw 6792 none
grubtest.cfg 0xe3cc0 raw 6780 none
background.png 0xe5780 raw 12221 none
(empty) 0xe8780 null 7351140 none
bootblock 0x7eb300 bootblock 19120 none
with the changes detailed above:
FMAP REGION: COREBOOT
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 56920 none
fallback/ramstage 0xdf80 stage 110592 LZMA (241860 decompressed)
config 0x29000 raw 483 none
revision 0x29240 raw 718 none
build_info 0x29540 raw 107 none
fallback/dsdt.aml 0x29600 raw 14861 none
cmos.default 0x2d040 cmos_default 256 none
cmos_layout.bin 0x2d180 cmos_layout 1696 none
fallback/postcar 0x2d880 stage 21068 none
data_ccfl.vbt 0x32b40 raw 1501 LZMA (3854 decompressed)
data_led.vbt 0x33180 raw 1439 LZMA (3863 decompressed)
seabios.elf 0x33780 simple elf 63601 none
etc/ps2-keyboard-spinup 0x43040 raw 8 none
etc/pci-optionrom-exec 0x43080 raw 8 none
etc/optionroms-checksum 0x430c0 raw 8 none
etc/only-load-option-roms 0x43100 raw 8 none
vgaroms/seavgabios.bin 0x43140 raw 25600 none
fallback/payload 0x49580 simple elf 1388530 none
grub.cfg 0x19c5c0 raw 6839 none
grubtest.cfg 0x19e0c0 raw 6827 none
background.png 0x19fbc0 raw 12221 none
(empty) 0x1a2bc0 null 6588196 none
bootblock 0x7eb300 bootblock 19120 none
It appears that there's quite a difference in `fallback/payload`, going from 625720 to 1388530 (bytes? EDIT: what are the units?).
That's a big difference, and i would completely understand forgoing this in general.
i'm actually surprised though, that the difference can be so big. I think the dejavu sans font was only about 100kb? the one i used was, anyway.
but yes, fonts are bloat. the default one will do just fine
yes, bytes
i'm actually surprised though, that the difference can be so big. I think the dejavu sans font was only about 100kb? the one i used was, anyway.
but yes, fonts are bloat. the default one will do just fine
Hi there, thanks for your work on Libreboot!
I noticed that there's a patch (
resources/grub/patches/0001-mitigate-grub-s-missing-characters-for-borders-arrow.patch
) whose purpose is to prevent the border and arrow characters from being drawn. Presumably this is there because without a suitable font these glyphs show up as question marks, not because including the font is a license issue or for some other reason (space?).If that is the case, one can compile the font into the grub binary and instruct it to use it as follows. First delete the patch, then include
unicode
in the fonts list for grub building:then direct grub, in
grub.cfg
, to load this fontI have tested this and confirmed on x200_8mb at commit
8888b2b777f42a9d208ce4c1deb987c7037ea18f
.Thanks for your attention, and apologies if i've told you something you already know!
i actually did it to save space. i want to save as much space as possible in the rom. so i made grub not display any characters that got messed up when doing that
Agreed. Makes more sense to keep the rom minimal.
however, nicer fonts may be desirable. i have a favour to request of you.
build it with lbmk as-is, where no font is added, and do:
cbfstool your.rom print
show me the output of that.
then compile the same rom for the same machine, but with this change that you specified, adding the font. show me cbfstool again
i wish to compare the difference in size
edit:
cbfstool is under
util/cbfstool/
in coreboot.git. just type make in thereyou can do this in lbmk:
./build module cbutils
with that, you will have the binary:
coreboot/default/util/cbfstool/cbfstool
by the way, lbmk builds rom images without a payload, and then inserts them afterwards. do this:
./build payload grub
well, what i'm thinking is this:
if someone does wish to modify grub, they could use advice such as yours. they could even add themes
you can simply deleted
fallback/payload
in the rom, using cbfstool:cbfstool your.rom remove -n fallback/payload/
then you can insert the new grub.elf from payload/grub/ when running the above command. like this:
cbfstool your.rom add-payload -n new.grub.elf -f fallback/payload -c lzma
The lzma option is important, because it compresses the payload.
You can also change the grub.cfg, using those instructions:
https://libreboot.org/docs/gnulinux/grub_cbfs.html
GRUB is actually quite flexible. The only problem is, I'm not sure how to modify the contents of memdisk on an existing GRUB build. This is why I suggest building it again.
However, GRUB doesn't take much time to compile. GCC and other requirements of coreboot take time to compile, so the user might want to rely on the above guidance alone.
At present, the bootblocks on all boards in lbmk are configured as follows: always load fallback.
Coreboot has a fallback/normal mechanism, where you can load two payloads into CBFS. What I could do in the future is modify the coreboot configs in lbmk to permit normal/fallback, and provide guidance on the documentation.
The benefit to this is to provide an easier recovery mechanism, in case the user messes up their GRUB build.
Here's the comparison you had asked for, note that
memtest
does not compile for me (a separate issue) so i omitted it from the board config forx200_8mb
.Building from head on master:
with the changes detailed above:
It appears that there's quite a difference in
fallback/payload
, going from 625720 to 1388530 (bytes? EDIT: what are the units?).That's a big difference, and i would completely understand forgoing this in general.
yes, bytes
i'm actually surprised though, that the difference can be so big. I think the dejavu sans font was only about 100kb? the one i used was, anyway.
but yes, fonts are bloat. the default one will do just fine
Absolutely, thanks for your attention :)