Removed the execute bit on all files in mainboard/amd/parmer/acpi
Change-Id: I85ffa66e0beb9c4bfe826b72968f7f633c224487
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/3807
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change all PCI configuration accesses to MMIO in qemu-q35
emulation
To enable MMIO style access, add (move) explicit PCI IO config write
in the bootblock. As there is no northbridge/x/x/bootblock.c
file, a mainboard/x/x/bootblock.c file is added for this purpose.
Change-Id: I979efb3d9b2f359a9ccbd1b4f6c05f83bab43007
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3599
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Taking device_t as a parameter, this allows to alter the PCI config
access handlers. This is useful to add tracing of PCI config writes
for devices having problems to initialise correctly.
On older AMD platform PCI MMIO may not be able to fully configure all
PCI devices/nodes, while MMIO_SUPPORT_DEFAULT would be preferred due
to its atomic nature. So those can be forced to IO config instead.
Change-Id: I2162884185bbfe461b036caf737980b45a51e522
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3608
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Refactor the structure to better support receive and another
set of endpoints over usbdebug.
Change-Id: Ib0f76afdf4e638363ff30c67010920142c58f250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3726
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The raw CPUID is useful for matching the directories under 'src/cpu/intel'
and is not easy to find out otherwise because it is most often decoded
already. The decoded values are not obviously hexadecimal so prepend
them with 0x to make sure they are unambiguous.
The output differences look like this:
- CPU: Processor Type: 0, Family 6, Model 25, Stepping 2
+ CPU: ID 0x20652, Processor Type 0x0, Family 0x6, Model 0x25, Stepping 0x2
Change-Id: Id47f0b00f8db931f0000451c8f63ac1e966442c4
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3788
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Tested-by: build bot (Jenkins)
The code to figure out how to set num_starts was
starting to get kludgy. It's a constant for a given
CPU; constants should be constant; make it a config variable.
This change includes an example of how to override it.
Build but not boot tested; drivers welcome.
Change-Id: Iddd906a707bb16251615c7b42f2bfb5a044379b4
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3796
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
This is the first of a series of patches to provide support
for a new mainboard, Gigabyte GA-B75M-D3V.
This patch provides early serial for the superio and has been
tested on this mainboard. The code is based on IT8718F superio.
Change-Id: I5636199b49314166ed3b81e60b41131964dd44ff
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/3794
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Change-Id: If1fa39db79eeecbef90c8695143d2fe2adf2f21a
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3732
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The Linux thinkpad_acpi.c driver looks for this string while
reading information about the system it is running on.
This commit does not make the module load but it is one of
several things that the module looks for on a ThinkPad.
The use of 3 defines for the serial number template
seems odd but it's done in a way that eliminates
magic numbers, yet avoids use of strcpy, strlen,
strindex, strchr, or strspan: we can have some
correctness assured at compile time. Also, the
defines can be copy/pasted for other mainboards
and we should void errors due to people not changing
magic numbers.
Change-Id: Ief5f28d2e27bf959cb579c4c8eea9eecc9a89a7c
Signed-off-by: Peter Stuge <peter@stuge.se>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CBFS_ROM_OFFSET was declared in both the am335x config and the beaglebone
config. This removes it from the beaglebone config.
Change-Id: I657cb8e83a1ee961d8bdc995a41f303920bc53f9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3771
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
Kimarie Hoot