Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.
Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>
If the debug UART is enabled, get it ready for use at the earliest possible
opportunity. This is not actually very early, but until we have a stack it
is difficult to make it work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add some comments in start.S for the fact that with FSP U-Boot
actually enters the code twice. Also change to use fsp_init()
and fsp_continue for accuracy.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.
Drop the unneeded code and adjust the hooks in board_f.c to cope.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.
Unfortunately the debug UART implementation needs a stack to work. I cannot
seem to remove this limitation as the absolute 'jmp %eax' instruction goes
off into the weeds.
So this means that the character output cannot be any earlier than
car_init_ret, where memory is available for a stack.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.
Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find the 32-bit cold reset entry point. Previously this was at a
fixed offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix a typo, improve some comments and add a little more detail in some
cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
It worked pretty well but looks not that good. Apart from doing too
much work than just enabling CAR, it cannot read the configuration
data from device tree at that time. Now we want to move it a little
bit later as part of init_sequence_f[] being called by board_init_f().
This way it looks and works better in the U-Boot initialization path.
Due to FSP's design, after calling FspInitEntry it will not return to
its caller, instead it jumps to a continuation function which is given
by bootloader with a new stack in system memory. The original stack in
the CAR is gone, but its content is perserved by FSP and described by
a bootloader temporary memory HOB. Technically we can recover anything
we had before in the previous stack, but that is way too complicated.
To make life much easier, in the FSP continuation routine we just
simply call fsp_init_done() and jump back to car_init_ret() to redo
the whole board_init_f() initialization, but this time with a non-zero
HOB list pointer saved in U-Boot's global data so that we can bypass
the FspInitEntry for the second time.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Tested-by: Simon Glass <sjg@chromium.org>
Various files are needlessly rebuilt every time due to the version and
build time changing. As version.h is not actually needed, remove the
include.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Macpaul Lin <macpaul@andestech.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: York Sun <yorksun@freescale.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Cc: Eric Jarrige <eric.jarrige@armadeus.org>
Cc: "David Müller" <d.mueller@elsoft.ch>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Torsten Koschorrek <koschorrek@synertronixx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Łukasz Majewski <l.majewski@samsung.com>
For platforms with CAR we should disable it before relocation. Check if
this function is available and call it if so.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
On x86 it is common to use 'post codes' which are 8-bit hex values emitted
from the code and visible to the user. Traditionally two 7-segment displays
were made available on the motherboard to show the last post code that was
emitted. This allows diagnosis of a boot problem since it is possible to
see where the code got to before it died.
On modern hardware these codes are not normally visible. On Chromebooks
they are displayed by the Embedded Controller (EC), so it is useful to emit
them. We must enable this feature for the EC to see the codes, so add an
option for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The built in self test value is available in register eax on start-up. Save
it so that it can be accessed later. Unfortunately we must wait until the
global_data is available before we can do this, so there is a little bit of
shuffling to keep it around.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is a little muddled, so tidy it up. Make sure that we put the
GDT in the right place and set it up properly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To permit information to be passed from the early U-Boot code to
board_init_f() we cannot zero the global_data in board_init_f(). Instead
zero it in the start-up code.
Signed-off-by: Simon Glass <sjg@chromium.org>
We currently assume that the global data pointer is at the start of
struct global_data. We want to remove this restriction, and it is
easiest to do this in C.
Remove the asm code and add equivalent code in C.
This idea was proposed by Graeme Russ here:
http://patchwork.ozlabs.org/patch/199741/
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Apply Graeme Russ' comments
http://patchwork.ozlabs.org/patch/206305/ here, re-order]
Signed-off-by: Tom Rini <trini@ti.com>
These were removed, but actually are useful.
Cold means that we started from a reset/power on.
Warm means that we started from another U-Boot.
We determine whether u-boot on x86 was warm or cold booted (really if
it started at the beginning of the text segment or at the ELF entry point).
We plumb the result through to the global data structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Putting global data on the stack simplifies the init process (and makes it
slightly quicker). During the 'flash' stage of the init sequence, global
data is in the CAR stack. After SDRAM is initialised, global data is copied
from CAR to the SDRAM stack
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the base address of the 'F' segment as a pointer to the global data
structure. By adding the linear address (i.e. the 'D' segment address) as
the first word of the global data structure, the address of the global data
relative to the 'D' segment can be found simply, for example, by:
fs movl 0, %eax
This makes the gd 'pointer' writable prior to relocation (by reloading the
Global Desctriptor Table) which brings x86 into line with all other arches
NOTE: Writing to the gd 'pointer' is expensive (but we only do it
twice) but using it to access global data members (read and write) is
still fairly cheap
--
Changes for v2:
- Rebased against changes made to patch #3
- Removed extra indent
- Tweaked commit message
Move the relocation offset calculation out of assembler and into C. This
also paves the way for the upcoming init sequence simplification by adding
the board_init_f_r flash to RAM transitional function
--
Changes for v2:
- Added commit message
- Minor adjustment to new stack address comment
By adding a multiboot header, U-Boot can be loaded by GRUB2. Using GRUB2 to
bootstrap U-Boot is useful for using an existing BIOS to get an initial
U-Boot port up and running before implementing the low-level reset vector
code, SDRAM init, etc. and overwriting the BIOS
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
There was a mix of UTF-8 and ISO-8859 files in the U-Boot source
tree, which could cause issues with the patchwork review system.
This commit converts all ISO-8859 files to UTF-8.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Recieve/Receive
recieve/receive
Interupt/Interrupt
interupt/interrupt
Addres/Address
addres/address
Signed-off-by: Mike Williams <mike@mikebwilliams.com>
Make the copyright notices in the x86 files consistent and update them with
proper attributions for recent updates
Also fix a few comment style/accuracy and whitespace/blank line issues
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
early_board_init has been skipped to avoid SDRAM corruption in the case
that a fully relocatable image has been loaded into SDRAM and is being
executed from SDRAM. x86 is being aligned with other architectures (ARM
and PPC in particlar) and will be using Cache-As-RAM to run a C
environment from Flash (or SRAM if you have some). early_board_init may
be needed to assist in the setup of Cache-As-RAM and the early C
environment
u-boot.bin can be loaded at any 4-byte aligned memory location and directly
'jumped' to using the 'go' command using the load address as the start
address. Doing so performs a 'warm boot' which skips memory initialisation
and other low-level initialisations, relocates U-Boot to upper memory and
starts U-Boot in RAM as per normal 'cold boot'
By reserving space for the Global Data immediately below the stack during
assembly level initialisation, the C declaration of the static global data
can be removed, along with the 'RAM Bootstrap' function. This results in
cleaner code, and the ability to pass boot-up flags from assembler into C
Simon Glass
Albert ARIBAUD
Bin Meng
Rob Herring
Wolfgang Denk
Gabe Black
Graeme Russ
Mike Williams