The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
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 a93900be8d8a8260db49e30737608f9161fbf249)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6715
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7083b6b843d803bd4ddbd8a5aaf9c5c05bad2044)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6531
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
override default ivy VGA_BIOS_ID
add model & part number
Remove ARCH_X86 as is in,
fd33781 Move ARCH_* from board/Kconfig to cpu or soc Kconfig.
Change-Id: I61dc6434de7af2d8672f784df87a8b9d3f0fb068
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/6759
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This disables the blink hardware as it seems to be in the dump. This is
safer as it does not rely on 0 as the reset value when '0x00040000' is
the default according to the util/inteltool. As seen:
gpiobase+0x0018: 0x00040000 (GPO_BLINK) DIFF
Change-Id: Ia1fde108bf3752484f5e991600c435f776af0ced
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6436
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Use defines of offsets rather than hard coded values.
Change-Id: Id2471cd22aa402d74163473e48f86af9789cdaa7
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6435
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
SATA Port documentation
PCIe unused ports and documentation
T520 have no keyboard backlight
Change-Id: I517ff8519ea22a9a7a9b6e3136efd15d4a0f8fc4
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/6743
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Thinkpad T520 ExpressCard Slot PCIe lanes are connected to port 4.
Tested with Serial Port Card. Information read from schematic / lspci
Change-Id: I459943d427578d135f9aed1aa66da269ddfeee87
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/6735
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Clean up both ram and rom stage support and fix board to match.
Change-Id: I55e3e7338c0551f0fb663eb9707f16ecdc1aca35
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6509
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Compile romstage component as link-time symbols. Pass CONFIG_TTY0_BASE
as argument instead of hard coding and playing funny business with the
pre-processor. Fix board to match.
Change-Id: If6d0d5389bd4e7765bb6056cf488c94fd45915c2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6463
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The ARM Makefile was copied from x86 and then modified, and as a result it
was carrying a lot of baggage. On top of that, the extra complication made it
inflexible, and we need a lot of flexiblity in order to support the fact that
the Tegra124 starts on an ARMv4 coprocessor instead of one of the ARMv7 main
CPUs.
Change-Id: Ia6ddc27619bdb51e152ad0c628ad6f3037c103ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171017
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 512d942788336c8d52470135b43ee4e6a1c95f6c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
As is in:
91175bb lenovo/x201 & x230: Add EC info to SMBIOS
This is needed for the Linux driver for the Lenovo's to properly attach.
Change-Id: Ib910b25f392d9d3d6362b6909ce9fd4eeae9a096
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6399
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not needed anymore with GTT at the end of range.
Change-Id: I57b02c7d605d3c43ac92bd744bb6472e3c3471e2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6717
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The INTERMEDIATE variable was used to hook dd-ing the BL1 into the image for
Exynos SOCs, but we can do that directly without having a special hook.
Change-Id: I434506b52ca4ea1d01e25a785cbfe66dfdea21c4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170921
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 8db03c387ad654227d064e2a7fa5ecf09d07e3c5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6714
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Since commit 17fec8a0 [1]
drm/i915: Use Graphics Base of Stolen Memory on all gen3+
present in the Linux kernel since version 3.12, 3D does not work
anymore [2].
Comparing the graphics registers, in this case that means output of
`intel_reg_dumper`, the vendor Video BIOS is setting the register
PGTBL_CTL/PGETBL_CTL, only documented in the i965 datasheet [3], to
`0x3ffc0001` on a system with 1 GB of RAM, while native graphics init
sets it to `0x3f800001`.
Currently native graphis init sets the GTT right above the base
address of stolen memory. The Video BIOS sets it below the top of
memory. The Linux Intel driver expects it to be below top of memory, so
do it this way, by setting the address to TOM minus the size of the GTT,
which is hardcoded to 256 KiB.
As `PGETBL_CTL` is zero by default, reading its value in the beginning
is not necessary and is only confusing. Make it clear that the code
calculates the value.
There is still a PTE error reported during boot, but 3D works
with Linux 3.12+ and no user visible problems are shown.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17fec8a08698bcab98788e1e89f5b8e7502ababd
[2] https://bugs.freedesktop.org/show_bug.cgi?id=79038
[3] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_1_graphics_core_0.pdf
Intel ® 965 Express Chipset Family and
Intel ® G35 Express Chipset Graphics Controller
Programmer’s Reference Manual
Volume 1: Graphics Core
Revision 1.0a
Change-Id: I0a5b04c2c5300f5056cb48075aa5804984bc9948
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-on: http://review.coreboot.org/5927
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
This patch fixes the following minor bugs in the USB stack:
1. Ensure that all dynamically allocated device structures are cleaned
on detachment, and that the device address is correctly released again.
2. Make sure MSC and HID drivers notice missing endpoints and actually
detach the device in that case (to prevent it from being used).
3. Make sure XHCI-specific set_address() cleans up all data structures
on failure.
4. Fix broken Slot ID range check that prevented XHCI devices from being
correctly cleaned up.
Change-Id: I7b2b9c8cd6c5e93cb19abcf01425bcd85d2e1f22
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170665
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 9671472263ddd0c30400ae3b6da780a18cd21ded)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6701
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This uses the packet mode of the controller since that allows transfering more
data at a time.
Change-Id: I8329e5f915123cb55464fc28f7df9f9037b0446d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172402
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4444cd626a55c8c2486cda6ac9cfece4e53dd0d3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6703
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pins on tegra are controlled by three different units, the pinmux, the
pin group controls, and the GPIO banks. Each of these units controls some
aspect of the pins, and they layer together and interact in interesting ways.
By default, the GPIOs are configured to pass through the special purpose IO
that the pinmux is configured to and so can be ignored unless a GPIO is needed.
The pinmux controls which special purpose signal passes through, along with
pull ups, downs, and whether the output is tristated. The pingroup controls
change the parameters of a group of pins which all have to do with a related
function unit.
The enum which holds constants related to the pinmux is relatively involved
and may not be entirely complete or correct due to slightly inconsistent,
incomplete, or missing documentation related to the pinmux. Considerable
effort has been made to make it as accurate as possible. It includes a
constant which is the index into the pinmux control registers for that pin,
what each of the functions supported by that pin are, and which GPIO it
corresponds to. The GPIO constant is named after the GPIO and is the pinmux
register index for the pin for that GPIO. That way, when you need to turn on
a GPIO, you can use that constant along with the pinmux manipulating functions
to enable its tristate and pull up/down mode in addition to setting up the
GPIO controls.
Also, while in general I prefer not to use macros or the preprocessor when
writing C code, in this case the set of constants in the enums was too large
and cumbersome to manage without them. Since they're being used to construct
a table in a straightforward way, hopefully their negative aspects will be
minimized.
In addition to the low level functions in each driver, the GPIO code also
includes some high level functions to set up input or output GPIOs since that
will probably be a very common thing to want to do.
Old-Change-Id: I48efa58d1b5520c0367043cef76b6d3a7a18530d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171806
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
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 5cd9f17fe0196d13c1e10b8cde0f2d3989b5ae1a)
tegra124: Add base address for the pinmux and pingroup registers.
There weren't any constants for the pinmux or pingroup registers in the
address map header.
Old-Change-Id: I52b9042c7506cab0bedd7a734f346cc9fe4ac3fe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172081
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 79b61016bfd702b0ea5221658305d8bd359f4f62)
Squashed two related commits.
Change-Id: Ifeb6085128bd53f0ef5f82c930eda66a2b59499b
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6702
Tested-by: build bot (Jenkins)
If these aren't set, the rom and ram stages will attempt to load at address
zero which doesn't work.
Change-Id: I0b9b37d6363e6b208248d8a1af6ebee4db602486
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173540
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 6ac5cea39d423bfcf5bbd53c2cc6228ab89f08b2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6704
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
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 055ed0e28476123b0bd666109af90baf40aadcee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A problem with including the tegra124 directory directly in the include path
is that it makes all headers in that directory first level headers available
everywhere including places that have nothing to do with the SOC, even headers
which were only intended for local use by tegra124 code. This change modifies
things a bit to be more like the way the arch headers are chosen. In the
tegra124 directory, there's an include directory which has an soc subdirectory
in it. That include directory is added to the include path, making it possible
to have headers private to the tegra124. When files specific to whatever tegra
is being built for are needed, you can include <soc/foo.h> and get the version
specific to that particular soc.
Also, the soc.h header file was overhauled to use enums instead of defines, to
consistently name things as far as their prefix (the less cryptic TEGRA instead
of NV_PA) and suffixes like "BASE", and to get rid of values which were
specific to U-Boot which we don't need. Since the only thing in the file were
address constants, I also renamed the file addressmap.h. It would be included
as:
<soc/addressmap.h>
which I think is easy to remember, does what you'd think it does from the
name, and won't conflict with other header files just minding their own
business in some other directory.
Change-Id: I6a1be1ba28417b7103ad8584e6ec5024a7ff4e55
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172080
Reviewed-by: Julius Werner <jwerner@chromium.org>
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 2c554f58f9ee18e151e824f01c03eb3f0e907858)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6659
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The USB MSC device structure contains a "ready" state that can be either
"ready", "not ready" or "detached". The last one can only be assigned
when the device is completely unresponsive and gets forcefully logically
detached via usb_detach_device(). This call (at least in the current
version) also calls all destructors and frees the complete usbdev_t
structure (including the MSC specific part), which unfortunately makes
storing the "detached" state in that very structure a little pointless.
This patch reduces the "ready" value to a simple boolean and makes sure
that all detachment cases immediately return from the MSC driver,
carefully avoiding any use-after-free opportunities.
Change-Id: Iff1c0849f9ce7c95d399bb9a1a0a94469951194d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170667
(cherry picked from commit fd4529f37fdd1c93a8b902488ffeef7001b1a05a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6654
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
I just spent half a day (including the time to implement a stack dumper)
to figure out that I am reading from a NULL pointer. A problem this
simple should be more easy to catch. Let's mark the address range below
SRAM as uncached so that the MMU can yell at you right away for being
the bad programmer you are when you access a NULL pointer.
Change-Id: I4a3a13f75bf21b25732be2ecb69d47503eff1b53
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170112
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 7316732ea0ccdc0d607bde81dbb38ca9abd29fa9)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6650
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 547fbbfe2eeb6da4e161f36be2caf8099f9eac9b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6649
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Gabe Black