August 2019 - U-Boot

[U-Boot] [PATCH 0/3] arm: socfpga: Convert drivers from struct to defines
by Ley Foon Tan 28 Aug '19

28 Aug '19

Convert reset, system and clock manager drivers to use #define instead of struct. No functional change. Ley Foon Tan (3): arm: socfpga: Convert reset manager from struct to defines arm: socfpga: Convert system manager from struct to defines arm: socfpga: Convert clock manager from struct to defines arch/arm/mach-socfpga/clock_manager.c | 12 +- arch/arm/mach-socfpga/clock_manager_arria10.c | 217 +++++++++-------- arch/arm/mach-socfpga/clock_manager_gen5.c | 221 +++++++++--------- arch/arm/mach-socfpga/clock_manager_s10.c | 171 +++++++------- .../mach-socfpga/include/mach/clock_manager.h | 15 ++ .../include/mach/clock_manager_arria10.h | 129 ++++------ .../include/mach/clock_manager_gen5.h | 108 ++++----- .../include/mach/clock_manager_s10.h | 111 ++++----- .../mach-socfpga/include/mach/reset_manager.h | 12 + .../include/mach/reset_manager_arria10.h | 41 +--- .../include/mach/reset_manager_gen5.h | 20 +- .../include/mach/reset_manager_s10.h | 33 +-- .../include/mach/system_manager.h | 15 ++ .../include/mach/system_manager_arria10.h | 92 ++------ .../include/mach/system_manager_gen5.h | 121 ++-------- .../include/mach/system_manager_s10.h | 184 ++++++--------- arch/arm/mach-socfpga/mailbox_s10.c | 5 +- arch/arm/mach-socfpga/misc_arria10.c | 7 +- arch/arm/mach-socfpga/misc_gen5.c | 22 +- arch/arm/mach-socfpga/misc_s10.c | 8 +- arch/arm/mach-socfpga/reset_manager_arria10.c | 73 +++--- arch/arm/mach-socfpga/reset_manager_gen5.c | 33 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 52 ++--- arch/arm/mach-socfpga/scan_manager.c | 6 +- arch/arm/mach-socfpga/spl_a10.c | 5 +- arch/arm/mach-socfpga/spl_gen5.c | 15 +- arch/arm/mach-socfpga/spl_s10.c | 9 +- arch/arm/mach-socfpga/system_manager_gen5.c | 33 ++- arch/arm/mach-socfpga/system_manager_s10.c | 32 +-- arch/arm/mach-socfpga/wrap_pll_config_s10.c | 11 +- drivers/ddr/altera/sdram_gen5.c | 9 +- drivers/ddr/altera/sdram_s10.c | 6 +- drivers/fpga/socfpga_arria10.c | 7 +- drivers/fpga/socfpga_gen5.c | 4 +- drivers/mmc/socfpga_dw_mmc.c | 15 +- drivers/sysreset/sysreset_socfpga.c | 6 +- 36 files changed, 754 insertions(+), 1106 deletions(-) -- 2.19.0

4 24

[U-Boot] [PATCH v3 0/4] ARM: Aspeed: Add SD host controller driver
by Eddie James 28 Aug '19

28 Aug '19

This series adds support for the SD host controller on the Aspeed ast2xxx SocS. It also enables MMC and the SD controller for the ast2500 EVB. Changes since v2: - Remove mmc_initialize call in the ast2500 board init - Add OF_CONTROL to the ast2500 EVB configuration - Fix the clock-getting code in the driver probe function Changes since v1: - Split the patch up - Add defconfig and devicetree changes Eddie James (4): clk: aspeed: Add support for SD clock mmc: Add Aspeed SD controller driver configs: AST2500 EVB: Enable SD controller ARM: dts: ast2500: Add SDHCI nodes arch/arm/dts/ast2500-evb.dts | 14 ++++ arch/arm/dts/ast2500-u-boot.dtsi | 16 +++++ arch/arm/include/asm/arch-aspeed/scu_ast2500.h | 3 + arch/arm/include/asm/gpio.h | 3 +- configs/evb-ast2500_defconfig | 8 +++ drivers/clk/aspeed/clk_ast2500.c | 27 ++++++++ drivers/mmc/Kconfig | 11 ++++ drivers/mmc/Makefile | 1 + drivers/mmc/aspeed_sdhci.c | 90 ++++++++++++++++++++++++++ drivers/pinctrl/aspeed/pinctrl_ast2500.c | 2 + 10 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 drivers/mmc/aspeed_sdhci.c -- 1.8.3.1

3 9

[U-Boot] [PATCH v4 0/8] Support Andes RISC-V l2cache on AE350 platform
by Andes 28 Aug '19

28 Aug '19

From: Rick Chen <rick(a)andestech.com> Add a v5l2 cache controller driver that is usually found on Andes RISC-V ae350 platform. It will parse and configure the cache settings (data & instruction prefetch, data & tag latency) from the device tree blob. Also implement L2 cache flush and disable before jump to linux. The sequence will be preferred as below: L1 flush -> L1 disable -> L2 flush -> L2 disable Changes in v4: - Remove definitions of v5l2cache.h to cache-v5l2.c Changes in v3: - Add the enable/disable in sandbox_cache.c. - Parse dtb data in v5l2_ofdata_to_platdata() and configure HW in v5l2_probe(). - Move cache_disable() into dcache_disable() of cache.c Changes in v2: - Add new patch [1/7] to support dm cache uclass enable and disable ops. - Use ofdata_to_platdata() to parse and save register base instead of global data. - Rename compatible string of "cache" as "v5l2cache". - make v512_init() return void. - Use dm cache uclass api to disable L2 cache. Rick Chen (8): dm: cache: Add enable and disable ops for cache uclass dm: cache: Add enable and disable ops for sandbox and test dm: cache: add v5l2 cache controller driver riscv: ae350: use the v5l2 driver to configure the cache riscv: ax25: add imply v5l2 cache controller riscv: cache: Flush L2 cache before jump to linux riscv: dts: move out AE350 L2 node from cpus node riscv: cache: use CCTL to flush d-cache arch/riscv/cpu/ax25/Kconfig | 1 + arch/riscv/cpu/ax25/cache.c | 39 +++++-- arch/riscv/dts/ae350_32.dts | 17 +-- arch/riscv/dts/ae350_64.dts | 17 +-- board/AndesTech/ax25-ae350/ax25-ae350.c | 9 ++ drivers/cache/Kconfig | 9 ++ drivers/cache/Makefile | 1 + drivers/cache/cache-uclass.c | 20 ++++ drivers/cache/cache-v5l2.c | 186 ++++++++++++++++++++++++++++++++ drivers/cache/sandbox_cache.c | 13 +++ include/cache.h | 31 ++++++ test/dm/cache.c | 2 + 12 files changed, 324 insertions(+), 21 deletions(-) create mode 100644 drivers/cache/cache-v5l2.c -- 2.7.4

2 9

[U-Boot] Error reading cluster" from fs/fat/fat.c
by Oliver Graute 28 Aug '19

28 Aug '19

Hello list, I have a annoying problem with u-boot 2019.07. I try to boot a Linux Image from a fat16 partition on a SD-Card. But I got the "Error reading cluster" Message from fs/fat/fat.c => boot switch to partitions #0, OK mmc2 is current device Error reading cluster ** Unable to read file Image ** => mmc part Partition Map for MMC device 2 -- Partition Type: DOS Part Start Sector Num Sectors UUID Type 1 16384 266240 d38187c8-01 06 2 282624 7491584 d38187c8-02 83 After some debugging I end up in blk_dread() from drivers/block/blk-uclass.c blks_read = ops->read(dev, start, blkcnt, buffer); here I got blks_read=0 which seems is the cause for the "Error reading cluster" later in get_cluster(). Here a Debug Trace with some variables printed out: ... get_fatent() FAT16: entry: 0x0000595c = 22876, offset: 0x055c = 1372 get_fatent() FAT16: ret: 0x0000595d, entry: 0x0000595c, offset: 0x055c get_cluster() gc - clustnum: 16813, startsect: 134800 blkcache_read() miss: start 24e90, count 48513 blk_dread() dev=fd6ebaa0 blk_dread() start=24e90 blk_dread() blkcnt=48513 blk_dread() buffer=80280000 blk_find_device() blk_find_device: if_type=6, devnum=2: usdhc(a)5b010000.blk, 6, 0 blk_find_device() blk_find_device: if_type=6, devnum=2: usdhc(a)5b030000.blk, 6, 2 blk_dread() blks_read=0 blk_dread() blkcnt=48513 disk_read() ret=0 disk_read() nr_blocks=48513 get_cluster() Error reading data (got -1) 2 get_cluster() ret=-1 get_cluster() idx=48513 Error reading cluster 2 ** Unable to read file Image ** Can somebody help me to find the cause of this problem? Is something with my fat partion or partition table wrong or do I hit a bug? Best regards, Oliver

1 2

[U-Boot] booting multi-image with several embedded dtbs
by Rasmus Villemoes 28 Aug '19

28 Aug '19

Hi, I have a (legacy) multi-image uImage with several embedded dtbs, but no initrd. I.e. one created by something like "mkimage -T multi -d zImage:dtb1:dtb2:dtb3". I thought I could boot that using the bootm command like this bootm $loadaddr:0 - $loadaddr:3 # choose dtb3 but that fails with ERROR: uImage is not a fdt Just doing "bootm $loadaddr" kind of works (in the sense that the kernel starts, and I can see that dtb2 got passed as dtb) fails quite miserably once dtb1 gets interpreted as an initrd - and of course what I want is to be able to choose between the dtbs at runtime. Yes, we will switch to proper FIT image at some point, but is there any way to use the existing multi-image uImage as described? Thanks, Rasmus

1 0

[U-Boot] [PATCH] ata: ahci allow 64-bit DMA for SATA
by Roman Kapl 28 Aug '19

28 Aug '19

Allow 64-bit DMA on AHCI. If not supported by the host controller, at least print a message and fail. Signed-off-by: Roman Kapl <rka(a)sysgo.com> --- drivers/ata/ahci.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 9a08575053..02007ad4bd 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -503,9 +503,15 @@ static int ahci_fill_sg(struct ahci_uc_priv *uc_priv, u8 port, } for (i = 0; i < sg_count; i++) { - ahci_sg->addr = - cpu_to_le32((unsigned long) buf + i * MAX_DATA_BYTE_COUNT); - ahci_sg->addr_hi = 0; + /* We assume virt=phys */ + phys_addr_t pa = (unsigned long)buf + i * MAX_DATA_BYTE_COUNT; + + ahci_sg->addr = cpu_to_le32(pa & U32_MAX); + ahci_sg->addr_hi = cpu_to_le32((pa >> 32) & U32_MAX); + if (ahci_sg->addr_hi && !(uc_priv->cap & AHCI_CAP_S64A)) { + printf("Error: DMA address too high\n"); + return -1; + } ahci_sg->flags_size = cpu_to_le32(0x3fffff & (buf_len < MAX_DATA_BYTE_COUNT ? (buf_len - 1) -- 2.22.0

1 0

[U-Boot] [PATCH 0/6] Remove no use clk_enable() for rockchip platform
by Kever Yang 28 Aug '19

28 Aug '19

There are some clk_enable() callback add to rockchip clock drivers but with out any real operation driver code, it's waste of CPU cycles at runtime and waste of code size. The callback are add because some peripheral REQUIRE it, eg. ehci/ohci generic driver, and other driver also need it if the ops exist, eg. dwc3 driver and designware net driver. After update ehci&ohci driver to not always need clk_enable ops in vendor driver, we can remove all relate no use code in rockchip clock drivers. Kever Yang (6): usb: ehci-generic: don't probe fail if there is no clk_enable() ops usb: ohci-generic: don't probe fail if there is no clk_enable() ops rockchip: clk: rk3288: remove clk_enable() rockchip: clk: rk3328: remove clk_enable() rockchip: clk: rk3368: remove clk_enable() rockchip: clk: rk3399: remove clk_enable() drivers/clk/rockchip/clk_rk3288.c | 23 ------------------- drivers/clk/rockchip/clk_rk3328.c | 12 ---------- drivers/clk/rockchip/clk_rk3368.c | 19 ---------------- drivers/clk/rockchip/clk_rk3399.c | 37 ------------------------------- drivers/usb/host/ehci-generic.c | 2 +- drivers/usb/host/ohci-generic.c | 2 +- 6 files changed, 2 insertions(+), 93 deletions(-) -- 2.17.1

2 8

[U-Boot] [PATCH] board: amlogic: document alternative libretech-cc installation methods
by Daniel Drake 28 Aug '19

28 Aug '19

As already documented in this README, several binaries must be glued together in order to boot the device. Extend the documentation to cover the prebuilt binaries (saving you the hassle of installing ancient cross-compilers), and also mention the open source replacements for the encryption tool (which is especially useful if you want to avoid requiring 32-bit x86 binaries in your build system). Signed-off-by: Daniel Drake <drake(a)endlessm.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> --- board/amlogic/p212/README.libretech-cc | 41 +++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/board/amlogic/p212/README.libretech-cc b/board/amlogic/p212/README.libretech-cc index d007f58764..6af7de3cfa 100644 --- a/board/amlogic/p212/README.libretech-cc +++ b/board/amlogic/p212/README.libretech-cc @@ -38,9 +38,28 @@ U-Boot compilation Image creation ============== -Amlogic doesn't provide sources for the firmware and for tools needed -to create the bootloader image, so it is necessary to obtain them from -the git tree published by the board vendor: +To boot the system, u-boot must be combined with several earlier stage +bootloaders: + +* bl2.bin: vendor-provided binary blob +* bl21.bin: built from vendor u-boot source +* bl30.bin: vendor-provided binary blob +* bl301.bin: built from vendor u-boot source +* bl31.bin: vendor-provided binary blob +* acs.bin: built from vendor u-boot source + +These binaries and the tools required below have been collected and prebuilt +for convenience at <https://github.com/BayLibre/u-boot/releases/> + +Download and extract the libretech-cc release from there, and set FIPDIR to +point to the `fip` subdirectory. + + > export FIPDIR=/path/to/extracted/fip + +Alternatively, you can obtain the original vendor u-boot tree which +contains the required blobs and sources, and build yourself. +Note that old compilers are required for this to build. The compilers here +are suggested by Amlogic, and they are 32-bit x86 binaries. > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc… > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc… @@ -53,7 +72,10 @@ the git tree published by the board vendor: > make > export FIPDIR=$PWD/fip -Go back to mainline U-Boot source tree then : +Once you have the binaries available (either through the prebuilt download, +or having built the vendor u-boot yourself), you can then proceed to glue +everything together. Go back to mainline U-Boot source tree then : + > mkdir fip > cp $FIPDIR/gxl/bl2.bin fip/ @@ -100,3 +122,14 @@ and then write the image to SD with: > DEV=/dev/your_sd_device > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1 > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444 + +Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no +source code. Should you prefer to avoid that, there are open source reverse +engineered versions available: + +1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy + Makefile that automates the whole process. +2. meson-tools <https://github.com/afaerber/meson-tools> + +However, these community-developed alternatives are not endorsed by or +supported by Amlogic. -- 2.20.1

4 5

[U-Boot] [PATCH] clk: meson-g12b: add compatible
by Mark Kettenis 28 Aug '19

28 Aug '19

The G12B clock controller is almost identical to the G12A and so far the differences don't matter. Adding the G12B compatible makes USB work on the Odroid-N2. Signed-off-by: Mark Kettenis <kettenis(a)openbsd.org> --- drivers/clk/meson/g12a.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c index 112326e553..43dac1aa37 100644 --- a/drivers/clk/meson/g12a.c +++ b/drivers/clk/meson/g12a.c @@ -405,6 +405,7 @@ static struct clk_ops meson_clk_ops = { static const struct udevice_id meson_clk_ids[] = { { .compatible = "amlogic,g12a-clkc" }, + { .compatible = "amlogic,g12b-clkc" }, { } }; -- 2.22.0

2 1

[U-Boot] [U-BOOT PATCH 0/3] add support for spi-nor device on HiFive Unleashed board
by Sagar Shrikant Kadam 28 Aug '19

28 Aug '19

This patch series adds support for 32MiB SPI-NOR flash (is25wp256 from ISSI). Many thanks to Bhargav Shah <bhargavshah1988(a)gmail.com> for porting the spi-nor patches from linux to U-boot in order to support this device. Ref: linux patches which are under review https://lkml.org/lkml/2019/7/2/859 Linux has an option of registering post-bfpt fixups in order to over-ride the incorrect configuration of flash devices due to wrong SFDP entries read from the flash device during nor scan phase. The 1st patch introduces this support to register post bfpt fixup hook similar to that done in linux. The second patch in the series enables support for the flash device in single I/O mode. A post bfpt fixup is registered because the flash device gets BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for address width, whereas the flash can support 4 byte address width. The SPI_NOR_HAS_BP3 bit indicates that the flash protection block has BP0 to BP3 bits. Lock/Unlock mechanism: The implementation is based on stm_lock/unlock scheme and is validated for different number of blocks passed to sf command. Unlock scheme unilateraly clears all the protection bits of all blocks in the status register. The series is based on the master branch of[1] [1] https://gitlab.denx.de/u-boot/custodians/u-boot-riscv and is available in dev/sagark/hifive-spi-nor_v2 branch of[2] [2] https://github.com/sagsifive/u-boot. Flash operations like erase/read/write lock/unlock are verified and data integrity is checked using sf commands as follows: => sf write 0x80600000 0x0 0x2000000 device 0 whole chip SF: 33554432 bytes @ 0x0 Written: OK => sf read 0x82700000 0x0 0x2000000 device 0 whole chip SF: 33554432 bytes @ 0x0 Read: OK => cmp.b 0x80600000 0x82700000 0x2000000 Total of 33554432 byte(s) were the same => sf protect lock 0x1000000 0x1000000 => mw 0x80600000 0x12345678 0x2000000 => sf write 0x80600000 0x0 0x2000000 Reset the board to flush out data from memory => sf probe => sf read 0x80600000 0x0 0x2000000 In memory dump after sf read from address 0x80600000 we can see that upper 16MiB flash section is protected. Sagar Shrikant Kadam (3): spi: nor: add spi-nor-fixup handlers for nor devices spi: nor: add support for is25wp256 spi: riscv: use single bit mode for spi transfers board/sifive/fu540/Kconfig | 5 + drivers/mtd/spi/sf_internal.h | 23 +++ drivers/mtd/spi/spi-nor-core.c | 373 +++++++++++++++++++++++++++++++++++------ drivers/mtd/spi/spi-nor-ids.c | 5 + drivers/spi/spi-sifive.c | 7 +- include/linux/mtd/spi-nor.h | 8 + 6 files changed, 363 insertions(+), 58 deletions(-) -- 2.7.4

3 9