summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-05-03arm: mvebu: turris_omnia: refactor I2C accessing codeMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: add SCSI as boot targetMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: move I2C dependencies to KconfigMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: remove legacy macros from board headerMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: use AHCI and SATA driver modelMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: add XHCI to defconfigMarek Behún
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>
2019-05-03arm: mvebu: turris_omnia: remove redundant codeMarek Behún
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>
2019-05-03kwbimage: fixing the issue with proper return code checkingYoung Xiao
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>
2019-05-02lib: uuid: Fix unseeded PRNG on RANDOM_UUID=yEugeniu Rosca
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>
2019-05-02cmd: gpt: fix and tidy up help messageEugeniu Rosca
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>
2019-05-02disk: efi: Fix memory leak on 'gpt verify'Eugeniu Rosca
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>
2019-05-02disk: efi: Fix memory leak on 'gpt guid'Eugeniu Rosca
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>
2019-05-02efi_loader: description of efi_add_handle()Heinrich Schuchardt
Correct the comments describing function efi_add_handle(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-02efi_selftest: test exit_dataHeinrich Schuchardt
Amend the unit test 'start image exit' to transfer a string as exit data. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-02efi_loader: implement support of exit dataHeinrich Schuchardt
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>
2019-05-02efi_loader: memory leak in append valueHeinrich Schuchardt
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>
2019-05-02efi_loader: optional data in load options are binaryHeinrich Schuchardt
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>
2019-05-02cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()AKASHI Takahiro
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>
2019-05-02efi_loader: set OsIndicationsSupported at initAKASHI Takahiro
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>
2019-05-02efi_loader: FreePages() must fail with pages = 0Heinrich Schuchardt
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>
2019-05-02efi_loader: parameter check CreateEventEx()Heinrich Schuchardt
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>
2019-05-01Merge tag 'rockchip-for-2019.07' of git://git.denx.de/u-boot-rockchipTom Rini
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.
2019-05-01Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imxTom Rini
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
2019-05-01rockchip: rk3288: include header for back_to_bootromPhilipp Tomsich
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>
2019-05-01rockchip: rk3399: include gpio.hPhilipp Tomsich
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>
2019-05-01rockchip: rk3399: add board_debug_uart_init()Kever Yang
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>
2019-05-01rockchip: rk3399: use grf structure to access regKever Yang
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>
2019-05-01rockchip: rk3368: move board_debug_uart_init() to rk3368.cKever Yang
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>
2019-05-01rockchip: rk3288: add board_debug_uart_init()Kever Yang
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>
2019-05-01rockchip: rk3288: use grf structure to access soc_con2Kever Yang
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>
2019-05-01rockchip: rk322x: move board_debug_uart_init() to rk322x.cKever Yang
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>
2019-05-01rockchip: rk3188: add board_debug_uart_init()Kever Yang
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>
2019-05-01rockchip: rk3036: add board_debug_uart_init()Kever Yang
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>
2019-05-01rockchip; kylin-rk3036: enabl DEBUG UARTKever Yang
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>
2019-05-01rockchip: enable DEBUG_UART_BOARD_INIT by defaultKever Yang
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>
2019-05-01rockchip: correct ARCH_SOC nameKever Yang
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>
2019-05-01rockchip: use 'arch-rockchip' as header file pathKever Yang
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>
2019-05-01rockchip: arm: use 'arch-rockchip' for common headerKever Yang
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>
2019-05-01rockchip: add Kever Yang as co-custodianKever Yang
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>
2019-05-01rockchip: arm: remove no use macroKever Yang
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>
2019-05-01rk3288-board: remove pinctrl call for debug uartUrja Rannikko
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>
2019-05-01pinctrl: exit pinconfig_post_bind if there are no subnodesUrja Rannikko
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>
2019-05-01rockchip: rk3399: Add Orangepi RK3399 supportJagan Teki
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>
2019-05-01rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsiJagan Teki
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>
2019-05-01rockchip: dts: rk3399: Sync rk3399-opp from LinuxJagan Teki
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>
2019-05-01rockchip: spi: make optimised receive-handler unaligned-safePhilipp Tomsich
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>
2019-05-01rockchip: spi: add driver-data and a 'rxonly_manages_fifo' flagPhilipp Tomsich
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>
2019-05-01rockchip: spi: add optimised receive-only implementationPhilipp Tomsich
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>
2019-05-01rockchip: spi: only wait for completion, if transmittingPhilipp Tomsich
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>
2019-05-01rockchip: spi: consistently use false/true with rkspi_enable_chipPhilipp Tomsich
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>
generated by cgit (git 2.34.1) at 2024-12-28 14:37:17 +0000