It just doesn't work to have files depend on their parent
directory: As soon as the files are written, the time stamp
of the directory changes, too.
This led to spurious updates of cbfstool and rmodtool, and
related "permission denied" errors when linker and build
system ran into each other.
Change-Id: I44a7d7b4b1d47a1567ece1f57dfd6745d05ee651
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6276
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
It's probably safe to say that .xcompile needs an update if
util/xcompile/xcompile changed, so tell make about this
dependency.
Updates are honored immediately due to GNU make's feature of
reinterpreting everything when an included file changes. See "How
Makefiles Are Remade" in the GNU make documentation for details.
Change-Id: Ide2f028eaddcee66028c6403688cc83e1622fa6b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6255
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This uses die() which was previously unused.
Before this change an unhelpful error message was printed when make tried
to parse English text as if it was part of the makefile:
.xcompile:1: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
After this change the first error message at least mentions that iasl is
missing:
ERROR: no iasl found
make: -print-libgcc-file-name: Command not found
make: -print-libgcc-file-name: Command not found
make: -print-libgcc-file-name: Command not found
/bin/sh: 0: Illegal option -
Makefile.inc:36: *** Please use the coreboot toolchain (or prove that your toolchain works). Stop.
Change-Id: I79d5de5993e3828460130192df376daa55f32aa0
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6272
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Only yangtze has longer FIFO in SPI controller. This was overlooked
in commit
9f0a2be AMD SPI: Optimise for longer writes
which broke SPI writes and caused CBFS errors with fam15tn.
Change-Id: I821e3f1fa186d2383b30eab9c5d52797c2ef22c5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6273
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Like many other (but not all) BiosCallouts, StdHeader is also passed
as ConfigPtr argument. Use that instead to make no assumptions of the
real type of FchData as it changes depending of the StdHeader.
Change-Id: Ibdf01d08e63b9e1b8e99ac16abb7f807d37a056e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6240
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Followup deals further with Fam15 case. For unknown reasons calls
were commented out for amd/dinar and they remain that way.
Change-Id: Ie0a25fbb6f5378019fbf0f19a02acf024d79817e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6237
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
AGESA correctly uses the enum AGESA_STATUS type whereas boards use a
mess of UINT32 typecasts.
Also no need to shout VOID. We are not that careful on changing
all cases of VOID->void or whitespace issues as these files will
get merged with follow-ups.
Change-Id: I16ccfcc73cda6b917c7ff5fd42ee2cd04e7dc0dd
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6182
Tested-by: build bot (Jenkins)
Leave it to the implementation of flash->write() to split the writes
to match SPI controller and SPI flash part restrictions. This allows
for some optimisation for auto-address-increment (AAI) commands.
Kconfig AMD_SB_SPI_TX_LEN can be kept as local.
Change-Id: I4a8bc55ab7eb0eeda8f25003a8f5ff2a643ab7a7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6164
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
SPI controllers in Intel and AMD bridges have a slightly different
restriction on how long transactions they can handle.
Change-Id: I3d149d4b7e7e9633482a153d5e380a86c553d871
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6163
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
There are two separate restrictions to take into account:
Page Program command must not cross address boundaries defined by the
flash part's page size.
Total number of bytes for any command sent to flash part is restricted
by the SPI controller capabilities.
Consider
CONTROLLER_PAGE_LIMIT=64, page_size=256, offset=62, len=4.
This write would be split at offset 64 for no reason.
Consider
CONTROLLER_PAGE_LIMIT=40, page_size=256, offset=254, len=4.
This write would not be split at page boundary as required.
We do not really hit the second case. Nevertheless, CONTROLLER_PAGE_LIMIT
is a misnomer for the maximum payload length supported by the SPI controller
and is removed in a followup.
Change-Id: I727f2e7de86a91b6a509460ff1f374acd006a0bc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6162
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
FLVL is used to keep track of which thermal zones are active, but it is
not initialized upon boot / resume. An initial value of zero corresponds
to all zones being active, which causes the fan to spin at max speed
until the OS changes zones. Fix this annoyance by initializing FLVL to
the lowest temperature zone.
Also, fix a related bug where FLVL may jump to an undesired value. For
example, if FLVL=3 (zones 3 + 4 active), and zone 0 is set to off (it's
already off!), FLVL would previously become 1 (zones 1 + 2 + 3 + 4
active!). Fix this by not taking zone ON / OFF actions if our zone is
already ON / OFF.
BUG=chrome-os-partner:25766, chrome-os-partner:24775
TEST=Suspend / resume on Panther 20 times, verify that thermal zone after
resume matches expectation based upon temperature. Also, stress system
and verify thermal zones become active according to temperature
increase.
Change-Id: Ic60686aa5a67bf40c17497832b086ba09d56111a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186455
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186669
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/6006
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Without this patch coreboot will always use the read-only version
of ramstage, even if there is a read-write version available.
BRANCH=panther
BUG=chrome-os-partner:25870
TEST=Install different RO and RW version, check in cbmem log that
coreboot's romstage and ramstage have different timestamps
in their banners.
Change-Id: I723a3d4479d59534660728d891a9f40a077b4ef0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186664
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/6005
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When the thermal sensor on Panther is unavailable (early on resume)
it will return 0x80 which causes our AML thermal code to overflow,
which causes the system to shut down. Instead, return a reasonable
value in those cases so that the system will continue running until
the sensor gets back on its feet.
BUG=chrome-os-partner:24918
BRANCH=panther
TEST=suspend_resume_test survived more than 100 iterations on Panther
Change-Id: Ib2d714c39d353ce2415361bc6590784a3f6837d2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182369
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/6002
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Some SSD modules don't support DEVSLP correctly due to their
firmware. Since the power savings are minimal, don't use
DEVSLP to prevent potential problems. Some of the symptoms
are that sometimes this causes USB devices to not work properly.
BUG=chrome-os-partner:23186,
BRANCH=panther
TEST=Boot tested on Panther
Change-Id: Iba3f721c73e0e760b6a9861ca23480ddb923df40
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181957
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5999
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There needs to be an ACPI linkage to provide the power resource
needed to wake this device so the kernel will enable the SCI
before going to suspend.
A link is added for both NIC and WLAN, but it is only tested
on the NIC.
This is a forward port from Duncan's beltino patch.
BUG=chrome-os-partner:24657
BRANCH=panther
TEST=build and boot on panther, suspend and wake with etherwake
Change-Id: I2804d2e904e26d6e34f5a177f0dabc1aaa3f0288
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181752
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/5998
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
(Panther clone of Ia41af8425ab6c24746253abd025acd3365dd5a18 by reinauer)
BUG=chrome-os-partner:23563
TEST=emerge-panther chromeos-coreboot-panther
[pg: Drop configs/, which is chromeos stuff, adapted
libpayload's config.panther to work with upstream]
[pm: Add HAVE_IFD_BIN and HAVE_ME_BIN Kconfig options]
[pm: rebase to master branch of coreboot upstream]
[md: don't use FMAP to get MAC address if CONFIG_CHROMEOS not set]
Change-Id: I50fd5c02da154e424dfefbe2020f4ce7ef9a4f8f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/174555
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: http://review.coreboot.org/5990
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The fan2 (chasis fan) was set to automatic mode, but the
registers for smart guardian have still default value which
will stop it. Run it in manual mode for now.
Change-Id: Ic2c2414ac88abba77a9e7a129788f9777e7e5ad5
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/6217
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
When USB3 devices are attached while in suspend, or two USB3 devices
that are both plugged in are switched to the other port while in
suspend the kernel does not seem to notice this -- despite the cold
attach status bit. This results in the devices showing up in the USB
list at the old enumerated device numbers and higher layers continuing
to think they are present but not reseponding.
With the kernel workaround to deal with devices that are logically
disconnected it is possible for firmware to send a warm port reset to
devices that are in this state and then the kernel will see them disappear
and handle it properly.
This same issue exists in the EFI firmware on the Whitetip Mountain 2
reference board so it is not specifically a coreboot bug. If this
behavior is fixed in the kernel then this workaround could be removed
since it is in RW firmware.
BUG=chrome-os-partner:22818
BRANCH=falco,peppy,wolf,leon
TEST=manual:
1) attach two USB3 devices
2) suspend system
3) switch the ports that the USB3 devices are attatched to
4) resume system
5) confirm that the devices are re-enumerated and come up properly
Original-Change-Id: Ifba3ffc94a06dc0b2436d7d7d464d824657362af
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 203d200268f4af6445224962190cbc66ad2a83e4)
Change-Id: I54fd2847ee25a60f25c2cefebdc1a3c18455464a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170579
[pm: rebase to master branch of coreboot upstream]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6017
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
I have been attempting to work around USB3 issues that appear in the
kernel with hacks in the firmware, but this is resulting in more
headaches in the kernel.
Instead remove all the work that was being done at resume time and undo
the change that was issuing a warm reset to all ports at suspend time.
The bad device behavior will be dealt with at the kernel level to
handle devices that get stuck in polling state after enable/disable
sequence.
BUG=chrome-os-partner:22754
BRANCH=falco,peppy,wolf,leon
TEST=manual:
suspend/resume with several misbehaving devices:
Kingston USB3 Media Reader
Transcend USB3 Media Reader
Various ADATA USB3 drives
Various Kingston USB3 sticks
Original-Change-Id: I0894454af42d2ced456fe0da921d74c9e74902d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170107
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c2abb4d0dad6ed00e1e230d604c4c0a76eb4eef7)
Change-Id: Ib215d9c230f90a1c9f34bf29254bb9feec28c67e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170578
[pm: rebase to master branch of coreboot upstream]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6016
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Worked out the purpose of more int15 calls and let them return
appropriate values. Also remove handlers for copy-pasted calls never
observed on this board.
Change-Id: I3d8c4ec5542bd19baca1dca83badc9b568779e1b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6249
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Fix some outputs of the super i/o that should be GPIOs and make
variables out of magic values that configure LVDS.
Change-Id: Ib9eef065980cefff0046485549a68cf8f070d5b9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6248
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Implement the fix for the erratum #712. - Processor May Hang During Graphics Memory Controller
Sequencing
The processor may hang during a graphics memory controller (GMC) sleep state transitioning. The failure may
be processor specific and may be sensitive to temperature.
Potential Effect on System:
System hang.
Suggested Workaround:
BIOS should set D18F2x408_dct[1:0] bit 31 = 1b.
See Publication # 48931 Revision: 3.08
Change-Id: I4346fd4ef3cf554ffdaaad5ab6fc84e73532e885
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/6216
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
In an abuild run, cbfstool is built in a shared directory
using "make tools". Unfortunately the build system doesn't
actually use that binary directly but creates a per-board
copy (for convenience purposes when editing the image later)
and uses that.
With this change the build system uses the original file but
still creates the copy for the user, avoiding the race while
ensuring convenience.
Change-Id: I38c603a7eca5ef859875ad3031bf7a850189645f
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/6242
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Setting of `controller->reg_base` is of no use here, as it is never read
(in another function) later. Looks like this pattern originated from uhci.c
where it makes sense.
By removing the indirection through `reg_base` we also fix a possible
truncation to u32.
Change-Id: I5c99c5bf1f5b1d6c04bd84d87fd3e275fd7d0411
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6251
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
