Age | Commit message (Collapse) | Author |
|
Does not fix 3rdparty/, *.S or *.ld or yet.
Change-Id: I66b48013dd89540b35ab219d2b64bc13f5f19cda
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/17656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Currently this needlessly initializes the hardware in the both the
romstage and the bootblock, but it works.
Build option is renamed to USBDEBUG_IN_PRE_RAM to reflect the
use better, related support files can be built to pre-ram stages
regardless of usbdebug being enabled or not.
Tested on Google/peppy (adapted to C_ENVIRONMENT_BOOTBLOCK).
Change-Id: Ib77f2fc7f3d8fa524405601bae15cce9f76ffc6f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Expose the function that can unconditionally re-initialise
EHCI debug host and gadget.
Given the missing header in soc/intel files that prevented
building with USBDEBUG_IN_ROMSTAGE=y, it is not actually
known if those SOCs work at all for usbdebug.
Change-Id: I8ae7e144a89a8f7e5f9d307ba4e73d4f96401a79
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Remove all cases in code where we tested for
EARLY_CBMEM_INIT or LATE_CBMEM_INIT being set.
This also removes all references to LATE_CBMEM_INIT
in comments.
Change-Id: I4e47fb5c8a947d268f4840cfb9c0d3596fb9ab39
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/26827
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds two new post codes to indicate start and end of
memory param preparation in callbacks to SoC/mainboard code:
1. 0x34: Start of memory preparation
2. 0x36: End of memory preparation
These post codes are already used in coreboot. This change just
ensures that the codes are defined in post_codes.h for easy lookup.
These post codes are useful if SoC/mainboard decides to do a reset of
the platform before returning back to memory initialization.
Change-Id: I065518caedb7943d960a8a5c8708823b8eb3246d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/29150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a __noreturn macro that wraps __attribute__((noreturn)) and replace
current users with the macro.
Change-Id: Iddd0728cf79678c3d1c1f7e7946c27375a644a7d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/28505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I3e52569a34e1f7bfea8be9da91348c364ab705e1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
coreboot build is broken due to
CL: I6830a65bc9cea2907f4209bb97a53ccebcbf248d
This patch ensures to build coreboot successfully.
Change-Id: I4c9dfc9b19ce159ce1abcfbb287be4ce273cbaf1
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In some cases it may be useful to be able to bitbang a UART, such as
during early bring-up when a driver for the actual controller isn't
available yet. On some platforms we may even want to use this
permanently, such as on the SDM845 where the hardware UART controller
needs to have firmware loaded and is thus unavailable for most of the
bootblock.
This patch adds some helper code that makes it easy to implement this on
a platform, you just have to pass it a function to control the Tx pin
state and it will do the rest. It relies on the mono_time API and is
thus bound to microsecond timing granularity, but that seems to be
barely good enough for 115200 baud if the bit times are calculated
carefully.
Change-Id: If7dcecc7b8a95ec15f456efd2ec1f1e0dde239b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds a config option to allow mainboard to override
the console loglevel. When the option is set, the platform has
to define the function get_console_loglevel returning a valid
loglevel value.
This allows a mainboard to sample a GPIO to switch the loglevel
value between different environments (qualification vs production)
without re-flashing.
Change-Id: Id6cc72b8fe5c4c50a6f83ce80e6440b078eec6e2
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23712
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The rationale is to allow the mainboard to override the default
baudrate for instance by sampling GPIOs at boot.
A new configuration option is available for mainboards to select
this behaviour. It will then have to define the function
get_uart_baudrate to return the computed baudrate.
Change-Id: I970ee788bf90b9e1a8c6ccdc5eee8029d9af0ecc
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
There have been discussions about removing this since it does not seem
to be used much and only creates troubles for boards without defaults,
not to mention that it was configurable on many boards that do not
even feature uart.
It is still possible to configure the baudrate through the Kconfig
option.
Change-Id: I71698d9b188eeac73670b18b757dff5fcea0df41
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
It was originally designed such that if usbdebug_init() was called
before cbmem_initialize(), it would fetch the already-initialized
state from CBMEM. This changed when cbmem_find() behaviour changed
to require cbmem_initialize() to be called first. As a result,
ramstage had to reinitialize all of the EHCI controller and USB
endpoints on entry. This was slow, specially with AMD hardware
where one can scan USB ports to probe for the debug dongle.
For postcar and ramstage, move usbdebug entry such that it is
triggered from CBMEM_INIT_HOOK instead of console_init().
Side-effect of this is usbdebug console shows 'coreboot-xxx ...
starting...' line only for romstage.
Initialisation for usbdebug is never done in postcar. If you have
USBDEBUG_IN_ROMSTAGE=n, postcar will not have console output on
usb either.
While at it, fix also some other __PRE_RAM__ cases to ENV_ROMSTAGE
and alike.
Change-Id: If8ab973321a801abc5529f3ff68c5dccae9512ad
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Call weak method die_notify.
The method should be overwritten in mainboard directory to signal that
a fatal error had occurred. On boards that do share the same EC and where
the EC is capable of controlling LEDs or a buzzer the method can be
overwritten in EC directory instead.
Tested on Lenovo T500.
Change-Id: I71f8ddfc96047e8a0d39f084588db1fe2f251612
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19696
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
New post codes are
POST_FSP_MEMORY_EXIT
POST_FSP_SILICON_EXIT
This patch will make it more consistent to debug FSP hang
and reset issues.
Bug=none
Branch=none
TEST=Build and Boot on eve
Change-Id: I93004a09c2a3a97ac9458a0f686ab42415af19fb
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/20541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Also unify __attribute__ ((..)) to __attribute__((..)) and
handle ((__packed__)) like ((packed))
Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/15921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I7945ddb988262e7483da4e623cedf972380e65a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
If CONSOLE_SPI_FLASH config is enabled, we write the cbmem
messages to the 'CONSOLE' area in FMAP which allows us to grab the
log when we read the flash.
This is useful when you don't have usb debugging, and
UART lines are hard to find. Since a failure to boot would
require a hardware flasher anyways, we can get the log
at the same time.
This feature should only be used when no alternative is
found and only when we can't boot the system, because
excessive writes to the flash is not recommended.
This has been tested on purism/librem13 v2 and librem 15 v3 which
run Intel Skylake hardware. It has not been tested on other archs
or with a driver other than the fast_spi.
Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3
Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Reviewed-on: https://review.coreboot.org/19849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|
|
Change-Id: I3d0c61c37399e96c1d154c1d3af5c47db967a07a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19763
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|
|
Change-Id: Ib92550fe755293ce8c65edf59242a2b04327128e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19332
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
Changed a few comments to reduce line length. File
src/include/cpu/amd/vr.h was skipped.
TEST=Build and run on Galileo Gen2
Change-Id: Ie3c07111acc1f89923fb31135684a6d28a505b61
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18687
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: Comparisons should place the constant on the right side of the test
TEST=Build and run on Galileo Gen2
Change-Id: Id790e0034ea5c926fcaef95486319d6c0c936f28
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18682
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: please, no space before tabs
TEST=Build and run on Galileo Gen2
Change-Id: If60a58021d595289722d1d6064bea37b0b0bc039
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18652
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error found by checkpatch.pl:
ERROR: Macros with complex values should be enclosed in parentheses
False positives are detected for attribute macros. An example is:
ERROR: Macros with complex values should be enclosed in parentheses
+#define BOOT_STATE_INIT_ATTR __attribute__ ((used, section
(".bs_init")))
False positive also generated for macros for linker script files. An
example is:
ERROR: Macros with complex values should be enclosed in parentheses
+#define CBFS_CACHE(addr, size) \
+ REGION(cbfs_cache, addr, size, 4) \
+ ALIAS_REGION(cbfs_cache, preram_cbfs_cache) \
+ ALIAS_REGION(cbfs_cache, postram_cbfs_cache)
False positives generated for assembly code macros. An example is:
ERROR: Macros with complex values should be enclosed in parentheses
+#define DECLARE_OPTIONAL_REGION(name) asm (".weak _" #name ", _e" #name
)
False positive detected when macro includes multiple comma separated
values. The following code is from src/include/device/azalia_device.h:
#define AZALIA_SUBVENDOR(codec, val) \
(((codec) << 28) | (0x01720 << 8) | ((val) & 0xff)), \
(((codec) << 28) | (0x01721 << 8) | (((val) >> 8) & 0xff)), \
(((codec) << 28) | (0x01722 << 8) | (((val) >> 16) & 0xff)), \
(((codec) << 28) | (0x01723 << 8) | (((val) >> 24) & 0xff))
TEST=Build and run on Galileo Gen2
Change-Id: I6e3b6950738e6906851a172ba3a22e3d5af1e35d
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18649
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: space required after that ',' (ctx:VxV)
TEST=Build and run on Galileo Gen2
Change-Id: I297bfc3d03dc95b471d3bb4b13803e81963841b5
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18647
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Messages from AGESA proper are additionally controlled
by various IDS parameters in board/OptionsIds.h file.
Change-Id: I83e975d37ad2bdecb09c483ecae71c0ed6877731
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/18545
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The end of firmware notification is currently not being tracked
so it's hard to get good data on how long it takes. Update the
code to provide timestamp data as well as post codes.
BUG=chrome-os-partner:56656
Change-Id: I74c1043f2e72d9d85b23a99b8253ac465f62a7f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17373
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
|
|
Implement postcar stage cbmem console support. The postcar stage
is more like ramstage in that RAM is already up. Therefore, in
order to make the cbmem console reinit flow work one needs the cbmem
init hook infrastructure in place and the cbmem recovery called.
This call is added to x86/postcar.c to achieve that. Additionally,
one needs to provide postcar stage cbmem init hook callbacks for
the cbmem console library to use. A few other places need to
become postcar stage aware so that the code paths are taken.
Lastly, since postcar is backed by ram indicate that to the
cbmem backing store.
BUG=chrome-os-partner:57513
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The declarations for console_init() were unconditionally
exposed even though there is a Kconfig option. Correct this
by honoring the CONFIG_POSTCAR_CONSOLE condition.
BUG=chrome-os-partner:57513
Change-Id: Id45ae3d7c05a9f4ebcf85c446fc68a709513bb0f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16617
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Ic8ffd26e61c0c3f27872699bb6aa9c39204155b7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16390
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
Change the code guard for do_printk_va_list() accordingly, since it's
used by vboot (not Chrome OS) code.
Change-Id: I44e868d2fd8e1368eeda2f10a35d0a2bd7259759
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16230
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Add write line routine which is called indirectly by FSP.
TEST=Build and run on Galileo Gen2.
Change-Id: Idefb6e9ebe5a2b614055dabddc1882bfa3bba673
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16127
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I4d529f6393937e5b97d8546f9348b44a448330e8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/16007
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add a Kconfig value to enable the console during postcar. Add a call
to console_init at the beginning of the postcar stage in exit_car.S.
TEST=Build and run on Galileo Gen2
Change-Id: I66e2ec83344129ede2c7d6e5627c8062e28f50ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Id40c1bf868820c77ea20146d19c6d552c2f970c4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15942
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Build the UART drivers for the postcar stage.
TEST=Build and run on Galileo Gen2
Change-Id: I8bf51135ab7e62fa4bc3e8d45583f2feac56942f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15843
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I72f894fd14bf0e333d9fda970397a3c82de598c3
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/15121
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Allow the platform to override the input clock divider by adding the
uart_input_clock_divider routine. This routine combines the baud-rate
oversample divider with any other input clock divider. The default
routine returns 16 which is the standard baud-rate oversampling value.
A platform may override this default "weak" routine by providing a new
routine and selecting UART_OVERRIDE_INPUT_CLOCK_DIVIDER. This works
around ROMCC not supporting weak routines.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing is successful when CorebootPayloadPkg is able to properly
initialize the serial port without using built-in values.
Change-Id: Ieb6453b045d84702b8f730988d0fed9f253f63e2
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This just updates existing guard name comments on the header files
to match the actual #define name.
As a side effect, if there was no newline at the end of these files,
one was added.
Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- occured -> occurred
- accomodate -> accommodate
- existant -> existent
- asssertion -> assertion
- manangement -> management
- cotroller -> controller
Change-Id: Ibd6663752466d691fabbdc216ea05f2b58ac12d1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12850
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add post codes for the various FSP phases and use them as appropriate
in FSP 1.0 and 1.1 implementations.
This will make it more consistent to debug FSP hangs and resets.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados and chell
Change-Id: I32f8dde80a0c6c117fe0fa48cdfe2f9a83b9dbdf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3b616ff3c9d8b6d05c8bfe7f456f5c189e523547
Original-Change-Id: I081745dcc45b3e9e066ade2227e675801d6f669a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/313822
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12595
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It's been decided to only support ARM Trusted Firmware for
any EL3 monitor. That means any SoC that requires PSCI
needs to add its support for ATF otherwise multi-processor
bring up won't work.
Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11897
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The conditions in cbmem console for supporting verstage
were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle
the cbmem console enablement. Fix it so verstage is a first
class citizen for deciding actions pertaining to cbmem console.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using verstage. cbmem console
shows verstage output.
Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11820
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The EM100Pro allows the debug console to be sent over the SPI bus.
This is not yet working in romstage due to the use of static variables
in the SPI driver code. It is also not working on chipsets that have
SPI write buffers of less than 10 characters due to the 9 byte
command/header length specified by the EM100 protocol.
While this currently works only with the EM100, it seems like it would
be useful on any logic analyzer with SPI debug - just filter on command
bytes of 0x11.
Change-Id: Icd42ccd96cab0a10a4e70f4b02ecf9de8169564b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The proper log level for any given printk statement is up to the
interpretation of the developer. This results in console output with
somewhat inconsistent levels of verbosity. This patch clearly defines each
log level and its use case, hopefully resulting in less ambiguity for
developers.
The concern with this patch might be that it leaves a lot of preexisting
printk statements using a log level that is inconsistent with the
description. I think that *most* statements map to these extended
definitions very nicely. The most discrepancies are between debug and
spew, but I'm willing to say that 95% of statements with a level lower than
debug are correct by these definitions.
There was some discussion dating back to 2010 on the mailing list about
renaming these constants to lose the 'BIOS_' prefix and to consolidate
some of them into a single constant. I disagree that it is necessary
to merge any of them, I think they all have unique use cases. But I do
think that if you all agree with these definitions, it might be useful to
rename them to reflect their use cases.
I also will add that I believe removing BIOS_NEVER is a good idea. I do
not see the use case, and it's used in only 4 files.
Change-Id: I8aefdd9dee4cb4ad2fc78ee7133a93f8ddf0720b
Signed-off-by: Nicky Sielicki <nlsielicki@wisc.edu>
Reviewed-on: http://review.coreboot.org/10444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|