u-boot.git/include/configs, branch v2017.07-rc1 Unnamed repository; edit this file 'description' to name the repository. ARM: ti: Update layout for MMC and eMMC (env and dfu) 2017-06-05T18:13:10+00:00 Jean-Jacques Hiblot jjhiblot@ti.com 2017-05-24T10:08:27+00:00 7a53a1a8115beb53b47a758c1a6e527420d8a43e The problems with the current DFU layout are: MMC: The space allocated for u-boot is too small for the latest u-boot (>750KB). We need to increase it. eMMC uses a much bigger area (2MB). eMMC: region "u-boot.img.raw" overlaps the environment area and the region "spl-os-image.raw". both: region "spl-os-image.raw" is quite small and can't handle android kernels Fixing this requires growing some regions and moving others. Care has been taken to leave some room for further growth of "spl-os-args.raw". Also the "env" now appears in the dfu so that it's apparent that the region is not free space that can be used to grow "u-boot.img.raw". The MLO region is 0x100 sectors wide but the 0x100 are unused in case the MLO comes too overflow this areas. The total space allocated for those raw binaries is 16MB, of which 13+MB are reserved for the kernel image. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> 
The problems with the current DFU layout are:
MMC: The space allocated for u-boot is too small for the latest u-boot
     (>750KB). We need to increase it. eMMC uses a much bigger area (2MB).
eMMC: region "u-boot.img.raw" overlaps the environment area and the region
      "spl-os-image.raw".
both: region "spl-os-image.raw" is quite small and can't handle android
      kernels

Fixing this requires growing some regions and moving others.
Care has been taken to leave some room for further growth of
"spl-os-args.raw".
Also the "env" now appears in the dfu so that it's apparent that the
region is not free space that can be used to grow "u-boot.img.raw".
The MLO region is 0x100 sectors wide but the 0x100 are unused in case the
MLO comes too overflow this areas.
The total space allocated for those raw binaries is 16MB, of which 13+MB
are reserved for the kernel image.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
arm: am57xx: cl-som-am57x: adjust default env to the installation system 2017-06-05T18:13:01+00:00 Uri Mashiach uri.mashiach@compulab.co.il 2017-05-17T14:29:28+00:00 dbf0518b608b1395bf81bad0b89e314c17ba339c The SD card automatic installation system depends on the default environment of the previous U-Boot. Add the missing environment variables. Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il> Reviewed-by: Tom Rini <trini@konsulko.com> 
The SD card automatic installation system depends on the default
environment of the previous U-Boot.

Add the missing environment variables.

Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
arm: am57xx: cl-som-am57x: support for FS boot 2017-06-05T18:13:00+00:00 Uri Mashiach uri.mashiach@compulab.co.il 2017-05-17T14:29:25+00:00 5c291bef30e10bb6fed4f65c1f7a4d58c20eb8a6 Supported boot devices are raw QSPI and raw SD card. Add support for a FAT16/32 file system for SD card. The SOC's boot ROM only supports FAT file system. Therefore remove the SPL support for the EXT file system. Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il> Reviewed-by: Tom Rini <trini@konsulko.com> 
Supported boot devices are raw QSPI and raw SD card.
Add support for a FAT16/32 file system for SD card.

The SOC's boot ROM only supports FAT file system.
Therefore remove the SPL support for the EXT file system.

Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
common: arm: freescale: layerscape: Move header files out of common.h 2017-06-05T18:12:59+00:00 Simon Glass sjg@chromium.org 2017-05-17T14:23:10+00:00 457e51cffdacf117c2afdd09d9bfc2f8df7314cb We should not have an arch-specific header file in common.h. Adjust the board files a little so it is not needed, and drop it. Signed-off-by: Simon Glass <sjg@chromium.org> 
We should not have an arch-specific header file in common.h. Adjust the
board files a little so it is not needed, and drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
common: arm: davinci: Move header file out of common 2017-06-05T16:31:23+00:00 Simon Glass sjg@chromium.org 2017-05-17T14:23:09+00:00 89f5eaa1ee9a3307e05458aa4f3b2155ab0a7144 We should not have an arch-specific header file in common.h. Instead, use the asm/hardware.h header to provide the required declarations, and drop the common.h changes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> 
We should not have an arch-specific header file in common.h. Instead, use
the asm/hardware.h header to provide the required declarations, and drop
the common.h changes.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
t81xx: Migrate TI81XX/TI816X/TI814X symbols to Kconfig 2017-06-05T15:02:25+00:00 Tom Rini trini@konsulko.com 2017-05-16T18:46:40+00:00 8bb687fdc10946a25e81393f8d6617d17e890df0 The symbol CONFIG_TI81XX is used for the parts that are common to the TI816x and TI814x SoCs and are not part of CONFIG_ARCH_OMAP2PLUS nor CONFIG_AM33XX. It however has so few uses that we can just modify the code to check for both and drop the symbol. The symbols CONFIG_TI816X and CONFIG_TI814X are for the repective SoCs. Signed-off-by: Tom Rini <trini@konsulko.com> 
The symbol CONFIG_TI81XX is used for the parts that are common to the
TI816x and TI814x SoCs and are not part of CONFIG_ARCH_OMAP2PLUS nor
CONFIG_AM33XX.  It however has so few uses that we can just modify the
code to check for both and drop the symbol. The symbols CONFIG_TI816X
and CONFIG_TI814X are for the repective SoCs.

Signed-off-by: Tom Rini <trini@konsulko.com>
ti816x: Modernize the defconfig 2017-06-05T15:02:25+00:00 Tom Rini trini@konsulko.com 2017-05-16T18:46:39+00:00 1d7f6ad2bf74afd26df1f455c05a4a1dc4915449 - Switch to using <configs/ti_armv7_omap.h> and family. This lets us drop lots of custom defines. - Ensure that our default environment uses DEFAULT_LINUX_BOOT_ENV so that Linux will boot correctly. - Enable CONFIG_DISTRO_DEFAULTS - Switch to using CONFIG_OF_CONTROL - Various other cleanups to match other SoCs in the family line. Signed-off-by: Tom Rini <trini@konsulko.com> 
- Switch to using <configs/ti_armv7_omap.h> and family.  This lets us
  drop lots of custom defines.
- Ensure that our default environment uses DEFAULT_LINUX_BOOT_ENV so
  that Linux will boot correctly.
- Enable CONFIG_DISTRO_DEFAULTS
- Switch to using CONFIG_OF_CONTROL
- Various other cleanups to match other SoCs in the family line.

Signed-off-by: Tom Rini <trini@konsulko.com>
ti816x: Enable NAND 2017-06-05T15:02:24+00:00 Tom Rini trini@konsulko.com 2017-05-16T18:46:37+00:00 77e99277a20533108101c3024f3c3cfbff0f7e80 The TI8168-EVM comes with NAND on board. Enable it and move environment over there. Signed-off-by: Tom Rini <trini@konsulko.com> 
The TI8168-EVM comes with NAND on board.  Enable it and move environment
over there.

Signed-off-by: Tom Rini <trini@konsulko.com>
ti816x: Rework DDR initialization sequence 2017-06-05T15:02:23+00:00 Tom Rini trini@konsulko.com 2017-05-16T18:46:35+00:00 8627733941ff9d35a3778da9c9b2e495a17bfe70 The ti816x/am389x SoC is the first generation in what U-Boot calls the "am33xx" family. In the first generation of this family the DDR initialization sequence is quite different from all of the subsequent generations. Whereas with ti814x (second generation) we can easily work the minor differenced between that and am33xx (third generation), our attempts to do this for ti816x weren't sufficient. Rather than add a large amount of #ifdef logic to make this different sequence work we add a new file, ti816x_emif4.c to handle the various required undocumented register writes and sequence and leverage what we can from arch/arm/mach-omap2/am33xx/ddr.c still. As DDR2 has similar problems today but I am unable to test it, we drop the DDR2 defines from the code rather than imply that it works by leaving it. We also remove a bunch of other untested code about changing the speed the DDR runs at. Signed-off-by: Tom Rini <trini@konsulko.com> 
The ti816x/am389x SoC is the first generation in what U-Boot calls the
"am33xx" family.  In the first generation of this family the DDR
initialization sequence is quite different from all of the subsequent
generations.  Whereas with ti814x (second generation) we can easily work
the minor differenced between that and am33xx (third generation), our
attempts to do this for ti816x weren't sufficient.  Rather than add a
large amount of #ifdef logic to make this different sequence work we add
a new file, ti816x_emif4.c to handle the various required undocumented
register writes and sequence and leverage what we can from
arch/arm/mach-omap2/am33xx/ddr.c still.  As DDR2 has similar problems
today but I am unable to test it, we drop the DDR2 defines from the code
rather than imply that it works by leaving it.  We also remove a bunch
of other untested code about changing the speed the DDR runs at.

Signed-off-by: Tom Rini <trini@konsulko.com>
Enable PXE boot on meson-gxbb. 2017-06-05T15:02:22+00:00 Vagrant Cascadian vagrant@debian.org 2017-05-05T21:11:26+00:00 e320d377666c87c0df21787f8b0432d6791c2900 Enable distro_bootcmd PXE functions on meson-gxbb systems. Signed-off-by: Vagrant Cascadian <vagrant@debian.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
Enable distro_bootcmd PXE functions on meson-gxbb systems.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>