Adjust the Makefile to build u-boot-tegra.bin which contains a device tree
if OF_SEPARATE is enabled, and does not if not. This mirrors U-Boot's new
approach of using u-boot.bin to handle both cases.
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present u-boot-spl.bin holds the plain SPL binary without the device
tree. This is somewhat annoying since you need either u-boot-spl.bin or
u-boot-spl-dtb.bin depending on whether device tree is used.

Adjust the build such that u-boot-spl.bin includes a device tree
(if enabled), and the plain binary is in u-boot-spl-nodtb.bin. For now
u-boot-spl-dtb.bin remains the same.
Tested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present u-boot.bin holds the plain U-Boot binary without the device tree.
This is somewhat annoying since you need either u-boot.bin or u-boot-dtb.bin
depending on whether device tree is used.

Adjust the build such that u-boot.bin includes a device tree (if enabled),
and the plain binary is in u-boot-nodtb.bin. For now u-boot-dtb.bin remains
the same.

This should be acceptable since:

- without OF_CONTROL, u-boot.bin still does not include a device tree
- with OF_CONTROL, u-boot-dtb.bin does not change

The main impact is build systems which are set up to use u-boot.bin as
the output file and then add a device tree. These will have to change to use
u-boot-nodtb.bin instead.

Adjust tegra rules so it continues to produce the correct files.
Tested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Fix the ALL-y logic in the Makefile so that is clear that we always want
the -nodtb file.
Tested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Commit df48b234 (".mailmap: Add all the mail alias for Ricardo
Ribalda") assigned two different proper names for the email address
"ricardo.ribalda@uam.es".  This is a completely wrong usage as the
mailmap feature exists for coalescing together commits by the same
person whose name is sometimes spelled differently.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This is a follow-up patch to e92029c0 and adds a prototype for
the weak mmc_get_env_dev function.

Cc: Tom Rini <trini@konsulko.com>
Cc: Stephen Warren <swarren@nvidia.com>
Signed-off-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NPeng Fan <peng.fan@nxp.com>

Use of memalign can trigger fragmentation issues such as:

// Internally, this needs to find a free block quite bit larger than s.
// Once the free region is found, any unaligned "padding" immediately
// before and after the block is marked free, so that the allocation
// takes only s bytes (plus malloc header overhead).
p = memalign(a, s);
// If there's little fragmentation so far, this allocation is likely
// located immediately after p.
p2 = malloc(x);
free(p);
// In theory, this should return the same value for p. However, the hole
// left by the free() call is only s in size (plus malloc header overhead)
// whereas memalign searches for a larger block in order to guarantee it
// can adjust the returned pointer to the alignment requirements. Hence,
// the pointer returned, if any, won't be p. If there's little or no space
// left after p2, this allocation will fail.
p = memalign(a, s);

In practice, this issue occurs when running the "dfu" command repeatedly
on NVIDIA Tegra boards, since DFU allocates a large 32M data buffer, and
then initializes the USB controller. If this is the first time USB has
been used in the U-Boot session, this causes a probe of the USB driver,
which causes various allocations, including a strdup() of a GPIO name
when requesting the VBUS GPIO. When DFU is torn down, the USB driver
is left probed, and hence its memory is left allocated. If "dfu" is
executed again, allocation of the 32M data buffer fails as described
above.

In practice, there is a memory hole exactly large enough to hold the 32M
data buffer than DFU needs. However, memalign() can't know that in a
general way. Given that, it's particularly annoying that the allocation
fails!

The issue is that memalign() tries to allocate something larger to
guarantee the ability to align the returned pointer. This patch modifies
memalign() so that if the "general case" over-sized allocation fails,
another allocation is attempted, of the exact size the user desired. If
that allocation just happens to be aligned in the way the user wants,
(and in the case described above, it will be, since the free memory
region is located where a previous identical allocation was located),
the pointer can be returned.

This patch is somewhat related to 806bd245 "dfu: don't keep
freeing/reallocating". That patch worked around the issue by removing
repeated free/memalign within a single execution of "dfu". However,
the same technique can't be applied across multiple invocations, since
there's no reason to keep the DFU buffer allocated while DFU isn't
running. This patch addresses the root-cause a bit more directly.

This problem highlights some of the disadvantages of dynamic allocation
and deferred probing of devices.

This patch isn't checkpatch-clean, since it conforms to the existing
coding style in dlmalloc.c, which is different to the rest of U-Boot.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLukasz Majewski <l.majewski@samsung.com>

- install using addons.apt
- remove MAKEALL
- split mpc85xx boards
- remove TEST_CONFIG_CMD, just info
- fetch mips toolchain via buildman
- remove --list-error-boards param
- conditional script
- use TOOLCHAIN instead of INSTALL_TOOLCHAIN
- add aarch64
- enable notifications via email
Signed-off-by: NRoger Meier <r.meier@siemens.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Andreas Färber <afaerber@suse.de>
Tested-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: NHeiko Schocher <hs@denx.de>

This adds ethernet, TFTP support for PIC32MZ[DA] Starter Kit. Also
custom environment variables/scripts are added to help boot from network.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>

This driver implements MAC and MII layer of the ethernet controller.
Network data transfer is handled by controller internal DMA engine.
Ethernet controller is configurable through device-tree file.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>

Add SMSC LAN8740 Phy support required for PIC32MZDA devices.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Enable MMC, SDHCI, FAT_FS support for PIC32MZ[DA] StarterKit.
Also add custom scripts, rules to boot Linux from microSD card.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>

This driver implements platform specific glue and fixups for
PIC32 internal SDHCI controller.
Signed-off-by: NAndrei Pistirica <andrei.pistirica@microchip.com>
Signed-off-by: NSandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com>
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

This adds support for Microchip PIC32MZ[DA] StarterKit board
based on a PIC32MZ[DA] family of microcontroller.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Add Microchip PIC32MZ[DA] SoC family support.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

This driver initializes PIC32 DDR2 SDRAM controller and internal DDR2 Phy module.
DDR2 controller operates in half-rate mode (upto 533MHZ frequency).
Signed-off-by: NPaul Thacker <paul.thacker@microchip.com>
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This adds PIC32 UART controller support based on driver model.
Signed-off-by: NPaul Thacker <paul.thacker@microchip.com>
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

In PIC32 GPIO controller is part of PIC32 pin controller.
PIC32 has ten independently programmable ports and each with multiple pins.
Each of these pins can be configured and used as GPIO, provided they
are not in use for other peripherals.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

In PIC32 pin-controller is a combined gpio-controller, pin-mux and
pin-config module. Remappable peripherals are assigned pins through
per-pin based muxing logic. And pin configuration are performed on
specific port registers which are shared along with gpio controller.
Note, non-remappable peripherals have default pins assigned thus
require no muxing.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

PIC32 clock module consists of multiple oscillators, PLLs, mutiplexers
and dividers capable of supplying clock to various controllers
on or off-chip.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Create initial directory, Kconfigs needed for PIC32 architecture
support. Also add PIC32 specific register definition required for drivers.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Rather than passing the I/O port base address to the Super I/O code,
switch it to using outb such that it makes use of the I/O port base
address automatically.

Drop the extern keyword to satisfy checkpatch whilst here.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>

Set the I/O port base earlier, from board_early_init_f, in preparation
for it being used by the serial driver.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>

The existing mips_io_port_base variable isn't suitable for use early
during boot since it will be stored in the .data section which may not
be writable pre-relocation. Fix this by moving the I/O port base address
into struct arch_global_data. In order to avoid adding this field for
all targets, make this dependant upon a new Kconfig entry
CONFIG_DYNAMIC_IO_PORT_BASE. Malta is the only board which sets a
non-zero I/O port base, so select this option only for Malta.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>

CONF_SLOWDOWN_IO is never set for any target, so remove the dead code in
the SLOW_DOWN_IO macro. This is done in preparation for changes to
mips_io_port_base which can be avoided in this path by removing it
entirely.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>

This patch makes sure that the flush/invalidate_dcache_range() functions
can handle corner-case calls like this -- invalidate_dcache_range(0, 0, 0);
This call is valid and is happily produced by USB EHCI code for example.
The expected behavior of the cache function(s) in this case is that they
will do no operation, since the size is zero.

The current implementation though has a problem where such invocation will
result in a hard CPU hang. This is because under such conditions, where the
start_addr = 0 and stop = 0, the addr = 0 and aend = 0xffffffe0 . The loop
will then try to iterate over the entire address space, which in itself is
wrong. But iterating over the entire address space might also hit some odd
address which will cause bus hang. The later happens on the Atheros MIPS.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>

Fix 32 vs 64 bit load/store instructions. Access CP0_WATCHHI as
32 Bit register. Use 64 Bit register access for clearing gd_data
and copying U-Boot.
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Argument boot_flags of board_init_f() should be set to 0 as
$a0 may be utilized in lowlevel_init() or mips_cache_reset()
or previous stage boot-loader.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

On Novena, the DRAM SPD is connected to i2c1 while the Utility EEPROM
is connected to i2c3. Now that the EEPROM handling in U-Boot is fixed,
also fix this bit on Novena.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Sean Cross <xobs@kosagi.com>
Cc: Stefano Babic <sbabic@denx.de>

Android's tool chain enable the -mandroid at default.
This option will enable the -fpic, which cause uboot compilation
failure:
"
 LD      u-boot
 u-boot contains unexpected relocations: R_ARM_ABS32
 R_ARM_RELATIVE
"

In my testcase, arm-linux-androideabi-gcc-4.9 internally
enables '-fpic', so when compiling code, there will be
relocation entries using type R_ARM_GOT_BREL and .got
section. When linking all the built-in.o using ld, there
will be R_ARM_ABS32 relocation entry and .got section
in the final u-boot elf image. This can not be handled
by u-boot, since u-boot only expects R_ARM_RELATIVE
relocation entry.
arm-poky-linux-gnueabi-gcc-4.9 default does not enable '-fpic',
so there is not .got section and R_ARM_GOT_BREL in built-in.o.
And in the final u-boot elf image, all relocation entries are
R_ARM_RELATIVE.

we can pass '-fno-pic' to xxx-gcc to disable pic. whether
the toolchain internally enables or disables pic, '-fno-pic'
can work well.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Reviewed-by: NTom Rini <trini@konsulko.com>

"DISCARD" will remove ._secure.text relocate, but PSCI framework
has already used some absolute address those need to relocate.

Use readelf -t -r u-boot show us:
.__secure_start		addr: 601408e4
.__secure_end		addr: 60141460

60141140  00000017 R_ARM_RELATIVE
46	_secure_monitor:
47	#ifdef CONFIG_ARMV7_PSCI
48      ldr     r5, =_psci_vectors

60141194  00000017 R_ARM_RELATIVE
6014119c  00000017 R_ARM_RELATIVE
601411a4  00000017 R_ARM_RELATIVE
601411ac  00000017 R_ARM_RELATIVE
64	_psci_table:
66	.word	psci_cpu_suspend
...
72	.word	psci_migrate

60141344  00000017 R_ARM_RELATIVE
6014145c  00000017 R_ARM_RELATIVE
202	ldr     r5, =psci_text_end

Solutions:
1. Change absolute address to RelAdr.
   Based on LDR (immediate, ARM), we only have 4K offset to jump.
Now PSCI code size is close to 4K size that is LDR limit jump size,
so even if the LDR is based on the current instruction address,
there is also have a risk for RelAdr. If we use two jump steps I
think we can fix this issue, but looks too hack, so give up this way.

2. Enable "DISCARD" only for CONFIG_ARMV7_SECURE_BASE has defined.
   If CONFIG_ARMV7_SECURE_BASE is defined in platform, all of secure
will in the BASE address that is absolute.
Signed-off-by: NWang Dongsheng <dongsheng.wang@nxp.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add code to aid tracking down cache alignment issues.
In case DEBUG is defined in the cache.c, this code will
check alignment of each attempt to flush/invalidate data
cache and print a warning if the alignment is incorrect.
If DEBUG is not defined, this code is optimized out.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>

Some armv7 targets are missing a cache line size declaration.
In preparation for "arm: cache: Implement cache range check for v7"
patch, add these declarations with the appropriate value for
the target's SoC or CPU.
Signed-off-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: NTom Rini <trini@konsulko.com>

Restore the old behavior of the MMU section entries configuration,
which is without the S-bit.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Simon Glass <sjg@chromium.org>

The arch/arm/lib/cache-cp15.c checks for CONFIG_ARMV7 and if this macro is
set, it configures TTBR0 register. This register must be configured for the
cache on ARMv7 to operate correctly.

The problem is that noone actually sets the CONFIG_ARMV7 macro and thus the
TTBR0 is not configured at all. On SoCFPGA, this produces all sorts of minor
issues which are hard to replicate, for example certain USB sticks are not
detected or QSPI NOR sometimes fails to write pages completely.

The solution is to replace CONFIG_ARMV7 test with CONFIG_CPU_V7 one. This is
correct because the code which added the test(s) for CONFIG_ARMV7 was added
shortly after CONFIG_ARMV7 was replaced by CONFIG_CPU_V7 and this code was
not adjusted correctly to reflect that change.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Simon Glass <sjg@chromium.org>

This should be 'rot', not 'tor'.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This adds tests for the different character types, line wrap, scrolling and
backspace.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Enable this feature so that truetype fonts can be used on the sandbox
console. Update the tests to select the normal/rotated console when needed.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NAnatolij Gustschin <agust@denx.de>

For testing it is useful to be able to select the font size and the console
driver for sandbox. Add this information to platform data and copy it to
the video device when needed.
Signed-off-by: NSimon Glass <sjg@chromium.org>