The baskingridge has a non-zero alt_gp_smi_en value in the
devicetree.cb file. It has just to be determined which GPI
pins should trigger an SMI on basking ridge. Without this change
the board would hang during boot (presumably through a SMI flood).
No more hangs once the value is zero.
Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2673
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Grays Reef CRB is deprecated by order of Intel. Basking Ridge
is the new hotness. Therefore, rename graysreef to basking ridge.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I203497e165d8efc99d3438c4c548140a6e9cc649
Reviewed-on: http://review.coreboot.org/2672
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some of the Lynx Point ids were off. Correct those and make
the pei data BAR fields consistent with the others.
Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2622
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CS5536 companion device has three different power domains.
* working domain
* standby domain
* RTC domain
When the system is "off" only the standby domain is powered.
MFGPT[7:6] are member of the standby power domain.
MFGPT7 is used to control the backlight of the device and so the
timer gets used and configured during system boot. If the system
does a reboot the timer stays configured and the Linux driver
can not use it:
"ot200-backlight: ot200-backlight.0: MFGPT 7 not availale"
The cs5535-mfgpt has a function to hard-reset all MFGPTs but the
system hangs after the first access to a MFGPT register - cause
unknown.
/*
* This is a sledgehammer that resets all MFGPT timers. This is required by
* some broken BIOSes which leave the system in an unstable state
* (TinyBIOS 0.98, for example; fixed in 0.99). It's uncertain as to
* whether or not this secret MSR can be used to release individual timers.
* Jordan tells me that he and Mitch once played w/ it, but it's unclear
* what the results of that were (and they experienced some instability).
*/
static void reset_all_timers(void)
{
uint32_t val, dummy;
/* The following undocumented bit resets the MFGPT timers */
val = 0xFF; dummy = 0;
wrmsr(MSR_MFGPT_SETUP, val, dummy);
}
After playing around with this undocumented MSR it looks like I only
need to set bit 7 to free the MFGPT7.
BTW, all MFGPT[0:5] will be reset during pll_reset().
Change-Id: I54a8d479ce495b0fc2f54db766a8d793bbb5d704
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2527
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Even though this is under the graysreef board it really
applies to the Basking Ridge board. A subsequent patch will
rename graysreef to baskingridge.
The GPIO pins were updated to reflect the Basking Ridge schematics
as well as the DIMM spd addresses and USB over current pins.
Change-Id: Ice4e05f5203de3024cd463dfccf0bcfec1e247c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a FIXME about checking a MCHBAR register that isn't setup yet.
Also, remove revision updating because I can't find anything in the
docs that suggest this is required for haswell.
Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2631
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.
Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Grays Reef is one of Intel's CRBs for the Haswell processor. The
platform is named Shark Bay.
GPIOs were the main focus so IRQ routing and ACPI still needs to be
further looked at.
Change-Id: Ie94b7af66f772714992a92612c76ca93b9b27088
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2621
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change the OSC method to actually grant control of
PCIe capabilities to the OS instead of granting no
control. I believe the logic was backwards in the
original commit. Bits should be set when granting
control and cleared when not granting control. By
setting the return value to 0x00, we effectively
tell the OS that it cannot control any PCIe
capability. See section 6.2.9 of the ACPI spec
version 3.0 for more information.
This edit is a duplication of the OSC method that
is in the src/southbridge/intel/bd82x6x/pch.asl
file.
Change-Id: Id2462ab12203afceb9033f24d06b4dfbf2236d2e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2714
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().
Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since commit »Drop redundant CHIP_NAME in mainboard.c« (a93c3fe7) [1]
`CHIP_NAME` is unneeded for mainboards as the name is composed
automatically in `src/devices/root_device.c` from the strings in
Kconfig.
Unfortunately the ports for Google Butterfly, Link and Parrot as
as well as IEI PM-LX2-800-R10 introduced CHIP_NAME again. So drop
it again too.
[1] http://review.coreboot.org/1635
Change-Id: Ice7577a2a5c6070e196f2647c440b7a8e140e27e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2708
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.
There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.
(Credit to Gabe for spotting this)
Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Despite everywhere the model name M5A88-V is used, in Kconfig the
string M5A88PM-V is used. Searching for that model string on the
WWW does not return anything which is unrelated to coreboot, so
change that string to M5A88-V.
Change-Id: I25cf9d4a5fc3f9b9356e8616452066ebf873f44c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2613
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: QingPei Wang <wangqingpei@gmail.com>
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'
By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`. PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge. However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.
This change will apply to other AMD mainboards and
will be in a different commit.
Change-Id: I44f22bc03a0dcbcd2594d4291508826cc2146860
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2592
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Changes:
- Get rid of the inagua mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: Id05227fcf18c6ab94ffe1beb50b533ab7b0535db
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2607
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently for Advansus A785E-I, ASRock E350M1 and ASUS M5A88-V
despite what is chosen in Kconfig »Chipset« menu item,
$ more .config
[…]
# CONFIG_ENABLE_IDE_COMBINED_MODE is not set
CONFIG_IDE_COMBINED_MODE=0x1
# CONFIG_SB800_SATA_IDE is not set
CONFIG_SB800_SATA_AHCI=y
# CONFIG_SB800_SATA_RAID is not set
CONFIG_SB800_SATA_MODE=0x2
[…]
the SATA controller is put into IDE mode.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40)
Commit »sb800: Add sata ahci/raid mode kconfig option«
(d4a0e7d0) [1] added the options above to configure the mode
using Kconfig and some SB800 boards were adapted already. For
example commit »persimmon: sb800 sata mode configure update«
(1386fa74) [2] did so for AMD Persimmon.
Doing the same by assigning the Kconfig variable to the value in
`platform_cfg.h` integrates this with the three remaining boards
listed above.
The patch is successfully tested with the ASRock E350M1.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
[1] http://review.coreboot.org/225
[2] http://review.coreboot.org/227
Change-Id: I227257e2c8f04f18c27ff00fe62d42e372de67e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2610
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Replace »persimmon« by »board« in comment to keep `diff` output
between boards small.
Change-Id: Ieae2a63782c488ae35f22eb30f5b1049200d12c8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Changes:
- Get rid of the union_station mainboard specific code and
use the platform generic function wrapper that was added
in change http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I19d6b0d674b67294519383f80928471b37da1e14
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2609
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Changes:
- Get rid of the south_station mainboard specific code and
use the platform generic function wrapper that was added
in change http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: If4291d25ea81bf375f55b64c07c223a847a211d0
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2608
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is previously used exception code from libpayload.
On startup it installs and then tests an exception handler.
The test is an unaligned memory operation.
Yes, we've seen what might be exceptions in the ramstage, and
it makes sense to handle them. This code is identical in structure
and operation to the previously committed payload exception handler,
though we reserve the right to change it as circumstances require.
The remaining question is whether we need it in romstage.
Change-Id: I24484686c33c9757af8ba171ebae9773828fb69d
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2614
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
According to BKDG:
"Memory controller (MCT) and DRAM controllers (DCTs) additions:
• Support for 933 MHz (1866 MT/s) MEMCLK frequency."
Change-Id: I6f307ce3fcb355d5445f1ea86def73a41b928a57
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2589
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The Hudson-E1's default SPI speed for normal i.e. non-fast reads is 66 MHz,
but the SST 25VF032B datasheet allows max. 25. Lower the speed to 22 MHz,
otherwise BIOS flashing fails.
Change-Id: I22e87d833a3ebd316b6e873595a2480831533ab1
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2605
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Changes:
- Get rid of the persimmon mainboard specific code which has been
moved into the wrapper as a platform generic function in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I5f017dbb8dee5a09ec19734a6069ff9b71a6ab50
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2500
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds some real GPIO mappings where virtual GPIOs were used before.
Change-Id: I25d4be45f986c8d622b97151f8bdae2651baf3e6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2603
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Quoting Jens Rottmann [1]:
Nevertheless I still think this whole function is bogus for the E350M1. The
function assumes GPIO21 is wired to reset APU PCIe lane 0+1 (PCIe x8, port 4+5
as Coreboot/AGESA calls it), GPIO25 resets lane 2 (PCIe x4) and GPIO02 lane 3.
But the E350M1 has PCIe x16 i.e. probably APU lanes 0-3 bundled, completely
different layout. They could have chosen GPIO21 to force resets, or 25 - or
maybe 50 like on the Persimmon or any other they fancied or - and this is the
most probable - none at all. Having BiosGnbPcieSlotReset() toggle some GPIOs
without knowing what they do on the E350M1 (if anything at all) is nonsense.
In my opinion this whole function should just "return AGESA_UNSUPPORTED" and
good riddance.
[1] http://review.coreboot.org/#/c/2445/
Change-Id: Iac66da41182e838c7e6925250cc3982adbb3e4ec
Reported-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2489
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
These are essential functions for setting up the display port and
framebuffer, and also enable such things as aux channel
communications. We do some very simple initialization in romstage,
mainly set a GPIO so that the graphics is powering up, but the complex
parts are done in the ramstage. This mirrors the way in which graphics
is done in the x86 size.
I've added a first pass at a real device, and put it in the mainboard
Kconfig, hoping for corrections. Because startup is so complex,
depending on device type, I've created a 'displayport' device that
removes some of the complexity and makes the flow *much* clearer. You
can actually follow the flow by looking at the code, which is not true
on other implementations. Since display port is perhaps the main port
used on these chips, that's a reasonable compromise. All parameters of
importance are now in the device tree.
Change-Id: I56400ec9016ecb8716ec5a5dae41fdfbfff4817a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2570
Tested-by: build bot (Jenkins)
Since the merg of the ASRock E350M1 port (a649a96e) the compiler
warns about the following [1].
mainboard.c:35, GNU Compiler 4 (gcc), Priorität: Normal
no previous prototype for 'set_pcie_reset' [-Wmissing-prototypes]
mainboard.c:43, GNU Compiler 4 (gcc), Priorität: Normal
no previous prototype for 'set_pcie_dereset' [-Wmissing-prototypes]
Adding the function prototypes to the beginning of the file as
done in commit »Persimmon updates for AMD F14 rev C0« (d7a696d0)
addresses the warning.
[1] http://qa.coreboot.org/job/coreboot-gerrit/4975/warnings13Result/package.-139448264/file.-1544928473/
[2] http://review.coreboot.org/137
Change-Id: Iad2e62ec37c3a2f749a264974b61ac7c226e9b83
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2590
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Set up the clocks used for sound and turn on the sound clock.
Change-Id: Ic59bfa9ae87116299503e6d25aeefba98c842fb8
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2587
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The MMC0 on google/snow can run in 8 bit mode. To simplify driver development,
we thought disabling it (using zero, which runs in 1-bit / 4-bit mode) may help.
However, after some experiments in payload drivers, setting pinmux to 8 bit mode
can still allow MMC to run in 1-bit / 4-bit mode, so it's pretty safe to enable
8 bit mode by default for better performance.
Verified to boot on google/snow, and got MMC0 working.
Change-Id: Ic0acc723fe6a8aecf373429d3801beadd70815d9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2585
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The first reason for selecting the CPU model at compile time was a
multi-second pause if booting a single core Fusion T40R with MAX_CPUS=2.
Recent tests show the pause has disappeared, someone must have fixed it.
The second reason was me not knowing how to make a single vgabios image
work with two different PCI IDs. Many thanks to Martin Roth for educating
me! Quote:
"The way to make coreboot use the same vbios for different video device IDs
is through the map_oprom_vendev function. In family 14 it's in
northbridge/amd/agesa/family14/amdfam14_conf.c You would name your video
bios 1002,9802 in the config and all the other device/vendor IDs for the
family 14h processors will fall through the initial check for the video
bios and will get remapped to use that vbios. This only works if you're
initializing the vbios inside coreboot. I don't know if you're using
SeaBios as a payload, but if you are you can add the vbios to cbfs as
vgaroms/vbios.rom and the rom will always be initialized."
I'd like to add the vgabios is added as type 'optionrom' when Coreboot make
adds it, however to work with SeaBios it has to be added manually with
cbfstool and with type 'raw', or it will hang.
Change-Id: I8190d0c3202a60dfccb77dde232f9ba7ce5ce318
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2584
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit f154c018
Author: Marc Jones <marcj303@gmail.com>
Date: Wed Dec 14 11:24:00 2011 -0700
Persimmon audio codec verb patch.
Reviewed-on: http://review.coreboot.org/490
has a typo code*c* in the comments for `AZALIA_OEM_VERB_TABLE`. As
this was copied over to the LiPPERT Fam14 boards, use the following
command to fix the typo.
$ git grep -l cocec | xargs sed -i s,cocec,codec,
Change-Id: I1525b0445edab81ab136b3adece52b78ba7abc71
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2576
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
If you try to reset the system with outb(3,0x92), outb(4,0xcf9) or a
triple-fault it will instead crash with a messy screen. As the more common
outb(0xFE, 0x64) doesn't work with our setup, Linux will crash whenever you
ask it to reboot. Closer inspection shows that on a warm boot of Coreboot
agesawrapper_amdinitpost() always fails with error code 7. Looks like DDR3
re-init goes wrong somehow. I tried find the reason for this but was
unable to. I am convinced this is not board specific but a bug in AGESA.
In the end I had to settle for a workaround: if amdinitpost returns 7 this
patch resets the system harder with outb(0x06, 0x0cf9), after that RAM init
will succeed. As amdinitpost is early in POST this automatic reset is
quick enough not to be noticable.
I'd perfer a real fix, but that's all I have.
Change-Id: I4763254b489f42a135232e45328ecf0d5c4d961a
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2573
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 2: change the Persimmon code to adapt it to the new board's hardware.
The Toucan-AF is a COM Express Compact Type 6 form factor embedded board:
- AMD Fusion G-T56N (1.65 GHz dual core) or T40R (1 GHz single core) APU
- 1-4 GB DDR3 memory down
- 1x VGA, 2x DisplayPort (1 switchable to LVDS)
- AMD A55E (Hudson-E1) southbridge
- 8x USB 2.0
- 4x SATA
- HD Audio (with codec on baseboard)
- NEC uPD78F0532 microcontroller on I2C ("SEMA")
- 7x PCIe2.0 x1 (1 on PEG)
- Intel I210 GbE (on APU PCIe x1, can be disabled for additional PCIe)
- 2x SST 25VF032B (SO8, soldered) 4 MB SPI flash (BIOS and failsafe BIOS)
The Toucan-AF has no SIO on board. This patch includes basic support for a
Winbond W83627DHG (PS/2, 2x RS232), because the ADLINK ExpressBase-6 used
for evaluation happens to have one. The code may have to be adapted to the
actual baseboard of the application.
http://www.adlinktech.com/PD/web/PD_detail.php?pid=1132
Change-Id: I9041b905bad45852ac9b402fcbd5decbc98b377b
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2572
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 1: copy all files unmodified from Persimmon. This makes it much
easier later to see how the two boards actually and deliberately differ
when porting bugfixes from one to the other. Git's copy detection is
imperfect (and slow).
Change-Id: I1ff02913479c07679f8c3ae5e6dd7876e6000b55
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2571
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 1: copy all files unmodified from Persimmon. This makes it much
easier later to see how the two boards actually and deliberately differ
when porting bugfixes from one to the other. Git's copy detection is
imperfect (and slow).
Change-Id: I2fd1bf8428fc8a1e7becee888b6182b9bd8166a0
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2552
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The SD/MMC interface on Exynos 5250 must be first configured with, GPIO, and
pinmux settings before it can be detected and used in ramstage / payload.
Verified on armv7/snow and successfully boot into ramstage.
Change-Id: I26669eaaa212ab51ca72e8b7712970639a24e5c5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2561
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows to drop some special cases in romstage.c
Change-Id: I53fdfcd1bb6ec21a5280afa07a40e3f0cba11c5d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2551
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's not used, and not needed.
Change-Id: Ifca92f3606ac58fc26e09676488c3add5d84ae79
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add two more GPIOs (total 6) as needed by the Google Snow laptop.
These are faking out settings for now. This code is tested and working.
Change-Id: I2077ffb8b85958eefdf54e19763d57cc1178ce89
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2538
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Commit 8487229b (Persimmon doesn't have HDMI so the GNB HD Audio should be
disabled.) turned off the device in AGESA. Now remove it from
devicetree.cb, too. This prevents the following boot message:
PCI: Left over static devices:
PCI: 00:01.1
PCI: Check your devicetree.cb.
Also clarify the line's comment a bit for the Fam14 boards which still
retain this device (to counter the loss of information ;-).
Change-Id: Ib671ed2e0d04bdef2869e8d70208d6e55cdea3fd
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2537
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The PCH register bit definition for sleep type is a little confusing.
For example, 7 is S5. To make this simpler for the mainbaord developer,
the mainboard smi sleep hander is called as mainboard_sleep(slp_typ-2).
A couple mainboard SMI handlers were using the PCH define for slp_ty,
so S3 code would be run for S5 and S5 code would never be run.
Change-Id: Iaecf96bfd48cf00153600cd119760364fbdfc29e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2514
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mainly replace spaces by tabs and format comments correctly.
Commit »Inagua: Indent and wihtespace cleanup« (f03360f3) [1] was
unfortunately incomplete and also used spaces instead of tabs in
some cases.
Hopefully fix this once and for all to have a template for the
other boards.
[1] http://review.coreboot.org/547
Change-Id: If15c797581dfefe2a57cd6f26e5bdac4cdd014dd
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2526
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch reduces unnecessary differences between AMD Inagua, Persimmon,
Union Station, South Station and Asrock E350M1. It's only cosmetical, but
makes them a little bit easier to compare.
This is the remainder of the original http://review.coreboot.org/2464,
parts of which somehow got lost in a flurry of refactoring and splitting
patches.
Change-Id: I034228be9edaaa4122506763d7bb4158f8e0ec53
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2529
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Changes:
- Fix printk warnings for these two platforms by getting rid of the
l length specifier and casting to unsigned int.
This gets rid of a bunch of warnings like this one:
agesawrapper.c:279, GNU Compiler 4 (gcc), Priority: Normal
format '%lu' expects argument of type 'long unsigned int',
but argument 3 has type 'UINT32' [-Wformat]
Notes:
- This is the same change that was done for Tyan s8226 in change:
ddff32eb - http://review.coreboot.org/#/c/2451/
Tyan S8226: Fix printk warnings
- I have not tested this change on either of these platforms, I have
just compiled it.
Change-Id: I46b4c13fde7473cd2a084c7c7cb5c893f1731b02
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes:
- Add #include of delay.h in mainboard.c to pick up declaration of
mdelay function.
Notes:
- This fixes this warning:
mainboard.c:69, GNU Compiler 4 (gcc), Priority: Normal
implicit declaration of function 'mdelay' [-Wimplicit-function-declaration]
Change-Id: I72f333cd87215a7fc1e62d1d7ee4b2395444b03e
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2501
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
