Without this change it'll get a build error with crossgcc-x64
because $(AS) is "util/crossgcc/xgcc/bin/x86_64-elf-as --32",
and running $(LPAS) (i.e. AS=$(AS) lpas) will run "--32" instead of
"x86_64-elf-as".
Change-Id: I95e5630cb1d4f1ce81a8ca8a7bf338450b325f02
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/13845
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
I first found the missing of #include guards when I tried to include
both sandybridge/gma.h and sandybridge/sandybridge.h, but
sandybridge.h includes gma.h in it and gives a compile error.
Change-Id: I13fdb8014b82e6065be2064137b7ea10062deaca
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/13775
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This allows coreinfo to be added to CBFS as a 'secondary'
payload on x86 systems, to be loaded by the main payload
if desired.
Selecting this option, which defaults to no, builds the coreinfo
payload and adds it to CBFS as `img/coreinfo` which can then be
loaded by for example SeaBIOS or GRUB.
Change-Id: I52661d486823bc4bb215ce92dca118c9d2c2a309
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13728
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Users had to build nvramcui manually because payload.sh was only meant
for abuild. Now the user can build it with:
cd payloads/libpayload/ && make menuconfig && make && make install
cd ../nvramcui && make
Change-Id: I409a3c39a1e1738e8071febb1a3f169e1aee959a
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: https://review.coreboot.org/13778
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.
Query bit 6 instead in accordance with the Aspeed AST2050 datasheet
v1.05.
Change-Id: I05c3c7877015d95eb8d512f7410604b9af043b26
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13807
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Improved version of
I1a115a45d5febf351d89721ece79eaf43f7ee8a0
The first version wasn't well tested due to the lack of hardware
and it was to aggressive.
With timC being direct function of timB's 6 LSBs it's critical to match
timC and timB.
Some tests increments the value of timB by a small value,
which might cause the 6bit value to overflow, if it's close
to 0x3F.
Increment the value by a small offset if it's likely
to overflow, to make sure it won't overflow while running
tests and bricks the system due to a non matching timC.
In comparission to the first attempt, only 4 out of 128 timB values
are considered bad.
Needs test on real hardware !
Fixes a "edge write discovery failed" on my test system.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: If9abfc5f92e20a8f39c6f50cc709ca1cedf6827d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It was tested with a mini-PCI POST card on a Toshiba
Satellite 1410 laptop with the stock BIOS.
Change-Id: Icdc0860e2c72b17862601c2cc59eaf0f3d8a0e54
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: https://review.coreboot.org/13763
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that the SoC is configuring the UART pads there's no need to
implement bootblock_mainboard_early_init(). Remove it and
bootblock.c.
Change-Id: I2ae7ea38351733e1c9757cde20b79e1d19d0c1e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13794
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Provide a bootblock_soc_early_init() to that takes care of
initializing the UART on behalf of the mainboard when serial
console is enabled.
Change-Id: I2d3875110b6f58a9e0b4c113084b85817aa05a87
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13793
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Instead of pushing the same code into each mainboard for configuring the
the UART pads and initializing the host contoller provide a function
to perform all the actions on behalf of the mainboard. The set of pads
configured is dictated by the CONFIG_UART_FOR_CONSOLE Kconfig option.
Change-Id: I06c499c7ee056b970468e0386d4bb1bc26537247
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13792
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
There was no 'early' call into the SoC code prior to console
getting initialized. Not having this enforces the mainboard to
drive the setup of the console which typically just ends up
calling into the SoC code. Provide a SoC early init call
to handle this without having to duplicate the same code
in mainboards utilizing the same SoC.
Change-Id: Ia233dc3ae89a77df284d6d5cf5b2b051ad3be089
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13791
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
GPIO_187 is the beginning of the Northwest community pads.
Change-Id: I5565ecf534530144e80c65d886db11b53f38f935
Signed-off-by Aaron Durbin <adurbin@chormium.org>
Reviewed-on: https://review.coreboot.org/13789
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add SOC_UART_DEBUG which does all the appropriate selection of the
dependent Kconfig options for seral console. Also provide a default
option of it being turned off instead of always selected.
Change-Id: I1a6dba9c0072a17859c8f389709afe6fe3b04fac
Signed-off-by: Aaron Durbin <adurbin@chormium.org>
Reviewed-on: https://review.coreboot.org/13790
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Fix an error where a variable named 'free' was shadowing the
function 'free'.
src/lib/memrange.c:293:73: error: declaration of 'free' shadows a global
declaration [-Werror=shadow]
Change-Id: Ie57194b392f8f00ed4fd5c76dab27299b00ae293
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13788
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The used Baytrail-M SoC on TCU3 tend to have issues
with DisplayPort if the graphic power gate is not set up
in coreboot. To avoid this error, use the graphic init
code on this board.
Change-Id: I973bbaa7d86c1ede1f2884b3a08ccb31f7d85087
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13774
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
On some devices it can happen that DisplayPort TX lanes
do not work properly if the power gate setup is omitted.
If that happens, DisplayPort training will fail and therefore
DisplayPort channel will not work. Both ports are affected.
It seems that not every CPU shows this effect
and those that are affected tend to fail more often in a cold
environment.
With this fix a board that originally shows this failure
was running for over 1000 power cycles without issues.
Change-Id: Ia266674490a1bee63a85b38d1dc949dcdf683cbc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13743
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
For C_ENVIRONMENT_BOOTBLOCK, memlayout.ld is added by call to
early_x86_stage. Remove redundant addition of memlayout.ld in this
case.
Change-Id: Ibb5ce690ac4e63f7ff5063d5bd04daeeb731e4d7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/13777
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The missing braces for access to a union member
cause an error on gcc versions < 4.6.
Change-Id: I7de14a6d89219f5376f4f969adecfe8014a5a9d8
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13776
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 17cb0370a7.
It’s the wrong thing to do, to just disable the warning. The code is
fixed for 32-bit user space now in Change-Id
I85bee25a69c432ef8bb934add7fd2e2e31f03662 (commonlib/lz4_wrapper: Use
correct casts to ensure valid calculations), so enable the warning
again.
Change-Id: I6d1c62c7b4875da8053c25e640c03cedf0ff2916
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/13772
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Commit 09f2921b (cbfs: Add LZ4 in-place decompression support for
pre-RAM stages) breaks building cbfstool with gcc (Debian 4.9.2-10)
4.9.2 in Debian 8.3 (jessie) with a 32-bit user space. It works fine
in a 64-bit user space.
```
/home/joey/src/coreboot/src/commonlib/lz4_wrapper.c:164:18: note: in expansion of macro 'MIN'
size_t size = MIN((uint32_t)b.size, dst + dstn - out);
^
/home/joey/src/coreboot/src/commonlib/include/commonlib/helpers.h:29:35: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
#define MIN(a,b) ((a) < (b) ? (a) : (b))
^
```
The problem is arithmetic on void*, so explicitly cast to the wanted
types as suggested by user *redi* in #gcc@irc.freenode.net.
Change-Id: I85bee25a69c432ef8bb934add7fd2e2e31f03662
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/13771
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The builders run perl scripts in taint mode, and some of the checks
that the kconfig lint script were running were tainted, causing
the script to terminate early when running on the servers.
This checks to see if taint mode is enabled, and untaints the path
if it is. All external tools (git & grep) must be in
/bin, /usr/bin, or /usr/local/bin.
This also removes the check for unused kconfig files if taint mode
is enabled.
Change-Id: I8d1e1c32275f759d085759fb5d8a6c85d4f99539
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13751
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
When U-Boot isn't selected as a payload, two of the targets:
$(project_dir): and $(project_dir)/$(TAG-y) evaluated to the same
value, generating a make warning when running a clean. By adding
additional text to the file that is created, this is avoided.
Gets rid of these warnings:
Makefile.inc:54: warning: overriding commands for target `u-boot'
Makefile.inc:37: warning: ignoring old commands for target `u-boot'
Change-Id: I4b4df753612b674b3ccde2a757338840be92d1f2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13767
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update the documentation to add the minimal ACPI support. Also add
TempRamExit entry to the FSP features table.
TEST=None
Change-Id: I7a4576d58005a0b6834188dfeca97f1683d03cb0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13757
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There was a report that xcompile wasn't finding the compilers correctly,
so to aid in future debugging, this adds a parameter to show what
xcompile is doing as it runs.
Run from the command line:
./util/xcompile/xcompile --debug
Change-Id: I779cb3de7b4e3f62a2ef2a6245c3538be518870c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13047
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It seems that the exact behavior of -Wsign-compare changes between GCC
versions... some of them like the commonlib/lz4_wrapper.c code, and some
don't. Since we don't have a well-defined HOSTCC toolchain this slipped
through pre-commit testing. Explicitly silence the warning to ensure
cbfstool still builds on all systems.
Change-Id: I43f951301d3f14ce34dadbe58e885b82d21d6353
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13769
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some users may wish to run this script using a coreboot image
that does get built in the usual build/ directory, for example
if abuild is used to generate the image.
Change-Id: I7e98780f8b7b57ebbf3babd6a289f0e4fd4103d8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/12489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Use shared gpio code from common folder.
Remove the now unused bd82x6x/gpio.c.
Needs test on real hardware !
Change-Id: Ibb54c03fd83a529d1ceccfb2c33190e7d42224d8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13616
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Use shared gpio code from common folder, except for
INTEL_LYNXPOINT_LP, which has it's own gpio code.
Needs test on real hardware !
Change-Id: Iccc6d254bafb927b6470704cec7c9dd7528e2c68
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13615
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This turned out really handy when I tried to build coreboot
for my Chromebox.
These scripts can be used to extract System Agent reference code
and other blobs (e.g. mrc.bin, refcode, VGA option roms) from a
Chrome OS recovery image.
crosfirmware.sh downloads a Chrome OS recovery image from the recovery
image server, unpacks it, extracts the firmware update shell archive,
extracts the firmware images from the shell archive.
To download all Chrome OS firmware images, run
$ ./crosfirmware.sh
To download, e.g. the Panther firmware image, run
$ ./crosfirmware.sh panther
extract_blobs.sh extracts the blobs from a Chrome OS firmware image.
Right now it will produce the ME firmware blob, IFD, VGA option rom,
and mrc.bin
Change-Id: I5fb7e14b10e03e18cd360bc35f1dc92e8ed34e63
Signed-off-by: Joe Pillow <joseph.a.pillow@gmail.com>
Reviewed-on: https://review.coreboot.org/13752
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The urara bootblock is less than a kilobyte from its limit (20K).
There's more than enough space available so increase it to avoid
impeding changes to core code.
Also add some more automated checks to better model the platform's
multiple windows into the same memory region and guard against
accidental overlaps by a seemingly benign change to one window.
Change-Id: I2e535b56d5d1748830ea1e70fd12fd9e87009bce
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13733
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Stages are inconsistent with other memlayout regions in that they don't
have _<name> and _e<name> symbols defined. We have _program and
_eprogram, but that always only refers to the current stage and
_eprogram marks the actual end of the executable's memory footprint, not
the end of the area allocated in memlayout. Both of these are sometimes
useful to know, so let's add another set of symbols that allow the stage
areas to be treated more similarly to other regions.
Change-Id: I9e8cff46bb15b51c71a87bd11affb37610aa7df9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13737
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable the minimal ACPI tables. Initialize the FADT header and provide
an empty DSDT.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Edit .config file and add the following lines:
* CONFIG_PAYLOAD_ELF=y
* CONFIG_PAYLOAD_FILE="path to UEFIPAYLOAD.fd"
* Testing successful if:
* Outputs multiple lines of debug serial text
Change-Id: I2e30c8af2994c9f56d9ba4fe6bc35e133b1d2d6b
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13759
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add all needed functions to fsp_baytrail so that reg_script can
do full iosf access. To keep it simple, this patch synchronises
iosf access between baytrail and fsp_baytrail.
Change-Id: Ic7f52d7d90c0fe3560fa5a5d96f7fc15062d66d1
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change I9dd8e4027be21363015cd8df9918610e206afce2 replaces
colons with underscores in paths, to improve compatibility of paths.
This breaks any attempt to interpret the timestamp part of the tree
as a timestamp, so revert the change before doing so.
Change-Id: I0e82e4045120700e9b4fcc8c6e54d761068eaea3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://review.coreboot.org/13766
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Only i386 has code to support bounce buffer. For others coreboot
would silently discard part of binary which doesn't work and is a hell to debug.
Instead just die.
Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13750
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the build instructions for CorebootPayloadPkg to target the
Galileo Gen2 platform.
TEST=Build and run on the Galileo Gen2 platform.
Change-Id: I9ca8a67811eff988f81f04d4c01c77115356c050
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13756
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Enable baud rates of 230400, 460800 and 921600. Leave the default set
to 115200.
TEST=Build and run on Galileo at 921600.
Change-Id: I8e3980f33665bc183b454cf97c68e297f1b0502c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13755
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
coreboot passes information about the serial port implementation to
payloads through a cbtables entry.
We set the register width to 1 on most SoCs because that looked as good
a default as any, but checking the uart structs they use, it's 4 for all
of them.
Change-Id: I9848f79737106dc32f864ca901c0bc48f489e6b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13746
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
The commit description is enough and this avoids hourly updates of the
timestamp by a cron job.
Change-Id: I30e9fcf28caf94edbb816c22bc8fbcb7ab09ae6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I952a694f645caf9d9726965e39afc09c6fdce0e3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13741
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I1240c215f3d6c3934911c096e2ecbabff175d501
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13740
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Old map does not work on recent qemu. New map puts coreboot to ROM, so
it behave more like most real machines would.
For details on this map see comment in memlayout.ld
Change-Id: If1f3328b511daca32ba93da5a6d44402508b37e9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Some vendors store lower frequency profiles in the regular SPD,
if the SPD contains a XMP profile. To make use of the board's and DIMM's
maximum supported DRAM frequency, try to parse the XMP profile and
use it instead.
Validate the XMP profile to make sure that the installed DIMM count
per channel is supported and the requested voltage is supported.
To reduce complexity only XMP Profile 1 is read.
Allows my DRAM to run at 800Mhz instead of 666Mhz as encoded in the
default SPD.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: Ib4dd68debfdcfdce138e813ad5b0e8e2ce3a40b2
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13486
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
If we only need to "combo" two PSP directories into one image,
we can put first address in romsig 0x10 and second one in
romsig 0x14.
If we really need to put three, the 0x14 is the combo directory
which points to multiple level-2 PSP directories.
I guess that two PSP can also use combo directory, with only
one level-2 directory. But nobody seems to do that.
Change-Id: Ic450a846bc04db90a75cd417b6d7104fe2a5b177
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/13739
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Iru Cai