Suriyan Ramasami [Mon, 17 Nov 2014 22:39:38 +0000 (14:39 -0800)]
fs: API changes enabling extra parameter to return size of type loff_t
The sandbox/ext4/fat/generic fs commands do not gracefully deal with files
greater than 2GB. Negative values are returned in such cases.
To handle this, the fs functions have been modified to take an additional
parameter of type "* loff_t" which is then populated. The return value
of the fs functions are used only for error conditions.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
[trini: Update board/gdsys/p1022/controlcenterd-id.c,
drivers/fpga/zynqpl.c for changes] Signed-off-by: Tom Rini <trini@ti.com>
Suriyan Ramasami [Mon, 17 Nov 2014 22:39:34 +0000 (14:39 -0800)]
sandbox: Use md5sum and fatwrite to enable testing of fs commands
Enable md5sum to obtain the MD5 of the read and written files to check
their contents for validity.
Use map_sysmem() to map buffer in a sandbox environment.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
This fixes following warning when compiled with MIPS64
common/board_f.c: In function 'display_text_info':
common/board_f.c:150:2: warning: format '%X' expects argument i
of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
debug("U-Boot code: %08X -> %08lX BSS: -> %08lX\n",
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Masahiro Yamada [Thu, 13 Nov 2014 10:29:09 +0000 (19:29 +0900)]
spl: fix descending condition to drivers/mtd/nand/
SPL should not reference CONFIG_CMD_NAND to decide whether or not
it should build drivers/mtd/nand. CONFIG_CMD_NAND should be only
used to select the NAND utility command on the command parser.
Masahiro Yamada [Thu, 13 Nov 2014 10:29:07 +0000 (19:29 +0900)]
hush: add CONFIG_HUSH_PARSER to Kconfig
The README file states that the macros beginning with "CONFIG_SYS_"
depend on the hardware etc. and should not be meddled with if you do
not what you're doing.
We have already screwed up with this policy; we have given the prefix
"CONFIG_SYS_" to many user-selectable configurations.
Here, "CONFIG_SYS_HUSH_PARSER" is one of them. Users can enable it
if they want to use a more powerful command line parser, or disable it
if they only need a simple one.
This commit attempts to rename CONFIG_SYS_HUSH_PARSER to
CONFIG_HUSH_PARSER and move it to Kconfig.
Every board maintainer is expected to enable CONFIG_HUSH_PARSER
(= add "CONFIG_HUSH_PARSER=y" to his defconfig file) and remove
"#define CONFIG_SYS_HUSH_PARSER" from his header file.
Since commit 0defddc851ed (config: Add a default CONFIG_SYS_PROMPT),
each board header does not need to define CONFIG_SYS_PROMPT
as long as it uses the default prompt "=> ".
Masahiro Yamada [Thu, 13 Nov 2014 03:28:41 +0000 (12:28 +0900)]
x86: use CONFIG_SYS_COREBOOT to descend into coreboot/ directory
The references of CONFIG_SYS_COREBOOT in arch/x86/cpu/coreboot/Makefile
are redundant because the build system descends into the directory
only when CONFIG_SYS_COREBOOT is defined.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
Masahiro Yamada [Thu, 13 Nov 2014 03:28:40 +0000 (12:28 +0900)]
kbuild: Descend into SOC directory from CPU directory
Some CPUs of some architectures have SOC directories.
At present, the build system directly descends into SOC directories
from the top Makefile, but it should generally descend into each
directory from its parent directory.
Thierry Reding [Thu, 13 Nov 2014 01:26:50 +0000 (18:26 -0700)]
Add pr_fmt() macro
This macro can be overridden in source files (before including common.h)
and can be used to specify a prefix for debug and error messages. An
example of how to use this is shown below:
#define pr_fmt(fmt) "foo: " fmt
#include <common.h>
...
debug("bar");
The resulting message will read:
foo: bar
Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Thierry Reding [Thu, 13 Nov 2014 01:26:49 +0000 (18:26 -0700)]
pci: Honour pci_skip_dev()
When enumerating devices, honour the pci_skip_dev() function. This can
be used by PCI controller drivers to restrict which devices will be
probed.
This is required by the NVIDIA Tegra PCIe controller driver, which will
fail with a data abort exception if an access is attempted to a device
number larger than 0 outside of bus 0. pci_skip_dev() is therefore
implemented to prevent any such accesses.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Thierry Reding [Thu, 13 Nov 2014 01:26:48 +0000 (18:26 -0700)]
pci: Abort early if bus does not exist
When listing the devices on a PCI bus, the current code will blindly try
to access all devices. Internally this causes pci_bus_to_hose() to be
repeatedly called and output an error message every time. Prevent this
by calling pci_bus_to_hose() once and abort early if no bus was found.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Thierry Reding [Thu, 13 Nov 2014 01:26:47 +0000 (18:26 -0700)]
vsprintf: Add modifier for phys_addr_t
Provide a new modifier to vsprintf() to print phys_addr_t variables to
avoid having to cast or #ifdef when printing them out. The %pa modifier
is used for this purpose, so phys_addr_t variables need to be passed by
reference, like so:
phys_addr_t start = 0;
printf("start: %pa\n", &start);
Depending on the size of phys_addr_t this will print out the address
with 8 or 16 hexadecimal digits following a 0x prefix.
Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Some filesystems have a UUID stored in its superblock. To
allow using root=UUID=... for the kernel command line we
need a way to read-out the filesystem UUID.
changes rfc -> v1:
- make the environment variable an option parameter. If not
given, the UUID is printed out. If given, it is stored in the env
variable.
- corrected typos
- return error codes
changes v1 -> v2:
- fix return code of do_fs_uuid(..)
- document do_fs_uuid(..)
- implement fs_uuid_unsuported(..) be more consistent with the
way other optional functionality works
changes v2 -> v3:
- change ext4fs_uuid(..) to make use of #if .. #else .. #endif
construct to get rid of unreachable code
Hit any key to stop autoboot: 0
=> fsuuid
fsuuid - Look up a filesystem UUID
Usage:
fsuuid <interface> <dev>:<part>
- print filesystem UUID
fsuuid <interface> <dev>:<part> <varname>
- set environment variable to filesystem UUID
Stefan Roese [Tue, 11 Nov 2014 18:03:55 +0000 (19:03 +0100)]
spl: Change debug to printf for "Unsupported boot-device"
We had the problem on an AM33xx platform, that SPL detected an
unsupported boot-device. But since this message is a debug message
it took a bit of time to really know, where the hangup in SPL
resulted from. So let's change this debug message to a printf
and also print the detected boot-device that is not supported.
This makes debugging of such cases much easier.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Tom Rini <trini@ti.com> Acked-by: Heiko Schocher <hs@denx.de>
Masahiro Yamada [Thu, 6 Nov 2014 18:03:31 +0000 (03:03 +0900)]
linux/kernel.h: sync min, max, min3, max3 macros with Linux
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Masahiro Yamada [Mon, 17 Nov 2014 08:19:41 +0000 (17:19 +0900)]
dm: core: remove unnecessary return condition in uclass lookup
These conditions never happen.
- There is no real uclass with UCLASS_INVALID id.
- uclass never becomes NULL because ll_entry_start() always returns
a valid pointer.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
Masahiro Yamada [Mon, 17 Nov 2014 08:19:39 +0000 (17:19 +0900)]
dm: core: remove meaningless if conditional
If the variable "ret" is equal to "-ENOENT", it is trapped at [1] and
never reaches [2]. At [3], the condition "ret != -ENOENT" is always
true.
if (ret == -ENOENT) { <------------------ [1]
continue;
} else if (ret == -ENODEV) {
dm_dbg("Device '%s' has no compatible string\n", name);
break;
} else if (ret) { <------------------ [2]
dm_warn("Device tree error at offset %d\n", offset);
if (!result || ret != -ENOENT) <------------------ [3]
result = ret;
break;
}
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 11 Nov 2014 17:46:23 +0000 (10:46 -0700)]
dm: spi: Use device_bind_driver() instead of our own function
The SPI function does the same thing, so we may as well just use the new
generic function. The 'cs' parameter was not actually used, so can be
dropped.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> Acked-by: Heiko Schocher <hs@denx.de>
Simon Glass [Tue, 11 Nov 2014 17:46:20 +0000 (10:46 -0700)]
dm: fdt: Correct handling of aliases with embedded digits
Since we scan from left to right looking for the first digit, "i2c0" returns
2 instead of 0 for the alias number. Adjust the code to scan from right to
left instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@ti.com>
Simon Glass [Tue, 11 Nov 2014 00:16:51 +0000 (17:16 -0700)]
dm: tegra: Add platform data for the GPIO driver
Add platform data for the GPIO driver. It doesn't need to contain anything
since the GPIO driver will actually use information from the CONFIGs for
now. This merely serves to ensure that the GPIO driver is bound.
Simon Glass [Tue, 11 Nov 2014 00:16:48 +0000 (17:16 -0700)]
dm: Allow stdio registration to be dropped
Provide a CONFIG_DM_STDIO option to enable registering a serial device
with the stdio library. This is seldom useful in SPL, so disable it by
default when building for SPL.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
Simon Glass [Tue, 11 Nov 2014 00:16:47 +0000 (17:16 -0700)]
dm: Allow device removal features to be dropped
For SPL we don't expect to need to remove a device. Save some code space
by dropping this feature. The board config can define
CONFIG_DM_DEVICE_REMOVE if this is in fact needed.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
Simon Glass [Tue, 11 Nov 2014 00:16:44 +0000 (17:16 -0700)]
dm: arm: spl: Allow simple malloc() in SPL
For SPL it is sometimes useful to have a simple malloc() just to permit
driver model to work, in the cases where the full malloc() is not made
available by the board config.
Simon Glass [Tue, 11 Nov 2014 00:16:43 +0000 (17:16 -0700)]
dm: Split the simple malloc() implementation into its own file
The simple malloc() implementation is used when memory is tight. It provides
a simple buffer with an incrementing pointer.
At present the implementation is inside dlmalloc. Move it into its own file
so that it is easier to find.
Rather than using relocation as a signal that the full malloc() is
available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the
simple malloc() should no longer be used.
In some cases, such as SPL, even the code space used by the full malloc() is
wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple
malloc. In this case the full malloc is not available at all. It saves about
1KB of code space and about 0.5KB of data on Thumb 2.
Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 29 Oct 2014 19:09:01 +0000 (13:09 -0600)]
dm: at91: Convert snapper9260 to use driver model
Convert this at91sam9260-based board to use driver model. This should serve
as an example for other similar boards. Serial and GPIO are supported so
far.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
Simon Glass [Wed, 29 Oct 2014 19:09:00 +0000 (13:09 -0600)]
dm: at91: Add driver model support for the serial driver
Add driver model support while retaining the existing legacy code. This
allows the driver to support boards that have converted to driver model
as well as those that have not.
Simon Glass [Wed, 29 Oct 2014 19:08:58 +0000 (13:08 -0600)]
dm: at91: Add platform data for GPIO on at91sam9260-based boards
These boards all have the same GPIO arrangement, so add some common platform
data that can be used by all boards. Remove the configs which are no longer
required.
Simon Glass [Thu, 13 Nov 2014 05:42:29 +0000 (22:42 -0700)]
x86: Rename chromebook-x86 to coreboot
Rename this vendor since it is intended to be used on any platform where
coreboot runs at reset and then loads U-Boot.
So far it is only tested on link. When other boards are supported it is
likely that we will need to move to multiple board names, all under the
'coreboot' vendor. So while it would be possible to remove the vendor for
now, that would be short-sighted.
Suggested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 13 Nov 2014 05:42:28 +0000 (22:42 -0700)]
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.
Simon Glass [Thu, 13 Nov 2014 05:42:27 +0000 (22:42 -0700)]
x86: ivybridge: Add LAPIC support
The local advanced programmable interrupt controller is not used much in
U-Boot but we do need to set it up. Add basic support for this, which will
be extended as needed.
Simon Glass [Thu, 13 Nov 2014 05:42:24 +0000 (22:42 -0700)]
x86: ivybridge: Add support for early GPIO init
When not relying on Coreboot for GPIO init the GPIOs must be set up
correctly. This is currently done statically through a rather ugly method.
As the GPIOs are figured out they can be moved to the device tree and set
up as needed rather than all at the start.
In this implementation, board files should call ich_gpio_set_gpio_map()
before the GPIO driver is used in order to provide the GPIO information.
We use the early PCI interface so that this driver can now be used before
relocation.
Simon Glass [Thu, 13 Nov 2014 05:42:18 +0000 (22:42 -0700)]
x86: Add msr read/write functions that use a structure
It is convenient to be able to adjust MSRs with a structure that splits the
two 32-bit halves into separate fields, as they are often dealt with
separately. Add a few functions to support this.
Simon Glass [Thu, 13 Nov 2014 05:42:16 +0000 (22:42 -0700)]
x86: Tidy up coreboot header usage
There is no need to explicitly write 'arch-coreboot' when including headers,
as when the arch directory points to coreboot the correct files will be
used.
Simon Glass [Thu, 13 Nov 2014 05:42:15 +0000 (22:42 -0700)]
x86: ivybridge: Add early LPC init so that serial works
The PCH (Platform Controller Hub) includes an LPC (Low Pin Count) device
which provides a serial port. This is accessible on Chromebooks, so enable
it early in the boot process.
Simon Glass [Thu, 13 Nov 2014 05:42:14 +0000 (22:42 -0700)]
x86: pci: Allow configuration before relocation
Add simple PCI access routines for x86 which permit use before relocation.
The normal PCI stack is still used, but for pre-relocation use there can
only ever be a single hose. After relocation, fall back to the normal
access, although even then on x86 machines there is normally only a single
PCI bus.
Simon Glass [Thu, 13 Nov 2014 05:42:11 +0000 (22:42 -0700)]
x86: Refactor PCI to permit alternate init
We want access PCI earlier in the init sequence, so refactor the code so
that it does not require use of a BSS variable to work. This will allow us
to use early malloc() to store information about a PCI hose.
Common PCI code moves to arch/x86/cpu/pci.c and a new
board_pci_setup_hose() function is provided by boards to set up the (single)
hose used by that board.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 13 Nov 2014 05:42:10 +0000 (22:42 -0700)]
x86: chromebook_link: Implement CAR support (cache as RAM)
Add support for CAR so that we have memory to use prior to DRAM init.
On link there is a total of 128KB of CAR available, although some is
used for the memory reference code.
Simon Glass [Thu, 13 Nov 2014 05:42:09 +0000 (22:42 -0700)]
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>
Simon Glass [Thu, 13 Nov 2014 05:42:08 +0000 (22:42 -0700)]
x86: Build a .rom file which can be flashed to an x86 machine
On x86 machines U-Boot needs to be added to a large ROM image which is
then flashed onto the target board. The ROM has a particular format so it
makes sense for U-Boot to build this image automatically. Unfortunately
it relies on binary blobs so we cannot require this for the default
build as yet.
Simon Glass [Thu, 13 Nov 2014 05:42:07 +0000 (22:42 -0700)]
x86: Add chromebook_link board
This board is a 'bare' version of the existing 'link 'board. It does not
require coreboot to run, but is intended to start directly from the reset
vector.
This initial commit has place holders for a wide range of features. These
will be added in follow-on patches and series. So far it cannot be booted
as there is no ROM image produced, but it does build without errors.
Masahiro Yamada [Thu, 13 Nov 2014 03:28:41 +0000 (12:28 +0900)]
x86: use CONFIG_SYS_COREBOOT to descend into coreboot/ directory
The references of CONFIG_SYS_COREBOOT in arch/x86/cpu/coreboot/Makefile
are redundant because the build system descends into the directory
only when CONFIG_SYS_COREBOOT is defined.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 11 Nov 2014 01:00:22 +0000 (18:00 -0700)]
x86: Add ifdtool for working with Intel Flash Descriptor ROM images
Newer Intel chips require a Management Engine which requires a particular
format for the SPI flash that contains the boot loader. Add a tool that
supports creating and modifying these ROM images.
This tool is from Chrome OS but has been cleaned up to use U-Boot style
and to add comments. A few features have been added also.
Simon Glass [Tue, 11 Nov 2014 01:00:21 +0000 (18:00 -0700)]
dm: gpio: Add a function to read an ID from a list of GPIOs
For board IDs a common approach is to set aside several GPIOs for use in
determining the board ID. This can provide information about board features
and the revision.
Add a function that turns a list of GPIOs into an integer by assigning
each GPIO to a single bit.
Simon Glass [Tue, 11 Nov 2014 01:00:20 +0000 (18:00 -0700)]
dm: serial: Move current serial port pointer to global_data
In general we can't store things in the data section until we have inited
SDRAM. Some platforms allow this (e.g. those with SPL) but some don't. Move
the pointer to global_data so that it will work on all platforms.
Without this fix the serial port will not work prior to relocation with
driver model on some platforms.
Simon Glass [Tue, 11 Nov 2014 01:00:18 +0000 (18:00 -0700)]
Move early malloc() to before arch_cpu_init()
For some CPUs, having malloc() available very early is useful. There is no
reason to delay this since early malloc is allocated before board_init_f()
is called.
Move early malloc() init nearer to the start of the init sequence.
projects / u-boot.git / log