The payloads Libreboot uses are listed in contrib. Add a section for
U-Boot as well, now used by supported Chromebooks.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Update the Chromebook codenames in the 20221214 release news page, and
remove part of the note about missing documentation added in previous
commits.
Remove note about me doing "extensive changes to U-Boot" regarding it
being a coreboot payload, that's not exactly true. The patches in lbmk
are optional, quality of life stuff, and mostly other people's. Upstream
basically happens to work fine this way but integration could be much
much better (which I will try to work on in the future).
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Replace the placeholder "U-Boot instructions" page with initial
documentation about the U-Boot payload. Move the warnings in the
hardware index to this document, but keep a small warning with a link.
This is light on installation instructions compared to what's there on
GRUB, since U-Boot's UEFI support means generic installer images should
work and at that point I think it becomes distro developers' job. But
the added links should be enough as a good start otherwise.
Also add a section for known issues that people might want to know.
Not sure about opening lbmk issues for those, because they're mostly
long-standing upstream things and I'm not really as invested in the
issue tracker.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add initial documentation about flashing Libreboot on supported ChromeOS
devices. Link the Chromebooks in the hardware index to it. I only have
tried firmware work on gru-kevin, so there is an implicit focus on that,
but most others should be similar.
The one exception is gru-bob, as it is new enough to support Closed Case
Debugging which can be used to disable write-protect and flash the
firmware externally. Provide links to the ChromiumOS docs for that.
Although not supported on Libreboot, x86 Chromebooks still carry the
curse that is unreadable non-redistributable Intel ME firmware, so
provide a warning against flashing x86 images without it just in case.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
At least one Chromebook (gru-kevin) has GD25LQ64C [1], which is a 1.8V
8MB SPI NOR flash chip. Although it can be flashed internally, it has to
be flashed externally when a broken image is flashed. I have been using
an unmodified bad CH341A with a 1.8V adapter which works fine so far.
Try to replace mentions of 3.3V with either nondescript terms like
"power" or "VCC", or both 1.8V and 3.3V, except where it's specifically
about 3.3V. Add warnings to check the part number and datasheet for the
rated supply voltage for the chips, and to make sure to match the
flashing hardware's supply to that.
[1] https://www.gigadevice.com/flash-memory/gd25lq64c/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add new U-Boot related options to coreboot board.cfg section. Fix a
remark about not being able to build non-x86 roms. Copy the sections
documenting coreboot resources and other payload scripts, and modify
them to document U-Boot resources and scripts.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add codenames for the Chromebooks now supported in Libreboot. The names
of the per-board lbmk resources directories are slightly different than
these for naming consistency (e.g. "gru-kevin" instead of "kevin"). The
names in the coreboot src/mainboard are usually of the baseboard
("google/gru" instead of "kevin").
Also add a link to a ChromiumOS docs page listing most if not all
Chromebooks and their codename information among other things.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add an example qemu-system invocation for the qemu_x86_12mb board's
U-Boot payload. List the QEMU arm64 board in the supported hardware page
and an example invocation for that as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add some lbmk invocation examples for U-Boot. Try to keep it light in
the section that tells people to just use "build boot roms" instead,
but have more detail in the payload-specific section.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
http2 now enabled on the server, so multiple http requests
are a bit more efficient for modern browsers
this will save a bit of bandwidth, at the expense of causing
additional delay on high latency connections:
someone on 500ms latency and using http1.1 basically has to
wait an extra half-second for the site to load
(however, that's only the first time, assuming their browser
caches the css file)
Alper Nebi Yasak