x86: Fix out of bounds irq handlers access

Using coreboot-x86_defconfig, the following error occurred prior to this modification:
CC arch/x86/lib/interrupts
arch/x86/lib/interrupts.c: In function ‘d

x86: Fix out of bounds irq handlers access

Using coreboot-x86_defconfig, the following error occurred prior to this modification:
CC arch/x86/lib/interrupts
arch/x86/lib/interrupts.c: In function ‘do_irqinfo’:
arch/x86/lib/interrupts.c:134:24: error: iteration 16u invokes undefined behavior [-Werror=aggressive-loop-optimizations]
if (irq_handlers[irq].handler != NULL) {
^
arch/x86/lib/interrupts.c:133:2: note: containing loop
for (irq = 0; irq <= CONFIG_SYS_NUM_IRQS; irq++) {
^
cc1: all warnings being treated as errors
scripts/Makefile.build:275: recipe for target 'arch/x86/lib/interrupts.o' failed
make[1]: *** [arch/x86/lib/interrupts.o] Error 1
Makefile:1093: recipe for target 'arch/x86/lib' failed
make: *** [arch/x86/lib] Error 2

Change-Id: I3572a822081b72ab760f1eb99442e1161d3d167e
Signed-off-by: Sebastien Ronsse <sronsse@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Allow a hardcoded TSC frequency provided by Kconfig

By default U-Boot automatically calibrates TSC running frequency via
MSR and PIT. The calibration may not work on every x86 processor, so
a n

x86: Allow a hardcoded TSC frequency provided by Kconfig

By default U-Boot automatically calibrates TSC running frequency via
MSR and PIT. The calibration may not work on every x86 processor, so
a new Kconfig option CONFIG_TSC_CALIBRATION_BYPASS is introduced to
allow bypassing the calibration and assign a hardcoded TSC frequency
CONFIG_TSC_FREQ_IN_MHZ.

Normally the bypass should be turned on in a simulation environment
like qemu.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: fsp: Drop get_hob_type() and get_hob_length()

These two are not worth having separate inline functions as they are
really simple, so drop them.

Also changed 'type' parameter of fsp_get_next_ho

x86: fsp: Drop get_hob_type() and get_hob_length()

These two are not worth having separate inline functions as they are
really simple, so drop them.

Also changed 'type' parameter of fsp_get_next_hob() from u16 to uint.

Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Add an 'mtrr' command to list and adjust MTRRs

It is useful to be able to see the MTRR setup in U-Boot. Add a command
to list the state of the variable MTRR registers and allow them to be
chang

x86: Add an 'mtrr' command to list and adjust MTRRs

It is useful to be able to see the MTRR setup in U-Boot. Add a command
to list the state of the variable MTRR registers and allow them to be
changed.

Update the documentation to list some of the available commands.

This does not support fixed MTRRs as yet.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Commit the current MTRRs before relocation

Once we stop running from ROM we should set up the MTTRs to speed up
execution. This is only needed for platforms that don't have an FSP.
Also in the

x86: Commit the current MTRRs before relocation

Once we stop running from ROM we should set up the MTTRs to speed up
execution. This is only needed for platforms that don't have an FSP.
Also in the Coreboot case, the MTRRs are set up for us.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Tidy up VESA mode numbers

There are some bits which should be ignored when displaying the mode number.
Make sure that they are not included in the mode that is displayed.

Signed-off-by: Simon

x86: Tidy up VESA mode numbers

There are some bits which should be ignored when displaying the mode number.
Make sure that they are not included in the mode that is displayed.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Use cache, don't clear the display in video BIOS

There is no need to run with the cache disabled, and there is no point in
clearing the display frame buffer since U-Boot does it later.

Signed-

x86: Use cache, don't clear the display in video BIOS

There is no need to run with the cache disabled, and there is no point in
clearing the display frame buffer since U-Boot does it later.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Simplify the fsp hob access functions

Remove the troublesome union hob_pointers so that some annoying casts
are no longer needed in those hob access routines. This also improves
the readability

x86: Simplify the fsp hob access functions

Remove the troublesome union hob_pointers so that some annoying casts
are no longer needed in those hob access routines. This also improves
the readability.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Clean up the FSP support codes

This is the follow-on patch to clean up the FSP support codes:

- Remove the _t suffix on the structures defines
- Use __packed for structure defines
- Use U-Boot

x86: Clean up the FSP support codes

This is the follow-on patch to clean up the FSP support codes:

- Remove the _t suffix on the structures defines
- Use __packed for structure defines
- Use U-Boot's assert()
- Use standard bool true/false
- Remove read_unaligned64()
- Use memcmp() in the compare_guid()
- Remove the cast in the memset() call
- Replace some magic numbers with macros
- Use panic() when no valid FSP image header is found
- Change some FSP utility routines to use an fsp_ prefix
- Add comment blocks for asm_continuation and fsp_init_done
- Remove some casts in find_fsp_header()
- Change HOB access macros to static inline routines
- Add comments to mention find_fsp_header() may be called in a
stackless environment
- Add comments to mention init(&params) in fsp_init() cannot
be removed

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: move arch-specific asmlinkage to <asm/linkage.h>

Commit 65dd74a674d6 (x86: ivybridge: Implement SDRAM init) introduced
x86-specific asmlinkage into arch/x86/include/asm/config.h.

Commit ed0a2f

x86: move arch-specific asmlinkage to <asm/linkage.h>

Commit 65dd74a674d6 (x86: ivybridge: Implement SDRAM init) introduced
x86-specific asmlinkage into arch/x86/include/asm/config.h.

Commit ed0a2fbf14f7 (x86: Add a definition of asmlinkage) added the
same macro define again, this time, into include/common.h.
(Please do not add arch-specific stuff to include/common.h any more;
it is already too cluttered.)

The generic asmlinkage is defined in <linux/linkage.h>. If you want
to override it with an arch-specific one, the best way is to add it
to <asm/linkage.h> like Linux Kernel.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Add a simple command to show FSP HOB information

FSP builds a series of data structures called the Hand-Off-Blocks
(HOBs) as it progresses through initializing the silicon. These data
structure

x86: Add a simple command to show FSP HOB information

FSP builds a series of data structures called the Hand-Off-Blocks
(HOBs) as it progresses through initializing the silicon. These data
structures conform to the HOB format as described in the Platform
Initialization (PI) specification Volume 3 Shared Architectual
Elements specification, which is part of the UEFI specification.

Create a simple command to parse the HOB list to display the HOB
address, type and length in bytes.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Support Intel FSP initialization path in start.S

Per Intel FSP architecture specification, FSP provides 3 routines
for bootloader to call. The first one is the TempRamInit (aka
Cache-As-Ram ini

x86: Support Intel FSP initialization path in start.S

Per Intel FSP architecture specification, FSP provides 3 routines
for bootloader to call. The first one is the TempRamInit (aka
Cache-As-Ram initialization) and the second one is the FspInit
which does the memory bring up (like MRC for other x86 targets)
and chipset initialization. Those two routines have to be called
before U-Boot jumping to board_init_f in start.S.

The FspInit() will return several memory blocks called Hand Off
Blocks (HOBs) whose format is described in Platform Initialization
(PI) specification (part of the UEFI specication) to the bootloader.
Save this HOB address to the U-Boot global data for later use.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Clean up asm-offsets

Move GD_BIST from lib/asm-offsets.c to arch/x86/lib/asm-offsets.c
as it is x86 arch specific stuff. Also remove GENERATED_GD_RELOC_OFF
which is not referenced anymore.

Sig

x86: Clean up asm-offsets

Move GD_BIST from lib/asm-offsets.c to arch/x86/lib/asm-offsets.c
as it is x86 arch specific stuff. Also remove GENERATED_GD_RELOC_OFF
which is not referenced anymore.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Replace <compiler.h> with <linux/compiler.h>

Including <linux/compiler.h> is enough for general use.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

x86: Add support for running option ROMs natively

On x86 machines we can use an emulator to run option ROMS as with other
architectures. But with some additional effort (mostly due to the 16-bit
nat

x86: Add support for running option ROMs natively

On x86 machines we can use an emulator to run option ROMS as with other
architectures. But with some additional effort (mostly due to the 16-bit
nature of option ROMs) we can run them natively. Add support for this.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Refactor interrupt_init()

Rename interrupt_init() in arch/x86/lib/pcat_interrupts.c to
i8259_init() and create a new interrupt_init() in
arch/x86/cpu/interrupt.c to call i8259_init() followed b

x86: Refactor interrupt_init()

Rename interrupt_init() in arch/x86/lib/pcat_interrupts.c to
i8259_init() and create a new interrupt_init() in
arch/x86/cpu/interrupt.c to call i8259_init() followed by a
call to cpu_init_interrupts().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Call cpu_init_interrupts() from interrupt_init()

Currently cpu_init_interrupts() is called from cpu_init_r() to
setup the interrupt and exception of the cpu core, but at that
time the i8259 has

x86: Call cpu_init_interrupts() from interrupt_init()

Currently cpu_init_interrupts() is called from cpu_init_r() to
setup the interrupt and exception of the cpu core, but at that
time the i8259 has not been initialized to mask all the irqs
and remap the master i8259 interrupt vector base, so the whole
system is at risk of being interrupted, and if interrupted,
wrong interrupt/exception message is shown.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Set up edge triggering on interrupt 9

Add this additional init in case it is needed by the OS.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: Panic if there is no relocation data

This normally indicates a problem which will prevent relocation from
functioning, resulting in a hang. Panic in this case to make it easier
to debug.

Signe

x86: Panic if there is no relocation data

This normally indicates a problem which will prevent relocation from
functioning, resulting in a hang. Panic in this case to make it easier
to debug.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: ivybridge: Implement SDRAM init

Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
the board directory and the SDRAM SPD information in the device tree. This
also needs

x86: ivybridge: Implement SDRAM init

Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
the board directory and the SDRAM SPD information in the device tree. This
also needs the Intel Management Engine (me.bin) to work. Binary blobs
everywhere: so far we have MRC, ME and microcode.

SDRAM init works by setting up various parameters and calling the MRC. This
in turn does some sort of magic to work out how much memory there is and
the timing parameters to use. It also sets up the DRAM controllers. When
the MRC returns, we use the information it provides to map out the
available memory in U-Boot.

U-Boot normally moves itself to the top of RAM. On x86 the RAM is not
generally contiguous, and anyway some RAM may be above 4GB which doesn't
work in 32-bit mode. So we relocate to the top of the largest block of
RAM we can find below 4GB. Memory above 4GB is accessible with special
functions (see physmem).

It would be possible to build U-Boot in 64-bit mode but this wouldn't
necessarily provide any more memory, since the largest block is often below
4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large
ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit
kernels directly so this does not pose a limitation in that area. Also there
are probably parts of U-Boot that will not work correctly in 64-bit mode.
The MRC is one.

There is some work remaining in this area. Since memory init is very slow
(over 500ms) it is possible to save the parameters in SPI flash to speed it
up next time. Suspend/resume support is not fully implemented, or at least
it is not efficient.

With this patch, link boots to a prompt.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Allow timer calibration to work on ivybridge

Unfortunately MSR_FSB_FREQ is not available on this CPU, and the PIT method
seems to take up to 50ms which is much too long.

For this CPU we know t

x86: Allow timer calibration to work on ivybridge

Unfortunately MSR_FSB_FREQ is not available on this CPU, and the PIT method
seems to take up to 50ms which is much too long.

For this CPU we know the frequency, so add another special case for now.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

x86: Remove unnecessary find_fdt(), prepare_fdt() functions

These are no-longer needed so drop them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: Save TSC frequency in the global data

Return the saved TSC frequency in get_tbclk_mhz().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon

x86: Save TSC frequency in the global data

Return the saved TSC frequency in get_tbclk_mhz().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Add quick TSC calibration via PIT

Use the same way that Linux does for quick TSC calibration via PIT
when calibration via MSR fails.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simo

x86: Add quick TSC calibration via PIT

Use the same way that Linux does for quick TSC calibration via PIT
when calibration via MSR fails.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

x86: Do TSC MSR calibration only for known/supported CPUs

Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on
processors which do not have this MSR. Instead only doing the MSR
calibrat

x86: Do TSC MSR calibration only for known/supported CPUs

Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on
processors which do not have this MSR. Instead only doing the MSR
calibration for known/supported CPUs.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...