There's a definition in stdint.h (provided by gcc) which will be more correct
if available.
Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make'
commmand.
This adjusts the settings for x86 and sandbox, with both have 64-bit options.
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Rewritten to be an option, since stdint.h is often available only in glibc.
Changed to preserve a clear boundary between stdint and non-stdint
Signed-off-by: Simon Glass <sjg@chromium.org>
This code doesn't follow the normal approach of having its arch-specific
definitions in an arch-specific directory. Add a new arch-specific file
and make use of it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The private libgcc is supported only on ARM, MIPS, PowerPC, SH, x86.
Those architectures should "select" HAVE_PRIVATE_LIBGCC and
CONFIG_USE_PRIVATE_LIBGCC should depend on it.
Currently, this option is enabled on Tegra boards and x86 architecture.
Move the definition from header files to Kconfig.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC
to a boolean macro so we can move it to Kconfig.
In the current implementation, there are two forms of syntax
for this macro:
- CONFIG_USE_PRIVATE_LIBGCC=y
- CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc
The latter is only used by x86 architecture.
With a little bit refactoring, it can be converted to the former.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
The x86 bootm code is quite special, and geared to zimage. Adjust it
to support device tree and make it more like the ARM code, with
separate bootm stages and functions for each stage.
Create a function announce_and_cleanup() to handle printing the
"Starting kernel ..." message and put it in bootm so it is in one
place and can be used by any loading code. Also move the
board_final_cleanup() function into bootm.
Signed-off-by: Simon Glass <sjg@chromium.org>
These options are used by the image code. To allow us to use the generic
code more easily, define these for x86.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some changes are needed to x86 timer functions to support tracing. Add
these so that the feature works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Coreboot provides a lot of useful timing information. Provide a facility
to add this to bootstage on start-up.
Signed-off-by: Simon Glass <sjg@chromium.org>
While we don't want PCAT timers for timing, we want timer 2 so that we can
still make a beep. Re-purpose the PCAT driver for this, and enable it in
coreboot.
Signed-off-by: Simon Glass <sjg@chromium.org>
This timer runs at a rate that can be calculated, well over 100MHz. It is
ideal for accurate timing and does not need interrupt servicing.
Tidy up some old broken and unneeded implementations at the same time.
To provide a consistent view of boot time, we use the same time
base as coreboot. Use the base timestamp supplied by coreboot
as U-Boot's base time.
Signed-off-by: Simon Glass <sjg@chromium.org>base
Signed-off-by: Simon Glass <sjg@chromium.org>
panic_puts() can be called in early boot to display a message. It might
help with early debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Since we use CONFIG_SYS_GENERIC_BOARD on x86, we don't need this anymore.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>
Graeme Russ pointed out that this code is no longer used. Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>
We create a separate header file for link symbols defined by the link
scripts. It is helpful to have these all in one place and try to
make them common across architectures. Since Linux already has a similar
file, we bring this in even though many of the symbols there are not
relevant to us.
Each architecture has its own asm/sections.h where symbols specifc to
that architecture can be added. For now everything except AVR32 just
includes the generic header.
One change is needed in arch/avr32/lib/board.c to make this conversion
work.
Reviewed-by: Tom Rini <trini@ti.com> (version 5)
Signed-off-by: Simon Glass <sjg@chromium.org>
With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate
it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: Simon Glass <sjg@chromium.org>
With this symbol we can easy append something (e.g. an FDT) to the U-Boot
binary and access it from within U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Add new global_data members to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code is pretty old and we want to support only 32-bit systems now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>
This x86 CPU variant is no longer required as the boards that use it have
been removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>
The libfdt.h file is the definition file for libfdt. It is unnecessary
to include other fdt header files (the necessary ones are pulled in
by libfdt.h).
Signed-off-by: Gerald Van Baren <gvb@unssw.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefan Roese <sr@denx.de>
and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.
this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add arch/x86/cpu/cpu.c changes after Graeme's comments]
Signed-off-by: Tom Rini <trini@ti.com>
We plan to move architecture-specific data into a separate structure so
that we can make the rest of it common.
As a first step, create struct arch_global_data to hold these fields.
Initially it is empty.
This patch applies to all archs at once. I can split it if this is really
a pain.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not intended to be exported from the video drivers, so
remove the prototype. This fixes an error:
cfb_console.c:1793:12: error: static declaration of 'video_init' follows non-static declaration
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
If we have SPI support, make sure that we init it.
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vic Yang <victoryang@chromium.org>
These types should be 64 bits long to reflect the fact that physical
addresses and the size of physical areas of memory are more than 32 bits
long.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
To maintain the initialization state of the timestamp facility, thesq
pointer to the CBMEM section containing the timestamp table should be
kept in the .data section (so that it is maintained across u-boot
relocation).
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This change turns on the code which allows u-boot to add
timestamps to the timestamp table created by coreboot.
Since u-boot does not use the tsc_t like structure to represent
HW counter readings, this structure is being replaced by 64 bit
integer.
The timestamp_init() function is now initializing the base timer
value used by u-boot to calculate the HW counter increments.
Timestamp facility is initialized as soon as the timestamp table
pointer is found in the coreboot table. The u-boot generated
timer events' ID will start at 1000 to clearly separate u-boot
events from coreboot events in the timer trace.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Put this function in the u-boot-x86.h header file. We could instead create
timer.h perhaps.
We support setting a base time, and reading the time relative to this base.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Implement <asm-generic/gpio.h> functions for Intel ICH6 and later.
Only GPIOs 0-31 are handled by this code.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch prevents u-boot from "spamming" random progress codes on
a port 80 "post card".
The previous version of this patch just removed the delays in the "slow"
IO functions, as they do not need to be slow, however, this patch is
less intrusive.
It uses another unused port that is often used by BIOSes (and the Linux
Kernel) for small delay timing purposes.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
The i386 version of io.h depends on the phys_addr_t type which is defined in
types.h. It wasn't including that explicitly, and was working presumably
because the other files including it had already included types.h themselves
directly or indirectly. This change fixes that.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This function provides an opportunity for some last minute cleanup and
reconfiguration before control is handed over to Linux. It's possible this
may need to do something in the future, but for now it's left empty. It's set
up as a weak symbol so it can be overridden if necessary on a case by case
basis.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This change adds a pointer to the global data structure in x86 to point to
the device tree. This mirrors an identical pointer in ARM.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for decoding tags for GPIOs, compile/build info, cbmem and
other features.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
U-boot needs a host controller or "hose" to interact with the PCI busses
behind them. This change installs a host controller during initialization of
the coreboot "board" which implements some of X86's basic PCI semantics. This
relies on some existing generic code, but also duplicates a little bit of code
from the sc520 implementation. Ideally we'd eliminate that duplication at some
point.
It looks like in order to scan buses beyond bus 0, we'll need to tell u-boot's
generic PCI configuration code what to do if it encounters a bridge,
specifically to scan the bus on the other side of it.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>
I suspect these includes were usually available because something else
included them earlier or because they were brought in transitively.
Change-Id: I6aae2ac94dc792eac6febb4345e8125f69f70988
Signed-off-by: Gabe Black <gabeblack@chromium.org>
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>
So it can be used as a type in struct global_data and remove an ugly typecast
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
All the global flag defines are the same across all arches. So unify them
in one place, and add a simple way for arches to extend for their needs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
All arches init this the same way, so move the logic into the core
net code to avoid duplicating it everywhere else.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
This field gets read in one place (by "bdinfo"), and we can replace
that with getenv("ipaddr"). After all, the bi_ip_addr field is kept
up-to-date implicitly with the value of the ipaddr env var.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Create an init function array for board_init_f_r - This finalises the
migration to a purely array based initialisation mechanism
Also tweak a few comments while we are at it so everything is 'correct'
--
Changes for v2:
- Renamed to a more apt name
- Fix bug in set_reloc_flag_r
- Re-instate gd->flags = boot_flags; in board_init_f
- Added commit message
This patch moves towards reducing board.c to simply a set of init cores for
the three initialisation phases (Flash, Flash/RAM, and RAM), a set of three
init function arrays and a init function array processing function
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
If vboot successfully verifies a kernel, it will leave it in place and
basically ready to boot. The zeropage table which is part of the x86 boot
protocol is at the end of the kernel, though, instead of the beginning, and
because the image is already in place there's no need to copy it around.
This change refactors the code which implements the zboot command so that
the configuration of the zeropage table and loading the pieces of the
kernel into memory are done separately. Also, because the command line goes
before the zeropage table in vboot which is somewhat incompatible with the
normal protocol, where to put the command line is a now a parameter instead
of being hard coded.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
This change conditionally modifies the zboot command so that it can use the
32 bit boot protocol. This is necessary because the 16 bit realmode entry
point assumes that it can call BIOS services which neither coreboot nor
u-boot provide.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
This change cleans up some formatting issues in the zimage handling code, and
converts it from using offsets added to a base pointer to using the available
structure definitions which were already being included.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
This change also forces the lib_sysinfo structure to be in the .data
section. Otherwise it ends up in the .bss section. U-boot assumes that it
doesn't need to copy it over during relocation, and instead fills that
whole section with zeroes. If we really were booting from ROM that would be
appropriate, but we need some information from the coreboot tables (memory
size) before then and have to fill that structure before relocation. We
skirt u-boot's assumption by putting this in .data where it assumes there
is still read only but non-zero data.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
The new implementation is about twice as fast as the old. This is from
glibc-2.14, sysdeps/i386/memset.c.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
This pushes the ugly duplicated arch ifdef lists we maintain in various
image related files out to the arch headers themselves.
Acked-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Tested-by: Thomas Chou <thomas@wytron.com.tw>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Allow redirection of console output prior to console initialisation to a
temporary buffer.
To enable this functionality, the board (or arch) must define:
- CONFIG_PRE_CONSOLE_BUFFER - Enable pre-console buffer
- CONFIG_PRE_CON_BUF_ADDR - Base address of pre-console buffer
- CONFIG_PRE_CON_BUF_SZ - Size of pre-console buffer (in bytes)
The pre-console buffer will buffer the last CONFIG_PRE_CON_BUF_SZ bytes
Any earlier characters are silently dropped.
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>
Clean up some duplicated prototype declarations.
Get rid of now useless AVR32 initcalls.h file.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Albert Aribaud <albert.aribaud@free.fr>
Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Graeme Russ <graeme.russ@gmail.com>
Recieve/Receive
recieve/receive
Interupt/Interrupt
interupt/interrupt
Addres/Address
addres/address
Signed-off-by: Mike Williams <mike@mikebwilliams.com>
