| Age | Commit message (Collapse) | Author |
|---|
|
The Kconfig declaration for FIXED_UART_FOR_CONSOLE was accidentally
placed inside an `if CONSOLE_SERIAL` in a96e66a (soc/intel: Clean mess
around UART_DEBUG).
TEST=Start a clean config, select intel/leafhill and disable serial
console. Confirm that config can be saved without error.
Change-Id: Ie41687e91af11a13697cbe25938dada2c74b40fb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Everything is wrong here, the Kconfig symbols are only the tip of the
iceberg. Based on Kconfig prompts the SoC code performed pad configu-
rations! I don't see why the person who configures coreboot should have
the board schematics at hand.
As a mitigation, we remove the prompts for UART_DEBUG, which is renamed
to INTEL_LPSS_UART_FOR_CONSOLE (because the former didn't really say
what it's about), and for UART_FOR_CONSOLE in case the former is selec-
ted.
Change-Id: Ibe2ed3cab0bb04bb23989c22da45299f088c758b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The dependencies of CONSOLE_SERIAL and DRIVERS_UART were somehow
backwards. Fix that. Now, CONSOLE_SERIAL depends on DRIVERS_UART,
because it's using its interface. The individual UART drivers
select DRIVERS_UART, because they implement the interface and
depend on the common UART code.
Some guards had to be fixed (using CONSOLE_SERIAL now instead of
DRIVERS_UART). Some other guards that were only about compilation
of units were removed. We want to build test as much as possible,
right?
Change-Id: I0ea73a8909f07202b23c88db93df74cf9dc8abf9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
CB:26053 changed coreboot's default loglevel from SPEW to DEBUG. This
may be the most reasonable choice for most users that are mostly
interested in the UART console. However, on Chrome OS devices the UART
is disabled for production configurations anyway, and instead they rely
heavily on the CBMEM console for remote debugging and bug reports. For
these kinds of cases more info is almost always better, and you can't
easily reproduce a remotely filed bug if you notice that you need some
info that is only provided by BIOS_SPEW. On the other hand, the cost of
logging extra info to the CBMEM console is pretty negligible.
Therefore, let's bump the loglevel for CONFIG_CHROMEOS in particular
back up to the maximum. (Unfortunately, it seems that you can't 'select'
a choice option from another option, so this has to go in the
console/Kconfig file.)
Change-Id: I50724e3f7f8f57fdbc5846f21babc71798b21b65
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/29144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It seems to be the only user of the USB debug driver. So having to
enable it separately seems wrong.
It still depends on the selection of the EHCI debug driver.
Change-Id: I5f5f38a912423d9b8f1e71ae875b6a14fdee651c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The former default SPEW is very noisy, intentionally. It is usually
only useful to debug specific issues and doesn't carry much infor-
mational value.
Reducing the loglevel should also mitigate overflows in pre-CBMEM
console buffers.
Change-Id: Iebcd4681572c58f1d17085c5ef01a2dd49e981ca
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26053
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Angel Pons
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
|
|
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>
|
|
It's hidden behind a configuration option `CONFIG_RAMSTAGE_LIBHWBASE`.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
v2: Also update 3rdparty/libhwbase to the latest master commit.
Change-Id: I8e8d50271b46aac1141f95ab55ad323ac0889a8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This reverts commit 2c8f3bd91b54e85b4d2e24894ee8bbbfb9ad8a31.
I mistakenly commited a WIP, sorry.
Change-Id: I3c66c688dbfd903ecf5303abcdf6b5ded84585c7
Reviewed-on: https://review.coreboot.org/17028
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
On other architectures, the serial ports aren't mapped at 0x3f8.
WIP: I'm not sure how exactly the dependency should be encoded in
Kconfig.
Change-Id: Ia1de545325a53607f62d08e76b2f61b25edbe6ef
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16982
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.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>
|
|
Those options have no effect or lead to compile error on ARM due
to fundamental incompatibilities. Add proper "depends on" clauses
to hide them.
Change-Id: I860fbd331439c25efd8aa92023195fda3add2e2c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Enable baud rates of 230400, 460800 and 921600. Leave the default set
to 115200.
TEST=Build and run on Galileo at 921600.
Change-Id: I8e3980f33665bc183b454cf97c68e297f1b0502c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13755
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add a "depends on SMP" to the value SQUELCH_EARLY_SMP Kconfig value to
disable its selection when SMP is not enabled.
TEST=Build for Galileo
Change-Id: Ia3aa1d2169ed793e1bb26538b74b12347453d5af
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13639
Tested-by: build bot (Jenkins)
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of depending BOOTBLOCK_CONSOLE on a set of architectures,
allow the arch or platform to specify whether it can provide a C
environment. This simplifies the selection logic.
Change-Id: Ia3e41796d9aea197cee0a073acce63761823c3aa
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I09943aafe29f6e7a2a878e7b6141661982dfc645
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add help and a comment about the serial IO port selection to give the
user better feedback when a port index is selected.
Change-Id: I4c1614be51aee0286308fbc5c24554e218120bf7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12487
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Intel cave creek chipset needs to have port 80 routing configured
before any post codes can be sent to port 80h. Sending post codes out
before the routing is done will hang the system.
This patch allows us to disable the first couple of post codes that go
out before the routing can be configured.
The Kconfig symbol is selected by the cave creek chipset (fsp_i89xx).
Change-Id: I9bf41669ec32744f87a1ed2de011d31c72ea38da
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12422
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: York Yang <york.yang@intel.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>
|
|
The new function can be compiled in only when serial console is
disabled.
When invoked, this function initializes the serial interface and dumps
the contents of the CBMEM console buffer to serial output.
BRANCH=none
BUG=chromium:475347
TEST=compiled for different platforms with and without serial console
enabled. No actual test of this function yet.
Change-Id: Ia8d16649dc9d09798fa6970f2cfd893438e00dc5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a38a8254dd788ad188ba2509b9ae117d6f699579
Original-Change-Id: Ib85759a2727e31ba1ca21da7e6c346e434f83b52
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265293
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9984
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Kconfig options pertaining cbmem console in the preram
environment no longer make sense with the linker script
changes. Remove them and their usage within cbmem_console.
Change-Id: Ibf61645ca2331e4851e748e4e7aa5059e1192ed7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9851
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
In addition to ARM based systems, allow MIPS based systems to select
bootblock console support.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I40e5d8b651102709118878a317f7e983a617f433
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a41853273ef9ae716d5645379fcef79c5771b87
Original-Change-Id: I41f03ea8c8104ba2dd9f532b084696385d29636c
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/207973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8769
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Currently on AMD boards no romstage messages can be saved in CBMEM, so
only messages from ramstage on will be stored in CBMEM. Other than
that nothing changes.
Enabling CBMEM console by default does not noticeably decrease boot
time as the messages are directly written to CAR or RAM.
The board status script under `util/board_status/` reads the coreboot
messages from CBMEM, which are then uploaded to the board status
repository. With CBMEM console disabled by default, currently no
coreboot console messages are uploaded to the board status repository,
although it is important to have those.
Enabling CBMEM console by default improves this situation, so that for
all boards at least ramstage messages are stored in the board status
repository.
Change-Id: I8d5a58c078325c43a0317bcfaafc722d039aab0b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5350
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
This was added to handle cases of Intel FSP platforms that had
EARLY_CBMEM_INIT but could not migrate CAR variables to CBMEM.
These boards were recently fixed.
To support combination of EARLY_CBMEM_INIT without CAR migration was
added maintenance effort with little benefits. You had no CBMEM
console for romstage and the few timestamps you could store were
circulated via PCI scratchpads or CMOS nvram.
Change-Id: I5cffb7f2b14c45b67ee70cf48be4d7a4c9e5f761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8636
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
If it's not supported on a particular board, either the build will fail or
checks within the cbmem console itself should detect the problem. There
shouldn't be random memory corruption any more.
BUG=None
TEST=Built with CONSOLE_CBMEM enabled on nyan and saw that it was actually
enabled.
BRANCH=None
Original-Change-Id: Id6c8c7675daafe07aa4878cfcf13faefe576e520
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193167
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 20b486443bfc2d93d72bbc9e496023a00ab9ab30)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I39fbcdff61f6d8f520f2e9d7612dee78e97898b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7748
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Use the value of CONSOLE_PRERAM_BUFFER_SIZE to determine if we can
do CBMEM console in bootblock and romstage. Kconfig forces it to zero
if _BASE is unset or we cannot do CAR migration on x86.
Add CBMEM console to bootblock, except for x86. Only one of bootblock
and romstage clears the pre-RAM buffer.
To start with empty console log on S3 wakeup, ramstage now clears
previous contents of CBMEM buffer if there was no pre-RAM buffer.
Unify Kconfig variable naming.
TODO: ARM configurations do not define PRERAM_BUFFER_BASE values.
Change-Id: I70d82da629529dbfd7bc9491223abd703cbc0115
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Works in the RISCV version of QEMU.
Note that the lzmadecode is so unclean that it needs a lot of work.
A cleanup is in progress.
We decided in Prague to do this as one thing, because it forms a nice case study
of the bare minimum you need to add to get a new architecture going in qemu.
Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7584
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
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.
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>
(cherry picked from commit a492761c27076bcac080013d509ae4aafd6dc3e3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7013
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is essentially a revert of commit 10bd772d. The CAR_MIGRATE
mechanism is only useful to migrate variables from a special region
(e.g. cache as RAM) into DRAM-backed CBMEM between different parts of
the romstage (it does not persist into ramstage). Since ARM devices use
SRAM for which there is no reason to become inaccessible in later parts
of the romstage, this mechanism isn't useful for them. Removing it makes
the romstage.ld script much simpler, which has the nice side-effect of
putting the BSS at the end of the memory image (so that cbfstool can
actually figure out that it doesn't need to be part of the ROM image).
Old-Change-Id: I50e91d8bd51b5deb19446d9da48699edecbef6ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176761
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ebfd698e57c902e2f39a0cfc1bc2b02665e47ec6)
console: Make cbmem depend on x86.
The cbmem implementation isn't supported on anything other than x86 right now
and actually causes memory corruption on ARM machines. Until that's fixed, this
will prevent people from turning it on and causing hard to track down errors.
Old-Change-Id: I00e8aacf008acfe2f76d4eab82570f7c1cc89cab
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/191107
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit e54f16e346a7f2c66d802fb78a6b24e53b732b83)
Squashed two related commits for cbmem support on arm.
Change-Id: I2be48cea348ee5dc8ca3632d743500aa111bab08
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6888
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
|
|
board_status shows that truncation of few KiB is pretty common.
So bump this value.
Change-Id: I78a16974846a59ee4eae782380e6d01d2fa324f2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6902
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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.
Old-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>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
|
|
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_.
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>
(cherry picked from commit a93900be8d8a8260db49e30737608f9161fbf249)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6715
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Use CONSOLE_POST because the preprocessor conditional in post_code()
in src/console/post.c depends on it, while POST_IO is used in another
conditional for sending the codes to an I/O port.
Change-Id: Ia044cffb5f0aad0f8b2bb04faa12df11a705757a
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6416
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Without this change, removal of default UART_FOR_CONSOLE entries
under mainboard/ Kconfig will remove this option entirely from
created .config file.
Change-Id: I11422ddb8c51abca177f999936c995ae0c91c459
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5626
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
We have means to easily disable a specific console in romstage if
necessary, so this global option makes little sense.
The option was initially introduced as a work-around for build issues
around CACHE_AS_RAM, ROMCC and ARCH_ARMV7 dependencies for UARTs.
Change-Id: I797bdd11a48ddd813d3ee7ccef9a0c050f16f669
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5607
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The port for console remains to be a compile time constant.
The Kconfig option is changed to select an UART port with index
to avoid putting map of UART base addresses in Kconfigs.
With this change it is possible to have other than debug console
on different UART port.
Change-Id: Ie1845a946f8d3b2604ef5404edb31b2e811f3ccd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5342
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Option DRIVERS_UART builds with support for UART hardware.
Option CONSOLE_SERIAL enables the console output for UART.
Those x86 boards that do not have serial port on SuperIO should select
NO_UART_ON_SUPERIO to disable 8250 UART for the default configuration.
Removes:
CONSOLE_SERIAL_UART
HAVE_UART_IO_MAPPED
HAVE_UART_MEMORY_MAPPED
Renames:
CONSOLE_SERIAL8250 -> DRIVERS_UART_8250IO
CONSOLE_SERIAL8250MEM -> DRIVERS_UART_8250MEM
Change-Id: Id3afa05f85c0d6849746886db8b6c2ed6c846b61
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5311
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: If92b50ab3888518228d2d3b76f5c50c4aef968dd
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4561
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This menu may become a bit more complicated with addition of
new USB hardware so move it out of console/.
Change-Id: Ieb330675b9227a3e53d093f7c2b5a65e3842dc82
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5307
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
If there is trouble setting up usbdebug, it may be useful to delay
usbdebug init to run in ramstage.
Change-Id: I31de5a06d3f9ce19f71c422cce0c8cb0fd50f396
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4488
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
No need to show the choice of USB port or controller in case of older
hardware where location for usbdebug was hardwired.
Change-Id: Ia186bf2c6ed60be2834cf6fd0a1965c8bf81ed4d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4290
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
Reviewed-on: http://review.coreboot.org/4229
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The main usbdebug file lib/usbdebug.c was removed from romstage
build with commit f8bf5a10 but the chipset-specific parts were not,
leading to unresolved symbol errors for AMD platforms.
Add a silent Kconfig variable USBDEBUG_IN_ROMSTAGE for convenient
use of this feature.
Change-Id: I0cd3fccf2612cf08497aa5c3750c89bf43ff69be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3983
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
As boards without EARLY_CBMEM_INIT do not initialize CBMEM in romstage,
and have no CAR migration, these features are available for ramstage only.
Change-Id: Ic3f77ccdedd4e71ba693619c02c9b98b328a0882
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
