December 2019 - U-Boot

[PATCH 1/1] efi_loader: clear screen should move cursor to home
by Heinrich Schuchardt 22 Dec '19

22 Dec '19

On a VT100 terminal <ESC>[2J should be enough to both clear the whole screen and set the cursor to position (1, 1). But the Linux console does not behave like this. So send an extra <ESC>[H. For reference see the console_codes(4) man page. Add a function description. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_console.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index 218f7caa12..8494044799 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -360,12 +360,26 @@ static efi_status_t EFIAPI efi_cout_set_attribute( return EFI_EXIT(EFI_SUCCESS); } +/** + * efi_cout_clear_screen() - clear screen + * + * This function implements the ClearScreen service of the + * EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. See the Unified Extensible Firmware + * Interface (UEFI) specification for details. + * + * @this: pointer to the protocol instance + * Return: status code + */ static efi_status_t EFIAPI efi_cout_clear_screen( struct efi_simple_text_output_protocol *this) { EFI_ENTRY("%p", this); - printf(ESC"[2J"); + /* + * The Linux console wants both a clear and a home command. The video + * uclass does not support <ESC>[H without coordinates, yet. + */ + printf(ESC "[2J" ESC "[1;1H"); efi_con_mode.cursor_column = 0; efi_con_mode.cursor_row = 0; -- 2.20.1

1 0

[U-Boot] [PATCH 0/4] Odroid n2 using eMMC would fail to boot up
by Anand Moon 21 Dec '19

21 Dec '19

Here are some small changes to fix booting of Odroid N2 Tested on below eMMC module new orange - eMMC AJNB4R 14.6 GiB MMC 5.1 old back - eMMC CGND3R 58.2 GiB MMC 5.0 -Anand Anand Moon (4): mmc: meson-gx: Fix tx phase in the tuning process configs: meson64: enable GIC support for G12A/G12B board: amlogic: select PWRSEQ for all amlogic platform board: amlogic: Add missing config option arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 ++ configs/odroid-c2_defconfig | 2 ++ drivers/mmc/meson_gx_mmc.c | 2 +- include/configs/meson64.h | 2 +- 5 files changed, 7 insertions(+), 2 deletions(-) -- 2.24.0

3 16

Sunxi (pine64-lts) SPL load BL32
by adam parker 21 Dec '19

21 Dec '19

I am attempting to boot the Pine64-lts with a Trusted OS. In the ARM-TF documentation it states "make sure the loader (SPL) loads the Trusted OS binary to the beginning of DRAM (0x40000000)." I have yet to find a mechanism by which U-Boot's SPL for this platform can be configured to do this. Any help would be appreciated. Thanks, Adam

3 2

[PATCH] drivers: net: bcm-sf2: pass -1 to phy_connect()
by Alex Marginean 20 Dec '19

20 Dec '19

Passing 0 to PHY connect used to trigger a MDIO scan due to a bug fixed in the meantime. It's unclear if bcm-sf2 wants to connect to PHY @ addr 0 or is scanning the bus, passing -1 here should keep it functional either way. Signed-off-by: Alex Marginean <alexandru.marginean(a)nxp.com> Cc: Jiandong Zheng <jdzheng(a)broadcom.com> --- drivers/net/bcm-sf2-eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bcm-sf2-eth.c b/drivers/net/bcm-sf2-eth.c index 615037f1a3..11f937032f 100644 --- a/drivers/net/bcm-sf2-eth.c +++ b/drivers/net/bcm-sf2-eth.c @@ -50,7 +50,7 @@ static int bcm_sf2_eth_init(struct eth_device *dev) eth->port_num = 0; debug("Connecting PHY 0...\n"); phydev = phy_connect(miiphy_get_dev_by_name(dev->name), - 0, dev, eth->phy_interface); + -1, dev, eth->phy_interface); if (phydev != NULL) { eth->port[0] = phydev; eth->port_num += 1; -- 2.17.1

3 2

[PATCH 0/5] arm64: meson: add libretech-pc support
by Jerome Brunet 20 Dec '19

20 Dec '19

Add libretech PC platform support. This platform comes in 2 variants, one with the s905d and the other s912. The corresponding DT have been applied and should be merged during the next merge window [0] While working on these boards, I've found a problem related the mmc clock. In some cases, the ROM code will leave the mmc clocks in such a weird state that any access to the mmc controller would lock the device. Making sure the MMC clocks are properly reset and enabled is enough to solve the problem. [0]: https://lkml.kernel.org/r/7h5zig82ha.fsf@baylibre.com Jerome Brunet (5): dt-bindings: leds: import common led bindings from linux v5.4 mmc: meson-gx: enable input clocks clk: meson: reset mmc clock on probe arm64: dts: meson: gxl: add i2c C pins arm64: dts: meson: add libretech-pc support arch/arm/dts/Makefile | 2 + arch/arm/dts/meson-gx-libretech-pc.dtsi | 376 ++++++++++++++++++ .../meson-gxl-s905d-libretech-pc-u-boot.dtsi | 7 + arch/arm/dts/meson-gxl-s905d-libretech-pc.dts | 17 + arch/arm/dts/meson-gxl-s905d.dtsi | 12 + arch/arm/dts/meson-gxl.dtsi | 44 +- .../meson-gxm-s912-libretech-pc-u-boot.dtsi | 7 + arch/arm/dts/meson-gxm-s912-libretech-pc.dts | 62 +++ configs/libretech-s905d-pc_defconfig | 73 ++++ configs/libretech-s912-pc_defconfig | 73 ++++ drivers/clk/meson/axg.c | 7 + drivers/clk/meson/g12a.c | 7 + drivers/clk/meson/gxbb.c | 7 + drivers/mmc/meson_gx_mmc.c | 14 +- include/dt-bindings/leds/common.h | 75 ++++ 15 files changed, 772 insertions(+), 11 deletions(-) create mode 100644 arch/arm/dts/meson-gx-libretech-pc.dtsi create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts create mode 100644 arch/arm/dts/meson-gxl-s905d.dtsi create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc.dts create mode 100644 configs/libretech-s905d-pc_defconfig create mode 100644 configs/libretech-s912-pc_defconfig create mode 100644 include/dt-bindings/leds/common.h -- 2.23.0

4 13

[PATCH v2] serdes: ls1046afwry: Disable sgmi support
by Pramod Kumar 20 Dec '19

20 Dec '19

LS1046A SoC serdes protocol 0x3040 supports both sgmi and qsgmii, however frwy-ls1046a supports only QSGMI on board. Disable unsupported sgmii on bord. Signed-off-by: Pramod Kumar <pramod.kumar_1(a)nxp.com> --- Changes in v2: - incorporated review comments board/freescale/ls1046afrwy/eth.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/freescale/ls1046afrwy/eth.c b/board/freescale/ls1046afrwy/eth.c index 9f8bd92..d38e4d7 100644 --- a/board/freescale/ls1046afrwy/eth.c +++ b/board/freescale/ls1046afrwy/eth.c @@ -53,6 +53,8 @@ int board_eth_init(bd_t *bis) fm_info_set_mdio(FM1_DTSEC10, dev); fm_info_set_mdio(FM1_DTSEC1, dev); + fm_disable_port(FM1_DTSEC9); + cpu_eth_init(bis); #endif -- 2.7.4

1 0

[PATCH 0/1] Small patch series to add support for VoCore2 board.
by MCon 20 Dec '19

20 Dec '19

Details about this SoM can be found at "https://vocore.io/v2.html". This port is working for me and able to boot Linux v5.0. Some subsystems (notably SD) are not working due to shortcomings of current drivers (e.g.: mtk_sd.c); they work in the booted Linux. NOTE: This is my first attempt to use patman; any hint welcome. MCon (1): Port to new board "VoCore2" arch/mips/dts/Makefile | 6 ++-- arch/mips/dts/vocore2.dts | 62 +++++++++++++++++++++++++++++++++++ arch/mips/mach-mtmips/Kconfig | 9 +++++ board/vonger/vocore2/Kconfig | 11 +++++++ board/vonger/vocore2/Makefile | 2 ++ board/vonger/vocore2/board.c | 35 ++++++++++++++++++++ configs/vocore2_defconfig | 61 ++++++++++++++++++++++++++++++++++ include/configs/vocore2.h | 57 ++++++++++++++++++++++++++++++++ 8 files changed, 240 insertions(+), 3 deletions(-) create mode 100644 arch/mips/dts/vocore2.dts create mode 100644 board/vonger/vocore2/Kconfig create mode 100644 board/vonger/vocore2/Makefile create mode 100644 board/vonger/vocore2/board.c create mode 100644 configs/vocore2_defconfig create mode 100644 include/configs/vocore2.h -- 2.24.0

4 5

[PATCH] dm: uclass: don't assign aliased seq numbers
by Michael Walle 19 Dec '19

19 Dec '19

If there are aliases for an uclass, set the base for the "dynamically" allocated numbers next to the highest alias. Please note, that this might lead to holes in the sequences, depending on the device tree. For example if there is only an alias "ethernet1", the next device seq number would be 2. In particular this fixes a problem with boards which are using ethernet aliases but also might have network add-in cards like the E1000. If the board is started with the add-in card and depending on the order of the drivers, the E1000 might occupy the first ethernet device and mess up all the hardware addresses, because the devices are now shifted by one. As a side effect, this should also make the following commits superfluous: - 7f3289bf6d ("dm: device: Request next sequence number") - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()") Although I don't understand the root cause of the said problem. Thomas, Michal, could you please test this and then I'd add a second patch removing the old code. Cc: Thomas Fitzsimmons <fitzsim(a)fitzsim.org> Cc: Michal Simek <michal.simek(a)xilinx.com> Signed-off-by: Michael Walle <michael(a)walle.cc> --- drivers/core/uclass.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index c520ef113a..c3b325141a 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -675,13 +675,14 @@ int uclass_unbind_device(struct udevice *dev) int uclass_resolve_seq(struct udevice *dev) { + struct uclass *uc = dev->uclass; + struct uclass_driver *uc_drv = uc->uc_drv; struct udevice *dup; - int seq; + int seq = 0; int ret; assert(dev->seq == -1); - ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, dev->req_seq, - false, &dup); + ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false, &dup); if (!ret) { dm_warn("Device '%s': seq %d is in use by '%s'\n", dev->name, dev->req_seq, dup->name); @@ -693,9 +694,16 @@ int uclass_resolve_seq(struct udevice *dev) return ret; } - for (seq = 0; seq < DM_MAX_SEQ; seq++) { - ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq, - false, &dup); + if (CONFIG_IS_ENABLED(DM_SEQ_ALIAS) && + (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) { + /* dev_read_alias_highest_id() will return -1 if there no + * alias. Thus we can always add one. + */ + seq = dev_read_alias_highest_id(uc_drv->name) + 1; + } + + for (; seq < DM_MAX_SEQ; seq++) { + ret = uclass_find_device_by_seq(uc_drv->id, seq, false, &dup); if (ret == -ENODEV) break; if (ret) -- 2.20.1

3 4

[PATCH] riscv: Fix breakage caused by linker relaxation
by Sean Anderson 19 Dec '19

19 Dec '19

Due to the two-instruction sequence needed to access arbitrary memory locations, the RISC-V linker aggressively optimises memory accesses and jumps at link-time. This is called "linker relaxation," and is discussed in this SiFive article <https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-to…>. One of the optimizations in place is to assume that the __global_pointer symbol is placed in the gp register. To quote the article: "...The magic __global_pointer$ symbol is defined to point 0x800 bytes past the start of the .sdata section. The 0x800 magic number allows signed 12-bit offsets from __global_pointer$ to address symbols at the start of the .sdata section. The linker assumes that if this symbol is defined, then the gp register contains that value, which it can then use to relax accesses to global symbols within that 12-bit range. The compiler treats the gp register as a constant so it doesn't need to be saved or restored, which means it is generally only written by _start, the ELF entry point." However, U-Boot instead keeps the global data pointer in gp. This causes memory accesses and jumps optimized to use the gp pointer to fail. To fix this problem, we undefine the __global_pointer symbol. Signed-off-by: Sean Anderson <seanga2(a)gmail.com> --- arch/riscv/cpu/u-boot.lds | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds index 838a844399..c00d17c736 100644 --- a/arch/riscv/cpu/u-boot.lds +++ b/arch/riscv/cpu/u-boot.lds @@ -32,7 +32,6 @@ SECTIONS . = ALIGN(4); .data : { - __global_pointer$ = . + 0x800; *(.data*) } . = ALIGN(4); -- 2.23.0

2 2

[PATCH 0/2] Extend board_fdt_blob_setup() to support OF_SEPARATE
by Michal Simek 19 Dec '19

19 Dec '19

Hi, it is simply series which align board_fdt_blob_setup() with fdtdec with highest priority on default location where external DTB can be found. Thanks, Michal Michal Simek (2): arm64: zynqmp: Rename fw_dtb variable to fdt_blob arm64: zynqmp: Add support for OF_SEPARATE with board DTB board/xilinx/Kconfig | 2 +- board/xilinx/common/board.c | 31 ++++++++++++++++++++++++------- 2 files changed, 25 insertions(+), 8 deletions(-) -- 2.24.0

1 2