extable.c:66:9: warning: symbol 'ex_tab_message' was not declared. Should it be static?

making it static can produce a new build warning on some boards:

extable.c:66:12: warning: 'ex_tab_message' defined but not used [-Wunused-variable]

but ex_tab_message doesn't do much even when used, so just remove it.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>

a fixup __iomem definition in arch code appears to be placed there as a cover
up from a code import from linux when u-boot didn't yet have a compiler.h,
introduced by commit 812711ce "Implement
__raw_{read,write}[bwl] on all architectures".

git show 812711ce:include/linux/compiler.h
fatal: Path 'include/linux/compiler.h' exists on disk, but not in '812711ce'.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>

hack to avoid:

/opt/gcc-4.6.3-nolibc/powerpc-linux/bin/../lib/gcc/powerpc-linux/4.6.3/include/stddef.h:413:9: warning: preprocessor token offsetof redefined
u-boot/include/linux/stddef.h:20:9: this was the original definition

tried protecting with __KERNEL__, and #including compiler.h first.

Even tried include dir reordering to no avail:

 +++ b/config.mk
 @@ -194,7 +194,11 @@ OBJCFLAGS += --gap-fill=0xff
 gccincdir := $(shell $(CC) -print-file-name=include)

 CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS)                \
 -       -D__KERNEL__
 +       -D__KERNEL__  \
 +       -I $(gccincdir) \
 +       -nostdinc
 +
 +#      -isystem $(gccincdir) \

 # Enable garbage collection of un-used sections for SPL
 ifeq ($(CONFIG_SPL_BUILD),y)
 @@ -227,8 +231,7 @@ CPPFLAGS += -I$(OBJTREE)/include2 -I$(OBJTREE)/include
 endif

 CPPFLAGS += -I$(TOPDIR)/include
 -CPPFLAGS += -fno-builtin -ffreestanding -nostdinc      \
 -       -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS)
 +CPPFLAGS += -fno-builtin -ffreestanding -pipe $(PLATFORM_CPPFLAGS)
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>

include/linux/unaligned/generic.h:5:9: warning: preprocessor token __force redefined
include/linux/compiler.h:10:10: this was the original definition

fixup __force definitions in compat.h code appears to be placed
there as a cover up from a code import from linux when u-boot didn't yet
have a compiler.h, introduced by commit
b1b4e89a "Add LZO decompressor support".
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>

include/linux/compat.h:4:9: warning: preprocessor token __user redefined
include/linux/compiler.h:7:10: this was the original definition
include/linux/compat.h:5:9: warning: preprocessor token __iomem redefined
include/linux/compiler.h:12:10: this was the original definition

fixup __iomem, __user definitions in compat.h code appears to be placed
there as a cover up from a code import from linux when u-boot didn't yet
have a compiler.h, introduced by commit
932394ac "Rewrite of NAND code based on
what is in 2.6.12 Linux kernel".
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>

u-boot's byteorder headers did not contain endianness attributions
for use with sparse, causing a lot of false positives.  Import the
kernel's latest definitions, and enable them by including compiler.h
and types.h.  They come with 'const' added for some swab functions, so
fix those up, too:

include/linux/byteorder/big_endian.h:46:2: warning: passing argument 1 of '__swab64p' discards 'const' qualifier from pointer target type [enabled by default]

Also, note: u-boot's historic __BYTE_ORDER definition has been
preserved (for the time being at least).

We also remove ad-hoc barrier() definitions, since we're including
compiler.h in files that hadn't in the past:

macb.c:54:0: warning: "barrier" redefined [enabled by default]

In addition, including compiler.h in byteorder changes the 'noinline'
definition to expand to __attribute__((noinline)).  This fixes
arch/powerpc/lib/bootm.c:

bootm.c:329:16: error: attribute '__attribute__': unknown attribute
bootm.c:329:16: error: expected ')' before '__attribute__'
bootm.c:329:25: error: expected identifier or '(' before ')' token

powerpc sparse builds yield:

include/common.h:356:22: error: marked inline, but without a definition

the unknown-reason inlining without a definition is considered obsolete
given it was part of the 2002 initial commit, and no arm version was
'fixed.'

also fixed:
ydirectenv.h:60:0: warning: "inline" redefined [enabled by default]

and:

Configuring for devconcenter - Board: intip, Options: DEVCONCENTER
make[1]: *** [4xx_ibm_ddr2_autocalib.o] Error 1
make: *** [arch/powerpc/cpu/ppc4xx/libppc4xx.o] Error 2
powerpc-fsl-linux-size: './u-boot': No such file
4xx_ibm_ddr2_autocalib.c: In function 'DQS_autocalibration':
include/asm/ppc4xx-sdram.h:1407:13: sorry, unimplemented: inlining failed in call to 'ppc4xx_ibm_ddr2_register_dump': function body not available
4xx_ibm_ddr2_autocalib.c:1243:32: sorry, unimplemented: called from here

and:

In file included from crc32.c:50:0:
crc32table.h:4:1: warning: implicit declaration of function '___constant_swab32' [-Wimplicit-function-declaration]
crc32table.h:4:1: error: initializer element is not constant
crc32table.h:4:1: error: (near initialization for 'crc32table_le[0]')
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
[trini: Remove '#endif' in include/common.h around setenv portion]
Signed-off-by: NTom Rini <trini@ti.com>

When the generic filesystem load command "fsload" was written, I felt
that "load" was too generic of a name for it, since many other similar
commands already existed. However, it turns out that there is already
an "fsload" command, so that name cannot be used. Rename the new
"fsload" to plain "load" to avoid the conflict. At least anyone who's
used a Basic interpreter should feel familiar with the name!
Signed-off-by: NStephen Warren <swarren@nvidia.com>

Commit 045fa1e1 "fs: add filesystem switch libary, implement ls and
fsload commands" unified the implementation of fatload and ext*load
with the new command fsload. However, this altered the interpretation
of command-line numbers from always being base-16, to requiring a "0x"
prefix for base-16 numbers. Enhance do_fsload() to allow commands to
specify which base to use.

Use base 0, thus requiring a "0x" prefix for the new fsload command.
This feels much cleaner than assuming base 16.

Use base 16 for the pre-existing fatload and ext*load to prevent a
change in behaviour.

Use base 16 exclusively for the loadaddr environment variable, since
that variable is interpreted in multiple places, so we don't want the
behaviour to change.

Update command help text to make it clear where numbers are assumed to
be hex, and where an explicit "0x" prefix is required.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

TABs in the help text won't line up in the same place on the console as
in a source editor. Replace them with spaces to make ensuring correct
alignment easier.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

Most arguments to the shell command do_fsload() implements are optional.
Fix the minimum argc check to respect that. Cater for the situation
where argv[2] is not provided.

Enhance both do_fsload() and do_ls() to check the maximum number of
arguments too. While this check would typically be implemented via
U_BOOT_CMD()'s max_args parameter, if these functions are called
directly, then that check won't exist.

Finally, alter do_ls() to check (argc >= 4) rather than (argc == 4) so
that if the function is enhanced to allow extra arguments in the future,
this test won't need to be changed at that time.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

Enable AHCI driver for Intel SATA devices.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The prototypes in the header were changed by commit 4ac8f8e0 but the
functions no longer match. Correct this.

It seems odd that block devices take an lbaint_t for the block count, but
an unsigned long for the blknr. Surely we should promote blknr to lbaint_t
also?
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@ti.com>

Currently, this driver uses a 28bit interface to AHCI, this
limits the number of blocks addressable to 2^28, or the max
disk size to 512(2^28) or about 137GB. This change allows
supporting drives up to about 2TB.

Testing this is a bit difficult. There is test code that
can be inserted into U-Boot that will write test patterns
into certain unused blocks. These patterns can be manually
checked using 'dd' after boot. Another way is to confirm the
original error that exposed this bug is fixed. IOW: see if
AU (Auto Update) will now work on the drive. Also, check
that there are no warning messages from the 'cgpt' utility.
Signed-off-by: NWalter Murphy <wmurphy@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Writes in u-boot are so rare, and the logic to know when is
the last write and do a flush only there is sufficiently
difficult. Just do a flush after every write. This incurs,
usually, one extra flush when the rare writes do happen.
Signed-off-by: NMarc Jones <marc.jones@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add HDD handling to the SSD-only AHCI driver, by separately dealing with
spin-up and link-up.
Signed-off-by: NMarc Jones <marc.jones@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Note: These are timeout values and not delay values, so the event being
timed out will complete whenever it is actually ready, with a
measurement granularity of 1 millisecond, up till the timeout value.
Therefore, there is no effect on SSD booting.

The values were determined by instrumenting the code and measuring the
actual time taken by several different models of HDD for each of the
parameters and then adding 50% more for the spinup value and just
doubling the command timeout value.
Signed-off-by: NWalter Murphy <wmurphy@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Exynos5 automatically performs DMA when the SATA controller executes
commands.  This adds the necessary dcache-to-memory flush &
invalidation calls to allow the DMA to properly function.
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update the assignment of various physical memory buffers used by the
SATA controller to explicitly be denoted as physical addresses.

The memory is identity-mapped, so these function calls are a nop, but
they provide good semantic documentation for any maintainers.

The return value of virt_to_phys() is 'unsigned long'.  On machines
where sizeof(unsigned long) != sizeof(pointer), a cast through
(uintptr_t) is needed to appease the compiler due to the potential of
losing the upper 32 bits of the address.

In compilation this scenario, a physical address could be 64-bits, yet
the C pointer environment only allows 32-bit addresses; the constraint
is that pointers cannot address more than 4Gb of memory and if
virt_to_phys() ever returns an out-of-range value for the physical
address, there are issues with emmory mapping which must be solved.
However, since the memory is identify mappeed, there is no problem
introducing the cast: the original pointer will reside in 32-bits, so
the physical address will also be within in 32-bits.
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Capacity needs to allow for a 64-bit value.
Signed-off-by: NGabe Black <gabeblack@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This fixes a spelling error in a message which can be output to the
console.
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This cleanup replaces the hardcoded use of '20', which represents the
number of bytes in the FIS, with sizeof(fis).
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

In the structure returned by the ATA identify device command, there are two
fields which describe the device capacity. One is a 32 bit data type which
reports the number of sectors as a 28 bit LBA, and the other is a 64 bit data
type which is for a 48 bit LBA. If the device doesn't support 48 bit LBAs,
the small value is the only value with the correct size. If it supports more,
if the number of sectors is small enough to fit into 28 bits, both fields
reflect the correct value. If it's too large, the smaller field has 28 bits of
1s, 0xfffffff, and the other field has the correct value.

The AHCI driver is implemented by attaching to the generic SCSI code and
translating on the fly between SCSI binary data structures and AHCI data
structures. It responds to requests to execute specific SCSI commands by
executing the equivalent AHCI commands and then crafting a response which
matches what a SCSI disk would send.

The AHCI driver now considers both fields and chooses the correct one when
implementing both the SCSI READ CAPACITY (10) and READ CAPACITY (16) commands.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The "scsi write" command requires support from underlying driver.
This CL enables SCSI_WRITE10 in AHCI driver.

Tested in U-Boot console, try to i/o with sector #64:
scsi read 1000 40 1
md.b 1000 200 # check if things are not 0xcc
mw.b 1000 cc 200 # try to fill with 0xcc
scsi write 1000 40 1
mw.b 1000 0 200 # fill with zero
md.b 1000 200 # should be all 0
scsi read 1000 40 1
md.b 1000 200 # should be all 0xcc
Signed-off-by: NHung-Te Lin <hungte@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This command doesn't really do anything when talking to a SATA device, and
sending it confuses some of them. This change makes sending the command
optional, and defaults to not. The situations where it should be sent are not
the common case.

With the standard SSD in the machine, here are some times with the option
turned off:
1. 8277
2. 8273
3. 8050

And turned on:
1. 8303
2. 8155
3. 8276

Sending that command seems to have no meaningful effect on performance.

This fixes problems with an SSD marked Toshiba NV6424, Taiwan 11159AE P
and TC58NVG5D2FTA10.
Signed-off-by: NGabe Black <gabeblack@chromium.org>
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

- print the correct speed
- print all the AHCI capability flags
(information taken from Linux kernel driver)
- clean up some comments

For example, this might show the following string:
AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3 impl SATA mode
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>

Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NStefan Reinauer <reinauer@chromium.org>

- remove unused ssleep macro
- add some useful debugging information
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The existing code waits a whole second for the AHCI controller to reset.
Instead, let's poll the status register to see if the reset has
succeeded and return earlier if possible. This brings down the time for
AHCI probing from 1s to 20ms.
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a new function to find out the number of available SCSI disks. Also
set the 'scsidevs' environment variable after each scan.
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This includes were outside an #ifdef CONFIG_PPC, but there is not reason
to exclude powerpc from using them.

Move the declaration outside the #ifdef.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Implement write functionality in the scsi layer. A ''scsi write'
command is also added to console for testing.
Signed-off-by: NHung-Te Lin <hungte@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Many AHCI controllers are identical, the main (and often the
only) difference being the PCI Vendor ID/Device ID combination
reported by the device.

This change allows the config file to define a list of PCI vendor
ID/device ID pairs. The driver would scan the list and initialize
the first device it finds.

No actual multiple device list is introduced yet, this change
just add the framework.
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

With an Intel AHCI controller, the driver does not operate properly
if the requested amount of blocks to read exceeds 255.

It is probably possible to specify 0 as the block count and the driver
will read 256 blocks, but it was decided to limit the number of blocks
read at once to 128 (it should be a power of 2 for the optimal
performance of solid state drives).
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This patch fixes the following compile warning:
zfs.c:2006:1: warning: 'zfs_label' defined but not used [-Wunused-function]
zfs.c:2029:1: warning: 'zfs_uuid' defined but not used [-Wunused-function]
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Jorgen Lundman <lundman@lundman.net>

This patch fixes the following compile warnings:

cmd_zfs.c:177:1: warning: initialization from incompatible pointer type [enabled by default]
cmd_zfs.c:177:1: warning: (near initialization for '_u_boot_list_cmd_zfsls.cmd') [enabled by default]
cmd_zfs.c:182:1: warning: initialization from incompatible pointer type [enabled by default]
cmd_zfs.c:182:1: warning: (near initialization for '_u_boot_list_cmd_zfsload.cmd') [enabled by default]
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Jorgen Lundman <lundman@lundman.net>

We add CONFIG_ENV_VARS_UBOOT_CONFIG,
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG and CONFIG_BOARD_LATE_INIT to set
the variables and then fdtfile and findfdt to make us of this.  It is
now possible to do 'run findfdt' to have fdtfile be set to the value of
the dtb file to load for the board we are running on.
Signed-off-by: NTom Rini <trini@ti.com>

CONFIG_ENV_VARS_UBOOT_CONFIG creates environment variables indicating
which configuration U-Boot was built for. Some U-Boot binaries run on
multiple boards, and hence this information may not uniquley describe
the HW that U-Boot is actually running on. Another patch introduces
environment variable board_name to represent that. In order to avoid
scripts having to check $board_name, use it if set, and then fall back
to using $board, make CONFIG_ENV_VARS_UBOOT_CONFIG also set a default
value for board_name, so that variable is always available.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

This option is intended to be set by boards which will set the
board_name and board_rev environment variables.  These are to be used
when the U-Boot binary can support more than one board type at run-time
and the user needs an easy way (for example for scripting to determine
what device tree to load) to determine what board they are on.
Signed-off-by: NTom Rini <trini@ti.com>

Grame is still listed since he has agreed to continue with some review.
Also add an alias to shorten things.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The %p format of printf() would print a pointer to address null as
"(null)".  This makes sense in a real OS where a NULL pointer must
never be dereferenced, but this is a bootloader, and there are cases
where accessing the data at address null makes perfect sense.

Remove the special case in lib/vsprintf.c using "#if 0" with a comment
to make clear this was an intentional change and to stop re-adding
this code.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

When putting pointers into a format string use %p to ensure that they
are printed correctly regardless of bitsize.  This fixes warnings on
sandbox on 64bit systems.

Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Gerald Van Baren <vanbaren@cideas.com>
Signed-off-by: NTom Rini <trini@ti.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>