| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Id1277ceefc844a052627483e6c9d01bcb5da975f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3722
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 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>
|
|
Change-Id: I4feabc448945c4664d3114c0c8afdad48338230a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3705
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I2dc4caa370473dd86fee2b5cc8b1b9eb154b970e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... this is needed for libpayload to talk to USB devices.
(forward ported from https://gerrit.chromium.org/gerrit/#/c/55554)
Change-Id: I5a20864689efd0c0149775e6d85b658e0cc6715c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3697
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... this is needed for libpayload to talk to USB devices.
Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
Change-Id: I06ba773da3af249efec723bb90c2e9e8075a777a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
Change-Id: I270bbfd3aff781d88304791b1d9735777643caab
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That part isn't used on pit.
Change-Id: I48f3a10f7e6eb89b1e9630d2372b6865b4c12a7f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3687
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
Change-Id: I7218f85f9f26623bd13aaaf8ded0638b3b2f874a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
Change-Id: I9c6f21f183dacc0bca71277e681e670834412d78
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3680
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Tested and working. Gets us to ramstage.
Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5e0ec360597cd95cb6510fb32b04d8931e6a33db
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3674
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
Change-Id: I2152ab760e31a335dbcd9d6ad32cd1eaae4b89bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3670
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
Change-Id: Ie349f2a4117883302b743027ed13cc9705b804f8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Updated ec_commands.h is copied in directly from EC repo
- Removed "old" interface and update resources for "new" interface
- Updated temp sensor constants and added "not calibrated"
- Update mainboards to remove check for EC_SWITCH_KEYBOARD_RECOVERY
Change-Id: Ic93c1914f86b6f5bc224178270624ed92b5c1e15
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The new code is stolen from U-Boot with little or no understanding of how it
works.
Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Coreboot knows that, for the snow board, certain pins are to be connected to
bus controllers in the SOC and to the wires of a bus external to the SOC. It
can configure them as such and free its payload from having to know how to
set everything up.
Change-Id: I1bb127c810e9ee077afc4227a6f316eaa53d6498
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3650
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change adds a pit mainboard which is mostly a copy of snow, except that
mentions of the 5250 were replaced with the 5420, and mentions of snow were
replaced with pit.
Change-Id: I8eb0ce379eb2fa353bb88d5656a0c5e2290afbf0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In ram stage, all code flow should be tied to the resource allocator.
Stuff that has to happen before everything else goes into the mainboard
enable function in mainboard.c. This patch empties the main() wrapper
around hardwaremain.c, allowing to get rid of this special case in the
ARM port.
Change-Id: Ide91a23f1043b64acf64471f180a2297f0f40d97
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3638
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: I07512b3695fea0b22949074b467986420783d62a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3637
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This code is the initial version of FUI for haswell and wtm2.
The code is simplified from before in many ways. I've gotten rid of
the opcode table, because it obscured meaning and I don't think it is
needed any more. Register sets, mainly used for reset, are just lines
of code -- not many of them. There are a bunch of not-yet-documented
registers here; the VBIOS seemed to think they were necessary and
testing shows they seem to be right.
As a bit of added paranoia, we always include the VBIOS code as our
emergency recovery path. You have to run it now anyways, so this is no
regression from our current situation; and, if all goes well, in a
week (or so), you'll never have to run it again, but like the Force
and nose hair, it will be with you always.
The code can return in three ways. The first, best way is success:
panel is up and the VBIOS need not run. The second mode is that we
tried to light up the panel but could not, for some reason, but will
return with the panel partly up. In this case, it's ok not to power
cycle the panel. The third, worst case, which will NEVER happen, ha
ha, is that we have to turn the panel off and wait the required 600ms
for it to cycle. Life sucks sometimes. This failure mode is in the
'hang on we're going to fix it' category now that we have ramstage in
RW.
The Big Goal here is to create something other coreboot ports can use
as well. The guys doing the x60 report that the link FUI works,
without too many mods, on that chipset, so it seems Intel is keeping
things from changing too much over time.
Also, again, please note: this and the next 3 versions will ALWAYS fail.
The goal is to verify the correctness of the recovery path.
The bizarre tab-space formatting in drm_dp_helper.h is from the original,
as in i915_reg.h
Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3635
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This lights up the display. We don't get graphics but we are missing the gttsetup
at this point, so that is no shock. The real shock is that anything works at all.
Change-Id: I03fc470334e96878aeb8465044b3cc9c90378735
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3634
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: If357b55b91618ee2438e6c6b2efb7018c56d26d0
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3628
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I8d42f765519e356d8f0cc6ed339d9b74f0a3e4d7
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3610
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change all PCI configuration accesses to MMIO on two boards
with i5000 chipset. To enable MMIO style access, add explicit
PCI IO config write in the bootblock.
Change-Id: I26f1c2da5ae98aeeda78bdcae0fb1e8c711a3586
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I missed the board with gm45 when I moved MMCONF_SUPPORT lines.
Also, the intel/i3100 does not have MMCONF_SUPPORT implemented
even though it was previously selected for intel/eagleheights board.
Change-Id: I9c7f6b0a150b4d54288a1e015277b9d98467fca4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3598
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change all PCI configuration accesses to MMIO on all boards
with i945 chipset. To enable MMIO style access, add explicit
PCI IO config write in the bootblock.
Change-Id: Ia1ab73f1a2dcda87db4eb9b2ffddc6f7b4382b01
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3584
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
Change all PCI configuration accesses to MMIO on all boards
with SandyBridge and IvyBridge. To enable MMIO style access,
add explicit PCI IO config write in the bootblock.
Change-Id: I8f957a80bf57df000897c5a080dd5ff131b1ec0d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3576
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
Move/remove MMCONF_SUPPORT reference under mainboard Kconfig, as
that feature originates from northbridge and cannot be disabled
for a single mainboard.
Change-Id: I6d6861079876ddddaff90b10f18edb6936e93bd0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3589
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Set up the pinmux to enable the pins and the clocks for whichever UART is
currently configured.
Change-Id: Iac13f16d9d84320555b99734ea83eafd0a2803fe
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3573
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Thanks to Bruce's great work, we can finally drop this workaround.
Change-Id: Ie92d1e53ef867fa34aa2489ccfb682d73195b213
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3569
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Users of mptable_write_buses() pass two pass-by-reference
parameters reflecting a maximum bus number and a search bus
number. These bus numbers are expected to be held in "int"
variables and are updated by the function. Both of the
Supermicro boards define the search bus number as a
byte value in mptable.c.
For now, change the two Supermicro boards to use "int"
to hold the search bus index.
Change-Id: Ie71850719c1fa3cda0ac9c8773bb80650de95c70
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3546
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fix a bunch of compiler-generated warning messages. These fixes are
mainly braces for grouping initializers. These changes are not
intended to change any code functionality. There are two changes where
function prototypes are added, and two cases where unused variables are
eliminated.
Change-Id: I93cef8899170b5575e7fb7c55181b381a7bcd9d8
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3545
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The existing code for setting Azalia configuration assumes that
the configuration bits are contiguous within a single byte and
can be set using a byte copy addressed into the lowest 2-bit
subfield.
The fix in Family 14 defines a union that can be addressed as a
byte to overlay the bit fields. Since the offset of the four
subfields is not necessarily fixed, change the code to initialize
each of the four subfields individually.
Change-Id: I1dff20bb8bd3e1bcd8b4e6b0537e20779d2a3521
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3544
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Copy a type cast from the other cases of the same switch statement
to eliminate compiler warning messages.
Change-Id: I8d0a88892f6a5f8e43227ab5f830041894b07f6a
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3543
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On Dinar, H8SCM, and H8QGI, add <cpu/amd/amdfam15.h> as an
include to pick up the prototype definition of get_bus_conf().
Change-Id: Ie4887670ac52aa194745881362df19cd1d75773e
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3542
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This requires a new system agent binary (v6 / v11 on haswell).
Note that the existing system agent binaries are long time obsolete
and won't work with current coreboot, so this update is overdue.
Change-Id: I48d8649576ca84d2b85ab082ce06f3462e189059
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3568
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
BIOS write protects 8 bytes of CMOS, which nvramtool can't cope with.
This makes initial installation harder, so just mark those as reserved
to work around the issue.
Change-Id: I210861dff8572e226a0f250556a3b811671ea8f2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3531
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
For iwave/iWRainbowG6 using intel/sch, MMCONF_BASE_ADDRESS was unused
and different from hardware setting. Change that to match hardware
programming.
Change-Id: I3324b7ea0e6f092206d4b6b791476d538e826657
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3507
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: Ife1c0a8597c2de04773899cdd87af6b6c630906a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3392
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There are no files to build left under AMD nortbridge/x/root_complex
directories. For some cases, even the Kconfig file was no longer sourced.
Remove all such references and empty files.
For devicetree.cb treat component paths with "/root_complex" in them valid
even when the directory does not exists. This is because AMD boards us this
dummy chip component as the root node in their devicetree.cb.
The generated devicetree file static.c remains unchanged.
Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3434
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The IOMMU needs IRQs assigned. So add those.
Change-Id: Ic9f02e28aac593cddf7d222a8abb780a10572d32
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3318
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In commit Rudolf Marek discovered, that it is not uniformly written. As
»ASL names are not case-sensitive and will be converted to upper case.« [2]
this change does not have any functional change.
The following command was used to create this patch.
$ git grep -l 'package()' src/mainboard | xargs sed -i 's,package(),Package(),'
[1] http://review.coreboot.org/#/c/3318/
[2] http://www.acpi.info/spec40a.htm
(18.2.1 ASL Names)
Change-Id: I1784dbc50936a1ef9d4376209a3c324ef1fb85cf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3516
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This commit was tested on qemu with and without CONFIG_DYNAMIC_CBMEM
by running cmbmem -c once booted. The qemu command that was used was:
qemu-system-i386 -bios ./build/coreboot.rom -serial stdio -hda ../virt/parabola.img
Note that using CONFIG_RELOCATABLE_RAMSTAGE make it fails like that:
Loading image.
CBFS: Decompressing stage fallback/coreboot_ram @ 0x3ffbefc0 (184400 bytes)
Loading module at 3ffbf000 with entry 3ffbf000. filesize: 0x18db8 memsize: 0x2c050
Processing 1703 relocs with adjust value of 0x3ffbe000
FATAL: Essential component is missing.
However without CONFIG_RELOCATABLE_RAMSTAGE set it boots fine.
Change-Id: I633a8c3832eee4e8bed244940fdc370b98dd26f0
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3504
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Collect early timestamps in T60's romstage like some newer boards do.
This should also work on X60s (and other ICH7 based systems with
EARLY_CBMEM_INIT).
Change-Id: I3b2872dd7423f3379ff3b68ad999523ec35fc08e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3499
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Ditch unused fb*.h files.
Rename init.c (name is _way_ to generic) to bochs.c.
Add proper bochs dispi interface detection and mode setup.
Hook up coreboot framebuffer table initialization.
Change-Id: I7154b1593902e7d42606b64819217872eee10683
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3500
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I8371764e3f2d16a3a776beb1c064f461b20a4262
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3496
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
All 3 boards with AGESA_HUDSON had HAVE_HARD_RESET with the reset.c
file already placed under southbridge/.
All 15 boards with CIMX_SBx00 had HAVE_HARD_RESET with functionally
identical reset.c file under mainboard/. Move those files under
respective southbridge/.
Change-Id: Icfda51527ee62e578067a7fc9dcf60bc9860b269
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3486
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Confusingly, romstage compiled in different copy of soft_reset()
than ramstage. Use source in reset.c for both.
Change-Id: I2e4b6d1b89c859c7cf5d9e9c8f7748b43d369775
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3487
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The chip component is unconditionally selected for the mainboard
so these uses are superfluous.
Change-Id: I84b053ab47f7b1f68e88d968cf305e24bc95f4da
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3485
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
CONFIG_HUDSON_XHCI_ENABLE will control the XHCI flags in the
amd/parmer and asus/f2a85-m mainboards. The XHCI ports on
amd/thatcher are not wired to USB jacks so always disable the flags.
This was tested on amd/parmer using a USB 3.0 thumbdrive.
Change-Id: I596b040fec30882d8d4dee34ab9f866dc1f8896b
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3465
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I0d499027ffb175638cba0a9830d6ec2041a139db
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3488
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for the new q35 chipset emulation
added in qemu 1.4.
Change-Id: Iabfaa1310dc7b54c9d224635addebdfafe1fbfaf
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3430
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ic83f55d01b29b43028e3b363749d64b927db5489
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3492
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
So the pci allocation code knows where memory is and doesn't
try map pci devices there. We also don't have to check for
overlaps between pci hole and memory then.
Change-Id: I5eaea0e4d21210719685860fa1f16ca7b2137cde
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3491
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Prepare tree for adding q35 support:
Move emulation/qemu-x86 to emulation/qemu-i440fx.
Rename some stuff to include 'i440fx'.
Change-Id: Ib8c58175c5734cfcda1b22404ef52c09d38f0462
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3429
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This issue can be reproduced in Linux by the following steps:
1) use pm-suspend to suspend.
2) use USB keyboard to wake up.
3) use pm-suspend to suspend. FAIL To SUSPEND.
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
In this patch, I add AcpiGpe0Blk using MMIO access and write 1
on bit 11. Write 1 to clear as spec says.
I have tested on Thatcher
The same change was done for AMD Parmer in commit »AMD Parmer:
fix issue 'S3 fails to suspend after wake up from USB keyboard'
(03901124) [1].
[1] http://review.coreboot.org/#/c/3347/
(Change-Id: Iec3078bf29de99683e7cd3ef4e178fbeb4dc09c1)
Change-Id: Iaef39237497ef896d0f186e8f5522222c0ce6cb7
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3374
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This ancient board with Intel e7505 invalidates cache while it does HW
scrubbing for ECC in romstage. This breaks usbdebug console and prevents
system from booting.
If both EARLY_CONSOLE and USBDEBUG are selected, skip ECC scrubbing under
these rare conditions to boot system.
Change-Id: I6cb43bf69af54119f4a582dcaf498dd941d4c62d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3385
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Now that the ROM size is decoupled from the size of the on chip RAM,
it's size is now only constrained by the size of the medium it's loaded
from and the memory it's being loaded into, probably GBs in both cases.
Making it 4MB is a reasonable compromise between giving the payload lots
of breathing room and wasting space on the source medium which won't be
used.
Change-Id: I80932e0d4ce2dad02c3879345382e7d6ba44503a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3422
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Until we get serial working, this is a good way to show that coreboot is
running. It can be removed once we have better methods.
Change-Id: I62d25e52aa88a97aba4c959538d680b67a0bbbb2
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
EPIA-M850 can now boot linux. For a list of issues, see:
http://www.coreboot.org/VIA_EPIA-M850
That's all folks.
Change-Id: I7624944dbc05fbf3019897a116954d71dfda0031
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1228
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Keep in mind that we can _NOT_ read back the current state
of the LEDS as some crazy FPGA designer wanted it that way.
Change-Id: I5cd1ac598072318b3234d1ec35a79271655b46ac
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3271
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Without that commit, with CONFIG_PCI_OPTION_ROM_RUN_YABEL,
The VGA option rom doesn't init the right display:
it initializes the external display, where we have
a black scren(with backlight on).
This commit is based on the code of mainboard.c in
src/mainboard/roda/rk886ex.
Change-Id: I8457aaf0503e0efdf0fcba9ff5e8a07ac04c5ca6
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3265
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
First copy over from SeaBIOS git repo, then adapt for coreboot:
Disable cpu/pci hotplug bits. Disable dynamic pci window.
Both depend on stuff in the SSDT tables created by SeaBIOS.
Bits are left in, but deactivated via #if 0, so it's easier
to see the differences when diffing the coreboot tables with
the SeaBIOS tables.
Adapt dsdt DefinitionBlock.
Enable acpi table generation in acpi_tables.c.
With this patch linux boots successfully with ACPI enabled.
It's not bug-free though. Missing cpu detection leads to
funky messages like this one:
weird, boot CPU (#0) not listed by the BIOS.
and SMP most likely wouldn't work either.
Change-Id: Ic3803a6f1ef6d54c11cc4ca3844d3032a374ae6b
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3342
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The DDI connector table and the PCIe Port List lookup table are
copied onto HEAP. This copy is not needed since these are lookup
tables used to define the platform configuration.
Change-Id: If4760f80e08faa8da4fd11337a3812f89cf805f9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add boot cpu to the device tree. Figure the number of CPUs installed
(using the qemu firmware config interface) and add cpu devices for them,
so they show up in all generated BIOS tables correctly. This gets SMP
going.
Change-Id: I0e99f98942d8ca90150b27fc13c1c7e926a1a644
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Needed to make 'register "gpo" = ...' work.
While being at it add comments saying which device is which.
Change-Id: I911d5e4a7b6c7abf4ad73e863ab201e9e55ee0d4
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3346
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
qemu has a special device to pass configuration information
from qemu to the firmware. This patch adds initial support
the interface, namely some infrastructure, detection code and
a function to query the number of CPUs.
Change-Id: I43ff5f4fbf12334a91422aa38f514a82a1d5219e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit eed28f97b375a9469a2872996c19eb102647052e.
For whatever reason, the dependencies were lost in Gerrit and the
commit [1] was submitted without its dependencies. As a result
buidling the ASUS F2A85-M fails now [2] and therefore commits
based on this commit fail to pass the buid tests by Jenkins.
[…]
Created CBFS image (capacity = 8387656 bytes)
LINK cbfs/fallback/romstage_null.debug
CC cbfs/fallback/coreboot_ram.debug
coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1
make: *** Waiting for unfinished jobs....
coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
[…]
Therefore revert the commit to get the tree working again and
submit this patch with its dependencies again.
[1] http://review.coreboot.org/#/c/3317/
[2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Do the setup for all PCI slots, not only the third.
Also remove the bogus message, as slot 3 may carry
any device, not only NICs.
This makes IRQ setup simliar to SeaBIOS.
SeaBIOS assignments (with patch for logging added,
and a bunch of pci devices for testing purposes):
PCI IRQ [piix]: bdf=00:01.3 pin=1 line=10
PCI IRQ [piix]: bdf=00:03.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:04.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:05.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:06.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.1 pin=2 line=10
PCI IRQ [piix]: bdf=00:1d.2 pin=3 line=11
PCI IRQ [piix]: bdf=00:1d.7 pin=4 line=11
Coreboot assignments without this patch:
Assigning IRQ 11 to 0:3.0
Coreboot assignments with this patch:
Assigning IRQ 10 to 0:1.3
Assigning IRQ 11 to 0:3.0
Assigning IRQ 11 to 0:4.0
Assigning IRQ 10 to 0:5.0
Assigning IRQ 10 to 0:6.0
Assigning IRQ 10 to 0:1d.0
Assigning IRQ 10 to 0:1d.1
Assigning IRQ 11 to 0:1d.2
Assigning IRQ 11 to 0:1d.7
Change-Id: Ie96be39185f2f1cbde3c9fc50e29faff59c28493
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3334
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Activate the IOMMU support for the Asus F2A85-M.
Add the device to `devicetree.cb`.
$ pci -s 0.2
[…]
00:00.2 IOMMU: Advanced Micro Devices [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit
$ dmesg
[…]
[ 0.000000] ACPI: IVRS 00000000bf144e10 00070 (v02 AMD AMDIOMMU 00000001 AMD 00000000)
[ 0.000000] ACPI: SSDT 00000000bf144e80 0051F (v02 AMD ALIB 00000001 MSFT 04000000)
[ 0.000000] ACPI: SSDT 00000000bf1453a0 006B2 (v01 AMD POWERNOW 00000001 AMD 00000001)
[ 0.000000] ACPI: SSDT 00000000bf145a52 00045 (v02 CORE COREBOOT 0000002A CORE 0000002A)
[…]
[ 0.465114] [Firmware Bug]: ACPI: no secondary bus range in _CRS
[…]
[ 0.567330] pci 0000:00:00.0: >[1022:1410] type 00 class 0x060000
[ 0.567364] pci 0000:00:00.2: >[1022:1419] type 00 class 0x080600
[ 0.567427] pci 0000:00:01.0: >[1002:9993] type 00 class 0x03000
[…]
[ 0.597731] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.597899] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PIBR._PRT]
[ 0.597933] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR0._PRT]
[ 0.597972] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR1._PRT]
[ 0.598073] pci0000:00: >Requesting ACPI _OSC control (0x1d)
[ 0.603808] pci0000:00: >ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[ 0.612397] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 0.620508] Freeing initrd memory: 14876k freed
[…]
[ 0.882674] pci 0000:00:01.0: >Boot video device
[ 0.882876] PCI: CLS 64 bytes, default 64
[ 0.897088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 extended features: PreF PPR GT IA
[ 0.905816] pci 0000:00:00.2: >irq 40 for MSI/MSI-X
[ 0.917457] AMD-Vi: Lazy IO/TLB flushing enabled
[ 0.922076] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.928500] software IO TLB [mem 0xbb13d000-0xbf13cfff] (64MB) mapped at [ffff8800bb13d000-ffff8800bf13cfff]
[ 0.938535] LVT offset 0 assigned for vector 0x400
[ 0.943338] perf: AMD IBS detected (0x000000ff)
[ 0.948037] audit: initializing netlink socket (disabled)
[ 0.953432] type=2000 audit(1369659616.800:1): initialized
[ 0.977011] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[…]
[ 7.881938] radeon 0000:00:01.0: >VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 7.881941] radeon 0000:00:01.0: >GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[…]
[ 7.885516] radeon 0000:00:01.0: >irq 48 for MSI/MSI-X
[ 7.885525] radeon 0000:00:01.0: >radeon: using MSI.
[…]
[ 8.276775] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae000 flags=0x0010]
[ 8.287363] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc00 flags=0x0010]
[ 8.297945] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae200 flags=0x0010]
[ 8.308527] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae080 flags=0x0010]
[ 8.319109] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae240 flags=0x0010]
[ 8.329694] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001accc0 flags=0x0010]
[ 8.340276] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace80 flags=0x0010]
[ 8.350858] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd80 flags=0x0010]
[ 8.361441] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae280 flags=0x0010]
[ 8.372022] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae180 flags=0x0010]
[ 8.382605] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace00 flags=0x0010]
[ 8.393188] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acdc0 flags=0x0010]
[ 8.403770] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace40 flags=0x0010]
[ 8.414353] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae1c0 flags=0x0010]
[ 8.424936] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc40 flags=0x0010]
[ 8.435518] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc80 flags=0x0010]
[ 8.446100] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae2c0 flags=0x0010]
[ 8.456684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae300 flags=0x0010]
[ 8.467265] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae340 flags=0x0010]
[ 8.477849] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae380 flags=0x0010]
[ 8.488431] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae3c0 flags=0x0010]
[ 8.499013] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae0c0 flags=0x0010]
[ 8.509596] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acec0 flags=0x0010]
[ 8.520179] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd00 flags=0x0010]
[ 8.530761] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad000 flags=0x0010]
[ 8.541343] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae400 flags=0x0010]
[ 8.551925] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae440 flags=0x0010]
[ 8.562509] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf00 flags=0x0010]
[ 8.573090] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae480 flags=0x0010]
[ 8.583675] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae100 flags=0x0010]
[ 8.594257] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae4c0 flags=0x0010]
[…]
[ 8.604840] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf40 flags=0x0010]
[ 8.615421] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd40 flags=0x0010]
[ 8.626004] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad140 flags=0x0010]
[ 8.636587] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad040 flags=0x0010]
[ 8.647169] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad080 flags=0x0010]
[ 8.657751] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae500 flags=0x0010]
[ 8.668335] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad100 flags=0x0010]
[ 8.678917] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad0c0 flags=0x0010]
[ 8.689499] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf80 flags=0x0010]
[ 8.700080] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acfc0 flags=0x0010]
[ 8.710664] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae140 flags=0x0010]
[ 8.721246] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae040 flags=0x0010]
[ 8.731828] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad180 flags=0x0010]
[ 8.742412] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae540 flags=0x0010]
[ 8.752995] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad280 flags=0x0010]
[ 8.763577] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad340 flags=0x0010]
[ 8.774160] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad200 flags=0x0010]
[ 8.784741] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad300 flags=0x0010]
[ 8.795324] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae5c0 flags=0x0010]
[ 8.805906] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae640 flags=0x0010]
[ 8.816490] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad2c0 flags=0x0010]
[ 8.827072] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad1c0 flags=0x0010]
[ 8.837655] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad240 flags=0x0010]
[ 8.848238] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae580 flags=0x0010]
[ 8.858819] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae600 flags=0x0010]
[ 8.869402] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad3c0 flags=0x0010]
[ 8.879985] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad380 flags=0x0010]
[ 8.890568] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae7c0 flags=0x0010]
[ 8.901151] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae740 flags=0x0010]
[ 8.911732] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae6c0 flags=0x0010]
[ 8.922316] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae780 flags=0x0010]
[ 8.932897] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae700 flags=0x0010]
[ 8.943480] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae680 flags=0x0010]
[ 8.963011] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 8.963165] radeon 0000:00:01.0: >WB enabled
[…]
It is not known, what the implications of the `IO_PAGE_FAULT` are.
Change-Id: Ic5fde609322a5fdeb1a48052c403847197752a4b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
