January 2019 - U-Boot

[U-Boot] [PATCH 0/7] TF-A Boot support for NXP Chassis 3 platforms
by Rajesh Bhagat 18 Jan '19

18 Jan '19

Includes changes in u-boot framework to support TF-A for NXP Chassis 3 platforms. A new defconfig is added namely ls*_tfa_defconfig which will be used for all boot sources when TF-A is used. Also, provide fixes for TF-A Boot NXP Chassis 2 platforms. Pankit Garg (3): ls1043a: add support for nand-boot cmd for TFA armv8: ls1088ardb: Add TFABOOT support armv8: ls1088aqds: Add TFABOOT support Rajesh Bhagat (4): armv8: fsl-layerscape: fixes for TFABOOT framework drivers: ifc: restore the legacy flow for IFC config armv8: ls2088ardb: Add TFABOOT support armv8: ls2088aqds: Add TFABOOT support arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 26 +-- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +- arch/arm/cpu/armv8/fsl-layerscape/soc.c | 13 +- arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 4 + board/freescale/ls1088a/MAINTAINERS | 4 + board/freescale/ls1088a/ddr.c | 11 ++ board/freescale/ls1088a/ls1088a.c | 193 +++++++++++++++++++ board/freescale/ls2080a/ls2080a.c | 7 + board/freescale/ls2080aqds/MAINTAINERS | 2 + board/freescale/ls2080aqds/ddr.c | 12 ++ board/freescale/ls2080ardb/MAINTAINERS | 2 + board/freescale/ls2080ardb/ddr.c | 12 ++ board/freescale/ls2080ardb/ls2080ardb.c | 37 ++++ configs/ls1088aqds_tfa_defconfig | 69 +++++++ configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 64 ++++++ configs/ls1088ardb_tfa_defconfig | 61 ++++++ configs/ls2088aqds_tfa_defconfig | 63 ++++++ configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 74 +++++++ configs/ls2088ardb_tfa_defconfig | 72 +++++++ drivers/misc/fsl_ifc.c | 173 +++++++++++++++++ include/configs/ls1043a_common.h | 2 + include/configs/ls1088a_common.h | 11 +- include/configs/ls1088aqds.h | 99 +++++++++- include/configs/ls1088ardb.h | 137 ++++++++++++- include/configs/ls2080a_common.h | 8 + include/configs/ls2080aqds.h | 40 +++- include/configs/ls2080ardb.h | 137 ++++++++++++- 27 files changed, 1310 insertions(+), 25 deletions(-) create mode 100644 configs/ls1088aqds_tfa_defconfig create mode 100644 configs/ls1088ardb_tfa_SECURE_BOOT_defconfig create mode 100644 configs/ls1088ardb_tfa_defconfig create mode 100644 configs/ls2088aqds_tfa_defconfig create mode 100644 configs/ls2088ardb_tfa_SECURE_BOOT_defconfig create mode 100644 configs/ls2088ardb_tfa_defconfig -- 2.17.1

2 10

[U-Boot] [PATCH 1/1] efi_loader: remove duplicate function mem2hex()
by Heinrich Schuchardt 18 Jan '19

18 Jan '19

Replace duplicate function mem2hex() by inline function bin2hex(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_variable.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c index eea7f68b85..2ac27731fe 100644 --- a/lib/efi_loader/efi_variable.c +++ b/lib/efi_loader/efi_variable.c @@ -47,19 +47,6 @@ #define PREFIX_LEN (strlen("efi_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_")) -static char *mem2hex(char *hexstr, const u8 *mem, int count) -{ - static const char hexchars[] = "0123456789abcdef"; - - while (count-- > 0) { - u8 ch = *mem++; - *hexstr++ = hexchars[ch >> 4]; - *hexstr++ = hexchars[ch & 0xf]; - } - - return hexstr; -} - static efi_status_t efi_to_native(char **native, const u16 *variable_name, const efi_guid_t *vendor) { @@ -282,7 +269,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name, /* store payload: */ s += sprintf(s, "(blob)"); - s = mem2hex(s, data, data_size); + s = bin2hex(s, data, data_size); *s = '\0'; debug("%s: setting: %s=%s\n", __func__, native_name, val); -- 2.20.1

1 0

[U-Boot] Porting u-boot to flash micro with proprietary (non-GPL) flash programming library
by Ulf Samuelsson 18 Jan '19

18 Jan '19

I am working in a project where we are considering using U-Boot as a bootloader for a flash microcontroller with an ARM Cortex-Rx core. The chip is currently not supported by U-Boot. The processor will not be running linux. Our board will use • On Chip Flash • External Parallel Flash • External SPI Flash Problem: To program the internal flash, we need to use the a library from the CPU vendor which is only supplied to us in binary form. Their license forbids us to link that library to open source code in a way that “contaminates” their code with GPL. GPL forbids code to be linked with non-GPL code. There are a few common exceptions to GPL when running linux. 1. Linking with a shared library is OK. 2. Using a device driver which was originally written for another OS. (I think this has been primarily used for graphics drivers) Right now, our idea is to do runtime linking to the flash programming library similar to a shared library. For various reasons, we plan to have our own first level bootloader which has very simple functionality, and this will be contain the vendor flash programming library. U-boot, can when started, query the first level bootloader for the location of the entry points in the library and use the result to fill in a struct containing the address of the entry points. As far as I understand, this will not be static linking, so this should be allowed in GPL. Q: Is this a reasonable approach to the problem? Even if acceptable, there may be several ways of implementing this. Here is what I can think of: ====================================================================== 1) CALLING THROUGH AN EXTERNAL CALL TABLE The first level bootloader has a call table containing the absolute addresses of the flash library entry points. The u-boot driver will declare the table external, and define the table in the linker command file. u-boot needs a header file describing the call table (probably implemented as a struct) ====================================================================== 2) COPYING A STRUCT FROM A KNOWN ADDRESS IN THE FIRST LEVEL BOOTLOADER The simplest way I can envision, is that the first level bootloader has a struct containing an field for each entrypoint. The field contains the absolute address of the entry point. The struct is copied into an u-boot datastructure as is. u-boot can call any entry by an indirect call. (*externallib.function1)(<parameters>); For this to work, u-boot needs to know the absolute address of the table inside the first level bootloader. Both u-boot and the first level bootloader will contain a definition of the struct in a header file. ====================================================================== 3) COPYING A STRUCT FROM AN UNKNOWN ADDRESS THROUGH A SUPERVISOR CALL. The first level bootloader will reside in flash at the reset address. It has a supervisor call exception vector. A specific supervisor call can return the address of the struct above. With this method, U-boot does not need to have internal knowledge of where the struct is located in the first level bootloader. It does need to have a header file describing the struct. ====================================================================== 4) CREATING A CALL TABLE BY QUERYING FOR EACH ENTRY. This assumes that u-boot should not have any knowledge of a struct. Instead a supervisor call is implemented which sends a parameter defining which entry point of interest. The supervisor call returns the absolute address of the entry point. ====================================================================== Q: Are any of the methods above violating the GPL license? ====================================================================== Q: Is there another method which is recommended to handle the problem with proprietary vendor flash libraries? ====================================================================== Q: If a processor contains functionality in a bootROM, for which source is not available. How can that be used in u-boot? -- Best Regards Ulf Samuelsson

1 1

[U-Boot] [PATCH v6.1 15/20] arm: sunxi: Enable CLK, RESET
by Jagan Teki 18 Jan '19

18 Jan '19

CLK and DM_RESET drivers are now available for all of the Allwinner platforms, so enable them in arch/arm/Kconfig Enabling CLK will select DM_RESET by default. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- Changes for v6.1: - Enable CLK at one place since all Allwinner SoC's supported arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d6b1629a00..a23cbd5719 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -846,6 +846,7 @@ config ARCH_SUNXI select CMD_GPIO select CMD_MMC if MMC select CMD_USB if DISTRO_DEFAULTS + select CLK select DM select DM_ETH select DM_GPIO -- 2.18.0.321.gffc6fa0e3

1 1

[U-Boot] [PATCH v6 00/20] clk: Add Allwinner CLK, RESET support
by Jagan Teki 18 Jan '19

18 Jan '19

This series fixes few comments from previous verision for Allwinner clock gates, resets and dropped clock tree patches which I have mentioned on previous series[1]. Changes for v6: - use ARRAY_SIZE for reset array instead of number - remove comment from sunxi_reset_request - Enable CONFIG_USB_OHCI_HCD on few missing boards - collect Marek Acked-by Any inputs, Jagan. [1] https://patchwork.ozlabs.org/cover/1019654/ Jagan Teki (20): clk: Add Allwinner A64 CLK driver reset: Add Allwinner RESET driver clk: sunxi: Add Allwinner H3/H5 CLK driver clk: sunxi: Add Allwinner A10/A20 CLK driver clk: sunxi: Add Allwinner A10s/A13 CLK driver clk: sunxi: Add Allwinner A31 CLK driver clk: sunxi: Add Allwinner A23/A33 CLK driver clk: sunxi: Add Allwinner A83T CLK driver clk: sunxi: Add Allwinner R40 CLK driver clk: sunxi: Add Allwinner V3S CLK driver clk: sunxi: Implement UART clocks clk: sunxi: Implement UART resets clk: sunxi: Add Allwinner H6 CLK driver sunxi: A64: Update sun50i-a64-ccu.h sunxi: Enable CLK phy: sun4i-usb: Use CLK and RESET support reset: Add reset valid musb-new: sunxi: Use CLK and RESET support sunxi: usb: Switch to Generic host controllers usb: host: Drop [e-o]hci-sunxi drivers arch/arm/include/asm/arch-sunxi/ccu.h | 96 ++++++++ arch/arm/mach-sunxi/Kconfig | 12 + configs/A10-OLinuXino-Lime_defconfig | 1 + configs/A10s-OLinuXino-M_defconfig | 1 + configs/A13-OLinuXinoM_defconfig | 1 + configs/A13-OLinuXino_defconfig | 1 + configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + configs/A20-OLinuXino-Lime2_defconfig | 1 + configs/A20-OLinuXino-Lime_defconfig | 1 + configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 + configs/A20-OLinuXino_MICRO_defconfig | 1 + configs/A20-Olimex-SOM-EVB_defconfig | 1 + configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 + configs/A20-Olimex-SOM204-EVB_defconfig | 1 + configs/Auxtek-T003_defconfig | 1 + configs/Auxtek-T004_defconfig | 1 + configs/Bananapi_defconfig | 1 + configs/Bananapi_m2m_defconfig | 1 + configs/Bananapro_defconfig | 1 + configs/CHIP_defconfig | 1 + configs/CHIP_pro_defconfig | 1 + configs/CSQ_CS908_defconfig | 1 + configs/Colombus_defconfig | 1 + configs/Cubieboard2_defconfig | 1 + configs/Cubieboard_defconfig | 1 + configs/Cubietruck_defconfig | 1 + configs/Cubietruck_plus_defconfig | 1 + configs/Hummingbird_A31_defconfig | 1 + configs/Itead_Ibox_A20_defconfig | 1 + configs/Lamobo_R1_defconfig | 1 + configs/Linksprite_pcDuino3_Nano_defconfig | 1 + configs/Linksprite_pcDuino3_defconfig | 1 + configs/Linksprite_pcDuino_defconfig | 1 + configs/MK808C_defconfig | 1 + configs/Marsboard_A10_defconfig | 1 + configs/Mele_A1000G_quad_defconfig | 1 + configs/Mele_A1000_defconfig | 1 + configs/Mele_I7_defconfig | 1 + configs/Mele_M3_defconfig | 1 + configs/Mele_M5_defconfig | 1 + configs/Mele_M9_defconfig | 1 + configs/Mini-X_defconfig | 1 + configs/Orangepi_defconfig | 1 + configs/Orangepi_mini_defconfig | 1 + configs/Sinlinx_SinA31s_defconfig | 1 + configs/Sinlinx_SinA33_defconfig | 1 + configs/Sinovoip_BPI_M2_Plus_defconfig | 1 + configs/Sinovoip_BPI_M2_defconfig | 1 + configs/Sinovoip_BPI_M3_defconfig | 1 + configs/Wexler_TAB7200_defconfig | 1 + configs/Wits_Pro_A20_DKT_defconfig | 1 + configs/Wobo_i5_defconfig | 1 + configs/a64-olinuxino_defconfig | 1 + configs/ba10_tv_box_defconfig | 1 + configs/bananapi_m1_plus_defconfig | 1 + configs/bananapi_m64_defconfig | 1 + configs/ga10h_v1_1_defconfig | 1 + configs/h8_homlet_v2_defconfig | 1 + configs/i12-tvbox_defconfig | 1 + configs/icnova-a20-swac_defconfig | 1 + configs/inet1_defconfig | 1 + configs/inet_q972_defconfig | 1 + configs/jesurun_q5_defconfig | 1 + configs/libretech_all_h3_cc_h2_plus_defconfig | 1 + configs/libretech_all_h3_cc_h3_defconfig | 1 + configs/libretech_all_h3_cc_h5_defconfig | 1 + configs/mixtile_loftq_defconfig | 1 + configs/mk802_a10s_defconfig | 1 + configs/mk802_defconfig | 1 + configs/mk802ii_defconfig | 1 + configs/nanopi_a64_defconfig | 1 + configs/nanopi_m1_defconfig | 1 + configs/nanopi_m1_plus_defconfig | 1 + configs/nanopi_neo2_defconfig | 1 + configs/nanopi_neo_air_defconfig | 1 + configs/nanopi_neo_defconfig | 1 + configs/nanopi_neo_plus2_defconfig | 1 + configs/orangepi_2_defconfig | 1 + configs/orangepi_lite_defconfig | 1 + configs/orangepi_one_defconfig | 1 + configs/orangepi_pc2_defconfig | 1 + configs/orangepi_pc_defconfig | 1 + configs/orangepi_pc_plus_defconfig | 1 + configs/orangepi_plus2e_defconfig | 1 + configs/orangepi_plus_defconfig | 1 + configs/orangepi_prime_defconfig | 1 + configs/orangepi_r1_defconfig | 1 + configs/orangepi_win_defconfig | 1 + configs/orangepi_zero_defconfig | 1 + configs/orangepi_zero_plus2_defconfig | 1 + configs/orangepi_zero_plus_defconfig | 1 + configs/parrot_r16_defconfig | 1 + configs/pine64_plus_defconfig | 1 + configs/pinebook_defconfig | 1 + configs/r7-tv-dongle_defconfig | 1 + configs/sopine_baseboard_defconfig | 1 + configs/sun8i_a23_evb_defconfig | 1 + configs/sunxi_Gemei_G9_defconfig | 1 + configs/tbs_a711_defconfig | 1 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/sunxi/Kconfig | 82 ++++++ drivers/clk/sunxi/Makefile | 18 ++ drivers/clk/sunxi/clk_a10.c | 68 +++++ drivers/clk/sunxi/clk_a10s.c | 61 +++++ drivers/clk/sunxi/clk_a23.c | 75 ++++++ drivers/clk/sunxi/clk_a31.c | 82 ++++++ drivers/clk/sunxi/clk_a64.c | 78 ++++++ drivers/clk/sunxi/clk_a83t.c | 75 ++++++ drivers/clk/sunxi/clk_h3.c | 89 +++++++ drivers/clk/sunxi/clk_h6.c | 53 ++++ drivers/clk/sunxi/clk_r40.c | 88 +++++++ drivers/clk/sunxi/clk_sunxi.c | 74 ++++++ drivers/clk/sunxi/clk_v3s.c | 59 +++++ drivers/phy/allwinner/phy-sun4i-usb.c | 77 ++++-- drivers/reset/Kconfig | 8 + drivers/reset/Makefile | 1 + drivers/reset/reset-sunxi.c | 124 ++++++++++ drivers/usb/host/Kconfig | 2 + drivers/usb/host/Makefile | 2 - drivers/usb/host/ehci-sunxi.c | 204 --------------- drivers/usb/host/ohci-sunxi.c | 233 ------------------ drivers/usb/musb-new/sunxi.c | 79 +++--- include/configs/sun4i.h | 4 - include/configs/sun50i.h | 5 - include/configs/sun5i.h | 4 - include/configs/sun6i.h | 4 - include/configs/sun7i.h | 4 - include/configs/sun8i.h | 4 - include/configs/sunxi-common.h | 1 - include/dt-bindings/clock/sun50i-a64-ccu.h | 2 + include/reset.h | 11 + scripts/config_whitelist.txt | 2 - 133 files changed, 1353 insertions(+), 527 deletions(-) create mode 100644 arch/arm/include/asm/arch-sunxi/ccu.h create mode 100644 drivers/clk/sunxi/Kconfig create mode 100644 drivers/clk/sunxi/Makefile create mode 100644 drivers/clk/sunxi/clk_a10.c create mode 100644 drivers/clk/sunxi/clk_a10s.c create mode 100644 drivers/clk/sunxi/clk_a23.c create mode 100644 drivers/clk/sunxi/clk_a31.c create mode 100644 drivers/clk/sunxi/clk_a64.c create mode 100644 drivers/clk/sunxi/clk_a83t.c create mode 100644 drivers/clk/sunxi/clk_h3.c create mode 100644 drivers/clk/sunxi/clk_h6.c create mode 100644 drivers/clk/sunxi/clk_r40.c create mode 100644 drivers/clk/sunxi/clk_sunxi.c create mode 100644 drivers/clk/sunxi/clk_v3s.c create mode 100644 drivers/reset/reset-sunxi.c delete mode 100644 drivers/usb/host/ehci-sunxi.c delete mode 100644 drivers/usb/host/ohci-sunxi.c -- 2.18.0.321.gffc6fa0e3

2 26

[U-Boot] am335x: EFI: tftp: CACHE: Misaligned operation at range [9ce7e470, 9ce7e4b0]
by Matwey V. Kornilov 18 Jan '19

18 Jan '19

Hello, I am running u-boot 2018.11 at BeagleBoneBlack with the following setup. I have EFI Grub image with tftp module enabled. This image is deployed by tftp and it is advertised by dhcp. When started Grub loads Linux kernel and initrd and boots OS. Such setup works fine with qemu-arm and OVMF (TianoCore EFI). Now, I am trying to use BeagleBoneBlack and do the following: => run findfdt => run loadfdt => print fdt_addr_r fdt_addr_r=0x88000000 => dhcp link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.185.197 (20 ms) Using cpsw device TFTP from server 192.168.185.80; our IP address is 192.168.185.197 Filename '/bootarm.efi'. Load address: 0x82000000 Loading: ############################### 4.1 MiB/s done Bytes transferred = 448512 (6d800 hex) => bootefi 0x82000000 0x88000000 Then I see Grub menu for a moment and the console is constantly flooding be the following messages with very high rate (dozens of lines per second): CACHE: Misaligned operation at range [9ce7e470, 9ce7e4b0] At the same time I see in tcpdump that there is ongoing exchange between tftp server and the board. After some time I see that the kernel is booting and CACHE messages disappear: bash-4.4# uname -a Linux 88cc78c5ecd6 5.0.0-rc1-default+ #1 SMP PREEMPT Tue Jan 15 19:23:17 MSK 2019 armv7l armv7l armv7l GNU/Linux The question is how to fix this CACHE messages or their reason?

1 0

[U-Boot] [PATCH 0/2] Board support updates for topic-miamiplus modules
by Mike Looijmans 18 Jan '19

18 Jan '19

Patches rebased for re-submission, were sent earlier as part of a longer series. This improves performance and functionality for the topic-miamiplus boards with Zynq 7035/7045/7100. Mike Looijmans (2): topic-miamiplus: Run CPU at 800MHz for speedgrade-2 board: topic-miamiplus: Run IO PLL at 1000 MHz arch/arm/dts/zynq-topic-miamiplus.dts | 9 ++++++ .../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 34 ++++++++++------------ 2 files changed, 25 insertions(+), 18 deletions(-) -- 1.9.1

2 3

[U-Boot] [RESEND] videomodes: Relax EDID validation checks for hsync/vsync pulse width
by Priit Laes 18 Jan '19

18 Jan '19

From: Priit Laes <priit.laes(a)paf.com> Current EDID detailed timing parser errors out when either horizontal or vertical pulse sync width is 0, thus not allowing a display with EDID listed below work properly. EDID below works ok within Linux although it warns about these two fields being 0. Therefore relax the checks a bit so we can actually use this the screen out of the box. Of-course, this display itself is somewhat quirky display with following anti-features: - HPD pin is not usable - although resolution is 640x480, only top 240 pixels are visible $ xxd -p display.edid 00ffffffffffff0005a1e00301000000150f0103800f05780a0f6ea05748 9a2610474f200000010101010101010101010101010101012a08804520e0 0b1020004000953600000018000000fd0034441a2403000a202020202020 0000001000310a20202020202020202020200000001000002a4030701300 782d1100001e006b $ edid-decode display.edid EDID version: 1.3 Manufacturer: AMA Model 3e0 Serial Number 1 Digital display Maximum image size: 15 cm x 5 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6250, 0.3398 Green: 0.2841, 0.6044 Blue: 0.1494, 0.0644 White: 0.2802, 0.3105 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz Standard timings supported: Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm 640 672 672 709 hborder 0 480 484 484 491 vborder 0 -hsync -vsync VertFreq: 60 Hz, HorFreq: 29478 Hz Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz Dummy block Dummy block Checksum: 0x6b (valid) Signed-off-by: Priit Laes <priit.laes(a)paf.com> Signed-off-by: Priit Laes <plaes(a)plaes.org> --- drivers/video/videomodes.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c index 74bafff011..1cfeaa980f 100644 --- a/drivers/video/videomodes.c +++ b/drivers/video/videomodes.c @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct edid_detailed_timing *t, EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || /* 3d formats are not supported*/ EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) return -EINVAL; -- 2.11.0

1 0

[U-Boot] [PULL] u-boot-mips
by Daniel Schwierzeck 18 Jan '19

18 Jan '19

Hi Tom, please pull updates for MIPS https://travis-ci.org/danielschwierzeck/u-boot/builds/480371326 The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff: Prepare v2019.01 (2019-01-14 17:02:36 -0500) are available in the Git repository at: git://git.denx.de/u-boot-mips.git tags/mips-pull-2019-11-16 for you to fetch changes up to 49f0b6bab919e6a9a509af841b43bbb49728dc45: mips: mt7688: gardena-smart-gateway: Enable green power LED on startup (2019-01-16 14:00:26 +0100) ---------------------------------------------------------------- - MIPS: mscc: various enhancements for Luton and Ocelot platforms - MIPS: mscc: added support for Jaguar2 platform - MIPS: optimised SPL linker script - MIPS: bcm6368: fix restart flow issues - MIPS: fixed CONFIG_OF_EMBED warnings for all MIPS boards - MIPS: mt7688: small fixes and enhancements - mmc: compile-out write support if disabled ---------------------------------------------------------------- Daniel Schwierzeck (7): MIPS: optimize and fix ELF sections MIPS: jz47xx: remove custom u-boot-spl.lds MIPS: boston: switch to CONFIG_OF_SEPARATE MIPS: malta: switch to CONFIG_OF_SEPARATE MIPS: pic32mzdask: switch to CONFIG_OF_SEPARATE MIPS: xilfpga: switch to CONFIG_OF_SEPARATE MIPS: bmips: switch to CONFIG_OF_SEPARATE Ezequiel Garcia (2): mmc: Use proper IS_ENABLED macro to check block support mmc: jz_mmc: Compile-out write support if disabled Horatiu Vultur (6): pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family MSCC: Add support for Jaguar2 SOC family MSCC: Add device tree for Jaguar2 board MSCC: Add device tree for Jaguar2-48 board MSCC: add device tree for Serval2 board MSCC: Add board support for Jaguar2 SOC family Lars Povlsen (13): mips: mscc: Add generic PHY MIIM utility functions mips: mscc: Add generic GPIO control utility function mips: luton: DT: Add pcb090 mips: mscc: luton+ocelot: Remove board config options, do probing mips: mscc_sgpio: Add the MSCC serial GPIO device (SIO) mips: mscc_sgpio: Add DT bindings documentation mips: luton: DT: Enable use of serial gpio mips: luton: Enable use of serial gpio for LED mips: ocelot: DT: Enable use of serial gpio mips: ocelot: Enable use of serial gpio for LED mips: spi: mscc: Add fast bitbang SPI driver mips: mscc: DT: Update luton device tree to use fast SPI driver mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c Stefan Roese (2): mips: mt7688: gardena-smart-gateway: Update mtdparts/mtdids for Kernel 4.19 mips: mt7688: gardena-smart-gateway: Enable green power LED on startup Álvaro Fernández Rojas (1): net: bcm6368: fix restart flow issues MAINTAINERS | 5 + arch/mips/cpu/u-boot-spl.lds | 100 ++++--- arch/mips/cpu/u-boot.lds | 104 ++++--- arch/mips/dts/Makefile | 3 + arch/mips/dts/gardena-smart-gateway-mt7688.dts | 2 +- arch/mips/dts/jr2_pcb110.dts | 74 +++++ arch/mips/dts/jr2_pcb111.dts | 74 +++++ arch/mips/dts/luton_pcb090.dts | 57 ++++ arch/mips/dts/luton_pcb091.dts | 27 ++ arch/mips/dts/mscc,jr2.dtsi | 187 ++++++++++++ arch/mips/dts/mscc,luton.dtsi | 29 +- arch/mips/dts/mscc,ocelot.dtsi | 23 ++ arch/mips/dts/ocelot_pcb120.dts | 76 +++++ arch/mips/dts/ocelot_pcb123.dts | 25 ++ arch/mips/dts/serval2_pcb112.dts | 60 ++++ arch/mips/mach-jz47xx/jz4780/u-boot-spl.lds | 50 ---- arch/mips/mach-mscc/Kconfig | 45 ++- arch/mips/mach-mscc/Makefile | 5 +- arch/mips/mach-mscc/cpu.c | 7 + arch/mips/mach-mscc/dram.c | 2 +- arch/mips/mach-mscc/gpio.c | 33 +++ arch/mips/mach-mscc/include/mach/common.h | 65 +++++ arch/mips/mach-mscc/include/mach/ddr.h | 38 ++- arch/mips/mach-mscc/include/mach/jr2/jr2.h | 24 ++ .../mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h | 20 ++ .../include/mach/jr2/jr2_devcpu_gcb_miim_regs.h | 25 ++ .../mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h | 321 ++++++++++++++++++++ .../include/mach/luton/luton_devcpu_gcb.h | 4 + .../mach/luton/luton_devcpu_gcb_miim_regs.h | 26 ++ .../include/mach/ocelot/ocelot_devcpu_gcb.h | 2 + .../mach/ocelot/ocelot_devcpu_gcb_miim_regs.h | 25 ++ arch/mips/mach-mscc/phy.c | 73 +++++ arch/mips/mach-mscc/reset.c | 17 ++ board/mscc/common/Makefile | 4 + board/mscc/common/spi.c | 31 ++ board/mscc/jr2/Kconfig | 15 + board/mscc/jr2/Makefile | 4 + board/mscc/jr2/jr2.c | 115 ++++++++ board/mscc/luton/luton.c | 52 +++- board/mscc/ocelot/ocelot.c | 76 +++-- configs/bcm968380gerg_ram_defconfig | 1 - configs/boston32r2_defconfig | 1 - configs/boston32r2el_defconfig | 1 - configs/boston32r6_defconfig | 1 - configs/boston32r6el_defconfig | 1 - configs/boston64r2_defconfig | 1 - configs/boston64r2el_defconfig | 1 - configs/boston64r6_defconfig | 1 - configs/boston64r6el_defconfig | 1 - configs/ci20_mmc_defconfig | 1 - configs/comtrend_ar5315u_ram_defconfig | 1 - configs/comtrend_ar5387un_ram_defconfig | 1 - configs/comtrend_ct5361_ram_defconfig | 1 - configs/comtrend_vr3032u_ram_defconfig | 1 - configs/comtrend_wap5813n_ram_defconfig | 1 - configs/gardena-smart-gateway-mt7688-ram_defconfig | 4 +- configs/gardena-smart-gateway-mt7688_defconfig | 4 +- configs/huawei_hg556a_ram_defconfig | 1 - configs/imgtec_xilfpga_defconfig | 1 - configs/malta64_defconfig | 1 - configs/malta64el_defconfig | 1 - configs/malta_defconfig | 1 - configs/maltael_defconfig | 1 - ..._ocelot_pcb120_defconfig => mscc_jr2_defconfig} | 25 +- configs/mscc_luton_defconfig | 13 +- configs/mscc_ocelot_defconfig | 10 +- configs/netgear_cg3100d_ram_defconfig | 1 - configs/netgear_dgnd3700v2_ram_defconfig | 1 - configs/pic32mzdask_defconfig | 1 - configs/sagem_f@st1704_ram_defconfig | 1 - configs/sfr_nb4-ser_ram_defconfig | 1 - doc/device-tree-bindings/gpio/mscc_sgpio.txt | 45 +++ drivers/gpio/Kconfig | 12 +- drivers/gpio/Makefile | 2 +- drivers/gpio/gpio-mscc-bitbang-spi.c | 122 -------- drivers/gpio/mscc_sgpio.c | 275 ++++++++++++++++++ drivers/mmc/jz_mmc.c | 105 ++++--- drivers/mmc/mmc_write.c | 8 +- drivers/net/bcm6368-eth.c | 109 ++++--- drivers/pinctrl/mscc/Kconfig | 9 + drivers/pinctrl/mscc/Makefile | 1 + drivers/pinctrl/mscc/mscc-common.c | 90 ++++-- drivers/pinctrl/mscc/mscc-common.h | 17 +- drivers/pinctrl/mscc/pinctrl-jr2.c | 323 +++++++++++++++++++++ drivers/pinctrl/mscc/pinctrl-luton.c | 16 +- drivers/pinctrl/mscc/pinctrl-ocelot.c | 16 +- drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/mscc_bb_spi.c | 236 +++++++++++++++ include/configs/vcoreiii.h | 2 + 90 files changed, 2907 insertions(+), 496 deletions(-) create mode 100644 arch/mips/dts/jr2_pcb110.dts create mode 100644 arch/mips/dts/jr2_pcb111.dts create mode 100644 arch/mips/dts/luton_pcb090.dts create mode 100644 arch/mips/dts/mscc,jr2.dtsi create mode 100644 arch/mips/dts/serval2_pcb112.dts delete mode 100644 arch/mips/mach-jz47xx/jz4780/u-boot-spl.lds create mode 100644 arch/mips/mach-mscc/gpio.c create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb_miim_regs.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_devcpu_gcb_miim_regs.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_devcpu_gcb_miim_regs.h create mode 100644 arch/mips/mach-mscc/phy.c create mode 100644 board/mscc/common/Makefile create mode 100644 board/mscc/common/spi.c create mode 100644 board/mscc/jr2/Kconfig create mode 100644 board/mscc/jr2/Makefile create mode 100644 board/mscc/jr2/jr2.c rename configs/{mscc_ocelot_pcb120_defconfig => mscc_jr2_defconfig} (73%) create mode 100644 doc/device-tree-bindings/gpio/mscc_sgpio.txt delete mode 100644 drivers/gpio/gpio-mscc-bitbang-spi.c create mode 100644 drivers/gpio/mscc_sgpio.c create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c create mode 100644 drivers/spi/mscc_bb_spi.c

2 1

[U-Boot] Problems to boot i.MX8QXP EVK board
by Breno Matheus Lima 18 Jan '19

18 Jan '19

Hi Peng, I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board by following README file (board/freescale/imx8qxp_mek/README). After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to true") everything seems to be working fine. Do you happen to know if the procedure in README file should be enough for v2019.01? Thanks, Breno Lima

3 11