This patch changes the GPIO API once again, this time back to functions.
It introduces a new opaque type gpio_t that holds both the GPIO number
and the corresponding pinmux number and can be constructed with a macro
(e.g. 'gpio_output(GPIO(Q2), 1);' ). This makes the GPIO functions
convenient to use, but also allows passing GPIOs around in variables and
function parameters.
BUG=None
TEST=Made sure GPIOs still twiddle when commanded.
Change-Id: I519c32b872b0c912046a3aaa070ef4e9699856ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172916
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Pull-ups and pull-downs can be active on functional pins. Add configs
for these options so they can be specified on board GPIO maps.
TEST=Manual on bayleybay. Verify that platform boots to payload load.
BUG=chrome-os-partner:22863
Change-Id: I0905dc94e4fcce87fd97be0e87c83aa5f2ae78b9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172766
Reviewed-by: <adurbin@chromium.org>
Now that CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM is
an option the haswell boards need to be kept in line
to maintain their previous behavior. This commit
is separated from the actual implementation for
easier rebasing.
BUG=None
BRANCH=None
TEST=Built for falco.
CQ-DEPEND=CL:172602
Change-Id: Ic8b1c7f37ab4ac7b7d453e924c30f18a528f6eb6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172643
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
CQ-DEPEND=CL:172643
CQ-DEPEND=CL:*146397
CQ-DEPEND=CL:*146398
CQ-DEPEND=CL:*146435
CQ-DEPEND=CL:*146445
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The GPIO wrappers are already pretty nice, but you still end up writing
everything twice since you need to specify the pinmux register:
gpio_output(GPIO_Q2, PINMUX_GPIO_Q2, 1);
Calculating the pinmux index from the GPIO isn't easy, but luckily the
enums use a similar naming scheme. This patch changes the wrapper
functions to macros that generate the corresponding pinmux name
automatically.
BUG=None
TEST=Made sure code with GPIO macros compiles, twiddled some output
GPIOs to confirm that they work.
Change-Id: Id23855c5aec5f87b4201f22bac32503e72f83392
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172731
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch changes the order of GPIO and pinmux register accesses when
setting GPIOs to make the operations as atomic as possible, and avoid
output-to-output as well as special-function-to-input glitches under
some circumstances. It also sets the TRISTATE pinmux for input GPIOs,
since according to my understanding of the pinmux circuit this is the
right thing to do.
Also changed all uintXX_t types to uXX, since I think we agreed on
preferring that for all new code.
BUG=None
TEST=Twiddled some Servo-connected GPIOs and make sure they work.
Change-Id: I2e0156fbaa85e46e460b4494765a06e19f50d4e4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172730
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This will make the PCIe slots and the onboard network interface
work.
BUG=none
BRANCH=none
TEST=Use onboard network interface
Change-Id: Ia65a5e2443883da75b6fff60748d25189c91aa64
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
For graphics we need a chip.h in tegra124. Add it.
Set it in the nyan mainboard as a test.
BUG=None
TEST=build it
BRANCH=None
Change-Id: I1c5ccd5574d2e6b49bb4947035ccd10e99729458
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172773
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Add code which initializes the AS3722 PMIC based on the initialization
sequence U-Boot uses. I wasn't able to find documentation which said what each
register in the PMIC does, so the next best solution was to imitate another
implementation which presumably sets things up correctly.
The code is set up significantly differently than the U-Boot code, first
because it uses the i2c driver through it's external interface instead of
poking values into the controller's registers directly. The driver uses the
packet mode of the controller while the U-Boot code does not. Second, it uses
an array of register indices and values, a pattern established with Exynos,
instead of having a sequence of calls to the i2c_write function.
This change is also a practical test of the i2c driver's write capability.
BUG=None
TEST=Built and booted into the bootblock on nyan. Used a multimeter to measure
the voltage on capacitors connected to the CPU's power rail. When booting
U-Boot, the voltage across the capacitors is 1V. When booting coreboot before
this change, that rail stayed off and the rail stayed at 0V. After this change
it went to 1V.
BRANCH=None
Change-Id: Iab1f8d3b735b0737ce93ee3c9c7fdb2a1dcbbf8a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172585
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Set up the i2c controllers that are used on nyan.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ibdd5685e3effdd13ca560b8f18db25e9edadc07b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172584
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
There's generic clock initialization that needs to be done for any mainboard
using that soc. Other initialization depends on what peripherals are going to
be used and what rate they should run at and should be done in the mainboard
source.
BUG=None
TEST=Built and booted into the mainboard on nyan.
BRANCH=None
Change-Id: Idf79faac523bb99f3c7c29bac6947d2149fc3651
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172583
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We need somewhere to put mainboard specific bootblock initialization.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ief409baff5ae67871879291c7ff0533f19ea6e56
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172582
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We should seperate out the mainboard specific parts of the bootblock so that
they can be customized as necessary.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
Change-Id: Ia633a68521725f6e88341608ccdbedc4f1ce8223
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172581
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This uses the packet mode of the controller since that allows transfering more
data at a time.
BUG=None
TEST=Used the i2c driver to read registers in the PMIC. I wasn't able to find
documentation which said what values to expect, but the values I got were
consistent, seemed reasonable, and tracked which register I was reading.
BRANCH=None
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>
I cleaned up the clk_rst struct: no need to have an array for the
source select because each thing is an individual entity.
There is a bit of a trick in here. I'm using macros to index arrays in the
clk_rst struct. Simple reason: if people use the constants we get compile-time
checking for simple errors.
init_pllx is fixed. The vendor table in u-boot was wrong.
BUG=None
TEST=builds. Amazing. Prints. Amazing.
BRANCH=None
Change-Id: I4429b3e5c14c200db6b4dd129eff14261fe1f326
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172106
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
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.
BUG=None
TEST=Builds and this code was not used anywhere
BRANCH=None
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>
Fix USB2 and USB3 port configuration for Beltino
BUG=none
BRANCH=none
TEST=Boot system, see front USB ports working.
Change-Id: I7b799e2a2d17a89bde7dd93b4e9149f19ae4e7ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172274
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The bootblock and romstage UART consoles were being built in based only on
whether or not the bootblock and romstage consoles were selected, ignoring
whether serial console support was compiled in generally.
BUG=None
TEST=Built for nyan with and without serial.
BRANCH=None
Change-Id: I3866519c422a990c44ced66885108eff24894563
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172580
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
In order to enable a SuperIO in non ChromeEC systems we
need to make pch_enable_lpc() available to the mainboard
romstage.c
BUG=none
BRANCH=none
TEST=boot ChromeOS on Beltino
Change-Id: I34e7d23012e1852c69e82ba7cdc81a05751846de
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172180
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
The access to control registers were scattered about.
Provide a single header file to provide the correct
access function and definitions.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted using this infrastructure. Also objdump'd the
assembly to ensure consistency (objdump -d -r -S | grep xmm).
Change-Id: Iff7a043e4e5ba930a6a77f968f1fcc14784214e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172641
Reviewed-by: Stefan Reinauer <reinauer@google.com>
When compiling coreboot for x86 on gcc the compiler is
free to pick whatever defaults it is using at the time of
gcc's compile/configuration when no -march is specified.
Not properly specifying -march then opens up the use of SSE
instructions for copmilation units it should not be used such
as the SMM module as this module doesn't save/restore SSE
registers.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and confirmed -march=i686 was used on command line. Also
noted not xmm registers were produced grep'ing through objdump
output.
Change-Id: I64d4a6c5fa9fadb4b35bc7097458e992a094dcba
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172640
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This is a direct copy of the bayleybay configuration.
BUG=chrome-os-partner:23121
TEST=emerge-rambi libpayload
Change-Id: Ib90f5797b4656ac366d16da5f3243fea20357dc5
Reviewed-on: https://chromium-review.googlesource.com/172587
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
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.
BUG=chrome-os-partner:22139
TEST=Manual
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>
The current XHCI code only sets IOC on the last TRB of a TD, and
doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this
won't generate an event at all when we have a short transfer that is not
on the last TRB of a TD, resulting in event ring desync and everyone
having a bad time. However, just setting ISP on other TRBs doesn't
really make for a nice solution: we then need to do ugly special casing
to fish out the spurious second transfer event you get for short
packets, and we still need a way to figure out how many bytes were
transferred. Since the Short Packet transfer event only reports
untransferred bytes for the current TRB, we would have to manually walk
the rest of the unprocessed TRB chain and add up the bytes. Check out
U-Boot and the Linux kernel to see how complicated this looks in
practice.
Now what if we had a way to just tell the HC "I want an event at exactly
*this* point in the TD, I want it to have the right completion code for
the whole TD, and to contain the exact number of bytes written"? Enter
the Event Data TRB: this little gizmo really does pretty much exactly
what any sane XHCI driver would want, and I have no idea why it isn't
used more often. It solves both the short packet event generation and
counting the transferred bytes without requiring any special magic in
software.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Idab412d61edf30655ec69c80066bfffd80290403
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170980
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
We had a hardcoded version of the set_avp_clock_to_clkm function in the
bootblock, and we had to use it until now because the real version uses
udelay, and until now that hadn't been implemented. Also, replace the delay
loop in the hacky_hardcoded_uart_setup_function with a call to the real thing.
BUG=None
TEST=Built and booted into the bootblock on nyan. Verified that there was
still serial output.
BRANCH=None
Change-Id: I6df9421bcad484e0855c67649683d474d78e4883
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It turns out there's a register in tegra which automatically counts at 1us
increments. It's primarily intended for hardware to use (I think to drive
other timers) but we can read it ourselves since a 1us timer is exactly what
we need to support the monotonic timer API.
BUG=None
TEST=Built and booted into the bootblock on nyan with test code in the
bootblock. Used that code to print two serial messages, 1 minute apart. The
messages happened 1 minute and 2 seconds apart. That's pretty close, although
it might be worthwhile to figure out where those extra two seconds are coming
from (measurement error?).
BRANCH=None
Change-Id: I68e947944acec7b460e61f42dbb325643a9739e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172044
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>
The pins for the UART had been configured manually using hardcoded offsets and
values. Now that we have pinmux functions for that sort of thing, we should
use that instead. This also provides a very simple test for the pinmux code.
Ultimately this code should be wrapped in a function which handles setting up
any of the UARTs which is appropriately parameterized and which would be
called from the bootblock main instead of being in it, but for now this is
sufficient.
BUG=None
TEST=Built and booted into the bootblock on nyan. Saw console output.
BRANCH=None
Change-Id: I69e36fa5fc9b6f3f5ef7f1be3e9f18cdbfdd7fe9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171807
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>
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 docuemtnation 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.
BUG=None
TEST=Replaced the hardcoded pinmux configuration code for the UART pins and
saw that the UART still worked correctly. Added an infinite loop to the
bootblock that read and print the value of the lid switch over and over. Ran
it and toggled the lid switch on servo and saw that the output changed as
expected. Repeated that with the dev switch GPIO.
BRANCH=None
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>
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.
BUG=None
TEST=Built and booted on pit. Before this change, the payload would fail to
load because no bounce buffer could be found. After this change, ChromeOS
booted successfully.
BRANCH=None
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>
The flags used to compile libgcc may make it incompatible with the code it's
linked against, and/or the hardware it's going to run on. Rather than try to
tease the right libgcc from the compiler, lets just leave it out and use our
own implementations of the necessary functions.
Most of these implementations were taken from the Linux kernel, except for
uldivmod.S which was taken from a CL originally written for U-Boot by
Che-Liang Chiou in December of 2010. It was modified to not use the CLZ
instruction on machines that don't have it, anything earlier than ARMv5. The
top block was taken from an earlier version of the same CL which didn't use
CLZ in that spot. The later block was written from scratch.
BUG=None
TEST=Built and booted into the bootblock on nyan. Ran a series of tests which
divided and modded a 64 bit value by various 32 bit values which were powers
of 2. Confirmed that this function was used and that the returned value was
correct. Printed decimal and hex versions of some values and verified that
they equaled each other. Built and booted on pit with serial enabled.
BRANCH=None
Change-Id: I7527e28af411b7aa7f94579be95a6b352a91a224
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172401
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This just updates a comment which refers to "board_init_f". We use
bootblock main() in coreboot.
BUG=none
BRANCH=none
TEST=locally compiled.
Change-Id: I4cb6b3c11f163b67fe48de495d13dce88710efc0
Reviewed-on: https://chromium-review.googlesource.com/172095
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Move (and rename to make it clearer) the function that computes display
parameters from the dpcd and edid.
BUG=None
TEST=Build and boot on peppy. Doesn't break falco other builds.
BRANCH=None
Change-Id: Idfbb56fd312b23c742c52abca1a34ae117a8fece
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171366
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
There are currently 4 SKUs:
0b000 - 4GiB total - 2 x 2GiB Micron MT41K256M16HA-125:E 1600MHz
0b001 - 4GiB total - 2 x 2GiB Hynix H5TC4G63AFR-PBA 1600MHz
0b010 - 2GiB total - 2 x 1GiB Micron MT41K128M16JT-125:K 1600MHz
0b011 - 2GiB total - 2 x 1GiB Hynix H5TC2G63FFR-PBA 1600MHz
Add each of the 4 spds to the build, and use the proper
parameters to MRC to use the in-memory SPD information.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built. Noted 1024 bytes of SPD content.
Change-Id: Ife96650f9b0032b6bd0d1bdd63b8970e29868365
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172280
It's helpful to have a lot of the early init happen
before the handoff to mainboard. One example of this
need is having the BARs programmed so that the mainboard
can read board-specific gpios.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built. Booted and saw console outout in bayleybay
mainboard.
Signed-off-by; Aaron Durbin <adurbin@chromium.org>
Change-Id: I030d7b4f9061ad7501049e8e204ea12255061fbe
Reviewed-on: https://chromium-review.googlesource.com/172290
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
- Add functions to peek at GPIO input pad values (need to be used from
romstage for board ram_id GPIOs)
- Modify UART GPIOs to use existing fn-assignment function
TEST=Manual. Add debug print and verify that GPIO functions return input
values. Also, verify UART still functions in romstage.
BUG=chrome-os-partner:22865
Change-Id: Ib2e57631c127a592cfa20ab6e2184822424e9d77
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172189
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There weren't any constants for the pinmux or pingroup registers in the
address map header.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
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>
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.
BUG=None
TEST=Built and booted into the bootblock on nyan.
BRANCH=None
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>
Set the BSP to operate at max frequency early in romstage.
The call to punit_init() is when the frequency actually ramps as
that makes the punit actually start working.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted. Noted operating frequency status is max.
Change-Id: Icfd9e5c7682aa21fc740bd687607ca6a66597d5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172131
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The caching policy for romstage was previously using a 32KiB
of cache-as-ram for both the MRC wrapper and the romstage stack/data.
It also used a 32KiB code cache region. The BWG's limitations for
the code and data region before memory is up was wrong. It consists
of a 16-way set associative 1MiB cache. As long as enough addresses
are not read there isn't a risk of evicting the data/stack.
Now create a 64KiB cache-as-ram region split evenly between romstage
and the MRC wrapper. Additionally cache the memory just below
4GiB in CBFS size. This will cover any code and read-only data needed.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted quickly with corresponding changes to MRC warpper.
CQ-DEPEND=CL:*146175
Change-Id: I021cecb886a9c0622005edc389136d22905d4520
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172150
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The graphics.c file was never used. Just remove it.
BUG=chrome-os-partner:23121
BRANCH=None
TEST=built.
Change-Id: Ia6bc6251c76074dd73357564d22480122b6a3bb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171930
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
- Set config0 defaults for hysteresis disable, pad bypass, etc.
- Set config1 power-on defaults.
- Set pad_val for input as default.
BUG=chrome-os-partner:22863
TEST=Manual. Enable GPIO_DEBUG and verify pad registers are set
according to expectation. Also verify bayleybay still boots to payload
loading.
Change-Id: I0f1c9e4d4f39c5c56d7e14a82eb4825612e19420
Reviewed-on: https://chromium-review.googlesource.com/171903
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
This interrupt needs to be specified in the MADT before it can
be used by the kernel driver.
BUG=chrome-os-partner:22996
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
This was also tested on bolt by configuring the touchscreen to use
a shared GPIO interrupt:
localhost ~ $ grep atmel_mxt_ts /proc/interrupts
54: 24 188 93 124 LP-GPIO-demux atmel_mxt_ts
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>
The GPIO controller uses IRQ14 as an active high level triggered
source for GPIOs that are configured to trigger shared interrupt.
BUG=chrome-os-partner:22996
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
This was also tested on bolt by configuring the touchscreen to use
a shared GPIO interrupt:
localhost ~ $ grep atmel_mxt_ts /proc/interrupts
54: 24 188 93 124 LP-GPIO-demux atmel_mxt_ts
Change-Id: I3765120112bae11407e5b2020399d0d0b8e3cef8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171901
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:22996
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
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>
This is just a copy from bayleybay.
BUG=chrome-os-partner:23121
BRANCH=None
TEST=None
Change-Id: I283415be326e2d92e1e1bf7866954f17a7266edb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171940
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
This change shows the source structure for nvidia Tegra and Tegra124
SOC. The problem we are trying to solve is that there is a large
amount of common code in the form of .c and .h files across many
different Tegra SOCs. The solution is to provide common code in a
single directory, but not to compile in the common code directory;
rather, we compile in a directory for a given SOC. Different SOCs
will sometimes need different bits of code from the common directory.
Tegra common code lives in tegra/, but there is no makefile there: if
a Tegra common file is needed in a SOC, it is referenced via a
Makefile in a specific Tegra SOC.
Another issue is includes. Include files in the common directory might be
accessed by a piece of code in an SOC directory. More problematically,
code in the common directory might require a file in an SOC directory.
We don't want to put the SOC name in an #include path, e.g.
in a C file in tegra/ is very undesirable, since we might be compiling
for a tegra114.
On some systems this is solved by a pre-pass which creates a set of
symbolic links; on others with nested #ifdef in the common code
which include different .h files depending on CPP variables.
In previous years, both LinuxBIOS and coreboot have tried these
solutions and found them inconvenient and error-prone.
We choose to solve it by requiring explicit naming of part of the path
of files that are in the common directory. This requirement, coupled
with two -I directives in the Makefile.inc, allows common and SOC
C code to incorporate both common and SOC .h files.
.c and .h files -- SOC or common -- name include
files in the common directory with the prefix tegra/, e.g.
SOC files will be included from the SOC directory if they have no prefix:
The full patch of clock.h will depend on what SOC is being compiled, which
is desirable.
In this way, a common file can pick up a specific SOC file without
creating symlinks or other such tricky magic.
We show this usage with one file, soc/nvidia/tega124/clock.c. This compiles.
The last question is where to put the prototype for the function
defined in this file -- soc.h?
BUG=None
TEST=Builds
BRANCH=None
Change-Id: Iecb635cec70f24a5b3e18caeda09d04a00d29409
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/171569
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
