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>
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)
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 1cd6160821
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 8f4647a24b
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>
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>
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't seem to need it, and it currently confuses the payload.
(credit to Gabe Black for this, I'm just uploading it)
Change-Id: I4e3a60eceb9b24e3bc8e50db431c1a731d1cdbae
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2385
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes some files leftover from the initial port. Some are
leftover from U-Boot and some were leftover from the skeleton code
derived from x86.
There's a bit more that we'll get in another sweep.
Change-Id: I325793ecb902b3b9430dcf531714ce025d201de6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmu_setup() was originally written in U-Boot to utilize board-specific
global data. Since we're trying to avoid that, we added start and size
parameters so that board-specific info can be passed in via mainboard
code. Let's start using it that way.
Change-Id: I7d7de0e42bd918c9f9f0c177acaf56c110bf8353
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2378
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The comment introduced in
commit 50c0a50ac6
Author: David Hendricks <dhendrix@chromium.org>
Date: Thu Jan 31 17:05:50 2013 -0800
armv7: unify stage hand-off routines
Reviewed-on: http://review.coreboot.org/2254
contained a typo, which is corrected now.
Change-Id: I87f7cfa82fcd12b6961d3329e634b4c201cc047e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2372
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is just to get us to the payload.
TODO: Do we want to implement any of the stuff from the x86 version,
such as copying coreboot to a new location?
Change-Id: Ia0544f111d7a1189ebd92d0ba3e11448eabd6252
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2363
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
RAMBASE and RAMTOP are leftovers from the x86 port and do not apply
the same way on ARM platforms. On x86 they refer to the low memory
region where coreboot tables reside.
However on ARM we don't have such a region which is architecturally
defined. So instead we'll use the CPU-defined DRAM base address and
the mainboard-defined DRAM size.
This also has the pleasant side-effect of fixing the coreboot tables
to not clobber ramstage code...
Change-Id: I5548ecf05e82f9d9ecec8548fabdd99cc1e39c3b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This places the .id section toward the lower region of the coreboot
image, before the bootblock. It's easier for humans to find by dumping
the image and it also eliminates ID_SECTION_OFFSET which is currently
the upper bound on our image size.
Change-Id: I7d737b901dac659ddf9aa437cee5dc32f1080546
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a .bl1 and .start symbol that is placed at the beginning
of the .rom section.
The goal is to move the .id section in between the reset vector and
bootblock_main.
Change-Id: Ie732ce656d697c059cc0fa40c844b39f53fc214c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Kconfig variable indicates KB, but the number used was bytes.
Let's just assume KB is correct for now.
Change-Id: I910c126104f0222fc48b70a18df943f2afddeca3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Except for one board, the flags can be derived from CONFIG_MMX
and CONFIG_SSE.
Change-Id: I64a11135ee7ce8676f3422b2377069a3fa78e24d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2336
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The bootblock is typically run before fpu/mmx/sse setup, so
we can't rely on -mcpu=p4 and the like to increase the
register space.
bootblock_romccflags does that for SSE, but they're controlled
separately.
Change-Id: I2b0609ac18b2394a319bf9bbbee1f77d2e758127
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2335
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a first-pass attempt at cleaning up the coreboot tables
for ARM. The most noticable difference is that there is no longer
both a high and a low table.
Change-Id: I5ba87ad57bf9a697b733511182c0326825071617
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a BL1_SIZE_KB config variable so that we can get rid of
some magic constants.
Change-Id: I9dbcfb407d3f8e367be5d943e95b032ce88b0ad0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Explicitly including it allows us to get rid of some magic constants
in the bootblock linker script.
Change-Id: I095899babc997addce6b383f00e5ebf135e99d5e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2331
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use same console initialization procedure for all ARM stages (bootblock,
romstage, and ramstage):
#include <console/console.h>
...
console_init()
...
printk(level, format, ...)
Verified to boot on armv7/snow with console messages in all stages.
Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Revise console source file dependency (especially for EARLY_CONSOLE) and
interpret printk/console_init according to EARLY_CONSOLE setting (no-ops if
EARLY_CONSOLE is not defined).
Verified to boot on x86/qemu and armv7/snow. Disabling EARLY_CONSOLE correctly
stops romstage messages on x86/qemu (armv7/snow needs more changes to work).
Change-Id: Idbbd3a26bc1135c9d3ae282aad486961fb60e0ea
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2300
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"SPL" from U-Boot is deprecated by bootblock in coreboot/arm, so we don't need
it anymore.
Change-Id: Id16877075d0b870839a10160073ad70777a2af0a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2297
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
hang() is the legacy function from U-boot and should be replaced by hlt() in
coreboot.
Change-Id: I0f390b1b6f9ff71487ea36cf16c462724b66d8ca
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2298
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The common part of the bootblock resets the nvram data if it's found
to be invalid. Since that code is compiled with romcc in i386 mode,
there's a shortage on registers.
Try to reduce the strain by doing things smarter: cmos_write_inner
is the same as cmos_write, just that it doesn't check if the RTC is
disabled. Since we just disabled it before, we can assume that it is so.
Change-Id: Ic85eb2a5df949d1c1aff654bc1b40d6f2ff71756
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2296
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
For arm/snow, current bootblock is larger than previously assigned CBFS offset
and will fail to boot. To prevent this happening again in future, cbfstool now
checks if CBFS will overlap bootblock.
A sample error message:
E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000)
E: Failed to create build/coreboot.pre1.tmp.
arm/snow offset is also enlarged and moved to Kconfig variable.
Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2295
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We don't need a special Kconfig variable anymore
because the FV _is_ the payload, unlike with the
old tianocoreboot implementation.
Change-Id: I349b5a95783e4146e3ab7f926871188cf2021935
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2284
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This removes the hack implemented in http://review.coreboot.org/#/c/2280
(and should make using 64bit Tiano easier, but that's not yet supported)
Change-Id: Ie30129c4102dfbd41584177f39057b31f5a937fd
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Usage Changes: To support platforms with different memory layout, "create" takes
two extra optional parameters:
"-b": base address (or offset) for bootblock. When omitted, put bootblock in
end of ROM (x86 style).
"-H": header offset. When omitted, put header right before bootblock,
and update a top-aligned virtual address reference in end of ROM.
Example: (can be found in ARM MAkefile):
cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \
-a 64 -b 0x0000 -H 0x2040 -o 0x5000
Verified to boot on ARM (Snow) and X86 (QEMU).
Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2214
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To support platforms without top-aligned address mapping like ARM, "locate"
command now outputs platform independent ROM offset by default. To retrieve x86
style top-aligned virtual address, add "-T".
To test:
cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T
# Example output: 0xffffdc10
Change-Id: I474703c4197b36524b75407a91faab1194edc64d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2213
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This unplugs Stefan's PIANO project.
Change Tianocore payload configuration to use corebootPkg.
As argument you have to give it the COREBOOT.FD generated by
the Tianocore build system.
It automatically determines base address and entry point.
Compression setting is honored (ie. no compression if you don't
want), but corebootPkg currently assumes that coreboot is doing
it. Loading a 6MB payload into CBFS without compression will fail
more often than not.
Change-Id: If9c64c9adb4a846a677c8af40f149ce697059ee6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If somebody makes use of CONFIG_LOCALVERSION show this
user provided config string for DMI bios_version.
As requested I have attached example output.
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
4.0-3360-g5be6673-dirty
CONFIG_LOCALVERSION="V1.01.02 Beta"
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
V1.01.02 Beta
Change-Id: I5640b72b56887ddf85113efa9ff23df9d4c7eb86
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2279
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
This removes some duplicate code from Snow's mainboard bootblock
by utilizing the bootblock build class.
Change-Id: I153247370a8c5127260082dcdca3ebdc5e104fb8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".
Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.
For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)
Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Eliminate the warning message:
ld: warning: cannot find entry symbol _start; defaulting to 040000000
The "_start" from c_start.S is deprecated so we need to define entry
point again in link description file.
Change-Id: I174428faa2e7f08cd91fe96a53e6efea9dc3634e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2258
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes a few lines which are obsolete or unneeded.
We may want to do something with SMP eventually (can we use it for
decompression?) but for now we'll assume non-bootstrap cores are idle
until the OS does something with them.
Change-Id: Iff6b196e008e803bcfd00e5de07cf471bd2357ea
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2257
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces the current stage-specific exit/entry functions with
generic versions. Now all stages compile with stage_entry(), which
is placed at .text.stage_entry.armv7, and stage_exit().
Snow's ramstage files are also updated to avoid build breakage.
Change-Id: I953a2c4b8121bd4b66c3362557997a9ca3aa53b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
People make mistakes. Hanging the box is not a good reason to kill the firmware,
esp. since this is probably happening in a printk.
The only issue with the recursive call to printk is that we may
deadlock if we have locked something. But we can at least try.
Hanging is certainly not what we want ...
Change-Id: Ib3bc87bc395ae89e115cf6d042f4167856422ca1
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2233
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is a Tiano Core loader payload based on libpayload. It
will load a Tiano Core DXE core from an UEFI firmware volume
stored in CBFS.
Currently Tiano Core dies because it does not find all the UEFI services it needs:
coreboot-4.0-3316-gc5c9ff8-dirty Mon Jan 28 15:37:12 PST 2013 starting...
[..]
Tiano Core Loader v1.0
Copyright (C) 2013 Google Inc. All rights reserved.
Memory Map (5 entries):
1. 0000000000000000 - 0000000000000fff [10]
2. 0000000000001000 - 000000000009ffff [01]
3. 00000000000c0000 - 0000000003ebffff [01]
4. 0000000003ec0000 - 0000000003ffffff [10]
5. 00000000ff800000 - 00000000ffffffff [02]
DXE code: 03e80000
DXE stack: 03e60000
HOB list: 03d5c000
Found UEFI firmware volume.
GUID: 8c8ce578-8a3d-4f1c-9935-896185c32dd3
length: 0x0000000000260000
Found DXE core at 0xffc14e0c
Section 0: .text size=000158a0 rva=00000240 in file=000158a0/00000240 flags=60000020
Section 1: .data size=00006820 rva=00015ae0 in file=00006820/00015ae0 flags=c0000040
Section 2: .reloc size=000010a0 rva=0001c300 in file=000010a0/0001c300 flags=42000040
Jumping to DXE core at 0x3e80000
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3E96708
HOBLIST address in DXE = 0x3E56010
Memory Allocation 0x00000003 0x3E80000 - 0x3EBFFFF
FV Hob 0xFFC14D78 - 0xFFE74D77
InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D 3E95EA0
InstallProtocolInterface: EE4E5898-3914-4259-9D6E-DC7BD79403CF 3E9630C
Security Arch Protocol not present!!
CPU Arch Protocol not present!!
Metronome Arch Protocol not present!!
Timer Arch Protocol not present!!
Bds Arch Protocol not present!!
Watchdog Timer Arch Protocol not present!!
Runtime Arch Protocol not present!!
Variable Arch Protocol not present!!
Variable Write Arch Protocol not present!!
Capsule Arch Protocol not present!!
Monotonic Counter Arch Protocol not present!!
Reset Arch Protocol not present!!
Real Time Clock Arch Protocol not present!!
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT /home/reinauer/svn/Tiano/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(461): !EFI_ERROR (Status)
Change-Id: I14068e9a28ff67ab1bf03105d56dab2e8be7b230
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2154
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently "cbfstool locate" outputs a hex number without "0x" prefix.
This makes extra step (prefix 0x, and then generate another temp file) in build
process, and may be a problem when we want to allow changing its output format
(ex, using decimal). Adding the "0x" in cbfstool itself should be better.
Change-Id: I639bb8f192a756883c9c4b2d11af6bc166c7811d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2201
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The previous incarnation did not use all of mmu_setup, which meant
we did not carefully disable things before (possibly) changing them.
This code is tested and works, and it's a bit of a simplification.
Change-Id: I0560f9b8e25f31cd90e34304d6ec987fc5c87699
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2204
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This begins to remove references to global data which u-boot used.
There are still many commented out references to gd-> and bd-> which
we'll fix once we're happy with the replacements.
Change-Id: Ie1b40a997e28a118f8f3ad96a2f9a2462d32fbe3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2210
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This just removes unused code. If for some reason we don't want to
initialize cache, then the CPU or mainboard specific init routines
don't need to call these.
Change-Id: Ieb7393b6cbc103e490753da4ed27114156466ded
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2209
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
No need to keep duplicate variants of counting ioapic interrupts.
Change-Id: I512860297309c46e05cc5379bf61479878817b1e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2185
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Apply the same fix for `setup_ioapic` as done in the following commit.
commit 23c046b6f1 Author: Nico Huber <nico.huber@secunet.com> Date: Mon Sep 24 10:48:43 2012 +0200
Fix reading of number of interrupts for IO-APICs
The number read from the io-apic register represents the index of the
highest interrupt redirection entry, i.e. the number of interrupts
minus one.
Change-Id: I54c992e4ff400de24bb9fef5d82251078f92c588
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I7b730d016a514c95c3b32aee6f31bd3d7b2c08cb
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2043
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This replaces the call() function with a stub which is compiled
separately using -marm. See http://review.coreboot.org/#/c/2175/
for details.
Change-Id: I7f8c45b5e63ec97b0a82294488129d1c97ec0cbf
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2180
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
This adds a wrapper around main() in romstage which is compiled using
-marm. This assumes that the bootblock branches to romstage in ARM
mode.
The long-term idea is to enforce ABI compatibility when handing off to
the next stage by using shims which are which are compiled in a pre-
determiend manner and leave the main portions of each stage up to
whatever the compiler wants. So it will eventually look like this:
1. bootblock_main (ARM/Thumb)
2. bootblock_exit (ARM)
3. romstage_entry (ARM)
4. romstage_main (ARM/Thumb)
(credit to Gabe Black for writing the patch, I'm just uploading it)
Change-Id: I4fdb8d2c6c2c0a7178bcb9154c378ddce0567309
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We've had obscure errors as the size of the bootblock changes.
This fix allows us to use a 32-bit constant. Please test on
real hardware before you ack.
Change-Id: Ic3d9f4763554bd6104ae9c4ce5bbacd17b40872c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2168
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Our earlier attempt was jumping straight from asm to the old u-boot
board_init_f in lowlevel_init_c.c. We are getting ready to transition
to using a real bootblock for ARM, so add romstage.c to the files
compiled and we'll make main() our entry point.
This also updates romstage.ld to place main() (*(.text.startup)) at
the beginning of romstage.
Change-Id: Ifc77a6bfba27d915c4cad62c6c8040665294628a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2163
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces hard-coded bootblock offsets using the new scheme.
The assembler will place the initial branch instruction after BL1,
skip 2 aligned chunks, and place the remaining bootblock code after.
It will also leave an anchor string, currently 0xdeadbeef which
cbfstool will find. Once found, cbfstool will place the master CBFS
header at the next aligned offset.
Here is how it looks:
0x0000 |--------------|
| BL1 |
0x2000 |--------------|
| branch |
0x2000 + align |--------------|
| CBFS header |
0x2000 + align * 2 |--------------|
| bootblock |
|--------------|
TODO: The option for alignment passed into cbfstool has always been
64. Can we set it to 16 instead?
Change-Id: Icbe817cbd8a37f11990aaf060aab77d2dc113cb1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This lays out the groundwork for using a proper bootblock on ARM.
Currently we bypass the bootblock entirely and go straight to
romstage. However we want to utilize CBFS to maximize flexibility
of placing code without relying on a lot of magic numbers which
will break depending on the SoC in use.
Change-Id: I9cc2a8191d2db38b27b6363ba673e5a360de9684
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and delete traces in source files.
Change-Id: Ie0f70a479f1eadadc654a41fa3c426d1d4ac2f2b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since coreboot is compiled into 32bit code, and userspace
might be 32 or 64bit, putting a pointer into the coreboot
table is not viable. Instead, use a uint64_t, which is always
big enough for a pointer, even if we decide to move to a 64bit
coreboot at some point.
Change-Id: Ic974cdcbc9b95126dd1e07125f3e9dce104545f5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces 0x02023400 with an SoC-specific Kconfig variable.
Change-Id: I21482d54a1e1fa6c4437c030ddae2b0bb3331551
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This doesn't seem to be strictly required (so far), but makes sense.
Change-Id: I18416c427ff886507ae09c7fc1a018baf94af24a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2131
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't pass arguments when we jump out of assembly code.
Change-Id: Iccf3a6f713e260b08f9ff47e8b542b9e96369166
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2122
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We moved to using __ASSEMBLER__ years ago since it is set by as.
Change-Id: I60103ba23ebe87be1d0bc63beed0ef5b05eed4f2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2111
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It's a bad Linux heritage.. We have no userland in firmware.
Change-Id: Ib19e5ba713078ca37514571213d19f418417b964
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2108
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It makes no sense to have directories with one file.
Change-Id: I65ba93dda5e6a4bcc5a7cc049c1378ebf5d6abcd
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2105
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This reverts commit ec8d35fe91
We are almost certain that this is not necessary.
Change-Id: I70e94f883be95655da00a0b127ed9ffd7c81c63b
Reviewed-on: http://review.coreboot.org/2104
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Our reference toolchain uses -mabi=aapcs whereas we started
forcing -mabi=aapcs-linux. Drop this to prevent ABI incompatibility.
Also drop -fno-common since that's set in the top level Makefile.inc
already.
Change-Id: I4afdcf5da9a5d86c2f9e5de5c7d523ccd2f5f1e0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2103
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We accidently checked in some files from libgcc as well as
a Makefile from u-boot and a duplicate implementation of div0.
Drop all those files to reduce the confusion.
Change-Id: I8ff6eabbced6f663813f8cc55f19c81839d03477
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2102
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was a misuse of bool that would cause the dcache policy to not be
set up correctly, but instead present options "y" and "n" in the Kconfig
menu.
Also, TINY_BOOTBLOCK was removed a while ago, everything is
TINY_BOOTBLOCK now. Hence remove the option.
Change-Id: I5c28ac828955c69614c7bdaf106f79db51e68723
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2101
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This updates $CFLAGS used for armv7. Most of them were just added
to be consistent with what u-boot does. The important ones here
are -march=armv7-a and -mthumb (to allow 16-bit Thumb instructions).
I removed the hard float support because it got errors and
coreboot should never use floats anyway. We're still having trouble
with enums but I want to see how far it gets with this patch.
Also, put the flags in a form that makes diffs easier to read. It's
almost impossible otherwise.
Finally, move some flags to the architecture Makefile, and
rely on the fact that some are set for all architectures.
Depends-On: I6f730d017391f9ec4401cdfd34931c869df10a9e
Change-Id: Ia8a1ae22959933e06f7b996d1832cea40819f1ff
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2075
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This mirrors the naming convention of handlers in
northbridge and southbridge.
Change-Id: I45d97c569991c955f0ae54ce909d8c267e9a5173
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2058
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This replaces a somewhat useless calculation used earlier (which
always evaluated to 0) with an offset to specify the location
of the Coreboot bootblock.
Change-Id: Ib85aaccf138cebeb6bf8aedf82308861206dff48
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2094
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The old start.S file did a lot of work and had AP-specific #ifndef's.
The new init.S will eventually contain only bare minimum generic ARM
code for use by the bootblock. Processor-specific stuff and things
that take place later in the boot process should go elsewhere.
Change-Id: I7db0a77ee4bbad1ddecb193ea125d8941a50532b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2083
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is still a work-in-progress, but it seems to work better than
before and is less complicated...
Change-Id: I6f730d017391f9ec4401cdfd34931c869df10a9e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2041
Tested-by: build bot (Jenkins)
While "payload none" is undesirable for instant flashing,
assume that it was a conscious user choice.
(more immediate: jenkins isn't happy with escape sequences)
Change-Id: I9958b34a037b4d10bb7dba893335a63917623a70
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2055
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Initialize the pointer fadt to NULL to prevent a later comparison
(if (fadt == NULL)) when the pointer had the *possibility* of never
having been initialized.
Change-Id: Ib2a544c190b609ab8c23147dc69dca5f4ac7f38c
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2037
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
cbfstool was called with the wrong parameters
Change-Id: I405d0fd7c84b46da3c98a36fd19ef0034dc175cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2022
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
stddef.h should be fairly generic across all platforms we'd want to
support, so let's move it to generic code.
Change-Id: I580c9c9b54f62fadd9ea97115933e16ea0b13ada
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2007
Tested-by: build bot (Jenkins)
The first ARMv7 CPU we're going to support is the Exynos 5250
used in the Google Snow ChromeBook.
Change-Id: I4de8433bbc6202eb8fef2556a11186a3376d411b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2004
Tested-by: build bot (Jenkins)
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change allows to override default bootblock_mainboard_init() with
mainboard-specific code.
If the default bootblock_mainboard_init() handler is replaced, with
one from file BOOTBLOCK_MAINBOARD_INIT, one needs to take care the
replacement calls all the necessary bootblock_x_init() functions.
Change-Id: Ie8c667cdba7cafe9ed2d4b19ab2bd21d941ad4ca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1845
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Makes it a bit easier to implement mainboard-specific behaviour
while executing the bootblock.
Change-Id: I04e87f89efb4fad1c0e20b62ea6a50329a286205
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is an initial re-factoring of CBFS code to enable multiple
architectures. To achieve a clean solution, an additional field
describing the architecture has to be added to the master header.
Hence we also increase the version number in the master header.
Change-Id: Icda681673221f8c27efbc46f16c2c5682b16a265
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1944
Tested-by: build bot (Jenkins)
This adds a dummy config for ARMV7 for developing various
follow-up patches which rely on ARCH_ARMV7.
Change-Id: Id913054d916f41607d10ebc02aaf74082e14b554
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This provides weak empty declaration for mainboard_ops.
The struct chip_operations is not defined for __PRE_RAM__ so
the declaration is also moved upwards in the output.
Change-Id: I101f0b8b9f0a55fb51a7c6475d53cc588c84026d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1931
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
c_start.o has a special case in the build system, which we can
eliminate, somewhat simplifying the build.
To ensure that the entry point is at the beginning, introduce a
new section .textfirst that is placed appropriately. In principle
the ENTRY() definition in the linker script should be enough, but
better be safe.
Change-Id: I9737f7f5731e12ceb2119eb432b0e09832bc53fa
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1909
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ramstage.a has two issues:
1. duplicate source filenames don't survive the ar(1)
treatment properly (so files aren't considered)
2. ld doesn't resolve symbols if it isn't forced to, in
particular no overrides of weak symbols
Downside: The resulting binaries get slightly larger.
Link time optimizations should fix that, as would tighter
rules in the build system (to not compile unused code in
the first place).
Change-Id: Iaae771ec8f92b42069237acd3b79c14e5bf9c03d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1566
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
e.g.
-#if CONFIG_LOGICAL_CPUS == 1
+#if CONFIG_LOGICAL_CPUS
This will make it easier to switch over to use the config_enabled()
macro later on.
Change-Id: I0bcf223669318a7b1105534087c7675a74c1dd8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This ensures that there's only one disable/enable cycle for
the entire rewrite instead for every single byte.
Change-Id: Ic06e6dcb08976d158ff784660838c0fbad875176
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Both remaining options, DRIVERS_PS2_KEYBOARD and ID_SECTION_OFFSET
are not likely to go away any time soon, so let's not keep them
in Kconfig.deprecated_options but move them close to the code they
control.
Change-Id: I310b877c5b3d5a3444056641c4aee07a48c4c4be
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1839
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Add mainboard_smi.c from arch/x86/Makefile if it's there
- Add mainboard's chromeos.c from the chromeos Makefile
Change-Id: I3f80e2cb368f88d2a38036895a19f3576dd9553b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1835
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is the beginning of a Kconfig cleanup series
- drop CONFIG_HAVE_BUS_CONFIG and add get_bus_conf.c if it
exists in the mainboard directory
- drop duplicate ACPI_SSDTX_NUM from mainboard Kconfig
if it only defines the defaul value of 0
- Add mptable.c, fadt.c, reset.c and ssdtX.asl when they
exist, not based on some Kconfig magic
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia14a7116dad6a724af7e531920fee9a51fd0b200
Reviewed-on: http://review.coreboot.org/1832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
YABEL's version of mainboard_interrupt_handlers() was hidden behind an
inline stub. This fixes it.
Change-Id: Ie53424a8ce074e93a720c0ef94cb39994cacd023
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM GNVS pointer is normally updated only when the
ACPI tables are created, which does not happen in the
resume path.
In order to restore this pointer it needs to be available
at resume time. The method used to locate it at creation
time cannot be used again as that magic signature is
overwritten with the address itself. So a new CBMEM ID
is added to store the 32bit address so it can be found
again easily.
A new function is defined to save this pointer in CBMEM
which needs to be called when the ACPI tables are created
in each mainboard when write_acpi_tables() is called.
The cpu_index variable had to be renamed due to a conflict
when cpu/cpu.h is added for the smm_setup_structures()
prototype.
Change-Id: Ic764ff54525e12b617c1dd8d6a3e5c4f547c3e6b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Let memory initialization code use the coreboot romstage console. This
simplifies the code and makes sure that all output is available in
/sys/firmware/log.
The pei_data structure is modified to allow passing the console output
function pointer. Romstage console_tx_byte() is used for this purpose.
Change-Id: I722cfcb9ff0cf527c12cb6cac09d77ef17b588e0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1823
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This addition is in support of future multicore support in
coreboot. It also will allow us to remove some asssembly code.
The CPU "index" -- i.e., its order in the sequence in which
cores are brought up, NOT its APIC id -- is passed into the
secondary start. We modify the function to specify regparm(0).
We also take this opportunity to do some cleanup:
indexes become unsigned ints, not unsigned longs, for example.
Build and boot on a multicore system, with pcserial enabled.
Capture the output. Observe that the messages
Initializing CPU #0
Initializing CPU #1
Initializing CPU #2
Initializing CPU #3
appear exactly as they do prior to this change.
Change-Id: I5854d8d957c414f75fdd63fb017d2249330f955d
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1820
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Right now coreboot's build process produces images that are
not booting on actual hardware because they are smaller than
the actual flash device and also don't have an IFD nor an ME
firmware in them. In order to produce bootable images, you
needed a wrapper script / extra step until now. With this
change, the resulting coreboot.rom is actually bootable.
Change-Id: I82714069fb004d4badc41698747a704bd9fed4da
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1771
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The currently encoded register constraints fails compilation
for SMM code or any code that compiles with -fPIC. The reason
is that the ebx register is used for GOT base register.
I don't believe the comment eluding to register constraints for AMD
processors still applies. Therefore remove mmio_conf.h, and use the
mmio methods in io.h.
Change-Id: I391e5c2088ebc760b3a6ed6c37b65bbecab40a5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Adding more and more optional and non-optional parameters
bloated cbfstool and made the code hard to read with a lot
of parsing in the actual cbfs handling functions. This change
switches over to use getopt style options for everything but
command and cbfs file name.
- This allows us to simplify the coreboot Makefiles a bit
- Also, add guards to include files
- Fix some 80+ character lines
- Add more detailed error reporting
- Free memory we're allocating
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7
Reviewed-on: http://review.coreboot.org/1800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the modules use their own rolled pci_or_configX functions.
Therefore, make them first class so everyone can use them without
copying them.
Change-Id: I9a4d3364c832548dbfe18139c27cce2d60c3316d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1797
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Double equal sign like "test a == b" works. It really does, except NetBSD.
But I haven't found any clue in the manual for the command test about "==".
Change-Id: I37254cfeb688fd1092f2e549d24f8eb270f02fd8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1817
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
coreboot uses about 2K of stack on the BSP, and about 1K of stack on the
APs. No reason to use an overdimensonal stack of 32k per core/thread.
Change-Id: I734c240b992d40e1e35db3df5437c36da0a755cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1780
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At least when CONFIG_CHROMEOS is turned on, it's possible for
CONFIG_FRAMEBUFFER_KEEP_VESA_MODE to be set but for there not to be any valid
information to put into the framebuffer coreboot table. That means that what's
put in there is junk, probably all zeroes from the uninitialized global
variable the mode information is stored in (mode_info).
When a payload uses libpayload and turns on the coreboot framebuffer console,
that console will attempt to scroll at some point and decrease the cursor's y
coordinate until it is less than the number of rows claimed by the console.
The number of rows is computed by taking the vertical resolution of the
framebuffer and dividing it by the height of the font. Because the mode
information was all zeroes, the coreboot table info is all zeroes, and that
means that the number of rows the console claims is zero. You can't get the
unsigned y coordinate of the cursor to be less than zero, so libpayload gets
stuck in an infinite loop.
The solution this change implements is to add a new function,
vbe_mode_info_valid, which simply returns whether or not mode_info has anything
in it. If not, the framebuffer coreboot table is not created, and libpayload
doesn't get stuck.
Change-Id: I08f3ec628e4453f0cfe9e15c4d8dfd40327f91c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
And move the pre-hardwaremain post code to 0x79
so it comes before hardwaremain at 0x80.
Emit these codes from ACPI OS resume vector as well
as the finalize step in bd82x6x southbridge.
Change-Id: I7f258998a2f6549016e99b67bc21f7c59d2bcf9e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On Sandybridge and Ivybridge systems the firmware image has to
store a lot more than just coreboot, including:
- a firmware descriptor
- Intel Management Engine firmware
- MRC cache information
This option allows to limit the size of the CBFS portion in
the firmware image.
Change-Id: Ib87fd16fff2a6811cf898d611c966b90c939c50f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will use 3 bytes of CMOS to keep track of the POST
code for the current boot while also leaving a record of
the previous boot.
The active bank is switched early in the bootblock.
Test:
1) clear cmos
2) reboot
3) use "mosys nvram dump" to verify that the first byte
contains 0x80 and the second byte contains 0xF8
4) powerd_suspend and then resume
5) use "mosys nvram dump" to verify that the first byte
contains 0x81 and the second byte contains 0xFD
Change-Id: I1ee6bb2dac053018f3042ab5a0b26c435dbfd151
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a slight improvement over the rep movsb loop
Change-Id: Id71d9bfe5330b154a5c62fac85ce3955ae89b057
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Our linker script for romstage checks for global variables and
makes the build fail if there are any (on non-AMD systems).
This is great, but having the build fail without any indication
which variables are global is not very useful.
Moving the check to the Makefile allows us to let the linking stage
succeed and reveil which variable names end up in the data and bss
sections of the binary.
To test, add "int foo;" as the first line in src/mainboard/samsung/lumpy/romstage.c
and build coreboot for Lumpy. See the build break the following
way:
LINK cbfs/fallback/romstage_null.debug
Forbidden global variables in romstage:
00006a84 B foo
Change-Id: I3c8780888f46a6577ffd36bcea317997b4f84f6f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1692
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Adds lowlevel handling of DMAR tables for use by mainboards'
ACPI code. Not much automagic (yet).
Change-Id: Ia86e950dfcc5b9994202ec0e2f6d9a2912c74ad8
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We only want to add data once per device. Using the one in
chip_operations is not very usable anyway, as different
devices under the same chip directory would need to output
entirely different sets of data.
Change-Id: I96690c4c699667343ebef44a7f3de1f974cf6d6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1492
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
The number read from the io-apic register represents the index of the
highest interrupt redirection entry, i.e. the number of interrupts
minus one.
Change-Id: I54c992e4ff400de24bb9fef5d82251078f92c588
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
HPET's min ticks (minimum time between events to avoid
losing interrupts) is chipset specific, so move it to
Kconfig.
Via also has a special base address, so move it as well.
Apart from these (and the base address was already #defined),
the table is very uniform.
Change-Id: I848a2e2b0b16021c7ee5ba99097fa6a5886c3286
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1562
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
This is in preparation for sharing interrupt handlers
between YABEL and x86emu.
Change-Id: Iff92c1d899b8ada20972731944341805a49b6326
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Don't derive the IRQ pin from the function number. Especially onboard
chipset devices don't follow that rule. Instead check and add all
fixed IRQ entries.
Change-Id: I46c88bad39104c1d9b4154f180f8b3c42df28262
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1461
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The current code does some argument manipulation to detect when a stage is being
added to cbfs. This same manipulation needs to be done when adding a payload.
Change-Id: Ief4c4a81446c9437923cbbb1ce3fa90729317587
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1451
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When we encounter an x86 exception, we print the problem address, dump the
registers and die. This may not be sufficient information for debug. Also
dump the memory around the problem instruction. This has proven useful in
identifying memory issues, and DRAM burst reordering problems.
Change-Id: I6411344e89f946e16d11217d7dbd73812c45d54c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1454
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Adding ranges directly into coreboot memory table raised issues
as those methods bypassed the MTRR setup. Such regions are now
added as resources, so declare the functions again as static.
Change-Id: If78613da40eabc5c99c49dbe2d6047cb22a71b69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1415
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 042c1461fb.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EHCI debug allows to send message with 8 bytes length, but
we're only sending one byte in each transaction. Buffer up
to 8 bytes to speed up debug output.
Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1357
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
This patch extends the current smbios api to allow changing mainboard
serial and version during coreboot runtime. This is helpful if you
have an EEPROM etc. to access these informations and want to add
some quirks for broken hardware revision for the linux kernel.
This could be done via DMI_MATCH marco.
Change-Id: I1924a56073084e965a23e47873d9f8542070423c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
This include file needs to be prevented from being included multiple
times.
Change-Id: I42e0cbe38d332b919f22e331eaf7a0251929e1dc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1293
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Code can easily make the mistake of using uninitialized
values or, in assembly, mistakenly dereferencing stack pointers
when an address is desired.
Set the stack to a non-zero value which is also (by testing)
a pointer which will crash coreboot if used. This poisoning
has uncovered at least one bug.
Change-Id: I4affb9a14b96611e8bf83cb82636e47913025a5d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1221
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
This patch adds support for autogenerating the MPTABLE from
devicetree.cb. This is done by a write_smp_table() declared
weak in mpspec.c. If the mainboard doesn't provide it's own
function, this generic implementation is called.
Syntax in devicetree.cb:
ioapic_irq <APICID> <INTA|INTB|INTC|INTD> <INTPIN>
The ioapic_irq directive can be used in pci and pci_domain
devices. If there's no directive, the autogen code traverses
the tree back to the pci_domain and stops at the first device
which such a directive, and use that information to generate the
entry according to PCI IRQ routing rules.
Change-Id: I4df5b198e8430f939d477c14c798414e398a2027
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1138
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If a CPU was pre-allocated, cpu_path is not copied and thus
index would not be updated. This breaks cpu_index() and AMD
model_fxx is possibly broken without this patch.
Change-Id: I77483181cf0bca31423c655942c022bffab3c7ea
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1199
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
PCI Type 2 config was a strange and never-used config mechanism.
It is unlikely that in the 13 years of coreboot's existence that
type 2 was ever used; it just made life complicated for everyone.
It lived long enough in coreboot to be replaced by mmioconf.
Prior to making the device tree visible in romstage we want to
get rid of type2.
Delete two files we don't need any more (yay!).
Replace two functions with one: pci_config_default, which returns
a pointer to the default config method. At some future time this
may change to mmio but for now it is old type1 style.
Change-Id: Icc4ccf379a89bfca8be43f305b68ab45d88bf0ab
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1159
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
With this change it is possible to define serial number
and version of the mainboard. These informations are used
in SMBIOS tables.
Change-Id: I1634882270f6cb94e00aceb7832e7fd14adc186b
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1163
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The error message from romstage is annoying and misleading:
"Do not use global variables in romstage"
Because it can occur even when global variables are not used
in some circumstances, but also because it gives you only a rough
idea where to look. This change sucks but sucks less. We still don't
know which file the problem is in but at least we know if it is data
or bss.
Replace the error message with something that provides more information
and less guessing on the part of the script:
".bss is non-zero size in romstage which is not allowed -- global variable?"
or
".data is non-zero size in romstage which is not allowed -- global variable?"
To test: build coreboot as normal. It builds.
Add
char d[32];
to romstage.c and get the first error message; add
int x = 32;
to romstage.c and get the second.
Change-Id: I300ec05bdb4b30d7ef3f5112e6cc09b1fafe8263
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1160
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The wrapper for Trinity. Support S3. Parme is a example board.
Change-Id: Ib4f653b7562694177683e1e1ffdb27ea176aeaab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current code for initializing AP cpus has several shortcomings:
- it assumes APIC IDs are sequential
- it uses only the BSP for determining the AP count, which is bad if
there's more than one physical CPU, and CPUs are of different type
Note that the new code call cpu->ops->init() in parallel, and therefore
some CPU code needs to be changed to address that. One example are old
Intel HT enabled CPUs which can't do microcode update in parallel.
Change-Id: Ic48a1ebab6a7c52aa76765f497268af09fa38c25
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's a quick demonstration on how to use it(tested on M4A785T-M).
(gdb) file ./build/cbfs/fallback/coreboot_ram.debug
Reading symbols from [...]/build/cbfs/fallback/coreboot_ram.debug...done.
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
_text () at src/arch/x86/lib/c_start.S:85
85 call hardwaremain
Change-Id: Ia49cbecc41deb061433bc39f5b81715da49edc98
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The constant value 0x100000000 is used in linker scripts to calculate
offsets from the end of 32-bit-addressed memory. There is nothing
wrong with it, but 32-bit versions of ld do the calculation wrong.
Change-Id: I4e27c6fd0c864b4d98f686588bf78c7aa48bcba8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1129
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Without that fix we have:
LINK cbfs/fallback/romstage_null.debug
build/generated/crt0.romstage.o: In function `ramtest':
romstage.c:(.rom.text+0x53f): undefined reference to `.Lhlt'
collect2: ld returned 1 exit status
make: *** [build/cbfs/"fallback"/romstage_null.debug] Error 1
On the M4A785T-M which doesn't have CONFIG_ROMCC.
Change-Id: I49eded1d18e996afe9441b85dae04ae30c760dd6
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1101
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
- Add #define to allow the FADT PM Profile to be overridden.
- Change the location of the PMA_CNT_BLOCK_ADDRESS to match
current documentation.
- cst_cnt should be 0 if smi_cmd == 0
- add a couple of default access sizes.
- Add a couple of #define values for unsupported C2 & C3 entries.
- Add PM Profile override value into amd/persimmon platform.
This does not use the #defines in acpi.h so that the files that
include this don't all need to start including acpi.h.
Change-Id: Ib11ef8f9346d42fcf653fae6e2752d62a40a3094
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1055
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
It is just me or does anybody have the same build error without
this patch?
------
src/arch/x86/boot/acpigen.c: In function 'acpigen_write_empty_PTC':
src/arch/x86/boot/acpigen.c:347:3: error: unknown field 'resv'
specified in initializer
src/arch/x86/boot/acpigen.c:347:3: warning: missing braces around
initializer
src/arch/x86/boot/acpigen.c:347:3⚠️ (near initialization
for 'addr.<anonymous>')
-------
Anyway, I believe at least this will cause warnings.
"resv" is a member of a union, not of acpi_addr_t. So it should be
wrapped by a brace in the initializer.
Change-Id: I72624386816c987d5bb2d3a3a64c7c58eb9af389
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1056
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
clang does its own linking, incompatible to our
binutils-centric linker magic.
Change-Id: I243597adcb6bc3f7343c3431d7473610c327353d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When compiling coreboot with the latest ChromeOS toolchain, GCC
complains that some printk calls use %zu in connection with size_t
types since it resolves the typedefs to long unsigned int.
The problem is solved by using the GCC built-in __SIZE_TYPE__ if it
exists and define __SIZE_TYPE__ to long unsigned int otherwise.
Change-Id: I449c3d385b5633a05e57204704e981de6e017b86
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1040
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The bootblock.ld linkerscript is used by romstage. Name it
accordingly to avoid confusion.
Change-Id: I7ca9147bb821fe6f83224d170f5fe25654ef250f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1031
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Cygwin is case insensitive, so bootblock.s and bootblock.S in the
same directory cause a build failure. This changes bootblock.S
to bootblock_inc.S, as it is generated from bootblock_inc.
crt0.S and crt0.S also had this problem. This changes crt0.S to
crt0.romstage.S.
Change-Id: I29d230a93b0743e34f11228f9034880ceaf7ab7b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1032
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Use the coreboot IASL for building SeaBIOS.
Change-Id: Ia6c802b090d53b7fbbc8ddb6edad3de6b822ff41
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1033
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Change source file modes from 755 to 644
The following files have been grepped for changes:
*.c
*.h
*Kconfig*
*Makefile*
Change-Id: I275f42ac7c4df894380d0492bca65c16a057376c
Signed-off-by: Alec Ari <neotheuser@ymail.com>
Reviewed-on: http://review.coreboot.org/1023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Change-Id: I1ec7a7e54513671331ac12f08d5f59161b72b0fd
Example:
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/994
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CBMEM_ID_RESUME_SCRATCH area is only used by Agesa code, on one
particular board (AMD Persimmon). Make the creation of that section
depending on Agesa so it does consume space on non-Agesa systems.
Change-Id: I2a1a4f76991ef936ea68cf75928b20b7ed132b84
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/992
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of the special case in the generic Makefile.inc,
use cbfs-files in the CPU directories.
Change-Id: I71d9c8dff906c9a516ac0dd09a315f8956075592
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/962
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
stages have special cbfstool syntax, which we need to support.
Change-Id: I119255246af818f010acfc7ec2091a6184e74eb3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/961
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This code fixes the sandybridge C state generation code to work with
the current version of the ACPI code generator.
Change-Id: I56ae1185dc0694c06976236523fdcbe5c1795b01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/950
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's used by Sandybridge specific C state generation code.
Change-Id: Ia6f1e14e748841a9646fd93d0a18f9e8f2a55e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/949
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... in order to unify the Sandybridge and Lenovo implementations
currently used in the tree.
- use acpi_addr_t in acpigen_write_register()
- use acpi_cstate_t for cstate tables (and fix up
the x60 and t60)
- drop cst_entry from acpigen.h
Change-Id: Icb87418d44d355f607c4a67300107b40f40b3b3f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/943
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
since it is used in CPU specific ACPI generation code
Change-Id: I2559658f43c89dc5b4dc8230dea8847d2802990c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/947
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If compiling coreboot with ChromeOS support, two
more include files are required.
Change-Id: I7e042e250e4a89e7dd4bab58443824d503c3f709
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/931
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Added a union to identify the byte that was reserved in the
Generic Address Structure from ACPI 2.0 to ACPI 2.0b as the
Access Size byte for ACPI 2.0c to ACPI 5.0
- Added various #defines for use in the FADT
- Added a couple of comments for the #endifs
Change-Id: I294ddfd89fcb0ad88bb6e52d911f807d84671e82
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Move final build results under $(objcbfs).
Move intermediate files under $(objgenerated).
Remove use of sed -i.
Change-Id: Ie035a1544848b26514a197c340f470201065b8d5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
$(obj)/coreboot_ap -> $(objcbfs)/coreboot_ap.elf
It is really a ramstage for AP CPU and not a romstage, it is not
enabled for any mainboard by default, and it doesn't compile
even if enabled.
Change-Id: Ifb9c5cb6df65309660b000876cf6a9a3da9b6839
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/840
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit d4d5e4d3e1 contains #ifdef instead
of #if, making the FSB/serial bus selection for APIC always select serial
bus. The bug is harmless on most chipsets because the bit is often RO,
but it breaks at least on VIA K8T890.
Change-Id: I89c4855922199eca7f921c3e4eb500656544c8e5
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/921
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Final build results (.elf, .debug, .map) are to be placed under
directory $(objcbfs), the default is:
$(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/
Intermediate build results (.o, .s, .S, .inc, .ld) that do not have
a clear one-to-one relation to a file under src/ are to be placed
under directory $(objgenerated), the default is:
$(obj)/generated
Also defines implicit rules for final build results:
.debug -> .elf and .map
.elf -> .bin
Change-Id: I448c6b7c9a952e54170df42091d7db438025a795
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/858
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
As cmos.layout parsing capabilities are already there in nvramtool,
use those than using build_opt_tbl.c. Add binary and header file
generation in nvramtool. Make appropriate changes to Makefile.inc.
Change-Id: Iaf3f5d4f51451aeb33c92800a0c895045f2388cf
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/898
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
HEST feature starts from ACPI 4.0.
HEST is one of four kinds of tables of ACPI Platform Error
Interfaces (APEI). In Windows world, APEI is called Windows Hardware
Error Architecture (WHEA).
APEI consists of four separate tables:
1. Error Record Serialization Table (ERST)
2. BOOT Error Record Table (BERT)
3. Hardware Error Source Table (HEST)
4. Error Injection Table (EINJ)
All these 4 tables have the same header as FADT, MADT, etc. They are
pointed by RSDP.
For the HEST, it contains the error source. The types of them are
defined as
type description
1. Machine Check Exception (MCE)
2. Corrected Machine Check (CMC)
3. NMI Error
6. PCI Express Root Port AER
7. PCI Express Device AER
8. PCI Express Bridge AER
9. Generic Hardware Error Source
Error source types 3, 4, and 5 are reserved for legacy reasons and
must not be used.
Currently AMD board only provide part of "Machine Check
Exception (MCE)" & Corrected Machine Check (CMC)". we need to provide
the header of each error source. Other types of Error Sources is in
TODO list.
Only persimmon is tested. Linux can add HEST feature. The dmesg says,
ACPI: HEST 0000000066fe5010 00198 (v03 CORE COREBOOT 00000000 CORE 00000000)
......
HEST: Table parsing has been initialized.
No more message is got.
Windows can boot with this patch. Havent found a way to test it.
Change-Id: I447e7f57b8e8f0433a145a43d0710910afabf00f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/888
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Some places still hardcoded the address instead of using IO_APIC_ADDR.
Change-Id: I3941c1ff62972ce56a5bc466eab7134f901773d3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix regression after commit:
7dfe32c540
Only align 16-bit entry on platforms that really require it,
indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig.
Disable assertion test of AP_SIPI_VECTOR for platforms not
depending on this feature.
Build of romstage should be fixed to get the vector address from
bootblock build automatically.
Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/875
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function can be used outside of the normal CPU setup
Change-Id: I810c63b8aff868a6f69d5b992bea1cfae5a5996b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/868
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In ChromeOS we potentially have different payloads with
different versions. Since the user land tools get information
on which one of them is loaded, leave the string in smbios
empty so we can fill it out in the payload.
Also fill out system version number and serial number with
some constant values.
Change-Id: Id1fed5a54b511c730975fa83347452f1274b8504
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/867
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
ChromeOS uses two extensions to the coreboot table:
- ChromeOS specific GPIO description for onboard switches
- position of verified boot area in nvram
Change-Id: I8c389feec54c00faf2770aafbfd2223ac9da1362
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/866
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and always include IP checksumming in romstage.
It's generally useful and our upcoming port needs it.
Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/827
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some mainboards (most likely laptops) will need mainboard specific functions
called upon a resume from suspend.
Change-Id: If1518a4b016bba776643adaef0ae64ff49f57e51
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/852
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We changed our verified boot initialization to run from romstage,
as that allows faster boot times and does not add as much ChromeOS
specific code to generic files.
Change-Id: Id4164c26d524ea0ffce34467cf91379a19a4b2f6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The socket mPGA604 is for P4 Xeon which to my knowledge is always
HT-enabled. I assume the existing usage of car/cache_as_ram.inc
on socket_mPGA604, namely the Tyan S2735, as broken.
Existing car/cache_as_ram.inc has invalid SIPI vector and it does
not initialise AP CPU's to activate L2 cache.
Other mPGA604 boards are not affected, as they have not been
converted to CAR.
Change-Id: I7320589695c7f6a695b313a8d0b01b6b1cafbb04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/607
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The x86 memcpy() implementation did not mention its implicit output
registers ESI, EDI and ECX which might make this code miscompile when
the compiler uses the value of EDI for the return value *after* the 'rep
movsb' has completed. That would break the API of memcpy as this would
return 'dst+len' instead of 'dst'.
Fix this possible bug by removing the wrong comment and listing all
output registers as such (using dummy stack variables that get optimized
away).
Also the leading 'cld' is superflous as the ABI mandates the direction
flag to be cleared all the time when we're in C (see
<http://gcc.gnu.org/gcc-4.3/changes.html>) and we have no ASM call sites
that might require it to be cleared explicitly (SMM might come to mind,
but it clears the DF itself before passing control to the C part of the
SMI handler).
Last but not least fix the prototype to match the one from <string.h>.
Change-Id: I106422d41180c4ed876078cabb26b45e49f3fa93
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/836
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
For a hyper-threading processor, enabling cache requires that both the
BSP and AP CPU clear CR0.CD (Cache Disable) bit. For a Cache-As-Ram
implementation, partial multi-processor initialisation precedes
raminit and AP CPUs' 16bit entry must be run from ROM.
The AP CPU can only start execute real-mode code at a 4kB aligned
address below 1MB. The protected mode entry code for AP is identical
with the BSP code, which is already located at the top of bootblock.
This patch takes the simplest approach and aligns the bootblock
16 bit entry at highest possible 4kB boundary below 1MB.
The symbol ap_sipi_vector is tested to match CONFIG_AP_SIPI_VECTOR
used by the CAR code in romstage. Adress is not expected to ever
change, but if it does, link will fail.
Change-Id: I82e4edbf208c9ba863f51a64e50cd92871c528ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/454
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
After change it is more clear how romstage is linked twice and with
what scripts. Also with the change, it is easier to add some
object of static size that need to be re-compiled for the 2nd link.
One such object could be md5sum of executable.
Change-Id: Ib34d1876071a51345c5c7319a0ed937868817fd1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/803
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There were cases where output file was generated and modified within
a recipe. If make was interrupted, it could exit with an output file
that appears as up-to-date, but was generated with incomplete recipe.
The output file should be created only when successful, in an atomic
operation. There could be other places in the make system which
require a similar fix, this needs to be investigated further.
Change-Id: I25c8ee23577a460eace196fd28c23cc67aa72a9a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/830
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's not significantly faster, but easier to read and smaller.
Change-Id: Ibab0b478873912d67bf1f07743f628586353368a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/755
Reviewed-by: Mathias Krause <minipli@googlemail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I forgot to implement this the first time around.
It does not seem to cause noticeable problems but
in heavy suspend/resume testing I saw a suspicious
crash in the kernel when trying to bring one of the
CPUs back online.
Change-Id: I950ac260f251e2683693d9bd20a0dd5e041aa26e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since we do not run option roms in normal mode nothing was
initializing the BDA/EBDA and yet Linux depends very much
on it having sane values here. For the most part the kernel
tries to work around this not being initialized, but every
once in awhile (1/300 boots or so) it would end up reading
something that looked sane from BDA but was not and then
it would panic.
In this change the EBDA is unconditionally setup before devices
are initialized. I'm not set on the location in dev_initialize()
but there does not seem to be another place to hook it in so
that it runs just once for ALL platforms regardless of whether
they use option roms or not. (possibly hardwaremain?)
The EBDA setup code has been moved into its own location in
arch/x86/lib/ebda.c so it can be compiled in even if the option
rom code is not.
The low memory size is still set to 1MB which is enough to make
linux happy without having to hook into each mainboard to get a
more appropriate value. The setup_ebda() function takes inputs
so it could be changed for a mainboard if needed.
OLD/BROKEN would read garbage. Examples from different boots:
ebda_addr=0x75e80 lowmem=0x1553400
ebda_addr=0x5e080 lowmem=0x3e51400
ebda_addr=0x7aa80 lowmem=0x2f8a800
NEW/FIXED now reads consistent values:
ebda_addr=0xf6000 lowmem=0x100000
Change-Id: I6cb79f0e3e43cc65f7e5fe98b6cad1a557ccd949
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/769
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This avoids using EBX and instead uses EDI where possible,
and ESI when necessary to get the EBX value out.
This allows me to enable -fpic for SMM TSEG code.
Also add a new CPUID extended function to query with ECX set.
Change-Id: I10dbded3f3ad98a39ba7b53da59af6ca3145e2e5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/764
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
It's not used on any board supported by coreboot but has been
detected at run time since ages. No new boards (since 2000?)
are using the CONF2 method, so it is unlikely we ever have to
turn this on for a board.
Change-Id: I17df94a8a77b9338fde10a6b114b44d393776e66
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/758
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a number of timestamps in ramstage and romstage
so we can figure out where execution time goes.
Change-Id: Iea17c08774e623fc1ca3fa4505b70523ba4cbf01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/749
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It looks like the cbfstool utility generates the output file even when
it fails to generate it properly. This causes make, if started second
time in a row, after cbfstool failure, to continue beyond the point of
failure (as the corrupted output file is present in the output tree,
the second make invocation presumes that it is valid, as it is newer
than the dependencies).
The output file should be created only when successful, in an atomic
operation. There could be other places in the make system which
require a similar fix, this needs to be investigated further.
Change-Id: I7c17f033ee5937eb712b1a594122430cee5c9146
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/750
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
and initialize the TPM on S3 resume
This patch integrates the TPM driver and runs TPM resume upon an ACPI S3
resume without including any other parts of vboot.
We could link against vboot_fw.a but it is compiled with u-boot's CFLAGS
(that are incompatible with coreboot's) and it does a lot more than we
want it to do.
Change-Id: I000d4322ef313e931e23c56defaa17e3a4d7f8cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cbmem console structure and car global data are put in their own section,
with the cbmem console coming after the global data. These areas are linked
to be where CAR is available and at the very bottom of the stack.
There is one shortcoming of this change:
The section created by this change needs to be stripped out by the Makefile
since leaving it in confuses cbfstool when it installs the stage in the image.
I would like to make the tools link those symbols at the right location but
leave allocation of that space out of the ELF.
Change-Id: Iccfb99b128d59c5b7d6164796d21ba46d2a674e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/727
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use an int in CAR global data to store whether or not the OXPCIE serial card
is actually there. Also, time out if the card doesn't show up quickly enough,
don't continue initialization if it's not there, and don't make the
initialization routine default to a card if none is found.
Change-Id: I9c72d3abc6ee2867b77ab2f2180e6f01f647af8c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/728
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We need to provide u-boot access to several different CBMEM
sections. To do that, a common coreboot table structure is used,
just different tags match different coreboot table sections.
Also, the code is added to export CBMEM console and MRC cache
addresses through the same mechanism.
Change-Id: I63adb67093b8b50ee61b0deb0b56ebb2c4856895
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change exports the timestamp table pointer through coreboot
table to make it possible for u-boot to add timestamps to the
table.
Inclusion of cbmem.h allows to drop external declarations in
coreboot_table.c.
Change-Id: Ia070198cee7a6ffdaeece03d9d15bd91e033b6d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The new added code is compiled in when the CBMEM_CONSOLE config
flag is enabled.
Change-Id: Ifd1f492ce6321412a014333babbc5b3f14635988
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/721
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Renamed CONFIG_ROMBASE to ROMSTAGE_BASE and removed it from Kconfig.
Removed no-op calculation in ldscript.
Change-Id: I53d39b60f07db76c8537b3133e59360687b9d4a7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/802
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Provide a way to redefine the names of normal and fallback via CBFS.
This way updates can use some more expressive naming scheme (numbers,
dates, version numbers) and replace the coreboot-stages file to
point to the new version (with the current version as new "old").
If coreboot-stages doesn't exist, the default behaviour remains to
use "normal" and "fallback".
Change-Id: I77c134d79ed95831ad5098b7663c15e95d3b5a2a
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/589
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Also any CPU_AMD_AGESA_FAMILYxx selects CPU_AMD_AGESA, so remove
the explicit selects from the mainboards.
Change-Id: I4d71726bccd446b0f4db4e26448b5c91e406a641
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/792
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
clang is more picky on that.
Change-Id: Iaa8472beb6e275c39037d11e1a72dbb80d46424b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/779
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The original comment says it's a Via C3 and not Epia requirement
to deliver IOAPIC interrupts on APIC serial bus.
Change-Id: I73c55755e0ec1ac5756b4ee7ccdfc8eb93184e4f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/435
Tested-by: build bot (Jenkins)
This way u-boot won't try to use a UART that isn't plugged in.
Change-Id: I9a3a0d074dd03add8afbd4dad836c4c6a05abe6f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/729
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Packing a device tree into the coreboot table can easily make
the table exceed the current limit of 8KB. However, right now
there is no error handling in place to catch that case.
Increase the maximum memory usable for all tables from 64KB to
128KB and increase the maximum coreboot table size from 8KB
to 32KB.
Change-Id: I2025bf070d0adb276c1cd610aa8402b50bdf2525
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/704
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The code when reporting the coreboot table size did not account
for the last added table record. This change fixes the problem.
. rebuild coreboot, program it on the target, restart it
. look for 'Wrote coreboot table at:' in the console log
. observe the adequate table size reported
$ grep 'Wrote coreboot table:' /tmp/cb.log
Wrote coreboot table at: 00000500, 0x10 bytes, checksum c06f
Wrote coreboot table at: 7f6fc000, 0x1a73 bytes, checksum 3e45
$
Change-Id: Ic55501a4ae06fab2bcda9aea58e362325f2edccf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/703
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CONFIG_ variables are used inconsistently within the file
src/arch/x86/boot/coreboot_table.c. #ifdef will do the wrong
thing if the option is disabled. #if (CONFIG_FOO == 1) is
not needed.
Change-Id: Ifcac6ceac5fb34b931281beae500023597b3533b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/701
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
We used several names for that same value, and hardcoded the value
at some more places.
They're all LOCAL_APIC_ADDR now (except for lapic specific code
that still uses LAPIC_DEFAULT_BASE).
Change-Id: I1d4be73b1984f22b7e84681edfadf0588a7589b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Also mark the corresponding lint test stable.
Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After CPUID, requested feature flag is in edx, not eax.
Change-Id: I9ce27c22186f17cc64986be342d7d1ac78a79898
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/688
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
When the romstage.bin becomes bigger than the size of XIP, the
cbfstool can not allocate the romstage in the CBFS. But it doesn't
report an error. It will take quite a while to find out the root
cause.
Change-Id: I5be2a46a8b57934f14c5a0d4596f3bec4251e0aa
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/650
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Make sure SeaBIOS build files live under $(OUT) instead of
in the source tree.
Change-Id: I7d357773e32bc25ba7e7eae3fb6ddc31feb413ec
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/552
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
CPUs with CPUID level >= 0x80000008 can return
the number of physical address bits.
Change-Id: I1c0523b6a091c476af838d173ed9030280360d7f
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/599
Tested-by: build bot (Jenkins)
Moved the conditional compilation out of the source file
Change-Id: Ic4045006f39d70f4a0bc37d1bd5e073ed8477c68
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/578
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to use SSE+MMX optimized payloads we don't want to disable SSE+MMX
instructions in the CPU after romstage.
Change-Id: I51aeb01f04492ad7bc8b1fe181a4ae17fe0ca61e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/553
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There was no good way to extract the build version from an image.
This change will be mostly backward compatible: The only assumption
that could break is that the board name string ends directly before
the 3 dwords that represent .id's "header".
Change-Id: I325491a0c42911d9d6ecd59e21ee1b756c987693
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/537
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
The current code uses static values for the physical address size
supported by a CPU. This isn't always the right value: I.e. on
model_6[ef]x Core (2) Duo CPUs physical address size is 36, while
Xeons from the same family have 38 bits, which results in invalid
MTRR setup. Fix this by getting the right number from CPUID.
Change-Id: If019c3d9147c3b86357f0ef0d9fda94d49d811ca
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function prevents the linker from choosing the right
get_cst_entries(), preventing writing the _CST tables.
Change-Id: I4bc0168aee110171faeaa081f217dfd1536bb821
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/496
Tested-by: build bot (Jenkins)
CMOS accesses are not safe for multi-processor and only the BSP CPU
should count reboots and test CMOS sanity.
A questionable single byte CMOS read access from AP CPUs remains.
AP CPUs should always select the same romstage prefix as BSP CPU.
Change-Id: I29118e33c07c0080c94abb90f703e38312c72432
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/446
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Allocation size for the section was miscalculated, so the section
did not honour its upper-bound address.
Also align the section start to 4 bytes, so it starts with code
instead of pad bytes.
Change-Id: Ic2a43981836a0873b50abecfcad2def7b6586a5d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/453
Tested-by: build bot (Jenkins)
Reviewed-by: Alec Ari <neotheuser@ymail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Detection of a CPU being a BSP CPU is not dependent of the existence
of northbridge and/or southbridge init code in the bootblock.
Even if CONFIG_LOGICAL_CPUS==0, boot_cpu() can get executed on an AP
CPU of a hyper-threading CPU and needs to return actual BSP bit from
MSR.
Change-Id: I9187f954bb357ba1dbd459cfe11cc96cb7567968
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Following files were no longer used in the build and are deleted:
src/arch/x86/init/entry.S
src/arch/x86/init/ldscript.ld
Also fix ugly whitespace in code copyrights and comments.
Change-Id: Ia6360b0ffc227f372d5f997495697a101f7ad81b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/440
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Relocate early post_code() so it gets executed and does not corrupt
BIST at %eax.
Change-Id: Ieeebcb23f7c327e501b410eaa60d1e49110ee988
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/439
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This was split out when we had separate rules for big bootblock.
Change-Id: Id0a117f6996fb6bdef7bf97e7d80c36f5dec0ad7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/404
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The rule to prepare a new coreboot.pre1 was ignored in the
"update image" scenario because a perfectly fine file exists.
Mark it phony to fix it.
Change-Id: Ie7f8b36b71015a593958cd6e19602bad6b854320
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/351
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change removes CONFIG_TINY_BOOTBLOCK, CONFIG_BIG_BOOTBLOCK, and
all their uses, assuming TINY_BOOTBLOCK=y, BIG_BOOTBLOCK=n.
This might break a couple of boards on runtime, but so far, fixes were
quite simple.
There's a flag day: Code that relies on CONFIG_TINY_BOOTBLOCK must be
adapted.
Change-Id: I1e17a4a1b9c9adb8b43ca4db8aed5a6d44d645f5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/320
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That value is now generated from a code address and CONFIG_XIP_ROM_SIZE.
This works as MTRRs are fully specified by their size and any address
within the range.
Change-Id: Id35d34eaf3be37f59cd2a968e3327d333ba71a34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/348
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Linux 2.6.11 seems to require a certain order in CPUs listed in mptable,
so enforce it. This was only done on arima/hdama, but now is generic.
Unfortunately this is somewhat slow.
Change-Id: I85715ebae8a009cb816bc9ffd6372708f246bf66
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add information about memory mapped/io mapped base addresses.
and fix up libpayload to use the same structures
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I5f7b5eda6063261b9acb7a46310172d4a5471dfb
Reviewed-on: http://review.coreboot.org/261
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stefan Reinauer