October 2018 - U-Boot

[U-Boot] [PATCH 0/1] board: arm: Add support for Broadcom BCM7445D0
by Thomas Fitzsimmons 28 Sep '19

28 Sep '19

Hi, This patch adds support for loading U-Boot on the Broadcom 7445D0 SoC, as a third stage bootloader loaded by Broadcom's BOLT bootloader. While this is only a partial port, it does enable some of U-Boot's flexibility on this SoC, functionality beyond what BOLT provides. Specifically, it brings: - ext4 file system traversal - support for loading FIT images - advanced scripting - support for FIT-provided DTBs instead of relying on the BOLT-provided DTB My team at Cisco is using a customized version of this port in production. The same approach may work on other BCM7xxx boards, with some configuration adjustments and memory layout experimentation. Stefan Roese reviewed (off-list) some early revisions of these changes. This patch is my attempt to rebase on the current U-Boot master branch. I'm submitting it in case there is interest in including this port in upstream U-Boot. Thomas Thomas Fitzsimmons (1): board: arm: Add support for Broadcom BCM7445D0 arch/arm/Kconfig | 12 + arch/arm/cpu/armv7/Makefile | 1 + arch/arm/cpu/armv7/bcm7445d0/Makefile | 11 + arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S | 24 ++ arch/arm/lib/crt0.S | 2 + arch/arm/mach-bcm7445d0/include/mach/gpio.h | 12 + arch/arm/mach-bcm7445d0/include/mach/hardware.h | 12 + arch/arm/mach-bcm7445d0/include/mach/sdhci.h | 15 + board/broadcom/bcm7445d0/Kconfig | 132 ++++++++ board/broadcom/bcm7445d0/Makefile | 11 + board/broadcom/bcm7445d0/bcm7445d0.c | 147 ++++++++ common/fdt_support.c | 9 +- common/image-fit.c | 2 + configs/bcm7445d0_defconfig | 21 ++ drivers/mmc/Makefile | 1 + drivers/mmc/bcmstb_sdhci.c | 59 ++++ drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/bcmstb_spi.c | 428 ++++++++++++++++++++++++ dts/Kconfig | 6 + include/configs/bcm7445d0.h | 227 +++++++++++++ include/configs/bcmstb.h | 57 ++++ lib/fdtdec.c | 8 + 23 files changed, 1204 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/bcm7445d0/Makefile create mode 100644 arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S create mode 100644 arch/arm/mach-bcm7445d0/include/mach/gpio.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/hardware.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/sdhci.h create mode 100644 board/broadcom/bcm7445d0/Kconfig create mode 100644 board/broadcom/bcm7445d0/Makefile create mode 100644 board/broadcom/bcm7445d0/bcm7445d0.c create mode 100644 configs/bcm7445d0_defconfig create mode 100644 drivers/mmc/bcmstb_sdhci.c create mode 100644 drivers/spi/bcmstb_spi.c create mode 100644 include/configs/bcm7445d0.h create mode 100644 include/configs/bcmstb.h -- 1.8.3.1

6 36

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.
by Yuri Frolov 11 Sep '19

11 Sep '19

Hi, I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip. Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. g_snpsid register reports 0x5533290a revision. It's verified, that linux kernel support is ok, usb is fully functional. axi { <...> usb@1F04D050 { compatible = "be,baikal-dwc3"; reg = <0x1f04d050 0x4>; interrupts = <0x0 0x45 0x4>; #address-cells = <0x1>; #size-cells = <0x1>; clocks = <0xf 0x0>; clock-names = "usb"; ranges; status = "okay"; dwc3@1F100000 { compatible = "snps,dwc3", "synopsys,dwc3", "generic-xhci"; reg = <0x1f100000 0x10000>; interrupts = <0x0 0x44 0x4>; dr_mode = "host"; tx-fifo-resize; maximum-speed = "high-speed"; }; }; }; whereas in u-boot 'usb start' fails on hub initialization (as I can see): Any ideas why this could happen?.. Any direction where to look at? Any suggestions will be greatly appreciated. # usb start (Re)start USB... USB0: dwc3_reg->g_snpsid: 0x5533290a Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... New Device 0 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F get_conf_no 0 Result 25, wLength 31 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF Manufacturer U-Boot Product XHCI Host Controller SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC 1 ports detected ganged power switching standalone hub individual port over-current protection TT requires at most 8 FS bit times (666 ns) power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 801 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 devnum=1 poweron: query_delay=100 connect_timeout=1100 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 devnum=1 port=1: USB dev found usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_hub_port_reset: resetting port 1... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 111, change 0, 12 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 XHCI timeout on event type 33... cannot recover. BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()! BUG! Reset CPU by CPC Here is the drivers/usb/host/xhci-baikal.c: #include <common.h> #include <usb.h> #include <linux/errno.h> #include <linux/compat.h> #include <linux/usb/dwc3.h> #include <linux/usb/xhci-omap.h> #include "xhci.h" /* Declare global data pointer */ DECLARE_GLOBAL_DATA_PTR; struct baikal_xhci { struct xhci_hccr *hcd; struct dwc3 *dwc3_reg; }; static struct baikal_xhci baikal; int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init); static int baikal_xhci_core_init(struct baikal_xhci *baikal) { int ret = 0; ret = dwc3_core_init(baikal->dwc3_reg); if (ret) { debug("%s:failed to initialize core\n", __func__); return ret; } /* We are hard-coding DWC3 core to Host Mode */ dwc3_set_mode(baikal->dwc3_reg, DWC3_GCTL_PRTCAP_HOST); return ret; } static void baikal_xhci_core_exit(struct baikal_xhci *baikal) { } int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor) { struct baikal_xhci *ctx = &baikal; int ret = 0; ctx->hcd = (struct xhci_hccr *)CONFIG_USB_XHCI_BAIKAL_BASE; ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET); ret = board_usb_init(index, USB_INIT_HOST); if (ret != 0) { puts("Failed to initialize board for USB\n"); return ret; } ret = baikal_xhci_core_init(ctx); if (ret < 0) { puts("Failed to initialize xhci\n"); return ret; } *hccr = (struct xhci_hccr *)(CONFIG_USB_XHCI_BAIKAL_BASE); *hcor = (struct xhci_hcor *)((uint32_t) *hccr + HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); debug("baikal-xhci: init hccr %x and hcor %x hc_length %d\n", (uint32_t)*hccr, (uint32_t)*hcor, (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); return ret; } void xhci_hcd_stop(int index) { } TIA, Yuri

4 6

[U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag
by Patrick Wildt 06 Aug '19

06 Aug '19

The PXE object contains a flag that specifies whether or not a DHCP ACK has been received. This can be used by EFI Applications to find out whether or not it is worth to read the DHCP information from our object. Signed-off-by: Patrick Wildt <patrick(a)blueri.se> --- lib/efi_loader/efi_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index 8c5d5b492c..0b9c7b9345 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -332,8 +332,10 @@ int efi_net_register(void) netobj->net_mode.max_packet_size = PKTSIZE; netobj->pxe.mode = &netobj->pxe_mode; - if (dhcp_ack) + if (dhcp_ack) { netobj->pxe_mode.dhcp_ack = *dhcp_ack; + netobj->pxe_mode.dhcp_ack_received = 1; + } /* * Create WaitForPacket event. -- 2.14.3 (Apple Git-98)

5 19

[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver
by Simon Glass 01 Aug '19

01 Aug '19

This series introduces a generic VESA video driver and adjusts the generic PCI ROM support to support it. It also fixes up some problems which prevent this from working on PowerPC at present. It is now possible to use VESA graphics: - On PowerPC, using the x86 emulator - On x86, using either the x86 emulator or native code execution As it turns out, on the only platform I have tested (link), the x86 emulator is only slightly slower that native code execution (200ms difference). Still, we may as well leave this feature in there. VGA ROMs are a very old technology but they are still used by modern platforms, including at least link and some Atom designs. Simon Glass (10): bios_emulator: Fix an #ifdef typo in the header file x86: Correct endianness isues in pci_rom x86: Support ROMs on other archs bios_emulator: Don't display error when emulator terminates bios_emulator: Add some VESA interface debugging x86: pci: Don't stop when we get a vendor/device mismatch x86: Add a VESA video driver x86: Drop the x86_fb driver x86: Access the VGA ROM when needed RFC: Test code for glacier PCI video support arch/x86/include/asm/u-boot-x86.h | 2 + drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++---- drivers/bios_emulator/include/x86emu/debug.h | 2 +- drivers/bios_emulator/x86emu/ops.c | 2 +- drivers/pci/pci_auto.c | 28 ++++- drivers/pci/pci_rom.c | 40 ++++--- drivers/video/Makefile | 2 +- drivers/video/vesa_fb.c | 64 +++++++++++ drivers/video/x86_fb.c | 38 ------- include/configs/canyonlands.h | 31 ++++++ include/configs/chromebook_link.h | 2 +- include/pci.h | 9 ++ include/pci_rom.h | 1 - include/vbe.h | 9 +- 14 files changed, 312 insertions(+), 79 deletions(-) create mode 100644 drivers/video/vesa_fb.c delete mode 100644 drivers/video/x86_fb.c -- 2.2.0.rc0.207.ga3a616c

3 42

[U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K
by Mark Kettenis 13 Jun '19

13 Jun '19

Currently U-Boot doesn't make any effort to reserve the memory used by ARM Trusted Firmware on these platforms. The result is that the memory is listed as available in the EFI memory map. And as soon as a loaded kernel tries to use this memory things explode. I've seen this with the OpenBSD kernel. But I totally expect a Linux kernel to suffer the same fate. I'm currently using the diff below, but it is not entirely clear to me if arch_early_init_r() is the appropriate place to do this. I'm also wondering whether the block should also be marked as reserved in the FDT using fdt_add_mem_rsv(). If the latter is required this probably needs to be done by ft_board_setup() or ft_system_setup(). The address and size of the region have been taken from Marvell's ATF fork at https://github.com/MarvellEmbeddedProcessors/atf-marvell The memory layout is defined in plat/marvell/a8k/common/include/platform_def.h where there are lots of defines and a diagram that attempt to describe the memory. It is not entirely obvious to me what part needs to be reserved. But 0x0400000-0x04200000 works. diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c index 3c84043a2c..895cd2852f 100644 --- a/arch/arm/mach-mvebu/arm64-common.c +++ b/arch/arm/mach-mvebu/arm64-common.c @@ -95,5 +95,11 @@ int arch_early_init_r(void) pci_init(); #endif +#ifdef CONFIG_EFI_LOADER + /* Reserve trusted SRAM section */ + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, + EFI_RESERVED_MEMORY_TYPE, false); +#endif + return 0; }

7 11

[U-Boot] [PATCH V3 01/10] disk: support host devices in dev_print()
by Stephen Warren 18 May '19

18 May '19

Add a case statement for IF_TYPE_HOST in dev_print() so that it prints the device type rather than the "device type unknown" message. Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- disk/part.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/disk/part.c b/disk/part.c index 43485c9148b0..4e72257434b6 100644 --- a/disk/part.c +++ b/disk/part.c @@ -179,6 +179,9 @@ void dev_print (block_dev_desc_t *dev_desc) case IF_TYPE_DOC: puts("device type DOC\n"); return; + case IF_TYPE_HOST: + puts("host device\n"); + break; case IF_TYPE_UNKNOWN: puts("device type unknown\n"); return; -- 1.9.1

2 13

[U-Boot] [PATCH] fs: fat: fix reading non-cluster-aligned root directory
by Anssi Hannula 10 Apr '19

10 Apr '19

FAT16 root directory might not start at a cluster boundary (though it always ends on one). However, next_dent() always starts reading the directory at the beginning of the cluster, causing no files to be found (at least if the beginning of the cluster contains zeroes). Fix that by skipping to the actual start of the root directory in such a case. This is a relatively common case as at least the filesystem formatter on Win7 seems to create such filesystems by default on 2GB USB sticks (cluster size 64 sectors, rootdir size 32 sectors). dosfstools mkfs.vfat does not seem to create such filesystems. Signed-off-by: Anssi Hannula <anssi.hannula(a)bitwise.fi> --- fs/fat/fat.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index b08949d370..4a0d4bb8bc 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -782,6 +782,20 @@ static dir_entry *next_dent(fat_itr *itr) itr->remaining = nbytes / sizeof(dir_entry) - 1; itr->dent = dent; + + if (itr->fsdata->fatsize != 32 && + itr->clust == itr->fsdata->root_cluster) { + /* rootdir might not start at cluster boundary */ + u32 sect_offset = itr->fsdata->rootdir_sect - + clust_to_sect(itr->fsdata, + itr->fsdata->root_cluster); + u32 dirent_offset = itr->fsdata->sect_size / + sizeof(dir_entry) * sect_offset; + + itr->remaining -= dirent_offset; + itr->dent += dirent_offset; + } + } else { itr->remaining--; itr->dent++; -- 2.17.1

3 4

[U-Boot] [PATCH 1/2] Add domain mapping for Pepperl+Fuchs
by Simon Goldschmidt 09 Apr '19

09 Apr '19

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> --- u-boot-config/domain-map | 1 + 1 file changed, 1 insertion(+) diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map index f2abba9..74c1538 100644 --- a/u-boot-config/domain-map +++ b/u-boot-config/domain-map @@ -262,6 +262,7 @@ parallels.com Parallels pasemi.com PA Semi Corporation pcs.de PCS Systemtechnik pengutronix.de Pengutronix +pepperl-fuchs.com Pepperl+Fuchs pheonix.com Phoeonix philosys.de Philosys Software phytec.de Phytec -- 2.17.1

2 5

[U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
by Miquel Raynal 08 Apr '19

08 Apr '19

Today way is to rely on CMD_NAND to be selected and from the root Makefile compile what is in drivers/mtd/nand/raw. While this will work most of the time with decent configurations, it is better to also compile this subsystem upon simple request in the configuration. Otherwise, a user not selecting CMD_NAND but selecting NAND and any of the controller drivers will not see their build. Fix this weird situation by adding a single line in the nand/ directory Kconfig file. Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index a358bc680e..2c33447995 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -2,4 +2,5 @@ nandcore-objs := core.o bbt.o obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o +obj-$(CONFIG_NAND) += raw/ obj-$(CONFIG_MTD_SPI_NAND) += spi/ -- 2.17.1

3 7

[U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq
by Christian Gmeiner 04 Apr '19

04 Apr '19

Fixes performance related issue when running vxWorks 5/7 images. The overall memory performance (L1, L2 cache and ram) was measured with Bandwidth [0]. Without this patch we get following numbers: - sequential 128-bit reads: ~5.2 GB/s - sequential 128-bit copy: ~2.1 GB/s - random 32-bit writes: ~1.2 GB/s With this patch patch we get the following numbers: - sequential 128-bit reads: ~18.0 GB/s - sequential 128-bit copy: ~9.5 GB/s - random 32-bit writes: ~5.0 GB/s [0] https://zsmith.co/bandwidth.html v1 -> v2: - incorporate feedback from Bin Meng Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- arch/x86/cpu/queensbay/Makefile | 2 +- arch/x86/cpu/queensbay/cpu.c | 58 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/queensbay/cpu.c diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile index c0681995bd..3dd23465d4 100644 --- a/arch/x86/cpu/queensbay/Makefile +++ b/arch/x86/cpu/queensbay/Makefile @@ -5,4 +5,4 @@ # obj-y += fsp_configs.o irq.o -obj-y += tnc.o +obj-y += tnc.o cpu.o diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c new file mode 100644 index 0000000000..805a94cc27 --- /dev/null +++ b/arch/x86/cpu/queensbay/cpu.c @@ -0,0 +1,58 @@ +/* + * Copyright (C) 2018, Bachmann electronic GmbH + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <cpu.h> +#include <dm.h> +#include <asm/cpu.h> +#include <asm/cpu_x86.h> +#include <asm/msr.h> + +static void set_max_freq(void) +{ + msr_t msr; + + /* Enable enhanced speed step */ + msr = msr_read(MSR_IA32_MISC_ENABLES); + msr.lo |= (1 << 16); + msr_write(MSR_IA32_MISC_ENABLES, msr); + + /* Set new performance state */ + msr = msr_read(MSR_IA32_PERF_CTL); + msr.lo = 0x101f; + msr_write(MSR_IA32_PERF_CTL, msr); +} + +static int cpu_x86_tunnelcreek_probe(struct udevice *dev) +{ + if (!ll_boot_init()) + return 0; + debug("Init TunnelCreek core\n"); + + /* Set core to max frequency ratio */ + set_max_freq(); + + return 0; +} + +static const struct cpu_ops cpu_x86_tunnelcreek_ops = { + .get_desc = cpu_x86_get_desc, + .get_count = cpu_x86_get_count, +}; + +static const struct udevice_id cpu_x86_tunnelcreek_ids[] = { + { .compatible = "intel,tunnelcreek-cpu" }, + { } +}; + +U_BOOT_DRIVER(cpu_x86_tunnelcreek_drv) = { + .name = "cpu_x86_tunnelcreek", + .id = UCLASS_CPU, + .of_match = cpu_x86_tunnelcreek_ids, + .bind = cpu_x86_bind, + .probe = cpu_x86_tunnelcreek_probe, + .ops = &cpu_x86_tunnelcreek_ops, +}; -- 2.14.3

3 10