With the proper configuration flags enabled, do_printk is available
from src/console, no need to define it elsewhere.
BUG=chrome-os-partner:31438
TEST=with upcoming patches, the urara board coreboot builds fine
Change-Id: Ib1e3e5750cdc1adc509b4580a4f24d3ff3b105ee
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215862
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the build infrastructure and basic architectural support required
to build for targets using the MIPS architecture. This is sufficient
to run on a simulator, but will require the addition of some cache
maintenance and timer setup in order to run on real hardware.
BUG=chrome-os-partner:31438, chromium:409082
TEST=none yet
Change-Id: If4f99554463bd3760fc142477440326fd16c67cc
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207972
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>
These symbols should have been removed with the stack
refactoring. I'm not sure how it was missed.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted into kernel with both cpus.
Change-Id: I17bc9a7aaaf133f427b15f803a6003fa2ca8f8a6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215541
Provides a minimal API for coordinating with the SoC for
bringing up the secondary CPUs. There's no eventloop or
dispatcher currently nor does it do anything proper when
one of the secondary CPUs are brought up. Those decisions
are deferred to the SoC.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and brought up 2nd cpu using this API.
Change-Id: I3b7334b7d2df2df093cdc0cbb997e8230d3b2685
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214775
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
exception_hwinit() provides a path for just setting the hardware
state. This allows for other CPUs but the boot CPU for setting up
the appropriate vector table.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted to the kernel.
Change-Id: Ib09c813b49a4f00daca0b53d9dca972251fcf476
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214773
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
No need to pass in the same value for the ttb after just
calling mmu_init(). All current users are setting this once
and forgetting it.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I54c7e4892d44ea6129429d8a46461d089dd8e2a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214772
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
To allow setting the entry point for the secondary CPUs
provide a pointer, c_entry, which contains the location
to branc to after setting up the stack.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted to the kernel on ryu.
Change-Id: Ic2f6c79cde708b24c379345aed1e2cc0760ccad8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214771
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Move the stack seeding out of assembly and into C so the
code in stage_entry.S can more easily be used. The seeding
of the stack doesn't touch at least 256 bytes to account
for current usage at time fo the call.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted into kernel on ryu.
Change-Id: I44004220a02b1ff06d27a0555eb4e96d9e213544
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214770
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of defining the stacks by Kconfig options include
the stack sizes for all the CPUs including each of their
exception stacks. This allows for providing each CPU
on startup a stack to work with.
Note: this currently inherits CONFIG_STACK_SIZE from x86 because
of the Kconfig mess of options not being guarded.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted into the kernel on ryu.
Change-Id: Ica09dc256e6ce1dd032433d071894af5f445acdb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214669
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Provide a common entry point arm64 cores coming out of reset. Also,
take into account CONFIG_ARM64_CPUS_START_IN_ELx to set the
correct SCTLR_ELx register. The SCR_EL3 initialization was removed
as that can be done in policy code in C later. Part of this refactor
allows for greater code reuse for the secure monitor.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=built and booted to linux on ryu
Change-Id: If16b3f979923ec8add59854db6bad4aaed35e3aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214668
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Depending on the armv8 implementation the cpus could start in
EL1, EL2, or EL3. Therefore allow the SoC to select the appropriate
mode.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built.
Change-Id: Id063681ef7691097e528c105fffac5d467585e4e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214666
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There are 2 things wrong with the current implementation:
1. the stack isn't guaranteed to be aligned to CONFIG_STACK_SIZE.
2. the stack isn't necessarily CONFIG_STACK_SIZE bytes.
Utilize the smp_processor_id() function to obtain the correct
cpu_info structure to obtain the correct index.
BUG=chrome-os-partner:31545
BRANC=None
TEST=Built and booted.
Change-Id: I2825118e2313dbbf13712a4afdfa05a2e38ee3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214665
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
In order to accomodate MP on arm64 one needs to be able to determine
the current logical processor id. Because it depends on the SoC
implementation the SoC needs to provide this implementation.
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built.
Change-Id: I9511b54b5a1ab340b0f1309b0d9976be68b50903
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214663
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This just removes some unneeded symbols and comments. Additionally,
moved most of the absolute symbols into the individual sections.
Also, aligned data sections to 64 bytes (typical cache line size).
BUG=chrome-os-partner:31545
BRANCH=None
TEST=Built and booted through coreboot normally on ryu.
Change-Id: I304e3702247a06507f5f4e23f8776331a3562c68
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214662
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As MIPS toolchain does not provide adequate support for 64 bit
division and shift operations, the missing functions are required to
be provided by the user.
This patch brings in the Linux implementation of the 64 bit arithmetic
shift borrowed from arch/mips/lib/ashldi3.c.
BUG=chromium:406038
TEST=With the upcoming patches coreboot successfully builds for MIPS
targets in chroot (coming later).
Change-Id: Ia1ccb29d4c9f3c95e04e06f6af7ce8a00e2e7455
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214156
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:31515
BRANCH=None
TEST=test_exception generates a page fault which is handled by the exception
handler and execution continues after eret from the exception
Change-Id: I29b7dabaece9b11a04ee3628d83513d30eb07b1d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/213661
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Non-cacheable normal memory is needed when one wants an easy way
to have a DMA region. That way all the reads and writes will be
picked up by the CPU and the device without any cache management
operations.
BUG=chrome-os-partner:31293
BRANCH=None
TEST=With a bevy of other patches can use a carved out DMA region
for talking to USB.
Change-Id: I36b7fc276467fe3e9cec4d602652d6fa8098c133
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212160
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add smbios type 17 which can optionally be implemented
at the platform or mainboard level
In order to create SMBIOS type17, you will need to fill
memory_info data
BUG=None
BRANCH=None
TEST=Compile successfully on rambi and samus
Boot to chromeOS on samus and rambi
Change-Id: Ie4da89135c879d7a687305d423103fcfcbb96e3f
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/210005
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It's helpful to view program size by inspecting the symbols.
_start and _end exist on romstage and ramstage. In order to
be consistent add _end for bootblock too.
BUG=None
BRANCH=None
TEST=Built and noted bootblock has _end symbol.
Change-Id: I7f0b4dd4078c7d23c70949563b4c3f4df9e66142
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210832
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Currently, the rmodules inclusion for vboot is dependent on ramstage_arch.
This change adds dependency on romstage_arch, since vboot is associated with
romstage. Inclusion based on ramstage_arch is left as is in case someone needs
it in ramstage.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for link, rush and nyan
Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209568
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The arm architectures have a stage_exit() function
which takes a void * pointer as an entry point. Provide
the same API for x86. This can make the booting paths
less architecture-specific.
BUG=chrome-os-partner:30784
TEST=built for nyan.
Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5086
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://chromium-review.googlesource.com/209591
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Add support for initializing and enabling mmu for armv8. Using 64KiB granule and
33 bits per VA, thus total VA address space is 6GiB. PA Range is 64GiB. Makes
use of memrange library to get a list of all the mmap regions from the SoC to
initialize XLAT table.
Currently, all calculations in mmu.h are based on the assumptions that max 33
bits are used in VA and granule size is 64KiB. Changes in these assumptions will
have to reflect in the dependent calculations as well.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until "payload not found". Goes past
all the earlier alignment errors.
Change-Id: Iac1df15f0b81dcf64484a56b94f51357bcd67cc2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208761
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The CCSIDR_EL1 register has cache attribute information
for a given cache selection in CSSELR_EL1. However, the
cache isn't being selected before reading CCSIDR_EL1.
Instead use CTR_EL0 which better fits with the semantics
of dcache_line_bytes(). CTR_EL0 has the minimum data cache
line size of all caches in the system encoded in 19:16 encoded
as lg(line size in words).
BUG=None
TEST=Built.
Change-Id: I2cbf888a93031736e668918de928c3a99c26bedd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208720
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Some of the SoC's need an early hook to configure
certain registers. One example of this is on t132
where ramstage is the first thing being ran on the
arm64 core and it is the only entity that can configure
certain registers required for the rest of ramstage.
Therefore, provide the opportunity for the SoC to
implement such requirements.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot.
Change-Id: Ib352f3788872f888581b398c9b394b7c4e54b02a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208061
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Since RES1 and RES0 bits are marked as SBOP(Should-Be-One-or-Preserved) and
SBZP(Should-Be-Zero-or-Preserved) respectively, resetting the SCTLR and SCR
registers should be done with proper bitmask.
BUG=None
BRANCH=None
TEST=Compiles successfully and verified that the RES bits are preserved across
register writes.
Change-Id: I5094ba7e51e8ea6f7d7612ba4d11b10dcbdb1607
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/207815
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
To align with arm use the RAMSTAGE_BASE Kconfig option
for start of ramstage. Also, use 16-byte alignment for the
start and end of the secions. 4 bytes were previously used, but
it definitely seems more appropriate to at least have the heap
handing out 16-byte aligned pointers.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted through attempting to load payload
Change-Id: I39329055696ae21a9ed1d9a64769981ab4dcdddd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207432
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Inconsistent progress was observed running ramstage.
It was determined that the hand-coded assembly functions
were causing issues. Some of the comments seems suspect about
the hardware taking care of alignment. The prudent thing to do
is to use the C ones. Optimization can come later after maturity.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted to attempting to payload
Change-Id: I4137adf9b36b638ed207e4efd57adaac64c6a6c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207431
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Ramstage needs an assembly entry point for setting up
the initial state of the CPU. Therefore, a function is
provided, arm64_el3_startup(), that bootstraps the state
of the processor, initializes the stack pointer, and
branches to a defined entry symbol. To make this work
without adding too much preprocessor macro conditions
provide _stack and _estack for all the stages.
Currently the entry point after initialization is 'main',
however it can be changed/extended to do more work such
as seeding the stack contents with tombstones, etc.
It should be noted that romstage and bootblock weren't
tested. Only ramstage is known to work.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Brought up 64-bit ramstage on rush.
Change-Id: I1f07d5b6656e13e6667b038cdc1f4be8843d1960
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207262
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The driver structures live in special sections which have no
direct reference to the symbols. Therefore, when garbage
collecting sections in the liner the drivers are tossed out
resulting in no drivers being linked into ramstage. Fix this
by adding the KEEP() directive to those special sections.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and noted console starts working in ramstage.
Change-Id: Iaa0fd428bf975c82d4e6b0e75a17e6fd231fbaa9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207261
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Furquan Shaikh <furquan@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>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
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: Iad57741157ec70426c676e46c5855e6797ac1dac
Reviewed-on: https://chromium-review.googlesource.com/204376
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add basic romstage support for rush. Since, dram init needs to be done before we
can jump to armv8 core, romstage will run on armv4 core as well. Thus,
correcting the compiler selection options.
BUG=None
BRANCH=None
TEST=Compiles successfully for rush. Prints romstage banner and initial printk
Change-Id: Ie3cd290e56a712b07c1503dab199e4e34cec04d2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/205763
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Define functions for setting cntfrq register in arm and arm64 arch. This allows
SoCs to set this register independent of the architecture being used.
BUG=None
BRANCH=None
TEST=Compiles successfully for nyan and rush
Change-Id: I93240419b2c012eee29a408deff34a42af943a63
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/205580
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Add config option for customize this value by board.
BUG=chromium:366940
TEST=Manual add config for specific board and verify by dmidecode.
Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Change-Id: I6deb7f07c00c899bad1eb08fa6a2410deb7a8c6a
Reviewed-on: https://chromium-review.googlesource.com/203657
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Kevin Cheng <kevin.cheng@intel.com>
Tested-by: Kevin Cheng <kevin.cheng@intel.com>
Add XN/PXN bits to prevent cpu from fetching speculative instructions
on noncacheable region.
BUG=chrome-os-partner:28568
BRANCH=nyan
TEST=Build and run reboot tests on nyan_big
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I0cd2ad5a47a467ef609d30d42cd300b5ca45b77b
Reviewed-on: https://chromium-review.googlesource.com/203447
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
BUG=None
BRANCH=None
TEST=Compiled successfully for rush board with bootblock being armv4 and
romstage and ramstage being armv8
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199844
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and
COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these
attributes are associated with each of the stages.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Image booted
successfully on link, rambi and nyan.
Change-Id: I10d36ff950712756fb16dcb4d315924d177846b5
Reviewed-on: https://chromium-review.googlesource.com/195574
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others
from arch level Makefile.inc to top level Makefile.inc.
Also, organize Makefile.inc at arch level into per-stage rules and variables.
BUG=None
BRANCH=None
TEST=Compiled successfully. Image booted successfully on link,nyan and rambi.
Change-Id: I22f5ef692b740f84d73071534732286e809f3bc4
Reviewed-on: https://chromium-review.googlesource.com/195446
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names(bootblock, romstage) and to allow any
Makefile rule generalization. (Required for patches to be submitted later)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197835
Make sure it is initialized at different stages.
BUG=chrome-os-partner:27784
TEST=manual
. not much at this point, just verified that it compiles
Change-Id: I343e7a6648e2ca935606cd76befd204aabd93726
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196592