u-boot.git/include, branch v2016.01 Unnamed repository; edit this file 'description' to name the repository. Merge git://git.denx.de/u-boot-rockchip 2016-01-08T19:19:24+00:00 Tom Rini trini@konsulko.com 2016-01-08T19:19:24+00:00 d77a092dd3619ca747fb8290ae8f255e9799aaa6 






Merge branch 'master' of git://www.denx.de/git/u-boot-imx
2016-01-08T15:18:18+00:00

Tom Rini
trini@konsulko.com

2016-01-08T15:18:18+00:00

b685c7348c521b14591a49ec6b78a2ad28a176e0












cyrus: Enable STDIO deregister
2016-01-08T15:15:47+00:00

Andy Fleming
afleming@gmail.com

2016-01-06T21:34:50+00:00

9d243b1481e0053aefbd53eedaee72eb8fdffd5a

If CONFIG_SYS_STDIO_DEREGISTER is not enabled, usb reset
will fail every time. Enabling it allows usb reset to
work.

Signed-off-by: Andy Fleming <afleming@gmail.com>





If CONFIG_SYS_STDIO_DEREGISTER is not enabled, usb reset
will fail every time. Enabling it allows usb reset to
work.

Signed-off-by: Andy Fleming <afleming@gmail.com>







arm64: Juno/FVP: adjust kernel load address
2016-01-08T15:15:44+00:00

Andre Przywara
andre.przywara@arm.com

2016-01-04T15:43:36+00:00

7babe48252bb92d3c9e7a9dfebde723c9da30c78

The default kernel load offset for an arm64 kernel is 0x80000, so
U-Boot takes cares of moving the loaded kernel to a matching memory
location just before booting it.
Since we run with caches off, this takes a while for any decently
sized kernel - with no output explaining the reason for the delay
(unless one uses a DEBUG build).
By adjusting the default load offset for Juno and VFP to be 512K
aligned in the first place we can skip this copying and boot much
faster.
Tested on Juno.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>





The default kernel load offset for an arm64 kernel is 0x80000, so
U-Boot takes cares of moving the loaded kernel to a matching memory
location just before booting it.
Since we run with caches off, this takes a while for any decently
sized kernel - with no output explaining the reason for the delay
(unless one uses a DEBUG build).
By adjusting the default load offset for Juno and VFP to be 512K
aligned in the first place we can skip this copying and boot much
faster.
Tested on Juno.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>







include: Correct "requset" typoes in misc.h
2016-01-08T15:15:42+00:00

Robert P. J. Day
rpjday@crashcourse.ca

2015-12-14T11:28:51+00:00

f5abb40997eb68ef11102b726d8be747b3dd126e

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Acked-by: Thomas Chou <thomas@wytron.com.tw>





Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Acked-by: Thomas Chou <thomas@wytron.com.tw>







rockchip: Fix the configuration for chromebook_jerry
2016-01-08T14:59:07+00:00

Simon Glass
sjg@chromium.org

2015-12-29T12:22:45+00:00

dd8e42900b8a087fb3b97898fb5a42ef2a0597df

Various updates did not make it through to this board. Also the instructions
for building a SPI image are no-longer correct. Fix these so that Jerry can
boot to a prompt again.

Signed-off-by: Simon Glass <sjg@chromium.org>





Various updates did not make it through to this board. Also the instructions
for building a SPI image are no-longer correct. Fix these so that Jerry can
boot to a prompt again.

Signed-off-by: Simon Glass <sjg@chromium.org>







usb: Allow up to 7 storage devices
2016-01-07T17:27:07+00:00

Simon Glass
sjg@chromium.org

2016-01-03T20:50:30+00:00

70caa97108d790e5779b347a8530b130df9f000a

The current limit of 5 is not enough for the driver model USB tests. Really
we should not have a limit but the driver model code still uses the
usb_dev_desc[] array, which has a limit.

Increasing the limit by 2 should not bother anyone. Adjust it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>





The current limit of 5 is not enough for the driver model USB tests. Really
we should not have a limit but the driver model code still uses the
usb_dev_desc[] array, which has a limit.

Increasing the limit by 2 should not bother anyone. Adjust it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>







imx_watchdog: always set minimal timeout in reset_cpu
2016-01-07T16:54:53+00:00

Andrey Skvortsov
andrej.skvortzov@gmail.com

2015-12-20T18:09:58+00:00

587c3f8ebe356b558f1876414885c1b4a31294ab

The problem is that timeout bits in WCR register were leaved unchanged.
So previously set timeout value was applied and therefore 'reset'
command takes any value up to two minutes, depending on previous
watchdog settings, instead of minimal 0.5 seconds.

Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>





The problem is that timeout bits in WCR register were leaved unchanged.
So previously set timeout value was applied and therefore 'reset'
command takes any value up to two minutes, depending on previous
watchdog settings, instead of minimal 0.5 seconds.

Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>







imx: mx6ul: disable VIDEO for SPL
2016-01-07T16:51:47+00:00

Peng Fan
van.freenix@gmail.com

2016-01-04T04:19:14+00:00

ce2190f52523f36e42b702a5b59eb202aae565b2

With DEBUG macro enabled, SPL build failure:
"
arch/arm/cpu/armv7/built-in.o: In function `reset_misc':
~/uboot/arch/arm/cpu/armv7/mx6/soc.c:406: undefined reference to `lcdif_power_down'
scripts/Makefile.spl:244: recipe for target 'spl/u-boot-spl' failed
"
Wrap VIDEO settings with ifndef CONFIG_SPL_BUILD

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>





With DEBUG macro enabled, SPL build failure:
"
arch/arm/cpu/armv7/built-in.o: In function `reset_misc':
~/uboot/arch/arm/cpu/armv7/mx6/soc.c:406: undefined reference to `lcdif_power_down'
scripts/Makefile.spl:244: recipe for target 'spl/u-boot-spl' failed
"
Wrap VIDEO settings with ifndef CONFIG_SPL_BUILD

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>







mmc: update MMC_ERASE argument to match Linux kernel.
2016-01-04T16:17:43+00:00

Eric Nelson
eric@nelint.com

2015-12-07T14:50:01+00:00

1aa2d074a7acda61eb43e654ced21c139703633c

Table 41 of the JEDEC standard for eMMC says that bit 31 of
the command argument is obsolete when issuing the ERASE
command (CMD38) on page 115 of this document:
	http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also
makes no mention of the use of bit 31.
	https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and
non-secure erase, and this patch copies the macro names from
include/linux/mmc/core.h.

Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Eric Nelson <eric@nelint.com>
Tested-by: Hector Palacios <hector.palacios@digi.com>





Table 41 of the JEDEC standard for eMMC says that bit 31 of
the command argument is obsolete when issuing the ERASE
command (CMD38) on page 115 of this document:
	http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also
makes no mention of the use of bit 31.
	https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and
non-secure erase, and this patch copies the macro names from
include/linux/mmc/core.h.

Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Eric Nelson <eric@nelint.com>
Tested-by: Hector Palacios <hector.palacios@digi.com>