oweals/u-boot.git
5 years agonet: davinci_emac: drop support for unused PHYs
Bartosz Golaszewski [Mon, 29 Apr 2019 16:37:08 +0000 (18:37 +0200)]
net: davinci_emac: drop support for unused PHYs

The boards with SoCs from the DaVinci DM* family used to come with
different PHYs that needed special support implemented in mach-davinci.

Since the support for these chips has long been removed, we can now
drop this unnused code from the emac driver.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
5 years agoMerge git://git.denx.de/u-boot-socfpga
Tom Rini [Fri, 3 May 2019 18:23:01 +0000 (14:23 -0400)]
Merge git://git.denx.de/u-boot-socfpga

- Misc MMC, FPGA bridge, general SoCFPGA fixes

5 years agoMerge git://git.denx.de/u-boot-usb
Tom Rini [Fri, 3 May 2019 18:22:38 +0000 (14:22 -0400)]
Merge git://git.denx.de/u-boot-usb

- DaVinci updates

5 years agoMerge git://git.denx.de/u-boot-marvell
Tom Rini [Fri, 3 May 2019 18:22:23 +0000 (14:22 -0400)]
Merge git://git.denx.de/u-boot-marvell

- Fix in kwbimage (return code checking) (Young Xiao)
- Misc updates to Turris Omnia (Marek)

5 years agoARM: davinci: Remove unused functions from header
Adam Ford [Sun, 28 Apr 2019 21:45:26 +0000 (16:45 -0500)]
ARM: davinci: Remove unused functions from header

There are a few functions defined in the header file, but they are
not referenced by any Davinci code.  In order to make a general
function in the future with static function declarations, this
patch will remove the references all together.

Signed-off-by: Adam Ford <aford173@gmail.com>
5 years agousb: ohci: Re-enable commented out delay
Adam Ford [Sun, 28 Apr 2019 21:45:25 +0000 (16:45 -0500)]
usb: ohci: Re-enable commented out delay

There is a delay function that was commented out.  This patch
re-enables it, because it will be needed for da850 ohci support.

Signed-off-by: Adam Ford <aford173@gmail.com>
5 years agoMerge branch '2019-05-03-master-imports'
Tom Rini [Fri, 3 May 2019 11:30:55 +0000 (07:30 -0400)]
Merge branch '2019-05-03-master-imports'

- Various btrfs fixes
- Various TI platform fixes
- Other fixes (cross build, taurus update, Kconfig help text)

5 years agofs: btrfs: fix btrfs methods return values on failure
Marek Behún [Thu, 2 May 2019 13:28:43 +0000 (15:28 +0200)]
fs: btrfs: fix btrfs methods return values on failure

The btrfs implementation methods .ls(), .size() and .read() returns 1 on
failure, but the command handlers expect values <0 on failure.

For example if given a nonexistent path, the load command currently
returns success, and hush scripting does not work.

Fix this by setting return values of these methods to -1 instead of 1 on
failure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
5 years agotools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS
Fabrice Fontaine [Wed, 1 May 2019 13:08:25 +0000 (15:08 +0200)]
tools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS

When CROSS_BUILD_TOOLS is set, set HOSTCFLAGS to CFLAGS otherwise CC
will be used with HOSTCFLAGS which seems wrong

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
5 years agoARM: dts: logicpd-som-lv: Fix MMC1 card detect
Adam Ford [Tue, 30 Apr 2019 12:53:16 +0000 (07:53 -0500)]
ARM: dts: logicpd-som-lv: Fix MMC1 card detect

The card detect pin was incorrectly using IRQ_TYPE_LEVEL_LOW
instead of GPIO_ACTIVE_LOW when reading the state of the CD pin.

Without this patch, MMC1 won't be detected.

This is the same patch submitted to linux-omap, but I was hoping
to get it applied to U-Boot without having to wait for the
linux adoption and then backporting.

Fixes: 5448ff33f281 ("ARM: DTS: Resync Logic PD SOM-LV 37xx
devkit with Linux 4.18-RC4")

Signed-off-by: Adam Ford <aford173@gmail.com>
5 years agoREADME: davinci: update the documentation for DaVinci
Bartosz Golaszewski [Tue, 30 Apr 2019 07:39:25 +0000 (09:39 +0200)]
README: davinci: update the documentation for DaVinci

The DM* family of SOCs is no longer supported. We now support the
omap-l138 lcdk board and Lego EV3 platform. Reflect those changes
in the README.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
5 years agoti: Add am335x-pocketbeagle to am335x_evm_defconfig.
Vagrant Cascadian [Mon, 29 Apr 2019 23:12:30 +0000 (16:12 -0700)]
ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agoti: Add device-tree for am335x-pocketbeagle.
Vagrant Cascadian [Mon, 29 Apr 2019 23:12:29 +0000 (16:12 -0700)]
ti: Add device-tree for am335x-pocketbeagle.

Add device-tree files from linux 5.1-rc7 needed to complete support
for PocketBeagle.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agoarm: dts: k3-am654: Sync IOPAD macros with Linux
Andreas Dannenberg [Mon, 29 Apr 2019 17:56:44 +0000 (12:56 -0500)]
arm: dts: k3-am654: Sync IOPAD macros with Linux

Transition to the IOPAD macros as used in Linux in which the pin mux
mode is specified using a dedicated parameter while also dropping the
related MUX_MODEx macros that are no longer needed. This transition
will allow us to keep both Linux and U-Boot DTS in sync more easily.
While at it also align the file name of the include file itself and
update any references accordingly.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoat91: cleanup taurus port
Heiko Schocher [Mon, 29 Apr 2019 14:36:10 +0000 (16:36 +0200)]
at91: cleanup taurus port

- at91sam9g20-taurus.dts: use labels
- cleanup taurus port to compile clean with
  current mainline again. SPL has no serial
  output anymore, so it fits into SRAM.

Signed-off-by: Heiko Schocher <hs@denx.de>
5 years agofirmware: ti_sci: Always request response from firmware
Andrew F. Davis [Mon, 29 Apr 2019 13:04:11 +0000 (09:04 -0400)]
firmware: ti_sci: Always request response from firmware

TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
already do this, set this for the ones that do not.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Alejandro Hernandez <ajhernandez@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
5 years agolib: Kconfig: fix help text for GZIP
Heiko Schocher [Mon, 29 Apr 2019 06:59:38 +0000 (08:59 +0200)]
lib: Kconfig: fix help text for GZIP

commit 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")

introduced Kconfig option for gzip in U-Boot, but help text
says gzip for SPL, which is wrong. Fix this.

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
5 years agolib/vsprintf: remove #include <uuid.h> from vsprintf.c
Heinrich Schuchardt [Mon, 29 Apr 2019 06:04:36 +0000 (08:04 +0200)]
lib/vsprintf: remove #include <uuid.h> from vsprintf.c

common.h already includes uuid.h

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agofs: btrfs: Do not print mount fail message when not btrfs filesystem
Marek Behún [Fri, 26 Apr 2019 13:11:09 +0000 (15:11 +0200)]
fs: btrfs: Do not print mount fail message when not btrfs filesystem

Other filesystem drivers don't do this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
5 years agofs: correct comments for fs_read() and write()
Heinrich Schuchardt [Thu, 25 Apr 2019 18:36:39 +0000 (20:36 +0200)]
fs: correct comments for fs_read() and write()

The existing comments where confusing read and write. The comment for
fs_write() had:
"@addr: The address to read into"

So let's rework the comments and format them in Sphinx style.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoarmv7R: dts: k3: am654: Switch DMSC TX message thread ID
Andreas Dannenberg [Thu, 25 Apr 2019 17:27:02 +0000 (12:27 -0500)]
armv7R: dts: k3: am654: Switch DMSC TX message thread ID

Switch from using the high priority DMSC transmit message queue used
by the secure R5 MCU island boot context to the low priority message
queue. While the change in priority is irrelevant for the current boot
architecture it however gives us access to a deeper message queue that
will allow us to buffer more messages. This is an important aspect when
sending several messages without requesting and waiting for a response
in a row which is a communication scheme used during core shutdown for
example. See AM654 TISCI User Guide for additional details.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: am335x: Drop duplicate pinmux configuration
Paul Barker [Thu, 25 Apr 2019 14:12:00 +0000 (15:12 +0100)]
board: am335x: Drop duplicate pinmux configuration

In commit ad6054f1fe128f797b6eb2964afca6674b584785 where support for the
Sancloud BeagleBone Enhanced (BBE) was added, new conditional
configuration of either MII pin muxing or RGMII pin muxing is done
depending on the board type. However, the old call to set up MII pin
muxing was not removed.

This may result in misconfiguration of the pin muxing for the BBE or
duplicate configuration for other boards and so we remove this obsolete
call.

Signed-off-by: Paul Barker <paul.barker@sancloud.co.uk>
5 years agowatchdog: Kconfig: update WDT help message
Patrice Chotard [Thu, 25 Apr 2019 10:57:28 +0000 (12:57 +0200)]
watchdog: Kconfig: update WDT help message

Restart operation never exists and reset operation never
makes the watchdog expire immediately but expire_now operation
does.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
5 years agodma: ti: k3-udma: Do not touch RT registers before channel configuration
Peter Ujfalusi [Thu, 25 Apr 2019 06:38:15 +0000 (12:08 +0530)]
dma: ti: k3-udma: Do not touch RT registers before channel configuration

Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.

Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
5 years agofirmware: ti_sci: Fix TISCI mailbox receive timeout handling
Andreas Dannenberg [Wed, 24 Apr 2019 19:20:08 +0000 (14:20 -0500)]
firmware: ti_sci: Fix TISCI mailbox receive timeout handling

An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.

Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.

Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource management")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoMAINTAINERS, git-mailrc: Update the mmc maintainer
Peng Fan [Wed, 24 Apr 2019 11:56:58 +0000 (11:56 +0000)]
MAINTAINERS, git-mailrc: Update the mmc maintainer

Update the mmc maintainer from Jaehoon to me.

Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Marek Vasut <marex@denx.de>
5 years agodrivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL
Keerthy [Wed, 24 Apr 2019 11:03:54 +0000 (16:33 +0530)]
drivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL

Currently packet data is wrongly extracted when metadata is NULL.
Fix it and negate the if check.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
5 years agoMerge tag 'efi-2019-07-rc2' of git://git.denx.de/u-boot-efi
Tom Rini [Fri, 3 May 2019 11:10:17 +0000 (07:10 -0400)]
Merge tag 'efi-2019-07-rc2' of git://git.denx.de/u-boot-efi

Pull request for UEFI sub-system for v2019.07-rc2

This pull request provides error fixes for the handling of GPT partitions
and for the UEFI subsystem.

5 years agoarm: mvebu: turris_omnia: enable defconfig options needed by vendor
Marek Behún [Thu, 2 May 2019 14:53:40 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: enable defconfig options needed by vendor

This options will be enabled by default by CZ.NIC shipped U-Boot. Enable
them in defconfig.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: add GPIO support to defconfig
Marek Behún [Thu, 2 May 2019 14:53:39 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: add GPIO support to defconfig

Add support for the gpio command and driver for the I2C connected
pca9538 controller, to be able to determine if SFP module is present in
the Turris Omnia router.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoi2c: mvtwsi: fix reading status register after interrupt
Marek Behún [Thu, 2 May 2019 14:53:38 +0000 (16:53 +0200)]
i2c: mvtwsi: fix reading status register after interrupt

The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.

On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.

My theory is that the controller does approximately this:
  1. sets interrupt flag in control register,
  2. sets the value of status register,
  3. causes an interrupt

In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.

The bug does not appear if I add a small delay before reading status
register.

Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: add RESET button handling
Marek Behún [Thu, 2 May 2019 14:53:37 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: add RESET button handling

There is a Factory RESET button on the back side of the Turris Omnia
router. When user presses this button before powering the device up and
keeps it pressed, the microcontroller prevents the main CPU from booting
and counts how long the RESET button is being pressed (and indicates
this by lighting up front LEDs).

The idea behind this is that the user can boot the device into several
Factory RESET modes.

This patch adds support for U-Boot to read into which Factory RESET mode
the user booted the device. The value is an integer stored into the
omnia_reset environment variable. It is 0 if the button was not pressed
at all during power up, otherwise it is the number identifying the
Factory RESET mode.

This patch also changes bootcmd to a special hardcoded value if Factory
RESET button was pressed during device powerup. This special bootcmd
value sets the colors of all the LEDs on the front panel to green and
then tries to load the rescue image from the SPI flash memory and boot
it.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: fix regdomain env var setting
Marek Behún [Thu, 2 May 2019 14:53:36 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: fix regdomain env var setting

The regdomain environment variable is set according to value read from
EEPROM. This has to be done in board_late_init, after the environment
variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig
for the Turris Omnia target.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_*: remove watchdog include
Marek Behún [Thu, 2 May 2019 14:53:35 +0000 (16:53 +0200)]
arm: mvebu: turris_*: remove watchdog include

Since board watchdog is now unified and not handled in board files,
remove the unnecessary includes.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: print board info as Turris Mox
Marek Behún [Thu, 2 May 2019 14:53:34 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: print board info as Turris Mox

Unify the way how Omnia and Mox print board information (RAM size and
serial number).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: refactor more code
Marek Behún [Thu, 2 May 2019 14:53:33 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: refactor more code

Refactor RAM size reading from EEPROM in preparation for next patch.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig
Marek Behún [Thu, 2 May 2019 14:53:32 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig

This driver is required for Turris Omnia to read ethernet addresses.
Move the dependency from turris_omnia_defconfig to Kconfig.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: fix checkpatch warnings
Marek Behún [Thu, 2 May 2019 14:53:31 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: fix checkpatch warnings

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: refactor I2C accessing code
Marek Behún [Thu, 2 May 2019 14:53:30 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: refactor I2C accessing code

Refactor code which accesses the microcontroller and EEPROM via I2C.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: add SCSI as boot target
Marek Behún [Thu, 2 May 2019 14:53:29 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: add SCSI as boot target

If SCSI is enabled, U-Boot should try to boot also from SCSI device on
Turris Omnia.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: move I2C dependencies to Kconfig
Marek Behún [Thu, 2 May 2019 14:53:28 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: move I2C dependencies to Kconfig

The I2C dependencies are defined in include/configs/turris_omnia.h,
because Turris Omnia won't boot correctly without I2C support.

Move these dependencies to Kconfig, so that they are selected if Turris
Omnia is selected as target.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: remove legacy macros from board header
Marek Behún [Thu, 2 May 2019 14:53:27 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: remove legacy macros from board header

These are not needed if MMC and SCSI DM drivers are used.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: use AHCI and SATA driver model
Marek Behún [Thu, 2 May 2019 14:53:26 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: use AHCI and SATA driver model

Enable AHCI, SCSI and SATA for compliance with the driver model
migration.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: add XHCI to defconfig
Marek Behún [Thu, 2 May 2019 14:53:25 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: add XHCI to defconfig

Add XHCI_HOST and XHCI_MVEBU to defconfig, so that user's can by default
boot from USB on Turris Omnia.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agoarm: mvebu: turris_omnia: remove redundant code
Marek Behún [Thu, 2 May 2019 14:53:24 +0000 (16:53 +0200)]
arm: mvebu: turris_omnia: remove redundant code

The i2c slave disabling is done by mvtwsi driver and is not needed here.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agokwbimage: fixing the issue with proper return code checking
Young Xiao [Wed, 17 Apr 2019 09:20:24 +0000 (17:20 +0800)]
kwbimage: fixing the issue with proper return code checking

EVP_VerifyFinal would return one of three values:
1 if the data is verified to be correct;
0 if it is incorrect;
-1 if there is any failure in the verification process.

The varification in unpatched version is wrong, since it ignored
the return value of -1.

The bug allows a malformed signature to be treated as a good
signature rather than as an error. This issue affects the
signature checks on DSA ans ECDSA keys used with SSL/TLS.

This issue is similar to CVE-2008-5077, CVE-2009-0021,
CVE-2009-0025, CVE-2009-0046 ~ CVE-2009-0049.

Signed-off-by: Young Xiao <92siuyang@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
5 years agolib: uuid: Fix unseeded PRNG on RANDOM_UUID=y
Eugeniu Rosca [Thu, 2 May 2019 12:27:06 +0000 (14:27 +0200)]
lib: uuid: Fix unseeded PRNG on RANDOM_UUID=y

The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:

 => ### interrupt autoboot
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7

While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.

Assuming U-Boot with RANDOM_UUID=y is deployed on a large number of
devices, all those devices would essentially expose the same UUID,
breaking the assumption of system/RFS/application designers who rely
on UUID as being globally unique (e.g. a database using UUID as key
would alias/mix up entries/records due to duplicated UUID).

The root cause seems to be simply _not_ seeding PRNG before generating
a random value. It turns out this belongs to an established class of
PRNG-specific problems, commonly known as "unseeded randomness", for
which I am able to find below bugs/CVE/CWE:
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
   ("CVE-2015-0285 openssl: handshake with unseeded PRNG")
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
   ("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded
   randomness")
 - https://cwe.mitre.org/data/definitions/336.html
   ("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")

The first revision [1] of this patch updated the seed based on the
output of get_timer(), similar to [4].

There are two problems with this approach:
 - get_timer() has a poor _ms_ resolution
 - when gen_rand_uuid() is called in a loop, get_timer() returns the
   same result, leading to the same seed being passed to srand(),
   leading to the same uuid being generated for several partitions
   with different names

The above drawbacks have been addressed in the second version [2].
In its third revision (current), the patch reworded the description
and summary line to emphasize it is a *fix* rather than an improvement.

Testing [3] consisted of running 'gpt write mmc 1 $partitions' in a
loop on R-Car3 for several minutes, collecting 8844 randomly generated
UUIDS. Two consecutive cold boots are concatenated in the log.
As a result, all uuid values are unique (scripted check).

Thanks to Roman, who reported the issue and provided support in fixing.

[1] https://patchwork.ozlabs.org/patch/1091802/
[2] https://patchwork.ozlabs.org/patch/1092945/
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
[4] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function")

Reported-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agocmd: gpt: fix and tidy up help message
Eugeniu Rosca [Tue, 30 Apr 2019 02:53:46 +0000 (04:53 +0200)]
cmd: gpt: fix and tidy up help message

Apply the following changes:
 - Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
   since 'gpt read' is not available on CMD_GPT_RENAME=n
 - Prefix the {read,swap,rename} commands with one space for consistency
 - Prefix the 'guid' commands with 'gpt' for consistency

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agodisk: efi: Fix memory leak on 'gpt verify'
Eugeniu Rosca [Tue, 30 Apr 2019 02:53:45 +0000 (04:53 +0200)]
disk: efi: Fix memory leak on 'gpt verify'

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt verify mmc 1
 No partition list provided - only basic check
 Verify GPT: success!
 => ### keep calling 'gpt verify mmc 1'
 => ### on 58th call, we are out of memory:
 => gpt verify mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
 Verify GPT: error!

This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().

With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.

[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions

Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agodisk: efi: Fix memory leak on 'gpt guid'
Eugeniu Rosca [Tue, 30 Apr 2019 02:53:44 +0000 (04:53 +0200)]
disk: efi: Fix memory leak on 'gpt guid'

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt guid mmc 1
 21200400-0804-0146-9dcc-a8c51255994f
 success!
 => ### keep calling 'gpt guid mmc 1'
 => ### on 59th call, we are out of memory:
 => gpt guid mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid GPT ***
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid Backup GPT ***
 error!

After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().

With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.

Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: description of efi_add_handle()
Heinrich Schuchardt [Wed, 1 May 2019 07:42:39 +0000 (09:42 +0200)]
efi_loader: description of efi_add_handle()

Correct the comments describing function efi_add_handle().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_selftest: test exit_data
Heinrich Schuchardt [Sun, 30 Sep 2018 11:26:36 +0000 (13:26 +0200)]
efi_selftest: test exit_data

Amend the unit test 'start image exit' to transfer a string as exit data.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: implement support of exit data
Heinrich Schuchardt [Tue, 30 Apr 2019 15:57:30 +0000 (17:57 +0200)]
efi_loader: implement support of exit data

In case of a failure exit data may be passed to Exit() which in turn is
returned by StartImage().

Let the `bootefi` command print the exit data string in case of an error.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: memory leak in append value
Heinrich Schuchardt [Tue, 30 Apr 2019 05:14:09 +0000 (07:14 +0200)]
efi_loader: memory leak in append value

When printing an UEFI variable an error may arise while converting an
illegal hexadecimal value. In this case a buffer is leaked.

Close the memory leak. Provide an error message.

Reported-by: Coverity (CID 185830)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: optional data in load options are binary
Heinrich Schuchardt [Mon, 29 Apr 2019 11:51:45 +0000 (13:51 +0200)]
efi_loader: optional data in load options are binary

The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.

When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the BootXXXX variable.

When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.

Here is an example session protocol:

=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
  attributes: A-- (0x00000001)
  label: label1
  file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
  data:
    00000000: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00  m.y. .o.p.t.i.o.
    00000010: 6e 00 00 00                                      n...
Boot00A1:
  attributes: A-- (0x00000001)
  label: label2
  file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
  data:

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agocmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()
AKASHI Takahiro [Fri, 26 Apr 2019 00:44:18 +0000 (09:44 +0900)]
cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()

Currently in do_efi_boot_dump(), we directly read EFI variables from
related environment variables. To accommodate alternative storage
backends, we should switch to using the UEFI API instead.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: set OsIndicationsSupported at init
AKASHI Takahiro [Wed, 24 Apr 2019 06:30:38 +0000 (15:30 +0900)]
efi_loader: set OsIndicationsSupported at init

UEFI variables should be installed using well-defined API.
Currently we don't support much, but the value of OsIndicationsSupported
will be updated once some features are added in the future.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Add comments. Rename a variable.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: FreePages() must fail with pages = 0
Heinrich Schuchardt [Thu, 25 Apr 2019 16:41:40 +0000 (18:41 +0200)]
efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoefi_loader: parameter check CreateEventEx()
Heinrich Schuchardt [Thu, 25 Apr 2019 05:30:41 +0000 (07:30 +0200)]
efi_loader: parameter check CreateEventEx()

CreateEvent() and CreateEventEx() should check that a notify function is
provided for either of EVT_NOTIFY_SIGNAL or EVT_NOTIFY_WAIT.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
5 years agoMerge tag 'rockchip-for-2019.07' of git://git.denx.de/u-boot-rockchip
Tom Rini [Wed, 1 May 2019 15:52:04 +0000 (11:52 -0400)]
Merge tag 'rockchip-for-2019.07' of git://git.denx.de/u-boot-rockchip

Improvements and new features:
- improved SPI driver for better read throughput
- refactors initialisation of debug UART init
- restructures header file paths
- adds pinctrl improvements

Adds Kever as a co-custodian.

5 years agoMerge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx
Tom Rini [Wed, 1 May 2019 03:21:27 +0000 (23:21 -0400)]
Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx

Porting to DM and i.MX8
------------------------

- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8

5 years agorockchip: rk3288: include header for back_to_bootrom
Philipp Tomsich [Mon, 29 Apr 2019 22:00:38 +0000 (00:00 +0200)]
rockchip: rk3288: include header for back_to_bootrom

To avoid a warning, we need to include the header defining
back_to_bootrom for us.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3399: include gpio.h
Philipp Tomsich [Mon, 29 Apr 2019 17:05:26 +0000 (19:05 +0200)]
rockchip: rk3399: include gpio.h

After applying the series for debug_uart_init(), Travis-CI reports:

arch/arm/mach-rockchip/rk3399/rk3399.c:90:2: error: implicit declaration of function 'spl_gpio_set_pull' [-Werror=implicit-function-declaration]
  spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 2), GPIO_PULL_NORMAL);
  ^~~~~~~~~~~~~~~~~

This is caused by a missing header-file include.  Fix it.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3399: add board_debug_uart_init()
Kever Yang [Fri, 29 Mar 2019 01:09:07 +0000 (09:09 +0800)]
rockchip: rk3399: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3399: use grf structure to access reg
Kever Yang [Fri, 29 Mar 2019 01:09:06 +0000 (09:09 +0800)]
rockchip: rk3399: use grf structure to access reg

Prefer to use structure to access register if we could.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3368: move board_debug_uart_init() to rk3368.c
Kever Yang [Fri, 29 Mar 2019 01:09:05 +0000 (09:09 +0800)]
rockchip: rk3368: move board_debug_uart_init() to rk3368.c

Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3288: add board_debug_uart_init()
Kever Yang [Fri, 29 Mar 2019 01:09:04 +0000 (09:09 +0800)]
rockchip: rk3288: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3288: use grf structure to access soc_con2
Kever Yang [Fri, 29 Mar 2019 01:09:03 +0000 (09:09 +0800)]
rockchip: rk3288: use grf structure to access soc_con2

Prefer to use structure to access register if we can.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk322x: move board_debug_uart_init() to rk322x.c
Kever Yang [Fri, 29 Mar 2019 01:09:02 +0000 (09:09 +0800)]
rockchip: rk322x: move board_debug_uart_init() to rk322x.c

Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed up header-list to not break FASTBOOT:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3188: add board_debug_uart_init()
Kever Yang [Fri, 29 Mar 2019 01:09:01 +0000 (09:09 +0800)]
rockchip: rk3188: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3036: add board_debug_uart_init()
Kever Yang [Fri, 29 Mar 2019 01:09:00 +0000 (09:09 +0800)]
rockchip: rk3036: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed whitespace error:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip; kylin-rk3036: enabl DEBUG UART
Kever Yang [Fri, 29 Mar 2019 01:08:59 +0000 (09:08 +0800)]
rockchip; kylin-rk3036: enabl DEBUG UART

Enable debug uart for kylin board in defconfig.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: enable DEBUG_UART_BOARD_INIT by default
Kever Yang [Fri, 29 Mar 2019 01:08:58 +0000 (09:08 +0800)]
rockchip: enable DEBUG_UART_BOARD_INIT by default

All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board
UART IOMUX, enable it by default.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: correct ARCH_SOC name
Kever Yang [Thu, 28 Mar 2019 03:01:24 +0000 (11:01 +0800)]
rockchip: correct ARCH_SOC name

The ARCH_SOC name default as 'rockchip' and we put all the
header file in 'arch/arm/include/asm/arch-rockchip/', but
the 'rockchip' is not the SOC name, let's correct it after
we update all the source file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsiich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: use 'arch-rockchip' as header file path
Kever Yang [Thu, 28 Mar 2019 03:01:23 +0000 (11:01 +0800)]
rockchip: use 'arch-rockchip' as header file path

Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
header file path, so that we can get the correct path directly.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: arm: use 'arch-rockchip' for common header
Kever Yang [Thu, 28 Mar 2019 03:01:22 +0000 (11:01 +0800)]
rockchip: arm: use 'arch-rockchip' for common header

rockchip platform header file is in 'arch-rockchip'
instead of arch-$(SOC) for all SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: add Kever Yang as co-custodian
Kever Yang [Wed, 3 Apr 2019 07:28:16 +0000 (15:28 +0800)]
rockchip: add Kever Yang as co-custodian

This updates MAINTAINERS and git-mailrc to add me as a
co-custodian for rockchip

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Tom Rini <trini@konsulko.com>
5 years agorockchip: arm: remove no use macro
Kever Yang [Thu, 28 Mar 2019 09:36:07 +0000 (17:36 +0800)]
rockchip: arm: remove no use macro

TIMER7_BASE is no used by source code now, remove it.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agork3288-board: remove pinctrl call for debug uart
Urja Rannikko [Fri, 22 Mar 2019 19:14:34 +0000 (19:14 +0000)]
rk3288-board: remove pinctrl call for debug uart

This failed and caused a boot failure on c201, and afaik
the pins should be setup by the new pinctrl driver.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agopinctrl: exit pinconfig_post_bind if there are no subnodes
Urja Rannikko [Fri, 22 Mar 2019 19:14:33 +0000 (19:14 +0000)]
pinctrl: exit pinconfig_post_bind if there are no subnodes

This fixes RK3288 SPL hanging or hitting this assert:
drivers/core/ofnode.c:183: ofnode_first_subnode: Assertion `ofnode_valid(node)' failed.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3399: Add Orangepi RK3399 support
Jagan Teki [Mon, 11 Mar 2019 08:20:04 +0000 (13:50 +0530)]
rockchip: rk3399: Add Orangepi RK3399 support

Add initial support for Orangepi RK3399 board.

Specification
- Rockchip RK3399
- 2GB/4GB DDR3
- 16GB eMMC
- SD card slot
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- Mini PCIe
- Sensors, Keys etc
- DC12V-2A and DC5V-2A

Commit details about Linux DTS sync:
"arm64: dts: rockchip: Add support for the Orange Pi RK3399"
(sha1: d3e71487a790979057c0fdbf32f85033639c16e6)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
Jagan Teki [Mon, 11 Mar 2019 08:20:03 +0000 (13:50 +0530)]
rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
which is U-Boot specific devicetrees binding.

Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
bindings will move it future based on the requirement.

This would help to sync the devicetrees from Linux whenever required
instead of adding specific nodes.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: dts: rk3399: Sync rk3399-opp from Linux
Jagan Teki [Mon, 11 Mar 2019 08:20:02 +0000 (13:50 +0530)]
rockchip: dts: rk3399: Sync rk3399-opp from Linux

Sync rk3399-opp.dtsi from Linux.

Linux commit details about the rk3399-opp.dtsi sync:
"arm64: dts: rockchip: use SPDX-License-Identifier"
(sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: make optimised receive-handler unaligned-safe
Philipp Tomsich [Sun, 3 Feb 2019 15:17:33 +0000 (16:17 +0100)]
rockchip: spi: make optimised receive-handler unaligned-safe

To support unaligned output buffers (i.e. 'in' in the terminology of
the SPI framework), this change splits each 16bit FIFO element after
reading and writes them to memory in two 8bit transactions.  With this
change, we can now always use the optimised mode for receive-only
transcations independent on the alignment of the target buffer.

Given that we'll run with caches on, the impact should be negligible:
as expected, this has no adverse impact on throughput if running with
a 960MHz LPLL configuration.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: add driver-data and a 'rxonly_manages_fifo' flag
Philipp Tomsich [Sun, 3 Feb 2019 15:17:32 +0000 (16:17 +0100)]
rockchip: spi: add driver-data and a 'rxonly_manages_fifo' flag

The SPI controller's documentation (I only had access to the RK3399,
RK3368 and PX30 TRMs) specifies that, when operating in master-mode,
the controller will stop the SCLK to avoid RXFIFO overruns and TXFIFO
underruns.  Looks like my worries that we'd need to support DMA-330
(aka PL330) to make any further progress were unfounded.

This adds a driver-data structure to capture hardware-specific
settings of individual controller instances (after all, we don't know
if all versions are well-behaved) and adds a 'master_manages_fifo'
flag to it.  The first use of said flag is in the optimised
receive-only transfer-handler, which can now request 64Kframe
(i.e. 128KByte) bursts of data on each reprogramming of CTRLR1
(i.e. every time through the loop).

This improves throughput to 46.85MBit/s (a 94.65% bus-utilisation).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: add optimised receive-only implementation
Philipp Tomsich [Sun, 3 Feb 2019 15:17:31 +0000 (16:17 +0100)]
rockchip: spi: add optimised receive-only implementation

For the RK3399-Q7 we recommend storing SPL and u-boot.itb in the
on-module 32MBit (and sometimes even larger, if requested as part of a
configure-to-order configuration) SPI-NOR flash that is clocked for a
bitrate of 49.5MBit/s and connected in a single-IO configuration (the
RK3399 only supports single-IO for SPI).

Unfortunately, the existing SPI driver is excruciatingly slow at
reading out large chunks of data (in fact it is just as slow for small
chunks of data, but the overheads of the driver-framework make it less
noticeable): before this change, the throughput on a 4MB read from
SPI-NOR is 8.47MBit/s which equates a 17.11% bus-utilisation.

To improve on this, this commit adds an optimised receive-only
transfer (i.e.: out == NULL) handler that hooks into the main transfer
function and processes data in 16bit frames (utilising the full with
of each FIFO element).  As of now, the receive-only handler requires
the in-buffer to be 16bit aligned.  Any lingering data (i.e. either if
the in-buffer was not 16-bit aligned or if an odd number of bytes are
to be received) will be handled by the original 8bit reader/wirter.

Given that the SPI controller's documentation does not guarantuee any
interlocking between the RXFIFO and the master SCLK, the transfer loop
will be restarted for each chunk of 32 frames (i.e. 64 bytes).

With this new receive-only transfer handler, the throughput for a 4MB
read increases to 36.28MBit/s (i.e. 73.29% bus-utilisation): this is a
4x improvement over the baseline.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reported-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com>

5 years agorockchip: spi: only wait for completion, if transmitting
Philipp Tomsich [Sun, 3 Feb 2019 15:17:30 +0000 (16:17 +0100)]
rockchip: spi: only wait for completion, if transmitting

The logic in the main transmit loop took a bit of reading the TRM to
fully understand (due to silent assumptions based in internal logic):
the "wait until idle" at the end of each iteration through the loop is
required for the transmit-path as each clearing of the ENA register
(to update run-length in the CTRLR1 register) will implicitly flush
the FIFOs... transmisson can therefore not overlap loop iterations.

This change adds a comment to clarify the reason/need for waiting
until the controller becomes idle and wraps the entire check into an
'if (out)' to make it clear that this is required for transfers with a
transmit-component only (for transfers having a receive-component,
completion of the transmit-side is trivially ensured by having
received the correct number of bytes).

The change does not increase execution time measurably in any of my
tests.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: consistently use false/true with rkspi_enable_chip
Philipp Tomsich [Sun, 3 Feb 2019 15:17:29 +0000 (16:17 +0100)]
rockchip: spi: consistently use false/true with rkspi_enable_chip

While rkspi_enable_chip is called with true/false everywhere else in
the file, one call site uses '0' to denot 'false'.
This change this one parameter to 'false' and effects consistency.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: fix off-by-one in chunk size computation
Philipp Tomsich [Sun, 3 Feb 2019 15:17:28 +0000 (16:17 +0100)]
rockchip: spi: fix off-by-one in chunk size computation

The maximum transfer length (in a single transaction) for the Rockchip
SPI controller is 64Kframes (i.e. 0x10000 frames) of 8bit or 16bit
frames and is encoded as (num_frames - 1) in CTRLR1.  The existing
code subtracted the "minus 1" twice for a maximum transfer length of
0xffff (64K - 1) frames.

While this is not strictly an error (the existing code is correct, but
leads to a bit of head-scrating), fix this off-by-one situation.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: remove unused code and fields in priv
Philipp Tomsich [Sun, 3 Feb 2019 15:17:27 +0000 (16:17 +0100)]
rockchip: spi: remove unused code and fields in priv

Even though the priv-structure and the claim-bus function contain
logic for 16bit frames and for unidirectional transfer modes, neither
of these is used anywhere in the driver.

This removes the unused (as in "has no effect") logic and fields.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: spi: add debug message for delay in CS toggle
Philipp Tomsich [Sun, 3 Feb 2019 15:17:26 +0000 (16:17 +0100)]
rockchip: spi: add debug message for delay in CS toggle

In analysing delays introduced for large SPI reads, the absence of any
indication when a delay was inserted (to ensure the CS toggling is
observed by devices) became apparent.

Add an additional debug-only debug message to record the insertion and
duration of any delay (note that the debug-message will cause a delay
on-top of the delay-duration).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
5 years agorockchip: rk3399-puma: support Gigadevice SPI-NOR flash
Philipp Tomsich [Sun, 3 Feb 2019 14:59:23 +0000 (15:59 +0100)]
rockchip: rk3399-puma: support Gigadevice SPI-NOR flash

Over the last quarter, a part of our production has used NOR flash
from Gigadevice in addition to the Winbond parts that we typically
source.  This requires the SPI_FLASH_GIGADEVICE config to be set.

Enable SPI_FLASH_GIGADEVICE in the board's default defconfig.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Klaus Goger <klaus.goger@theobroma-systems.com>
5 years agoPrepare v2019.07-rc1 v2019.07-rc1
Tom Rini [Tue, 30 Apr 2019 01:54:04 +0000 (21:54 -0400)]
Prepare v2019.07-rc1

Signed-off-by: Tom Rini <trini@konsulko.com>
5 years agoconfigs: move CONFIG_SPL_TEXT_BASE to Kconfig
Simon Goldschmidt [Sun, 30 Sep 2018 12:31:53 +0000 (14:31 +0200)]
configs: move CONFIG_SPL_TEXT_BASE to Kconfig

Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing
values.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
[trini: Re-run migration]
Signed-off-by: Tom Rini <trini@konsulko.com>
5 years agoconfigs: Resync with savedefconfig
Tom Rini [Mon, 29 Apr 2019 19:54:04 +0000 (15:54 -0400)]
configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>
5 years agodts: arm: socfpga: fix socfpga_de10_nano console
Simon Goldschmidt [Mon, 29 Apr 2019 18:32:27 +0000 (20:32 +0200)]
dts: arm: socfpga: fix socfpga_de10_nano console

Booting this board failed as the initial console isn't found since
commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")

The uart0 devicetree entry was missing "clock-frequency = <100000000>:"
since that commit

Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
Reported-by: rafael mello <rafaelmello_3@hotmail.com>
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
5 years agoARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
Marek Vasut [Tue, 23 Apr 2019 15:24:22 +0000 (17:24 +0200)]
ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

The usage of socfpga_sdram_apply_static_cfg() seems rather dubious and
is confirmed to lead to a rare system hang when enabling bridges. This
patch removes the socfpga_sdram_apply_static_cfg() altogether, because
it's use seems unjustified and problematic.

The socfpga_sdram_apply_static_cfg() triggers write to SDRAM staticcfg
register to set the applycfg bit, which according to old vendor U-Boot
sources can only be written when there is no traffic between the SDRAM
controller and the rest of the system. Empirical measurements confirm
this, setting the applycfg bit when there is traffic between the SDRAM
controller and CPU leads to the SDRAM controller accesses being blocked
shortly after.

Altera originally solved this by moving the entire code which sets the
staticcfg register to OCRAM [1]. The commit message claims that the
applycfg bit needs to be set after write to fpgaportrst register. This
is however inverted by Altera shortly after in [2], where the order
becomes the exact opposite of what commit message [1] claims to be the
required order. The explanation points to a possible problem in AMP
use-case, where the FPGA might be sending transactions through the F2S
bridge.

However, the AMP is only the tip of the iceberg here. Any of the other
L2, L3 or L4 masters can trigger transactions to the SDRAM. It becomes
rather non-trivial to guarantee there are no transactions to the SDRAM
controller.

The SoCFPGA SDRAM driver always writes the applycfg bit in SPL. Thus,
writing the applycfg again in bridge enable code seems redundant and
can presumably be dropped.

[1] https://github.com/altera-opensource/u-boot-socfpga/commit/75905816ec95b0ccd515700b922628d7aa9036f8
[2] https://github.com/altera-opensource/u-boot-socfpga/commit/8ba6986b04a91d23c7adf529186b34c8d2967ad5

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
5 years agommc: dw_mmc: Round up descriptor end to nearest multiple of cacheline size
Marek Vasut [Wed, 13 Feb 2019 19:16:20 +0000 (20:16 +0100)]
mmc: dw_mmc: Round up descriptor end to nearest multiple of cacheline size

The driver currently calculates the end address of cache flush operation
for the DMA descriptors by adding cacheline size to the start address of
the last DMA descriptor. This is not safe, as the cacheline size may be,
in some unlikely cases, smaller than the DMA descriptor size. Replace the
addition with roundup() applied on the end address of the last DMA
descriptor to round it up to the nearest cacheline size multiple.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
5 years agommc: dw_mmc: Handle return value from bounce_buffer_start()
Marek Vasut [Sat, 23 Mar 2019 17:45:27 +0000 (18:45 +0100)]
mmc: dw_mmc: Handle return value from bounce_buffer_start()

The bounce_buffer_start() can return -ENOMEM in case memory allocation
failed. However, in that case, the bounce buffer address is the same as
the possibly unaligned input address, and the cache maintenance operations
were not applied to this address. This could cause subtle problems. Add
handling for the bounce_buffer_start() return value to prevent such a
problem from happening.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
5 years agommc: dw_mmc: Calculate timeout from transfer length
Marek Vasut [Sat, 23 Mar 2019 02:32:24 +0000 (03:32 +0100)]
mmc: dw_mmc: Calculate timeout from transfer length

The current 4-minute data transfer timeout is misleading and broken.
Instead of such a long wait, calculate the timeout duration based on
the length of the data transfer. The current formula is the transfer
length in bits, divided by a multiplication of bus frequency in Hz,
bus width, DDR mode and converted the mSec. The value is bounded from
the bottom to 1000 mSec.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>