The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
Change-Id: I06ba773da3af249efec723bb90c2e9e8075a777a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
Change-Id: I270bbfd3aff781d88304791b1d9735777643caab
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That part isn't used on pit.
Change-Id: I48f3a10f7e6eb89b1e9630d2372b6865b4c12a7f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3687
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
Change-Id: I7218f85f9f26623bd13aaaf8ded0638b3b2f874a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The members data structures in dmc.h are intended to have a particular size.
Rather than assume that particular types are the right size, we should use
types that are guaranteed to be the right size. Also, since the registers are
at particular offsets as well, the structures should be packed.
Change-Id: I9cc11d7451f92ba3eb85c6be88ecbc62c7a5652d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3685
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The previous driver was a bit awkward and not entirely correct. This change
primarily replaces the read/write functions with simpler and more robust
(hopefully) version.
Change-Id: I55f0ad8faec2de520e27577bd6dad9c0118d8171
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Change-Id: I4e4c22a0693988834e619dd33d121bf994ed57e8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The dmb should be executed before reading operations, and before/after writing
operations.
Change-Id: I572136a2f9a07eb2c38a112f5deeb2de0c0fd46c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This updates the low-level I2C code to handle the new high-speed
HSI2C/USI inteface. It also outputs a bit more error information
when things go wrong. Also adds some more error prints. Timeouts
really need to be noted.
In hsi2c_wait_for_irq, order the delay so that we do an initial
sleep first to avoid an early-test that was kicking us out of the
test too soon. We got to the test before the hardware was ready
for us. Finally, test clearing the interrupt status register every time
we wait for it on the write. Works.
Change-Id: I69500eedad58ae0c6405164fbeee89b6a4c6ec6c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3681
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
Change-Id: I9c6f21f183dacc0bca71277e681e670834412d78
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3680
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds register offsets and important values for the Maxim
MAX77802 PMIC.
Change-Id: I3724b82bcb235b6684d2b976876f628f1ffbed3f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
Change-Id: I3e1e17ffe82ae270eea539530368a58c6cfe0ebe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 5420 clock code still had a data structure in it for the 5250 clock
registers which was used by some of the clock functions. That caused some
clocks to be configured incorrectly, specifically the i2c clock which was
running at about 80KHz instead of about 600KHz as configured by U-Boot.
Also, the registers and bit positions used to set up the SPI bus were not
consistent with U-Boot, and if the bus clock rate were set to 50MHz, a rate
which has historically worked on snow, loading would fail. With these fixes
the clock rate can be set to 50MHz and the device boots as much as is
expected. I haven't yet measured the actual frequency of the bus to verify
that it's now being calculated correctly.
Change-Id: Id53448fcb6d186bddb3f889c84ba267135dfbc00
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3678
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested and working. Gets us to ramstage.
Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds entries for I2C8-10 to giant switch statement in
clock_get_periph_rate(). It also eliminates the I2C peripheral's
usage of clk_bit_info since it's confusing and error-prone.
Change-Id: I30dfc4c9a03fbf16d08e44e074189fb9021edb6d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code has been there for quite a while but was never enabled.
Change-Id: I4ec3dcbb3c03805ac5c75872614e5d394df667cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3675
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
Change-Id: I2152ab760e31a335dbcd9d6ad32cd1eaae4b89bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3670
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
remove some unused code
Change-Id: I41602fb391c1910c588a4f9dcc7c2edefe8ab5bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3669
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we
make it uncacheable first, the writes will be serialized writes of
whatever sized chunks memset uses, probably 4 bytes or less.
Change-Id: I960f87a370e97f9e91236ad796d931573bb3dbb8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3668
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At one time it seemed to be necessary to disable and then re-enable the
MMU when setting the framebuffer to be uncache-able due to bugs in the
MMU management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I7ce825cf5eaaa95119364d780cba0935752e4632
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code which figured out the rate of the input clock to a peripheral was
doing several things wrong. First, it was using the wrong values when
determing what the source of a clock was set to. Second, it was using the
wrong offset into that register to find the current source setting.
This change fixes the constants which select a clock source which get some
more things working, but doesn't attempt to fix the bit position table.
Change-Id: Id7482ee1c78cec274353bae3ce2dccb84705c66a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
Change-Id: I3f8060bff32d3a49f1488b26830ae26b83dab79d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: http://review.coreboot.org/3746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
Change-Id: Ie349f2a4117883302b743027ed13cc9705b804f8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome EC still does not tolerate SERIRQ in quiet mode
and so the keyboard does not work properly.
Change-Id: I9ab052187c9926ce0e2c86b86dfe987dd6564c1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This stuff is not used, so let's drop it.
Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With only 19 source files it doesn't make a whole lot of sense to
create sub directories in arch/armv7, especially since the files
were distributed somewhat randomly.
Change-Id: I029c7848e915edf1737e1c401c034837c95d179d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3659
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new code is stolen from U-Boot with little or no understanding of how it
works.
Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function had been declared in a public header file, but was marked
static when actually defined.
Change-Id: Ia551a5a12e7dbaf7bc00861e085695145ab7b91a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3657
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we make
it uncacheable first, the writes will be serialized writes of whatever sized
chunks memset uses, probably 4 bytes or less.
Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At one time it seemed to be necessary to disable and then re-enable the MMU
when setting the framebuffer to be uncache-able due to bugs in the MMU
management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When modifying the page tables, use writel to ensure the writes happen, flush
the page tables themselves to ensure they're visible to the MMU if it doesn't
look at the caches, and invalidate the right TLB entries.
The first two changes are probably safer but may not be strictly necessary.
The third change is necessary because we were invalidating the TLB using i
which was in megabytes but using an instruction that expects an address in
bytes.
One symptom of this problem was that the framebuffer, which was supposed to be
marked uncacheable, was only being partially updated since some of the updates
were still in the cache. With this change the graphics show up correctly.
Change-Id: I5475df29690371459b0d37a304eebc62f81dd76b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3653
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Coreboot knows that, for the snow board, certain pins are to be connected to
bus controllers in the SOC and to the wires of a bus external to the SOC. It
can configure them as such and free its payload from having to know how to
set everything up.
Change-Id: I1bb127c810e9ee077afc4227a6f316eaa53d6498
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3650
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Change-Id: I53a40d114aa2da76398c5b97443d4096809dcf36
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3730
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I1fef27c4a16ee4358ace8014a8d6e9fa92c4f790
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3728
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ifea10f0180c0c4b684030a168402a95fadf1a9db
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3727
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The page tables need to be aligned to a 16KB boundary and are 16KB in size.
The CBMEM allocator only guarantees 512 byte alignment, so to make sure
things are where they're supposed to be, the code was allocating extra space
and then adjusting the pointer upwards. Unfortunately, it was adding the size
of the table to the pointer first, then aligning it. Since it allocated twice
the space of the table, this had the effect of moving past the first table
size region of bytes, and then aligning upwards, pushing the end of the table
out of the space allocated for it.
You can get away with this if you push things you don't care about off the
end, and it happened to be the case that we were allocating a color map we
weren't using at the start of the next part of cbmem.
Change-Id: I6b196fc573801b02f27f2e667acbf06163266651
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3651
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3649
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change adds a pit mainboard which is mostly a copy of snow, except that
mentions of the 5250 were replaced with the 5420, and mentions of snow were
replaced with pit.
Change-Id: I8eb0ce379eb2fa353bb88d5656a0c5e2290afbf0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some of the settings which were defaulted to or automatically selected for the
exynos5420 which were inherited from the exynos5250 were not correct for this
SOC.
Change-Id: I11ffd8a6b80628405ac493fe2139f79c05d15d7e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3645
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3740
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The enumeration results are stored as five DWORDs in one 20 byte buffer.
Bytes 3, 7, 11 and 15 were used to set the lowest bit of each DWORD.
ACPI uses little endian, so 1, 4, 8 and 12 are the correct indices.
Change-Id: I793225cb1bb62fd148ecfa1e61e02f5d7be62cdb
Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de>
Reviewed-on: http://review.coreboot.org/3602
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In ram stage, all code flow should be tied to the resource allocator.
Stuff that has to happen before everything else goes into the mainboard
enable function in mainboard.c. This patch empties the main() wrapper
around hardwaremain.c, allowing to get rid of this special case in the
ARM port.
Change-Id: Ide91a23f1043b64acf64471f180a2297f0f40d97
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3638
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: I07512b3695fea0b22949074b467986420783d62a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3637
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default for this variable should be n, it should only depend on
EC_GOOGLE_CHROMEEC, and it should be (and is) explicitly enabled when
needed. This prevents it from being turned on when the EC bus is SPI.
Change-Id: Idc6651a764be4f055341a36b9b4a58990f050b0c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3737
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via
MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage.
The implementation of pci_default_config() always returned with
pci_cf8_conf1. This means any PCI configuration access that did
not target bus 0 used PCI IO config operations, if PCI MMIO config
was not explicitly requested.
Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3606
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Without that fix, and with CONFIG_SMM_TSEG, we have:
src/southbridge/intel/i82801gx/smihandler.c: In function 'southbridge_smi_sleep':
src/southbridge/intel/i82801gx/smihandler.c:340:3: error: implicit declaration of function 'smi_release_lock' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make: *** [build/southbridge/intel/i82801gx/smihandler.smm.o] Error 1
The fix is modelled after src/cpu/x86/smm/smihandler.c which
ifdefs smi_release_lock().
Change-Id: Icdc6d039b34a1d95d0e607419bba2484d21abc5e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3281
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This mistake was spoted by comparison with the
src/southbridge/intel/bd82x6x/smihandler.c file.
Change-Id: I1516f0131d524bd7d001e6780e9a45402d1814d1
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add an option to mark all SPI regions write protected on each S3 resume.
We were used to lock the SPI interface in the payload which isn't run on
the resume path. So we have to do it here.
For the write protection to be effective, all write opcodes in the
opmenu have to be marked correctly (as write operations) and the whole
SPI interface has to be locked. Both is already done.
Change-Id: I5c268ae8850642f5e82f18c28c71cf1ae248dbff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3594
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This code is the initial version of FUI for haswell and wtm2.
The code is simplified from before in many ways. I've gotten rid of
the opcode table, because it obscured meaning and I don't think it is
needed any more. Register sets, mainly used for reset, are just lines
of code -- not many of them. There are a bunch of not-yet-documented
registers here; the VBIOS seemed to think they were necessary and
testing shows they seem to be right.
As a bit of added paranoia, we always include the VBIOS code as our
emergency recovery path. You have to run it now anyways, so this is no
regression from our current situation; and, if all goes well, in a
week (or so), you'll never have to run it again, but like the Force
and nose hair, it will be with you always.
The code can return in three ways. The first, best way is success:
panel is up and the VBIOS need not run. The second mode is that we
tried to light up the panel but could not, for some reason, but will
return with the panel partly up. In this case, it's ok not to power
cycle the panel. The third, worst case, which will NEVER happen, ha
ha, is that we have to turn the panel off and wait the required 600ms
for it to cycle. Life sucks sometimes. This failure mode is in the
'hang on we're going to fix it' category now that we have ramstage in
RW.
The Big Goal here is to create something other coreboot ports can use
as well. The guys doing the x60 report that the link FUI works,
without too many mods, on that chipset, so it seems Intel is keeping
things from changing too much over time.
Also, again, please note: this and the next 3 versions will ALWAYS fail.
The goal is to verify the correctness of the recovery path.
The bizarre tab-space formatting in drm_dp_helper.h is from the original,
as in i915_reg.h
Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3635
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This lights up the display. We don't get graphics but we are missing the gttsetup
at this point, so that is no shock. The real shock is that anything works at all.
Change-Id: I03fc470334e96878aeb8465044b3cc9c90378735
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3634
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch was started by Dave Hendricks and implements the procedure for
setting up the UART as described in the manual. Some unused code was removed.
Change-Id: If26a424cac401ef3eafaec081147f41184fbcee9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3490
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The PnP's logical device activation normally resides at 0x30. This might
have been overlooked as 0x29 looks very close to 0x30 in human eyes.
Change-Id: Id5d5a92f2683ebe1808b943f686c062151d216da
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3592
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The enumeration method tried to evaluate an one-byte OperationRegion
instead of a field in this OperationRegion, which resulted in an
AE_TYPE error at runtime.
Indexing the OperationRegion with a single field fixes this error.
Change-Id: I15dd7aa6ecafb3a215d165d2b721003446815025
Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de>
Reviewed-on: http://review.coreboot.org/3603
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change all PCI configuration accesses to MMIO on two boards
with i5000 chipset. To enable MMIO style access, add explicit
PCI IO config write in the bootblock.
Change-Id: I26f1c2da5ae98aeeda78bdcae0fb1e8c711a3586
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I missed the board with gm45 when I moved MMCONF_SUPPORT lines.
Also, the intel/i3100 does not have MMCONF_SUPPORT implemented
even though it was previously selected for intel/eagleheights board.
Change-Id: I9c7f6b0a150b4d54288a1e015277b9d98467fca4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3598
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change all PCI configuration accesses to MMIO on all boards
with SandyBridge and IvyBridge. To enable MMIO style access,
add explicit PCI IO config write in the bootblock.
Change-Id: I8f957a80bf57df000897c5a080dd5ff131b1ec0d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3576
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Move/remove MMCONF_SUPPORT reference under mainboard Kconfig, as
that feature originates from northbridge and cannot be disabled
for a single mainboard.
Change-Id: I6d6861079876ddddaff90b10f18edb6936e93bd0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3589
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The W83627DHG has some power managements bits to power down individual
logical devices. These are called `* Power Down`. Counterintuitively and
in contrast to `Immediate Power Down` (bit to power down the whole chip),
these bits are set when the respective logical device is powered.
Unfortunately, our ACPI code set them wrong which led to disabled
devices after a S3 suspend/resume. Adding an option how to set the PM
bits and setting them to zero for the W83627DHG, corrects it.
Tested with kontron/ktqm77.
Change-Id: I8a472d480d4277721bd17c9f7c2ce44fa84e8ae2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3590
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use the same indentation, comment placement and spelling of words.
Run `indent -linux …`.
Change-Id: Id5765c45b28058cdd50ee4c0a1fd9f645ad7f3f8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3220
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The MAX_PIRQ_LINKS is defined in src/Kconfig with a default value
of 4. The src/northbridge/via/vx900/Kconfig also defines
MAX_PIRQ_LINKS with a default of 8 and it ends up giving us
a value of 8 for non-VIA platforms.
Change-Id: Iee1938d38a93ab7c35c8cb6fe9656a92cf3fa21e
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3586
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add comments in PAR0._PRS explaining which dependent resource
descriptor puts the parallel port into EPP or SPP mode.
Change-Id: If4e224dbaf6f9105cde88d995d2e7c74fbf14502
Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de>
Reviewed-on: http://review.coreboot.org/3495
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Set up the pinmux to enable the pins and the clocks for whichever UART is
currently configured.
Change-Id: Iac13f16d9d84320555b99734ea83eafd0a2803fe
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3573
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pinmux register data structure describes a subset of the control module
registers, but the address which pointed to the base of the pinmux registers
was actually being set to the beginning of all the control module registers,
not just those having to do with the pinmux. With this address fixed, the UART
now works on the beaglebone black.
Change-Id: I7c99b6f37d7da359af074127cd0c1a86fda2d9a0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3574
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
All the additional work that needs to be done in EHCI BAR relocation
is independent of the hardware platform and was functionally identical
in all the copies removed.
When USBDEBUG is not selected, PCI EHCI controllers use standard
pci_dev_read_resources() call.
With USBDEBUG selected, PCI EHCI controller's device_operations
.read_resources is replaced with pci_ehci_read_resources() call,
which in turn will replace the device_operations .set_resources call.
The replacement for .set_resources reconfigures usbdebug driver side,
and calls the original .set_resources to configure hardware side.
Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3412
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch is based on 'AMD S3: Program the flash in a bigger data packet'[1]
Some AMD south bridge can write bigger data when saving S3 info.
In this patch, I use config 'AMD_SB_SPI_TX_LEN' to contral data size.
AMD_SB_SPI_TX_LEN is defined in 'src/southbridge/amd/Kconfig'
and then can be overridden in the Kconfig for specific
southbridges that support larger size.
I have tested on AMD Parmer and Thatcher. We will release a new board
whose south bridge can transfer more than 4 bytes each time.
[1] http://review.coreboot.org/#/c/2306/
Change-Id: Id984955d46eae487e39d45979f1a90054aa9f54b
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3413
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Without that fix we have:
src/drivers/elog/elog.c: In function 'elog_is_header_valid':
src/drivers/elog/elog.c:213:3: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format]
Change-Id: I71b80a94c03a04eedb688ae107d92c05a878315e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3551
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Gabe Black