Commit graph

48 commits

Author SHA1 Message Date
Andy Shevchenko
1d01d0c2f0 x86: Introduce USE_EARLY_BOARD_INIT option
Introduce USE_EARLY_BOARD_INIT option and select it by the actual users.

Cc: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-01 13:38:31 +08:00
Simon Glass
538c9b3d29 x86: Update the comment about booting for FSP2
The comment here applies only to FSP1, so update it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-07-17 14:32:24 +08:00
Andy Shevchenko
fa97ca161b Revert "x86: use invd instead of wbinvd in real mode start code"
This reverts commit 0d67fac29f.

As real hardware testing (*) shows the above mentioned commit
breaks U-Boot on it. Revert for the upcoming release. We may get
more information in the future and optimize the code accordingly.

(*) on Intel Edison board.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fix a typo in the commit message]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-03-05 18:19:40 +08:00
Masahiro Yamada
0d67fac29f x86: use invd instead of wbinvd in real mode start code
I do not know why the boot code immediately after the system reset
should write-back the cache content. I think the cache invalidation
should be enough.

I tested this commit with qemu-x86_defconfig, and it worked for me.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-04 01:19:26 +08:00
Simon Glass
08deb6d36f x86: Add more comments to the start-up code
The full start-up sequence (TPL->SPL->U-Boot) can be a bit confusing since
each phase has its own 'start' file. Add comments to explain this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-08 13:57:36 +08:00
Simon Glass
6172e94c3c x86: Change condition for using CAR
At present we assume that CAR (Cache-as-RAM) is used if HOBs (Hand-off
blocks) are not, since HOBs typically indicate that an FSP is in use, and
FSPs handle the CAR init.

However this is a bit indirect, and for FSP2 machines which use their own
CAR implementation (such as apollolake) but use the FSP for other
functions, the logic is wrong.

To fix this, add a dedicated Kconfig option to indicate when CAR is used.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fix a typo in the commit message]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-08 13:57:36 +08:00
Stefan Roese
8ad01ce36f x86: Remove x86 specific GD flags as they are not referenced at all
This patch removes the x86 architecture specific GD flags
(GD_FLG_COLD_BOOT & GD_FLG_WARM_BOOT), as they are not used. Only
GD_FLG_COLD_BOOT is referenced in coreboot.c but assigned in start16.S.
But the coreboot target does not use start16.S at all and boots directly
from the 32-bit start code.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-08-18 21:54:10 +08:00
Park, Aiden
544293f878 x86: Add new slimbootloader CPU type
This slimbootloader CPU type is to enable U-Boot as a payload which
runs on top of Slim Bootloader (https://github.com/slimbootloader).
The Slim Bootloader is designed with multi-stage architecture for
the execution from reset vector to OS booting, and supports QEMU,
Apollolake, Whiskeylake and Coffeelake platforms consuming Intel
FSP (https://github.com/IntelFsp) for silicon initialization
including CAR and memory initialization.
The Slim Bootloader generates new HOB (Hand Off Block) which are
serial port info, memory map info, performance data info and so on,
and passes it to a Payload. U-Boot as a payload will use these HOB
information for basic initialization such as serial console.

As an initial commit,
- Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type
- Add new arch/x86/cpu/slimbootloader directory with minimum codes
- Get hob_list pointer from Slim Bootloader

Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-09 22:24:02 +08:00
Simon Glass
49dffb7a07 x86: Add a way to jump from TPL to SPL
When TPL finishes it needs to jump to SPL with the stack set up correctly.
Add a function to handle this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-05-08 13:02:18 +08:00
Bin Meng
3d2be8003c x86: Fix car_uninit weak symbol definition
Since commit 80df194f01 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:

do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 0xfff00087
do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 0xfff00091

Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,

fff00087  000df401 R_386_32          00000000   car_uninit
fff00091  000df402 R_386_PC32        00000000   car_uninit

we see R_386_32 and R_386_PC32 relocation type is generated for
symbol car_uninit, which is declared as a weak symbol in start.S.

However the actual weak symbol implementation ends up nowhere. As
we can see below, it's *UND*.

$ objdump -t u-boot | grep car_uninit
00000000  w      *UND*  00000000 car_uninit

With this fix, it is normal now.

$ objdump -t u-boot | grep car_uninit
fff00094  w    F .text.start    00000001 car_uninit

Reported-by: Hannes Schmelzer <hannes@schmelzer.or.at>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2018-10-28 21:02:15 +08:00
Alexander Graf
7e21fbca26 efi_loader: Rename sections to allow for implicit data
Some times gcc may generate data that is then used within code that may
be part of an efi runtime section. That data could be jump tables,
constants or strings.

In order to make sure we catch these, we need to ensure that gcc emits
them into a section that we can relocate together with all the other
efi runtime bits. This only works if the -ffunction-sections and
-fdata-sections flags are passed and the efi runtime functions are
in a section that starts with ".text".

Up to now we had all efi runtime bits in sections that did not
interfere with the normal section naming scheme, but this forces
us to do so. Hence we need to move the efi_loader text/data/rodata
sections before the global *(.text*) catch-all section.

With this patch in place, we should hopefully have an easier time
to extend the efi runtime functionality in the future.

Signed-off-by: Alexander Graf <agraf@suse.de>
[agraf: Fix x86_64 breakage]
2018-07-25 14:57:44 +02:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Andy Shevchenko
446d4e048e x86: make LOAD_FROM_32_BIT visible for platforms
This option is useful not only for development, but for the platforms
where U-Boot is run from custom ROM bootloader. For example, Intel
Edison is that board.

Make this option visible that platforms can select it if needed.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-02-07 13:36:50 +08:00
Simon Glass
e5aa8a9b15 x86: Support a chained-boot development flow
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>
2016-03-17 10:27:27 +08:00
Albert ARIBAUD
ecc306639e Fix board init code to respect the C runtime environment
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>
2016-01-13 21:05:17 -05:00
Simon Glass
60994a02a5 x86: Init the debug UART if enabled
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>
2015-10-21 07:46:50 -06:00
Bin Meng
48aa6c2614 x86: fsp: Add comments about U-Boot entering start.S twice
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>
2015-08-26 07:54:11 -07:00
Bin Meng
57b10f59b7 x86: fsp: Enlarge the size of malloc() pool before relocation
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>
2015-08-26 07:54:11 -07:00
Simon Glass
f0c7d9c746 x86: Switch to using generic global_data setup
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>
2015-08-14 09:50:10 -06:00
Simon Glass
bbbe55f6f2 x86: Enable debug UART for Minnowmax
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>
2015-08-06 07:44:30 -06:00
Simon Glass
42fde30500 x86: Add support for passing tables into U-Boot
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>
2015-08-05 08:44:07 -06:00
Simon Glass
83ec7de3bc x86: Tidy up global_data flags
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>
2015-08-05 08:42:40 -06:00
Simon Glass
da3a95d60b x86: Add various minor tidy-ups to the 32-bit startup code
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>
2015-08-05 08:42:40 -06:00
Bin Meng
aefaff8ed8 x86: fsp: Move FspInitEntry call to board_init_f()
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>
2015-07-14 18:03:15 -06:00
Rob Herring
7682a99826 remove unnecessary version.h includes
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>
2015-03-24 10:50:50 -04:00
Simon Glass
801d70ce02 x86: Disable CAR before relocation on platforms that need it
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>
2015-01-13 07:25:01 -08:00
Bin Meng
bceb9f0fc8 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>
2014-12-13 22:32:05 -07:00
Bin Meng
fe0c33a5ac 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>
2014-12-13 22:32:04 -07:00
Simon Glass
65dd74a674 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>
2014-11-21 07:34:15 +01:00
Simon Glass
d1cd045982 x86: Emit post codes in startup code for Chromebooks
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>
2014-11-21 07:34:11 +01:00
Simon Glass
f67cd51e65 x86: Save the BIST value on reset
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>
2014-11-21 07:24:10 +01:00
Simon Glass
76f90f3020 x86: Tidy up global descriptor table setup
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>
2014-11-21 07:24:09 +01:00
Simon Glass
5dbcaa2128 dm: x86: Support pre-reloc malloc()
Add support for this by reserving a block of memory below global_data.

Signed-off-by: Simon Glass <sjg@chromium.org>
2014-10-23 19:45:28 -06:00
Simon Glass
fbd7282426 dm: x86: Zero global data before board_init_f()
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>
2014-10-23 19:45:28 -06:00
Wolfgang Denk
1a4596601f Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24 09:44:38 -04:00
Simon Glass
0cecc3b679 x86: Set up the global data pointer in C instead of asm
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>
2013-02-01 15:36:53 -05:00
Gabe Black
91d82a29e7 x86: Add back cold- and warm-boot flags
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>
2012-12-06 14:30:42 -08:00
Graeme Russ
8d61625d6a x86: Put global data on the stack
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>
2012-11-28 11:40:03 -08:00
Graeme Russ
9e6c572ff0 x86: Use fs for global data
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
2012-01-04 22:17:24 +11:00
Graeme Russ
f48dd6fc6c x86: Simplify Flash-to-RAM code execution transition
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
2012-01-04 22:17:20 +11:00
Graeme Russ
109ad143f8 x86: Remove GDR related magic numbers
--
Changes for v2:
 - Use an enum
 - Add defined for GDT size (previously added in patch 7)
 - Use X86_ namespace (as per Linux headers)
2012-01-04 21:05:09 +11:00
Graeme Russ
2f0e0cd246 x86: Misc cleanups
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
2011-11-29 21:10:12 +11:00
Graeme Russ
a206cc2343 x86: Add multiboot header
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>
2011-11-29 21:08:02 +11:00
Graeme Russ
311b1a2b38 sc520: Create arch asm-offsets
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
2011-11-29 21:07:42 +11:00
Graeme Russ
facc9e7bf4 x86: Punt cold- and warm-boot flags
Nobody uses them anyway

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
2011-11-29 21:04:06 +11:00
Albert ARIBAUD
fa82f871c8 Convert ISO-8859 files to UTF-8
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>
2011-08-04 23:34:02 +02:00
Mike Williams
1626308797 cleanup: Fix typos and misspellings in various files.
Recieve/Receive
recieve/receive
Interupt/Interrupt
interupt/interrupt
Addres/Address
addres/address

Signed-off-by: Mike Williams <mike@mikebwilliams.com>
2011-07-28 21:27:36 +02:00
Graeme Russ
fea2572001 x86: Rename i386 to x86
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
2011-04-13 19:43:28 +10:00
Renamed from arch/i386/cpu/start.S (Browse further)