Split the Parmer, Family 15tn, and Hudson DSDT into groups. This splits
the DSDT table into includable ASL files which carry details specific
to the Family 15tn APU, the Parmer platform, and the Hudson FCH. The
dsdt.asl file in the mainboard directory contains only #include
references to the appropriate files.
Initially, this split was done by moving each piece of functionality
into its own file (e.g. IRQ routing and mapping, processor tree, sleep
states and sleep methods, etc.) and those pieces were #included in
dsdt.asl to ensure an exact match (via acpidump/acpixtract/iasl -d)
with the extant version of the table. Once the new tables were found
to exactly match the existing tables, the pieces were rearranged into
reasonable groups (e.g. fch.asl, northbridge.asl, pci_int.asl, etc.).
Some include files have no content but are left as a template for
other platforms and as placeholders for completing the ACPI
implementation for Parmer (e.g. thermal.asl, superio.asl, ide.asl,
sata.asl, etc.).
Change-Id: I098b0c5ca27629da9bc1cff1e6ba9fa6703e2710
Signed-off-by: Steve Goodrich <steve.goodrich@se-eng.com>
Reviewed-on: http://review.coreboot.org/3629
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
It might be the case that a file is being loaded from a portion of CBFS which
has already been loaded into a limitted bit of memory somewhere, and we want
to load that file in place, effectively, so that it's original location in
CBFS overlaps with its new location. That's only guaranteed to work if you use
memmove instead of memcpy.
Change-Id: Id550138c875907749fff05f330fcd2fb5f9ed924
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3577
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SOC's built in ROM loads the bootblock and the ROM stage into the on chip
memory before handing over control to the bootblock. To avoid having to add
one or more driver to the bootblock so that it can re-load the ROM stage from
whatever media Coreboot is stored on, we can just take advantage of the copy
that's already there. Loading the RAM stage/payloads won't be so simple,
so the ROM stage and the RAM stage will have to have different media drivers.
Change-Id: Id74ed4bc3afd2063277a36e666080522af2305dd
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3583
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This variable wasn't being defined and was defaulting to zero when used in the
ROM stage's linker script. This change defines it as a variable, and gives it
a value which is slightly beyond the end of the bootblock. By making the ROM
stage request to be loaded slightly farther into memory than it was loaded by
the SOC's masked ROM, we ensure that it's moved away from the stage's metadata
instead of on top of it. When it moves the other way, it clobbers important
values like the entry point vefore the bootblock has had a chance to use them.
Change-Id: I027a1365d05f1d79d7fc1e1349965ccb7d4e81b9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3582
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The placeholder code in beaglebone's romstage.c didn't do anything, it just
immediately tried to load the RAM stage and jump into it. That doesn't
currently work, and there's no indication whether you actually successfully
got into the ROM stage or not.
This change adds a few lines which initialize the console and say "Hi" so that
we can tell that the ROM stage is running.
Change-Id: I45a0908c3ac65b21e0e5020428696d2e54933d0e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3581
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At least when building with the gnu toolchain, the headers the linker
automatically generate save space for the actual ELF headers in one of the
loadable segments. This creates two problems. First, the data you intended to
be at the start of the image doesn't actually show up there, it's actually the
ELF headers. Second, the ELF headers are essentially useless for firmware
since there's currently nothing to tell you where they are, and even if there
was, there isn't much of a reason to look at them. They're useful in userspace
for, for instance, the dynamic linker, but not really in firmware.
This change adds a PHDRS construct to each of the linker scripts used on ARM
which define a single segment called to_load which does not have the flag set
which would tell the linker to put headers in it. The first section defined in
the script has ": to_load" to tell the linker which segment to put it in, and
from that point on the other sections go in there by default.
Change-Id: I24b721eb436d17afd234002ae82f9166d2fcf65d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3580
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vendor and part name from coreboot is normally stored in these
SMBIOS structure fields, but it can be useful to override them.
On Lenovo ThinkPads an override is e.g. needed to convince the Linux
thinkpad_acpi.c driver that it is actually running on a ThinkPad.
Change-Id: I0dfe38b9f6f99b3376f1547412ecc97c2f7aff2b
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/1556
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This is needed for the Linux thinkpad_acpi.c driver to load.
Change-Id: I3d9549395556ffb0abfc3cb52b3d01386c34caa5
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3731
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This version is taken from arch/arm/lib/memmove.S in the Linux kernel.
Change-Id: Ic875d0cf5b1cb407606530b7f465c406b134f0fa
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3763
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is from memcpy_32.c in the Linux kernel. There was no copyright header
in the original file either.
Change-Id: Ifd259cb8a87615dce79ed1e551cc4bacb0414b4f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I4b6a57e7d8e7e685c609b1d85368585b9dd197dc
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
mainboard_enable() is now modelled after google/parrot where the
enable function only sets dev->ops->init for the root device to
point to a mainboard_init() function, which in turn is called in a
later pass over the device tree to do the actual initialization.
Change-Id: Iaf9187532a1e432b991260201b95dda85cc312c5
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The options that keep track of whether there are arch versions of the standard
string functions shouldn't be in the arch/x86 directory since they apply to
all architectures. Move them into the higher level, shared Kconfig defaulting
to off. Then, in each applicable arch (currently all of them) they can be
selected to on.
Change-Id: I7ea64a583230fdc28773f17fd7cc23e0f0a5f3d6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3760
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some kernel assembly code uses a W macro to optionally add a .w to
instructions that need to be 32 bit thumb. The gnu assembler doesn't seem to
need the .w and won't assemble if it's provided.
Change-Id: I0a288177788b5c61810ee7bd3d2debea66835de2
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3759
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
With EARLY_CBMEM_INIT and CAR_MIGRATION selected, cbmemc_reinit()
was called twice during romstage. This effectively deleted output
of romstage in CBMEM console.
Change-Id: I21072a319c0e4a5f695b0573bc017bf7921fc663
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Split PCI IO configuration and MMIO configuration cycles to separate
files. Modern hardware does not use IO cycles for PCI configuration
after initial setup in bootblock.
Note that the pci_mmio_ and pcie_ functions were different in masking
the alignment for register address. PCI standard requires that 16-bit
and 32-bit configuration register writes do not cross boundaries.
Change-Id: Ie6441283e1a033b4b395e972c18c31277f973897
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3554
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
PCI bus operations are static through the ramstage, and should be
initialized from the very beginning. For all the replaced instances,
there is no MMCONF_SUPPORT nor MMCONF_SUPPORT_DEFAULT selected for
the northbridge, so these continue to use PCI IO config access.
Change-Id: I658abd4a02aa70ad4c9273568eb5560c6e572fb1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Routes IRQs for USB device, SPI1, MOTOR, HD audio, CAN bus.
Change-Id: I995a5c6d3ed6a7dca4f0d21545c928132ccbbc21
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3725
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Store EHCI Debug Port runtime variables in CAR_GLOBAL.
For platforms without CAR_MIGRATION, logging on EHCI Debug Port is
temporarily lost when CAR is torn down at end of romstage.
On model_2065x and model_206ax ehci_debug_info was overlapping the MRC
variable region and additionally migration used incorrect size for
the structure.
Change-Id: I5e6c613b8a4b1dda43d5b69bd437753108760fca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3475
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are other uses for EHCI debug port besides console, so move
EHCI relocation code from console to lib.
Change-Id: I95cddd31be529351d9ec68f14782cc3cbe08c617
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3626
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move ehci_debug_info allocation from console to lib, as console code
was only built for ramstage.
Implement dbgp_ehci_info() to return the EHCI context. Alread alias this
as dbgp_console_input() and _output() to return the console stream context
later on.
Change-Id: Id6cc07d62953f0466df61eeb159e22b0e3287d4e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3625
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Output to usbdebug console needs to be disabled until hardware is
initialized and while EHCI BAR is relocated. Add separate field
ehci_info to point to back to EHCI context when hardware is ready
to transfer data.
Change-Id: If7d441b561819ab8ae23ed9f3f320f7742ed231e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3624
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The display port bridge on pit is different from the one on snow and needs to
be initialized differently. Instead of waiting for the chip to come up on its
own and assert the hotplug detect, we need to access it over i2c and get it up
and running ourselves.
Change-Id: I4bc911cb8e4463edff7beabd2f356cb70ae9f507
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3723
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This driver is basically the same as the one in U-Boot but without the device
tree stuff. That driver is, in turn, a straightforward implementation of the
sequence of register writes described in the data sheet. Comments were added
in U-Boot which helpfully describe what the register writes are actually
doing and are kept.
Change-Id: I64ba6b373478853bb2120f0553a43de901170d02
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/3753
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was removed from ramstage a little while ago and should have been removed
from here as well.
Change-Id: I6a40ed4a98bedac39e5492e4b1aed3427ab4e08b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3720
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This appears to be needed, though we have no way to test yet.
Change-Id: I39033581011e056258193f2cdff78814361a8d55
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3719
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In resume path, if memory setup takes too long without setting PS_HOLD, EC watch
dog may power off or reboot the system. To prevent that, we should enable
PS_HOLD in same timing as cold boot - right before starting memory setup.
Change-Id: I5c294fa7ae015f8cff57b1fd81e5b80902647b15
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3718
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The functions which manipulated the tps65090 were removed a while ago because
it isn't accessible directly from the AP, it's on an I2C bus that has to be
accessed by the EC on our behalf. Now that that capability has been added, we
can rewrite the small portion of the the tps65090 we actually used but using
the EC passthrough commands.
Also, we should not be configuring the hardware display port hotplug detect
line since we're using it as a GPIO for other purposes. The GPIO we're using
instead defaults to being an input, but to be safe we should probably
explicitly configure it as one anyway.
Change-Id: I7f8a8a767e3cccb813513940a5feceea482982f5
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ChromeOS EC for peach_pit is connected to SPI2 bus, not I2C.
Change-Id: Ifeb8a626aa4fc3d3a181a7bc016e3f91be948ae5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3716
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The workaround of re-opening device in exynos_spi_read has been fixed by the new
correct open/close and xfer procedure. It's safe to be removed now.
Change-Id: I6b1bf717c916903999a137998a578b0a866829bd
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3715
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Switch spi_xfer and exynos_spi_read to use the new spi_rx_tx function.
Change-Id: I01ab43509df1319672bec30dd111f98001d655d0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SPI driver (exynos_spi_rx_tx) was implemented with only "read" ability and
only full-duplex mode. To communicate with devices like ChromeOS EC, we need
both output (tx) and half-duplex (searching frame header) features.
This commit adds a spi_rx_tx that can handle all cases we need.
Change-Id: I6aba3839eb0711d49c143dc0620245c0dfe782d8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3713
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The original Exynos SPI open/close procedure was copied from U-Boot SPL with
some assumptions that only works in SPL stage. For example, it tries to always
work in 4-byte transmission mode with only RX data is swapped, and claims a
packet for initial address command (and with incorrect size).
This commit revises open/close and reset so only the required SPI registers are
configured.
Change-Id: Ieba1f03d80a8949c39a6658218831ded39853744
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3712
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fill the SPI device parameters for spi_setup_slave on Exynos 5420.
Change-Id: I10b4b9e6cfe46d7bfa34e80e3727c7e7da99ba9d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SPI module in Exynos 5420 didn't follow Coreboot's SPI API standard
(spi-generic.h) and will be a problem when we want to share SPI drivers.
This commit replaces exynos_spi_* by spi_* functions.
Note, exynos_spi_read is kept and changed to a static function because its usage
is different from the standard API "spi_xfer".
Change-Id: I6de301bc6b46a09f87b0336c60247fedbe844ca3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove unused header and constant definition in SPI module.
Change-Id: I339e603f48186e4a356e83518b0d0b4c907f11b8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3709
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add SPI0 and SPI2 to Exynos 5 SPI list, and correct structure names.
Also removed the un-enumerated devices (SPI_BASE, base_spi()).
Change-Id: Ica6d9a41f9619c8c61eab664d5e988dd4a428e09
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3708
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For devices with ChromeOS EC on SPI bus, use the standard SPI driver interface
(see spi-generic.h) to exchange data.
Note: Only EC protocol v3 is supported for SPI bus.
Change-Id: Ia8dcdecd125a2bd7424d0c7560e046b6d6988a03
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the new Chrome EC protocol version 3 to Coreboot.
Note, protocol version 3 is not applied on any bus implementations yet.
LPC (x86) and I2C (arm/snow) are still using v2 protocol. The first one to use
v3 protocol will be SPI bus (arm/pit). LPC / I2C will be updated to v3 only
when they are ready to change.
Change-Id: I3006435295fb509c6351afbb97de0fcedcb1d8c4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3750
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since EC protocol v3, the packet format will be the same for all buses (inclding
I2C, SPI, and LPC). That will simplify the implementation in each individual bus
driver source file.
To prepare for that, we will move the protocol part into crosec_proto.c:
crosec_command_proto, with bus driver in callback "crosec_io".
Change-Id: I9ccd19a57a182899dd1ef1cd90598679c1546295
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Embedded Controller (EC) for Pit is connected via SPI2, and needs to be
configured before we can talk to it.
Change-Id: I1f8e921b4616f15951f3e5fae1ecbf116de4ba90
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3707
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Steve Goodrich