| Age | Commit message (Collapse) | Author |
|---|
|
Without that fix we have with CONFIG_USE_OPTION_TABLE:
OPTION cmos_layout.bin
build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin
make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'. Stop.
rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c
That log was captured with make V=1 but the error also appear with make.
Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]:
PC Engines ALIX.1C: Add CMOS defaults.
[1] http://review.coreboot.org/#/c/3323/
Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3223
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This feature has not been used and was never fully integrated.
In the progress of cleaning up coreboot, let's drop it.
Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
it has been unused since 9 years or so, hence drop it.
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Some southbridges have code in their `lpc.c` files to dump the
I/O APIC registers.
printk(BIOS_SPEW, "Dumping IOAPIC registers\n");
for (i=0; i<3; i++) {
*ioapic_index = i;
printk(BIOS_SPEW, " reg 0x%04x:", i);
reg32 = *ioapic_data;
printk(BIOS_SPEW, " 0x%08x\n", reg32);
}
Add similar code to `src/arch/x86/lib/ioapic.c` so all boards using
the function `set_ioapic_id()` get the debug feature and the other
boards can be more easily adapted in follow-up patches.
Change-Id: Ic59c4c2213ed97bdf3798b3dc6e7cecc30e135d8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3184
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
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....
[…]
Change-Id: Id600007573ff011576967339cc66e6c883a2ed5a
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>
|
|
The old approach was to invalidate the entire TLB every time we set up
a table entry. This worked because we didn't turn the MMU on until
after we had set everything up. This patch uses the TLBIMVAA wrapper
to invalidate each entry as it's added/modified.
Change-Id: I27654a543a2015574d910e15d48b3d3845fdb6d1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3166
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
It is useful to be able to lock out certain address ranges,
NULL being the most important example.
void mmu_disable_range(unsigned long start_mb, unsigned long size_mb)
will allow us to lock out selected virtual addresses on MiB boundaries.
As in other ARM mmu functions, the addresses and quantities are in units
of MiB.
Change-Id: If516ce955ee2d12c5a409f25acbb5a4b424f699b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This adds an inline wrapper for the TLBIMVAA instruction (invalidate
unified TLB by MVA, all address space identifiers).
Change-Id: Ibcd289ecedaba8586ade26e36c177ff1fcaf91d3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3161
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Utilize the static boot state callback scheduling to initialize
and tear down the coverage infrastructure at the appropriate points.
The coverage initialization is performed at BS_PRE_DEVICE which is the
earliest point a callback can be called. The tear down occurs at the
2 exit points of ramstage: OS resume and payload boot.
Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's helpful to provide a distinct state that affirmatively
describes that OS resume will occur. The previous code included
the check and the actual resuming in one function. Because of this
grouping one had to annotate the innards of the ACPI resume
path to perform specific actions before OS resume. By providing
a distinct state in the boot state machine the necessary actions
can be scheduled accordingly without modifying the ACPI code.
Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3134
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Many of the boot state callbacks can be scheduled at compile time.
Therefore, provide a way for a compilation unit to inform the
boot state machine when its callbacks should be called. Each C
module can export the callbacks and their scheduling requirements
without changing the shared boot flow code.
Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3133
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds $$(INTERMEDIATE) as a pre-requisite for coreboot.rom on
armv7. It is modeled after the $(obj)/coreboot.rom rule for x86.
Change-Id: I483a88035fa2288829b6e042e51ef932c8c4f23c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2095
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2987
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).
Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
= udelay((N * 2) / (1.7 * 10^3))
The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))
There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.
Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
|
|
It's better to recognize aborts when they occur than to mask them to
discover them later without knowing where they actually came from.
Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3065
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.
This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.
Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
In such cases the safe versions of readl() and writel() should be
used anyway.
Note: This also fixes two dubious casts as to avoid breaking
compilation.
Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds condition codes when using the msr instruction. Although
described as "optional" in the Cortex-A series programmer's guide,
our experience with using the msr instruction in the payload suggests
that the condition code is not optional and that this only worked
in coreboot (and u-boot) because the processor comes up in SVC32 mode.
(credit to Gabe Black for finding this, I'm only uploading the patch)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b
Reviewed-on: http://review.coreboot.org/3037
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Adding a pxe rom manually is inconvenient.
With this patch, PXE ROM can be added automatically by selecting PXE_ROM in Kconfig.
I have tested this patch on AMD Parmer and Thatcher with iPXE.
iPXE would be a boot device in Seabios when pressing F12.
iPXE works well with coreboot and Seabios.
Change-Id: I2c4fc73fd9ae6c979f0af2290d410935f600e2c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3013
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There is a wildcard rule to include mainboard/fadt.c.
Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2940
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Use register-sized types in case the inline assembler doesn't do
so automatically.
Change-Id: I3202ba972ef2548323fe557f45dc4b0b1cf6c818
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2983
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
dcache_mmu_disable() no longer needs to have its own iterative loop
to select each cache level of cache since
dcache_clean_invalidate_all() does that now.
Change-Id: I5ca273f98943981b943c1c1622f4574d7133fb50
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2967
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This moves the dsb() before the loop to sync any outstanding memory
accesses, and adds an isb() after the loop to ensure all outstanding
instructions are completed.
Change-Id: I1a11b39f104ae780370cfd2db3badcf4e91dc017
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2929
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds a missing CSSELR write in the case of a dcache or unified
cache being invalidated by armv7_invalidate_caches(), ensuring that
all levels of dcache/unified cache are invalidated as expected when
the function is called.
Change-Id: Ie90184bf8a8181afa3afe0786897455b30b7f022
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2947
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This adds a call to tlb_invalidate_all() after configuring a range
of memory.
Change-Id: I558402e7e54b6bf9e0b013f153d9b84c0873a6cf
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2946
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This makes dcache maintenance functions operate on all levels
of cache instead of just the current one.
Change-Id: I2708fc7ba6da6740dbdfd733d937e7c943012d62
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2945
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This adds simple accessor functions for reading/writing L2CTLR.
Change-Id: I2768d00d5bb2c43e84741ccead81e529dac9254d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2948
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This makes it easier to copy + paste code into libpayload since
libpayload since both coreboot and libpayload have stdint.h and
it defines the types needed.
Change-Id: Ifa55f04a9bdddd17bc1a2679321a6744c75f25a8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2944
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds some paranoia to cache manipulation routines:
- "memory" is added to the clobber list for functions which clean
and/or invalidate dcache or TLB entries.
- Remove unneeded clobber list for read_sctlr()
Change-Id: Iaa82ef78bfdad4119f097c3b6db8219f29f832bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2928
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This iterates thru all cache levels and cleans + invalidates all
data and unified caches before disabling dcache and MMU.
Change-Id: I8a671b4c90d7b88b8d0a95947bfa17f912cebaa2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2930
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This is just a cosmetic change to dcache_op_mva() to (hopefully) make
it a easier to follow and more difficult to screw up.
Change-Id: Ia348b2d58f2f2bf5c3cafabcfba06bc411937dba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2927
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
'<' was used when '<<' is needed. Oops!
Change-Id: I8451f76888e86219df16b50739cd2c8db80dcb14
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2941
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This passes the correct value into dccimvac.
Change-Id: I6098440ea48a9b6429380d5913fce6d36e3afb41
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2926
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This fixes a couple issues with dcache_op_by_mva():
- Add missing data and instruction sync barriers.
- Removes unneded -1 from loop terminating condition.
Change-Id: I098388614397c1e53079c017d56b1cf3ef273676
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2913
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's not used (instead ARM puts it in Kconfig)
Change-Id: Ia22a7ac756bec4cb6fee00a4d946a020ea6290aa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2916
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
If a configuration was not using RELOCTABLE_RAMSTAGE, but it
was using HAVE_ACPI_RESUME then the ACPI memory was not being
marked as reserved to the OS. The reason is that memory is marked as
reserved during write_coreboot_table(). These reservations were
being added to cbmem after the call to write_coreboot_table(). In
the non-dynamic cbmem case this sequence is fine because cbmem area
is a fixed size and is already reserved. For the dynamic cbmem case
that no longer holds by the nature of the dynamic cbmem.
Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2897
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It was never used, because we pushed romstage_null into the CBFS
instead of romstage_xip. It's not surprising this worked, but it
was a crude hack. Get rid of all the intermediate objects that are
not needed.
This could probably be further simplified to use the default cbfs
mechanism in our build system instead of having a specific rule for
romstage, but that's for another day.
Change-Id: I492ca2015ec81e13499fcd8dd331371f46a31c78
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2912
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This adds new MMU setup code. Most notably, this version uses
cbmem_add() to determine the translation table base address, which
in turn is necessary to ensure payloads which wipe memory can tell
which regions to wipe out.
TODOs:
- Finish cleaning up references to old cache/MMU stuff
- Add L2 setup (from exynos_cache.c)
- Set up ranges dynamically rather than in ramstage's main().
Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2877
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
When the linking of ramstage was changed to use an intermeidate
object with all ramstage objects in it the .textfirst section
was introduced to keep the entry point at 0. However, the
section was not marked allocatable or executable. Nor was it
marked as @progbits. That didn't cause an issue on its own since
.textfirst was directly called out in the linker script. However,
the rmodule infrastructure relies on all the relocation entries
being included in the rmodule. Without the proper section attributes
the .rel.textfirst section entries were not being included in
the final ramstage rmodule.
Change-Id: I54e7055a19bee6c86e269eba047d9a560702afde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The ramstage is now linked using an intermediate object that
is created from the complete list of ramstage object files.
The rmodule code was developed when ramstage was linked using
an archive file. Because of the fact that the rmodule headers
are not referenced from any other object the link could start
by specifying the rmodule header object for ramstage. That,
however, is not the case as all ramstage objects are included
in the intermediate linked object. Therefore, the
ramstage_module_header.ramstage.o object file needs to be removed
from the object list for the ramstage rmodule.
Change-Id: I6a79b6f8dd1dbfe40fdc7753297243c3c9b45fae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The vboot module relied on being able to flush the console
after it called vtxprintf() from its log wrapper function.
Expose the console_tx_flush() function in romstage so the
vboot module can ensure messages are flushed.
Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2882
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
coreboot tables are, unlike general system tables, a platform
independent concept. Hence, use the same code for coreboot table
generation on all platforms. lib/coreboot_tables.c is based
on the x86 version of the file, because some important fixes
were missed on the ARMv7 version lately.
Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2863
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
The vboot_handoff structure contians the VbInitParams as well as the
shared vboot data. In order for the boot loader to find it, the
structure address and size needs to be obtained from the coreboot
tables.
Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as well
by choosing the RO path.
Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds a parallel implementation of cbmem that supports
dynamic sizing. The original implementation relied on reserving
a fixed-size block of memory for adding cbmem entries. In order to
allow for more flexibility for adding cbmem allocations the dynamic
cbmem infrastructure was developed as an alternative to the fixed block
approach. Also, the amount of memory to reserve for cbmem allocations
does not need to be known prior to the first allocation.
The dynamic cbmem code implements the same API as the existing cbmem
code except for cbmem_init() and cbmem_reinit(). The add and find
routines behave the same way. The dynamic cbmem infrastructure
uses a top down allocator that starts allocating from a board/chipset
defined function cbmem_top(). A root pointer lives just below
cbmem_top(). In turn that pointer points to the root block which
contains the entries for all the large alloctations. The corresponding
block for each large allocation falls just below the previous entry.
It should be noted that this implementation rounds all allocations
up to a 4096 byte granularity. Though a packing allocator could
be written for small allocations it was deemed OK to just fragment
the memory as there shouldn't be that many small allocations. The
result is less code with a tradeoff of some wasted memory.
+----------------------+ <- cbmem_top()
| +----| root pointer |
| | +----------------------+
| | | |--------+
| +--->| root block |-----+ |
| +----------------------+ | |
| | | | |
| | | | |
| | alloc N |<----+ |
| +----------------------+ |
| | | |
| | | |
\|/ | alloc N + 1 |<-------+
v +----------------------+
In addition to preserving the previous cbmem API, the dynamic
cbmem API allows for removing blocks from cbmem. This allows for
the boot process to allocate memory that can be discarded after
it's been used for performing more complex boot tasks in romstage.
In order to plumb this support in there were some issues to work
around regarding writing of coreboot tables. There were a few
assumptions to how cbmem was layed out which dictated some ifdef
guarding and other runtime checks so as not to incorrectly
tag the e820 and coreboot memory tables.
The example shown below is using dynamic cbmem infrastructure.
The reserved memory for cbmem is less than 512KiB.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000002ffff: RAM
2. 0000000000030000-000000000003ffff: RESERVED
3. 0000000000040000-000000000009ffff: RAM
4. 00000000000a0000-00000000000fffff: RESERVED
5. 0000000000100000-0000000000efffff: RAM
6. 0000000000f00000-0000000000ffffff: RESERVED
7. 0000000001000000-000000007bf80fff: RAM
8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES
9. 000000007c000000-000000007e9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-00000001005fffff: RAM
Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf
coreboot table: 948 bytes.
CBMEM ROOT 0. 7bfff000 00001000
MRC DATA 1. 7bffe000 00001000
ROMSTAGE 2. 7bffd000 00001000
TIME STAMP 3. 7bffc000 00001000
ROMSTG STCK 4. 7bff7000 00005000
CONSOLE 5. 7bfe7000 00010000
VBOOT 6. 7bfe6000 00001000
RAMSTAGE 7. 7bf98000 0004e000
GDT 8. 7bf97000 00001000
ACPI 9. 7bf8b000 0000c000
ACPI GNVS 10. 7bf8a000 00001000
SMBIOS 11. 7bf89000 00001000
COREBOOT 12. 7bf81000 00008000
And the corresponding e820 entries:
BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable
BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved
BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable
BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved
BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable
BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16
BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved
BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2848
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The standard string functions memcmp(), memset(), and memcpy()
are needed by most programs. The rmodules class provides a way to
build objects for the rmodules class. Those programs most likely need
the string functions. Therefore provide those standard functions to
be used by any generic rmodule program.
Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2821
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:
1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
is attempted to load where the relocatable ramstage resides the load
is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
using the romstage_handoff structure stored in cbmem. This region is
communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
and begin of execution of a elf payload is straight forward.
Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The romstage_handoff structure is intended to be a way for romstage and
ramstage to communicate with one another instead of using sideband
signals such as stuffing magic values in pci config or memory
scratch space. Initially this structure just contains a single region
that indicates to ramstage that it should reserve a memory region used
by the romstage. Ramstage looks for a romstage_handoff structure in cbmem
with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving
the region defined in the romstage_handoff structure.
Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2791
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The current ramstage code contains uses of symbols that cause issues
when the ramstage is relocatable. There are 2 scenarios resolved by this
patch:
1. Absolute symbols that are actually sizes/limits. The symbols are
problematic when relocating a program because there is no way to
distinguish a symbol that shouldn't be relocated and one that can.
The only way to handle these symbols is to write a program to post
process the relocations and keep a whitelist of ones that shouldn't
be relocated. I don't believe that is a route that should be taken
so fix the users of these sizes/limits encoded as absolute symbols
to calculate the size at runtime or dereference a variable in memory
containing the size/limit.
2. Absoulte symbols that were relocated to a fixed address. These
absolute symbols are generated by assembly files to be placed at a
fixed location. Again, these symbols are problematic because one
can't distinguish a symbol that can't be relocated. The symbols
are again resolved at runtime to allow for proper relocation.
For the symbols defining a size either use 2 symbols and calculate the
difference or provide a variable in memory containing the size.
Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2789
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This adds a function for using the DCCMVAC instruction (dcache clean
by MVA at point of coherency (main memory)). We already have the
inline defined, it's just not used by anything.
Change-Id: Ia0641566a8881335bed8da2963e1db8321d74267
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2871
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This adds a helper function for dcache ops by MVA which will perform
the specified operation on a given memory range. This will make it
more trivial to add other data cache maintenance routines.
Change-Id: I01d746d5fd2f4138257ca9cab9e9d738e73f8633
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2870
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This clarifies and/or fixes formatting of some comments and
alphabetizes some function prototypes and inlines. It also
corrects references to "modified virtual address" (MVA).
Change-Id: Ibcdda4febf915cc4a1996a5bbb4ffecbcb50a324
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2869
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This removes some old macros that we no longer use.
Change-Id: I9d87beb5c2deca228cdf89a98e54b2779be0f0ea
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2868
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This just moves cache maintenance stuff from the armv7 bootblock
code to cache.c
Change-Id: I0b3ab58a1d8a3fe3d9568e02e156a36b6f33ca0b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2867
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The cbfs stage loading routine already zeros out the full
memory region that a stage will be loaded. Therefore, it is
unnecessary to to clear the bss again after once ramstage starts.
Change-Id: Icc7021329dbf59bef948a41606f56746f21b507f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2865
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
For diagnostic purposes we had been dumping the assembly
code when stages.o was built. We've past the need to do this
and it's confusing to watch.
Change-Id: Ib84cb73ed9dad3454efcb2be90d990ce88575229
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2555
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Remove the spurious creation of a start symbol, and use the
stage_entry symbol directly.
Change-Id: Ia62d5c056ac8b20c8ffdb78bff3d306065b6c45f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2560
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
There are some external libraries that are built within
coreboot's environment that expect a more common C standard
environment. That includes things like inttypes.h and UINTx_MAX
macros. This provides the minimal amount of #defines and files
to build vboot_reference.
Change-Id: I95b1f38368747af7b63eaca3650239bb8119bb13
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2859
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds a new API for cache maintenance operations. The idea is
to be more explicit about operations that are going on so it's easier
to manage branch predictor, cache, and TLB cleans and invalidations.
Also, this adds some operations that were missing but required early
on, such as branch predictor invalidation. Instruction and sync
barriers were wrong earlier as well since the imported API assumed
we compield with -march=armv5 (which we don't) and was missing
wrappers for the native ARMv7 ISB/DSB/DMB instructions.
For now, this is a start and it gives us something we can easily use
in libpayload for doing things like cleaning and invalidating dcache
when doing DMA transfers.
TODO:
- Set cache policy explicitly before re-enabling. Right now it's left
at default.
- Finish deprecating old cache maintenance API.
- We do an extra icache/dcache flush when going from bootblock to
romstage.
Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Coreboot's ramstage defines certain sections/symbols in its fixed
static linker script. It uses these sections/symbols for locating the
drivers as well as its own program information. Add these sections
and symbols to the rmodule linker script so that ramstage can be
linked as an rmodule. These sections and symbols are a noop for other
rmodule-linked programs, but they are vital to the ramstage.
Also add a comment in coreboot_ram.ld to mirror any changes made there
to the rmodule linker script.
Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2786
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
In order to prepare the ramstage to be linked by the rmodule linker the
stack needs to be self-contained within the ramstage objects. The
reasoning is that the rmodule linker provides a way to define a heap,
but it doesn't currently have a region for the stack.
The downside to this is that memory footprint of the ramstage can change
when compared before this change. The size difference stems from the
link ordering of the objects as the stack is now defined within
c_start.S. The size fluctuation ranges from 0 to CONFIG_STACK_SIZE - 1
because of the previous behavior or aligning to CONFIG_STACK_SIZE. It
should be noted that such an alignment is unnecessary for 32-bit x86 as
the alignment requirement for the stacks are 4 byte alignment. Also the
memory footprint is still dominated by CONFIG_RAMTOP and CONFIG_RAMBASE.
Change-Id: I63a4ddd249104bc27aff2ab6b39fc6db12b54028
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2785
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
cbfstool usage change:
The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size".
The "locate" command was used to find a place to store ELF stage image in one
memory page. Its argument "-a (alignment)" was actually specifying the page size
instead of doing memory address alignment. This can be confusing when people are
trying to put a blob in aligned location (ex, microcode needs to be aligned in
0x10), and see this:
cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000
# output: 0x44, which does not look like aligned to 0x40000.
To prevent confusion, it's now switched to "-P/--page-size".
Verified by building i386/axus/tc320 (with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731
Reviewed-on: http://review.coreboot.org/2730
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Haswell CPUs require a FIT table in the firmware. This commit
adds rudimentary support for a FIT table. The number of entries
in the table is based on a configuration option. The code only
generates a type 0 entry. A follow-on tool will need to be developed
to populate the FIT entries as well as checksumming the table.
Verified image has a FIT pointer and table when option is selected.
Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2642
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Link native graphics commit 49428d84 [1]
Add support for Google's Chromebook Pixel
was missing some of the higher level bits, and hence could not be
used. This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.
1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.
While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.
[1] http://review.coreboot.org/2482
Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
|
|
There are 2 issues in lb_cleanup_memory_ranges(). The first
is that during sort there is a neighbor comparison that initially
starts with the current entry. The second issue is that merging
has an off by one comparison for adjacent entries.
Before:
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000efffff: RAM
4. 0000000000f00000-0000000000ffffff: RESERVED
5. 0000000001000000-00000000acebffff: RAM
6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
7. 00000000ad000000-00000000af9fffff: RESERVED
8. 00000000f0000000-00000000f3ffffff: RESERVED
9. 00000000fed10000-00000000fed17fff: RESERVED
10. 00000000fed18000-00000000fed18fff: RESERVED
11. 00000000fed19000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-000000018f5fffff: RAM
After:
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000efffff: RAM
4. 0000000000f00000-0000000000ffffff: RESERVED
5. 0000000001000000-00000000acebffff: RAM
6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
7. 00000000ad000000-00000000af9fffff: RESERVED
8. 00000000f0000000-00000000f3ffffff: RESERVED
9. 00000000fed10000-00000000fed19fff: RESERVED
10. 00000000fed84000-00000000fed84fff: RESERVED
11. 0000000100000000-000000018f5fffff: RAM
Change-Id: I656aab61b0ed4711c9dceaedb81c290d040ffdec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2671
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
This is previously used exception code from libpayload.
On startup it installs and then tests an exception handler.
The test is an unaligned memory operation.
Yes, we've seen what might be exceptions in the ramstage, and
it makes sense to handle them. This code is identical in structure
and operation to the previously committed payload exception handler,
though we reserve the right to change it as circumstances require.
The remaining question is whether we need it in romstage.
Change-Id: I24484686c33c9757af8ba171ebae9773828fb69d
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2614
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
I've used an operating system for over 10 years now that makes
UTF-8 easy. It's not called Linux or OSX.
When UTF-8 is needed, of course, then we can look again.
I can't think of a single redeeming feature of placing
it in the comment in this manner. It's certainy not
needed.
The inclusion of UTF-8 characters is inconvenient,
especially from a text terminal.
I don't really want to start using compose in
CROSH shell terminals on chromeos.
We might want to incorporate "no UTF-8" as a
commit filter. For now, get rid of these
characters.
Change-Id: If94cc657bae1dbd282bec8de6c5309b1f8da5659
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2604
Reviewed-by: Bernhard Urban <lewurm@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This reverts commit 1cd616082100f47dc2d6d73669c6aa2e5eb039ad
Division bites us again. I don't know how or why, but printk() seems to break (again) with this patch. I'm surprised we didn't encounter problems earlier on...
Change-Id: I81cb9f20879f5eb73a76e1af47b96a68d1e81dc8
TODO: Find a better solution for div64. This one is too painful, but seems necessary for now (and sort-of works with our vtxprintf hack).
Reviewed-on: http://review.coreboot.org/2600
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
While reading through the file fix some spotted errors like
indentation, locution(?), capitalization and missing full stops.
Change-Id: Id435b4750e329b06a9b36c1df2c39d2038a09b18
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2484
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.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>
|
|
This breaks booting, and in fact stages.c is always going to be special: for it to work it has to be compiled for arm only, no thumb allowed. It's probably better to leave the stages.o target in explicitly so it's clear that it has to be compiled with a particular set of flags, rather than try to remember that we must always have the default rules no break stages.c compilation. That would be a mess. I will be pushing a CL to get rid of the assembly dump, but will be a trivial fix.
This reverts commit 8f4647a24bf19a96531af9905b23ae8a2fc2675a
Change-Id: I5e3d8e5b991f6ccf4d49078378cd4615fb230ca0
Reviewed-on: http://review.coreboot.org/2554
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is a leftover from when we were debugging
this code. Let's make it easier to understand.
Change-Id: Ia3d0ab1504ff9dd9634d5f393d3c59fe1e43a0c0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2543
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Currently some southbridge codes implement the set_ioapic_id() part
locally and do not implement the load_vectors() part at all.
This change allows clean-up of those southbridges without introducing
changed behaviour.
Change-Id: Ic5e860b9b669ecd1e9ddac4bbb92d80bdb9c2fca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/300
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These were not separable or it would have been two CLs.
Enable CHROMEOS configure option on snow. Write gpio support code for
the mainboard. Right now the GPIO just returns hard-wired values for
"virtual" GPIOs.
Add a chromeos.c file for snow, needed to build.
This is tested and creates gpio table entries that our hardware can use.
Lots still missing but we can now start to fill in the blanks, since
we have enabled CHROMEOS for this board. We are getting further into
the process of actually booting a real kernel.
Change-Id: I5fdc68b0b76f9b2172271e991e11bef16f5adb27
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2467
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We don't need the overly complex optimized version, since
we're only doing this in very few non-critical places.
Also, add the div* files to the bootblock, they're needed
if we do printk.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I83bd766d4b03b488326ade1c13b7c364a7119e7b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2508
Tested-by: build bot (Jenkins)
|
|
If CONFIG_CONSOLE_SERIAL is set, and we can call the standard function
and get a non-zero uart address, then we create an lb table entry.
The code was mostly right, just needed a tweak.
Change-Id: I5b36c7b4e580a23319b7ba92cc8ad61592b1757a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2466
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
|
|
Payloads, by design, can return. There's lots of mechanism in the payload code
to support it, and the chooser payload relies on it. Hence, we should not mark
the function call in exit_stage as noreturn.
Not all ARM have unified caches, and it's not always easy to tell what
to do. So we are very paranoid. Before we call between stages, we
should carefully flush the dcache to memory and invalidate the icache.
This may be more than is necessary on all architectures but it
doesn't really hurt for the most part.
So compile cache management code into all stages, and call the
flush dcache/invalidate icache from all stages.
Change-Id: Ib9cc625c4dfd2d7d4b3c69a74686cc655a9d6484
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2462
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds necessary device operations to add CPU and RAM resources.
Change-Id: Ief8f66627ef37f4fa786bfc3f7899529d3e5b037
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2419
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds a simple loop which initializes the stack to 0xdeadbeef
which is used by checkstack().
Change-Id: I8aecf7bfb1067de68c4080c1fcb7eefa28fd04a7
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2421
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch fixes up the usage of stack pointer and regions.
The current approach only works by coincidence, so this fixes a few
things at once to get it into a working state and allow us to use
checkstack() again:
- Add a STACK_SIZE Kconfig variable. Earlier on it was evaluated to 0.
- Assign _stack and _estack using CPU-specific Kconfig variables since
it may reside elsewhere in memory (not necessarily DRAM).
- Make the existing IRAM stack variables more useful in this context.
Change-Id: I4ca5b5680c9ea7e26b1b2b6b3890e028188b51c2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2416
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Just a mechanical cleanup.
Change-Id: I0815625e629ab0b7ae6c948144085f1bd8cabfb5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2408
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
We don't need three different implementations.
Change-Id: Ie7b5fa90794676ea38838454a33e8e9188428eb7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2406
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
They're unused. Also drop some unused defines in system.h
Change-Id: Ia5afc3a676a4a94787041430f05d08f333033c73
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2404
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
We don't have asm/
Change-Id: I7f80f47e9d7f457b7a5a64603c59b14d3b536a8c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2403
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Change-Id: I0dd83f96d2a9598e9677d1b0b114229de6724287
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2401
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Multiboot is an x86 only thing. Drop support on ARM.
Change-Id: I13fafa464a794206d5450b4a1f23a187967a8338
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2392
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
