Low level 64 bit division and modulo functions are not available for
MIPS platforms, but are required by the printk formatter.
Modify the code to avoid 64 bit math when building for MIPS. In case
the user does print a value exceeding 2^32, send a few junk characters
to the output to indicate a corrupted value printed.
BRANCH=none
BUG=none
TEST=startup code on Urara properly prints CBFS address values which
are passed as 64 bit integers.
Change-Id: I25b8a900b3ba4ec1da3446dcc5f03101d5cdb757
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232294
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 9c0978d944.
The underlying assumption was that the only format specification which
required 64 bit division was '%L', and it was used on x86 only. It
turns out, that '%ll' also uses 64 bit division, and this format
specification is more popular in the code, which in turn results in
incorrect values printed when the caller passes in 64 bit numbers.
An alternative solution will be presented in the next patch.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ie671d49a5026eb3b0c3c250f365d725e3b19bb25
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232293
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a new option to the set of console UART choices and uses the
common console wrapper for bg4cd based devices.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=with the upcoming SOC specific patch applied, when building with
serial console enabled the following option shows up in
auto.conf:
CONFIG_CONSOLE_SERIAL_BG4CD=y
Change-Id: Id2aa2ed4827740aaf04514233bd57cd8df0fea55
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213370
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provided finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also removes the
never-used and never-working BOOTBLOCK_NORMAL mechanism from ARM, and
gave ARM64 its own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech
off the ARM one (currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219171
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch started out as an attempt to run linker scripts through the
preprocessor. However, since that required some more infrastructure
changes, the build system is so intertwined, and there are so many other
small issues that turned up and are easier to fix (and get running, and
test thoroughly) in a single go, it turned out a little bigger. In order
of appearance, it:
- wraps direct linker invocations in a macro to avoid the widespread
ifeq($(CONFIG_COMPILER_LLVM_CLANG),y) duplication.
- introduces an $(generic-deps) (equivalent to $(<class>-deps)) variable
for targets that all files depend on
- makes the $(src-to-obj) function usable in multiple places as the
authoritative way to get an output file name (even if the respective
source file is also under build/), and makes it preserve extensions on
everything except %.c and %.S (e.g. %.ld and %.asl)
- replaces the old $(<class>-postprocess) with a single
$(postprocessors) variable. The old ramstage-postprocess was weird
because it contained unescaped $(eval ...)s, meaning it gets executed
as soon as the variable is first substituted (and the other
$(eval ...) in the toplevel Makefile does essentially nothing). The
new mechanism is just $(eval ...)ed directly after the recursive parse
with no further magic. Files can freely append their own (escaped)
content to it and access variables valid in the calling context (like
$(<class>-objs)) directly.
- enhances the existing $(<class>-<type>-ccopts) mechanism with
$(<class>-generic-ccopts) and $(generic-<type>-ccopts) to reduce
duplication.
- makes .ld a type that can be added like a normal class file, causing
it to be preprocessed with the correct #defines for the current class
(needed for a follow-up feature). Migrates all linker scripts to this
mechanism, which allows us to get rid of the weird $(ldoptions)
mechanism (Kconfigs are replaced by preprocessor and no longer need to
be defined as symbols).
- removes duplicate $(INCLUDES) from $(CFLAGS)
- repairs the crazy state of MIPS Makefiles, which seem to have been
copied together from X86 despite having absolutely nothing in common
with that architecture. They were using the same code to paste
assembly pieces and linker scripts together without really needing it
for anything, and even accidentally relied on a Kconfig default set
in the arch/x86 subdirectory (I wish I was kidding). Changed them to
work equivalent to the arm/arm64 Makefiles which are far closer
related (also being SRAM-based platforms).
- moves the x86-specifc $(OPTION_TABLES_H) into the x86 Makefile.inc and
fixes an rule that would've had an empty target if it wasn't defined
- removes the custom ldscript-gathering variables for x86 bootblock and
romstage. The Makefile simply combines all .ld files that have been
added to the respective class now.
- uses the normal class build system to replace some of the custom rules
for autogenerated bootblock/crt0 files on x86, and removes some
hardcoded flags by using the normal $(...-ccopts) variables.
- moves the handling of .asl files from the global Makefile.inc to x86.
Changed to reuse the generic template for the preprocessing and C
compilation steps.
- removed the extra <name>.o linking step before linking an rmodule for
modules that don't require special linker flags (most of them).
- removes the incorrect assumption that there was a global $(LDFLAGS)
from the SMM Makefile.inc (it was named $(LDFLAGFS in one place so it
couldn't have been all that important ;) ).
- allow -j flag for parallel builds to be properly passed through to
vboot child invocation by using special $(MAKE) variable.
BUG=None
TEST=Built for Falco, Nyan_Blaze, Stout, Rush_Ryu and Urara. Binary
diffed old and new coreboot.rom (and some manually uncompressed stages),
confirmed that images/stages are byte-for-byte identical except for some
embedded timestamps and commit hashes. (Addresses in Falco/Stout
ramstages shifting slightly due to different link order for ASL object
files within their directory. Some addresses in Urara ramstage .rodata
and some relocation entries in rmodules moved around due to linking them
in fewer steps.)
Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214371
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Reviewed-on: https://chromium-review.googlesource.com/212365
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I41f03ea8c8104ba2dd9f532b084696385d29636c
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/207973
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
The 64 bit division function is not readily available from the MIPS
toolchain inside chroot. This causes link failures when building
upcoming MIPS coreboot targets.
It turns out that the only place using the 64 bit division is the
printf formatter when processing the '%L' format specification.
Further examining of the source code has shown that so far the '%L'
format specification is used only in x86 code.
The suggested fix is to suppress %L support for MIPS.
BUG=chromium:406038
TEST=with this patch the upcoming MIPS platforms build successfully.
Change-Id: Iec0123620ac84a1697892f995235511b3288d4b2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214174
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
vprintk is created out of do_printk for all the archs.
BUG=none
TEST=Built Nyans, Falco, and Ryu. Verified serial output on Blaze and Falco.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Idf708359f0e9e9a9f32a601a5a117e469d5025ba
Reviewed-on: https://chromium-review.googlesource.com/214566
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Reviewed-on: https://chromium-review.googlesource.com/204522
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
This is just a convenience - when printing a pre-ram coreboot banner,
add the actual stage name to it.
BUG=none
TEST=manual
. with CONFIG_EARLY_CONSOLE enabled the banners look as follows (the
last one is for ramstage reads 'booting' instead of 'starting'):
coreboot-4.0 bootblock Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 romstage Tue May 13 14:13:37 PDT 2014 starting...
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 booting...
Change-Id: I218c0d3bbfa4a9bdff5632855c520af8626d6495
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199671
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch it the last one in the chain adapting the ipq9064 UART
driver for use in coreboot. A new config option
(CONSOLE_SERIAL_IPQ806X) is being introduced to control inclusion of
the driver.
The previously introduced uart_wrapper.c is now included in the build
to provide the console driver structure used by ramstage.
Necessary configuration options are added to allow use of UART in the
bootblock.
BUG=chrome-os-partner:27784
TEST=with this change the coreboot image on AP148 prints a banner on
start up:
coreboot-4.0 Wed Apr 23 16:24:51 PDT 2014 starting...
Change-Id: I129ee30ba17a5061b30cfee56c135df31eba98b5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196663
Coreboot is designed to have a single serial console at most, on top
of that it may have a CBMEM (virtual) console. Matters are complicated
by the fact that console interface is different between bootblock and
later stages.
A linker list of console driver descriptors is used to allow to
determine the set and type of console drivers at compile time. Even
though the upstream seems to have done away with this approach, which
does not seem the best idea.
As an alternative this patch introduces a common wrapper which
different UART drivers can plug in into. The driver exports a single
API which can be used both directly (in bootblock) and through the
wrapper (in later stages).
The existing drivers can be adjusted to fit this scheme one by one.
The common UART driver API also aligns fine with the upstream
approach.
BUG=chrome-os-partner:27784
TEST=none yet
Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196660
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
This patch brings in ipq806x source files from the vendor's u-boot
tree as it was published in the 'cs_banana' release.
The following files are being copied:
arch/arm/cpu/armv7/ipq/clock.c => src/soc/qualcomm/ipq806x/clock.c
arch/arm/cpu/armv7/ipq/gpio.c => src/soc/qualcomm/ipq806x/gpio.c
arch/arm/cpu/armv7/ipq/timer.c => src/soc/qualcomm/ipq806x/timer.c
arch/arm/include/asm/arch-ipq806x/clock.h => src/soc/qualcomm/ipq806x/clock.h
arch/arm/include/asm/arch-ipq806x/gpio.h => src/soc/qualcomm/ipq806x/gpio.h
arch/arm/include/asm/arch-ipq806x/gsbi.h => src/soc/qualcomm/ipq806x/gsbi.h
arch/arm/include/asm/arch-ipq806x/iomap.h => src/soc/qualcomm/ipq806x/iomap.h
arch/arm/include/asm/arch-ipq806x/timer.h src/soc/qualcomm/ipq806x/timer.h
arch/arm/include/asm/arch-ipq806x/uart.h => src/soc/qualcomm/ipq806x/uart.h
board/qcom/ipq806x_cdp/ipq806x_cdp.c => src/mainboard/google/storm/cdp.c
board/qcom/ipq806x_cdp/ipq806x_cdp.h => src/soc/qualcomm/ipq8064/cdp.h
drivers/serial/ipq806x_uart.c => src/console/ipq806x_console.c
Note that local timer.c gets overwritten with the original version. To
prevent a build breakage some shortly to be reverted modifications had
to be made to src/soc/qualcomm/ipq806x/Makefile.inc and
src/soc/qualcomm/ipq806x/cbfs.c.
BRANCH=none
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Change-Id: I3f50bfbec2e18a3b5d2c640cff353a26f88c98c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193722
Reviewed-by: David Hendricks <dhendrix@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>
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
Change-Id: Id6c8c7675daafe07aa4878cfcf13faefe576e520
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
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.
BUG=None
TEST=Built for rambi and verified that CONSOLE_CBMEM was still enabled. Built
for nyan and verified that it still wasn't.
BRANCH=None
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>
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>
Right now some console specific objects are included
in the bootblock even if CONFIG_BOOTBLOCK_CONSOLE is
disabled while others are not. Make all of them conditional
and also fix a preprocessor misuse in bootblock_simple.c
and a stray (useless) die() in the Exynos wakeup code that
made inclusion of those files necessary.
BRANCH=none
BUG=none
TEST=boot tested on pit
Change-Id: Ia7f9d17654466f199b0e13afbdc9e14c9706530f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168772
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=none
BRANCH=none
Change-Id: I3979be4b1d67de27275bc7ba4f45131b09a276f0
Reviewed-on: https://gerrit.chromium.org/gerrit/59323
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This was used by Ron 13ys ago and was never used again
ever since.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
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>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
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.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: emerge-slippy chromeos-coreboot-slippy
This adds new infrastructure that is not used yet.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: verify post codes in CMOS during suspend/resume test
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It makes much more sense to use CONFIG_USE_OPTION_TABLE instead
of CONFIG_HAVE_CMOS_DEFAULT. As we want to read the used
debug_level from our CMOS. This change makes it possible to
change log_debug via nvramtool and make use of the new
value after a reboot/poweroff.
CONFIG_HAVE_CMOS_DEFAULT does have an other meaning
Change-Id: I438dd01a2b4171dba2b73f2001511c71f4317725
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM
rely on EARLY_CBMEM_INIT. This isn't true in the face of
DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT.
Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM
when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem
implementation when COLLECT_TIMESTAMPS is selected.
Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On ARMv7 the console code can also be built into
the bootblock. Currently building the ARM targets
on a reasonably fast machine can fail, because
console.bootblock.o is attempted to build before
build.h is created. This patch adds a specific
rule for the bootblock variant of console.c, to
match the other variants so that the race condition
goes away.
Change-Id: I52e4242c66a02f011ef26b854aa50c2606a1f81f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2873
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This eliminates the use of do_div() in favor of using libgcc
functions.
This was tested by building and booting on Google Snow (ARMv7)
and Qemu (x86). printk()s which use division in vtxprintf() look good.
Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Just a tiny mistake, but it made the console driver assume that
CMOS data isn't available.
Change-Id: I4e6f53e9ed59024de7b09333f82f0ce3235ef8f6
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/2323
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Revise console source file dependency (especially for EARLY_CONSOLE) and
interpret printk/console_init according to EARLY_CONSOLE setting (no-ops if
EARLY_CONSOLE is not defined).
Verified to boot on x86/qemu and armv7/snow. Disabling EARLY_CONSOLE correctly
stops romstage messages on x86/qemu (armv7/snow needs more changes to work).
Change-Id: Idbbd3a26bc1135c9d3ae282aad486961fb60e0ea
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2300
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Early console should always be allowed to be turned on / off (for generating
production and debug versions), and should not be enforced by "select" Kconfig
rule.
A new "DEFAULT_EARLY_CONSOLE" is introduced for devices to select if they
prefer early console output by default.
Verified Kconfig value on qemu/x86 (default y by CACHE_AS_RAM), snow/x86
(default y by EXYNOS5 config), and intel/jarrell (default n).
Change-Id: Ib1cc76d4ec115a302b95e7317224f1a40d1ab035
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2307
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The do_div code has a nice optimization in it when it is called with
constants. The current highly generalized use of it defeats those
optimizations and causes trouble on ARM, resulting in a complex and
buggy code path.
Since we only need to print in bases 8, 10, and 16, do a minor
restructuring of the code so that we call do_div with constants.
If you need base 2, print in base 16 and do it in your head. :-)
This fixes an ongoing problem with ARM, will not harm X86, and will
help PPC should we ever want to support it again.
Plus, I don't have to ever try to understand the div64 assembly and where
it's going wrong :-)
Change-Id: I6a480011916eb0834e05c5bb10909d83330fe797
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2235
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
During the ARM port, disabling serial console became broken.
This patch fixes it.
Change-Id: I40460596073918a08c19bb9c991cada341cca940
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2136
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch makes pre-RAM serial init more generic, particularly for
platforms which do not necessarily need cache-as-RAM in order to use
the serial console and do not have a standard 8250 serial port.
This adds a Kconfig variable to set romstage-* for very early serial
console init. The current method assumes that cache-as-RAM should
enable this, so to maintain compatibility selecting CACHE_AS_RAM will
also select EARLY_SERIAL_CONSOLE.
The UART code structure needs some rework, but the use of ROMCC,
romstage, and then ramstage makes things complex.
uart.h now includes all .h files for all uarts. All 2 of them.
This is actually a simplifying change.
Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2086
Tested-by: build bot (Jenkins)
Because they use outb instructions, they are bound to fail
on non-PC80 systems like ARM.
Change-Id: I679ac6c0964c06c369cc90556529bb6f629d56f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1974
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
get_option() is used to get a config option (debug loglevel) from
CMOS. However, not all machines have CMOS, so define a dummy inline
function that will return an error code so the caller (console_init())
will use the default loglevel.
Change-Id: I6adf371d79164178f40a83f7608289a6a7673357
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1962
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
