mkimage: Default to adding a crc32 hash with '-f auto'

This option currently does not add any sort of hash to the images in the
FIT.

Add a hash node requesting a crc32 checksum, which at least provides some
protection.

The crc32 value is easily ignored (e.g. in SPL) if not needed. and takes
up only about 48 bytes per image, including overhead.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>

tools: fw_env: Fix warning when reading too little

When using CONFIG_ENV_IS_IN_FAT and the config-file specifies a size
larger than what U-Boot wrote into the env-file, a confusing error
message is shown:

    $ fw_printenv
    Read error on /boot/uboot.env: Success

Fix this by showing a different error message when read returns too
little data.

Signed-off-by: Harald Seiler <hws@denx.de>

image: android: fix abootimg support

abootimg creates images where all load addresses are 0.

 Android Boot Image Info:
* file name = artifacts/fastboot.img
* image size = 31381504 bytes (29.93 MB)
  page size  = 2048 bytes
* Boot Name = ""
* kernel size       = 9397406 bytes (8.96 MB)
  ramdisk size      = 21981144 bytes (20.96 MB)
* load addresses:
  kernel:       0x00000000
  ramdisk:      0x00000000
  tags:         0x00000000

Without this fix we end in a data abort:

Booting kernel at 0x15000000...
*  kernel: cmdline image address = 0x15000000
Kernel load addr 0x00000000 size 9178 KiB
Kernel command line: ip=dhcp console=ttymxc0,115200n8
   kernel data at 0x15000800, len = 0x008f649e (9397406)
*  ramdisk: cmdline image address = 0x15000000
RAM disk load addr 0x00000000 size 21473 KiB
   ramdisk start = 0x158f7000, ramdisk end = 0x16def35c
   kernel loaded at 0x00000000, end = 0x00000000
   Loading Kernel Image
data abort
pc : [<8ff8c004>]    lr : [<5d7ac70f>]
sp : 8f57ed64  ip : 48f17668  fp : 00000000
r10: 00000002  r9 : 8f58aed0  r8 : 03fa4c58
r7 : 5e842497  r6 : fbe73965  r5 : 7c459955  r4 : df020fde
r3 : 1b7aa45b  r2 : 007f23fe  r1 : 15104820  r0 : 00104000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32 (T)
Code: f07c e8b1 51f8 3a20 (e8a0) 51f8
Resetting CPU ...
resetting ...

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>

dma-mapping: Add header file for ARCH_DMA_MINALIGN

This is defined in the asm/cache.h header file. Update this header file to
include it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm

usb: ohci: Add header file for ARCH_DMA_MINALIGN

This is defined in the asm/cache.h header file. Update this header file to
include it so it gets the same value consistently across U-Boot.

This fixes 'usb host' on omapl138_lcdk.

Fixes: 90526e9fbac ("common: Drop net.h from common header")
Reported-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

test/py: use actual core count for parallel builds

When building U-Boot we should not blindly use make -j8 but consider the
actual core count given by os.cpu_count().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86

- Corrected some FSP-M/FSP-S settings for Chromebook Coral
- ICH SPI driver and mrccache fixes for obtaining the SPI memory map
- Fixed various warnings generated by latest version IASL when compiling
  ACPI tables

x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge

PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:

  Warning 3073 - Multiple types (Device object requires either a _HID
  or _ADR, but not both)

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

x86: baytrail: acpi: Replace _ADR() by _UID() in description of PCI host bridge

PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:

  Warning 3073 - Multiple types (Device object requires either a _HID
  or _ADR, but not both)

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

x86: baytrail: acpi: Create buffers outside of the methods

Create buffers outside of the methods as ACPICA 20200430 complains
about this:

  Remark 2173 - Creation of named objects within a method is highly
  inefficient, use globals or method local variables instead
  (\_SB.PCI0.LPCB.IURT._CRS)

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

x86: tangier: acpi: Drop _HID() where enumerated by _ADR()

ACPICA complains that either _HID() or _ADR() should be used.
For General Purpose DMA we may not drop the _ADR() because
the device is enumerated by PCI. Thus, simple drop _HID().

Reported-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: tangier: acpi: Drop _ADR() where _HID() is present

ACPICA complains that either _HID() or _ADR() should be used.
Drop _ADR() where _HID() is present.

Reported-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: tangier: acpi: Replace _ADR() by _UID() in description of PCI host bridge

PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former.

Reported-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: tangier: acpi: Create buffers outside of the methods

Create buffers outside of the methods as ACPICA 20200214 complains about this:

Remark 2173 - Creation of named objects within a method is
highly inefficient, use globals or method local variables
instead

Reported-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: minnowmax: Add support for Winbond flash

This allows the use of the Dediprog em100pro so I can test SPI flash on
this board in my lab.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: apl: Add hex offsets for registers in FSP-S

When comparing hex dumps it is useful to see the offsets of the registers.
Add them in where they correspond to a multiple of 16.

Possibly it would be useful to have a a command to output the FSP values
in human-readable form, making use of the fsp_bindings implementation.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: coral: Correct some FSP-S settings

Some settings were modified slightly in the device-tree conversion. Return
these to their original values. This includes some audio settings and a
few others that have changed.

Note that we still rely on the FSP defaults for most values, so there is
no need to specify a value if the FSP default is suitable.

This makes WiFi work again.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>

x86: apl: Add hex offsets for registers in FSP-M

When comparing hex dumps it is useful to see the offsets of the registers.
Add them in where they correspond to a multiple of 16.

Possibly it would be useful to have a a command to output the FSP values
in human-readable form, making use of the fsp_bindings implementation.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: coral: Correct some FSP-M settings

Some settings were modified slightly in the device-tree conversion. Return
these to their original values.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>

x86: mrccache: Allow use before driver model is active

The change to avoid searching the device tree does not work on boards
wich don't have driver model set up this early, for example minnowmax.
Put back the old code (converted to livetree) as a fallback for these
devices. Also update the documentation.

This is tested on minnowmax, link, samus and coral.

Fixes: 87f1084a630 (x86: Adjust mrccache_get_region() to use livetree)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> (on Intel minnowmax)

x86: spl: Print the error on SPL failure

The error code is often useful to figure out what is going on. Printing it
does not increase code size much, so print out the error and then hang.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: spi: Rewrite logic for obtaining the SPI memory map

At present this logic does not work on link and samus, since their SPI
controller is not a PCI device, but a child of the PCH.

Unfortunately, fixing this involves a lot of extra logic. Still, this was
requested in the review of the fix-up patch, so here it is.

Fixes: 92842147c31 ("spi: ich: Add support for get_mmap() method")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> (on Intel minnowmax)

x86: spi: Add a way to access the SPI mapping via registers

At present the PCI BDF (bus/device/function) is needed to access the SPI
mapping, since the registers are at BAR0. This doesn't work when PCI
auto-config has not been done yet, since BARs are unassigned.

Add another way to find the mapping, using the MMIO base, if the caller
knows this.

Also add a missing function comment.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Merge tag 'rpi-next-2020.07.2' of https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi

rpi4:
- set ARCH_FIXUP_FDT_MEMORY
- bump NR_DRAM_BANKS to four to enable 8 GB of RAM

Merge tag 'u-boot-stm32-20200528' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm

- stm32mp15: fix DT on DHCOR SOM and avenger96 board
- stm32mp15: re-enable KS8851 on DHCOM

Merge tag 'u-boot-rockchip-20200531' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip

- Fix mmc of path after syncfrom kernel dts;
- Add dwc3 host support with DM for rk3399;
- Add usb2phy and typec phy for rockchip platform;
- Migrate board list doc to rockchip.rst;
- Add rk3399 Pinebook Pro board support;
- Update dram_init in board_init and add memory node in SPL;

spl: add fixed memory node in target fdt also when loading ATF

In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent
OP-TEE will re-use the same fdt as the U-Boot target and may need the
information about usable memory ranges.

Especially OP-TEE needs this to initialize dynamic shared memory
(the only type U-Boot implements when talking to OP-TEE).

So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to
the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the
ATF path as well.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spl: do full dram_init instead of only probing

Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.

dram_init() from sdram.c does the following steps:
- uclass_get_device(UCLASS_RAM, ...) like the current code
- ret = ram_get_info(dev, &ram);
- gd->ram_size = ram.size;

CONFIG_SPL_RAM already makes sure that sdram.c gets compiled
and thus no other variant of dram_init() can exist.

So it's the same functionality as before and only adds that the
SPL now aquires knowledge about the amount of available ram,
which it didn't know about before.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: Add initial support for the Pinebook Pro laptop from Pine64.

Specification:
- Rockchip RK3399
- 4GB Dual-Channel LPDDR4
- eMMC socket
- mSD card slot
- 128Mbit (16Mb) SPI Flash
- AP6256 for 11AC WiFi + BT5
- 14 inch 1920*1080 eDP MiPi display
- Camera
- USB 3.0, 2.0 ports
- Type-C port with alt-mode display (DP 1.2) and 15W charge
- DC 5V/3A
- optional PCIe slot for NVMe SSD drive

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

arm: dts: rockchip: Add initial DT for Pinebook Pro

Sync initial support for Pinebook Pro device tree from Linux 5.7-rc1.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

dt-bindings: input: adopt Linux gpio-keys binding constants

Sync the gpio-keys input bindings from linux 5.7-rc1.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sh

- r2dplus fixes

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usb

- ehci-mx6, eth/r8152 bugfixes

configs: rpi: set NR_DRAM_BANKS to four

With the new RPi4 which has 8 GB of RAM, we can have up to four DRAM
banks. Bump up the configuration files to detect all the memory in
U-Boot.

Signed-off-by: Matthias Brugger <mbrugger@suse.com>

rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

As discussed at https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc92c9@arm.com/T/
the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
Without it, booting with an initrd fail.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

Merge tag 'dm-pull-30may20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm

Patman changelog enhancements
Sandbox SPI flash doc update

Merge tag 'bugfixes-for-v2020.07-rc4' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c

i2c changes for v2020.07-rc4
- fix eeprom issue with AT24MAC402 (address != 0)
- fix in i2c-uclass.c when compiling compiling with -Wtype-limits
- designware_i2c: small fixes:
  - check if the device is powered
  - tidy up use of NULL priv

patman: Modify functional tests for new behavior

This patch adds or modifies functional tests for the Cover-changes,
Commit-changes, and Series-process-log tags in order to account for new
behavior added in the previous few patches. The '(no changes since v1)'
case is not tested for, since that would need an additional commit to test
in addition to testing the existing code paths.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Support multi-line changes in changelogs

This patch adds support to multi-line changes. That is, if one has a line
in a changelog like
- Do a thing but
  it spans multiple lines
Using Series-process-log sort would sort as if those lines were unrelated.
With this patch, any change line starting with whitespace will be
considered part of the change before it.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Add new tags for finer-grained changelog control

By default patman generates a combined changelog for the cover letter. This
may not always be desirable.

Many patches may have the same changes. These can be coalesced with
"Series-process-log: uniq", but this is imperfect. Similar changes like
"Move foo to patch 7" will not be merged with the similar "Move foo to this
patch from patch 6".

Changes may not make sense outside of the patch they are written for. For
example, a change line of "Add check for bar" does not make sense outside
of the context in which bar might be checked for. Some changes like "New"
or "Lint" may be repeated many times throughout different change logs, but
carry no useful information in a summary.

Lastly, I like to summarize the broad strokes of the changes I have made in
the cover letter, while documenting all the details in the appropriate
patches. I think this makes it easier to get a good feel for what has
changed, without making it difficult to wade through every change in the
whole series.

This patch adds two new tags to add changelog entries which only appear in
the cover letter, or only appear in the commit. Changes documented with
"Commit-changes" will only appear in the commit, and will not appear in the
cover letter. Changes documented with "Cover-changes" will not appear in
any commit, and will only appear in the cover letter.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Suppress empty changelog entries

Patman outputs a line for every edition of the series in every patch,
regardless of whether any changes were made. This can result in many
redundant lines in patch changelogs, especially when a patch did not exist
before a certain revision. For example, the existing behaviour could result
in a changelog of

Changes in v7: None
Changes in v6: None
Changes in v5:
- Make a change

Changes in v4: None

Changes in v3:
- New

Changes in v2: None

With this patch applied and with --no-empty-changes, the same patch would
look like

(no changes since v5)

Changes in v5:
- Make a change

Changes in v3:
- New

This is entirely aesthetic, but I think it reduces clutter, especially for
patches added later on in a series.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Add an option to create patches without binary contents

Some mailing lists have size limits and when we add binary contents
to our patches it's easy to exceed the size limits.

Git supports a command line option "--no-binary" to generate patches
without any binary contents. Add an option in patman to handle this.
Note with this option patches cannot be applied properly, but they
are still useful for code review.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Sort the command line options

Sort the existing command line options by:

- help comes first
- option starts with '-'
- option starts with '--'

Lower case followed by upper case letters, in alphabetical order.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: core: Reorder include files in read.c

Including the assembler headers before including common.h etc leads to
compilation errors upon MIPS64 based platforms using OF_LIVE. This
patch reorders the include files to the "correct" oder.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: update documents regarding spi_sf

Since the commit 1289e96797bf ("sandbox: spi: Drop command-line SPI
option"), "--spi_sf" command line option is no longer supported.

So update the following documents to sync them up with the change.
doc/arch/sandbox.rst
doc/SPI/README.sandbox-spi

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: drop CONFIG_SYS_RELOC_GD_ENV_ADDR

As we discussed in [1], this option is not needed for sandbox build.

[1] https://lists.denx.de/pipermail/u-boot/2020-February/400182.html

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

rockchip: rockpro64: enable DM_KEYBOARD

USB stack uses DM so DM_KEYBOARD is needed to get USB keyboard working.

Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

roc-rk3399-pc: Enable USB3.0 Host

Enable USB3.0 Host support for ROC-RK3399-PC boards.

Tested USB3.0 SSD on Type C1 port on board.

=> usb start
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
     u-boot EHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 100mA)
        USB 2.0 Hub [MTT]

  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 0mA)
  | |  VIA Labs, Inc. USB2.0 Hub
  | |
  | +-4  Hub (480 Mb/s, 100mA)
  |   |   USB 2.0 Hub
  |   |
  |   +-5   (480 Mb/s, 100mA)
  |        VIA Technologies Inc. USB 2.0 BILLBOARD  0000000000000001
  |
  +-3  Hub (5 Gb/s, 0mA)
    |  VIA Labs, Inc. USB3.0 Hub
    |
    +-6  Mass Storage (5 Gb/s, 224mA)
         JMicron External Disk 3.0 DB12345678A2

=> usb reset
resetting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

configs: evb-rk3399: update support usb3.0 host

Update evb-rk3399 default config to support USB3.0 Host.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

ARM: dts: rk3399-evb: usb3.0 host support

Configure 'tcphy1' and 'usbdrd_dwc3_1' nodes to support USB3.0 host
for Rockchip RK3399 Evaluation Board.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

driver: usb: drop legacy rockchip xhci driver

We have changed to use dwc3 generic driver for usb3.0 host, so the
legacy Rockchip's xHCI driver is not needed, and drop it.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

usb: dwc3: add make compatible for rockchip platform

RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller
in resetting to hold pipe power state in P2 before initializing the PHY.
This commit fixed it and added device compatible for rockchip platform.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

usb: ehci-mx6: Print error code on failure

Print the error code if the regulator enable fails, otherwise the error
message is rather useless and confusing.

Signed-off-by: Marek Vasut <marex@denx.de>

sh: r2dplus: Enable HUSH

Enable richer HUSH shell to make working with the board more pleasant.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

sh: r2dplus: Enable board_eth_init only for non-DM case

The board_eth_init() is not used for DM case, enable it only for
the non-DM case. This function should eventually be removed.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

usb: ehci-mx6: Handle fixed regulators correctly

The regulator-fixed would return -ENOSYS when enabled/disabled,
because this operation is not supported, but this is not an error
e.g. on systems where the VBUS cannot be controlled, so if this
is the error code reported by the regulator core, consider it a
success and continue.

Signed-off-by: Marek Vasut <marex@denx.de>

eth/r8152: fix assigning the wrong endpoint

Although I think it never occurs, the code doesn't make sense, because
it may allow to assign an IN endpoint to ss->ep_out.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>

Merge tag 'u-boot-amlogic-20200529' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic

- Finally enable config to support HDMI console output in VIM3 boards
- Fix USB gadget support for libretech-ac/pc & vim/vim2 boards

usb: dwc3: amend UTMI/UTMIW phy interface setup

Let move 8/16-bit UTMI+ interface initialization into DWC3 core init
that is convenient for both DM_USB and u-boot traditional process.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

usb: dwc3: Enable AutoRetry feature in the controller

By default when core sees any transaction error (CRC or overflow) it
replies with terminating retry ACK (Retry=1 and Nump == 0).

Enabling this Auto Retry feature in controller will make the core send
a non-terminanting ACK upon such transaction errors. That is, ACK TP
with Retry=1 and Nump != 0.

Doing so will give controller a chance to recover from transient error
conditions.

Reference from below Linux commit,

commit <b138e23d3dff> ("usb: dwc3: core: Enable AutoRetry feature
in the controller")

Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

usb: dwc3: Add disable u2mac linestate check quirk

This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Reference from below Linux commit,

commit <65db7a0c9816> ("usb: dwc3: add disable u2mac linestate
check quirk")

Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

usb: dwc3: add dis_u2_freeclk_exists_quirk

Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.

Refer to commit 27f83eeb6b42("usb: dwc3: add dis_u2_freeclk_exists_quirk")
in Linux Rockchip Kernel.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>

usb: dwc3: add dis_enblslpm_quirk

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.

Refer to commit ec791d149bca("usb: dwc3: Add dis_enblslpm_quirk")
in Linux Kernel.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>

phy: rockchip: Add Rockchip USB TypeC PHY driver

Add USB TYPEC PHY driver for rockchip platform.

Referenced from Linux TypeC PHY driver, currently
supporting usb3-port and dp-port need to add it
in the future.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

phy: rockchip: Add Rockchip USB2PHY driver

Add Rockchip USB2PHY driver with initial support.

This will help to use it for EHCI controller in host
mode, and USB 3.0 controller in otg mode.

More functionality like charge, vbus detection will
add it in future changes.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm: mach-rockchip: bind sub-nodes for rk3399_syscon

There are some sub-nodes under the grf DT, so add bind callback
function in rk3399 syscon driver to scan them recursively.

Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # roc-rk3399-pc
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

clk: rk3399: Enable/Disable TCPHY clocks

Enable/Disable TCPHY clock for rk3399 platform.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

clk: rk3399: Set empty for TCPHY assigned-clocks

Due to v5.7-rc1 sync the SD controller nodes in rk3399.dtsi
have SCLK_UPHY0_TCPDCORE, SCLK_UPHY1_TCPDCORE assigned-clocks
which are usually required for Linux and don't require to
handle them in U-Boot.

  assigned-clocks = <&cru SCLK_UPHY0_TCPDCORE>;
  assigned-clocks = <&cru SCLK_UPHY1_TCPDCORE>;

So, mark them as empty in clock otherwise device probe on
those typec phy driver would fail.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

clk: rk3399: Enable/Disable the USB2PHY clk

Enable/Disable the USB2PHY clk for rk3399.

CLK is clear in enable and set in disable functionality.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

doc: rockchip: Remove list of supported boards

As documentation is being moved to doc/boards/rockchip create a warning
message and remove the redundant list of supported boards.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

doc: board: rockchip: Add missing supported boards

Update the list of supported boards with the information available
on doc/README.rockchip.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

doc: board: rockchip: Improve supported board list format

As an additional step to move documentation to doc/boards/rockchip
improve format of the supported board list to make it more readable.
Additionally, add the configuration files used to build them based on
doc/README.rockchip.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: enable USB OHCI host for RockPro64

U-Boot has video output enabled so time to get keyboard working.

=> usb reset;usb tree
resetting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 3 USB Device(s) found
scanning bus dwc3 for devices... cannot reset port 1!?
2 USB Device(s) found
       scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
  1  Hub (480 Mb/s, 0mA)
     u-boot EHCI Host Controller

  1  Hub (12 Mb/s, 0mA)
      U-Boot Root Hub

  1  Hub (480 Mb/s, 0mA)
     u-boot EHCI Host Controller

  1  Hub (12 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Hub (12 Mb/s, 100mA)
    |  ALCOR Generic USB Hub
    |
    +-3  Mass Storage (12 Mb/s, 200mA)
         Kingston DT 101 G2 001478544887BB3157380157

  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller
  |
  +-2  Mass Storage (5 Gb/s, 76mA)
       ADATA ADATA USB Flash Drive 1520405012240002

Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rk3399: Enable NVMe distro bootcmd

Include NVME in the list of boot targets if CONFIG_NVME is enabled.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

pci: Make Rockchip PCIe voltage regulators optional

The vpcie*-supply properties are optional and these are absent on
boards like the ROCKPro64 and Firefly RK3399 where the voltage is
supplied by always-on regulators that are already enabled upon
boot.  Make these regulators optional and properly check their
presence before attempting to enable them.

Makes PCIe work on un U-Boot on the boards mentioned above.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>

doc: rockchip: Document eMMC program steps

Document eMMC partition creation and program steps for
rockchip platforms.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

nanopc-t4: Enable USB Gadget

Enable DWC3 core, gadget for nanopc-t4 board.

This would help to use fastboot by default.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order

Add u-boot,spl-boot-order as sdhci and sdmmc for booting
from eMMC and SD card.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

clk: rk3399: Fix eMMC get_clk reg offset

Actual eMMC get_clk register is clksel_con22 instead of
clksel_con21.

Fix it.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: Fix spl mmc boot device ofpath

Linux v5.7-rc1 dts(i) sync has changed the sdmmc node from
dwmmc@fe320000 to mmc@fe320000 and this ofpath is being
used in rockchip spl bootdevice code.

So, update the ofpath with a new node name and prefix "same-as-spl"
to missing u-boot,spl-boot-order.

Bug log:
U-Boot SPL 2020.07-rc2-00256-g9c5fef5774 (May 24 2020 - 20:20:43 +0530)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices

Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux"
Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm: dts: meson-gxl: fix USB gadget by adding missing nodes for U-Boot

The khadas-vim, khadas-vim2, libretech-ac & libretech-*-pc boards were missing
DT tweak to enable USB gadget.
Add them to their -u-boot.dtsi files and include the right gxl-u-boot.dtsi.

Fixes: a19e8a0f03 ("arm: dts: meson-gxl: Add USB Gadget nodes for U-Boot")
Reported-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

configs: khadas-vim3: enable HDMI output

Enable options to permit HDMI output on Khadas VIM3 & VIM3L boards.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

arm: dts: khadas-vim3: include meson-g12-common-u-boot.dtsi to enable HDMI output

Include the common g12 u-boot tweaks to permit enabling video output tweaks
on Khadas VIM3 boards.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

ARM: dts: stm32: Disable SDR104 mode on AV96

Disable SDR104 mode until we know it is really stable.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

ARM: dts: stm32: Repair I2C2 operation on AV96

The I2C2 uses different pinmux on AV96, use correct pinmux and
also add comments about the I2C being present on the "low-speed"
expansion connector X6.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

ARM: dts: stm32: Add alternate pinmux for I2C2 pins

Add another mux option for I2C2 pins, this is used on AV96 board.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

ARM: stm32: Hog GPIO PF7 high on DHCOR to unlock SPI NOR nWP

The SPI NOR nWP line is connected to GPIO PF7 on the SoM,
pull the GPIO line high by default to clear SPI NOR WP.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

ARM: stm32: Re-enable KS8851 on DHCOM

Since the KS8851 driver is now in, enable the Kconfig entry on DHCOM
to make the second ethernet available.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

misc: i2c_eeprom: implement different probe test eeprom offset

Because of this commit :
5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at probe()")
at probe time, each eeprom is tested for read at offset 0.

The Atmel AT24MAC402 eeprom has different mapping. One i2c slave address is
used for the lower 0x80 bytes and another i2c slave address is used for the
upper 0x80 bytes. Because of this basically the i2c master sees 2 different
slaves. We need the upper bytes because we read the unique MAC address from
this EEPROM area.

However this implies that our slave address will return error on reads
from address 0x0 to 0x80.

To solve this, implemented an offset field inside platform data that is by
default 0 (as it is used now), but can be changed in the compatible table.

The probe function will now read at this offset and use it, instead of blindly
checking offset 0.

This will fix the regression noticed on these EEPROMs since the commit
abovementioned that introduces the probe failed issue.

Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: observe scl_count in i2c_deblock_gpio_loop()

When compiling with -Wtype-limits we see this error:

drivers/i2c/i2c-uclass.c: In function ‘i2c_deblock_gpio_loop’:
drivers/i2c/i2c-uclass.c:517:21: error: comparison of
unsigned expression >= 0 is always true [-Werror=type-limits]
  517 |  while (scl_count-- >= 0) {
      |

Don't loop forever.

Fixes: 1f746a2c82b1 ("i2c: Make deblock delay and SCL clock configurable")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

i2c: designware_i2c: Check if the device is powered

If the device doesn't return a version that means the device is
non-functional.

The dw_i2c_regs had invalid offsets for the version field. I got the
correct value from the DesignWare databook. It also matches what the
Picasso PPR says.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested on chromebook_coral:
Signed-off-by: Simon Glass <sjg@chromium.org>

i2c: designware_i2c: Tidy up use of NULL priv

At present we still have pre-driver-model code in this driver and it makes
things a bit confusing. In particular calc_bus_speed() is called with priv
as NULL if not using driver model.

This results in spk_cnt and comp_param1 being read from an invalid address
if not using driver model. For comp_param1 this may not cause problems if
reading from addresses close to 0 happens to be allowed, as high speed is
only supported by DM code. But spk_cnt is subsequently used to calculate
the bus periods and so this may cause problems (e.g. on spear600 board
which has not been migrated yet).

Add a new parameter regs parameter to calc_bus_speed() and add more
comments to this function and to _dw_i2c_set_bus_speed(), which calls it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell

- Fix SPI boot on ds414 (Ezra)
- Fix PHY mode definition on armada-3720-uDPU (Jakov)
- Convert CRS305-1G-4S to generic version (Luka)

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86

- Use device tree for FSP-M and FSP-S configuration on Intel Apollo Lake
- Add SMBIOS cbmem entry parsing for coreboot
- Various clean-ups to CBFS implementation

cbfs: Don't require the CBFS size with cbfs_init_mem()

The size is not actually used since it is present in the header. Drop this
parameter. Also tidy up error handling while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cbfs: Allow reading a file from a CBFS given its base addr

Currently we support reading a file from CBFS given the address of the end
of the ROM. Sometimes we only know the start of the CBFS. Add a function
to find a file given that.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cbfs: Change file_cbfs_find_uncached() to return an error

This function currently returns a node pointer so there is no way to know
the error code. Also it uses data in BSS which seems unnecessary since the
caller might prefer to use a local variable.

Update the function and split its body out into a separate function so we
can use it later.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cbfs: Return the error code from file_cbfs_init()

We may as well return the error code and use it directly in the command
code. CBFS still uses its own error enum which we may be able to remove,
but leave it for now.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cbfs: Record the start address in cbfs_priv

The start address of the CBFS is used when scanning for files. It makes
sense to put this in our cbfs_priv struct and calculate it when we read
the header.

Update the code accordingly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cbfs: Use void * for the position pointers

It doesn't make sense to use u8 * as the pointer type for accessing the
CBFS since we do not access it as bytes, but via structures. Change it to
void *, which allows us to avoid a cast.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>