Commit Graph

8442 Commits

Author SHA1 Message Date
Paul Menzel 9c50e6a4a0 Intel BD82x6x: LPC: Unify I/O APIC setup
Remove local copies of reading and writing I/O APIC registers by
using already available functions.

This change is similar to

    commit db4f875a41
    Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
    Date:   Tue Jan 31 17:24:12 2012 +0200

        IOAPIC: Divide setup_ioapic() in two parts.

        Reviewed-on: http://review.coreboot.org/300

and

    commit e614353194
    Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
    Date:   Tue Feb 26 17:24:41 2013 +0200

        Unify setting 82801a/b/c/d IOAPIC ID

        Reviewed-on: http://review.coreboot.org/2532

and uses `io_apic_read()` and `io_apic_write()` too. Define
`ACPI_EN` in the header file `pch.h`.

As commented by Aaron Durbin, a separate `pch_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].

[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c

Change-Id: I4478b1902d09061ca1db8eab6b71fef388c7a74c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3183
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-06-03 08:21:54 +02:00
Paul Menzel 42409e8732 northbridge/amd/amdmct: Use `static const` instead of `const static`
From ISO C99 standard: »The placement of a storage-class specifier
other than at the beginning of the declaration specifiers in a
declaration is an obsolescent feature.«

Found at <http://www.approxion.com/?p=41>.

The following command was used to make the change.

    $ git grep -l 'const static' src/ | xargs sed -i 's/const static/static const/'

As asked by Bruce Griffith, the changes in `src/vendorcode` were
reverted as that is what AMD prefers.

The same change was done already for AMD Persimmon in the following
commit.

    commit 824e192809
    Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
    Date:   Wed Feb 20 21:24:20 2013 +0100

        Persimmon: platform_cfg.h: Declare codec arrays as `static const`

        Reviewed-on: http://review.coreboot.org/2474

Change-Id: I233c83fdc95ea4f83f7296c818547beb52366a3d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3197
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-03 08:20:54 +02:00
Gabe Black 3aa58162e1 am335x: Clean up/fix some settings in the am335x Kconfig.
Some settings in the am335x Kconfig weren't actually used for anything, some
where place holders, and some where left over from another CPU. The memory
addresses are in the internal RAM in the SOC as described in the reference
manual. The stack is put where the internal ROM had its stack, and the
bootblock is put at the bottom of that region as the manual suggests. The
ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the
bootblock currently takes up.

Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3327
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-06-03 03:10:17 +02:00
Denis 'GNUtoo' Carikli 29a4355973 Provide sane Kconfig default for cmos.default.
Without that fix we have with CONFIG_USE_OPTION_TABLE:

    OPTION     cmos_layout.bin
  build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin
  make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'.  Stop.
  rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c

That log was captured with make V=1 but the error also appear with make.

Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]:

  PC Engines ALIX.1C: Add CMOS defaults.

[1] http://review.coreboot.org/#/c/3323/

Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3223
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
2013-06-02 23:07:22 +02:00
Denis 'GNUtoo' Carikli 8977b6ac5c Lenovo ThinkPad X60: cleanup Native VGA init.
Change-Id: Iaefa23a6257fd0295357465eb03ccadbef0f70da
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3272
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-31 18:57:42 +02:00
Steven Sherk 474eeedbc8 AMD Trinity boards: Add reserved memory area for SPI base address in ACPI
- SPI controller base address gets overwritten by SD controller under Linux.

    - Reason for overwrite is the SPI base address isn't in a standard BAR and doesn't
      get automatically reserved. Solution is to add it as a reserved memory area in
      ACPI.

    - This issue was found on the ASUS F2A85-M platform. Currently a workaround on this
      platform was made as part of: http://review.coreboot.org/#/c/3167/3

    - Once approved a follow-on patch for other southbridges using a non-standard BAR for
      the spi controller.

Change-Id: I1b67da3045729a6754e245141cd83c5b3cc9009e
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: http://review.coreboot.org/3270
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-31 18:17:49 +02:00
Siyuan Wang 0390112407 AMD Parmer: fix issue 'S3 fails to suspend after wake up from USB keyboard'
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. I have tested on Parmer.

Change-Id: Iec3078bf29de99683e7cd3ef4e178fbeb4dc09c1
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3347
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-31 17:50:53 +02:00
Paul Menzel d189229b45 AMD Llano, Brazos boards: Use `sizeof(var)` to get its size
Change `sizeof(type) * n`, where n is the number of array
elements, to `sizeof(variable)` to directly get the size of the
variable (struct, array). Determining the size by counting array
elements is error prone and unnecessary.

Rudolf Marek’s patch »ASUS F2A85-M: Correct and clean up PCIe
config« [1] contains the same change and is ported over. In
the commit message Rudolf makes the following comment.

»Not sure why the copy is needed instead of direct reference.
Maybe it has something to do with CAR?«

Testing on the ASRock E350M1, no regressions were noticed.

[1] http://review.coreboot.org/#/c/3194/

Change-Id: I123031b3819a10c9c85577fdca96c70d9c992e87
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3248
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-30 18:10:45 +02:00
Rudolf Marek d3ed411123 AMD Trinity boards: Use `sizeof(var)` to get its size
Change `sizeof(type) * n`, where n is the number of array
elements, to `sizeof(variable)` to directly get the size of the
variable (struct, array). Determining the size by counting array
elements is error prone and unnecessary.

Not sure why the copy is needed instead of direct reference.
Maybe it has something to do with CAR?

These changes are based on Rudolf’s original patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1], where it was just done for
the ASUS board.

[1] http://review.coreboot.org/#/c/3194/

Change-Id: I4aa4c6cde5a27b7f335a71afc21d1603f2ae814b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3247
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-30 18:04:52 +02:00
Gerd Hoffmann 1a71f4c21f qemu: remove vga hook
Extra care for the qemu vga should not be needed any more.
Since release 0.12 qemu loads the vgabios into the PCI ROM
bar, so everything works exactly like it does on real hardware.

Change-Id: I4b9bf1244cad437cbe5168600aeee52031456033
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3333
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-29 18:19:23 +02:00
Christian Gmeiner c4fd2973ab cpu/amd/geode_lx/Kconfig: Select TSC_MONOTONIC_TIMER
The following is an excerpt from serial log of the Bachmann OT200.

$ grep usec coreboot_log
clocks_per_usec: 500
Root Device init 48034 usecs
CPU_CLUSTER: 0 init 133251 usecs
PCI: 00:01.0 init 33376 usecs
PCI: 00:01.1 init 9930 usecs
PCI: 00:01.2 init 9929 usecs
PCI: 00:04.0 init 9929 usecs
PCI: 00:0f.0 init 185788 usecs
PCI: 00:0f.2 init 21473 usecs
PCI: 00:0f.3 init 9930 usecs
PCI: 00:0f.4 init 9930 usecs
PCI: 00:0f.5 init 9930 usecs
PCI: 00:0f.6 init 9930 usecs
PCI: 00:0f.7 init 9929 usecs

Change-Id: I4d0805c4cf8fcb25ec107615787fc6da0c945a30
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3308
Tested-by: build bot (Jenkins)
2013-05-29 09:22:42 +02:00
Vladimir Serbinenko e4e8e090fa util/inteltool: Add support for mobile 5 chipset
Dump registers on mobile 5. Successfully tested on X201.

Change-Id: I606371801d3ae6c96d3d404c9775c254bd0ffbc9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2993
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-05-27 02:53:49 +02:00
Gabe Black 3c7e939c3e beaglebone: initial Kconfig and Makefiles
Initial structure of Beaglebone port

Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-26 18:19:36 +02:00
Ronald G. Minnich b460a66aa9 Get buildgcc to behave reasonably with the -p choice.
buildgcc has many wrong choices, and two right ones,
but you would never guess that. It's even more
frustrating when it spends lots of time building a
full tool chain and you find out it's not the one you
wanted and, still worse, you've forgotten what it does want
and, even worse, it won't f-ing tell you what the two
right choices are!.

Have it tell you when you've done something wrong, and have it
make reasonable decisions when you say things like
-p arm
instead of
-p armv7a-eabi

This change lowers my blood pressure 10 points.

Change-Id: I44a59d7cb7a6260894d8bcb692a693ed25681ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3292
Tested-by: build bot (Jenkins)
2013-05-26 18:18:52 +02:00
Paul Menzel ac6ea04b62 Lenovo ThinkPad T60: Add support for `EARLY_CBMEM_INIT` needed for CBMEM console
Add code to support `EARLY_CBMEM_INIT` needed for CBMEM console
support by copying GNUtoo’s commit for the Lenovo ThinkPad X60.

    commit 4560ca5003
    Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
    Date:   Fri Apr 26 12:21:41 2013 +0200

        Lenovo ThinkPad X60: Init CBMEM early for CBMEM console support.

        Reviewed-on: http://review.coreboot.org/3142

Change-Id: I0c4ca5a5e60f4bb3b91653a133ec71039fcca6ab
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3187
Tested-by: build bot (Jenkins)
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-05-26 18:01:22 +02:00
Gabe Black c6d1da0b18 snow: Add a name to the serial console UART choice block.
This allows other boards to have the same choice block without confusing
kconfig.

Change-Id: Iea5a7f2d1c263aa7992f504b832ca9c862833c3f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3293
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2013-05-26 15:19:04 +02:00
Roman Zippel 330bb6acc8 kconfig: fix choice dependency check
Properly check the dependency of choices as a group.
Also fix that sym_check_deps() correctly terminates the dependency loop
error check (otherwise it would continue printing the dependency chain).

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

=======

Cherry-picked from the Linux kernel.

Change-Id: I0c98760dd0f55cf2ff70c53e0b014288b59574c8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-26 11:50:11 +02:00
Roel Kluin 48757668a5 kconfig: reversed borderlines in inputbox
Fix reversal of dlg.border.atr and dlg.dialog.atr for draw_box()
Makes the inputbox look like expected

Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

=======

Cherry-picked from the Linux kernel.

Change-Id: I596915aab0204ef0e392fefa56fad8e25204e207
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-26 11:49:30 +02:00
Roman Zippel 543aa7ba7b kconfig: add named choice group
As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

=======

Cherry-picked from the Linux kernel.

Change-Id: If0f00d1783907d606220cda5307b8960d3bfc38d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3291
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-26 11:49:12 +02:00
Ronald G. Minnich 5750fddcba Intel GM45, 945, SNB: Move `multiply_to_tsc()` to `tsc.h`
multiply_to_tsc was being copied everywhere, which is bad
practice. Put it in the tsc.h include file where it belongs.
Delete the copies of it.

Per secunet, no copyright notice is needed.

This might be a good time to get a copyright notice into tsc.h
anyway.

Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3242
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-05-25 14:22:06 +02:00
Paul Menzel 60c54cc017 cpu/amd/agesa/Kconfig: Select LAPIC_MONOTONIC_TIMER
Thanks to Aaron Durbin coreboot provides monotonic timers. Select
the LAPIC monotonic timer for the AMD AGESA CPUs.

The following is an excerpt from serial log of the ASRock E350M1.

    $ grep usec seriallog-20130502_100902.log
    01.016: Root Device init 1578 usecs
    01.029: CPU_CLUSTER: 0 init 112415 usecs
    01.029: PCI: 00:00.0 init 3240 usecs
    01.088: PCI: 00:01.0 init 104572 usecs
    01.088: PCI: 00:01.1 init 1663 usecs
    01.088: PCI: 00:11.0 init 1662 usecs
    01.088: PCI: 00:14.0 init 1662 usecs
    01.088: PCI: 00:14.3 init 8665 usecs
    01.088: PCI: 00:14.4 init 1665 usecs
    01.088: PCI: 00:18.0 init 1662 usecs
    01.088: PCI: 00:18.1 init 1663 usecs
    01.088: PCI: 00:18.2 init 1663 usecs
    01.088: PCI: 00:18.3 init 1663 usecs
    01.088: PCI: 00:18.4 init 1663 usecs
    01.088: PCI: 00:18.5 init 1665 usecs
    01.088: PCI: 00:18.6 init 1664 usecs
    01.088: PCI: 00:18.7 init 1663 usecs
    01.088: PNP: 002e.2 init 1576 usecs
    01.088: PNP: 002e.5 init 1577 usecs
    01.088: PNP: 002e.a init 1590 usecs
    01.088: PNP: 002e.b init 30144 usecs
    01.088: PCI: 03:00.0 init 1663 usecs

So the graphics device needs around 100 ms for being initialized.

The full serial log is in the Gerrit comments.

Change-Id: Ia7b3012e51fcf94b0f22290cdef2b4424295ad6d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3172
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-05-24 08:11:57 +02:00
Paul Menzel 4e01cfb6d5 cpu/intel/haswell/Kconfig: Intend help text with two spaces
Commit »haswell: 24MHz monotonic time implementation« (c46cc6f1) [1]
added the Kconfig variable `MONOTONIC_TIMER_MSR` with a help text,
but only used one space instead of the suggested two spaces for
indentation. So add one space.

»Lines under a "config" definition are indented with one tab, while
help text is indented an additional two spaces.« [2]

[1] http://review.coreboot.org/3153
[2] https://www.kernel.org/doc/Documentation/CodingStyle
    (Chapter 10: Kconfig configuration files)

Change-Id: I39cf356bfd54c66a2f1b837c6667dcc915e41f29
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3262
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-05-24 07:57:33 +02:00
Paul Menzel 87b9bf5bad include/timer.h: Fix typo in in*iti*alize in comment
Correct a typo in a comment introduced in commit »coreboot:
introduce monotonic timer API« (a421791d) [1].

[1] http://review.coreboot.org/3152

Change-Id: Ia0abc5304547d419478db1ae37b5525406fa19cc
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3261
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-23 20:17:37 +02:00
Paul Menzel 51837f9dac Intel Sandy Bridge: udelay.c: Change comparison from <= to <
Currently code in `udelay.c` differs between the Intel northbridges
GM45, 945 on the one hand and Sandy Bridge on the other hand.

The reason for this is that a wrong comparison > was used.

The following commit

    commit 784ffb3db6
    Author: Sven Schnelle <svens@stackframe.org>
    Date:   Tue Jan 10 12:16:38 2012 +0100

        i945: fix tsc udelay()

        Reviewed-on: http://review.coreboot.org/530

fixed the sign from > to <, whereas Stefan Reinauer changed it from
> to <= before adding the Sandy Bridge port in the following commit.

    commit 00636b0dae
    Author: Stefan Reinauer <stefan.reinauer@coreboot.org>
    Date:   Wed Apr 4 00:08:51 2012 +0200

        Add support for Intel Sandybridge CPU (northbridge part)

        Reviewed-on: http://review.coreboot.org/854

As there are no technical reasons for this difference, unify this
between the chipsets. See the discussion of the other patch set in
Gerrit [1].

[1] http://review.coreboot.org/#/c/3220/1/src/northbridge/intel/i5000/udelay.c

Change-Id: I64f2aa1db114ad2e9f34181c5f3034f6a8414a11
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3259
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-05-23 10:44:36 +02:00
Paul Menzel 1e24f4b37f Kconfig: Remove duplicate entry for `USE_OPTION_TABLE`
The following commit

    commit eb50c7d922
    Author: Edwin Beasant <edwin_beasant@virtensys.com>
    Date:   Tue Jul 6 21:05:04 2010 +0000

    Re-integrate "USE_OPTION_TABLE" code.

added a duplicate entry `config USE_OPTION_TABLE`. Remove it again.

Change-Id: I3ff64c360bad531439e74fa1b25a06c4a447a33f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3165
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-05-23 10:42:41 +02:00
Nico Huber 393619b9a6 intel/gm45: Add more debug output to read/write training
Add debug output for the timing values of the edges found during
read and write training.

Now, output for one DIMM of DDR3-1066 in a roda/rk9 looks like:

[...]
Lower bound for byte lane 0 on channel 0: 0.0
Upper bound for byte lane 0 on channel 0: 8.4
Final timings for byte lane 0 on channel 0: 4.2
Lower bound for byte lane 1 on channel 0: 0.0
Upper bound for byte lane 1 on channel 0: 10.2
Final timings for byte lane 1 on channel 0: 5.1
Lower bound for byte lane 2 on channel 0: 0.0
Upper bound for byte lane 2 on channel 0: 7.5
Final timings for byte lane 2 on channel 0: 3.6
Lower bound for byte lane 3 on channel 0: 0.0
Upper bound for byte lane 3 on channel 0: 11.4
Final timings for byte lane 3 on channel 0: 5.6
Lower bound for byte lane 4 on channel 0: 0.0
Upper bound for byte lane 4 on channel 0: 9.4
Final timings for byte lane 4 on channel 0: 4.6
Lower bound for byte lane 5 on channel 0: 0.0
Upper bound for byte lane 5 on channel 0: 11.2
Final timings for byte lane 5 on channel 0: 5.5
Lower bound for byte lane 6 on channel 0: 0.0
Upper bound for byte lane 6 on channel 0: 8.4
Final timings for byte lane 6 on channel 0: 4.2
Lower bound for byte lane 7 on channel 0: 0.0
Upper bound for byte lane 7 on channel 0: 10.4
Final timings for byte lane 7 on channel 0: 5.2
Lower bound for group 0 on channel 0: 1.7.5
Upper bound for group 0 on channel 0: 2.2.2
Final timings for group 0 on channel 0: 1.10.7
Lower bound for group 1 on channel 0: 1.6.1
Upper bound for group 1 on channel 0: 2.0.2
Final timings for group 1 on channel 0: 1.9.1
Lower bound for group 2 on channel 0: 2.0.7
Upper bound for group 2 on channel 0: 2.8.1
Final timings for group 2 on channel 0: 2.4.4
Lower bound for group 3 on channel 0: 2.4.7
Upper bound for group 3 on channel 0: 3.0.0
Final timings for group 3 on channel 0: 2.8.3
[...]

Final timings are always the average of the two bounds. The last dots
separate eights (not decimals) and the middles are elenvenths or twelfths
depending on the clock speed (twelfths in this case).

Change-Id: Idb7c84b514716c7265b94890c39b7225de7800dc
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 18:07:22 +02:00
Nico Huber 12276acfd7 intel/gm45: Handle overflows during DDR3 write training
We halted the machine on any overflow during the write training.
However, overflows during the search for a good to bad edge are
non-fatal, and should be ignored.

Change-Id: I45ccbabc214e208974039246d806b0d2ca2fdc03
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3256
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 18:05:34 +02:00
Nico Huber 08bee23f7e intel/gm45: Refactor DDR3 write training
Split some code in individual functions. It's the refactoring part of
a bigger change, following...

Change-Id: Id19be4588ad8984935040d9bcba4d7c5f2e1114f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3255
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 18:04:11 +02:00
Nico Huber 35e45c0780 intel/gm45: Handle overflows during DDR3 read training
We halted the machine on any overflow during the read training. However,
overflows during the search for a good to bad edge are non-fatal, and
should be ignored.

Change-Id: I77085840ade25bce955480689c84603334113d1f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3254
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 18:02:24 +02:00
Nico Huber 26a6435123 intel/gm45: Refactor DDR3 read training
Split some code in individual functions. It's the refactoring part of
a bigger change, following...

Change-Id: Ied551a011eaf22f6f8f6db0044de3634134f0b37
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3253
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 18:00:56 +02:00
Nico Huber 0da92863a7 intel/gm45: Fix interpretation of VT-d disable bit
When configuring the GTT size for the integrated graphics, the state
of VT-d was read wrong. Bit 48 of CAPID0 (D0F0) is set when VT-d is
_disabled_.

In the log of a VT-d enabled roda/rk9 we have now:

[...]
VT-d enabled
[...]
IGD decoded, subtracting 32M UMA and 4M GTT
[...]

Without this patch, only 2M GTT were reported.

Change-Id: I87582c18f4769c2a05be86936d865c0d1fb35966
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3252
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22 17:59:10 +02:00
Nico Huber 0f43af2ebb intel/i5000: Remove unused copy of udelay.c
It's a copy from i945 and looks like not beeing included in a
build at all.

If you should ever want to use that file for the Intel 5000,
please copy it from another chipset like the Intel 945 as it
is going to be improved.

Change-Id: I5c113bb0b2fed7b93feb3dcb1b5d962e1442963a
Reported-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3219
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-21 17:46:02 +02:00
Paul Menzel 883b03f323 AMD AGESA Hudson: Include `stdint.h` and `io.h` to fix build
Apparently the files `smbus.{h,c}`, where never used and therefore
build beforehand. Needing one function in them for the ASUS F2A85-M
the build fails as some headers are missing. Including the headers
`stdint.h` and `io.h` fixes the following errors.

    […]
        CC         southbridge/amd/agesa/hudson/smbus.romstage.o
    In file included from src/southbridge/amd/agesa/hudson/smbus.c:23:0:
    src/southbridge/amd/agesa/hudson/smbus.h:67:24: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:67:43: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:67:55: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:68:25: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:68:44: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:68:56: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:68:69: error: unknown type name 'u8'
    src/southbridge/amd/agesa/hudson/smbus.h:69:24: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:69:43: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:70:24: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:70:43: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:70:55: error: unknown type name 'u8'
    src/southbridge/amd/agesa/hudson/smbus.h:71:20: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:71:35: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:71:49: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:71:59: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:71:69: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:72:20: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:72:35: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:72:49: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:72:59: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:73:20: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:73:32: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:73:44: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.h:73:54: error: unknown type name 'u32'
    src/southbridge/amd/agesa/hudson/smbus.c: In function 'smbus_delay':
    src/southbridge/amd/agesa/hudson/smbus.c:27:2: error: implicit declaration of function 'outb' [-Werror=implicit-function-declaration]
    src/southbridge/amd/agesa/hudson/smbus.c:27:2: error: implicit declaration of function 'inb' [-Werror=implicit-function-declaration]
    […]

Probably all the (AMD(?)) `smbus.{h,c}` suffer from this and
should be fixed. Even better, as these function do not differ
between most boards, the file should be moved out from the
specific southbridge directories.

[1] http://qa.coreboot.org/job/coreboot-gerrit/6168/testReport/junit/(root)/board/i386_asus_f2a85_m/

Change-Id: I285101fa06a365da44fa27b688c536e614d57f50
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3202
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
2013-05-20 18:34:18 +02:00
Paul Menzel b2cddd4c12 ASUS F2A85-M: romstage.c: Set RAM voltage for non 1.5 Volt case
Currently the code in the if statement

    if (!byte)
    	do_smbus_write_byte(0xb20, 0x15, 0x3, byte);

only gets executed if `byte == 0x0`, that means only in the
default case where RAM voltage is 1.5 Volts. But the RAM voltage
should be changed when configured for the non-default case.

So negate the predicate to alter the RAM voltage for the
non-default cases.

To prevent the build error

    OBJCOPY    cbfs/fallback/coreboot_ram.elf
    coreboot-builds/asus_f2a85-m/generated/crt0.romstage.o: In function `cache_as_ram_main':
    /srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/mainboard/asus/f2a85-m/romstage.c:106: undefined reference to `do_smbus_write_byte'
    collect2: error: ld returned 1 exit status
    make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1

add `southbridge/amd/agesa/hudson/smbus.c` providing the function
`do_smbus_write_byte` to ROM stage in `Makefile.inc`. That can
actually be used after the needed header files are included in a
previous commit.

Change-Id: I89542479c4cf6d412614bcf4586ea98e097328d6
Reported-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3200
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-05-20 18:33:23 +02:00
Nico Huber 963bed546f Make: Use unaltered object list for dependency inclusion
It looks like the inclusion of dependency files was broken for all
ramstage objects since the list of those gets processed through the
ramstage-postprocess macro. Fix that by taking the unaltered list
for dependency files.

The output of `make printall` (look for DEPENDENCIES=) shows which
dependency files will be included.

See also:

    commit 79f9010e80
    Author: Patrick Georgi <patrick@georgi-clan.de>
    Date:   Sun Nov 25 14:31:08 2012 +0100

        build system: Add hook to postprocess classes (object lists)

and:

    commit f33e395213
    Author: Patrick Georgi <patrick@georgi-clan.de>
    Date:   Sun Nov 25 17:10:47 2012 +0100

        build system: Split linking into multiple steps

Change-Id: If93b1773c5d53240f98382aab11bf7f5a4649ee8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3258
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-05-20 10:28:25 +02:00
Stefan Reinauer b0fb2234be Drop llshell
This feature has not been used and was never fully integrated.
In the progress of cleaning up coreboot, let's drop it.

Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-20 08:42:28 +02:00
Bruce Griffith d433acb816 AMD Inagua: PlatformGnbPcie.c: Allocate exact needed size for buffer
The following commit

    commit 05f3b117dd
    Author: Paul Menzel <paulepanter@users.sourceforge.net>
    Date:   Tue May 14 09:28:26 2013 +0200

        AMD Inagua: PlatformGnbPcie.c: Allocate exact needed size for buffer

        Reviewed-on: http://review.coreboot.org/3246

changed one calculation for the size of the array PortList[] to
reflect only four elements, but neglected three additional calculations
of the size of the same table.

Correct that by setting the size for four array elements in all four
calculations.

[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c

Change-Id: Ib66b7b2b388d847888663e9eb6d1c8c9d50b9939
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3250
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-05-17 18:50:23 +02:00
Paul Menzel 05f3b117dd AMD Inagua: PlatformGnbPcie.c: Allocate exact needed size for buffer
The following commit

    commit d0790694b0
    Author: Kerry Sheh <shekairui@gmail.com>
    Date:   Thu Jan 19 13:18:37 2012 +0800

        Inagua: Inagua GNB ddi lanes and pcie lanes config update

        Reviewed-on: http://review.coreboot.org/544

assigns lanes 4 and 5 to PCI device number 4, but does not
adapt the rest of the code.

After the commit above, the array `PortList []` only has four
elements, but the buffer size `AllocHeapParams.RequestedBufferSize`
is set to a size as it still has five elements.

Correct that by setting the size for four array elements.

[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c

Change-Id: I3ff07f308ffd417d2bf73117eda9da2a1a05f199
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3246
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-16 06:06:50 +02:00
Aaron Durbin 5b54d353aa haswell: enable cache-as-ram migration
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.

cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.

Change-Id: I08998dca579c167699030e1e24ea0af8802c0758
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16 01:30:25 +02:00
Aaron Durbin 2ad6bd23a7 cbmem console: use cache-as-ram API and cleanup
Allow for automatic cache-as-ram migration for the cbmem
console. The code was refactored in the thought of making
it easier to read. The #ifdefs still exist, but they are no
longer sprinkled throughout the code. The cbmem_console_p
variable now exists globally in both romstage and ramstage.
However, the cbmem_console_p is referenced using the
cache-as-ram API. When cbmem is initialized the console
is automatically copied over by calling cbmemc_reinit()
through a callback.

Change-Id: I9f4a64e33c58b8b7318db27942e37c13804e6f2c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16 01:30:17 +02:00
Aaron Durbin 677e1558c3 chromeos: use cache-as-ram migration API for vbnv
It's possible that the vbnv global variables may be accessed
in romstage after cache-as-ram is torn down. Therefore use
the cache-as-ram migration API. Wrappers were written to
wrap the API to keep the existing code as close as possible.

Change-Id: Ia1d8932f98e00def0a44444a1ead0018a59d3d98
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3234
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16 01:30:09 +02:00
Aaron Durbin cb997d3710 pc80/tpm: allow for cache-as-ram migration
As the TPM driver can be accessed in romstage after
cache-as-ram is torn down use the cache-as-ram migration
API to dynamically determine the global variable address.

Change-Id: I149d7c130bc3677ed52282095670c07a76c34439
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3233
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16 01:29:59 +02:00
Aaron Durbin 716738a6b8 x86: add cache-as-ram migration option
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.

Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.

Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16 01:29:50 +02:00
Dave Frodin adc300d88b libpayload: Fix the logic for hardware-less serial consoles
This fixes the configuration where serial console output is
being sent to non-existant hardware to be captured with I/O
trapping. In this configuration where there isn't serial
hardware present we still want to init the consoles. We just
never want to read non-existant hardware.

Change-Id: Ic51dc574b9c0df3f6ed071086b0fb2119afedc44
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3249
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-15 16:56:33 +02:00
Ronald G. Minnich 4bd7b0cbad EXYNOS5250/SNOW: fix the build script. Add a script to get the bl1.
build-snow got broken when the snow makefile improved. So fix it.

While we're at it, create a script like the update-microcode
scripts that gets the bl1. I thought about making this a common
script but the various names and paths always evolve, leaving
me thinking it's not worth it. This script is just a
piece of the snow build script.

Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3238
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-05-14 22:03:07 +02:00
Paul Menzel 3a1457137e AMD Fam15tn boards: BiosCallOuts.c: Declare codec arrays as `static`
These arrays are declared as `static` for AMD SB800 based boards,
so do the same for this generation.

Rudolf Marek just changed `const CODEC_TBL_LIST` to `static const`
in [1]. Adapt all Fam15tn based boards (AMD Parmer, AMD Thatcher,
ASUS F2A85-M) to keep the differences between them small.

[1] http://review.coreboot.org/#/c/3170/3/src/mainboard/asus/f2a85-m/BiosCallOuts.c

Change-Id: I353b38bd8bc77ba500a4b7fe9250e9aa3071c530
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3198
Tested-by: build bot (Jenkins)
2013-05-14 15:58:34 +02:00
Rudolf Marek cd1cef4438 AMD Fam15tn boards: Document lane ID mapping from BKDG
To make it easier to fill in the values, place the table
from the BIOS and Kernel Developer’s Guide (BKDG) [1]
as a comment.

[1] http://www.coreboot.org/Datasheets#AMD_Fam15

Change-Id: I218f76e9fa2dc88d47af51ea6c062e315afb0000
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3221
Tested-by: build bot (Jenkins)
2013-05-14 15:53:14 +02:00
Aaron Durbin 38c326d041 x86: add thread support
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.

Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-14 05:24:18 +02:00
Aaron Durbin 4409a5eef6 coreboot: add thread cooperative multitasking
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c).  All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.

The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.

Note that the intention on when to yield a thread will be on
calls to udelay().

Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-14 05:18:47 +02:00
Paul Menzel 8c8af592ca AMD Brazos/Trinity boards: PlatformGnbPcie.c: Reserve correct amount of memory
In `PlatformGnbPcie.c` AGESA functions are used to reserve memory
space to save the PCIe configuration to. This is the

With the following definitions in `AGESA.h`

    $ more src/vendorcode/amd/agesa/f14/AGESA.h
    […]
    /// PCIe port descriptor
    typedef struct {
      IN       UINT32               Flags;                    /**< Descriptor flags
                                                               * @li @b Bit31 - last descriptor in complex
                                                               */
      IN       PCIe_ENGINE_DATA     EngineData;               ///< Engine data
      IN       PCIe_PORT_DATA       Port;                     ///< PCIe port specific configuration info
    } PCIe_PORT_DESCRIPTOR;

    /// DDI descriptor
    typedef struct {
      IN       UINT32               Flags;                    /**< Descriptor flags
                                                               * @li @b Bit31 - last descriptor in complex
                                                               */
      IN       PCIe_ENGINE_DATA     EngineData;               ///< Engine data
      IN       PCIe_DDI_DATA        Ddi;                      ///< DDI port specific configuration info
    } PCIe_DDI_DESCRIPTOR;

    /// PCIe Complex descriptor
    typedef struct {
      IN       UINT32               Flags;                    /**< Descriptor flags
                                                               * @li @b Bit31 - last descriptor in topology
                                                               */
      IN       UINT32               SocketId;                 ///< Socket Id
      IN       PCIe_PORT_DESCRIPTOR *PciePortList;            ///< Pointer to array of PCIe port descriptors or NULL (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
      IN       PCIe_DDI_DESCRIPTOR  *DdiLinkList;             ///< Pointer to array DDI link descriptors (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
      IN       VOID                 *Reserved;                ///< Reserved for future use
    } PCIe_COMPLEX_DESCRIPTOR;
    […]

memory has to be reserved for the `PCIe_COMPLEX_DESCRIPTOR` and,
as two struct members are pointers to arrays with elements of type
`PCIe_PORT_DESCRIPTOR` and `PCIe_DDI_DESCRIPTOR`, space for these
times the number of array elements have to be reserved:
a + b * 5 + c * 2.

      sizeof(PCIe_COMPLEX_DESCRIPTOR)
    + sizeof(PCIe_PORT_DESCRIPTOR) * 5
    + sizeof(PCIe_DDI_DESCRIPTOR) * 2;

But for whatever reason parentheses were put in there making this
calculation incorrect and reserving too much memory.

    (a + b * 5 + c) * 2

So, remove the parentheses to reserve the exact amount of memory
needed.

The ASRock E350M1 still boots with these changes. No changes were
observed as expected.

Rudolf Marek made this change as part of his patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1]. Factor this hunk out as it
affects all AMD Brazos and Trinity based boards.

[1] http://review.coreboot.org/#/c/3194/

Change-Id: I32e8c8a3dfc5e87eb119eb17719d612e57e0817a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-14 04:49:03 +02:00