Commit 039223a: gitmodules: Ignore 3rdparty in "diff family"
changed the behavior of our 3rdparty repository and disallowed
updates to the checked out hash. Instead of "ignore=all" we
want "ignore=dirty" to ignore local changes but allow changing
to the HEAD of the 3rdparty repo.
Change-Id: I66c35ad4fcfb0efb0ba611f67648a096a6de1479
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3566
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit d358a506c4http://review.coreboot.org/#/c/3514/ comments:
The pei_data version changed to 6, so new binaries are needed.
However, demand for new binary blob is not referenced with this commit nor is git submodules hash updated. Also the new binary blob almost doubles its size and no longer fits in the allocation sandybridge defines.
Change-Id: I84eb70517d5b9278c611fdfa587a71f6ca0f657f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3553
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The counted delay of 1ms was shorter than the time usb_poll() took
(~30ms observed). So with a given timeout of 100ms it actually took 3s.
We can lower the problem if we delay 10ms per loop iteration.
Change-Id: I6e084bdd05332111cc8adcd13493a5dfb4bc8b28
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3533
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The xHCI controller's MMIO space has a length of 64KiB not 4KiB.
Therefore, setting the xHCI BAR to 0xe8001000 worked the same like
setting it to 0xe8000000, as bit12 is reserved and ignored. This again
interfered with the MMIO space of the first EHCI controller and broke
S3 resume on Ivy Bridge.
AFAIK, the MRC ignores the setting of the xHCI BAR, anyway. So just drop
these lines.
Change-Id: I8af9c2ba34133f15636a9056fc8880b3b6ab95e0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3521
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.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>
Teach lpgcc to look in the in-coreboot tree directory structure, too.
Change-Id: I3809456d072ce2f91542b0edb3fd39f536298cc2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3530
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
6021 is Vortex86DX northbridge PCI device ID, not for Vortex86EX.
Change-Id: I9bea799c9033adbcfacc8ad47052280a32f9ee59
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3529
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Current build configuration always wants to include an Intel Management
Engine firmware (me.bin) on Sandy Bridge systems. However, we can have
a working coreboot without it, as long as the factory delivered ME
firmware is kept untouched in the flash ROM. So let the user decide if
a ME firmware will be included in the build.
Change-Id: I9a1cc29d4940ba22355eb9e653606e436f07e04c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3522
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
abuild checks the path for toolchains prior to building a
mainboard. It didn't check xgcc/, which would be picked up
by the coreboot make, and fail to build when it shouldn't.
Change-Id: If0ca4238e8c57a6b015fdad623ccdbf237ef1ba6
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/3350
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This new tool called `ifdfake` just creates an empty Intel Firmware
Descriptor (IFD) and writes the IFD signature plus the section layout
given on the command line.
usage: ifdfake [(-b|-m|-g|-p) <start>:<end>]... <output file>
-b | --bios <start>:<end> BIOS region
-m | --me <start>:<end> Intel ME region
-g | --gbe <start>:<end> Gigabit Ethernet region
-p | --platform <start>:<end> Platform Data region
-h | --help print this help
<start> and <end> bounds are given in Bytes, the <end> bound is inclusive.
All regions must be multiples of 4K in size and 4K aligned.
The descriptor region always resides in the first 4K.
An IFD created with ifdfake won't work as a replacement for a real IFD.
Never try to flash such an IFD to your board!
The output of ifdfake can be utilized to build an image with just the
later added sections (like coreboot itself) being valid. The resulting
image can then be partially written to a machines flash ROM to just
update coreboot (i.e. the BIOS section).
Change-Id: I925b47cab5c6d490a79d684bdd7a7a45ac442640
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3523
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On newer Intel systems, the flash ROM is shared between the host
processor (BIOS), it's Management Engine (ME) and an integrated ethernet
controller (GbE). The layout of the flash ROM (and other information) is
kept in the so called Intel Firmware Descriptor (IFD). If we only want
to build coreboot to update the BIOS section, all we need is the flash
layout.
This patch adds the option to specify the flash layout in the
mainboard's Kconfig, and thus, to build without the real IFD. However,
with such a build, one has to make sure that the IFD section on the
flash ROM won't be written over (nor any other section that hasn't been
included by coreboot). A patch to write selected sections of a flash ROM
with IFD has been sent to the flashrom mailing list [1].
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
Change-Id: Ia23e439a00a197fb54852263f8e206f16c3e8851
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3524
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
The IOMMU AGESA needs a reserved scratch space and it wants
to allocate the stuff for runtime. So provide a simple
allocator for 4 KB CBMEM page.
Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3315
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For IOMMU we need to allocate a 512 KB BAR in a non-standard
location. Use the standard allocator for that and limit the BAR
to 32-bits to be compatible with older systems.
Change-Id: I44414ce6b264b7f1c086a9b1c7ea275a0830205e
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LynxPoint LP has only EHCI controller #1.
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: I95c59fb9d5f09afd152872e9bc0418dc67e4aeb2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3472
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Also, add pretty printing of Westmere's DMI registers (tested on my t410s
by staring at non-zero output values :)
Apparently Nehalem does not have a MEMBAR? But there are some
documented memory controller control registers in PCI configuration
space... left out for now.
The PCIEXBAR is not documented publicly AFAICT, but there is
a similar register on a device on bus 0xFF. phcoder might know more...
Change-Id: I5faadb6e4f701728f5290276c02809b4993bd86d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3505
Tested-by: build bot (Jenkins)
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 patch allows the use of migrated CAR_GLOBAL variables from
the very beginning of ramstage. Without the patch, CAR_GLOBALS were
not available until northbridge set_resources().
Change-Id: Ifd4ab2ed52e07dcbe8c77e2e460dc483323e93c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3513
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Non-S3 resume paths of sandy/ivybridge call cbmem_initialize()
more than once. Doing car_migrate_variables() more than twice caused
at least loss of some lines in CBMEM console.
Change-Id: Idd14aba9384984aa3a7d38937a4b3572aa5dc088
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.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)
In case we are going to use this in future designs.
BUG=none
TEST=none
BRANCH=none
Change-Id: I750addf10e4fe6f8240f8c8262253f8af7027e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55844
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3515
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
src/lib/cbmem.c is for the static cbmem.
Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode:
<adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled
[...]
<adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
<adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c
<adurbin> +endif
<adurbin> +endif
Without that fix we have:
src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes]
src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes]
src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes]
This commit was tested on qemu-i440fx with the following commit:
qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM
( http://review.coreboot.org/#/c/3504/ ).
Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3503
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: Ib6f7cfac5acf3f8170508547d1584af90273e8c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3471
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Location is hard-coded right now, which isn't optimal.
It must be chip erase block aligned, which might fail on some flash chips
(it's 64k aligned which should work for most cases).
Change-Id: I6fe0607948c5fab04b9ed565a93e00b96bf44986
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3497
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
Upgrade the ICH7 bootblock to store an initial timestamp like we do it
since Sandy Brigde. I've checked the datasheets for the used scratchpad
registers and grepped for their usage. I'm pretty sure that they aren't
used on any ICH7 based board (for anything before the usual S3-resume
indication).
Change-Id: I28a9b90d3e6f6401a8114ecd240554a5dddc0eb5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
src/lib/edid.c:1177: error: ‘y’ may be used uninitialized in this function
Warning is bogus, but seems my gcc (4.4.7 as shipped by RHEL-6)
isn't clever enougth to figure this on its own. So help a bit
by explicitly initializing the variable.
Change-Id: Ia9f966c9c0a6bd92a9f41f1a4a3c8e49f258be37
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3501
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We can't read the drives signature before it's ready, i.e. spun up.
So set the timeout to the standard 30s. Also put a notice on the
console, so the user knows why the signature reading failed.
Change-Id: I2148258f9b0eb950b71544dafd95776ae70afac8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3493
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SPI logical device on the W83627DHG uses the second i/o port
register pair but not the first one. So we have to also set `io1`
(the second io_info struct) and not `io0` in the pnp_info structure.
Setting the PNP_IO1 flag without a mask in `io1` caused coreboot to
hang in pnp_enable_devices() until commit aeead274 which added a
check for an unset mask.
Change-Id: I027d279b4641fecd88afb14d40fbe1c0bfbf81bb
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3391
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
I was unable to find documentation that said what mode numbers correspond
to what functionality, so I translated over what U-Boot does.
Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
To have USB 3.0 support the XHCI controller needs to be enabled
and the xhci.bin firmware needs to be added to CBFS.
Change-Id: I0b641b30b67163b7dc73ee7ae67efe678e11c000
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3464
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Find all the (ramstage) implementations of enter()/exit() functions
for the configuration state, register and call them through the new
struct pnp_mode_ops. As our standard PnP functions are aware of the
pnp_mode_ops, it's not necessary to call enter()/exit() around them
anymore.
Patch generated with the cocci below. It's not perfect. The movement
of the enter()/exit() calls is somehow fragile. So I checked the
remaining calls for sense, and changed some empty lines. Also a
duplicate insertion of pnp_conf_mode_ops had to be removed.
/* Try to find enter and exit functions by their outb() structure and
their usage around calls to our standard pnp functions: */
@ enter_match @
identifier enter;
identifier dev;
type device_t;
@@
void enter(device_t dev)
{
<...
outb(..., dev->path.pnp.port);
...>
}
@ exit_match @
identifier exit;
identifier dev;
type device_t;
@@
void exit(device_t dev)
{
<...
outb(..., dev->path.pnp.port);
...>
}
@ pnp_match @
identifier op;
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
identifier enter_match.enter, exit_match.exit;
type device_t;
identifier dev;
@@
void op(device_t dev)
{
...
enter(dev);
...
pnp_op(dev);
...
exit(dev);
...
}
/* Now add enter/exit to a pnp_mode_ops structure: */
@ depends on pnp_match @
identifier enter_match.enter;
identifier exit_match.exit;
identifier ops;
@@
+static const struct pnp_mode_ops pnp_conf_mode_ops = {
+ .enter_conf_mode = enter,
+ .exit_conf_mode = exit,
+};
+
struct device_operations ops = {
...,
+ .ops_pnp_mode = &pnp_conf_mode_ops,
};
/* Match against the new structure as we change the code and the above
matches might not work anymore: */
@ mode_match @
identifier enter, exit, ops;
@@
struct pnp_mode_ops ops = {
.enter_conf_mode = enter,
.exit_conf_mode = exit,
};
/* Replace enter()/enter() calls with new standard calls (e.g.
pnp_enter_conf_mode()): */
@@
identifier mode_match.enter;
expression e;
@@
-enter(e)
+pnp_enter_conf_mode(e)
@@
identifier mode_match.exit;
expression e;
@@
-exit(e)
+pnp_exit_conf_mode(e)
/* If there are calls to standard PnP functions, (re)move the
enter()/exit() calls around them: */
@@
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
expression e;
@@
-pnp_enter_conf_mode(e);
pnp_op(e);
+pnp_enter_conf_mode(e);
...
pnp_exit_conf_mode(e);
@@
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
expression e;
@@
pnp_enter_conf_mode(e);
...
+pnp_exit_conf_mode(e);
pnp_op(e);
-pnp_exit_conf_mode(e);
@@
expression e;
@@
-pnp_enter_conf_mode(e);
-pnp_exit_conf_mode(e);
Change-Id: I5c04b0c6a8f01a30bc25fe195797c02e75b6c276
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3482
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Many super i/o chips only answer to PnP requests if they are in a
configuration state (sometimes also called ext func mode). To cope with
that, the code of many chips implements its own version of our default
PnP functions like pnp_set_resource(), pnp_enable_resource() etc.
To avoid this code duplication, this patch extends our PnP device
interface with optional functions to enter and exit configuration mode.
Change-Id: I9b7662a0db70ede93276764fa15020f251eb46bd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3481
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current default implementation of pnp_enable() only disables devices
- if set so in the devicetree - but does not enable them. Enablement takes
place in pnp_enable_resources(). Yet, many PnP chips implement their own
version of pnp_enable() which also enables devices if set in the devicetree.
It's arguable, if enabling those devices makes sense, before they get
resources assigned. Maybe we can't write the resource registers if not,
who knows? The least we can do is providing a common implementation for
this behavior, and get rid of some code duplication.
Used the following cocci:
@@
expression e;
@@
+pnp_alt_enable(e);
-pnp_set_logical_device(e);
(
-pnp_set_enable(e, !!e->enabled);
|
-(e->enabled) ? pnp_set_enable(e, 1) : pnp_set_enable(e, 0);
|
-if (e->enabled) { pnp_set_enable(e, 1); }
-else { pnp_set_enable(e, 0); }
)
Change-Id: I8d695e8fcd3cf8b847b1aa99326b51a554700bc4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3480
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A timeout while waiting for a device' signature has shown that our
error path wasn't correct. The shutdown of the ports command engine
always timed out. Fix that by waiting for FR (FIS Receive Running)
to be cleared independently from CR (Command List Running) and after
clearing FRE (FIS Receive Enable).
Change-Id: I50edf426ef0241424456f1489a7fc86a2cfc5753
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3494
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stefan Reinauer