July 2017 - U-Boot

[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] [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 1/2] usb: gadget: fastboot: Request status and length check in rx handler
by Paul Kocialkowski 18 Mar '19

18 Mar '19

This avoids handling requests that have an error status or no data. In particular, this avoids showing unnecessary error messages when the USB gadget gets disconnected (e.g. with fastboot continue) and the fastboot USB gadget driver sends an error back to the host (that has disconnected already). Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- drivers/usb/gadget/f_fastboot.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 206b6d1..b9a9099 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -635,6 +635,9 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) void (*func_cb)(struct usb_ep *ep, struct usb_request *req) = NULL; int i; + if (req->status != 0 || req->length == 0) + return; + for (i = 0; i < ARRAY_SIZE(cmd_dispatch_info); i++) { if (!strcmp_l1(cmd_dispatch_info[i].cmd, cmdbuf)) { func_cb = cmd_dispatch_info[i].cb; @@ -656,9 +659,7 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) } } - if (req->status == 0) { - *cmdbuf = '\0'; - req->actual = 0; - usb_ep_queue(ep, req, 0); - } + *cmdbuf = '\0'; + req->actual = 0; + usb_ep_queue(ep, req, 0); } -- 1.9.1

4 15

[U-Boot] [PATCH v2 0/4] ARM: atmel: boards: enable SPL support
by Bo Shen 22 Feb '19

22 Feb '19

This patch series enable SPL support for following boards: - at91sam9m10g45ek - NAND flash boot support - SD card boot support - at91sam9n12ek - NAND flash boot support - SPI flash boot support - at91sam9x5ek - NAND flash boot support - SPI flash boot support Changes in v2: - Remove the meaningless prefix "+S:" in configuration file. Bo Shen (4): ARM: atmel: arm926ejs: fix clock configuration ARM: atmel: at91sam9m10g45ek: enable spl support ARM: atmel: at91sam9x5ek: enable spl support ARM: atmel: at91sam9n12ek: enable spl support arch/arm/mach-at91/Kconfig | 3 + arch/arm/mach-at91/Makefile | 2 + arch/arm/mach-at91/arm926ejs/clock.c | 54 +++++++++-------- arch/arm/mach-at91/arm926ejs/u-boot-spl.lds | 48 +++++++++++++++ arch/arm/mach-at91/include/mach/at91_pmc.h | 6 +- arch/arm/mach-at91/include/mach/at91sam9x5.h | 10 ++++ arch/arm/mach-at91/mpddrc.c | 3 +- arch/arm/mach-at91/spl.c | 2 +- arch/arm/mach-at91/spl_at91.c | 11 +++- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 80 +++++++++++++++++++++++++ board/atmel/at91sam9n12ek/at91sam9n12ek.c | 73 ++++++++++++++++++++++ board/atmel/at91sam9x5ek/at91sam9x5ek.c | 74 +++++++++++++++++++++++ configs/at91sam9m10g45ek_mmc_defconfig | 1 + configs/at91sam9m10g45ek_nandflash_defconfig | 1 + configs/at91sam9n12ek_nandflash_defconfig | 1 + configs/at91sam9n12ek_spiflash_defconfig | 1 + configs/at91sam9x5ek_nandflash_defconfig | 1 + configs/at91sam9x5ek_spiflash_defconfig | 1 + include/configs/at91sam9m10g45ek.h | 58 ++++++++++++++++++ include/configs/at91sam9n12ek.h | 58 +++++++++++++++++- include/configs/at91sam9x5ek.h | 57 ++++++++++++++++++ 21 files changed, 513 insertions(+), 32 deletions(-) create mode 100644 arch/arm/mach-at91/arm926ejs/u-boot-spl.lds -- 2.3.3.220.g9ab698f

4 14

[U-Boot] [PATCH] nios2: 10m50: Add CPU pre-relocation in device tree
by Gan, Yau Wai 20 Sep '18

20 Sep '18

Tag CPU with dm-pre-reloc to enable driver before relocation. Signed-off-by: Gan, Yau Wai <yau.wai.gan(a)intel.com> Cc: Thomas Chou <thomas(a)wytron.com.tw> --- arch/nios2/dts/10m50_devboard.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/nios2/dts/10m50_devboard.dts b/arch/nios2/dts/10m50_devboard.dts index 05eac30..461ae68 100644 --- a/arch/nios2/dts/10m50_devboard.dts +++ b/arch/nios2/dts/10m50_devboard.dts @@ -19,6 +19,7 @@ #size-cells = <0>; cpu: cpu@0 { + u-boot,dm-pre-reloc; device_type = "cpu"; compatible = "altr,nios2-1.1"; reg = <0x00000000>; -- 2.7.4

4 3

[U-Boot] [PATCH] x86: extend baudrate table with 57600
by Christian Gmeiner 06 Sep '18

06 Sep '18

Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- include/configs/x86-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index b5ef8b5..9a97714 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -56,7 +56,7 @@ * Serial Configuration */ #define CONFIG_SYS_BAUDRATE_TABLE {300, 600, 1200, 2400, 4800, \ - 9600, 19200, 38400, 115200} + 9600, 19200, 38400, 57600, 115200} #define CONFIG_SYS_NS16550_PORT_MAPPED #define CONFIG_CMDLINE_EDITING -- 2.9.4

3 8

[U-Boot] [PATCH 0/8] efi_loader: Support loading from El Torito isos
by Alexander Graf 14 Aug '18

14 Aug '18

Some distributions still provide .iso files for installation media. To give us greatest flexibility, this patch set adds support for El Torito booting with EFI payloads. Please consider for 2016.05 still. Thanks, Alex Alexander Graf (8): iso: Make little endian and 64bit safe iso: Start with partition 1 iso: Allow 512 byte sector size efi_loader: Split drive add into function efi_loader: Add el torito support efi_loader: Pass file path to payload efi_loader: Increase path string to 32 characters distro: Enable iso partition code cmd/bootefi.c | 48 +++++++++++++--- cmd/fs.c | 3 +- disk/part_iso.c | 50 +++++++++++----- disk/part_iso.h | 40 ++++++------- include/config_distro_defaults.h | 1 + include/efi_api.h | 2 +- include/efi_loader.h | 5 +- lib/efi_loader/efi_disk.c | 121 +++++++++++++++++++++++++++------------ 8 files changed, 187 insertions(+), 83 deletions(-) -- 1.8.5.6

4 19

[U-Boot] armv5 and OMAP3 Question
by Adam Ford 04 Aug '18

04 Aug '18

The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work" We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead. I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC. (please don't flame me, I am honestly curious). adam

2 9

[U-Boot] [PATCH] xyz-modem: Change getc timeout loop waiting
by Tomas Melin 02 Aug '18

02 Aug '18

This fixes the loop delay when using a hw watchdog. In case a watchdog is used that accesses CPU registers, the defined delay of 20us in a tight loop will cause a huge delay in the actual timeout seen. This is caused by the fact that udelay will inheritantly call WATCHDOG_RESET. Together with the omap wdt implementation, the seen timeout increases up to around 30s. This makes the loop very slow and causes long delays when using the modem. Instead, implement the 2 sec loop by using the timer interface to know when to break out of the timeout loop. Watchdog kicking is taken care of by getc(). Signed-off-by: Tomas Melin <tomas.melin(a)vaisala.com> --- common/xyzModem.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/common/xyzModem.c b/common/xyzModem.c index 5656aac..e0d87db 100644 --- a/common/xyzModem.c +++ b/common/xyzModem.c @@ -71,12 +71,12 @@ typedef int cyg_int32; static int CYGACC_COMM_IF_GETC_TIMEOUT (char chan, char *c) { -#define DELAY 20 - unsigned long counter = 0; - while (!tstc () && (counter < xyzModem_CHAR_TIMEOUT * 1000 / DELAY)) + + ulong now = get_timer(0); + while (!tstc ()) { - udelay (DELAY); - counter++; + if (get_timer(now) > xyzModem_CHAR_TIMEOUT) + break; } if (tstc ()) { -- 2.1.4

3 6

[U-Boot] [PATCH] sunxi: reduce Orange Pi Zero DRAM clock speed
by Clément Bœsch 31 May '18

31 May '18

Using `fel-boot-lima-memtester-on-orange-pi-pc 672` on an Orange Pi without heatsink results in the following error after a few minutes: WRITE FAILURE: 0x00200000 != 0xffdfffff at offset 0x0137f47c (bitflip). Also, the constructor repository (github/orangepi-xunlong) seems to contain that 624 Mhz clock speed in its u-boot fork. It may be that 672 Mhz is the advertized overclocked speed. According to http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit it may be worth decreasing that value with other Orange Pi boards. See also e7d6aa0b74b7f4d08ee68da8a586c76c761348e2. --- configs/orangepi_zero_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig index c650ce87d9..16a3929aa5 100644 --- a/configs/orangepi_zero_defconfig +++ b/configs/orangepi_zero_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_MACH_SUN8I_H3=y -CONFIG_DRAM_CLK=672 +CONFIG_DRAM_CLK=624 CONFIG_DRAM_ZQ=3881979 CONFIG_DRAM_ODT_EN=y # CONFIG_VIDEO_DE2 is not set -- 2.13.3

3 3