Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
Hi Jagan,
> -Original Message-
> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Wednesday, May 09, 2018 12:01 PM
> To: Siva Durga Prasad Paladugu
> Cc: U-Boot-Denx ; michal.si...@xilinx.com
> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP
> qspi driver
>
> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> wrote:
> > This patch adds qspi driver support for ZynqMP SoC. This driver is
> > responsible for communicating with qspi flash devices.
> >
> > Signed-off-by: Siva Durga Prasad Paladugu
> >
> > ---
> > Changes for v3:
> > - Renamed all macros, functions, files and configs as per comment
> > - Used wait_for_bit wherever required
> > - Removed unnecessary header inclusion
> >
> > Changes for v2:
> > - Rebased on top of latest master
> > - Moved macro definitions to .h file as per comment
> > - Fixed magic values with macros as per comment
> > ---
> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154 ++
> > drivers/spi/Kconfig | 7 +
> > drivers/spi/Makefile| 1 +
> > drivers/spi/zynqmp_gqspi.c | 670
>
> > 4 files changed, 832 insertions(+)
> > create mode 100644 arch/arm/include/asm/arch-
> zynqmp/zynqmp_gqspi.h
> > create mode 100644 drivers/spi/zynqmp_gqspi.c
> >
> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>
> already asked you to move this header code in driver .c file
You might have missed my reply to your earlier comment on this. These were
moved to .h based on comment
from Lukasz in v1.
I don’t have any issue in having them anywhere. Let me know your choice.
>
> > new file mode 100644
> > index 000..4b26d80
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> > @@ -0,0 +1,154 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
>
> [snip]
>
> > + *
> > + * Xilinx ZynqMP Generic Quad-SPI(QSPI) controller driver(master mode
> > + only) */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> headers are inorder.
Ok.
>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct zynqmp_qspi_platdata {
> > + struct zynqmp_qspi_regs *regs;
> > + struct zynqmp_qspi_dma_regs *dma_regs;
> > + u32 frequency;
> > + u32 speed_hz;
> > + unsigned int tx_rx_mode;
> > +};
> > +
> > +struct zynqmp_qspi_priv {
> > + struct zynqmp_qspi_regs *regs;
> > + struct zynqmp_qspi_dma_regs *dma_regs;
> > + u8 mode;
> > + const void *tx_buf;
> > + void *rx_buf;
> > + unsigned int len;
> > + int bytes_to_transfer;
> > + int bytes_to_receive;
> > + unsigned int is_inst;
> > + unsigned int cs_change:1;
> > +};
> > +
> > +static u8 last_cmd;
> > +
> > +static int zynqmp_qspi_ofdata_to_platdata(struct udevice *bus) {
> > + struct zynqmp_qspi_platdata *plat = bus->platdata;
> > + u32 mode = 0;
> > + u32 value;
> > + int ret;
> > + struct clk clk;
> > + unsigned long clock;
> > +
> > + debug("%s\n", __func__);
> > +
> > + plat->regs = (struct zynqmp_qspi_regs *)(devfdt_get_addr(bus) +
> > +GQSPI_REG_OFFSET);
> > + plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > + (devfdt_get_addr(bus) +
> > + GQSPI_DMA_REG_OFFSET);
> > +
> > + ret = clk_get_by_index(bus, 0, &clk);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to get clock\n");
> > + return ret;
> > + }
> > +
> > + clock = clk_get_rate(&clk);
> > + if (IS_ERR_VALUE(clock)) {
> > + dev_err(dev, "failed to get rate\n");
> > + return clock;
> > + }
> > + debug("%s: CLK %ld\n", __func__, clock);
> > +
> > + ret = clk_enable(&clk);
> > + if (ret && ret != -ENOSYS) {
> > + dev_err(dev, "failed to enable clock\n");
> > + return ret;
> > + }
> > +
> > + value = dev_read_u32_default(bus, "spi-rx-bus-width", 1);
> > + switch (value) {
> > + case 1:
> > + break;
> > + case 2:
> > + mode |= SPI_RX_DUAL;
> > + break;
> > + case 4:
> > + mode |= SPI_RX_QUAD;
> > + break;
> > + default:
> > + printf("Invalid spi-rx-bus-width %d\n", value);
> > + break;
> > + }
> > +
> > + value = dev_read_u32_default(bus, "spi-tx-bus-width", 1);
> > + switch (value) {
> > + case 1:
> > + break;
> > + case 2:
> > + mode |= SPI_TX_DUAL;
> > + break;
> > + case 4:
> > + mode |= SPI_TX_QUAD;
> > + bre
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
> On 9 May 2018, at 07:29, Marty E. Plummer wrote:
>
> On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
>>
>>> On 8 May 2018, at 21:21, Marty E. Plummer wrote:
>>>
>>> On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
Marty,
> On 8 May 2018, at 02:52, Marty E. Plummer wrote:
>
> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>
>>> On 7 May 2018, at 04:34, Marty E. Plummer
>>> wrote:
>>>
>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
Hi Marty,
On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>
> Without this change, my u-boot build for the asus c201 chromebook
> (4GiB)
> is incorrectly detected as 0 Bytes of ram.
I know the root cause for this issue, and I have a local patch for it.
The rk3288 is 32bit, and 4GB size is just out of range, so we need to
before
the max size before return with '<<20'. Sorry for forgot to send it
out.
>
> Signed-off-by: Marty E. Plummer
> ---
> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> 1 file changed, 37 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/sdram_common.c
> b/arch/arm/mach-rockchip/sdram_common.c
> index 76dbdc8715..a9c9f970a4 100644
> --- a/arch/arm/mach-rockchip/sdram_common.c
> +++ b/arch/arm/mach-rockchip/sdram_common.c
> @@ -10,6 +10,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
> size_t rockchip_sdram_size(phys_addr_t reg)
> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> size_t size_mb = 0;
> u32 ch;
>
> - u32 sys_reg = readl(reg);
> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> -& SYS_REG_NUM_CH_MASK);
> + if (!size_mb) {
I don't understand this and follow up changes, we don't really need it,
isn't it?
I think don't need the changes before here.
>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>> guard, but I've reworked the patch to not do that as it was pointed out
>>> that since size_mb is initialized to 0 prior.
> + /*
> + * we use the 0x~0xfeff space
> + * since 0xff00~0x is soc register space
> + * so we reserve it
> + */
> + size_mb = min(size_mb, 0xff00/SZ_1M);
This is what we really need, as Klaus point out, we need to use
SDRAM_MAX_SIZE
instead of hard code.
>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
>>> build and boot tested on my hardware.
>>
>> In that case you just masked the problem but didn???t solve it: assuming
>> size_mb
>> is size_t (I???ll assume this is 64bit, but did not check), then your
>> 4GB is 0x1__ )
>> which overflows to 0x0 when converted to a u32.
>>
>> In other words: we need to figure out where the truncation occurs (image
>> what
>> happens if a new 32bit processor with LPAE comes out???).
>>
> A very valid point. With the following patch to sdram_common.c and
> sdram_rk3288.c applied I get the debug output that follows it:
> diff --git a/arch/arm/mach-rockchip/sdram_common.c
> b/arch/arm/mach-rockchip/sdram_common.c
> index 232a7fa655..0fe69bf558 100644
> --- a/arch/arm/mach-rockchip/sdram_common.c
> +++ b/arch/arm/mach-rockchip/sdram_common.c
> @@ -4,6 +4,7 @@
> * SPDX-License-Identifier: GPL-2.0+
> */
>
> +#define DEBUG 1
> #include
> #include
> #include
> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> SYS_REG_ROW_3_4_MASK;
>
> chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> + debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__,
> chipsize_mb);
>
> if (rank > 1)
> chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> if (row_3_4)
> chipsize_mb = chipsize_mb * 3 / 4;
> size_mb += chipsize_mb;
> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
> debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
> rank, col, bk, cs0_row, bw, row_3_4);
> }
>
> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
> siz
[U-Boot] [PATCH] board/freescale,lsch3: Add entry for 0.9v
As per updated hardware documentation for lsch3 based chips like LS2088A, 0.9v support has been added in possible supported SoC volatges Signed-off-by: Priyanka Jain --- board/freescale/common/vid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c index 0476f24..eb5cf88 100644 --- a/board/freescale/common/vid.c +++ b/board/freescale/common/vid.c @@ -428,7 +428,7 @@ int adjust_vdd(ulong vdd_override) 0, /* reserved */ 0, /* reserved */ 0, /* reserved */ - 0, /* reserved */ + 9000, /* reserved */ 0, /* reserved */ 0, /* reserved */ 0, /* reserved */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support
On 07.05.18 04:13, r...@andestech.com wrote: > > >> -Original Message- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Monday, May 07, 2018 4:59 AM >> To: u-boot@lists.denx.de >> Cc: Heinrich Schuchardt; sch...@suse.de; Greentime Hu; Rick Jian-Zhi Chen(陳 >> 建志) >> Subject: Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support >> >> >> >> On 23.04.18 07:59, Alexander Graf wrote: >>> We now have RISC-V support in U-Boot - which is great! >>> >>> However, not that we're finally making progress to converge on >>> efi_loader and distro boot for booting on ARM platforms, we really >>> want to make sure there is no technical reason not to do the same on >>> RISC-V as well. >>> >>> So this patch set introduces distro boot and efi_loader support for >>> RISC-V! >>> >>> So far, I've only tested it with the selftest and hello world target >>> in U-Boot, as the number of target binaries to run is still slim. But >>> it should at least give us a good starting point. >> >> Rick, can this go into 2018.07? >> >> Via which tree do you want to push it? I can take it via the efi one or you >> can take >> it if you like ;). >> >> > > Yes > I prefer to u-boot-riscv.git > If this can enter main line, I will fetch it > I think you can take it via the efi one. :) > > > But when I verify the efi flow this days. > I find one issue and still clarify it now. > > I find the auto flow can not be disabled from make menuconfig > Following are the experiments I do: > > Currently the boot flow will auto scan *.efi file from sd card and tftp > server. > If I do not insert sd card and tftp server caple. > > The boot message will as below: > > U-Boot 2018.03-00351-g1dd246f-dirty (Apr 23 2018 - 15:34:32 +0800) > > DRAM: 1 GiB > No arch specific invalidate_icache_all available! > MMC: > Loading Environment from SPI Flash... SF: Detected mx25u1635e with page size > 256 Bytes, erase size 4 KiB, total 2 MiB > *** Warning - bad CRC, using default environment > > Failed (-5) > In:serial@f030 > Out: serial@f030 > Err: serial@f030 > Net: no alias for ethernet0 > > Warning: mac@e010 (eth0) using random MAC address - 66:7d:d7:be:c0:10 > eth0: mac@e010 > Hit any key to stop autoboot: 0 > No MMC device available > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > BOOTP broadcast 6 > BOOTP broadcast 7 > BOOTP broadcast 8 > BOOTP broadcast 9 > BOOTP broadcast 10 > BOOTP broadcast 11 > BOOTP broadcast 12 > BOOTP broadcast 13 > BOOTP broadcast 14 > BOOTP broadcast 15 > BOOTP broadcast 16 > BOOTP broadcast 17 > > Retry time exceeded; starting again > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > BOOTP broadcast 6 > BOOTP broadcast 7 > BOOTP broadcast 8 > BOOTP broadcast 9 > BOOTP broadcast 10 > BOOTP broadcast 11 > BOOTP broadcast 12 > BOOTP broadcast 13 > BOOTP broadcast 14 > BOOTP broadcast 15 > BOOTP broadcast 16 > BOOTP broadcast 17 > > Retry time exceeded; starting again > RISC-V # > > > Then I think if I don't want enter this auto flow, what can I do ? > > 1 Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > But it still enter auto flow. > > 2 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the > CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h > And Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > And it will NOT enter auto flow > > #ifdef CONFIG_DISTRO_DEFAULTS > /* Enable distro boot */ > #define BOOT_TARGET_DEVICES(func) \ > func(MMC, mmc, 0) \ > func(DHCP, dhcp, na) > > #include > > #define CONFIG_EXTRA_ENV_SETTINGS \ > "kernel_addr_r=0x0008\0" \ > "pxefile_addr_r=0x01f0\0" \ > "scriptaddr=0x01f0\0" \ > "fdt_addr_r=0x0200\0" \ > "ramdisk_addr_r=0x0280\0" \ > BOOTENV > #endif > > 3 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the > CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h > And do NOT Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > But disable CONFIG_DISTRO_DEFAULTS from make menuconfig >General setup ---> > [ ] Select defaults suitable for booting general purpose Linux > distributions > And it still enter auto flow > > Offering this information for you. This is the same for all distro enabled boards. The basic idea is that U-Boot ships with something that "just boots" for simple use cases. If you want something more advanced, you usually want to put something very target specific in there anyway, such as "bootm $nor_flash". In that case, you adapt the CONFIG_BOOTCOMMAND parameter to whatever you want. The boot command can also be overridden using the environment. So if you have working environment store, you can change the U-Boot variable "bootcmd" and U-Boot will run that instead wh
[U-Boot] [PATCH 0/3] Adjust at91 boards config offset for all boards
We have a new demo layout of our sama5 boards for the NAND Flash memory. According to this new layout, adjust the mtdparts variable in bootargs and config offsets in the board include files. The map is available at : http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d3XplainedMainPage#NAND_Flash_demo_Memory_map We have already aligned the sama5 mtdparts to new map with commit: "72281cbcf" : configs: at91: sama5: updated mtdparts variable in bootargs This series will fix the other at91 boards w.r.t. mtdparts and all the at91 boards w.r.t. CONFIG_ENV_OFFSET. All the boards will be aligned with the same flash memory map linked above. Thanks! Eugen Hristev (1): configs: at91sam9x5ek: updated mtdparts variable in bootargs Nicolas Ferre (2): configs: at91: sama5_common: Adjust CONFIG_ENV_OFFSET to match block alignment configs: at91: Adjust CONFIG_ENV_OFFSET to match sama5 address configs/at91sam9x5ek_dataflash_defconfig | 2 +- configs/at91sam9x5ek_nandflash_defconfig | 2 +- configs/at91sam9x5ek_spiflash_defconfig | 2 +- include/configs/at91-sama5_common.h | 2 +- include/configs/at91sam9260ek.h | 2 +- include/configs/at91sam9261ek.h | 2 +- include/configs/at91sam9263ek.h | 2 +- include/configs/at91sam9m10g45ek.h | 2 +- include/configs/at91sam9n12ek.h | 2 +- include/configs/at91sam9rlek.h | 2 +- include/configs/at91sam9x5ek.h | 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] configs: at91: Adjust CONFIG_ENV_OFFSET to match sama5 address
From: Nicolas Ferre In order to have a single ENV_OFFSET to manage, use the same as the sama5 one. This address matches our NAND flash map available at: http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d3XplainedMainPage#NAND_Flash_demo_Memory_map Signed-off-by: Nicolas Ferre [eugen.hris...@microchip.com: rework on latest version of u-boot] Signed-off-by: Eugen Hristev --- include/configs/at91sam9260ek.h| 2 +- include/configs/at91sam9261ek.h| 2 +- include/configs/at91sam9263ek.h| 2 +- include/configs/at91sam9m10g45ek.h | 2 +- include/configs/at91sam9n12ek.h| 2 +- include/configs/at91sam9rlek.h | 2 +- include/configs/at91sam9x5ek.h | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 433e4a8..137d7f0 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -138,7 +138,7 @@ #elif defined(CONFIG_SYS_USE_NANDFLASH) /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index 6a085dd..9e85259 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -125,7 +125,7 @@ #else /* CONFIG_SYS_USE_NANDFLASH */ /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index f37ef59..4c476fc 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -234,7 +234,7 @@ #elif CONFIG_SYS_USE_NANDFLASH /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x30; bootm" diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index 2597066..bec1558 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -76,7 +76,7 @@ #ifdef CONFIG_NAND_BOOT /* bootstrap + u-boot + env in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h index b284db3..a6865b2 100644 --- a/include/configs/at91sam9n12ek.h +++ b/include/configs/at91sam9n12ek.h @@ -110,7 +110,7 @@ #elif defined(CONFIG_NAND_BOOT) /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND \ diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h index f805c75..5ddb767 100644 --- a/include/configs/at91sam9rlek.h +++ b/include/configs/at91sam9rlek.h @@ -86,7 +86,7 @@ #elif CONFIG_SYS_USE_NANDFLASH /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND "nand read 0x2200 0x20 0x60; " \ diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index de10fad..8fc9750 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -86,7 +86,7 @@ #ifdef CONFIG_NAND_BOOT /* bootstrap + u-boot + env + linux in nandflash */ -#define CONFIG_ENV_OFFSET 0x12 +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */ #define CONFIG_BOOTCOMMAND "nand read " \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] configs: at91sam9x5ek: updated mtdparts variable in bootargs
We have a new demo layout of our sama5 boards for the NAND Flash memory. According to this new layout, adjust the mtdparts variable in bootargs to align with this, which is available at : http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d3XplainedMainPage#NAND_Flash_demo_Memory_map, Based on original work by Wenyou Yang Signed-off-by: Eugen Hristev --- configs/at91sam9x5ek_dataflash_defconfig | 2 +- configs/at91sam9x5ek_nandflash_defconfig | 2 +- configs/at91sam9x5ek_spiflash_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/at91sam9x5ek_dataflash_defconfig b/configs/at91sam9x5ek_dataflash_defconfig index ffed179..a888e9d 100644 --- a/configs/at91sam9x5ek_dataflash_defconfig +++ b/configs/at91sam9x5ek_dataflash_defconfig @@ -8,7 +8,7 @@ CONFIG_DEBUG_UART=y CONFIG_SYS_EXTRA_OPTIONS="SYS_USE_DATAFLASH" CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro,256k(env),256k(env_redundant),256k(spare),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs rw" +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=6 root=ubi0:rootfs rw" # CONFIG_CONSOLE_MUX is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_DISPLAY_BOARDINFO is not set diff --git a/configs/at91sam9x5ek_nandflash_defconfig b/configs/at91sam9x5ek_nandflash_defconfig index 4d16eb5..e3c863e 100644 --- a/configs/at91sam9x5ek_nandflash_defconfig +++ b/configs/at91sam9x5ek_nandflash_defconfig @@ -8,7 +8,7 @@ CONFIG_DEBUG_UART=y CONFIG_NAND_BOOT=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro,256k(env),256k(env_redundant),256k(spare),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs rw" +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=6 root=ubi0:rootfs rw" # CONFIG_CONSOLE_MUX is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_DISPLAY_BOARDINFO is not set diff --git a/configs/at91sam9x5ek_spiflash_defconfig b/configs/at91sam9x5ek_spiflash_defconfig index 52c419d..16d7de5 100644 --- a/configs/at91sam9x5ek_spiflash_defconfig +++ b/configs/at91sam9x5ek_spiflash_defconfig @@ -8,7 +8,7 @@ CONFIG_DEBUG_UART=y CONFIG_SPI_BOOT=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro,256k(env),256k(env_redundant),256k(spare),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs rw" +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=6 root=ubi0:rootfs rw" # CONFIG_CONSOLE_MUX is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_DISPLAY_BOARDINFO is not set -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] configs: at91: sama5_common: Adjust CONFIG_ENV_OFFSET to match block alignment
From: Nicolas Ferre Fix the unaligned environment address. This address matches our NAND flash map available at: http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d3XplainedMainPage#NAND_Flash_demo_Memory_map Signed-off-by: Nicolas Ferre [eugen.hris...@microchip.com: rework on latest version of u-boot] Signed-off-by: Eugen Hristev --- include/configs/at91-sama5_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/at91-sama5_common.h b/include/configs/at91-sama5_common.h index 5af7d1d..30c6cd4 100644 --- a/include/configs/at91-sama5_common.h +++ b/include/configs/at91-sama5_common.h @@ -57,7 +57,7 @@ #ifdef CONFIG_NAND_BOOT /* u-boot env in nand flash */ -#define CONFIG_ENV_OFFSET 0xc +#define CONFIG_ENV_OFFSET 0x14 #define CONFIG_ENV_OFFSET_REDUND 0x10 #define CONFIG_ENV_SIZE0x2 #define CONFIG_BOOTCOMMAND "nand read 0x2100 0x18 0x8;"\ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> Sent: Wednesday, May 09, 2018 12:01 PM
>> To: Siva Durga Prasad Paladugu
>> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP
>> qspi driver
>>
>> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> wrote:
>> > This patch adds qspi driver support for ZynqMP SoC. This driver is
>> > responsible for communicating with qspi flash devices.
>> >
>> > Signed-off-by: Siva Durga Prasad Paladugu
>> >
>> > ---
>> > Changes for v3:
>> > - Renamed all macros, functions, files and configs as per comment
>> > - Used wait_for_bit wherever required
>> > - Removed unnecessary header inclusion
>> >
>> > Changes for v2:
>> > - Rebased on top of latest master
>> > - Moved macro definitions to .h file as per comment
>> > - Fixed magic values with macros as per comment
>> > ---
>> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154 ++
>> > drivers/spi/Kconfig | 7 +
>> > drivers/spi/Makefile| 1 +
>> > drivers/spi/zynqmp_gqspi.c | 670
>>
>> > 4 files changed, 832 insertions(+)
>> > create mode 100644 arch/arm/include/asm/arch-
>> zynqmp/zynqmp_gqspi.h
>> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >
>> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>
>> already asked you to move this header code in driver .c file
>
> You might have missed my reply to your earlier comment on this. These were
> moved to .h based on comment
> from Lukasz in v1.
> I don’t have any issue in having them anywhere. Let me know your choice.
I'm trying to align Linux code, better to move like that and make sure
to use similar macros.
>
>>
>> > new file mode 100644
>> > index 000..4b26d80
>> > --- /dev/null
>> > +++ b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> > @@ -0,0 +1,154 @@
>> > +/* SPDX-License-Identifier: GPL-2.0+ */
>>
>> [snip]
>>
>> > + *
>> > + * Xilinx ZynqMP Generic Quad-SPI(QSPI) controller driver(master mode
>> > + only) */
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>>
>> headers are inorder.
>
> Ok.
>>
>> > +
>> > +DECLARE_GLOBAL_DATA_PTR;
>> > +
>> > +struct zynqmp_qspi_platdata {
>> > + struct zynqmp_qspi_regs *regs;
>> > + struct zynqmp_qspi_dma_regs *dma_regs;
>> > + u32 frequency;
>> > + u32 speed_hz;
>> > + unsigned int tx_rx_mode;
>> > +};
>> > +
>> > +struct zynqmp_qspi_priv {
>> > + struct zynqmp_qspi_regs *regs;
>> > + struct zynqmp_qspi_dma_regs *dma_regs;
>> > + u8 mode;
>> > + const void *tx_buf;
>> > + void *rx_buf;
>> > + unsigned int len;
>> > + int bytes_to_transfer;
>> > + int bytes_to_receive;
>> > + unsigned int is_inst;
>> > + unsigned int cs_change:1;
>> > +};
>> > +
>> > +static u8 last_cmd;
>> > +
>> > +static int zynqmp_qspi_ofdata_to_platdata(struct udevice *bus) {
>> > + struct zynqmp_qspi_platdata *plat = bus->platdata;
>> > + u32 mode = 0;
>> > + u32 value;
>> > + int ret;
>> > + struct clk clk;
>> > + unsigned long clock;
>> > +
>> > + debug("%s\n", __func__);
>> > +
>> > + plat->regs = (struct zynqmp_qspi_regs *)(devfdt_get_addr(bus) +
>> > +GQSPI_REG_OFFSET);
>> > + plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
>> > + (devfdt_get_addr(bus) +
>> > + GQSPI_DMA_REG_OFFSET);
>> > +
>> > + ret = clk_get_by_index(bus, 0, &clk);
>> > + if (ret < 0) {
>> > + dev_err(dev, "failed to get clock\n");
>> > + return ret;
>> > + }
>> > +
>> > + clock = clk_get_rate(&clk);
>> > + if (IS_ERR_VALUE(clock)) {
>> > + dev_err(dev, "failed to get rate\n");
>> > + return clock;
>> > + }
>> > + debug("%s: CLK %ld\n", __func__, clock);
>> > +
>> > + ret = clk_enable(&clk);
>> > + if (ret && ret != -ENOSYS) {
>> > + dev_err(dev, "failed to enable clock\n");
>> > + return ret;
>> > + }
>> > +
>> > + value = dev_read_u32_default(bus, "spi-rx-bus-width", 1);
>> > + switch (value) {
>> > + case 1:
>> > + break;
>> > + case 2:
>> > + mode |= SPI_RX_DUAL;
>> > + break;
>> > + case 4:
>> > + mode |= SPI_RX_QUAD;
>> > + break;
>> > + default:
>> > + printf("Invalid spi-rx-bus-width %d\n", value);
>> > + break;
>> > + }
>> > +
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
Hi,
> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 1:12 PM
> To: Siva Durga Prasad Paladugu
> Cc: Jagan Teki ; U-Boot-Denx b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
>
> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >> To: Siva Durga Prasad Paladugu
> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP
> >> qspi driver
> >>
> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >> wrote:
> >> > This patch adds qspi driver support for ZynqMP SoC. This driver is
> >> > responsible for communicating with qspi flash devices.
> >> >
> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >> >
> >> > ---
> >> > Changes for v3:
> >> > - Renamed all macros, functions, files and configs as per comment
> >> > - Used wait_for_bit wherever required
> >> > - Removed unnecessary header inclusion
> >> >
> >> > Changes for v2:
> >> > - Rebased on top of latest master
> >> > - Moved macro definitions to .h file as per comment
> >> > - Fixed magic values with macros as per comment
> >> > ---
> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154 ++
> >> > drivers/spi/Kconfig | 7 +
> >> > drivers/spi/Makefile| 1 +
> >> > drivers/spi/zynqmp_gqspi.c | 670
> >>
> >> > 4 files changed, 832 insertions(+) create mode 100644
> >> > arch/arm/include/asm/arch-
> >> zynqmp/zynqmp_gqspi.h
> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
> >> >
> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >>
> >> already asked you to move this header code in driver .c file
> >
> > You might have missed my reply to your earlier comment on this. These
> > were moved to .h based on comment from Lukasz in v1.
> > I don’t have any issue in having them anywhere. Let me know your choice.
>
> I'm trying to align Linux code, better to move like that and make sure to use
> similar macros.
>
> >
[snip]
> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
> *priv) {
> >> > + u8 command = 1;
> >> > + u32 gen_fifo_cmd;
> >> > + u32 bytecount = 0;
> >> > +
> >> > + while (priv->len) {
> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
> >> > +
> >> > + if (command) {
> >> > + command = 0;
> >> > + last_cmd = *(u8 *)priv->tx_buf;
> >> > + }
> >>
> >> don't understand this code can you explain? command assigned 1 it
> >> will not updated anywhere?
> >
> > I want to store last command sent. As the first byte in loop only
> > contains command, it ensures it fills only for one time and next time it
> may contain data to be sent along with command.
> > Command initialized to 1 while declaring it above(u8 command = 1).
>
> Ok the first TX buf has command and reused in tx and rx fifo, how come to
> use use same in rx fifo? why is is last_cmd it is first_cmd?
This holds the command that was sent last to the device before we use in tx/rx
fill, hence used this name.
Thanks,
Siva
>
>
> >
> >>
> >> > +
> >> > + gen_fifo_cmd |= GQSPI_SPI_MODE_SPI;
> >> > + gen_fifo_cmd |= *(u8 *)priv->tx_buf;
> >> > + bytecount++;
> >> > + priv->len--;
> >> > + priv->tx_buf = (u8 *)priv->tx_buf + 1;
> >> > +
> >> > + debug("GFIFO_CMD_Cmd = 0x%x\n", gen_fifo_cmd);
> >> > +
> >> > + zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
> >> > + }
> >> > +}
> >> > +
> >> > +static u32 zynqmp_qspi_calc_exp(struct zynqmp_qspi_priv *priv,
> >> > + u32 *gen_fifo_cmd) {
> >> > + u32 expval = 8;
> >> > + u32 len;
> >> > +
> >> > + while (1) {
> >> > + if (priv->len > 255) {
> >>
> >> what is 255 here?
> > When length is greater than 2^8 then we should fill length in different
> way, hence this check.
> > I will anyway use macro for better readability.
>
> make sure to write proper comments on why?
>
> >
> >>
> >> > + if (priv->len & (1 << expval)) {
> >> > + *gen_fifo_cmd &= ~GQSPI_GFIFO_IMD_MASK;
> >> > + *gen_fifo_cmd |= GQSPI_GFIFO_EXP_MASK;
> >> > + *gen_fifo_cmd |= expval;
> >> > + priv->len -= (1 << expval);
> >> > + return expval;
> >> > +
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
wrote:
>
> Hi,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 1:12 PM
>> To: Siva Durga Prasad Paladugu
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> wrote:
>> > Hi Jagan,
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >> To: Siva Durga Prasad Paladugu
>> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP
>> >> qspi driver
>> >>
>> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >> wrote:
>> >> > This patch adds qspi driver support for ZynqMP SoC. This driver is
>> >> > responsible for communicating with qspi flash devices.
>> >> >
>> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >> >
>> >> > ---
>> >> > Changes for v3:
>> >> > - Renamed all macros, functions, files and configs as per comment
>> >> > - Used wait_for_bit wherever required
>> >> > - Removed unnecessary header inclusion
>> >> >
>> >> > Changes for v2:
>> >> > - Rebased on top of latest master
>> >> > - Moved macro definitions to .h file as per comment
>> >> > - Fixed magic values with macros as per comment
>> >> > ---
>> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154 ++
>> >> > drivers/spi/Kconfig | 7 +
>> >> > drivers/spi/Makefile| 1 +
>> >> > drivers/spi/zynqmp_gqspi.c | 670
>> >>
>> >> > 4 files changed, 832 insertions(+) create mode 100644
>> >> > arch/arm/include/asm/arch-
>> >> zynqmp/zynqmp_gqspi.h
>> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >> >
>> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >>
>> >> already asked you to move this header code in driver .c file
>> >
>> > You might have missed my reply to your earlier comment on this. These
>> > were moved to .h based on comment from Lukasz in v1.
>> > I don’t have any issue in having them anywhere. Let me know your choice.
>>
>> I'm trying to align Linux code, better to move like that and make sure to use
>> similar macros.
>>
>> >
>
> [snip]
>
>> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>> *priv) {
>> >> > + u8 command = 1;
>> >> > + u32 gen_fifo_cmd;
>> >> > + u32 bytecount = 0;
>> >> > +
>> >> > + while (priv->len) {
>> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
>> >> > +
>> >> > + if (command) {
>> >> > + command = 0;
>> >> > + last_cmd = *(u8 *)priv->tx_buf;
>> >> > + }
>> >>
>> >> don't understand this code can you explain? command assigned 1 it
>> >> will not updated anywhere?
>> >
>> > I want to store last command sent. As the first byte in loop only
>> > contains command, it ensures it fills only for one time and next time it
>> may contain data to be sent along with command.
>> > Command initialized to 1 while declaring it above(u8 command = 1).
>>
>> Ok the first TX buf has command and reused in tx and rx fifo, how come to
>> use use same in rx fifo? why is is last_cmd it is first_cmd?
>
> This holds the command that was sent last to the device before we use in
> tx/rx fill, hence used this name.
ie. what I wonder, usually the spi transfer start with cmd + data in
that case it would be the first command, did gqspi work reverse way?
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: at91: clk-h32mx: replace dm_warn with dev_dbg
dm_warn is too noisy, replace with dev_dbg for less noise.
Based on original work by Wenyou Yang
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/clk-h32mx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/at91/clk-h32mx.c b/drivers/clk/at91/clk-h32mx.c
index 485a023..8f02d73 100644
--- a/drivers/clk/at91/clk-h32mx.c
+++ b/drivers/clk/at91/clk-h32mx.c
@@ -26,7 +26,7 @@ static ulong sama5d4_h32mx_clk_get_rate(struct clk *clk)
rate /= 2;
if (rate > H32MX_MAX_FREQ)
- dm_warn("H32MX clock is too fast\n");
+ dev_dbg(clk->dev, "H32MX clock is too fast\n");
return rate;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
Hi Jagan,
> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 1:22 PM
> To: Siva Durga Prasad Paladugu
> Cc: Jagan Teki ; U-Boot-Denx b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
>
> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
> wrote:
> >
> > Hi,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Wednesday, May 09, 2018 1:12 PM
> >> To: Siva Durga Prasad Paladugu
> >> Cc: Jagan Teki ; U-Boot-Denx >> b...@lists.denx.de>; michal.si...@xilinx.com
> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >> for ZynqMP qspi driver
> >>
> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> >> wrote:
> >> > Hi Jagan,
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >> >> To: Siva Durga Prasad Paladugu
> >> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> >> ZynqMP
> >> >> qspi driver
> >> >>
> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >> >> wrote:
> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
> >> >> > is responsible for communicating with qspi flash devices.
> >> >> >
> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >> >> >
> >> >> > ---
> >> >> > Changes for v3:
> >> >> > - Renamed all macros, functions, files and configs as per
> >> >> > comment
> >> >> > - Used wait_for_bit wherever required
> >> >> > - Removed unnecessary header inclusion
> >> >> >
> >> >> > Changes for v2:
> >> >> > - Rebased on top of latest master
> >> >> > - Moved macro definitions to .h file as per comment
> >> >> > - Fixed magic values with macros as per comment
> >> >> > ---
> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
> ++
> >> >> > drivers/spi/Kconfig | 7 +
> >> >> > drivers/spi/Makefile| 1 +
> >> >> > drivers/spi/zynqmp_gqspi.c | 670
> >> >>
> >> >> > 4 files changed, 832 insertions(+) create mode 100644
> >> >> > arch/arm/include/asm/arch-
> >> >> zynqmp/zynqmp_gqspi.h
> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
> >> >> >
> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >> >>
> >> >> already asked you to move this header code in driver .c file
> >> >
> >> > You might have missed my reply to your earlier comment on this.
> >> > These were moved to .h based on comment from Lukasz in v1.
> >> > I don’t have any issue in having them anywhere. Let me know your
> choice.
> >>
> >> I'm trying to align Linux code, better to move like that and make
> >> sure to use similar macros.
> >>
> >> >
> >
> > [snip]
> >
> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
> >> *priv) {
> >> >> > + u8 command = 1;
> >> >> > + u32 gen_fifo_cmd;
> >> >> > + u32 bytecount = 0;
> >> >> > +
> >> >> > + while (priv->len) {
> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> >> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
> >> >> > +
> >> >> > + if (command) {
> >> >> > + command = 0;
> >> >> > + last_cmd = *(u8 *)priv->tx_buf;
> >> >> > + }
> >> >>
> >> >> don't understand this code can you explain? command assigned 1 it
> >> >> will not updated anywhere?
> >> >
> >> > I want to store last command sent. As the first byte in loop only
> >> > contains command, it ensures it fills only for one time and next
> >> > time it
> >> may contain data to be sent along with command.
> >> > Command initialized to 1 while declaring it above(u8 command = 1).
> >>
> >> Ok the first TX buf has command and reused in tx and rx fifo, how
> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
> >
> > This holds the command that was sent last to the device before we use in
> tx/rx fill, hence used this name.
>
> ie. what I wonder, usually the spi transfer start with cmd + data in that case
> it would be the first command, did gqspi work reverse way?
It's also same as others :-), the last_cmd holds the recent command that was
sent to the device.
Its just name. To avoid confusion, I can use other names like "cmd_sent or
cmd_recent". Hope this is ok for you or suggest which
one would be appropriate.
Thanks,
Siva
>
> Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs
Hi Jonathan, Thanks for the patch, and it's interesting how this is missing, it means all the rockchip socs can not get console output with v2018.05 :( Thanks, - Kever On 05/08/2018 06:43 PM, Jonathan Gray wrote: > Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Kever Yang > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/rockchip-common.h > b/include/configs/rockchip-common.h > index dee82ca99d..68e1105a4b 100644 > --- a/include/configs/rockchip-common.h > +++ b/include/configs/rockchip-common.h > @@ -7,6 +7,8 @@ > #define _ROCKCHIP_COMMON_H_ > #include > > +#define CONFIG_SYS_NS16550_MEM32 > + > #ifndef CONFIG_SPL_BUILD > > /* First try to boot from SD (index 0), then eMMC (index 1) */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs
Kever, There were a number a merge conflicts with this series and it looks like I missed one of them. This is the risk when I try to resolve conflicts instead of asking for a series to be rebased onto master… Regards, Philipp. > On 9 May 2018, at 10:06, Kever Yang wrote: > > Hi Jonathan, > > > Thanks for the patch, and it's interesting how this is missing, > > it means all the rockchip socs can not get console output with v2018.05 :( > > > Thanks, > - Kever > On 05/08/2018 06:43 PM, Jonathan Gray wrote: >> Add back part of patch send out as >> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have >> gotten lost when it got merged to set SYS_NS16550_MEM32. >> >> Allows serial output to work on tinker-rk3288 again after >> c3c0331db1fb7b1f4ff41e144fc04353b37c785c. >> >> Signed-off-by: Kever Yang >> Signed-off-by: Jonathan Gray >> Cc: Philipp Tomsich >> --- >> include/configs/rockchip-common.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/configs/rockchip-common.h >> b/include/configs/rockchip-common.h >> index dee82ca99d..68e1105a4b 100644 >> --- a/include/configs/rockchip-common.h >> +++ b/include/configs/rockchip-common.h >> @@ -7,6 +7,8 @@ >> #define _ROCKCHIP_COMMON_H_ >> #include >> >> +#define CONFIG_SYS_NS16550_MEM32 >> + >> #ifndef CONFIG_SPL_BUILD >> >> /* First try to boot from SD (index 0), then eMMC (index 1) */ > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs
> Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Kever Yang > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs
> Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Kever Yang > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs
> Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Kever Yang > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs
Kever, if this affects all SoCs, then apparently nobody tested -rc3 … I had made sure that all these last-minute changes had gone in before rc3. Regards, Philipp. > On 9 May 2018, at 10:12, Dr. Philipp Tomsich > wrote: > > Kever, > > There were a number a merge conflicts with this series and it looks like I > missed > one of them. This is the risk when I try to resolve conflicts instead of > asking for > a series to be rebased onto master… > > Regards, > Philipp. > >> On 9 May 2018, at 10:06, Kever Yang wrote: >> >> Hi Jonathan, >> >> >>Thanks for the patch, and it's interesting how this is missing, >> >> it means all the rockchip socs can not get console output with v2018.05 :( >> >> >> Thanks, >> - Kever >> On 05/08/2018 06:43 PM, Jonathan Gray wrote: >>> Add back part of patch send out as >>> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have >>> gotten lost when it got merged to set SYS_NS16550_MEM32. >>> >>> Allows serial output to work on tinker-rk3288 again after >>> c3c0331db1fb7b1f4ff41e144fc04353b37c785c. >>> >>> Signed-off-by: Kever Yang >>> Signed-off-by: Jonathan Gray >>> Cc: Philipp Tomsich >>> --- >>> include/configs/rockchip-common.h | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/include/configs/rockchip-common.h >>> b/include/configs/rockchip-common.h >>> index dee82ca99d..68e1105a4b 100644 >>> --- a/include/configs/rockchip-common.h >>> +++ b/include/configs/rockchip-common.h >>> @@ -7,6 +7,8 @@ >>> #define _ROCKCHIP_COMMON_H_ >>> #include >>> >>> +#define CONFIG_SYS_NS16550_MEM32 >>> + >>> #ifndef CONFIG_SPL_BUILD >>> >>> /* First try to boot from SD (index 0), then eMMC (index 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] kconfig: Print reverse dependencies in groups
Hi Engeniu,
> -Original Message-
> From: Eugeniu Rosca [mailto:ero...@de.adit-jv.com]
> Sent: Wednesday, May 09, 2018 5:04 PM
> To: Tom Rini ; Yamada, Masahiro/山田 真弘
> ; Petr Vorel
> Cc: Ulf Magnusson ; Simon Glass ;
> U-Boot Mailing List ; Eugeniu Rosca
> ; Eugeniu Rosca
> Subject: Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
>
> Masahiro, Tom, Petr,
>
> Thanks for your prompt feedback.
>
> > On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > > I prefer syncing to check-picking.
> > > [...]
> > > Would you do that please?
> > > Or, do you want me to do it?
>
> I would happily attempt that. However, see my below question.
>
> On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> > I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
>
> Just to avoid any miscommunication, is my understanding correct that
> this is an explicit request for Masahiro to take care of the update? I
> would totally understand this.
>
> FWIW, here is some statistics of the kernel kconfig development in the
> v4.10..v4.17-rc4 commit range:
>
> - 86 non-merge change-sets:
> git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
> 86
>
> - 8 Kconfig commits which touch non-Kconfig files too (ignoring
> Documentation) and hence might require more delicate conflict
> resolution:
>
> for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 --
> scripts/kconfig/); do
> if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig
> |
> egrep -v "scripts/kconfig|Documentation" > /dev/null); then
> git --no-pager log --oneline $c -1;
> fi;
> done
>
> cb77f0d623ff scripts: Switch to more portable Perl shebang
> bb3290d91695 Remove gperf usage from toolchain
> b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files
> with no license
> 07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
> 911a91c39cab kconfig: rename silentoldconfig to syncconfig
> 598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the
> top-level .gitignore
> 9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from
> top-level Makefile
> b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
>
> I also think that the most sensitive part of this update is related to:
> - changed tooling requirements for hosts, e.g. flex and bison seem to
> be required starting with commit 29c833061c1d ("kconfig: generate
> lexer and parser during build instead of shipping").
> - dropped silentoldconfig support, starting with commit cedd55d49dee
> ("kconfig: Remove silentoldconfig from help and docs; fix
> kconfig/conf's help").
>
> There might be questions from users experiencing build errors/warnings
> after the update, same as we've seen in [1].
>
> [1] https://patchwork.kernel.org/patch/10318503/
>
> I would appreciate if Tom answers the question raised in the beginning
> of my post.
Tom will make a decision.
Just my thought.
U-Boot is basically a mirror of Linux.
Syncing Kconfig will add new tool requirement, flex & bison, for building
U-Boot,
but this is OK because Linux does it.
U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX
license tag style.
And, you understand well the points for resyncing.
Yes, other parts must be adjusted.
So, I am happy if you contribute to this work.
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
Hi Eugeniu, > FWIW, here is some statistics of the kernel kconfig development in the > v4.10..v4.17-rc4 commit range: > - 86 non-merge change-sets: > git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/ > 86 FYI: I send some time ago a patchset to update kconfig in buildroot, where delta is even bigger as sync was to 3.13-rc5 (+ some fixes). > Eugeniu. Kind regards, Petr [1] https://patchwork.ozlabs.org/project/buildroot/list/?series=40942 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] GCC 7.x vs. C++ comments
Tom, I recently ran a local buildman with a came across these: > cc -Wp,-MD,tools/.gen_eth_addr.d -Wall -Wstrict-prototypes -O2 > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o tools/gen_eth_addr > tools/gen_eth_addr.c > tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in ISO > C90 > // SPDX-License-Identifier: GPL-2.0+ > ^ > tools/gen_eth_addr.c:1:1: warning: (this will be reported only once per input > file) > cc -Wp,-MD,tools/.gen_ethaddr_crc.o.d -Wall -Wstrict-prototypes -O2 > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/gen_ethaddr_crc.o > tools/gen_ethaddr_crc.c > tools/gen_ethaddr_crc.c:1:1: warning: C++ style comments are not allowed in > ISO C90 > // SPDX-License-Identifier: GPL-2.0+ > ^ > tools/gen_ethaddr_crc.c:1:1: warning: (this will be reported only once per > input file) > echo "#include <../lib/crc8.c>" >tools/lib/crc8.c > cc -Wp,-MD,tools/lib/.crc8.o.d -Wall -Wstrict-prototypes -O2 > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/lib/crc8.o > tools/lib/crc8.c > In file included from tools/lib/crc8.c:1:0: > ./tools/../lib/crc8.c:1:1: warning: C++ style comments are not allowed in ISO > C90 > // SPDX-License-Identifier: GPL-2.0+ > ^ The system compiler was a > Using built-in specs. > COLLECT_GCC=cc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian > 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-4.9 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls > --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug > --enable-libstdcxx-time=yes --enable-gnu-unique-object > --disable-vtable-verify --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) What’s your preferred solution: (a) change these comments (b) change our Makefiles to let GCC know that we are compiling gnu99/C99? Neither solution is too appealing to me, so I am asking... Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/3] sf: Add GigaDevice gd25q32b entry
> Add entry for GigaDevice gd25q32b part. > > Signed-off-by: Marty E. Plummer > --- > drivers/mtd/spi/spi_flash_ids.c | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: fix off-by-one bug in efi_get_variable
On 05/09/2018 12:50 AM, Ivan Gorinov wrote:
efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.
Signed-off-by: Ivan Gorinov
Thanks to the memset right above the loop we can just remove the *mem =
0 line altogether, no?
Alex
---
lib/efi_loader/efi_variable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..d031338 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -68,11 +68,11 @@ static const char *hex2mem(u8 *mem, const char *hexstr, int
count)
do {
int nibble;
- *mem = 0;
-
if (!count || !*hexstr)
break;
+ *mem = 0;
+
nibble = hex(*hexstr);
if (nibble < 0)
break;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v3 0/7] Add support of SD3.0 UHS modes for ZynqMP
Hi Jaehoon, On 2.5.2018 04:05, Jaehoon Chung wrote: > On 04/30/2018 06:02 PM, Michal Simek wrote: >> Hi Tom, >> >> On 19.4.2018 09:07, Siva Durga Prasad Paladugu wrote: >>> This patch series is meant to add SD3.0 support for ZynqMP >>> platform. >>> The first five patches in the series mostly setting up >>> things in sdhci layer to support SD3.0 , the sixth patch >>> is to add SD3.0 support for ZynqMP platform and the last >>> patch is to enable this support for ZynqMP zcu102 rev1.0 >>> eval board. >>> >>> Siva Durga Prasad Paladugu (7): >>> mmc: sdhci: Add support for disabling clock >>> mmc: sdhci: Handle execute tuning command in sdhci_send_command >>> sdhci: Add new sdhci ops for platform specific tuning and delays >>> mmc: sdhci: Invoke platform specific tuning and delay routines >>> mmc : sdhci: Read capabilities register1 and update host caps >>> mmc: zynq_sdhci: Add support for SD3.0 >>> zynqmp: zcu102: Enable UHS support for ZCU102 Rev1.0 board >>> >>> board/xilinx/zynqmp/Makefile | 2 + >>> board/xilinx/zynqmp/tap_delays.c | 229 >>> + >>> configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 2 + >>> drivers/mmc/sdhci.c | 63 ++- >>> drivers/mmc/zynq_sdhci.c | 231 >>> +- >>> include/sdhci.h | 8 + >>> include/zynqmp_tap_delay.h| 20 +++ >>> 7 files changed, 547 insertions(+), 8 deletions(-) >>> create mode 100644 board/xilinx/zynqmp/tap_delays.c >>> create mode 100644 include/zynqmp_tap_delay.h >>> >> >> It looks like that Jaehoon is out or busy with something else. Can you >> please recommend someone to take a look at these patches? Definitely >> feel free to look at it self. > > Sorry. First, I checked the patches that delegate to me on patchwork. > So I missed this patchset. I will check this on Today. It looks like that Today wasn't really Today. Anyway giving you one more day and then will apply it via my tree. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fs: ext4: fix crash on ext4ls
Found a crash while issuing ext4ls with a non-existent directory.
Crash test:
=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>] lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]lr : [<26f2bed8>]
sp : 3f963338 ip : 3fdc3dc4 fp : 3fd6b370
r10: 0004 r9 : 3f967ec0 r8 : 3f96db68
r7 : 3fdc99b4 r6 : r5 : 3f96dc88 r4 : 3fdcbc8c
r3 : fffa r2 : r1 : 3f96e0bc r0 : 0002
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)
Looks like crash is introduced by commit:
"fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.
I added initialization and a check for dirname being NULL.
Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns
Cc: Tom Rini
Signed-off-by: Eugen Hristev
---
Hello,
Regarding this fix, I am not sure if we actually need to free the node, but
according to commit "fa9ca8a" , it was added to fix Coverity case.
So, I decided to keep the free call under if statement if variable is NULL.
If a different fix is required, please advise and I can change and resend.
Thanks !
fs/ext4/ext4fs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 4b36a3e..2a28031 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
int ext4fs_ls(const char *dirname)
{
- struct ext2fs_node *dirnode;
+ struct ext2fs_node *dirnode = NULL;
int status;
if (dirname == NULL)
@@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
FILETYPE_DIRECTORY);
if (status != 1) {
printf("** Can not find directory. **\n");
- ext4fs_free_node(dirnode, &ext4fs_root->diropen);
+ if (dirnode)
+ ext4fs_free_node(dirnode, &ext4fs_root->diropen);
return 1;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: fix off-by-one bug in efi_get_variable
On 05/09/2018 12:50 AM, Ivan Gorinov wrote:
efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.
Signed-off-by: Ivan Gorinov
Thanks for the patch.
There other issues we might want to fix:
If the blob has an uneven number of hexadecimal digits 2 N + 1 the
function hex2mem is called with count = 2 N + 2. hex('\0') will return
-1, hex2mem returns NULL, and the blob is happily considered as correct.
We should create an error instead.
There is no need for the argument count at all as hexstr is '\0' terminated.
---
lib/efi_loader/efi_variable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..d031338 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -68,11 +68,11 @@ static const char *hex2mem(u8 *mem, const char *hexstr, int
count)
do {
int nibble;
- *mem = 0;
-
if (!count || !*hexstr)
break;
+ *mem = 0;
+
Why should we have this line at all? We set *mem = nibble below.
Regards
Heinrich
nibble = hex(*hexstr);
if (nibble < 0)
break;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: sama5d2_xplained: enable ext4 command support
To support loading the zImage + DTB from the rootfs ext4 partitions, enable the ext4 command support. Based on original work by Wenyou Yang Signed-off-by: Eugen Hristev --- configs/sama5d2_xplained_mmc_defconfig | 1 + configs/sama5d2_xplained_spiflash_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/sama5d2_xplained_mmc_defconfig b/configs/sama5d2_xplained_mmc_defconfig index 066fdb3..6d1dc92 100644 --- a/configs/sama5d2_xplained_mmc_defconfig +++ b/configs/sama5d2_xplained_mmc_defconfig @@ -34,6 +34,7 @@ CONFIG_CMD_SF=y CONFIG_CMD_USB=y CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y +CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y diff --git a/configs/sama5d2_xplained_spiflash_defconfig b/configs/sama5d2_xplained_spiflash_defconfig index 87bca1f..f4333ea 100644 --- a/configs/sama5d2_xplained_spiflash_defconfig +++ b/configs/sama5d2_xplained_spiflash_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_SF=y CONFIG_CMD_USB=y CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y +CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] ARM: mvebu: a38x: updates to ddr training code
Hi Chris, On 09.04.2018 12:12, Chris Packham wrote: This series updates the ddr training code in u-boot with the latest publicly available version from Marvell which can be found at https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git (mv_ddr-armada-17.10 branch). I've tried to make the delta as small as possible without breaking bisect-ability. The first 2 patches have already been sent as http://patchwork.ozlabs.org/patch/894866/ and http://patchwork.ozlabs.org/patch/894865/ The bulk of the changes are in patch 4. Naturally this doesn't pass checkpatch.pl but I'm erring on the side of being able to diff with the upstream source. Also due to it's size this patch may not make it to the mailing list so the full series can be retrieved from the mv-ddr branch of https://github.com/cpackham/u-boot.git. I've tested this series on the db-88f6820-amc board and on a custom board that is not upstream (yet). I've also build tested the other a38x boards. More testing on actual hardware would be greatly appreciated. Changes in v2: - remove unused #include Many thanks for working on this. I tried to apply the patches today but failed. Most likely the license SPDX tag changes recently applied are the problem. Could you please rebase again against latest master and re-send? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org
On 08.05.2018 02:50, Tom Rini wrote:
> From: Daniel Schwierzeck
>
> Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
>
> Also use a regex for matching the tarball names. Some gcc versions
> use '-ARCH-' instead of '_ARCH-'.
>
> As part of this, we switch TravisCI to also using these toolchains for
> all platforms.
>
> Signed-off-by: Daniel Schwierzeck
> Signed-off-by: Tom Rini
> ---
> Changes in v2:
> - Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions. Update
> .travis.yml for x86_64 toolchain and fetch all toolchains.
> - Fold in the old patch I had to expand and update SH builds as we
> cannot build without those changes.
> ---
> .travis.yml | 38 ++
> tools/buildman/toolchain.py | 6 +++---
> 2 files changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 57f38e11698b..b07ce9b8ceb4 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -21,7 +21,6 @@ addons:
> - python-virtualenv
> - swig
> - libpython-dev
> -- gcc-powerpc-linux-gnu
> - iasl
> - grub-efi-ia32-bin
> - rpm2cpio
> @@ -29,6 +28,11 @@ addons:
> - device-tree-compiler
> - lzop
>
> +before_install:
> + - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
> + - sudo apt-get update -q
> + - sudo apt-get install libisl15 -y
> +
> install:
> # Clone uboot-test-hooks
> - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git
> /tmp/uboot-test-hooks
> @@ -36,10 +40,8 @@ install:
> - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
> # prepare buildman environment
> - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
> - - echo -e "aarch64 =
> /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" >> ~/.buildman
> - - echo -e "arm = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf"
> >> ~/.buildman
> - echo -e "arc =
> /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" >> ~/.buildman
> - - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
> + - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
> - cat ~/.buildman
> - virtualenv /tmp/venv
> - . /tmp/venv/bin/activate
> @@ -64,10 +66,10 @@ before_script:
>- if [[ "${TOOLCHAIN}" == *microblaze* ]]; then ./tools/buildman/buildman
> --fetch-arch microblaze ; fi
>- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman
> --fetch-arch mips ; fi
>- if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman
> --fetch-arch or32 ; fi
> - - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman
> --fetch-arch sh4 ; fi
> + - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman
> --fetch-arch sh2 ; fi
>- if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
>./tools/buildman/buildman --fetch-arch x86_64;
> - echo -e "\n[toolchain-prefix]\nx86 =
> ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> >> ~/.buildman;
> + echo -e "\n[toolchain-prefix]\nx86 =
> ${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> >> ~/.buildman;
you could add "x86 = x86_64" to section [toolchain-alias] to avoid
hard-coding this
> fi
>- if [[ "${TOOLCHAIN}" == arc ]]; then
> wget
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-release/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
> &&
> @@ -80,11 +82,10 @@ before_script:
> fi
># If TOOLCHAIN is unset, we're on some flavour of ARM.
>- if [[ "${TOOLCHAIN}" == "" ]]; then
> - wget
> http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/aarch64-linux-gnu/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz
> &&
> - wget
> http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz
> &&
> - tar -C /tmp -xf
> gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz &&
> - tar -C /tmp -xf
> gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz;
> + ./tools/buildman/buildman --fetch-arch arm &&
> + ./tools/buildman/buildman --fetch-arch aarch64;
> fi
> + - if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman
> --fetch-arch powerpc; fi
>- if [[ "${TOOLCHAIN}" == "riscv" ]]; then
> wget
> https://github.com/PkmX/riscv-prebuilt-toolchains/releases/download/20180111/riscv32-unknown-elf-toolchain.tar.gz
> &&
> tar -C /tmp -xf riscv32-unknown-elf-toolchain.tar.gz &&
> @@ -227,26 +228,37 @@ matrix:
>TOOLCHAIN="mips"
> - env:
> - BUILDMAN="mpc83xx"
> + TOOLCHAIN="powerpc"
> - env:
> - BUILDMAN="mpc85xx -x freescale"
> + TOOLCHAIN="powerpc"
> - env:
> - BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x p1_p2_rdb_pc -x
> p1010rdb -x corenet_ds -x b4860qds -x sbc8548 -x bsc
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 1:22 PM
>> To: Siva Durga Prasad Paladugu
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>> wrote:
>> >
>> > Hi,
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >> To: Siva Durga Prasad Paladugu
>> >> Cc: Jagan Teki ; U-Boot-Denx > >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> for ZynqMP qspi driver
>> >>
>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >> wrote:
>> >> > Hi Jagan,
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >> >> To: Siva Durga Prasad Paladugu
>> >> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> >> ZynqMP
>> >> >> qspi driver
>> >> >>
>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >> >> wrote:
>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>> >> >> > is responsible for communicating with qspi flash devices.
>> >> >> >
>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >> >> >
>> >> >> > ---
>> >> >> > Changes for v3:
>> >> >> > - Renamed all macros, functions, files and configs as per
>> >> >> > comment
>> >> >> > - Used wait_for_bit wherever required
>> >> >> > - Removed unnecessary header inclusion
>> >> >> >
>> >> >> > Changes for v2:
>> >> >> > - Rebased on top of latest master
>> >> >> > - Moved macro definitions to .h file as per comment
>> >> >> > - Fixed magic values with macros as per comment
>> >> >> > ---
>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>> ++
>> >> >> > drivers/spi/Kconfig | 7 +
>> >> >> > drivers/spi/Makefile| 1 +
>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
>> >> >>
>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
>> >> >> > arch/arm/include/asm/arch-
>> >> >> zynqmp/zynqmp_gqspi.h
>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >> >> >
>> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >>
>> >> >> already asked you to move this header code in driver .c file
>> >> >
>> >> > You might have missed my reply to your earlier comment on this.
>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >> > I don’t have any issue in having them anywhere. Let me know your
>> choice.
>> >>
>> >> I'm trying to align Linux code, better to move like that and make
>> >> sure to use similar macros.
>> >>
>> >> >
>> >
>> > [snip]
>> >
>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>> >> *priv) {
>> >> >> > + u8 command = 1;
>> >> >> > + u32 gen_fifo_cmd;
>> >> >> > + u32 bytecount = 0;
>> >> >> > +
>> >> >> > + while (priv->len) {
>> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>> >> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
>> >> >> > +
>> >> >> > + if (command) {
>> >> >> > + command = 0;
>> >> >> > + last_cmd = *(u8 *)priv->tx_buf;
>> >> >> > + }
>> >> >>
>> >> >> don't understand this code can you explain? command assigned 1 it
>> >> >> will not updated anywhere?
>> >> >
>> >> > I want to store last command sent. As the first byte in loop only
>> >> > contains command, it ensures it fills only for one time and next
>> >> > time it
>> >> may contain data to be sent along with command.
>> >> > Command initialized to 1 while declaring it above(u8 command = 1).
>> >>
>> >> Ok the first TX buf has command and reused in tx and rx fifo, how
>> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
>> >
>> > This holds the command that was sent last to the device before we use in
>> tx/rx fill, hence used this name.
>>
>> ie. what I wonder, usually the spi transfer start with cmd + data in that
>> case
>> it would be the first command, did gqspi work reverse way?
>
> It's also same as others :-), the last_cmd holds the recent command that was
> sent to the device.
> Its just name. To avoid confusion, I can use other names like "cmd_sent or
> cmd_recent". Hope this is ok for you or suggest which
> one would be appropriate.
Let's park the naming aside.
u8 command = 0;
while (priv->len) {
gen_fifo_cmd = zynqmp_
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 4:08 PM, Jagan Teki wrote:
> On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> wrote:
>> Hi Jagan,
>>
>>> -Original Message-
>>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>>> Sent: Wednesday, May 09, 2018 1:22 PM
>>> To: Siva Durga Prasad Paladugu
>>> Cc: Jagan Teki ; U-Boot-Denx >> b...@lists.denx.de>; michal.si...@xilinx.com
>>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> ZynqMP qspi driver
>>>
>>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> >> -Original Message-
>>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>>> >> To: Siva Durga Prasad Paladugu
>>> >> Cc: Jagan Teki ; U-Boot-Denx >> >> b...@lists.denx.de>; michal.si...@xilinx.com
>>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>>> >> for ZynqMP qspi driver
>>> >>
>>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>>> >> wrote:
>>> >> > Hi Jagan,
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>>> >> >> To: Siva Durga Prasad Paladugu
>>> >> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> >> ZynqMP
>>> >> >> qspi driver
>>> >> >>
>>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>>> >> >> wrote:
>>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>>> >> >> > is responsible for communicating with qspi flash devices.
>>> >> >> >
>>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>>> >> >> >
>>> >> >> > ---
>>> >> >> > Changes for v3:
>>> >> >> > - Renamed all macros, functions, files and configs as per
>>> >> >> > comment
>>> >> >> > - Used wait_for_bit wherever required
>>> >> >> > - Removed unnecessary header inclusion
>>> >> >> >
>>> >> >> > Changes for v2:
>>> >> >> > - Rebased on top of latest master
>>> >> >> > - Moved macro definitions to .h file as per comment
>>> >> >> > - Fixed magic values with macros as per comment
>>> >> >> > ---
>>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>>> ++
>>> >> >> > drivers/spi/Kconfig | 7 +
>>> >> >> > drivers/spi/Makefile| 1 +
>>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
>>> >> >>
>>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
>>> >> >> > arch/arm/include/asm/arch-
>>> >> >> zynqmp/zynqmp_gqspi.h
>>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>>> >> >> >
>>> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >>
>>> >> >> already asked you to move this header code in driver .c file
>>> >> >
>>> >> > You might have missed my reply to your earlier comment on this.
>>> >> > These were moved to .h based on comment from Lukasz in v1.
>>> >> > I don’t have any issue in having them anywhere. Let me know your
>>> choice.
>>> >>
>>> >> I'm trying to align Linux code, better to move like that and make
>>> >> sure to use similar macros.
>>> >>
>>> >> >
>>> >
>>> > [snip]
>>> >
>>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>>> >> *priv) {
>>> >> >> > + u8 command = 1;
>>> >> >> > + u32 gen_fifo_cmd;
>>> >> >> > + u32 bytecount = 0;
>>> >> >> > +
>>> >> >> > + while (priv->len) {
>>> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>>> >> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
>>> >> >> > +
>>> >> >> > + if (command) {
>>> >> >> > + command = 0;
>>> >> >> > + last_cmd = *(u8 *)priv->tx_buf;
>>> >> >> > + }
>>> >> >>
>>> >> >> don't understand this code can you explain? command assigned 1 it
>>> >> >> will not updated anywhere?
>>> >> >
>>> >> > I want to store last command sent. As the first byte in loop only
>>> >> > contains command, it ensures it fills only for one time and next
>>> >> > time it
>>> >> may contain data to be sent along with command.
>>> >> > Command initialized to 1 while declaring it above(u8 command = 1).
>>> >>
>>> >> Ok the first TX buf has command and reused in tx and rx fifo, how
>>> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
>>> >
>>> > This holds the command that was sent last to the device before we use in
>>> tx/rx fill, hence used this name.
>>>
>>> ie. what I wonder, usually the spi transfer start with cmd + data in that
>>> case
>>> it would be the first command, did gqspi work reverse way?
>>
>> It's also same as others :-), the last_cmd holds the recent command that was
>> sent to the device.
>> Its just name. To avoid confusion, I can use other names like "cmd_sent or
>> cmd_recent". Ho
[U-Boot] [PATCH v2 1/3] spi: sh_qspi: full DM conversion
v1->v2
New in v2
update Kconfig
replace __sh_qspi_setup to sh_qspi_setup
add missing memeber of platform data
Signed-off-by: Akash Gajjar
---
drivers/spi/Kconfig| 12 +-
drivers/spi/sh_qspi.c | 49 +++---
include/dm/platform_data/qspi_sh.h | 4
3 files changed, 31 insertions(+), 34 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84..81079c5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,12 @@ config SANDBOX_SPI
};
};
+config SH_QSPI
+ bool "Renesas Quad SPI driver"
+ help
+ Enable the Renesas Quad SPI controller driver. This driver can be
+ used on Renesas SoCs.
+
config STM32_QSPI
bool "STM32F7 QSPI driver"
depends on STM32F7
@@ -259,12 +265,6 @@ config SH_SPI
Enable the SuperH SPI controller driver. This driver can be used
on various SuperH SoCs, such as SH7757.
-config SH_QSPI
- bool "Renesas Quad SPI driver"
- help
- Enable the Renesas Quad SPI controller driver. This driver can be
- used on Renesas SoCs.
-
config TI_QSPI
bool "TI QSPI driver"
help
diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index 5fdd52e..b81cee5 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -77,49 +77,48 @@ struct sh_qspi_priv {
struct sh_qspi_regs *regs;
};
-static int __sh_qspi_setup(struct sh_qspi_priv *priv)
+static void sh_qspi_setup(struct sh_qspi_priv *priv)
{
- /* QSPI initialize */
- priv->regs = (struct sh_qspi_regs *)SH_QSPI_BASE;
+ struct sh_qspi_regs *regs = priv->regs;
/* Set master mode only */
- writeb(SPCR_MSTR, &priv->regs->spcr);
+ writeb(SPCR_MSTR, ®s->spcr);
/* Set SSL signal level */
- writeb(0x00, &priv->regs->sslp);
+ writeb(0x00, ®s->sslp);
/* Set MOSI signal value when transfer is in idle state */
- writeb(SPPCR_IO3FV | SPPCR_IO2FV, &priv->regs->sppcr);
+ writeb(SPPCR_IO3FV | SPPCR_IO2FV, ®s->sppcr);
/* Set bit rate. See 58.3.8 Quad Serial Peripheral Interface */
- writeb(0x01, &priv->regs->spbr);
+ writeb(0x01, ®s->spbr);
/* Disable Dummy Data Transmission */
- writeb(0x00, &priv->regs->spdcr);
+ writeb(0x00, ®s->spdcr);
/* Set clock delay value */
- writeb(0x00, &priv->regs->spckd);
+ writeb(0x00, ®s->spckd);
/* Set SSL negation delay value */
- writeb(0x00, &priv->regs->sslnd);
+ writeb(0x00, ®s->sslnd);
/* Set next-access delay value */
- writeb(0x00, &priv->regs->spnd);
+ writeb(0x00, ®s->spnd);
/* Set equence command */
- writew(SPCMD_INIT2, &priv->regs->spcmd0);
+ writew(SPCMD_INIT2, ®s->spcmd0);
/* Reset transfer and receive Buffer */
- setbits_8(&priv->regs->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
+ setbits_8(®s->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
/* Clear transfer and receive Buffer control bit */
- clrbits_8(&priv->regs->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
+ clrbits_8(®s->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
/* Set equence control method. Use equence0 only */
- writeb(0x00, &priv->regs->spscr);
+ writeb(0x00, ®s->spscr);
/* Enable SPI function */
- setbits_8(&priv->regs->spcr, SPCR_SPE);
+ setbits_8(®s->spcr, SPCR_SPE);
}
static int sh_qspi_set_speed(struct udevice *bus, uint hz)
@@ -156,7 +155,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int
bitlen,
if (dout == NULL && din == NULL) {
if (flags & SPI_XFER_END)
- spi_cs_deactivate(regs);
+ spi_cs_deactivate(regs);/* TODO */
return 0;
}
@@ -168,7 +167,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int
bitlen,
nbyte = bitlen / 8;
if (flags & SPI_XFER_BEGIN) {
- spi_cs_activate(regs);
+ spi_cs_activate(regs); /* TODO */
/* Set 1048576 byte */
writel(0x10, spbmul0);
@@ -219,7 +218,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int
bitlen,
}
if (flags & SPI_XFER_END)
- spi_cs_deactivate(regs);
+ spi_cs_deactivate(regs);/* TODO */
return ret;
}
@@ -229,7 +228,9 @@ static int sh_qspi_probe(struct udevice *bus)
struct sh_qspi_platdata *plat = bus->platdata;
struct sh_qspi_priv *priv = dev_get_priv(bus);
- __sh_qspi_setup(priv);
+ priv->regs = plat->regs;
+
+ sh_qspi_setup(priv);
return 0;
}
@@ -252,14 +253,14 @@ static int sh_qspi_ofdata_to_platadata(struct udevice
*bus)
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
- plat->cs = fdtdec_get_in
[U-Boot] [PATCH v2 2/3] spi: sh_spi: full DM conversion
v1->v2
New in v2
add cs_info method
remove fixed regs address
add missing platform struct missing member
moved priv struct into sh_spi.c
remove unnecessary space and comments
Signed-off-by: Akash Gajjar
---
drivers/spi/sh_spi.c | 44 +++
drivers/spi/sh_spi.h | 4
include/dm/platform_data/spi_sh.h | 5 -
3 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/sh_spi.c b/drivers/spi/sh_spi.c
index b308ec8..db14031 100644
--- a/drivers/spi/sh_spi.c
+++ b/drivers/spi/sh_spi.c
@@ -2,7 +2,7 @@
* SH SPI driver
*
* Support for device model:
- * Copyright (C) 2018 Akash Gajjar
+ * Copyright (C) 2018 Akash Gajjar
* Harshit Shah
*
* Copyright (C) 2011-2012 Renesas Solutions Corp.
@@ -19,6 +19,11 @@
#include
#include "sh_spi.h"
+struct sh_spi_priv {
+ struct sh_spi_regs *regs;
+ u32 cs;
+};
+
static void sh_spi_write(unsigned long data, unsigned long *reg)
{
writel(data, reg);
@@ -86,10 +91,11 @@ static void sh_spi_set_cs(struct sh_spi_regs *regs,
unsigned int cs)
sh_spi_set_bit(val, ®s->cr4);
}
-static void __spi_setup(struct sh_spi_regs *regs, uint cs)
+static void spi_setup(struct sh_spi_priv *priv)
{
- /* initialize spi */
- regs = (struct sh_spi_regs *)CONFIG_SH_SPI_BASE;
+ struct sh_spi_regs *regs = priv->regs;
+ u32 cs = priv->cs;
+
/* SPI sycle stop */
sh_spi_write(0xfe, ®s->cr1);
/* CR1 init */
@@ -106,7 +112,7 @@ static void __spi_setup(struct sh_spi_regs *regs, uint cs)
}
static int sh_spi_send(struct sh_spi_regs *regs, const unsigned char *tx_data,
- unsigned int len, unsigned long flags)
+ unsigned int len, unsigned long flags)
{
int i, cur_len, ret = 0;
int remain = (int)len;
@@ -151,7 +157,7 @@ static int sh_spi_send(struct sh_spi_regs *regs, const
unsigned char *tx_data,
}
static int sh_spi_receive(struct sh_spi_regs *regs, unsigned char *rx_data,
- unsigned int len, unsigned long flags)
+ unsigned int len, unsigned long flags)
{
int i;
@@ -227,12 +233,29 @@ static int sh_spi_xfer(struct udevice *dev, unsigned int
bitlen,
return ret;
}
+static int sh_spi_cs_info(struct udevice *bus, uint cs,
+ struct spi_cs_info *info)
+{
+ struct sh_spi_priv *priv = dev_get_priv(bus);
+
+ if (cs >= priv->cs) {
+ printf("no cs %u\n", cs);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
static int sh_spi_probe(struct udevice *bus)
{
+ struct sh_spi_platdata *plat = bus->platdata;
struct sh_spi_priv *priv = dev_get_priv(bus);
struct sh_spi_regs *regs = priv->regs;
- __spi_setup(regs, priv->cs);
+ priv->regs = plat->regs;
+ priv->cs = plat->cs;
+
+ spi_setup(priv);
return 0;
}
@@ -248,8 +271,9 @@ static int sh_spi_ofdata_to_platadata(struct udevice *bus)
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
+ plat->regs = (struct sh_spi_regs *regs)addr;
plat->cs = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
- "num-cs", 4);
+ "num-cs", 4);
return 0;
}
@@ -259,10 +283,12 @@ static const struct dm_spi_ops mvebu_spi_ops = {
.xfer = sh_spi_xfer,
.set_speed = sh_spi_set_speed,
.set_mode = sh_spi_set_mode,
+ .cs_info= sh_spi_cs_info,
};
+/* TODO: update compatible device tree */
static const struct udevice_id sh_spi_ids[] = {
- { .compatible = "sh,sh_spi" },
+ { .compatible = " " },
};
#endif
diff --git a/drivers/spi/sh_spi.h b/drivers/spi/sh_spi.h
index 87a253f..f945744 100644
--- a/drivers/spi/sh_spi.h
+++ b/drivers/spi/sh_spi.h
@@ -55,10 +55,6 @@ struct sh_spi_regs {
#define SH_SPI_FIFO_SIZE 32
#define SH_SPI_NUM_CS 4
-struct sh_spi_priv {
- struct sh_spi_regs *regs;
-};
-
static inline struct sh_spi *to_sh_spi(struct spi_slave *slave)
{
return container_of(slave, struct sh_spi, slave);
diff --git a/include/dm/platform_data/spi_sh.h
b/include/dm/platform_data/spi_sh.h
index b4d63dc..c6d0ac5 100644
--- a/include/dm/platform_data/spi_sh.h
+++ b/include/dm/platform_data/spi_sh.h
@@ -2,16 +2,11 @@
* Copyright (C) 2018 Akash Gajjar
*
* SPDX-License-Identifier:GPL-2.0+
- *
*/
#ifndef __spi_sh_h
#define __spi_sh_h
-/*
- * struct sh_spi_platdata - information about a sh spi module
- *
- */
struct sh_spi_platdata {
struct sh_spi_regs *regs;
u8 cs;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/1] spi: lpc32xx_ssp: DM conversion
From: Akash Gajjar
This patch adds support for DM to the LPC32xx SSP SPI driver.
Some TODOs are left over for later, These would be enhancements to the
original functionality, and can come later. The legacy functionality is
removed in this version.
Signed-off-by: Akash Gajjar
---
drivers/spi/Kconfig| 10 +-
drivers/spi/lpc32xx_ssp.c | 145 +++--
include/dm/platform_data/spi_lpc32xx_ssp.h | 15 +++
3 files changed, 93 insertions(+), 77 deletions(-)
create mode 100644 include/dm/platform_data/spi_lpc32xx_ssp.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84..2297d4a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -99,6 +99,11 @@ config ICH_SPI
access the SPI NOR flash on platforms embedding this Intel
ICH IP core.
+config LPC32XX_SSP
+ bool "LPC32XX SPI Driver"
+ help
+ Enable support for SPI on LPC32xx
+
config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
help
@@ -277,11 +282,6 @@ config KIRKWOOD_SPI
Enable support for SPI on various Marvell SoCs, such as
Kirkwood and Armada 375.
-config LPC32XX_SSP
- bool "LPC32XX SPI Driver"
- help
- Enable support for SPI on LPC32xx
-
config MPC8XX_SPI
bool "MPC8XX SPI Driver"
depends on MPC8xx
diff --git a/drivers/spi/lpc32xx_ssp.c b/drivers/spi/lpc32xx_ssp.c
index e2a593b..ae41b57 100644
--- a/drivers/spi/lpc32xx_ssp.c
+++ b/drivers/spi/lpc32xx_ssp.c
@@ -4,6 +4,9 @@
* (C) Copyright 2014 DENX Software Engineering GmbH
* Written-by: Albert ARIBAUD
*
+ * Support for device model:
+ * Copyright (C) 2018 Akash Gajjar
+ *
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -13,6 +16,8 @@
#include
#include
#include
+#include
+#include
/* SSP chip registers */
struct ssp_regs {
@@ -36,90 +41,36 @@ struct ssp_regs {
/* SSP status RX FIFO not empty bit */
#define SSP_SR_RNE 0x0004
-/* lpc32xx spi slave */
-struct lpc32xx_spi_slave {
- struct spi_slave slave;
+struct lpc32xx_ssp_spi_priv {
struct ssp_regs *regs;
};
-static inline struct lpc32xx_spi_slave *to_lpc32xx_spi_slave(
- struct spi_slave *slave)
+static int lpc32xx_ssp_spi_claim_bus(struct udevice *dev)
{
- return container_of(slave, struct lpc32xx_spi_slave, slave);
-}
-
-/* spi_init is called during boot when CONFIG_CMD_SPI is defined */
-void spi_init(void)
-{
- /*
-* nothing to do: clocking was enabled in lpc32xx_ssp_enable()
-* and configuration will be done in spi_setup_slave()
- */
+ return 0;
}
-/* the following is called in sequence by do_spi_xfer() */
-
-struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
+static int lpc32xx_ssp_spi_release_bus(struct udevice *dev)
{
- struct lpc32xx_spi_slave *lslave;
-
- /* we only set up SSP0 for now, so ignore bus */
-
- if (mode & SPI_3WIRE) {
- pr_err("3-wire mode not supported");
- return NULL;
- }
-
- if (mode & SPI_SLAVE) {
- pr_err("slave mode not supported\n");
- return NULL;
- }
-
- if (mode & SPI_PREAMBLE) {
- pr_err("preamble byte skipping not supported\n");
- return NULL;
- }
-
- lslave = spi_alloc_slave(struct lpc32xx_spi_slave, bus, cs);
- if (!lslave) {
- printf("SPI_error: Fail to allocate lpc32xx_spi_slave\n");
- return NULL;
- }
-
- lslave->regs = (struct ssp_regs *)SSP0_BASE;
-
- /*
-* 8 bit frame, SPI fmt, 500kbps -> clock divider is 26.
-* Set SCR to 0 and CPSDVSR to 26.
-*/
-
- writel(0x7, &lslave->regs->cr0); /* 8-bit chunks, SPI, 1 clk/bit */
- writel(26, &lslave->regs->cpsr); /* SSP clock = HCLK/26 = 500kbps */
- writel(0, &lslave->regs->imsc); /* do not raise any interrupts */
- writel(0, &lslave->regs->icr); /* clear any pending interrupt */
- writel(0, &lslave->regs->dmacr); /* do not do DMAs */
- writel(SSP_CR1_SSP_ENABLE, &lslave->regs->cr1); /* enable SSP0 */
- return &lslave->slave;
+ return 0;
}
-void spi_free_slave(struct spi_slave *slave)
+static int lpc32xx_ssp_spi_set_speed(struct udevice *bus, uint hz)
{
- struct lpc32xx_spi_slave *lslave = to_lpc32xx_spi_slave(slave);
-
- debug("(lpc32xx) spi_free_slave: 0x%08x\n", (u32)lslave);
- free(lslave);
+ return 0;
}
-int spi_claim_bus(struct spi_slave *slave)
+static int lpc32xx_ssp_spi_set_mode(struct udevice *bus, uint mode)
{
- /* only one bus and slave so far, always available */
return 0;
}
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
- const void *dout, void *din, unsigned long flags)
+static int lpc32xx_ssp_spi_xfer(struct udevice *dev, uint bitlen,
+ const void *dout, void *din, ulon
[U-Boot] [PATCH v2 3/3] spi: mxs_spi: full dm conversion
v1->v2
register cs_info method
remove unused function __mxs_spi_setup
merged __spi_xfer function to spi_xfer
printf replaced by debug
Signed-off-by: Akash Gajjar
---
drivers/spi/mxs_spi.c | 169 --
1 file changed, 81 insertions(+), 88 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 0af2eee..3054438 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -82,7 +82,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
if (mxs_wait_mask_set(&ssp_regs->hw_ssp_ctrl0_reg,
SSP_CTRL0_RUN, MXS_SPI_MAX_TIMEOUT)) {
- printf("MXS SPI: Timeout waiting for start\n");
+ debug("MXS SPI: Timeout waiting for start\n");
return -ETIMEDOUT;
}
@@ -94,7 +94,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
if (!write) {
if (mxs_wait_mask_clr(&ssp_regs->hw_ssp_status_reg,
SSP_STATUS_FIFO_EMPTY, MXS_SPI_MAX_TIMEOUT)) {
- printf("MXS SPI: Timeout waiting for data\n");
+ debug("MXS SPI: Timeout waiting for data\n");
return -ETIMEDOUT;
}
@@ -104,7 +104,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
if (mxs_wait_mask_clr(&ssp_regs->hw_ssp_ctrl0_reg,
SSP_CTRL0_RUN, MXS_SPI_MAX_TIMEOUT)) {
- printf("MXS SPI: Timeout waiting for finish\n");
+ debug("MXS SPI: Timeout waiting for finish\n");
return -ETIMEDOUT;
}
}
@@ -233,78 +233,6 @@ static int mxs_spi_xfer_dma(struct mxs_spi_priv *priv,
return ret;
}
-static int __spi_xfer(struct mxs_spi_priv *priv, unsigned int bitlen,
- const void *dout, void *din, unsigned long flags)
-{
- struct mxs_ssp_regs *ssp_regs = priv->regs;
- int len = bitlen / 8;
- char dummy;
- int write = 0;
- char *data = NULL;
- int dma = 1;
-
- if (bitlen == 0) {
- if (flags & SPI_XFER_END) {
- din = (void *)&dummy;
- len = 1;
- } else
- return 0;
- }
-
- /* Half-duplex only */
- if (din && dout)
- return -EINVAL;
- /* No data */
- if (!din && !dout)
- return 0;
-
- if (dout) {
- data = (char *)dout;
- write = 1;
- } else if (din) {
- data = (char *)din;
- write = 0;
- }
-
- /*
-* Check for alignment, if the buffer is aligned, do DMA transfer,
-* PIO otherwise. This is a temporary workaround until proper bounce
-* buffer is in place.
-*/
- if (dma) {
- if (((uint32_t)data) & (ARCH_DMA_MINALIGN - 1))
- dma = 0;
- if (((uint32_t)len) & (ARCH_DMA_MINALIGN - 1))
- dma = 0;
- }
-
- if (!dma || (len < MXSSSP_SMALL_TRANSFER)) {
- writel(SSP_CTRL1_DMA_ENABLE, &ssp_regs->hw_ssp_ctrl1_clr);
- return mxs_spi_xfer_pio(priv, data, len, write, flags);
- } else {
- writel(SSP_CTRL1_DMA_ENABLE, &ssp_regs->hw_ssp_ctrl1_set);
- return mxs_spi_xfer_dma(priv, data, len, write, flags);
- }
-}
-
-static int __mxs_spi_setup(struct mxs_spi_priv *mxs_spi, uint bus)
-{
- struct mxs_spi_priv *priv = mxs_spi;
- int err;
-
- priv->max_khz = max_hz / 1000;
- priv->mode = mode;
- priv->regs = mxs_ssp_regs_by_bus(bus);
- priv->bus = bus;
-
- if (mxs_dma_init_channel(MXS_DMA_CHANNEL_AHB_APBH_SSP0 + priv->bus)) {
- printf("%s: DMA init channel error %d\n", __func__, err);
- return err;
- }
-
- return 0;
-}
-
static int mxs_spi_claim_bus(struct udevice *dev)
{
struct udevice *bus = dev_get_parent(dev);
@@ -321,8 +249,6 @@ static int mxs_spi_claim_bus(struct udevice *dev)
static int mxs_spi_release_bus(struct udevice *dev)
{
- /* TODO */
-
return 0;
}
@@ -335,7 +261,7 @@ static int mxs_spi_set_speed(struct udevice *bus, uint
speed)
speed = plat->max_khz;
priv->max_khz = speed;
- printf("%s speed %u\n", __func__, speed);
+ debug("%s speed %u\n", __func__, speed);
mxs_set_ssp_busclock(plat->bus, priv->max_khz);
@@ -348,8 +274,8 @@ static int mxs_spi_set_mode(struct udevice *bus, uint mode)
struct mxs_ssp_regs *ssp_regs = priv->regs;
u32 reg;
- printf("%s mode %u\n", __func__, mode);
priv->mode = mode;
+ debug("%s mode %u\n", __func__, mode);
reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug
Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian: On 2018-05-08, Vagrant Cascadian wrote: On 2018-05-05, Tom Rini wrote: On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote: Markus Krebs discovered that the sheevaplug target has again grown and installation overlaps where the u-boot env is saved since u-boot ~2017.09. Running saveenv overwrites u-boot, and installing u-boot overwrites any prior environment settings. ... I've added the maintainer to the list as well. I would suggest looking for things to trim out, perhaps CMD_MEMTEST ? Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a *lot* left to disable in the config, but that's a significant start... And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it down to 432k! Thanks to beeble for the suggestion. Anyone who has a sheevaplug can test that it actually boots with CONFIG_SYS_THUMB_BUILD=y enabled? I could test it, but I don't know the config-file where I can change those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
Masahiro, Tom, Petr,
Thanks for your prompt feedback.
> On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > I prefer syncing to check-picking.
> > [...]
> > Would you do that please?
> > Or, do you want me to do it?
I would happily attempt that. However, see my below question.
On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
Just to avoid any miscommunication, is my understanding correct that
this is an explicit request for Masahiro to take care of the update? I
would totally understand this.
FWIW, here is some statistics of the kernel kconfig development in the
v4.10..v4.17-rc4 commit range:
- 86 non-merge change-sets:
git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
86
- 8 Kconfig commits which touch non-Kconfig files too (ignoring
Documentation) and hence might require more delicate conflict
resolution:
for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 --
scripts/kconfig/); do
if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig |
egrep -v "scripts/kconfig|Documentation" > /dev/null); then
git --no-pager log --oneline $c -1;
fi;
done
cb77f0d623ff scripts: Switch to more portable Perl shebang
bb3290d91695 Remove gperf usage from toolchain
b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files with
no license
07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
911a91c39cab kconfig: rename silentoldconfig to syncconfig
598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the top-level
.gitignore
9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level
Makefile
b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
I also think that the most sensitive part of this update is related to:
- changed tooling requirements for hosts, e.g. flex and bison seem to
be required starting with commit 29c833061c1d ("kconfig: generate
lexer and parser during build instead of shipping").
- dropped silentoldconfig support, starting with commit cedd55d49dee
("kconfig: Remove silentoldconfig from help and docs; fix
kconfig/conf's help").
There might be questions from users experiencing build errors/warnings
after the update, same as we've seen in [1].
[1] https://patchwork.kernel.org/patch/10318503/
I would appreciate if Tom answers the question raised in the beginning
of my post.
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] board: sunxi: sun8i-v4: Add Bananapi M2 Berry support
On Wed, May 2, 2018 at 2:46 PM, Maxime Ripard wrote: > On Fri, Apr 27, 2018 at 05:33:42PM +0530, Jagan Teki wrote: >> Banana Pi BPI-M2 Berry is a quad-core mini single board computer >> built with Allwinner V40 SoC. It features >> - Quad Core ARM Cortex A7 CPU V40 >> - 1GB of RAM . >> - microSD/SATA port.. >> - onboard WiFi and BT >> - 4 USB A 2.0 ports >> - 1 USB OTG port >> - 1 HDMI port >> - 1 audio jack >> - DC power port >> >> Signed-off-by: Jagan Teki > > There's a typo in your commit title, it should be v40 and not > v4. Otherwise it looks good, > Acked-by: Maxime Ripard Fixed and Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ARM: dts: sun8i: Sync r40 dtsi from Linux
On Fri, Apr 27, 2018 at 5:33 PM, Jagan Teki wrote: > Sync sun8i-r40.dtsi changes from Linux with > > Merge: a406778618d0 088345fc3553 > Author: Stephen Rothwell > Date: Tue Apr 24 14:15:02 2018 +1000 > > Merge branch 'akpm/master' > > Signed-off-by: Jagan Teki > --- Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-sunxi/master
Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit b25f8e2112b1582ce6386e846800a31bab688e50: Merge git://git.denx.de/u-boot-imx (2018-04-30 07:14:05 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to f3df7758b5fb4e1f8eb8f2bbd9b9354054884502: board: sunxi: sun8i-v40: Add Bananapi M2 Berry support (2018-05-07 11:33:19 +0530) Chen-Yu Tsai (5): sunxi: Disable R_I2C for Libre Computer Board ALL-H3-CC H3 ver. sunxi: Split out common board design for ALL-H3-CC device tree sunxi: Add Libre Computer Board ALL-H3-CC H2+ ver. sunxi: Add Libre Computer Board ALL-H3-CC H5 ver. sunxi: Sort dts Makefile entries for H3 Jagan Teki (2): ARM: dts: sun8i: Sync r40 dtsi from Linux board: sunxi: sun8i-v40: Add Bananapi M2 Berry support arch/arm/dts/Makefile | 15 +- arch/arm/dts/sun50i-h5-libretech-all-h3-cc.dts | 13 ++ arch/arm/dts/sun8i-h2-plus-libretech-all-h3-cc.dts | 13 ++ arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts | 166 +- arch/arm/dts/sun8i-r40.dtsi| 43 + arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts | 132 +++ arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi| 168 ++ board/sunxi/MAINTAINERS| 9 +- configs/bananapi_m2_berry_defconfig| 14 ++ configs/libretech_all_h3_cc_h2_plus_defconfig | 15 ++ configs/libretech_all_h3_cc_h3_defconfig | 2 - configs/libretech_all_h3_cc_h5_defconfig | 15 ++ include/dt-bindings/clock/sun8i-r40-ccu.h | 187 + include/dt-bindings/reset/sun8i-r40-ccu.h | 130 ++ 14 files changed, 749 insertions(+), 173 deletions(-) create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-cc.dts create mode 100644 arch/arm/dts/sun8i-h2-plus-libretech-all-h3-cc.dts create mode 100644 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi create mode 100644 configs/bananapi_m2_berry_defconfig create mode 100644 configs/libretech_all_h3_cc_h2_plus_defconfig create mode 100644 configs/libretech_all_h3_cc_h5_defconfig create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/mtd/spi: Default page size Spansion flash "S25FS512S" is 256b
On Mon, May 7, 2018 at 4:01 PM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar
> ---
> drivers/mtd/spi/spi_flash.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 3d24a08..ce420cb 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -1046,14 +1046,15 @@ int spi_flash_scan(struct spi_flash *flash)
> flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
> flash->page_size = info->page_size;
> /*
> -* The Spansion S25FL032P and S25FL064P have 256b pages, yet use the
> -* 0x4d00 Extended JEDEC code. The rest of the Spansion flashes with
> -* the 0x4d00 Extended JEDEC code have 512b pages. All of the others
> -* have 256b pages.
> +* The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages,
> +* yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion
> +* flashes with the 0x4d00 Extended JEDEC code have 512b pages.
> +* All of the others have 256b pages.
> */
> if (JEDEC_EXT(info) == 0x4d00) {
> if ((JEDEC_ID(info) != 0x0215) &&
> - (JEDEC_ID(info) != 0x0216))
> + (JEDEC_ID(info) != 0x0216) &&
> + (JEDEC_ID(info) != 0x0220))
0220 is JEDEC ID for S25FS512S which is 512 is it? commit message says 256b?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
Hi Jagan,
> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 4:18 PM
> To: Siva Durga Prasad Paladugu
> Cc: Jagan Teki ; U-Boot-Denx b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
>
> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
> wrote:
> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> > wrote:
> >> Hi Jagan,
> >>
> >>> -Original Message-
> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >>> Sent: Wednesday, May 09, 2018 1:22 PM
> >>> To: Siva Durga Prasad Paladugu
> >>> Cc: Jagan Teki ; U-Boot-Denx >>> b...@lists.denx.de>; michal.si...@xilinx.com
> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >>> for ZynqMP qspi driver
> >>>
> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
> >>> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> >> -Original Message-
> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
> >>> >> To: Siva Durga Prasad Paladugu
> >>> >> Cc: Jagan Teki ; U-Boot-Denx >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >>> >> support for ZynqMP qspi driver
> >>> >>
> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> >>> >> wrote:
> >>> >> > Hi Jagan,
> >>> >> >
> >>> >> >> -Original Message-
> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >>> >> >> To: Siva Durga Prasad Paladugu
> >>> >> >> Cc: U-Boot-Denx ;
> >>> >> >> michal.si...@xilinx.com
> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> >>> >> ZynqMP
> >>> >> >> qspi driver
> >>> >> >>
> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >>> >> >> wrote:
> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
> >>> >> >> > driver is responsible for communicating with qspi flash devices.
> >>> >> >> >
> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >>> >> >> >
> >>> >> >> > ---
> >>> >> >> > Changes for v3:
> >>> >> >> > - Renamed all macros, functions, files and configs as per
> >>> >> >> > comment
> >>> >> >> > - Used wait_for_bit wherever required
> >>> >> >> > - Removed unnecessary header inclusion
> >>> >> >> >
> >>> >> >> > Changes for v2:
> >>> >> >> > - Rebased on top of latest master
> >>> >> >> > - Moved macro definitions to .h file as per comment
> >>> >> >> > - Fixed magic values with macros as per comment
> >>> >> >> > ---
> >>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
> >>> ++
> >>> >> >> > drivers/spi/Kconfig | 7 +
> >>> >> >> > drivers/spi/Makefile| 1 +
> >>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
> >>> >> >>
> >>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
> >>> >> >> > arch/arm/include/asm/arch-
> >>> >> >> zynqmp/zynqmp_gqspi.h
> >>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
> >>> >> >> >
> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
> zynqmp/zynqmp_gqspi.h
> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >>> >> >>
> >>> >> >> already asked you to move this header code in driver .c file
> >>> >> >
> >>> >> > You might have missed my reply to your earlier comment on this.
> >>> >> > These were moved to .h based on comment from Lukasz in v1.
> >>> >> > I don’t have any issue in having them anywhere. Let me know
> >>> >> > your
> >>> choice.
> >>> >>
> >>> >> I'm trying to align Linux code, better to move like that and make
> >>> >> sure to use similar macros.
> >>> >>
> >>> >> >
> >>> >
> >>> > [snip]
> >>> >
> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
> zynqmp_qspi_priv
> >>> >> *priv) {
> >>> >> >> > + u8 command = 1;
> >>> >> >> > + u32 gen_fifo_cmd;
> >>> >> >> > + u32 bytecount = 0;
> >>> >> >> > +
> >>> >> >> > + while (priv->len) {
> >>> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> >>> >> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
> >>> >> >> > +
> >>> >> >> > + if (command) {
> >>> >> >> > + command = 0;
> >>> >> >> > + last_cmd = *(u8 *)priv->tx_buf;
> >>> >> >> > + }
> >>> >> >>
> >>> >> >> don't understand this code can you explain? command assigned
> 1
> >>> >> >> it will not updated anywhere?
> >>> >> >
> >>> >> > I want to store last command sent. As the first byte in loop
> >>> >> > only contains command, it ensures it fills only for one time
> >>> >> > and next time it
> >>> >> may contain data to be sent along with command.
> >>> >> > Command initialized to 1 while declaring it above(u8 command =
> 1).
> >>> >>
> >>> >> Ok the first TX buf ha
Re: [U-Boot] GCC 7.x vs. C++ comments
On Wed, May 09, 2018 at 10:46:10AM +0200, Dr. Philipp Tomsich wrote: > Tom, > > I recently ran a local buildman with a came across these: > > cc -Wp,-MD,tools/.gen_eth_addr.d -Wall -Wstrict-prototypes -O2 > > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o tools/gen_eth_addr > > tools/gen_eth_addr.c > > tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in > > ISO C90 > > // SPDX-License-Identifier: GPL-2.0+ > > ^ > > tools/gen_eth_addr.c:1:1: warning: (this will be reported only once per > > input file) > > cc -Wp,-MD,tools/.gen_ethaddr_crc.o.d -Wall -Wstrict-prototypes -O2 > > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o > > tools/gen_ethaddr_crc.o tools/gen_ethaddr_crc.c > > tools/gen_ethaddr_crc.c:1:1: warning: C++ style comments are not allowed in > > ISO C90 > > // SPDX-License-Identifier: GPL-2.0+ > > ^ > > tools/gen_ethaddr_crc.c:1:1: warning: (this will be reported only once per > > input file) > > echo "#include <../lib/crc8.c>" >tools/lib/crc8.c > > cc -Wp,-MD,tools/lib/.crc8.o.d -Wall -Wstrict-prototypes -O2 > > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude > > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC > > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/lib/crc8.o > > tools/lib/crc8.c > > In file included from tools/lib/crc8.c:1:0: > > ./tools/../lib/crc8.c:1:1: warning: C++ style comments are not allowed in > > ISO C90 > > // SPDX-License-Identifier: GPL-2.0+ > > ^ > > The system compiler was a > > Using built-in specs. > > COLLECT_GCC=cc > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper > > Target: x86_64-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Debian > > 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs > > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > > --program-suffix=-4.9 --enable-shared --enable-linker-build-id > > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > > --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls > > --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug > > --enable-libstdcxx-time=yes --enable-gnu-unique-object > > --disable-vtable-verify --enable-plugin --with-system-zlib > > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre > > --enable-java-home > > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 > > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 > > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > > --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 > > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu > > --target=x86_64-linux-gnu > > Thread model: posix > > gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) > > > What’s your preferred solution: > (a) change these comments > (b) change our Makefiles to let GCC know that we are compiling > gnu99/C99? > > Neither solution is too appealing to me, so I am asking... Lets go with (b) which I guess what a more modern toolchain defaults to anyhow. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org
On Wed, May 09, 2018 at 12:27:38PM +0200, Daniel Schwierzeck wrote:
>
>
> On 08.05.2018 02:50, Tom Rini wrote:
> > From: Daniel Schwierzeck
> >
> > Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
> >
> > Also use a regex for matching the tarball names. Some gcc versions
> > use '-ARCH-' instead of '_ARCH-'.
> >
> > As part of this, we switch TravisCI to also using these toolchains for
> > all platforms.
> >
> > Signed-off-by: Daniel Schwierzeck
> > Signed-off-by: Tom Rini
> > ---
> > Changes in v2:
> > - Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions. Update
> > .travis.yml for x86_64 toolchain and fetch all toolchains.
> > - Fold in the old patch I had to expand and update SH builds as we
> > cannot build without those changes.
> > ---
> > .travis.yml | 38 ++
> > tools/buildman/toolchain.py | 6 +++---
> > 2 files changed, 29 insertions(+), 15 deletions(-)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index 57f38e11698b..b07ce9b8ceb4 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -21,7 +21,6 @@ addons:
> > - python-virtualenv
> > - swig
> > - libpython-dev
> > -- gcc-powerpc-linux-gnu
> > - iasl
> > - grub-efi-ia32-bin
> > - rpm2cpio
> > @@ -29,6 +28,11 @@ addons:
> > - device-tree-compiler
> > - lzop
> >
> > +before_install:
> > + - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
> > + - sudo apt-get update -q
> > + - sudo apt-get install libisl15 -y
> > +
> > install:
> > # Clone uboot-test-hooks
> > - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git
> > /tmp/uboot-test-hooks
> > @@ -36,10 +40,8 @@ install:
> > - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
> > # prepare buildman environment
> > - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
> > - - echo -e "aarch64 =
> > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" >> ~/.buildman
> > - - echo -e "arm =
> > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" >> ~/.buildman
> > - echo -e "arc =
> > /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" >> ~/.buildman
> > - - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
> > + - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
> > - cat ~/.buildman
> > - virtualenv /tmp/venv
> > - . /tmp/venv/bin/activate
> > @@ -64,10 +66,10 @@ before_script:
> >- if [[ "${TOOLCHAIN}" == *microblaze* ]]; then
> > ./tools/buildman/buildman --fetch-arch microblaze ; fi
> >- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman
> > --fetch-arch mips ; fi
> >- if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman
> > --fetch-arch or32 ; fi
> > - - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman
> > --fetch-arch sh4 ; fi
> > + - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman
> > --fetch-arch sh2 ; fi
> >- if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
> >./tools/buildman/buildman --fetch-arch x86_64;
> > - echo -e "\n[toolchain-prefix]\nx86 =
> > ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> > >> ~/.buildman;
> > + echo -e "\n[toolchain-prefix]\nx86 =
> > ${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> > >> ~/.buildman;
>
> you could add "x86 = x86_64" to section [toolchain-alias] to avoid
> hard-coding this
There's some amount of "fun" going on in order to build all of
arch/{sandbox,x86} with the same toolchain. I'll double check what we
can get away with in terms of toolchain-prefix vs toolchain-alias.
Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 4:18 PM
>> To: Siva Durga Prasad Paladugu
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
>> wrote:
>> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
>> > wrote:
>> >> Hi Jagan,
>> >>
>> >>> -Original Message-
>> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >>> Sent: Wednesday, May 09, 2018 1:22 PM
>> >>> To: Siva Durga Prasad Paladugu
>> >>> Cc: Jagan Teki ; U-Boot-Denx > >>> b...@lists.denx.de>; michal.si...@xilinx.com
>> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >>> for ZynqMP qspi driver
>> >>>
>> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>> >>> wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> >> -Original Message-
>> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >>> >> To: Siva Durga Prasad Paladugu
>> >>> >> Cc: Jagan Teki ; U-Boot-Denx > >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >>> >> support for ZynqMP qspi driver
>> >>> >>
>> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >>> >> wrote:
>> >>> >> > Hi Jagan,
>> >>> >> >
>> >>> >> >> -Original Message-
>> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >>> >> >> To: Siva Durga Prasad Paladugu
>> >>> >> >> Cc: U-Boot-Denx ;
>> >>> >> >> michal.si...@xilinx.com
>> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> >>> >> ZynqMP
>> >>> >> >> qspi driver
>> >>> >> >>
>> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >>> >> >> wrote:
>> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
>> >>> >> >> > driver is responsible for communicating with qspi flash devices.
>> >>> >> >> >
>> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >>> >> >> >
>> >>> >> >> > ---
>> >>> >> >> > Changes for v3:
>> >>> >> >> > - Renamed all macros, functions, files and configs as per
>> >>> >> >> > comment
>> >>> >> >> > - Used wait_for_bit wherever required
>> >>> >> >> > - Removed unnecessary header inclusion
>> >>> >> >> >
>> >>> >> >> > Changes for v2:
>> >>> >> >> > - Rebased on top of latest master
>> >>> >> >> > - Moved macro definitions to .h file as per comment
>> >>> >> >> > - Fixed magic values with macros as per comment
>> >>> >> >> > ---
>> >>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>> >>> ++
>> >>> >> >> > drivers/spi/Kconfig | 7 +
>> >>> >> >> > drivers/spi/Makefile| 1 +
>> >>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
>> >>> >> >>
>> >>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
>> >>> >> >> > arch/arm/include/asm/arch-
>> >>> >> >> zynqmp/zynqmp_gqspi.h
>> >>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >>> >> >> >
>> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
>> zynqmp/zynqmp_gqspi.h
>> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >>> >> >>
>> >>> >> >> already asked you to move this header code in driver .c file
>> >>> >> >
>> >>> >> > You might have missed my reply to your earlier comment on this.
>> >>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >>> >> > I don’t have any issue in having them anywhere. Let me know
>> >>> >> > your
>> >>> choice.
>> >>> >>
>> >>> >> I'm trying to align Linux code, better to move like that and make
>> >>> >> sure to use similar macros.
>> >>> >>
>> >>> >> >
>> >>> >
>> >>> > [snip]
>> >>> >
>> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
>> zynqmp_qspi_priv
>> >>> >> *priv) {
>> >>> >> >> > + u8 command = 1;
>> >>> >> >> > + u32 gen_fifo_cmd;
>> >>> >> >> > + u32 bytecount = 0;
>> >>> >> >> > +
>> >>> >> >> > + while (priv->len) {
>> >>> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>> >>> >> >> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
>> >>> >> >> > +
>> >>> >> >> > + if (command) {
>> >>> >> >> > + command = 0;
>> >>> >> >> > + last_cmd = *(u8 *)priv->tx_buf;
>> >>> >> >> > + }
>> >>> >> >>
>> >>> >> >> don't understand this code can you explain? command assigned
>> 1
>> >>> >> >> it will not updated anywhere?
>> >>> >> >
>> >>> >> > I want to store last command sent. As the first byte in loop
>> >>> >> > only contains command, it ensures it fills only for one time
>> >>> >> > a
Re: [U-Boot] [PATCH v2 1/3] spi: sh_qspi: full DM conversion
What I understand from this is you made changes on top of your previous patch which is wrong. Since the first patch is not accepted and request for changes you need to make changes on top. Since this is v2 you mentioned 'changes for v2' what is been fixed/updated with this version. On Wed, May 9, 2018 at 12:06 PM, Akash Gajjar wrote: > v1->v2 > New in v2 > update Kconfig > replace __sh_qspi_setup to sh_qspi_setup > add missing memeber of platform data > > Signed-off-by: Akash Gajjar > --- Changes you need to write it here? > drivers/spi/Kconfig| 12 +- > drivers/spi/sh_qspi.c | 49 > +++--- > include/dm/platform_data/qspi_sh.h | 4 > 3 files changed, 31 insertions(+), 34 deletions(-) > Send v3. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
On Wed, May 09, 2018 at 08:32:56AM +, yamada.masah...@socionext.com wrote:
> Hi Engeniu,
>
> > -Original Message-
> > From: Eugeniu Rosca [mailto:ero...@de.adit-jv.com]
> > Sent: Wednesday, May 09, 2018 5:04 PM
> > To: Tom Rini ; Yamada, Masahiro/山田 真弘
> > ; Petr Vorel
> > Cc: Ulf Magnusson ; Simon Glass ;
> > U-Boot Mailing List ; Eugeniu Rosca
> > ; Eugeniu Rosca
> > Subject: Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
> >
> > Masahiro, Tom, Petr,
> >
> > Thanks for your prompt feedback.
> >
> > > On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > > > I prefer syncing to check-picking.
> > > > [...]
> > > > Would you do that please?
> > > > Or, do you want me to do it?
> >
> > I would happily attempt that. However, see my below question.
> >
> > On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> > > I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
> >
> > Just to avoid any miscommunication, is my understanding correct that
> > this is an explicit request for Masahiro to take care of the update? I
> > would totally understand this.
> >
> > FWIW, here is some statistics of the kernel kconfig development in the
> > v4.10..v4.17-rc4 commit range:
> >
> > - 86 non-merge change-sets:
> > git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
> > 86
> >
> > - 8 Kconfig commits which touch non-Kconfig files too (ignoring
> > Documentation) and hence might require more delicate conflict
> > resolution:
> >
> > for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 --
> > scripts/kconfig/); do
> > if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig
> > |
> > egrep -v "scripts/kconfig|Documentation" > /dev/null); then
> > git --no-pager log --oneline $c -1;
> > fi;
> > done
> >
> > cb77f0d623ff scripts: Switch to more portable Perl shebang
> > bb3290d91695 Remove gperf usage from toolchain
> > b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files
> > with no license
> > 07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
> > 911a91c39cab kconfig: rename silentoldconfig to syncconfig
> > 598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the
> > top-level .gitignore
> > 9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from
> > top-level Makefile
> > b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
> >
> > I also think that the most sensitive part of this update is related to:
> > - changed tooling requirements for hosts, e.g. flex and bison seem to
> > be required starting with commit 29c833061c1d ("kconfig: generate
> > lexer and parser during build instead of shipping").
> > - dropped silentoldconfig support, starting with commit cedd55d49dee
> > ("kconfig: Remove silentoldconfig from help and docs; fix
> > kconfig/conf's help").
> >
> > There might be questions from users experiencing build errors/warnings
> > after the update, same as we've seen in [1].
> >
> > [1] https://patchwork.kernel.org/patch/10318503/
> >
> > I would appreciate if Tom answers the question raised in the beginning
> > of my post.
>
>
> Tom will make a decision.
>
> Just my thought.
>
>
> U-Boot is basically a mirror of Linux.
>
> Syncing Kconfig will add new tool requirement, flex & bison, for building
> U-Boot,
> but this is OK because Linux does it.
>
> U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX
> license tag style.
>
>
> And, you understand well the points for resyncing.
> Yes, other parts must be adjusted.
>
> So, I am happy if you contribute to this work.
Yes, I'm fine adding flex/bison as build requirements. And I'm also
fine with anyone that feels they can handle doing the re-sync doing the
re-sync, thanks folks!
--
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] arm: ls1021aqds: config: enable CONFIG_ID_EEPROM for mac command
Signed-off-by: Jagdish Gediya --- include/configs/ls1021aqds.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 0b4a6a4..79a84c4 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -351,6 +351,15 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */ #define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */ +/* EEPROM */ +#define CONFIG_ID_EEPROM +#define CONFIG_SYS_I2C_EEPROM_NXID +#define CONFIG_SYS_EEPROM_BUS_NUM 0 +#define CONFIG_SYS_I2C_EEPROM_ADDR 0x57 +#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 +#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3 +#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5 + /* * I2C bus multiplexer */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
Dear Tom, In message <20180509111627.gd12...@bill-the-cat.ec.rr.com> you wrote: > > > What’s your preferred solution: > > (a) change these comments > > (b) change our Makefiles to let GCC know that we are compiling > > gnu99/C99? > > > > Neither solution is too appealing to me, so I am asking... > > Lets go with (b) which I guess what a more modern toolchain defaults to > anyhow. Thanks! I disagree. UI-Boot always discouraged the use of C++ comments, see for example bullet # 5 at [1]. We should clearly fix the comments, please. [1] http://www.denx.de/wiki/U-Boot/Coding Best regards, Wolfgang Denk -- 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 "It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
On Wed, May 09, 2018 at 01:38:37PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20180509111627.gd12...@bill-the-cat.ec.rr.com> you wrote: > > > > > What’s your preferred solution: > > > (a) change these comments > > > (b) change our Makefiles to let GCC know that we are compiling > > > gnu99/C99? > > > > > > Neither solution is too appealing to me, so I am asking... > > > > Lets go with (b) which I guess what a more modern toolchain defaults to > > anyhow. Thanks! > > I disagree. UI-Boot always discouraged the use of C++ comments, see > for example bullet # 5 at [1]. We should clearly fix the comments, > please. > > [1] http://www.denx.de/wiki/U-Boot/Coding We should go and update [1] to note some special exemptions to the rule. I see you missed out on the SPDX thread over here: https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat myself, I see it as more worthwhile to (a) follow the kernel in this area (for both tooling and consistency and ease of development for our overlapping community) (b) save space (in just about every conversion we went from 2 lines to 1 line). Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
Hi,
> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 4:47 PM
> To: Siva Durga Prasad Paladugu
> Cc: Jagan Teki ; U-Boot-Denx b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
>
> On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
> wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Wednesday, May 09, 2018 4:18 PM
> >> To: Siva Durga Prasad Paladugu
> >> Cc: Jagan Teki ; U-Boot-Denx >> b...@lists.denx.de>; michal.si...@xilinx.com
> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >> for ZynqMP qspi driver
> >>
> >> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
>
> >> wrote:
> >> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> >> > wrote:
> >> >> Hi Jagan,
> >> >>
> >> >>> -Original Message-
> >> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >>> Sent: Wednesday, May 09, 2018 1:22 PM
> >> >>> To: Siva Durga Prasad Paladugu
> >> >>> Cc: Jagan Teki ; U-Boot-Denx >> >>> b...@lists.denx.de>; michal.si...@xilinx.com
> >> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >> >>> support for ZynqMP qspi driver
> >> >>>
> >> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
> >> >>> wrote:
> >> >>> >
> >> >>> > Hi,
> >> >>> >
> >> >>> >> -Original Message-
> >> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
> >> >>> >> To: Siva Durga Prasad Paladugu
> >> >>> >> Cc: Jagan Teki ; U-Boot-Denx >> >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
> >> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >> >>> >> support for ZynqMP qspi driver
> >> >>> >>
> >> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> >> >>> >> wrote:
> >> >>> >> > Hi Jagan,
> >> >>> >> >
> >> >>> >> >> -Original Message-
> >> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >> >>> >> >> To: Siva Durga Prasad Paladugu
> >> >>> >> >> Cc: U-Boot-Denx ;
> >> >>> >> >> michal.si...@xilinx.com
> >> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >> >>> >> >> for
> >> >>> >> ZynqMP
> >> >>> >> >> qspi driver
> >> >>> >> >>
> >> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >> >>> >> >> wrote:
> >> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
> >> >>> >> >> > driver is responsible for communicating with qspi flash
> devices.
> >> >>> >> >> >
> >> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >> >>> >> >> >
> >> >>> >> >> > ---
> >> >>> >> >> > Changes for v3:
> >> >>> >> >> > - Renamed all macros, functions, files and configs as per
> >> >>> >> >> > comment
> >> >>> >> >> > - Used wait_for_bit wherever required
> >> >>> >> >> > - Removed unnecessary header inclusion
> >> >>> >> >> >
> >> >>> >> >> > Changes for v2:
> >> >>> >> >> > - Rebased on top of latest master
> >> >>> >> >> > - Moved macro definitions to .h file as per comment
> >> >>> >> >> > - Fixed magic values with macros as per comment
> >> >>> >> >> > ---
> >> >>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h |
> 154
> >> >>> ++
> >> >>> >> >> > drivers/spi/Kconfig | 7 +
> >> >>> >> >> > drivers/spi/Makefile| 1 +
> >> >>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
> >> >>> >> >>
> >> >>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
> >> >>> >> >> > arch/arm/include/asm/arch-
> >> >>> >> >> zynqmp/zynqmp_gqspi.h
> >> >>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
> >> >>> >> >> >
> >> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
> >> zynqmp/zynqmp_gqspi.h
> >> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >> >>> >> >>
> >> >>> >> >> already asked you to move this header code in driver .c
> >> >>> >> >> file
> >> >>> >> >
> >> >>> >> > You might have missed my reply to your earlier comment on
> this.
> >> >>> >> > These were moved to .h based on comment from Lukasz in v1.
> >> >>> >> > I don’t have any issue in having them anywhere. Let me know
> >> >>> >> > your
> >> >>> choice.
> >> >>> >>
> >> >>> >> I'm trying to align Linux code, better to move like that and
> >> >>> >> make sure to use similar macros.
> >> >>> >>
> >> >>> >> >
> >> >>> >
> >> >>> > [snip]
> >> >>> >
> >> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
> >> zynqmp_qspi_priv
> >> >>> >> *priv) {
> >> >>> >> >> > + u8 command = 1;
> >> >>> >> >> > + u32 gen_fifo_cmd;
> >> >>> >> >> > + u32 bytecount = 0;
> >> >>> >> >> > +
> >> >>> >> >> > + while (priv->len) {
> >> >>> >> >> > + gen_fifo_cmd = zynqmp_qspi_bus_
Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver
On Wed, May 9, 2018 at 5:22 PM, Siva Durga Prasad Paladugu
wrote:
> Hi,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 4:47 PM
>> To: Siva Durga Prasad Paladugu
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
>> wrote:
>> > Hi Jagan,
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> Sent: Wednesday, May 09, 2018 4:18 PM
>> >> To: Siva Durga Prasad Paladugu
>> >> Cc: Jagan Teki ; U-Boot-Denx > >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> for ZynqMP qspi driver
>> >>
>> >> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
>>
>> >> wrote:
>> >> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
>> >> > wrote:
>> >> >> Hi Jagan,
>> >> >>
>> >> >>> -Original Message-
>> >> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> >>> Sent: Wednesday, May 09, 2018 1:22 PM
>> >> >>> To: Siva Durga Prasad Paladugu
>> >> >>> Cc: Jagan Teki ; U-Boot-Denx > >> >>> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >> >>> support for ZynqMP qspi driver
>> >> >>>
>> >> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>> >> >>> wrote:
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> >
>> >> >>> >> -Original Message-
>> >> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >> >>> >> To: Siva Durga Prasad Paladugu
>> >> >>> >> Cc: Jagan Teki ; U-Boot-Denx > >> >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >> >>> >> support for ZynqMP qspi driver
>> >> >>> >>
>> >> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >> >>> >> wrote:
>> >> >>> >> > Hi Jagan,
>> >> >>> >> >
>> >> >>> >> >> -Original Message-
>> >> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >> >>> >> >> To: Siva Durga Prasad Paladugu
>> >> >>> >> >> Cc: U-Boot-Denx ;
>> >> >>> >> >> michal.si...@xilinx.com
>> >> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> >>> >> >> for
>> >> >>> >> ZynqMP
>> >> >>> >> >> qspi driver
>> >> >>> >> >>
>> >> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >> >>> >> >> wrote:
>> >> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
>> >> >>> >> >> > driver is responsible for communicating with qspi flash
>> devices.
>> >> >>> >> >> >
>> >> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >> >>> >> >> >
>> >> >>> >> >> > ---
>> >> >>> >> >> > Changes for v3:
>> >> >>> >> >> > - Renamed all macros, functions, files and configs as per
>> >> >>> >> >> > comment
>> >> >>> >> >> > - Used wait_for_bit wherever required
>> >> >>> >> >> > - Removed unnecessary header inclusion
>> >> >>> >> >> >
>> >> >>> >> >> > Changes for v2:
>> >> >>> >> >> > - Rebased on top of latest master
>> >> >>> >> >> > - Moved macro definitions to .h file as per comment
>> >> >>> >> >> > - Fixed magic values with macros as per comment
>> >> >>> >> >> > ---
>> >> >>> >> >> > arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h |
>> 154
>> >> >>> ++
>> >> >>> >> >> > drivers/spi/Kconfig | 7 +
>> >> >>> >> >> > drivers/spi/Makefile| 1 +
>> >> >>> >> >> > drivers/spi/zynqmp_gqspi.c | 670
>> >> >>> >> >>
>> >> >>> >> >> > 4 files changed, 832 insertions(+) create mode 100644
>> >> >>> >> >> > arch/arm/include/asm/arch-
>> >> >>> >> >> zynqmp/zynqmp_gqspi.h
>> >> >>> >> >> > create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >> >>> >> >> >
>> >> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
>> >> zynqmp/zynqmp_gqspi.h
>> >> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >>> >> >>
>> >> >>> >> >> already asked you to move this header code in driver .c
>> >> >>> >> >> file
>> >> >>> >> >
>> >> >>> >> > You might have missed my reply to your earlier comment on
>> this.
>> >> >>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >> >>> >> > I don’t have any issue in having them anywhere. Let me know
>> >> >>> >> > your
>> >> >>> choice.
>> >> >>> >>
>> >> >>> >> I'm trying to align Linux code, better to move like that and
>> >> >>> >> make sure to use similar macros.
>> >> >>> >>
>> >> >>> >> >
>> >> >>> >
>> >> >>> > [snip]
>> >> >>> >
>> >> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
>> >> zynqmp_qspi_priv
>> >> >>> >> *priv) {
>> >> >>> >> >> > + u8 command = 1;
>> >> >>> >> >> > +
Re: [U-Boot] [PATCH] fs: ext4: fix crash on ext4ls
On Wed, May 09, 2018 at 12:57:35PM +0300, Eugen Hristev wrote:
> Found a crash while issuing ext4ls with a non-existent directory.
> Crash test:
>
> => ext4ls mmc 0 1
> ** Can not find directory. **
> data abort
> pc : [<3fd7c2ec>] lr : [<3fd93ed8>]
> reloc pc : [<26f142ec>]lr : [<26f2bed8>]
> sp : 3f963338 ip : 3fdc3dc4 fp : 3fd6b370
> r10: 0004 r9 : 3f967ec0 r8 : 3f96db68
> r7 : 3fdc99b4 r6 : r5 : 3f96dc88 r4 : 3fdcbc8c
> r3 : fffa r2 : r1 : 3f96e0bc r0 : 0002
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
> Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)
>
> Looks like crash is introduced by commit:
> "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
>
> Issue is that dirnode is not initialized, and then freed if the call
> to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
> thus we have a crash with data abort.
>
> I added initialization and a check for dirname being NULL.
>
> Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
> Cc: Stefan Brüns
> Cc: Tom Rini
> Signed-off-by: Eugen Hristev
> ---
> Hello,
>
> Regarding this fix, I am not sure if we actually need to free the node, but
> according to commit "fa9ca8a" , it was added to fix Coverity case.
> So, I decided to keep the free call under if statement if variable is NULL.
> If a different fix is required, please advise and I can change and resend.
>
> Thanks !
>
> fs/ext4/ext4fs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> index 4b36a3e..2a28031 100644
> --- a/fs/ext4/ext4fs.c
> +++ b/fs/ext4/ext4fs.c
> @@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>
> int ext4fs_ls(const char *dirname)
> {
> - struct ext2fs_node *dirnode;
> + struct ext2fs_node *dirnode = NULL;
> int status;
>
> if (dirname == NULL)
> @@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
> FILETYPE_DIRECTORY);
> if (status != 1) {
> printf("** Can not find directory. **\n");
> - ext4fs_free_node(dirnode, &ext4fs_root->diropen);
> + if (dirnode)
> + ext4fs_free_node(dirnode, &ext4fs_root->diropen);
> return 1;
> }
This looks good. Can you please do a v2 that also updates
test/fs/fs-test.sh to have a test for this case? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] i2c: Drop CONFIG_TSI108_I2C
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
Signed-off-by: Tuomas Tynkkynen
---
doc/driver-model/i2c-howto.txt | 1 -
drivers/i2c/Makefile | 1 -
drivers/i2c/tsi108_i2c.c | 275 -
include/tsi108.h | 207 ---
4 files changed, 484 deletions(-)
delete mode 100644 drivers/i2c/tsi108_i2c.c
delete mode 100644 include/tsi108.h
diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 605d3ef7ad..1b2c5312c4 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -16,7 +16,6 @@ ones remain:
sh_i2c
sh_sh7734_i2c
soft_i2c
- tsi108_i2c
zynq_i2c
The deadline for this work is the end of June 2017. If no one steps
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index e8bb6327fb..795dd33c64 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
deleted file mode 100644
index 208c0900ef..00
--- a/drivers/i2c/tsi108_i2c.c
+++ /dev/null
@@ -1,275 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Author: Alex Bounine
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include
-#include
-
-#include
-
-#if defined(CONFIG_CMD_I2C)
-
-#define I2C_DELAY 10
-#undef DEBUG_I2C
-
-#ifdef DEBUG_I2C
-#define DPRINT(x) printf (x)
-#else
-#define DPRINT(x)
-#endif
-
-/* All functions assume that Tsi108 I2C block is the only master on the bus */
-/* I2C read helper function */
-
-void i2c_init(int speed, int slaveaddr)
-{
- /*
-* The TSI108 has a fixed I2C clock rate and doesn't support slave
-* operation. This function only exists as a stub to fit into the
-* U-Boot I2C API.
-*/
-}
-
-static int i2c_read_byte (
- uint i2c_chan, /* I2C channel number: 0 - main, 1 - SDC SPD */
- uchar chip_addr,/* I2C device address on the bus */
- uint byte_addr, /* Byte address within I2C device */
- uchar * buffer /* pointer to data buffer */
- )
-{
- u32 temp;
- u32 to_count = I2C_DELAY;
- u32 op_status = TSI108_I2C_TIMEOUT_ERR;
- u32 chan_offset = TSI108_I2C_OFFSET;
-
- DPRINT (("I2C read_byte() %d 0x%02x 0x%02x\n",
- i2c_chan, chip_addr, byte_addr));
-
- if (0 != i2c_chan)
- chan_offset = TSI108_I2C_SDRAM_OFFSET;
-
- /* Check if I2C operation is in progress */
- temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + I2C_CNTRL2);
-
- if (0 == (temp & (I2C_CNTRL2_RD_STATUS | I2C_CNTRL2_WR_STATUS |
- I2C_CNTRL2_START))) {
- /* Set device address and operation (read = 0) */
- temp = (byte_addr << 16) | ((chip_addr & 0x07) << 8) |
- ((chip_addr >> 3) & 0x0F);
- *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset +
I2C_CNTRL1) =
- temp;
-
- /* Issue the read command
-* (at this moment all other parameters are 0
-* (size = 1 byte, lane = 0)
-*/
-
- *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset +
I2C_CNTRL2) =
- (I2C_CNTRL2_START);
-
- /* Wait until operation completed */
- do {
- /* Read I2C operation status */
- temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE +
chan_offset + I2C_CNTRL2);
-
- if (0 == (temp & (I2C_CNTRL2_RD_STATUS |
I2C_CNTRL2_START))) {
- if (0 == (temp &
-(I2C_CNTRL2_I2C_CFGERR |
- I2C_CNTRL2_I2C_TO_ERR))
- ) {
- op_status = TSI108_I2C_SUCCESS;
-
- temp = *(u32 *)
(CONFIG_SYS_TSI108_CSR_BASE +
-chan_offset +
-I2C_RD_DATA);
-
- *buffer = (u8) (temp & 0xFF);
- } else {
- /* report HW error */
- op_status = TSI108_I2C_IF_ERROR;
-
-
[U-Boot] [PATCH 3/3] i2c: Drop CONFIG_SH_SH7734_I2C
Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").
Signed-off-by: Tuomas Tynkkynen
---
doc/driver-model/i2c-howto.txt | 1 -
drivers/i2c/Makefile | 1 -
drivers/i2c/sh_sh7734_i2c.c| 376 -
3 files changed, 378 deletions(-)
delete mode 100644 drivers/i2c/sh_sh7734_i2c.c
diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 1b2c5312c4..8ba2f6e267 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -14,7 +14,6 @@ ones remain:
ppc4xx_i2c
rcar_i2c
sh_i2c
- sh_sh7734_i2c
soft_i2c
zynq_i2c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 795dd33c64..e32d65dc2f 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
diff --git a/drivers/i2c/sh_sh7734_i2c.c b/drivers/i2c/sh_sh7734_i2c.c
deleted file mode 100644
index 6fe356baca..00
--- a/drivers/i2c/sh_sh7734_i2c.c
+++ /dev/null
@@ -1,376 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2012 Nobuhiro Iwamatsu
- * Copyright (C) 2012 Renesas Solutions Corp.
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include
-#include
-#include
-
-struct sh_i2c {
- u8 iccr1;
- u8 iccr2;
- u8 icmr;
- u8 icier;
- u8 icsr;
- u8 sar;
- u8 icdrt;
- u8 icdrr;
- u8 nf2cyc;
- u8 __pad0;
- u8 __pad1;
-};
-
-static struct sh_i2c *base;
-static u8 iccr1_cks, nf2cyc;
-
-/* ICCR1 */
-#define SH_I2C_ICCR1_ICE (1 << 7)
-#define SH_I2C_ICCR1_RCVD (1 << 6)
-#define SH_I2C_ICCR1_MST (1 << 5)
-#define SH_I2C_ICCR1_TRS (1 << 4)
-#define SH_I2C_ICCR1_MTRS \
- (SH_I2C_ICCR1_MST | SH_I2C_ICCR1_TRS)
-
-/* ICCR1 */
-#define SH_I2C_ICCR2_BBSY (1 << 7)
-#define SH_I2C_ICCR2_SCP (1 << 6)
-#define SH_I2C_ICCR2_SDAO (1 << 5)
-#define SH_I2C_ICCR2_SDAOP (1 << 4)
-#define SH_I2C_ICCR2_SCLO (1 << 3)
-#define SH_I2C_ICCR2_IICRST(1 << 1)
-
-#define SH_I2C_ICIER_TIE (1 << 7)
-#define SH_I2C_ICIER_TEIE (1 << 6)
-#define SH_I2C_ICIER_RIE (1 << 5)
-#define SH_I2C_ICIER_NAKIE (1 << 4)
-#define SH_I2C_ICIER_STIE (1 << 3)
-#define SH_I2C_ICIER_ACKE (1 << 2)
-#define SH_I2C_ICIER_ACKBR (1 << 1)
-#define SH_I2C_ICIER_ACKBT (1 << 0)
-
-#define SH_I2C_ICSR_TDRE (1 << 7)
-#define SH_I2C_ICSR_TEND (1 << 6)
-#define SH_I2C_ICSR_RDRF (1 << 5)
-#define SH_I2C_ICSR_NACKF (1 << 4)
-#define SH_I2C_ICSR_STOP (1 << 3)
-#define SH_I2C_ICSR_ALOVE (1 << 2)
-#define SH_I2C_ICSR_AAS(1 << 1)
-#define SH_I2C_ICSR_ADZ(1 << 0)
-
-#define IRQ_WAIT 1000
-
-static void sh_i2c_send_stop(struct sh_i2c *base)
-{
- clrbits_8(&base->iccr2, SH_I2C_ICCR2_BBSY | SH_I2C_ICCR2_SCP);
-}
-
-static int check_icsr_bits(struct sh_i2c *base, u8 bits)
-{
- int i;
-
- for (i = 0; i < IRQ_WAIT; i++) {
- if (bits & readb(&base->icsr))
- return 0;
- udelay(10);
- }
-
- return 1;
-}
-
-static int check_stop(struct sh_i2c *base)
-{
- int ret = check_icsr_bits(base, SH_I2C_ICSR_STOP);
- clrbits_8(&base->icsr, SH_I2C_ICSR_STOP);
-
- return ret;
-}
-
-static int check_tend(struct sh_i2c *base, int stop)
-{
- int ret = check_icsr_bits(base, SH_I2C_ICSR_TEND);
-
- if (stop) {
- clrbits_8(&base->icsr, SH_I2C_ICSR_STOP);
- sh_i2c_send_stop(base);
- }
-
- clrbits_8(&base->icsr, SH_I2C_ICSR_TEND);
- return ret;
-}
-
-static int check_tdre(struct sh_i2c *base)
-{
- return check_icsr_bits(base, SH_I2C_ICSR_TDRE);
-}
-
-static int check_rdrf(struct sh_i2c *base)
-{
- return check_icsr_bits(base, SH_I2C_ICSR_RDRF);
-}
-
-static int check_bbsy(struct sh_i2c *base)
-{
- int i;
-
- for (i = 0 ; i < IRQ_WAIT ; i++) {
- if (!(SH_I2C_ICCR2_BBSY & readb(&base->iccr2)))
- return 0;
- udelay(10);
- }
- return 1;
-}
-
-static int check_ackbr(struct sh_i2c *base)
-{
- int i;
-
- for (i = 0 ; i < IRQ_WAIT ; i++) {
- if (!(SH_I2C_ICIER_ACKBR & readb(&base->icier)))
- return 0;
- udelay(10);
- }
-
- return 1;
-}
-
-static void sh_i2c_reset(struct sh_i2c *base)
-{
- setbits_8(&base->iccr2, SH_I2C_ICCR2_IICRST);
-
- udelay(100);
-
- clrbits_8(&base->iccr
[U-Boot] [PATCH 1/3] net: Drop CONFIG_TSI108_ETH
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
Signed-off-by: Tuomas Tynkkynen
---
drivers/net/Makefile |1 -
drivers/net/tsi108_eth.c | 1015 --
include/netdev.h |1 -
scripts/config_whitelist.txt |1 -
4 files changed, 1018 deletions(-)
delete mode 100644 drivers/net/tsi108_eth.c
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 851f82fb01..584bfdf2f9 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -58,7 +58,6 @@ obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o
-obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
obj-$(CONFIG_ULI526X) += uli526x.o
obj-$(CONFIG_VSC7385_ENET) += vsc7385.o
obj-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
deleted file mode 100644
index 108cf61647..00
--- a/drivers/net/tsi108_eth.c
+++ /dev/null
@@ -1,1015 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/***
- *
- * Copyright (c) 2005 Freescale Semiconductor, Inc.
- *
- * Description:
- * Ethernet interface for Tundra TSI108 bridge chip
- *
- ***/
-
-#include
-
-#if !defined(CONFIG_TSI108_ETH_NUM_PORTS) || (CONFIG_TSI108_ETH_NUM_PORTS > 2)
-#error "CONFIG_TSI108_ETH_NUM_PORTS must be defined as 1 or 2"
-#endif
-
-#include
-#include
-#include
-#include
-#include
-
-#ifdef DEBUG
-#define TSI108_ETH_DEBUG 7
-#else
-#define TSI108_ETH_DEBUG 0
-#endif
-
-#if TSI108_ETH_DEBUG > 0
-#define debug_lev(lev, fmt, args...) \
-if (lev <= TSI108_ETH_DEBUG) \
-printf ("%s %d: " fmt, __FUNCTION__, __LINE__, ##args)
-#else
-#define debug_lev(lev, fmt, args...) do{}while(0)
-#endif
-
-#define RX_PRINT_ERRORS
-#define TX_PRINT_ERRORS
-
-#define ETH_BASE (CONFIG_SYS_TSI108_CSR_BASE + 0x6000)
-
-#define ETH_PORT_OFFSET0x400
-
-#define __REG32(base, offset) (*((volatile u32 *)((char *)(base) + (offset
-
-#define reg_MAC_CONFIG_1(base) __REG32(base, 0x)
-#define MAC_CONFIG_1_TX_ENABLE (0x0001)
-#define MAC_CONFIG_1_SYNC_TX_ENABLE(0x0002)
-#define MAC_CONFIG_1_RX_ENABLE (0x0004)
-#define MAC_CONFIG_1_SYNC_RX_ENABLE(0x0008)
-#define MAC_CONFIG_1_TX_FLOW_CONTROL (0x0010)
-#define MAC_CONFIG_1_RX_FLOW_CONTROL (0x0020)
-#define MAC_CONFIG_1_LOOP_BACK (0x0100)
-#define MAC_CONFIG_1_RESET_TX_FUNCTION (0x0001)
-#define MAC_CONFIG_1_RESET_RX_FUNCTION (0x0002)
-#define MAC_CONFIG_1_RESET_TX_MAC (0x0004)
-#define MAC_CONFIG_1_RESET_RX_MAC (0x0008)
-#define MAC_CONFIG_1_SIM_RESET (0x4000)
-#define MAC_CONFIG_1_SOFT_RESET(0x8000)
-
-#define reg_MAC_CONFIG_2(base) __REG32(base, 0x0004)
-#define MAC_CONFIG_2_FULL_DUPLEX (0x0001)
-#define MAC_CONFIG_2_CRC_ENABLE(0x0002)
-#define MAC_CONFIG_2_PAD_CRC (0x0004)
-#define MAC_CONFIG_2_LENGTH_CHECK (0x0010)
-#define MAC_CONFIG_2_HUGE_FRAME(0x0020)
-#define MAC_CONFIG_2_INTERFACE_MODE(val) (((val) & 0x3) << 8)
-#define MAC_CONFIG_2_PREAMBLE_LENGTH(val) (((val) & 0xf) << 12)
-#define INTERFACE_MODE_NIBBLE 1 /* 10/100 Mb/s MII) */
-#define INTERFACE_MODE_BYTE2 /* 1000 Mb/s GMII/TBI */
-
-#define reg_MAXIMUM_FRAME_LENGTH(base) __REG32(base, 0x0010)
-
-#define reg_MII_MGMT_CONFIG(base) __REG32(base, 0x0020)
-#define MII_MGMT_CONFIG_MGMT_CLOCK_SELECT(val) ((val) & 0x7)
-#define MII_MGMT_CONFIG_NO_PREAMBLE(0x0010)
-#define MII_MGMT_CONFIG_SCAN_INCREMENT (0x0020)
-#define MII_MGMT_CONFIG_RESET_MGMT (0x8000)
-
-#define reg_MII_MGMT_COMMAND(base) __REG32(base, 0x0024)
-#define MII_MGMT_COMMAND_READ_CYCLE(0x0001)
-#define MII_MGMT_COMMAND_SCAN_CYCLE(0x0002)
-
-#define reg_MII_MGMT_ADDRESS(base) __REG32(base, 0x0028)
-#define reg_MII_MGMT_CONTROL(base) __REG32(base, 0x002c)
-#define reg_MII_MGMT_STATUS(base) __REG32(base, 0x0030)
-
-#define reg_MII_MGMT_INDICATORS(base) __REG32(base, 0x0034)
-#define MII_MGMT_INDICATORS_BUSY (0x0001)
-#define MII_MGMT_INDICATORS_SCAN (0x0002)
-#define MII_MGMT_INDICATORS_NOT_VALID (0x0004)
-
-#define reg_INTERFACE_STATUS(base) __REG32(base, 0x003c)
-#define INTERFACE_STATUS_LINK_FAIL (0x0008)
-#define INTERFACE_STATUS_EXCESS_DEFER (0x0200)
-
-#define reg_STATION_ADDRESS_1(base)__REG32(base, 0x0040)
-#define
Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug
> On 09.05.2018, at 10:19, Markus Krebs wrote: > > Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian: >> On 2018-05-08, Vagrant Cascadian wrote: >>> On 2018-05-05, Tom Rini wrote: On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote: > Markus Krebs discovered that the sheevaplug target has again grown and > installation overlaps where the u-boot env is saved since u-boot > ~2017.09. Running saveenv overwrites u-boot, and installing u-boot > overwrites any prior environment settings. >> ... I've added the maintainer to the list as well. I would suggest looking for things to trim out, perhaps CMD_MEMTEST ? >>> >>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling >>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a >>> *lot* left to disable in the config, but that's a significant start... >> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it >> down to 432k! Thanks to beeble for the suggestion. >> Anyone who has a sheevaplug can test that it actually boots with >> CONFIG_SYS_THUMB_BUILD=y enabled? > > I could test it, but I don't know the config-file where I can change those > options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD). Both are Kconfig options. So just disable it via menuconfig or in your .config file ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: zynq: Add initial support for Avnet MiniZed
On 4.5.2018 11:40, Ibai Erkiaga wrote:
> Initial support for Avnet MiniZed board. Tested UART1 (serial console),
> QSPI(Flash), SDHCI1 (eMMC), USB.
>
> Signed-off-by: Ibai Erkiaga
> ---
> arch/arm/dts/Makefile |1 +
> arch/arm/dts/zynq-minized.dts | 115
>
> configs/zynq_minized_defconfig | 68 +++
> 3 files changed, 184 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/dts/zynq-minized.dts
> create mode 100644 configs/zynq_minized_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ac7667b..ba1e261 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -131,6 +131,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> zynq-cc108.dtb \
> zynq-cse-qspi-single.dtb \
> zynq-microzed.dtb \
> + zynq-minized.dtb \
> zynq-picozed.dtb \
> zynq-syzygy-hub.dtb \
> zynq-topic-miami.dtb \
> diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
> new file mode 100644
> index 000..ecf1bc0
> --- /dev/null
> +++ b/arch/arm/dts/zynq-minized.dts
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Avnet MiniZed board
> + *
> + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> + *
> + * Ibai Erkiaga
> + */
> +
> +/dts-v1/;
> +#include "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MiniZed Development Board";
> + compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
My patch for adding avnet prefix to kernel was accepted.
That's why use:
model = "Avnet Zynq MiniZed Development Board";
compatible = "avnet,minized", "xlnx,zynq-7000";
> +
> + aliases {
> + serial0 = &uart1;
> + serial1 = &uart0;
> + spi0 = &qspi;
> + mmc0 = &sdhci0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x2000>;
> + };
> +
> + chosen {
> + bootargs = "";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0@e0002000 {
> + compatible = "ulpi-phy";
> + #phy-cells = <0>;
> + reg = <0xe0002000 0x1000>;
> + view-port = <0x0170>;
> + drv-vbus;
> + };
Please check other boards. This ulpi-phy is just in Xilinx git repo.
> +};
> +
> +&gpio0 {
> + emio-gpio-width = <4>;
> + gpio-mask-high = <0x0>;
> + gpio-mask-low = <0x5600>;
This is not the part of binding.
> +};
> +
> +&intc {
> + num_cpus = <2>;
> + num_interrupts = <96>;
this is not the part of kernel intc binding doc.
It looks like qemu binding.
> +};
> +
> +&qspi {
> + status = "okay";
> + is-dual = <0>;
> + num-cs = <1>;
> + flash@0 {
> + compatible = "micron,m25p128";
> + reg = <0x0>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + spi-max-frequency = <5000>;
> +
please use "fixed-partitions" here.
> + partition@0x {
remove 0x from node name and the same below.
> + label = "boot";
> + reg = <0x0 0xff>;
> + };
> +
> + partition@0x0027 {
> + label = "kernel";
> + reg = <0x27 0xd8>;
> + };
> +
> + partition@0x00ff {
> + label = "bootenv";
> + reg = <0xff 0x1>;
> + };
> +
> + partition@0x0100 {
> + label = "spare";
> + reg = <0x100 0x0>;
> + };
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + usb-reset = <&gpio0 7 0>; /* USB_RST_N-MIO7 */
> +};
> +
> +&sdhci1 {
> + status = "okay";
> + non-removable;
> + bus-width= <4>;
missing space.
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mmccard: mmccard@0 {
> + compatible = "mmc-card";
> + reg = <0>;
> + broken-hpi;
> + };
> +};
> diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
> new file mode 100644
> index 000..05cfc0e
> --- /dev/null
> +++ b/configs/zynq_minized_defconfig
> @@ -0,0 +1,68 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ZYNQ=y
> +CONFIG_SYS_TEXT_BASE=0x400
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R_ADDR=0x20
> +CONFIG_DEFAULT_DEVICE_TREE="zynq-minized"
> +CONFIG_DEBUG_UART=y
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_FIT_SIGNATURE=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_OS_BOOT=y
> +CONFIG_SYS_PROMPT="Zynq> "
> +CONFIG_CMD_THOR_DOWNLOAD=y
> +CONFIG_CMD_DFU=y
> +# CONFIG_CMD_
Re: [U-Boot] GCC 7.x vs. C++ comments
Dear Tom, In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote: > > We should go and update [1] to note some special exemptions to the rule. I'm not happy about this. > I see you missed out on the SPDX thread over here: > https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat Marek already said what was on my mind, and got ignored. Would it have changed anything if I had posted another complaint? I'm doing now, and apparently I get ignored, too. So what exactly is your argument? > myself, I see it as more worthwhile to (a) follow the kernel in this > area (for both tooling and consistency and ease of development for our > overlapping community) (b) save space (in just about every conversion we > went from 2 lines to 1 line). Thanks! OK, so you decided, and any additional discussion is futile... Wolfgang Denk -- 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 It is practically impossible to teach good programming style to stu- dents that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] i2c: Drop CONFIG_TSI108_I2C
Hello Tuomas,
Am 09.05.2018 um 14:24 schrieb Tuomas Tynkkynen:
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
Signed-off-by: Tuomas Tynkkynen
---
doc/driver-model/i2c-howto.txt | 1 -
drivers/i2c/Makefile | 1 -
drivers/i2c/tsi108_i2c.c | 275 -
include/tsi108.h | 207 ---
4 files changed, 484 deletions(-)
delete mode 100644 drivers/i2c/tsi108_i2c.c
delete mode 100644 include/tsi108.h
Acked-by: Heiko Schocher
Thanks!
bye,
Heiko
diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 605d3ef7ad..1b2c5312c4 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -16,7 +16,6 @@ ones remain:
sh_i2c
sh_sh7734_i2c
soft_i2c
- tsi108_i2c
zynq_i2c
The deadline for this work is the end of June 2017. If no one steps
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index e8bb6327fb..795dd33c64 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
deleted file mode 100644
index 208c0900ef..00
--- a/drivers/i2c/tsi108_i2c.c
+++ /dev/null
@@ -1,275 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Author: Alex Bounine
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include
-#include
-
-#include
-
-#if defined(CONFIG_CMD_I2C)
-
-#define I2C_DELAY 10
-#undef DEBUG_I2C
-
-#ifdef DEBUG_I2C
-#define DPRINT(x) printf (x)
-#else
-#define DPRINT(x)
-#endif
-
-/* All functions assume that Tsi108 I2C block is the only master on the bus */
-/* I2C read helper function */
-
-void i2c_init(int speed, int slaveaddr)
-{
- /*
-* The TSI108 has a fixed I2C clock rate and doesn't support slave
-* operation. This function only exists as a stub to fit into the
-* U-Boot I2C API.
-*/
-}
-
-static int i2c_read_byte (
- uint i2c_chan, /* I2C channel number: 0 - main, 1 - SDC SPD */
- uchar chip_addr,/* I2C device address on the bus */
- uint byte_addr, /* Byte address within I2C device */
- uchar * buffer /* pointer to data buffer */
- )
-{
- u32 temp;
- u32 to_count = I2C_DELAY;
- u32 op_status = TSI108_I2C_TIMEOUT_ERR;
- u32 chan_offset = TSI108_I2C_OFFSET;
-
- DPRINT (("I2C read_byte() %d 0x%02x 0x%02x\n",
- i2c_chan, chip_addr, byte_addr));
-
- if (0 != i2c_chan)
- chan_offset = TSI108_I2C_SDRAM_OFFSET;
-
- /* Check if I2C operation is in progress */
- temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + I2C_CNTRL2);
-
- if (0 == (temp & (I2C_CNTRL2_RD_STATUS | I2C_CNTRL2_WR_STATUS |
- I2C_CNTRL2_START))) {
- /* Set device address and operation (read = 0) */
- temp = (byte_addr << 16) | ((chip_addr & 0x07) << 8) |
- ((chip_addr >> 3) & 0x0F);
- *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset +
I2C_CNTRL1) =
- temp;
-
- /* Issue the read command
-* (at this moment all other parameters are 0
-* (size = 1 byte, lane = 0)
-*/
-
- *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset +
I2C_CNTRL2) =
- (I2C_CNTRL2_START);
-
- /* Wait until operation completed */
- do {
- /* Read I2C operation status */
- temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE +
chan_offset + I2C_CNTRL2);
-
- if (0 == (temp & (I2C_CNTRL2_RD_STATUS |
I2C_CNTRL2_START))) {
- if (0 == (temp &
-(I2C_CNTRL2_I2C_CFGERR |
- I2C_CNTRL2_I2C_TO_ERR))
- ) {
- op_status = TSI108_I2C_SUCCESS;
-
- temp = *(u32 *)
(CONFIG_SYS_TSI108_CSR_BASE +
-chan_offset +
-I2C_RD_DATA);
-
- *buffer = (u8) (temp & 0xFF);
- } else {
-
Re: [U-Boot] [PATCH 3/3] i2c: Drop CONFIG_SH_SH7734_I2C
Hello Tuomas,
Am 09.05.2018 um 14:24 schrieb Tuomas Tynkkynen:
Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").
Signed-off-by: Tuomas Tynkkynen
---
doc/driver-model/i2c-howto.txt | 1 -
drivers/i2c/Makefile | 1 -
drivers/i2c/sh_sh7734_i2c.c| 376 -
3 files changed, 378 deletions(-)
delete mode 100644 drivers/i2c/sh_sh7734_i2c.c
Thanks!
Acked-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] SPL too big for Turris Omnia in v2018.05
Hi, While trying to build u-boot for Turris Omnia board in v2018.05 with GCC 7.3.1, I get the following error: MKIMAGE u-boot-spl.kwb Error: Image header (incl. SPL image) too big! header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000! Increase CONFIG_SYS_U_BOOT_OFFS! Error: Image header (incl. SPL image) too big! header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000! Increase CONFIG_SYS_U_BOOT_OFFS! Could not create image make: *** [Makefile:1097: u-boot-spl.kwb] Error 1 Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] fs: ext4: fix crash on ext4ls
Found a crash while issuing ext4ls with a non-existent directory.
Crash test:
=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>] lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]lr : [<26f2bed8>]
sp : 3f963338 ip : 3fdc3dc4 fp : 3fd6b370
r10: 0004 r9 : 3f967ec0 r8 : 3f96db68
r7 : 3fdc99b4 r6 : r5 : 3f96dc88 r4 : 3fdcbc8c
r3 : fffa r2 : r1 : 3f96e0bc r0 : 0002
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)
Looks like crash is introduced by commit:
"fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.
I added initialization and a check for dirname being NULL.
Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns
Cc: Tom Rini
Signed-off-by: Eugen Hristev
---
Changes in v2:
- Added test case in test/fs/fs-test.sh in a different commit
fs/ext4/ext4fs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 4b36a3e..2a28031 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
int ext4fs_ls(const char *dirname)
{
- struct ext2fs_node *dirnode;
+ struct ext2fs_node *dirnode = NULL;
int status;
if (dirname == NULL)
@@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
FILETYPE_DIRECTORY);
if (status != 1) {
printf("** Can not find directory. **\n");
- ext4fs_free_node(dirnode, &ext4fs_root->diropen);
+ if (dirnode)
+ ext4fs_free_node(dirnode, &ext4fs_root->diropen);
return 1;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] test: fs: fs-test: Modified test 1 to do a ls to a nonexistent dir
Added a simple ls to a nonexistent directory for test 1.
In case the driver is broken for a nonexistent directory, U-boot
might crash.
Here is an example failed output:
=> # Test Case 1 - ls
=> ext4ls host 0:0
4096 .
4096 ..
16384 lost+found
4096 SUBDIR
262144 2.5GB.file
1048576 1MB.file
=> # In addition, test with a nonexistent directory to see if we crash.
=> ext4ls host 0:0 invalid_d
** Can not find directory. **
./test/fs/fs-test.sh: line 161: 25786 Segmentation fault (core dumped)
$UBOOT <
---
Hello,
Not sure whether this is the best test for this case, but I tried to do
a separate case and:
cannot really tell if it passed or not by just watching the output
(several FS show nothing, EXT4 shows "Can not find directory"),
so not really any string I can grep for to send to pass_fail function.
So, I decided to add another command to test no 1, which is a basic 'ls' test
to some 'invalid_d' directory.
Like this, we won't see anything in the output, but, if U-boot crashes, the
whole test series fails.
test/fs/fs-test.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
index 20d5dd8..6bb5311 100755
--- a/test/fs/fs-test.sh
+++ b/test/fs/fs-test.sh
@@ -225,6 +225,8 @@ setenv bind 'if test "\$sb" != sb; then sb bind 0 "$1"; fi'
run bind
# Test Case 1 - ls
${PREFIX}ls host${SUFFIX} $6
+# In addition, test with a nonexistent directory to see if we crash.
+${PREFIX}ls host${SUFFIX} invalid_d
#
# We want ${PREFIX}size host 0:0 $3 for host commands and
# sb size hostfs - $3 for hostfs commands.
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
On Wed, May 09, 2018 at 02:46:54PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote: > > > > We should go and update [1] to note some special exemptions to the rule. > > I'm not happy about this. > > > I see you missed out on the SPDX thread over here: > > https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat > > Marek already said what was on my mind, and got ignored. > Would it have changed anything if I had posted another complaint? Ignored, no. Counts as a veto? No. And if you had chimed in too, I don't know if that would have gotten anyone else to also chime in. Looking over the thread again there's two yes votes, two no votes, two people that chimed in on the thread but didn't express a yes or no to the change, and then no one else has said anything. The main thing I see currently is a whole lot of ambivalence. > I'm doing now, and apparently I get ignored, too. So what exactly > is your argument? > > > myself, I see it as more worthwhile to (a) follow the kernel in this > > area (for both tooling and consistency and ease of development for our > > overlapping community) (b) save space (in just about every conversion we > > went from 2 lines to 1 line). Thanks! > > OK, so you decided, and any additional discussion is futile... It's not futile, but here's as best I can tell, the arguments: Against Linux Kernel style SPDX tags: - Don't like // style comments - Visually inconsistent / jarring For Linux Kernel style SPDX tags: - Has higher visibility. - Has tooling to enforce correctly formatted tags. - Shorter (enforced as a single line comment means we don't have people spacing around it). - Consistent expectations for our overlapping developer community. Things that could be taken, without changing overall formatting: - Logic operators for exceptions/dual-license/etc If people speak up against the change now that we've done it, we could revert and then add in the "LICENSE-A OR LICENSE-B" change. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
> On 9 May 2018, at 15:49, Tom Rini wrote: > > On Wed, May 09, 2018 at 02:46:54PM +0200, Wolfgang Denk wrote: >> Dear Tom, >> >> In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote: >>> >>> We should go and update [1] to note some special exemptions to the rule. >> >> I'm not happy about this. >> >>> I see you missed out on the SPDX thread over here: >>> https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat >> >> Marek already said what was on my mind, and got ignored. >> Would it have changed anything if I had posted another complaint? > > Ignored, no. Counts as a veto? No. And if you had chimed in too, I > don't know if that would have gotten anyone else to also chime in. > Looking over the thread again there's two yes votes, two no votes, two > people that chimed in on the thread but didn't express a yes or no to > the change, and then no one else has said anything. The main thing I > see currently is a whole lot of ambivalence. Although I am ambivalent to the underlying discussion, I have strong opinions regarding the language/standard-compliance... My vote goes to C++ comments and upgrading the language standard to C99 (or rather gnu99, as our code uses extensions). This will (at least somewhat) match how the default C compliance level in GCC has evolved over the GCC 6 through GCC 8 release cycles. And while we’re at it, we should allow "for (int i = 0; …”-style C99 declaration of loop iterations within the loop-head. > >> I'm doing now, and apparently I get ignored, too. So what exactly >> is your argument? >> >>> myself, I see it as more worthwhile to (a) follow the kernel in this >>> area (for both tooling and consistency and ease of development for our >>> overlapping community) (b) save space (in just about every conversion we >>> went from 2 lines to 1 line). Thanks! >> >> OK, so you decided, and any additional discussion is futile... > > It's not futile, but here's as best I can tell, the arguments: > Against Linux Kernel style SPDX tags: > - Don't like // style comments > - Visually inconsistent / jarring > > For Linux Kernel style SPDX tags: > - Has higher visibility. > - Has tooling to enforce correctly formatted tags. > - Shorter (enforced as a single line comment means we don't have people > spacing around it). > - Consistent expectations for our overlapping developer community. > > Things that could be taken, without changing overall formatting: > - Logic operators for exceptions/dual-license/etc > > If people speak up against the change now that we've done it, we could > revert and then add in the "LICENSE-A OR LICENSE-B" change. Thanks! > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine
Hello I have successfully built u-boot and launched qemu with the flags proposed by the patch. My problems start when I try to boot the kernel What is the linux kernel defconfig that should be used to boot this machine? I tried the versatile one but they are different in some key places like the sd card. The end result is that I can only see Starting Kernel, and nothing else. What bootargs do you pass to the kernel to have the serial output in qemu? Paulo Neves ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
On Wed, May 09, 2018 at 07:23:19AM -0400, Tom Rini wrote: > On Wed, May 09, 2018 at 08:32:56AM +, yamada.masah...@socionext.com wrote: > > Tom will make a decision. > > > > Just my thought. > > > > > > U-Boot is basically a mirror of Linux. > > > > Syncing Kconfig will add new tool requirement, flex & bison, for building > > U-Boot, > > but this is OK because Linux does it. > > > > U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX > > license tag style. > > > > > > And, you understand well the points for resyncing. > > Yes, other parts must be adjusted. > > > > So, I am happy if you contribute to this work. > > Yes, I'm fine adding flex/bison as build requirements. And I'm also > fine with anyone that feels they can handle doing the re-sync doing the > re-sync, thanks folks! > > -- > Tom I will take care of it in the next days. Thanks for your support, Tom, Masahiro and Petr. Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] drivers/net/vsc9953: Initialize action RAM in VCAP complex
From: Radu Bulie
VCAP tables must be initialized even if no advanced classification
is used. If no initialization is performed, then ECC error will
be observed by the user when the first packet enters the l2switch.
The error is marked in MPIC_EISR0 -bit 29 which means - Internal RAM
multi-bit ECC error.
This patch fixes the aforementioned ECC error by performing the
initialization of VCAP tables.
Signed-off-by: Radu Bulie
---
drivers/net/vsc9953.c | 134 ++
include/vsc9953.h | 58 ++
2 files changed, 192 insertions(+)
diff --git a/drivers/net/vsc9953.c b/drivers/net/vsc9953.c
index 2388438..f90181d 100644
--- a/drivers/net/vsc9953.c
+++ b/drivers/net/vsc9953.c
@@ -2469,6 +2469,139 @@ void vsc9953_default_configuration(void)
debug("VSC9953: failed to set default aggregation code mode\n");
}
+static void vcap_entry2cache_init(u32 target, u32 entry_words)
+{
+ int i;
+
+ for (i = 0; i < entry_words; i++) {
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_ENTRY_DAT(target, i)), 0x00);
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_MASK_DAT(target, i)), 0xFF);
+ }
+
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_TG_DAT(target)), 0x00);
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(target)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(entry_words));
+}
+
+static void vcap_action2cache_init(u32 target, u32 action_words,
+ u32 counter_words)
+{
+ int i;
+
+ for (i = 0; i < action_words; i++)
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_ACTION_DAT(target, i)), 0x00);
+
+ for (i = 0; i < counter_words; i++)
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_CNT_DAT(target, i)), 0x00);
+}
+
+static int vcap_cmd(u32 target, u16 ix, int cmd, int sel, int entry_count)
+{
+ u32 tgt = target;
+ u32 value = (VSC9953_VCAP_UPDATE_CTRL_UPDATE_CMD(cmd) |
+VSC9953_VCAP_UPDATE_CTRL_UPDATE_ADDR(ix) |
+VSC9953_VCAP_UPDATE_CTRL_UPDATE_SHOT);
+
+ if ((sel & TCAM_SEL_ENTRY) && ix >= entry_count)
+ return CMD_RET_FAILURE;
+
+ if (!(sel & TCAM_SEL_ENTRY))
+ value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_ENTRY_DIS;
+
+ if (!(sel & TCAM_SEL_ACTION))
+ value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_ACTION_DIS;
+
+ if (!(sel & TCAM_SEL_COUNTER))
+ value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_CNT_DIS;
+
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_UPDATE_CTRL(tgt)), value);
+
+ do {
+ value = in_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_UPDATE_CTRL(tgt)));
+
+ } while (value & VSC9953_VCAP_UPDATE_CTRL_UPDATE_SHOT);
+
+ return CMD_RET_SUCCESS;
+}
+
+static void vsc9953_vcap_init(void)
+{
+ u32 tgt = VSC9953_ES0;
+ int cmd_ret;
+
+ /* write entries */
+ vcap_entry2cache_init(tgt, ENTRY_WORDS_ES0);
+ cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE, TCAM_SEL_ENTRY,
+ ENTRY_WORDS_ES0);
+ if (cmd_ret != CMD_RET_SUCCESS)
+ debug("VSC9953:%d invalid TCAM_SEL_ENTRY\n",
+ __LINE__);
+
+ /* write actions and counters */
+ vcap_action2cache_init(tgt, BITS_TO_DWORD(91), BITS_TO_DWORD(1));
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(tgt)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(VSC9953_ES0_CNT + VSC9953_PORTS));
+ cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE,
+ TCAM_SEL_ACTION | TCAM_SEL_COUNTER, ENTRY_WORDS_ES0);
+ if (cmd_ret != CMD_RET_SUCCESS)
+ debug("VSC9953:%d invalid TCAM_SEL_ACTION | TCAM_SEL_COUNTER\n",
+ __LINE__);
+
+ tgt = VSC9953_IS1;
+
+ /* write entries */
+ vcap_entry2cache_init(tgt, ENTRY_WORDS_IS1);
+ cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE, TCAM_SEL_ENTRY,
+ ENTRY_WORDS_IS1);
+ if (cmd_ret != CMD_RET_SUCCESS)
+ debug("VSC9953:%d invalid TCAM_SEL_ENTRY\n",
+ __LINE__);
+
+ /* write actions and counters */
+ vcap_action2cache_init(tgt, BITS_TO_DWORD(320), BITS_TO_DWORD(4));
+ out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(tgt)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(VSC9953_IS1_CNT + 1));
+ cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE,
+
Re: [U-Boot] GCC 7.x vs. C++ comments
Dear Tom, In message <20180509134905.gk12...@bill-the-cat.ec.rr.com> you wrote: > > > Marek already said what was on my mind, and got ignored. > > Would it have changed anything if I had posted another complaint? > > Ignored, no. Counts as a veto? No. And if you had chimed in too, I > don't know if that would have gotten anyone else to also chime in. This does not really convince me. IMO it makes no sense to blow up mailing list traffic with extensive voting for such things. Marek said everything that needed to be said, and repeating it would IMO not add any weight to it. If you really want a poll including more people, then explicitly start one - but please not on the mailing list, at least not fuch such details. > It's not futile, but here's as best I can tell, the arguments: > Against Linux Kernel style SPDX tags: I think this argument is wrong from the start. This is not about "Linux Kernel style SPDX tags". There is two different topics, which are actually independent, and should be treated as such: - Linux Kernel style SPDX tags, or rather more modern SPDX tags including the needed operators to deal with exceptions, multiple licenses, etc. When I invented the SPDX tags I did not foresee this need (my fault), but I'm still proud that U-Boot introduced this mechanism at all. Yes, it is necessary to adapt the new developments in this area. - Comment style. This is just a matter of coding style and preferences. Whether you use C comments (single line or multi-line) or C++ comments does not make any difference technically. U-Boot has been discouraging the use of C++ comments for 18 years, and I still see no good reason to change this. [And yes, we also have the rule not to meddle with code copied from other projects.] > - Don't like // style comments > - Visually inconsistent / jarring - Against existing coding style. > For Linux Kernel style SPDX tags: > - Has higher visibility. ??? I can't parse this. In which way has // SPDX-License-Identifier: GPL-2.0+ "higher visibility" than /* SPDX-License-Identifier: GPL-2.0+ */ or even /* * SPDX-License-Identifier: GPL-2.0+ */ ? [IMO, the last form is the most visible one.] And since when do we care about a single line of white space or two when it comes to consistency or readability? > - Has tooling to enforce correctly formatted tags. > - Shorter (enforced as a single line comment means we don't have people > spacing around it). Come on, this argument is really lame. > - Consistent expectations for our overlapping developer community. Please explain? Who associates SPDX tags with C++ comments? This is silly. We don't use these in Makefiles, or in shell scripts, or in ... And when talking about consistency - what about this in the current Linux Kernel tree: arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0 arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */ arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */ arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0 drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */ drivers/memory/brcmstb_dpfe.c: * SPDX-License-Identifier: GPL-2.0 drivers/soc/amlogic/meson-mx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+ drivers/soc/amlogic/meson-gx-pwrc-vpu.c: * SPDX-License-Identifier: GPL-2.0+ drivers/soc/amlogic/meson-gx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+ drivers/i2c/busses/i2c-sprd.c: * SPDX-License-Identifier: (GPL-2.0+ OR MIT) drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT) drivers/pinctrl/meson/pinctrl-meson-axg.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT) drivers/virt/vboxguest/vboxguest_core.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */ drivers/virt/vboxguest/vboxguest_linux.c:/* SPDX-License-Identifier: GPL-2.0 */ drivers/virt/vboxguest/vboxguest_utils.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */ drivers/watchdog/rtd119x_wdt.c: * SPDX-License-Identifier: GPL-2.0+ drivers/rtc/rtc-rtd119x.c: * SPDX-License-Identifier: GPL-2.0+ drivers/rtc/rtc-sc27xx.c: * SPDX-License-Identifier: GPL-2.0 ... Yes, 47 files is only a small fraction compared against the 5261 C files with C++ commented tags. But consistency of apparently not a real issue when it comes to comment style in Linux. > Things that could be taken, without changing overall formatting: > - Logic operators for exceptions/dual-license/etc Right, this is completely independent and out of question here. > If people speak up against the change now that we've done it, we could > revert and then add in the "LICENSE-A OR LICENSE-B" change. Thanks! I have always been against the use of C++ comments in U-Boot (and in general in non C++ code), and I still am against it. Not that this ma
Re: [U-Boot] GCC 7.x vs. C++ comments
Dear Tom, In message <20180509154052.5e0b4240...@gemini.denx.de> I wrote: > > > - Don't like // style comments > > - Visually inconsistent / jarring > > - Against existing coding style. Also, the SPDX tag is rarely a separate comment line. In most cases, it is part of a larger file header, say for example: common/main.c: /* * (C) Copyright 2000 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier: GPL-2.0+ */ Do you suggest to reformat this into something like: /* * (C) Copyright 2000 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ // SPDX-License-Identifier: GPL-2.0+ ? If yes, then please explain which sense this would make? It is just unnecessay work, and the result is inconsistent and ugly. > > - Has tooling to enforce correctly formatted tags. I forgot to ask which "tooling" you have in mind here? I did not see anything like that in the kernel source tree. What am I missing? Best regards, Wolfgang Denk -- 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 This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance.- Steven Wright, comedian ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
On Wed, May 09, 2018 at 05:40:52PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20180509134905.gk12...@bill-the-cat.ec.rr.com> you wrote: > > > > > Marek already said what was on my mind, and got ignored. > > > Would it have changed anything if I had posted another complaint? > > > > Ignored, no. Counts as a veto? No. And if you had chimed in too, I > > don't know if that would have gotten anyone else to also chime in. > > This does not really convince me. > > IMO it makes no sense to blow up mailing list traffic with extensive > voting for such things. Marek said everything that needed to be > said, and repeating it would IMO not add any weight to it. If you > really want a poll including more people, then explicitly start one > - but please not on the mailing list, at least not fuch such > details. I honestly couldn't think of a better way to see if anyone cared besides an RFC to the mailing list. > > It's not futile, but here's as best I can tell, the arguments: > > Against Linux Kernel style SPDX tags: > > I think this argument is wrong from the start. This is not about > "Linux Kernel style SPDX tags". There is two different topics, > which are actually independent, and should be treated as such: > > - Linux Kernel style SPDX tags, or rather more modern SPDX tags > including the needed operators to deal with exceptions, multiple > licenses, etc. When I invented the SPDX tags I did not foresee > this need (my fault), but I'm still proud that U-Boot introduced > this mechanism at all. > > Yes, it is necessary to adapt the new developments in this area. And for the record, it's a good thing you did. Since we were the best example of a project going all-in on the tags for a long while I know the people that did the kernel scheme looked at what we had. > - Comment style. This is just a matter of coding style and > preferences. Whether you use C comments (single line or > multi-line) or C++ comments does not make any difference > technically. I disagree on these being separate. I copy/pasted the relevant part of the kernel documentation as an update to our doc but where it goes (first line) and how it goes (comments like ) are as much a part of the style as the syntax. I'd argue that where the license copies go and some directory structure there-of is also part of it but I think our locations are more set in stone, but we can live with it. > U-Boot has been discouraging the use of C++ comments for 18 years, > and I still see no good reason to change this. [And yes, we also > have the rule not to meddle with code copied from other projects.] I don't want to have it buried here but maybe it's time to talk about fully adopting C99 (or, GNU C99). Did you happen to read https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along? Having read that after converting the tags that my first regex missed, maybe we were wrong 18 years ago. > > - Don't like // style comments > > - Visually inconsistent / jarring > > - Against existing coding style. > > > > For Linux Kernel style SPDX tags: > > - Has higher visibility. > > ??? I can't parse this. In which way has > > // SPDX-License-Identifier: GPL-2.0+ > > "higher visibility" than > > /* SPDX-License-Identifier: GPL-2.0+ */ > > or even I was pointing out first line vs somewhere within the top comment block as I don't consider comment format vs location different items. > /* > * SPDX-License-Identifier: GPL-2.0+ > */ > > ? > > [IMO, the last form is the most visible one.] > > And since when do we care about a single line of white space or two > when it comes to consistency or readability? > > > - Has tooling to enforce correctly formatted tags. > > > > - Shorter (enforced as a single line comment means we don't have people > > spacing around it). > > Come on, this argument is really lame. That the SPDX tag meant the same as the whole license text was part of the reason to convert. > > - Consistent expectations for our overlapping developer community. > > Please explain? Who associates SPDX tags with C++ comments? This This is again part of the difference in counting comment format as part of it, or not. > is silly. We don't use these in Makefiles, or in shell scripts, or > in ... We sometimes do for Makefiles, almost always do in shell scripts. > And when talking about consistency - what about this in the current > Linux Kernel tree: > > arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0 > arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0 > drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */ > drivers/memory/brcmstb_dpf
Re: [U-Boot] GCC 7.x vs. C++ comments
On Wed, May 09, 2018 at 06:07:50PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20180509154052.5e0b4240...@gemini.denx.de> I wrote: > > > > > - Don't like // style comments > > > - Visually inconsistent / jarring > > > > - Against existing coding style. > > Also, the SPDX tag is rarely a separate comment line. In most > cases, it is part of a larger file header, say for example: > > common/main.c: > > /* > * (C) Copyright 2000 > * Wolfgang Denk, DENX Software Engineering, w...@denx.de. > * > * SPDX-License-Identifier: GPL-2.0+ > */ > > > Do you suggest to reformat this into something like: > > /* > * (C) Copyright 2000 > * Wolfgang Denk, DENX Software Engineering, w...@denx.de. > */ > > // SPDX-License-Identifier: GPL-2.0+ > > ? I know it's going to annoy you more, but yes, that's already _done_: $ head -n5 common/main.c // SPDX-License-Identifier: GPL-2.0+ /* * (C) Copyright 2000 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ It was about 97% automatic perl regex + sed insert and 3% "Ugh, this file does not follow the normal conventional comment style at all". > If yes, then please explain which sense this would make? It is just > unnecessay work, and the result is inconsistent and ugly. > > > > > - Has tooling to enforce correctly formatted tags. > > I forgot to ask which "tooling" you have in mind here? I did not > see anything like that in the kernel source tree. What am I > missing? This started because I updated checkpatch.pl and that in turn checks if new files have an SPDX tag and if so, does it match the kernel style formatting. The first email: https://lists.denx.de/pipermail/u-boot/2018-April/325510.html that brought this up. And yes, I run checkpatch.pl on everything before every pull/push. -- 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] rockchip: set SYS_NS16550_MEM32 for all SoCs
On 05/08/2018 12:43 PM, Jonathan Gray wrote: > Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Philipp Tomsich > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich With the patch I get a serial console on the Asus Tinker-Board (RK3288). Tested-by: Heinrich Schuchardt > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/rockchip-common.h > b/include/configs/rockchip-common.h > index dee82ca99d..68e1105a4b 100644 > --- a/include/configs/rockchip-common.h > +++ b/include/configs/rockchip-common.h > @@ -7,6 +7,8 @@ > #define _ROCKCHIP_COMMON_H_ > #include > > +#define CONFIG_SYS_NS16550_MEM32 > + > #ifndef CONFIG_SPL_BUILD > > /* First try to boot from SD (index 0), then eMMC (index 1) */ > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: ti: boot: Extract PARTS_DEFAULT to boot.h
On 04/19/2018 03:57 PM, Sam Protsenko wrote:
> Eliminate code duplication: the same PARTS_DEFAULT was defined in
> am57xx_evm.h and in dra7xx_evm.h. Extract it to environment/boot.h and
> use in all OMAP5-based boards.
>
> Signed-off-by: Sam Protsenko
> ---
Acked-by: Andrew F. Davis
> include/configs/am57xx_evm.h | 25 -
> include/configs/cl-som-am57x.h | 2 ++
> include/configs/cm_t54.h | 2 ++
> include/configs/dra7xx_evm.h | 25 -
> include/environment/ti/boot.h | 27 +--
> 5 files changed, 29 insertions(+), 52 deletions(-)
>
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index d1f73f76a4..886a5696f5 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -38,31 +38,6 @@
>
> #define CONFIG_SYS_OMAP_ABE_SYSCK
>
> -/* Define the default GPT table for eMMC */
> -#define PARTS_DEFAULT \
> - /* Linux partitions */ \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=bootloader,start=384K,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
> - /* Android partitions */ \
> - "partitions_android=" \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \
> - "name=bootloader,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
> - "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
> - "name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
> - "name=efs,size=16M,uuid=${uuid_gpt_efs};" \
> - "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
> - "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
> - "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
> - "name=system,size=768M,uuid=${uuid_gpt_system};" \
> - "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
> - "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
> - "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
> - "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
> - "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
> -
> #define DFUARGS \
> "dfu_bufsiz=0x1\0" \
> DFU_ALT_INFO_MMC \
> diff --git a/include/configs/cl-som-am57x.h b/include/configs/cl-som-am57x.h
> index 9c70cf0b37..709e0375b3 100644
> --- a/include/configs/cl-som-am57x.h
> +++ b/include/configs/cl-som-am57x.h
> @@ -18,6 +18,8 @@
>
> #define CONFIG_SYS_OMAP_ABE_SYSCK
>
> +#define PARTS_DEFAULT
> +
> #include
>
> /* misc */
> diff --git a/include/configs/cm_t54.h b/include/configs/cm_t54.h
> index 6123cd374d..f0d76ed806 100644
> --- a/include/configs/cm_t54.h
> +++ b/include/configs/cm_t54.h
> @@ -14,6 +14,8 @@
> #define CONFIG_CM_T54
> #define CONFIG_DRAM_2G
>
> +#define PARTS_DEFAULT
> +
> #include
>
> /* EEPROM related defines */
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 917a05d701..9b3fb2c913 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -45,31 +45,6 @@
> #define CONFIG_SYS_OMAP_ABE_SYSCK
>
> #ifndef CONFIG_SPL_BUILD
> -/* Define the default GPT table for eMMC */
> -#define PARTS_DEFAULT \
> - /* Linux partitions */ \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=bootloader,start=384K,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
> - /* Android partitions */ \
> - "partitions_android=" \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \
> - "name=bootloader,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
> - "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
> - "name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
> - "name=efs,size=16M,uuid=${uuid_gpt_efs};" \
> - "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
> - "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
> - "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
> - "name=system,size=768M,uuid=${uuid_gpt_system};" \
> - "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
> - "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
> - "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
> - "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
> - "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
> -
> #define DFUARGS \
> "dfu_bufsiz=0x1\0" \
> DFU_ALT_INFO_MMC \
> diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
> index 24b7783f88..4f3d748b5c 100644
> --- a/include/environment/ti/boot.h
> +++ b/include/environment/ti/boot.h
> @@ -15,8 +15,31 @@
> #endif
>
> #ifndef PARTS_DEFAULT
> -#define PARTS_DEFAULT
> -#endif
> +/* Define the default GPT table for eMMC */
> +#define PARTS_DEFAULT \
> + /* Linux partitions */ \
> + "uuid_disk=${uuid_gpt_disk};" \
> +
Re: [U-Boot] [PATCH] spi: fsl_qspi: Introduce is_controller_busy function
On 03/22/2018 02:46 AM, Rajat Srivastava wrote: > Some SoCs have different endianness of QSPI IP if compared > to endianness of core. The function is_controller_busy() > checks if the QSPI controller is busy or not, considering > the endianness of the QSPI IP. > > Signed-off-by: Rajat Srivastava > Reviewed-by: York Sun > --- > drivers/spi/fsl_qspi.c | 31 +-- > 1 file changed, 21 insertions(+), 10 deletions(-) Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v3] mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0
On 03/23/2018 04:17 AM, Jagdish Gediya wrote: > Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC > version 2.0.0 due to increase in SRAM size. This is causing eccstat > array to over flow. > > So, replace eccstat array with u32 variable to make it fail-safe and > independent of number of ECC status registers or SRAM size. > > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Jagdish Gediya > --- > Changes for v2: > - Resolve checkpatch error > - Give suitable name to variable and do proper initialization. > > Changes for v3: > - Changes to avoid reading of register twice if sector_start > is multiple of 4. I don't see any comment on this patch. So it is applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: layerscape: Avoid code duplication for TZASC Instantiation
On 03/26/2018 03:54 AM, Sriram Dash wrote: > TZASC controller configurations are similar. > Put them in a macro and avoid code duplication. > > Signed-off-by: Priyanka Jain > Signed-off-by: Sriram Dash > --- > arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 62 > +++- > 1 file changed, 34 insertions(+), 28 deletions(-) > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Patch v2] armv8: ls1088a: Move CONFIG_BOOTARGS and CONFIG_CMD_GREPENV to defconfig
On 03/26/2018 04:32 AM, Ashish Kumar wrote: > Signed-off-by: Ashish Kumar > --- > v2: Rebase to top > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] armv8: sec_firmware: Remove JR3 from device tree node in all cases
On 04/12/2018 05:53 AM, Ruchika Gupta wrote: > JR3 was getting removed from device tree only if random number generation > was successful. However, if SEC firmware is present,JR3 should be removed > from device tree node irrespective of the random seed generation as > SEC firmware reserves it for it's use. Not removing it in case of random > number generation failure causes the kernel to crash. > > Random number generation was being called twice. This is not required. > If SEC firmware is running, SIP call can be made to the SEC firmware to > get the random number. This call itself would return failure if function > is not supported. Duplicate calling of random number generation function > has been removed > > Signed-off-by: Ruchika Gupta > --- > Changes from v1: > Removed unused variable rand from the sec_firmware_support_hwrng function > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1088aqds: Enable mdio commands on u-boot prompt
On 04/13/2018 01:58 AM, Ashish Kumar wrote: > Signed-off-by: Ashish Kumar > --- > board/freescale/ls1088a/eth_ls1088aqds.c | 2 ++ > 1 file changed, 2 insertions(+) > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1088: Update 1900MT/s DDR timing to bring consistency
On 04/18/2018 12:07 AM, Ashish Kumar wrote: > Signed-off-by: Ashish Kumar > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] powerpc: mpc85xx: Improve Work-around for Erratum A005125
On 04/22/2018 11:27 PM, Takuma Ueba wrote: > powerpc/mpc85xx: Work-around for Erratum A005125 must be applied to all cores. > > Signed-off-by: Yoshihisa Morizumi > Signed-off-by: Takuma Ueba > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: sec_firmware: Add support for multiple loadables
On 04/23/2018 05:20 AM, Sumit Garg wrote: > Enable support for multiple loadable images in SEC firmware FIT image. > Also add example "sec_firmware_ppa.its" file. > > Signed-off-by: Sumit Garg > --- > > Changes in v2: > Added example "sec_firmware_ppa.its" file. Also added printf instead of > debug in case of error scenario. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-lsch2: correct QMAN clock
On 04/25/2018 03:29 AM, Z.q. Hou wrote: > From: Hou Zhiqiang > > Signed-off-by: Hou Zhiqiang > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/fsl-lsch2: make the workaround for PIN MUX erratum A010539 robust
On 04/25/2018 01:26 AM, Z.q. Hou wrote: > From: Hou Zhiqiang > > Mask HRESET_B after cleared the the RCW_SRC, because in the workaround > we override the RCW_SRC and if HRESET_B is issued after the override > then SoC cannot find valid RCW as the RCW_SRC was overwritten and result > in hang. So we need to mask HRESET_B in case user asserts it, and the > PORESET_B should be asserted which leads to resampling of cfg_rcw_src > pins and loading of correct RCW_SRC. > > Signed-off-by: Hou Zhiqiang > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v3] mtd: nand: fsl_ifc: Fix nand waitfunc return value
On 05/01/2018 03:52 AM, Jagdish Gediya wrote: > As per the IFC hardware manual, Most significant byte in > nand_fsr register is the outcome of NAND READ STATUS command. > > So status value need to be shifted as per the nand > framework requirement. > > Signed-off-by: Jagdish Gediya > Reviewed-by: Prabhakar Kushwaha > --- > Changes for v2: > - Change the waitfunc return value according to semantic > enforced by framework. > > Changes for v3: > - Change commit message as per York's suggestion. Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] driver: net: fsl-mc: updated copyright info
On 05/09/2018 12:26 AM, Yogesh Narayan Gaur wrote: > Updated copyright info for the issues reported after running > check-legal test. > > Signed-off-by: Yogesh Gaur > Reviewed-by: York Sun > --- > Legally NXP and Freescale Semiconductor are same entity. > Changes for v2: > - Rebase to top as per York's comment. > Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs
> Add back part of patch send out as > 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have > gotten lost when it got merged to set SYS_NS16550_MEM32. > > Allows serial output to work on tinker-rk3288 again after > c3c0331db1fb7b1f4ff41e144fc04353b37c785c. > > Signed-off-by: Kever Yang > Signed-off-by: Jonathan Gray > Cc: Philipp Tomsich > Reviewed-by: Philipp Tomsich > Acked-by: Philipp Tomsich > Reviewed-by: Philipp Tomsich > Tested-by: Heinrich Schuchardt > --- > include/configs/rockchip-common.h | 2 ++ > 1 file changed, 2 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug
Am 09.05.2018 um 14:33 schrieb klaus.go...@theobroma-systems.com: On 09.05.2018, at 10:19, Markus Krebs wrote: Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian: On 2018-05-08, Vagrant Cascadian wrote: On 2018-05-05, Tom Rini wrote: On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote: Markus Krebs discovered that the sheevaplug target has again grown and installation overlaps where the u-boot env is saved since u-boot ~2017.09. Running saveenv overwrites u-boot, and installing u-boot overwrites any prior environment settings. ... I've added the maintainer to the list as well. I would suggest looking for things to trim out, perhaps CMD_MEMTEST ? Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a *lot* left to disable in the config, but that's a significant start... And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it down to 432k! Thanks to beeble for the suggestion. Anyone who has a sheevaplug can test that it actually boots with CONFIG_SYS_THUMB_BUILD=y enabled? I could test it, but I don't know the config-file where I can change those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD). Both are Kconfig options. So just disable it via menuconfig or in your .config file Thanks. The modified u-boot (size indeed 441592 bytes only) boots! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed
Initial support for Avnet MiniZed board. Tested UART1 (serial console),
QSPI(Flash), SDHCI1 (eMMC), USB.
Signed-off-by: Ibai Erkiaga
---
Changes for v2:
-board model changed to use Avent prefix
-usb phy driver changed usb-no-xceiv
-removed gpio and intc binding
-fixed-partitions usage
---
U-Boot 2018.05-00023-gdf332c1-dirty (May 09 2018 - 14:50:51 +0100)
Model: Avnet Zynq MiniZed Development Board
Board: Xilinx Zynq
Silicon: v3.1
DRAM: ECC disabled 512 MiB
MMC: sdhci@e0101000: 0
Loading Environment from SPI Flash... SF: Detected n25q128 with page size 256
Bytes, erase size 64 KiB, total 16 MiB
OK
In:serial@e0001000
Out: serial@e0001000
Err: serial@e0001000
Net: No ethernet found.
Hit any key to stop autoboot: 0
Zynq> fatls mmc 0
16783864 image.ub
183 wpa_supplicant.conf
1391116 smallboot.bin
3 file(s), 0 dir(s)
Zynq> sf probe 0 0 0
SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Zynq> usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Zynq> fatls usb 0
12 test.txt
1 file(s), 0 dir(s)
Zynq>
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/zynq-minized.dts | 104
configs/zynq_minized_defconfig | 68 ++
3 files changed, 173 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/dts/zynq-minized.dts
create mode 100644 configs/zynq_minized_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6fe93a8..5c5f8a8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -129,6 +129,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cc108.dtb \
zynq-cse-qspi-single.dtb \
zynq-microzed.dtb \
+ zynq-minized.dtb \
zynq-picozed.dtb \
zynq-syzygy-hub.dtb \
zynq-topic-miami.dtb \
diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
new file mode 100644
index 000..68fe09a
--- /dev/null
+++ b/arch/arm/dts/zynq-minized.dts
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Avnet MiniZed board
+ *
+ * (C) Copyright 2017 - 2018, Xilinx, Inc.
+ *
+ * Ibai Erkiaga
+ */
+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+ model = "Avnet Zynq MiniZed Development Board";
+ compatible = "avnet,minized", "xlnx,zynq-7000";
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart0;
+ spi0 = &qspi;
+ mmc0 = &sdhci0;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "";
+ stdout-path = "serial0:115200n8";
+ };
+
+ usb_phy0: phy0 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+};
+
+&qspi {
+ status = "okay";
+ is-dual = <0>;
+ num-cs = <1>;
+ flash@0 {
+ compatible = "micron,m25p128";
+ reg = <0x0>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <5000>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "boot";
+ reg = <0x0 0xff>;
+ };
+
+ partition@027 {
+ label = "kernel";
+ reg = <0x27 0xd8>;
+ };
+
+ partition@ff {
+ label = "bootenv";
+ reg = <0xff 0x1>;
+ };
+
+ partition@100 {
+ label = "spare";
+ reg = <0x100 0x0>;
+ };
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+ dr_mode = "host";
+ usb-phy = <&usb_phy0>;
+ usb-reset = <&gpio0 7 0>; /* USB_RST_N-MIO7 */ };
+
+&sdhci1 {
+ status = "okay";
+ non-removable;
+ bus-width = <4>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mmccard: mmccard@0 {
+ compatible = "mmc-card";
+ reg = <0>;
+ broken-hpi;
+ };
+};
diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
new file mode 100644
index 000..05cfc0e
--- /dev/null
+++ b/configs/zynq_minized_defconfig
@@ -0,0 +1,68 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ZYNQ=y
+CONFIG_SYS_TEXT_BASE=0x40
Re: [U-Boot] [PATCH 09/12] ARM: kirkwood: Add device-tree for nsa310s
Hi Chris,
What we have in Linux mainline is Zyxel NSA310 (Marvell 88f6281). The Zyxel
NSA310S (Marvell 88f6702) is actually a different box, which has not been
mainlined yet.
By the way, there are 3 variations of the Zyxel NSA310 box. This box has
some combination of: red USB Led, lm85 sensor, adt7476 sensor that make
them slighly different. The mainlined NSA310 DTS is for the one with adt7476
sensor.
Regards
bodhi
On Tue, May 8, 2018 at 3:34 AM, Chris Packham
wrote:
> Import the dts files from Linux 4.17 and enable CONFIG_OF_CONTROL.
>
> Signed-off-by: Chris Packham
> ---
>
> arch/arm/dts/kirkwood-nsa310.dts | 139
> arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 158 +++
> configs/nsa310s_defconfig| 3 +-
> 3 files changed, 299 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/kirkwood-nsa310.dts
> create mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi
>
> diff --git a/arch/arm/dts/kirkwood-nsa310.dts b/arch/arm/dts/kirkwood-
> nsa310.dts
> new file mode 100644
> index ..9b861c2e76c5
> --- /dev/null
> +++ b/arch/arm/dts/kirkwood-nsa310.dts
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include "kirkwood-nsa3x0-common.dtsi"
> +
> +/ {
> + compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281",
> "marvell,kirkwood";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x1000>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + stdout-path = &uart0;
> + };
> +
> + ocp@f100 {
> + pinctrl: pin-controller@1 {
> + pinctrl-0 = <&pmx_unknown>;
> + pinctrl-names = "default";
> +
> + pmx_led_esata_green: pmx-led-esata-green {
> + marvell,pins = "mpp12";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_esata_red: pmx-led-esata-red {
> + marvell,pins = "mpp13";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_usb_green: pmx-led-usb-green {
> + marvell,pins = "mpp15";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_usb_red: pmx-led-usb-red {
> + marvell,pins = "mpp16";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_sys_green: pmx-led-sys-green {
> + marvell,pins = "mpp28";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_sys_red: pmx-led-sys-red {
> + marvell,pins = "mpp29";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_hdd_green: pmx-led-hdd-green {
> + marvell,pins = "mpp41";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_hdd_red: pmx-led-hdd-red {
> + marvell,pins = "mpp42";
> + marvell,function = "gpio";
> + };
> +
> + pmx_unknown: pmx-unknown {
> + marvell,pins = "mpp44";
> + marvell,function = "gpio";
> + };
> +
> + };
> +
> + i2c@11000 {
> + status = "okay";
> +
> + adt7476: adt7476a@2e {
> + compatible = "adi,adt7476";
> + reg = <0x2e>;
> + };
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <&pmx_led_esata_green &pmx_led_esata_red
> +&pmx_led_usb_green &pmx_led_usb_red
> +&pmx_led_sys_green &pmx_led_sys_red
> +&pmx_led_copy_green &pmx_led_copy_red
> +&pmx_led_hdd_green &pmx_led_hdd_red>;
> + pinctrl-names = "default";
> +
> + green-sys {
> + label = "nsa310:green:sys";
> + gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;
> + };
> + red-sys {
> + label = "nsa310:red:sys";
> + gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>;
> + };
> + green-hdd {
> + label = "nsa310:green:hdd";
> + gpios = <&
Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()
On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote:
> If we cannot determine the size of the serial terminal we still have
> to check the parameters of efi_cout_query_mode().
>
> Querying the size of the serial terminal drains the keyboard buffer.
> So make sure we do this during the initialization and not in the midst
> of an EFI application.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_console.c | 90
> +++-
> 1 file changed, 48 insertions(+), 42 deletions(-)
>
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index d687362a50..f1b8db55d6 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -13,8 +13,6 @@
> #include
> #include
>
> -static bool console_size_queried;
> -
> #define EFI_COUT_MODE_2 2
> #define EFI_MAX_COUT_MODE 3
>
> @@ -206,6 +204,51 @@ static int query_console_serial(int *rows, int *cols)
> return 0;
> }
>
> +/*
> + * Update the mode table.
> + *
> + * By default the only mode available is 80x25. If the console has at least
> 50
> + * lines, enable mode 80x50. If we can query the console size and it is
> neither
> + * 80x25 nor 80x50, set it as an additional mode.
> + */
> +static void query_console_size(void)
> +{
> + const char *stdout_name = env_get("stdout");
> + int rows, cols;
> +
> + if (stdout_name && !strcmp(stdout_name, "vidconsole") &&
> + IS_ENABLED(CONFIG_DM_VIDEO)) {
> + struct stdio_dev *stdout_dev =
> + stdio_get_by_name("vidconsole");
> + struct udevice *dev = stdout_dev->priv;
> + struct vidconsole_priv *priv =
> + dev_get_uclass_priv(dev);
> + rows = priv->rows;
> + cols = priv->cols;
> + } else if (query_console_serial(&rows, &cols)) {
> + return;
> + }
> +
> + /* Test if we can have Mode 1 */
> + if (cols >= 80 && rows >= 50) {
> + efi_cout_modes[1].present = 1;
> + efi_con_mode.max_mode = 2;
> + }
> +
> + /*
> + * Install our mode as mode 2 if it is different
> + * than mode 0 or 1 and set it as the currently selected mode
> + */
> + if (!cout_mode_matches(&efi_cout_modes[0], rows, cols) &&
> + !cout_mode_matches(&efi_cout_modes[1], rows, cols)) {
> + efi_cout_modes[EFI_COUT_MODE_2].columns = cols;
> + efi_cout_modes[EFI_COUT_MODE_2].rows = rows;
> + efi_cout_modes[EFI_COUT_MODE_2].present = 1;
> + efi_con_mode.max_mode = EFI_MAX_COUT_MODE;
> + efi_con_mode.mode = EFI_COUT_MODE_2;
> + }
> +}
> +
> static efi_status_t EFIAPI efi_cout_query_mode(
> struct efi_simple_text_output_protocol *this,
> unsigned long mode_number, unsigned long *columns,
> @@ -213,52 +256,12 @@ static efi_status_t EFIAPI efi_cout_query_mode(
> {
> EFI_ENTRY("%p, %ld, %p, %p", this, mode_number, columns, rows);
>
> - if (!console_size_queried) {
> - const char *stdout_name = env_get("stdout");
> - int rows, cols;
> -
> - console_size_queried = true;
> -
> - if (stdout_name && !strcmp(stdout_name, "vidconsole") &&
> - IS_ENABLED(CONFIG_DM_VIDEO)) {
> - struct stdio_dev *stdout_dev =
> - stdio_get_by_name("vidconsole");
> - struct udevice *dev = stdout_dev->priv;
> - struct vidconsole_priv *priv =
> - dev_get_uclass_priv(dev);
> - rows = priv->rows;
> - cols = priv->cols;
> - } else if (query_console_serial(&rows, &cols)) {
> - goto out;
> - }
> -
> - /* Test if we can have Mode 1 */
> - if (cols >= 80 && rows >= 50) {
> - efi_cout_modes[1].present = 1;
> - efi_con_mode.max_mode = 2;
> - }
> -
> - /*
> - * Install our mode as mode 2 if it is different
> - * than mode 0 or 1 and set it as the currently selected mode
> - */
> - if (!cout_mode_matches(&efi_cout_modes[0], rows, cols) &&
> - !cout_mode_matches(&efi_cout_modes[1], rows, cols)) {
> - efi_cout_modes[EFI_COUT_MODE_2].columns = cols;
> - efi_cout_modes[EFI_COUT_MODE_2].rows = rows;
> - efi_cout_modes[EFI_COUT_MODE_2].present = 1;
> - efi_con_mode.max_mode = EFI_MAX_COUT_MODE;
> - efi_con_mode.mode = EFI_COUT_MODE_2;
> - }
> - }
> -
> if (mode_number >= efi_con_mode.max_mode)
> return EFI_EXIT(EFI_UNSUPPORTED);
>
> if (efi_cout_modes[mode_number].present != 1)
> return EFI_EXIT(EFI_UNSUPPOR
[U-Boot] [PATCH 1/1] arm: print instructions pointed to by pc
If an exception occurs in a loaded image and the relocation offset is
unknown, it is helful to know the instructions pointed to by the
program counter. This patch adds the missing output.
A possible output is:
*pc: defe e7ff 8010 e8bd abb9 9ffc f7d5 9ffc
Signed-off-by: Heinrich Schuchardt
---
arch/arm/lib/interrupts.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index cda4d48460..24fa3d433d 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -60,6 +60,8 @@ static void show_efi_loaded_images(struct pt_regs *regs)
void show_regs (struct pt_regs *regs)
{
unsigned long __maybe_unused flags;
+ /* The least significant bit chooses thumb, remove it. */
+ u16 *pc = (u16 *)(instruction_pointer(regs) & ~1);
const char __maybe_unused *processor_modes[] = {
"USER_26", "FIQ_26", "IRQ_26", "SVC_26",
"UK4_26", "UK5_26", "UK6_26", "UK7_26",
@@ -97,6 +99,8 @@ void show_regs (struct pt_regs *regs)
fast_interrupts_enabled (regs) ? "on" : "off",
processor_modes[processor_mode (regs)],
thumb_mode (regs) ? " (T)" : "");
+ printf("*pc: %04x %04x %04x %04x %04x %04x %04x %04x\n",
+ pc[0], pc[1], pc[2], pc[3], pc[4], pc[5], pc[6], pc[7]);
}
/* fixup PC to point to the instruction leading to the exception */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GCC 7.x vs. C++ comments
Dear Tom, In message <20180509161456.gm12...@bill-the-cat.ec.rr.com> you wrote: > > I don't want to have it buried here but maybe it's time to talk about > fully adopting C99 (or, GNU C99). Did you happen to read > https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along? > Having read that after converting the tags that my first regex missed, > maybe we were wrong 18 years ago. OK. You know my opinion. > > is silly. We don't use these in Makefiles, or in shell scripts, or > > in ... > > We sometimes do for Makefiles, almost always do in shell scripts. You misunderstand. I meant: we do not use C++ comments in Makefiles or in shell scripts, or in most other non-C code... I drop out of this discussion here - thanks. Best regards, Wolfgang Denk -- 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 "Ada is PL/I trying to be Smalltalk. - Codoso diBlini ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()
On 05/09/2018 10:00 PM, Tom Rini wrote: > On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote: > >> If we cannot determine the size of the serial terminal we still have >> to check the parameters of efi_cout_query_mode(). >> >> Querying the size of the serial terminal drains the keyboard buffer. >> So make sure we do this during the initialization and not in the midst >> of an EFI application. >> >> Signed-off-by: Heinrich Schuchardt > > Even without this patch with a newer gcc we see: > https://travis-ci.org/trini/u-boot/jobs/376853382#L916 > > Can you address that while doing this fixup as well? Thanks! > I don't doubt there is an issue. But why don't we see the error outside of Travis CI? Do we set different flags when building? Can't see it with gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 nor with gcc (Debian 7.3.0-17) 7.3.0 Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()
On Wed, May 09, 2018 at 11:13:37PM +0200, Heinrich Schuchardt wrote: > On 05/09/2018 10:00 PM, Tom Rini wrote: > > On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote: > > > >> If we cannot determine the size of the serial terminal we still have > >> to check the parameters of efi_cout_query_mode(). > >> > >> Querying the size of the serial terminal drains the keyboard buffer. > >> So make sure we do this during the initialization and not in the midst > >> of an EFI application. > >> > >> Signed-off-by: Heinrich Schuchardt > > > > > > > Even without this patch with a newer gcc we see: > > https://travis-ci.org/trini/u-boot/jobs/376853382#L916 > > > > Can you address that while doing this fixup as well? Thanks! > > > > I don't doubt there is an issue. But why don't we see the error outside > of Travis CI? Do we set different flags when building? > > Can't see it with > gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > nor with > gcc (Debian 7.3.0-17) 7.3.0 As a warning or an error? The toolchain in question is https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_x86_64-linux.tar.xz and on that specific branch is where I'm testing moving buildman up. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()
On 05/09/2018 11:18 PM, Tom Rini wrote: > On Wed, May 09, 2018 at 11:13:37PM +0200, Heinrich Schuchardt wrote: >> On 05/09/2018 10:00 PM, Tom Rini wrote: >>> On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote: >>> If we cannot determine the size of the serial terminal we still have to check the parameters of efi_cout_query_mode(). Querying the size of the serial terminal drains the keyboard buffer. So make sure we do this during the initialization and not in the midst of an EFI application. Signed-off-by: Heinrich Schuchardt >> >> >> >>> >>> Even without this patch with a newer gcc we see: >>> https://travis-ci.org/trini/u-boot/jobs/376853382#L916 >>> >>> Can you address that while doing this fixup as well? Thanks! >>> >> >> I don't doubt there is an issue. But why don't we see the error outside >> of Travis CI? Do we set different flags when building? >> >> Can't see it with >> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 >> nor with >> gcc (Debian 7.3.0-17) 7.3.0 > > As a warning or an error? The toolchain in question is > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_x86_64-linux.tar.xz > and on that specific branch is where I'm testing moving buildman up. > Thanks! When I run git checkout master make qemu-x86_defconfig make -j6 I see no warning. I strongly dislike using buildman locally because it pulls in binaries from some dubious source which are not even signed. Best regards Heinrich > > > > ___ > 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: print instructions pointed to by pc
> Am 09.05.2018 um 22:16 schrieb Heinrich Schuchardt :
>
> If an exception occurs in a loaded image and the relocation offset is
> unknown, it is helful to know the instructions pointed to by the
> program counter. This patch adds the missing output.
>
> A possible output is:
> *pc: defe e7ff 8010 e8bd abb9 9ffc f7d5 9ffc
>
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/arm/lib/interrupts.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
> index cda4d48460..24fa3d433d 100644
> --- a/arch/arm/lib/interrupts.c
> +++ b/arch/arm/lib/interrupts.c
> @@ -60,6 +60,8 @@ static void show_efi_loaded_images(struct pt_regs *regs)
> void show_regs (struct pt_regs *regs)
> {
>unsigned long __maybe_unused flags;
> +/* The least significant bit chooses thumb, remove it. */
> +u16 *pc = (u16 *)(instruction_pointer(regs) & ~1);
u16 values are quite bad for this. Non-thumb instruuctions are 32bit, so will
be swapped in the output. Even with thumb you may get 32bit long ones.
Better just output everything as bytes. Then a simple xxd -ps -r can convert it
into a binary you can throw objdump on.
Alex
>const char __maybe_unused *processor_modes[] = {
>"USER_26","FIQ_26","IRQ_26","SVC_26",
>"UK4_26","UK5_26","UK6_26","UK7_26",
> @@ -97,6 +99,8 @@ void show_regs (struct pt_regs *regs)
>fast_interrupts_enabled (regs) ? "on" : "off",
>processor_modes[processor_mode (regs)],
>thumb_mode (regs) ? " (T)" : "");
> +printf("*pc: %04x %04x %04x %04x %04x %04x %04x %04x\n",
> + pc[0], pc[1], pc[2], pc[3], pc[4], pc[5], pc[6], pc[7]);
> }
>
> /* fixup PC to point to the instruction leading to the exception */
> --
> 2.17.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
