Certain MMIO resources can be set to a write-combining cacheable
mode to increase performance. Typical resources that use this would
be graphics memory.
Change-Id: Icd96c720f86f7e2f19a6461bb23cb323124eb68e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2891
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The IORESOURCE_UMA_FB and IORESOURCE_IGNORE_MTRR attributes
on a resource provided hints to the MTRR algorithm. The
IORESOURCE_UMA_FB directed the MTRR algorithm to setup a uncacheable
space for the resource. The IORESOURCE_IGNORE_MTRR directed
the MTRR algorithm to ignore this resource as it was used reserving
RAM space.
Now that the optimizing MTRR algorithm is in place there isn't a need
for these flags. All IORESOURCE_IGNORE_MTRR users are handled by the
MTRR code merging resources of the same cacheable type. The users
of the IORESOURCE_UMA_FB will find that the default MTRR type
calculation means there isn't a need for this flag any more.
Change-Id: I4f62192edd9a700cb80fa7569caf49538f9b83b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2890
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The old MTRR code had issues using too many variable
MTRRs depending on the physical address space layout dictated
by the device resources. This new implementation calculates
the default MTRR type by comparing the number of variable MTRRs
used for each type. This avoids the need for IORESOURE_UMA_FB
because in many of those situations setting the default type to WB
frees up the variable MTTRs to set that space to UC.
Additionally, it removes the need for IORESOURCE_IGNORE_MTRR
becuase the new mtrr uses the memrange library which does merging
of resources.
Lastly, the sandybridge gma has its speedup optimization removed
for the graphics memory by writing a pre-determined MTRR index.
That will be fixed in an upcoming patch once write-combining support
is added to the resources.
Slight differences from previous MTRR code:
- The number of reserved OS MTRRs is not a hard limit. It's now advisory
as PAT can be used by the OS to setup the regions to the caching
policy desired.
- The memory types are calculated once by the first CPU to run the code.
After that all other CPUs use that value.
- CONFIG_CACHE_ROM support was dropped. It will be added back in its own
change.
A pathological case that was previously fixed by changing vendor code
to adjust the IO hole location looked like the following:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
As noted by the output below it's impossible to accomodate those
ranges even with 10 variable MTRRS. However, because the code
can select WB as the default MTRR type it can be done in 6 MTRRs:
MTRR: default type WB/UC MTRR counts: 6/14.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2889
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use the memrange library for keeping track of the address
space region types. The memrange library is built to do just
that for both the MTRR code and the coreboot memtable code.
Change-Id: Iee2a7c37a3f4cf388db87ce40b580f274384ff3c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2917
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a missing CSSELR write in the case of a dcache or unified
cache being invalidated by armv7_invalidate_caches(), ensuring that
all levels of dcache/unified cache are invalidated as expected when
the function is called.
Change-Id: Ie90184bf8a8181afa3afe0786897455b30b7f022
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2947
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This adds a call to tlb_invalidate_all() after configuring a range
of memory.
Change-Id: I558402e7e54b6bf9e0b013f153d9b84c0873a6cf
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2946
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This makes dcache maintenance functions operate on all levels
of cache instead of just the current one.
Change-Id: I2708fc7ba6da6740dbdfd733d937e7c943012d62
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2945
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This adds simple accessor functions for reading/writing L2CTLR.
Change-Id: I2768d00d5bb2c43e84741ccead81e529dac9254d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2948
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes it easier to copy + paste code into libpayload since
libpayload since both coreboot and libpayload have stdint.h and
it defines the types needed.
Change-Id: Ifa55f04a9bdddd17bc1a2679321a6744c75f25a8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2944
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds some paranoia to cache manipulation routines:
- "memory" is added to the clobber list for functions which clean
and/or invalidate dcache or TLB entries.
- Remove unneeded clobber list for read_sctlr()
Change-Id: Iaa82ef78bfdad4119f097c3b6db8219f29f832bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2928
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This iterates thru all cache levels and cleans + invalidates all
data and unified caches before disabling dcache and MMU.
Change-Id: I8a671b4c90d7b88b8d0a95947bfa17f912cebaa2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2930
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
This is just a cosmetic change to dcache_op_mva() to (hopefully) make
it a easier to follow and more difficult to screw up.
Change-Id: Ia348b2d58f2f2bf5c3cafabcfba06bc411937dba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2927
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
'<' was used when '<<' is needed. Oops!
Change-Id: I8451f76888e86219df16b50739cd2c8db80dcb14
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2941
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
This passes the correct value into dccimvac.
Change-Id: I6098440ea48a9b6429380d5913fce6d36e3afb41
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2926
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
This moves the ram resource allocation into cpu_init() so that we
no longer rely on declaring a domain in devicetree.cb (which is kind
of weird for this platform). This does not cause any actual changes
to the coreboot memory table, and paves the way for further updates
to Snow's devicetree.
Change-Id: I141277f59b5d48288f409257bf556a1cfa7a8463
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2923
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes a couple issues with dcache_op_by_mva():
- Add missing data and instruction sync barriers.
- Removes unneded -1 from loop terminating condition.
Change-Id: I098388614397c1e53079c017d56b1cf3ef273676
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2913
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's not used (instead ARM puts it in Kconfig)
Change-Id: Ia22a7ac756bec4cb6fee00a4d946a020ea6290aa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2916
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
If a configuration was not using RELOCTABLE_RAMSTAGE, but it
was using HAVE_ACPI_RESUME then the ACPI memory was not being
marked as reserved to the OS. The reason is that memory is marked as
reserved during write_coreboot_table(). These reservations were
being added to cbmem after the call to write_coreboot_table(). In
the non-dynamic cbmem case this sequence is fine because cbmem area
is a fixed size and is already reserved. For the dynamic cbmem case
that no longer holds by the nature of the dynamic cbmem.
Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2897
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use the memrange library for keeping track of the address
space region types. The memrange library is built to do just
that for both the MTRR code and the coreboot memtable code.
Change-Id: Ic667df444586c2b5b5f2ee531370bb790d683a42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2896
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
It was never used, because we pushed romstage_null into the CBFS
instead of romstage_xip. It's not surprising this worked, but it
was a crude hack. Get rid of all the intermediate objects that are
not needed.
This could probably be further simplified to use the default cbfs
mechanism in our build system instead of having a specific rule for
romstage, but that's for another day.
Change-Id: I492ca2015ec81e13499fcd8dd331371f46a31c78
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2912
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>
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM
rely on EARLY_CBMEM_INIT. This isn't true in the face of
DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT.
Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM
when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem
implementation when COLLECT_TIMESTAMPS is selected.
Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmio_resource() was previously being used for reserving
RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute.
Instead, be more explicit for those uses with
reserved_ram_resource(). bad_ram_resource() now calls
reserved_ram_resource(). Those resources are marked as cacheable
but reserved.
The sandybridge and haswell code were relying on the implementation
fo the MTRR algorithm's interaction for reserved regions. Instead
be explicit about what ranges are MMIO reserved and what are RAM
reserved.
Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2886
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When the linking of ramstage was changed to use an intermeidate
object with all ramstage objects in it the .textfirst section
was introduced to keep the entry point at 0. However, the
section was not marked allocatable or executable. Nor was it
marked as @progbits. That didn't cause an issue on its own since
.textfirst was directly called out in the linker script. However,
the rmodule infrastructure relies on all the relocation entries
being included in the rmodule. Without the proper section attributes
the .rel.textfirst section entries were not being included in
the final ramstage rmodule.
Change-Id: I54e7055a19bee6c86e269eba047d9a560702afde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ramstage is now linked using an intermediate object that
is created from the complete list of ramstage object files.
The rmodule code was developed when ramstage was linked using
an archive file. Because of the fact that the rmodule headers
are not referenced from any other object the link could start
by specifying the rmodule header object for ramstage. That,
however, is not the case as all ramstage objects are included
in the intermediate linked object. Therefore, the
ramstage_module_header.ramstage.o object file needs to be removed
from the object list for the ramstage rmodule.
Change-Id: I6a79b6f8dd1dbfe40fdc7753297243c3c9b45fae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There were 3 things stopping the vboot module from being
compiled:
1. The vboot_reference code removed in the firmware/arch/$(ARCH)/include
directory. This caused romcc to fail because romcc fails if -I<dir>
points to non-existent directory.
2. The rmodule API does not have the no-clearing-of-bss variant of the
load function.
3. cbfs API changes.
Change-Id: I1e1296c71c5831d56fc9acfaa578c84a948b4ced
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The vboot module relied on being able to flush the console
after it called vtxprintf() from its log wrapper function.
Expose the console_tx_flush() function in romstage so the
vboot module can ensure messages are flushed.
Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2882
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The x86 linker script added a .textfirst section. In
order to properly link ramstage as a relocatable module
the .textfirst section needs to be included.
Also, the support for code coverage was added by including
the constructor section and symbols. Coverage has not been
tested as I suspect it might not work in a relocatable
environment without some tweaking. However, the section
and symbols are there if needed.
Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2883
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There were some cbfs calls that did not get transitioned
to the new cbfs API. Fix the callsites to conform to the
actual cbfs, thus fixing the copilation errors.
Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Make it more similar to i82801d LPC init.
Change-Id: I7b32747ee8012c220c8628994d749999c144b716
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2545
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm.
However, the AMD code needs to handle the RdMem and WrMem attribute
bits in the fixed MTRR MSRs. Instead of duplicating the code
with the one slight change introduce a Kconfig option,
X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields
need to be handled for writeback fixed MTRR ranges.
The order of how the AMD MTRR setup routine is maintained by providing
a x86_setup_fixed_mtrrs_no_enable() function which does not enable
the fixed MTRRs after setting them up. All Kconfig files which had a
Makefile that included amd/mtrr in the subdirs-y now have a default
X86_AMD_FIXED_MTRRS selection. There may be some overlap with the
agesa and socket code, but I didn't know the best way to tease out
the interdependency.
Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2866
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
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)
The haswell patches that verified correctly were not yet submitted,
but verified correctly. However they still used romcc_io.h which was
dropped in another patch earlier today.
With a lot of development happening in parallel, this is
unfortunately nothing that the gerrit 2.6 Rebase If Necessary submit
type could have fixed.
Change-Id: Ifef9ae05b22c408e78d6cff37defd68e4ed91ed9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2876
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 coreboot include were not being passed correctly when
building vboot_reference. The paths being included were of the
src/<dir> form. However, vboot_reference lives in
src/../vboot_reference. That coupled with the recursive make
call made vboot_reference not see coreboot's header files.
Fix this by appending ../ to coreboot's default include paths.
Change-Id: I73949c6f854ecfce77ac36bb995918d51f91445e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2860
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure contians the VbInitParams as well as the
shared vboot data. In order for the boot loader to find it, the
structure address and size needs to be obtained from the coreboot
tables.
Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Take the vboot path in romstage. This will complete the haswell
support for vboot firmware selection.
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: Ie2b0a34e6c5c45e6f0d25f77a5fdbaef0324cb09
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2856
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>
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
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: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For completeness add a vboot rmodule type since vboot will be
built as an rmodule.
Change-Id: I4b9b1e6f6077f811cafbb81effd4d082c91d4300
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot firmware selection from romstage will need to
pass the resulting vboot data to other consumers. This will
be done using a cbmem entry.
Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
