SMI1 is being written to but never read from.
Change-Id: I82c0800713e3093eb1317b5e1f6f228771134857
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6808
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reduces disk use and simplifies using abuild on
a ramdisk.
Change-Id: I3fb8d273dcbb5008fa9cfaa9465a59e3bbcb974b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Create a new mainboard based on the AMD DB-FT3 development board
(Olive Hill) using an AMD Steppe Eagle processor. The actual DB-FT3
and DB-FT3b mainboards are identical except for the soldered-down
SoC device. The new AMD DB-FT3b development board (Olive Hill+)
features:
* Mini-ITX form factor
* 2x DisplayPort
* 1x VGA
* Integrated Realtek RTL8111-compatible Ethernet
* 2x USB 3.0 ports
* 2x USB 2.0 externally-accessible ports
* 2x USB 2.0 internally-accessible ports (via headers)
* micro LPC header
* Integrated platform security processor
* 2x Full-size DDR3 DIMM support (1 channel)
* Realtek ALC272 HD audio
* 2x SATA ports
* 1x SD card slot
* 1x PCIe (x4) slot
* 1x mini-PCIe slot
* 8-pin programming header
Eliminate the extraneous headers included in PlatformGnbPcie.
BiosCallOuts normally has a bunch of extraneous references to the
mainboard name. Rather than correct the spelling of a bunch of
instances, just get rid of them.
For the most part, use the Olive Hill ACPI definitions since the
DB-FT3b board ("Olive Hill+") and Olive Hill are the same board
with different processors.
Change some function prototypes for functions without parameters
to void instead of AGESA's VOID. There are no parameters for
these functions, so there is no real reason to use VOID.
S3 and fan control are not supported. HD audio is not working.
Change-Id: I794d7a8f4f948346cfe7cbd443c9aed5f70c99ed
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6681
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
The Linux trampoline code does not set up the segment descriptors for
__BOOT_CS and __BOOT_DS as described in the Linux kernel
documentation:
... a GDT must be loaded with the descriptors for selectors
__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G
flat segment; __BOOT_CS must have execute/read permission, and
__BOOT_DS must have read/write permission;
This is not a problem when launching a Linux payload from coreboot, as
coreboot configures the segment descriptors at selectors 0x10 and
0x18. Coreboot configures these selectors in the ramstage to match
what the Linux kernel expects (see
coreboot/src/arch/x86/lib/c_start.S).
When the cbfs payload is launched in other environments, SeaBIOS for
example, the segment descriptors are configured differently and the
cbfs Linux payload does not work.
If the cbfs Linux payload is to be used in multiple environments
should the trampoline needs to take care of the descriptors that Linux
requires.
This patch updates the Linux trampoline code to configure the 4G flat
descriptors that Linux expects. The configuration is borrowed from
the descriptor configs in coreboot/src/arch/x86/lib/c_start.S for
selectors 0x10 and 0x18.
The linux_trampoline code is slightly refractored by defining the
trampoline entry address, 0x40000, as TRAMPOLINE_ENTRY_LOC. This
definition is moved into a separate header file, linux_trampoline.h.
This header file is now included by both the trampoline assembly
language code and the trampoline loader C code.
The trampoline assembly language code can now use TRAMPOLINE_ENTRY_LOC
as scratch space for the sgdt CPU instruction.
Testing Done:
Verified the Linux payload is booted correctly in the following
environments:
1. Coreboot -> Linux Payload
2. Coreboot -> SeaBIOS -> Linux Payload: (previously did not work)
Change-Id: I888f74ff43073a6b7318f6713a8d4ecb804c0162
Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Reviewed-on: http://review.coreboot.org/6796
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This target does (pretty much) exactly the same what jenkins
is doing on our build nodes:
- complete abuild run of our tree with a given payload
- building all libpayload configs we ship
- building the cbmem utility
In fact at some point we could tell jenkins to just run this command.
For debugging, pass along V and Q variables so inner make processes
are slightly more noisy on demand.
Change-Id: Ib515170603a151cc3c3b10c743f1468a9875dbdc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6797
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Ubuntu's HDMI audio has noise and echo. Disable NoSnoopEnable can
resolve this issue. The posted amd_late_init.c northbridge code
is missing a test for Steppe Eagle northbridges. See coreboot Gerrit
change 3934, commit ID 4ca721399c (AMD Olive Hill: Disable
NoSnoopEnable to fix HDMI audio corruptions with Ubuntu).
Change-Id: I89894d0ce4ad72ea16d61b445edb9e67920bca24
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6822
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch represents a major overhaul of the USB enumeration code in
order to make it cleaner and much more robust to weird or malicious
devices. The main improvement is that it correctly parses the USB
descriptors even if there are unknown descriptors interspersed within,
which is perfectly legal and in particular present on all SuperSpeed
devices (due to the SuperSpeed Endpoint Companion Descriptor).
In addition, it gets rid of the really whacky and special cased
get_descriptor() function, which would read every descriptor twice
whether it made sense or not. The new code makes the callers allocate
descriptor memory and only read stuff twice when it's really necessary
(i.e. the device and configuration descriptors).
Finally, it also moves some more responsibilities into the
controller-specific set_address() function in order to make sure things
are initialized at the same stage for all controllers. In the new model
it initializes the device entry (which zeroes the endpoint array), sets
up endpoint 0 (including MPS), sets the device address and finally
returns the whole usbdev_t structure with that address correctly set.
Note that this should make SuperSpeed devices work, but SuperSpeed hubs
are a wholly different story and would require a custom hub driver
(since the hub descriptor and port status formats are different for USB
3.0 ports, and the whole issue about the same hub showing up as two
different devices on two different ports might present additional
challenges). The stack currently just issues a warning and refuses to
initialize this part of the hub, which means that 3.0 devices connected
through a 3.0 hub may not work correctly.
Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170666
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6780
Tested-by: build bot (Jenkins)
We had brought this code in from the kernel but found it best to
use mainboard- or chipset specific versions. Firmware should
strive to be as non-generic as possible.
Change-Id: Ic1ca746cc52c3f9ea4de6895f2b32946229beada
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172625
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7dba0dfd25bf9e367f9e5128b15edb018e958c3a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6779
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This patch removes the confusing concept of a special "xhci_speed" with
a different numeric value from the usual speed used throughout the USB
core (except for the places directly interacting with the xHC, which are
explicitly marked). It also moves the MPS0 decoding function into the
core and moves some definitions around in preparation of later changes
that will make the stack SuperSpeed-ready. It makes both set_address
implementations share a constant for the specification-defined
SetAddress() recovery delay and removes pointless additional delays from
the non-XHCI version.
Change-Id: I422379d05d4a502b12dae183504e5231add5466a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170664
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6776
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git can do lots of things by itself, no need to parse
its output and redo that.
Change-Id: Id2cdd2ea8d34c1ba2b0abddc88e1f3260d74f47d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6798
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Checked by comparing binaries and seeing no differences other than
build info.
Change-Id: Ie702c540a18b50d6da0379f7c4e65adf3e4f18d4
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6819
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not referenced anywhere.
Change-Id: I6529f2ecbc34a2fa9ca720fea1224670eb98bdcd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6815
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The BLOBs repo has been updated with AMD PI header files, peripheral
BLOBs for the new Avalon southbridge, the AGESA binary PI BLOB for
Steppe Eagle, the Steppe Eagle video BIOS, and platform security
processor firmware.
Change-Id: I8bb58a5cc572d2d75de33b14843d7d1893fff532
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6770
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There is some magic new SPD SDRAM type 241 to indicate LPDDR.
I cannot find it specificed in any JEDEC document but it is
what the reference code uses.
Change-Id: I21d7a943784435cb336ecdba7ca5eac0bf5fcd92
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171900
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 0a1385515c62fd1e534b12568df8aaf2170e06f4)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6777
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch fixes a bug in the XHCI stack that occurs when a multi-TRB TD
times out before the last TRB is processed. The driver will correctly
issue a Stop Endpoint command in that case, but the xHC will still
preserve the transfer state and just pick up right after that on the
next doorbell ring. It will then process the leftover TRBs from the old
TD the next time a transfer is issued. (cf. XHCI 4.6.9)
We fix this by changing the existing xhci_reset_endpoint() calls in
transfer functions to not only trigger on Halted (2) and Error (4), but
also on Stopped (3). That function will not actually issue a Reset
Endpoint command in this case, but it will nuke the whole transfer ring
and issue a Set TR Dequeue Pointer command, which is sufficient (though
slightly overkill) to solve our problem.
Change-Id: I3abbe30ff9d4911a8af1f792324e018d427019e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170833
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit f12424af0e29ac12963e8e5a7970fadcc0bb6cee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6787
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Change-Id: I7b9b91519d87d70405b57920b3f1ab98c50526d1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6810
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
OEM strings should not be handled by mobo code but by common code with strings
collected from all devices.
Change-Id: Ibde61a1ca79845670bc0df87dc6c67fa868d48a9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6788
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Tablets have different mainboard version than laptop variants.
Change-Id: I77a1e2b50d30dcf3fa064e0c378ceca7ccf96e89
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6785
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Add the CPU files required to support the Steppe Eagle and Mullins
models of Family 16h SoC processors from AMD. This CPU is based on
the Jaguar core and is similar to Kabini.
Change-Id: Ib48a3f03128f99a1242fe8c157e0e98feb53b1ea
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6679
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Add the northbridge file for AMD's new Mullins and Steppe Eagle
processor family. Since the processor family name is not the
same across AMD's sales and marketing channels, I have elected
to use part of the processor ID as the family name. The intent
is to reduce confusion since the processor ID is the same for
both families. This northbridge support has only been validated
on the AMD Embedded variants ("Steppe Eagle").
The AGESA wrappers in coreboot have a function that is intended to
mirror the UMA memory allocation performed during memory initialization
by AGESA. Update the Steppe Eagle memory allocation to mimic the
memory reservation done inside the AGESA BLOB.
Change the default CBMEM address, the default video BIOS device ID,
and a couple of other defaults to match changes in coreboot community
code.
The northbridge chip.h specifies how many processor sockets, how
many channels, and how many DIMM slots are supported by the
northbridge. Steppe Eagle does not permit multisocket systems
and has only one memory controller channel.
Change-Id: I20d8b78e3b153cda2dd05100fbb75e2ebadd9e08
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6678
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
00730F01 contains the Avalon southbridge and a Platform Security
Processor (PSP). Supporting the PSP requires specific binaries to
be included in the ROM. The fletcher utility is used to sign PSP
binaries.
The IMC access routines are not accessible for newer AMD parts that
use pre-compiled AGESA. Change the Hudson code such that the IMC
code is not compiled if IMC is not selected in Kconfig.
Disable compilation of resume.c if HAVE_ACPI_RESUME is disabled.
The newer AMD mainboards will initially be released without ACPI
resume support (S3) due to the use of AGESA internals in the
existing Hudson routines. The Makefile change allows newer
mainboards to avoid the API issues.
Change Kconfig such that the FWM flag is always set for PSP-enabled
parts. This has the side effect of forcing the generation of the
FWM directory in the absence of GEC, IMC, and xHCI.
Change-Id: I6d056f54b60a64300841599490b9fafd561c4a7d
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6677
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc
makefiles, some Kconfig, and the AGESA standard library
functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
The AGESA dispatcher is built using its own rules rather than
generic library generation rules in coreboot/Makefile and
coreboot/Makefile.inc. The AGESA source files are initially
copied from whereever they live into coreboot/build/agesa.
They are compiled from there. The binary PI directory has a
mandatory structure that places the AGESA BLOB into the same
directory as the support headers. These will nominally be
placed in the 3rdparty directory in coreboot.org.
The copy commands that were added to the the vendorcode
Makefile.inc ensure that only one thread will operate on each
source file by using a macro to generate the copy targets.
After the change, each copy target will operate on exactly one
source file.
Due to API issues, coreboot has no way to control the IMC to set up
fan control. Set a Kconfig flag that removes the ability to install
an IMC BLOB into CBFS.
Change-Id: I050b72a19086aaeba6cb65ce165297b10e3cfc45
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6595
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
The AMD Platform Security Processor (PSP) requires a Fletcher's
Checksum at the end of the PSP directory. This code implements
a Fletcher's Checksum by reading bytes from stdin and writes the
bytes back to stdout with a checksum inserted into the byte stream
at the appropriate offset.
This utility is used on PSP binaries during coreboot build.
Include a runtime debug option such that the command:
fletcher --print <file.bin >file_with_cksum.bin
will print out the computed checksum value for debugging. The
compile-time debug option is retained that allows -DDEBUG to
be added to the compilation line. This option has the same
effect as "--print".
Change-Id: I506a479d8204ca4f8267d53aa152ac4b473dbc75
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6676
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
This interrupt needs to be specified in the MADT before it can
be used by the kernel driver.
Change-Id: Ic920a792a203cb06cd4529815680584a21532106
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171902
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit a330fddb62cb6346ad66ceb5b5c32b66aecd81e2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6778
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Add the coreboot board files for samus
- Based on Bolt
- GPIO setup based on 0.91 schematic
- Support both memory types
- No HDA verb table for this platform
- Some GPIO interrupts are shared and need to be passed to OS
Change-Id: I8dbd7639456c631a0115b03a493d94b5e2361ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 249a74c628264e3d4ce754803ede31238404b4d5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6775
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
tegra124: Add a test function which spams exclamation points on the UART.
This function spews characters on the console and, until we have a working
console, is an easy way to see whether the system boots to a particular point.
For some reason waiting for transmitter to be empty hangs, but transmitting
characters still works.
Old-Change-Id: I1622c8a58849f4b8bdcaa67500b81042d7346df4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171030
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit e0059181958cfe8afec2f3a7ea732e81f5d55e5d)
tegra124: Re-enable waiting for the transmitter to empty in the test function.
The compiler was emitting code compatible with armv7-a, but the bootblock was
running on a core which uses armv4t. By coincidence, it was emitting an
instruction which is unavailable on armv4t when checking the value of the
UART's LSR register. Now that the bootblock is compiled with more appropriate
flags, this code can be re-introduced.
Old-Change-Id: I7ecada4138b0889b963d1a8b19a4bab8e0bb1add
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170997
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 2a0adceb5029c8ee633d17c82dbb11e48d30349d)
tegra124: Seperate out the non-UART specific hardcoded init in the bootblock.
The hardcoded init in the test function in the bootblock is actually useful
generally because it doesn't belong in the UART driver itself but is necessary
for the UART to work. Until we have real implementations for the pinmux, etc.,
we can use that code to get the UART and console going.
Old-Change-Id: I2efe0b571d8b022eb2a2e5569620558540b28373
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171334
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit ae7d4d890be1936cc86dc15adeb33f3b46a51ae5)
tegra124: Implement and enable serial console support for tegra124.
The driver is very similar to the 8250 driver, except it isn't in two parts,
and it also spaces its registers 4 bytes apart instead of having them directly
adjacent to each other.
Also, eliminate the UART test function in the bootblock. It's no longer needed
since the actual console output serves the same purpose.
Right now the clock divisor is fixed for now, and we'll want to actually
figure out what value to use at some point.
Old-Change-Id: Idd659222901eb76b0ed8cbb986deb5124096f2f6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171337
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 86f5e2875b18901b349283cfbcd4f8cc88b7a019)
Squashed 4 commits related to uart support for tegra124. Modified the
new uart.c to look like the uart.c for exynos5420.
Change-Id: I490cba014a43d58c30c48ca9ddcae2b00095b7a6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6764
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The exynos directories had been moved from src/cpu to src/soc, but the name
of the chip_operations structure wasn't updated properly. That meant that the
SOCs never installed their memory resources and the ram stage would fail to
load the payload.
Change-Id: Ib60489b6d3434e3ebd13827a804452f762747f1b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172400
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9100d475ebcc4dae23184583a6cc0162577e70d1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6781
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This minor refactoring patch changes the signature of all limited cache
invalidation functions in coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
(cherry picked from commit d550bec944736dfa29fcf109e30f17a94af03576)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6623
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
commit 9518b56 (intel/gma: Clarify code and use dedicated init for
Google Peppy) changed "struct edid" and thereby broke the build.
Adapt drivers/emulation/qemu/bochs.c to the changes to fix this.
Build failure triggers with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE=y.
Change-Id: I2d3cecde21d495e9b99ff8d2f741f8a462c75a4d
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/6771
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
commit 9518b56 (intel/gma: Clarify code and use dedicated init for
Google Peppy) changed "struct edid" and thereby broke the build.
Adapt drivers/emulation/qemu/bochs.c to the changes to fix this.
Build failure triggers with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE=y.
Change-Id: Ic295c6d31284555e1463af5bca673231b8722d54
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/6769
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While the 8250 compatible serial port driver is primarily useful on x86
systems because it works with the legacy x86 com ports, some devices which
aren't x86 based have 8250 compatible UARTs as well. This change renames the
CONFIG_X86_SERIAL_CONSOLE option to the more general and direct
CONFIG_8250_SERIAL_CONSOLE and fixes up the dependencies so that non-x86
systems can enable the driver, although it will default to on on x86 and off
otherwise.
Also, the default IO port address that's added to the sysinfo structure on x86
and which is intended to be overwritten by a value in the coreboot tables is
not used on ARM. That variable is adjusted so that it's more clear it's a
default value, and made dependent on x86 since that's the only place its value
is actually used.
Change-Id: Ifeaade0e7bd76d382426e947275a9c933da4930e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170834
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9a10e39a2da3cb0bfb316c0869cf5025078e287f)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6655
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This implementation is the same as the general one except that it removes all
the things that don't work on an ARMv4.
Change-Id: I1108a79cc656b26f7d48df20aef3016cf5ae3182
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171019
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d1436288d3b025af27a8d28ba94b589940ead504)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6713
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tegra needs to use a custom bootblock implementation because it starts on a
coprocessor which uses ARMv4. It doesn't have the same control registers,
caches, etc., and the regular bootblock gets exceptions and dies.
Change-Id: Id197db2939bc840ad64244d6e2017fc5c89e0cbd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171018
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a66393fdd6fe68757e394b8a611e610f1938771d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6710
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Vladimir Serbinenko