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