Re: [U-Boot] [PATCH] menu: fix timeout duration
2018-05-24 13:29 GMT+09:00 Masahiro Yamada: > menu_interactive_choice() divides the timeout value by 10 before > passing it to cli_readline_into_buffer(). > > For distro-boot, the "timeout" variable in the boot script should > specify the time in _seconds_ to wait for keyboard input before > booting the default menu entry. > > Due to the division, "timeout 50" actually wait for only 5 seconds > instead of 50. What is worse, "timeout 5" never breaks because > "m->timeout / 10" is zero, which means no timeout. > > For CONFIG_MENU_SHOW case, menu_show() should also take the timeout > value in seconds because its default comes from CONFIG_BOOTDELAY. > > The "division by 10" was introduced by commit 8594753ba0a7 ("menu: > only timeout when menu is displayed"). Its log claimed "fixed", > but to me, it rather looks the root cause of the problem. > > Signed-off-by: Masahiro Yamada > --- > > Rob, > > I know commit 8594753ba0a7 is already 6 years ago. > If you remember something about "/ 10", please comment. > I was misunderstanding. I will do v2. > common/menu.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/common/menu.c b/common/menu.c > index bf2b471..bf23194 100644 > --- a/common/menu.c > +++ b/common/menu.c > @@ -194,8 +194,7 @@ static inline int menu_interactive_choice(struct menu *m, > void **choice) > > if (!m->item_choice) { > readret = cli_readline_into_buffer("Enter choice: ", > - cbuf, > - m->timeout / 10); > + cbuf, timeout); > > if (readret >= 0) { > choice_item = menu_item_by_key(m, cbuf); > -- > 2.7.4 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] common: Generic loader for file system
From: Tien Fong CheeThis is file system generic loader which can be used to load the file image from the storage into target such as memory. The consumer driver would then use this loader to program whatever, ie. the FPGA device. Signed-off-by: Tien Fong Chee --- drivers/misc/Kconfig | 11 +++ drivers/misc/Makefile| 1 + drivers/misc/fs_loader.c | 240 +++ include/dm/uclass-id.h | 1 + include/fs_loader.h | 28 ++ 5 files changed, 281 insertions(+) create mode 100644 drivers/misc/fs_loader.c create mode 100644 include/fs_loader.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index be900cf..59f716b 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -268,4 +268,15 @@ config GDSYS_RXAUI_CTRL depends on MISC help Support gdsys FPGA's RXAUI control. + +config FS_LOADER + bool "Enable loader driver for file system" + depends on DM + help + This is file system generic loader which can be used to load + the file image from the storage into target such as memory. + + The consumer driver would then use this loader to program whatever, + ie. the FPGA device. + endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index e362609..74364a0 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -53,3 +53,4 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o obj-$(CONFIG_STM32_RCC) += stm32_rcc.o obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o +obj-$(CONFIG_FS_LOADER) += fs_loader.o diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c new file mode 100644 index 000..127f7f1 --- /dev/null +++ b/drivers/misc/fs_loader.c @@ -0,0 +1,240 @@ +/* + * Copyright (C) 2018 Intel Corporation + * + * SPDX-License-Identifier:GPL-2.0 + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +struct firmware_priv { + const char *name; /* Filename */ + u32 offset; /* Offset of reading a file */ +}; + +static int select_fs_dev(struct udevice *dev) +{ + int ret; + struct device_platdata *plat; + + plat = dev->platdata; + if (!strcmp("mmc", plat->name)) { + ret = fs_set_blk_dev("mmc", plat->devpart, FS_TYPE_ANY); + } else if (!strcmp("usb", plat->name)) { + ret = fs_set_blk_dev("usb", plat->devpart, FS_TYPE_ANY); + } else if (!strcmp("sata", plat->name)) { + ret = fs_set_blk_dev("sata", plat->devpart, FS_TYPE_ANY); + } else if (!strcmp("ubi", plat->name)) { + if (plat->ubivol) + ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS); + else + ret = -ENODEV; + } else { + debug("Error: unsupported storage device.\n"); + return -ENODEV; + } + + if (ret) + debug("Error: could not access storage.\n"); + + return ret; +} + +static void set_storage_devpart(struct udevice *dev, char *devpart) +{ + struct device_platdata *plat; + + plat = dev->platdata; + plat->devpart = devpart; +} + +static void set_storage_mtdpart(struct udevice *dev, char *mtdpart) +{ + struct device_platdata *plat; + + plat = dev->platdata; + plat->mtdpart = mtdpart; +} + +static void set_storage_ubivol(struct udevice *dev, char *ubivol) +{ + struct device_platdata *plat; + + plat = dev->platdata; + plat->ubivol = ubivol; +} + +/** + * _request_firmware_prepare - Prepare firmware struct. + * + * @firmware_p: Pointer to pointer to firmware image. + * @name: Name of firmware file. + * @dbuf: Address of buffer to load firmware into. + * @size: Size of buffer. + * @offset: Offset of a file for start reading into buffer. + * + * Return: Negative value if fail, 0 for successful. + */ +static int _request_firmware_prepare(struct firmware **firmware_p, + const char *name, void *dbuf, + size_t size, u32 offset) +{ + struct firmware *firmware; + struct firmware_priv *fw_priv; + + *firmware_p = NULL; + + if (!name || name[0] == '\0') + return -EINVAL; + + firmware = calloc(1, sizeof(*firmware)); + if (!firmware) + return -ENOMEM; + + fw_priv = calloc(1, sizeof(*fw_priv)); + if (!fw_priv) { + free(firmware); + return -ENOMEM; + } + + fw_priv->name = name; + fw_priv->offset = offset; + firmware->data = dbuf; + firmware->size = size; + firmware->priv = fw_priv; + *firmware_p = firmware; + + return 0; +} + +/** + * fw_get_filesystem_firmware - load firmware into an allocated buffer. +
[U-Boot] [PATCH v2 2/3] doc: dtbinding: Add file system firmware loader binding document
From: Tien Fong CheeAdd a document to describe file system firmware loader binding information. Signed-off-by: Tien Fong Chee --- doc/device-tree-bindings/misc/fs_loader.txt | 50 + 1 file changed, 50 insertions(+) create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt diff --git a/doc/device-tree-bindings/misc/fs_loader.txt b/doc/device-tree-bindings/misc/fs_loader.txt new file mode 100644 index 000..066d690 --- /dev/null +++ b/doc/device-tree-bindings/misc/fs_loader.txt @@ -0,0 +1,50 @@ +* File system firmware loader + +Required properties: + + +- compatible: should contain "fs_loader" +- storage_device: which storage device loading from, could be: + - mmc, usb, sata, and ubi. +- devpart: which storage device and partition the image loading from, + this property is required for mmc, usb and sata. +- mdtpart: which partition of ubi the image loading from, this property is + required for ubi. +- ubivol: which volume of ubi the image loading from, this proprety is required + for ubi. + +Example of default storage device partition search set for mmc, usb, sata and +ubi in device tree source as shown in below: + +Example for mmc: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "mmc"; + devpart = "0:1"; + }; + +Example for usb: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "usb"; + devpart = "0:1"; + }; + +Example for sata: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "sata"; + devpart = "0:1"; + }; + +Example for ubi: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "ubi"; + mtdpart = "UBI", + ubivol = "ubi0"; + }; -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] doc: Add new doc for file system firmware loader driver model
From: Tien Fong CheeProvide information about - overview of file system firmware loader driver model - describe default storage device in device tree source - describe fie system firmware loader API Signed-off-by: Tien Fong Chee --- doc/driver-model/fs_firmware_loader.txt | 103 1 file changed, 103 insertions(+) create mode 100644 doc/driver-model/fs_firmware_loader.txt diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-model/fs_firmware_loader.txt new file mode 100644 index 000..f05db8d --- /dev/null +++ b/doc/driver-model/fs_firmware_loader.txt @@ -0,0 +1,103 @@ +# Copyright (C) 2018 Intel Corporation +# +# SPDX-License-Identifier:GPL-2.0 + +Introduction + + +This is file system firmware loader for U-Boot framework, which has very close +to some Linux Firmware API. For the details of Linux Firmware API, you can refer +to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html. + +File system firmware loader can be used to load whatever(firmware, image, +and binary) from the storage device in file system format into target location +such as memory, then consumer driver such as FPGA driver can program FPGA image +from the target location into FPGA. + +To enable firmware loader driver model, CONFIG_FS_LOADER need to be set at +_defconfig such as "CONFIG_FS_LOADER=y". + +Firmware Loader API core features +- + +Firmware storage device described in device tree source +--- + Example of default storage device partition search set for mmc, usb, + sata and ubi as shown in below: + Example for mmc: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "mmc"; + devpart = "0:1"; + }; + + Example for usb: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "usb"; + devpart = "0:1"; + }; + + Example for sata: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "sata"; + devpart = "0:1"; + }; + + Example for ubi: + fs_loader { + u-boot,dm-pre-reloc; + compatible = "fs_loader"; + storage_device = "ubi"; + mtdpart = "UBI", + ubivol = "ubi0"; + }; + + + However, the default fs_loader with property devpart, mtdpart, and + ubivol values can be overwritten with value which is defined in the + environment variable "fw_dev_part", "fw_ubi_mtdpart", and + "fw_ubi_volume" respectively. + For example: env_set("fw_dev_part", "0:2"); + +File system firmware Loader API +--- + +int request_firmware_into_buf(struct udevice *dev, +struct firmware **firmware_p, +const char *name, +void *buf, size_t size, u32 offset) + +Load firmware into a previously allocated buffer + +Parameters: + +1. struct udevice *dev + An instance of a driver + +2. struct firmware **firmware_p + pointer to firmware image + +3. const char *name + name of firmware file + +4. void *buf + address of buffer to load firmware into + +5. size_t size + size of buffer + +6. u32 offset + offset of a file for start reading into buffer + +return: + size of total read + -ve when error + +Description: + The firmware is loaded directly into the buffer pointed to by buf and + the @firmware_p data member is pointed at buf. -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Generic file system firmware loader DM
From: Tien Fong CheeThis patchset contains generic file system loader DM which is very close to Linux firmware loader but for U-Boot framework. Generic file system firmware loader can be used load whatever into target location, and then consumer driver would use it to program whatever, ie. the FPGA. This version mainly resolved comments from Tom Rini in [v1]. This series is working on top of u-boot-socfpga.git - http://git.denx.de/u-boot.git . [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg286294.html v1 -> v2 changes - Changed the documents to rST format. Tien Fong Chee (3): doc: Add new doc for file system firmware loader driver model doc: dtbinding: Add file system firmware loader binding document common: Generic loader for file system doc/device-tree-bindings/misc/fs_loader.txt | 50 ++ doc/driver-model/fs_firmware_loader.txt | 103 drivers/misc/Kconfig| 11 ++ drivers/misc/Makefile | 1 + drivers/misc/fs_loader.c| 240 include/dm/uclass-id.h | 1 + include/fs_loader.h | 28 7 files changed, 434 insertions(+) create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt create mode 100644 doc/driver-model/fs_firmware_loader.txt create mode 100644 drivers/misc/fs_loader.c create mode 100644 include/fs_loader.h -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] sunxi: add support for Banana Pi M2 Zero board
Banana Pi M2 Zero is a board by Sinovoip with Allwinner H2+ SoC, 16-bit 512MiB DDR3 memory, a MicroSD slot, two MicroUSB ports (one OTG and one powering-only) and a miniHDMI port. DTS file is from Linux kernel with removing some nodes that are not needed in u-boot or not merged into u-boot yet. Signed-off-by: Icenowy ZhengSigned-off-by: Jun Nie --- arch/arm/dts/Makefile | 1 + arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 68 + board/sunxi/MAINTAINERS | 5 ++ configs/bananapi_m2_zero_defconfig | 15 ++ 4 files changed, 89 insertions(+) create mode 100644 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts create mode 100644 configs/bananapi_m2_zero_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 20a4c37..8d6fab2 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -338,6 +338,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \ sun8i-a83t-cubietruck-plus.dtb \ sun8i-a83t-tbs-a711.dts dtb-$(CONFIG_MACH_SUN8I_H3) += \ + sun8i-h2-plus-bananapi-m2-zero.dtb \ sun8i-h2-plus-orangepi-zero.dtb \ sun8i-h3-bananapi-m2-plus.dtb \ sun8i-h3-libretech-all-h3-cc.dtb \ diff --git a/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts b/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts new file mode 100644 index 000..92e8cf4 --- /dev/null +++ b/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts @@ -0,0 +1,68 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2017 Icenowy Zheng + * + * Based on sun8i-h3-bananapi-m2-plus.dts, which is: + * Copyright (C) 2016 Chen-Yu Tsai + */ + +/dts-v1/; +#include "sun8i-h3.dtsi" +#include "sunxi-common-regulators.dtsi" + +#include +#include + +/ { + model = "Banana Pi BPI-M2-Zero"; + compatible = "sinovoip,bpi-m2-zero", "allwinner,sun8i-h2-plus"; + + aliases { + serial0 = + serial1 = + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + leds { + compatible = "gpio-leds"; + + pwr_led { + label = "bananapi-m2-zero:red:pwr"; + gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */ + default-state = "on"; + }; + }; + + gpio_keys { + compatible = "gpio-keys"; + + sw4 { + label = "power"; + linux,code = ; + gpios = <_pio 0 3 GPIO_ACTIVE_LOW>; + }; + }; +}; + + { + vmmc-supply = <_vcc3v3>; + bus-width = <4>; + /* +* On the production batch of this board the card detect GPIO is +* high active (card inserted), although on the early samples it's +* low active. +*/ + cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ + status = "okay"; +}; + + { + status = "okay"; +}; + + { + status = "okay"; +}; diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 5eb8bbe..0d904d9 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -363,6 +363,11 @@ M: Icenowy Zheng S: Maintained F: configs/Sinovoip_BPI_M2_Plus_defconfig +SINOVOIP BPI M2 ZERO BOARD +M: Icenowy Zheng +S: Maintained +F: configs/Sinovoip_BPI_M2_Zero_defconfig + SINOVOIP BPI M3 A83T BOARD M: VishnuPatekar S: Maintained diff --git a/configs/bananapi_m2_zero_defconfig b/configs/bananapi_m2_zero_defconfig new file mode 100644 index 000..b919d8b --- /dev/null +++ b/configs/bananapi_m2_zero_defconfig @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SYS_TEXT_BASE=0x4a00 +CONFIG_MACH_SUN8I_H3=y +CONFIG_DRAM_CLK=408 +CONFIG_DRAM_ZQ=3881979 +CONFIG_DRAM_ODT_EN=y +CONFIG_MMC0_CD_PIN="" +CONFIG_DEFAULT_DEVICE_TREE="sun8i-h2-plus-bananapi-m2-zero" +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_SPL=y +# CONFIG_CMD_FLASH is not set +# CONFIG_SPL_DOS_PARTITION is not set +# CONFIG_SPL_ISO_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] menu: fix timeout duration
menu_interactive_choice() divides the timeout value by 10 before passing it to cli_readline_into_buffer(). For distro-boot, the "timeout" variable in the boot script should specify the time in _seconds_ to wait for keyboard input before booting the default menu entry. Due to the division, "timeout 50" actually wait for only 5 seconds instead of 50. What is worse, "timeout 5" never breaks because "m->timeout / 10" is zero, which means no timeout. For CONFIG_MENU_SHOW case, menu_show() should also take the timeout value in seconds because its default comes from CONFIG_BOOTDELAY. The "division by 10" was introduced by commit 8594753ba0a7 ("menu: only timeout when menu is displayed"). Its log claimed "fixed", but to me, it rather looks the root cause of the problem. Signed-off-by: Masahiro Yamada--- Rob, I know commit 8594753ba0a7 is already 6 years ago. If you remember something about "/ 10", please comment. common/menu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/common/menu.c b/common/menu.c index bf2b471..bf23194 100644 --- a/common/menu.c +++ b/common/menu.c @@ -194,8 +194,7 @@ static inline int menu_interactive_choice(struct menu *m, void **choice) if (!m->item_choice) { readret = cli_readline_into_buffer("Enter choice: ", - cbuf, - m->timeout / 10); + cbuf, timeout); if (readret >= 0) { choice_item = menu_item_by_key(m, cbuf); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq
Hi Christian, On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeinerwrote: > Fixes performance related issue when running vxWorks 5/7 images. nits: vxWorks -> VxWorks > 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 This should not show in the commit message. > > Signed-off-by: Christian Gmeiner > --- > 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 00..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 > +#include > +#include > +#include > +#include > +#include > + > +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); > +} I tried to find any documentation that describes the performance state values of the TunnelCreek processor, but in vain. However when I read the doc, I do have a question here: The enhanced speedstep technology is set to disabled by the processor after power-on, that means we don't need set the performance state (P-state) via the MSR_IA32_PERF_CTL and the processor itself should work under its maximum base frequency. So I believe this whole set_max_freq() is not needed. Can you clarify this? > + > +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= _x86_tunnelcreek_ops, > +}; > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: spi-nor: new NXP FlexSPI driver location & framework to use ?
HI Jagan, > -Original Message- > From: Jagan Teki [mailto:jagannadh.t...@gmail.com] > Sent: Monday, May 21, 2018 8:36 PM > To: Prabhakar Kushwaha> Cc: u-boot@lists.denx.de > Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & framework to > use ? > > On Fri, May 18, 2018 at 3:46 PM, Prabhakar Kushwaha > wrote: > > Hi Jagan, > > > >> -Original Message- > >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com] > >> Sent: Friday, May 18, 2018 11:54 AM > >> To: Prabhakar Kushwaha > >> Cc: u-boot@lists.denx.de > >> Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & framework to > use ? > >> > >> On Fri, May 18, 2018 at 10:31 AM, Prabhakar Kushwaha > >> wrote: > >> > Dear Jagan, > >> > > >> > > >> >> -Original Message- > >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com] > >> >> Sent: Friday, May 18, 2018 10:24 AM > >> >> To: Prabhakar Kushwaha > >> >> Cc: u-boot@lists.denx.de > >> >> Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & > >> >> framework to use ? > >> >> > >> >> On Thu, May 17, 2018 at 4:49 PM, Prabhakar Kushwaha > >> >> wrote: > >> >> > Dear Jagan, > >> >> > > >> >> >> -Original Message- > >> >> >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > >> >> >> Prabhakar Kushwaha > >> >> >> Sent: Monday, May 14, 2018 6:55 PM > >> >> >> To: Jagan Teki > >> >> >> Cc: u-boot@lists.denx.de > >> >> >> Subject: Re: [U-Boot] mtd: spi-nor: new NXP FlexSPI driver > >> >> >> location & framework to use ? > >> >> >> > >> >> >> Thanks Jagan, > >> >> >> > >> >> >> > -Original Message- > >> >> >> > From: Jagan Teki [mailto:jagannadh.t...@gmail.com] > >> >> >> > Sent: Friday, May 11, 2018 11:31 AM > >> >> >> > To: Prabhakar Kushwaha > >> >> >> > Cc: Jagan Teki ; York Sun > >> >> >> > ; Yogesh Narayan Gaur > >> >> >> ; > >> >> >> > Poonam Aggrwal ; Ashish Kumar > >> >> >> > ; u- b...@lists.denx.de > >> >> >> > Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & > >> >> >> > framework to use ? > >> >> >> > > >> >> >> > On Fri, May 11, 2018 at 11:08 AM, Prabhakar Kushwaha > >> >> >> > wrote: > >> >> >> > > Dear Jagan, > >> >> >> > > > >> >> >> > > NXP is coming up with new FlexSPI controller. It is similar > >> >> >> > > to existing QSPI > >> >> >> > with enhanced feature-set. > >> >> >> > > We have the driver ready as per existing framework i.e. > driver/spi. > >> >> >> > > > >> >> >> > > From recend discussion, we go to know about framework > change. > >> >> >> > > Migration of qspi drivers in > >> >> >> > > u-boot-spi/drivers/mtd/spi-nor/ > >> >> >> > git://git.denx.de/u-boot-spi.git branch mtd-spinor-working. > >> >> >> > > > >> >> >> > > We are in dilemma for sending FlexSPI driver upstream. > >> >> >> > > Do we follow existing framework i.e. driver/spi or new > proposed > >> >> >> > framework i.e. u-boot-spi/drivers/mtd/spi-nor/ > >> >> >> > > > >> >> >> > > Also, do we have any timeline of > >> >> >> > > u-boot-spi/drivers/mtd/spi-nor/ to > >> >> >> > become default. > >> >> >> > > >> >> >> > Idea is to move spi-nor, mtd-spinor-working is paused because > >> >> >> > of non-dm drivers accessing. > >> >> >> > >> >> >> This means, flexspi controller driver should be upstream'ed via > >> >> >> u-boot- spi/drivers/mtd/spi-nor branch mtd-spinor-working > >> >> >> > >> >> > > >> >> > Please help me with the query. > >> >> > We don’t want to end up with 2 FlexSPI drivers being posted in > upstream. > >> >> > >> >> Let me understand is this FlexSPI is spi-nor controller, is it > >> >> Linux upstreamed or ML? > >> > > >> > RFC patch > >> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpat > >> chw > >> > ork.ozlabs.org%2Fpatch%2F894918%2F=02%7C01%7Cprabhakar.kushw > ah > >> > a%40nxp.com%7C32aaec29f75b416004ec08d5bc87f8f1%7C686ea1d3bc2b4c6f > >> > a92cd99c5c301635%7C0%7C0%7C636622214533987461=%2F8i9vHtQF1 > >> S5Q6Bn65HVNPIMe%2FI6eSvP%2FKmKs1gxA8U%3D=0 is > under > >> discussion. > >> > It is with assumption of driver/mtd/spi-nor > >> > >> Ohh, there is chance to move this to spi-mem is it? > >> > >> > > >> >> I think for now you can add it mtd/spi with UCLASS_SPI_FLASH > >> >> driver, Since Boris mentioned about spi-mem(I still need to see > >> >> the Linux framework for more details) which may be re-placer for > >> >> spi-nor but once we decided to go with spi-mem or spi-nor then the > >> >> flexspi can convert > >> accordingly. > >> >> > >> > > >> > This means, FlexSPI should be part of driver/mtd/spi-nor for now. > >> > When You decide way forward(mtd/spi or spi-mem), flexSPI driver can > >> > move > >> accordingly. > >> >
Re: [U-Boot] [PATCH 1/2] ARM: dts: exynos5: remove the duplicated nodes
2018년 5월 23일 (수) 16:20, Minkyu Kang님이 작성: > Hi, > > 2018년 5월 16일 (수) 11:30, Minkyu Kang 님이 작성: > >> >> >> 2018년 5월 9일 (수) 12:53, Anand Moon 님이 작성: >> >>> Hi Jaehoon, >>> >>> On 12 January 2018 at 16:37, Jaehoon Chung >>> wrote: >>> > Remove the duplicated gic and combiner nodes in exynos5.dtsi. >>> > >>> > Signed-off-by: Jaehoon Chung >>> > --- >>> > arch/arm/dts/exynos5.dtsi | 27 --- >>> > 1 file changed, 27 deletions(-) >>> > >>> > diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi >>> > index 8650800f52..8b725c0ddc 100644 >>> > --- a/arch/arm/dts/exynos5.dtsi >>> > +++ b/arch/arm/dts/exynos5.dtsi >>> > @@ -45,33 +45,6 @@ >>> > #size-cells = <0>; >>> > }; >>> > >>> > - combiner: interrupt-controller@1044 { >>> > - compatible = "samsung,exynos4210-combiner"; >>> > - #interrupt-cells = <2>; >>> > - interrupt-controller; >>> > - samsung,combiner-nr = <32>; >>> > - reg = <0x1044 0x1000>; >>> > - interrupts =<0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, >>> > - <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, >>> > - <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, >>> > - <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>, >>> > - <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>, >>> > - <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>, >>> > - <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>, >>> > - <0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>; >>> > - }; >>> > - >>> > - gic: interrupt-controller@10481000 { >>> > - compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; >>> > - #interrupt-cells = <3>; >>> > - interrupt-controller; >>> > - reg = <0x10481000 0x1000>, >>> > - <0x10482000 0x1000>, >>> > - <0x10484000 0x2000>, >>> > - <0x10486000 0x2000>; >>> > - interrupts = <1 9 0xf04>; >>> > - }; >>> > - >>> > i2c_0: i2c@12C6 { >>> > compatible = "samsung,s3c2440-i2c"; >>> > reg = <0x12C6 0x100>; >>> > -- >>> > 2.15.1 >>> > >>> > ___ >>> > U-Boot mailing list >>> > U-Boot@lists.denx.de >>> > https://lists.denx.de/listinfo/u-boot >>> >>> Looks like this series of patch is missing in u-boot git repository. >>> >>> Best Regards >>> -Anand >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot >> >> >> >> applied to u-boot-samsung. >> > > I accepted this patch series, but I cannot push now since network problem > in my office. > So please wait few days more. > Done! Thanks. > >> Thanks, >> Minkyu Kang. >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] gadget: f_thor: Fix memory leaks of usb request and its buffer
There are memory leaks of usb request and its buffer for ep0, in_ep, and out ep. Fix memory leaks of usb request and its buffer. Signed-off-by: Seung-Woo Kim--- Change from v1 - remove allocation of out_ep request instead of allocating and freeing - fix use error path instead of duplicated error handling code --- drivers/usb/gadget/f_thor.c | 45 --- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c index c8eda05..02d6844 100644 --- a/drivers/usb/gadget/f_thor.c +++ b/drivers/usb/gadget/f_thor.c @@ -752,6 +752,13 @@ int thor_handle(void) return 0; } +static void free_ep_req(struct usb_ep *ep, struct usb_request *req) +{ + if (req->buf) + free(req->buf); + usb_ep_free_request(ep, req); +} + static int thor_func_bind(struct usb_configuration *c, struct usb_function *f) { struct usb_gadget *gadget = c->cdev->gadget; @@ -860,21 +867,18 @@ static int thor_func_bind(struct usb_configuration *c, struct usb_function *f) return 0; fail: + if (dev->req) + free_ep_req(gadget->ep0, dev->req); free(dev); return status; } -static void free_ep_req(struct usb_ep *ep, struct usb_request *req) -{ - free(req->buf); - usb_ep_free_request(ep, req); -} - static void thor_unbind(struct usb_configuration *c, struct usb_function *f) { struct f_thor *f_thor = func_to_thor(f); struct thor_dev *dev = f_thor->dev; + free_ep_req(dev->gadget->ep0, dev->req); free(dev); memset(thor_func, 0, sizeof(*thor_func)); thor_func = NULL; @@ -895,8 +899,6 @@ static void thor_func_disable(struct usb_function *f) } if (dev->out_ep->driver_data) { - free(dev->out_req->buf); - dev->out_req->buf = NULL; usb_ep_free_request(dev->out_ep, dev->out_req); usb_ep_disable(dev->out_ep); dev->out_ep->driver_data = NULL; @@ -924,14 +926,13 @@ static int thor_eps_setup(struct usb_function *f) result = usb_ep_enable(ep, d); if (result) - goto exit; + goto err; ep->driver_data = cdev; /* claim */ req = thor_start_ep(ep); if (!req) { - usb_ep_disable(ep); result = -EIO; - goto exit; + goto err_disable_in_ep; } dev->in_req = req; @@ -941,22 +942,34 @@ static int thor_eps_setup(struct usb_function *f) result = usb_ep_enable(ep, d); if (result) - goto exit; + goto err_free_in_req; ep->driver_data = cdev; /* claim */ - req = thor_start_ep(ep); + req = usb_ep_alloc_request(ep, 0); if (!req) { - usb_ep_disable(ep); result = -EIO; - goto exit; + goto err_disable_out_ep; } + req->complete = thor_rx_tx_complete; dev->out_req = req; /* ACM control EP */ ep = dev->int_ep; ep->driver_data = cdev; /* claim */ - exit: + return 0; + + err_disable_out_ep: + usb_ep_disable(dev->out_ep); + + err_free_in_req: + free_ep_req(dev->in_ep, dev->in_req); + dev->in_req = NULL; + + err_disable_in_ep: + usb_ep_disable(dev->in_ep); + + err: return result; } -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] mmc: dwmmc: socfpga: Add reset ctrl to driver
On Mon, May 14, 2018 at 6:01 AM, Simon Glasswrote: > On 8 May 2018 at 13:19, Ley Foon Tan wrote: >> Add code to reset all reset signals as in mmc DT node. A reset property is >> an optional feature, >> so only print out a warning and do not fail if a reset property is not >> present. >> >> If a reset property is discovered, then use it to deassert, thus bringing the >> IP out of reset. >> >> Signed-off-by: Ley Foon Tan >> --- >> drivers/mmc/socfpga_dw_mmc.c | 17 + >> 1 files changed, 17 insertions(+), 0 deletions(-) > > Reviewed-by: Simon Glass Hi Jaehoon Can you help to merge this patch? Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory
Hi Simon Patman is very helpful and useful! I have sent my patches v2 with patman. Thanks a lot for your kind help! Yours, Ken -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: 2018年5月24日 0:22 To: Ken Ma Cc: U-Boot Mailing List; Stefan Roese; Wilson Ding; Nadav Haklai; Hua Jing Subject: Re: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory Hi Ken, On 23 May 2018 at 01:06, Ken Mawrote: > Dear Simon > > Thanks a lot for your kind help and review. > > Previously I did not use patman and generated my patches as below: > 1. used "git mv arch/arm/mach-mvebu/sata.c drivers/ata/ahci_mvebu.c" to do > the file renaming with makefiles and Kconfig file updating. > 2. After the 4 patches are all finished, I used "git format-patch -4 > --cover-letter -o outgoing/sata" to generate the patch set with cover letter. > 3. I used " git send-email --to u-boot@lists.denx.de outgoing/sata* --force" > to send out patches. > > And I try to use patman as your advice, I find that the patch generated by > "patman" can indicate the file "rename" relationship while the patch > generated by "git format-patch" can not. > arch/arm/mach-mvebu/Makefile | 1 - > drivers/ata/Kconfig| 9 + > drivers/ata/Makefile | 1 + > arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++--- > 4 files changed, 13 insertions(+), 4 deletions(-) > rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%) > … > diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c > similarity index 89% > rename from arch/arm/mach-mvebu/sata.c > rename to drivers/ata/ahci_mvebu.c > index 5d8032b..5c1b293 100644 > --- a/arch/arm/mach-mvebu/sata.c > +++ b/drivers/ata/ahci_mvebu.c > @@ -1,15 +1,15 @@ > /* > + * Copyright (C) 2018 Marvell International Ltd. > * Copyright (C) 2016 Stefan Roese > * > - * SPDX-License-Identifier:GPL-2.0+ > + * SPDX-License-Identifier: GPL-2.0+ > + * https://spdx.org/licenses > */ > > #include > #include > #include > > -DECLARE_GLOBAL_DATA_PTR; > - > /* > * Dummy implementation that can be overwritten by a board > * specific function > > But I failed to send out patches by patman as below, it says " Alias 'ata' > not found ". > ken@mshsrv05:~/git_ken/u-boot/u-boot$ tools/patman/patman -c4 > Cleaned 4 patches > 0 errors, 1 warnings, 0 checks for > 0001-ata-mvebu-move-mvebu-sata-driver-to-drivers-ata-dire.patch: > :0: warning: added, moved or deleted file(s), does > MAINTAINERS need updating? > > checkpatch.pl found 0 error(s), 1 warning(s), 0 checks(s) > Traceback (most recent call last): > File "tools/patman/patman", line 161, in > options.add_maintainers) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/series.py", line > 231, in MakeCcFile > raise_on_error=raise_on_error) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", > line 326, in BuildEmailList > raw += LookupEmail(item, alias, raise_on_error=raise_on_error) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", > line 503, in LookupEmail > raise ValueError(msg) > ValueError: Alias 'ata' not found > > > Thanks a lot for your kind help! You can use the -t flag to ignore the missing alias. Regards, Simon > > Yours, > Ken > > > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: 2018年5月23日 7:30 > To: Ken Ma > Cc: U-Boot Mailing List; Stefan Roese > Subject: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to > drivers/ata directory > > External Email > > -- > Hi Ken, > > On 17 May 2018 at 19:27, wrote: >> From: Ken Ma >> >> Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this >> patch moves it to drivers/ata directory with renaming "sata.c" to >> "ahci_mvebu.c" which is aligned to Linux. >> New ahci driver's kconfig option is added as AHCI_MVEBU which selects >> DM_SCSI. >> >> Signed-off-by: Ken Ma >> Cc: Simon Glass >> Cc: Stefan Roese >> --- >> arch/arm/mach-mvebu/Makefile | 1 - >> arch/arm/mach-mvebu/sata.c | 54 >> >> drivers/ata/Kconfig | 9 >> drivers/ata/Makefile | 1 + >> drivers/ata/ahci_mvebu.c | 54 >> >> 5
Re: [U-Boot] [PATCH v3 2/3] serial: ns16550: Add reset ctrl to driver
On Tue, May 8, 2018 at 11:19 AM, Ley Foon Tanwrote: > Add code to reset all reset signals as in serial DT node. A reset property is > an optional feature, > so do not fail if a reset property is not present. > > If a reset property is discovered, then use it to deassert, thus bringing the > IP out of reset. > > Signed-off-by: Ley Foon Tan > Reviewed-by: Marek Vasut > --- > drivers/serial/ns16550.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index 53550bf..9c80090 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -177,6 +178,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) > #if defined(CONFIG_ARCH_OMAP2PLUS) > serial_out(0x7, _port->mdr1); /* mode select reset > TL16C750*/ > #endif > + > serial_out(UART_MCRVAL, _port->mcr); > serial_out(ns16550_getfcr(com_port), _port->fcr); > if (baud_divisor != -1) > @@ -370,6 +372,12 @@ static int ns16550_serial_setbrg(struct udevice *dev, > int baudrate) > int ns16550_serial_probe(struct udevice *dev) > { > struct NS16550 *const com_port = dev_get_priv(dev); > + struct reset_ctl_bulk reset_bulk; > + int ret; > + > + ret = reset_get_bulk(dev, _bulk); > + if (!ret) > + reset_deassert_bulk(_bulk); > > com_port->plat = dev_get_platdata(dev); > NS16550_init(com_port, -1); > -- > 1.7.1 > Hi Tom Can you help to merge this patch if okay with this patch? Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] net: designware: Add reset ctrl to driver
On Wed, May 16, 2018 at 5:08 AM, Joe Hershbergerwrote: > On Mon, May 7, 2018 at 10:19 PM, Ley Foon Tan wrote: >> Add code to reset all reset signals as in Ethernet DT node. A reset property >> is an optional feature, >> so only print out a warning and do not fail if a reset property is not >> present. >> >> If a reset property is discovered, then use it to deassert, thus bringing the >> IP out of reset. >> >> Signed-off-by: Ley Foon Tan > > Acked-by: Joe Hershberger Hi Joe Will you merge this patch to mainline? Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory
From: Ken MaCurrently mvebu sata driver is in arch/arm/mach_mvebu directory, this patch moves it to drivers/ata directory with renaming "sata.c" to "ahci_mvebu.c" which is aligned to Linux. New ahci driver's kconfig option is added as AHCI_MVEBU which selects DM_SCSI. Signed-off-by: Ken Ma --- Changes in v2: - Add MAINTAINERS updating MAINTAINERS| 1 + arch/arm/mach-mvebu/Makefile | 1 - drivers/ata/Kconfig| 9 + drivers/ata/Makefile | 1 + arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++--- 5 files changed, 14 insertions(+), 4 deletions(-) rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%) diff --git a/MAINTAINERS b/MAINTAINERS index 077828c..97c0752 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -134,6 +134,7 @@ S: Maintained T: git git://git.denx.de/u-boot-marvell.git F: arch/arm/mach-kirkwood/ F: arch/arm/mach-mvebu/ +F: drivers/ata/ahci_mvebu.c ARM MARVELL PXA M: Marek Vasut diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index d4210af..7f0d692 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -9,7 +9,6 @@ ifdef CONFIG_ARM64 obj-$(CONFIG_ARMADA_3700) += armada3700/ obj-$(CONFIG_ARMADA_8K) += armada8k/ obj-y += arm64-common.o -obj-y += sata.o else # CONFIG_ARM64 diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 86ec628..9ef4589 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -99,4 +99,13 @@ config SATA_SIL3114 help Enable this driver to support the SIL3114 SATA controllers. +config AHCI_MVEBU + bool "Marvell EBU AHCI SATA support" + depends on ARCH_MVEBU + select DM_SCSI + help + This option enables support for the Marvell EBU SoC's + onboard AHCI SATA. + + If unsure, say N. endmenu diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index a94c804..0254640 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -19,3 +19,4 @@ obj-$(CONFIG_SATA_MV) += sata_mv.o obj-$(CONFIG_SATA_SIL3114) += sata_sil3114.o obj-$(CONFIG_SATA_SIL) += sata_sil.o obj-$(CONFIG_SANDBOX) += sata_sandbox.o +obj-$(CONFIG_AHCI_MVEBU) += ahci_mvebu.o diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c similarity index 89% rename from arch/arm/mach-mvebu/sata.c rename to drivers/ata/ahci_mvebu.c index 5d8032b..5c1b293 100644 --- a/arch/arm/mach-mvebu/sata.c +++ b/drivers/ata/ahci_mvebu.c @@ -1,15 +1,15 @@ /* + * Copyright (C) 2018 Marvell International Ltd. * Copyright (C) 2016 Stefan Roese * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier: GPL-2.0+ + * https://spdx.org/licenses */ #include #include #include -DECLARE_GLOBAL_DATA_PTR; - /* * Dummy implementation that can be overwritten by a board * specific function -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] ahci mvebu driver updates
From: Ken MaThese patches move ahci mvebu driver to drivers/ata directory with bug fixing and scsi supporting. Changes in v2: - Add MAINTAINERS updating David Sniatkiwicz (1): ata: ahci_mvebu: a8040 a0: remove bad port register offsets workarounds Ken Ma (3): ata: mvebu: move mvebu sata driver to drivers/ata directory ata: ahci_mvebu: add scsi support arm64: mvebu: defconfig: enable CONFIG_AHCI_MVEBU MAINTAINERS| 1 + arch/arm/mach-mvebu/Makefile | 1 - configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_db_armada8k_defconfig| 1 + configs/mvebu_espressobin-88f3720_defconfig| 1 + configs/mvebu_mcbin-88f8040_defconfig | 1 + drivers/ata/Kconfig| 9 drivers/ata/Makefile | 1 + .../mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 25 ++ 9 files changed, 31 insertions(+), 10 deletions(-) rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (63%) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] arm64: mvebu: defconfig: enable CONFIG_AHCI_MVEBU
From: Ken MaThis patch enables the new ahci mvebu driver for marvell arm64 platform SOCs(A3k and A8k). Signed-off-by: Ken Ma --- Changes in v2: None configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_db_armada8k_defconfig | 1 + configs/mvebu_espressobin-88f3720_defconfig | 1 + configs/mvebu_mcbin-88f8040_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/mvebu_db-88f3720_defconfig b/configs/mvebu_db-88f3720_defconfig index 1d6233a..d40dd42 100644 --- a/configs/mvebu_db-88f3720_defconfig +++ b/configs/mvebu_db-88f3720_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SCSI_AHCI=y +CONFIG_AHCI_MVEBU=y CONFIG_BLOCK_CACHE=y CONFIG_DM_GPIO=y # CONFIG_MVEBU_GPIO is not set diff --git a/configs/mvebu_db_armada8k_defconfig b/configs/mvebu_db_armada8k_defconfig index da67aad..72c86f3 100644 --- a/configs/mvebu_db_armada8k_defconfig +++ b/configs/mvebu_db_armada8k_defconfig @@ -30,6 +30,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SCSI_AHCI=y +CONFIG_AHCI_MVEBU=y CONFIG_BLOCK_CACHE=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index 314d405..cc41711 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -28,6 +28,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SCSI_AHCI=y +CONFIG_AHCI_MVEBU=y CONFIG_BLOCK_CACHE=y CONFIG_DM_I2C=y CONFIG_MISC=y diff --git a/configs/mvebu_mcbin-88f8040_defconfig b/configs/mvebu_mcbin-88f8040_defconfig index e16a56e..dea0cd0 100644 --- a/configs/mvebu_mcbin-88f8040_defconfig +++ b/configs/mvebu_mcbin-88f8040_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SCSI_AHCI=y +CONFIG_AHCI_MVEBU=y CONFIG_BLOCK_CACHE=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] ata: ahci_mvebu: add scsi support
From: Ken MaMvebu AHCI is AHCI driver which uses SCSI under the hood. This patch adjusts AHCI setup to support SCSI by creating a SCSI device as a child. Signed-off-by: Ken Ma --- Changes in v2: None drivers/ata/ahci_mvebu.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c index 97a04d9..9041a72 100644 --- a/drivers/ata/ahci_mvebu.c +++ b/drivers/ata/ahci_mvebu.c @@ -19,6 +19,20 @@ __weak int board_ahci_enable(void) return 0; } +static int mvebu_ahci_bind(struct udevice *dev) +{ + struct udevice *scsi_dev; + int ret; + + ret = ahci_bind_scsi(dev, _dev); + if (ret) { + debug("%s: Failed to bind (err=%d\n)", __func__, ret); + return ret; + } + + return 0; +} + static int mvebu_ahci_probe(struct udevice *dev) { /* @@ -27,7 +41,7 @@ static int mvebu_ahci_probe(struct udevice *dev) */ board_ahci_enable(); - ahci_init(devfdt_get_addr_ptr(dev)); + ahci_probe_scsi(dev, (ulong)devfdt_get_addr_ptr(dev)); return 0; } @@ -42,5 +56,6 @@ U_BOOT_DRIVER(ahci_mvebu_drv) = { .name = "ahci_mvebu", .id = UCLASS_AHCI, .of_match = mvebu_ahci_ids, + .bind = mvebu_ahci_bind, .probe = mvebu_ahci_probe, }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] ata: ahci_mvebu: a8040 a0: remove bad port register offsets workarounds
From: David SniatkiwiczThis workaround was added for A8040/7040 A0. A8040/7040 A0 is no longer supported so this workaround can be removed. Signed-off-by: David Sniatkiwicz Signed-off-by: Ken Ma --- Changes in v2: None drivers/ata/ahci_mvebu.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c index 5c1b293..97a04d9 100644 --- a/drivers/ata/ahci_mvebu.c +++ b/drivers/ata/ahci_mvebu.c @@ -19,14 +19,6 @@ __weak int board_ahci_enable(void) return 0; } -#ifdef CONFIG_ARMADA_8K -/* CP110 has different AHCI port addresses */ -void __iomem *ahci_port_base(void __iomem *base, u32 port) -{ - return base + 0x1 + (port * 0x1); -} -#endif - static int mvebu_ahci_probe(struct udevice *dev) { /* -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] riscv: dts: Support cfi flash
From: Rick ChenAdd nor node for cfi-flash driver and smc node for smc(aftsmc020) controller. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- arch/riscv/dts/ae350.dts | 12 1 file changed, 12 insertions(+) diff --git a/arch/riscv/dts/ae350.dts b/arch/riscv/dts/ae350.dts index f7d4190..be72b5c 100644 --- a/arch/riscv/dts/ae350.dts +++ b/arch/riscv/dts/ae350.dts @@ -117,6 +117,18 @@ interrupt-parent = <>; }; + smc0: smc@e040 { +compatible = "andestech,atfsmc020"; +reg = <0x0 0xe040 0x0 0x1000>; + }; + + nor@0,0 { +compatible = "cfi-flash"; +reg = <0x0 0x8800 0x0 0x1000>; +bank-width = <2>; +device-width = <1>; + }; + spi: spi@f0b0 { compatible = "andestech,atcspi200"; reg = <0x0 0xf0b0 0x0 0x1000>; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] mtd: ftsmc020: Drop unsed code
From: Rick Chenftsmc020_init is not used anymore. So it can be removed. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- drivers/mtd/Makefile | 1 - drivers/mtd/ftsmc020.c | 38 -- 2 files changed, 39 deletions(-) mode change 100644 => 100755 drivers/mtd/Makefile delete mode 100644 drivers/mtd/ftsmc020.c diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile old mode 100644 new mode 100755 index 20c0d0a..c4ffbe3 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -14,7 +14,6 @@ obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o obj-$(CONFIG_ALTERA_QSPI) += altera_qspi.o obj-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o obj-$(CONFIG_FLASH_CFI_MTD) += cfi_mtd.o -obj-$(CONFIG_FTSMC020) += ftsmc020.o obj-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o obj-$(CONFIG_FLASH_PIC32) += pic32_flash.o diff --git a/drivers/mtd/ftsmc020.c b/drivers/mtd/ftsmc020.c deleted file mode 100644 index e2e8082..000 --- a/drivers/mtd/ftsmc020.c +++ /dev/null @@ -1,38 +0,0 @@ -/* - * (C) Copyright 2009 Faraday Technology - * Po-Yu Chuang - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#include -#include -#include -#include - -struct ftsmc020_config { - unsigned intconfig; - unsigned inttiming; -}; - -static void ftsmc020_setup_bank(unsigned int bank, struct ftsmc020_config *cfg) -{ - struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE; - - if (bank > 3) { - printf("bank # %u invalid\n", bank); - return; - } - - writel(cfg->config, >bank[bank].cr); - writel(cfg->timing, >bank[bank].tpr); -} - -void ftsmc020_init(void) -{ - struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS; - int i; - - for (i = 0; i < ARRAY_SIZE(config); i++) - ftsmc020_setup_bank(i, [i]); -} -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] board: ax25-ae350: Support cfi flash
From: Rick ChenAdd smc_init() to get register base from dts and deal with atfsmc020 controler initialzation job. Write protect is enabled by default. So WP shall be disabled when startup, then cfi flash can be detected and erasing and writing can be executed. Adp-ae3xx and adp-ag101p both do smc initilize job in lowlevel_init.S and get register base fron CONFIG_FTSMC020_BASE. They also can be moved those codes to board stage. Remind them as todo jobs. After that CONFIG_FTSMC020_BASE can be removed. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- board/AndesTech/ax25-ae350/ax25-ae350.c | 34 + 1 file changed, 34 insertions(+) diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c b/board/AndesTech/ax25-ae350/ax25-ae350.c index d2e9bcb..ffec1e1 100644 --- a/board/AndesTech/ax25-ae350/ax25-ae350.c +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c @@ -11,6 +11,8 @@ #include #endif #include +#include +#include DECLARE_GLOBAL_DATA_PTR; @@ -73,3 +75,35 @@ void *board_fdt_blob_setup(void) return (void *)CONFIG_SYS_FDT_BASE; } + +int smc_init(void) +{ + int node = -1; + const char *compat = "andestech,atfsmc020"; + void *blob = (void *)gd->fdt_blob; + fdt_addr_t addr; + struct ftsmc020_bank *regs; + + node = fdt_node_offset_by_compatible(blob, -1, compat); + if (node < 0) + return -FDT_ERR_NOTFOUND; + + addr = fdtdec_get_addr(blob, node, "reg"); + + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; + + regs = (struct ftsmc020_bank *)addr; + regs->cr &= ~FTSMC020_BANK_WPROT; + + return 0; +} + +#ifdef CONFIG_BOARD_EARLY_INIT_F +int board_early_init_f(void) +{ + smc_init(); + + return 0; +} +#endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] configs: ax25-ae350: Support cfi flash
From: Rick ChenEnable cfi flash driver and setup flash parameters to support parallel nor flash which type is JS28F00A-M29EWH. Verification: Size detection, data read, erase and write are all ok. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- configs/ax25-ae350_defconfig | 5 + include/configs/ax25-ae350.h | 38 ++ 2 files changed, 43 insertions(+) mode change 100644 => 100755 include/configs/ax25-ae350.h diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig index 4ceccb7..59919b8 100644 --- a/configs/ax25-ae350_defconfig +++ b/configs/ax25-ae350_defconfig @@ -4,8 +4,10 @@ CONFIG_DEFAULT_DEVICE_TREE="ae350" CONFIG_TARGET_AX25_AE350=y CONFIG_FIT=y CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_F=y # CONFIG_AUTO_COMPLETE is not set CONFIG_SYS_PROMPT="RISC-V # " +CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF=y CONFIG_CMD_SF_TEST=y @@ -25,6 +27,9 @@ CONFIG_MMC=y CONFIG_DM_MMC=y CONFIG_FTSDC010=y CONFIG_FTSDC010_SDIO=y +CONFIG_MTD=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_CFI_FLASH=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h old mode 100644 new mode 100755 index a90c75a..8ce3e6c --- a/include/configs/ax25-ae350.h +++ b/include/configs/ax25-ae350.h @@ -80,6 +80,44 @@ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_0 #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_0 + PHYS_SDRAM_0_SIZE) +/* + * FLASH and environment organization + */ + +/* use CFI framework */ +#define CONFIG_SYS_FLASH_CFI +#define CONFIG_FLASH_CFI_DRIVER + +#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT +#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE +#define CONFIG_SYS_CFI_FLASH_STATUS_POLL + +/* support JEDEC */ +#ifdef CONFIG_CFI_FLASH +#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1 +#endif/* Do not use CONFIG_FLASH_CFI_LEGACY to detect on board flash */ +#define PHYS_FLASH_1 0x8800 /* BANK 0 */ +#define CONFIG_SYS_FLASH_BASE PHYS_FLASH_1 +#define CONFIG_SYS_FLASH_BANKS_LIST{ PHYS_FLASH_1, } +#define CONFIG_SYS_MONITOR_BASEPHYS_FLASH_1 + +#define CONFIG_SYS_FLASH_ERASE_TOUT12 /* TO for Flash Erase (ms) */ +#define CONFIG_SYS_FLASH_WRITE_TOUT500 /* TO for Flash Write (ms) */ + +/* max number of memory banks */ +/* + * There are 4 banks supported for this Controller, + * but we have only 1 bank connected to flash on board +*/ +#ifndef CONFIG_SYS_MAX_FLASH_BANKS_DETECT +#define CONFIG_SYS_MAX_FLASH_BANKS 1 +#endif +#define CONFIG_SYS_FLASH_BANKS_SIZES {0x400} + +/* max number of sectors on one chip */ +#define CONFIG_FLASH_SECTOR_SIZE (0x1*2) +#define CONFIG_SYS_MAX_FLASH_SECT 512 + /* environments */ #define CONFIG_ENV_SPI_BUS 0 #define CONFIG_ENV_SPI_CS 0 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] Add Intel Stratix 10 SoC support
On Wed, May 23, 2018 at 6:00 PM, Marek Vasutwrote: > On 05/23/2018 06:17 PM, Ley Foon Tan wrote: >> This is 3rd version of patchset to adds support for Intel Stratix 10 SoC. >> This patchset is work on top of uboot.git/master and patchset in [1]. >> >> Changes: >> - rebase on uboot.git/master >> - update reviewed-by >> >> Patchset history: >> [v1]: https://patchwork.ozlabs.org/cover/900499/ >> [v2]: https://patchwork.ozlabs.org/cover/916060/ >> >> [1]: https://patchwork.ozlabs.org/cover/910018/ > > Applied, thanks > > -- Thanks! Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-DM] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support
Vabhav, Simon, On Wed, May 23, 2018 at 12:55:41PM -0600, Simon Glass wrote: > Hi, > > On 23 May 2018 at 12:04, Simon Glasswrote: > > On 23 May 2018 at 11:56, Vabhav Sharma wrote: > >> Hello Everyone, > >> > >> I am working on integrating generic PL011 driver in u-boot and linux for > > Note, it is 'U-Boot' > > >> ARMv8 NXP SoC and facing issue with multiple UART console enablement in > >> u-boot using DM model > >> > >> Kindly provide your valuable feedback and experts comments. > >> > >> > >> > >> DTS require stdout-path(e.g-UART0) to the /chosen device tree node > >> ,Accordingly controller(UART0) is probed/initialized as boot console > >> > >> On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for > >> linux boot but kernel hangs after “Starting kernel ... print” > >> > >> > >> > >> After debugging it’s found that UART1 is not initialized and single(first) > >> controller is probed/initialized in u-boot (Irrespective of 4 UART nodes > >> are enabled in dts) > >> > >> In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT > >> stdout-path or CONFIG_CONS_INDEX or platform data(first index) > >> > >> > >> > >> Does the u-boot DM model support only one or multiple UART driver > >> probing/initialization? Is there any configuration parameter required to > >> define number of UART controllers to be probed/initialized. > >> > >> This looks limitation as same boot console is used for u-boot and linux and > >> unable to use all available UART controllers. > >> > >> > >> > >> I am new to u-boot and please correct any misunderstanding > >> > >> Let me know If I can submit a patch for multiple UART probe in > >> serial-uclass > >> or open a bug for multiple UART support in u-boot DM model > > You can probe additional serial drivers if you like. U-Boot only > probes things in a 'lazy' manner so far. Perhaps you could submit a > patch which probes all serial devices? That is just a case of using > uclass_first_device()...uclass_next_device() to iterate through them. > I suppose we could have a CONFIG option to enable this. That would indeed be useful. I was facing a similar issue of having to initialize multiple UARTs, and ended up probing additional instances manually from the board file using the respective DM functions (unreleased code). Not pretty but it worked. I'll be happy to test such a patch if created. -- Andreas Dannenberg Texas Instruments Inc > >> > >> > >> > >> PS:I am unable to find owner of serial uclass driver from MAINTAINERS file > > Not guilty but I did port a lot of things to driver model. > > >> > >> > >> > >> Regards, > >> > >> Vabhav > >> > >> > > Regards, > Simon > ___ > U-Boot-DM mailing list > u-boot...@lists.denx.de > https://lists.denx.de/listinfo/u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: driver support for layerscape
Hi york, Yes, I sent it two days ago, but it's failed to send to u-boot list, so I resend it. Xiaoliang Yang -Original Message- From: York Sun Sent: 2018年5月24日 6:58 To: Xiaoliang Yang; u-boot@lists.denx.de Subject: Re: [PATCH 1/2] watchdog: driver support for layerscape On 05/23/2018 12:52 AM, Xiaoliang Yang wrote: > Support watchdog driver for layerscape. If you want to use it, please > define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG, define > CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout. > > Signed-off-by: Xiaoliang Yang > --- > arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 10 ++ > drivers/watchdog/Makefile |2 +- > drivers/watchdog/imx_watchdog.c| 11 +++ > 3 files changed, 22 insertions(+), 1 deletions(-) > Isn't this the same as you sent two days ago? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: msm: Replace board_prepare_usb with board_usb_init
On Wed, May 23, 2018 at 2:30 AM, Simon Glasswrote: > Hi Ramon, > On 20 May 2018 at 13:04, Ramon Fried wrote: >> Use standard board_usb_init() instead of the specific board_prepare_usb. > > You should mention why... > > For any patch: > - what the problem is / motivation > - what your patch does Sure, thanks. I'll resend the updated patch shortly. Thanks, Ramon > >> >> Signed-off-by: Ramon Fried >> --- >> board/qualcomm/dragonboard410c/dragonboard410c.c | 4 ++-- >> drivers/usb/host/ehci-msm.c | 11 --- >> 2 files changed, 6 insertions(+), 9 deletions(-) >> > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] board: arm: Add support for Broadcom BCM7445
Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas FitzsimmonsCc: Stefan Roese Cc: Tom Rini Cc: Florian Fainelli --- Changes for v2: - Reorganize Kconfig to create ARCH_BCMSTB - Use generic bcmstb SoC name wherever possible - Eliminate crt0.S changes by moving relocation logic to bcmstb.c - Use debug() macro where appropriate - Read bcmstb_spi register base addresses from prior stage device tree, where possible - Read bcmstb_sdhci register base address from prior stage DT - Make timer register addresses configurable - Fix BOLT typos - Eliminate CONFIG_BCMSTB_ACCOMMODATE_STBLINUX by keeping FIT initramfs and device tree binary in-place - Add README.bcm7xxx - Read memory configuration from prior stage device tree - Add CONFIG_OF_PRIOR_STAGE support in spi-uclass.c - Fix issues reported by checkpatch.pl - Fix issues reported by sparse - Update some comments and formatting - Add a MAINTAINERS file arch/arm/Kconfig| 12 + arch/arm/Makefile | 1 + arch/arm/mach-bcmstb/Kconfig| 64 arch/arm/mach-bcmstb/Makefile | 9 + arch/arm/mach-bcmstb/include/mach/gpio.h| 12 + arch/arm/mach-bcmstb/include/mach/hardware.h| 12 + arch/arm/mach-bcmstb/include/mach/prior_stage.h | 31 ++ arch/arm/mach-bcmstb/include/mach/sdhci.h | 16 + arch/arm/mach-bcmstb/include/mach/timer.h | 14 + arch/arm/mach-bcmstb/lowlevel_init.S| 22 ++ board/broadcom/bcmstb/MAINTAINERS | 6 + board/broadcom/bcmstb/Makefile | 9 + board/broadcom/bcmstb/bcmstb.c | 192 +++ configs/bcm7445_defconfig | 27 ++ doc/README.bcm7xxx | 147 drivers/mmc/Kconfig | 11 + drivers/mmc/Makefile| 1 + drivers/mmc/bcmstb_sdhci.c | 68 drivers/spi/Kconfig | 7 + drivers/spi/Makefile| 1 + drivers/spi/bcmstb_spi.c| 440 drivers/spi/spi-uclass.c| 2 +- dts/Kconfig | 7 + include/configs/bcmstb.h| 189 ++ include/fdtdec.h| 4 + lib/fdtdec.c| 4 + 26 files changed, 1307 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-bcmstb/Kconfig create mode 100644 arch/arm/mach-bcmstb/Makefile create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S create mode 100644 board/broadcom/bcmstb/MAINTAINERS create mode 100644 board/broadcom/bcmstb/Makefile create mode 100644 board/broadcom/bcmstb/bcmstb.c create mode 100644 configs/bcm7445_defconfig create mode 100644 doc/README.bcm7xxx create mode 100644 drivers/mmc/bcmstb_sdhci.c create mode 100644 drivers/spi/bcmstb_spi.c create mode 100644 include/configs/bcmstb.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9bd70f4..fa3089f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -498,6 +498,16 @@ config TARGET_VEXPRESS_CA15_TC2 select CPU_V7_HAS_VIRT select PL011_SERIAL +config ARCH_BCMSTB + bool "Broadcom BCM7XXX family" + select CPU_V7 + select DM + select OF_CONTROL + select OF_PRIOR_STAGE + help + This enables support for Broadcom ARM-based set-top box + chipsets, including the 7445 family of chips. + config TARGET_VEXPRESS_CA5X2 bool "Support vexpress_ca5x2" select CPU_V7 @@ -1237,6 +1247,8 @@ source "arch/arm/mach-at91/Kconfig" source "arch/arm/mach-bcm283x/Kconfig" +source "arch/arm/mach-bcmstb/Kconfig" + source "arch/arm/mach-davinci/Kconfig" source "arch/arm/mach-exynos/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 4fa8b38..b0cd152 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -53,6 +53,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y) machine-$(CONFIG_ARCH_ASPEED) += aspeed machine-$(CONFIG_ARCH_AT91)+= at91 machine-$(CONFIG_ARCH_BCM283X) += bcm283x +machine-$(CONFIG_ARCH_BCMSTB) += bcmstb machine-$(CONFIG_ARCH_DAVINCI) += davinci
[U-Boot] [PATCH v2 0/1] board: arm: Add support for Broadcom BCM7445
Add support for Broadcom BCM7445 Changes for v2: - Reorganize Kconfig to create ARCH_BCMSTB - Use generic bcmstb SoC name wherever possible - Eliminate crt0.S changes by moving relocation logic to bcmstb.c - Use debug() macro where appropriate - Read bcmstb_spi register base addresses from prior stage device tree, where possible - Read bcmstb_sdhci register base address from prior stage DT - Make timer register addresses configurable - Fix BOLT typos - Eliminate CONFIG_BCMSTB_ACCOMMODATE_STBLINUX by keeping FIT initramfs and device tree binary in-place - Add README.bcm7xxx - Read memory configuration from prior stage device tree - Add CONFIG_OF_PRIOR_STAGE support in spi-uclass.c - Fix issues reported by checkpatch.pl - Fix issues reported by sparse - Update some comments and formatting - Add a MAINTAINERS file Thomas Fitzsimmons (1): board: arm: Add support for Broadcom BCM7445 arch/arm/Kconfig| 12 + arch/arm/Makefile | 1 + arch/arm/mach-bcmstb/Kconfig| 64 arch/arm/mach-bcmstb/Makefile | 9 + arch/arm/mach-bcmstb/include/mach/gpio.h| 12 + arch/arm/mach-bcmstb/include/mach/hardware.h| 12 + arch/arm/mach-bcmstb/include/mach/prior_stage.h | 31 ++ arch/arm/mach-bcmstb/include/mach/sdhci.h | 16 + arch/arm/mach-bcmstb/include/mach/timer.h | 14 + arch/arm/mach-bcmstb/lowlevel_init.S| 22 ++ board/broadcom/bcmstb/MAINTAINERS | 6 + board/broadcom/bcmstb/Makefile | 9 + board/broadcom/bcmstb/bcmstb.c | 192 +++ configs/bcm7445_defconfig | 27 ++ doc/README.bcm7xxx | 147 drivers/mmc/Kconfig | 11 + drivers/mmc/Makefile| 1 + drivers/mmc/bcmstb_sdhci.c | 68 drivers/spi/Kconfig | 7 + drivers/spi/Makefile| 1 + drivers/spi/bcmstb_spi.c| 440 drivers/spi/spi-uclass.c| 2 +- dts/Kconfig | 7 + include/configs/bcmstb.h| 189 ++ include/fdtdec.h| 4 + lib/fdtdec.c| 4 + 26 files changed, 1307 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-bcmstb/Kconfig create mode 100644 arch/arm/mach-bcmstb/Makefile create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S create mode 100644 board/broadcom/bcmstb/MAINTAINERS create mode 100644 board/broadcom/bcmstb/Makefile create mode 100644 board/broadcom/bcmstb/bcmstb.c create mode 100644 configs/bcm7445_defconfig create mode 100644 doc/README.bcm7xxx create mode 100644 drivers/mmc/bcmstb_sdhci.c create mode 100644 drivers/spi/bcmstb_spi.c create mode 100644 include/configs/bcmstb.h -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: ftsdc010_mci: Sync compatible with DT mmc node
From: Rick ChenThe compatible string of ftsdc010_mci.c is different from the mmc driver in Linux Kernel. Modify it for consistency. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- drivers/mmc/ftsdc010_mci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c index 9de3a15..f98472c 100644 --- a/drivers/mmc/ftsdc010_mci.c +++ b/drivers/mmc/ftsdc010_mci.c @@ -464,7 +464,7 @@ int ftsdc010_mmc_bind(struct udevice *dev) } static const struct udevice_id ftsdc010_mmc_ids[] = { - { .compatible = "andestech,atsdc010" }, + { .compatible = "andestech,atfsdc010" }, { } }; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] riscv: dts: Sync DT with Linux Kernel
From: Rick ChenUse same dts to boot U-Boot and RISC-V Linux Kernel v4.16-rc2 in ax25-ae350 platform. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Cc: Greentime Hu --- arch/riscv/dts/ae350.dts | 204 --- 1 file changed, 122 insertions(+), 82 deletions(-) diff --git a/arch/riscv/dts/ae350.dts b/arch/riscv/dts/ae350.dts index 4bfb876..f7d4190 100644 --- a/arch/riscv/dts/ae350.dts +++ b/arch/riscv/dts/ae350.dts @@ -1,97 +1,137 @@ /dts-v1/; + / { - compatible = "riscv32 ax25"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <>; + #address-cells = <2>; + #size-cells = <2>; + compatible = "andestech,ax25"; + model = "andestech,ax25"; + + aliases { +uart0 = +spi0 = + } ; + + chosen { +bootargs = "console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf030 debug loglevel=7"; +stdout-path = "uart0:38400n8"; + }; - aliases { - uart0 = - ethernet0 = - spi0 = - } ; + cpus { +#address-cells = <1>; +#size-cells = <0>; +timebase-frequency = <1000>; +CPU0: cpu@0 { + device_type = "cpu"; + reg = <0>; + status = "okay"; + compatible = "riscv"; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv39"; + clock-frequency = <6000>; + CPU0_intc: interrupt-controller { +#interrupt-cells = <1>; +interrupt-controller; +compatible = "riscv,cpu-intc"; + }; +}; + }; - chosen { - bootargs = "console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf030 debug loglevel=7"; - stdout-path = "uart0:38400n8"; - tick-timer = - }; + memory@0 { +device_type = "memory"; +reg = <0x0 0x 0x0 0x4000>; + }; - memory@0 { - device_type = "memory"; - reg = <0x 0x4000>; - }; + soc { +#address-cells = <2>; +#size-cells = <2>; +compatible = "andestech,riscv-ae350-soc"; +ranges; + }; - spiclk: virt_100mhz { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <1>; - }; + plmt0@e600 { +compatible = "riscv,plmt0"; +interrupts-extended = <_intc 7>; +reg = <0x0 0xe600 0x0 0x10>; + }; - cpus { - #address-cells = <1>; - #size-cells = <0>; - cpu@0 { - compatible = "andestech,n13"; - reg = <0>; - /* FIXME: to fill correct frqeuency */ - clock-frequency = <6000>; - }; - }; + plic0: interrupt-controller@e400 { +compatible = "riscv,plic0"; +#address-cells = <2>; +#interrupt-cells = <2>; +interrupt-controller; +reg = <0x0 0xe400 0x0 0x200>; +riscv,ndev=<31>; +interrupts-extended = <_intc 11 _intc 9>; + }; - intc: interrupt-controller { - compatible = "andestech,atnointc010"; - #interrupt-cells = <1>; - interrupt-controller; - }; + plic1: interrupt-controller@e640 { +compatible = "riscv,plic1"; +#address-cells = <2>; +#interrupt-cells = <2>; +interrupt-controller; +reg = <0x0 0xe640 0x0 0x40>; +riscv,ndev=<1>; +interrupts-extended = <_intc 3>; + }; - serial0: serial@f030 { - compatible = "andestech,uart16550", "ns16550a"; - reg = <0xf030 0x1000>; - interrupts = <7 4>; - clock-frequency = <19660800>; - reg-shift = <2>; - reg-offset = <32>; - no-loopback-test = <1>; - }; + spiclk: virt_100mhz { +#clock-cells = <0>; +compatible = "fixed-clock"; +clock-frequency = <1>; + }; - timer0: timer@f040 { - compatible = "andestech,atcpit100"; - reg = <0xf040 0x1000>; - interrupts = <2 4>; - clock-frequency = <4000>; - }; + timer0: timer@f040 { +compatible = "andestech,atcpit100"; +reg = <0x0 0xf040 0x0 0x1000>; +clock-frequency = <4000>; +interrupts = <3 4>; +interrupt-parent = <>; + }; - mac0: mac@e010 { - compatible = "andestech,atmac100"; - reg = <0xe010 0x1000>; - interrupts = <25 4>; - }; + serial0: serial@f030 { +compatible = "andestech,uart16550", "ns16550a"; +reg = <0x0 0xf030 0x0 0x1000>; +interrupts = <9 4>; +clock-frequency = <19660800>; +reg-shift = <2>; +reg-offset = <32>; +no-loopback-test = <1>; +interrupt-parent = <>; + }; - mmc0: mmc@f0e0 { - compatible =
Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0
Tom Riniwrites: > On Sun, May 06, 2018 at 07:09:22AM -0400, Thomas Fitzsimmons wrote: > >> Add support for loading U-Boot on the Broadcom 7445D0 SoC. This port >> assumes Broadcom's BOLT bootloader is acting as the second stage >> bootloader, and U-Boot is acting as the third stage bootloader, loaded >> as an ELF program by BOLT. >> >> Signed-off-by: Thomas Fitzsimmons >> Cc: Stefan Roese > [snip] >> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S >> index fa81317..f1a6f35 100644 >> --- a/arch/arm/lib/crt0.S >> +++ b/arch/arm/lib/crt0.S >> @@ -94,6 +94,7 @@ ENTRY(_main) >> * 'here' but relocated. >> */ >> >> +#if !defined(CONFIG_OF_PRIOR_STAGE) >> ldr r0, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ >> bic r0, r0, #7 /* 8-byte alignment for ABI compliance */ >> mov sp, r0 >> @@ -108,6 +109,7 @@ ENTRY(_main) >> #endif >> ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ >> b relocate_code >> +#endif >> here: >> /* >> * now relocate vectors > > Can you explain this bit a good bit more? When BOLT loads U-Boot as an ELF program, this relocation code hangs -- I haven't found out why yet -- but if I skip the relocation, U-Boot runs successfully. I figured out a different approach to preventing the relocation, one that only requires logic in an SoC-specific file, so v2 of the patch will not have any crt0.S changes. >> +config BCHP_BSPI_MAST_N_BOOT_CTRL >> +hex "" >> +default 0x003e3208 > > Doing hex "" seems wrong. What are you doing here exactly? I've reorganized all these into more appropriate locations, and documented all the remaining Kconfig items, which you'll see in the v2 patch I'll post shortly. >> diff --git a/common/fdt_support.c b/common/fdt_support.c >> index 66a313e..f07dfe3 100644 >> --- a/common/fdt_support.c >> +++ b/common/fdt_support.c >> @@ -242,11 +242,13 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong >> initrd_end) >> } >> } >> >> +#if !defined(CONFIG_BCMSTB_ACCOMMODATE_STBLINUX) >> err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start); >> if (err < 0) { >> printf("fdt_initrd: %s\n", fdt_strerror(err)); >> return err; >> } >> +#endif > > Why do we need this? The background is that stblinux is designed to use some physical memory for Linux itself, and leave the rest of physical memory for direct use by video decode blocks in the SoC. Basically, without making accommodations for it in U-Boot, stblinux will allocate less memory for use by the video decode blocks than is actually available, even if it could safely allocate more. In v2 of the patch, I've documented a different approach to loading FIT images (one that keeps the RFS and DTB in-place), which eliminates the need for this configuration macro. >> +#ifdef DEBUG >> +static int debug_tx_rx; >> +#define D(fmt, args...) debug_cond(debug_tx_rx, fmt, ##args) >> +#else >> +#define D(fmt, args...) >> +#endif > > We have dbg() etc, please use. Thanks! OK, done in v2 of the patch. Thanks for reviewing, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 05/23/2018 10:51 PM, DATACOM - Paulo.Zaneti wrote: > > > On 23/05/2018 15:00, Marek Vasut wrote: >> On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote: >>> >>> On 23/05/2018 14:43, Marek Vasut wrote: On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: > On 23/05/2018 14:03, Marek Vasut wrote: >> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >>> Hi, >> Hi, >> >>> When trying to migrate a board from u-boot version 2016.09 to >>> version >>> 2018.03, I found a problem with a USB 2.0 device which used to >>> work on >>> version 2016.09. >> Does it still happen in u-boot/master ? > Yes, it still happens. > > I just tested it with the following commit: > dca268a .travis.yml: Further optimizations >>> In u-boot version 2016.09 the device appears like this: >>> >>> 2: Mass Storage, USB Revision 2.0 >>> - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is. Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks. >>> No, it is a NXP T1024 SoC. >>> Do you think it may be a problem with the SoC or NXP USB host driver ? >>> >> So that's chipidea ? That one should be reasonably sane. > I don't think so. It uses following drivers: > drivers/usb/host/ehci-fsl.c > drivers/usb/host/ehci-hcd.c Should be chipidea IP. >> Submit the patch you had in mind and let's see what happens. > I just noticed that this stick needs more time after the > usb_set_address() call. > I increased the mdelay(10) to mdelay(20) and the "usb start" command > worked. > But the problem is that I am still not convinced that this should be the > solution. Try setenv usb_pgood_delay 1 ; usb reset then ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
Hi, On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zanetiwrote: > > > On 23/05/2018 15:00, Marek Vasut wrote: >> >> On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote: >>> >>> >>> On 23/05/2018 14:43, Marek Vasut wrote: On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: > > On 23/05/2018 14:03, Marek Vasut wrote: >> >> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >>> >>> Hi, >> >> Hi, >> >>> When trying to migrate a board from u-boot version 2016.09 to version >>> 2018.03, I found a problem with a USB 2.0 device which used to work >>> on >>> version 2016.09. >> >> Does it still happen in u-boot/master ? > > Yes, it still happens. > > I just tested it with the following commit: > dca268a .travis.yml: Further optimizations >>> >>> In u-boot version 2016.09 the device appears like this: >>> >>> 2: Mass Storage, USB Revision 2.0 >>> - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is. Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks. >>> >>> No, it is a NXP T1024 SoC. >>> Do you think it may be a problem with the SoC or NXP USB host driver ? >>> >> So that's chipidea ? That one should be reasonably sane. > > I don't think so. It uses following drivers: > drivers/usb/host/ehci-fsl.c > drivers/usb/host/ehci-hcd.c > >> >> Submit the patch you had in mind and let's see what happens. > > I just noticed that this stick needs more time after the usb_set_address() > call. > I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. > But the problem is that I am still not convinced that this should be the > solution. > Agreed. Can you bisect to see which commit broke your stick? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: driver support for layerscape
On 05/23/2018 12:52 AM, Xiaoliang Yang wrote: > Support watchdog driver for layerscape. If you want to use it, > please define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG, > define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout. > > Signed-off-by: Xiaoliang Yang> --- > arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 10 ++ > drivers/watchdog/Makefile |2 +- > drivers/watchdog/imx_watchdog.c| 11 +++ > 3 files changed, 22 insertions(+), 1 deletions(-) > Isn't this the same as you sent two days ago? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 23/05/2018 15:00, Marek Vasut wrote: On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote: On 23/05/2018 14:43, Marek Vasut wrote: On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: On 23/05/2018 14:03, Marek Vasut wrote: On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: Hi, Hi, When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09. Does it still happen in u-boot/master ? Yes, it still happens. I just tested it with the following commit: dca268a .travis.yml: Further optimizations In u-boot version 2016.09 the device appears like this: 2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is. Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks. No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ? So that's chipidea ? That one should be reasonably sane. I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c Submit the patch you had in mind and let's see what happens. I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dlmalloc: ensure gd is set for early free
Hi Stephen, On Wed, May 23, 2018 at 01:32:53PM -0600, Stephen Warren wrote: > On 05/23/2018 01:07 PM, Eugeniu Rosca wrote: > >This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc: > >ensure gd is set for early alloc"). Here is a gdb backtrace to make them > >look even more similar (sandbox build): > ... > >Interestingly, this issue appears on a very old v2015.04 U-boot, but > >not on u-boot/master (even if the fix applies cleanly to u-boot/master). > >With the patch applied, my ancient u-boot starts to work properly: > > That's probably because of 2f0bcd4de1ab0cb03f01428a334cd91f8870504c "malloc: > use hidden visibility" which prevents code outside of U-Boot from using > U-Boot's malloc/free? This fixes my issue in apparently much cleaner way. Thanks! The break down of sandbox into phases is very informative. Like the comments/code ratio. > (I only remember this because I very recently bisected an issue in an old > branch that caused sandbox crashes after upgrading the OS on a test machine > and triggering the bug that commit fixes.) Thanks again! Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: Unirqify bcm2835_sdhost and fix writes
The bcm2835 sdhost driver has a problem with "write multiple" commands. It seems to boil down to the fact that the controller dislikes its FIFO to get drained at the end of a block when a write multiple blocks command is in flight. The easy fix is to simply get rid of all the IRQ driven logic and make the driver push as much data into the FIFO as it can. That way we never drain and we never run into the problem. Reported-by: Jan LeonhardtSigned-off-by: Alexander Graf --- drivers/mmc/bcm2835_sdhost.c | 265 --- 1 file changed, 47 insertions(+), 218 deletions(-) diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c index 96428333b0..1ce019af57 100644 --- a/drivers/mmc/bcm2835_sdhost.c +++ b/drivers/mmc/bcm2835_sdhost.c @@ -163,7 +163,6 @@ struct bcm2835_host { int clock; /* Current clock speed */ unsigned intmax_clk;/* Max possible freq */ unsigned intblocks; /* remaining PIO blocks */ - int irq;/* Device IRQ */ u32 ns_per_fifo_word; @@ -173,14 +172,7 @@ struct bcm2835_host { struct mmc_cmd *cmd; /* Current command */ struct mmc_data *data; /* Current data request */ - booldata_complete:1;/* Data finished before cmd */ booluse_busy:1; /* Wait for busy interrupt */ - boolwait_data_complete:1; /* Wait for data */ - - /* for threaded irq handler */ - boolirq_block; - boolirq_busy; - boolirq_data; struct udevice *dev; struct mmc *mmc; @@ -240,17 +232,9 @@ static void bcm2835_reset_internal(struct bcm2835_host *host) writel(host->cdiv, host->ioaddr + SDCDIV); } -static int bcm2835_finish_command(struct bcm2835_host *host); - -static void bcm2835_wait_transfer_complete(struct bcm2835_host *host) +static int bcm2835_wait_transfer_complete(struct bcm2835_host *host) { - int timediff; - u32 alternate_idle; - - alternate_idle = (host->data->flags & MMC_DATA_READ) ? - SDEDM_FSM_READWAIT : SDEDM_FSM_WRITESTART1; - - timediff = 0; + int timediff = 0; while (1) { u32 edm, fsm; @@ -261,7 +245,10 @@ static void bcm2835_wait_transfer_complete(struct bcm2835_host *host) if ((fsm == SDEDM_FSM_IDENTMODE) || (fsm == SDEDM_FSM_DATAMODE)) break; - if (fsm == alternate_idle) { + + if ((fsm == SDEDM_FSM_READWAIT) || + (fsm == SDEDM_FSM_WRITESTART1) || + (fsm == SDEDM_FSM_READDATA)) { writel(edm | SDEDM_FORCE_DATA_MODE, host->ioaddr + SDEDM); break; @@ -273,9 +260,11 @@ static void bcm2835_wait_transfer_complete(struct bcm2835_host *host) "wait_transfer_complete - still waiting after %d retries\n", timediff); bcm2835_dumpregs(host); - return; + return -ETIMEDOUT; } } + + return 0; } static int bcm2835_transfer_block_pio(struct bcm2835_host *host, bool is_read) @@ -322,6 +311,9 @@ static int bcm2835_transfer_block_pio(struct bcm2835_host *host, bool is_read) fsm_state != SDEDM_FSM_READCRC)) || (!is_read && (fsm_state != SDEDM_FSM_WRITEDATA && + fsm_state != SDEDM_FSM_WRITEWAIT1 && + fsm_state != SDEDM_FSM_WRITEWAIT2 && + fsm_state != SDEDM_FSM_WRITECRC && fsm_state != SDEDM_FSM_WRITESTART1 && fsm_state != SDEDM_FSM_WRITESTART2))) { hsts = readl(host->ioaddr + SDHSTS); @@ -358,9 +350,8 @@ static int bcm2835_transfer_pio(struct bcm2835_host *host) is_read = (host->data->flags & MMC_DATA_READ) != 0; ret = bcm2835_transfer_block_pio(host, is_read); - - if (host->wait_data_complete) - bcm2835_wait_transfer_complete(host); + if (ret) + return ret; sdhsts = readl(host->ioaddr + SDHSTS); if (sdhsts & (SDHSTS_CRC16_ERROR | @@ -379,21 +370,8 @@ static int bcm2835_transfer_pio(struct bcm2835_host *host) return ret; } -static void bcm2835_set_transfer_irqs(struct bcm2835_host *host) -{ - u32 all_irqs = SDHCFG_DATA_IRPT_EN | SDHCFG_BLOCK_IRPT_EN | - SDHCFG_BUSY_IRPT_EN; - - host->hcfg = (host->hcfg & ~all_irqs) | -
Re: [U-Boot] [PATCH] dlmalloc: ensure gd is set for early free
On 05/23/2018 01:07 PM, Eugeniu Rosca wrote: This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc: ensure gd is set for early alloc"). Here is a gdb backtrace to make them look even more similar (sandbox build): ... Interestingly, this issue appears on a very old v2015.04 U-boot, but not on u-boot/master (even if the fix applies cleanly to u-boot/master). With the patch applied, my ancient u-boot starts to work properly: That's probably because of 2f0bcd4de1ab0cb03f01428a334cd91f8870504c "malloc: use hidden visibility" which prevents code outside of U-Boot from using U-Boot's malloc/free? (I only remember this because I very recently bisected an issue in an old branch that caused sandbox crashes after upgrading the OS on a test machine and triggering the bug that commit fixes.) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dlmalloc: ensure gd is set for early free
This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc: ensure gd is set for early alloc"). Here is a gdb backtrace to make them look even more similar (sandbox build): (gdb) run Starting program: /path/to/u-boot [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x004123c0 in free (mem=0x0) at common/dlmalloc.c:2460 2460 if (mem == NULL) /* free(0) has no effect */ (gdb) where #0 0x004123c0 in free (mem=0x0) at common/dlmalloc.c:2460 #1 0x73f46cea in ?? () from /lib/x86_64-linux-gnu/libselinux.so.1 #2 0x77de76ba in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffd928, env=env@entry=0x7fffd938) at dl-init.c:72 #3 0x77de77cb in call_init (env=0x7fffd938, argv=0x7fffd928, argc=1, l=) at dl-init.c:30 #4 _dl_init (main_map=0x77ffe168, argc=1, argv=0x7fffd928, env=0x7fffd938) at dl-init.c:120 #5 0x77dd7c6a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #6 0x0001 in ?? () #7 0x7fffddbb in ?? () #8 0x in ?? () Interestingly, this issue appears on a very old v2015.04 U-boot, but not on u-boot/master (even if the fix applies cleanly to u-boot/master). With the patch applied, my ancient u-boot starts to work properly: $ ./u-boot U-Boot 2015.04-00280-g5755c9e48b83 (May 23 2018 - 20:53:31) DRAM: 128 MiB Using default environment In:serial Out: lcd Err: lcd => Signed-off-by: Eugeniu Rosca--- common/dlmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index b395eefbf862..6012f9f162c0 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1524,7 +1524,7 @@ void fREe(mem) Void_t* mem; #if CONFIG_VAL(SYS_MALLOC_F_LEN) /* free() is a no-op - all the memory will be freed on relocation */ - if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) + if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) return; #endif -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support
Hi, On 23 May 2018 at 12:04, Simon Glasswrote: > On 23 May 2018 at 11:56, Vabhav Sharma wrote: >> Hello Everyone, >> >> I am working on integrating generic PL011 driver in u-boot and linux for Note, it is 'U-Boot' >> ARMv8 NXP SoC and facing issue with multiple UART console enablement in >> u-boot using DM model >> >> Kindly provide your valuable feedback and experts comments. >> >> >> >> DTS require stdout-path(e.g-UART0) to the /chosen device tree node >> ,Accordingly controller(UART0) is probed/initialized as boot console >> >> On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for >> linux boot but kernel hangs after “Starting kernel ... print” >> >> >> >> After debugging it’s found that UART1 is not initialized and single(first) >> controller is probed/initialized in u-boot (Irrespective of 4 UART nodes >> are enabled in dts) >> >> In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT >> stdout-path or CONFIG_CONS_INDEX or platform data(first index) >> >> >> >> Does the u-boot DM model support only one or multiple UART driver >> probing/initialization? Is there any configuration parameter required to >> define number of UART controllers to be probed/initialized. >> >> This looks limitation as same boot console is used for u-boot and linux and >> unable to use all available UART controllers. >> >> >> >> I am new to u-boot and please correct any misunderstanding >> >> Let me know If I can submit a patch for multiple UART probe in serial-uclass >> or open a bug for multiple UART support in u-boot DM model You can probe additional serial drivers if you like. U-Boot only probes things in a 'lazy' manner so far. Perhaps you could submit a patch which probes all serial devices? That is just a case of using uclass_first_device()...uclass_next_device() to iterate through them. I suppose we could have a CONFIG option to enable this. >> >> >> >> PS:I am unable to find owner of serial uclass driver from MAINTAINERS file Not guilty but I did port a lot of things to driver model. >> >> >> >> Regards, >> >> Vabhav >> >> Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: allow CONFIG_DEFAULT_FDT_FILE override
On 05/17/2018 05:01 AM, Maxime Ripard wrote: On Tue, May 01, 2018 at 05:46:41PM -0700, Martin Kelly wrote: Currently, sunxi-common.h ignores CONFIG_DEFAULT_FDT_FILE and assumes the kernel fdtfile and the u-boot devicetree names are the same. Although this is typically the case, sometimes you might want to customize one of these differently, so it's useful to allow them to be different. Add logic in sunxi-common.h to respect CONFIG_DEFAULT_FDT_FILE, if set, and default to the values it currently uses. Signed-off-by: Martin KellyAcked-by: Maxime Ripard Maxime (ping) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 23/05/2018 14:43, Marek Vasut wrote: On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: On 23/05/2018 14:03, Marek Vasut wrote: On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: Hi, Hi, When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09. Does it still happen in u-boot/master ? Yes, it still happens. I just tested it with the following commit: dca268a .travis.yml: Further optimizations In u-boot version 2016.09 the device appears like this: 2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is. Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks. No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 23/05/2018 14:03, Marek Vasut wrote: On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: Hi, Hi, When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09. Does it still happen in u-boot/master ? Yes, it still happens. I just tested it with the following commit: dca268a .travis.yml: Further optimizations In u-boot version 2016.09 the device appears like this: 2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5567 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 200mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 But in version 2018.03 I just can't start usb. It fails with following error: => usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found I did a "git bisect" and found that this problem is related to the following commit: c008faa usb: Only get 64 bytes device descriptor for full speed devices I am not an expert on USB, so I would like to ask for help on this issue. In u-boot v2018.03, file common/usb.c, line 973, shouldn't the comparison be like this: if (do_read && dev->speed >= USB_SPEED_FULL) { or, at list: if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == USB_SPEED_HIGH)) { I would submit a patch for this, but I lack on USB knowledge for explaining the patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Wednesday, May 23, 2018 2:49 AM > To: Manjukumar Harthikote Matha; Rajan Vaja > > Cc: mon...@monstr.eu; Albert Aribaud ; Jolly Shah > ; Michal Simek ; u- > b...@lists.denx.de; Moritz Fischer > Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0 > > On 05/22/2018 06:44 PM, Manjukumar Harthikote Matha wrote: > [...] > >> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 > >> (the one on github, not the one on git.yoctoproject) without version > >> which provides the ABI 1.0 rather than the v2017.03 one from > >> meta-xilinx rel-v2018.1. And then the new release of meta-xilinx > >> rel-v2018.2 will get PMUFW v2018.1 . > >> > >> But why is such vital component as the working PMUFW recipe stashed > >> in some other repo than meta-xilinx , while meta-xilinx contains a > >> non working one is not clear to me. Anyway. > >> > > > > Release branches in github are related to Xilinx tools release to > > support PetaLinux, xsct etc The flow using github release uses a layer > > stack and how to use is documented here > > > http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct > o > > and manifest is here > > https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1 > > > > We don’t support a flow where you use only one layer instead of the entire > stack. > > Then the obvious question is, why is it not a single metalayer ... > The proposal was sent out, there are dependencies on why the merge has not happened https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-November/003309.html We plan to resolve in the next release (Thud) > >> It is also becoming less and less clear to me which PMUFW provides > >> which ABI based on the recipe versions, since they do not reflect the > >> ABI in any way. And, back to my original question-ish, there is an > >> ABI break between PMUFW v0.3 and PMUFW v1.0 which may render systems > >> unbootable if everything is not updated in tandem, right ? > >> > > > > I was not aware of the breakage, I will have to check. > > Try using mainline U-Boot 2018.05 with PMUFW v0.3 and load FPGA image from > U-Boot, it'll fail. > > > If you use our entire layer stack for rel-v2018.1 (manifest) then you > > shouldn’t > see the issue. > > > > As far as master branch is considred, we are in process of updating it for > > sumo > release. > > If you are on mailing list, you will see the patches sent for review and is > > on 4th > version. > > We hope to get it merged if there are no hiccups by end of week. > > See : > > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.h > > tml > > See: > > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.h > > tml > > Great > > btw I presume you do mean OpenEmbedded. > > >>> > >>> > >>> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ > >>> > >>> > >> So it's this pmu-firmware_git recipe which provides different ABI > >> in different versions of meta-xilinx-bsp, yet this is not in any > >> way indicated by the package version, right ? > > > > Didn’t get what you mean here? Package version is set according to > > the release under use > > https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xs > > ctap > > p.bbclass#L9 > > Ah, I see, so unlike any other regular recipe which encodes the > version in the recipe file name, Xilinx stuff has custom class > which is inherited into version- > >> less > recipe and sets the version. This is horrid. > > >>> > >>> Not true, any recipe which includes version can be in an include > >>> file or in a class > >> or in a conf file. > >>> There is no strict guidelines on where this version should be set > >>> (recipe, include, > >> conf or class). > >>> Just because you are familiar with one way of doing things, does not > >>> mean > >> everything else is horrid. > >> > >> Well, I think I've seen my share of recipes over the years, both good > >> and bad. OE gives the user a lot of freedom to do all kinds of hacks, > >> which still doesn't mean it's a good idea to do them. > >> > >> Writing your own bbclass as a sort-of header file to be included by a > >> recipe is one of the bad ideas. With the ABI break at hand, there is > >> also no migration strategy for this PMUFW recipe, the platform just > >> breaks during the update and stops booting or misbehaves, which is > >> grueling. > >> > > > > The same class is shared for multiple components, FSBL, DTG etc hence > > the reasoning to use a class However, this something for us to consider and > work in future releases. > > This seems to be long overdue > Debatable according to me. > > This should indicate, release version with a part of commit id of > > git being > >>
[U-Boot] usb: Fail to get descriptor for USB 2.0 device
Hi, When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09. In u-boot version 2016.09 the device appears like this: 2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5567 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 200mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 But in version 2018.03 I just can't start usb. It fails with following error: => usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found I did a "git bisect" and found that this problem is related to the following commit: c008faa usb: Only get 64 bytes device descriptor for full speed devices I am not an expert on USB, so I would like to ask for help on this issue. In u-boot v2018.03, file common/usb.c, line 973, shouldn't the comparison be like this: if (do_read && dev->speed >= USB_SPEED_FULL) { or, at list: if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == USB_SPEED_HIGH)) { I would submit a patch for this, but I lack on USB knowledge for explaining the patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler
> -Original Message- > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] > Sent: Wednesday, May 23, 2018 3:30 AM > To: Bin Meng> Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Moore, Robert ; Sami > Mujawar ; Evan Lloyd > Subject: Re: [PATCH v1] x86: acpi: Adopt new version of iASL compiler > > On Wed, 2018-05-23 at 18:22 +0800, Bin Meng wrote: > > Hi Andy, > > > > On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenko > > wrote: > > > The commit > > > > > > f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file > > > in C)") > > > [Moore, Robert] This change was requested by a customer, and it seemed quite reasonable to us. Sorry for any inconvenience. Bob > > > in ACPICA project changed a template of the a of variable that is > > > used > > > > a template of the a of variable? Cannot understand this. > > "a template of the variable" > > > > > > in the generated C-file. Now, instead of hard coded "AmlCode" the > > > "%s_aml_code" is in use, where the prefix is a lowered case base > > > name of the output file. In our case it will be "dsdt" producing a > > > name as "dsdt_aml_code". > > > > > > The quick solution is to call sed which replaces new name by the old > > > one to keep compatibility with old version of iASL. > > > > > > The long term solution would be to modify code to use the new name > > > because it more scalable. > > > > it *is* more scalable. > > Yes, thanks. > > > > > > > > > Cc: Robert Moore > > > Cc: Sami Mujawar > > > Cc: Evan Lloyd > > > Signed-off-by: Andy Shevchenko > > > --- > > > scripts/Makefile.lib | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index > > > f9809ce7ce..b5cf7e5427 100644 > > > --- a/scripts/Makefile.lib > > > +++ b/scripts/Makefile.lib > > > @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \ > > > > > > $(obj)/dsdt.c:$(src)/dsdt.asl > > > $(call cmd,acpi_c_asl) > > > + $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ > > > > > > # Bzip2 > > > # --- > > > > > > -- > > > > Otherwise, > > Reviewed-by: Bin Meng > > > > Regards, > > Bin > > -- > Andy Shevchenko > Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote: > > > On 23/05/2018 14:43, Marek Vasut wrote: >> On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: >>> >>> On 23/05/2018 14:03, Marek Vasut wrote: On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: > Hi, Hi, > When trying to migrate a board from u-boot version 2016.09 to version > 2018.03, I found a problem with a USB 2.0 device which used to work on > version 2016.09. Does it still happen in u-boot/master ? >>> Yes, it still happens. >>> >>> I just tested it with the following commit: >>> dca268a .travis.yml: Further optimizations > In u-boot version 2016.09 the device appears like this: > > 2: Mass Storage, USB Revision 2.0 > - SanDisk Cruzer Blade 200443243002FB509E64 >> Let me guess, is this a DWC2-based host ? You didn't mention which SoC >> or USB controller it is. >> >> Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , >> DWC2 has problems with those sandisk sticks. > No, it is a NXP T1024 SoC. > Do you think it may be a problem with the SoC or NXP USB host driver ? > So that's chipidea ? That one should be reasonably sane. Submit the patch you had in mind and let's see what happens. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support
On 23 May 2018 at 11:56, Vabhav Sharmawrote: > Hello Everyone, > > I am working on integrating generic PL011 driver in u-boot and linux for > ARMv8 NXP SoC and facing issue with multiple UART console enablement in > u-boot using DM model > > Kindly provide your valuable feedback and experts comments. > > > > DTS require stdout-path(e.g-UART0) to the /chosen device tree node > ,Accordingly controller(UART0) is probed/initialized as boot console > > On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for > linux boot but kernel hangs after “Starting kernel ... print” > > > > After debugging it’s found that UART1 is not initialized and single(first) > controller is probed/initialized in u-boot (Irrespective of 4 UART nodes > are enabled in dts) > > In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT > stdout-path or CONFIG_CONS_INDEX or platform data(first index) > > > > Does the u-boot DM model support only one or multiple UART driver > probing/initialization? Is there any configuration parameter required to > define number of UART controllers to be probed/initialized. > > This looks limitation as same boot console is used for u-boot and linux and > unable to use all available UART controllers. > > > > I am new to u-boot and please correct any misunderstanding > > Let me know If I can submit a patch for multiple UART probe in serial-uclass > or open a bug for multiple UART support in u-boot DM model > > > > PS:I am unable to find owner of serial uclass driver from MAINTAINERS file > > > > Regards, > > Vabhav > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: > > > On 23/05/2018 14:03, Marek Vasut wrote: >> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >>> Hi, >> Hi, >> >>> When trying to migrate a board from u-boot version 2016.09 to version >>> 2018.03, I found a problem with a USB 2.0 device which used to work on >>> version 2016.09. >> Does it still happen in u-boot/master ? > Yes, it still happens. > > I just tested it with the following commit: > dca268a .travis.yml: Further optimizations >> >>> In u-boot version 2016.09 the device appears like this: >>> >>> 2: Mass Storage, USB Revision 2.0 >>> - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is. Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: > Hi, Hi, > When trying to migrate a board from u-boot version 2016.09 to version > 2018.03, I found a problem with a USB 2.0 device which used to work on > version 2016.09. Does it still happen in u-boot/master ? > In u-boot version 2016.09 the device appears like this: > > 2: Mass Storage, USB Revision 2.0 > - SanDisk Cruzer Blade 200443243002FB509E64 > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0781 Product 0x5567 Version 1.38 > Configuration: 1 > - Interfaces: 1 Bus Powered 200mA > Interface: 0 > - Alternate Setting 0, Endpoints: 2 > - Class Mass Storage, Transp. SCSI, Bulk only > - Endpoint 1 In Bulk MaxPacket 512 > - Endpoint 2 Out Bulk MaxPacket 512 > > > But in version 2018.03 I just can't start usb. It fails with following > error: > > => usb start > starting USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 > unable to get device descriptor (error=-1) > 1 USB Device(s) found > USB1: USB EHCI 1.00 > scanning bus 1 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > > > I did a "git bisect" and found that this problem is related to the > following commit: > > c008faa usb: Only get 64 bytes device descriptor for full speed devices > > I am not an expert on USB, so I would like to ask for help on this issue. > > In u-boot v2018.03, file common/usb.c, line 973, shouldn't the > comparison be like this: > > if (do_read && dev->speed >= USB_SPEED_FULL) { > > or, at list: > > if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == > USB_SPEED_HIGH)) { > > > I would submit a patch for this, but I lack on USB knowledge for > explaining the patch. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] lib: Import hexdump.c from Linux
Hi Mario, On 23 May 2018 at 06:09, Mario Sixwrote: > Especially for commands, it is useful to be able to turn a hexadecimal > string into its binary representation. > > Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the > Linux kernel. > > Signed-off-by: Mario Six > > --- > > v1 -> v2: > New in v2 > > --- > include/linux/kernel.h | 4 + > lib/Makefile | 1 + > lib/hexdump.c | 321 > + > 3 files changed, 326 insertions(+) > create mode 100644 lib/hexdump.c Does Linux have any tests for this code? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add FIT data-position & data-offset property support
Hi Kelvin, On 22 May 2018 at 19:34, Kelvin Cheungwrote: > Hi Simon, > > > 2018-05-23 7:30 GMT+08:00 Simon Glass : >> >> Hi, >> >> On 18 May 2018 at 01:56, Kelvin Cheung wrote: >> > Add FIT data-position & data-offset property support for bootm, >> > which were already supported in SPL. >> > >> > Signed-off-by: Kelvin Cheung >> > --- >> > >> > Changes for v2: >> >create fit_image_get_data_and_size() to remove duplicated code >> > >> > --- >> > common/image-fit.c | 54 >> > +++--- >> > include/image.h| 2 ++ >> > 2 files changed, 53 insertions(+), 3 deletions(-) >> >> Reviewed-by: Simon Glass >> >> How can we get this feature integrated into the tests? >> > Do you mean the test scripts under test dir? I mean the test_fit.py test. > > BTW, I updated this patch to v3 several days ago. OK, well please take a look at the test. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] drivers: Add OSD uclass
On 23 May 2018 at 06:09, Mario Sixwrote: > Some devices offer a text-based OSD (on-screen display) that can be > programmatically controlled (i.e. text displayed on). > > Add a uclass to support such devices. > > Signed-off-by: Mario Six > > --- > > v1 -> v2: > * Use singular case for UCLASS_VIDEO_OSD description > * Expanded description of video_osd_set_mem with example > * Replaced all left-over mentions of pixels with text > * Renamed x and y parameters to col and row > * Expaneded description of color parameter > * Added general description of the OSD uclass > * Expanded description of video_osd_info > > --- > drivers/video/Kconfig| 8 ++ > drivers/video/Makefile | 2 + > drivers/video/video_osd-uclass.c | 46 ++ > include/dm/uclass-id.h | 1 + > include/video_osd.h | 193 > +++ > 5 files changed, 250 insertions(+) > create mode 100644 drivers/video/video_osd-uclass.c > create mode 100644 include/video_osd.h Why drop the 'u' on 'colour'? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] video_osd: Add ihs_video_out driver
Hi Mario, On 23 May 2018 at 06:09, Mario Sixwrote: > Add a driver for IHS OSDs on IHS FPGAs. > > Signed-off-by: Mario Six > > --- > > v1 -> v2: > * Renamed x and y parameters to col and row > * Removed duplicate IHS_VIDEO_OUT definition > * Switched error return code of ihs_video_out_set_mem to E2BIG > * Dropped blank lines between dev_read_u32_default calls > * Documented members of ihs_video_out_priv > * Turned printfs into debugs > * Don't display OSD until something has been written to it > * Made the code a bit more readable > * Added binding file > * Expanded documentation and help > * Switched to display_enable > * Switched to regmap usage (instead of fpgamap uclass) > * Renamed 'dp_tx' property to 'video_tx' > > --- > .../video/osd/gdsys,ihs_video_out.txt | 22 ++ > drivers/video/Kconfig | 9 + > drivers/video/Makefile | 1 + > drivers/video/ihs_video_out.c | 277 > + > 4 files changed, 309 insertions(+) > create mode 100644 doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt > create mode 100644 drivers/video/ihs_video_out.c > Reviewed-by: Simon Glass You could perhaps s/dev_read_prop/dev_read_string/ to avoid the cast. Also is there a binding file for your driver's device-tree node somewhere? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] cmd: Add osd commands
Hi Mario, On 23 May 2018 at 06:09, Mario Sixwrote: > Add command to query information from and write text to on-screen > display (OSD) devices. > > Signed-off-by: Mario Six > > --- > > v1 -> v2: > * Added explanation for what a OSD is > * Added explanation of the color parameter > * Moved GDSYS_LEGACY_OSD_CMDS to gdsys Kconfig > > --- > board/gdsys/mpc8308/Kconfig | 11 ++ > cmd/Kconfig | 8 + > cmd/Makefile| 1 + > cmd/osd.c | 378 > > 4 files changed, 398 insertions(+) > create mode 100644 cmd/osd.c To me it seems unfortunate that the legacy and new commands are named the same. I suppose that is unavoidable? I wonder if the legacy code could be moved to board/gdsys instead? It is out of the way then. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] malloc: Use malloc simple before malloc is fully initialized in memalign()
Hi, On 23 May 2018 at 00:32, Ley Foon Tanwrote: > On Sat, May 19, 2018 at 10:37 PM, Simon Glass wrote: >> Hi Ley, >> >> On 18 May 2018 at 04:03, Ley Foon Tan wrote: >>> Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and >>> use >>> malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the malloc bytes >>> to align with the requested alignment. >>> >>> The original memalign() function will access mchunkptr struct to adjust the >>> alignment if there is misalignment happen, but mchunkptr struct is not being >>> initialized before full malloc is initialized. This cause the system crash. >>> >>> Signed-off-by: Ley Foon Tan >>> --- >>> common/dlmalloc.c |7 +++ >>> 1 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c >>> index b395eef..edaad29 100644 >>> --- a/common/dlmalloc.c >>> +++ b/common/dlmalloc.c >>> @@ -1891,6 +1891,13 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; >>> size_t bytes; >>> >>>if ((long)bytes < 0) return NULL; >>> >>> +#if CONFIG_VAL(SYS_MALLOC_F_LEN) >> >> How about: >> >> if (IS_ENABLED(CONFIG_SYS_MALLOC_F)) > > I think this is the reason it uses #if CONFIG_VAL(SYS_MALLOC_F_LEN), > same for malloc(). > > "spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN" > > http://git.denx.de/?p=u-boot.git;a=commit;h=f1896c45cb2f7d8dbed27e784a6459a129fc0762 So how about if (CONFIG_IS_ENABLED(SYS_MALLOC_F_LEN) Or you could use #if if you need to To me it seems better to use the setting itself (i.e. whether the pre-reloc malloc() is enabled) rather than one of its parameters (the size of the region). > > >> >> ? >> >>> + if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) { >>> + nb = roundup(bytes, alignment); >>> + return malloc_simple(nb); >>> + } >>> +#endif >>> + >>>/* If need less alignment than we give anyway, just relay to malloc */ >>> >>>if (alignment <= MALLOC_ALIGNMENT) return mALLOc(bytes); >>> -- >>> 1.7.1 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] video_osd: Add osd sandbox driver and tests
Hi Mario, On 23 May 2018 at 06:09, Mario Sixwrote: > Add sandbox driver and tests for the new OSD uclass. > > Signed-off-by: Mario Six > > --- > > v1 -> v2: > New in v2 > > --- > arch/sandbox/dts/test.dts | 4 + > configs/sandbox64_defconfig| 3 + > configs/sandbox_defconfig | 3 + > configs/sandbox_flattree_defconfig | 3 + > configs/sandbox_noblk_defconfig| 3 + > configs/sandbox_spl_defconfig | 3 + > drivers/video/Kconfig | 6 ++ > drivers/video/Makefile | 1 + > drivers/video/sandbox_osd.c| 157 > drivers/video/sandbox_osd.h| 14 +++ > drivers/video/video_osd-uclass.c | 9 ++ > include/video_osd.h| 7 ++ > test/dm/Makefile | 1 + > test/dm/osd.c | 208 > + > 14 files changed, 422 insertions(+) > create mode 100644 drivers/video/sandbox_osd.c > create mode 100644 drivers/video/sandbox_osd.h > create mode 100644 test/dm/osd.c This looks good. But you can't add a new get_mem() operation just for sandbox. Instead, how about a back-door function that allows sandbox to get its information. You can call it sandbox_video_osd_get_mem(), for example, and just directly call it from you test code and implement it in your driver. There are some functions like this in arch/sandbox/include/asm/test.h Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: pci: use a 1:1 mapping for bus <-> phy addresses
Hi Christian, On 23 May 2018 at 06:00, Christian Gmeinerwrote: > If u-boot gets used as coreboot payload all pci resources got U-Boot (please use this consistently) > assigned by coreboot. If a dts without any pci ranges gets used > the dm is not able to access pci device memory. To get things > working make use of a 1:1 mapping for bus <-> phy addresses. > > This change makes it possible to get the e1000 u-boot driver > working on a sandybridge device where u-boot is used as coreboot > payload. > > Signed-off-by: Christian Gmeiner > --- > drivers/pci/pci-uclass.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index 416444a230..9cec619bb2 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -1175,6 +1175,11 @@ static int _dm_pci_bus_to_phys(struct udevice *ctlr, > struct pci_region *res; > int i; > > + if (hose->region_count == 0) { Or just if (!hose->region_count) Please add a comment as to the case you are covering here. How come the mapping will be 1:1? Is that guaranteed? > + *pa = bus_addr; > + return 0; > + } > + > for (i = 0; i < hose->region_count; i++) { > res = >regions[i]; > > @@ -1238,6 +1243,11 @@ int _dm_pci_phys_to_bus(struct udevice *dev, > phys_addr_t phys_addr, > ctlr = pci_get_controller(dev); > hose = dev_get_uclass_priv(ctlr); > > + if (hose->region_count == 0) { > + *ba = phys_addr; > + return 0; > + } > + > for (i = 0; i < hose->region_count; i++) { > res = >regions[i]; > > -- > 2.17.0 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory
Hi Ken, On 23 May 2018 at 01:06, Ken Mawrote: > Dear Simon > > Thanks a lot for your kind help and review. > > Previously I did not use patman and generated my patches as below: > 1. used "git mv arch/arm/mach-mvebu/sata.c drivers/ata/ahci_mvebu.c" to do > the file renaming with makefiles and Kconfig file updating. > 2. After the 4 patches are all finished, I used "git format-patch -4 > --cover-letter -o outgoing/sata" to generate the patch set with cover letter. > 3. I used " git send-email --to u-boot@lists.denx.de outgoing/sata* --force" > to send out patches. > > And I try to use patman as your advice, I find that the patch generated by > "patman" can indicate the file "rename" relationship while the patch > generated by "git format-patch" can not. > arch/arm/mach-mvebu/Makefile | 1 - > drivers/ata/Kconfig| 9 + > drivers/ata/Makefile | 1 + > arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++--- > 4 files changed, 13 insertions(+), 4 deletions(-) > rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%) > … > diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c > similarity index 89% > rename from arch/arm/mach-mvebu/sata.c > rename to drivers/ata/ahci_mvebu.c > index 5d8032b..5c1b293 100644 > --- a/arch/arm/mach-mvebu/sata.c > +++ b/drivers/ata/ahci_mvebu.c > @@ -1,15 +1,15 @@ > /* > + * Copyright (C) 2018 Marvell International Ltd. > * Copyright (C) 2016 Stefan Roese > * > - * SPDX-License-Identifier:GPL-2.0+ > + * SPDX-License-Identifier: GPL-2.0+ > + * https://spdx.org/licenses > */ > > #include > #include > #include > > -DECLARE_GLOBAL_DATA_PTR; > - > /* > * Dummy implementation that can be overwritten by a board > * specific function > > But I failed to send out patches by patman as below, it says " Alias 'ata' > not found ". > ken@mshsrv05:~/git_ken/u-boot/u-boot$ tools/patman/patman -c4 > Cleaned 4 patches > 0 errors, 1 warnings, 0 checks for > 0001-ata-mvebu-move-mvebu-sata-driver-to-drivers-ata-dire.patch: > :0: warning: added, moved or deleted file(s), does > MAINTAINERS need updating? > > checkpatch.pl found 0 error(s), 1 warning(s), 0 checks(s) > Traceback (most recent call last): > File "tools/patman/patman", line 161, in > options.add_maintainers) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/series.py", line > 231, in MakeCcFile > raise_on_error=raise_on_error) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", > line 326, in BuildEmailList > raw += LookupEmail(item, alias, raise_on_error=raise_on_error) > File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", > line 503, in LookupEmail > raise ValueError(msg) > ValueError: Alias 'ata' not found > > > Thanks a lot for your kind help! You can use the -t flag to ignore the missing alias. Regards, Simon > > Yours, > Ken > > > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: 2018年5月23日 7:30 > To: Ken Ma > Cc: U-Boot Mailing List; Stefan Roese > Subject: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to > drivers/ata directory > > External Email > > -- > Hi Ken, > > On 17 May 2018 at 19:27, wrote: >> From: Ken Ma >> >> Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this >> patch moves it to drivers/ata directory with renaming "sata.c" to >> "ahci_mvebu.c" which is aligned to Linux. >> New ahci driver's kconfig option is added as AHCI_MVEBU which selects >> DM_SCSI. >> >> Signed-off-by: Ken Ma >> Cc: Simon Glass >> Cc: Stefan Roese >> --- >> arch/arm/mach-mvebu/Makefile | 1 - >> arch/arm/mach-mvebu/sata.c | 54 >> >> drivers/ata/Kconfig | 9 >> drivers/ata/Makefile | 1 + >> drivers/ata/ahci_mvebu.c | 54 >> >> 5 files changed, 64 insertions(+), 55 deletions(-) >> delete mode 100644 arch/arm/mach-mvebu/sata.c >> create mode 100644 drivers/ata/ahci_mvebu.c >> > > How come this doesn't show up as a file move? Are you using patman to > generate your patches? > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv3, 2/3] buildman: support newer gcc versions from kernel.org
On Thu, May 10, 2018 at 07:15:53AM -0400, Tom Rini wrote: > From: Daniel Schwierzeck> > Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4. > > Also use a regex for matching the tarball names. Some gcc versions > use '-ARCH-' instead of '_ARCH-'. > > As part of this, we switch TravisCI to also using these toolchains for > all platforms. > > Signed-off-by: Daniel Schwierzeck > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv3, 3/3] .travis.yml: Further optimizations
On Thu, May 10, 2018 at 07:15:54AM -0400, Tom Rini wrote: > - Xilinx aarch64 is caught in the general xilinx arm job, exclude from > the general aarch64 job. > - Give the generic aarch64 job a better name > - Re-sort the PowerPC jobs so that we can complete them a bit quicker. > > Signed-off-by: Tom RiniApplied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv3, 1/3] at91: Minor tweaks to SPL logic for space savings on smartweb
On Thu, May 10, 2018 at 07:15:52AM -0400, Tom Rini wrote: > - spl_board_init is empty on smartweb so drop that function > - When CONFIG_AT91SAM9_WATCHDOG is set we do not disable the watchdog in > SPL and instead let full U-Boot handle it. Instead of an empty > function just do not call a function. > > Signed-off-by: Tom RiniApplied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] misc: uclass: Add enable/disable function
Add generic enable/disable function to the misc uclass. Signed-off-by: Mario Six--- v2 -> v3: * Now return old state from misc_set_enabled v1 -> v2: * Merged the two functions into one function * Explained the semantics of enabling/disabling more throughly --- drivers/misc/misc-uclass.c | 10 ++ include/misc.h | 27 +++ 2 files changed, 37 insertions(+) diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c index 0dc62d00344..f240cda5c05 100644 --- a/drivers/misc/misc-uclass.c +++ b/drivers/misc/misc-uclass.c @@ -55,6 +55,16 @@ int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size, return ops->call(dev, msgid, tx_msg, tx_size, rx_msg, rx_size); } +int misc_set_enabled(struct udevice *dev, bool val) +{ + const struct misc_ops *ops = device_get_ops(dev); + + if (!ops->set_enabled) + return -ENOSYS; + + return ops->set_enabled(dev, val); +} + UCLASS_DRIVER(misc) = { .id = UCLASS_MISC, .name = "misc", diff --git a/include/misc.h b/include/misc.h index 0acb4c4df64..ffc489ec6b0 100644 --- a/include/misc.h +++ b/include/misc.h @@ -60,6 +60,23 @@ int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size, void *rx_msg, int rx_size); /** + * misc_set_enabled() - Enable or disable a device. + * + * The semantics of "disable" and "enable" should be understood here as + * activating or deactivating the device's primary function, hence a "disabled" + * device should be dormant, but still answer to commands and queries. + * + * A probed device may start in a disabled or enabled state, depending on the + * driver and hardware. + * + * @dev: the device to enable or disable. + * @val: the flag that tells the driver to either enable or disable the device. + * Return: -ve on error, 0 if the previous state was "disabled", 1 if the + *previous state was "enabled" + */ +int misc_set_enabled(struct udevice *dev, bool val); + +/* * struct misc_ops - Driver model Misc operations * * The uclass interface is implemented by all miscellaneous devices which @@ -112,6 +129,16 @@ struct misc_ops { */ int (*call)(struct udevice *dev, int msgid, void *tx_msg, int tx_size, void *rx_msg, int rx_size); + /** +* Enable or disable a device, optional. +* +* @dev: the device to enable. +* @val: the flag that tells the driver to either enable or disable the +* device. +* Return: -ve on error, 0 if the previous state was "disabled", 1 if +* the previous state was "enabled" +*/ + int (*set_enabled)(struct udevice *dev, bool val); }; #endif /* _MISC_H_ */ -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] misc: docs: Fix comments in misc.h
The comments in misc.h are not in kernel-doc format. Correct the format. Signed-off-by: Mario Six--- v2 -> v3: New in v3 --- include/misc.h | 66 +++--- 1 file changed, 35 insertions(+), 31 deletions(-) diff --git a/include/misc.h b/include/misc.h index 68f8e64d61a..0acb4c4df64 100644 --- a/include/misc.h +++ b/include/misc.h @@ -6,38 +6,40 @@ #ifndef _MISC_H_ #define _MISC_H_ -/* - * Read the device to buffer, optional. +/** + * misc_read() - Read the device to buffer, optional. * * @dev: the device * @offset: offset to read the device * @buf: pointer to data buffer * @size: data size in bytes to read the device - * @return: 0 if OK, -ve on error + * Return: 0 if OK, -ve on error */ int misc_read(struct udevice *dev, int offset, void *buf, int size); -/* - * Write buffer to the device, optional. + +/** + * misc_write() - Write buffer to the device, optional. * * @dev: the device * @offset: offset to write the device * @buf: pointer to data buffer * @size: data size in bytes to write the device - * @return: 0 if OK, -ve on error + * Return: 0 if OK, -ve on error */ int misc_write(struct udevice *dev, int offset, void *buf, int size); -/* - * Assert command to the device, optional. + +/** + * misc_ioctl() - Assert command to the device, optional. * * @dev: the device * @request: command to be sent to the device * @buf: pointer to buffer related to the request - * @return: 0 if OK, -ve on error + * Return: 0 if OK, -ve on error */ int misc_ioctl(struct udevice *dev, unsigned long request, void *buf); -/* - * Send a message to the device and wait for a response. +/** + * misc_call() - Send a message to the device and wait for a response. * * The caller provides the message type/ID and payload to be sent. * The callee constructs any message header required, transmits it to the @@ -47,64 +49,66 @@ int misc_ioctl(struct udevice *dev, unsigned long request, void *buf); * * @dev: the device. * @msgid: the message ID/number to send. - * tx_msg: the request/transmit message payload. - * tx_size: the size of the buffer pointed at by tx_msg. - * rx_msg: the buffer to receive the response message payload. May be NULL if - * the caller only cares about the error code. - * rx_size: the size of the buffer pointed at by rx_msg. - * @return the response message size if OK, -ve on error + * @tx_msg: the request/transmit message payload. + * @tx_size: the size of the buffer pointed at by tx_msg. + * @rx_msg: the buffer to receive the response message payload. May be NULL if + * the caller only cares about the error code. + * @rx_size: the size of the buffer pointed at by rx_msg. + * Return: the response message size if OK, -ve on error */ int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size, void *rx_msg, int rx_size); -/* +/** * struct misc_ops - Driver model Misc operations * * The uclass interface is implemented by all miscellaneous devices which * use driver model. */ struct misc_ops { - /* + /** * Read the device to buffer, optional. * * @dev: the device * @offset: offset to read the device * @buf: pointer to data buffer * @size: data size in bytes to read the device -* @return: 0 if OK, -ve on error +* Return: 0 if OK, -ve on error */ int (*read)(struct udevice *dev, int offset, void *buf, int size); - /* + + /** * Write buffer to the device, optional. * * @dev: the device * @offset: offset to write the device * @buf: pointer to data buffer * @size: data size in bytes to write the device -* @return: 0 if OK, -ve on error +* Return: 0 if OK, -ve on error */ int (*write)(struct udevice *dev, int offset, const void *buf, int size); - /* + /** * Assert command to the device, optional. * * @dev: the device * @request: command to be sent to the device * @buf: pointer to buffer related to the request -* @return: 0 if OK, -ve on error +* Return: 0 if OK, -ve on error */ int (*ioctl)(struct udevice *dev, unsigned long request, void *buf); - /* + + /** * Send a message to the device and wait for a response. * * @dev: the device * @msgid: the message ID/number to send -* tx_msg: the request/transmit message payload -* tx_size: the size of the buffer pointed at by tx_msg -* rx_msg: the buffer to receive the response message payload. May be -* NULL if the caller only cares about the error code. -* rx_size: the size of the buffer pointed at by rx_msg -* @return the response message size if OK, -ve on error +* @tx_msg: the
[U-Boot] [PATCH v3 3/3] misc: Add gdsys_ioep driver
Add driver for the IHS IO endpoint on IHS FPGAs. Signed-off-by: Mario Six--- v2 -> v3: No changes v1 -> v2: * Switched to regmap usage (instead of fpgamap) --- drivers/misc/Kconfig | 6 ++ drivers/misc/Makefile | 1 + drivers/misc/gdsys_ioep.c | 155 ++ drivers/misc/gdsys_ioep.h | 73 ++ 4 files changed, 235 insertions(+) create mode 100644 drivers/misc/gdsys_ioep.c create mode 100644 drivers/misc/gdsys_ioep.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index be900cf4d6e..dc4cd4ec110 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -268,4 +268,10 @@ config GDSYS_RXAUI_CTRL depends on MISC help Support gdsys FPGA's RXAUI control. + +config GDSYS_IOEP + bool "Enable gdsys IOEP driver" + depends on MISC + help + Support gdsys FPGA's IO endpoint driver. endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index e362609d62a..1782dc8be42 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -53,3 +53,4 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o obj-$(CONFIG_STM32_RCC) += stm32_rcc.o obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o +obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o diff --git a/drivers/misc/gdsys_ioep.c b/drivers/misc/gdsys_ioep.c new file mode 100644 index 000..2c29e8c4e8c --- /dev/null +++ b/drivers/misc/gdsys_ioep.c @@ -0,0 +1,155 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * based on the cmd_ioloop driver/command, which is + * + * (C) Copyright 2014 + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include + +#include "gdsys_ioep.h" + +struct gdsys_ioep_priv { + struct regmap *map; + bool state; +}; + +enum last_spec { + READ_DATA_IS_LAST, + READ_DATA_IS_NOT_LAST, +}; + +int gdsys_ioep_set_receive(struct udevice *dev, bool val) +{ + struct gdsys_ioep_priv *priv = dev_get_priv(dev); + u16 state; + + priv->state = !priv->state; + + if (val) + state = CTRL_PROC_RECEIVE_ENABLE; + else + state = ~CTRL_PROC_RECEIVE_ENABLE; + + gdsys_ioep_set(priv->map, tx_control, state); + + if (val) { + /* Set device address to dummy 1*/ + gdsys_ioep_set(priv->map, device_address, 1); + } + + return !priv->state; +} + +int gdsys_ioep_send(struct udevice *dev, int offset, const void *buf, int size) +{ + struct gdsys_ioep_priv *priv = dev_get_priv(dev); + int k; + u16 *p = (u16 *)buf; + + for (k = 0; k < size; ++k) + gdsys_ioep_set(priv->map, transmit_data, *(p++)); + + gdsys_ioep_set(priv->map, tx_control, CTRL_PROC_RECEIVE_ENABLE | + CTRL_FLUSH_TRANSMIT_BUFFER); + + return 0; +} + +int receive_byte_buffer(struct udevice *dev, uint len, u16 *buffer, enum last_spec last_spec) +{ + struct gdsys_ioep_priv *priv = dev_get_priv(dev); + int k; + int res = -EIO; + + for (k = 0; k < len; ++k) { + u16 rx_tx_status; + + gdsys_ioep_get(priv->map, receive_data, buffer++); + + gdsys_ioep_get(priv->map, rx_tx_status, _tx_status); + if (k == (len - 1) && (last_spec == READ_DATA_IS_NOT_LAST || + rx_tx_status & STATE_RX_DATA_LAST)) + res = 0; + } + + return res; +} + +int gdsys_ioep_receive(struct udevice *dev, int offset, void *buf, int size) +{ + int res1, res2; + struct io_generic_packet header; + u16 *p = (u16 *)buf; + const int header_words = sizeof(struct io_generic_packet) / 2; + uint len; + + res1 = receive_byte_buffer(dev, header_words, p, READ_DATA_IS_NOT_LAST); + memcpy(, p, 2 * header_words); + p += header_words; + + len = (header.packet_length + 1) / 2; + + if (!res1) + res2 = receive_byte_buffer(dev, len, p, READ_DATA_IS_LAST); + + return res1 ? res1 : res2; +} + +int gdsys_ioep_get_and_reset_status(struct udevice *dev, int msgid, + void *tx_msg, int tx_size, void *rx_msg, + int rx_size) +{ + struct gdsys_ioep_priv *priv = dev_get_priv(dev); + const u16 mask = STATE_RX_DIST_ERR | STATE_RX_LENGTH_ERR | +STATE_RX_FRAME_CTR_ERR | STATE_RX_FCS_ERR | +STATE_RX_PACKET_DROPPED | STATE_TX_ERR; + u16 *status = rx_msg; + + gdsys_ioep_get(priv->map, rx_tx_status, status); + + gdsys_ioep_set(priv->map, rx_tx_status, *status); + + return (*status & mask) ? 1 : 0; +} + +static const struct misc_ops
Re: [U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional
Hi Bin, Am Mi., 23. Mai 2018 um 15:10 Uhr schrieb Bin Meng: > Hi Christian, > On Wed, May 23, 2018 at 8:00 PM, Christian Gmeiner > wrote: > > If we use u-boot as coreboot payload with a generic dts without > > any ranges specified we fail in pci pre_probe and our pci bus > > is not usable. > > > What do you mean by "a generic dts"? > The coreboot payload needs to specify a dedicated dts for that board, > for example to build a coreboot payload for minnowmax, we need specify > minnowmax.dts in the Kconfig. README.x86 documents this. Yeah.. so in my eyes a "generic dts" contains only this part regarding pci: pci { compatible = "pci-x86"; #address-cells = <0x3>; #size-cells = <0x2>; }; The important part is that it does not contain any ranges. Coreboot is the one who does the pci bus setup (assigning memory windows for devices etc). So I do not want to know in u-boot at build time (ranges thing for pci) how the pci bus looks regarding addresses. My end goal is one generic u-boot payload that gets used for different FSP 2.0 based boards. > > So convert decode_regions(..) into a void function and do the simple > > error handling there. > > > > Signed-off-by: Christian Gmeiner > > --- > > drivers/pci/pci-uclass.c | 21 + > > 1 file changed, 9 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > > index 49be1ebdd7..416444a230 100644 > > --- a/drivers/pci/pci-uclass.c > > +++ b/drivers/pci/pci-uclass.c > > @@ -810,7 +810,7 @@ error: > > return ret; > > } > > > > -static int decode_regions(struct pci_controller *hose, ofnode parent_node, > > +static void decode_regions(struct pci_controller *hose, ofnode parent_node, > > ofnode node) > > { > > int pci_addr_cells, addr_cells, size_cells; > > @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, > > int i; > > > > prop = ofnode_get_property(node, "ranges", ); > > - if (!prop) > > - return -EINVAL; > > + if (!prop) { > > + debug("%s: Cannot decode regions\n", __func__); > > + return; > > + } > > + > > pci_addr_cells = ofnode_read_simple_addr_cells(node); > > addr_cells = ofnode_read_simple_addr_cells(parent_node); > > size_cells = ofnode_read_simple_size_cells(node); > > @@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, > > bd_t *bd = gd->bd; > > > > if (!bd) > > - return 0; > > + return; > > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { > > if (bd->bi_dram[i].size) { > > @@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, > > base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY); > > #endif > > > > - return 0; > > + return; > > } > > > > static int pci_uclass_pre_probe(struct udevice *bus) > > { > > struct pci_controller *hose; > > - int ret; > > > > debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name, > > bus->parent->name); > > @@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice *bus) > > /* For bridges, use the top-level PCI controller */ > > if (!device_is_on_pci_bus(bus)) { > > hose->ctlr = bus; > > - ret = decode_regions(hose, dev_ofnode(bus->parent), > > -dev_ofnode(bus)); > > - if (ret) { > > - debug("%s: Cannot decode regions\n", __func__); > > - return ret; > > - } > > + decode_regions(hose, dev_ofnode(bus->parent), dev_ofnode(bus)); > > } else { > > struct pci_controller *parent_hose; > > > > -- > > > Regards, > Bin -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Add KConfig option for cache maintenance availability
Hi Faiz, On Tue, 22 May 2018 11:47:41 +0530 Faiz Abbaswrote: > Hi, > > On Monday 30 April 2018 02:03 PM, Emmanuel Vadot wrote: > > Hi, > > > > In order to correctly exectute some binaries on some arch we need to flush > > the data cache or instructions cache. Some arch offer helper functions for > > this while others don't (or don't have the ability to do this in hardware). > > Introduce some kconfig option name SYS_HAVE_DCACHE_MAINTENANCE and > > SYS_HAVE_ICACHE_MAINTENANCE and enable it on some arm CPU that have cache > > maintenance helpers. > > It was decided that instead of flushing/invalidating caches, > architectures should add support for allocating coherent data in the > first place. > > See the discussion here: > https://patchwork.ozlabs.org/patch/826131/ > > Thanks, > Faiz Thanks for the heads up. Are you working on on this for arm ? Cheers, -- Emmanuel Vadot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional
Hi Christian, On Wed, May 23, 2018 at 8:00 PM, Christian Gmeinerwrote: > If we use u-boot as coreboot payload with a generic dts without > any ranges specified we fail in pci pre_probe and our pci bus > is not usable. > What do you mean by "a generic dts"? The coreboot payload needs to specify a dedicated dts for that board, for example to build a coreboot payload for minnowmax, we need specify minnowmax.dts in the Kconfig. README.x86 documents this. > So convert decode_regions(..) into a void function and do the simple > error handling there. > > Signed-off-by: Christian Gmeiner > --- > drivers/pci/pci-uclass.c | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index 49be1ebdd7..416444a230 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -810,7 +810,7 @@ error: > return ret; > } > > -static int decode_regions(struct pci_controller *hose, ofnode parent_node, > +static void decode_regions(struct pci_controller *hose, ofnode parent_node, > ofnode node) > { > int pci_addr_cells, addr_cells, size_cells; > @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, > ofnode parent_node, > int i; > > prop = ofnode_get_property(node, "ranges", ); > - if (!prop) > - return -EINVAL; > + if (!prop) { > + debug("%s: Cannot decode regions\n", __func__); > + return; > + } > + > pci_addr_cells = ofnode_read_simple_addr_cells(node); > addr_cells = ofnode_read_simple_addr_cells(parent_node); > size_cells = ofnode_read_simple_size_cells(node); > @@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller *hose, > ofnode parent_node, > bd_t *bd = gd->bd; > > if (!bd) > - return 0; > + return; > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { > if (bd->bi_dram[i].size) { > @@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller *hose, > ofnode parent_node, > base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY); > #endif > > - return 0; > + return; > } > > static int pci_uclass_pre_probe(struct udevice *bus) > { > struct pci_controller *hose; > - int ret; > > debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name, > bus->parent->name); > @@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice *bus) > /* For bridges, use the top-level PCI controller */ > if (!device_is_on_pci_bus(bus)) { > hose->ctlr = bus; > - ret = decode_regions(hose, dev_ofnode(bus->parent), > -dev_ofnode(bus)); > - if (ret) { > - debug("%s: Cannot decode regions\n", __func__); > - return ret; > - } > + decode_regions(hose, dev_ofnode(bus->parent), > dev_ofnode(bus)); > } else { > struct pci_controller *parent_hose; > > -- > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] sandbox: Add and build AXI bus and device
Add test AXI drivers to the sandbox. Reviewed-by: Simon GlassSigned-off-by: Mario Six --- v1 -> v2: No changes --- arch/sandbox/dts/sandbox.dts | 11 +++ arch/sandbox/dts/test.dts| 11 +++ configs/sandbox_defconfig| 3 +++ 3 files changed, 25 insertions(+) diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index 86680a6b11d..8a236ea76b2 100644 --- a/arch/sandbox/dts/sandbox.dts +++ b/arch/sandbox/dts/sandbox.dts @@ -12,6 +12,7 @@ i2c0 = _0; pci0 = rtc0 = _0; + axi0 = }; chosen { @@ -315,6 +316,16 @@ }; }; }; + + axi: axi@0 { + compatible = "sandbox,axi"; + #address-cells = <0x1>; + #size-cells = <0x1>; + store@0 { + compatible = "sandbox,sandbox_store"; + reg = <0x0 0x400>; + }; + }; }; #include "cros-ec-keyboard.dtsi" diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 5a0f187d8b7..5822c5dd59a 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -34,6 +34,7 @@ usb0 = _0; usb1 = _1; usb2 = _2; + axi0 = }; a-test { @@ -507,6 +508,16 @@ compatible = "sandbox,wdt"; }; + axi: axi@0 { + compatible = "sandbox,axi"; + #address-cells = <0x1>; + #size-cells = <0x1>; + store@0 { + compatible = "sandbox,sandbox_store"; + reg = <0x0 0x400>; + }; + }; + chosen { #address-cells = <1>; #size-cells = <1>; diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 2fc84a16c91..83107c7f99a 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -45,6 +45,7 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SF=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y +CONFIG_CMD_AXI=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_TFTPSRV=y CONFIG_CMD_RARP=y @@ -81,6 +82,8 @@ CONFIG_DEVRES=y CONFIG_DEBUG_DEVRES=y CONFIG_ADC=y CONFIG_ADC_SANDBOX=y +CONFIG_AXI=y +CONFIG_AXI_SANDBOX=y CONFIG_CLK=y CONFIG_CPU=y CONFIG_DM_DEMO=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] video_display: Add Xilinx LogiCore DP TX
Add a driver for the Xilinx LogiCORE DisplayPort IP core, which is a pure DP transmitter core for Xiling FPGA (no display capabilities). Signed-off-by: Mario Six--- v1 -> v2: * Switch to display_enable * Mentioned that the LogiCORE has no display capabilities --- drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/logicore_dp_dpcd.h | 342 ++ drivers/video/logicore_dp_tx.c | 1975 ++ drivers/video/logicore_dp_tx.h | 40 + drivers/video/logicore_dp_tx_regif.h | 365 +++ 6 files changed, 2734 insertions(+) create mode 100644 drivers/video/logicore_dp_dpcd.h create mode 100644 drivers/video/logicore_dp_tx.c create mode 100644 drivers/video/logicore_dp_tx.h create mode 100644 drivers/video/logicore_dp_tx_regif.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 4c4d2861fe7..ddec697e359 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -423,6 +423,17 @@ config ATMEL_HLCD help HLCDC supports video output to an attached LCD panel. +config LOGICORE_DP_TX + bool "Enable Logicore DP TX driver" + depends on DISPLAY + help + Enable the driver for the transmitter part of the Xilinx LogiCORE + DisplayPort, a IP core for Xilinx FPGAs that implements a DisplayPort + video interface as defined by VESA DisplayPort v1.2. + + Note that this is a pure transmitter device, and has no display + capabilities by itself. + config VIDEO_BROADWELL_IGD bool "Enable Intel Broadwell integrated graphics device" depends on X86 diff --git a/drivers/video/Makefile b/drivers/video/Makefile index cf7ad281c3b..fa4ac715fcf 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o obj-$(CONFIG_ATMEL_HLCD) += atmel_hlcdfb.o +obj-$(CONFIG_LOGICORE_DP_TX) += logicore_dp_tx.o obj-$(CONFIG_ATMEL_LCD) += atmel_lcdfb.o obj-$(CONFIG_CFB_CONSOLE) += cfb_console.o obj-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o diff --git a/drivers/video/logicore_dp_dpcd.h b/drivers/video/logicore_dp_dpcd.h new file mode 100644 index 000..68582945514 --- /dev/null +++ b/drivers/video/logicore_dp_dpcd.h @@ -0,0 +1,342 @@ +/* + * logicore_dp_dpcd.h + * + * DPCD interface definition for XILINX LogiCore DisplayPort v6.1 + * based on Xilinx dp_v3_1 driver sources + * + * (C) Copyright 2016 + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __GDSYS_LOGICORE_DP_DPCD_H__ +#define __GDSYS_LOGICORE_DP_DPCD_H__ + +/* receiver capability field */ +#define DPCD_REV 0x0 +#define DPCD_MAX_LINK_RATE 0x1 +#define DPCD_MAX_LANE_COUNT0x2 +#define DPCD_MAX_DOWNSPREAD0x3 +#define DPCD_NORP_PWR_V_CAP0x4 +#define DPCD_DOWNSP_PRESENT0x5 +#define DPCD_ML_CH_CODING_CAP 0x6 +#define DPCD_DOWNSP_COUNT_MSA_OUI 0x7 +#defineDPCD_RX_PORT0_CAP_0 0x8 +#defineDPCD_RX_PORT0_CAP_1 0x9 +#defineDPCD_RX_PORT1_CAP_0 0xA +#defineDPCD_RX_PORT1_CAP_1 0xB +#define DPCD_I2C_SPEED_CTL_CAP 0xC +#define DPCD_EDP_CFG_CAP 0xD +#define DPCD_TRAIN_AUX_RD_INTERVAL 0xE +#define DPCD_ADAPTER_CAP 0xF +#define DPCD_FAUX_CAP 0x00020 +#define DPCD_MSTM_CAP 0x00021 +#define DPCD_NUM_AUDIO_EPS 0x00022 +#defineDPCD_AV_GRANULARITY 0x00023 +#define DPCD_AUD_DEC_LAT_7_0 0x00024 +#define DPCD_AUD_DEC_LAT_15_8 0x00025 +#define DPCD_AUD_PP_LAT_7_00x00026 +#define DPCD_AUD_PP_LAT_15_8 0x00027 +#define DPCD_VID_INTER_LAT 0x00028 +#define DPCD_VID_PROG_LAT 0x00029 +#define DPCD_REP_LAT 0x0002A +#define DPCD_AUD_DEL_INS_7_0 0x0002B +#define DPCD_AUD_DEL_INS_15_8 0x0002C +#define DPCD_AUD_DEL_INS_23_16
[U-Boot] [PATCH v2 3/7] axi: Add AXI sandbox driver and simple emulator
Add test infrastructure and tests for the AXI uclass. Signed-off-by: Mario Six--- v1 -> v2: * Spelled out abbreviations in Kconfig help * Expanded emulation documentation * Renamed storage pointer to storep * Expanded AXI emulator usage documentation * Switched AXI emulator to aligned access --- drivers/axi/Kconfig | 7 +++ drivers/axi/Makefile | 3 ++ drivers/axi/axi-emul-uclass.c | 68 ++ drivers/axi/axi_sandbox.c | 77 + drivers/axi/sandbox_store.c | 110 ++ include/axi.h | 84 include/dm/uclass-id.h| 1 + 7 files changed, 350 insertions(+) create mode 100644 drivers/axi/axi-emul-uclass.c create mode 100644 drivers/axi/axi_sandbox.c create mode 100644 drivers/axi/sandbox_store.c diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig index ae80c98af8a..f81d843f894 100644 --- a/drivers/axi/Kconfig +++ b/drivers/axi/Kconfig @@ -22,4 +22,11 @@ config IHS_AXI Interface (IHS AXI) bus on a gdsys IHS FPGA used to communicate with IP cores in the FPGA (e.g. video transmitter cores). +config AXI_SANDBOX + bool "Enable AXI sandbox driver" + depends on DM + help + Support AXI (Advanced eXtensible Interface) emulation for the sandbox + environment. + endif diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile index 18d9380e9ba..66b6c5a28f4 100644 --- a/drivers/axi/Makefile +++ b/drivers/axi/Makefile @@ -7,3 +7,6 @@ obj-$(CONFIG_AXI) += axi-uclass.o obj-$(CONFIG_IHS_AXI) += ihs_axi.o +obj-$(CONFIG_SANDBOX) += axi-emul-uclass.o +obj-$(CONFIG_SANDBOX) += sandbox_store.o +obj-$(CONFIG_AXI_SANDBOX) += axi_sandbox.o diff --git a/drivers/axi/axi-emul-uclass.c b/drivers/axi/axi-emul-uclass.c new file mode 100644 index 000..8d37935323f --- /dev/null +++ b/drivers/axi/axi-emul-uclass.c @@ -0,0 +1,68 @@ +/* + * (C) Copyright 2018 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include + +int axi_sandbox_get_emul(struct udevice *bus, ulong address, enum axi_size_t size, +struct udevice **emulp) +{ + struct udevice *dev; + u32 reg[2]; + uint offset; + + switch (size) { + case AXI_SIZE_8: + offset = 1; + break; + case AXI_SIZE_16: + offset = 2; + break; + case AXI_SIZE_32: + offset = 4; + break; + default: + offset = 0; + } + + for (device_find_first_child(bus, ); +dev; +device_find_next_child()) { + int ret; + + ret = dev_read_u32_array(dev, "reg", reg, ARRAY_SIZE(reg)); + if (ret) + continue; + + if (address >= reg[0] && address <= reg[0] + reg[1] - offset) { + if (device_probe(dev)) + return -ENODEV; + + *emulp = dev; + return 0; + } + } + + return -ENODEV; +} + +int axi_get_store(struct udevice *dev, u8 **storep) +{ + struct axi_emul_ops *ops = axi_emul_get_ops(dev); + + if (!ops->get_store) + return -ENOSYS; + + return ops->get_store(dev, storep); +} + +UCLASS_DRIVER(axi_emul) = { + .id = UCLASS_AXI_EMUL, + .name = "axi_emul", +}; diff --git a/drivers/axi/axi_sandbox.c b/drivers/axi/axi_sandbox.c new file mode 100644 index 000..7a485b114bf --- /dev/null +++ b/drivers/axi/axi_sandbox.c @@ -0,0 +1,77 @@ +/* + * (C) Copyright 2018 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include + +/* + * This driver implements a AXI bus for the sandbox architecture for testing + * purposes. + * + * The bus forwards every access to it to a special AXI emulation device (which + * it gets via the axi_emul_get_ops function) that implements a simple + * read/write storage. + * + * The emulator device must still be contained in the device tree in the usual + * way, since configuration data for the storage is read from the DT. + */ + +int axi_sandbox_read(struct udevice *bus, ulong address, void *data, +enum axi_size_t size) +{ + struct axi_emul_ops *ops; + struct udevice *emul; + int ret; + + /* Get emulator device */ + ret = axi_sandbox_get_emul(bus, address, size, ); + if (ret) + return ret == -ENODEV ? 0 : ret; + /* Forward all reads to the AXI emulator */ + ops = axi_emul_get_ops(emul); + if (!ops || !ops->read) + return -ENOSYS; + + return ops->read(emul, address, data, size); +} + +int
[U-Boot] [PATCH v2 6/7] cmd: Add axi command
Add a command to debug the AXI bus. Signed-off-by: Mario Six--- v1 -> v2: No changes --- cmd/Kconfig | 8 ++ cmd/Makefile | 1 + cmd/axi.c| 310 +++ 3 files changed, 319 insertions(+) create mode 100644 cmd/axi.c diff --git a/cmd/Kconfig b/cmd/Kconfig index 38406fcfdac..0f730f7a397 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -995,6 +995,14 @@ config CMD_USB_MASS_STORAGE help USB mass storage support +config CMD_AXI + bool "axi" + depends on AXI + help + Enable the command "axi" for accessing AXI (Advanced eXtensible + Interface) busses, a on-chip interconnect specification for managing + functional blocks in SoC designs, which is also often used in designs + involving FPGAs (e.g. communication with IP cores in Xilinx FPGAs). endmenu diff --git a/cmd/Makefile b/cmd/Makefile index 0d7322ee0a4..cfca11499ec 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -145,6 +145,7 @@ obj-$(CONFIG_CMD_ZFS) += zfs.o obj-$(CONFIG_CMD_DFU) += dfu.o obj-$(CONFIG_CMD_GPT) += gpt.o obj-$(CONFIG_CMD_ETHSW) += ethsw.o +obj-$(CONFIG_CMD_AXI) += axi.o # Power obj-$(CONFIG_CMD_PMIC) += pmic.o diff --git a/cmd/axi.c b/cmd/axi.c new file mode 100644 index 000..d8001875e2c --- /dev/null +++ b/cmd/axi.c @@ -0,0 +1,310 @@ +/* + * (C) Copyright 2016 + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc + * + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include + +static struct udevice *axi_cur_bus; +static uint dp_last_size; +static uint dp_last_addr; +static uint dp_last_length = 0x40; + +static void show_bus(struct udevice *bus) +{ + struct udevice *dev; + + printf("Bus %d:\t%s", bus->req_seq, bus->name); + if (device_active(bus)) + printf(" (active %d)", bus->seq); + printf("\n"); + for (device_find_first_child(bus, ); +dev; +device_find_next_child()) + printf(" %s\n", dev->name); +} + +static int do_axi_show_bus(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + if (argc == 1) { + /* show all busses */ + struct udevice *bus; + + for (uclass_first_device(UCLASS_AXI, ); +bus; +uclass_next_device()) + show_bus(bus); + } else { + int i; + + /* show specific bus */ + i = simple_strtoul(argv[1], NULL, 10); + + struct udevice *bus; + int ret; + + ret = uclass_get_device_by_seq(UCLASS_AXI, i, ); + if (ret) { + printf("Invalid bus %d: err=%d\n", i, ret); + return CMD_RET_FAILURE; + } + show_bus(bus); + } + + return 0; +} + +static int cmd_axi_set_bus_num(unsigned int busnum) +{ + struct udevice *bus; + struct udevice *dummy; + int ret; + + /* Make sure that all sequence numbers are initialized */ + for (uclass_first_device(UCLASS_AXI, ); +dummy; +uclass_next_device()) + ; + + ret = uclass_get_device_by_seq(UCLASS_AXI, busnum, ); + if (ret) { + debug("%s: No bus %d\n", __func__, busnum); + return ret; + } + axi_cur_bus = bus; + + return 0; +} + +static int axi_get_cur_bus(struct udevice **busp) +{ + if (!axi_cur_bus) { + puts("No AXI bus selected\n"); + return ENODEV; + } + *busp = axi_cur_bus; + + return 0; +} + +static int do_axi_bus_num(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + int ret = 0; + int bus_no; + + if (argc == 1) { + /* querying current setting */ + struct udevice *bus; + + if (!axi_get_cur_bus()) + bus_no = bus->seq; + else + bus_no = -1; + printf("Current bus is %d\n", bus_no); + } else { + bus_no = simple_strtoul(argv[1], NULL, 10); + printf("Setting bus to %d\n", bus_no); + + ret = cmd_axi_set_bus_num(bus_no); + + if (ret) + printf("Failure changing bus number (%d)\n", ret); + } + + return ret ? CMD_RET_FAILURE : 0; +} + +#define DISP_LINE_LEN 16 + +int do_axi_md(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) +{ + unsigned int k; + ulong addr, length, size; + int rc = 0; + u32 linebuf[DISP_LINE_LEN / sizeof(u32)]; + ulong nbytes; + enum axi_size_t axisize; + int unitsize; + +
[U-Boot] [PATCH v2 2/7] axi: Add ihs_axi driver
Add a driver for the gdsys IHS AXI bus used on IHS FPGAs. Signed-off-by: Mario Six--- v1 -> v2: New in v2 --- drivers/axi/Kconfig | 12 drivers/axi/Makefile | 1 + drivers/axi/ihs_axi.c | 179 ++ 3 files changed, 192 insertions(+) create mode 100644 drivers/axi/ihs_axi.c diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig index 4e4153b4283..ae80c98af8a 100644 --- a/drivers/axi/Kconfig +++ b/drivers/axi/Kconfig @@ -11,3 +11,15 @@ menuconfig AXI for now). Other similar bus architectures may be compatible as well. + +if AXI + +config IHS_AXI + bool "Enable IHS AXI driver" + depends on DM + help + Support for gdsys Integrated Hardware Systems Advanced eXtensible + Interface (IHS AXI) bus on a gdsys IHS FPGA used to communicate with + IP cores in the FPGA (e.g. video transmitter cores). + +endif diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile index 100a77788a2..18d9380e9ba 100644 --- a/drivers/axi/Makefile +++ b/drivers/axi/Makefile @@ -6,3 +6,4 @@ # obj-$(CONFIG_AXI) += axi-uclass.o +obj-$(CONFIG_IHS_AXI) += ihs_axi.o diff --git a/drivers/axi/ihs_axi.c b/drivers/axi/ihs_axi.c new file mode 100644 index 000..21227638f78 --- /dev/null +++ b/drivers/axi/ihs_axi.c @@ -0,0 +1,179 @@ +/* + * (C) Copyright 2016 + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc + * + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +struct ihs_axi_regs { + u16 interrupt_status; + u16 interrupt_enable_control; + u16 address_lsb; + u16 address_msb; + u16 write_data_lsb; + u16 write_data_msb; + u16 read_data_lsb; + u16 read_data_msb; +}; + +#define ihs_axi_set(map, member, val) \ + regmap_set(map, struct ihs_axi_regs, member, val) + +#define ihs_axi_get(map, member, valp) \ + regmap_get(map, struct ihs_axi_regs, member, valp) + +struct ihs_axi_priv { + struct regmap *map; +}; + +enum { + STATUS_EVENT_MASK = GENMASK(15, 12), + + STATUS_READ_COMPLETE_EVENT = BIT(15), + STATUS_WRITE_COMPLETE_EVENT = BIT(14), + STATUS_TIMEOUT_EVENT = BIT(13), + STATUS_ERROR_EVENT = BIT(12), + STATUS_AXI_INT = BIT(11), + STATUS_READ_DATA_AVAILABLE = BIT(7), + STATUS_BUSY = BIT(6), + STATUS_INIT_DONE = BIT(5), +}; + +enum { + CONTROL_EVENT_ENABLE_MASK = GENMASK(15, 11), + CONTROL_CMD_MASK = GENMASK(3, 0), + + CONTROL_READ_COMPLETE_EVENT_ENABLE = BIT(15), + CONTROL_WRITE_COMPLETE_EVENT_ENABLE = BIT(14), + CONTROL_TIMEOUT_EVENT_ENABLE = BIT(13), + CONTROL_ERROR_EVENT_ENABLE = BIT(12), + CONTROL_AXI_INT_ENABLE = BIT(11), + + CONTROL_CMD_NOP = 0x0, + CONTROL_CMD_WRITE = 0x8, + CONTROL_CMD_WRITE_POST_INC = 0x9, + CONTROL_CMD_READ = 0xa, + CONTROL_CMD_READ_POST_INC = 0xb, + +}; + +static int ihs_axi_transfer(struct udevice *bus, ulong address, u16 cmd, + u16 complete_flag) +{ + struct ihs_axi_priv *priv = dev_get_priv(bus); + u16 wait_mask = complete_flag | STATUS_TIMEOUT_EVENT | + STATUS_ERROR_EVENT; + u16 status; + uint k; + + cmd &= CONTROL_CMD_MASK; + + ihs_axi_set(priv->map, address_lsb, address & 0x); + ihs_axi_set(priv->map, address_msb, (address >> 16) & 0x); + + ihs_axi_set(priv->map, interrupt_status, wait_mask); + ihs_axi_set(priv->map, interrupt_enable_control, cmd); + + for (k = 10; k > 0; --k) { + ihs_axi_get(priv->map, interrupt_status, ); + if (status & wait_mask) + break; + udelay(1); + } + + if (!k) + ihs_axi_get(priv->map, interrupt_status, ); + + if (status & complete_flag) + return 0; + + if (status & STATUS_ERROR_EVENT) + return -EIO; + + return -ETIMEDOUT; +} + +/* + * API + */ + +int ihs_axi_read(struct udevice *dev, ulong address, void *data, +enum axi_size_t size) +{ + struct ihs_axi_priv *priv = dev_get_priv(dev); + int res = 0; + u16 data_lsb, data_msb; + u32 *p = data; + + if (size != AXI_SIZE_32) + return -ENOSYS; + + res = ihs_axi_transfer(dev, address, CONTROL_CMD_READ, + STATUS_READ_COMPLETE_EVENT); + if (res < 0) + return res; + + ihs_axi_get(priv->map, read_data_lsb, _lsb); + ihs_axi_get(priv->map, read_data_msb, _msb); + + *p = (data_msb << 16) | data_lsb; + + return res; +} + +int ihs_axi_write(struct udevice *dev, ulong address, void *data, + enum axi_size_t size) +{ + struct ihs_axi_priv
[U-Boot] [PATCH v2 5/7] test: Add AXI test
Add tests for the AXI uclass. Signed-off-by: Mario Six--- v1 -> v2: * Fixed asserts (moved expected values first) --- test/dm/Makefile | 1 + test/dm/axi.c| 74 2 files changed, 75 insertions(+) create mode 100644 test/dm/axi.c diff --git a/test/dm/Makefile b/test/dm/Makefile index 5511a85700c..de8b9940888 100644 --- a/test/dm/Makefile +++ b/test/dm/Makefile @@ -43,4 +43,5 @@ obj-$(CONFIG_DM_VIDEO) += video.o obj-$(CONFIG_ADC) += adc.o obj-$(CONFIG_SPMI) += spmi.o obj-$(CONFIG_WDT) += wdt.o +obj-$(CONFIG_AXI) += axi.o endif diff --git a/test/dm/axi.c b/test/dm/axi.c new file mode 100644 index 000..cd31efd6126 --- /dev/null +++ b/test/dm/axi.c @@ -0,0 +1,74 @@ +/* + * (C) Copyright 2018 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include + +/* Test that sandbox AXI works correctly */ +static int dm_test_axi_base(struct unit_test_state *uts) +{ + struct udevice *bus; + + ut_assertok(uclass_get_device(UCLASS_AXI, 0, )); + + return 0; +} +DM_TEST(dm_test_axi_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT); + +/* Test that sandbox PCI bus numbering works correctly */ +static int dm_test_axi_busnum(struct unit_test_state *uts) +{ + struct udevice *bus; + + ut_assertok(uclass_get_device_by_seq(UCLASS_AXI, 0, )); + + return 0; +} +DM_TEST(dm_test_axi_busnum, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT); + +/* Test that we can use the store device correctly */ +static int dm_test_axi_store(struct unit_test_state *uts) +{ + struct udevice *store; + u8 tdata1[] = {0x55, 0x66, 0x77, 0x88}; + u8 tdata2[] = {0xAA, 0xBB, 0xCC, 0xDD}; + u32 val; + u8 *data; + + /* Check that asking for the device automatically fires up AXI */ + ut_assertok(uclass_get_device(UCLASS_AXI_EMUL, 0, )); + ut_assert(device_active(store)); + + axi_get_store(store, ); + + /* Test reading */ + memcpy(data, tdata1, ARRAY_SIZE(tdata1)); + axi_read(store, 0, , AXI_SIZE_32); + ut_asserteq(0x55667788, val); + + memcpy(data + 3, tdata2, ARRAY_SIZE(tdata2)); + axi_read(store, 3, , AXI_SIZE_32); + ut_asserteq(0xAABBCCDD, val); + + /* Reset data store */ + memset(data, 0, 16); + + /* Test writing */ + val = 0x55667788; + axi_write(store, 0, , AXI_SIZE_32); + ut_asserteq(0, memcmp(data, tdata1, ARRAY_SIZE(tdata1))); + + val = 0xAABBCCDD; + axi_write(store, 3, , AXI_SIZE_32); + ut_asserteq(0, memcmp(data + 3, tdata2, ARRAY_SIZE(tdata1))); + + return 0; +} +DM_TEST(dm_test_axi_store, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT); -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] drivers: Add AXI uclass
Add a uclass for AXI (Advanced eXtensible Interface) busses, and a driver for the gdsys IHS AXI bus on IHS FPGAs. Signed-off-by: Mario Six--- v1 -> v2: * Spelled out all abbreviations in the Kconfig help * Split commit into uclass addition and driver addition --- drivers/Kconfig | 2 ++ drivers/Makefile | 1 + drivers/axi/Kconfig | 13 + drivers/axi/Makefile | 8 ++ drivers/axi/axi-uclass.c | 40 ++ include/axi.h| 75 include/dm/uclass-id.h | 1 + 7 files changed, 140 insertions(+) create mode 100644 drivers/axi/Kconfig create mode 100644 drivers/axi/Makefile create mode 100644 drivers/axi/axi-uclass.c create mode 100644 include/axi.h diff --git a/drivers/Kconfig b/drivers/Kconfig index c2e813f5adf..eeaaa7575cd 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -8,6 +8,8 @@ source "drivers/adc/Kconfig" source "drivers/ata/Kconfig" +source "drivers/axi/Kconfig" + source "drivers/block/Kconfig" source "drivers/bootcount/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index b3f1b600a55..54b396d6368 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -99,6 +99,7 @@ obj-y += input/ obj-y += soc/ obj-$(CONFIG_REMOTEPROC) += remoteproc/ obj-y += thermal/ +obj-y += axi/ obj-$(CONFIG_MACH_PIC32) += ddr/microchip/ endif diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig new file mode 100644 index 000..4e4153b4283 --- /dev/null +++ b/drivers/axi/Kconfig @@ -0,0 +1,13 @@ +menuconfig AXI + bool "AXI bus drivers" + help + Support AXI (Advanced eXtensible Interface) busses, a on-chip + interconnect specification for managing functional blocks in SoC + designs, which is also often used in designs involving FPGAs (e.g. + communication with IP cores in Xilinx FPGAs). + + These types of busses expose a virtual address space that can be + accessed using different address widths (8, 16, and 32 are supported + for now). + + Other similar bus architectures may be compatible as well. diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile new file mode 100644 index 000..100a77788a2 --- /dev/null +++ b/drivers/axi/Makefile @@ -0,0 +1,8 @@ +# +# (C) Copyright 2017 +# Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-$(CONFIG_AXI) += axi-uclass.o diff --git a/drivers/axi/axi-uclass.c b/drivers/axi/axi-uclass.c new file mode 100644 index 000..3a5ddf3a46a --- /dev/null +++ b/drivers/axi/axi-uclass.c @@ -0,0 +1,40 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include + +int axi_read(struct udevice *dev, ulong address, void *data, +enum axi_size_t size) +{ + struct axi_ops *ops = axi_get_ops(dev); + + if (!ops->read) + return -ENOSYS; + + return ops->read(dev, address, data, size); +} + +int axi_write(struct udevice *dev, ulong address, void *data, + enum axi_size_t size) +{ + struct axi_ops *ops = axi_get_ops(dev); + + if (!ops->write) + return -ENOSYS; + + return ops->write(dev, address, data, size); +} + +UCLASS_DRIVER(axi) = { + .id = UCLASS_AXI, + .name = "axi", + .post_bind = dm_scan_fdt_dev, + .flags = DM_UC_FLAG_SEQ_ALIAS, +}; + diff --git a/include/axi.h b/include/axi.h new file mode 100644 index 000..317e931a6cf --- /dev/null +++ b/include/axi.h @@ -0,0 +1,75 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _AXI_H_ +#define _AXI_H_ + +enum axi_size_t { + AXI_SIZE_8, + AXI_SIZE_16, + AXI_SIZE_32, +}; + +/** + * struct axi_ops - driver operations for AXI uclass + * + * Drivers should support these operations unless otherwise noted. These + * operations are intended to be used by uclass code, not directly from + * other code. + */ +struct axi_ops { + /** +* read() - Read a single value from a specified address on a AXI bus +* +* @dev:AXI bus to read from. +* @address:The address to read from. +* @data: Pointer to a variable that takes the data value read +* from the address on the AXI bus. +* @size: The size of the data to be read. +* @return 0 if OK, -ve on error. +*/ + int (*read)(struct udevice *dev, ulong address, void *data, enum axi_size_t size); + + /** +* write() - Write a single value to a specified address on a AXI bus +* +* @dev:AXI bus to write to. +* @address:The address to write to. +* @data:
[U-Boot] [PATCH v2 5/5] cmd: Add osd commands
Add command to query information from and write text to on-screen display (OSD) devices. Signed-off-by: Mario Six--- v1 -> v2: * Added explanation for what a OSD is * Added explanation of the color parameter * Moved GDSYS_LEGACY_OSD_CMDS to gdsys Kconfig --- board/gdsys/mpc8308/Kconfig | 11 ++ cmd/Kconfig | 8 + cmd/Makefile| 1 + cmd/osd.c | 378 4 files changed, 398 insertions(+) create mode 100644 cmd/osd.c diff --git a/board/gdsys/mpc8308/Kconfig b/board/gdsys/mpc8308/Kconfig index cb29c25c650..9d99f686923 100644 --- a/board/gdsys/mpc8308/Kconfig +++ b/board/gdsys/mpc8308/Kconfig @@ -1,3 +1,9 @@ +config GDSYS_LEGACY_OSD_CMDS + bool + help + Use the 'osdw', 'osdp', and 'osdsize' legacy commands required by + gdsys devices. + if TARGET_HRCON config SYS_BOARD @@ -9,6 +15,9 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "hrcon" +config GDSYS_LEGACY_OSD_CMDS + default y + endif if TARGET_STRIDER @@ -22,6 +31,8 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "strider" +config GDSYS_LEGACY_OSD_CMDS + default y endif config CMD_IOLOOP diff --git a/cmd/Kconfig b/cmd/Kconfig index 38406fcfdac..898839c8d75 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -865,6 +865,14 @@ config CMD_ONENAND and erasing blocks. It allso provides a way to show and change bad blocks, and test the device. +config CMD_OSD + bool "osd" + help + Enable the 'osd' command which allows to query information from and + write text data to a on-screen display (OSD) device; a virtual device + associated with a display capable of displaying a text overlay on the + display it's associated with.. + config CMD_PART bool "part" select PARTITION_UUIDS diff --git a/cmd/Makefile b/cmd/Makefile index 0d7322ee0a4..4aeab8e5c77 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_CMD_FUSE) += fuse.o obj-$(CONFIG_CMD_GETTIME) += gettime.o obj-$(CONFIG_CMD_GPIO) += gpio.o obj-$(CONFIG_CMD_HVC) += smccc.o +obj-$(CONFIG_CMD_OSD) += osd.o obj-$(CONFIG_CMD_I2C) += i2c.o obj-$(CONFIG_CMD_IOTRACE) += iotrace.o obj-$(CONFIG_CMD_HASH) += hash.o diff --git a/cmd/osd.c b/cmd/osd.c new file mode 100644 index 000..8afbe85475b --- /dev/null +++ b/cmd/osd.c @@ -0,0 +1,378 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * based on the gdsys osd driver, which is + * + * (C) Copyright 2010 + * Dirk Eibach, Guntermann & Drunck GmbH, eib...@gdsys.de + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include + +#ifndef CONFIG_GDSYS_LEGACY_OSD_CMDS +static struct udevice *osd_cur; +#endif + +#ifdef CONFIG_GDSYS_LEGACY_OSD_CMDS +int do_osd_write(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) +{ + struct udevice *dev; + uint x, y; + uint count; + char *hexstr; + u8 *buffer; + size_t buflen; + + if (argc < 4 || (strlen(argv[3])) % 2) { + cmd_usage(cmdtp); + return CMD_RET_FAILURE; + } + + x = simple_strtoul(argv[1], NULL, 16); + y = simple_strtoul(argv[2], NULL, 16); + hexstr = argv[3]; + count = (argc > 4) ? simple_strtoul(argv[4], NULL, 16) : 1; + + buflen = strlen(hexstr) / 2; + buffer = malloc(buflen); + hex2bin(buffer, hexstr, buflen); + + for (uclass_first_device(UCLASS_VIDEO_OSD, ); +dev; +uclass_next_device()) { + int res; + + res = video_osd_set_mem(dev, x, y, buffer, buflen, count); + + if (res) { + printf("Could not write to video mem on osd %s\n", + dev->name); + return CMD_RET_FAILURE; + } + } + + free(buffer); + + return CMD_RET_SUCCESS; +} + +static int do_osd_print(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + struct udevice *dev; + uint x, y; + u8 color; + char *text; + + if (argc < 5) { + cmd_usage(cmdtp); + return CMD_RET_FAILURE; + } + + x = simple_strtoul(argv[1], NULL, 16); + y = simple_strtoul(argv[2], NULL, 16); + color = simple_strtoul(argv[3], NULL, 16); + text = argv[4]; + + for (uclass_first_device(UCLASS_VIDEO_OSD, ); +dev; +uclass_next_device()) { + int res; + + res = video_osd_print(dev, x, y, color, text); + if (res) { + printf("Could not print string to osd %s\n", dev->name); + return CMD_RET_FAILURE; + } + } + + return CMD_RET_SUCCESS; +} + +int do_osd_size(cmd_tbl_t *cmdtp,
[U-Boot] [PATCH v2 3/5] video_osd: Add osd sandbox driver and tests
Add sandbox driver and tests for the new OSD uclass. Signed-off-by: Mario Six--- v1 -> v2: New in v2 --- arch/sandbox/dts/test.dts | 4 + configs/sandbox64_defconfig| 3 + configs/sandbox_defconfig | 3 + configs/sandbox_flattree_defconfig | 3 + configs/sandbox_noblk_defconfig| 3 + configs/sandbox_spl_defconfig | 3 + drivers/video/Kconfig | 6 ++ drivers/video/Makefile | 1 + drivers/video/sandbox_osd.c| 157 drivers/video/sandbox_osd.h| 14 +++ drivers/video/video_osd-uclass.c | 9 ++ include/video_osd.h| 7 ++ test/dm/Makefile | 1 + test/dm/osd.c | 208 + 14 files changed, 422 insertions(+) create mode 100644 drivers/video/sandbox_osd.c create mode 100644 drivers/video/sandbox_osd.h create mode 100644 test/dm/osd.c diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 5a0f187d8b7..b6cdda0fd33 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -559,6 +559,10 @@ }; }; }; + + osd { + compatible = "sandbox,sandbox_osd"; + }; }; #include "sandbox_pmic.dtsi" diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index 20a2ab3ffb7..7464a3ca3af 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -39,6 +39,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_GPT_RENAME=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_READ=y CONFIG_CMD_REMOTEPROC=y @@ -185,6 +186,8 @@ CONFIG_CONSOLE_ROTATION=y CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y CONFIG_WDT=y CONFIG_WDT_SANDBOX=y CONFIG_FS_CBFS=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 2fc84a16c91..f7925dfe6fb 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -39,6 +39,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_GPT_RENAME=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_READ=y CONFIG_CMD_REMOTEPROC=y @@ -186,6 +187,8 @@ CONFIG_CONSOLE_ROTATION=y CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y CONFIG_WDT=y CONFIG_WDT_SANDBOX=y CONFIG_FS_CBFS=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index e922c4b38ff..126b9c07c54 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -31,6 +31,7 @@ CONFIG_CMD_DEMO=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y +CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SF=y @@ -167,6 +168,8 @@ CONFIG_CONSOLE_ROTATION=y CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y CONFIG_CMD_DHRYSTONE=y CONFIG_TPM=y CONFIG_LZ4=y diff --git a/configs/sandbox_noblk_defconfig b/configs/sandbox_noblk_defconfig index 8bdd4edcda6..243234b6c72 100644 --- a/configs/sandbox_noblk_defconfig +++ b/configs/sandbox_noblk_defconfig @@ -35,6 +35,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SF=y @@ -166,6 +167,8 @@ CONFIG_CONSOLE_ROTATION=y CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y CONFIG_FS_CBFS=y CONFIG_FS_CRAMFS=y CONFIG_CMD_DHRYSTONE=y diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig index fb6bb4baa2b..771d0f05a48 100644 --- a/configs/sandbox_spl_defconfig +++ b/configs/sandbox_spl_defconfig @@ -43,6 +43,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SF=y @@ -185,6 +186,8 @@ CONFIG_CONSOLE_ROTATION=y CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y CONFIG_FS_CBFS=y CONFIG_FS_CRAMFS=y CONFIG_CMD_DHRYSTONE=y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 4ca15174bb2..b1a8e05ad74 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -667,6 +667,12 @@ config OSD is a (usually text-oriented) graphics buffer to show information on a display. +config SANDBOX_OSD + bool "Enable sandbox OSD" + depends on OSD + help + Enable support for sandbox OSD device used for testing purposes. + config IHS_VIDEO_OUT bool "Enable IHS video out driver" depends on OSD diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 44252b5989a..80a8b19ed5d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -56,6
[U-Boot] [PATCH v2 4/5] lib: Import hexdump.c from Linux
Especially for commands, it is useful to be able to turn a hexadecimal string into its binary representation. Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the Linux kernel. Signed-off-by: Mario Six--- v1 -> v2: New in v2 --- include/linux/kernel.h | 4 + lib/Makefile | 1 + lib/hexdump.c | 321 + 3 files changed, 326 insertions(+) create mode 100644 lib/hexdump.c diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 04a09eb4f64..ea31759667c 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -150,6 +150,10 @@ (__x < 0) ? -__x : __x; \ }) +extern int hex_to_bin(char ch); +extern int __must_check hex2bin(u8 *dst, const char *src, size_t count); +extern char *bin2hex(char *dst, const void *src, size_t count); + /* * min()/max()/clamp() macros that also do * strict type-checking.. See the diff --git a/lib/Makefile b/lib/Makefile index d531ea54b31..0f6d744579f 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o +obj-y += hexdump.o obj-y += initcall.o obj-$(CONFIG_LMB) += lmb.o obj-y += ldiv.o diff --git a/lib/hexdump.c b/lib/hexdump.c new file mode 100644 index 000..81587c2ee75 --- /dev/null +++ b/lib/hexdump.c @@ -0,0 +1,321 @@ +/* + * lib/hexdump.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +const char hex_asc[] = "0123456789abcdef"; +EXPORT_SYMBOL(hex_asc); +const char hex_asc_upper[] = "0123456789ABCDEF"; +EXPORT_SYMBOL(hex_asc_upper); + +#define hex_asc_lo(x) hex_asc[((x) & 0x0f)] +#define hex_asc_hi(x) hex_asc[((x) & 0xf0) >> 4] + +static inline char *hex_byte_pack(char *buf, u8 byte) +{ + *buf++ = hex_asc_hi(byte); + *buf++ = hex_asc_lo(byte); + return buf; +} + +extern const char hex_asc_upper[]; +#define hex_asc_upper_lo(x)hex_asc_upper[((x) & 0x0f)] +#define hex_asc_upper_hi(x)hex_asc_upper[((x) & 0xf0) >> 4] + +static inline char *hex_byte_pack_upper(char *buf, u8 byte) +{ + *buf++ = hex_asc_upper_hi(byte); + *buf++ = hex_asc_upper_lo(byte); + return buf; +} + +/** + * hex_to_bin - convert a hex digit to its real value + * @ch: ascii character represents hex digit + * + * hex_to_bin() converts one hex digit to its actual value or -1 in case of bad + * input. + */ +int hex_to_bin(char ch) +{ + if ((ch >= '0') && (ch <= '9')) + return ch - '0'; + ch = tolower(ch); + if ((ch >= 'a') && (ch <= 'f')) + return ch - 'a' + 10; + return -1; +} +EXPORT_SYMBOL(hex_to_bin); + +/** + * hex2bin - convert an ascii hexadecimal string to its binary representation + * @dst: binary result + * @src: ascii hexadecimal string + * @count: result length + * + * Return 0 on success, -EINVAL in case of bad input. + */ +int hex2bin(u8 *dst, const char *src, size_t count) +{ + while (count--) { + int hi = hex_to_bin(*src++); + int lo = hex_to_bin(*src++); + + if ((hi < 0) || (lo < 0)) + return -EINVAL; + + *dst++ = (hi << 4) | lo; + } + return 0; +} +EXPORT_SYMBOL(hex2bin); + +/** + * bin2hex - convert binary data to an ascii hexadecimal string + * @dst: ascii hexadecimal result + * @src: binary data + * @count: binary data length + */ +char *bin2hex(char *dst, const void *src, size_t count) +{ + const unsigned char *_src = src; + + while (count--) + dst = hex_byte_pack(dst, *_src++); + return dst; +} +EXPORT_SYMBOL(bin2hex); + +/** + * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory + * @buf: data blob to dump + * @len: number of bytes in the @buf + * @rowsize: number of bytes to print per line; must be 16 or 32 + * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1) + * @linebuf: where to put the converted data + * @linebuflen: total size of @linebuf, including space for terminating NUL + * @ascii: include ASCII after the hex output + * + * hex_dump_to_buffer() works on one "line" of output at a time, i.e., + * 16 or 32 bytes of input data converted to hex + ASCII output. + * + * Given a buffer of u8 data, hex_dump_to_buffer() converts the input data + * to a hex + ASCII dump at the supplied memory location. + * The converted output is always NUL-terminated. + * + * E.g.: + * hex_dump_to_buffer(frame->data, frame->len, 16, 1, + * linebuf, sizeof(linebuf), true); + * + * example
[U-Boot] [PATCH v2 1/5] drivers: Add OSD uclass
Some devices offer a text-based OSD (on-screen display) that can be programmatically controlled (i.e. text displayed on). Add a uclass to support such devices. Signed-off-by: Mario Six--- v1 -> v2: * Use singular case for UCLASS_VIDEO_OSD description * Expanded description of video_osd_set_mem with example * Replaced all left-over mentions of pixels with text * Renamed x and y parameters to col and row * Expaneded description of color parameter * Added general description of the OSD uclass * Expanded description of video_osd_info --- drivers/video/Kconfig| 8 ++ drivers/video/Makefile | 2 + drivers/video/video_osd-uclass.c | 46 ++ include/dm/uclass-id.h | 1 + include/video_osd.h | 193 +++ 5 files changed, 250 insertions(+) create mode 100644 drivers/video/video_osd-uclass.c create mode 100644 include/video_osd.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 4c4d2861fe7..37be23d2fcc 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -658,4 +658,12 @@ config VIDEO_DT_SIMPLEFB The video output is initialized by U-Boot, and kept by the kernel. +config OSD + bool "Enable OSD support" + depends on DM + default n + help + This supports drivers that provide a OSD (on-screen display), which + is a (usually text-oriented) graphics buffer to show information on + a display. endmenu diff --git a/drivers/video/Makefile b/drivers/video/Makefile index cf7ad281c3b..1889c5a5208 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -55,5 +55,7 @@ obj-${CONFIG_EXYNOS_FB} += exynos/ obj-${CONFIG_VIDEO_ROCKCHIP} += rockchip/ obj-${CONFIG_VIDEO_STM32} += stm32/ +obj-${CONFIG_OSD} += video_osd-uclass.o + obj-y += bridge/ obj-y += sunxi/ diff --git a/drivers/video/video_osd-uclass.c b/drivers/video/video_osd-uclass.c new file mode 100644 index 000..ae9b6a6fa82 --- /dev/null +++ b/drivers/video/video_osd-uclass.c @@ -0,0 +1,46 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include + +int video_osd_get_info(struct udevice *dev, struct video_osd_info *info) +{ + struct video_osd_ops *ops = video_osd_get_ops(dev); + + return ops->get_info(dev, info); +} + +int video_osd_set_mem(struct udevice *dev, uint col, uint row, u8 *buf, + size_t buflen, uint count) +{ + struct video_osd_ops *ops = video_osd_get_ops(dev); + + return ops->set_mem(dev, col, row, buf, buflen, count); +} + +int video_osd_set_size(struct udevice *dev, uint col, uint row) +{ + struct video_osd_ops *ops = video_osd_get_ops(dev); + + return ops->set_size(dev, col, row); +} + +int video_osd_print(struct udevice *dev, uint col, uint row, ulong color, + char *text) +{ + struct video_osd_ops *ops = video_osd_get_ops(dev); + + return ops->print(dev, col, row, color, text); +} + +UCLASS_DRIVER(video_osd) = { + .id = UCLASS_VIDEO_OSD, + .name = "video_osd", + .flags = DM_UC_FLAG_SEQ_ALIAS, +}; diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h index d7f9df3583a..e42f8481bf8 100644 --- a/include/dm/uclass-id.h +++ b/include/dm/uclass-id.h @@ -89,6 +89,7 @@ enum uclass_id { UCLASS_VIDEO, /* Video or LCD device */ UCLASS_VIDEO_BRIDGE,/* Video bridge, e.g. DisplayPort to LVDS */ UCLASS_VIDEO_CONSOLE, /* Text console driver for video device */ + UCLASS_VIDEO_OSD, /* On-screen display */ UCLASS_WDT, /* Watchdot Timer driver */ UCLASS_COUNT, diff --git a/include/video_osd.h b/include/video_osd.h new file mode 100644 index 000..c3bcd3a4fd8 --- /dev/null +++ b/include/video_osd.h @@ -0,0 +1,193 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _VIDEO_OSD_H_ +#define _VIDEO_OSD_H_ + +struct video_osd_info { + /* The width of the OSD display in columns */ + uint width; + /* The height of the OSD display in rows */ + uint height; + /* The major version of the OSD device */ + uint major_version; + /* The minor version of the OSD device */ + uint minor_version; +}; + +/** + * struct video_osd_ops - driver operations for OSD uclass + * + * The OSD uclass implements support for text-oriented on-screen displays, + * which are taken to be devices that independently display a graphical + * text-based overlay over the video output of an associated display. + * + * The functions defined by the uclass support writing text to the display in + * either a generic form (by specifying a string, a driver-specific color value + * for the text, and
[U-Boot] [PATCH v2 2/5] video_osd: Add ihs_video_out driver
Add a driver for IHS OSDs on IHS FPGAs. Signed-off-by: Mario Six--- v1 -> v2: * Renamed x and y parameters to col and row * Removed duplicate IHS_VIDEO_OUT definition * Switched error return code of ihs_video_out_set_mem to E2BIG * Dropped blank lines between dev_read_u32_default calls * Documented members of ihs_video_out_priv * Turned printfs into debugs * Don't display OSD until something has been written to it * Made the code a bit more readable * Added binding file * Expanded documentation and help * Switched to display_enable * Switched to regmap usage (instead of fpgamap uclass) * Renamed 'dp_tx' property to 'video_tx' --- .../video/osd/gdsys,ihs_video_out.txt | 22 ++ drivers/video/Kconfig | 9 + drivers/video/Makefile | 1 + drivers/video/ihs_video_out.c | 277 + 4 files changed, 309 insertions(+) create mode 100644 doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt create mode 100644 drivers/video/ihs_video_out.c diff --git a/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt b/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt new file mode 100644 index 000..464374613b8 --- /dev/null +++ b/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt @@ -0,0 +1,22 @@ +* Guntermann & Drunck Integrated Hardware Systems OSD + +Required properties: +- compatible: "gdsys,ihs_video_out" +- reg: Register base for the video registers +- osd_base: Register base for the OSD registers +- osd_buffer_base: Address of the OSD video memory +- mode: The initial resolution and frequency: "1024_768_60", "720_400_70", or +"640_480_70" +- clk_gen: phandle to the pixel clock generator +- dp_tx: phandle to the display associated with the OSD + +Example: + +fpga0_video0 { + compatible = "gdsys,ihs_video_out"; + reg = <0x100 0x40>; + osd_base = <0x180>; + osd_buffer_base = <0x1000>; + dp_tx = <_dp_video0>; + clk_gen = <_video0_clkgen>; +}; diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 37be23d2fcc..4ca15174bb2 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -666,4 +666,13 @@ config OSD This supports drivers that provide a OSD (on-screen display), which is a (usually text-oriented) graphics buffer to show information on a display. + +config IHS_VIDEO_OUT + bool "Enable IHS video out driver" + depends on OSD + help + Enable support for the gdsys Integrated Hardware Systems (IHS) video + out On-screen Display (OSD) used on gdsys FPGAs to control dynamic + textual overlays of the display outputs. + endmenu diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 1889c5a5208..44252b5989a 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -56,6 +56,7 @@ obj-${CONFIG_VIDEO_ROCKCHIP} += rockchip/ obj-${CONFIG_VIDEO_STM32} += stm32/ obj-${CONFIG_OSD} += video_osd-uclass.o +obj-$(CONFIG_IHS_VIDEO_OUT) += ihs_video_out.o obj-y += bridge/ obj-y += sunxi/ diff --git a/drivers/video/ihs_video_out.c b/drivers/video/ihs_video_out.c new file mode 100644 index 000..3a870e22c2e --- /dev/null +++ b/drivers/video/ihs_video_out.c @@ -0,0 +1,277 @@ +/* + * (C) Copyright 2017 + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc + * + * based on the gdsys osd driver, which is + * + * (C) Copyright 2010 + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.de + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include + +#define MAX_X_CHARS 53 +#define MAX_Y_CHARS 26 +#define MAX_VIDEOMEM_WIDTH (2 * 64) +#define MAX_VIDEOMEM_HEIGHT (2 * 32) +#define CHAR_WIDTH 12 +#define CHAR_HEIGHT 18 + +struct ihs_video_out_regs { + u16 versions; + u16 features; + u16 control; + u16 xy_size; + u16 xy_scale; + u16 x_pos; + u16 y_pos; +}; + +#define ihs_video_out_set(map, member, val) \ + regmap_range_set(map, 1, struct ihs_video_out_regs, member, val) + +#define ihs_video_out_get(map, member, valp) \ + regmap_range_get(map, 1, struct ihs_video_out_regs, member, valp) + +enum { + CONTROL_FILTER_BLACK = (0 << 0), + CONTROL_FILTER_ORIGINAL = (1 << 0), + CONTROL_FILTER_DARKER = (2 << 0), + CONTROL_FILTER_GRAY = (3 << 0), + + CONTROL_MODE_PASSTHROUGH = (0 << 3), + CONTROL_MODE_OSD = (1 << 3), + CONTROL_MODE_AUTO = (2 << 3), + CONTROL_MODE_OFF = (3 << 3), + + CONTROL_ENABLE_OFF = (0 << 6), + CONTROL_ENABLE_ON = (1 << 6), +}; + +struct ihs_video_out_priv { + /* Register map for OSD device */ + struct regmap *map; + /* Pointer to video memory */ + u16 *vidmem; + /* Display width in text columns */ + uint base_width; + /* Display height in text rows */ + uint base_height;
Re: [U-Boot] [PATCH] x86: tsc: add support for reading CPU freq from cpuid
Am Mi., 23. Mai 2018 um 11:48 Uhr schrieb Bin Meng: > On Mon, May 14, 2018 at 5:32 PM, Christian Gmeiner > wrote: > > Starting with cpuid level 0x16 (Skylake-based processors) > > it is possible to get CPU base freq via cpuid. > > > > This fixes booting on a skylake based system. > > > > Signed-off-by: Christian Gmeiner > > --- > > drivers/timer/tsc_timer.c | 31 +-- > > 1 file changed, 25 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c > > index c7fefd2031..96a3e55513 100644 > > --- a/drivers/timer/tsc_timer.c > > +++ b/drivers/timer/tsc_timer.c > > @@ -21,6 +21,17 @@ > > > > DECLARE_GLOBAL_DATA_PTR; > > > > +static unsigned long cpu_mhz_from_cpuid(void) > > +{ > > + if (gd->arch.x86_vendor != X86_VENDOR_INTEL) > > + return 0; > > + > > + if (cpuid_eax(0) < 0x16) > > + return 0; > > + > > + return cpuid_eax(0x16); > > +} > > + > > /* > > * According to Intel 64 and IA-32 System Programming Guide, > > * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be > > @@ -343,14 +354,22 @@ static void tsc_timer_ensure_setup(void) > > if (!gd->arch.clock_rate) { > > unsigned long fast_calibrate; > > > > + fast_calibrate = cpu_mhz_from_cpuid(); > > + if (fast_calibrate) > > + goto done; > > + > > fast_calibrate = cpu_mhz_from_msr(); > > - if (!fast_calibrate) { > > - fast_calibrate = quick_pit_calibrate(); > > - if (!fast_calibrate) > > - panic("TSC frequency is ZERO"); > > - } > > + if (fast_calibrate) > > + goto done; > > + > > + fast_calibrate = quick_pit_calibrate(); > > + if (fast_calibrate) > > + goto done; > > + > > + panic("TSC frequency is ZERO"); > > > > - gd->arch.clock_rate = fast_calibrate * 100; > > + done: > nits: this indention is wrong, and will cause checkpatch warnings. Oops. > > + gd->arch.clock_rate = fast_calibrate * 100; > > } > > } > Reviewed-by: Bin Meng > I can fix the nits when applying. That would be great - thanks! -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] dm: pci: use a 1:1 mapping for bus <-> phy addresses
If u-boot gets used as coreboot payload all pci resources got assigned by coreboot. If a dts without any pci ranges gets used the dm is not able to access pci device memory. To get things working make use of a 1:1 mapping for bus <-> phy addresses. This change makes it possible to get the e1000 u-boot driver working on a sandybridge device where u-boot is used as coreboot payload. Signed-off-by: Christian Gmeiner--- drivers/pci/pci-uclass.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 416444a230..9cec619bb2 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -1175,6 +1175,11 @@ static int _dm_pci_bus_to_phys(struct udevice *ctlr, struct pci_region *res; int i; + if (hose->region_count == 0) { + *pa = bus_addr; + return 0; + } + for (i = 0; i < hose->region_count; i++) { res = >regions[i]; @@ -1238,6 +1243,11 @@ int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr, ctlr = pci_get_controller(dev); hose = dev_get_uclass_priv(ctlr); + if (hose->region_count == 0) { + *ba = phys_addr; + return 0; + } + for (i = 0; i < hose->region_count; i++) { res = >regions[i]; -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional
If we use u-boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable. So convert decode_regions(..) into a void function and do the simple error handling there. Signed-off-by: Christian Gmeiner--- drivers/pci/pci-uclass.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 49be1ebdd7..416444a230 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -810,7 +810,7 @@ error: return ret; } -static int decode_regions(struct pci_controller *hose, ofnode parent_node, +static void decode_regions(struct pci_controller *hose, ofnode parent_node, ofnode node) { int pci_addr_cells, addr_cells, size_cells; @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, int i; prop = ofnode_get_property(node, "ranges", ); - if (!prop) - return -EINVAL; + if (!prop) { + debug("%s: Cannot decode regions\n", __func__); + return; + } + pci_addr_cells = ofnode_read_simple_addr_cells(node); addr_cells = ofnode_read_simple_addr_cells(parent_node); size_cells = ofnode_read_simple_size_cells(node); @@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, bd_t *bd = gd->bd; if (!bd) - return 0; + return; for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { if (bd->bi_dram[i].size) { @@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller *hose, ofnode parent_node, base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY); #endif - return 0; + return; } static int pci_uclass_pre_probe(struct udevice *bus) { struct pci_controller *hose; - int ret; debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name, bus->parent->name); @@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice *bus) /* For bridges, use the top-level PCI controller */ if (!device_is_on_pci_bus(bus)) { hose->ctlr = bus; - ret = decode_regions(hose, dev_ofnode(bus->parent), -dev_ofnode(bus)); - if (ret) { - debug("%s: Cannot decode regions\n", __func__); - return ret; - } + decode_regions(hose, dev_ofnode(bus->parent), dev_ofnode(bus)); } else { struct pci_controller *parent_hose; -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] Add Intel Stratix 10 SoC support
On 05/23/2018 06:17 PM, Ley Foon Tan wrote: > This is 3rd version of patchset to adds support for Intel Stratix 10 SoC. > This patchset is work on top of uboot.git/master and patchset in [1]. > > Changes: > - rebase on uboot.git/master > - update reviewed-by > > Patchset history: > [v1]: https://patchwork.ozlabs.org/cover/900499/ > [v2]: https://patchwork.ozlabs.org/cover/916060/ > > [1]: https://patchwork.ozlabs.org/cover/910018/ Applied, thanks -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0
On 05/22/2018 06:44 PM, Manjukumar Harthikote Matha wrote: [...] >> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 (the >> one on github, not the one on git.yoctoproject) without version which >> provides the ABI 1.0 rather than the v2017.03 one from meta-xilinx >> rel-v2018.1. And then the new release of meta-xilinx rel-v2018.2 will >> get PMUFW v2018.1 . >> >> But why is such vital component as the working PMUFW recipe stashed in >> some other repo than meta-xilinx , while meta-xilinx contains a non >> working one is not clear to me. Anyway. >> > > Release branches in github are related to Xilinx tools release to support > PetaLinux, xsct etc > The flow using github release uses a layer stack and how to use is documented > here > http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto > and manifest is here > https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1 > > We don’t support a flow where you use only one layer instead of the entire > stack. Then the obvious question is, why is it not a single metalayer ... >> It is also becoming less and less clear to me which PMUFW provides which >> ABI based on the recipe versions, since they do not reflect the ABI in >> any way. And, back to my original question-ish, there is an ABI break >> between PMUFW v0.3 and PMUFW v1.0 which may render systems unbootable if >> everything is not updated in tandem, right ? >> > > I was not aware of the breakage, I will have to check. Try using mainline U-Boot 2018.05 with PMUFW v0.3 and load FPGA image from U-Boot, it'll fail. > If you use our entire layer stack for rel-v2018.1 (manifest) then you > shouldn’t see the issue. > > As far as master branch is considred, we are in process of updating it for > sumo release. > If you are on mailing list, you will see the patches sent for review and is > on 4th version. > We hope to get it merged if there are no hiccups by end of week. > See : > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.html > See: https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.html Great btw I presume you do mean OpenEmbedded. >>> >>> >>> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ >>> >>> >> So it's this pmu-firmware_git recipe which provides different ABI in >> different versions of meta-xilinx-bsp, yet this is not in any way >> indicated by the package version, right ? > > Didn’t get what you mean here? Package version is set according to the > release under use > https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctap > p.bbclass#L9 Ah, I see, so unlike any other regular recipe which encodes the version in the recipe file name, Xilinx stuff has custom class which is inherited into version- >> less recipe and sets the version. This is horrid. >>> >>> Not true, any recipe which includes version can be in an include file or in >>> a class >> or in a conf file. >>> There is no strict guidelines on where this version should be set (recipe, >>> include, >> conf or class). >>> Just because you are familiar with one way of doing things, does not mean >> everything else is horrid. >> >> Well, I think I've seen my share of recipes over the years, both good >> and bad. OE gives the user a lot of freedom to do all kinds of hacks, >> which still doesn't mean it's a good idea to do them. >> >> Writing your own bbclass as a sort-of header file to be included by a >> recipe is one of the bad ideas. With the ABI break at hand, there is >> also no migration strategy for this PMUFW recipe, the platform just >> breaks during the update and stops booting or misbehaves, which is grueling. >> > > The same class is shared for multiple components, FSBL, DTG etc hence the > reasoning to use a class > However, this something for us to consider and work in future releases. This seems to be long overdue > This should indicate, release version with a part of commit id of git > being >> used. Right ... >> Also, do I understand it correctly that Xilinx doesn't support arm64 >> with multilib? >> > > Yes Xilinx does not support multilib way of building PMUFW What are you talking about ? PMUFW is microblaze, which doesn't do multilib >> in the first place. >>> >>> Exactly, when you are building for zynqmp (zcu102 board) >> >> No, I am not building for zcu102. >> >>> , it is aarch64. Yocto build system needs to understand mixed architectures >>> when >> building in the same project, hence the use of multilib to be build PMUFW. >> >> But you never build the microblaze toolchain, so how do you use multilib >> here at all ? From what I see, the pmu-firmware is compiled with >> toolchain referenced from outside of the OE build, in fact from vivado, >> see my comment below from using external tools like that. >> > > I am not sure how your dependencies are wired in: > We
[U-Boot] [PATCH 2/2] watchdog: Kconfig: add config to disable wdog reset
Add Kconfig support for CONFIG_WATCHDOG_RESET_DISABLE, use this config to disable watchdog reset in imx_watchdog driver, so that the watchdog will not be fed in u-boot. Signed-off-by: Xiaoliang Yang--- arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |3 +++ drivers/watchdog/Kconfig |5 + drivers/watchdog/imx_watchdog.c|2 ++ 3 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 index 87b91eb..c43a99b 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 @@ -18,3 +18,6 @@ Use following config to set watchdog timeout, if this config is not defined, the default timeout value is 128s which is the maximum. Set 10 seconds for example: #define CONFIG_WATCHDOG_TIMEOUT_MSECS 1 +Use following config to disable reset watchdog, so that the watchdog will +not be fed in u-boot: +#define CONFIG_WATCHDOG_RESET_DISABLE diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 148c6a0..f9b3035 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -103,4 +103,9 @@ config WDT_CDNS Select this to enable Cadence watchdog timer, which can be found on some Xilinx Microzed Platform. +config WATCHDOG_RESET_DISABLE + bool "Disable reset watchdog" + help + Disable reset watchdog, which can let WATCHDOG_RESET invalid. + endmenu diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c index 3ad4e55..6691ee9 100644 --- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -20,10 +20,12 @@ #ifdef CONFIG_IMX_WATCHDOG void hw_watchdog_reset(void) { +#ifndef CONFIG_WATCHDOG_RESET_DISABLE struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR; writew(0x, >wsr); writew(0x, >wsr); +#endif /* CONFIG_WATCHDOG_RESET_DISABLE*/ } void hw_watchdog_init(void) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] watchdog: driver support for layerscape
Support watchdog driver for layerscape. If you want to use it, please define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG, define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout. Signed-off-by: Xiaoliang Yang--- arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 10 ++ drivers/watchdog/Makefile |2 +- drivers/watchdog/imx_watchdog.c| 11 +++ 3 files changed, 22 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 index a6ef830..87b91eb 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 @@ -8,3 +8,13 @@ Freescale LayerScape with Chassis Generation 2 This architecture supports Freescale ARMv8 SoCs with Chassis generation 2, for example LS1043A. + +Watchdog support Overview +--- +Support watchdog driver for Layerscape. Use following configs to enable it: +#define CONFIG_IMX_WATCHDOG +#define CONFIG_HW_WATCHDOG +Use following config to set watchdog timeout, if this config is not defined, +the default timeout value is 128s which is the maximum. Set 10 seconds for +example: +#define CONFIG_WATCHDOG_TIMEOUT_MSECS 1 diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index f405f51..4835b27 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o -ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mx7 vf610)) +ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mx7 vf610 fsl-layerscape)) obj-y += imx_watchdog.o endif obj-$(CONFIG_S5P) += s5p_wdt.o diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c index 3f826d1..3ad4e55 100644 --- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -8,6 +8,13 @@ #include #include #include +#ifdef CONFIG_FSL_LAYERSCAPE +#ifdef CONFIG_FSL_LSCH3 +#include +#elif defined(CONFIG_FSL_LSCH2) +#include +#endif +#endif #include #ifdef CONFIG_IMX_WATCHDOG @@ -33,8 +40,12 @@ void hw_watchdog_init(void) #define CONFIG_WATCHDOG_TIMEOUT_MSECS 128000 #endif timeout = (CONFIG_WATCHDOG_TIMEOUT_MSECS / 500) - 1; +#ifdef CONFIG_FSL_LAYERSCAPE + writew((WCR_WDA | WCR_SRS | WCR_WDE) << 8 | timeout, >wcr); +#else writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS | WCR_WDA | SET_WCR_WT(timeout), >wcr); +#endif /* CONFIG_FSL_LAYERSCAPE*/ hw_watchdog_reset(); } #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add FIT data-position & data-offset property support
Hi Simon, 2018-05-23 7:30 GMT+08:00 Simon Glass: > Hi, > > On 18 May 2018 at 01:56, Kelvin Cheung wrote: > > Add FIT data-position & data-offset property support for bootm, > > which were already supported in SPL. > > > > Signed-off-by: Kelvin Cheung > > --- > > > > Changes for v2: > >create fit_image_get_data_and_size() to remove duplicated code > > > > --- > > common/image-fit.c | 54 ++ > +--- > > include/image.h| 2 ++ > > 2 files changed, 53 insertions(+), 3 deletions(-) > > Reviewed-by: Simon Glass > > How can we get this feature integrated into the tests? > > Do you mean the test scripts under test dir? BTW, I updated this patch to v3 several days ago. Thanks! > Regards, > Simon > -- Best regards, Kelvin Cheung ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0
Hi Marek, > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Tuesday, May 22, 2018 4:28 AM > To: Manjukumar Harthikote Matha; Rajan Vaja > > Cc: mon...@monstr.eu; Albert Aribaud ; Jolly Shah > ; Michal Simek ; u- > b...@lists.denx.de; Moritz Fischer > Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0 > > On 05/21/2018 11:26 PM, Manjukumar Harthikote Matha wrote: > [...] > Ah, I see, so there are three versions of pmu-firmware in a single > release, but the one which is actually needed for the system to boot > correctly is not in the meta-xilinx repo as one would expect, but in > some other repo. That ... doesn't make any sense, but so be it. > > >>> > >>> If you are planning to use rel-v2018.x Xilinx tools release branches, > >>> stick with all the layers provided by Xilinx. The same is documented > >>> in wiki as well > >>> > >>> > >> > http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct > >> o > >>> > >>> If you want to use Yocto open-source release stick with branches likes > >>> rocko, > >> morty etc. These branches will not have dependencies on Xilinx tools. > >> > >> I think you missed my point, there are three different PMUFW recipes in > >> those > >> metalayers. The only one that matters is not in the BSP layer, which makes > >> no > >> sense to me, but so be it. > > > > AFAIK, there are two. One in meta-xilinx-bsp and other in > > meta-xilinx-tools. You > can use PREFERRED_PROVIDER to switch between the two in your distro. > > > > I still don’t think you get the difference between Xilinx tools releases > > from > Github and upstream Yocto project repository. > > See http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ > > Do I understand it correctly that you have two repositories with the > same name, but with different content ? Talk about confusing. Assume I > use the meta-xilinx stuff from github/xilinx. > > > Also note that none of the Xilinx tool release branches are present at > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ > > > > The thing that matters to you is pmu-firmware recipe in meta-xilinx-bsp. The > recipe is present and based on 2017.3 in master and Rocko. Stick with Rocko > branch till the next release,Sumo branch is cut, which will get 2018.1 > version. > > Ah, I see. > > So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 (the > one on github, not the one on git.yoctoproject) without version which > provides the ABI 1.0 rather than the v2017.03 one from meta-xilinx > rel-v2018.1. And then the new release of meta-xilinx rel-v2018.2 will > get PMUFW v2018.1 . > > But why is such vital component as the working PMUFW recipe stashed in > some other repo than meta-xilinx , while meta-xilinx contains a non > working one is not clear to me. Anyway. > Release branches in github are related to Xilinx tools release to support PetaLinux, xsct etc The flow using github release uses a layer stack and how to use is documented here http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto and manifest is here https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1 We don’t support a flow where you use only one layer instead of the entire stack. > It is also becoming less and less clear to me which PMUFW provides which > ABI based on the recipe versions, since they do not reflect the ABI in > any way. And, back to my original question-ish, there is an ABI break > between PMUFW v0.3 and PMUFW v1.0 which may render systems unbootable if > everything is not updated in tandem, right ? > I was not aware of the breakage, I will have to check. If you use our entire layer stack for rel-v2018.1 (manifest) then you shouldn’t see the issue. As far as master branch is considred, we are in process of updating it for sumo release. If you are on mailing list, you will see the patches sent for review and is on 4th version. We hope to get it merged if there are no hiccups by end of week. See : https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.html See: https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.html > >> btw I presume you do mean OpenEmbedded. > >> > > > > > > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ > > > > > So it's this pmu-firmware_git recipe which provides different ABI in > different versions of meta-xilinx-bsp, yet this is not in any way > indicated by the package version, right ? > >>> > >>> Didn’t get what you mean here? Package version is set according to the > >>> release under use > >>> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctap > >>> p.bbclass#L9 > >> > >> Ah, I see, so unlike any other regular recipe which encodes the version in > >> the > >> recipe file name, Xilinx stuff has custom class which is inherited
Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler
On Wed, 2018-05-23 at 18:22 +0800, Bin Meng wrote: > Hi Andy, > > On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenko >wrote: > > The commit > > > > f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file > > in C)") > > > > in ACPICA project changed a template of the a of variable that is > > used > > a template of the a of variable? Cannot understand this. "a template of the variable" > > > in the generated C-file. Now, instead of hard coded "AmlCode" the > > "%s_aml_code" is in use, where the prefix is a lowered case base > > name of > > the output file. In our case it will be "dsdt" producing a name as > > "dsdt_aml_code". > > > > The quick solution is to call sed which replaces new name by the old > > one > > to keep compatibility with old version of iASL. > > > > The long term solution would be to modify code to use the new name > > because it more scalable. > > it *is* more scalable. Yes, thanks. > > > > > Cc: Robert Moore > > Cc: Sami Mujawar > > Cc: Evan Lloyd > > Signed-off-by: Andy Shevchenko > > --- > > scripts/Makefile.lib | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > > index f9809ce7ce..b5cf7e5427 100644 > > --- a/scripts/Makefile.lib > > +++ b/scripts/Makefile.lib > > @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \ > > > > $(obj)/dsdt.c:$(src)/dsdt.asl > > $(call cmd,acpi_c_asl) > > + $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ > > > > # Bzip2 > > # --- > > > > -- > > Otherwise, > Reviewed-by: Bin Meng > > Regards, > Bin -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler
Hi Andy, On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenkowrote: > The commit > > f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file in C)") > > in ACPICA project changed a template of the a of variable that is used a template of the a of variable? Cannot understand this. > in the generated C-file. Now, instead of hard coded "AmlCode" the > "%s_aml_code" is in use, where the prefix is a lowered case base name of > the output file. In our case it will be "dsdt" producing a name as > "dsdt_aml_code". > > The quick solution is to call sed which replaces new name by the old one > to keep compatibility with old version of iASL. > > The long term solution would be to modify code to use the new name > because it more scalable. it *is* more scalable. > > Cc: Robert Moore > Cc: Sami Mujawar > Cc: Evan Lloyd > Signed-off-by: Andy Shevchenko > --- > scripts/Makefile.lib | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index f9809ce7ce..b5cf7e5427 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \ > > $(obj)/dsdt.c:$(src)/dsdt.asl > $(call cmd,acpi_c_asl) > + $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ > > # Bzip2 > # --- > -- Otherwise, Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] LS1012AFRWY: Add Secure Boot support
From: Vinitha V PillaiAdded the following: 1. defconfig for LS1012AFRWY Secure boot 2. PfE Validation support Signed-off-by: Vinitha V Pillai --- arch/arm/Kconfig | 1 + board/freescale/ls1012afrdm/Kconfig| 8 board/freescale/ls1012afrdm/MAINTAINERS| 4 ++ board/freescale/ls1012afrdm/ls1012afrdm.c | 5 +++ configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 54 ++ drivers/net/pfe_eth/pfe_firmware.c | 29 ++ include/configs/ls1012afrwy.h | 16 +++- 7 files changed, 116 insertions(+), 1 deletion(-) create mode 100644 configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b1eb7c6..4f0ea04 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1036,6 +1036,7 @@ config TARGET_LS1012A2G5RDB config TARGET_LS1012AFRWY bool "Support ls1012afrwy" select ARCH_LS1012A + select BOARD_LATE_INIT select ARM64 imply SCSI imply SCSI_AHCI diff --git a/board/freescale/ls1012afrdm/Kconfig b/board/freescale/ls1012afrdm/Kconfig index 73ad2fe..f52a896 100644 --- a/board/freescale/ls1012afrdm/Kconfig +++ b/board/freescale/ls1012afrdm/Kconfig @@ -70,6 +70,14 @@ config SYS_LS_PPA_FW_ADDR hex "PPA Firmware Addr" default 0x4006 +config SYS_LS_PPA_ESBC_ADDR + hex "PPA Firmware HDR Addr" + default 0x401f4000 + +config SYS_LS_PFE_ESBC_ADDR + hex "PFE Firmware HDR Addr" + default 0x401f8000 + endif source "board/freescale/common/Kconfig" diff --git a/board/freescale/ls1012afrdm/MAINTAINERS b/board/freescale/ls1012afrdm/MAINTAINERS index 36e3e5a..f3fcdb8 100644 --- a/board/freescale/ls1012afrdm/MAINTAINERS +++ b/board/freescale/ls1012afrdm/MAINTAINERS @@ -11,3 +11,7 @@ S: Maintained F: board/freescale/ls1012afrwy/ F: include/configs/ls1012afrwy.h F: configs/ls1012afrwy_qspi_defconfig + +M: Vinitha V Pillai +S: Maintained +F: configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig diff --git a/board/freescale/ls1012afrdm/ls1012afrdm.c b/board/freescale/ls1012afrdm/ls1012afrdm.c index e30ad6e..315da8b 100644 --- a/board/freescale/ls1012afrdm/ls1012afrdm.c +++ b/board/freescale/ls1012afrdm/ls1012afrdm.c @@ -18,6 +18,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -140,6 +141,10 @@ int board_init(void) gd->env_addr = (ulong)_environment[0]; #endif +#ifdef CONFIG_FSL_CAAM + sec_init(); +#endif + #ifdef CONFIG_FSL_LS_PPA ppa_init(); #endif diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig new file mode 100644 index 000..bfc120a --- /dev/null +++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig @@ -0,0 +1,54 @@ +CONFIG_ARM=y +CONFIG_TARGET_LS1012AFRWY=y +CONFIG_SECURE_BOOT=y +CONFIG_SYS_TEXT_BASE=0x4010 +CONFIG_FSL_LS_PPA=y +CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-frwy" +CONFIG_DISTRO_DEFAULTS=y +# CONFIG_SYS_MALLOC_F is not set +CONFIG_FIT_VERBOSE=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT" +CONFIG_QSPI_BOOT=y +CONFIG_BOOTDELAY=10 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 quiet lpj=25" +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_CMD_GREPENV=y +CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y +CONFIG_CMD_SF=y +CONFIG_CMD_USB=y +CONFIG_CMD_CACHE=y +CONFIG_OF_CONTROL=y +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_DM=y +# CONFIG_BLK is not set +CONFIG_DM_MMC=y +# CONFIG_DM_MMC_OPS is not set +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_DM_ETH=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_NETDEVICES=y +CONFIG_E1000=y +CONFIG_FSL_PFE=y +CONFIG_PCI=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_LAYERSCAPE=y +CONFIG_SYS_NS16550=y +CONFIG_DM_SPI=y +CONFIG_FSL_DSPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_STORAGE=y +CONFIG_RSA=y +CONFIG_RSA_SOFTWARE_EXP=y diff --git a/drivers/net/pfe_eth/pfe_firmware.c b/drivers/net/pfe_eth/pfe_firmware.c index f06ed37..adb2d06 100644 --- a/drivers/net/pfe_eth/pfe_firmware.c +++ b/drivers/net/pfe_eth/pfe_firmware.c @@ -12,6 +12,9 @@ #include #include +#ifdef CONFIG_CHAIN_OF_TRUST +#include +#endif #define PFE_FIRMEWARE_FIT_CNF_NAME "config@1" @@ -168,10 +171,15 @@ static int pfe_fit_check(void) */ int pfe_firmware_init(void) { +#define PFE_KEY_HASH NULL char *pfe_firmware_name; const void *raw_image_addr; size_t raw_image_size = 0; u8 *pfe_firmware; +#ifdef CONFIG_CHAIN_OF_TRUST + uintptr_t pfe_esbc_hdr = 0; + uintptr_t pfe_img_addr = 0; +#endif int ret = 0; int fw_count; @@
[U-Boot] [PATCH 2/3] board: ls1012a: FRWY-LS1012A board support
FRWY-LS1012A belongs to LS1012A family with features 2 1G SGMII PFE MAC, Micro SD, USB 3.0, DDR, QuadSPI, Audio, UART. Signed-off-by: Bhaskar Upadhaya--- arch/arm/Kconfig | 12 +++ arch/arm/cpu/armv8/Kconfig| 1 + arch/arm/dts/Makefile | 3 +- arch/arm/dts/fsl-ls1012a-frwy.dts | 43 +++ board/freescale/ls1012afrdm/Kconfig | 35 +++-- board/freescale/ls1012afrdm/MAINTAINERS | 7 ++ board/freescale/ls1012afrdm/ls1012afrdm.c | 68 - configs/ls1012afrwy_qspi_defconfig| 50 + include/configs/ls1012afrwy.h | 120 ++ 9 files changed, 330 insertions(+), 9 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1012a-frwy.dts create mode 100644 configs/ls1012afrwy_qspi_defconfig create mode 100644 include/configs/ls1012afrwy.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3e05f79..b1eb7c6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1033,6 +1033,18 @@ config TARGET_LS1012A2G5RDB development platform that supports the QorIQ LS1012A Layerscape Architecture processor. +config TARGET_LS1012AFRWY + bool "Support ls1012afrwy" + select ARCH_LS1012A + select ARM64 + imply SCSI + imply SCSI_AHCI + help +Support for Freescale LS1012AFRWY platform. +The LS1012A FRWY board (FRWY) is a high-performance +development platform that supports the QorIQ LS1012A +Layerscape Architecture processor. + config TARGET_LS1012AFRDM bool "Support ls1012afrdm" select ARCH_LS1012A diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 3a0e129..22d2f29 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -91,6 +91,7 @@ config PSCI_RESET !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \ !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \ !TARGET_LS1012A2G5RDB && !TARGET_LS1012AQDS && \ + !TARGET_LS1012AFRWY && \ !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \ !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ !TARGET_LS2081ARDB && \ diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index a0349a8..0a46b0e 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -227,7 +227,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \ fsl-ls1012a-qds.dtb \ fsl-ls1012a-rdb.dtb \ fsl-ls1012a-2g5rdb.dtb \ - fsl-ls1012a-frdm.dtb + fsl-ls1012a-frdm.dtb \ + fsl-ls1012a-frwy.dtb dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb diff --git a/arch/arm/dts/fsl-ls1012a-frwy.dts b/arch/arm/dts/fsl-ls1012a-frwy.dts new file mode 100644 index 000..3158246 --- /dev/null +++ b/arch/arm/dts/fsl-ls1012a-frwy.dts @@ -0,0 +1,43 @@ +/* + * NXP ls1012a FRWY board device tree source + * + * Copyright 2018 NXP + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +/dts-v1/; +#include "fsl-ls1012a.dtsi" + +/ { + model = "FRWY-LS1012A Board"; + + aliases { + spi0 = + }; + + chosen { + stdout-path = + }; +}; + + { + bus-num = <0>; + status = "okay"; + + qflash0: w25q16dw@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "spi-flash"; + spi-max-frequency = <2000>; + reg = <0>; + }; +}; + + { + status = "okay"; +}; + + { + status = "okay"; +}; diff --git a/board/freescale/ls1012afrdm/Kconfig b/board/freescale/ls1012afrdm/Kconfig index fd33807..73ad2fe 100644 --- a/board/freescale/ls1012afrdm/Kconfig +++ b/board/freescale/ls1012afrdm/Kconfig @@ -12,20 +12,23 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1012afrdm" +config SYS_LS_PFE_FW_ADDR + hex "Flash address of PFE firmware" + default 0x40a0 + config SYS_LS_PPA_FW_ADDR hex "PPA Firmware Addr" default 0x4040 +endif + if FSL_PFE config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select PHYLIB imply PHY_REALTEK - -config SYS_LS_PFE_FW_ADDR - hex "Flash address of PFE firmware" - default 0x40a0 + imply PHY_ATHEROS config DDR_PFE_PHYS_BASEADDR hex "PFE DDR physical base address" @@ -45,6 +48,28 @@ config PFE_EMAC2_PHY_ADDR endif -source "board/freescale/common/Kconfig" +if TARGET_LS1012AFRWY + +config SYS_BOARD + default "ls1012afrdm" + +config SYS_VENDOR + default "freescale" + +config SYS_SOC + default "fsl-layerscape" + +config SYS_CONFIG_NAME + default "ls1012afrwy" + +config SYS_LS_PFE_FW_ADDR + hex "Flash address of PFE firmware" + default 0x4002 + +config
[U-Boot] [PATCH 1/3] board: Kconfig: Re-Arrangement of PPA firmware and header addresses
ppa firmware and header address may vary depending upon different boards, configure ppa firmware and header address in board specific kconfig Signed-off-by: Vinitha V PillaiSigned-off-by: Jagdish Gediya Signed-off-by: Bhaskar Upadhaya --- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 34 --- board/freescale/ls1012afrdm/Kconfig | 4 board/freescale/ls1012aqds/Kconfig| 3 +++ board/freescale/ls1012ardb/Kconfig| 14 + board/freescale/ls1043aqds/Kconfig| 16 +++ board/freescale/ls1043ardb/Kconfig| 14 + board/freescale/ls1046aqds/Kconfig| 16 +++ board/freescale/ls1046ardb/Kconfig| 15 ++ board/freescale/ls1088a/Kconfig | 28 + board/freescale/ls2080aqds/Kconfig| 16 +++ board/freescale/ls2080ardb/Kconfig| 31 ++-- 11 files changed, 141 insertions(+), 50 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 546de33..f2111fa 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -261,40 +261,6 @@ config SYS_LS_PPA_FW_IN_NAND endchoice -config SYS_LS_PPA_FW_ADDR - hex "Address of PPA firmware loading from" - depends on FSL_LS_PPA - default 0x2040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A - default 0x4040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT - default 0x58040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A - default 0x2040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A - default 0x6040 if SYS_LS_PPA_FW_IN_XIP - default 0x40 if SYS_LS_PPA_FW_IN_MMC - default 0x40 if SYS_LS_PPA_FW_IN_NAND - - help - If the PPA firmware locate at XIP flash, such as NOR or - QSPI flash, this address is a directly memory-mapped. - If it is in a serial accessed flash, such as NAND and SD - card, it is a byte offset. - -config SYS_LS_PPA_ESBC_ADDR - hex "hdr address of PPA firmware loading from" - depends on FSL_LS_PPA && CHAIN_OF_TRUST - default 0x6068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1043A - default 0x4068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A - default 0x4068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A - default 0x2068 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A - default 0x58068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A - default 0x2068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A - default 0x68 if SYS_LS_PPA_FW_IN_MMC - default 0x68 if SYS_LS_PPA_FW_IN_NAND - help - If the PPA header firmware locate at XIP flash, such as NOR or - QSPI flash, this address is a directly memory-mapped. - If it is in a serial accessed flash, such as NAND and SD - card, it is a byte offset. - config LS_PPA_ESBC_HDR_SIZE hex "Length of PPA ESBC header" depends on FSL_LS_PPA && CHAIN_OF_TRUST && !SYS_LS_PPA_FW_IN_XIP diff --git a/board/freescale/ls1012afrdm/Kconfig b/board/freescale/ls1012afrdm/Kconfig index 22d521b..fd33807 100644 --- a/board/freescale/ls1012afrdm/Kconfig +++ b/board/freescale/ls1012afrdm/Kconfig @@ -12,6 +12,10 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1012afrdm" +config SYS_LS_PPA_FW_ADDR + hex "PPA Firmware Addr" + default 0x4040 + if FSL_PFE config BOARD_SPECIFIC_OPTIONS # dummy diff --git a/board/freescale/ls1012aqds/Kconfig b/board/freescale/ls1012aqds/Kconfig index c0b12ed..b702fb2 100644 --- a/board/freescale/ls1012aqds/Kconfig +++ b/board/freescale/ls1012aqds/Kconfig @@ -12,6 +12,9 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1012aqds" +config SYS_LS_PPA_FW_ADDR +hex "PPA Firmware Addr" +default 0x4040 if FSL_PFE diff --git a/board/freescale/ls1012ardb/Kconfig b/board/freescale/ls1012ardb/Kconfig index 493d477..4cd66bd 100644 --- a/board/freescale/ls1012ardb/Kconfig +++ b/board/freescale/ls1012ardb/Kconfig @@ -12,6 +12,16 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1012ardb" +config SYS_LS_PPA_FW_ADDR +hex "PPA Firmware Addr" +default 0x4040 + +if CHAIN_OF_TRUST +config SYS_LS_PPA_ESBC_ADDR + hex "PPA Firmware HDR Addr" + default 0x4068 +endif + if FSL_PFE config BOARD_SPECIFIC_OPTIONS # dummy @@ -59,6 +69,10 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1012a2g5rdb" +config SYS_LS_PPA_FW_ADDR +hex "PPA Firmware Addr" +default 0x4040 + if FSL_PFE config BOARD_SPECIFIC_OPTIONS # dummy diff --git a/board/freescale/ls1043aqds/Kconfig b/board/freescale/ls1043aqds/Kconfig index 95d2888..182900e 100644 --- a/board/freescale/ls1043aqds/Kconfig +++
Re: [U-Boot] [PATCH] disk: efi: Correct backing up the MBR boot code
On Tue, May 22, 2018 at 2:04 AM, Sam Protsenkowrote: > In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR") > there was added the procedure for storing old boot code when doing "gpt > write". But instead of storing just backup code, the whole MBR was > stored, and only specific fields were replaced further, keeping > everything else intact. That's obviously not what we want. > > Fix the code to actually store only old boot code and zero out > everything else. This fixes next testing case: > > => mmc write $loadaddr 0x0 0x7b > => gpt write mmc 1 $partitions > > In case when $loadaddr address and further memory contains 0xff, the > board was bricked (ROM-code probably didn't like partition entries that > were clobbered with 0xff). With this patch applied, commands above don't > brick the board. Tested-by: Andy Shevchenko At least it doesn't break Intel Edison. > > Signed-off-by: Sam Protsenko > Cc: Alejandro Hernandez > --- > disk/part_efi.c| 6 -- > include/part_efi.h | 3 ++- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/disk/part_efi.c b/disk/part_efi.c > index 72e3997b84..5c1039f013 100644 > --- a/disk/part_efi.c > +++ b/disk/part_efi.c > @@ -350,8 +350,6 @@ static int set_protective_mbr(struct blk_desc *dev_desc) > { > /* Setup the Protective MBR */ > ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, p_mbr, 1, dev_desc->blksz); > - memset(p_mbr, 0, sizeof(*p_mbr)); > - > if (p_mbr == NULL) { > printf("%s: calloc failed!\n", __func__); > return -1; > @@ -363,6 +361,10 @@ static int set_protective_mbr(struct blk_desc *dev_desc) > return -1; > } > > + /* Clear all data in MBR except of backed up boot code */ > + memset((char *)p_mbr + MSDOS_MBR_BOOT_CODE_SIZE, 0, sizeof(*p_mbr) - > + MSDOS_MBR_BOOT_CODE_SIZE); > + > /* Append signature */ > p_mbr->signature = MSDOS_MBR_SIGNATURE; > p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; > diff --git a/include/part_efi.h b/include/part_efi.h > index 6065c571f3..8525770445 100644 > --- a/include/part_efi.h > +++ b/include/part_efi.h > @@ -20,6 +20,7 @@ > #include > > #define MSDOS_MBR_SIGNATURE 0xAA55 > +#define MSDOS_MBR_BOOT_CODE_SIZE 440 > #define EFI_PMBR_OSTYPE_EFI 0xEF > #define EFI_PMBR_OSTYPE_EFI_GPT 0xEE > > @@ -111,7 +112,7 @@ typedef struct _gpt_entry { > } __packed gpt_entry; > > typedef struct _legacy_mbr { > - u8 boot_code[440]; > + u8 boot_code[MSDOS_MBR_BOOT_CODE_SIZE]; > __le32 unique_mbr_signature; > __le16 unknown; > struct partition partition_record[4]; > -- > 2.17.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: tsc: add support for reading CPU freq from cpuid
On Mon, May 14, 2018 at 5:32 PM, Christian Gmeinerwrote: > Starting with cpuid level 0x16 (Skylake-based processors) > it is possible to get CPU base freq via cpuid. > > This fixes booting on a skylake based system. > > Signed-off-by: Christian Gmeiner > --- > drivers/timer/tsc_timer.c | 31 +-- > 1 file changed, 25 insertions(+), 6 deletions(-) > > diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c > index c7fefd2031..96a3e55513 100644 > --- a/drivers/timer/tsc_timer.c > +++ b/drivers/timer/tsc_timer.c > @@ -21,6 +21,17 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +static unsigned long cpu_mhz_from_cpuid(void) > +{ > + if (gd->arch.x86_vendor != X86_VENDOR_INTEL) > + return 0; > + > + if (cpuid_eax(0) < 0x16) > + return 0; > + > + return cpuid_eax(0x16); > +} > + > /* > * According to Intel 64 and IA-32 System Programming Guide, > * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be > @@ -343,14 +354,22 @@ static void tsc_timer_ensure_setup(void) > if (!gd->arch.clock_rate) { > unsigned long fast_calibrate; > > + fast_calibrate = cpu_mhz_from_cpuid(); > + if (fast_calibrate) > + goto done; > + > fast_calibrate = cpu_mhz_from_msr(); > - if (!fast_calibrate) { > - fast_calibrate = quick_pit_calibrate(); > - if (!fast_calibrate) > - panic("TSC frequency is ZERO"); > - } > + if (fast_calibrate) > + goto done; > + > + fast_calibrate = quick_pit_calibrate(); > + if (fast_calibrate) > + goto done; > + > + panic("TSC frequency is ZERO"); > > - gd->arch.clock_rate = fast_calibrate * 100; > + done: nits: this indention is wrong, and will cause checkpatch warnings. > + gd->arch.clock_rate = fast_calibrate * 100; > } > } Reviewed-by: Bin Meng I can fix the nits when applying. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler
The commit f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file in C)") in ACPICA project changed a template of the a of variable that is used in the generated C-file. Now, instead of hard coded "AmlCode" the "%s_aml_code" is in use, where the prefix is a lowered case base name of the output file. In our case it will be "dsdt" producing a name as "dsdt_aml_code". The quick solution is to call sed which replaces new name by the old one to keep compatibility with old version of iASL. The long term solution would be to modify code to use the new name because it more scalable. Cc: Robert MooreCc: Sami Mujawar Cc: Evan Lloyd Signed-off-by: Andy Shevchenko --- scripts/Makefile.lib | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index f9809ce7ce..b5cf7e5427 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \ $(obj)/dsdt.c:$(src)/dsdt.asl $(call cmd,acpi_c_asl) + $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ # Bzip2 # --- -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: zynq: Add initial support for Avnet MiniZed
On 22.5.2018 18:03, Ibai Erkiaga wrote: > Initial support for Avnet MiniZed board. Tested UART1 (serial console), > QSPI(Flash), SDHCI1 (eMMC), USB. > > Signed-off-by: Ibai Erkiaga> --- > > Changes in v3: > -dts formating refactor > -CONFIG_DISPLAY_CPUINFO removed from config > -CONFIG_OF_EMBED removed from config > > Changes in v2: > -board model changed to use Avent prefix > -usb phy driver changed usb-no-xceiv > -removed gpio and intc binding > -fixed-partitions usage > > --- > arch/arm/dts/Makefile |1 + > arch/arm/dts/zynq-minized.dts | 106 > > configs/zynq_minized_defconfig | 66 + > 3 files changed, 173 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/dts/zynq-minized.dts > create mode 100644 configs/zynq_minized_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 7bec3d6..f7b33f9 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \ > zynq-cc108.dtb \ > zynq-cse-qspi-single.dtb \ > zynq-microzed.dtb \ > + zynq-minized.dtb \ > zynq-picozed.dtb \ > zynq-syzygy-hub.dtb \ > zynq-topic-miami.dtb \ > diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts > new file mode 100644 > index 000..525921e > --- /dev/null > +++ b/arch/arm/dts/zynq-minized.dts > @@ -0,0 +1,106 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * dts file for Avnet MiniZed board > + * > + * (C) Copyright 2017 - 2018, Xilinx, Inc. > + * > + * Ibai Erkiaga > + */ > + > +/dts-v1/; > +#include "zynq-7000.dtsi" > + > +/ { > + model = "Avnet Zynq MiniZed Development Board"; > + compatible = "avnet,minized", "xlnx,zynq-7000"; > + > + aliases { > + serial0 = > + serial1 = > + spi0 = > + mmc0 = > + }; > + > + memory@0 { > + device_type = "memory"; > + reg = <0x0 0x2000>; > + }; > + > + chosen { > + bootargs = ""; > + stdout-path = "serial0:115200n8"; > + }; > + > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > +}; > + > + { > + status = "okay"; > + is-dual = <0>; > + num-cs = <1>; > + flash@0 { > + compatible = "micron,m25p128"; > + reg = <0x0>; > + spi-tx-bus-width = <4>; > + spi-rx-bus-width = <4>; > + spi-max-frequency = <5000>; > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + partition@0 { > + label = "boot"; > + reg = <0x0 0xff>; > + }; > + > + partition@27 { > + label = "kernel"; > + reg = <0x27 0xd8>; > + }; > + > + partition@ff { > + label = "bootenv"; > + reg = <0xff 0x1>; > + }; > + > + partition@100 { > + label = "spare"; > + reg = <0x100 0x0>; > + }; > + }; > + }; > +}; > + > + { > + status = "okay"; > +}; > + > + { > + u-boot,dm-pre-reloc; > + status = "okay"; > +}; > + > + { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <_phy0>; > + usb-reset = < 7 0>; /* USB_RST_N-MIO7 */ > +}; > + > + { > + status = "okay"; > + non-removable; > + bus-width = <4>; > + max-frequency = <1200>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + mmccard: mmccard@0 { > + compatible = "mmc-card"; > + reg = <0>; > + broken-hpi; > + }; > +}; > diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig > new file mode 100644 > index 000..8cf3215 > --- /dev/null > +++ b/configs/zynq_minized_defconfig > @@ -0,0 +1,66 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_ZYNQ=y > +CONFIG_SYS_TEXT_BASE=0x400 > +CONFIG_SPL=y > +CONFIG_SPL_STACK_R_ADDR=0x20 > +CONFIG_DEFAULT_DEVICE_TREE="zynq-minized" > +CONFIG_DEBUG_UART=y > +CONFIG_DISTRO_DEFAULTS=y > +CONFIG_FIT=y > +CONFIG_FIT_SIGNATURE=y > +CONFIG_FIT_VERBOSE=y > +CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd" > +CONFIG_SPL_STACK_R=y > +CONFIG_SPL_OS_BOOT=y > +CONFIG_SYS_PROMPT="Zynq> " > +CONFIG_CMD_THOR_DOWNLOAD=y > +CONFIG_CMD_DFU=y > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_FPGA_LOADBP=y > +CONFIG_CMD_FPGA_LOADFS=y > +CONFIG_CMD_FPGA_LOADMK=y >