June 2018 - U-Boot

[U-Boot] [PATCH v5 0/6] Iotrace improvements
by Ramon Fried 21 Jun '18

21 Jun '18

These set of patches add few improvements to iotrace. * Region limiting - allows setting an address and size where only io operations that falls into that address are logged. * Timestamping - Timestamp every iotrace record with current timestamp * dumping - iotrace dump command for dumping all records from buffer in a readable fashion. In terms of backwards compatibility, the timestamp is not backward compatible as it changes the iotrace record. so if one developed an offline parsing tool it will be broken. I though of adding #ifdef specific for that, but eventually I didn't. Changes in v5: - Removed common.h include that caused werid compliation problems in other boards (trini) - Fixed portability issue in printf (trini) Changes in v4: - Resend complete patchset with patman Changes in v3: - fixed wrong usage of WARN_ONCE Changes in v2: - introduced needed_size to notify the user about the needed buffer size. Changes in v1: - Change timestamp function to get_ticks() Ramon Fried (6): cmd: iotrace: add set region command iotrace: add IO region limit common: iotrace: add timestamp to iotrace records iotrace: move record definitons to header file cmd: iotrace: add dump trace command iotrace: fix behaviour when buffer is full cmd/iotrace.c | 63 ++++++++++++++++++++++++++++++++++++++++++--- common/iotrace.c | 65 +++++++++++++++++++++++++++-------------------- include/iotrace.h | 57 +++++++++++++++++++++++++++++++++++++++-- 3 files changed, 153 insertions(+), 32 deletions(-) -- 2.17.1

3 15

[U-Boot] Reprobe devices at run time
by Michal Simek 21 Jun '18

21 Jun '18

Hi Simon and other, do we have a way to remove device and probe it again via u-boot prompt? I was grepping u-boot and I didn't find any command for that. I see functionality in the code and several tests but nothing what it is available via command. Thanks, Michal

3 3

[U-Boot] [PATCH] tools: fit_common: allow opening of block devices
by Radek Dostál 21 Jun '18

21 Jun '18

During manufacturing it is useful to be able to verify integrity of secondary fit image by just running `./fit_check_sign -f /dev/mtdblock? -k ...` This was unfortunately failing as fstat(fd, sbuf) was setting sbuf->st_size to zero, which caused mmap to fail later on. Signed-off-by: Radek Dostál <radek.dostal(a)streamunlimited.com> Reviewed-by: Vladimir Koutny <vladimir.koutny(a)streamunlimited.com> --- tools/fit_common.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/fit_common.c b/tools/fit_common.c index d96085e..2c917d3 100644 --- a/tools/fit_common.c +++ b/tools/fit_common.c @@ -22,6 +22,8 @@ #include "fit_common.h" #include <image.h> #include <u-boot/crc.h> +#include <sys/ioctl.h> +#include <linux/fs.h> int fit_verify_header(unsigned char *ptr, int image_size, struct image_tool_params *params) @@ -58,6 +60,14 @@ int mmap_fdt(const char *cmdname, const char *fname, size_t size_inc, goto err; } + if (sbuf->st_size == 0 && S_ISBLK(sbuf->st_mode)) { + if (ioctl(fd, BLKGETSIZE64, &sbuf->st_size) < 0) { + fprintf(stderr, "%s: Can't determine size of %s: %s\n", + cmdname, fname, strerror(errno)); + goto err; + } + } + if (size_inc) { sbuf->st_size += size_inc; if (ftruncate(fd, sbuf->st_size)) { -- 2.7.4

1 0

[U-Boot] [PATCH] arm64: zynqmp: Enable usb mass storage command and functionality
by Michal Simek 21 Jun '18

21 Jun '18

Enable ums command for zcu100 to enable mass storage gadget. Tested with ums 0 mmc 0 (for SD) and ums 0 usb 0 (for USB flashdisk). Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_zcu100_revC_defconfig b/configs/xilinx_zynqmp_zcu100_revC_defconfig index 65f7a8d175af..52d3a8a1787b 100644 --- a/configs/xilinx_zynqmp_zcu100_revC_defconfig +++ b/configs/xilinx_zynqmp_zcu100_revC_defconfig @@ -33,6 +33,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_TIME=y CONFIG_MP=y -- 1.9.1

1 0

[U-Boot] [PATCH] ARC: EMDK: Add readme
by Alexey Brodkin 21 Jun '18

21 Jun '18

Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> --- board/synopsys/emdk/README | 82 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 board/synopsys/emdk/README diff --git a/board/synopsys/emdk/README b/board/synopsys/emdk/README new file mode 100644 index 000000000000..706b547a9ed2 --- /dev/null +++ b/board/synopsys/emdk/README @@ -0,0 +1,82 @@ +================================================================================ +Useful notes on bulding and using of U-Boot on ARC EM Development Kit (AKA EMDK) +================================================================================ + + BOARD OVERVIEW + + The DesignWare ARC EM Development Kit is FPGA-bases platform for rapid + software development on the ARC EM family of processors. + + Since this board is based on FPGA it's possible to load and use different + versions of ARC EM CPUs. U-Boot is built to be run on the simplest + possible configuration which means the same one binary will work on more + advanced configurations as well. + + The board has the following features useful for U-Boot: + * On-board 2-channel FTDI TTL-to-USB converter + - The first channel is used for serial debug port (which makes it possible + to use a serial connection on pretty much any host machine be it + Windows, Linux or Mac). + On Linux machine typucally FTDI serial port would be /dev/ttyUSB0. + There's no HW flow-control and baud-rate is 115200. + + - The second channel is used for built-in Digilent USB JTAG probe. + That means no extra hardware is required to access ARC core from a + debugger on development host. Both proprietary MetaWare debugger and + open source OpenOCD + GDB client are supported. + + - Also with help of this FTDI chip it is possible to reset entire + board with help of a special `rff-ftdi-reset` utility, see: + https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset + + * Micro SD-card slot + - U-Boot expects to see the very first partition on the card formatted as + FAT file-system and uses it for keeping its environment in `uboot.env` + file. Note uboot.env is not just a text file but it is auto-generated + file created by U-Boot on invocation of `saveenv` command. + It contains a checksum which makes this saved environment invalid in + case of maual modification. + + - There might be more useful files on that first FAT partition like + user applications, data files etc. + + * 256 KiB of "ROM" + - This so-called "ROM" is a part of FPGA image and even though it + might be unlocked for writes its initial content will be restored + on the next power-on. + + + BUILDING U-BOOT + + 1. Configure U-Boot: + ------------------------->8---------------------- + make emdk_defconfig + ------------------------->8---------------------- + + 2. To build Elf file (for example to be used with host debugger via JTAG + connection to the target board): + ------------------------->8---------------------- + make mdbtrick + ------------------------->8---------------------- + + This will produce `u-boot` Elf file. + + 3. To build binary image to be put in "ROM": + ------------------------->8---------------------- + make u-boot.bin + ------------------------->8---------------------- + + + EXECUTING U-BOOT + + 1. The EMDK board is supposed to auto-start U-Boot image stored in ROM on + power-on. For that make sure VCCIO DIP-switches are all in "off" state. + + 2. Though it is possible to load U-Boot as a simple Elf file via JTAG right + in "ROM" and start it from the debugger. One important note here we first + need to enable writes into "ROM" by writing 1 to 0xf0001000. + + 2.1. In case of proprietary MetaWare debugger run: + ------------------------->8---------------------- + mdb -dll=opxdarc.so -OK -preloadexec="eval *(int*)0xf0001000=0" u-boot + ------------------------->8---------------------- -- 2.17.1

1 0

[U-Boot] [PATCH v2] arm: mvebu: clearfog: add u-boot, dm-spl tag for spi
by Baruch Siach 21 Jun '18

21 Jun '18

From: Jon Nettleton <jon(a)solid-run.com> This is required so SPL and u-boot can boot from spi flash devices that use the dm drivers. Signed-off-by: Jon Nettleton <jon(a)solid-run.com> [baruch: use -u-boot.dtsi] Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- v2: Add u-boot,dm-spl in .dtsi (Stefan Roese) --- arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 arch/arm/dts/armada-388-clearfog-u-boot.dtsi diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi new file mode 100644 index 000000000000..f31691ee9491 --- /dev/null +++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi @@ -0,0 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0+ + +&spi1 { + u-boot,dm-spl; + + spi-flash@0 { + u-boot,dm-spl; + }; +}; -- 2.17.1

2 1

[U-Boot] [PATCH] arm: mvebu: clearfog: add u-boot, dm-spl tag for spi
by Baruch Siach 21 Jun '18

21 Jun '18

From: Jon Nettleton <jon(a)solid-run.com> This is required so SPL and u-boot can boot from spi flash devices that use the dm drivers. Signed-off-by: Jon Nettleton <jon(a)solid-run.com> Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- arch/arm/dts/armada-388-clearfog.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/armada-388-clearfog.dts b/arch/arm/dts/armada-388-clearfog.dts index a0b566a5ae0e..b219441d84be 100644 --- a/arch/arm/dts/armada-388-clearfog.dts +++ b/arch/arm/dts/armada-388-clearfog.dts @@ -342,6 +342,7 @@ pinctrl-0 = <&spi1_pins &clearfog_spi1_cs_pins &mikro_spi_pins>; pinctrl-names = "default"; status = "okay"; + u-boot,dm-spl; spi-flash@0 { #address-cells = <1>; @@ -349,6 +350,7 @@ compatible = "w25q32", "jedec,spi-nor", "spi-flash"; reg = <0>; /* Chip select 0 */ spi-max-frequency = <3000000>; + u-boot,dm-spl; }; }; -- 2.17.1

2 1

[U-Boot] U-Boot CONFIG_OF_BOARD vs CONFIG_OF_SEPARATE
by Student - John Chan Kar Onn 21 Jun '18

21 Jun '18

Hello, I came across this commit on the github repo titled: "fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE" dated 10th Jan in lib/fdtdec.c The commit changes the following lines: >elif defined CONFIG_OF_SEPARATE > ifdef CONFIG_SPL_BUILD > if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)) > gd->fdt_blob = (ulong *)&_image_binary_end; > else > gd->fdt_blob = (ulong *)&__bss_end; > else > gd->fdt_blob = (ulong *)&_end; >endif >elif defined(CONFIG_OF_BOARD) > gd->fdt_blob = board_fdt_blob_setup(); to >elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) > gd->fdt_blob = board_fdt_blob_setup(); where >if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE) > >__weak void *board_fdt_blob_setup(void) >{ > void *fdt_blob = NULL; >ifdef CONFIG_SPL_BUILD > if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)) > fdt_blob = (ulong *)&_image_binary_end; > else > fdt_blob = (ulong *)&__bss_end; >else > fdt_blob = (ulong *)&_end; >endif > return fdt_blob; >} >endif >From what i understand, this means that the definition of CONFIG_OF_BOARD and CONFIG_OF_SEPARATE would have the same behaviour. Is this the intended outcome? As I am working on a rpi, the defined board_fdt_blob_setup in board/raspberrypi/rpi/rpi.c would run instead of the weakly defined board_fdt_blob_setup from above. If i wish to have the ability for CONFIG_OF_BOARD and CONFIG_OF_SEPARATE to have the previous behaviour of board_fdt_blob_setup, should i revert the fdtdec.c or make the edits under rpi.c? Many thanks in advance Warmest Regards, John Chan This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.

1 0

[U-Boot] [PATCH] efi_loader: Fix GOP 32bpp exposure
by Alexander Graf 21 Jun '18

21 Jun '18

We store pixels as BGRA in memory, as can be seen from struct efi_gop_pixel. So we need to expose the same format to UEFI payloads to actually have them use the correct colors. Reported-by: Fabian Vogt <fvogt(a)suse.com> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- lib/efi_loader/efi_gop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c index 1afe8418e1..3a36bbcbfa 100644 --- a/lib/efi_loader/efi_gop.c +++ b/lib/efi_loader/efi_gop.c @@ -472,7 +472,7 @@ efi_status_t efi_gop_register(void) gopobj->info.version = 0; gopobj->info.width = col; gopobj->info.height = row; - gopobj->info.pixel_format = EFI_GOT_RGBA8; + gopobj->info.pixel_format = EFI_GOT_BGRA8; gopobj->info.pixels_per_scanline = col; gopobj->bpix = bpix; -- 2.12.3

4 3

[U-Boot] [PATCH] gpio: zynq: Use live-tree function
by Michal Simek 21 Jun '18

21 Jun '18

Use live-tree function. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/gpio/zynq_gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c index 8d84e3fc1313..afba4580f570 100644 --- a/drivers/gpio/zynq_gpio.c +++ b/drivers/gpio/zynq_gpio.c @@ -374,7 +374,7 @@ static int zynq_gpio_ofdata_to_platdata(struct udevice *dev) { struct zynq_gpio_privdata *priv = dev_get_priv(dev); - priv->base = devfdt_get_addr(dev); + priv->base = (phys_addr_t)dev_read_addr(dev); return 0; } -- 1.9.1

1 0