PWM_ROCKCHIP need to enable for PWM regulator, this config
is missing during rebase and new patch set in previous submission.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The size dram node need to be deduced by the same amount of reserved space.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

UART,s -> UARTs, to avoid this spreading via copy&paste.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NSimon Glass <sjg@chromium.org>

Sort rk3036 before rk3288.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NSimon Glass <sjg@chromium.org>

Currently the specific set ops functions are directly
called without any check for min/max current limits for a regulator.
Check for them and proceed.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Fixed checking of current limits:
Signed-off-by: NSimon Glass <sjg@chromium.org>

Currently the specific set ops functions are directly
called without any check for voltage limits for a regulator.
Check for them and proceed.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Fixed checking of voltate limits:
Signed-off-by: NSimon Glass <sjg@chromium.org>

In case we want to force a particular value on a regulator
irrespective of the min/max constraints for testing purposes
one can call regulator_set_value_force function.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add Jagan and Maxime as Maintainers for SUNXI
Signed-off-by: NJagan Teki <jagan@openedev.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

This commit adds support for the Macronix MX66U51235F,
MX66L1G45G and Micron MT25QU02G, MT25QL02G flash parts.
Signed-off-by: NRadu Bacrau <dumitru.bacrau@intel.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Radu Bacrau <radu.bacrau@gmail.com>
[Update proper commit header and 80-line cut on body]
Reviewed-by: NJagan Teki <jagan@openedev.com>

Starting with the changes to fix USB host on am57xx/am43xx we stopped
using usb_otg_ss1/related stuff and but we hadn't been enabling the
relevant options to cause the warnings until just recently.

Fixes: 55efadde (ARM: AM57xx: AM43xx: Fix USB host)
Fixes: a48d687c (configs: am57xx: Enable download gadget)
Signed-off-by: NTom Rini <trini@konsulko.com>

Currently, the fastboot item in menuconfig is a comment followed by a
boolean option withan empty prompt, followed by a menu:

        *** FASTBOOT ***
    [*]
          Fastboot support  --->

This is not "nice-looking" at all...

Change the logic to make the boolean option a "menuconfig" rather than a
mere "config", so that all dependent options gets groupped under a menu.
The layout is now:

        *** FASTBOOT ***
    [*] Fastboot support  --->
Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

The previous partition table did not support a separate device tree
and the kernel size was limited to 4MB.  This update shows the
location of the device tree (labeled as spl-os) for those who
want to use Falcon Mode or use U-Boot to store the Flattened
Device Tree (FDT) to NAND without appending it to the kernel.

This also grows the kernel to 6MB since 4MB was becomming tight
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Commit ("2cd1ff84: OMAP3_LOGIC: Setup defconfig to enable
SPL and NAND booting") accidentally enabled FIT support.

This patch removes the FIT support.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

The memory map defined in commit ("49c7303f: OMAP3: Enable SPL
on omap3_logic) was used by a copy-paste of another board without
fully understanding how the map works in Falcon mode.  This patch
undoes the customization and uses the default SPL Memory Map
for OMAP3.

When building the uImage, set LOADADDR=0x82000000 and Falcon
mode should properly load.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].

If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.

This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob

There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:

fdt addr ${fdt_addr}
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}

Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.

[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018Signed-off-by: NCédric Schieli <cschieli@gmail.com>
Acked-by: NStephen Warren <swarren@nvidia.com>

Implement a hook to allow boards to save boot-time CPU state for later
use. When U-Boot is chain-loaded by another bootloader, CPU registers may
contain useful information such as system configuration information. This
feature mirrors the equivalent ARMv7 feature.
Signed-off-by: NCédric Schieli <cschieli@gmail.com>
Acked-by: NStephen Warren <swarren@nvidia.com>

Remove the need to explicitly add SHA/RSA pairings. Invalid SHA/RSA
pairings will still fail on verify operations when the hash length is
longer than the key length.

Follow the same naming scheme "checksum,crytpo" without explicitly
defining the string.

Indirectly adds support for "sha1,rsa4096" signing/verification.
Signed-off-by: NAndrew Duda <aduda@meraki.com>
Signed-off-by: Naduda <aduda@meraki.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Cut down on the repetition of algorithm information by defining separate
checksum and crypto structs. image_sig_algos are now simply pairs of
unique checksum and crypto algos.
Signed-off-by: NAndrew Duda <aduda@meraki.com>
Signed-off-by: Naduda <aduda@meraki.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Padding verification was done against static SHA/RSA pair arrays which
take up a lot of static memory, are mostly 0xff, and cannot be reused
for additional SHA/RSA pairings. The padding can be easily computed
according to PKCS#1v2.1 as:

  EM = 0x00 || 0x01 || PS || 0x00 || T

where PS is (emLen - tLen - 3) octets of 0xff and T is DER encoding
of the hash.

Store DER prefix in checksum_algo and create rsa_verify_padding
function to handle verification of a message for any SHA/RSA pairing.
Signed-off-by: NAndrew Duda <aduda@meraki.com>
Signed-off-by: Naduda <aduda@meraki.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

checksum_algo's pad_len field isn't actually used to store the length of
the padding but the total length of the RSA key (msg_len + pad_len)
Signed-off-by: NAndrew Duda <aduda@meraki.com>
Signed-off-by: Naduda <aduda@meraki.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

With the move to arch/arm/mach-omap2 there are now very few uses of
CONFIG_OMAP_COMMON and further they can all be replaced with
CONFIG_ARCH_OMAP2, so do so.
Signed-off-by: NTom Rini <trini@konsulko.com>

This moves what was in arch/arm/cpu/armv7/omap-common in to
arch/arm/mach-omap2 and moves
arch/arm/cpu/armv7/{am33xx,omap3,omap4,omap5} in to arch/arm/mach-omap2
as subdirectories.  All refernces to the former locations are updated to
the current locations.  For the logic to decide what our outputs are,
consolidate the tests into a single config.mk rather than including 4.
Signed-off-by: NTom Rini <trini@konsulko.com>

To start consolidating various TI-related code, introduce the ARCH_OMAP2
symbol.  While we have removed omap2-specific boards some time ago,
matching up with the kernel naming here will help overall.
Signed-off-by: NTom Rini <trini@konsulko.com>

After the latest changes, ext4 no longer has any fails.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>

Support was already implemented, but not hooked up. This fixes several
fails in the test cases.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>

A sparse file may have regions not mapped by any extents, at the start
or at the end of the file, or anywhere between, thus not finding a
matching extent region is never an error.

Found by python filesystem tests.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>

If a test uses a fixture which is expensive to setup, the fixture can
possibly created with session or module scope. As u_boot_console has
function scope, it can not be used in this case.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>

The IP supports two ports, A and B, each providing up to 32 gpios.
The driver already creates a 2nd gpio bank by reading the 2nd node
from DT, so this is quite a simple change to support the 2nd bank.
Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com>
Acked-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Make Android partition table the same as for AM57x EVM.

  1. Make "bootloader" partition start from 0x300 sectors offset, so
     DRA7 is bootable in Android mode (see
     CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR option).
  2. Increase "bootloader" partition size, because size of u-boot.img is
     about 632 KiB (when building DT defconfig, with FIT image enabled).
  3. Specify "reserved" partition explicitly, rather than specifying
     "efs" partition start. Reserved area will be used to store U-Boot
     environment on eMMC. It's convenient to have it exposed explicitly
     so we can read/write U-Boot environment.
  4. Keep all Android partitions locations intact, by reducing
     "reserved" partition size. CONFIG_ENV_SIZE is considered.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>

Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>

"fastboot oem format" command reuses "gpt write" command, which in turn
requires correct partitions defined in $partitions variable. This patch
adds such definition of Android partitions for DRA7XX EVM board.

By default $partitions variable contains Linux partition table. In order
to prepare Android environment one can run next commands from U-Boot
shell:

    => env set partitions $partitions_android
    => env save

After those operations one can go to fastboot mode and perform
"fastboot oem format" to create Android partition table.

While at it, enable CONFIG_RANDOM_UUID to spare user from providing
UUIDs for each partition manually.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>

Add support for distro_bootcmd on MMC and fall back to prior
behavior if distro_bootcmd fails.

Tested on Beagleboad xM to boot GRUB2 (and then Linux kernel) in EFI mode
from MMC.
Signed-off-by: NGuillaume GARDET <guillaume.gardet@free.fr>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Enable USB download gadget (needed for fastboot support) and all
dependencies.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

On "fastboot reboot-bootloader" we check "dofastboot" variable and do
"fastboot 0" command in U-Boot if it's 1. But there are boards which have
USB controller number other than 0, so it should be respected when
performing "fastboot" command.

This patch reuses CONFIG_FASTBOOT_USB_DEV option toprovide correct USB
controller number to "fastboot" command.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Some boards (like AM57x EVM) has USB OTG controller other than 0. So in
order to use correct controller number in compiled environment we should
define CONFIG_FASTBOOT_USB_DEV option.

For example, when doing "fastboot reboot-bootloader" we want to enter
fastboot mode automatically. But to do so we need to provide controller
number to "fastboot" command. If this procedure is defined in some config
which is common to bunch of boards, and boards have different USB
controller numbers, we can't just hardcode "fastboot 0" in the
environment. We need to use configurable option, which this patch adds.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Detect the board very early and avoid reading eeprom multiple times.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

This is similar to Commit 93e6253d ("ARM: OMAP4/5: Centralize
early clock initialization") that was done for OMAP4+, reflecting the same
for AM33xx and AM43xx SoCs to centralize clock initialization.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
[trini: Add setup_early_clocks that calls setup_clocks_for_console for
        ti81xx]
Signed-off-by: NTom Rini <trini@konsulko.com>

Early system initialization is being done before initf_dm is being called
in U-Boot. Then system will fail to boot if any of the DM enabled driver
is being called in this system initialization code. So, rearrange the
code a bit so that DM enabled drivers can be called during early system
initialization. This is inspired by commit e850ed82 ("ARM: OMAP4+: Allow
arch specific code to use early DM")
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>