The LPDDR3 memory is x32 and dual rank with 14 row bits.
In addition the memory is actually elpida, even though
they are owned by micron it is confusing to label it as such.
And the ram strap options were inverted from what I expected
so the memory table needs to be updated.
Change-Id: Ia29a23e8140d884fb84f940806f041b40562aab9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 0d63d36b8035165f95db798ed40488519e622a65)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6828
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
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 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
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 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
Change-Id: I3ad8eed42255db426987065190c197baead40673
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6836
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Windows bugchecks on this for a while, so we ifndef'd the free() call out.
Now some Linuxes (depending on their glibc) also fail on it, so just
remove the call altogether at the cost of some leaked memory (couple
hundred kilobytes) because tracking down the precise fix is too hard.
In case someone wants to fix it, valgrind sees the issues, so
revert this change and work on romcc's memory management until valgrind
is happy.
To get a fix in, provide a good explanation why your change is actually
the right way to fix it - for silencing valgrind, this change will do.
Change-Id: Iae3f847e09a0d7bcb8bb4f50983a1b0727570b23
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6846
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This approach avoids having same basic tables 150-lines mantra over 100 times
in codebase.
Change-Id: I76fb2fbcb9ca0654f2e5fd5d90bd62392165777c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6801
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
Duncan Laurie