Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and
COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these
attributes are associated with each of the stages.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Image booted
successfully on link, rambi and nyan.
Change-Id: I10d36ff950712756fb16dcb4d315924d177846b5
Reviewed-on: https://chromium-review.googlesource.com/195574
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names(bootblock, romstage) and to allow any
Makefile rule generalization. (Required for patches to be submitted later)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197800
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Move the driver to where it belongs.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Iee33de0b29a6bb86ba7c37e7e89aabc0fee42e80
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196658
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
These driver needs to be in src/lib, and the include file needs to be
renamed to avoid collision with the top level uart.h.
BUG=chrome-os-partner:27784
TEST=emerge-storm coreboot still works
Change-Id: Ie12f44e055bbef0eb8b1a3ffc8d6742e7a446942
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196393
In last clean-up commit, the detailed_blocks parsing has been merged to one
for-loop and combining return values in each iteration instead of assignment.
As a result, has_valid_detailed_blocks should now be initialized as 1.
BRANCH=none
BUG=none
TEST=Tested AUO 1080p and InnoLux 720p panels on nyan_big
Change-Id: Ie4b6e25de63c0e216ae5de9bde20eed1fe3e59a6
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/195803
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
To support parsing multiple EDID blobs, the static "decode results" flags should
be changed to auto variables inside decode_edid.
This is done by packaging static variables into a structure inside decode_edid.
We also revised some functions (manufacturer_name, do_checksum) to avoid
accessing global variables directly. Extension (and detail block) parsing may
need to access and return all parsed context so we pass the whole structure to
it.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage
# See EDID parsed correctly on Nyan.
Change-Id: Ieca93d446bacf655c145dffdfa6cc6f5dc87ac26
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195372
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The "vbe_valid" flag is used by Coreboot table to notify payloads if a valid VBE
system is available. It is possible that display system initialization may fail
after a valid EDID is found. In that case, currently payloads will crash when
trying to output to video console.
The original intention for this portion of code is to add some check so
set_vbe_mode_info_valid can abort when no valid EDID is found. However now we do
have platforms (ex, ARM/Exynos) that hard codes EDID structure without calling
decode_edid, so we should let the callers decide if they want to continue
by the return value of decode_edid. We don't need to set vbe_valid when checksum
is correct.
It should be safe to remove the setting of vbe_valid in decode_edid function,
because vbe_valid is also set in set_vbe_mode_info_valid function. Currently all
devices calling decode_edid (tegra124, link, peppy, falco) do invoke
set_vbe_mode_info_valid after decode_edid.
BRANCH=none
BUG=none
TEST=Manually built and tested on following devices:
nyan_big, link, peppy, falco.
Change-Id: I5232bca92f73b21314d37dcd6c81578232318fd5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195371
Reviewed-by: Julius Werner <jwerner@chromium.org>
The cbmem console had been explicitly disabled in the bootblock because of
the complexity of handing off the console from the bootblock to the ROM stage.
The fixed cbmem location means no handoff is really necessary, so these can
be re-enabled.
Also include some other shared console drivers if they and bootblock console
have been enabled.
BUG=None
TEST=Built and booted on nyan and saw bootblock console output in cbmem. Built
for falco.
BRANCH=None
Change-Id: Iffe2747d6d526b58fabb0195f8744ae420f2e19d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193168
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
In E-EDID(EDID v1.3), Monitor Name (0xfc) and Monitor Range Limits (0xfd) are
always required. However, some panels do not really have these fields. As a
workaround (and since we don't really use these fields), we only print warning
messages for that case.
BUG=chrome-os-partner:27413
TEST=emerge-nyan coreboot chromeos-bootimage
Successfully decoded Nyan panels.
BRANCH=none
Change-Id: I81b1db7d7f6c6f9320a862608dec4c7be298d7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193742
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The current CBMEM console implementation can work in two different ways, one
that requires CAR migration which doesn't make sense on ARM and will break the
build, and a second which assumes 0x600 is a valid memory address which can be
used to keep track of the current location of the console. Neither of those
work on ARM.
To get around that problem, this change adds yet another flavor of behavior
to the cbmem console driver where it assumes the console is in a fixed place
before RAM is initialized (bootblock and ROM stage) and in CBMEM afterwards
(RAM stage). More specifically, the location of the console is always fixed
in a particular stage, attempts to set it are ignored, it's only initialized
in the earliest stage it's enabled, and cbmem reinitialization and migration
is ignored in RAM stage.
We really need to rework all the twisted paths through this code and reduce
it to one implementation that makes sense and works in all the situations it
needs to without all the extra complexity.
BUG=None
TEST=Built and booted on nyan with other changes that enable the console.
Ran cbmem -c and verified that output was preserved. Did the same on falco.
BRANCH=None
Change-Id: I05e75448be8572e2736d4d0e04997e536fb69396
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193166
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
On non-x86 systems, the location of the preram CBMEM console may not be in a
predictable place relative to other things in the linker script. That makes it
difficult to work with as its own section because the linker will complain if
you try to move backwards as it lays out memory. If the console header is
treated as an actual blob of memory which has to be put in the image, we'd
have to predict where to put it so that it isn't before something with a lower
address or after something with a higher address. Symbols, on the other hand,
can be defined arbitrarily.
BUG=None
TEST=Built and booted on link and falco. Spot checked that the CBMEM console
was the same as the output on the serial port.
BRANCH=None
Change-Id: I3257b981eee0c15bb997a9f2c55a03494c6ec6f0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193164
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
EDID v1.4 has changed some fields (0xfc - Monitor Name, 0xfd - Monitor Range
Limits) to optional so we need to list the requirements explicitly instead of
sharing v1.3 requirements.
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Successfully decoded Nyan panels.
BRANCH=none
Change-Id: I5c7ca06893bd20e178bc35164c4ca639c881e00b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193013
The detail block may contain timing descriptor, or other fields like monitor
descriptor, so we should return 1 in detailed_block function when a valid
structure is found, otherwise for any EDID containing monitor descriptor we will
see following error messages:
EDID block does not conform at all!
Detailed blocks filled with garbage
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage;
Manually executed on a Nayn and not seeing error message like
"Detailed blocks filled with garbage".
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: Ib4e91d648741e5b54a558d53a1152273c7341427
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193002
The ASCII Data String in EDID Monitor Descriptor (3.10.3) is "Stored as ASCII,
code page #437" and may contain special characters like '-'. The isalnum check
should be removed.
Also, the "Monitor Name" (0xfc) does not need to always end with 0Ah, so the
name_descriptor_terminated should be replaced by has_valid_string_termination.
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage;
Sucessfully decoded Monitor Descriptor with dash symbol (-) on Nyan.
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: I12a670237e12577fc971c0fbd9b2a61c82040ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193001
When parsing "extensions", we should skip the first EDID (main) block and start
from offset 128 (EDID may have only main block, so an EDID without any
extension is fine) because the header format for main block and extensions are
different.
Without this we will see "Unknown extension block" on all EDIDs, and seeing a
error (1) return value for EDIDs without extension.
Also, after the first "unknown" error is fixed, we can now collect all return
values from parse_extension, and give error when any of the extensions are wrong
(not just last one).
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Manually boot on Nyan and no "Unknown extension block" anymore.
Also tried EDID from following devices: Link, Peppy. Display panel
initialization is still functional.
Change-Id: I0ee029ac8ec6800687cd7749e23989399e721109
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193011
Some lines in decode_edid have incorrect indent levels.
BUG=none
TEST=emerge-nyan coreboot
BRANCH=none
Change-Id: Icc9cb57ff8dd2e2056599b3dc733fe5ac4e41c16
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193010
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The vboot implementation previously assumed that ramstage would
be a relocatable module. Allow for ramstage not being a relocatable
module.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot.
Change-Id: Id3544533740d77e2db6be3960bef0c129173bacc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190923
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The arm architecture currently exports cache_sync_instructions()
in <arch/cache.h>. In order for rmodule loading to work on arm
architectures the cache_sync_instructions() needs to be called to
sequence the instruction cache. To avoid sprinkling #ifdefs around
just add an empty cache_sync_instructions() definition.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted nyan and rambi.
Change-Id: I1a969757fffe0ca92754a0d953ba3630810556e3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191551
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
BUG=chrome-os-partner:26563
BRANCH=baytrail
TEST=Confirmed SMM backup region in cbmem. Suspend and Resumed.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188716
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186393
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is always built into coreboot, and is enabled by a static variable
in src/lib/hardwaremain.c. Payload choosing can be enabled at build
time, or at runtime via jtag/gdb.
The operation is simple. The chooser, if enabled, lists the payloads and puts
up a prompt.
Payloads:
fallback/payload
Pick one>
The user then types in the name of a payload, e.g.
Pick one>fallback/payload
The line is ended by newline or carriage return.
And the payload is booted.
If you get it wrong, no backspace
or correction. Just hit return and try again.
I started with Bayou but feel the need is low and the complexity
high for that solution; this is just much simpler.
So, let's think about some UI here. Some options:
- default to the first payload if the user hits return
- time out after 5 seconds or so
- Don't make people type the name;
number the payloads as they are printed and let the user
hit, say, 2, to get the second payload
What would you like to see?
BUG=None
TEST=Works on Nyan
BRANCH=None
Change-Id: I4f93633636abf73e65e1b14c1b9e77ac2e25c453
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180343
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
For choosing payloads we need to be able to read out all the payload
headers. cbfs_payload_headers() delivers names and all the info available
about any payloads.
BUG=None
TEST=builds, tested on Nyan, works fine.
BRANCH=None
Change-Id: If98437819d53cc01d175234fc7429d6aa3383c2c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180352
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
This will make it possible for payloads to find the ACPI
NVS region which is needed to get base addresses for devices
that are in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: Ia67b66ee8bd45ab8270444bbb2802080d31d14eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179849
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow ramstage cache to be used from ramstage proper. Also
add a helper function for checking validity of ramstage
cache structure.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: If1f2ad1bcf64504b42e315be243a12432b50e3d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179775
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's a slew of ports required to initialize baytrail's
perf and power values. Therefore, add the necessary
functionality in the iosf module as well as the reg_script
library.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted.
Change-Id: Id45def82f9b173abeba0e67e4055f21853e62772
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The reg_script library has proven to be useful. It's
also shown that many scripts operate on devices. However,
certain code paths run the same script on multiple,
but different, devices. In order to make that easier
introduce reg_script_run_on_dev() which takes a device
as a parameter. That way, chained reg_scripts are not
scrictly needed to run the same script on multiple devices.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I273499af4d303ebd7dc19e9b635ca23cf9bb2225
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179540
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
BUG=None
TEST=Made sure exceptions can fire and get handled correctly in romstage
and ramstage on Nyan and all three stages on Snow.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Print a space after a full stop.
BUG=none
TEST=boot tested
BRANCH=none
Change-Id: Ic7d0522ae35079b64ce61956d06ea59843ef9d80
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176756
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Add the LPSS IOSF port access to reg_script. This is
going to be used by baytrail.
BUG=chrome-os-partner:23790
BRANCH=None
TEST=Buit.
Change-Id: I0367acdb584f2de0bb871b136042b57fe6b7ec90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This required changing value/mask types to uint64_t.
Another option would be to use id field to select low or high
32 bits of the MSR and set them independently.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi
Change-Id: Ied9998058a8035bf3f003185236f3be3e0df7fc9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176304
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The reg_script stuff only makes sense for those platforms that
need it: ARM V8 and all x86. Have its usage controlled by a config variable.
BUG=None
TEST=the broken nyan build is fixed.
BRANCH=None
Change-Id: Iad54773f412e2d829e68b98fd845cd72ae408ee1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/175530
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.
There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi
Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The CBFS core checks the result of a media->map() operation in multiple
places for CBFS_MEDIA_INVALID_MAP_ADDRESS, suggesting that this is a
valid response. However, it ironically fails to do so when actually
mapping the CBFS file itself, which can fail on buffer-constrained
systems since the size is much larger than when mapping metadata. This
patch adds a check with an error message and a NULL pointer return for
that case to make it easier to understand this condition.
BUG=None
TEST=None
Change-Id: Icae3dd20d3d111cdfc4f2dc6397b52174349b140
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174951
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The load_stage_from_cbfs() when CONFIG_RELOCATABLE_RAMSTAGE is
selected is incorrect in that it hard coded the wrong stage name.
Instead it should honor the name past in instead of using a
predetermined (and wrong!) name.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built booted. Noted fallback path works.
Change-Id: I61654313d15167efe50d5e4ff24fb06eab16f389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174391
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
CQ-DEPEND=CL:172643
CQ-DEPEND=CL:*146397
CQ-DEPEND=CL:*146398
CQ-DEPEND=CL:*146435
CQ-DEPEND=CL:*146445
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
BUG=None
TEST=Built for link, lumpy, pit, and nyan. With this and other changes, got
bootblock serial output on nyan.
BRANCH=None
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
BUG=None
TEST=build and boot on peppy and get a screen, in both dev and normal modes.
BRANCH=None
Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
