| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Yeah.
|
| | |
|
| |
|
|
|
|
| |
R500 support in its current state should not be merged in the master branch.
This will likely not make it into the immediate upcoming release. This patch
will be reverted in a separate experimental branch, for the time being.
|
| |
|
|
|
|
|
| |
Use NPROC=foo
Replace "foo" with a number. By default, the build system uses $(nproc).
This patch allows the user to specify any number of cores. This is useful
on some systems, or certain chroot environments.
|
| | |
|
| | |
|
| |
|
|
|
| |
This will speed up the build process. The plan is to, if possible,
always use 1 revision.
|
| | |
|
| | |
|
| |
|
|
| |
Only text mode works on this board.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The release archives will be bigger, but this is a necessary change
that makes libreboot development easier.
At present, there are boards maintained in libreboot by different
people. By doing it this way, that becomes much easier. This is in
contrast to the present situation, where a change to one board
potentially affects all other boards, especially when updating to
a new version of coreboot.
Coreboot-libre scripts, download scripts, build scripts - everything.
The entire build system has been modified to reflect this change
of development.
For reasons of consistency, cbfstool and nvramtool are no longer
included in the util archives.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add coreinfo as optional payload providing various
useful system information.
As part of coreboot, coreinfo does not need to be
downloaded seperately, just build it using
$ ./build module coreinfo
after downloading and building coreboot.
See https://www.coreboot.org/Payloads#Coreinfo for
more information.
|
| | |
|
| | |
|
| |
|
|
| |
We now tell coreboot's build system what version string to use.
|
| | |
|
| |
|
|
|
| |
This is one of the things needed, for building coreboot in a
reproducible fashion.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Not all CrOS devices are Chromebooks (laptops) or run on ARM, not all RK3288
CrOS devices are Chromebooks, either.
We want to support more CrOS devices, including some that are not Chromebooks,
such as the ASUS Chromebit!
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
find bin/grub [...] also searches other boards'
ROMs and thus would print a ROM layout not
neccessarily belonging to the same board images
got built for.
|
| |
|
|
| |
klemens, please merge this!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Also contains other fixes from coreboot, like:
* 551cff0 Derive lvds_dual_channel from EDID timings.
^ makes single/dual channel LVDS selection on GM45 automatic
* 26fc544 lenovo/t60: Enable native intel gfx init.
^ was being maintained in libreboot, now upstreamed so not needed
Framebuffer mode was disabled for the KGPE-D16, because only
text-mode works at the moment.
|
| |
|
|
| |
Forgot to do this during rebase
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces Libreboot support for the Asus Chromebook C201 (codename
veyron_speedy). At this point, this produces a standalone Libreboot image that
can be flashed to the RO Coreboot partition of the SPI flash, as well as the
Libreboot version that can be flash to the RO Firmware ID partition.
Libreboot on the Chromebook C201 uses the depthcharge bootloader, modified to
display text messages instead of ChromeOS bitmaps (that encourage the use of
ChromeOS).
For convenience, an installation script, chromebook-flash-replace, is provided
along with a description of the flash layout, to ease the replacement of the
Coreboot and RO Firmware ID partitions on the full SPI flash image.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ich9deblob and ich9gen utilities were modified, so that they
support reading and/or writing descriptor images where the GbE
region is not defined. These utilities were also re-factored
and tidied up a bit.
A quick was noticed during the course of this work, in that
Compenent 1 Density was being set to 8MiB constantly, even
on systems with 4MiB flash chips. Component 2 Density was
set statically to 2MiB. ich9gen now sets both to 4MiB or 8MiB,
depending on whether building the descriptor for a 4MiB or
8MiB ROM image.
There are still some ACPI bugs (see docs/hcl/r500.html), which
will have to be fixed upstream. TODO: get hw reg dumps from
a factory R500, and compare with the X200 or T400 dumps.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Otherwise, these are brick.rom images
|
| |
|
|
| |
Otherwise, these images are brick.rom images
|
| | |
|
| | |
|
