Re: [U-Boot] [PATCH] Convert CONFIG_MII et al to Kconfig
On Sat, Jul 21, 2018 at 9:33 AM, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_MII >CONFIG_DRIVER_TI_EMAC > > Signed-off-by: Adam Ford > --- Acked-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 25.7.2018 08:52, Simon Goldschmidt wrote:
> On 25.07.2018 08:40, Michal Simek wrote:
>> On 25.7.2018 08:26, Simon Goldschmidt wrote:
>>>
>>>
>>> On 24.07.2018 15:07, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel
image
type. >
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9eabb1c1058b..dbf5ac33a845 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -257,10 +257,7 @@ static int spl_load_fit_image(struct
spl_load_info *info, ulong sector,
board_fit_image_post_process(&src, &length);
#endif
- if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
- IS_ENABLED(CONFIG_SPL_GZIP) &&
- image_comp == IH_COMP_GZIP &&
- type == IH_TYPE_KERNEL) {
+ if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
size = length;
if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
src, &size)) {
>>>
>>> I suppose this is to support a gziped fpga image in a fit. Does this
>>> work for U-Boot proper already?
>>
>> Luis has tested it some days ago based on my suggestion. I have tried
>> that yesterday on zynq zc706 and it was also working for internal data.
>> Please take a look at second thread where also times are listed.
>
> Isn't that 2nd thread on SPL also? I was asking for U-Boot proper in
> comparison.
I have tested several cases for this series.
https://lists.denx.de/pipermail/u-boot/2018-July/335193.html
This is my script for generating images.
mkimage -d download.bin -T firmware -C none -a 0x100 -e 0x100 -A
arm -n "fpga download.bin" download.ub
gzip < download.bin > download.bin.gz
mkimage -d download.bin.gz -T firmware -C gzip -a 0x1000 -e
0x1000 -A arm -n "fpga download.bin.gz" download.gz.ub
mkimage -f fit.its download-fit.ub
fit.its unfortunately is not using gzip format.
> We are programming the FPGA from U-Boot proper, not SPL, using a
> Multi-config FIT image including matching Kernel and Device tree. And
> here, using a gziped FPGA might be nice. But from reading the sources (I
> think I also tested it once), that doesn't work. That's why I ask.
I am going to retest the whole series and I can try it but if this is
working in SPL I can't see any issue why this shouldn't work in full
u-boot. I am not using -E for mkimage but please test it and let me know
if this is working or not.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: zynq: add support for the zybo z7 board
On 24.7.2018 17:31, Luis Araneda wrote:
> The board is manufactured by Digilent
> Main features:
> - Soc: XC7Z010 (Z7-10) or XC7Z020 (Z7-20)
> - RAM: 1 GB DDR3L
> - FLASH: 16 MB QSPI
> - 1 Gbps Ethernet
> - USB 2.0
> - microSD slot
> - Pcam camera connector
> - HDMI Tx and Rx
> - Audio codec: stereo out, stereo in, mic
> - 5 (Z7-10) or 6 (Z7-20) Pmod ports
> - 6 push-buttons, 4 switches, 5 LEDs
> - 1 (Z7-10) or 2 (Z7-20) RGB LEDs
>
> Signed-off-by: Luis Araneda
> ---
>
> This patch adds support for the Digilent Zybo Z7 board
>
> The only thing that I tested and is not working yet, is reading the
> MAC address from the OTP region of the SPI flash memory, but I'm trying
> to find a solution
>
> Changes from v2:
> - Removed silicon version 2_0 and 1_0 from ps7_init_gpl.c
>
> Changes from v1:
> - Rebased on u-boot/master
> - Removed comments and indented ps7_init_gpl.c
> - Removed CONFIG_DISPLAY from defconfig
> - Replaced the cadence I2C driver by zynq_i2c
> - Squashed the patches as they are less than 100kB now
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/zynq-zybo-z7.dts | 81 +
> board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c | 297 ++
> configs/zynq_zybo_z7_defconfig| 68
> 4 files changed, 448 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/zynq-zybo-z7.dts
> create mode 100644 board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> create mode 100644 configs/zynq_zybo_z7_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 09adf5eab1..07d8729104 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -149,7 +149,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> zynq-zc770-xm013.dtb \
> zynq-zed.dtb \
> zynq-zturn.dtb \
> - zynq-zybo.dtb
> + zynq-zybo.dtb \
> + zynq-zybo-z7.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += \
> zynqmp-mini-emmc0.dtb \
> zynqmp-mini-emmc1.dtb \
> diff --git a/arch/arm/dts/zynq-zybo-z7.dts b/arch/arm/dts/zynq-zybo-z7.dts
> new file mode 100644
> index 00..3f8a3bfa0f
> --- /dev/null
> +++ b/arch/arm/dts/zynq-zybo-z7.dts
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2011 - 2015 Xilinx
> + * Copyright (C) 2012 National Instruments Corp.
> + */
> +/dts-v1/;
> +#include "zynq-7000.dtsi"
> +#include
> +
> +/ {
> + model = "Digilent Zybo Z7 board";
> + compatible = "digilent,zynq-zybo-z7", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + spi0 = &qspi;
> + mmc0 = &sdhci0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x4000>;
> + };
> +
> + chosen {
> + bootargs = "";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + ld4 {
> + label = "zynq-zybo-z7:green:ld4";
> + gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + usb_phy0: phy0 {
> + #phy-cells = <0>;
> + compatible = "usb-nop-xceiv";
> + reset-gpios = <&gpio0 46 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy@0 {
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> +};
> +
> +&qspi {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&sdhci0 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&uart1 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> +};
> diff --git a/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> new file mode 100644
> index 00..f1b9357780
> --- /dev/null
> +++ b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> @@ -0,0 +1,297 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (c) Copyright 2010-2014 Xilinx, Inc. All rights reserved.
> + *
> + * Procedure to generate this file (using Vivado Webpack 2018.2):
> + * + Install board files from digilent/vivado-boards repository
> + * (commit 6a45981 from 2018-06-05)
> + * + Start Vivado and create a new RTL project with the Zybo-z7-20 board
> + * + Create a block design
> + * - Add "ZYNQ7 Processing System" IP
> + * - Run "Block Automation" (Check "Apply Board Preset")
> + * - Connect ports FCLK_CLK0 and M_AXI_GP0_ACLK
> + * - Save diagram changes
> + * - Go to sources view, select the block diagram,
> + * and select "Generate Output Products"
> + * + Copy the generated "ps7_init_gpl.c" file
> + * + Perform manu
Re: [U-Boot] [PATCH v2 0/4] arm: odroid: Convert to distro_bootcmd.
Hi Vagrant, > Switch odroid platform to use distro_bootcmd, adjusting to use > standardized environment variable names, and use the default > bootdelay. > > The additional environment variables from distro_bootcmd requires > increasing the default environment size, which would break backwards > compatibility with saved environments. At Marek's suggestion, I've > bumped it well over the size needed (~4.5k vs. 16k) to give room for > future growth. > > Variations on these patches have been in use in Debian's u-boot > packages since 2016. > > A variation of this patch series was originally submitted to u-boot > over a year ago, and resent a few times since, with little to no > response. Yes, the Samsung port of u-boot could work better. I think that Tom can apply those patches directly if no response is given in a reasonable time. > > Thanks for considering! I would like to emphasize this one more time - thanks for your patches. > > Changes in v2: > - Change from 16384 to SZ_16K, as suggested by Minkyu Kang. > > Vagrant Cascadian (4): > arm: odroid: Use standard environment variable names kernel_addr_r, > ramdisk_addr_r and fdt_addr_r. > arm: odroid: Increase default env size in preparation for > distro_bootcmd. > arm: odroid: Enable distro_bootcmd support. > arm: odroid: Inherit default value for bootdelay from > distro_bootcmd. > > include/configs/odroid.h | 36 > 1 file changed, 20 insertions(+), 16 deletions(-) > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpw5SArjT3J_.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: A64: fix default DRAM_ODT_EN symbol
On Wed, Jul 25, 2018 at 01:02:31AM +0100, Andre Przywara wrote: > "default" lines in Kconfig are processed in order, the first hit will > stop considering subsequent lines. In the case of the DRAM_ODT_EN symbol > that means that everything following the first two lines will never be > checked: > > config DRAM_ODT_EN > bool "sunxi dram odt enable" > default n if !MACH_SUN8I_A23 > default y if MACH_SUN8I_A23 > default y if MACH_SUN8I_R40 > default y if MACH_SUN50I > > > Assuming that the "default y" for the A64 and the R40 were a deliberate > choice, fix the Kconfig stanza to take this into account. > Also remove the now redundant lines from the respective defconfigs. > > Signed-off-by: Andre Przywara > --- > Hi, > > I would be grateful if people could test this and find out whether > enabling ODT works reliably. > > Thanks! > Andre. > > arch/arm/mach-sunxi/Kconfig | 2 +- > configs/Bananapi_M2_Ultra_defconfig | 1 - > configs/amarula_a64_relic_defconfig | 1 - > configs/bananapi_m2_berry_defconfig | 1 - > configs/sopine_baseboard_defconfig | 1 - > 5 files changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 678e33dd40..7ff0347e20 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -405,10 +405,10 @@ config DRAM_ZQ > > config DRAM_ODT_EN > bool "sunxi dram odt enable" > - default n if !MACH_SUN8I_A23 > default y if MACH_SUN8I_A23 > default y if MACH_SUN8I_R40 > default y if MACH_SUN50I > + default n I think this is the default's default, so there's no need to set it explicitly. Otherwise, Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] arm: odroid: Convert to distro_bootcmd.
Hi, 2018년 7월 25일 (수) 16:25, Lukasz Majewski 님이 작성: > Hi Vagrant, > > > Switch odroid platform to use distro_bootcmd, adjusting to use > > standardized environment variable names, and use the default > > bootdelay. > > > > The additional environment variables from distro_bootcmd requires > > increasing the default environment size, which would break backwards > > compatibility with saved environments. At Marek's suggestion, I've > > bumped it well over the size needed (~4.5k vs. 16k) to give room for > > future growth. > > > > Variations on these patches have been in use in Debian's u-boot > > packages since 2016. > > > > A variation of this patch series was originally submitted to u-boot > > over a year ago, and resent a few times since, with little to no > > response. > > Yes, the Samsung port of u-boot could work better. > > I think that Tom can apply those patches directly if no response is > given in a reasonable time. > I was waiting v2 of this patchset. It will be accepted soon. > > > > Thanks for considering! > > I would like to emphasize this one more time - thanks for your patches. > > > > > Changes in v2: > > - Change from 16384 to SZ_16K, as suggested by Minkyu Kang. > > > > Vagrant Cascadian (4): > > arm: odroid: Use standard environment variable names kernel_addr_r, > > ramdisk_addr_r and fdt_addr_r. > > arm: odroid: Increase default env size in preparation for > > distro_bootcmd. > > arm: odroid: Enable distro_bootcmd support. > > arm: odroid: Inherit default value for bootdelay from > > distro_bootcmd. > > > > include/configs/odroid.h | 36 > > 1 file changed, 20 insertions(+), 16 deletions(-) > > > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Cavium Octeon support for u-boot
Hi Aaron, On Wed, Jul 25, 2018 at 2:06 PM Aaron Williams wrote: > While mainline U-Boot does not support Octeon, we have our own fork of it that > I maintain. I am using the 2018.07 release with only a few minor changes > around the periphery to support the older version of U-Boot Octeon is based > off of. Just out of interest is there any particular barrier to Octeon support landing upstream? At $dayjob we have 4 platforms using various Octeon III processors. We're in the position of being stuck on an older version of u-boot because we can't bring support for our boards up to date without having to bring all the Octeon SoC support forward as well. Is there any interest from Cavium to get Octeon upstreamed? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/20] w1: enumerate sandbox driver if configured
On Tue, Jul 24, 2018 at 09:28:30AM -0600, Simon Glass wrote: > Hi Maxime, > > On 24 July 2018 at 00:58, Maxime Ripard wrote: > > On Mon, Jul 23, 2018 at 05:48:25PM -0600, Simon Glass wrote: > >> Hi, > >> > >> On 20 July 2018 at 08:01, Lukasz Majewski wrote: > >> > Hi Eugen, > >> > > >> > Thanks for (re-)bringing the One wire support to u-boot. > >> > > >> >> Add a sandbox eeprom on the bus as a device, if sandbox driver is > >> >> configured. > >> >> > >> >> Signed-off-by: Eugen Hristev > >> >> --- > >> >> drivers/w1/w1-uclass.c | 5 + > >> >> 1 file changed, 5 insertions(+) > >> >> > >> >> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c > >> >> index cfddda3..e58c1ca 100644 > >> >> --- a/drivers/w1/w1-uclass.c > >> >> +++ b/drivers/w1/w1-uclass.c > >> >> @@ -142,6 +142,11 @@ static int w1_enumerate(struct udevice *bus) > >> >> } > >> >> } > >> >> > >> >> +#ifdef CONFIG_W1_EEPROM_SANDBOX > >> >> + /* before we are finished, add a sandbox device if we can */ > >> >> + w1_new_device(bus, W1_FAMILY_EEP_SANDBOX); > >> >> +#endif > >> > > >> > IMHO we shouldn't mix the sandbox code with production (on boards) code. > >> > > >> > Maybe Simon (+CCed) could provide some more input here? > >> > >> I have not seen this series. But new devices should be created > >> automatically based on them being in the device tree. So you should > >> just be able to add them there. > > > > 1-Wire is discoverable, so there's no device nodes in the DT. > > Well there should be. See for example PCI, USB, I2C and SPI :-) I didn't know u-boot's sandbox had binding for USB and PCI devices. My bad :) Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] dm: pci: Assign correct driver data when binding a driver
The correct driver data comes from the matching 'id' instead of
'find_id' in pci_find_and_bind_driver().
Signed-off-by: Bin Meng
---
drivers/pci/pci-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71..7e16ad1 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -690,7 +690,7 @@ static int pci_find_and_bind_driver(struct udevice *parent,
if (ret)
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
- dev->driver_data = find_id->driver_data;
+ dev->driver_data = id->driver_data;
*devp = dev;
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] pci: Add all known capability and extended capability ids
Currently we don't have a complete list of capability and extended capability ids. This adds them. Signed-off-by: Bin Meng --- include/pci.h | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/include/pci.h b/include/pci.h index 8e27cbf..cce69c4 100644 --- a/include/pci.h +++ b/include/pci.h @@ -333,7 +333,21 @@ #define PCI_CAP_ID_SLOTID 0x04/* Slot Identification */ #define PCI_CAP_ID_MSI0x05/* Message Signalled Interrupts */ #define PCI_CAP_ID_CHSWP 0x06/* CompactPCI HotSwap */ -#define PCI_CAP_ID_EXP0x10/* PCI Express */ +#define PCI_CAP_ID_PCIX 0x07/* PCI-X */ +#define PCI_CAP_ID_HT 0x08/* HyperTransport */ +#define PCI_CAP_ID_VNDR 0x09/* Vendor-Specific */ +#define PCI_CAP_ID_DBG0x0A/* Debug port */ +#define PCI_CAP_ID_CCRC 0x0B/* CompactPCI Central Resource Control */ +#define PCI_CAP_ID_SHPC 0x0C/* PCI Standard Hot-Plug Controller */ +#define PCI_CAP_ID_SSVID 0x0D/* Bridge subsystem vendor/device ID */ +#define PCI_CAP_ID_AGP3 0x0E/* AGP Target PCI-PCI bridge */ +#define PCI_CAP_ID_SECDEV 0x0F/* Secure Device */ +#define PCI_CAP_ID_EXP0x10/* PCI Express */ +#define PCI_CAP_ID_MSIX 0x11/* MSI-X */ +#define PCI_CAP_ID_SATA 0x12/* SATA Data/Index Conf. */ +#define PCI_CAP_ID_AF 0x13/* PCI Advanced Features */ +#define PCI_CAP_ID_EA 0x14/* PCI Enhanced Allocation */ +#define PCI_CAP_ID_MAXPCI_CAP_ID_EA #define PCI_CAP_LIST_NEXT 1 /* Next capability in the list */ #define PCI_CAP_FLAGS 2 /* Capability defined flags (16 bits) */ #define PCI_CAP_SIZEOF 4 @@ -449,6 +463,10 @@ #define PCI_EXT_CAP_ID_SECPCI 0x19/* Secondary PCIe Capability */ #define PCI_EXT_CAP_ID_PMUX0x1A/* Protocol Multiplexing */ #define PCI_EXT_CAP_ID_PASID 0x1B/* Process Address Space ID */ +#define PCI_EXT_CAP_ID_DPC 0x1D/* Downstream Port Containment */ +#define PCI_EXT_CAP_ID_L1SS0x1E/* L1 PM Substates */ +#define PCI_EXT_CAP_ID_PTM 0x1F/* Precision Time Measurement */ +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM /* Include the ID list */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] dm: pci: Add APIs to find capability and extended capability
This introduces two new APIs dm_pci_find_capability() and
dm_pci_find_ext_capability() to get PCI capability address and
PCI express extended capability address for a given PCI device.
Signed-off-by: Bin Meng
---
drivers/pci/pci-uclass.c | 68
include/pci.h| 46
2 files changed, 114 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 7e16ad1..c887989 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1319,6 +1319,74 @@ void *dm_pci_map_bar(struct udevice *dev, int bar, int
flags)
return dm_pci_bus_to_virt(dev, pci_bus_addr, flags, 0, MAP_NOCACHE);
}
+int dm_pci_find_capability(struct udevice *dev, int cap)
+{
+ u16 status;
+ u8 header_type;
+ int ttl = PCI_FIND_CAP_TTL;
+ u8 id;
+ u16 ent;
+ u8 pos;
+
+ dm_pci_read_config16(dev, PCI_STATUS, &status);
+ if (!(status & PCI_STATUS_CAP_LIST))
+ return 0;
+
+ dm_pci_read_config8(dev, PCI_HEADER_TYPE, &header_type);
+ if (header_type == PCI_HEADER_TYPE_CARDBUS)
+ pos = PCI_CB_CAPABILITY_LIST;
+ else
+ pos = PCI_CAPABILITY_LIST;
+
+ dm_pci_read_config8(dev, pos, &pos);
+ while (ttl--) {
+ if (pos < PCI_STD_HEADER_SIZEOF)
+ break;
+ pos &= ~3;
+ dm_pci_read_config16(dev, pos, &ent);
+
+ id = ent & 0xff;
+ if (id == 0xff)
+ break;
+ if (id == cap)
+ return pos;
+ pos = (ent >> 8);
+ }
+
+ return 0;
+}
+
+int dm_pci_find_ext_capability(struct udevice *dev, int cap)
+{
+ u32 header;
+ int ttl;
+ int pos = PCI_CFG_SPACE_SIZE;
+
+ /* minimum 8 bytes per capability */
+ ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
+
+ dm_pci_read_config32(dev, pos, &header);
+ /*
+* If we have no capabilities, this is indicated by cap ID,
+* cap version and next pointer all being 0.
+*/
+ if (header == 0)
+ return 0;
+
+ while (ttl--) {
+ if (PCI_EXT_CAP_ID(header) == cap)
+ return pos;
+
+ pos = PCI_EXT_CAP_NEXT(header);
+ if (pos < PCI_CFG_SPACE_SIZE)
+ break;
+
+ dm_pci_read_config32(dev, pos, &header);
+ }
+
+ return 0;
+}
+
UCLASS_DRIVER(pci) = {
.id = UCLASS_PCI,
.name = "pci",
diff --git a/include/pci.h b/include/pci.h
index cce69c4..602c834 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -17,6 +17,7 @@
* Under PCI, each device has 256 bytes of configuration address space,
* of which the first 64 bytes are standardized as follows:
*/
+#define PCI_STD_HEADER_SIZEOF 64
#define PCI_VENDOR_ID 0x00/* 16 bits */
#define PCI_DEVICE_ID 0x02/* 16 bits */
#define PCI_COMMAND0x04/* 16 bits */
@@ -1326,6 +1327,51 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
phys_addr_t addr,
*/
void *dm_pci_map_bar(struct udevice *dev, int bar, int flags);
+/**
+ * dm_pci_find_capability() - find a capability
+ *
+ * Tell if a device supports a given PCI capability. Returns the
+ * address of the requested capability structure within the device's
+ * PCI configuration space or 0 in case the device does not support it.
+ *
+ * Possible values for @cap:
+ *
+ * %PCI_CAP_ID_MSIMessage Signalled Interrupts
+ * %PCI_CAP_ID_PCIX PCI-X
+ * %PCI_CAP_ID_EXPPCI Express
+ * %PCI_CAP_ID_MSIX MSI-X
+ *
+ * See PCI_CAP_ID_xxx for the complete capability ID codes.
+ *
+ * @dev: PCI device to query
+ * @cap: capability code
+ * @return:capability address or 0 if not supported
+ */
+int dm_pci_find_capability(struct udevice *dev, int cap);
+
+/**
+ * dm_pci_find_ext_capability() - find an extended capability
+ *
+ * Tell if a device supports a given PCI express extended capability.
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 in case the device
+ * does not support it.
+ *
+ * Possible values for @cap:
+ *
+ * %PCI_EXT_CAP_ID_ERRAdvanced Error Reporting
+ * %PCI_EXT_CAP_ID_VC Virtual Channel
+ * %PCI_EXT_CAP_ID_DSNDevice Serial Number
+ * %PCI_EXT_CAP_ID_PWRPower Budgeting
+ *
+ * See PCI_EXT_CAP_ID_xxx for the complete extended capability ID codes.
+ *
+ * @dev: PCI device to query
+ * @cap: extended capability code
+ * @return:extended capability address or 0 if not supported
+ */
+int dm_pci_find_ext_capability(struct udevice *dev, int cap);
+
#define dm_pci_virt_to_bus(dev, addr, flags) \
dm_pci_phys_to_bus(dev, (virt_to_phys(addr)), (flags))
#define dm_pci_bus_to_virt(dev, addr, flags, l
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On 25.7.2018 08:31, Chee, Tien Fong wrote:
> On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
>> On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee
>>>
>>> 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.
>>>
>>> Signed-off-by: Tien Fong Chee
>>> ---
>>> drivers/misc/Kconfig | 10 ++
>>> drivers/misc/Makefile| 1 +
>>> drivers/misc/fs_loader.c | 295
>>> +++
>>> include/dm/uclass-id.h | 1 +
>>> include/fs_loader.h | 79 +
>>> 5 files changed, 386 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 17b3a80..4163b4f 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
>>> depends on MISC
>>> help
>>> Support gdsys FPGA's RXAUI control.
>>> +
>>> +config FS_LOADER
>>> + bool "Enable loader driver for file system"
>>> + 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 4ce9d21..67a36f8 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
>>> obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.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..5fe642b
>>> --- /dev/null
>>> +++ b/drivers/misc/fs_loader.c
>>> @@ -0,0 +1,295 @@
>>> +/*
>>> + * Copyright (C) 2018 Intel Corporation
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0
>>> + */
>>> +#include
>>> +#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 */
>>> +};
>>> +
>>> +#ifdef CONFIG_CMD_UBIFS
>>> +static int mount_ubifs(char *mtdpart, char *ubivol)
>>> +{
>>> + int ret = ubi_part(mtdpart, NULL);
>>> +
>>> + if (ret) {
>>> + debug("Cannot find mtd partition %s\n", mtdpart);
>>> + return ret;
>>> + }
>>> +
>>> + return cmd_ubifs_mount(ubivol);
>>> +}
>>> +
>>> +static int umount_ubifs(void)
>>> +{
>>> + return cmd_ubifs_umount();
>>> +}
>>> +#else
>>> +static int mount_ubifs(char *mtdpart, char *ubivol)
>>> +{
>>> + debug("Error: Cannot load image: no UBIFS support\n");
>>> + return -ENOSYS;
>>> +}
>>> +#endif
>>> +
>>> +static int select_fs_dev(struct device_platdata *plat)
>>> +{
>>> + int ret;
>>> +
>>> + if (plat->phandlepart.phandle) {
>>> + ofnode node;
>>> +
>>> + node = ofnode_get_by_phandle(plat-
phandlepart.phandle);
>>> +
>>> + int of_offset = ofnode_to_offset(node);
>>> +
>>> + struct udevice *dev;
>>> +
>>> + ret = device_get_global_by_of_offset(of_offset,
>>> &dev);
>>> + if (!ret) {
>>> + struct blk_desc *desc =
>>> blk_get_by_device(dev);
>>> + if (desc) {
>>> + ret =
>>> fs_set_blk_dev_with_part(desc,
>>> + plat-
phandlepart.partition);
>>> + } else {
>>> + debug("%s: No device found\n",
>>> __func__);
>>> + return -ENODEV;
>>> + }
>>> + }
>>> + } else if (plat->mtdpart && plat->ubivol) {
>>> + ret = mount_ubifs(plat->mtdpart, plat->ubivol);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
>> I am curious why it is in generic FS loader any code which target any
>> filesystem. It should be filesystem independent.
> Because it supports our use case, and our preference using file system
> instead of RAW. As I agree with Tom, it can be evolved to support RAW
> in future.
It is not a problem that you have decided to support filesystems at
first place. I don't understand why you have UBIFS specific code here.
I would expect that this will done as CMD_FS_GENERIC option which is
based on code also able to work with UBIFS. It means this code will call
generic function and based on FS type proper functions will be chose
[U-Boot] [PATCH 1/1] ARM: dts: opos6ul: make the board boot again
Commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
dm-spl") removes the u-boot,dm-spl properties from the imx6ul.dtsi file
and breaks the OPOS6UL board.
Add the u-boot,dm-spl properties to make the board boot again.
Fixes: commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
dm-spl")
Signed-off-by: Sébastien Szymanski
---
arch/arm/dts/imx6ul-opos6ul.dtsi | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx6ul-opos6ul.dtsi b/arch/arm/dts/imx6ul-opos6ul.dtsi
index d51ad4de20..7023842315 100644
--- a/arch/arm/dts/imx6ul-opos6ul.dtsi
+++ b/arch/arm/dts/imx6ul-opos6ul.dtsi
@@ -99,7 +99,6 @@
/* eMMC */
&usdhc1 {
- u-boot,dm-spl;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
bus-width = <8>;
@@ -162,7 +161,6 @@
};
pinctrl_usdhc1: usdhc1grp {
- u-boot,dm-spl;
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
@@ -192,3 +190,34 @@
>;
};
};
+
+/* Specific to U-Boot */
+/ {
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+&aips1 {
+ u-boot,dm-spl;
+
+ spba-bus@0200 {
+ u-boot,dm-spl;
+ };
+};
+
+&aips2 {
+ u-boot,dm-spl;
+};
+
+&iomuxc {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc1 {
+ u-boot,dm-spl;
+};
+
+&usdhc1 {
+ u-boot,dm-spl;
+};
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: dts: opos6ul: make the board boot again
On Wed, Jul 25, 2018 at 11:07 AM, Sébastien Szymanski
wrote:
> Commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
> dm-spl") removes the u-boot,dm-spl properties from the imx6ul.dtsi file
> and breaks the OPOS6UL board.
> Add the u-boot,dm-spl properties to make the board boot again.
These should go into a imx6ul-opos6ul-u-boot.dtsi file so that when dt
files are synced from the kernel things like this aren't lost (again).
There's a number of examples of how that is done there.
Peter
> Fixes: commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for
> u-boot, dm-spl")
> Signed-off-by: Sébastien Szymanski
> ---
> arch/arm/dts/imx6ul-opos6ul.dtsi | 33 +++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/imx6ul-opos6ul.dtsi
> b/arch/arm/dts/imx6ul-opos6ul.dtsi
> index d51ad4de20..7023842315 100644
> --- a/arch/arm/dts/imx6ul-opos6ul.dtsi
> +++ b/arch/arm/dts/imx6ul-opos6ul.dtsi
> @@ -99,7 +99,6 @@
>
> /* eMMC */
> &usdhc1 {
> - u-boot,dm-spl;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> bus-width = <8>;
> @@ -162,7 +161,6 @@
> };
>
> pinctrl_usdhc1: usdhc1grp {
> - u-boot,dm-spl;
> fsl,pins = <
> MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
> MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
> @@ -192,3 +190,34 @@
> >;
> };
> };
> +
> +/* Specific to U-Boot */
> +/ {
> + soc {
> + u-boot,dm-spl;
> + };
> +};
> +
> +&aips1 {
> + u-boot,dm-spl;
> +
> + spba-bus@0200 {
> + u-boot,dm-spl;
> + };
> +};
> +
> +&aips2 {
> + u-boot,dm-spl;
> +};
> +
> +&iomuxc {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc1 {
> + u-boot,dm-spl;
> +};
> --
> 2.16.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 25.07.2018 09:04, Michal Simek wrote:
On 25.7.2018 08:52, Simon Goldschmidt wrote:
On 25.07.2018 08:40, Michal Simek wrote:
On 25.7.2018 08:26, Simon Goldschmidt wrote:
On 24.07.2018 15:07, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel
image
type. >
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9eabb1c1058b..dbf5ac33a845 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -257,10 +257,7 @@ static int spl_load_fit_image(struct
spl_load_info *info, ulong sector,
board_fit_image_post_process(&src, &length);
#endif
- if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
- IS_ENABLED(CONFIG_SPL_GZIP) &&
- image_comp == IH_COMP_GZIP &&
- type == IH_TYPE_KERNEL) {
+ if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
size = length;
if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
src, &size)) {
I suppose this is to support a gziped fpga image in a fit. Does this
work for U-Boot proper already?
Luis has tested it some days ago based on my suggestion. I have tried
that yesterday on zynq zc706 and it was also working for internal data.
Please take a look at second thread where also times are listed.
Isn't that 2nd thread on SPL also? I was asking for U-Boot proper in
comparison.
I have tested several cases for this series.
https://lists.denx.de/pipermail/u-boot/2018-July/335193.html
This is my script for generating images.
mkimage -d download.bin -T firmware -C none -a 0x100 -e 0x100 -A
arm -n "fpga download.bin" download.ub
gzip < download.bin > download.bin.gz
mkimage -d download.bin.gz -T firmware -C gzip -a 0x1000 -e
0x1000 -A arm -n "fpga download.bin.gz" download.gz.ub
mkimage -f fit.its download-fit.ub
fit.its unfortunately is not using gzip format.
I'm using the 'mkimage -f fit.its boot.itb' case (in U-Boot, not SPL),
so I if I read your comments above correctly, this is still not
supported for FIT images but only for "legacy" images?
But the recent patches add gzip support for FIT in SPL, did I get that
correctly?
If so, would it make sense to add FPGA gzip support in FIT to U-Boot proper?
We are programming the FPGA from U-Boot proper, not SPL, using a
Multi-config FIT image including matching Kernel and Device tree. And
here, using a gziped FPGA might be nice. But from reading the sources (I
think I also tested it once), that doesn't work. That's why I ask.
I am going to retest the whole series and I can try it but if this is
working in SPL I can't see any issue why this shouldn't work in full
u-boot. I am not using -E for mkimage but please test it and let me know
if this is working or not.
I'm not familiar with the -E option for mkimage. Does it apply to -f
fit.its? Given the above statements, I think my use case just does not
support gziped FPGA, yet.
Thanks,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX6Q SPL won't boot U-Boot from NAND
On 07/24/2018 09:25 PM, Adam Ford wrote: > I am trying to boot an i.MX6Q via SPL to U-Boot and eventually, use > Falcon mode to start the kernel. I can boot via SPL over USB. I have > enabled the NAND and SPL NAND, and i can confirm that mxs_nand_spl.c > is being built in. The board is imx6q_logic > > Unfortunately, I have run into two issues. > > 1. Imxs_nand_init from mxs_nand_spl.c is trying to run > nand_chip.scan_bbt(mtd), but nand_chip.scan_bbt hasn't been defined > from what i can tell. > > There is a function called nand_default_bb which looks like it should > be setup as the default for this, but I am not sure. As-is, the > system crashes when it attempts to run because it's a broken/NULL > function pointer. Is there something that should initialize this > pointer and/or what should it reference? > > 2. With the #1 commented out, I get some error messages, but I am > mostly concerned about the BCH read timeout. I am asking if there is > something missing. > > #define CONFIG_SYS_NAND_U_BOOT_OFFS0x20 +CC Stefano. btw I think you need kobs-ng to write the SPL in the special NXP format. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX6Q SPL won't boot U-Boot from NAND
On Wed, Jul 25, 2018 at 5:23 AM Marek Vasut wrote: > > On 07/24/2018 09:25 PM, Adam Ford wrote: > > I am trying to boot an i.MX6Q via SPL to U-Boot and eventually, use > > Falcon mode to start the kernel. I can boot via SPL over USB. I have > > enabled the NAND and SPL NAND, and i can confirm that mxs_nand_spl.c > > is being built in. The board is imx6q_logic > > > > Unfortunately, I have run into two issues. > > > > 1. Imxs_nand_init from mxs_nand_spl.c is trying to run > > nand_chip.scan_bbt(mtd), but nand_chip.scan_bbt hasn't been defined > > from what i can tell. > > > > There is a function called nand_default_bb which looks like it should > > be setup as the default for this, but I am not sure. As-is, the > > system crashes when it attempts to run because it's a broken/NULL > > function pointer. Is there something that should initialize this > > pointer and/or what should it reference? > > > > 2. With the #1 commented out, I get some error messages, but I am > > mostly concerned about the BCH read timeout. I am asking if there is > > something missing. > > > > #define CONFIG_SYS_NAND_U_BOOT_OFFS0x20 > > +CC Stefano. > > btw I think you need kobs-ng to write the SPL in the special NXP format. I did that. It wouldn't have booted at all without it. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 25.7.2018 12:14, Simon Goldschmidt wrote:
>
>
> On 25.07.2018 09:04, Michal Simek wrote:
>> On 25.7.2018 08:52, Simon Goldschmidt wrote:
>>> On 25.07.2018 08:40, Michal Simek wrote:
On 25.7.2018 08:26, Simon Goldschmidt wrote:
>
>
> On 24.07.2018 15:07, Michal Simek wrote:
>> There is no reason to limit gzip usage only for OS_BOOT and kernel
>> image
>> type. >
>> Signed-off-by: Michal Simek
>> ---
>>
>> common/spl/spl_fit.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index 9eabb1c1058b..dbf5ac33a845 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -257,10 +257,7 @@ static int spl_load_fit_image(struct
>> spl_load_info *info, ulong sector,
>> board_fit_image_post_process(&src, &length);
>> #endif
>> - if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
>> - IS_ENABLED(CONFIG_SPL_GZIP) &&
>> - image_comp == IH_COMP_GZIP &&
>> - type == IH_TYPE_KERNEL) {
>> + if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
>> size = length;
>> if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
>> src, &size)) {
>>
>
> I suppose this is to support a gziped fpga image in a fit. Does this
> work for U-Boot proper already?
Luis has tested it some days ago based on my suggestion. I have tried
that yesterday on zynq zc706 and it was also working for internal data.
Please take a look at second thread where also times are listed.
>>>
>>> Isn't that 2nd thread on SPL also? I was asking for U-Boot proper in
>>> comparison.
>>
>> I have tested several cases for this series.
>> https://lists.denx.de/pipermail/u-boot/2018-July/335193.html
>>
>> This is my script for generating images.
>>
>> mkimage -d download.bin -T firmware -C none -a 0x100 -e 0x100 -A
>> arm -n "fpga download.bin" download.ub
>>
>> gzip < download.bin > download.bin.gz
>> mkimage -d download.bin.gz -T firmware -C gzip -a 0x1000 -e
>> 0x1000 -A arm -n "fpga download.bin.gz" download.gz.ub
>>
>> mkimage -f fit.its download-fit.ub
>>
>> fit.its unfortunately is not using gzip format.
>
> I'm using the 'mkimage -f fit.its boot.itb' case (in U-Boot, not SPL),
> so I if I read your comments above correctly, this is still not
> supported for FIT images but only for "legacy" images?
>
> But the recent patches add gzip support for FIT in SPL, did I get that
> correctly?
We need to solve one issue with socfpga support but yes it is enabling
gzip support for FIT in SPL.
>
> If so, would it make sense to add FPGA gzip support in FIT to U-Boot
> proper?
Sure why not. I expect this shouldn't be hard to do.
>>
>>> We are programming the FPGA from U-Boot proper, not SPL, using a
>>> Multi-config FIT image including matching Kernel and Device tree. And
>>> here, using a gziped FPGA might be nice. But from reading the sources (I
>>> think I also tested it once), that doesn't work. That's why I ask.
>>
>> I am going to retest the whole series and I can try it but if this is
>> working in SPL I can't see any issue why this shouldn't work in full
>> u-boot. I am not using -E for mkimage but please test it and let me know
>> if this is working or not.
>
> I'm not familiar with the -E option for mkimage. Does it apply to -f
> fit.its? Given the above statements, I think my use case just does not
> support gziped FPGA, yet.
-E should be external data format that data are not stored with
information about partition. It means you can load just header and then
images which you need that you don't need to load everything what it is
there. Imaging fit image with 10 bitstreams and 10 configurations and
you only want to load one which you want to load.
It is faster to read 1 bitstream from sd then 10.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX6Q SPL won't boot U-Boot from NAND
On Wed, Jul 25, 2018 at 1:43 AM Jagan Teki wrote: > > On Wed, Jul 25, 2018 at 12:55 AM, Adam Ford wrote: > > I am trying to boot an i.MX6Q via SPL to U-Boot and eventually, use > > Falcon mode to start the kernel. I can boot via SPL over USB. I have > > enabled the NAND and SPL NAND, and i can confirm that mxs_nand_spl.c > > is being built in. The board is imx6q_logic > > > > Unfortunately, I have run into two issues. > > > > 1. Imxs_nand_init from mxs_nand_spl.c is trying to run > > nand_chip.scan_bbt(mtd), but nand_chip.scan_bbt hasn't been defined > > from what i can tell. > > > > There is a function called nand_default_bb which looks like it should > > be setup as the default for this, but I am not sure. As-is, the > > system crashes when it attempts to run because it's a broken/NULL > > function pointer. Is there something that should initialize this > > pointer and/or what should it reference? > > > > 2. With the #1 commented out, I get some error messages, but I am > > mostly concerned about the BCH read timeout. I am asking if there is > > something missing. > > Did you write the SPL from Linux? > Yes with kobs-ng. It wouldn't boot at all without doing that. > > > > #define CONFIG_SYS_NAND_U_BOOT_OFFS0x20 > > > > > > U-Boot SPL 2018.07-00031-g771af54de4-dirty (Jul 24 2018 - 14:18:14 -0500) > >>>spl:board_init_r() > > spl_early_init() > > Trying to boot from NAND > > spl: nand - using hw ecc > > 0x01:0xd3 erasesize=131072 (>>17) > > writesize=2048 (>>11) > > oobsize=64 > > chipsize=1073741824 > > Look like something broken in between, I'm observing SPL looping while > loading spl_load_image > > U-Boot SPL 2018.07-00368-g323a73adc9-dirty (Jul 25 2018 - 12:07:08 +0530) > >>spl:board_init_r() > spl_early_init() > I'm nand 12 > Trying to boot from NAND > spl: nand - using hw ecc > 0x2c:0xdc erasesize=262144 (>>18) > writesize=4096 (>>12) > oobsize=224 > chipsize=536870912 > > U-Boot SPL 2018.07-00368-g323a73adc9-dirty (Jul 25 2018 - 12:07:08 +0530) > >>spl:board_init_r() > spl_early_init() > I'm nand 12 > Trying to boot from NAND > spl: nand - using hw ecc > 0x2c:0xdc erasesize=262144 (>>18) > writesize=4096 (>>12) > oobsize=224 > chipsize=536870912 > > May be bisect with working commit can help us, here? I never had NAND working from SPL, so I am not sure if there is a good starting point from which to bisect. If I boot without using SPL, I can easily read/write my U-Boot environment to NAND and I can store the kernel, device tree, and UBIFS in NAND and successfully boot, so I think the problem is somewhere in the SPL version of the NAND drivers. adam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] env: Make environment loading log more clear
On 07/20/2018 06:18 PM, Sam Protsenko wrote: > This patch series intended to make boot log better. Basically here we > just remove unwanted error messages, relying on the message from most > deep API to be printed (like mmc subsystem). At the moment this looks > like most clean solution to cluttered log problem, as any other solution > will be hackish. > > With this patch set applied we will see something like this: > > Loading Environment from FAT... MMC: no card present > Loading Environment from MMC... OK > > instead of: > > Loading Environment from FAT... MMC: no card present > ** Bad device mmc 0 ** > Failed (-5) > Loading Environment from MMC... OK > > Sam Protsenko (2): > env: Don't print "Failed" error message > disk: part: Don't show redundant error message > > disk/part.c | 2 +- > env/env.c | 12 +++- > 2 files changed, 8 insertions(+), 6 deletions(-) > Hi Sam, After following the discussion from "Make U-Boot log great again" to here, it made me wonder: Does the user really need to be exposed to all the failed attempts to load the environment if it succeeded eventually? Maybe the maintainers are willing the consider a more drastic solution for clearing the console clutter when the environment loads. What if the only thing the user would see on a successful load is this: ENV: Loaded from MMC And the rest of the usual clutter would be visible only if DEBUG is set. It shouldn't be too hard to implement (Rising GD_FLG_SILENT if DEBUG not defined) and it is very consistent with the rest of the printed messages on boot. The problem is how and what to print on a failed load. I think it would be best if we could keep the above pattern like so: ENV: Failed to load from FAT - MMC: No card present (-5) ENV: Failed to load from MMC - No MMC card found (-5) ENV: Using default environment The last line would print only if (gd->flags & GD_FLG_ENV_DEFAULT) This might be harder to implement, but do you think it could work? Yaniv ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] mmc: arm_pl180_mmci: Remove cd_inverted host's struct field
On 07/24/2018 03:37 PM, Patrice Chotard wrote:
As platform uses GPIOs for card detection, it's
simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH)
in the gpio flags instead of using the cd-inverted
property.
Reported-by: Tuomas Tynkkynen
Signed-off-by: Patrice Chotard
---
Sounds good but doesn't this series need to also remove
the usage of cd-inverted from the DT? Like:
diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts
index c16594b7e4..f6753a4d1a 100644
--- a/arch/arm/dts/stm32429i-eval.dts
+++ b/arch/arm/dts/stm32429i-eval.dts
@@ -223,8 +223,7 @@
&sdio {
status = "okay";
vmmc-supply = <&mmc_vcard>;
- cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_HIGH>;
- cd-inverted;
+ cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins>;
pinctrl-1 = <&sdio_pins_od>;
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index e47f762e54..187c94b99b 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -307,8 +307,7 @@
&sdio {
status = "okay";
- cd-gpios = <&gpioc 13 0>;
- cd-inverted;
+ cd-gpios = <&gpioc 13 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins>;
pinctrl-1 = <&sdio_pins_od>;
diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31c21..210be07ccc 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -256,8 +256,7 @@
&sdio2 {
status = "okay";
- cd-gpios = <&gpioi 15 0>;
- cd-inverted;
+ cd-gpios = <&gpioi 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins_b>;
pinctrl-1 = <&sdio_pins_od_b>;
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 1cd780b3eec0..f71d79ecd6ba 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -499,11 +499,8 @@ static int dm_mmc_getcd(struct udevice *dev)
struct pl180_mmc_host *host = dev->priv;
int value = 1;
- if (dm_gpio_is_valid(&host->cd_gpio)) {
+ if (dm_gpio_is_valid(&host->cd_gpio))
value = dm_gpio_get_value(&host->cd_gpio);
- if (host->cd_inverted)
- return !value;
- }
return value;
}
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index 6b98db6cd978..36487be288b2 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -192,7 +192,6 @@ struct pl180_mmc_host {
struct mmc_config cfg;
#ifdef CONFIG_DM_MMC
struct gpio_desc cd_gpio;
- bool cd_inverted;
#endif
};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bootcount: Fix misaligned cache operation
1947c2d2a0 introduces cache line flushes for the bootcounter, but if
the start address is not aligned then the flush causes warnings of
the form:
CACHE: Misaligned operation at range [4030b7fc, 4030b83c]
Align both the start and end of the buffer (possibly crossing multiple
lines).
Fixes: 1947c2d2a0 ("bootcount: flush after storing the bootcounter")
Signed-off-by: Alex Kiernan
---
drivers/bootcount/bootcount.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
index a3162c97ed..646c563f8a 100644
--- a/drivers/bootcount/bootcount.c
+++ b/drivers/bootcount/bootcount.c
@@ -11,16 +11,23 @@
__weak void bootcount_store(ulong a)
{
void *reg = (void *)CONFIG_SYS_BOOTCOUNT_ADDR;
+ uintptr_t flush_start = rounddown(CONFIG_SYS_BOOTCOUNT_ADDR,
+ CONFIG_SYS_CACHELINE_SIZE);
+ uintptr_t flush_end;
#if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD)
raw_bootcount_store(reg, (BOOTCOUNT_MAGIC & 0x) | a);
+
+ flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 4,
+ CONFIG_SYS_CACHELINE_SIZE);
#else
raw_bootcount_store(reg, a);
raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
+
+ flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 8,
+ CONFIG_SYS_CACHELINE_SIZE);
#endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
- flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
- CONFIG_SYS_BOOTCOUNT_ADDR +
- CONFIG_SYS_CACHELINE_SIZE);
+ flush_dcache_range(flush_start, flush_end);
}
__weak ulong bootcount_load(void)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootcount: Fix misaligned cache operation
On 25/07/2018 13:45, Alex Kiernan wrote:
> 1947c2d2a0 introduces cache line flushes for the bootcounter, but if
> the start address is not aligned then the flush causes warnings of
> the form:
>
> CACHE: Misaligned operation at range [4030b7fc, 4030b83c]
>
> Align both the start and end of the buffer (possibly crossing multiple
> lines).
>
Thanks - not noted because I just used already aligned addresses :-)
> Fixes: 1947c2d2a0 ("bootcount: flush after storing the bootcounter")
> Signed-off-by: Alex Kiernan
> ---
>
> drivers/bootcount/bootcount.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
> index a3162c97ed..646c563f8a 100644
> --- a/drivers/bootcount/bootcount.c
> +++ b/drivers/bootcount/bootcount.c
> @@ -11,16 +11,23 @@
> __weak void bootcount_store(ulong a)
> {
> void *reg = (void *)CONFIG_SYS_BOOTCOUNT_ADDR;
> + uintptr_t flush_start = rounddown(CONFIG_SYS_BOOTCOUNT_ADDR,
> + CONFIG_SYS_CACHELINE_SIZE);
> + uintptr_t flush_end;
>
> #if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD)
> raw_bootcount_store(reg, (BOOTCOUNT_MAGIC & 0x) | a);
> +
> + flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 4,
> + CONFIG_SYS_CACHELINE_SIZE);
> #else
> raw_bootcount_store(reg, a);
> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
> +
> + flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 8,
> + CONFIG_SYS_CACHELINE_SIZE);
> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
> - flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
> - CONFIG_SYS_BOOTCOUNT_ADDR +
> - CONFIG_SYS_CACHELINE_SIZE);
> + flush_dcache_range(flush_start, flush_end);
> }
>
> __weak ulong bootcount_load(void)
>
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] dm: mdio: add a uclass for MDIO
Hello, On Tue, Jul 10, 2018 at 5:05 AM, Joe Hershberger wrote: > On Thu, Jul 5, 2018 at 2:34 AM, wrote: >> From: Ken Ma >> >> Add a uclass which provides access to MDIO busses and includes >> operations required by MDIO. >> The implementation is based on the existing mii/phy/mdio data >> structures and APIs. >> This patch also adds device tree binding for MDIO bus. >> >> Signed-off-by: Ken Ma >> Reviewed-by: s...@chromium.org, joe.hershber...@ni.com >> --- >> >> Changes in v4: >> - Minor updates for comments and Maintainer. >> >> Changes in v3: >> - Move mdio uclass implementation to driver/net folder; >> - Replace flat-tree functions with livetree functions and update codes >> and comments to be consistent with driver-model codes style; >> - Put struct mii_dev to uclass platdata to avoid the mdio alloc and >> let driver model framework to alloc the memroy automatically, >> meanwhile the mii bus link initialization is added. >> >> Changes in v2: >> - Fix error printing: >> - Change some debug to pr_err; >> - mii bus has no parent member and it is not a udevice, so dev_err >> is changed to pr_err for mii bus error printings. >> >> MAINTAINERS | 1 + >> doc/device-tree-bindings/net/mdio-bus.txt | 54 ++ >> drivers/Kconfig | 2 + >> drivers/net/Makefile | 1 + >> drivers/net/mdio/Kconfig | 18 + >> drivers/net/mdio/Makefile | 6 ++ >> drivers/net/mdio/mdio-uclass.c| 112 >> ++ >> include/dm/uclass-id.h| 1 + >> include/net/mdio.h| 62 + >> 9 files changed, 257 insertions(+) >> create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt >> create mode 100644 drivers/net/mdio/Kconfig >> create mode 100644 drivers/net/mdio/Makefile >> create mode 100644 drivers/net/mdio/mdio-uclass.c >> create mode 100644 include/net/mdio.h >> It looks this only supports mdio device via device tree. How about PCI NICs? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] ARM: opos6ul: make the board boot again
Commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
dm-spl") removes the u-boot,dm-spl properties from the imx6ul.dtsi file
and breaks the OPOS6UL board.
Add the u-boot,dm-spl properties into *-u-boot.dts files to make the
board boot again.
Fixes: commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
dm-spl")
Signed-off-by: Sébastien Szymanski
---
Changes for v2:
- put u-boot,dm-spl properties into -u-boot.dts files
arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi | 28
arch/arm/dts/imx6ul-opos6ul.dtsi | 2 --
arch/arm/dts/imx6ul-opos6uldev-u-boot.dts | 25 +
arch/arm/dts/imx6ul-opos6uldev.dts| 2 --
configs/opos6uldev_defconfig | 2 +-
5 files changed, 54 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6ul-opos6uldev-u-boot.dts
diff --git a/arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi
b/arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi
new file mode 100644
index 00..4918de388e
--- /dev/null
+++ b/arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source extras for U-Boot for the OPOS6UL SoM
+ *
+ * Copyright (C) 2018 Armadeus Systems
+ */
+
+/ {
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+&aips2 {
+ u-boot,dm-spl;
+};
+
+&iomuxc {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc1 {
+ u-boot,dm-spl;
+};
+
+&usdhc1 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx6ul-opos6ul.dtsi b/arch/arm/dts/imx6ul-opos6ul.dtsi
index d51ad4de20..8f16a0a81c 100644
--- a/arch/arm/dts/imx6ul-opos6ul.dtsi
+++ b/arch/arm/dts/imx6ul-opos6ul.dtsi
@@ -99,7 +99,6 @@
/* eMMC */
&usdhc1 {
- u-boot,dm-spl;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
bus-width = <8>;
@@ -162,7 +161,6 @@
};
pinctrl_usdhc1: usdhc1grp {
- u-boot,dm-spl;
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
diff --git a/arch/arm/dts/imx6ul-opos6uldev-u-boot.dts
b/arch/arm/dts/imx6ul-opos6uldev-u-boot.dts
new file mode 100644
index 00..21899cdd67
--- /dev/null
+++ b/arch/arm/dts/imx6ul-opos6uldev-u-boot.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source extras for U-Boot for the OPOS6ULDev board
+ *
+ * Copyright (C) 2018 Armadeus Systems
+ */
+
+#include "imx6ul-opos6uldev.dts"
+#include "imx6ul-opos6ul-u-boot.dtsi"
+
+&aips1 {
+ u-boot,dm-spl;
+
+ spba-bus@0200 {
+ u-boot,dm-spl;
+ };
+};
+
+&pinctrl_uart1 {
+ u-boot,dm-spl;
+};
+
+&uart1 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx6ul-opos6uldev.dts
b/arch/arm/dts/imx6ul-opos6uldev.dts
index 9a51d1e54f..0e59ee57fd 100644
--- a/arch/arm/dts/imx6ul-opos6uldev.dts
+++ b/arch/arm/dts/imx6ul-opos6uldev.dts
@@ -228,7 +228,6 @@
};
&uart1 {
- u-boot,dm-spl;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
status = "okay";
@@ -374,7 +373,6 @@
};
pinctrl_uart1: uart1grp {
- u-boot,dm-spl;
fsl,pins = <
MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
diff --git a/configs/opos6uldev_defconfig b/configs/opos6uldev_defconfig
index 729f9d78be..9f5697b121 100644
--- a/configs/opos6uldev_defconfig
+++ b/configs/opos6uldev_defconfig
@@ -12,7 +12,7 @@ CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
CONFIG_SPL=y
CONFIG_SPL_LIBDISK_SUPPORT=y
# CONFIG_CMD_BMODE is not set
-CONFIG_DEFAULT_DEVICE_TREE="imx6ul-opos6uldev"
+CONFIG_DEFAULT_DEVICE_TREE="imx6ul-opos6uldev-u-boot"
CONFIG_TPL_SYS_MALLOC_F_LEN=0x400
CONFIG_BOOTDELAY=5
CONFIG_USE_BOOTARGS=y
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] ARM: opos6ul: make the board boot again
On Wed, Jul 25, 2018 at 9:47 AM, Sébastien Szymanski
wrote:
> Commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
> dm-spl") removes the u-boot,dm-spl properties from the imx6ul.dtsi file
> and breaks the OPOS6UL board.
> Add the u-boot,dm-spl properties into *-u-boot.dts files to make the
> board boot again.
>
> Fixes: commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for
> u-boot, dm-spl")
> Signed-off-by: Sébastien Szymanski
> ---
>
> Changes for v2:
> - put u-boot,dm-spl properties into -u-boot.dts files
Looks good:
Reviewed-by: Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] efi patch queue 2018-07-25
Hi Tom, This is my current patch queue for efi. Please pull. Alex The following changes since commit 323a73adc9a1bf2de43fe03bdd9c3038ce7c2784: mtd: nand: add new enum for storing ECC algorithm (2018-07-23 14:33:21 -0400) are available in the git repository at: git://github.com/agraf/u-boot.git tags/signed-efi-next for you to fetch changes up to 0b8a88ab6aa24de0ef2bf1e8109409f71e770a8e: MAINTAINERS: assign lib/charset.c (2018-07-25 15:00:24 +0200) Patch queue for efi - 2018-07-25 Highlights this time: - Many small fixes to improve spec compatibility (found by SCT) - Almost enough to run with sandbox target - GetTime() improvements - Enable EFI_LOADER and HYP entry on ARMv7 with NONSEC=y Alexander Graf (11): efi_loader: Use compiler constants for image loader efi_loader: Use map_sysmem() in bootefi command efi_loader: Allow SMBIOS tables in highmem efi_loader: Disable miniapps on sandbox efi_loader: Introduce ms abi vararg helpers efi_loader: Move to compiler based target architecture determination elf: Move x86 reloc defines to common elf.h efi_loader: Use common elf.h reloc defines efi_loader: Expose U-Boot addresses in memory map for sandbox efi_loader: Rename sections to allow for implicit data x86: Add efi_loader bits to x86_64 linker script Heinrich Schuchardt (29): efi_selftest: update .gitignore efi_loader: efi_allocate_pages is too restrictive efi_loader: check parameters of CreateEvent efi_loader: check parameters in memory allocation efi_loader: check parameters of GetMemoryMap efi_loader: check map_key in ExitBootServices fs: fat: cannot write to subdirectories efi_selftest: test writing to file efi_driver: set DM_FLAG_NAME_ALLOCED flag efi_loader: set revision in loaded image protocol efi_loader: EFI_SIMPLE_TEXT_INPUT_PROTOCOL.Reset() efi_loader: clear screen has to reset cursor position efi_loader: specify UEFI spec revision efi_loader: correct EFI_RUNTIME_SERVICES_SIGNATURE efi_loader: correct headersize EFI tables efi_loader: provide firmware revision efi_loader: calculate crc32 for EFI tables efi_loader: allocate configuration table array efi_selftest: test InstallConfigurationTable() efi_loader: correct signature of CalculateCrc32() efi_loader: update crc32 in InstallConfigurationTable efi_selftest: check crc32 for InstallConfigurationTable efi_selftest: unit test for CalculateCrc32() rtc: remove CONFIG_CMD_DATE dependency efi_loader: remove unused efi_get_time_init() efi_loader: complete implementation of GetTime() efi_selftest: support printing leading zeroes efi_selftest: unit test for GetTime() MAINTAINERS: assign lib/charset.c Mark Kettenis (5): ARM: HYP/non-sec: migrate stack efi_loader: ARM: run EFI payloads non-secure efi_loader: ARM: don't attempt to enter non-secure mode twice ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported Revert "efi_loader: no support for ARMV7_NONSEC=y" Simon Glass (5): efi: sandbox: Adjust memory usage for sandbox vsprintf: Handle NULL with %pU efi_selftest: Clean up a few comments and messages efi: Tidy up device-tree-size calculation in copy_fdt() efi: Drop error return in efi_carve_out_dt_rsv() MAINTAINERS | 1 + arch/arm/config.mk | 4 +- arch/arm/cpu/armv7/Kconfig | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 2 + arch/arm/cpu/armv8/u-boot.lds| 24 ++- arch/arm/cpu/u-boot.lds | 36 ++-- arch/arm/mach-zynq/u-boot.lds| 36 ++-- arch/riscv/cpu/ax25/u-boot.lds | 26 ++- arch/sandbox/config.mk | 3 + arch/sandbox/cpu/u-boot.lds | 9 +- arch/x86/config.mk | 2 + arch/x86/cpu/start.S | 2 +- arch/x86/cpu/start64.S | 2 +- arch/x86/cpu/u-boot-64.lds | 37 +++- arch/x86/cpu/u-boot.lds | 34 ++-- arch/x86/include/asm/elf.h | 45 - arch/x86/lib/reloc_ia32_efi.c| 1 - arch/x86/lib/reloc_x86_64_efi.c | 1 - board/qualcomm/dragonboard410c/u-boot.lds| 17 +- board/qualcomm/dragonboard820c/u-boot.lds| 24 ++- board/ti/am335x/u-boot.lds | 36 ++-- cmd/bootefi.c| 90 +++-- doc/README.uefi | 2 - drivers/rtc/at91sam9_rtt.c | 4 - drivers/rtc/davinci.c| 2 - drivers/rtc/ds1302.c
Re: [U-Boot] [PATCH v3 6/6] mmc: arm_pl180_mmci: Remove cd_inverted host's struct field
Hi Tuomas
On 07/25/2018 01:42 PM, Tuomas Tynkkynen wrote:
> On 07/24/2018 03:37 PM, Patrice Chotard wrote:
>> As platform uses GPIOs for card detection, it's
>> simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH)
>> in the gpio flags instead of using the cd-inverted
>> property.
>>
>>
>> Reported-by: Tuomas Tynkkynen
>> Signed-off-by: Patrice Chotard
>> ---
>
> Sounds good but doesn't this series need to also remove
> the usage of cd-inverted from the DT? Like:
Argh sorry, i send my series too quickly yesterday ...
I will submit a v4
Thanks for checking ;-)
Patrice
>
> diff --git a/arch/arm/dts/stm32429i-eval.dts
> b/arch/arm/dts/stm32429i-eval.dts
> index c16594b7e4..f6753a4d1a 100644
> --- a/arch/arm/dts/stm32429i-eval.dts
> +++ b/arch/arm/dts/stm32429i-eval.dts
> @@ -223,8 +223,7 @@
> &sdio {
> status = "okay";
> vmmc-supply = <&mmc_vcard>;
> - cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_HIGH>;
> - cd-inverted;
> + cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default", "opendrain";
> pinctrl-0 = <&sdio_pins>;
> pinctrl-1 = <&sdio_pins_od>;
> diff --git a/arch/arm/dts/stm32f746-disco.dts
> b/arch/arm/dts/stm32f746-disco.dts
> index e47f762e54..187c94b99b 100644
> --- a/arch/arm/dts/stm32f746-disco.dts
> +++ b/arch/arm/dts/stm32f746-disco.dts
> @@ -307,8 +307,7 @@
>
> &sdio {
> status = "okay";
> - cd-gpios = <&gpioc 13 0>;
> - cd-inverted;
> + cd-gpios = <&gpioc 13 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default", "opendrain";
> pinctrl-0 = <&sdio_pins>;
> pinctrl-1 = <&sdio_pins_od>;
> diff --git a/arch/arm/dts/stm32f769-disco.dts
> b/arch/arm/dts/stm32f769-disco.dts
> index 59c9d31c21..210be07ccc 100644
> --- a/arch/arm/dts/stm32f769-disco.dts
> +++ b/arch/arm/dts/stm32f769-disco.dts
> @@ -256,8 +256,7 @@
>
> &sdio2 {
> status = "okay";
> - cd-gpios = <&gpioi 15 0>;
> - cd-inverted;
> + cd-gpios = <&gpioi 15 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default", "opendrain";
> pinctrl-0 = <&sdio_pins_b>;
> pinctrl-1 = <&sdio_pins_od_b>;
>
>> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
>> index 1cd780b3eec0..f71d79ecd6ba 100644
>> --- a/drivers/mmc/arm_pl180_mmci.c
>> +++ b/drivers/mmc/arm_pl180_mmci.c
>> @@ -499,11 +499,8 @@ static int dm_mmc_getcd(struct udevice *dev)
>> struct pl180_mmc_host *host = dev->priv;
>> int value = 1;
>> - if (dm_gpio_is_valid(&host->cd_gpio)) {
>> + if (dm_gpio_is_valid(&host->cd_gpio))
>> value = dm_gpio_get_value(&host->cd_gpio);
>> - if (host->cd_inverted)
>> - return !value;
>> - }
>> return value;
>> }
>> diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
>> index 6b98db6cd978..36487be288b2 100644
>> --- a/drivers/mmc/arm_pl180_mmci.h
>> +++ b/drivers/mmc/arm_pl180_mmci.h
>> @@ -192,7 +192,6 @@ struct pl180_mmc_host {
>> struct mmc_config cfg;
>> #ifdef CONFIG_DM_MMC
>> struct gpio_desc cd_gpio;
>> - bool cd_inverted;
>> #endif
>> };
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] efi: Fix truncation of constant value
Hello Alexander, Heinrich was kind to have a look at [1] and already provided his Reviewed-by. Could you please state your further expectations to accept the patches? [1] https://patchwork.ozlabs.org/patch/944004/ Thanks, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8: make SPL exception vectors optional
On Wed, Jul 25, 2018 at 12:57:01AM +0100, Andre Przywara wrote: > Even though the exception vector table is a fundamental part of the ARM > architecture, U-Boot mostly does not make real use of it, except when > crash dumping. But having it in takes up quite some space, partly due to > the architectural alignment requirement of 2KB. Since we don't take special > care of that, the compiler adds a more or less random amount of padding > space, which increases the image size quite a bit, especially for the SPL. > > On a typical Allwinner build this is around 1.5KB of padding, plus 1KB > for the vector table (mostly padding space again), then some extra code > to do the actual handling. This amounts to almost 10% of the maximum image > size, which is quite a lot for a pure debugging feature. > > Add a Kconfig symbol to allow the exception vector table to be left out > of the build for the SPL. > For now this is "default y" for everyone, but specific defconfigs, > platforms or .config files can opt out here at will, to mitigate the code > size pressure we see for some SPLs. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv8/Kconfig | 11 +++ > arch/arm/cpu/armv8/Makefile | 4 > arch/arm/cpu/armv8/start.S | 19 +++ > 3 files changed, 30 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig > index 22d2f29548..bd1e759c37 100644 > --- a/arch/arm/cpu/armv8/Kconfig > +++ b/arch/arm/cpu/armv8/Kconfig > @@ -1,5 +1,16 @@ > if ARM64 > > +config ARMV8_SPL_EXCEPTION_VECTORS > + bool "Install crash dump exception vectors" > + depends on SPL > + default y > + help > + The default exception vector table is only used for the crash > + dump, but still takes quite a lot of space in the image size. > + > + Say N here if you are running out of code space in the image > + and want to save some space at the cost of less debugging info. > + > config ARMV8_MULTIENTRY > bool "Enable multiple CPUs to enter into U-Boot" > > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile > index d1d4ffecfd..52c8daa049 100644 > --- a/arch/arm/cpu/armv8/Makefile > +++ b/arch/arm/cpu/armv8/Makefile > @@ -10,7 +10,11 @@ ifndef CONFIG_$(SPL_TPL_)TIMER > obj-$(CONFIG_SYS_ARCH_TIMER) += generic_timer.o > endif > obj-y+= cache_v8.o > +ifdef CONFIG_SPL_BUILD > +obj-$(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) += exceptions.o > +else > obj-y+= exceptions.o > +endif I _think_ we can make the code parts of this read better (and make use of CONFIG_IS_ENABLED() if we add CONFIG_ARMV8_EXCEPTION_VECTORS and don't allow it to be unselected (ie no text on the bool line). -- 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] [PATCH V2] drivers: regulator: fixed: add u-boot, off-on-delay-us
On Wed, Jul 25, 2018 at 03:02:04AM +, Peng Fan wrote: > Hi Fabio, > > > -Original Message- > > From: Fabio Estevam [mailto:feste...@gmail.com] > > Sent: 2018年7月25日 10:59 > > To: Peng Fan > > Cc: Simon Glass ; U-Boot-Denx ; > > dl-linux-imx ; Breno Matheus Lima > > Subject: Re: [U-Boot] [PATCH V2] drivers: regulator: fixed: add u-boot, > > off-on-delay-us > > > > Hi Peng, > > > > On Tue, Jul 24, 2018 at 5:11 AM, Peng Fan wrote: > > > > > .../devicetree/bindings/regulator/fixed-regulator.txt| 16 > > > > > drivers/power/regulator/fixed.c | 6 > > ++ > > > 2 files changed, 22 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/regulator/fixed-regulator.txt > > > > I thought that bindings should go into doc/device-tree-bindings/ in U-Boot > > instead? > > I was not aware of this place. I am not sure, because there is also a > Documentation/devicetree/bindings/ directory. > > Tom, > > Where should the new uboot bindings be put into? I just yesterday consolidated into just doc/device-tree-bindings/ as everything else was already in there. -- 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] Makefile: Fix 'clean' target
Now that we have removed the DocBook files we need to not try and clean
that directory.
Reported-by: ericywl
Fixes: 78a88f7930be ("doc: Replace DocBook with sphinx-based docs")
Signed-off-by: Tom Rini
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index d1246e063f85..79cbad22db82 100644
--- a/Makefile
+++ b/Makefile
@@ -1603,7 +1603,7 @@ clean: rm-files := $(CLEAN_FILES)
clean-dirs := $(foreach f,$(u-boot-alldirs),$(if $(wildcard
$(srctree)/$f/Makefile),$f))
-clean-dirs := $(addprefix _clean_, $(clean-dirs) doc/DocBook)
+clean-dirs := $(addprefix _clean_, $(clean-dirs))
PHONY += $(clean-dirs) clean archclean
$(clean-dirs):
@@ -1685,7 +1685,7 @@ help:
@echo ' coccicheck - Execute static code analysis with
Coccinelle'
@echo ''
@echo 'Documentation targets:'
- @$(MAKE) -f $(srctree)/doc/DocBook/Makefile dochelp
+ @$(MAKE) -f $(srctree)/Documentation/Makefile dochelp
@echo ''
@echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose
build'
@echo ' make V=2 [targets] 2 => give reason for rebuild of target'
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] docproc: Remove
Now that we have moved to Sphinx documentation we don't need the docproc
app anymore, remove.
Signed-off-by: Tom Rini
---
scripts/.gitignore | 1 -
scripts/Makefile | 9 -
scripts/docproc.c | 580 -
3 files changed, 590 deletions(-)
delete mode 100644 scripts/docproc.c
diff --git a/scripts/.gitignore b/scripts/.gitignore
index 17b903b0f5bf..08cc824bac3d 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -2,4 +2,3 @@
# Generated files
#
bin2c
-docproc
diff --git a/scripts/Makefile b/scripts/Makefile
index e27308a97a57..e7b353f77f43 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,20 +3,11 @@
# scripts contains sources for various helper programs used throughout
# the kernel for the build process.
# ---
-# docproc: Used in Documentation/DocBook
hostprogs-$(CONFIG_BUILD_BIN2C)+= bin2c
always := $(hostprogs-y)
-# The following hostprogs-y programs are only build on demand
-hostprogs-y += docproc
-
-# These targets are used internally to avoid "is up to date" messages
-PHONY += build_docproc
-build_docproc: $(obj)/docproc
- @:
-
# Let clean descend into subdirs
subdir-+= basic kconfig
subdir-$(CONFIG_DTC) += dtc
diff --git a/scripts/docproc.c b/scripts/docproc.c
deleted file mode 100644
index e267e621431a..
--- a/scripts/docproc.c
+++ /dev/null
@@ -1,580 +0,0 @@
-/*
- * docproc is a simple preprocessor for the template files
- * used as placeholders for the kernel internal documentation.
- * docproc is used for documentation-frontend and
- * dependency-generator.
- * The two usages have in common that they require
- * some knowledge of the .tmpl syntax, therefore they
- * are kept together.
- *
- * documentation-frontend
- * Scans the template file and call kernel-doc for
- * all occurrences of ![EIF]file
- * Beforehand each referenced file is scanned for
- * any symbols that are exported via these macros:
- * EXPORT_SYMBOL(), EXPORT_SYMBOL_GPL(), &
- * EXPORT_SYMBOL_GPL_FUTURE()
- * This is used to create proper -function and
- * -nofunction arguments in calls to kernel-doc.
- * Usage: docproc doc file.tmpl
- *
- * dependency-generator:
- * Scans the template file and list all files
- * referenced in a format recognized by make.
- * Usage: docproc depend file.tmpl
- * Writes dependency information to stdout
- * in the following format:
- * file.tmpl src.c src2.c
- * The filenames are obtained from the following constructs:
- * !Efilename
- * !Ifilename
- * !Dfilename
- * !Ffilename
- * !Pfilename
- *
- */
-
-#define _GNU_SOURCE
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/* exitstatus is used to keep track of any failing calls to kernel-doc,
- * but execution continues. */
-int exitstatus = 0;
-
-typedef void DFL(char *);
-DFL *defaultline;
-
-typedef void FILEONLY(char * file);
-FILEONLY *internalfunctions;
-FILEONLY *externalfunctions;
-FILEONLY *symbolsonly;
-FILEONLY *findall;
-
-typedef void FILELINE(char * file, char * line);
-FILELINE * singlefunctions;
-FILELINE * entity_system;
-FILELINE * docsection;
-
-#define MAXLINESZ 2048
-#define MAXFILES 250
-#define KERNELDOCPATH "scripts/"
-#define KERNELDOC "kernel-doc"
-#define DOCBOOK "-docbook"
-#define LIST "-list"
-#define FUNCTION "-function"
-#define NOFUNCTION"-nofunction"
-#define NODOCSECTIONS "-no-doc-sections"
-#define SHOWNOTFOUND "-show-not-found"
-
-static char *srctree, *kernsrctree;
-
-static char **all_list = NULL;
-static int all_list_len = 0;
-
-static void consume_symbol(const char *sym)
-{
- int i;
-
- for (i = 0; i < all_list_len; i++) {
- if (!all_list[i])
- continue;
- if (strcmp(sym, all_list[i]))
- continue;
- all_list[i] = NULL;
- break;
- }
-}
-
-static void usage (void)
-{
- fprintf(stderr, "Usage: docproc {doc|depend} file\n");
- fprintf(stderr, "Input is read from file.tmpl. Output is sent to
stdout\n");
- fprintf(stderr, "doc: frontend when generating kernel documentation\n");
- fprintf(stderr, "depend: generate list of files referenced within
file\n");
- fprintf(stderr, "Environment variable SRCTREE: absolute path to
sources.\n");
- fprintf(stderr, " KBUILD_SRC: absolute path to
kernel source tree.\n");
-}
-
-/*
- * Execute kernel-doc with parameters given in svec
- */
-static void exec_kernel_doc(char **svec)
-{
- pid_t pi
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Hi, On 25 July 2018 at 03:48, Michal Simek wrote: > > On 25.7.2018 08:31, Chee, Tien Fong wrote: > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote: > >> On 6.7.2018 10:28, tien.fong.c...@intel.com wrote: > >>> > >>> From: Tien Fong Chee > >>> [...] > >> > >> Also that DT binding is quite weird and I don't think you will get > >> ACK > >> for this from device tree community at all. I think that calling via > >> platdata and avoid DT nodes would be better way to go. > > Why do you think DT binding is weird? The DT is designed based on Simon > > proposal, and i believe following the rules in DTS spec. > > There are some DT benefits with current design, i think someone may be > > maintainer need to made the final decision on the design. > > It is software configuration in file which should mostly describe > hardware and state for hardware configuration. > > Your fs_loader node is purely describe sw configuration which shouldn't > be here. > You have there run time configuration via variables. I think using only > this way is enough. Default variables will match what you would want to > add to DT. I think DT makes sense in the U-Boot context. We don't have a user space to handle policy decisions, and the 'chosen' node is a good place to configure these common features. While you can argue that the partition or filesystem where an image comes from is a software config, it is something that has to be configured. It has impact on hardware too, since the FPGA has to get its firmware from somewhere. We use the chosen node to specify the UART to use, and this is no different. Again, we don't have user-space config files in U-Boot. This argument comes up from time to time and I'd really like to put it to bed for U-Boot. I understand that Linux has its own approach and rules, but in some cases they serve U-Boot poorly. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/9] configs: stm32f429-evaluation: Enable CONFIG_BLK
CONFIG_BLK config flag becomes mandatory, enable it. Signed-off-by: Patrice Chotard --- Changes in v4: None Changes in v3: None Changes in v2: None configs/stm32f429-evaluation_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig index 1b14a4964067..3ddd5c50fb1d 100644 --- a/configs/stm32f429-evaluation_defconfig +++ b/configs/stm32f429-evaluation_defconfig @@ -26,7 +26,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y -# CONFIG_BLK is not set CONFIG_DM_MMC=y CONFIG_ARM_PL180_MMCI=y CONFIG_MTD_NOR_FLASH=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/9] configs: stm32f746-disco: Enable CONFIG_BLK
CONFIG_BLK config flag becomes mandatory, enable it. Signed-off-by: Patrice Chotard Reviewed-by: Simon Glass --- Changes in v4: None Changes in v3: None Changes in v2: None configs/stm32f746-disco_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/stm32f746-disco_defconfig b/configs/stm32f746-disco_defconfig index aa7403f3c516..6f07ff155862 100644 --- a/configs/stm32f746-disco_defconfig +++ b/configs/stm32f746-disco_defconfig @@ -40,7 +40,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_NETCONSOLE=y -# CONFIG_BLK is not set CONFIG_DM_MMC=y # CONFIG_SPL_DM_MMC is not set CONFIG_ARM_PL180_MMCI=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/9] configs: stm32f469-disco: Enable CONFIG_BLK
CONFIG_BLK config flag becomes mandatory, enable it. Signed-off-by: Patrice Chotard --- Changes in v4: None Changes in v3: None Changes in v2: None configs/stm32f469-discovery_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/stm32f469-discovery_defconfig b/configs/stm32f469-discovery_defconfig index 4de03edcc2ca..a55476f2f323 100644 --- a/configs/stm32f469-discovery_defconfig +++ b/configs/stm32f469-discovery_defconfig @@ -26,7 +26,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y -# CONFIG_BLK is not set CONFIG_DM_MMC=y CONFIG_ARM_PL180_MMCI=y CONFIG_MTD_NOR_FLASH=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/9] mmc: arm_pl180_mmci: Update to support CONFIG_BLK
Config flag CONFIG_BLK becomes mandatory, update arm_pl180_mmci
to support this config.
This driver is used by STM32Fx and by Vexpress platforms.
Only STM32Fx are DM ready. No DM code is isolated and will be
removed easily when wexpress will be converted to DM.
Signed-off-by: Patrice Chotard
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- replace devfdt_get_addr() by dev_read_addr()
- re-introduce arm_pl180_mmc_ofdata_to_platdata()
drivers/mmc/arm_pl180_mmci.c | 67 ++--
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index e267cd782e8b..c4d94d102cc1 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -357,13 +357,13 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
.set_ios = host_set_ios,
.init = mmc_host_reset,
};
-#endif
/*
* mmc_host_init - initialize the mmc controller.
* Set initial clock and power for mmc slot.
* Initialize mmc struct and register with mmc framework.
*/
+
int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
{
u32 sdi_u32;
@@ -377,9 +377,8 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct
mmc **mmc)
writel(sdi_u32, &host->base->mask0);
host->cfg.name = host->name;
-#ifndef CONFIG_DM_MMC
host->cfg.ops = &arm_pl180_mmci_ops;
-#endif
+
/* TODO remove the duplicates */
host->cfg.host_caps = host->caps;
host->cfg.voltages = host->voltages;
@@ -393,20 +392,34 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host,
struct mmc **mmc)
*mmc = mmc_create(&host->cfg, host);
if (!*mmc)
return -1;
-
debug("registered mmc interface number is:%d\n",
(*mmc)->block_dev.devnum);
return 0;
}
+#endif
#ifdef CONFIG_DM_MMC
+static void arm_pl180_mmc_init(struct pl180_mmc_host *host)
+{
+ u32 sdi_u32;
+
+ writel(host->pwr_init, &host->base->power);
+ writel(host->clkdiv_init, &host->base->clock);
+ udelay(CLK_CHANGE_DELAY);
+
+ /* Disable mmc interrupts */
+ sdi_u32 = readl(&host->base->mask0) & ~SDI_MASK0_MASK;
+ writel(sdi_u32, &host->base->mask0);
+}
+
static int arm_pl180_mmc_probe(struct udevice *dev)
{
struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = &pdata->mmc;
- struct pl180_mmc_host *host = mmc->priv;
+ struct pl180_mmc_host *host = dev->priv;
+ struct mmc_config *cfg = &pdata->cfg;
struct clk clk;
u32 bus_width;
int ret;
@@ -421,27 +434,28 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
return ret;
}
- strcpy(host->name, "MMC");
host->pwr_init = INIT_PWR;
host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN |
SDI_CLKCR_HWFC_EN;
- host->voltages = VOLTAGE_WINDOW_SD;
- host->caps = 0;
host->clock_in = clk_get_rate(&clk);
- host->clock_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
- host->clock_max = dev_read_u32_default(dev, "max-frequency",
- MMC_CLOCK_MAX);
host->version2 = dev_get_driver_data(dev);
+ cfg->name = dev->name;
+ cfg->voltages = VOLTAGE_WINDOW_SD;
+ cfg->host_caps = 0;
+ cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
+ cfg->f_max = dev_read_u32_default(dev, "max-frequency", MMC_CLOCK_MAX);
+ cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
gpio_request_by_name(dev, "cd-gpios", 0, &host->cd_gpio, GPIOD_IS_IN);
bus_width = dev_read_u32_default(dev, "bus-width", 1);
switch (bus_width) {
case 8:
- host->caps |= MMC_MODE_8BIT;
+ cfg->host_caps |= MMC_MODE_8BIT;
/* Hosts capable of 8-bit transfers can also do 4 bits */
case 4:
- host->caps |= MMC_MODE_4BIT;
+ cfg->host_caps |= MMC_MODE_4BIT;
break;
case 1:
break;
@@ -449,19 +463,21 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
dev_err(dev, "Invalid bus-width value %u\n", bus_width);
}
- ret = arm_pl180_mmci_init(host, &mmc);
- if (ret) {
- dev_err(dev, "arm_pl180_mmci init failed\n");
- return ret;
- }
-
+ arm_pl180_mmc_init(host);
+ mmc->priv = host;
mmc->dev = dev;
- dev->priv = host;
upriv->mmc = mmc;
return 0;
}
+int arm_pl180_mmc_bind(struct udevice *dev)
+{
+ struct arm_pl180_mmc_plat *plat = dev_get_platdata(dev);
+
+ return mmc_bind(dev, &plat->mmc, &plat->cfg);
+}
+
static int dm_host_request(struct udevice *dev, struct mmc_cmd *cmd,
[U-Boot] [PATCH v4 5/9] mmc: arm_pl180_mmci: Add missing clk_free
Add missing clk_free() call in case of failure
when enabling the clock.
Signed-off-by: Patrice Chotard
Reviewed-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mmc/arm_pl180_mmci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index c4d94d102cc1..1cd780b3eec0 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -430,6 +430,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
ret = clk_enable(&clk);
if (ret) {
+ clk_free(&clk);
dev_err(dev, "failed to enable clock\n");
return ret;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] ARM: dts: stm32: remove cd-inverted for stm32f769-disco
As cd-inverted property is no more used by arm_pl180_mmci driver,
remove it. Update cd-gpios active level accordingly.
Reported-by: Tuomas Tynkkynen
Signed-off-by: Patrice Chotard
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32f769-disco.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31c213b..210be07ccc69 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -256,8 +256,7 @@
&sdio2 {
status = "okay";
- cd-gpios = <&gpioi 15 0>;
- cd-inverted;
+ cd-gpios = <&gpioi 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins_b>;
pinctrl-1 = <&sdio_pins_od_b>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/9] Add support of CONFIG_BLK for STM32Fx platforms
This series : - adds support of CONFIG_BLK flag to STM32Fx platforms - enables CONFIG_BLK flag for STM32Fx based boards - adds missing clk_free() call in error path Changes in v4: - update board DTS files to remove cd_inverted property and update cd-gpios active level Changes in v3: - remove usage of "cd_inverted" DT property in dm_mmc_getcd() Changes in v2: - replace devfdt_get_addr() by dev_read_addr() - re-introduce arm_pl180_mmc_ofdata_to_platdata() Patrice Chotard (9): configs: stm32f429-evaluation: Enable CONFIG_BLK configs: stm32f746-disco: Enable CONFIG_BLK configs: stm32f469-disco: Enable CONFIG_BLK mmc: arm_pl180_mmci: Update to support CONFIG_BLK mmc: arm_pl180_mmci: Add missing clk_free mmc: arm_pl180_mmci: Remove cd_inverted host's struct field ARM: dts: stm32: remove cd-inverted for stm32429i-eval ARM: dts: stm32: remove cd-inverted for stm32f769-disco ARM: dts: stm32: remove cd-inverted for stm32f746-disco arch/arm/dts/stm32429i-eval.dts| 3 +- arch/arm/dts/stm32f746-disco.dts | 3 +- arch/arm/dts/stm32f769-disco.dts | 3 +- configs/stm32f429-evaluation_defconfig | 1 - configs/stm32f469-discovery_defconfig | 1 - configs/stm32f746-disco_defconfig | 1 - drivers/mmc/arm_pl180_mmci.c | 73 +++--- drivers/mmc/arm_pl180_mmci.h | 1 - 8 files changed, 45 insertions(+), 41 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 7/9] ARM: dts: stm32: remove cd-inverted for stm32429i-eval
As cd-inverted property is no more used by arm_pl180_mmci driver,
remove it. Update cd-gpios active level accordingly.
Reported-by: Tuomas Tynkkynen
Signed-off-by: Patrice Chotard
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32429i-eval.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts
index c16594b7e433..f6753a4d1a1c 100644
--- a/arch/arm/dts/stm32429i-eval.dts
+++ b/arch/arm/dts/stm32429i-eval.dts
@@ -223,8 +223,7 @@
&sdio {
status = "okay";
vmmc-supply = <&mmc_vcard>;
- cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_HIGH>;
- cd-inverted;
+ cd-gpios = <&stmpegpio 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins>;
pinctrl-1 = <&sdio_pins_od>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 6/9] mmc: arm_pl180_mmci: Remove cd_inverted host's struct field
As platform uses GPIOs for card detection, it's
simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH)
in the gpio flags instead of using the cd-inverted
property.
Reported-by: Tuomas Tynkkynen
Signed-off-by: Patrice Chotard
---
Changes in v4:
- update board DTS files to remove cd_inverted property
and update cd-gpios active level
Changes in v3:
- remove usage of "cd_inverted" DT property in dm_mmc_getcd()
Changes in v2: None
drivers/mmc/arm_pl180_mmci.c | 5 +
drivers/mmc/arm_pl180_mmci.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 1cd780b3eec0..f71d79ecd6ba 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -499,11 +499,8 @@ static int dm_mmc_getcd(struct udevice *dev)
struct pl180_mmc_host *host = dev->priv;
int value = 1;
- if (dm_gpio_is_valid(&host->cd_gpio)) {
+ if (dm_gpio_is_valid(&host->cd_gpio))
value = dm_gpio_get_value(&host->cd_gpio);
- if (host->cd_inverted)
- return !value;
- }
return value;
}
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index 6b98db6cd978..36487be288b2 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -192,7 +192,6 @@ struct pl180_mmc_host {
struct mmc_config cfg;
#ifdef CONFIG_DM_MMC
struct gpio_desc cd_gpio;
- bool cd_inverted;
#endif
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 9/9] ARM: dts: stm32: remove cd-inverted for stm32f746-disco
As cd-inverted property is no more used by arm_pl180_mmci driver,
remove it. Update cd-gpios active level accordingly.
Reported-by: Tuomas Tynkkynen
Signed-off-by: Patrice Chotard
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32f746-disco.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index e47f762e54dc..187c94b99bfa 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -307,8 +307,7 @@
&sdio {
status = "okay";
- cd-gpios = <&gpioc 13 0>;
- cd-inverted;
+ cd-gpios = <&gpioc 13 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <&sdio_pins>;
pinctrl-1 = <&sdio_pins_od>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass wrote: > Hi, > > On 25 July 2018 at 03:48, Michal Simek wrote: > > > > On 25.7.2018 08:31, Chee, Tien Fong wrote: > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote: > > >> On 6.7.2018 10:28, tien.fong.c...@intel.com wrote: > > >>> > > >>> From: Tien Fong Chee > > >>> > [...] > > > >> > > >> Also that DT binding is quite weird and I don't think you will get > > >> ACK > > >> for this from device tree community at all. I think that calling via > > >> platdata and avoid DT nodes would be better way to go. > > > Why do you think DT binding is weird? The DT is designed based on Simon > > > proposal, and i believe following the rules in DTS spec. > > > There are some DT benefits with current design, i think someone may be > > > maintainer need to made the final decision on the design. > > > > It is software configuration in file which should mostly describe > > hardware and state for hardware configuration. > > > > Your fs_loader node is purely describe sw configuration which shouldn't > > be here. > > You have there run time configuration via variables. I think using only > > this way is enough. Default variables will match what you would want to > > add to DT. > > I think DT makes sense in the U-Boot context. > > We don't have a user space to handle policy decisions, and the > 'chosen' node is a good place to configure these common features. > > While you can argue that the partition or filesystem where an image > comes from is a software config, it is something that has to be > configured. It has impact on hardware too, since the FPGA has to get > its firmware from somewhere. We use the chosen node to specify the > UART to use, and this is no different. Again, we don't have user-space > config files in U-Boot. > > This argument comes up from time to time and I'd really like to put it > to bed for U-Boot. I understand that Linux has its own approach and > rules, but in some cases they serve U-Boot poorly. I want to second this as well. So long as we're using our prefix and we've thought through and discussed what we're trying to do here, it's OK to do things that might not be accepted for Linux. -- 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] [UBOOT PATCH v2] net: zynq_gem: convert to use livetree
On Tue, Jul 24, 2018 at 3:58 AM, Michal Simek wrote: > Hi, > > On 23.7.2018 07:48, Siva Durga Prasad Paladugu wrote: >> Hi Joe/Michal, >> >> Can you please take it up if it is fine. > > joe: Can you please take it via your tree? > There are some patches before this. Sure. The second series that you depend on has build issues, so this will be backed up behind that. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v2] net: zynq_gem: convert to use livetree
On Mon, Jul 16, 2018 at 7:55 AM, Siva Durga Prasad Paladugu wrote: > This patch updates the zynq gem driver to support livetree. > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Vipul Kumar Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
Am 25.07.2018 um 08:39 schrieb Michal Simek:
On 24.7.2018 21:56, Stefan Herbrechtsmeier wrote:
Am 24.07.2018 um 12:31 schrieb Michal Simek:
On 23.7.2018 20:42, Stefan Herbrechtsmeier wrote:
Am 23.07.2018 um 13:43 schrieb Michal Simek:
Reading registers for finding out output value is not working because
input value is read instead in case of tristate.
Reported-by: Stefan Herbrechtsmeier
Signed-off-by: Michal Simek
---
drivers/gpio/xilinx_gpio.c | 38
+-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
index 4da9ae114d87..9d3e9379d0e5 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
[snip]
+ priv->output_val[bank] = val;
+
return val;
};
@@ -441,6 +449,7 @@ static int xilinx_gpio_get_function(struct
udevice *dev, unsigned offset)
static int xilinx_gpio_get_value(struct udevice *dev, unsigned
offset)
{
struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
int val, ret;
u32 bank, pin;
@@ -451,7 +460,14 @@ static int xilinx_gpio_get_value(struct udevice
*dev, unsigned offset)
debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
(ulong)platdata->regs, offset, bank, pin);
- val = readl(&platdata->regs->gpiodata + bank * 2);
+ if (xilinx_gpio_get_function(dev, offset) == GPIOF_INPUT) {
+ debug("%s: Read input value from reg\n", __func__);
+ val = readl(&platdata->regs->gpiodata + bank * 2);
+ } else {
+ debug("%s: Read saved output value\n", __func__);
+ val = priv->output_val[bank];
+ }
Why you don't always read the data register? This doesn't work for three
state outputs.
In three state register every bit/pin is 0 - output, 1 input.
It means else part is output and I read saved value in priv->output_val.
If pin is setup as INPUT then I need read data reg to find out input
value.
Maybe you are commenting something else but please let me know if there
is any other bug.
What happen if I have an open drain output. Even if the gpio output is 1
the input could read a 0. You driver will always return the output value
and not the real input value. According to the picture in documentation
and my tests a data register write writes the output registers and a
data register read reads the input registers.
Why should the driver return the desired state (output register) and not
the real state (input register)?
First of all thanks for description.
I have another example where you have output only and you can't read
input because there is no wire.
Does you mean the all outputs configuration? Does this removes the
"gpio_io_i" signal from the IP?
Regarding open drain output.
Also this is what it is written in manual:
"AXI GPIO Data Register Description"
"For each I/O bit programmed as output:
• R: Reads to these bits always return zeros"
This must be a mistake in the documentation. I could read the input value.
The old driver and the Linux driver always read the register.
Additionally the documentation states that a write to an input doesn't work:
AXI GPIO Data Register.
For each I/O bit programmed as input:
• R: Reads value on the input pin.
• W: No effect.
However the Linux driver use the common sequence and sets first the data
register and afterwards the direction register.
If you want to support this configuration then you would have to change
pin to input and read it and revert it back. And all of this should be
done based on flag.
There is macro GPIO_OPEN_DRAIN which could be specified via DT binding.
Unfortunately this is for consumer not for generic listing. I can't also
see it in gpio_desc flags to be able to handle it in the driver.
That's why I have doubts if this is supported by any u-boot gpio driver
but I can be wrong.
I think the GPIO_OPEN_DRAIN is used to not set the output to 1. In our
case the open drain is transparent. The output has only two states
High-Z and 0. The input value of the FPGA output block is always 0 and
the tri-state input is connected to the output register of the GPIO
controller. The output of the FPGA input block is connected to the input
register of the GPIO controller.
Best regards
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
Hi Michal, Am 25.07.2018 um 08:07 schrieb Michal Simek: On 24.7.2018 21:39, Stefan Herbrechtsmeier wrote: Am 24.07.2018 um 10:37 schrieb Michal Simek: On 23.7.2018 20:29, Stefan Herbrechtsmeier wrote: Am 23.07.2018 um 11:08 schrieb Michal Simek: On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote: Am 12.07.2018 um 16:04 schrieb Michal Simek: There should be proper bank name setup to distiguish between different gpio drivers. Use dev->name for it. Signed-off-by: Michal Simek --- drivers/gpio/zynq_gpio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c index 26f69b1a713f..f793ee5754a8 100644 --- a/drivers/gpio/zynq_gpio.c +++ b/drivers/gpio/zynq_gpio.c @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev) struct zynq_gpio_privdata *priv = dev_get_priv(dev); struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev); + uc_priv->bank_name = dev->name; + if (priv->p_data) uc_priv->gpio_count = priv->p_data->ngpio; Does this not lead to ugly names because the gpio number is append to the bank_name? Have you check the "gpio status -a" output? Yes I was checking it. Names are composed together but also just numbers works as before. gpio@ff0a0: input: 0 [ ] gpio@ff0a1: input: 0 [ ] gpio@ff0a2: input: 0 [ ] gpio@ff0a3: input: 0 [ ] gpio@ff0a4: input: 0 [ ] gpio@ff0a5: input: 0 [ ] gpio@ff0a6: input: 0 [ ] gpio@ff0a7: input: 0 [ ] gpio@ff0a8: input: 0 [ ] gpio@ff0a9: input: 0 [ ] Do you think that this are meaningful names? It isn't possible to separate the device and pin number as well as it mix hex and decimal numbers. If you know better way how to setup a bank name please let me know but I need to distinguish ps gpio from pl one and for pl we need to know the address. I know the use case. A lot of drivers use the bank_name from the device tree, some drivers append an underscore to the bank name and others add the req_seq of the device to an alphabetic character. Other drivers use the gpio-bank-name from the device tree. I can't see this property inside Linux kernel. If this has been reviewed by dt guys please let me know. This property is only used by u-boot. I think it isn't needed by the Linux kernel. I am happy to use consistent solution but what's that? Consistent solution between what? all drivers. Name should be composed consistently among all drivers. It means drivers shouldn't add additional "_" in driver code for example. Mixing name with hex and int is not nice but adding "_" or something else is just a pain in driver code. If this is done in core I am fine with that but adding this code to all drivers don't look like generic solution at all. Normally the bank name is an alphabetic character or string. Maybe we could add the device name to the gpio_lookup_name function and add an additional optional device name parameter to the gpio command. Using additional u-boot property is not good too. I have mentioned in "gpio: xilinx: Convert driver to DM" (sha1:10441ec9224d0d269dc512819a32c0785a6338d3) that uc-priv->name is completely unused. Maybe this should be dev->name and bank_name should be really used for banks. Isn't the uc-priv->name used for the label of the request? Last time when I looked at it and I didn't see this name listed anywhere in output. Then in gpio status -a can be Device gpio@a0001000: Bank: ... but not sure how gpio commands will work to address exact pin from prompt. Because this is normally working gpio toggle gpio@a00010001 With an optional device name this would be: gpio toggle gpio@a0001000 1 Alternative the gpio command could support the requested labels: gpio toggle second-gpio I am open to see this solution. Feel free to invest your time support this but I have no time for that. What does this mean? I understand that you don't have the time to develop a new common solution. But the discussion disappoints me. You misuse the bank name in a poor way and decline alternative solutions with additional requirements even if they are already used in u-boot. The name "gpio@a000100011" for pin 11 of the device gpio@a0001000 isn't consistent between the u-boot drivers nor is the name used in Linux. A bank-name from the device tree is used by several u-boot drivers even if it isn't consistent between the drivers. Regards Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] phy: Break include cycle
Because some phy wants to export some functions [1], export.h was
including the whole phy subsystem which pulls in lots of stuff that
causes some ordering and redefinition issues. Split out the only part
that is actually needed in export.h and include it there and in phy.h.
[1] commit 95279315076c ("board/ls2085rdb: Export functions for
standalone AQ FW load apps")
Signed-off-by: Joe Hershberger
---
include/exports.h | 3 +--
include/phy.h | 55 +
include/phy_interface.h | 65 +
3 files changed, 67 insertions(+), 56 deletions(-)
create mode 100644 include/phy_interface.h
diff --git a/include/exports.h b/include/exports.h
index ebe81d9..a4b862f 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -3,8 +3,7 @@
#ifndef __ASSEMBLY__
#ifdef CONFIG_PHY_AQUANTIA
-#include
-#include
+#include
#endif
struct spi_slave;
diff --git a/include/phy.h b/include/phy.h
index 7c3fc5c..09645a8 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#define PHY_FIXED_ID 0xa5a55a5a
@@ -48,60 +49,6 @@
#endif
-typedef enum {
- PHY_INTERFACE_MODE_MII,
- PHY_INTERFACE_MODE_GMII,
- PHY_INTERFACE_MODE_SGMII,
- PHY_INTERFACE_MODE_SGMII_2500,
- PHY_INTERFACE_MODE_QSGMII,
- PHY_INTERFACE_MODE_TBI,
- PHY_INTERFACE_MODE_RMII,
- PHY_INTERFACE_MODE_RGMII,
- PHY_INTERFACE_MODE_RGMII_ID,
- PHY_INTERFACE_MODE_RGMII_RXID,
- PHY_INTERFACE_MODE_RGMII_TXID,
- PHY_INTERFACE_MODE_RTBI,
- PHY_INTERFACE_MODE_XGMII,
- PHY_INTERFACE_MODE_XAUI,
- PHY_INTERFACE_MODE_RXAUI,
- PHY_INTERFACE_MODE_SFI,
- PHY_INTERFACE_MODE_INTERNAL,
- PHY_INTERFACE_MODE_NONE,/* Must be last */
-
- PHY_INTERFACE_MODE_COUNT,
-} phy_interface_t;
-
-static const char *phy_interface_strings[] = {
- [PHY_INTERFACE_MODE_MII]= "mii",
- [PHY_INTERFACE_MODE_GMII] = "gmii",
- [PHY_INTERFACE_MODE_SGMII] = "sgmii",
- [PHY_INTERFACE_MODE_SGMII_2500] = "sgmii-2500",
- [PHY_INTERFACE_MODE_QSGMII] = "qsgmii",
- [PHY_INTERFACE_MODE_TBI]= "tbi",
- [PHY_INTERFACE_MODE_RMII] = "rmii",
- [PHY_INTERFACE_MODE_RGMII] = "rgmii",
- [PHY_INTERFACE_MODE_RGMII_ID] = "rgmii-id",
- [PHY_INTERFACE_MODE_RGMII_RXID] = "rgmii-rxid",
- [PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
- [PHY_INTERFACE_MODE_RTBI] = "rtbi",
- [PHY_INTERFACE_MODE_XGMII] = "xgmii",
- [PHY_INTERFACE_MODE_XAUI] = "xaui",
- [PHY_INTERFACE_MODE_RXAUI] = "rxaui",
- [PHY_INTERFACE_MODE_SFI]= "sfi",
- [PHY_INTERFACE_MODE_INTERNAL] = "internal",
- [PHY_INTERFACE_MODE_NONE] = "",
-};
-
-static inline const char *phy_string_for_interface(phy_interface_t i)
-{
- /* Default to unknown */
- if (i > PHY_INTERFACE_MODE_NONE)
- i = PHY_INTERFACE_MODE_NONE;
-
- return phy_interface_strings[i];
-}
-
-
struct phy_device;
#define MDIO_NAME_LEN 32
diff --git a/include/phy_interface.h b/include/phy_interface.h
new file mode 100644
index 000..0760d65
--- /dev/null
+++ b/include/phy_interface.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Andy Fleming
+ *
+ * This file pretty much stolen from Linux's mii.h/ethtool.h/phy.h
+ */
+
+#ifndef _PHY_INTERFACE_H
+#define _PHY_INTERFACE_H
+
+typedef enum {
+ PHY_INTERFACE_MODE_MII,
+ PHY_INTERFACE_MODE_GMII,
+ PHY_INTERFACE_MODE_SGMII,
+ PHY_INTERFACE_MODE_SGMII_2500,
+ PHY_INTERFACE_MODE_QSGMII,
+ PHY_INTERFACE_MODE_TBI,
+ PHY_INTERFACE_MODE_RMII,
+ PHY_INTERFACE_MODE_RGMII,
+ PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
+ PHY_INTERFACE_MODE_RTBI,
+ PHY_INTERFACE_MODE_XGMII,
+ PHY_INTERFACE_MODE_XAUI,
+ PHY_INTERFACE_MODE_RXAUI,
+ PHY_INTERFACE_MODE_SFI,
+ PHY_INTERFACE_MODE_INTERNAL,
+ PHY_INTERFACE_MODE_NONE,/* Must be last */
+
+ PHY_INTERFACE_MODE_COUNT,
+} phy_interface_t;
+
+static const char * const phy_interface_strings[] = {
+ [PHY_INTERFACE_MODE_MII]= "mii",
+ [PHY_INTERFACE_MODE_GMII] = "gmii",
+ [PHY_INTERFACE_MODE_SGMII] = "sgmii",
+ [PHY_INTERFACE_MODE_SGMII_2500] = "sgmii-2500",
+ [PHY_INTERFACE_MODE_QSGMII] = "qsgmii",
+ [PHY_INTERFACE_MODE_TBI]= "tbi",
+ [PHY_INTERFACE_MODE_RMII] = "rmii",
+ [PHY_INTERFACE_MOD
[U-Boot] [PATCH 1/3] arm: Prevent redefinition error in fsl-layerscape
The include/phy.h will start including dm.h, which pulls in linux/compat.h after the attempted redefinition in arch/arm/include/asm/armv8/mmu.h, so move this include to allow redefinition. Signed-off-by: Joe Hershberger --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index 40c2c3a..052e070 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -18,7 +19,6 @@ #include #include #include -#include #include #ifdef CONFIG_FSL_ESDHC #include -- 1.7.11.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] net: phy: Clean up includes of common.h
We want to be able to include some other system headers in phy.h but that requires us to have included common.h in the top-level first. Also, common.h includes config.h as the first thing it does, so don't include it directly. Seried-cc: ti Signed-off-by: Joe Hershberger --- drivers/net/phy/atheros.c| 1 + drivers/net/phy/broadcom.c | 1 - drivers/net/phy/davicom.c| 1 + drivers/net/phy/generic_10g.c| 2 -- drivers/net/phy/lxt.c| 1 + drivers/net/phy/marvell.c| 1 - drivers/net/phy/micrel_ksz8xxx.c | 1 - drivers/net/phy/micrel_ksz90x1.c | 2 -- drivers/net/phy/natsemi.c| 1 + drivers/net/phy/phy.c| 2 -- drivers/net/phy/realtek.c| 1 - drivers/net/phy/smsc.c | 1 + drivers/net/phy/teranetics.c | 1 - drivers/net/phy/vitesse.c| 1 + 14 files changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 79f68af..3783d15 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -5,6 +5,7 @@ * Copyright 2011, 2013 Freescale Semiconductor, Inc. * author Andy Fleming */ +#include #include #define AR803x_PHY_DEBUG_ADDR_REG 0x1d diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c index 202e3dd..3399fd2 100644 --- a/drivers/net/phy/broadcom.c +++ b/drivers/net/phy/broadcom.c @@ -5,7 +5,6 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ -#include #include #include diff --git a/drivers/net/phy/davicom.c b/drivers/net/phy/davicom.c index 27c7788..4666497 100644 --- a/drivers/net/phy/davicom.c +++ b/drivers/net/phy/davicom.c @@ -5,6 +5,7 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ +#include #include #define MIIM_DM9161_SCR0x10 diff --git a/drivers/net/phy/generic_10g.c b/drivers/net/phy/generic_10g.c index 1024d7d..b4384e1 100644 --- a/drivers/net/phy/generic_10g.c +++ b/drivers/net/phy/generic_10g.c @@ -7,8 +7,6 @@ * * Based loosely off of Linux's PHY Lib */ - -#include #include #include #include diff --git a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c index 5942664..2618deb 100644 --- a/drivers/net/phy/lxt.c +++ b/drivers/net/phy/lxt.c @@ -5,6 +5,7 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ +#include #include /* LXT971 Status 2 registers */ diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index 436ff57..efbbd31 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -5,7 +5,6 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ -#include #include #include #include diff --git a/drivers/net/phy/micrel_ksz8xxx.c b/drivers/net/phy/micrel_ksz8xxx.c index c70c036..3411150 100644 --- a/drivers/net/phy/micrel_ksz8xxx.c +++ b/drivers/net/phy/micrel_ksz8xxx.c @@ -6,7 +6,6 @@ * author Andy Fleming * (C) 2012 NetModule AG, David Andrey, added KSZ9031 */ -#include #include #include #include diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index 5462532..3951535 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -8,8 +8,6 @@ * (C) Copyright 2017 Adaptrum, Inc. * Written by Alexandru Gagniuc for Adaptrum, Inc. */ - -#include #include #include #include diff --git a/drivers/net/phy/natsemi.c b/drivers/net/phy/natsemi.c index 05c7e7c..efde457 100644 --- a/drivers/net/phy/natsemi.c +++ b/drivers/net/phy/natsemi.c @@ -5,6 +5,7 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ +#include #include /* NatSemi DP83630 */ diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 4e610bf..a88c13a 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -7,8 +7,6 @@ * * Based loosely off of Linux's PHY Lib */ - -#include #include #include #include diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c index b0867af..b3e6578 100644 --- a/drivers/net/phy/realtek.c +++ b/drivers/net/phy/realtek.c @@ -6,7 +6,6 @@ * author Andy Fleming * Copyright 2016 Karsten Merker */ -#include #include #include #include diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c index 2f92957..7740a25 100644 --- a/drivers/net/phy/smsc.c +++ b/drivers/net/phy/smsc.c @@ -9,6 +9,7 @@ * Some code copied from linux kernel * Copyright (c) 2006 Herbert Valerio Riedel */ +#include #include /* This code does not check the partner abilities. */ diff --git a/drivers/net/phy/teranetics.c b/drivers/net/phy/teranetics.c index d674e8f..49d6a1a 100644 --- a/drivers/net/phy/teranetics.c +++ b/drivers/net/phy/teranetics.c @@ -5,7 +5,6 @@ * Copyright 2010-2011 Freescale Semiconductor, Inc. * author Andy Fleming */ -#include #include #include diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index 9df4a3f
Re: [U-Boot] [PATCH 1/6] driver: net: fsl-mc: modify the label name
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote: > The goto label name is misspelled it should be DPMAC not DPAMC > > Signed-off-by: Pankaj Bansal Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/6] driver: net: fsl-mc: remove unused strcture elements
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote:
> The phydev structure is present in both ldpaa_eth_priv and
> wriop_dpmac_info. the phydev in wriop_dpmac_info is not being used
>
> As the phydev is created based on phy_addr and bus members of
> wriop_dpmac_info, it is appropriate to keep phydev in wriop_dpmac_info.
>
> Also phy_regs is not being used, therefore remove it
>
> Signed-off-by: Pankaj Bansal
One nit below, but...
Acked-by: Joe Hershberger
If we don't need another version of this series, I'll fix it up when
it's applied.
> ---
> drivers/net/ldpaa_eth/ldpaa_eth.c | 57 +++
> drivers/net/ldpaa_eth/ldpaa_eth.h | 1 -
> drivers/net/ldpaa_eth/ldpaa_wriop.c | 2 +
> include/fsl-mc/ldpaa_wriop.h| 1 -
> 4 files changed, 34 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 18bc05790a..fbc724fc33 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -35,7 +35,7 @@ static int init_phy(struct eth_device *dev)
> return -1;
> }
>
> - priv->phydev = phydev;
> + wriop_set_phy_dev(priv->dpmac_id, phydev);
>
> return phy_config(phydev);
> }
> @@ -388,6 +388,7 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> struct mii_dev *bus;
> phy_interface_t enet_if;
> struct dpni_queue d_queue;
> + struct phy_device *phydev = NULL;
>
> if (net_dev->state == ETH_STATE_ACTIVE)
> return 0;
> @@ -408,38 +409,41 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> goto err_dpmac_setup;
>
> #ifdef CONFIG_PHYLIB
> - if (priv->phydev) {
> - err = phy_startup(priv->phydev);
> + phydev = wriop_get_phy_dev(priv->dpmac_id);
> + if (phydev) {
> + err = phy_startup(phydev);
> if (err) {
> printf("%s: Could not initialize\n",
> - priv->phydev->dev->name);
> + phydev->dev->name);
> goto err_dpmac_bind;
> }
> }
> #else
> - priv->phydev = (struct phy_device *)malloc(sizeof(struct phy_device));
> - memset(priv->phydev, 0, sizeof(struct phy_device));
> + phydev = (struct phy_device *)malloc(sizeof(struct phy_device));
> + memset(phydev, 0, sizeof(struct phy_device));
> + wriop_set_phy_dev(priv->dpmac_id, phydev);
>
> - priv->phydev->speed = SPEED_1000;
> - priv->phydev->link = 1;
> - priv->phydev->duplex = DUPLEX_FULL;
> + phydev->speed = SPEED_1000;
> + phydev->link = 1;
> + phydev->duplex = DUPLEX_FULL;
> #endif
>
> bus = wriop_get_mdio(priv->dpmac_id);
> enet_if = wriop_get_enet_if(priv->dpmac_id);
> if ((bus == NULL) &&
> (enet_if == PHY_INTERFACE_MODE_XGMII)) {
> - priv->phydev = (struct phy_device *)
> + phydev = (struct phy_device *)
> malloc(sizeof(struct phy_device));
> - memset(priv->phydev, 0, sizeof(struct phy_device));
> + memset(phydev, 0, sizeof(struct phy_device));
> + wriop_set_phy_dev(priv->dpmac_id, phydev);
>
> - priv->phydev->speed = SPEED_1;
> - priv->phydev->link = 1;
> - priv->phydev->duplex = DUPLEX_FULL;
> + phydev->speed = SPEED_1;
> + phydev->link = 1;
> + phydev->duplex = DUPLEX_FULL;
> }
>
> - if (!priv->phydev->link) {
> - printf("%s: No link.\n", priv->phydev->dev->name);
> + if (!phydev->link) {
> + printf("%s: No link.\n", phydev->dev->name);
> err = -1;
> goto err_dpmac_bind;
> }
> @@ -476,17 +480,17 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> return err;
> }
>
> - dpmac_link_state.rate = priv->phydev->speed;
> + dpmac_link_state.rate = phydev->speed;
>
> - if (priv->phydev->autoneg == AUTONEG_DISABLE)
> + if (phydev->autoneg == AUTONEG_DISABLE)
> dpmac_link_state.options &= ~DPMAC_LINK_OPT_AUTONEG;
> else
> dpmac_link_state.options |= DPMAC_LINK_OPT_AUTONEG;
>
> - if (priv->phydev->duplex == DUPLEX_HALF)
> + if (phydev->duplex == DUPLEX_HALF)
> dpmac_link_state.options |= DPMAC_LINK_OPT_HALF_DUPLEX;
>
> - dpmac_link_state.up = priv->phydev->link;
> + dpmac_link_state.up = phydev->link;
>
> err = dpmac_set_link_state(dflt_mc_io, MC_CMD_NO_FLAGS,
> priv->dpmac_handle, &dpmac_link_state);
> @@ -530,7 +534,7 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> goto err_qdid;
> }
>
>
Re: [U-Boot] [PATCH 3/6] driver: net: fsl-mc: fix error handing in init_phy
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote:
> if an error occurs during init_phy, we should free the phydev structure
> which has been allocated by phy_connect.
>
> Signed-off-by: Pankaj Bansal
> ---
> drivers/net/ldpaa_eth/ldpaa_eth.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index fbc724fc33..8fcb948ee8 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -23,6 +23,7 @@ static int init_phy(struct eth_device *dev)
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)dev->priv;
> struct phy_device *phydev = NULL;
> struct mii_dev *bus;
> + int ret;
>
> bus = wriop_get_mdio(priv->dpmac_id);
> if (bus == NULL)
> @@ -37,7 +38,15 @@ static int init_phy(struct eth_device *dev)
>
> wriop_set_phy_dev(priv->dpmac_id, phydev);
>
> - return phy_config(phydev);
> + ret = phy_config(phydev);
> +
> + if (ret) {
> + free(phydev);
> + phydev = NULL;
This seems odd. It's a local variable... why not just pass NULL into
wriop_set_phy_dev()? That seems clearer.
> + wriop_set_phy_dev(priv->dpmac_id, phydev);
> + }
> +
> + return ret;
> }
> #endif
>
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] driver: net: fsl-mc: Modify the dpmac link detection method
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote:
> when there is no phy present for a dpmac, a dummy phy device is created.
> when we move to multiple phy method, we need to create as many dummy phy
> devices.
>
> Change this method so that we don't need to create dummy phy devices.
> We always report linkup if no phy is present.
>
> Signed-off-by: Pankaj Bansal
> ---
> drivers/net/ldpaa_eth/ldpaa_eth.c | 121 +---
> 1 file changed, 58 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 8fcb948ee8..d2a6d90f18 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -386,6 +386,60 @@ error:
> return err;
> }
>
> +static int ldpaa_get_dpmac_state(struct ldpaa_eth_priv *priv,
> +struct dpmac_link_state *state)
> +{
> + struct phy_device *phydev = NULL;
> + phy_interface_t enet_if;
> + int err;
> +
> + /* let's start off with maximum capabilities
> +*/
> + enet_if = wriop_get_enet_if(priv->dpmac_id);
> + switch (enet_if) {
> + case PHY_INTERFACE_MODE_XGMII:
> + state->rate = SPEED_1;
> + break;
> + default:
> + state->rate = SPEED_1000;
> + break;
> + }
> + state->up = 1;
> +
> +#ifdef CONFIG_PHYLIB
> + state->options |= DPMAC_LINK_OPT_AUTONEG;
> +
> + phydev = wriop_get_phy_dev(priv->dpmac_id);
> + if (phydev) {
> + err = phy_startup(phydev);
> + if (err) {
> + printf("%s: Could not initialize\n",
> phydev->dev->name);
> + state->up = 0;
> + }
> + if (phydev->link == 1) {
Just "phydev->link"
> + state->rate = state->rate < phydev->speed ?
> + state->rate : phydev->speed;
MIN(state->rate, phydev->speed);
> + if (!phydev->duplex)
> + state->options |= DPMAC_LINK_OPT_HALF_DUPLEX;
> + if (!phydev->autoneg)
> + state->options &= ~DPMAC_LINK_OPT_AUTONEG;
> + } else {
> + state->up = 0;
> + }
> + }
> +#endif
> + if (!phydev)
> + state->options &= ~DPMAC_LINK_OPT_AUTONEG;
> +
> + if (state->up == 0) {
> + state->rate = 0;
> + state->options = 0;
> + return -1;
return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> static int ldpaa_eth_open(struct eth_device *net_dev, bd_t *bd)
> {
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
> @@ -394,10 +448,7 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> struct dpni_link_state link_state;
> #endif
> int err = 0;
> - struct mii_dev *bus;
> - phy_interface_t enet_if;
> struct dpni_queue d_queue;
> - struct phy_device *phydev = NULL;
>
> if (net_dev->state == ETH_STATE_ACTIVE)
> return 0;
> @@ -417,45 +468,9 @@ static int ldpaa_eth_open(struct eth_device *net_dev,
> bd_t *bd)
> if (err < 0)
> goto err_dpmac_setup;
>
> -#ifdef CONFIG_PHYLIB
> - phydev = wriop_get_phy_dev(priv->dpmac_id);
> - if (phydev) {
> - err = phy_startup(phydev);
> - if (err) {
> - printf("%s: Could not initialize\n",
> - phydev->dev->name);
> - goto err_dpmac_bind;
> - }
> - }
> -#else
> - phydev = (struct phy_device *)malloc(sizeof(struct phy_device));
> - memset(phydev, 0, sizeof(struct phy_device));
> - wriop_set_phy_dev(priv->dpmac_id, phydev);
> -
> - phydev->speed = SPEED_1000;
> - phydev->link = 1;
> - phydev->duplex = DUPLEX_FULL;
> -#endif
> -
> - bus = wriop_get_mdio(priv->dpmac_id);
> - enet_if = wriop_get_enet_if(priv->dpmac_id);
> - if ((bus == NULL) &&
> - (enet_if == PHY_INTERFACE_MODE_XGMII)) {
> - phydev = (struct phy_device *)
> - malloc(sizeof(struct phy_device));
> - memset(phydev, 0, sizeof(struct phy_device));
> - wriop_set_phy_dev(priv->dpmac_id, phydev);
> -
> - phydev->speed = SPEED_1;
> - phydev->link = 1;
> - phydev->duplex = DUPLEX_FULL;
> - }
> -
> - if (!phydev->link) {
> - printf("%s: No link.\n", phydev->dev->name);
> - err = -1;
> + err = ldpaa_get_dpmac_state(priv, &dpmac_link_state);
> + if (err < 0)
> goto err_dpmac_bind;
> - }
>
> /* DPMAC binding DPNI */
> err = ldpaa_dpmac_bind(priv);
> @@ -489,18 +504,
Re: [U-Boot] [PATCH 5/6] driver: net: fsl-mc: initialize dpmac irrespective of phy
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote: > The dpmac initalization should not depend on phy. > As the phy is not necessary to be present for dpmac to function. > Therefore, remove dpmac initialization dependency from phy. > > Signed-off-by: Pankaj Bansal Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board
On Sat, 2018-07-21 at 16:23 +0200, Dr. Philipp Tomsich wrote: > Ezequiel, > > This series breaks the build (see > https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406351695). > Did you test with Travis prior to submitting? > No, I haven't. It's quite odd, as the README patch just adds some documentation. I am having a hard time figuring out how could it break the build, and I do not see any logs in the travis-ci link either. Any ideas? > When you revise, I’d also prefer a ‘rockchip:’ and a ‘board:’ tag over the > ARM tag … > OK, I will. > Thanks, > Philipp. > > > > On 20 Jul 2018, at 19:30, Philipp Tomsich > > wrote: > > > > > This commit adds support for RK3399 Ficus board, > > > aka ROCK960 Enterprise Edition. > > > > > > Following peripherals are tested and known to work: > > > * Gigabit Ethernet > > > * USB 2.0 > > > * MMC > > > > > > Signed-off-by: Ezequiel Garcia > > > Reviewed-by: Simon Glass > > > Reviewed-by: Philipp Tomsich > > > --- > > > arch/arm/dts/Makefile| 1 + > > > arch/arm/dts/rk3399-ficus.dts| 564 +++ > > > board/rockchip/evb_rk3399/README | 2 + > > > configs/ficus-rk3399_defconfig | 71 > > > 4 files changed, 638 insertions(+) > > > create mode 100644 arch/arm/dts/rk3399-ficus.dts > > > create mode 100644 configs/ficus-rk3399_defconfig > > > > > > > Acked-by: Philipp Tomsich > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] driver: net: fsl-mc: Add support of multiple phys for dpmac
On Fri, Jul 13, 2018 at 9:40 AM, Pankaj Bansal wrote:
> Till now we have had cases where we had one phy device per dpmac.
> Now, with the upcoming products (LX2160AQDS), we have cases, where there
> are sometimes two phy devices for one dpmac. One phy for TX lanes and
> one phy for RX lanes. to handle such cases, add the support for multiple
> phys in ethernet driver. The ethernet link is up if all the phy devices
> connected to one dpmac report link up. also the link capabilities are
> limited by the weakest phy device.
>
> i.e. say if there are two phys for one dpmac. one operates at 10G without
> autoneg and other operate at 1G with autoneg. Then the ethernet interface
> will operate at 1G without autoneg.
>
> Signed-off-by: Pankaj Bansal
> ---
> board/freescale/ls1088a/eth_ls1088aqds.c | 18 ++---
> board/freescale/ls1088a/eth_ls1088ardb.c | 21 +++---
> board/freescale/ls2080aqds/eth.c | 26 +++
> board/freescale/ls2080ardb/eth_ls2080rdb.c | 24 +++
> drivers/net/ldpaa_eth/ldpaa_eth.c | 71 ++--
> drivers/net/ldpaa_eth/ldpaa_wriop.c| 51 ++
> include/fsl-mc/ldpaa_wriop.h | 21 +++---
> 7 files changed, 147 insertions(+), 85 deletions(-)
>
> diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c
> b/board/freescale/ls1088a/eth_ls1088aqds.c
> index 40b1a0e631..f16b78cf03 100644
> --- a/board/freescale/ls1088a/eth_ls1088aqds.c
> +++ b/board/freescale/ls1088a/eth_ls1088aqds.c
> @@ -487,16 +487,16 @@ void ls1088a_handle_phy_interface_sgmii(int dpmac_id)
> case 0x3A:
> switch (dpmac_id) {
> case 1:
> - wriop_set_phy_address(dpmac_id, riser_phy_addr[1]);
> + wriop_set_phy_address(dpmac_id, 0, riser_phy_addr[1]);
> break;
> case 2:
> - wriop_set_phy_address(dpmac_id, riser_phy_addr[0]);
> + wriop_set_phy_address(dpmac_id, 0, riser_phy_addr[0]);
> break;
> case 3:
> - wriop_set_phy_address(dpmac_id, riser_phy_addr[3]);
> + wriop_set_phy_address(dpmac_id, 0, riser_phy_addr[3]);
> break;
> case 7:
> - wriop_set_phy_address(dpmac_id, riser_phy_addr[2]);
> + wriop_set_phy_address(dpmac_id, 0, riser_phy_addr[2]);
> break;
> default:
> printf("WRIOP: Wrong DPMAC%d set to SGMII", dpmac_id);
> @@ -532,13 +532,13 @@ void ls1088a_handle_phy_interface_qsgmii(int dpmac_id)
> case 4:
> case 5:
> case 6:
> - wriop_set_phy_address(dpmac_id, dpmac_id + 9);
> + wriop_set_phy_address(dpmac_id, 0, dpmac_id + 9);
> break;
> case 7:
> case 8:
> case 9:
> case 10:
> - wriop_set_phy_address(dpmac_id, dpmac_id + 1);
> + wriop_set_phy_address(dpmac_id, 0, dpmac_id + 1);
> break;
> }
>
> @@ -567,7 +567,7 @@ void ls1088a_handle_phy_interface_xsgmii(int i)
> case 0x15:
> case 0x1D:
> case 0x1E:
> - wriop_set_phy_address(i, i + 26);
> + wriop_set_phy_address(i, 0, i + 26);
> ls1088a_qds_enable_SFP_TX(SFP_TX);
> break;
> default:
> @@ -590,13 +590,13 @@ static void ls1088a_handle_phy_interface_rgmii(int
> dpmac_id)
>
> switch (dpmac_id) {
> case 4:
> - wriop_set_phy_address(dpmac_id, RGMII_PHY1_ADDR);
> + wriop_set_phy_address(dpmac_id, 0, RGMII_PHY1_ADDR);
> dpmac_info[dpmac_id].board_mux = EMI1_RGMII1;
> bus = mii_dev_for_muxval(EMI1_RGMII1);
> wriop_set_mdio(dpmac_id, bus);
> break;
> case 5:
> - wriop_set_phy_address(dpmac_id, RGMII_PHY2_ADDR);
> + wriop_set_phy_address(dpmac_id, 0, RGMII_PHY2_ADDR);
> dpmac_info[dpmac_id].board_mux = EMI1_RGMII2;
> bus = mii_dev_for_muxval(EMI1_RGMII2);
> wriop_set_mdio(dpmac_id, bus);
> diff --git a/board/freescale/ls1088a/eth_ls1088ardb.c
> b/board/freescale/ls1088a/eth_ls1088ardb.c
> index 418f362e9a..a2b52a879b 100644
> --- a/board/freescale/ls1088a/eth_ls1088ardb.c
> +++ b/board/freescale/ls1088a/eth_ls1088ardb.c
> @@ -55,16 +55,17 @@ int board_eth_init(bd_t *bis)
> * a MAC has no PHY address, we give a PHY address to XFI
> * MAC error.
> */
> - wriop_set_phy_address(WRIOP1_DPMAC1, 0x0a);
> - wriop_set_phy_address(WRIOP1_DPMAC2, AQ_PHY_ADDR1);
> - wriop_set_phy_address(WRIOP1_DPMAC3, QSGMII1
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 07/24/2018 10:58 PM, Michal Simek wrote:
> On 24.7.2018 18:26, York Sun wrote:
>> On 07/24/2018 06:07 AM, Michal Simek wrote:
>>> There is no reason to limit gzip usage only for OS_BOOT and kernel image
>>> type.
>>>
>>> Signed-off-by: Michal Simek
>>> ---
>>>
>>> common/spl/spl_fit.c | 5 +
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>>> index 9eabb1c1058b..dbf5ac33a845 100644
>>> --- a/common/spl/spl_fit.c
>>> +++ b/common/spl/spl_fit.c
>>> @@ -257,10 +257,7 @@ static int spl_load_fit_image(struct spl_load_info
>>> *info, ulong sector,
>>> board_fit_image_post_process(&src, &length);
>>> #endif
>>>
>>> - if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
>>> - IS_ENABLED(CONFIG_SPL_GZIP) &&
>>> - image_comp == IH_COMP_GZIP &&
>>> - type == IH_TYPE_KERNEL) {
>>> + if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
>>> size = length;
>>> if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
>>>src, &size)) {
>>>
>>
>> This will uncompress ramdisk unnecessarily.
>
> Can you please share your its fragment? Also is there any other image
> which should be exclude?
I used it for falcon boot. I guess the executable image should have "entry". In
my setup, only kernel image has "entry". Here is my its file.
/dts-v1/;
/ {
description = "Image file for the LS1046A Linux Kernel";
#address-cells = <1>;
images {
kernel@1 {
description = "ARM64 Linux kernel";
data = /incbin/("./arch/arm64/boot/Image.gz");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x8008>;
entry = <0x8008>;
};
fdt@1 {
description = "Flattened Device Tree blob";
data = /incbin/("./fsl-ls1046ardb.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
load = <0x9000>;
};
ramdisk@1 {
description = "Buildroot initramfs";
data = /incbin/("./rootfs.cpio.gz");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0xa000>;
};
};
configurations {
default = "config@1";
config@1 {
description = "Boot Linux kernel";
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
};
};
};
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board
Ezequiel, > On 25 Jul 2018, at 22:31, Ezequiel Garcia wrote: > > On Sat, 2018-07-21 at 16:23 +0200, Dr. Philipp Tomsich wrote: >> Ezequiel, >> >> This series breaks the build (see >> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406351695). >> Did you test with Travis prior to submitting? >> > > No, I haven't. It's quite odd, as the README patch just adds some > documentation. I responded to this mail, as there’s no cover letter. It’s the series breaking the build, not the README change. > I am having a hard time figuring out how could it break the build, > and I do not see any logs in the travis-ci link either. Does the direct link to the line with the error work for you: https://travis-ci.org/ptomsich/u-boot-rockchip/jobs/406351815#L1330 If not, I’ll have to copy this into a mail manually... > > Any ideas? > >> When you revise, I’d also prefer a ‘rockchip:’ and a ‘board:’ tag over the >> ARM tag … >> > > OK, I will. > >> Thanks, >> Philipp. >> >> >>> On 20 Jul 2018, at 19:30, Philipp Tomsich >>> wrote: >>> This commit adds support for RK3399 Ficus board, aka ROCK960 Enterprise Edition. Following peripherals are tested and known to work: * Gigabit Ethernet * USB 2.0 * MMC Signed-off-by: Ezequiel Garcia Reviewed-by: Simon Glass Reviewed-by: Philipp Tomsich --- arch/arm/dts/Makefile| 1 + arch/arm/dts/rk3399-ficus.dts| 564 +++ board/rockchip/evb_rk3399/README | 2 + configs/ficus-rk3399_defconfig | 71 4 files changed, 638 insertions(+) create mode 100644 arch/arm/dts/rk3399-ficus.dts create mode 100644 configs/ficus-rk3399_defconfig >>> >>> Acked-by: Philipp Tomsich >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot >> >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: socfpga: Add support for the ReflexCES R329 board
On 07/24/2018 07:21 PM, Xavier Ruppen wrote:
> The ReflexCES PCIe carrier board Arria 10 SoC SoM (R329) provides
> access to all the features of the Arria 10 SoC SoM (R315) (Ethernet,
> OTG USB, Transceivers, UART) and adds further functions, including SFP+
> connectors, PCIe x8 Gen3, USB3.0 and a wifi interface.
>
> No fpga portion is provided in fit_spl_fpga.its as MSEL is hardwired on
> this board. Thus, a bitstream is loaded before booting by using the EPCQ.
> It is possible to load a bitstream from the HPS (packaged in the .sfp file)
> but a small hardware mod on the MSEL lines is required (tested and works).
>
> Signed-off-by: Xavier Ruppen
> Cc: Marek Vasut
> Cc: Chin Liang See
> Cc: Dinh Nguyen
> ---
>
> This patch was created and tested against u-boot-socfpga/arria10_sdmmc.
Can it be based on u-boot/master and does it work ? I am not accepting
patches on top of these random branches.
> The handoff.dtsi file was created by meld'ing the (old) .dts file provided
> by ReflexCES and socfpga_arria10_socdk_sdmmc_handoff.dtsi.
>
> The board was tested with what I believe is the factory bitstream written
> in the EPCQ.
>
> As I copied and pasted the majority of the files from the arria10-socdk,
> I purposely ignored a bunch of checkpatch warnings, i.e. lenghty lines
> and a missing SPDX-License-Identifier in the .dts(i) files.
Those should be fixed ...
[...]
> +++ b/include/configs/socfpga_r329_a10_pcie.h
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2015-2017 Altera Corporation
> + */
> +
> +#ifndef __CONFIG_SOCFGPA_ARRIA10_H__
> +#define __CONFIG_SOCFGPA_ARRIA10_H__
> +
> +#include
> +
> +/* Booting Linux */
> +#define CONFIG_LOADADDR 0x0100
> +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
> +
> +/*
> + * U-Boot general configurations
> + */
> +/* Cache options */
> +#define CONFIG_SYS_DCACHE_OFF
Is this needed ?
> +/* Memory configurations */
> +#define PHYS_SDRAM_1_SIZE0xC000
> +
> +/* Ethernet on SoC (EMAC) */
The comments need cleanup.
> +/*
> + * U-Boot environment configurations
> + */
> +
> +/*
> + * Serial / UART configurations
> + */
> +#define CONFIG_SYS_NS16550_MEM32
Needed ?
> +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600, 115200}
Needed ?
If so, should be enabled on all socfpgas .
> +/*
> + * L4 OSC1 Timer 0
> + */
> +/* reload value when timer count to zero */
> +#define TIMER_LOAD_VAL 0x
> +
> +/*
> + * Flash configurations
> + */
> +#define CONFIG_SYS_MAX_FLASH_BANKS 1
> +
> +/* The rest of the configuration is shared */
> +#include
> +
> +#endif /* __CONFIG_SOCFGPA_ARRIA10_H__ */
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/9] ARM: dw_mmc: Exclude dwmci Exynos priv_data allocation from exynos_dwmci_get_config()
This commit prevents memory leak when this function is used with DM_MMC
as the struct dwmci_exynos_priv_data is already allocated by DM.
It is necessary for NON DM aware devices to allocate this struct first.
Signed-off-by: Lukasz Majewski
---
drivers/mmc/exynos_dw_mmc.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 865fdf4dbba0..49c4f7634830 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -146,17 +146,11 @@ static int do_dwmci_init(struct dwmci_host *host)
}
static int exynos_dwmci_get_config(const void *blob, int node,
- struct dwmci_host *host)
+ struct dwmci_host *host,
+ struct dwmci_exynos_priv_data *priv)
{
int err = 0;
u32 base, timing[3];
- struct dwmci_exynos_priv_data *priv;
-
- priv = malloc(sizeof(struct dwmci_exynos_priv_data));
- if (!priv) {
- pr_err("dwmci_exynos_priv_data malloc fail!\n");
- return -ENOMEM;
- }
/* Extract device id for each mmc channel */
host->dev_id = pinmux_decode_periph_id(blob, node);
@@ -167,7 +161,6 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
if (host->dev_index > 4) {
printf("DWMMC%d: Can't get the dev index\n", host->dev_index);
- free(priv);
return -EINVAL;
}
@@ -178,7 +171,6 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
base = fdtdec_get_addr(blob, node, "reg");
if (!base) {
printf("DWMMC%d: Can't get base address\n", host->dev_index);
- free(priv);
return -EINVAL;
}
host->ioaddr = (void *)base;
@@ -188,7 +180,6 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
if (err) {
printf("DWMMC%d: Can't get sdr-timings for devider\n",
host->dev_index);
- free(priv);
return -EINVAL;
}
@@ -208,14 +199,13 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
host->bus_hz = fdtdec_get_int(blob, node, "bus_hz", 0);
host->div = fdtdec_get_int(blob, node, "div", 0);
- host->priv = priv;
-
return 0;
}
static int exynos_dwmci_process_node(const void *blob,
int node_list[], int count)
{
+ struct dwmci_exynos_priv_data *priv;
struct dwmci_host *host;
int i, node, err;
@@ -224,11 +214,20 @@ static int exynos_dwmci_process_node(const void *blob,
if (node <= 0)
continue;
host = &dwmci_host[i];
- err = exynos_dwmci_get_config(blob, node, host);
+
+ priv = malloc(sizeof(struct dwmci_exynos_priv_data));
+ if (!priv) {
+ pr_err("dwmci_exynos_priv_data malloc fail!\n");
+ return -ENOMEM;
+ }
+
+ err = exynos_dwmci_get_config(blob, node, host, priv);
if (err) {
printf("%s: failed to decode dev %d\n", __func__, i);
+ free(priv);
return err;
}
+ host->priv = priv;
do_dwmci_init(host);
}
@@ -266,7 +265,8 @@ static int exynos_dwmmc_probe(struct udevice *dev)
struct dwmci_host *host = &priv->host;
int err;
- err = exynos_dwmci_get_config(gd->fdt_blob, dev_of_offset(dev), host);
+ err = exynos_dwmci_get_config(gd->fdt_blob, dev_of_offset(dev), host,
+ priv);
if (err)
return err;
err = do_dwmci_init(host);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/9] ARM: Odroid XU3: Enable driver model support for MMC (DM_MMC)
This commit enables support for DW_MMC running with driver model. Signed-off-by: Lukasz Majewski --- configs/odroid-xu3_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 6398c2cd0d6a..632542d98420 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -29,6 +29,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_ADC=y CONFIG_ADC_EXYNOS=y CONFIG_DFU_MMC=y +CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_NETDEVICES=y CONFIG_SMC911X=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/9] ARM: Odroid XU3: config: Disable SDHCI support in the Odroid XU3
The Exynos5422 is solely using DW MMC IP block to support eMMC/SD devices, hence the SDHCI code doesn't need to be compiled it. Signed-off-by: Lukasz Majewski --- configs/odroid-xu3_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 5943c19cf9b3..6398c2cd0d6a 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -30,8 +30,6 @@ CONFIG_ADC=y CONFIG_ADC_EXYNOS=y CONFIG_DFU_MMC=y CONFIG_MMC_DW=y -CONFIG_MMC_SDHCI=y -CONFIG_MMC_SDHCI_S5P=y CONFIG_NETDEVICES=y CONFIG_SMC911X=y CONFIG_SMC911X_BASE=0x500 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 7/9] ARM: Odroid XU3: Fix the dwmci_exynos *priv data assignment for DM_MMC (sdr_timing)
By convention for DM_MMC the host->priv is used to store struct udevice
*dev pointer.
Unfortunately, the legacy Exynos DW MMC code uses this field to
store pointer to dwmci_exynos_priv_data struct
Hence, we do need to get data in other way - namely by using container_of
when host pointer is present.
In this way the sdr_timing data is properly accessed.
Signed-off-by: Lukasz Majewski
---
drivers/mmc/exynos_dw_mmc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 49c4f7634830..cd0fa4c6341b 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -46,8 +46,12 @@ struct dwmci_exynos_priv_data {
*/
static void exynos_dwmci_clksel(struct dwmci_host *host)
{
+#ifdef CONFIG_DM_MMC
+ struct dwmci_exynos_priv_data *priv =
+ container_of(host, struct dwmci_exynos_priv_data, host);
+#else
struct dwmci_exynos_priv_data *priv = host->priv;
-
+#endif
dwmci_writel(host, DWMCI_CLKSEL, priv->sdr_timing);
}
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 6/9] ARM: Odroid XU3: MAINTAINERS: Add a co-maintainer for OdroidXU3
Signed-off-by: Lukasz Majewski --- board/samsung/smdk5420/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/samsung/smdk5420/MAINTAINERS b/board/samsung/smdk5420/MAINTAINERS index 590a1140b07e..31c00360f287 100644 --- a/board/samsung/smdk5420/MAINTAINERS +++ b/board/samsung/smdk5420/MAINTAINERS @@ -11,6 +11,7 @@ F:configs/peach-pi_defconfig ODROID-XU3 BOARD M: Jaehoon Chung +M: Lukasz Majewski S: Maintained F: board/samsung/smdk5420/ F: include/configs/odroid_xu3.h -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/9] ARM: Odroid XU3: Enable DM_MMC support which is necessary for CONFIG_BLK
This patch series provides following improvements to Odroid XU3:
- Fix sdr_timing problem with DW_MMC running with DM
- Clean up the defconfig file
- Allow default booting via SD card
- Fix potential memory leak when running under DM (DW_MMC)
Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/408080614
Lukasz Majewski (9):
ARM: dw_mmc: Exclude dwmci Exynos priv_data allocation from
exynos_dwmci_get_config()
ARM: Odroid XU3: config: Disable SDHCI support in the Odroid XU3
ARM: Odroid XU3: Enable driver model support for MMC (DM_MMC)
ARM: Odroid XU3: Fix autoboot.cmd to use ${mmcbootdev} instead of
hardcoded 0
ARM: Odroid XU3: Adjust BOOT_TARGET_DEVICES to allow booting from SD
card (mmc2)
ARM: Odroid XU3: MAINTAINERS: Add a co-maintainer for OdroidXU3
ARM: Odroid XU3: Fix the dwmci_exynos *priv data assignment for DM_MMC
(sdr_timing)
ARM: Odroid XU3: Modify exynos dw_mmc driver to support Odroid XU3 in
DM MMC
ARM: Odroid XU3: Modify Odroid XU3 config to boot by default from SD
card
board/samsung/common/bootscripts/autoboot.cmd | 6 ++---
board/samsung/smdk5420/MAINTAINERS| 1 +
configs/odroid-xu3_defconfig | 3 +--
drivers/mmc/exynos_dw_mmc.c | 37 +++
include/configs/exynos5-common.h | 1 +
include/configs/odroid_xu3.h | 7 +++--
6 files changed, 32 insertions(+), 23 deletions(-)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 8/9] ARM: Odroid XU3: Modify exynos dw_mmc driver to support Odroid XU3 in DM MMC
This commit enables support for Exynos Designware MMC driver based on DM.
Signed-off-by: Lukasz Majewski
---
drivers/mmc/exynos_dw_mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index cd0fa4c6341b..435ccac59421 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -295,6 +295,7 @@ static int exynos_dwmmc_bind(struct udevice *dev)
static const struct udevice_id exynos_dwmmc_ids[] = {
{ .compatible = "samsung,exynos4412-dw-mshc" },
+ { .compatible = "samsung,exynos-dwmmc" },
{ }
};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 5/9] ARM: Odroid XU3: Adjust BOOT_TARGET_DEVICES to allow booting from SD card (mmc2)
This change is necessary to allow booting the Odroid XU3 from SD card after enabling the DM_MMC support. After this change the SD card mmc IP block is correctly enumerated as mmc2 (and not as mmc1 as in the legacy code). Signed-off-by: Lukasz Majewski --- include/configs/exynos5-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index a7621fc701b2..cd2a9046afec 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -138,6 +138,7 @@ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 1) \ func(MMC, mmc, 0) \ + func(MMC, mmc, 2) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/9] ARM: Odroid XU3: Fix autoboot.cmd to use ${mmcbootdev} instead of hardcoded 0
This commit adjusts the autoboot.cmd file to use ${mmcbootdev} instead of
hardcoded value 0.
This is necessary to allow booting this board from the SD card.
Signed-off-by: Lukasz Majewski
---
board/samsung/common/bootscripts/autoboot.cmd | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/samsung/common/bootscripts/autoboot.cmd
b/board/samsung/common/bootscripts/autoboot.cmd
index 1faed8ba0c1a..11c724c4e095 100644
--- a/board/samsung/common/bootscripts/autoboot.cmd
+++ b/board/samsung/common/bootscripts/autoboot.cmd
@@ -74,15 +74,15 @@ setenv boot_img "
Routine: autoboot - choose proper boot path
setenv autoboot "
-if test -e mmc 0:${mmcbootpart} Image.itb; then
+if test -e mmc ${mmcbootdev}:${mmcbootpart} Image.itb; then
echo Found kernel image: Image.itb;
run setboot_fit;
run boot_img;
-elif test -e mmc 0:${mmcbootpart} zImage; then
+elif test -e mmc ${mmcbootdev}:${mmcbootpart} zImage; then
echo Found kernel image: zImage;
run setboot_zimg;
run boot_img;
-elif test -e mmc 0:${mmcbootpart} uImage; then
+elif test -e mmc ${mmcbootdev}:${mmcbootpart} uImage; then
echo Found kernel image: uImage;
run setboot_uimg;
run boot_img;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 9/9] ARM: Odroid XU3: Modify Odroid XU3 config to boot by default from SD card
This commit allows by default booting Odroid XU3 from the SD card (when e.g. eMMC module is not present). Signed-off-by: Lukasz Majewski --- include/configs/odroid_xu3.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h index f495f6219ba9..818a06515cb2 100644 --- a/include/configs/odroid_xu3.h +++ b/include/configs/odroid_xu3.h @@ -94,6 +94,9 @@ #undef CONFIG_SYS_BOARD #define CONFIG_SYS_BOARD "odroid" +#undef CONFIG_SYS_MMC_ENV_DEV +#define CONFIG_SYS_MMC_ENV_DEV 2 + /* Define new extra env settings, including DFU settings */ #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ @@ -105,8 +108,8 @@ "console=" CONFIG_DEFAULT_CONSOLE "\0"\ "fdtfile=exynos5422-odroidxu3.dtb\0" \ "boardname=odroidxu3\0" \ - "mmcbootdev=0\0" \ - "mmcrootdev=0\0" \ + "mmcbootdev=2\0" \ + "mmcrootdev=1\0" \ "mmcbootpart=1\0" \ "mmcrootpart=2\0" \ "dfu_alt_system="CONFIG_DFU_ALT_SYSTEM \ -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mailmap: Update mail address (lukma)
Update my e-mail address from samsung.com to denx.de Signed-off-by: Lukasz Majewski --- .mailmap | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index bd7267241a8e..513b4334c6e2 100644 --- a/.mailmap +++ b/.mailmap @@ -33,4 +33,4 @@ TsiChung Liew Wolfgang Denk York Sun York Sun -Łukasz Majewski +Lukasz Majewski -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device tree
> -Original Message-
> From: Horia Geanta
> Sent: Wednesday, July 25, 2018 11:25 PM
> To: Laurentiu Tudor ; York Sun
> ; Prabhakar Kushwaha
> ; u-boot@lists.denx.de
> Cc: Bharat Bhushan
> Subject: Re: [PATCH v4 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device
> tree
>
> On 7/24/2018 5:05 PM, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor
> >
> > Add support for SEC ICID configuration and apply it for ls1046a.
> > Also add code to make the necessary device tree fixups.
> > Also included in this patch, while adding the new required JR
> > defines sanitize the preexisting ones by dropping the CONFIG_
> > prefixes.
> >
> > Signed-off-by: Laurentiu Tudor
> > ---
> > .../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 15
> > .../asm/arch-fsl-layerscape/fsl_icid.h| 24 +++
> > .../asm/arch-fsl-layerscape/immap_lsch2.h | 11 ++---
> > drivers/crypto/fsl/jr.c | 2 +-
> > scripts/config_whitelist.txt | 2 --
> > 5 files changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> > index 30c7d8d28a..84f7665929 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> The header should be included where it's used, in fsl_icid.h.
>
> >
> > #ifdef CONFIG_SYS_DPAA_QBMAN
> > struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
> > @@ -40,6 +41,20 @@ struct icid_id_table icid_tbl[] = {
> > SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
> > SET_ETR_ICID(FSL_ETR_STREAM_ID),
> > SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
> > +#ifdef CONFIG_FSL_CAAM
> > + SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_JR_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_RTIC_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_RTIC_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_RTIC_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_RTIC_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_DECO_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_DECO_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
> > + SET_SEC_DECO_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
> > +#endif
> > };
> >
> PPA firmware running in secure world is using JR3 (what
> sec_firmware_used_jobring_offset() returns).
> I think a different ICID should be allocated for it, considering it has
> different security requirements.
All JR interfaces should be assigned different ICID.
While I am not sure DECO and RTIC are separate devices and can be used by
software independently from JR interface.
>
> BTW, is it clear that U-boot is responsible for ICID programming, and not
> PPA?
We can still boot without PPA/ATF, so keeping in u-boot is good at least for
now. I know about the new ATF architecture and stuff.
>
> > int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> > index 5be50a17ab..bd613219b6 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> > @@ -82,6 +82,30 @@ void fdt_fixup_icid(void *blob);
> > #define SET_FMAN_ICID_ENTRY(_port_id, streamid) \
> > { .port_id = (_port_id), .icid = (streamid) }
> >
> > +#define SET_SEC_QI_ICID(streamid) \
> > + SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
> > + (((streamid) << 16) | (streamid)), \
> > + offsetof(struct ccsr_sec, qilcr_ls) + \
> s/struct ccsr_sec/ccsr_sec_t
>
> > + CONFIG_SYS_FSL_SEC_ADDR, \
> > + CONFIG_SYS_FSL_SEC_ADDR)
> > +
> > +#define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
> > + SET_ICID_ENTRY("fsl,sec-v4.0-job-ring", streamid, \
> > + (((streamid) << 16) | (streamid)), \
> > + offsetof(struct ccsr_sec, jrliodnr[jr_num].ls) + \
> > + CONFIG_SYS_FSL_SEC_ADDR, \
> > + FSL_SEC_JR##jr_num##_BASE_ADDR)
> > +
> > +#define SET_SEC_DECO_ICID_ENTRY(deco_num, streamid) \
> > + SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
> > + offsetof(struct ccsr_sec, decoliodnr[deco_num].ls) + \
> > + CONFIG_SYS_FSL_SEC_ADDR, 0)
> > +
> > +#define SET_SEC_RTIC_ICID_ENTRY(rtic_num, streamid) \
> > + SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
> > + offsetof(struct ccsr_sec, rticliodnr[rtic_num].ls) + \
> > + CONFIG_SYS_FSL_SEC_ADDR, 0)
> > +
> > extern struct icid_id_table icid_tbl[];
> > extern struct fman_icid_id_table fman_i
Re: [U-Boot] [PATCH v2] mtd: add spi flash id s25fl128l
On Wed, Jul 18, 2018 at 12:03 PM, Clément Laigle wrote: > Add support for SPANSION s25fl128l 256k and 64k > > Changes for v2: > - Fix EXT_ID > > Signed-off-by: Clément Laigle > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5] u-boot: remove driver lookup loop from env_save()
Simon, Maxime,
any input on this? Via which tree would this be pushed? Should we CC Tom?
It would be nice if 2018.09 had this bug fixed (endless loop in
env_save() on error).
Thanks,
Simon
On 23.07.2018 10:01, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.
The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini
Reviewed-by: Simon Goldschmidt
---
Changes in v5:
- Correction to 'Reviewed-by' tag
Changes in v4:
- Remove env_load_location from gd_t since it is not used anymore
Changes in v3:
- Add comment when env_load() fails and the env location is restored
- Introduce env_load_prio into gd struct. It stores the current
priority of the environment location. Refactor of env_get_location()
which acts the same on all the 'env_operation'
Changes in v2:
- Restore gd->env_load_location to the highest priority location when
env_load() fails
env/env.c | 34 --
include/asm-generic/global_data.h | 2 +-
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/env/env.c b/env/env.c
index 5c0842a..e033b46 100644
--- a/env/env.c
+++ b/env/env.c
@@ -119,21 +119,12 @@ static void env_set_inited(enum env_location location)
*/
__weak enum env_location env_get_location(enum env_operation op, int prio)
{
- switch (op) {
- case ENVOP_GET_CHAR:
- case ENVOP_INIT:
- case ENVOP_LOAD:
- if (prio >= ARRAY_SIZE(env_locations))
- return ENVL_UNKNOWN;
-
- gd->env_load_location = env_locations[prio];
- return gd->env_load_location;
-
- case ENVOP_SAVE:
- return gd->env_load_location;
- }
+ if (prio >= ARRAY_SIZE(env_locations))
+ return ENVL_UNKNOWN;
+
+ gd->env_load_prio = prio;
- return ENVL_UNKNOWN;
+ return env_locations[prio];
}
@@ -205,22 +196,29 @@ int env_load(void)
return 0;
}
+ /*
+* In case of invalid environment, we set the 'default' env location
+* to the highest priority. In this way, next calls to env_save()
+* will restore the environment at the right place.
+*/
+ env_get_location(ENVOP_LOAD, 0);
+
return -ENODEV;
}
int env_save(void)
{
struct env_driver *drv;
- int prio;
- for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
+ drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
+ if (drv) {
int ret;
if (!drv->save)
- continue;
+ return -ENODEV;
if (!env_has_inited(drv->location))
- continue;
+ return -ENODEV;
printf("Saving Environment to %s... ", drv->name);
ret = drv->save();
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 0fd4900..c83fc01 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -50,7 +50,7 @@ typedef struct global_data {
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid;/* Environment valid? enum env_valid */
unsigned long env_has_init; /* Bitmask of boolean of struct
env_location offsets */
- int env_load_location;
+ int env_load_prio; /* Priority of the loaded environment */
unsigned long ram_base; /* Base address of RAM used by U-Boot */
unsigned long ram_top; /* Top address of RAM used by U-Boot */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: layerscape: Enable EHCI access for LS1012A
Hi York, > -Original Message- > From: York Sun > Sent: Tuesday, July 24, 2018 23:40 > To: Ran Wang ; Albert Aribaud > > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] armv8: layerscape: Enable EHCI access for LS1012A > > On 07/10/2018 07:11 PM, Ran Wang wrote: > > Hi York, > > > >> -Original Message- > >> From: York Sun > >> Sent: Wednesday, July 11, 2018 05:06 > >> To: Ran Wang ; Albert Aribaud > >> > >> Cc: u-boot@lists.denx.de > >> Subject: Re: [PATCH] armv8: layerscape: Enable EHCI access for > >> LS1012A > >> > >> On 07/02/2018 10:34 PM, Ran Wang wrote: > >>> Program Central Security Unit (CSU) to grant access permission for > >>> USB > >>> 2.0 controller, otherwiase EHCI funciton will down. > >>> > >>> Signed-off-by: Ran Wang > >>> --- > >>> arch/arm/cpu/armv8/fsl-layerscape/soc.c | 8 > >>> arch/arm/include/asm/arch-fsl-layerscape/ns_access.h | 1 + > >>> 2 files changed, 9 insertions(+) > >>> > >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > >>> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > >>> index 6a56269..2c4cf7f 100644 > >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > >>> @@ -14,6 +14,7 @@ > >>> #include > >>> #include > >>> #include > >>> +#include > >>> #ifdef CONFIG_LAYERSCAPE_NS_ACCESS > >>> #include > >>> #endif > >>> @@ -668,6 +669,13 @@ void fsl_lsch2_early_init_f(void) > >>>CCI400_DVM_MESSAGE_REQ_EN | > >> CCI400_SNOOP_REQ_EN); > >>> } > >>> > >>> + /* > >>> + * Program Central Security Unit (CSU) to grant access > >>> + * permission for USB 2.0 controller > >>> + */ > >>> +#if defined(CONFIG_ARCH_LS1012A) && > defined(CONFIG_USB_EHCI_FSL) > >>> + set_devices_ns_access(CSU_CSLX_USB_2, CSU_ALL_RW); #endif > >> > >> Is this LS1012A specific? > >> > > For Layerscape platforms, only LS1012A and LS1021A have USB2.0(EHCI) > > controller, Others have USB3.0 controller only. For now I can only > > verify on LS1012A, so didn't cover LS1021A yet. > > > > Ran, > > I think calling function set_devices_ns_access() may have an issue. It is not > EL2 safe, is it? Please check enable_layerscape_ns_access(). It detects > exception level before accessing EL3-only registers. > Yes, I re-checked the code and the experiments prove your point, I will send v2 patch soon. Thanks for reminding. BTW, I observed that in function board_late_init(), the return value of current_el() will be different: Case 1: Boot with PPA: return 2 ... Using SERDES1 Protocol: 13576 (0x3508) PPA Firmware: Version LSDK-1712-TC1-dirty SEC Firmware: 'loadables' present in config loadables: 'trustedOS@1' ... FPGA: v4 (LS1012QDS_2016_0405_1443), build 100 on Tue Apr 05 09:13:13 2016 wangran!!! current_el():2 Case 2: without PPA: return 3 ... Using SERDES1 Protocol: 13576 (0x3508) SEC Firmware: config-1: no such config SEC Firmware: error (-2) SEC Firmware: Failed to load image ... FPGA: v4 (LS1012QDS_2016_0405_1443), build 100 on Tue Apr 05 09:13:13 2016 wangran!!! current_el():3 Do you know the reason? Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/27] SPI-NAND support
On Fri, Jul 13, 2018 at 6:01 PM, Miquel Raynal
wrote:
> During the last months, Boris Brezillon shared his work to support
> serial flashes within Linux. First, he delivered (and merged) a new
> layer called spi-mem. He also initiated in Linux MTD subsystem the move
> of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> same time a NAND core that would be shared with all NAND devices. Then,
> he contributed a generic SPI-NAND driver, making use of this NAND core,
> as well as some vendor code to drive a few chips.
>
> On top of this work, I added an 'mtd' U-Boot command to handle all sort
> of MTD devices. This should become the default command instead of having
> one per flash flavor ('sf', 'nand', 'spi-nand' ?).
>
> The series has been tested on an Ocelot board PCB123 (VSC7514),
> featuring a Macronix SPI NAND chip.
>
> TL;DR: the series contains:
> - A few patches from Linux to resynchronize some areas of the MTD layer.
> - Various fixes and re-organization of the MTD subsystem.
> - The introduction of the SPI-mem interface.
> - The addition of the generic SPI-NAND driver (and its bindings).
> - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> - A new 'mtd' command.
> - Support for spi-nand devices in mtdparts.
>
> To test your SPI-NAND device with U-Boot simply follow these lines:
>
>> setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
>> setenv mtdids spi-nand0=spi-nand0
>> mtdparts # show the spi-nand device partitions
>> ubi part bar # create a static UBI volume in the bar partition
>
> Thanks,
> Miquèl
>
> Changes since v3:
> -
> * Fixed the debug messages in spi-mem to print either Rx or Tx data.
> * Fixed a Kconfig error that prevented to build mtdparts with plain
> defconfig.
> * Fixed a compilation error due to the above error that prevented one
> file to be compiled.
> * Adapted the mtd command to probe MTD partitions also.
> * Declared mtd_probe_devices() in a header so mtdparts or UBI could
> use it too (to probe all devices and MTD partitions in a clean way).
> * As I worked on mtdparts, I found annoying and completely useless the
> fact that we need to prefix the environment variable with
> "mtdparts=". Canceled this obligation.
> * Added one patch to allow spi-nand devices to be recognized by mtdparts
> (this is purely useless but needed to be done in order to use this
> command).
> * Removed useless definitions of MTD device types in UBI code.
> * Wrote a generic mtdparts environment variable parser, used by the mtd
> command.
> * Used the mtd_probe_devices() function from get_mtd_info() in
> cmd/mtdparts.c to be sure the desired partition really does not exist
> (otherwise it will be probed and then found).
>
> Changes since v2:
> -
> * Rebased on u-boot master branch.
> * Removed extra-parenthesis in
> "mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing"
> * s/fiels/files/ in "mtd: move NAND fiels into a raw/ subdirectory"
> * Do not describe generic SPI device properties in SPI NAND bindings.
> * Changes in the mtd command:
> * Printing more information in 'mtd list' (device type, device
> characteristics)
> * Switch to do_div() instead of '(u32)value64b % value32b' which only
> worked because value32b was a power of 2.
> * Removed erase.chip option.
> * By default, erase/read/write happen on the full MTD device while a
> dump will only work on a single page.
>
> Changes since v1:
> -
> * Fixed the nand_memorg structure of the MX35LF2GE4AB chip.
> * Added Reviewed-by tags from Jagan.
> * Backported and squashed two patches fixing things in the SPI NAND core
> received on the Linux ML.
> * Backported more changes in mtdcore.c from Linux.
> * Added a patch to add a fallback on mtd->_read/_write() in mtdcore.c
> when mtd->_read/write_oob() is not supported.
> * Removed the DT changes, useless as the DTs are not available in
> mainline yet.
> * Addressed Boris/Stefan comments on the 'mtd' command.
> * Added support for multi-pages OOB read/write.
>
>
> Boris Brezillon (7):
> mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
> mtd: Add sanity checks in mtd_write/read_oob()
> mtd: nand: Add core infrastructure to deal with NAND devices
> mtd: nand: Pass mode information to nand_page_io_req
> spi: Extend the core to ease integration of SPI memory controllers
> mtd: spinand: Add initial support for the MX35LF1GE4AB chip
> dt-bindings: Add bindings for SPI NAND devices
>
> Brian Norris (1):
> mtd: add get/set of_node/flash_node helpers
>
> Ezequiel Garcia (1):
> mtd: Uninline mtd_write_oob and move it to mtdcore.c
>
> Frieder Schrempf (1):
> mtd: spinand: Add initial support for Winbond W25M02GV
>
> Miquel Raynal (15):
> mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing
> mtd: fix build issue with includes
> mtd: move definitions to enlarge their range
> mtd: move all
Re: [U-Boot] [PATCH 1/2] mtd: nand: nand_base: Convert EINVAL into ENOTSUPP
On Fri, Jul 13, 2018 at 9:40 PM, Mylène Josserand wrote: > Convert the EINVAL error into ENOTSUPP when the GET/SET_FEATURES > is not supported. > > Signed-off-by: Mylène Josserand > --- Acked--by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd: nand: sunxi: Return on set_feature only when not ENOTSUPP
On Fri, Jul 13, 2018 at 9:40 PM, Mylène Josserand wrote: > Return the error code of the set_features function only if > the error code is not ENOTSUPP. Otherwise, if this function > is not supported, it will return and fail to initialize the > NAND. > > Signed-off-by: Mylène Josserand > --- Acked--by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v2] net: zynq_gem: convert to use livetree
On 25.7.2018 19:45, Joe Hershberger wrote: > On Tue, Jul 24, 2018 at 3:58 AM, Michal Simek wrote: >> Hi, >> >> On 23.7.2018 07:48, Siva Durga Prasad Paladugu wrote: >>> Hi Joe/Michal, >>> >>> Can you please take it up if it is fine. >> >> joe: Can you please take it via your tree? >> There are some patches before this. > > Sure. The second series that you depend on has build issues, so this > will be backed up behind that. ok. We will wait then. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 10/13] sunxi: add MMC support for H6
On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng wrote:
> The Allwinner H6 SoC has 3 MMC controllers like the ones in A64, with
> the MMC2 come with the capability to do crypto by EMCE.
>
> Add MMC support for H6. EMCE support is not added yet.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
> board/sunxi/board.c | 7 +++
> drivers/mmc/sunxi_mmc.c | 13 -
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
> b/arch/arm/include/asm/arch-sunxi/mmc.h
> index 1574b8e8fe..d98c53faaa 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -45,7 +45,7 @@ struct sunxi_mmc {
> u32 chda; /* 0x90 */
> u32 cbda; /* 0x94 */
> u32 res2[26];
> -#ifdef CONFIG_SUNXI_GEN_SUN6I
> +#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
> u32 res3[64];
> #endif
> u32 fifo; /* 0x100 / 0x200 FIFO access address */
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 5ed1b8bae1..857d5ff010 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -443,6 +443,13 @@ static void mmc_pinmux_setup(int sdc)
> sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> sunxi_gpio_set_drv(pin, 2);
> }
> +#elif defined(CONFIG_MACH_SUN50I_H6)
> + /* SDC2: PC4-PC14 */
> + for (pin = SUNXI_GPC(4); pin <= SUNXI_GPC(14); pin++) {
> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> + sunxi_gpio_set_drv(pin, 2);
> + }
> #elif defined(CONFIG_MACH_SUN9I)
> /* SDC2: PC6-PC16 */
> for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(16); pin++) {
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 7fa1ae8b16..39f15eb423 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -70,10 +70,12 @@ static int mmc_resource_init(int sdc_no)
> priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
> priv->mclkreg = &ccm->sd2_clk_cfg;
> break;
> +#ifdef SUNXI_MMC3_BASE
> case 3:
> priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
> priv->mclkreg = &ccm->sd3_clk_cfg;
> break;
> +#endif
> default:
> printf("Wrong mmc number %d\n", sdc_no);
> return -1;
> @@ -116,6 +118,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv,
> unsigned int hz)
> #ifdef CONFIG_MACH_SUN9I
> pll = CCM_MMC_CTRL_PLL_PERIPH0;
> pll_hz = clock_get_pll4_periph0();
> +#elif defined(CONFIG_MACH_SUN50I_H6)
> + pll = CCM_MMC_CTRL_PLL6X2;
> + pll_hz = clock_get_pll6() * 2;
> #else
> pll = CCM_MMC_CTRL_PLL6;
> pll_hz = clock_get_pll6();
> @@ -494,7 +499,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>
> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
> cfg->host_caps = MMC_MODE_4BIT;
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) ||
> defined(CONFIG_MACH_SUN50I_H6)
> if (sdc_no == 2)
> cfg->host_caps = MMC_MODE_8BIT;
> #endif
> @@ -509,6 +514,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>
> /* config ahb clock */
> debug("init mmc %d clock and io\n", sdc_no);
> +#if !defined(CONFIG_MACH_SUN50I_H6)
> setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
>
> #ifdef CONFIG_SUNXI_GEN_SUN6I
> @@ -519,6 +525,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
> /* sun9i has a mmc-common module, also set the gate and reset there */
> writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
>SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
> +#endif
> +#else /* CONFIG_MACH_SUN50I_H6 */
> + setbits_le32(&ccm->sd_gate_reset, 1 << sdc_no);
> + /* unassert reset */
> + setbits_le32(&ccm->sd_gate_reset, 1 << (RESET_SHIFT + sdc_no));
Set the ahb and reset directly in one call since we have a provision
of having same register in H6.
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 10/13] sunxi: add MMC support for H6
于 2018年7月26日 GMT+08:00 下午1:56:02, Jagan Teki 写到:
>On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng wrote:
>> The Allwinner H6 SoC has 3 MMC controllers like the ones in A64, with
>> the MMC2 come with the capability to do crypto by EMCE.
>>
>> Add MMC support for H6. EMCE support is not added yet.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
>> board/sunxi/board.c | 7 +++
>> drivers/mmc/sunxi_mmc.c | 13 -
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
>b/arch/arm/include/asm/arch-sunxi/mmc.h
>> index 1574b8e8fe..d98c53faaa 100644
>> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
>> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
>> @@ -45,7 +45,7 @@ struct sunxi_mmc {
>> u32 chda; /* 0x90 */
>> u32 cbda; /* 0x94 */
>> u32 res2[26];
>> -#ifdef CONFIG_SUNXI_GEN_SUN6I
>> +#if defined(CONFIG_SUNXI_GEN_SUN6I) ||
>defined(CONFIG_MACH_SUN50I_H6)
>> u32 res3[64];
>> #endif
>> u32 fifo; /* 0x100 / 0x200 FIFO access address
>*/
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index 5ed1b8bae1..857d5ff010 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -443,6 +443,13 @@ static void mmc_pinmux_setup(int sdc)
>> sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
>> sunxi_gpio_set_drv(pin, 2);
>> }
>> +#elif defined(CONFIG_MACH_SUN50I_H6)
>> + /* SDC2: PC4-PC14 */
>> + for (pin = SUNXI_GPC(4); pin <= SUNXI_GPC(14); pin++)
>{
>> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
>> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
>> + sunxi_gpio_set_drv(pin, 2);
>> + }
>> #elif defined(CONFIG_MACH_SUN9I)
>> /* SDC2: PC6-PC16 */
>> for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(16); pin++)
>{
>> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
>> index 7fa1ae8b16..39f15eb423 100644
>> --- a/drivers/mmc/sunxi_mmc.c
>> +++ b/drivers/mmc/sunxi_mmc.c
>> @@ -70,10 +70,12 @@ static int mmc_resource_init(int sdc_no)
>> priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
>> priv->mclkreg = &ccm->sd2_clk_cfg;
>> break;
>> +#ifdef SUNXI_MMC3_BASE
>> case 3:
>> priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
>> priv->mclkreg = &ccm->sd3_clk_cfg;
>> break;
>> +#endif
>> default:
>> printf("Wrong mmc number %d\n", sdc_no);
>> return -1;
>> @@ -116,6 +118,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv
>*priv, unsigned int hz)
>> #ifdef CONFIG_MACH_SUN9I
>> pll = CCM_MMC_CTRL_PLL_PERIPH0;
>> pll_hz = clock_get_pll4_periph0();
>> +#elif defined(CONFIG_MACH_SUN50I_H6)
>> + pll = CCM_MMC_CTRL_PLL6X2;
>> + pll_hz = clock_get_pll6() * 2;
>> #else
>> pll = CCM_MMC_CTRL_PLL6;
>> pll_hz = clock_get_pll6();
>> @@ -494,7 +499,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>>
>> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>> cfg->host_caps = MMC_MODE_4BIT;
>> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
>> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) ||
>defined(CONFIG_MACH_SUN50I_H6)
>> if (sdc_no == 2)
>> cfg->host_caps = MMC_MODE_8BIT;
>> #endif
>> @@ -509,6 +514,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>>
>> /* config ahb clock */
>> debug("init mmc %d clock and io\n", sdc_no);
>> +#if !defined(CONFIG_MACH_SUN50I_H6)
>> setbits_le32(&ccm->ahb_gate0, 1 <<
>AHB_GATE_OFFSET_MMC(sdc_no));
>>
>> #ifdef CONFIG_SUNXI_GEN_SUN6I
>> @@ -519,6 +525,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>> /* sun9i has a mmc-common module, also set the gate and reset
>there */
>> writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
>>SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
>> +#endif
>> +#else /* CONFIG_MACH_SUN50I_H6 */
>> + setbits_le32(&ccm->sd_gate_reset, 1 << sdc_no);
>> + /* unassert reset */
>> + setbits_le32(&ccm->sd_gate_reset, 1 << (RESET_SHIFT +
>sdc_no));
>
>Set the ahb and reset directly in one call since we have a provision
>of having same register in H6.
Programming guideline at User Manual's 3.3.3.4 suggests
a sequence.
>
>Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 25.7.2018 23:18, York Sun wrote:
> On 07/24/2018 10:58 PM, Michal Simek wrote:
>> On 24.7.2018 18:26, York Sun wrote:
>>> On 07/24/2018 06:07 AM, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type.
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9eabb1c1058b..dbf5ac33a845 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -257,10 +257,7 @@ static int spl_load_fit_image(struct spl_load_info
*info, ulong sector,
board_fit_image_post_process(&src, &length);
#endif
- if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
- IS_ENABLED(CONFIG_SPL_GZIP) &&
- image_comp == IH_COMP_GZIP &&
- type == IH_TYPE_KERNEL) {
+ if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
size = length;
if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
src, &size)) {
>>>
>>> This will uncompress ramdisk unnecessarily.
>>
>> Can you please share your its fragment? Also is there any other image
>> which should be exclude?
>
> I used it for falcon boot. I guess the executable image should have "entry".
> In
> my setup, only kernel image has "entry". Here is my its file.
>
> /dts-v1/;
>
> / {
> description = "Image file for the LS1046A Linux Kernel";
> #address-cells = <1>;
>
> images {
> kernel@1 {
> description = "ARM64 Linux kernel";
> data = /incbin/("./arch/arm64/boot/Image.gz");
> type = "kernel";
> arch = "arm64";
> os = "linux";
> compression = "gzip";
> load = <0x8008>;
> entry = <0x8008>;
> };
> fdt@1 {
> description = "Flattened Device Tree blob";
> data = /incbin/("./fsl-ls1046ardb.dtb");
> type = "flat_dt";
> arch = "arm64";
> compression = "none";
> load = <0x9000>;
> };
> ramdisk@1 {
> description = "Buildroot initramfs";
> data = /incbin/("./rootfs.cpio.gz");
> type = "ramdisk";
> arch = "arm64";
> os = "linux";
> compression = "gzip";
I have tested full u-boot and there is also no uncompression for ramdisk
when you put gzip compress there.
I have even tried gzip compression for fdt with expectation that u-boot
will uncompress it.
Based on doc/uImage.FIT/source_file_format.txt:
165 - compression : Compression used by included data. Supported
compressions
166 are "gzip" and "bzip2". If no compression is used compression
property
167 should be set to "none".
Based on me this means that data inside fit are compressed and you are
asking u-boot in boot to uncompress it. If you are not asking for that
you should put none there.
But it doesn't look like this is supported at all for fdt/ramdisk and it
is only handled for OS.
I see here two cases.
1. I want u-boot to uncompress my data in fit image (whatever it is)
before passing control to OS that's why I putting there compression method.
2. I want OS to uncompress data but I want pass this data unchanged from
u-boot to OS that's why I am putting compression method at "none"
I am expecting when you put "none" there than you will boot in falcon
mode without any issue.
I have no problem to change this patch and include only kernel and fpga
image but it sounds to me that we have gaps in implementation that not
all images inside the fit image have the same range of functionalities.
Also I think that "load" entry is that one which matters not "entry".
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions
On 26.07.2018 08:52, Michal Simek wrote:
On 25.7.2018 23:18, York Sun wrote:
On 07/24/2018 10:58 PM, Michal Simek wrote:
On 24.7.2018 18:26, York Sun wrote:
On 07/24/2018 06:07 AM, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type.
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9eabb1c1058b..dbf5ac33a845 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -257,10 +257,7 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
board_fit_image_post_process(&src, &length);
#endif
- if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
- IS_ENABLED(CONFIG_SPL_GZIP) &&
- image_comp == IH_COMP_GZIP &&
- type == IH_TYPE_KERNEL) {
+ if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
size = length;
if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
src, &size)) {
This will uncompress ramdisk unnecessarily.
Can you please share your its fragment? Also is there any other image
which should be exclude?
I used it for falcon boot. I guess the executable image should have "entry". In
my setup, only kernel image has "entry". Here is my its file.
/dts-v1/;
/ {
description = "Image file for the LS1046A Linux Kernel";
#address-cells = <1>;
images {
kernel@1 {
description = "ARM64 Linux kernel";
data = /incbin/("./arch/arm64/boot/Image.gz");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x8008>;
entry = <0x8008>;
};
fdt@1 {
description = "Flattened Device Tree blob";
data = /incbin/("./fsl-ls1046ardb.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
load = <0x9000>;
};
ramdisk@1 {
description = "Buildroot initramfs";
data = /incbin/("./rootfs.cpio.gz");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "gzip";
I have tested full u-boot and there is also no uncompression for ramdisk
when you put gzip compress there.
I have even tried gzip compression for fdt with expectation that u-boot
will uncompress it.
Based on doc/uImage.FIT/source_file_format.txt:
165 - compression : Compression used by included data. Supported
compressions
166 are "gzip" and "bzip2". If no compression is used compression
property
167 should be set to "none".
Based on me this means that data inside fit are compressed and you are
asking u-boot in boot to uncompress it. If you are not asking for that
you should put none there.
But it doesn't look like this is supported at all for fdt/ramdisk and it
is only handled for OS.
I see here two cases.
1. I want u-boot to uncompress my data in fit image (whatever it is)
before passing control to OS that's why I putting there compression method.
2. I want OS to uncompress data but I want pass this data unchanged from
u-boot to OS that's why I am putting compression method at "none"
I am expecting when you put "none" there than you will boot in falcon
mode without any issue.
I have no problem to change this patch and include only kernel and fpga
image but it sounds to me that we have gaps in implementation that not
all images inside the fit image have the same range of functionalities.
I think it would be more consistent to have the compression setting
control U-Boot unzip behaviour and implement unzip for all types (as you
did for SPL). Of course, I also have the fpga image in mind :-)
The question is (as often): how many existing .its would be broken with
such a change.
Simon
Also I think that "load" entry is that one which matters not "entry".
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
