Windows 7 cannot find HDMI audio device because of acpi setting.
I have tested on Windows 7. I can play music.
Change-Id: I53177ce00b676824a903a3397d69338e8c1a38af
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3936
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Northbridge code includes these headers, so they all need to
have the same name to allow different combinations of northbridge
and southbridge. This changes the sb900 names to match sb700 &
sb800, and points agesa/family12 and amd/torpedo to the new file
names.
Change-Id: I7a654ce9ae591a636a56177f64fb8cb953b4b04f
Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
Reviewed-on: http://review.coreboot.org/3825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If romstage does not make cbmem_initialize() call, linker should
optimize the code for CAR migration away.
This simplifies design of CBMEM console by a considerable amount.
As console buffer is now migrated within cbmem_initialize() call there
is no longer need for cbmemc_reinit() call made at end of romstage.
Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3916
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Assume EARLY_CBMEM_INIT=y everywhere and remove option from Kconfig.
If romstage does not make the cbmem_initialize() call, features like
COLLECT_TIMESTAMPS and early CBMEM_CONSOLE will execute during
romstage, but that data will get lost as no CAR migration is
executed.
Change-Id: I5615645ed0f5fd78fbc372cf5c3da71a3134dd85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3917
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This retrieves back the value stored with store_initial_timestamp()
in the bootblock for southbridge.
Change-Id: I377c823706c33ed65af023d20d2e4323edd31199
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3908
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Assign the lanes correctly to the physical slots
on the motherboard in `PlatformGnbPcie.c`.
• UMI is connected to SB via 4x PCIe bridge 8.
• The blue x16 slot is not shared with DDI and is routed
through PCIe bridge 2.
• The black x8 slot is in fact a x4 slot and uses all 4 GPPs
from the CPU.
• Assume that DDI is on out-of-PCIe-band lanes.
Change-Id: I44c4c83e6a8e31d6150a602a0993972ac63105bd
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3194
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Without this coreboot may (depends on the amount of memory) place the
pci bars below 0xb0000000, then the linux kernel goes move them around
so they are inside the window declared in the acpi tables.
This breaks vesafb as the vga framebuffer gets moved after vgabios
initialization. It's also not exactly nice to expect the OS fix our
mess ;)
Change-Id: If6b50ea863958eea71b567ccb7a06c6a28076111
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3927
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.
Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The console has already been initialized in the generic bootblock code, and
reinitializing it causes the same banner line to be printed twice and lots of
artifacts in the actual output. This same change had been made to the other
ARM boards but not for beaglebone.
Change-Id: I72e3be1326b1a52b7ec438a44e4fd5f87e4ec717
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3924
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>
Function is always called with get_top_of_ram() - HIGH_MEMORY_SIZE
which equals cbmem_base, thus no need to pass it as a parameter.
Change-Id: If026cb567ff534716cd9200cdffa08b21ac0c162
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3564
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This helper function is for compatibility only for chipsets that do
not implement get_top_of_ram() to support early CBMEM.
Also remove references to globals high_tables_base and _size under
arch/ and from two ARMv7 boards.
Change-Id: I17eee30635a0368b2ada06e0698425c5ef0ecc53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3902
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Use the new helper function set_top_of_ram() to remove remaining
uses of high_tables_base and _size under northbridge/.
Change-Id: I6b0d9615002ed2aff578c5811d7bd43dd2594453
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3561
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
A late for loop may reference over the current array allocation
and corrupt an unrelated global variable. As a quick fix bumb the
size of the array allocation uniformly to 6.
Change-Id: Ib067fdf077e091d13e32cc3a8e4a0b713d19bcc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Two new nvram variables control disabling the two non-ME NICs
on the mainboard. This is implemented by disabling their PCIe bridge.
Change-Id: I086f0d79de3ad0b53fa0ec40648d63378070e3bd
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3870
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Collect early timestamps in Lenovo X60’s romstage.
Selecting the option `COLLECT_TIMESTAMPS` in Kconfig and then
doing `cbmem --timestamps` should output the timestamps.
Change-Id: I7bd30f03a1b85c38e89c19cdf88b2d20b24abed8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3587
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The northbridge defines it already and to the same value.
Change-Id: Ia5d856258fac52ea0b249142f70a89123ca04f82
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3876
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested on Ubuntu 12.10. S3 is supported. No HD Audio.
Mainboard details: http://www.asrock.com/ipc/overview.asp?Model=IMB-A180
Change-Id: I75254194ab5da8e5c61383d8f85aa4e300815637
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3880
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
It still pointed to the old binary despite implementing the newer interface
Change-Id: Iebd5dae98168f5568f3ad6a18c5ebde9abc3ece0
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3869
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Drop unused and commented out variable, and fix a comment while at it.
Change-Id: I1bd7d10aca949c8579433ea1c91264fd816a3fb4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3873
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The slightly hackish ioapic ressource reservation is needed for i440fx
emulation only, for q35 the ich9 southbridge driver handles this just
fine.
[ Side note: The i440fx chipset emulated by qemu is pimped up with alot
of stuff which never existed on real hardware, which leads
to tweaks like this one. ]
Change-Id: I06bf54cbc247ccf17aa9063fb7dee9def323c605
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3850
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The board name in that variable name is not necessary, as it is not board
dependent, that means using the file as a template for making a new
coreboot port for another motherboard the variable does not need to be
changed, and just increases the code differences between AMD Parmer,
AMD Thather and ASUS F2A85-M. So use a generic name.
The same was done for AMD Persimmon (and inherited by the LiPPERT
FrontRunner/Toucan-AF) in the following commit.
commit 5e70766f14
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Tue Feb 26 15:56:11 2013 +0100
AMD Fam14 boards: reduce unnecessary differences, 2nd attempt
Reviewed-on: http://review.coreboot.org/2529
The board name is *not* removed from the `CODEC_ENTRY` variable name as
the verb table not only depends on the codec but also on the board [1].
Having the board name in the variable name is a good indicator that the
pin configuration needs to be adapted when taking this file as a template
for a new port. If it was board independent, a default chip configuration
could be used and shared between all boards, which is unfortunately not
the case.
[1] Unfortunately I was not able to find Jens’ comment in my mail archive
and in the Gerrit Web interface. Not sure where it is, but I am sure
he made that comment.
Change-Id: I440a306cf4ff0a5b1b61d1983d70c66d129904d0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3199
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The ThinkPad keyboard controller sometimes needs a while in order
to initialize, so let's ask SeaBIOS to wait for it.
This change ensures that the internal keyboard always functions
correctly on the ThinkPad when coreboot is built with SeaBIOS as
payload.
Change-Id: I562475ec98b0c1f5d0debf6e9b597748a420f068
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3735
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
QEMU has a bunch of non-standard virtual devices on various I/O ports.
Allocate resources for them so the coreboot resource management knows
those ports are used.
Change-Id: I51a85967cf2dcd634b0c883210bb52c0c34c8283
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Split the Family16 (Kabini) DSDT file into logical regions.
Olive Hill is the only mainboard and Kabini is the only NB/CPU
currently using Family16 AGESA code.
Change-Id: I9ef9a7245d14c59f664fc768d0ffa92ef5db7484
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3821
Tested-by: build bot (Jenkins)
Hook this up into the DMP Vortex86EX. Before under Windows XP
the microphone did not work. With the new logic it does. Now
line-in,line-out and microphone all work.
The verb data table is generated by Realtek.
Change-Id: I1bcef898a15547c86c12c4b52ce0069d13e23c84
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3855
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I58c4b021ac87a035ac2ec2b6b110b75e6d263ab4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3810
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Rearranged the F2A85-M DSDT file to match the functionality found
on Parmer. As with the Parmer implementation, the F2A85-M dsdt.asl
file in the mainboard directory contains only #include references to
the appropriate files.
As with Parmer, some include files have no content but are left as a
template for other platforms and as placeholders for completing the
ACPI implementation for F2A85-M.
Change-Id: Ic72cb6004538ca9d9f79826b9b3c8d6aeb25017c
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/3805
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Rearranged the Thatcher DSDT file to match the functionality found
on Parmer. As with the Parmer implementation, the Thatcher dsdt.asl
file in the mainboard directory contains only #include references to
the appropriate files.
As with Parmer, some include files have no content but are left as a
template for other platforms and as placeholders for completing the
ACPI implementation for Thatcher.
Change-Id: Ie44a32959cc547840914365e872416d4624d33df
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/3804
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Change-Id: I7f6f6ff444fda4bdf233db1383919772afe6b635
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3815
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Olive Hill does not have a Super I/O or keyboard controller.
Change-Id: I8c1e5d8c20c4a964fe8d98df920b416382a26d9d
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3848
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
The VBIOS device ID is set by processor family using the
map_oprom_vendev() function in the northbridge code. There
is rarely a reason why this should be overridden by the mainboard.
Since Kabini includes a default VBIOS vendor/device ID in the
northbridge Kconfig code, remove the setting from the Olive Hill
mainboard settings.
Change-Id: Icd69155f5b51105d564dd82c89e4bb54a6118a82
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3816
Tested-by: build bot (Jenkins)
Change-Id: Ifc180e6fcd594dbedc2512ea5bef283a3ad689d3
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3814
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Eliminate an unnecessary copy of the DDI descriptor list and
the PCIe port descriptor list. As descriptor tables, these
tables do not need dynamic updating and should be used from
ROM without runtime copying.
There will be a corresponding patch for AGESA that adds CONST
modifiers to function parameters that are pass-by-reference
"IN" values (read-only pointers).
Change-Id: I7ab78e58041e9247db22d0f97a6f76d45f338db0
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3818
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The Kconfig variable EXTERNAL_MRC_BLOB is not used.
Drop it.
Change-Id: I3caa5c2b6bcf5d2c13b6987da8ab3987bad0e506
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3829
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Removed the execute bit on all files in mainboard/amd/parmer/acpi
Change-Id: I85ffa66e0beb9c4bfe826b72968f7f633c224487
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/3807
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change all PCI configuration accesses to MMIO in qemu-q35
emulation
To enable MMIO style access, add (move) explicit PCI IO config write
in the bootblock. As there is no northbridge/x/x/bootblock.c
file, a mainboard/x/x/bootblock.c file is added for this purpose.
Change-Id: I979efb3d9b2f359a9ccbd1b4f6c05f83bab43007
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3599
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: If1fa39db79eeecbef90c8695143d2fe2adf2f21a
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3732
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The Linux thinkpad_acpi.c driver looks for this string while
reading information about the system it is running on.
This commit does not make the module load but it is one of
several things that the module looks for on a ThinkPad.
The use of 3 defines for the serial number template
seems odd but it's done in a way that eliminates
magic numbers, yet avoids use of strcpy, strlen,
strindex, strchr, or strspan: we can have some
correctness assured at compile time. Also, the
defines can be copy/pasted for other mainboards
and we should void errors due to people not changing
magic numbers.
Change-Id: Ief5f28d2e27bf959cb579c4c8eea9eecc9a89a7c
Signed-off-by: Peter Stuge <peter@stuge.se>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CBFS_ROM_OFFSET was declared in both the am335x config and the beaglebone
config. This removes it from the beaglebone config.
Change-Id: I657cb8e83a1ee961d8bdc995a41f303920bc53f9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3771
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Split the Parmer, Family 15tn, and Hudson DSDT into groups. This splits
the DSDT table into includable ASL files which carry details specific
to the Family 15tn APU, the Parmer platform, and the Hudson FCH. The
dsdt.asl file in the mainboard directory contains only #include
references to the appropriate files.
Initially, this split was done by moving each piece of functionality
into its own file (e.g. IRQ routing and mapping, processor tree, sleep
states and sleep methods, etc.) and those pieces were #included in
dsdt.asl to ensure an exact match (via acpidump/acpixtract/iasl -d)
with the extant version of the table. Once the new tables were found
to exactly match the existing tables, the pieces were rearranged into
reasonable groups (e.g. fch.asl, northbridge.asl, pci_int.asl, etc.).
Some include files have no content but are left as a template for
other platforms and as placeholders for completing the ACPI
implementation for Parmer (e.g. thermal.asl, superio.asl, ide.asl,
sata.asl, etc.).
Change-Id: I098b0c5ca27629da9bc1cff1e6ba9fa6703e2710
Signed-off-by: Steve Goodrich <steve.goodrich@se-eng.com>
Reviewed-on: http://review.coreboot.org/3629
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The placeholder code in beaglebone's romstage.c didn't do anything, it just
immediately tried to load the RAM stage and jump into it. That doesn't
currently work, and there's no indication whether you actually successfully
got into the ROM stage or not.
This change adds a few lines which initialize the console and say "Hi" so that
we can tell that the ROM stage is running.
Change-Id: I45a0908c3ac65b21e0e5020428696d2e54933d0e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3581
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vendor and part name from coreboot is normally stored in these
SMBIOS structure fields, but it can be useful to override them.
On Lenovo ThinkPads an override is e.g. needed to convince the Linux
thinkpad_acpi.c driver that it is actually running on a ThinkPad.
Change-Id: I0dfe38b9f6f99b3376f1547412ecc97c2f7aff2b
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/1556
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This is needed for the Linux thinkpad_acpi.c driver to load.
Change-Id: I3d9549395556ffb0abfc3cb52b3d01386c34caa5
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3731
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
mainboard_enable() is now modelled after google/parrot where the
enable function only sets dev->ops->init for the root device to
point to a mainboard_init() function, which in turn is called in a
later pass over the device tree to do the actual initialization.
Change-Id: Iaf9187532a1e432b991260201b95dda85cc312c5
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PCI bus operations are static through the ramstage, and should be
initialized from the very beginning. For all the replaced instances,
there is no MMCONF_SUPPORT nor MMCONF_SUPPORT_DEFAULT selected for
the northbridge, so these continue to use PCI IO config access.
Change-Id: I658abd4a02aa70ad4c9273568eb5560c6e572fb1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The display port bridge on pit is different from the one on snow and needs to
be initialized differently. Instead of waiting for the chip to come up on its
own and assert the hotplug detect, we need to access it over i2c and get it up
and running ourselves.
Change-Id: I4bc911cb8e4463edff7beabd2f356cb70ae9f507
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3723
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was removed from ramstage a little while ago and should have been removed
from here as well.
Change-Id: I6a40ed4a98bedac39e5492e4b1aed3427ab4e08b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3720
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This appears to be needed, though we have no way to test yet.
Change-Id: I39033581011e056258193f2cdff78814361a8d55
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3719
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In resume path, if memory setup takes too long without setting PS_HOLD, EC watch
dog may power off or reboot the system. To prevent that, we should enable
PS_HOLD in same timing as cold boot - right before starting memory setup.
Change-Id: I5c294fa7ae015f8cff57b1fd81e5b80902647b15
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3718
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The functions which manipulated the tps65090 were removed a while ago because
it isn't accessible directly from the AP, it's on an I2C bus that has to be
accessed by the EC on our behalf. Now that that capability has been added, we
can rewrite the small portion of the the tps65090 we actually used but using
the EC passthrough commands.
Also, we should not be configuring the hardware display port hotplug detect
line since we're using it as a GPIO for other purposes. The GPIO we're using
instead defaults to being an input, but to be safe we should probably
explicitly configure it as one anyway.
Change-Id: I7f8a8a767e3cccb813513940a5feceea482982f5
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ChromeOS EC for peach_pit is connected to SPI2 bus, not I2C.
Change-Id: Ifeb8a626aa4fc3d3a181a7bc016e3f91be948ae5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3716
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Embedded Controller (EC) for Pit is connected via SPI2, and needs to be
configured before we can talk to it.
Change-Id: I1f8e921b4616f15951f3e5fae1ecbf116de4ba90
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3707
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I4feabc448945c4664d3114c0c8afdad48338230a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3705
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... this is needed for libpayload to talk to USB devices.
(forward ported from https://gerrit.chromium.org/gerrit/#/c/55554)
Change-Id: I5a20864689efd0c0149775e6d85b658e0cc6715c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3697
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... this is needed for libpayload to talk to USB devices.
Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
Change-Id: I06ba773da3af249efec723bb90c2e9e8075a777a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
Change-Id: I270bbfd3aff781d88304791b1d9735777643caab
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That part isn't used on pit.
Change-Id: I48f3a10f7e6eb89b1e9630d2372b6865b4c12a7f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3687
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
Change-Id: I7218f85f9f26623bd13aaaf8ded0638b3b2f874a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
Change-Id: I9c6f21f183dacc0bca71277e681e670834412d78
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3680
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested and working. Gets us to ramstage.
Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
Change-Id: I2152ab760e31a335dbcd9d6ad32cd1eaae4b89bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3670
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
Change-Id: Ie349f2a4117883302b743027ed13cc9705b804f8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new code is stolen from U-Boot with little or no understanding of how it
works.
Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Coreboot knows that, for the snow board, certain pins are to be connected to
bus controllers in the SOC and to the wires of a bus external to the SOC. It
can configure them as such and free its payload from having to know how to
set everything up.
Change-Id: I1bb127c810e9ee077afc4227a6f316eaa53d6498
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3650
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change adds a pit mainboard which is mostly a copy of snow, except that
mentions of the 5250 were replaced with the 5420, and mentions of snow were
replaced with pit.
Change-Id: I8eb0ce379eb2fa353bb88d5656a0c5e2290afbf0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In ram stage, all code flow should be tied to the resource allocator.
Stuff that has to happen before everything else goes into the mainboard
enable function in mainboard.c. This patch empties the main() wrapper
around hardwaremain.c, allowing to get rid of this special case in the
ARM port.
Change-Id: Ide91a23f1043b64acf64471f180a2297f0f40d97
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3638
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: I07512b3695fea0b22949074b467986420783d62a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3637
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This code is the initial version of FUI for haswell and wtm2.
The code is simplified from before in many ways. I've gotten rid of
the opcode table, because it obscured meaning and I don't think it is
needed any more. Register sets, mainly used for reset, are just lines
of code -- not many of them. There are a bunch of not-yet-documented
registers here; the VBIOS seemed to think they were necessary and
testing shows they seem to be right.
As a bit of added paranoia, we always include the VBIOS code as our
emergency recovery path. You have to run it now anyways, so this is no
regression from our current situation; and, if all goes well, in a
week (or so), you'll never have to run it again, but like the Force
and nose hair, it will be with you always.
The code can return in three ways. The first, best way is success:
panel is up and the VBIOS need not run. The second mode is that we
tried to light up the panel but could not, for some reason, but will
return with the panel partly up. In this case, it's ok not to power
cycle the panel. The third, worst case, which will NEVER happen, ha
ha, is that we have to turn the panel off and wait the required 600ms
for it to cycle. Life sucks sometimes. This failure mode is in the
'hang on we're going to fix it' category now that we have ramstage in
RW.
The Big Goal here is to create something other coreboot ports can use
as well. The guys doing the x60 report that the link FUI works,
without too many mods, on that chipset, so it seems Intel is keeping
things from changing too much over time.
Also, again, please note: this and the next 3 versions will ALWAYS fail.
The goal is to verify the correctness of the recovery path.
The bizarre tab-space formatting in drm_dp_helper.h is from the original,
as in i915_reg.h
Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3635
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This lights up the display. We don't get graphics but we are missing the gttsetup
at this point, so that is no shock. The real shock is that anything works at all.
Change-Id: I03fc470334e96878aeb8465044b3cc9c90378735
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3634
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change all PCI configuration accesses to MMIO on two boards
with i5000 chipset. To enable MMIO style access, add explicit
PCI IO config write in the bootblock.
Change-Id: I26f1c2da5ae98aeeda78bdcae0fb1e8c711a3586
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I missed the board with gm45 when I moved MMCONF_SUPPORT lines.
Also, the intel/i3100 does not have MMCONF_SUPPORT implemented
even though it was previously selected for intel/eagleheights board.
Change-Id: I9c7f6b0a150b4d54288a1e015277b9d98467fca4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3598
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change all PCI configuration accesses to MMIO on all boards
with SandyBridge and IvyBridge. To enable MMIO style access,
add explicit PCI IO config write in the bootblock.
Change-Id: I8f957a80bf57df000897c5a080dd5ff131b1ec0d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3576
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Move/remove MMCONF_SUPPORT reference under mainboard Kconfig, as
that feature originates from northbridge and cannot be disabled
for a single mainboard.
Change-Id: I6d6861079876ddddaff90b10f18edb6936e93bd0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3589
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Set up the pinmux to enable the pins and the clocks for whichever UART is
currently configured.
Change-Id: Iac13f16d9d84320555b99734ea83eafd0a2803fe
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3573
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Thanks to Bruce's great work, we can finally drop this workaround.
Change-Id: Ie92d1e53ef867fa34aa2489ccfb682d73195b213
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3569
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Users of mptable_write_buses() pass two pass-by-reference
parameters reflecting a maximum bus number and a search bus
number. These bus numbers are expected to be held in "int"
variables and are updated by the function. Both of the
Supermicro boards define the search bus number as a
byte value in mptable.c.
For now, change the two Supermicro boards to use "int"
to hold the search bus index.
Change-Id: Ie71850719c1fa3cda0ac9c8773bb80650de95c70
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3546
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix a bunch of compiler-generated warning messages. These fixes are
mainly braces for grouping initializers. These changes are not
intended to change any code functionality. There are two changes where
function prototypes are added, and two cases where unused variables are
eliminated.
Change-Id: I93cef8899170b5575e7fb7c55181b381a7bcd9d8
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3545
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing code for setting Azalia configuration assumes that
the configuration bits are contiguous within a single byte and
can be set using a byte copy addressed into the lowest 2-bit
subfield.
The fix in Family 14 defines a union that can be addressed as a
byte to overlay the bit fields. Since the offset of the four
subfields is not necessarily fixed, change the code to initialize
each of the four subfields individually.
Change-Id: I1dff20bb8bd3e1bcd8b4e6b0537e20779d2a3521
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3544
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Copy a type cast from the other cases of the same switch statement
to eliminate compiler warning messages.
Change-Id: I8d0a88892f6a5f8e43227ab5f830041894b07f6a
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3543
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On Dinar, H8SCM, and H8QGI, add <cpu/amd/amdfam15.h> as an
include to pick up the prototype definition of get_bus_conf().
Change-Id: Ie4887670ac52aa194745881362df19cd1d75773e
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3542
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This requires a new system agent binary (v6 / v11 on haswell).
Note that the existing system agent binaries are long time obsolete
and won't work with current coreboot, so this update is overdue.
Change-Id: I48d8649576ca84d2b85ab082ce06f3462e189059
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3568
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
BIOS write protects 8 bytes of CMOS, which nvramtool can't cope with.
This makes initial installation harder, so just mark those as reserved
to work around the issue.
Change-Id: I210861dff8572e226a0f250556a3b811671ea8f2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3531
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For iwave/iWRainbowG6 using intel/sch, MMCONF_BASE_ADDRESS was unused
and different from hardware setting. Change that to match hardware
programming.
Change-Id: I3324b7ea0e6f092206d4b6b791476d538e826657
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3507
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There are no files to build left under AMD nortbridge/x/root_complex
directories. For some cases, even the Kconfig file was no longer sourced.
Remove all such references and empty files.
For devicetree.cb treat component paths with "/root_complex" in them valid
even when the directory does not exists. This is because AMD boards us this
dummy chip component as the root node in their devicetree.cb.
The generated devicetree file static.c remains unchanged.
Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3434
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The IOMMU needs IRQs assigned. So add those.
Change-Id: Ic9f02e28aac593cddf7d222a8abb780a10572d32
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3318
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In commit Rudolf Marek discovered, that it is not uniformly written. As
»ASL names are not case-sensitive and will be converted to upper case.« [2]
this change does not have any functional change.
The following command was used to create this patch.
$ git grep -l 'package()' src/mainboard | xargs sed -i 's,package(),Package(),'
[1] http://review.coreboot.org/#/c/3318/
[2] http://www.acpi.info/spec40a.htm
(18.2.1 ASL Names)
Change-Id: I1784dbc50936a1ef9d4376209a3c324ef1fb85cf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3516
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This commit was tested on qemu with and without CONFIG_DYNAMIC_CBMEM
by running cmbmem -c once booted. The qemu command that was used was:
qemu-system-i386 -bios ./build/coreboot.rom -serial stdio -hda ../virt/parabola.img
Note that using CONFIG_RELOCATABLE_RAMSTAGE make it fails like that:
Loading image.
CBFS: Decompressing stage fallback/coreboot_ram @ 0x3ffbefc0 (184400 bytes)
Loading module at 3ffbf000 with entry 3ffbf000. filesize: 0x18db8 memsize: 0x2c050
Processing 1703 relocs with adjust value of 0x3ffbe000
FATAL: Essential component is missing.
However without CONFIG_RELOCATABLE_RAMSTAGE set it boots fine.
Change-Id: I633a8c3832eee4e8bed244940fdc370b98dd26f0
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3504
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Collect early timestamps in T60's romstage like some newer boards do.
This should also work on X60s (and other ICH7 based systems with
EARLY_CBMEM_INIT).
Change-Id: I3b2872dd7423f3379ff3b68ad999523ec35fc08e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3499
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
Add support for the new q35 chipset emulation
added in qemu 1.4.
Change-Id: Iabfaa1310dc7b54c9d224635addebdfafe1fbfaf
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3430
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
So the pci allocation code knows where memory is and doesn't
try map pci devices there. We also don't have to check for
overlaps between pci hole and memory then.
Change-Id: I5eaea0e4d21210719685860fa1f16ca7b2137cde
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3491
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Prepare tree for adding q35 support:
Move emulation/qemu-x86 to emulation/qemu-i440fx.
Rename some stuff to include 'i440fx'.
Change-Id: Ib8c58175c5734cfcda1b22404ef52c09d38f0462
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3429
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This issue can be reproduced in Linux by the following steps:
1) use pm-suspend to suspend.
2) use USB keyboard to wake up.
3) use pm-suspend to suspend. FAIL To SUSPEND.
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
In this patch, I add AcpiGpe0Blk using MMIO access and write 1
on bit 11. Write 1 to clear as spec says.
I have tested on Thatcher
The same change was done for AMD Parmer in commit »AMD Parmer:
fix issue 'S3 fails to suspend after wake up from USB keyboard'
(03901124) [1].
[1] http://review.coreboot.org/#/c/3347/
(Change-Id: Iec3078bf29de99683e7cd3ef4e178fbeb4dc09c1)
Change-Id: Iaef39237497ef896d0f186e8f5522222c0ce6cb7
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3374
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This ancient board with Intel e7505 invalidates cache while it does HW
scrubbing for ECC in romstage. This breaks usbdebug console and prevents
system from booting.
If both EARLY_CONSOLE and USBDEBUG are selected, skip ECC scrubbing under
these rare conditions to boot system.
Change-Id: I6cb43bf69af54119f4a582dcaf498dd941d4c62d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3385
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that the ROM size is decoupled from the size of the on chip RAM,
it's size is now only constrained by the size of the medium it's loaded
from and the memory it's being loaded into, probably GBs in both cases.
Making it 4MB is a reasonable compromise between giving the payload lots
of breathing room and wasting space on the source medium which won't be
used.
Change-Id: I80932e0d4ce2dad02c3879345382e7d6ba44503a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3422
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Until we get serial working, this is a good way to show that coreboot is
running. It can be removed once we have better methods.
Change-Id: I62d25e52aa88a97aba4c959538d680b67a0bbbb2
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EPIA-M850 can now boot linux. For a list of issues, see:
http://www.coreboot.org/VIA_EPIA-M850
That's all folks.
Change-Id: I7624944dbc05fbf3019897a116954d71dfda0031
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1228
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Keep in mind that we can _NOT_ read back the current state
of the LEDS as some crazy FPGA designer wanted it that way.
Change-Id: I5cd1ac598072318b3234d1ec35a79271655b46ac
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3271
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Without that commit, with CONFIG_PCI_OPTION_ROM_RUN_YABEL,
The VGA option rom doesn't init the right display:
it initializes the external display, where we have
a black scren(with backlight on).
This commit is based on the code of mainboard.c in
src/mainboard/roda/rk886ex.
Change-Id: I8457aaf0503e0efdf0fcba9ff5e8a07ac04c5ca6
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3265
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
First copy over from SeaBIOS git repo, then adapt for coreboot:
Disable cpu/pci hotplug bits. Disable dynamic pci window.
Both depend on stuff in the SSDT tables created by SeaBIOS.
Bits are left in, but deactivated via #if 0, so it's easier
to see the differences when diffing the coreboot tables with
the SeaBIOS tables.
Adapt dsdt DefinitionBlock.
Enable acpi table generation in acpi_tables.c.
With this patch linux boots successfully with ACPI enabled.
It's not bug-free though. Missing cpu detection leads to
funky messages like this one:
weird, boot CPU (#0) not listed by the BIOS.
and SMP most likely wouldn't work either.
Change-Id: Ic3803a6f1ef6d54c11cc4ca3844d3032a374ae6b
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3342
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The DDI connector table and the PCIe Port List lookup table are
copied onto HEAP. This copy is not needed since these are lookup
tables used to define the platform configuration.
Change-Id: If4760f80e08faa8da4fd11337a3812f89cf805f9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add boot cpu to the device tree. Figure the number of CPUs installed
(using the qemu firmware config interface) and add cpu devices for them,
so they show up in all generated BIOS tables correctly. This gets SMP
going.
Change-Id: I0e99f98942d8ca90150b27fc13c1c7e926a1a644
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Needed to make 'register "gpo" = ...' work.
While being at it add comments saying which device is which.
Change-Id: I911d5e4a7b6c7abf4ad73e863ab201e9e55ee0d4
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3346
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
qemu has a special device to pass configuration information
from qemu to the firmware. This patch adds initial support
the interface, namely some infrastructure, detection code and
a function to query the number of CPUs.
Change-Id: I43ff5f4fbf12334a91422aa38f514a82a1d5219e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit eed28f97b3.
For whatever reason, the dependencies were lost in Gerrit and the
commit [1] was submitted without its dependencies. As a result
buidling the ASUS F2A85-M fails now [2] and therefore commits
based on this commit fail to pass the buid tests by Jenkins.
[…]
Created CBFS image (capacity = 8387656 bytes)
LINK cbfs/fallback/romstage_null.debug
CC cbfs/fallback/coreboot_ram.debug
coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1
make: *** Waiting for unfinished jobs....
coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
[…]
Therefore revert the commit to get the tree working again and
submit this patch with its dependencies again.
[1] http://review.coreboot.org/#/c/3317/
[2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Do the setup for all PCI slots, not only the third.
Also remove the bogus message, as slot 3 may carry
any device, not only NICs.
This makes IRQ setup simliar to SeaBIOS.
SeaBIOS assignments (with patch for logging added,
and a bunch of pci devices for testing purposes):
PCI IRQ [piix]: bdf=00:01.3 pin=1 line=10
PCI IRQ [piix]: bdf=00:03.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:04.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:05.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:06.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.1 pin=2 line=10
PCI IRQ [piix]: bdf=00:1d.2 pin=3 line=11
PCI IRQ [piix]: bdf=00:1d.7 pin=4 line=11
Coreboot assignments without this patch:
Assigning IRQ 11 to 0:3.0
Coreboot assignments with this patch:
Assigning IRQ 10 to 0:1.3
Assigning IRQ 11 to 0:3.0
Assigning IRQ 11 to 0:4.0
Assigning IRQ 10 to 0:5.0
Assigning IRQ 10 to 0:6.0
Assigning IRQ 10 to 0:1d.0
Assigning IRQ 10 to 0:1d.1
Assigning IRQ 11 to 0:1d.2
Assigning IRQ 11 to 0:1d.7
Change-Id: Ie96be39185f2f1cbde3c9fc50e29faff59c28493
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3334
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
baud_rate = 115200
debug_level = Spew
hyper_threading = Enable
nmi = Enable
boot_devices = ''
boot_default = 0x40
cmos_defaults_loaded = Yes
lpt = Enable
volume = 0xff
tft_brightness = 0xbf
first_battery = Primary
bluetooth = Enable
The code for handling the invalid CMOS space in mainboard.c
is now useless and so it was removed.
Change-Id: Ic57a14eeeea861aa034cb0884795b0152757bf5b
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Move the include before static inline int spd_read_byte().
Change-Id: I4cac4b1f55368041b067422d95c09208e15d0f2d
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3368
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On Asus F2A85-M, the Linux kernel complains that the _CRS method does
not specify the number of PCI busses.
[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS
Just put there 256. This should be part of re-factoring of the whole
ACPI stuff.
The same change was already done for the AMD Brazos (SB800) boards,
based on commit »Persimmon DSDT: Add secondary bus range to PCI0«
(4733c647) [1].
[1] http://review.coreboot.org/2592
Change-Id: I06f90ec353df9198a20b2165741ea0fe94071266
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3320
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
- 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>
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>
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>
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>
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>
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>
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)
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>
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>
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>
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>
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)
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)
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>
Revert commit f90071faee [1] as
it was merged without its dependencies and therefore the source
tree currently does not build [2][3].
OPTION option_table.h
GEN build.h
SCONFIG mainboard/pcengines/alix1c/devicetree.cb
CC arch/x86/lib/cbfs_and_run.romstage.o
CC arch/x86/lib/memcpy.romstage.o
CC arch/x86/lib/memset.romstage.o
CC arch/x86/lib/rom_media.romstage.o
CC arch/x86/lib/romstage_console.romstage.o
CC console/die.romstage.o
CC console/post.romstage.o
CC console/vtxprintf.romstage.o
CC device/device_romstage.romstage.o
CC lib/cbfs.romstage.o
CC lib/compute_ip_checksum.romstage.o
CC lib/gcc.romstage.o
CC lib/lzma.romstage.o
CC lib/memchr.romstage.o
CC lib/memcmp.romstage.o
CC lib/memmove.romstage.o
CC lib/ramtest.romstage.o
CC lib/uart8250.romstage.o
CC southbridge/amd/cs5536/smbus.romstage.o
ROMCC generated/bootblock.inc
GEN generated/bootblock.ld
make: *** No rule to make target `nvramtool', needed by `coreboot-builds/pcengines_alix1c/coreboot.pre1'. Stop.
make: *** Waiting for unfinished jobs....
OPTION cmos_layout.bin
[1] http://review.coreboot.org/#/c/3229/
[2] http://www.coreboot.org/pipermail/coreboot/2013-May/075864.html
[3] http://qa.coreboot.org/job/coreboot-gerrit/6251/testReport/junit/(root)/board/i386_pcengines_alix1c/
Change-Id: I4764d90c39ccdb4dc7e7a9aef7525c306614e1a8
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This was an early bring-up reference board for ULT but it is no
longer being worked on and was never complete enough to be useful
and I no longer have a board so it is already stale and untested.
All ULT bring-up work has moved to the wtm2 mainboard instead.
Change-Id: If64d61bf7a3fc8c9e16096ffc28fa4128aa99477
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3231
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The format of this function changed but was not updated in
all mainboards. This fixes BaskingRidge and WTM2.
The int15 handler no longer takes a regs structure as an
argument and instead uses global variables. The yabel interface
is now similar enough that we can drop the duplicate handler.
Change-Id: Ia717ae14f99cee6d83ccdb1e26b9d7defe1638c4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3230
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE,
GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used.
Change-Id: I5c7b7d45880367dba452ebcd4f01fbd0c15aac22
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3087
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Apply the following commit to all AMD boards.
commit 935850e082
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon May 6 16:16:03 2013 -0700
asrock/e350m1: reduce default stack size
The stack used on the ASRock E350M1 is significantly less than
what we currently set (64k per core). In fact, we use about half
of the default stack size (4k) on core 0 and even less on non
BSP cores [1]:
$ grep stack coreboot_without_patch_but_monotonic_timer.log
CPU1: stack_base 002a0000, stack_end 002afff8
CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes
CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes
[…]
Reviewed-on: http://review.coreboot.org/3209
Please note that AGESA seems to define bigger stack sizes. But
these seem to be too much too.
$ git grep STACK_SIZE src/vendorcode/amd
[…]
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define BSP_STACK_SIZE 16384
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE0_STACK_SIZE 16384
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE1_STACK_SIZE 4096
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: BSP_STACK_SIZE,
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE0_STACK_SIZE,
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE1_STACK_SIZE,
[…]
The following command was used to create the patch.
$ git grep -l STACK_SIZE src/mainboard/ | xargs sed -i '/STACK_SIZE/,+3d'
Change-Id: I36b95b7a6f190b64d0639fc036ce2fb0253f3fa1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3217
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
it has been unused since 9 years or so, hence drop it.
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The stack used on the ASRock E350M1 is significantly less than
what we currently set (64k per core). In fact, we use about half
of the default stack size (4k) on core 0 and even less on non
BSP cores [1]:
$ grep stack coreboot_without_patch_but_monotonic_timer.log
CPU1: stack_base 002a0000, stack_end 002afff8
CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes
CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes
Removing the Kconfig variable STACK_SIZE to use the default results
in the following numbers of stack usage.
$ grep stack coreboot_with_patch.log
CPU1: stack_base 00287000, stack_end 00287ff8
CPU1: stack: 00287000 - 00288000, lowest used address 00287da8, stack used: 600 bytes
CPU0: stack: 00288000 - 00289000, lowest used address 0028875c, stack used: 2212 bytes
[1] http://review.coreboot.org/#/c/3154/
(comment May 2 10:21 AM)
Change-Id: Ibdb2102c86094fce3787e3b5a162ca8423de205c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3209
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
1. Move comment for console init to correct place.
2. Start output with capital letter and add full stop at the end.
3. Add missing »)« at the end of description of GPIO 10.
4. Use tabulators instead of spaces.
5. Indent the code automatically using GNU indent [1] with the `-sc`
switch adding stars in front of comment blocks as the good indent
manual documents.
$ indent -linux -sc src/mainboard/lenovo/x60/romstage.c
Leave the numbers left aligned as it is more beneficial to be
able to run indent without adapting the result afterward.
[1] http://www.coreboot.org/Development_Guidelines#Coding_Style
Change-Id: I2fa018ec28ff19d23d68754b565c13a7d7a57355
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3185
Tested-by: build bot (Jenkins)
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 2fde9668b4
Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.
Reverting this until the other two go in.
Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If the SD controller is "off" hudson.c won't disable that because,
there is no code for this yet.
The PCI device is still visible and PCI BAR will be allocated
by Linux. Unfortunately it may happen that the particular address
is used by non-standard BAR for SPI controller.
Change-Id: Ied7c581727541e2c81b0b1c2b70fd32de0014730
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3167
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Stefan Reinauer suggested 'select UDELAY_LAPIC' did not belong in
f2a85-m/Kconfig. It got there via copy-paste from thatcher/Kconfig
so this commit removes the 'select UDELAY_LAPIC' from both and puts
it in cpu/amd/agesa/family15tn/Kconfig
Since f2a85-m is the only Thatcher board coreboot supports right
now, this should not break any other boards.
Change-Id: I811b579c31f8d259a237d3a6724ad3b17f3a6c3e
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3178
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
The "gigabit ethernet controller" (GEC) block was added to AMD
Hudson A55E to integrate ethernet capabilities into an AMD
southbridge.
The GEC is designed to work with B50610 and B50610M gigabit PHY
chips from Broadcom. These parts may not be generally available
in small quantities for embedded development.
The GEC block requires an opaque firmware blob to function. The
GEC blob is controlled by AMD and Broadcom and is not available
from coreboot.org.
This change removes GEC support from AMD Parmer and AMD Thatcher
mainboards since these boards do not have the Broadcom PHY.
AMD has requested that the GEC be hidden for Hudson FCH since
the PHY parts are not generally available. This Kconfig option
can make it appear that this is a viable and supported way to
add Ethernet to an embedded board. It is possible to use the
Hudson GEC block with other PHYs, but this requires development
of a custom GEC blob and a custom Ethernet driver. A custom GEC
blob has been developed for a Micrel PHY, but there is no
accompanying driver.
Change-Id: I7a7bf4d41e453390ecf987c9c45ef2434fc1f1a3
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3127
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
It's fine to always start timer even in suspend/resume mode, so we can
move the timer_start() back to the very beginning of boot procedure.
That provides more precise boot time information.
With that timer change, the wake up state test procedure can be simplified.
Verified by building and booting firmware image on Google/Snow successfully,
and then suspend-resume without problem (suspend_stress_test).
Change-Id: I0d739650dbff4eb3a75acbbf1e4356f2569b487d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The firmware media source (SPI1) is already initialized by Exynos iROM.
There is no need to do it again.
Verified by building and booting Google/Snow successfully.
Change-Id: I89390506aa825397c0d7e52ad7503f1cb808f7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The "console_init" does initialize UART driver (which will setup peripheral and
pinmux) and print starting message. Duplicated initialization can be removed.
Also, console_init (from console.c) is always linked to bootblock (and will do
nothing if CONFIG_EARLY_CONSOLE is not defined) so it's safe to remove #ifdef.
Verified by building and booting on Google/Snow, with and without
CONFIG_EARLY_CONSOLE.
Change-Id: I0c6b4d4eb1a4e81af0f65bcb032978dfb945c63d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3150
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable `EARLY_CBMEM_INIT` for CBMEM console support by looking how
other boards do this.
This commit is tested by enabling the CBMEM console (`CONSOLE_CBMEM` in
Kconfig) and then in GRUB 2 (as a payload) with the cbmemc command from
the cbmemc module and in userspace with ./cbmem -c. Both worked.
Change-Id: I34618a55ded7292a411bc232eb76267eec17d91e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3142
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The DDR3 memory initialization (with "mem_reset" set on normal boot) will cause
resume to be unstable, especially when X is running. System may show X screen
for few seconds, then crash randomly and unable to recover - although text
console may still work for a while. Probably caused by corrupted memory pages.
'mem_reset' (which refers to RESET# in DDR3 spec) should be enabled according
to DDR3 spec. But it seems that on Exynos 5, memory can be initialized without
setting mem_reset for both normal boot and resume - at least no known failure
cases are found yet. So this can be a temporary workaround.
Verified by booting a Google/Snow device with X Window and ChromeOS, entering
browser session with fancy web pages, closing LID to suspend for 5 seconds, then
re-opening to resume. Suspend/resume worked as expected.
Also tried the "suspend_stress_test" with X running and finished 100 iterations
of suspend/resume test without failure.
Change-Id: I7185b362ce8b545fe77b35a552245736c89d465e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3148
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the suspend/resume feature into bootblock and romstage.
Note, resuming with X and touchpad driver may be still unstable.
Verified by building and booting successfully on Google/Snow, and then executing
the "suspend_stress_test" in text mode ("stop ui; suspend_stress_test") in
Chromium OS, passed at least 20 iterations.
Change-Id: I65681c42eeef2736e55bb906595f42a5b1dfdf11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move board setup procedure to snow_setup_* functions, and Snow board-specific
(wakeup) code to snow_* for better function names and comments.
Verified by successfully building and booting on Google/Snow.
Change-Id: I2942d75064135093eeb1c1da188a005fd255111d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3130
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.
Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.
Verified by successfully building and booting Google/Snow firmware image.
Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support suspend/resume, PHY control must be reset only on normal boot
path. So add a new param "mem_reset" to specify that.
Verified to boot successfully on Google/Snow.
Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It seems that ConnectorTypeDP in DdiList supports both DP and HDMI monitors.
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
This commit partially reverts commit >AMD Thatcher: Fix PCIE link issues< (7f23aeb0) [1].
[1] http://review.coreboot.org/3011
Change-Id: I23cf1c69a8274f47daf56f1a12aafd88bad4a128
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3088
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.
Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
Due to
$ more src/southbridge/amd/cimx/sb800/Makefile.inc
[…]
romstage-y += cfg.c
romstage-y += early.c
romstage-y += smbus.c
ramstage-y += cfg.c
ramstage-y += late.c
[…]
`src/southbridge/amd/cimx/sb800/` is passed with the switch `-I` to
the compiler, where it is also going to find the header file
`sb_cimx.h`. Therefore use `#include <sb_cimx>` everywhere, which is
what some AMD SB800 based boards already do.
The only effect is, that the compiler will not needlessly look into
directories which do not contain the header file [1].
The following command was used for the replacement.
$ git grep -l sb_cimx.h src/mainboard/ | xargs sed -i 's/#include "sb_cimx.h"/#include <sb_cimx.h>/'
[1] http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Change-Id: I96ab34bac1524e6c38c85dfe9d99cb6ef55e6d7c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This PLL is unused and can be disabled to save about 250mW.
Change-Id: I1be37304d6ea5ff78696e05ad1023ce3c57f636c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3109
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This just cleans up a few areas:
- Removed an unnecessary delay from exynos_dp_bridge_setup()
- The delay at the end of exynos_dp_bridge_init() is necessary, so
removed the comment suggesting that it might not be.
- Simplified exynos_dp_hotplug
Change-Id: I44150f5ef3958e333985440c1022b4f1544a93aa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables clock gating to save power on unused IPs.
Change-Id: I9ab2a2535ebb91bb4110390a6f055a67146bdbf9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3110
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is based on >>AMD Thatcher: ConnectorTypeDP supports both DP and HDMI<< (I23cf1c6) [1]
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
[1] http://review.coreboot.org/#/c/3088/
Change-Id: I291beff43609ecb68ece24939f2dbc7c08dd0374
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3090
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables the thermal management unit (TMU) on Snow.
Change-Id: Idd76af40bf0a5408baf61ef2665fd52ae4e260ba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3108
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Same splitting as done on Persimmon and ASRock.
Moving common DSDT code to common areas and adding
new files as necessary. Boards updated are:
Inagua
Union-Station
South-Station
Change-Id: I8c9eea62996b41cea23a9c16858c4249197f6216
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3051
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
1) The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE,
GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used.
This is based on >AMD Thatcher: remove unused macros in PlatformGnbPcieComplex.h< [1].
2) Disable unused PCIE port in devicetree.cb.
PCIE port 3 is not used in Parmer.
This is based on item 3 of >AMD Thatcher: Fix PCIE link issues< [2].
[1] http://review.coreboot.org/#/c/3087/
[2] http://review.coreboot.org/#/c/3011/
Change-Id: Id6f00d5e77ce5133d9ef3db07f95ad03a59e061a
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3099
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function isn't yet used for much, or perhaps anything, but where it
appears in the code it's ored with other values. Since we're not actually
retrieving anything, it might be best to return 0 so that the other values
that are being ored in can be expressed and this function can stay dormant
until it actually has something to do.
Change-Id: I6edc222a5c2d00ece2ecfad5191a615331eeaf16
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3098
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
We need to read it to report its value to the payload. The kernel will
reconfigure it as an external interrupt, but we'll make it a regular input
for now.
Change-Id: I019bd2c2731144d3b7bb53fad0c2c903874f616c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3096
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These names were inherited from chromeos.c where they've already been
fixed.
Change-Id: I7ad57b979b7b8f42f6bd68d1ecf887caba3fa3f1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3095
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
ARM doesn't use option ROMs, so this value doesn't make sense.
Change-Id: I1a0f0854e1dd4b9594ca0c147e590337520436da
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3094
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Got rid of a lot of #defines, some of which were converted to enums and
the rest which were eliminated entirely. Got rid of cruft in
get_developer_mode_switch and started using it for the dev mode GPIO.
Instead of a macro defining how many GPIOs are expected, now the code
actually counts the GPIOs as they're added.
Change-Id: I97b6b9f52a72d1276eb3cf36d7f9dd7b335b4d19
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3093
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Implement the get_recovery_mode_switch function using the newly added I2C
based Chrome EC support.
Change-Id: I9d0200629887f202edf017cba3222a7d7f5b053e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3092
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The comment about the lid switch was left over from when this file was copied
from another board and was incorrect. Also fixed a capitalization
inconsistency.
Change-Id: Icefd19047971e13c08f615578e4a181e82a2997f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3091
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The code has been taken from the google link mainboard
and modified to fit the ThinkPad X60.
Change-Id: Ie16e45163acdc651ea46699ecc33055bfd34099c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/2998
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Google's Chrome EC can be installed on LPC or I2C bus, using different command
protocol. This commit adds I2C support for devices like Google/Snow.
Note: I2C interface cannot be automatically probed so the bus and chip number
must be explicitly set.
Verified by booting Google/Snow, with following console output:
Google Chrome EC: Hello got back 11223344 status (0)
Google Chrome EC: version:
ro: snow_v1.3.108-30f8374
rw: snow_v1.3.128-e35f60e
running image: 1
Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3074
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are not defined since commit »Drop HAVE_MAINBOARD_RESOURCES«
(1c5071d1) [1] but were unfortunately introduced again in new ports.
[1] http://review.coreboot.org/1414
Change-Id: I5eb61628141aefd08779615702d51ca155fa632a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2707
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.
(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).
Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5:
commit 1fde22c54c
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Apr 9 15:41:23 2013 +0200
siemens/sitemp_g1p1: Make ACPI report the right mmconf region
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It sneaked in without it's dependencies and, therefore, broke the build for
all amdk8 targets. Paul Menzel already commented on the issue in [1]. It
also doesn't look like the dependencies would be pulled soon [2].
[1] http://review.coreboot.org/#/c/3047/
[2] http://review.coreboot.org/#/c/2662/
Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3063
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
1). Thatcher PCIE x8 slot is reverse order.
Although the PCIE slot is x16, it actually uses 8 lanes(15:8).
Because the PCIE slot is configured by PortList[0], fix this item can enable the slot.
A x1 PCIE network adapter works well in this slot.
2). Fix DdiList to detect DP monitor or HDMI monitor.
GPIO50 can be used to detect DP0/HDMI0 monitor.
If GPIO50 is 1, it is DP monitor. If GPIO50 is 0, it is HDMI monitor.
GPIO51 can be used to detect DP1/HDMI1 in the same way.
3). Disable unused PCIE port and clean up code in PlatformGnbPcie.c and devicetree.cb.
PCIE port 3 and 7 are not used in Thatcher.
Change-Id: I8524b6fc1b6cdc03ba92e7191186bfb0986767c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory. Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future. I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time. Removing
it until it is decided that it is actually necessary.
This change was verified in three different ways:
1. Visual comparison of the compiled DSDT pulled from the
Persimmon after booting into Linux using the ACPI tools
acpidump, acpixtract, and iasl. The comparison was done
between the DSDT before and after doing the split work.
This test is somewhat difficult considering the expanse
of the changes. Blocks of code have been moved, and
others changed.
2. Linux logs were dumped before and after the DSDT split.
Logs dumped and compared include dmesg and lspci -tv.
Neither log changed significantly between the two compare
points.
3. The test suite FWTS was run on the Coreboot build both
before and after doing the DSDT split with the command
'sudo fwts -b -P -u'. The flag -b specifies all batch jobs,
-P specifies all power tests, and -u specifies utilities.
Interactive jobs were not run as most of them consist of
laptop checks. Again, there were no significant changes
between the two endpoints.
These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.
This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)
Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.
It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.
Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
This is the same split as was done on the Persimmon.
Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add basic edp support to the ramstage. Not working.
Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
This is a simpler device tree that is also more correct,
and has graphics settings as well.
Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Originally developed by LiPPERT and after the acquisition marketed as
'LiPPERT by ADLINK', the plan is now to streamline both boards into the
ADLINK naming scheme. But AFAIK a few have already been sold and as of
this writing the website still advertises the old names. And in any case
the veteran LX products will continue to be sold by ADLINK under their
original names.
So create CONFIG_VENDOR_ADLINK, currently only telling users to look under
LiPPERT (however any future boards will be added here).
Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard
model selection show both names.
Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3046
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 5d741567 added a prototype to broadcom.c to fix a warning. This part
is fine.
It also changed mainboard.c to #include broadcom.c. But broadcom.c is
already in Makefile.inc, now building will fail because the linker gets
broadcom_init() twice.
Undo the change to mainboard.c but keep the change to broadcom.c.
Change-Id: Ieccc098f477ffacccf4174056998034a220a9744
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3012
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Now that the ASRock E350M1 builds without any warnings, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: Idfecfb1434158969334a4b37972b5fc6fd76e72a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3014
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
When building the ASRock E350M1, the following warnings are shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/buildOpts.romstage.o
In file included from src/mainboard/asrock/e350m1/buildOpts.c:294:0:
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:6: warning: "DDR1333_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:40: warning: "DDR1866_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:5: warning: "TIMING_MODE_AUTO" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:31: warning: "TIMING_MODE_SPECIFIC" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:5: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:33: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:5: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:28: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
[…]
Adding the corresponding defines as done for AMD Persimmon in
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
addresses the warnings.
Change-Id: Id311b2dacdba5f2e6b4d834e43db0310213a35f9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2962
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables all of the SerialIO devices and sets the flag
to put them in ACPI mode.
Change-Id: I7436c47d26028e95bbefafc320854c7cc34a4d44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2972
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c:64:12: warning: unused variable 'dev' [-Wunused-variable]
[…]
Removing the variable `dev` addresses the warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I83f4630cb6ab1e4c95d04b4e8423850ed1858e45
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c: In function 'smp_write_config_table':
src/mainboard/asrock/e350m1/mptable.c:58:3: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I7912571fa57f6512b10fc9b5845427fcb6eb50c0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mainboard.ramstage.o
src/mainboard/asrock/e350m1/mainboard.c: In function 'mainboard_enable':
src/mainboard/asrock/e350m1/mainboard.c:63:2: warning: implicit declaration of function 'pm_iowrite' [-Wimplicit-function-declaration]
[…]
This warning was introduced by moving the initialization of the
ASF registers using `pm_iowrite` to `mainboard.c` in
commit db6c5bfd8b
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Thu Mar 21 22:21:28 2013 +0100
Asrock E350M1: Use SPD read code from F14 wrapper
Reviewed-on: http://review.coreboot.org/2875
and is fixed by including `southbridge/amd/cimx/cimx_util.h`
declaring `pm_iowrite`.
Note, that the other AMD SB800 based boards seem to use the
header file `southbridge/amd/sb800/sb800.h`, so no warning is shown
for those. But since the CIMx SB800 code is used, the routines
from the CIMx directory are more appropriate to declare these functions.
So delete the commented out include line for this header too.
Change-Id: I179aad5157c5a91294339a3e7b6c4c1715c6f099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This enables the TPM device in ACPI tables so the OS is able
to probe for the TPM without needing it be force loaded.
Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is a wildcard rule to include mainboard/fadt.c.
Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2940
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Unfortunately, an unneeded mainboard specific `pmio.h` was created
when merging the AMD Parmer and Thatcher ports.
Rudolf used the header from a more generic location
southbridge/amd/agesa/hudson/hudson.h
doing the the ASUS F2A85-M port, but did not delete the `pmio.h`
now unused `pmio.h` header file.
So adapt AMD Parmer and Thatcher to use the Hudson one as done for
the ASUS F2A85-M and delete the now unused mainboard specific header
file `pmio.h` to avoid duplication.
Change-Id: I961cd145ebc3b83e31c638ac453ac95ee19c18db
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2958
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/irq_tables.ramstage.o
src/mainboard/asrock/e350m1/irq_tables.c: In function 'write_pirq_routing_table':
src/mainboard/asrock/e350m1/irq_tables.c:64:2: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I40b5735feb7116961ca0c4d6940ec55cdf42d3c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2956
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/get_bus_conf.ramstage.o
src/mainboard/asrock/e350m1/get_bus_conf.c: In function 'get_bus_conf':
src/mainboard/asrock/e350m1/get_bus_conf.c:82:3: warning: implicit declaration of function 'agesawrapper_amdinitlate' [-Wimplicit-function-declaration]
[…]
Including the header file `agesawrapper.h` declaring the function
`agesawrapper_amdinitlate` fixes this warning.
All AMD Family 14 based boards already include that header file. For
example for the board AMD Persimmon the following patch fixed this
warning.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I695420b7071e07cb7d4667b2479b9a26ea13723d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2955
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/PlatformGnbPcie.romstage.o
CC mainboard/asrock/e350m1/agesawrapper.romstage.o
CC mainboard/asrock/e350m1/buildOpts.romstage.o
src/mainboard/asrock/e350m1/PlatformGnbPcie.c: In function 'OemCustomizeInitEarly':
src/mainboard/asrock/e350m1/PlatformGnbPcie.c:131:5: warning: 'return' with a value, in function returning void [enabled by default]
[…]
The function signature is (the return type might not be part of this though [1]),
VOID
OemCustomizeInitEarly (
IN OUT AMD_EARLY_PARAMS *InitEarly
)
so do not return anything.
All other AMD Family 14 boards already have the correct code. For example
following commit fixed this for AMD Persimmon.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
[1] http://cboard.cprogramming.com/cplusplus-programming/117286-what-exactly-function-signature.html
Change-Id: Ie60246bd9bb8452efd096e6838d8610f6364a6aa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2954
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
This adds a call to explicitly configure L2 cache (though defaults
should be set correctly).
Change-Id: I120e29c986918c2904a0332e46fcf9f1c5380d85
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2950
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
The WTM2 board has a fairly static configuration. As such
it's been tested to properly handle CACHE_ROM given the number
of MTRRs the boards' CPUs supports.
Change-Id: Ic67cd1eebce580003dc6b6655cac2b2a92dd1b5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2964
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that the AMD Inagua builds without any warnigs, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: I0b58bd74b06dc54d180b16d6a207354b5fea0d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2953
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Building the AMD Inagua board, the following warning is thrown.
CC mainboard/amd/inagua/get_bus_conf.ramstage.o
src/mainboard/amd/inagua/broadcom.c:319:6: warning: no previous prototype for 'broadcom_init' [-Wmissing-prototypes]
This warning was introduced by commit 3926b4c5.
commit 3926b4c520
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Fri Mar 1 19:41:41 2013 +0100
AMD Inagua: add GEC firmware, document Broadcom BCM57xx Selfboot Patch format
Reviewed-on: http://review.coreboot.org/2831
Adding the prototype to `broadcom.c` and removing it from
`mainboard.c` fixes the warning.
Change-Id: I1da0c4e972e129047dd8230d573f1c43fd71eb20
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2952
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Automatically select CACHE_ROM for all Google boards.
Tested by generating a config for the link board. CACHE_ROM
was selected and was unable to unselect it using
'make oldconfig'.
Change-Id: I8e34207e3929a020bb0280657f95ba7a000ad024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2963
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 9427ca151e
Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things.
coreboot memory table:
0. 0000000050000000-000000005000ffff: RESERVED
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
2. 0000014004000000-00000140044007ff: RESERVED
Before this patch:
coreboot memory table:
0. 0000000040000000-00000000bfefffff: RAM
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec
Reviewed-on: http://review.coreboot.org/2914
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This does NOT turn on the graphics.
The device tree has been changed enough so that, at the very least, the correct
functions are called at the correct time, with the correct paramaters. We
decided to yank the I2C entries as they did not obvious function and might
not even have been correct.
Not working, seemingly, but we need to add a 4M resource for
memory, and it seems it needs to be fixed at the address shown.
This address was chosen from current hardware.
We realized that the display code should be part of the cpu -- that's how
the hardware works!
Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2615
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This adds new MMU setup code. Most notably, this version uses
cbmem_add() to determine the translation table base address, which
in turn is necessary to ensure payloads which wipe memory can tell
which regions to wipe out.
TODOs:
- Finish cleaning up references to old cache/MMU stuff
- Add L2 setup (from exynos_cache.c)
- Set up ranges dynamically rather than in ramstage's main().
Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2877
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Broadcom BCM5785 GbE MAC integrated in the AMD Hudson-E1 requires a
secret sauce firmware blob to work. As Broadcom wasn't willing to send us
any documentation (or a firmware adapted to our Micrel PHY) I had to figure
out everything by myself in many weeks of hard detective work.
In the end we had to settle for a different solution, the modified firmware
I devised for the Micrel KSZ9021 PHY on our early FrontRunner-AF prototypes
is no longer needed for the production version. However the information
contained here might be very useful for others who'd like to use a
competing PHY instead of Broadcom's 50610, so it should not get lost.
And of course the unmodified, but now in large parts documented Selfboot
Patch is needed to get Ethernet on AMD Inagua. The code introduced here
should make the Hudson's internal MAC usable without having to add the
proprietary firmware blob. - At least in theory.
Unfortunately we've been unable to actually test this patch on Inagua,
therefore the broadcom_init() call in mainboard.c was left commented out.
If you have the hardware and can confirm it works please enable it.
The fun thing is: as Broadcom refused to do any business with us at all,
or send us any documentation, we never had to sign an NDA with them. This
leaves me free to publish everything I have found out. :-)
Change-Id: I94868250591862b376049c76bd21cb7e85f82569
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2831
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The patch is based on Thatcher board. So far it boots Linux (3.2/3.7),
internal network adapter works, AHCI works. External PCI/PCIe slots
works too. Power management/ACPI seems to work.
Internal VGA works with dumped ROM (VGA/DVI), but lacks GART.
PCI pref devices are being relocated by Linux, reason unknown.
This is a good start.
USB and XHCI untested but visible.
Change-Id: I1869aecb2634d548b00b3c9139517d6a0e0c9817
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/2038
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Changes:
- Get rid of the E350M1 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: I08c2aebc62facc14f94400ee1ad188901ba73f19
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2875
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Changes:
- Get rid of the LiPPERT FrontRunner-AF and Toucan-AF 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: I4ee5e1bc34f4caee20615c48248d4f7605c09377
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2874
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
coreboot tables are, unlike general system tables, a platform
independent concept. Hence, use the same code for coreboot table
generation on all platforms. lib/coreboot_tables.c is based
on the x86 version of the file, because some important fixes
were missed on the ARMv7 version lately.
Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2863
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
It's helpful to switch back and forth for developer and
recovery settings while testing boards. The wtm2 board
currently doesn't have gpios which dynamically seelect that.
Might as well make it easy to change the value for each
setting with one define. The original defaults are kept.
Change-Id: I7b928c592fd20a1b847e4733f4cdef09d6ddad4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2861
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The get_write_protect_state() function was added to the
chromeos API that needs to be supported by the boards.
Implement this support.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as
well by choosing the RO path.
Change-Id: Ifd213be25304163fc61d153feac4f5a875a40902
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2855
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Force link speed on these platforms to 3 Gbps to defeat buggy SATA
drives.
Change-Id: Ia38a7c486fb1f4469cd67ca5244bbf61f877d556
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2823
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes use of the new functions from pmutil.c that take
care of the differences between -H and -LP chipsets.
It also adds support for the LynxPoint-LP GPE0 register block
and the SMI/SCI routing differences.
The FADT is updated to report the new 256 byte GPE0 block on
wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address
block so that part is zeroed to prevent IASL and the kernel
from complaining about a mismatch.
This was tested on WTM2. Unfortunately I am still unable to get an
SCI delivered from the EC but I suspect that is due to a magic
command needed to put the EC in ACPI mode. Instead I verified that
all of the power management and GPIO registers were set to expected
values.
I also tested transitions into S3 and S5 from both the kernel and
by pressing the power button at the developer mode screen and they
all function as expected.
Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2816
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Changes:
- Get rid of the h8scm mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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: I575221039ad65a59ae0f93397ef1038b669e81c7
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes:
- Get rid of the dinar mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() were created from code that
was removed from AmdMemoryReadSPD() in dimmSpd.c. The functionality
is specific to the dinar mainboard configuration and was therefore
split from the generic read SPD functionality.
Change-Id: I1e4b9a20dc497c15dbde6d89865bd5ee7501cdc0
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes:
- Get rid of the s8226 mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I1eaf64986ef4fa3f89aed2b69d3f9c8c913f726f
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2827
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes:
- Get rid of the h8qgi mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I346ebd8399d4ba3e280576e667fdc62fa75a63b8
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This code is taken from an EDID reader written at Red Hat.
The key function is
int decode_edid(unsigned char *edid, int size, struct edid *out)
Which takes a pointer to an EDID blob, and a size, and decodes it into
a machine-independent format in out, which may be used for driving
chipsets. The EDID blob might come for IO, or a compiled-in EDID
BLOB, or CBFS.
Also included are the changes needed to use the EDID code on Link.
Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a new operator, P, for the state machine, meaning
implement a palette fill.
Implement a function (palette) that fills the palette when the
P operator is hit.
This replaces 256 lines in the state machine table with 1.
Change-Id: I67d9219fe7de0ecf1fb9faf92130c00c9f5f8e88
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/2835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For full integration of FUI into coreboot, we need aux channel
communcations. The intel_dp.c is a file taken from Linux and is
used for aux channel comms. This file has been cut down to work
with coreboot. For now it is associated with the link mainboard
until we get a better handle on how this all fits together. This
code is almost certainly usable on other platforms in the long term.
But one step at a time.
Change-Id: I7be4c56e0a7903f3901ac86e12b28f3bdc0f7947
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/2834
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a new API for cache maintenance operations. The idea is
to be more explicit about operations that are going on so it's easier
to manage branch predictor, cache, and TLB cleans and invalidations.
Also, this adds some operations that were missing but required early
on, such as branch predictor invalidation. Instruction and sync
barriers were wrong earlier as well since the imported API assumed
we compield with -march=armv5 (which we don't) and was missing
wrappers for the native ARMv7 ISB/DSB/DMB instructions.
For now, this is a start and it gives us something we can easily use
in libpayload for doing things like cleaning and invalidating dcache
when doing DMA transfers.
TODO:
- Set cache policy explicitly before re-enabling. Right now it's left
at default.
- Finish deprecating old cache maintenance API.
- We do an extra icache/dcache flush when going from bootblock to
romstage.
Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes a trivial error with the recovery mode GPIO index.
Change-Id: I7290c1e23cdddaf91c9021d4e4252c0c772b6eab
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A fix to eliminate warnings when building romstage files with ChromeOS
compilers
Change-Id: Ia5d7bbdde3aa3439fd493f5795f2cc2bf4c4c187
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2781
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Having this header file in the mainboard directory breaks
the dinar build on cygwin because the header file in the
dinar mainboard is used instead of the correct header file
src/vendorcode/amd/cimx/sb700/OEM.h. The build probably works
fine on Linux systems because, due to case-sensitivity, Oem.h
will not match the #include "OEM.h" statement in
src/southbridge/amd/cimx/sb700/Platform.h.
The Oem.h file in the dinar mainboard is not used by any other
source files, and the defines in the dinar mainboard are duplicated
by defines in the correct OEM.h file. Therefore, the file can be
safely removed.
Change-Id: I81b97eca8116d63644d335edc3bb51f90c7094d9
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2776
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This commit pulls in all the common logic for romstage into
the Haswell cpu directory. The bits specific to the mainboard
still reside under their respective directories. The calling
sequence bounces from the cpu directory to mainboard then back
to the cpu directory. The reasoning is that Haswell systems use
cache-as-ram for backing memory in romstage. The stack is used to
allocate structures. However, now changes can be made to the
romstage for Haswell and apply to all boards.
Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2754
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is causing a hang in depthcharge. For now just disable
this port.
Change-Id: I87a6db2d8361588e82eee640c74cea690115bed5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2764
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Rather than have to repeat this bit in every mainboard.
Also, remove the reset of the RTC power status from here.
We had done this in TOT for current platforms but did not
carry it back to emeraldlake2 where this branched from.
If we clear the status here then we don't get an event
logged later which can be important for the devices that
do not have a CMOS battery.
Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2683
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We're happy to announce coreboot support for the "Stout"
Chromebook, a.k.a Lenovo X131e Chromebook.
Change-Id: I9b995f8d0dd48e41c788b7c3d35b4fac5840e425
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2636
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is mostly a copy of Whitetip Mountain 1 with specific GPIO
map for this Customer Reference Board (CRB).
This mainboard currently has basic funcionality and is able to
boot a Linux Kernel but many of the new Haswell ULT specific
devices are not yet enabled.
Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2725
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Lots of things are still placeholder and need work.
Due to the useful GPIOs being run to either the EC or the SIO1007
I have hard coded developer mode on and recovery mode off.
Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@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 is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2736
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same chagne as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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 is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: I2701d915338294bdade2ad334b22a51db980892e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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 is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
Change-Id: If8d86f959822d528c44ab011a851659d486289b5
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current code is attempting to convert from an invalid
starting temperature. Since we aren't sure where the temperature
will come from yet just return a static value.
This stops the kernel from going to S5 on boot because it
thinks the temperature is too high.
Change-Id: I433fa407e545458344af5842b353df5bc71bfdad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2679
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option is not required for haswell. Enabling the option doesn't
do anything aside from complicate mtrr calculation. Therefore, remove
it.
Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2678
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This commit adds support for the deveveloper, recovery,
and write protect querying. It just uses jumpers on the
Basking Ridge board.
Noted ability to togggle jumpers results in toggling the
respective modes.
Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2676
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
While looking at the Basking Ridge schematic I noticed some changes
and wanted to make sure they were reflected in the GPIO map.
Change-Id: I686653c164314ae9f68c42331d2f950751411d4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2675
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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>
WANG Siyuan