| Age | Commit message (Collapse) | Author |
|---|
|
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
We have means to easily disable a specific console in romstage if
necessary, so this global option makes little sense.
The option was initially introduced as a work-around for build issues
around CACHE_AS_RAM, ROMCC and ARCH_ARMV7 dependencies for UARTs.
Change-Id: I797bdd11a48ddd813d3ee7ccef9a0c050f16f669
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5607
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Icae8042add5f4dd5c707369ffc4587c613d69d29
Reviewed-on: https://gerrit.chromium.org/gerrit/59324
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4315
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
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>
|
|
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>
|
|
To simplify testing ARM implementation, we need a QEMU configuration for
ARM. The qemu-armv7 provides serial output, CBFS simulation, and full
boot path (bootblock, romstage, ramstage) to verify the boot loader
functionality.
To run with QEMU:
export QEMU_AUDIO_DRV=none
qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom
Verified to boot until ramstage loaded successfully by QEMU v1.0.50.
Change-Id: I1f23ffaf408199811a0756236821c7e0f2a85004
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2354
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
