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
Some LPC initialiation can save some lines of code when being able
to use the functions `io_apic_read()` and `io_apic_write()`.
As these two functions are now public, remove them from the generic
driver as otherwise we get a build errors like the following.
[…]
Building roda/rk9; i386: ok, using i386-elf-gcc
Using payload /srv/jenkins/payloads/seabios/bios.bin.elf
Creating config file... (blobs, ccache) ok; Compiling image on 4 cpus in parallel .. FAILED after 12s!
Log excerpt:
coreboot-builds/roda_rk9/arch/x86/lib/ramstage.o: In function `io_apic_write':
/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/arch/x86/lib/ioapic.c:32: multiple definition of `io_apic_write'
coreboot-builds/roda_rk9/drivers/generic/ioapic/ramstage.o:/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/drivers/generic/ioapic/ioapic.c:22: first defined here
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/roda_rk9/generated/coreboot_ram.o] Error 1
make: *** Waiting for unfinished jobs....
[…]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3180
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
(cherry picked from commit ac75bc682b)
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: Ie829995e842c33ea82920799430c3e9f813be3da
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196262
Reviewed-by: Aaron Durbin <adurbin@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>
This symbol is set using a config variable which can be set to something
appropriate by the SOC. If it isn't, the symbol is set to 0 which should be
caught by checks in the cbmem console itself.
BUG=None
TEST=Built for nyan with a cbmem buffer location set. Built for peach_pit
without a location set.
BRANCH=None
Change-Id: I92cd65bb6767a67637faf1dd3cdbe03e433724a9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193165
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>
Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...
This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.
Bug found in upstream NetBSD (who would've thought...).
BUG=None
TEST=Still boots.
Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Though vboot could be built for arm platforms the resulting
code was not being included in the cbfs. Now conditionally
include the vboot rmdoule like x86.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot. Confirmed being added to cbfs.
Change-Id: I677d0bf16dc488cf2d5b75dd1a65cf123d3ad9d2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190927
In order to build rmodules for armv7 boards, the default
compiler options need to be set so the assembler sources
can correclty compile. For now assume rmodules for arm
devices use the ramstage compiler options.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vboot as rmodule for nyan.
Change-Id: I8d12a2a57944b187cbdff2f22176de5b4de87a54
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190926
The arm architecture currently exports cache_sync_instructions()
in <arch/cache.h>. In order for rmodule loading to work on arm
architectures the cache_sync_instructions() needs to be called to
sequence the instruction cache. To avoid sprinkling #ifdefs around
just add an empty cache_sync_instructions() definition.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted nyan and rambi.
Change-Id: I1a969757fffe0ca92754a0d953ba3630810556e3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191551
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Initial SCTLR setup done in arm_init_caches for EL3 is now
copied when switching to EL2.
BUG=None
BRANCH=none
TEST=Run coreboot and check for correct SCTLR_EL2 value
Change-Id: I88942ae913cb80c5ca561e5bdd790732dc3348d7
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187468
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Increase available RAM to 16M, register a ram_resource to it
and enter ramstage. Bounce buffer seems to be broken yet,
so assign the payload entry to be above coreboot area at
0x80000000 and it should jump to it.
BUG=None
BRANCH=none
TEST=Boot to minimal payload at 0x80100000 which halts the emulation
Change-Id: I77d6c56f5d4104c95283598b3d6ddabb8e5d0c7b
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186745
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some 64-bit pointer casts errors related to
DYNAMIC_CBMEM were fixed in a separate patch.
BUG=None
BRANCH=none
TEST=Ran image in foundation model
Change-Id: Ia4cce9bef152e9acd9c897de895b7c293f7d2188
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186742
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Since booting Linux requires that we are running
at EL1 or EL2, transition already from EL3 to EL2.
It is assumed for now that the system implements
all exception levels, which is not a requirement.
BUG=None
BRANCH=none
TEST=Boot to ramstage worked as before and used current_el()
to verify that we are indeed at EL2
Change-Id: I29d8fc830367158cba53703d1dc2f0ad398b9d49
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186741
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This installs a exception vector in bootblock, aborts are now
handled with a register file dump to console for debugging.
BUG=None
BRANCH=none
TEST=Ran image in foundation model, tested some exceptions
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Change-Id: I4cb4d95fc5eb905f8c3c623315a46a00fdbf2677
Reviewed-on: https://chromium-review.googlesource.com/185755
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
This adds simple bootblock initialization procedures with console
ouput support for the Foundation ARMv8 model. Includes stack
setup, basic caches/tlb/mmu control routines, SCTLR register access
for different exception levels and memset.S code from ARM.
It runs on the Foundation_v8 fast model from arm (see command line
in src/mainboard/emulation/foundation-armv8/Kconfig) until loading
romstage at cbfs_load_stage(), where it currently halts. Code is
debugable using printk only (after console_init) because the
Foundation model does not provide bare metal debugging support (so
adding exception handling and stack/register dump might be useful).
BUG=None
BRANCH=none
TEST=Ran image in foundation model
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Change-Id: I81b12416424a02f24a80924791fc39d9411fa4b4
Reviewed-on: https://chromium-review.googlesource.com/185275
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
This change introduces LPAE for virtual address translation. To enable it, set
ARM_LPAE. Boot slows down about 4ms on Tegra124 with LPAE enabled.
TEST=Booted nyan with and without LPAE. Built nyan_big and daisy.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Change-Id: I74aa729b6fe6d243f57123dc792302359c661cad
Reviewed-on: https://chromium-review.googlesource.com/187862
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183891
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
CQ-DEPEND=CL:183877
BUG=None
TEST=Snow and Nyan still boot. Time between entering romstage main() and
the configure_l2ctlr() call on Nyan drops from 390ms to 0.3ms. Even with
icache turned on the old implementation took 7.8ms since it cleared the
cache multiple times with a slow algorithm.
Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
BUG=None
TEST=Ran with cache_test code (see separate CL) and closely examined the
resulting output. Made sure results look as expected (iterating through
all sets (inner) and ways (outer) for L1 and then L2 cache, extracting
the right numbers from CLIDR and CCSIDR, not touching anything twice).
Time for a single dcache_clean_invalidate_all() on Nyan drops from 3.7ms
to 0.3ms.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch pulls in NetBSD's full cache flushing algorithm for ARM, to
replace our old, slow and slightly overzealous C-only implementation.
It's a beautiful piece of code that manages to run on only caller-saved
registers (meaning it doesn't need to write to memory) in a very tight
loop, and it's BSD-licensed to boot (which we need for libpayload).
Unfortunately it's also not quite correct, but I can fix that. Pulling
the original in a separate commit to make it more obvious what changes
are mine.
BUG=None
TEST=None
Change-Id: I7a71c9e570866a6e25f756cb09ae2b6445048d83
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183878
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182212
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The memcpy/memset/memmove assembly implementations have been taken from
U-Boot, which originally got them from Linux. I turns out that they are
actually not that bad, but they could use an update. This patch pulls in
the current Linux upstream versions of those files, removing some old
U-Boot cruft such as checking whether the two pointers in a memcpy() are
equal (really now?) or side-stepping the R8 register because it was used
for special purposes. It also returns to the good old Linux
ENTRY/ENDPROC macros since we have them now anyway, and straightens out
the W() macro in preparation for unified thumb support.
BUG=None
TEST=Snow still boots.
Change-Id: I138af269b423bef0a237759ac29f1ee58ca206a0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182179
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
BUG=None
TEST=Snow still boots.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is for the aarch64 architecture. A followon patch will be for the
ARM Ltd. v8 cpu implementation, followed by a mainboard.
This builds but will require the two follow on patches and my recently submitted
cbfstool patch if you wish to see what it looks like.
It is missing critical support for functions such as memcpy, etc. but my goal
is to get an early view of where it is going to the community.
The initial test will be getting it to halt correctly.
BUG=None
TEST=it breaks no builds
BRANCH=None
Change-Id: Ic298fa5c86547bbe3ca0545d338877673219cfd4
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180178
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
At least when building with the gnu toolchain, the headers the linker
automatically generate save space for the actual ELF headers in one of the
loadable segments. This creates two problems. First, the data you intended to
be at the start of the image doesn't actually show up there, it's actually the
ELF headers. Second, the ELF headers are essentially useless for firmware
since there's currently nothing to tell you where they are, and even if there
was, there isn't much of a reason to look at them. They're useful in userspace
for, for instance, the dynamic linker, but not really in firmware.
This change adds a PHDRS construct to each of the linker scripts used on ARM
which define a single segment called to_load which does not have the flag set
which would tell the linker to put headers in it. The first section defined in
the script has ": to_load" to tell the linker which segment to put it in, and
from that point on the other sections go in there by default.
BUG=None
TEST=Built and booted on nyan. Verified that the ROM stage was less than 18KB.
Reverted the change which forced ROM stage alignment and saw that the ROM
stage stayed the same size.
BRANCH=None
Change-Id: Ie2670f33f0421b16b2d4663fbfa99358890c77e4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180163
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
