Tom Rini [Sun, 5 May 2019 00:02:16 +0000 (20:02 -0400)]
Merge tag 'mmc-2019-5-3' of https://github.com/MrVan/u-boot
Tom Rini [Sat, 4 May 2019 23:58:09 +0000 (19:58 -0400)]
Merge branch '2019-05-04-master-imports'
- Remove dead code from davinci
- Migrate CONFIG_SUPPORT_EMMC_BOOT
Robert P. J. Day [Sun, 14 Apr 2019 10:20:55 +0000 (06:20 -0400)]
delete Kbuild "select" of long-dead SPL_DISABLE_OF_CONTROL
>From way back in 2015:
commit
dffb86e468c8e02ba77283989aefef214d904dc5
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed Aug 12 07:31:54 2015 +0900
of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL
As we discussed a couple of times, negative CONFIG options make our
life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ...
and here is another one.
Now, there are three boards enabling OF_CONTROL on SPL:
- socfpga_arria5_defconfig
- socfpga_cyclone5_defconfig
- socfpga_socrates_defconfig
This commit adds CONFIG_SPL_OF_CONTROL for them and deletes
CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert
the logic.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Alex Kiernan [Wed, 1 May 2019 07:58:27 +0000 (07:58 +0000)]
Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
This converts the following to Kconfig:
CONFIG_SUPPORT_EMMC_BOOT
As requested by Michal Simek <michal.simek@xilinx.com>, these boards
have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated:
xilinx_zynqmp_zc1275_revB
xilinx_zynqmp_zc1751_xm018_dc4
xilinx_zynqmp_zc1751_xm019_dc5
xilinx_zynqmp_zcu100_revC
xilinx_zynqmp_zcu102_rev1_0
xilinx_zynqmp_zcu102_revA
xilinx_zynqmp_zcu102_revB
xilinx_zynqmp_zcu104_revA
xilinx_zynqmp_zcu104_revC
xilinx_zynqmp_zcu106_revA
xilinx_zynqmp_zcu111_revA
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Ramon Fried <ramon.fried@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Bartosz Golaszewski [Mon, 29 Apr 2019 16:37:12 +0000 (18:37 +0200)]
arm: davinci: remove leftover code for dm* SoCs
The support for DaVinci DM* SoCs has been dropped a while ago. There's
still a lot of leftover code in mach-davinci though. Entirely remove
certain files and modify the common code to no longer reference
unsupported chips.
Note: all DaVinci platforms supported in u-boot now define SOC_DA8XX
but not all define SOC_DA850 (e.g. omapl138). We can safely remove
all ifdefs for the former, but let's leave the ones for the latter.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Bartosz Golaszewski [Mon, 29 Apr 2019 16:37:11 +0000 (18:37 +0200)]
usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
The support for DaVinci DM* SoCs has been dropped. The ifdefs in the
musb_hcd driver are no longer needed. Remove them.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Marek Vasut <marex@denx.de>
Bartosz Golaszewski [Mon, 29 Apr 2019 16:37:10 +0000 (18:37 +0200)]
nand: davinci: remove dead code for dm644x
The support for DaVinci DM* SoCs has been dropped. The code that used
to be relevant to dm644x is no longer needed. Remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Bartosz Golaszewski [Mon, 29 Apr 2019 16:37:09 +0000 (18:37 +0200)]
arm: davinci: remove dead code for PHYs used by DaVinci DM* boards
The support for DaVinci DM* boards has been dropped a while ago. The
code for all those PHYs is no longer used and they have their own
proper PHY drivers in drivers/net/phy anyway. Remove all dead code.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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>
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
Tom Rini [Fri, 3 May 2019 18:22:38 +0000 (14:22 -0400)]
Merge git://git.denx.de/u-boot-usb
- DaVinci updates
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)
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>
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>
Faiz Abbas [Tue, 16 Apr 2019 17:36:58 +0000 (23:06 +0530)]
mmc: sdhci: Add Support for ADMA2
The Standard Host Controller Interface (SDHCI) specification version
3.00 adds support for Advanced DMA (ADMA) for both 64 and 32 bit widths
of DMA. ADMA2 uses a table of descriptors for aggregating DMA requests.
This significantly improves read and write throughput.
Add Support for the same.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Faiz Abbas [Tue, 16 Apr 2019 17:36:57 +0000 (23:06 +0530)]
mmc: sdhci: Move DMA handling to prepare_dma() function
In preparation for addition of ADMA2 support, cleanup SDMA handling by
moving it to a new sdhci_prepare_dma() function. Also add a flags field
in sdhci_host to indicate if DMA is enabled.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Ye Li [Mon, 7 Jan 2019 09:10:27 +0000 (09:10 +0000)]
mmc: fsl_esdhc: Fix wp_enable issue
The wp-gpios property is used for gpio, if this is set, the WP pin is muxed
to gpio function, can't be used as internal WP checking. However the codes
remain to use internal WP checking.
This patch changes to examine the "fsl,wp-controller" for enabling internal WP
checking, and "wp-gpios" for muxing to gpio.
Signed-off-by: Ye Li <ye.li@nxp.com>
Ye Li [Mon, 7 Jan 2019 03:18:06 +0000 (03:18 +0000)]
mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue
When sd/mmc work at DDR mode, like HS400/HS400ES/DDR52/DDR50 mode,
the output clock rate is half of the internal clock rate.
This patch set the DDR_EN bit first for DDR mode, hardware divide
the usdhc clock automatically, then follow the original sdr clock
setting method.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
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)
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>