date:20180815

Enabled get_function support for dwapb where the function will
return the state of GPIO port.

Signed-off-by: Chin Liang See 
Signed-off-by: Ley Foon Tan 

---
v2: Change to use "if (gpio & BIT(offset))" bit masking.
---
 drivers/gpio/dwapb_gpio.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 680b11a..7cf2d47 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -78,11 +78,25 @@ static int dwapb_gpio_set_value(struct udevice *dev, 
unsigned pin, int val)
return 0;
 }
 
+static int dwapb_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
+   u32 gpio;
+
+   gpio = readl(plat->base + GPIO_SWPORT_DDR(plat->bank));
+
+   if (gpio & BIT(offset))
+   return GPIOF_OUTPUT;
+   else
+   return GPIOF_INPUT;
+}
+
 static const struct dm_gpio_ops gpio_dwapb_ops = {
.direction_input= dwapb_gpio_direction_input,
.direction_output   = dwapb_gpio_direction_output,
.get_value  = dwapb_gpio_get_value,
.set_value  = dwapb_gpio_set_value,
+   .get_function   = dwapb_gpio_get_function,
 };
 
 static int gpio_dwapb_probe(struct udevice *dev)
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] gpio: dwapb_gpio: Add reset ctrl to driver

Add code to reset all reset signals as in gpio DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 

---
v2:
- Move reset to probe() function.
---
 drivers/gpio/dwapb_gpio.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 7cf2d47..dfe1e6d 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -99,13 +100,30 @@ static const struct dm_gpio_ops gpio_dwapb_ops = {
.get_function   = dwapb_gpio_get_function,
 };
 
+static void gpio_dwapb_reset(struct udevice *dev)
+{
+   struct reset_ctl_bulk reset_bulk;
+   int ret;
+
+   ret = reset_get_bulk(dev, &reset_bulk);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   return;
+   }
+
+   reset_deassert_bulk(&reset_bulk);
+}
+
 static int gpio_dwapb_probe(struct udevice *dev)
 {
struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
struct gpio_dwapb_platdata *plat = dev->platdata;
 
-   if (!plat)
+   if (!plat) {
+   /* Reset on parent device only */
+   gpio_dwapb_reset(dev);
return 0;
+   }
 
priv->gpio_count = plat->pins;
priv->bank_name = plat->name;
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] usb: dwc2: Add reset ctrl to driver

Add code to reset all reset signals as in usb DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 

---
v2:
- Assert reset when .remove.
---
 drivers/usb/host/dwc2.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index cbe065b..bee3b33 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dwc2.h"
 
@@ -49,6 +50,8 @@ struct dwc2_priv {
 */
bool hnp_srp_disable;
bool oc_disable;
+
+   struct reset_ctl_bulk   resets;
 };
 
 #ifndef CONFIG_DM_USB
@@ -1124,11 +1127,37 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
usb_device *dev,
}
 }
 
+static int dwc2_reset(struct udevice *dev)
+{
+   int ret;
+   struct dwc2_priv *priv = dev_get_priv(dev);
+
+   ret = reset_get_bulk(dev, &priv->resets);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   return ret;
+   }
+
+   ret = reset_deassert_bulk(&priv->resets);
+   if (ret) {
+   reset_release_bulk(&priv->resets);
+   dev_err(dev, "Failed to reset: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
 {
struct dwc2_core_regs *regs = priv->regs;
uint32_t snpsid;
int i, j;
+   int ret;
+
+   ret = dwc2_reset(dev);
+   if (ret)
+   return ret;
 
snpsid = readl(®s->gsnpsid);
dev_info(dev, "Core Release: %x.%03x\n",
@@ -1303,6 +1332,8 @@ static int dwc2_usb_remove(struct udevice *dev)
 
dwc2_uninit_common(priv->regs);
 
+   reset_release_bulk(&priv->resets);
+
return 0;
 }
 
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "Revert "fdt_support: Use CONFIG_NR_DRAM_BANKS if defined""

2018-08-15 Thread Bin Meng

On Thu, Aug 16, 2018 at 4:02 AM, Vagrant Cascadian  wrote:
> This reverts commit 2a1f4f1758b55589395f90f583aacb07ae6fcafe.
>

Eh, this is a revert to a "revert" commit?

> Maybe there's a better way to fix this, but reverting this got
> odroid-xu4 booting agian:
>

Have we found out the real root cause? There must be a reason in the
original fix, then followed by another reasonable "revert", and now
the "revert" will be reverted again?

> U-Boot 2018.09-rc2+dfsg-1~20180814~1 (Aug 14 2018 - 18:33:28 +)
> for ODROID-XU3/XU4/HC1
>
> CPU:   Exynos5422 @ 800 MHz
> Model: Odroid XU3 based on EXYNOS5422
> Board: Odroid XU3 based on EXYNOS5422
> Type:  xu4
> DRAM:  2 GiB
> MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 2
> Loading Environment from MMC... *** Warning - No block device, using
> default environment
>
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> MMC Device 1 not found
> no mmc device at slot 1
> switch to partitions #0, OK
> mmc2 is current device
> Scanning mmc 2:2...
> Found U-Boot script /boot.scr
> 2445 bytes read in 3 ms (795.9 KiB/s)
> 3819744 bytes read in 364 ms (10 MiB/s)
> 54655 bytes read in 12 ms (4.3 MiB/s)
> 17611313 bytes read in 1676 ms (10 MiB/s)
> Booting Debian 4.9.0-7-armmp-lpae from mmc 2:2...
> Kernel image @ 0x4200 [ 0x00 - 0x3a48e0 ]
>Booting using the fdt blob at 0x4300
>Loading Ramdisk to 4ef34000, end 4a31 ... OK
>Loading Device Tree to 4ef23000, end 4ef3357e ... OK
> fdt_fixup_memory_banks: num banks 8 exceeds hardcoded limit
> 4. Recompile with higher MEMORY_BANKS_MAX?
> ERROR: arch-specific fdt fixup failed
>  - must RESET the board to recover.
>
> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
>
> Signed-off-by: Vagrant Cascadian 
> ---
>
>  common/fdt_support.c | 4 
>  1 file changed, 4 insertions(+)
>

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] board: arm: bcmstb: Declare get_ticks in timer.h

2018-08-15 Thread Thomas Fitzsimmons

In an earlier proposed patch, bcmstb.c implemented timer_read_counter,
but it was updated to implement get_ticks instead.  This patch updates
the declaration in timer.h accordingly.

Signed-off-by: Thomas Fitzsimmons 
---
 arch/arm/mach-bcmstb/include/mach/timer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcmstb/include/mach/timer.h 
b/arch/arm/mach-bcmstb/include/mach/timer.h
index d05b4d6..039dd66 100644
--- a/arch/arm/mach-bcmstb/include/mach/timer.h
+++ b/arch/arm/mach-bcmstb/include/mach/timer.h
@@ -8,6 +8,6 @@
 #ifndef _BCMSTB_TIMER_H
 #define _BCMSTB_TIMER_H
 
-unsigned long timer_read_counter(void);
+uint64_t get_ticks(void);
 
 #endif /* _BCMSTB_TIMER_H */
-- 
1.8.3.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/5] arm: socfpga: fix SPL booting from fpga OnChip RAM

On 08/15/2018 09:23 PM, Simon Goldschmidt wrote:
> On Wed, Aug 15, 2018 at 10:57 AM Marek Vasut  wrote:
>>
>> On 08/14/2018 10:26 PM, Simon Goldschmidt wrote:
>>> On Tue, Aug 14, 2018 at 8:12 AM Simon Goldschmidt
>>>  wrote:



 Marek Vasut  schrieb am Mo., 13. Aug. 2018, 22:36:
>
> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
>> To boot from fpga OnChip RAM, some changes are required in SPL
>> to ensure the code is linked to the correct address (in contrast
>> to QSPI and MMC boot, FPGA boot executes SPL in place instead of
>> copying it to SRAM) and that fpga OnChip RAM stays accessible while
>> SPL runs (don't disable fpga bridges).
>>
>> This adds a new config option (CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA)
>> for socfpga gen5 boards.
>>
>> Signed-off-by: Simon Goldschmidt 
>> ---
>>
>> Changes in v4: Adapted to changed previous patch
>> Changes in v3: this patch is new in v3
>> Changes in v2: None
>>
>>  arch/arm/mach-socfpga/Kconfig | 12 
>>  arch/arm/mach-socfpga/misc_gen5.c | 11 +--
>>  arch/arm/mach-socfpga/spl_gen5.c  |  6 --
>>  include/configs/socfpga_common.h  |  5 +
>>  4 files changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-socfpga/Kconfig 
>> b/arch/arm/mach-socfpga/Kconfig
>> index 5c1df2cf1f..a909395aac 100644
>> --- a/arch/arm/mach-socfpga/Kconfig
>> +++ b/arch/arm/mach-socfpga/Kconfig
>> @@ -132,3 +132,15 @@ config SYS_CONFIG_NAME
>>   default "socfpga_vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
>>
>>  endif
>> +
>> +if TARGET_SOCFPGA_GEN5
>> +
>> +config SPL_SOCFPGA_BOOT_FROM_FPGA
>> + bool "Allow booting SPL from FPGA OnChip RAM"
>> + default n
>> + help
>> +   Boot from FPGA: this changes the linker address for SPL code to 
>> run
>> +   from FPGA OnChip memory instead of SRAM and ensures FPGA OnChip 
>> RAM
>> +   stays accessible while SPL runs.
>> +
>> +endif
>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
>> b/arch/arm/mach-socfpga/misc_gen5.c
>> index 429c3d6cd5..c82c3584dc 100644
>> --- a/arch/arm/mach-socfpga/misc_gen5.c
>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
>> @@ -187,7 +187,13 @@ void socfpga_sdram_remap_zero(void)
>>   setbits_le32(&scu_regs->sacr, 0xfff);
>>
>>   /* Configure the L2 controller to make SDRAM start at 0 */
>> - writel(0x1, &nic301_regs->remap);   /* remap.mpuzero */
>> + if (CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA)) {
>> + /* remap.mpuzero, keep fpga bridge enabled */
>> + writel(0x9, &nic301_regs->remap);
>> + } else {
>> + /* remap.mpuzero */
>> + writel(0x1, &nic301_regs->remap);
>> + }
>>   writel(0x1, &pl310->pl310_addr_filter_start);
>>  }
>>
>> @@ -209,7 +215,8 @@ int arch_early_init_r(void)
>>   for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
>>   iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
>>
>> - socfpga_bridges_reset(1);
>> + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>> + socfpga_bridges_reset(1);
>>
>>   socfpga_sdram_remap_zero();
>>
>> diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
>> b/arch/arm/mach-socfpga/spl_gen5.c
>> index be318cc0d9..0c7f6a8c84 100644
>> --- a/arch/arm/mach-socfpga/spl_gen5.c
>> +++ b/arch/arm/mach-socfpga/spl_gen5.c
>> @@ -93,7 +93,8 @@ void board_init_f(ulong dummy)
>>   /* Put everything into reset but L4WD0. */
>>   socfpga_per_reset_all();
>>   /* Put FPGA bridges into reset too. */
>> - socfpga_bridges_reset(1);
>> + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>> + socfpga_bridges_reset(1);
>>
>>   socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
>>   socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
>> @@ -163,5 +164,6 @@ void board_init_f(ulong dummy)
>>   hang();
>>   }
>>
>> - socfpga_bridges_reset(1);
>> + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>> + socfpga_bridges_reset(1);
>>  }
>> diff --git a/include/configs/socfpga_common.h 
>> b/include/configs/socfpga_common.h
>> index d1148b838b..99c5e39086 100644
>> --- a/include/configs/socfpga_common.h
>> +++ b/include/configs/socfpga_common.h
>> @@ -239,7 +239,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>>   * 0xFFEz_ .. Malloc area (grows up to top)
>>   * 0xFFE3_ .. End of SRAM (top)
>>   */
>> +#if CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA
>> +/* SPL executed from FPGA */
>> +#define CONFIG_SPL_TEXT_BASE 0xC000
>> +#else
>>  #define CONFIG_SPL_

Re: [U-Boot] [PATCH 1/5 v2] mips: Add basic MediaTek MT7620/88 support



On 10.08.2018 09:48, Stefan Roese wrote:
> This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of
> the code is copied from the MediaTek GitHub repository:
> 
> https://github.com/MediaTek-Labs/linkit-smart-uboot.git
> 
> Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway
> both based on the MT7688 will be added in further patches.
> 
> Signed-off-by: Stefan Roese 
> Cc: Daniel Schwierzeck 
> ---
> v2:
> - Sort Kconfig symbols alphabetically
> - Use MIPS_TUNE_24KC
> - Use imply for SPI support
> - Dont' add LinkIt module support yet (is added with the board support)
> - Move SKIP_LOWLEVEL_INIT from Kconfig to config header
> - Use DT to get the base address of the system controller (for
>   display_cpuinfo)
> - Remove _machine_restart - a separate driver is provided in a new patch
> - Remove cachop_op() and cal_invalidate_dcache_range and use the
>   generic invalidate_dcache_range function instead
> 
> Daniel I tried to change to CPU_HAS PREFETCH, but this did not work
> smoothly. It seems this option is very old and outdated. Perhaps I
> can revisit this again, once this patchset has settled a bit.
>   
>  arch/mips/Kconfig |  15 ++
>  arch/mips/Makefile|   1 +
>  arch/mips/mach-mt7620/Kconfig | 113 +
>  arch/mips/mach-mt7620/Makefile|   8 +
>  arch/mips/mach-mt7620/cpu.c   |  72 ++
>  arch/mips/mach-mt7620/ddr_calibrate.c | 307 +++
>  arch/mips/mach-mt7620/lowlevel_init.S | 337 ++
>  arch/mips/mach-mt7620/mt76xx.h|  38 +++
>  8 files changed, 891 insertions(+)
>  create mode 100644 arch/mips/mach-mt7620/Kconfig
>  create mode 100644 arch/mips/mach-mt7620/Makefile
>  create mode 100644 arch/mips/mach-mt7620/cpu.c
>  create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c
>  create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S
>  create mode 100644 arch/mips/mach-mt7620/mt76xx.h
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 31b622ff51..b7c5fa3114 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -87,6 +87,20 @@ config ARCH_BMIPS
>   select SYSRESET
>   imply CMD_DM
>  
> +config ARCH_MT7620
> + bool "Support MT7620/7688 SoCs"
> + select DISPLAY_CPUINFO
> + select DM
> + select DM_SERIAL
> + imply DM_SPI
> + imply DM_SPI_FLASH
> + select MIPS_TUNE_24KC
> + select OF_CONTROL
> + select ROM_EXCEPTION_VECTORS
> + select SUPPORTS_CPU_MIPS32_R1
> + select SUPPORTS_CPU_MIPS32_R2
> + select SUPPORTS_LITTLE_ENDIAN
> +
>  config MACH_PIC32
>   bool "Support Microchip PIC32"
>   select DM
> @@ -141,6 +155,7 @@ source "board/qemu-mips/Kconfig"
>  source "arch/mips/mach-ath79/Kconfig"
>  source "arch/mips/mach-bmips/Kconfig"
>  source "arch/mips/mach-pic32/Kconfig"
> +source "arch/mips/mach-mt7620/Kconfig"
>  
>  if MIPS
>  
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 5deec9a202..cc8ea5d7d4 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -15,6 +15,7 @@ machine-$(CONFIG_SOC_AU1X00) += au1x00
>  machine-$(CONFIG_ARCH_ATH79) += ath79
>  machine-$(CONFIG_ARCH_BMIPS) += bmips
>  machine-$(CONFIG_MACH_PIC32) += pic32
> +machine-$(CONFIG_ARCH_MT7620) += mt7620
>  
>  machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
>  libs-y += $(machdirs)
> diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mt7620/Kconfig
> new file mode 100644
> index 00..396fbd0141
> --- /dev/null
> +++ b/arch/mips/mach-mt7620/Kconfig
> @@ -0,0 +1,113 @@
> +menu "MediaTek MIPS platforms"
> + depends on ARCH_MT7620
> +
> +config SYS_MALLOC_F_LEN
> + default 0x1000
> +
> +config SYS_SOC
> + default "mt7620" if SOC_MT7620
> +
> +choice
> + prompt "MediaTek MIPS SoC select"
> +
> +config SOC_MT7620
> + bool "MT7620/8"
> + select MIPS_L1_CACHE_SHIFT_5
> + help
> +   This supports MediaTek MIPS MT7620 family.
> +
> +endchoice
> +
> +choice
> + prompt "Board select"
> +
> +endchoice
> +
> +choice
> + prompt "Boot mode"
> +
> +config BOOT_RAM
> + bool "RAM boot"
> + depends on SUPPORTS_BOOT_RAM
> + help
> +   This builds an image that is linked to a RAM address. It can be used
> +   for booting from CFE via TFTP using an ELF image, but it can also be
> +   booted from RAM by other bootloaders using a BIN image.
> +
> +config BOOT_ROM
> + bool "ROM boot"
> + depends on SUPPORTS_BOOT_RAM
> + help
> +   This builds an image that is linked to a ROM address. It can be
> +   used as main bootloader image which is programmed onto the onboard
> +   flash storage (SPI NOR).
> +
> +endchoice
> +
> +choice
> + prompt "DDR2 size"
> +
> +config ONBOARD_DDR2_SIZE_256MBIT
> + bool "256MBit (32MByte) total size"
> + depends on BOOT_ROM
> + help
> +   Use 256MBit (32MByte) of DDR total size
> +
> +config ONBOARD_DDR2_SIZE_512MBIT
> + bool "512MBi

[U-Boot] [PATCH] i2c: Drop CONFIG_SYS_I2C_MXS

2018-08-15 Thread Tuomas Tynkkynen

Last user of this driver went away in May 2017, in
commit eb5ba3aefdf0f6 ("i2c: Drop use of CONFIG_I2C_HARD")

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/i2c/Makefile  |   1 -
 drivers/i2c/mxs_i2c.c | 319 --
 2 files changed, 320 deletions(-)
 delete mode 100644 drivers/i2c/mxs_i2c.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index da368cc02a..f2cbe78c53 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_SYS_I2C_LPC32XX) += lpc32xx_i2c.o
 obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o
 obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
 obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
-obj-$(CONFIG_SYS_I2C_MXS) += mxs_i2c.o
 obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_I2C) += rcar_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_IIC) += rcar_iic.o
diff --git a/drivers/i2c/mxs_i2c.c b/drivers/i2c/mxs_i2c.c
deleted file mode 100644
index 6766d37547..00
--- a/drivers/i2c/mxs_i2c.c
+++ /dev/null
@@ -1,319 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Freescale i.MX28 I2C Driver
- *
- * Copyright (C) 2011 Marek Vasut 
- * on behalf of DENX Software Engineering GmbH
- *
- * Partly based on Linux kernel i2c-mxs.c driver:
- * Copyright (C) 2011 Wolfram Sang, Pengutronix e.K.
- *
- * Which was based on a (non-working) driver which was:
- * Copyright (C) 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#defineMXS_I2C_MAX_TIMEOUT 100
-
-static struct mxs_i2c_regs *mxs_i2c_get_base(struct i2c_adapter *adap)
-{
-   if (adap->hwadapnr == 0)
-   return (struct mxs_i2c_regs *)MXS_I2C0_BASE;
-   else
-   return (struct mxs_i2c_regs *)MXS_I2C1_BASE;
-}
-
-static unsigned int mxs_i2c_get_bus_speed(struct i2c_adapter *adap)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   uint32_t clk = mxc_get_clock(MXC_XTAL_CLK);
-   uint32_t timing0;
-
-   timing0 = readl(&i2c_regs->hw_i2c_timing0);
-   /*
-* This is a reverse version of the algorithm presented in
-* i2c_set_bus_speed(). Please refer there for details.
-*/
-   return clk / timing0 >> 16) - 3) * 2) + 38);
-}
-
-static uint mxs_i2c_set_bus_speed(struct i2c_adapter *adap, uint speed)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   /*
-* The timing derivation algorithm. There is no documentation for this
-* algorithm available, it was derived by using the scope and fiddling
-* with constants until the result observed on the scope was good enough
-* for 20kHz, 50kHz, 100kHz, 200kHz, 300kHz and 400kHz. It should be
-* possible to assume the algorithm works for other frequencies as well.
-*
-* Note it was necessary to cap the frequency on both ends as it's not
-* possible to configure completely arbitrary frequency for the I2C bus
-* clock.
-*/
-   uint32_t clk = mxc_get_clock(MXC_XTAL_CLK);
-   uint32_t base = ((clk / speed) - 38) / 2;
-   uint16_t high_count = base + 3;
-   uint16_t low_count = base - 3;
-   uint16_t rcv_count = (high_count * 3) / 4;
-   uint16_t xmit_count = low_count / 4;
-
-   if (speed > 54) {
-   printf("MXS I2C: Speed too high (%d Hz)\n", speed);
-   return -EINVAL;
-   }
-
-   if (speed < 12000) {
-   printf("MXS I2C: Speed too low (%d Hz)\n", speed);
-   return -EINVAL;
-   }
-
-   writel((high_count << 16) | rcv_count, &i2c_regs->hw_i2c_timing0);
-   writel((low_count << 16) | xmit_count, &i2c_regs->hw_i2c_timing1);
-
-   writel((0x0030 << I2C_TIMING2_BUS_FREE_OFFSET) |
-   (0x0030 << I2C_TIMING2_LEADIN_COUNT_OFFSET),
-   &i2c_regs->hw_i2c_timing2);
-
-   return 0;
-}
-
-static void mxs_i2c_reset(struct i2c_adapter *adap)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   int ret;
-   int speed = mxs_i2c_get_bus_speed(adap);
-
-   ret = mxs_reset_block(&i2c_regs->hw_i2c_ctrl0_reg);
-   if (ret) {
-   debug("MXS I2C: Block reset timeout\n");
-   return;
-   }
-
-   writel(I2C_CTRL1_DATA_ENGINE_CMPLT_IRQ | I2C_CTRL1_NO_SLAVE_ACK_IRQ |
-   I2C_CTRL1_EARLY_TERM_IRQ | I2C_CTRL1_MASTER_LOSS_IRQ |
-   I2C_CTRL1_SLAVE_STOP_IRQ | I2C_CTRL1_SLAVE_IRQ,
-   &i2c_regs->hw_i2c_ctrl1_clr);
-
-   writel(I2C_QUEUECTRL_PIO_QUEUE_MODE, &i2c_regs->hw_i2c_queuectrl_set);
-
-   mxs_i2c_set_bus_speed(adap, speed);
-}
-
-static void mxs_i2c_setup_read(struct i2c_adapter *adap, uint8_t chip, int len)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-
-   writel(I2C_QUEUECMD_RETAIN_CLOCK | I2C_QUEUECMD_PRE_SEND_START |
-   I2C_QUEUECMD_MASTER_MODE | I2C_QUEUECMD_D

Re: [U-Boot] [PATCH 3/5 v2] mips: Add LinkIt Smart 7688 support



On 10.08.2018 09:48, Stefan Roese wrote:
> The LinkIt Smart 7688 modules have a MT7688 SoC with 128 MiB of RAM
> and 32 MiB of flash (SPI NOR).
> 
> The mt7628a.dtsi file is imported from Linux v4.17.
> 
> This patch also includes 2 targets. One is the target that can be
> programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
> added to support loading and booting via an already running U-Boot
> version. This allows easy development and testing without the
> need to flash the image each time.
> 
> Signed-off-by: Stefan Roese 
> Cc: Daniel Schwierzeck 
> ---
> v2:
> - Kconfig entries added with this patch now
> 
>  arch/mips/dts/linkit-smart-7688.dts   |  46 
>  arch/mips/dts/mt7628a.dtsi| 135 ++

this file should be added with patch 1/5

>  arch/mips/mach-mt7620/Kconfig |  13 +++
>  board/seeed/linkit-smart-7688/Kconfig |  12 ++
>  board/seeed/linkit-smart-7688/MAINTAINERS |   8 ++
>  board/seeed/linkit-smart-7688/Makefile|   3 +
>  board/seeed/linkit-smart-7688/board.c |  22 
>  configs/linkit-smart-7688-ram_defconfig   |  58 ++
>  configs/linkit-smart-7688_defconfig   |  62 ++
>  include/configs/linkit-smart-7688.h   |  52 +
>  10 files changed, 411 insertions(+)
>  create mode 100644 arch/mips/dts/linkit-smart-7688.dts
>  create mode 100644 arch/mips/dts/mt7628a.dtsi
>  create mode 100644 board/seeed/linkit-smart-7688/Kconfig
>  create mode 100644 board/seeed/linkit-smart-7688/MAINTAINERS
>  create mode 100644 board/seeed/linkit-smart-7688/Makefile
>  create mode 100644 board/seeed/linkit-smart-7688/board.c
>  create mode 100644 configs/linkit-smart-7688-ram_defconfig
>  create mode 100644 configs/linkit-smart-7688_defconfig
>  create mode 100644 include/configs/linkit-smart-7688.h

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Revert "Revert "fdt_support: Use CONFIG_NR_DRAM_BANKS if defined""

2018-08-15 Thread Vagrant Cascadian

This reverts commit 2a1f4f1758b55589395f90f583aacb07ae6fcafe.

Maybe there's a better way to fix this, but reverting this got
odroid-xu4 booting agian:

U-Boot 2018.09-rc2+dfsg-1~20180814~1 (Aug 14 2018 - 18:33:28 +)
for ODROID-XU3/XU4/HC1

CPU:   Exynos5422 @ 800 MHz
Model: Odroid XU3 based on EXYNOS5422
Board: Odroid XU3 based on EXYNOS5422
Type:  xu4
DRAM:  2 GiB
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 2
Loading Environment from MMC... *** Warning - No block device, using
default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc2 is current device
Scanning mmc 2:2...
Found U-Boot script /boot.scr
2445 bytes read in 3 ms (795.9 KiB/s)
3819744 bytes read in 364 ms (10 MiB/s)
54655 bytes read in 12 ms (4.3 MiB/s)
17611313 bytes read in 1676 ms (10 MiB/s)
Booting Debian 4.9.0-7-armmp-lpae from mmc 2:2...
Kernel image @ 0x4200 [ 0x00 - 0x3a48e0 ]
   Booting using the fdt blob at 0x4300
   Loading Ramdisk to 4ef34000, end 4a31 ... OK
   Loading Device Tree to 4ef23000, end 4ef3357e ... OK
fdt_fixup_memory_banks: num banks 8 exceeds hardcoded limit
4. Recompile with higher MEMORY_BANKS_MAX?
ERROR: arch-specific fdt fixup failed
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

Signed-off-by: Vagrant Cascadian 
---

 common/fdt_support.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 34d2bd59c4..be8cdfbeb3 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -409,7 +409,11 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64 
*address, u64 *size,
return p - (char *)buf;
 }
 
+#ifdef CONFIG_NR_DRAM_BANKS
+#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
+#else
 #define MEMORY_BANKS_MAX 4
+#endif
 int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
 {
int err, nodeoffset;
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/5] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-08-15 Thread Simon Goldschmidt

On Wed, Aug 15, 2018 at 10:57 AM Marek Vasut  wrote:
>
> On 08/14/2018 10:26 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 8:12 AM Simon Goldschmidt
> >  wrote:
> >>
> >>
> >>
> >> Marek Vasut  schrieb am Mo., 13. Aug. 2018, 22:36:
> >>>
> >>> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
>  To boot from fpga OnChip RAM, some changes are required in SPL
>  to ensure the code is linked to the correct address (in contrast
>  to QSPI and MMC boot, FPGA boot executes SPL in place instead of
>  copying it to SRAM) and that fpga OnChip RAM stays accessible while
>  SPL runs (don't disable fpga bridges).
> 
>  This adds a new config option (CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA)
>  for socfpga gen5 boards.
> 
>  Signed-off-by: Simon Goldschmidt 
>  ---
> 
>  Changes in v4: Adapted to changed previous patch
>  Changes in v3: this patch is new in v3
>  Changes in v2: None
> 
>   arch/arm/mach-socfpga/Kconfig | 12 
>   arch/arm/mach-socfpga/misc_gen5.c | 11 +--
>   arch/arm/mach-socfpga/spl_gen5.c  |  6 --
>   include/configs/socfpga_common.h  |  5 +
>   4 files changed, 30 insertions(+), 4 deletions(-)
> 
>  diff --git a/arch/arm/mach-socfpga/Kconfig 
>  b/arch/arm/mach-socfpga/Kconfig
>  index 5c1df2cf1f..a909395aac 100644
>  --- a/arch/arm/mach-socfpga/Kconfig
>  +++ b/arch/arm/mach-socfpga/Kconfig
>  @@ -132,3 +132,15 @@ config SYS_CONFIG_NAME
>    default "socfpga_vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> 
>   endif
>  +
>  +if TARGET_SOCFPGA_GEN5
>  +
>  +config SPL_SOCFPGA_BOOT_FROM_FPGA
>  + bool "Allow booting SPL from FPGA OnChip RAM"
>  + default n
>  + help
>  +   Boot from FPGA: this changes the linker address for SPL code to 
>  run
>  +   from FPGA OnChip memory instead of SRAM and ensures FPGA OnChip 
>  RAM
>  +   stays accessible while SPL runs.
>  +
>  +endif
>  diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
>  b/arch/arm/mach-socfpga/misc_gen5.c
>  index 429c3d6cd5..c82c3584dc 100644
>  --- a/arch/arm/mach-socfpga/misc_gen5.c
>  +++ b/arch/arm/mach-socfpga/misc_gen5.c
>  @@ -187,7 +187,13 @@ void socfpga_sdram_remap_zero(void)
>    setbits_le32(&scu_regs->sacr, 0xfff);
> 
>    /* Configure the L2 controller to make SDRAM start at 0 */
>  - writel(0x1, &nic301_regs->remap);   /* remap.mpuzero */
>  + if (CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA)) {
>  + /* remap.mpuzero, keep fpga bridge enabled */
>  + writel(0x9, &nic301_regs->remap);
>  + } else {
>  + /* remap.mpuzero */
>  + writel(0x1, &nic301_regs->remap);
>  + }
>    writel(0x1, &pl310->pl310_addr_filter_start);
>   }
> 
>  @@ -209,7 +215,8 @@ int arch_early_init_r(void)
>    for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
>    iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
> 
>  - socfpga_bridges_reset(1);
>  + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>  + socfpga_bridges_reset(1);
> 
>    socfpga_sdram_remap_zero();
> 
>  diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
>  b/arch/arm/mach-socfpga/spl_gen5.c
>  index be318cc0d9..0c7f6a8c84 100644
>  --- a/arch/arm/mach-socfpga/spl_gen5.c
>  +++ b/arch/arm/mach-socfpga/spl_gen5.c
>  @@ -93,7 +93,8 @@ void board_init_f(ulong dummy)
>    /* Put everything into reset but L4WD0. */
>    socfpga_per_reset_all();
>    /* Put FPGA bridges into reset too. */
>  - socfpga_bridges_reset(1);
>  + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>  + socfpga_bridges_reset(1);
> 
>    socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
>    socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
>  @@ -163,5 +164,6 @@ void board_init_f(ulong dummy)
>    hang();
>    }
> 
>  - socfpga_bridges_reset(1);
>  + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
>  + socfpga_bridges_reset(1);
>   }
>  diff --git a/include/configs/socfpga_common.h 
>  b/include/configs/socfpga_common.h
>  index d1148b838b..99c5e39086 100644
>  --- a/include/configs/socfpga_common.h
>  +++ b/include/configs/socfpga_common.h
>  @@ -239,7 +239,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>    * 0xFFEz_ .. Malloc area (grows up to top)
>    * 0xFFE3_ .. End of SRAM (top)
>    */
>  +#if CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA
>  +/* SPL executed from FPGA */
>  +#define CONFIG_SPL_TEXT_BASE 0xC000
>  +#else
>   #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR
>  +#e

[U-Boot] [PATCH V2] ARM: configs: Add da850evm_nand to boot from NAND

The DA850-EVM supports booting from NAND when used with the
UI expander board.  da850evm_nand will create an ais file
that can be burned to NAND and booted while storing the env in
NAND along with some partitions tables for storing kernel,
dtb and rootfs in NAND.

Signed-off-by: Adam Ford 
---
V2:  Increase the U-Boot size to fit u-boot.ais (not u-boot.bin)

diff --git a/board/davinci/da8xxevm/MAINTAINERS 
b/board/davinci/da8xxevm/MAINTAINERS
index 99b4786dd5..59589867b3 100644
--- a/board/davinci/da8xxevm/MAINTAINERS
+++ b/board/davinci/da8xxevm/MAINTAINERS
@@ -5,6 +5,7 @@ F:  board/davinci/da8xxevm/
 F: include/configs/da850evm.h
 F: configs/da850_am18xxevm_defconfig
 F: configs/da850evm_defconfig
+F: configs/da850evm_nand_defconfig
 F: configs/da850evm_direct_nor_defconfig
 
 OMAPL138_LCDK BOARD
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
new file mode 100644
index 00..11d6a2b4c5
--- /dev/null
+++ b/configs/da850evm_nand_defconfig
@@ -0,0 +1,60 @@
+CONFIG_ARM=y
+CONFIG_ARCH_DAVINCI=y
+CONFIG_SYS_TEXT_BASE=0xc108
+CONFIG_TARGET_DA850EVM=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
+CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH"
+CONFIG_BOOTDELAY=3
+CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_CRC32_VERIFY=y
+# CONFIG_CMD_EEPROM is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_GPT is not set
+CONFIG_CMD_NAND=y
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_TIME is not set
+# CONFIG_CMD_EXT4 is not set
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=nand512"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=nand512:128k(u-boot 
env),512k(u-boot),128k(spl-os),8m(kernel),-(rootfs)"
+CONFIG_CMD_DIAG=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_IN_NAND=y
+CONFIG_DM=y
+CONFIG_DM_GPIO=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_NAND=y
+CONFIG_NAND_DAVINCI=y
+CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
+CONFIG_SYS_NAND_U_BOOT_OFFS=0x28000
+CONFIG_SPL_NAND_SIMPLE=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_DAVINCI_SPI=y
+# CONFIG_FAT_WRITE is not set
+CONFIG_USE_TINY_PRINTF=y
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 3dcd1390ca..93aa02cfa0 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -37,6 +37,7 @@
 #define CONFIG_SYS_OSCIN_FREQ  2400
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
+#define CONFIG_SKIP_LOWLEVEL_INIT
 
 #ifdef CONFIG_DIRECT_NOR_BOOT
 #define CONFIG_ARCH_CPU_INIT
@@ -149,8 +150,11 @@
  * Flash & Environment
  */
 #ifdef CONFIG_NAND
+#ifdef CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_OFFSET  0x0 /* Block 0--not used by bootcode */
 #define CONFIG_ENV_SIZE(128 << 10)
+#define CONFIG_ENV_SECT_SIZE   (128 << 10)
+#endif
 #defineCONFIG_SYS_NAND_USE_FLASH_BBT
 #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
 #defineCONFIG_SYS_NAND_PAGE_2K
@@ -164,8 +168,7 @@
 #define CONFIG_SYS_NAND_5_ADDR_CYCLE
 #define CONFIG_SYS_NAND_PAGE_SIZE  (2 << 10)
 #define CONFIG_SYS_NAND_BLOCK_SIZE (128 << 10)
-#define CONFIG_SYS_NAND_U_BOOT_OFFS0x28000
-#define CONFIG_SYS_NAND_U_BOOT_SIZE0x6
+#define CONFIG_SYS_NAND_U_BOOT_SIZE0x4
 #define CONFIG_SYS_NAND_U_BOOT_DST 0xc108
 #define CONFIG_SYS_NAND_U_BOOT_START   CONFIG_SYS_NAND_U_BOOT_DST
 #define CONFIG_SYS_NAND_U_BOOT_RELOC_SP(CONFIG_SYS_NAND_U_BOOT_DST - \
@@ -215,9 +218,11 @@
 #endif
 
 #ifdef CONFIG_USE_SPIFLASH
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_ENV_SIZE(64 << 10)
 #define CONFIG_ENV_OFFSET  (512 << 10)
-#define CONFIG_ENV_SECT_SIZE   (64 << 10)
+#define CONFIG_ENV_SECT_SIZE   (64 << 10)
+#endif
 #ifdef CONFIG_SPL_BUILD
 #undef CONFIG_SPI_FLASH_MTD
 #endif
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: davinci: Full dm conversion

On Wed, Aug 15, 2018 at 8:20 AM Adam Ford  wrote:
>
> On Mon, Aug 13, 2018 at 6:50 PM Adam Ford  wrote:
> >
> > On Mon, Aug 13, 2018 at 5:09 PM Adam Ford  wrote:
> > >
> > > On Mon, Aug 13, 2018 at 1:29 PM Simon Goldschmidt
> > >  wrote:
> > > >
> > > > On Mon, Aug 13, 2018 at 3:46 PM Alex Kiernan  
> > > > wrote:
> > > > >
> > > > > On Mon, Aug 13, 2018 at 1:40 PM Adam Ford  wrote:
> > > > > >
> > > > > > On Sat, Aug 11, 2018 at 3:09 PM Adam Ford  
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Aug 11, 2018, 1:24 PM Jagan Teki 
> > > > > > >  wrote:
> > > > > > >>
> > > > > > >> On Sat, Aug 11, 2018 at 6:12 PM, Adam Ford  
> > > > > > >> wrote:
> > > > > > >> > On Fri, Aug 10, 2018 at 2:58 PM Adam Ford  
> > > > > > >> > wrote:
> > > > > > >> >>
> > > > > > >> >> On Fri, Aug 10, 2018 at 7:42 AM Jagan Teki 
> > > > > > >> >>  wrote:
> > > > > > >> >> >
> > > > > > >> >> > On Fri, Aug 10, 2018 at 3:50 PM, Adam Ford 
> > > > > > >> >> >  wrote:
> > > > > > >> >> > > On Fri, Aug 10, 2018 at 12:14 AM Jagan Teki 
> > > > > > >> >> > >  wrote:
> > > > > > >> >> > >>
> > > > > > >> >> > >> On Wed, Aug 8, 2018 at 6:47 PM, Adam Ford 
> > > > > > >> >> > >>  wrote:
> > > > > > >> >> > >> > On Tue, Aug 7, 2018 at 1:29 AM Jagan Teki 
> > > > > > >> >> > >> >  wrote:
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >> davinci_spi now support dt along with platform data,
> > > > > > >> >> > >> >> respective boards need to switch into dm for the same.
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >> Cc: Adam Ford 
> > > > > > >> >> > >> >> Cc: Vitaly Andrianov 
> > > > > > >> >> > >> >> Cc: Stefano Babic 
> > > > > > >> >> > >> >> Cc: Peter Howard 
> > > > > > >> >> > >> >> Cc: Tom Rini 
> > > > > > >> >> > >> >> Signed-off-by: Jagan Teki 
> > > > > > >> >> > >> >> ---
> > > > > > >> >> > >> >>  drivers/spi/Kconfig|  12 +-
> > > > > > >> >> > >> >>  drivers/spi/davinci_spi.c  | 289 
> > > > > > >> >> > >> >> +++--
> > > > > > >> >> > >> >>  include/dm/platform_data/spi_davinci.h |  15 ++
> > > > > > >> >> > >> >>  3 files changed, 97 insertions(+), 219 deletions(-)
> > > > > > >> >> > >> >>  create mode 100644 
> > > > > > >> >> > >> >> include/dm/platform_data/spi_davinci.h
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > > > > > >> >> > >> >> index d046e919b4..18ebff0231 100644
> > > > > > >> >> > >> >> --- a/drivers/spi/Kconfig
> > > > > > >> >> > >> >> +++ b/drivers/spi/Kconfig
> > > > > > >> >> > >> >> @@ -80,6 +80,12 @@ config CADENCE_QSPI
> > > > > > >> >> > >> >>   used to access the SPI NOR flash on 
> > > > > > >> >> > >> >> platforms embedding this
> > > > > > >> >> > >> >>   Cadence IP core.
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >> +config DAVINCI_SPI
> > > > > > >> >> > >> >> +   bool "Davinci & Keystone SPI driver"
> > > > > > >> >> > >> >> +   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> > > > > > >> >> > >> >> +   help
> > > > > > >> >> > >> >> + Enable the Davinci SPI driver
> > > > > > >> >> > >> >> +
> > > > > > >> >> > >> >>  config DESIGNWARE_SPI
> > > > > > >> >> > >> >> bool "Designware SPI driver"
> > > > > > >> >> > >> >> help
> > > > > > >> >> > >> >> @@ -281,12 +287,6 @@ config FSL_QSPI
> > > > > > >> >> > >> >>   used to access the SPI NOR flash on 
> > > > > > >> >> > >> >> platforms embedding this
> > > > > > >> >> > >> >>   Freescale IP core.
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >> -config DAVINCI_SPI
> > > > > > >> >> > >> >> -   bool "Davinci & Keystone SPI driver"
> > > > > > >> >> > >> >> -   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> > > > > > >> >> > >> >> -   help
> > > > > > >> >> > >> >> - Enable the Davinci SPI driver
> > > > > > >> >> > >> >> -
> > > > > > >> >> > >> >>  config SH_SPI
> > > > > > >> >> > >> >> bool "SuperH SPI driver"
> > > > > > >> >> > >> >> help
> > > > > > >> >> > >> >> diff --git a/drivers/spi/davinci_spi.c 
> > > > > > >> >> > >> >> b/drivers/spi/davinci_spi.c
> > > > > > >> >> > >> >> index a822858323..5007e6c618 100644
> > > > > > >> >> > >> >> --- a/drivers/spi/davinci_spi.c
> > > > > > >> >> > >> >> +++ b/drivers/spi/davinci_spi.c
> > > > > > >> >> > >> >> @@ -14,6 +14,7 @@
> > > > > > >> >> > >> >>  #include 
> > > > > > >> >> > >> >>  #include 
> > > > > > >> >> > >> >>  #include 
> > > > > > >> >> > >> >> +#include 
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >>  /* SPIGCR0 */
> > > > > > >> >> > >> >>  #define SPIGCR0_SPIENA_MASK0x1
> > > > > > >> >> > >> >> @@ -118,9 +119,6 @@ struct davinci_spi_regs {
> > > > > > >> >> > >> >>
> > > > > > >> >> > >> >>  /* davinci spi slave */
> > > > > > >> >> > >> >>  struct davinci_spi_slave {
> > > > > > >> >> > >> >> -#ifndef CONFIG_DM_SPI
> > > > > > >> >> > >> >> -   struct spi_slave slave;
> > > > > > >> >> > >> >> -#end

Re: [U-Boot] [PATCH] [RFC] blk: Increase cache element size

On Wed, Aug 15, 2018 at 06:20:16PM +0200, Marek Vasut wrote:
> On 08/15/2018 06:12 PM, Tom Rini wrote:
> > On Wed, Aug 15, 2018 at 06:04:50PM +0200, Marek Vasut wrote:
> > 
> >> On 08/15/2018 04:30 PM, Tom Rini wrote:
> >>> On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
> >>>
>  Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
>  the underlying block layer devices usually report support for 512B . In
>  most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
>  etc.) and the real block size of those devices is much bigger.
> 
>  To avoid performance degradation with such devices and FS setup, bump
>  the maximum cache entry size to 4 kiB.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Tom Rini 
>  Cc: Simon Glass 
> >>>
> >>> Reviewed-by: Tom Rini 
> >>>
> >>> I'll pick this up post v2018.09 if no one objects, thanks!
> >>
> >> I object. I was hoping there'd be some discussion on how to solve this
> >> in a future-proof manner ... it's only a matter of time until someone
> >> uses ext4 with 8k blocks on an SSD ...
> > 
> > In general, sure?  In specific, mkfs.ext4 1.42.13 man page says 1/2/4KiB
> > are the only valid values of block size, and based on having to whack
> > this for some other projects it's pretty common for OpenEmbedded at
> > least to spit out 1KiB block size images.
> 
> OE spits 4k , that's how I triggered it,
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext2 ?= "-i 4096"
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext3 ?= "-i 4096"
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext4 ?= "-i 4096"

That's bytes-per-inode, I was referring to block size which is -b and
dynamic unless specified.

> > So unless you know of cases
> > today (or tomorrow, but not next year) where 8KiB is common or likely,
> > we should probably just bump this for now and maybe make it a tunable so
> > it's easily changed?
> 
> It is already tunable, see blkcache config in blkcache command.
> 
> But what I'd like to see is somehow the FS and the underlying storage
> negotiating the best settings. Can we get the FS block size from the
> block cache perspective ?

Good questions that I don't have an answer to.

-- 
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] [RFC] blk: Increase cache element size

On 08/15/2018 06:12 PM, Tom Rini wrote:
> On Wed, Aug 15, 2018 at 06:04:50PM +0200, Marek Vasut wrote:
> 
>> On 08/15/2018 04:30 PM, Tom Rini wrote:
>>> On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
>>>
 Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
 the underlying block layer devices usually report support for 512B . In
 most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
 etc.) and the real block size of those devices is much bigger.

 To avoid performance degradation with such devices and FS setup, bump
 the maximum cache entry size to 4 kiB.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
>>>
>>> Reviewed-by: Tom Rini 
>>>
>>> I'll pick this up post v2018.09 if no one objects, thanks!
>>
>> I object. I was hoping there'd be some discussion on how to solve this
>> in a future-proof manner ... it's only a matter of time until someone
>> uses ext4 with 8k blocks on an SSD ...
> 
> In general, sure?  In specific, mkfs.ext4 1.42.13 man page says 1/2/4KiB
> are the only valid values of block size, and based on having to whack
> this for some other projects it's pretty common for OpenEmbedded at
> least to spit out 1KiB block size images.

OE spits 4k , that's how I triggered it,
meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext2 ?= "-i 4096"
meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext3 ?= "-i 4096"
meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext4 ?= "-i 4096"

> So unless you know of cases
> today (or tomorrow, but not next year) where 8KiB is common or likely,
> we should probably just bump this for now and maybe make it a tunable so
> it's easily changed?

It is already tunable, see blkcache config in blkcache command.

But what I'd like to see is somehow the FS and the underlying storage
negotiating the best settings. Can we get the FS block size from the
block cache perspective ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: davinci: Full dm conversion

On Wed, Aug 15, 2018 at 11:07 AM Jagan Teki  wrote:
>
> On Wed, Aug 15, 2018 at 6:50 PM, Adam Ford  wrote:
> > On Mon, Aug 13, 2018 at 6:50 PM Adam Ford  wrote:
> >>
> >> On Mon, Aug 13, 2018 at 5:09 PM Adam Ford  wrote:
> >> >
> >> > On Mon, Aug 13, 2018 at 1:29 PM Simon Goldschmidt
> >> >  wrote:
> >> > >
> >> > > On Mon, Aug 13, 2018 at 3:46 PM Alex Kiernan  
> >> > > wrote:
> >> > > >
> >> > > > On Mon, Aug 13, 2018 at 1:40 PM Adam Ford  wrote:
> >> > > > >
> >> > > > > On Sat, Aug 11, 2018 at 3:09 PM Adam Ford  
> >> > > > > wrote:
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Sat, Aug 11, 2018, 1:24 PM Jagan Teki 
> >> > > > > >  wrote:
> >> > > > > >>
> >> > > > > >> On Sat, Aug 11, 2018 at 6:12 PM, Adam Ford  
> >> > > > > >> wrote:
> >> > > > > >> > On Fri, Aug 10, 2018 at 2:58 PM Adam Ford 
> >> > > > > >> >  wrote:
> >> > > > > >> >>
> >> > > > > >> >> On Fri, Aug 10, 2018 at 7:42 AM Jagan Teki 
> >> > > > > >> >>  wrote:
> >> > > > > >> >> >
> >> > > > > >> >> > On Fri, Aug 10, 2018 at 3:50 PM, Adam Ford 
> >> > > > > >> >> >  wrote:
> >> > > > > >> >> > > On Fri, Aug 10, 2018 at 12:14 AM Jagan Teki 
> >> > > > > >> >> > >  wrote:
> >> > > > > >> >> > >>
> >> > > > > >> >> > >> On Wed, Aug 8, 2018 at 6:47 PM, Adam Ford 
> >> > > > > >> >> > >>  wrote:
> >> > > > > >> >> > >> > On Tue, Aug 7, 2018 at 1:29 AM Jagan Teki 
> >> > > > > >> >> > >> >  wrote:
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >> davinci_spi now support dt along with platform data,
> >> > > > > >> >> > >> >> respective boards need to switch into dm for the 
> >> > > > > >> >> > >> >> same.
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >> Cc: Adam Ford 
> >> > > > > >> >> > >> >> Cc: Vitaly Andrianov 
> >> > > > > >> >> > >> >> Cc: Stefano Babic 
> >> > > > > >> >> > >> >> Cc: Peter Howard 
> >> > > > > >> >> > >> >> Cc: Tom Rini 
> >> > > > > >> >> > >> >> Signed-off-by: Jagan Teki 
> >> > > > > >> >> > >> >> 
> >> > > > > >> >> > >> >> ---
> >> > > > > >> >> > >> >>  drivers/spi/Kconfig|  12 +-
> >> > > > > >> >> > >> >>  drivers/spi/davinci_spi.c  | 289 
> >> > > > > >> >> > >> >> +++--
> >> > > > > >> >> > >> >>  include/dm/platform_data/spi_davinci.h |  15 ++
> >> > > > > >> >> > >> >>  3 files changed, 97 insertions(+), 219 deletions(-)
> >> > > > > >> >> > >> >>  create mode 100644 
> >> > > > > >> >> > >> >> include/dm/platform_data/spi_davinci.h
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >> diff --git a/drivers/spi/Kconfig 
> >> > > > > >> >> > >> >> b/drivers/spi/Kconfig
> >> > > > > >> >> > >> >> index d046e919b4..18ebff0231 100644
> >> > > > > >> >> > >> >> --- a/drivers/spi/Kconfig
> >> > > > > >> >> > >> >> +++ b/drivers/spi/Kconfig
> >> > > > > >> >> > >> >> @@ -80,6 +80,12 @@ config CADENCE_QSPI
> >> > > > > >> >> > >> >>   used to access the SPI NOR flash on 
> >> > > > > >> >> > >> >> platforms embedding this
> >> > > > > >> >> > >> >>   Cadence IP core.
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >> +config DAVINCI_SPI
> >> > > > > >> >> > >> >> +   bool "Davinci & Keystone SPI driver"
> >> > > > > >> >> > >> >> +   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> >> > > > > >> >> > >> >> +   help
> >> > > > > >> >> > >> >> + Enable the Davinci SPI driver
> >> > > > > >> >> > >> >> +
> >> > > > > >> >> > >> >>  config DESIGNWARE_SPI
> >> > > > > >> >> > >> >> bool "Designware SPI driver"
> >> > > > > >> >> > >> >> help
> >> > > > > >> >> > >> >> @@ -281,12 +287,6 @@ config FSL_QSPI
> >> > > > > >> >> > >> >>   used to access the SPI NOR flash on 
> >> > > > > >> >> > >> >> platforms embedding this
> >> > > > > >> >> > >> >>   Freescale IP core.
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >> -config DAVINCI_SPI
> >> > > > > >> >> > >> >> -   bool "Davinci & Keystone SPI driver"
> >> > > > > >> >> > >> >> -   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> >> > > > > >> >> > >> >> -   help
> >> > > > > >> >> > >> >> - Enable the Davinci SPI driver
> >> > > > > >> >> > >> >> -
> >> > > > > >> >> > >> >>  config SH_SPI
> >> > > > > >> >> > >> >> bool "SuperH SPI driver"
> >> > > > > >> >> > >> >> help
> >> > > > > >> >> > >> >> diff --git a/drivers/spi/davinci_spi.c 
> >> > > > > >> >> > >> >> b/drivers/spi/davinci_spi.c
> >> > > > > >> >> > >> >> index a822858323..5007e6c618 100644
> >> > > > > >> >> > >> >> --- a/drivers/spi/davinci_spi.c
> >> > > > > >> >> > >> >> +++ b/drivers/spi/davinci_spi.c
> >> > > > > >> >> > >> >> @@ -14,6 +14,7 @@
> >> > > > > >> >> > >> >>  #include 
> >> > > > > >> >> > >> >>  #include 
> >> > > > > >> >> > >> >>  #include 
> >> > > > > >> >> > >> >> +#include 
> >> > > > > >> >> > >> >>
> >> > > > > >> >> > >> >>  /* SPIGCR0 */
> >> > > > > >> >> > >> >>  #define SPIGCR0_SPIENA_MASK0x1
> >> > > > > >> >> > >> >> @@ -118,9 +119,6 @@ struct davinci_spi_regs {
> >> > > > > >> >> > >> >>

Re: [U-Boot] [PATCH] [RFC] blk: Increase cache element size

On Wed, Aug 15, 2018 at 06:04:50PM +0200, Marek Vasut wrote:

> On 08/15/2018 04:30 PM, Tom Rini wrote:
> > On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
> > 
> >> Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
> >> the underlying block layer devices usually report support for 512B . In
> >> most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
> >> etc.) and the real block size of those devices is much bigger.
> >>
> >> To avoid performance degradation with such devices and FS setup, bump
> >> the maximum cache entry size to 4 kiB.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Tom Rini 
> >> Cc: Simon Glass 
> > 
> > Reviewed-by: Tom Rini 
> > 
> > I'll pick this up post v2018.09 if no one objects, thanks!
> 
> I object. I was hoping there'd be some discussion on how to solve this
> in a future-proof manner ... it's only a matter of time until someone
> uses ext4 with 8k blocks on an SSD ...

In general, sure?  In specific, mkfs.ext4 1.42.13 man page says 1/2/4KiB
are the only valid values of block size, and based on having to whack
this for some other projects it's pretty common for OpenEmbedded at
least to spit out 1KiB block size images.  So unless you know of cases
today (or tomorrow, but not next year) where 8KiB is common or likely,
we should probably just bump this for now and maybe make it a tunable so
it's easily changed?

-- 
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] spi: davinci: Full dm conversion

2018-08-15 Thread Jagan Teki

On Wed, Aug 15, 2018 at 6:50 PM, Adam Ford  wrote:
> On Mon, Aug 13, 2018 at 6:50 PM Adam Ford  wrote:
>>
>> On Mon, Aug 13, 2018 at 5:09 PM Adam Ford  wrote:
>> >
>> > On Mon, Aug 13, 2018 at 1:29 PM Simon Goldschmidt
>> >  wrote:
>> > >
>> > > On Mon, Aug 13, 2018 at 3:46 PM Alex Kiernan  
>> > > wrote:
>> > > >
>> > > > On Mon, Aug 13, 2018 at 1:40 PM Adam Ford  wrote:
>> > > > >
>> > > > > On Sat, Aug 11, 2018 at 3:09 PM Adam Ford  wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Sat, Aug 11, 2018, 1:24 PM Jagan Teki 
>> > > > > >  wrote:
>> > > > > >>
>> > > > > >> On Sat, Aug 11, 2018 at 6:12 PM, Adam Ford  
>> > > > > >> wrote:
>> > > > > >> > On Fri, Aug 10, 2018 at 2:58 PM Adam Ford  
>> > > > > >> > wrote:
>> > > > > >> >>
>> > > > > >> >> On Fri, Aug 10, 2018 at 7:42 AM Jagan Teki 
>> > > > > >> >>  wrote:
>> > > > > >> >> >
>> > > > > >> >> > On Fri, Aug 10, 2018 at 3:50 PM, Adam Ford 
>> > > > > >> >> >  wrote:
>> > > > > >> >> > > On Fri, Aug 10, 2018 at 12:14 AM Jagan Teki 
>> > > > > >> >> > >  wrote:
>> > > > > >> >> > >>
>> > > > > >> >> > >> On Wed, Aug 8, 2018 at 6:47 PM, Adam Ford 
>> > > > > >> >> > >>  wrote:
>> > > > > >> >> > >> > On Tue, Aug 7, 2018 at 1:29 AM Jagan Teki 
>> > > > > >> >> > >> >  wrote:
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >> davinci_spi now support dt along with platform data,
>> > > > > >> >> > >> >> respective boards need to switch into dm for the same.
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >> Cc: Adam Ford 
>> > > > > >> >> > >> >> Cc: Vitaly Andrianov 
>> > > > > >> >> > >> >> Cc: Stefano Babic 
>> > > > > >> >> > >> >> Cc: Peter Howard 
>> > > > > >> >> > >> >> Cc: Tom Rini 
>> > > > > >> >> > >> >> Signed-off-by: Jagan Teki 
>> > > > > >> >> > >> >> ---
>> > > > > >> >> > >> >>  drivers/spi/Kconfig|  12 +-
>> > > > > >> >> > >> >>  drivers/spi/davinci_spi.c  | 289 
>> > > > > >> >> > >> >> +++--
>> > > > > >> >> > >> >>  include/dm/platform_data/spi_davinci.h |  15 ++
>> > > > > >> >> > >> >>  3 files changed, 97 insertions(+), 219 deletions(-)
>> > > > > >> >> > >> >>  create mode 100644 
>> > > > > >> >> > >> >> include/dm/platform_data/spi_davinci.h
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> > > > > >> >> > >> >> index d046e919b4..18ebff0231 100644
>> > > > > >> >> > >> >> --- a/drivers/spi/Kconfig
>> > > > > >> >> > >> >> +++ b/drivers/spi/Kconfig
>> > > > > >> >> > >> >> @@ -80,6 +80,12 @@ config CADENCE_QSPI
>> > > > > >> >> > >> >>   used to access the SPI NOR flash on 
>> > > > > >> >> > >> >> platforms embedding this
>> > > > > >> >> > >> >>   Cadence IP core.
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >> +config DAVINCI_SPI
>> > > > > >> >> > >> >> +   bool "Davinci & Keystone SPI driver"
>> > > > > >> >> > >> >> +   depends on ARCH_DAVINCI || ARCH_KEYSTONE
>> > > > > >> >> > >> >> +   help
>> > > > > >> >> > >> >> + Enable the Davinci SPI driver
>> > > > > >> >> > >> >> +
>> > > > > >> >> > >> >>  config DESIGNWARE_SPI
>> > > > > >> >> > >> >> bool "Designware SPI driver"
>> > > > > >> >> > >> >> help
>> > > > > >> >> > >> >> @@ -281,12 +287,6 @@ config FSL_QSPI
>> > > > > >> >> > >> >>   used to access the SPI NOR flash on 
>> > > > > >> >> > >> >> platforms embedding this
>> > > > > >> >> > >> >>   Freescale IP core.
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >> -config DAVINCI_SPI
>> > > > > >> >> > >> >> -   bool "Davinci & Keystone SPI driver"
>> > > > > >> >> > >> >> -   depends on ARCH_DAVINCI || ARCH_KEYSTONE
>> > > > > >> >> > >> >> -   help
>> > > > > >> >> > >> >> - Enable the Davinci SPI driver
>> > > > > >> >> > >> >> -
>> > > > > >> >> > >> >>  config SH_SPI
>> > > > > >> >> > >> >> bool "SuperH SPI driver"
>> > > > > >> >> > >> >> help
>> > > > > >> >> > >> >> diff --git a/drivers/spi/davinci_spi.c 
>> > > > > >> >> > >> >> b/drivers/spi/davinci_spi.c
>> > > > > >> >> > >> >> index a822858323..5007e6c618 100644
>> > > > > >> >> > >> >> --- a/drivers/spi/davinci_spi.c
>> > > > > >> >> > >> >> +++ b/drivers/spi/davinci_spi.c
>> > > > > >> >> > >> >> @@ -14,6 +14,7 @@
>> > > > > >> >> > >> >>  #include 
>> > > > > >> >> > >> >>  #include 
>> > > > > >> >> > >> >>  #include 
>> > > > > >> >> > >> >> +#include 
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >>  /* SPIGCR0 */
>> > > > > >> >> > >> >>  #define SPIGCR0_SPIENA_MASK0x1
>> > > > > >> >> > >> >> @@ -118,9 +119,6 @@ struct davinci_spi_regs {
>> > > > > >> >> > >> >>
>> > > > > >> >> > >> >>  /* davinci spi slave */
>> > > > > >> >> > >> >>  struct davinci_spi_slave {
>> > > > > >> >> > >> >> -#ifndef CONFIG_DM_SPI
>> > > > > >> >> > >> >> -   struct spi_slave slave;
>> > > > > >> >> > >> >> -#endif
>> > > > > >> >> > >> >> struct davinci_spi_regs *regs;
>> > > > > >> >> > >> >> unsigned int freq; /

Re: [U-Boot] [PATCH] [RFC] blk: Increase cache element size

On 08/15/2018 04:30 PM, Tom Rini wrote:
> On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
> 
>> Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
>> the underlying block layer devices usually report support for 512B . In
>> most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
>> etc.) and the real block size of those devices is much bigger.
>>
>> To avoid performance degradation with such devices and FS setup, bump
>> the maximum cache entry size to 4 kiB.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
> 
> Reviewed-by: Tom Rini 
> 
> I'll pick this up post v2018.09 if no one objects, thanks!

I object. I was hoping there'd be some discussion on how to solve this
in a future-proof manner ... it's only a matter of time until someone
uses ext4 with 8k blocks on an SSD ...

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] dm: fdt: scan for devices under /firmware too

On Wed, Aug 15, 2018 at 09:31:30AM -0600, Rob Herring wrote:
> On Wed, Aug 15, 2018 at 8:51 AM Michal Simek  wrote:
> >
> > Hi Rob,
> >
> > On 15.8.2018 16:34, Tom Rini wrote:
> > > On Wed, Aug 15, 2018 at 04:30:15PM +0200, Michal Simek wrote:
> > >> On 15.8.2018 16:17, Tom Rini wrote:
> > >>> On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
> > >>>
> >  Just as /chosen may contain devices /firmware may contain devices, scan
> >  for devices under /firmware too.
> > 
> >  Signed-off-by: Jens Wiklander 
> >  ---
> >   drivers/core/root.c | 15 ++-
> >   1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> >  diff --git a/drivers/core/root.c b/drivers/core/root.c
> >  index 72bcc7d7f2a3..0dca507e1187 100644
> >  --- a/drivers/core/root.c
> >  +++ b/drivers/core/root.c
> >  @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice 
> >  *parent, const void *blob,
> > for (offset = fdt_first_subnode(blob, offset);
> >  offset > 0;
> >  offset = fdt_next_subnode(blob, offset)) {
> >  -  /* "chosen" node isn't a device itself but may contain 
> >  some: */
> >  -  if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> >  -  pr_debug("parsing subnodes of \"chosen\"\n");
> >  +  const char *node_name = fdt_get_name(blob, offset, NULL);
> >  +
> >  +  /*
> >  +   * The "chosen" and "firmware" nodes aren't devices
> >  +   * themselves but may contain some:
> >  +   */
> >  +  if (!strcmp(node_name, "chosen") ||
> >  +  !strcmp(node_name, "firmware")) {
> >  +  pr_debug("parsing subnodes of \"%s\"\n", node_name);
> > 
> > err = dm_scan_fdt_node(parent, blob, offset,
> >    pre_reloc_only);
> > >>>
> > >>> So, the /firmware node seems special.  Have you talked with the
> > >>> devicetree folks to get it listed in the spec?  That would seem rather
> > >>> valuable for something used by many parties.  Thanks!
> > >>>
> > >>
> > >> some days ago we have sent a patch for this too.
> > >> https://lists.denx.de/pipermail/u-boot/2018-August/338049.html
> > >>
> > >> It is using different way but it should do the same thing.
> > >
> > > OK, so it sounds like in terms of code clean-ups, we need something like
> > > what you reference and then some further clean-ups on top of that
> > > perhaps for other places to call dm_scan_fdt_ofnode_path() for special
> > > cases.  And in terms of formalized specification bits, I do think
> > > /firmware should perhaps get kicked up to the spec itself so that it's
> > > very clear to all consumers.
> >
> > I was also checking latest devicetree spec and there is no record about
> > /firmware node and how it is supposed to be used.
> 
> Patches welcome. :)
> 
> It's really only a container to define non-discoverable firmware
> interfaces. Typically accessed thru a secure call (for ARM) or a
> mailbox. It is primarily just convention rather than a strict
> requirement. We have to support firmware nodes at the top-level too
> anyways.

Right.  To be clear, I'm suggesting that someone (I was thinking Jens)
pop over to the devicetree-spec list and ask about adding _something_
there as "firmware" isn't even on the list of generic names and may even
warrant something in section 3 under base device node types.

-- 
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 v4] spi: Add SPI driver for MT76xx SoCs



On 15.08.2018 17:19, Stefan Roese wrote:
> This patch adds the SPI driver for the MediaTek MT7688 SoC (and
> derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
> Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
> Gateway additionally with an SPI NAND on CS1.
> 
> Note that the SPI controller only supports a max transfer size of 32
> bytes. This driver implementes a workaround to enable bigger xfer
> sizes to speed up the transfer especially for the SPI NAND support.
> 
> Signed-off-by: Stefan Roese 
> Cc: Jagan Teki 
> Cc: Daniel Schwierzeck 
> Reviewed-by: Jagan Teki 
> ---
> v4:
> - Rename functions and macros from mt7621 to mt76xx to better
>   reflect the SoC usage and match the driver name
> 
> v3:
> - Drop IO wrappers completely as suggested by Daniel
> - Read "clock-frequency" DT property instead of using 
>   CONFIG_SYS_MIPS_TIMER_FREQ
> 
> v2:
> - Add some macros instead of hardcoded numbers
> - Move compatible DT struct down in the file 
> 
>  drivers/spi/Kconfig  |   8 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/mt76xx_spi.c | 312 +++
>  3 files changed, 321 insertions(+)
>  create mode 100644 drivers/spi/mt76xx_spi.c
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] dm: fdt: scan for devices under /firmware too

2018-08-15 Thread Rob Herring

On Wed, Aug 15, 2018 at 8:51 AM Michal Simek  wrote:
>
> Hi Rob,
>
> On 15.8.2018 16:34, Tom Rini wrote:
> > On Wed, Aug 15, 2018 at 04:30:15PM +0200, Michal Simek wrote:
> >> On 15.8.2018 16:17, Tom Rini wrote:
> >>> On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
> >>>
>  Just as /chosen may contain devices /firmware may contain devices, scan
>  for devices under /firmware too.
> 
>  Signed-off-by: Jens Wiklander 
>  ---
>   drivers/core/root.c | 15 ++-
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 
>  diff --git a/drivers/core/root.c b/drivers/core/root.c
>  index 72bcc7d7f2a3..0dca507e1187 100644
>  --- a/drivers/core/root.c
>  +++ b/drivers/core/root.c
>  @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
>  const void *blob,
> for (offset = fdt_first_subnode(blob, offset);
>  offset > 0;
>  offset = fdt_next_subnode(blob, offset)) {
>  -  /* "chosen" node isn't a device itself but may contain some: 
>  */
>  -  if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
>  -  pr_debug("parsing subnodes of \"chosen\"\n");
>  +  const char *node_name = fdt_get_name(blob, offset, NULL);
>  +
>  +  /*
>  +   * The "chosen" and "firmware" nodes aren't devices
>  +   * themselves but may contain some:
>  +   */
>  +  if (!strcmp(node_name, "chosen") ||
>  +  !strcmp(node_name, "firmware")) {
>  +  pr_debug("parsing subnodes of \"%s\"\n", node_name);
> 
> err = dm_scan_fdt_node(parent, blob, offset,
>    pre_reloc_only);
> >>>
> >>> So, the /firmware node seems special.  Have you talked with the
> >>> devicetree folks to get it listed in the spec?  That would seem rather
> >>> valuable for something used by many parties.  Thanks!
> >>>
> >>
> >> some days ago we have sent a patch for this too.
> >> https://lists.denx.de/pipermail/u-boot/2018-August/338049.html
> >>
> >> It is using different way but it should do the same thing.
> >
> > OK, so it sounds like in terms of code clean-ups, we need something like
> > what you reference and then some further clean-ups on top of that
> > perhaps for other places to call dm_scan_fdt_ofnode_path() for special
> > cases.  And in terms of formalized specification bits, I do think
> > /firmware should perhaps get kicked up to the spec itself so that it's
> > very clear to all consumers.
>
> I was also checking latest devicetree spec and there is no record about
> /firmware node and how it is supposed to be used.

Patches welcome. :)

It's really only a container to define non-discoverable firmware
interfaces. Typically accessed thru a secure call (for ARM) or a
mailbox. It is primarily just convention rather than a strict
requirement. We have to support firmware nodes at the top-level too
anyways.

Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4] spi: Add SPI driver for MT76xx SoCs

This patch adds the SPI driver for the MediaTek MT7688 SoC (and
derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
Gateway additionally with an SPI NAND on CS1.

Note that the SPI controller only supports a max transfer size of 32
bytes. This driver implementes a workaround to enable bigger xfer
sizes to speed up the transfer especially for the SPI NAND support.

Signed-off-by: Stefan Roese 
Cc: Jagan Teki 
Cc: Daniel Schwierzeck 
Reviewed-by: Jagan Teki 
---
v4:
- Rename functions and macros from mt7621 to mt76xx to better
  reflect the SoC usage and match the driver name

v3:
- Drop IO wrappers completely as suggested by Daniel
- Read "clock-frequency" DT property instead of using 
  CONFIG_SYS_MIPS_TIMER_FREQ

v2:
- Add some macros instead of hardcoded numbers
- Move compatible DT struct down in the file 

 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/mt76xx_spi.c | 312 +++
 3 files changed, 321 insertions(+)
 create mode 100644 drivers/spi/mt76xx_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9fbd26740d..6c4e50d3e9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -116,6 +116,14 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
 
+config MT76XX_SPI
+   bool "MediaTek MT76XX SPI driver"
+   depends on ARCH_MT7620
+   help
+ Enable the MT76XX SPI driver. This driver can be used to access
+ the SPI NOR flash on platforms embedding these MediaTek
+ SPI cores.
+
 config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
select CLK_ARMADA_3720
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bdb5b5a02f..3d13ba1b21 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
 obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
 obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
+obj-$(CONFIG_MT76XX_SPI) += mt76xx_spi.o
 obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
 obj-$(CONFIG_MXC_SPI) += mxc_spi.o
 obj-$(CONFIG_MXS_SPI) += mxs_spi.o
diff --git a/drivers/spi/mt76xx_spi.c b/drivers/spi/mt76xx_spi.c
new file mode 100644
index 00..71ded3fe71
--- /dev/null
+++ b/drivers/spi/mt76xx_spi.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * Derived from the Linux driver version drivers/spi/spi-mt7621.c
+ *   Copyright (C) 2011 Sergiy 
+ *   Copyright (C) 2011-2013 Gabor Juhos 
+ *   Copyright (C) 2014-2015 Felix Fietkau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPI_MSG_SIZE_MAX   32  /* SPI message chunk size */
+/* Enough for SPI NAND page read / write with page size 2048 bytes */
+#define SPI_MSG_SIZE_OVERALL   (2048 + 16)
+
+#define MT76XX_SPI_TRANS   0x00
+#define MT76XX_SPI_TRANS_START BIT(8)
+#define MT76XX_SPI_TRANS_BUSY  BIT(16)
+
+#define MT76XX_SPI_OPCODE  0x04
+#define MT76XX_SPI_DATA0   0x08
+#define MT76XX_SPI_DATA4   0x18
+#define MT76XX_SPI_MASTER  0x28
+#define MT76XX_SPI_MOREBUF 0x2c
+#define MT76XX_SPI_POLAR   0x38
+
+#define MT76XX_LSB_FIRST   BIT(3)
+#define MT76XX_CPOLBIT(4)
+#define MT76XX_CPHABIT(5)
+
+#define MASTER_MORE_BUFMODEBIT(2)
+#define MASTER_RS_CLK_SEL  GENMASK(27, 16)
+#define MASTER_RS_CLK_SEL_SHIFT16
+#define MASTER_RS_SLAVE_SELGENMASK(31, 29)
+
+struct mt76xx_spi {
+   void __iomem *base;
+   unsigned int sys_freq;
+   u32 data[(SPI_MSG_SIZE_OVERALL / 4) + 1];
+   int tx_len;
+};
+
+static void mt76xx_spi_reset(struct mt76xx_spi *rs, int duplex)
+{
+   setbits_le32(rs->base + MT76XX_SPI_MASTER,
+MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE);
+}
+
+static void mt76xx_spi_set_cs(struct mt76xx_spi *rs, int cs, int enable)
+{
+   u32 val = 0;
+
+   debug("%s: cs#%d -> %s\n", __func__, cs, enable ? "enable" : "disable");
+   if (enable)
+   val = BIT(cs);
+   iowrite32(val, rs->base + MT76XX_SPI_POLAR);
+}
+
+static int mt76xx_spi_set_mode(struct udevice *bus, uint mode)
+{
+   struct mt76xx_spi *rs = dev_get_priv(bus);
+   u32 reg;
+
+   debug("%s: mode=0x%08x\n", __func__, mode);
+   reg = ioread32(rs->base + MT76XX_SPI_MASTER);
+
+   reg &= ~MT76XX_LSB_FIRST;
+   if (mode & SPI_LSB_FIRST)
+   reg |= MT76XX_LSB_FIRST;
+
+   reg &= ~(MT76XX_CPHA | MT76XX_CPOL);
+   switch (mode & (SPI_CPOL | SPI_CPHA)) {
+   case SPI_MODE_0:
+   break;
+   case SPI_MODE_1:
+   reg |= MT76XX_CPHA;
+   break;
+   case SPI_MODE_2:
+   reg |= MT76XX_CPOL;
+   break;
+   case SPI_MODE_3:
+   reg |= MT76XX_CPOL | MT76XX_CPHA;
+

Re: [U-Boot] [PATCH v6 1/8] dm: mmc: use block layer in mmc driver

2018-08-15 Thread York Sun

First of all, your subject is wrong. You are not making any change to dm
or mmc.

On 08/13/2018 12:09 AM, Yinbo Zhu wrote:
> At present the MMC subsystem maintains its own list
> of MMC devices. This cannot work with driver model
> when CONFIG_BLK is enabled, use blk_dread to
> replace previous mmc read interface,
> use mmc_get_blk_desc to get the mmc device property
> 
> Signed-off-by: Yinbo Zhu 
> ---
> Change in v6:
>   remove block layer in mmc_legacy.
> 
>  arch/arm/cpu/armv8/fsl-layerscape/ppa.c |5 ++---

You didn't replace all. If you compiled all targets, you would see
errors on secure boot targets. Please fix and test _ALL_ targets before
sending another version.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] dm: fdt: scan for devices under /firmware too

2018-08-15 Thread Michal Simek

Hi Rob,

On 15.8.2018 16:34, Tom Rini wrote:
> On Wed, Aug 15, 2018 at 04:30:15PM +0200, Michal Simek wrote:
>> On 15.8.2018 16:17, Tom Rini wrote:
>>> On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
>>>
 Just as /chosen may contain devices /firmware may contain devices, scan
 for devices under /firmware too.

 Signed-off-by: Jens Wiklander 
 ---
  drivers/core/root.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

 diff --git a/drivers/core/root.c b/drivers/core/root.c
 index 72bcc7d7f2a3..0dca507e1187 100644
 --- a/drivers/core/root.c
 +++ b/drivers/core/root.c
 @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
 const void *blob,
for (offset = fdt_first_subnode(blob, offset);
 offset > 0;
 offset = fdt_next_subnode(blob, offset)) {
 -  /* "chosen" node isn't a device itself but may contain some: */
 -  if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
 -  pr_debug("parsing subnodes of \"chosen\"\n");
 +  const char *node_name = fdt_get_name(blob, offset, NULL);
 +
 +  /*
 +   * The "chosen" and "firmware" nodes aren't devices
 +   * themselves but may contain some:
 +   */
 +  if (!strcmp(node_name, "chosen") ||
 +  !strcmp(node_name, "firmware")) {
 +  pr_debug("parsing subnodes of \"%s\"\n", node_name);
  
err = dm_scan_fdt_node(parent, blob, offset,
   pre_reloc_only);
>>>
>>> So, the /firmware node seems special.  Have you talked with the
>>> devicetree folks to get it listed in the spec?  That would seem rather
>>> valuable for something used by many parties.  Thanks!
>>>
>>
>> some days ago we have sent a patch for this too.
>> https://lists.denx.de/pipermail/u-boot/2018-August/338049.html
>>
>> It is using different way but it should do the same thing.
> 
> OK, so it sounds like in terms of code clean-ups, we need something like
> what you reference and then some further clean-ups on top of that
> perhaps for other places to call dm_scan_fdt_ofnode_path() for special
> cases.  And in terms of formalized specification bits, I do think
> /firmware should perhaps get kicked up to the spec itself so that it's
> very clear to all consumers.

I was also checking latest devicetree spec and there is no record about
/firmware node and how it is supposed to be used.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

2018-08-15 Thread Alexander Graf

On 08/08/2018 04:24 AM, Henry Beberman wrote:

-Original Message-
From: Alexander Graf 
Sent: Tuesday, August 7, 2018 6:46 AM
To: Tom Rini 
Cc: Stefano Babic ; Henry Beberman
; u-boot@lists.denx.de; Fabio Estevam

Subject: Re: [PATCH 01/11] imx: Add bootcmd to load and run UEFI from
mmc

Am 07.08.2018 um 12:16 schrieb Tom Rini :

On Tue, Aug 07, 2018 at 01:11:11PM +0200, Stefano Babic wrote:
Hi Henry,

On 14/07/2018 02:11, Henry Beberman wrote:
From: Henry Beberman 

This patch enables i.MX platforms to easily add a boot script to
their U-Boot Proper environment to automatically load and execute an
EFI firmware from the first FAT partition of an MMC device.

This is a portion of enabling the Windows 10 IoT Core boot path.

The go command is overridden when CONFIG_UEFI_BOOT is specified.
This new go will perform a cache flush/disable, disable interrupts,
then jump to the address where UEFI was loaded.

This patch adds two new Kconfig options:
CONFIG_UEFI_BOOT: Selects the UEFI bootcmd and overrides go to

flush

caches and disable interrupts.
CONFIG_UEFI_LOAD_ADDR: Specifies the load address for the UEFI

image

Signed-off-by: Henry Beberman 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Tom Rini 
---
arch/arm/mach-imx/Makefile|  1 +
arch/arm/mach-imx/boot.c  | 19 +++
common/Kconfig| 17 +
include/config_uefi_bootcmd.h | 29

+

4 files changed, 66 insertions(+)
create mode 100644 arch/arm/mach-imx/boot.c create mode 100644
include/config_uefi_bootcmd.h

I am really missing why we need this specially for i.MX. There is
nothing special to i.MX, and if this command is necessary, we should
put it in common code.

Anyway, should we not try to merge it with the general support for
UEFI in U-Boot ? We have already a "bootefi" command (aarch64 and
x86, currently).

Agreed, this should be folded in with our existing UEFI support, thanks!

Yes, please just use distro boot. Bootefi (which distro boot calls) already
supports running UEFI binaries for real even on armv7.

Alex

Running Windows directly on U-Boot through bootefi is definitely appealing, but
we're dependent on a number of features provided by our full UEFI firmware.

* Several ACPI tables that are unimplemented in U-Boot: CSRT, DBG2, SPCR, TPM2, 
GTDT
* Some DSDT elements that require the Microsoft ASL compiler (for now)
* UEFI Authenticated Variables that are writeable at runtime.
* UEFI Secure Boot
* Launching and communicating with a Firmware TPM running as an OP-TEE Trusted 
Application

I'd be happy to break down this patch's changes into more generic steps rather 
than
creating confusion by adding CONFIG_UEFI_BOOT.

I can move the UEFI binary into our FIT to eliminate the custom binary load 
script.
How should I cleanly add an alternate CONFIG_BOOTCOMMAND to an existing board.h 
file?

I think ideally you just integrate into whatever distro boot supports. 
It already gives you plenty options such as extboot, boot.scr and real 
generic bootefi support. I'm sure your specially crafted FIT image can 
by loaded by at least one of the existing mechanisms.

Where is the best place to define an alternate do_go_exec that calls
cleanup_before_linux() before jumping?

Do you really really need that? The ARM calling convention for bootz is 
trivial and sounds like pretty much what you need already, no?

Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] spi: Add SPI driver for MT76xx SoCs

This patch adds the SPI driver for the MediaTek MT7688 SoC (and
derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
Gateway additionally with an SPI NAND on CS1.

Note that the SPI controller only supports a max transfer size of 32
bytes. This driver implementes a workaround to enable bigger xfer
sizes to speed up the transfer especially for the SPI NAND support.

Signed-off-by: Stefan Roese 
Cc: Jagan Teki 
Cc: Daniel Schwierzeck 
Reviewed-by: Jagan Teki 
---
v3:
- Drop IO wrappers completely as suggested by Daniel
- Read "clock-frequency" DT property instead of using 
  CONFIG_SYS_MIPS_TIMER_FREQ

v2:
- Add some macros instead of hardcoded numbers
- Move compatible DT struct down in the file 
  
 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/mt76xx_spi.c | 312 +++
 3 files changed, 321 insertions(+)
 create mode 100644 drivers/spi/mt76xx_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9fbd26740d..6c4e50d3e9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -116,6 +116,14 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
 
+config MT76XX_SPI
+   bool "MediaTek MT76XX SPI driver"
+   depends on ARCH_MT7620
+   help
+ Enable the MT76XX SPI driver. This driver can be used to access
+ the SPI NOR flash on platforms embedding these MediaTek
+ SPI cores.
+
 config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
select CLK_ARMADA_3720
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bdb5b5a02f..3d13ba1b21 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
 obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
 obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
+obj-$(CONFIG_MT76XX_SPI) += mt76xx_spi.o
 obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
 obj-$(CONFIG_MXC_SPI) += mxc_spi.o
 obj-$(CONFIG_MXS_SPI) += mxs_spi.o
diff --git a/drivers/spi/mt76xx_spi.c b/drivers/spi/mt76xx_spi.c
new file mode 100644
index 00..094a5756eb
--- /dev/null
+++ b/drivers/spi/mt76xx_spi.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * Derived from the Linux driver version drivers/spi/spi-mt7621.c
+ *   Copyright (C) 2011 Sergiy 
+ *   Copyright (C) 2011-2013 Gabor Juhos 
+ *   Copyright (C) 2014-2015 Felix Fietkau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPI_MSG_SIZE_MAX   32  /* SPI message chunk size */
+/* Enough for SPI NAND page read / write with page size 2048 bytes */
+#define SPI_MSG_SIZE_OVERALL   (2048 + 16)
+
+#define MT7621_SPI_TRANS   0x00
+#define MT7621_SPI_TRANS_START BIT(8)
+#define MT7621_SPI_TRANS_BUSY  BIT(16)
+
+#define MT7621_SPI_OPCODE  0x04
+#define MT7621_SPI_DATA0   0x08
+#define MT7621_SPI_DATA4   0x18
+#define MT7621_SPI_MASTER  0x28
+#define MT7621_SPI_MOREBUF 0x2c
+#define MT7621_SPI_POLAR   0x38
+
+#define MT7621_LSB_FIRST   BIT(3)
+#define MT7621_CPOLBIT(4)
+#define MT7621_CPHABIT(5)
+
+#define MASTER_MORE_BUFMODEBIT(2)
+#define MASTER_RS_CLK_SEL  GENMASK(27, 16)
+#define MASTER_RS_CLK_SEL_SHIFT16
+#define MASTER_RS_SLAVE_SELGENMASK(31, 29)
+
+struct mt7621_spi {
+   void __iomem *base;
+   unsigned int sys_freq;
+   u32 data[(SPI_MSG_SIZE_OVERALL / 4) + 1];
+   int tx_len;
+};
+
+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
+{
+   setbits_le32(rs->base + MT7621_SPI_MASTER,
+MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE);
+}
+
+static void mt7621_spi_set_cs(struct mt7621_spi *rs, int cs, int enable)
+{
+   u32 val = 0;
+
+   debug("%s: cs#%d -> %s\n", __func__, cs, enable ? "enable" : "disable");
+   if (enable)
+   val = BIT(cs);
+   iowrite32(val, rs->base + MT7621_SPI_POLAR);
+}
+
+static int mt7621_spi_set_mode(struct udevice *bus, uint mode)
+{
+   struct mt7621_spi *rs = dev_get_priv(bus);
+   u32 reg;
+
+   debug("%s: mode=0x%08x\n", __func__, mode);
+   reg = ioread32(rs->base + MT7621_SPI_MASTER);
+
+   reg &= ~MT7621_LSB_FIRST;
+   if (mode & SPI_LSB_FIRST)
+   reg |= MT7621_LSB_FIRST;
+
+   reg &= ~(MT7621_CPHA | MT7621_CPOL);
+   switch (mode & (SPI_CPOL | SPI_CPHA)) {
+   case SPI_MODE_0:
+   break;
+   case SPI_MODE_1:
+   reg |= MT7621_CPHA;
+   break;
+   case SPI_MODE_2:
+   reg |= MT7621_CPOL;
+   break;
+   case SPI_MODE_3:
+   reg |= MT7621_CPOL | MT7621_CPHA;
+   break;
+   }
+   iowrite32(reg, rs->base + MT7621_SPI_MASTER);
+
+   return 0;
+}
+
+static int mt7

Re: [U-Boot] [PATCH 4/5 v2] mips: Add Gardena Smart-Gateway board support


On 15.08.2018 16:36, Daniel Schwierzeck wrote:



On 10.08.2018 09:48, Stefan Roese wrote:

The Gardena Smart-Gateway boards have a MT7688 SoC with 128 MiB of RAM
and 8 MiB of flash (SPI NOR) and additional 128MiB SPI NAND storage.

This patch also includes 2 targets. One is the target that can be
programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
added to support loading and booting via an already running U-Boot
version. This allows easy development and testing without the
need to flash the image each time.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
v2:
- No change

  .../mips/dts/gardena-smart-gateway-mt7688.dts | 54 +++
  arch/mips/mach-mt7620/Kconfig |  9 +++
  board/gardena/smart-gateway-mt7688/Kconfig| 12 
  .../gardena/smart-gateway-mt7688/MAINTAINERS  |  8 +++
  board/gardena/smart-gateway-mt7688/Makefile   |  3 +
  board/gardena/smart-gateway-mt7688/board.c| 18 +
  ...gardena-smart-gateway-mt7688-ram_defconfig | 68 +++
  .../gardena-smart-gateway-mt7688_defconfig| 67 ++
  .../configs/gardena-smart-gateway-mt7688.h| 56 +++
  9 files changed, 295 insertions(+)
  create mode 100644 arch/mips/dts/gardena-smart-gateway-mt7688.dts
  create mode 100644 board/gardena/smart-gateway-mt7688/Kconfig
  create mode 100644 board/gardena/smart-gateway-mt7688/MAINTAINERS
  create mode 100644 board/gardena/smart-gateway-mt7688/Makefile
  create mode 100644 board/gardena/smart-gateway-mt7688/board.c
  create mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig
  create mode 100644 configs/gardena-smart-gateway-mt7688_defconfig
  create mode 100644 include/configs/gardena-smart-gateway-mt7688.h

diff --git a/arch/mips/dts/gardena-smart-gateway-mt7688.dts 
b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
new file mode 100644
index 00..6b2600a446
--- /dev/null
+++ b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "gardena,smart-gateway-mt7688", "ralink,mt7628a-soc";
+   model = "Gardena smart-Gateway-MT7688";
+
+   aliases {
+   serial0 = &uart0;
+   spi0 = &spi0;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   stdout-path = &uart0;
+   };
+};
+
+&uart0 {
+   status = "okay";
+   clock-frequency = <4000>;
+};
+
+&spi0 {
+   status = "okay";
+   num-cs = <2>;
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+
+   spi-nand@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-nand";
+   spi-max-frequency = <2500>;
+   reg = <1>;
+   };
+};
diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mt7620/Kconfig
index ef1211d172..13a7bd2cc0 100644
--- a/arch/mips/mach-mt7620/Kconfig
+++ b/arch/mips/mach-mt7620/Kconfig
@@ -21,6 +21,14 @@ endchoice
  choice
prompt "Board select"
  
+config BOARD_GARDENA_SMART_GATEWAY_MT7688

+   bool "Gardena Smart Gateway"
+   depends on SOC_MT7620
+   select SUPPORTS_BOOT_RAM
+   help
+ Gardena Smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
+ and 8 MiB of flash (SPI NOR) and additional SPI NAND storage.
+
  config BOARD_LINKIT_SMART_7688
bool "LinkIt Smart 7688"
depends on SOC_MT7620
@@ -121,6 +129,7 @@ endchoice
  config SUPPORTS_BOOT_RAM
bool
  
+source "board/gardena/smart-gateway-mt7688/Kconfig"

  source "board/seeed/linkit-smart-7688/Kconfig"
  
  endmenu

diff --git a/board/gardena/smart-gateway-mt7688/Kconfig 
b/board/gardena/smart-gateway-mt7688/Kconfig
new file mode 100644
index 00..3653f8aadb
--- /dev/null
+++ b/board/gardena/smart-gateway-mt7688/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_GARDENA_SMART_GATEWAY_MT7688
+
+config SYS_BOARD
+   default "smart-gateway-mt7688"
+
+config SYS_VENDOR
+   default "gardena"
+
+config SYS_CONFIG_NAME
+   default "gardena-smart-gateway-mt7688"
+
+endif
diff --git a/board/gardena/smart-gateway-mt7688/MAINTAINERS 
b/board/gardena/smart-gateway-mt7688/MAINTAINERS
new file mode 100644
index 00..bbb491c1ce
--- /dev/null
+++ b/board/gardena/smart-gateway-mt7688/MAINTAINERS
@@ -0,0 +1,8 @@
+GARDENA_SMART_GATEWAY_MT7688 BOARD
+M: Stefan Roese 
+S: Maintained
+F: board/gardena/smart-gateway-mt7688
+F: include/configs/gardena-smart-gateway-mt7688.h
+F: configs/gardena-smart-gateway-mt7688_defconfig
+F: configs/gardena-smart-gateway-mt

Re: [U-Boot] [PATCH 4/5 v2] mips: Add Gardena Smart-Gateway board support



On 10.08.2018 09:48, Stefan Roese wrote:
> The Gardena Smart-Gateway boards have a MT7688 SoC with 128 MiB of RAM
> and 8 MiB of flash (SPI NOR) and additional 128MiB SPI NAND storage.
> 
> This patch also includes 2 targets. One is the target that can be
> programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
> added to support loading and booting via an already running U-Boot
> version. This allows easy development and testing without the
> need to flash the image each time.
> 
> Signed-off-by: Stefan Roese 
> Cc: Daniel Schwierzeck 
> ---
> v2:
> - No change
> 
>  .../mips/dts/gardena-smart-gateway-mt7688.dts | 54 +++
>  arch/mips/mach-mt7620/Kconfig |  9 +++
>  board/gardena/smart-gateway-mt7688/Kconfig| 12 
>  .../gardena/smart-gateway-mt7688/MAINTAINERS  |  8 +++
>  board/gardena/smart-gateway-mt7688/Makefile   |  3 +
>  board/gardena/smart-gateway-mt7688/board.c| 18 +
>  ...gardena-smart-gateway-mt7688-ram_defconfig | 68 +++
>  .../gardena-smart-gateway-mt7688_defconfig| 67 ++
>  .../configs/gardena-smart-gateway-mt7688.h| 56 +++
>  9 files changed, 295 insertions(+)
>  create mode 100644 arch/mips/dts/gardena-smart-gateway-mt7688.dts
>  create mode 100644 board/gardena/smart-gateway-mt7688/Kconfig
>  create mode 100644 board/gardena/smart-gateway-mt7688/MAINTAINERS
>  create mode 100644 board/gardena/smart-gateway-mt7688/Makefile
>  create mode 100644 board/gardena/smart-gateway-mt7688/board.c
>  create mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig
>  create mode 100644 configs/gardena-smart-gateway-mt7688_defconfig
>  create mode 100644 include/configs/gardena-smart-gateway-mt7688.h
> 
> diff --git a/arch/mips/dts/gardena-smart-gateway-mt7688.dts 
> b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
> new file mode 100644
> index 00..6b2600a446
> --- /dev/null
> +++ b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
> @@ -0,0 +1,54 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Stefan Roese 
> + */
> +
> +/dts-v1/;
> +
> +#include "mt7628a.dtsi"
> +
> +/ {
> + compatible = "gardena,smart-gateway-mt7688", "ralink,mt7628a-soc";
> + model = "Gardena smart-Gateway-MT7688";
> +
> + aliases {
> + serial0 = &uart0;
> + spi0 = &spi0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0800>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + stdout-path = &uart0;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> + clock-frequency = <4000>;
> +};
> +
> +&spi0 {
> + status = "okay";
> + num-cs = <2>;
> +
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-flash", "jedec,spi-nor";
> + spi-max-frequency = <2500>;
> + reg = <0>;
> + };
> +
> + spi-nand@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-nand";
> + spi-max-frequency = <2500>;
> + reg = <1>;
> + };
> +};
> diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mt7620/Kconfig
> index ef1211d172..13a7bd2cc0 100644
> --- a/arch/mips/mach-mt7620/Kconfig
> +++ b/arch/mips/mach-mt7620/Kconfig
> @@ -21,6 +21,14 @@ endchoice
>  choice
>   prompt "Board select"
>  
> +config BOARD_GARDENA_SMART_GATEWAY_MT7688
> + bool "Gardena Smart Gateway"
> + depends on SOC_MT7620
> + select SUPPORTS_BOOT_RAM
> + help
> +   Gardena Smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
> +   and 8 MiB of flash (SPI NOR) and additional SPI NAND storage.
> +
>  config BOARD_LINKIT_SMART_7688
>   bool "LinkIt Smart 7688"
>   depends on SOC_MT7620
> @@ -121,6 +129,7 @@ endchoice
>  config SUPPORTS_BOOT_RAM
>   bool
>  
> +source "board/gardena/smart-gateway-mt7688/Kconfig"
>  source "board/seeed/linkit-smart-7688/Kconfig"
>  
>  endmenu
> diff --git a/board/gardena/smart-gateway-mt7688/Kconfig 
> b/board/gardena/smart-gateway-mt7688/Kconfig
> new file mode 100644
> index 00..3653f8aadb
> --- /dev/null
> +++ b/board/gardena/smart-gateway-mt7688/Kconfig
> @@ -0,0 +1,12 @@
> +if BOARD_GARDENA_SMART_GATEWAY_MT7688
> +
> +config SYS_BOARD
> + default "smart-gateway-mt7688"
> +
> +config SYS_VENDOR
> + default "gardena"
> +
> +config SYS_CONFIG_NAME
> + default "gardena-smart-gateway-mt7688"
> +
> +endif
> diff --git a/board/gardena/smart-gateway-mt7688/MAINTAINERS 
> b/board/gardena/smart-gateway-mt7688/MAINTAINERS
> new file mode 100644
> index 00..bbb491c1ce
> --- /dev/null
> +++ b/board/gardena/smart-gateway-mt7688/MAINTAINERS
> @@ -0,0 +1,8 @@
> +GARDENA_SMART_GATEWAY_MT7688 BOARD
> +M:   Stefan Roese 
> +S:   Maintained
> +F:   board/gardena/smart-gateway-mt7688
> +F:   include/confi

Re: [U-Boot] [PATCH 3/5 v2] mips: Add LinkIt Smart 7688 support


On 15.08.2018 16:30, Daniel Schwierzeck wrote:



On 10.08.2018 09:48, Stefan Roese wrote:

The LinkIt Smart 7688 modules have a MT7688 SoC with 128 MiB of RAM
and 32 MiB of flash (SPI NOR).

The mt7628a.dtsi file is imported from Linux v4.17.

This patch also includes 2 targets. One is the target that can be
programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
added to support loading and booting via an already running U-Boot
version. This allows easy development and testing without the
need to flash the image each time.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
v2:
- Kconfig entries added with this patch now

  arch/mips/dts/linkit-smart-7688.dts   |  46 
  arch/mips/dts/mt7628a.dtsi| 135 ++
  arch/mips/mach-mt7620/Kconfig |  13 +++
  board/seeed/linkit-smart-7688/Kconfig |  12 ++
  board/seeed/linkit-smart-7688/MAINTAINERS |   8 ++
  board/seeed/linkit-smart-7688/Makefile|   3 +
  board/seeed/linkit-smart-7688/board.c |  22 
  configs/linkit-smart-7688-ram_defconfig   |  58 ++
  configs/linkit-smart-7688_defconfig   |  62 ++
  include/configs/linkit-smart-7688.h   |  52 +
  10 files changed, 411 insertions(+)
  create mode 100644 arch/mips/dts/linkit-smart-7688.dts
  create mode 100644 arch/mips/dts/mt7628a.dtsi
  create mode 100644 board/seeed/linkit-smart-7688/Kconfig
  create mode 100644 board/seeed/linkit-smart-7688/MAINTAINERS
  create mode 100644 board/seeed/linkit-smart-7688/Makefile
  create mode 100644 board/seeed/linkit-smart-7688/board.c
  create mode 100644 configs/linkit-smart-7688-ram_defconfig
  create mode 100644 configs/linkit-smart-7688_defconfig
  create mode 100644 include/configs/linkit-smart-7688.h

diff --git a/arch/mips/dts/linkit-smart-7688.dts 
b/arch/mips/dts/linkit-smart-7688.dts
new file mode 100644
index 00..df4bf907c6
--- /dev/null
+++ b/arch/mips/dts/linkit-smart-7688.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "seeed,linkit-smart-7688", "ralink,mt7628a-soc";
+   model = "LinkIt-Smart-7688";
+
+   aliases {
+   serial0 = &uart2;
+   spi0 = &spi0;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   stdout-path = &uart2;
+   };
+};
+
+&uart2 {
+   status = "okay";
+   clock-frequency = <4000>;
+};
+
+&spi0 {
+   status = "okay";
+   num-cs = <2>;
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
new file mode 100644
index 00..d00f528e1f
--- /dev/null
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "ralink,mt7628a-soc";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "mti,mips24KEc";
+   device_type = "cpu";
+   reg = <0>;
+   };
+   };
+
+   resetc: reset-controller {
+   compatible = "ralink,rt2880-reset";
+   #reset-cells = <1>;
+   };
+
+   cpuintc: interrupt-controller {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "mti,cpu-interrupt-controller";
+   };
+
+   palmbus@1000 {
+   compatible = "palmbus", "simple-bus";
+   reg = <0x1000 0x20>;
+   ranges = <0x0 0x1000 0x1F>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   sysc: system-controller@0 {
+   compatible = "ralink,mt7620a-sysc", "syscon";
+   reg = <0x0 0x100>;
+   };
+
+   intc: interrupt-controller@200 {
+   compatible = "ralink,rt2880-intc";
+   reg = <0x200 0x100>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   resets = <&resetc 9>;
+   reset-names = "intc";
+
+   interrupt-parent = <&cpuintc>;
+   interrupts = <2>;
+
+   ralink,intc-registers = <0x9c 0xa0
+0x6c 0xa4
+0x80 0x78>;
+   };

Re: [U-Boot] [PATCH 01/10] dm: fdt: scan for devices under /firmware too

On Wed, Aug 15, 2018 at 04:30:15PM +0200, Michal Simek wrote:
> On 15.8.2018 16:17, Tom Rini wrote:
> > On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
> > 
> >> Just as /chosen may contain devices /firmware may contain devices, scan
> >> for devices under /firmware too.
> >>
> >> Signed-off-by: Jens Wiklander 
> >> ---
> >>  drivers/core/root.c | 15 ++-
> >>  1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/core/root.c b/drivers/core/root.c
> >> index 72bcc7d7f2a3..0dca507e1187 100644
> >> --- a/drivers/core/root.c
> >> +++ b/drivers/core/root.c
> >> @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
> >> const void *blob,
> >>for (offset = fdt_first_subnode(blob, offset);
> >> offset > 0;
> >> offset = fdt_next_subnode(blob, offset)) {
> >> -  /* "chosen" node isn't a device itself but may contain some: */
> >> -  if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> >> -  pr_debug("parsing subnodes of \"chosen\"\n");
> >> +  const char *node_name = fdt_get_name(blob, offset, NULL);
> >> +
> >> +  /*
> >> +   * The "chosen" and "firmware" nodes aren't devices
> >> +   * themselves but may contain some:
> >> +   */
> >> +  if (!strcmp(node_name, "chosen") ||
> >> +  !strcmp(node_name, "firmware")) {
> >> +  pr_debug("parsing subnodes of \"%s\"\n", node_name);
> >>  
> >>err = dm_scan_fdt_node(parent, blob, offset,
> >>   pre_reloc_only);
> > 
> > So, the /firmware node seems special.  Have you talked with the
> > devicetree folks to get it listed in the spec?  That would seem rather
> > valuable for something used by many parties.  Thanks!
> > 
> 
> some days ago we have sent a patch for this too.
> https://lists.denx.de/pipermail/u-boot/2018-August/338049.html
> 
> It is using different way but it should do the same thing.

OK, so it sounds like in terms of code clean-ups, we need something like
what you reference and then some further clean-ups on top of that
perhaps for other places to call dm_scan_fdt_ofnode_path() for special
cases.  And in terms of formalized specification bits, I do think
/firmware should perhaps get kicked up to the spec itself so that it's
very clear to all consumers.

-- 
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 01/10] dm: fdt: scan for devices under /firmware too

2018-08-15 Thread Michal Simek

On 15.8.2018 16:17, Tom Rini wrote:
> On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
> 
>> Just as /chosen may contain devices /firmware may contain devices, scan
>> for devices under /firmware too.
>>
>> Signed-off-by: Jens Wiklander 
>> ---
>>  drivers/core/root.c | 15 ++-
>>  1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/core/root.c b/drivers/core/root.c
>> index 72bcc7d7f2a3..0dca507e1187 100644
>> --- a/drivers/core/root.c
>> +++ b/drivers/core/root.c
>> @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
>> const void *blob,
>>  for (offset = fdt_first_subnode(blob, offset);
>>   offset > 0;
>>   offset = fdt_next_subnode(blob, offset)) {
>> -/* "chosen" node isn't a device itself but may contain some: */
>> -if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
>> -pr_debug("parsing subnodes of \"chosen\"\n");
>> +const char *node_name = fdt_get_name(blob, offset, NULL);
>> +
>> +/*
>> + * The "chosen" and "firmware" nodes aren't devices
>> + * themselves but may contain some:
>> + */
>> +if (!strcmp(node_name, "chosen") ||
>> +!strcmp(node_name, "firmware")) {
>> +pr_debug("parsing subnodes of \"%s\"\n", node_name);
>>  
>>  err = dm_scan_fdt_node(parent, blob, offset,
>> pre_reloc_only);
> 
> So, the /firmware node seems special.  Have you talked with the
> devicetree folks to get it listed in the spec?  That would seem rather
> valuable for something used by many parties.  Thanks!
> 

some days ago we have sent a patch for this too.
https://lists.denx.de/pipermail/u-boot/2018-August/338049.html

It is using different way but it should do the same thing.

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5 v2] mips: Add LinkIt Smart 7688 support



On 10.08.2018 09:48, Stefan Roese wrote:
> The LinkIt Smart 7688 modules have a MT7688 SoC with 128 MiB of RAM
> and 32 MiB of flash (SPI NOR).
> 
> The mt7628a.dtsi file is imported from Linux v4.17.
> 
> This patch also includes 2 targets. One is the target that can be
> programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
> added to support loading and booting via an already running U-Boot
> version. This allows easy development and testing without the
> need to flash the image each time.
> 
> Signed-off-by: Stefan Roese 
> Cc: Daniel Schwierzeck 
> ---
> v2:
> - Kconfig entries added with this patch now
> 
>  arch/mips/dts/linkit-smart-7688.dts   |  46 
>  arch/mips/dts/mt7628a.dtsi| 135 ++
>  arch/mips/mach-mt7620/Kconfig |  13 +++
>  board/seeed/linkit-smart-7688/Kconfig |  12 ++
>  board/seeed/linkit-smart-7688/MAINTAINERS |   8 ++
>  board/seeed/linkit-smart-7688/Makefile|   3 +
>  board/seeed/linkit-smart-7688/board.c |  22 
>  configs/linkit-smart-7688-ram_defconfig   |  58 ++
>  configs/linkit-smart-7688_defconfig   |  62 ++
>  include/configs/linkit-smart-7688.h   |  52 +
>  10 files changed, 411 insertions(+)
>  create mode 100644 arch/mips/dts/linkit-smart-7688.dts
>  create mode 100644 arch/mips/dts/mt7628a.dtsi
>  create mode 100644 board/seeed/linkit-smart-7688/Kconfig
>  create mode 100644 board/seeed/linkit-smart-7688/MAINTAINERS
>  create mode 100644 board/seeed/linkit-smart-7688/Makefile
>  create mode 100644 board/seeed/linkit-smart-7688/board.c
>  create mode 100644 configs/linkit-smart-7688-ram_defconfig
>  create mode 100644 configs/linkit-smart-7688_defconfig
>  create mode 100644 include/configs/linkit-smart-7688.h
> 
> diff --git a/arch/mips/dts/linkit-smart-7688.dts 
> b/arch/mips/dts/linkit-smart-7688.dts
> new file mode 100644
> index 00..df4bf907c6
> --- /dev/null
> +++ b/arch/mips/dts/linkit-smart-7688.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Stefan Roese 
> + */
> +
> +/dts-v1/;
> +
> +#include "mt7628a.dtsi"
> +
> +/ {
> + compatible = "seeed,linkit-smart-7688", "ralink,mt7628a-soc";
> + model = "LinkIt-Smart-7688";
> +
> + aliases {
> + serial0 = &uart2;
> + spi0 = &spi0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0800>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + stdout-path = &uart2;
> + };
> +};
> +
> +&uart2 {
> + status = "okay";
> + clock-frequency = <4000>;
> +};
> +
> +&spi0 {
> + status = "okay";
> + num-cs = <2>;
> +
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-flash", "jedec,spi-nor";
> + spi-max-frequency = <2500>;
> + reg = <0>;
> + };
> +};
> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> new file mode 100644
> index 00..d00f528e1f
> --- /dev/null
> +++ b/arch/mips/dts/mt7628a.dtsi
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ralink,mt7628a-soc";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "mti,mips24KEc";
> + device_type = "cpu";
> + reg = <0>;
> + };
> + };
> +
> + resetc: reset-controller {
> + compatible = "ralink,rt2880-reset";
> + #reset-cells = <1>;
> + };
> +
> + cpuintc: interrupt-controller {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + palmbus@1000 {
> + compatible = "palmbus", "simple-bus";
> + reg = <0x1000 0x20>;
> + ranges = <0x0 0x1000 0x1F>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + sysc: system-controller@0 {
> + compatible = "ralink,mt7620a-sysc", "syscon";
> + reg = <0x0 0x100>;
> + };
> +
> + intc: interrupt-controller@200 {
> + compatible = "ralink,rt2880-intc";
> + reg = <0x200 0x100>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + resets = <&resetc 9>;
> + reset-names = "intc";
> +
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>;
> +
> + ralink,intc-registers = <0x9c 0xa0
> +

Re: [U-Boot] [PATCH] [RFC] blk: Increase cache element size

On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:

> Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
> the underlying block layer devices usually report support for 512B . In
> most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
> etc.) and the real block size of those devices is much bigger.
> 
> To avoid performance degradation with such devices and FS setup, bump
> the maximum cache entry size to 4 kiB.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 

Reviewed-by: Tom Rini 

I'll pick this up post v2018.09 if no one objects, 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] CONFIG_MIPS_BOOT_CMDLINE_LEGACY usage ?

On 15.08.2018 16:05, Daniel Schwierzeck wrote:

On 15.08.2018 15:13, Stefan Roese wrote:

Hi Daniel,

On 15.08.2018 15:01, Daniel Schwierzeck wrote:

On 15.08.2018 10:23, Stefan Roese wrote:

Hi Daniel,

I'm wondering about the CONFIG_MIPS_BOOT_CMDLINE_LEGACY Kconfig
option in MIPS. Why is this one called "legacy" and what should
be used instead to pass the U-Boot bootargs to the Linux kernel?

Thanks,
Stefan

This interface was initially added to U-Boot with MIPS support and is
copied from the MIPS Yamon bootloader. Dependent on the platform and the
used bootloader there are more different boot interfaces.

The modern way to boot a kernel on MIPS would be to add a DTB to the
kernel FIT image and let U-Boot pass it over to the kernel
(CONFIG_MIPS_BOOT_FDT). All bootargs would then be added automatically
to the /chosen/bootargs node. This interface is conformant with the MIPS
UHI boot protocol. The kernel supports this in a generic way. The PROM
code of a platform only needs to evaluate the fw_passed_dtb variable for
a DTB address. In your case the Ralink platform supports this.

But you still have the flexibility to use a DTB built-in or appended to
the kernel and pass the bootargs in the traditional way. The kernel has
various config options to select the source of bootargs.

I see. Thanks for the detailed answer. We'll move over to passing via
DT once this is ready in Linux. Until then, we will use this legacy
interface.

DT handover is already supported for Ralink/mMediatek platform, see [1]

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/ralink/of.c#n78

Right, thanks. I was more referring to the fact, that the current
Linux target we are using is not using an separate DT blob. Its no
big deal to add this though and we will do this soon.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2 1/3] pinctrl: bcm6838: add pinctrl support



On 13.08.2018 14:23, Philippe Reynes wrote:
> Add pinctrl support for broadcom bcm6838 SoC.
> 
> Signed-off-by: Philippe Reynes 
> ---
> Changelog:
> v2:
> - rename property pins-count to brcm,pins-count (feedback Daniel Schwierzeck)
> - rename property functions-count to brcm,functions-count (feedback Daniel 
> Schwierzeck)
> - clean dev_err message
> 
>  .../pinctrl/bcm6838-pinctrl.txt|  35 +
>  drivers/pinctrl/broadcom/Kconfig   |   8 +
>  drivers/pinctrl/broadcom/Makefile  |   1 +
>  drivers/pinctrl/broadcom/pinctrl-bcm6838.c | 161 
> +
>  4 files changed, 205 insertions(+)
>  create mode 100644 doc/device-tree-bindings/pinctrl/bcm6838-pinctrl.txt
>  create mode 100644 drivers/pinctrl/broadcom/pinctrl-bcm6838.c
> 

applied to u-boot-mips/next, thanks

-- 
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] dm: fdt: scan for devices under /firmware too

On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:

> Just as /chosen may contain devices /firmware may contain devices, scan
> for devices under /firmware too.
> 
> Signed-off-by: Jens Wiklander 
> ---
>  drivers/core/root.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index 72bcc7d7f2a3..0dca507e1187 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
> const void *blob,
>   for (offset = fdt_first_subnode(blob, offset);
>offset > 0;
>offset = fdt_next_subnode(blob, offset)) {
> - /* "chosen" node isn't a device itself but may contain some: */
> - if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> - pr_debug("parsing subnodes of \"chosen\"\n");
> + const char *node_name = fdt_get_name(blob, offset, NULL);
> +
> + /*
> +  * The "chosen" and "firmware" nodes aren't devices
> +  * themselves but may contain some:
> +  */
> + if (!strcmp(node_name, "chosen") ||
> + !strcmp(node_name, "firmware")) {
> + pr_debug("parsing subnodes of \"%s\"\n", node_name);
>  
>   err = dm_scan_fdt_node(parent, blob, offset,
>  pre_reloc_only);

So, the /firmware node seems special.  Have you talked with the
devicetree folks to get it listed in the spec?  That would seem rather
valuable for something used by many parties.  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] dm: core: fix devfdt_remap_addr_index()



On 14.08.2018 12:48, Cédric Le Goater wrote:
> commit 30a90f56c3a2 ("dm: core: add functions to get memory-mapped I/O
> addresses") introduced a devfdt_remap_addr_index() routine but it does
> not make use of the index parameter.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  drivers/core/fdtaddr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] CONFIG_MIPS_BOOT_CMDLINE_LEGACY usage ?



On 15.08.2018 15:13, Stefan Roese wrote:
> Hi Daniel,
> 
> On 15.08.2018 15:01, Daniel Schwierzeck wrote:
>> On 15.08.2018 10:23, Stefan Roese wrote:
>>> Hi Daniel,
>>>
>>> I'm wondering about the CONFIG_MIPS_BOOT_CMDLINE_LEGACY Kconfig
>>> option in MIPS. Why is this one called "legacy" and what should
>>> be used instead to pass the U-Boot bootargs to the Linux kernel?
>>>
>>> Thanks,
>>> Stefan
>>
>> This interface was initially added to U-Boot with MIPS support and is
>> copied from the MIPS Yamon bootloader. Dependent on the platform and the
>> used bootloader there are more different boot interfaces.
>>
>> The modern way to boot a kernel on MIPS would be to add a DTB to the
>> kernel FIT image and let U-Boot pass it over to the kernel
>> (CONFIG_MIPS_BOOT_FDT). All bootargs would then be added automatically
>> to the /chosen/bootargs node. This interface is conformant with the MIPS
>> UHI boot protocol. The kernel supports this in a generic way. The PROM
>> code of a platform only needs to evaluate the fw_passed_dtb variable for
>> a DTB address. In your case the Ralink platform supports this.
>>
>> But you still have the flexibility to use a DTB built-in or appended to
>> the kernel and pass the bootargs in the traditional way. The kernel has
>> various config options to select the source of bootargs.
> 
> I see. Thanks for the detailed answer. We'll move over to passing via
> DT once this is ready in Linux. Until then, we will use this legacy
> interface.
> 

DT handover is already supported for Ralink/mMediatek platform, see [1]

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/ralink/of.c#n78


-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: davinci: Full dm conversion

On Mon, Aug 13, 2018 at 6:50 PM Adam Ford  wrote:
>
> On Mon, Aug 13, 2018 at 5:09 PM Adam Ford  wrote:
> >
> > On Mon, Aug 13, 2018 at 1:29 PM Simon Goldschmidt
> >  wrote:
> > >
> > > On Mon, Aug 13, 2018 at 3:46 PM Alex Kiernan  
> > > wrote:
> > > >
> > > > On Mon, Aug 13, 2018 at 1:40 PM Adam Ford  wrote:
> > > > >
> > > > > On Sat, Aug 11, 2018 at 3:09 PM Adam Ford  wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Aug 11, 2018, 1:24 PM Jagan Teki 
> > > > > >  wrote:
> > > > > >>
> > > > > >> On Sat, Aug 11, 2018 at 6:12 PM, Adam Ford  
> > > > > >> wrote:
> > > > > >> > On Fri, Aug 10, 2018 at 2:58 PM Adam Ford  
> > > > > >> > wrote:
> > > > > >> >>
> > > > > >> >> On Fri, Aug 10, 2018 at 7:42 AM Jagan Teki 
> > > > > >> >>  wrote:
> > > > > >> >> >
> > > > > >> >> > On Fri, Aug 10, 2018 at 3:50 PM, Adam Ford 
> > > > > >> >> >  wrote:
> > > > > >> >> > > On Fri, Aug 10, 2018 at 12:14 AM Jagan Teki 
> > > > > >> >> > >  wrote:
> > > > > >> >> > >>
> > > > > >> >> > >> On Wed, Aug 8, 2018 at 6:47 PM, Adam Ford 
> > > > > >> >> > >>  wrote:
> > > > > >> >> > >> > On Tue, Aug 7, 2018 at 1:29 AM Jagan Teki 
> > > > > >> >> > >> >  wrote:
> > > > > >> >> > >> >>
> > > > > >> >> > >> >> davinci_spi now support dt along with platform data,
> > > > > >> >> > >> >> respective boards need to switch into dm for the same.
> > > > > >> >> > >> >>
> > > > > >> >> > >> >> Cc: Adam Ford 
> > > > > >> >> > >> >> Cc: Vitaly Andrianov 
> > > > > >> >> > >> >> Cc: Stefano Babic 
> > > > > >> >> > >> >> Cc: Peter Howard 
> > > > > >> >> > >> >> Cc: Tom Rini 
> > > > > >> >> > >> >> Signed-off-by: Jagan Teki 
> > > > > >> >> > >> >> ---
> > > > > >> >> > >> >>  drivers/spi/Kconfig|  12 +-
> > > > > >> >> > >> >>  drivers/spi/davinci_spi.c  | 289 
> > > > > >> >> > >> >> +++--
> > > > > >> >> > >> >>  include/dm/platform_data/spi_davinci.h |  15 ++
> > > > > >> >> > >> >>  3 files changed, 97 insertions(+), 219 deletions(-)
> > > > > >> >> > >> >>  create mode 100644 
> > > > > >> >> > >> >> include/dm/platform_data/spi_davinci.h
> > > > > >> >> > >> >>
> > > > > >> >> > >> >> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > > > > >> >> > >> >> index d046e919b4..18ebff0231 100644
> > > > > >> >> > >> >> --- a/drivers/spi/Kconfig
> > > > > >> >> > >> >> +++ b/drivers/spi/Kconfig
> > > > > >> >> > >> >> @@ -80,6 +80,12 @@ config CADENCE_QSPI
> > > > > >> >> > >> >>   used to access the SPI NOR flash on platforms 
> > > > > >> >> > >> >> embedding this
> > > > > >> >> > >> >>   Cadence IP core.
> > > > > >> >> > >> >>
> > > > > >> >> > >> >> +config DAVINCI_SPI
> > > > > >> >> > >> >> +   bool "Davinci & Keystone SPI driver"
> > > > > >> >> > >> >> +   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> > > > > >> >> > >> >> +   help
> > > > > >> >> > >> >> + Enable the Davinci SPI driver
> > > > > >> >> > >> >> +
> > > > > >> >> > >> >>  config DESIGNWARE_SPI
> > > > > >> >> > >> >> bool "Designware SPI driver"
> > > > > >> >> > >> >> help
> > > > > >> >> > >> >> @@ -281,12 +287,6 @@ config FSL_QSPI
> > > > > >> >> > >> >>   used to access the SPI NOR flash on platforms 
> > > > > >> >> > >> >> embedding this
> > > > > >> >> > >> >>   Freescale IP core.
> > > > > >> >> > >> >>
> > > > > >> >> > >> >> -config DAVINCI_SPI
> > > > > >> >> > >> >> -   bool "Davinci & Keystone SPI driver"
> > > > > >> >> > >> >> -   depends on ARCH_DAVINCI || ARCH_KEYSTONE
> > > > > >> >> > >> >> -   help
> > > > > >> >> > >> >> - Enable the Davinci SPI driver
> > > > > >> >> > >> >> -
> > > > > >> >> > >> >>  config SH_SPI
> > > > > >> >> > >> >> bool "SuperH SPI driver"
> > > > > >> >> > >> >> help
> > > > > >> >> > >> >> diff --git a/drivers/spi/davinci_spi.c 
> > > > > >> >> > >> >> b/drivers/spi/davinci_spi.c
> > > > > >> >> > >> >> index a822858323..5007e6c618 100644
> > > > > >> >> > >> >> --- a/drivers/spi/davinci_spi.c
> > > > > >> >> > >> >> +++ b/drivers/spi/davinci_spi.c
> > > > > >> >> > >> >> @@ -14,6 +14,7 @@
> > > > > >> >> > >> >>  #include 
> > > > > >> >> > >> >>  #include 
> > > > > >> >> > >> >>  #include 
> > > > > >> >> > >> >> +#include 
> > > > > >> >> > >> >>
> > > > > >> >> > >> >>  /* SPIGCR0 */
> > > > > >> >> > >> >>  #define SPIGCR0_SPIENA_MASK0x1
> > > > > >> >> > >> >> @@ -118,9 +119,6 @@ struct davinci_spi_regs {
> > > > > >> >> > >> >>
> > > > > >> >> > >> >>  /* davinci spi slave */
> > > > > >> >> > >> >>  struct davinci_spi_slave {
> > > > > >> >> > >> >> -#ifndef CONFIG_DM_SPI
> > > > > >> >> > >> >> -   struct spi_slave slave;
> > > > > >> >> > >> >> -#endif
> > > > > >> >> > >> >> struct davinci_spi_regs *regs;
> > > > > >> >> > >> >> unsigned int freq; /* current SPI bus frequency 
> > > > > >> >> > >> >> */
> > > > > >> >> > >> >> unsigned int mode; /* current SPI mode used */
> > > > > >> >> > >> >> @@

Re: [U-Boot] CONFIG_MIPS_BOOT_CMDLINE_LEGACY usage ?


Hi Daniel,

On 15.08.2018 15:01, Daniel Schwierzeck wrote:

On 15.08.2018 10:23, Stefan Roese wrote:

Hi Daniel,

I'm wondering about the CONFIG_MIPS_BOOT_CMDLINE_LEGACY Kconfig
option in MIPS. Why is this one called "legacy" and what should
be used instead to pass the U-Boot bootargs to the Linux kernel?

Thanks,
Stefan


This interface was initially added to U-Boot with MIPS support and is
copied from the MIPS Yamon bootloader. Dependent on the platform and the
used bootloader there are more different boot interfaces.

The modern way to boot a kernel on MIPS would be to add a DTB to the
kernel FIT image and let U-Boot pass it over to the kernel
(CONFIG_MIPS_BOOT_FDT). All bootargs would then be added automatically
to the /chosen/bootargs node. This interface is conformant with the MIPS
UHI boot protocol. The kernel supports this in a generic way. The PROM
code of a platform only needs to evaluate the fw_passed_dtb variable for
a DTB address. In your case the Ralink platform supports this.

But you still have the flexibility to use a DTB built-in or appended to
the kernel and pass the bootargs in the traditional way. The kernel has
various config options to select the source of bootargs.


I see. Thanks for the detailed answer. We'll move over to passing via
DT once this is ready in Linux. Until then, we will use this legacy
interface.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] CONFIG_MIPS_BOOT_CMDLINE_LEGACY usage ?

Hi Stefan,

On 15.08.2018 10:23, Stefan Roese wrote:
> Hi Daniel,
> 
> I'm wondering about the CONFIG_MIPS_BOOT_CMDLINE_LEGACY Kconfig
> option in MIPS. Why is this one called "legacy" and what should
> be used instead to pass the U-Boot bootargs to the Linux kernel?
> 
> Thanks,
> Stefan

This interface was initially added to U-Boot with MIPS support and is
copied from the MIPS Yamon bootloader. Dependent on the platform and the
used bootloader there are more different boot interfaces.

The modern way to boot a kernel on MIPS would be to add a DTB to the
kernel FIT image and let U-Boot pass it over to the kernel
(CONFIG_MIPS_BOOT_FDT). All bootargs would then be added automatically
to the /chosen/bootargs node. This interface is conformant with the MIPS
UHI boot protocol. The kernel supports this in a generic way. The PROM
code of a platform only needs to evaluate the fw_passed_dtb variable for
a DTB address. In your case the Ralink platform supports this.

But you still have the flexibility to use a DTB built-in or appended to
the kernel and pass the bootargs in the traditional way. The kernel has
various config options to select the source of bootargs.

-- 
- Daniel

signature.asc
Description: OpenPGP digital signature
___
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-v40: Add Bananapi M2 Berry support

2018-08-15 Thread Alan Beard

Hi Maxine and team,

I want to run Fedora linux, from here:
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/armhfp
/images/

on the Banana Pi BPI-M2 Berry. (works fine on a Banana Pi original)

I've waited six months for the patches to filter through to the Fedora team 
but, so far nothing.

I've downloaded the code from the denx.de website but I cannot see a way to
just generate the u-boot-sunxi-with-spl.bin file for the Berry.
There is a u-boot-sunxi-with-spl.bin file in the Fedora distribution for
the Berry but it doesn't work.
This also doesn't work:
https://github.com/BPI-SINOVOIP/BPI-Mainline-uboot.git
I suspect they check the chip-id and barf if it's not 0x1701 the R40.

I chose the Banana Pi BPI-M2 Berry over the Ultra because I didn't need
the extra ram or other bells and whistles. I want to embed a BPi Berry in
an amateur radio project where I need a board with a SATA port for an SSD.

Keep up the good work.

Alan

On Wed, 2 May 2018 11:16:30 +0200, 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 
> 
> for both patches, thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

Alan

Evil flourishes when good men do nothing.
Consider the Christmas child.
---
Alan Beard   Unix Support Technician from 1984 to today
70 Wedmore Rd.   Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS
Emu Heights N.S.W. 2750  Routers, terminal servers, printers, terminals etc..
+61 2 47353013 (h)   Support Programming, shell scripting, "C", assembler
0414 353013 (mobile) After uni, electronics tech

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spi: Add SPI driver for MT76xx SoCs


On 15.08.2018 14:02, Daniel Schwierzeck wrote:



On 15.08.2018 13:26, Stefan Roese wrote:

Hi Daniel,

On 11.08.2018 18:59, Daniel Schwierzeck wrote:

On 10.08.2018 08:56, Stefan Roese wrote:

This patch adds the SPI driver for the MediaTek MT7688 SoC (and
derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
Gateway additionally with an SPI NAND on CS1.

Note that the SPI controller only supports a max transfer size of 32
bytes. This driver implementes a workaround to enable bigger xfer
sizes to speed up the transfer especially for the SPI NAND support.

Signed-off-by: Stefan Roese 
Cc: Jagan Teki 
---
v2:
- Add some macros instead of hardcoded numbers
- Move compatible DT struct down in the file

   drivers/spi/Kconfig  |   8 +
   drivers/spi/Makefile |   1 +
   drivers/spi/mt76xx_spi.c | 319 +++
   3 files changed, 328 insertions(+)
   create mode 100644 drivers/spi/mt76xx_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9fbd26740d..6c4e50d3e9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -116,6 +116,14 @@ config ICH_SPI
     access the SPI NOR flash on platforms embedding this Intel
     ICH IP core.
   +config MT76XX_SPI
+    bool "MediaTek MT76XX SPI driver"
+    depends on ARCH_MT7620
+    help
+  Enable the MT76XX SPI driver. This driver can be used to access
+  the SPI NOR flash on platforms embedding these MediaTek
+  SPI cores.
+
   config MVEBU_A3700_SPI
   bool "Marvell Armada 3700 SPI driver"
   select CLK_ARMADA_3720
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bdb5b5a02f..3d13ba1b21 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
   obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
   obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
   obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
+obj-$(CONFIG_MT76XX_SPI) += mt76xx_spi.o
   obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
   obj-$(CONFIG_MXC_SPI) += mxc_spi.o
   obj-$(CONFIG_MXS_SPI) += mxs_spi.o
diff --git a/drivers/spi/mt76xx_spi.c b/drivers/spi/mt76xx_spi.c
new file mode 100644
index 00..f26b5341ce
--- /dev/null
+++ b/drivers/spi/mt76xx_spi.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * Derived from the Linux driver version drivers/spi/spi-mt7621.c
+ *   Copyright (C) 2011 Sergiy 
+ *   Copyright (C) 2011-2013 Gabor Juhos 
+ *   Copyright (C) 2014-2015 Felix Fietkau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPI_MSG_SIZE_MAX    32    /* SPI message chunk size */
+/* Enough for SPI NAND page read / write with page size 2048 bytes */
+#define SPI_MSG_SIZE_OVERALL    (2048 + 16)
+
+#define MT7621_SPI_TRANS    0x00
+#define MT7621_SPI_TRANS_START    BIT(8)
+#define MT7621_SPI_TRANS_BUSY    BIT(16)
+
+#define MT7621_SPI_OPCODE    0x04
+#define MT7621_SPI_DATA0    0x08
+#define MT7621_SPI_DATA4    0x18
+#define MT7621_SPI_MASTER    0x28
+#define MT7621_SPI_MOREBUF    0x2c
+#define MT7621_SPI_POLAR    0x38
+
+#define MT7621_LSB_FIRST    BIT(3)
+#define MT7621_CPOL    BIT(4)
+#define MT7621_CPHA    BIT(5)
+
+#define MASTER_MORE_BUFMODE    BIT(2)
+#define MASTER_RS_CLK_SEL    GENMASK(27, 16)
+#define MASTER_RS_CLK_SEL_SHIFT    16
+#define MASTER_RS_SLAVE_SEL    GENMASK(31, 29)
+
+struct mt7621_spi {
+    void __iomem *base;
+    unsigned int sys_freq;
+    u32 data[(SPI_MSG_SIZE_OVERALL / 4) + 1];
+    int tx_len;
+};
+
+static inline u32 mt7621_spi_read(struct mt7621_spi *rs, u32 reg)
+{
+    return ioread32(rs->base + reg);
+}
+
+static inline void mt7621_spi_write(struct mt7621_spi *rs, u32 reg,
u32 val)
+{
+    iowrite32(val, rs->base + reg);
+}
+
+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
+{
+    u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
+
+    master |= MASTER_RS_SLAVE_SEL;    /* CS control */
+    master |= MASTER_MORE_BUFMODE;    /* more_buf_mode */
+
+    mt7621_spi_write(rs, MT7621_SPI_MASTER, master);


if you omit the (actually unneeded) I/O wrappers, you could simplify
this with setbits_le32() (or setbits_32() for non-enforcing endianess)


Yes, you are correct. All this is derived / copied from the Linux
driver. Even though the main xfer routine is pretty much different,
so it makes not much sense any more to stick with this IO wrappers
for code compatibility.

I could work on a new version of this driver, omitting these IO
wrappers, if this is preferred. Or I could do this in a follow-up
patch, once this one is in mainline (time is a bit short right now).


follow-up patch would be ok, it was only meant as optional improvement.

But maybe the mt7621_ prefix could be replaced with mt76xx_ to be
consistent with the source file name?




+}
+
+static void mt7621_spi_set_cs(struct mt7621_spi *rs, int cs, int
enable)
+{
+    u32 val = 0;

Re: [U-Boot] [PATCH v2] spi: Add SPI driver for MT76xx SoCs



On 15.08.2018 13:26, Stefan Roese wrote:
> Hi Daniel,
> 
> On 11.08.2018 18:59, Daniel Schwierzeck wrote:
>> On 10.08.2018 08:56, Stefan Roese wrote:
>>> This patch adds the SPI driver for the MediaTek MT7688 SoC (and
>>> derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
>>> Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
>>> Gateway additionally with an SPI NAND on CS1.
>>>
>>> Note that the SPI controller only supports a max transfer size of 32
>>> bytes. This driver implementes a workaround to enable bigger xfer
>>> sizes to speed up the transfer especially for the SPI NAND support.
>>>
>>> Signed-off-by: Stefan Roese 
>>> Cc: Jagan Teki 
>>> ---
>>> v2:
>>> - Add some macros instead of hardcoded numbers
>>> - Move compatible DT struct down in the file
>>>
>>>   drivers/spi/Kconfig  |   8 +
>>>   drivers/spi/Makefile |   1 +
>>>   drivers/spi/mt76xx_spi.c | 319 +++
>>>   3 files changed, 328 insertions(+)
>>>   create mode 100644 drivers/spi/mt76xx_spi.c
>>>
>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>> index 9fbd26740d..6c4e50d3e9 100644
>>> --- a/drivers/spi/Kconfig
>>> +++ b/drivers/spi/Kconfig
>>> @@ -116,6 +116,14 @@ config ICH_SPI
>>>     access the SPI NOR flash on platforms embedding this Intel
>>>     ICH IP core.
>>>   +config MT76XX_SPI
>>> +    bool "MediaTek MT76XX SPI driver"
>>> +    depends on ARCH_MT7620
>>> +    help
>>> +  Enable the MT76XX SPI driver. This driver can be used to access
>>> +  the SPI NOR flash on platforms embedding these MediaTek
>>> +  SPI cores.
>>> +
>>>   config MVEBU_A3700_SPI
>>>   bool "Marvell Armada 3700 SPI driver"
>>>   select CLK_ARMADA_3720
>>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>>> index bdb5b5a02f..3d13ba1b21 100644
>>> --- a/drivers/spi/Makefile
>>> +++ b/drivers/spi/Makefile
>>> @@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>>>   obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
>>>   obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>>>   obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>>> +obj-$(CONFIG_MT76XX_SPI) += mt76xx_spi.o
>>>   obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
>>>   obj-$(CONFIG_MXC_SPI) += mxc_spi.o
>>>   obj-$(CONFIG_MXS_SPI) += mxs_spi.o
>>> diff --git a/drivers/spi/mt76xx_spi.c b/drivers/spi/mt76xx_spi.c
>>> new file mode 100644
>>> index 00..f26b5341ce
>>> --- /dev/null
>>> +++ b/drivers/spi/mt76xx_spi.c
>>> @@ -0,0 +1,319 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2018 Stefan Roese 
>>> + *
>>> + * Derived from the Linux driver version drivers/spi/spi-mt7621.c
>>> + *   Copyright (C) 2011 Sergiy 
>>> + *   Copyright (C) 2011-2013 Gabor Juhos 
>>> + *   Copyright (C) 2014-2015 Felix Fietkau 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define SPI_MSG_SIZE_MAX    32    /* SPI message chunk size */
>>> +/* Enough for SPI NAND page read / write with page size 2048 bytes */
>>> +#define SPI_MSG_SIZE_OVERALL    (2048 + 16)
>>> +
>>> +#define MT7621_SPI_TRANS    0x00
>>> +#define MT7621_SPI_TRANS_START    BIT(8)
>>> +#define MT7621_SPI_TRANS_BUSY    BIT(16)
>>> +
>>> +#define MT7621_SPI_OPCODE    0x04
>>> +#define MT7621_SPI_DATA0    0x08
>>> +#define MT7621_SPI_DATA4    0x18
>>> +#define MT7621_SPI_MASTER    0x28
>>> +#define MT7621_SPI_MOREBUF    0x2c
>>> +#define MT7621_SPI_POLAR    0x38
>>> +
>>> +#define MT7621_LSB_FIRST    BIT(3)
>>> +#define MT7621_CPOL    BIT(4)
>>> +#define MT7621_CPHA    BIT(5)
>>> +
>>> +#define MASTER_MORE_BUFMODE    BIT(2)
>>> +#define MASTER_RS_CLK_SEL    GENMASK(27, 16)
>>> +#define MASTER_RS_CLK_SEL_SHIFT    16
>>> +#define MASTER_RS_SLAVE_SEL    GENMASK(31, 29)
>>> +
>>> +struct mt7621_spi {
>>> +    void __iomem *base;
>>> +    unsigned int sys_freq;
>>> +    u32 data[(SPI_MSG_SIZE_OVERALL / 4) + 1];
>>> +    int tx_len;
>>> +};
>>> +
>>> +static inline u32 mt7621_spi_read(struct mt7621_spi *rs, u32 reg)
>>> +{
>>> +    return ioread32(rs->base + reg);
>>> +}
>>> +
>>> +static inline void mt7621_spi_write(struct mt7621_spi *rs, u32 reg,
>>> u32 val)
>>> +{
>>> +    iowrite32(val, rs->base + reg);
>>> +}
>>> +
>>> +static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
>>> +{
>>> +    u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
>>> +
>>> +    master |= MASTER_RS_SLAVE_SEL;    /* CS control */
>>> +    master |= MASTER_MORE_BUFMODE;    /* more_buf_mode */
>>> +
>>> +    mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
>>
>> if you omit the (actually unneeded) I/O wrappers, you could simplify
>> this with setbits_le32() (or setbits_32() for non-enforcing endianess)
> 
> Yes, you are correct. All this is derived / copied from the Linux
> driver. Even though the main xfer routine is pretty much different,
> so it makes not much sense any more to stick with this IO wrappers
> for code compatibility.
> 
> I could work on a new version

Re: [U-Boot] [PATCH] arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask

On 08/15/2018 12:32 PM, Ley Foon Tan wrote:
> On Wed, Aug 15, 2018 at 6:21 PM, Marek Vasut  wrote:
>> On 08/15/2018 08:20 PM, Ley Foon Tan wrote:
>>> Bitmask for EMAC should be bit-0, EMAC1 bit-8 and EMAC2 bit-16.
>>>
>>> Signed-off-by: Ley Foon Tan 
>>> ---
>>>  arch/arm/mach-socfpga/include/mach/system_manager_s10.h | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h 
>>> b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>>> index 813dff2..297f9e1 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>>> @@ -146,9 +146,9 @@ struct socfpga_system_manager {
>>>  #define SYSMGR_FPGAINTF_SDMMCBIT(8)
>>>  #define SYSMGR_FPGAINTF_SPIM0BIT(16)
>>>  #define SYSMGR_FPGAINTF_SPIM1BIT(24)
>>> -#define SYSMGR_FPGAINTF_EMAC0(0x11 << 0)
>>> -#define SYSMGR_FPGAINTF_EMAC1(0x11 << 8)
>>> -#define SYSMGR_FPGAINTF_EMAC2(0x11 << 16)
>>
>> Wasn't the point here to unreset the OCP bits alongside the standard
>> EMAC resets too ?
> No, these registers are nothing related to reset. These for FPGA
> interface registers if we route the peripheral pins to use FPGA IO.

OK, applied.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

On 08/15/2018 12:19 PM, Bin Meng wrote:
> Hi Marek,
> 
> On Wed, Aug 15, 2018 at 5:22 PM, Marek Vasut  wrote:
>> On 08/14/2018 11:40 AM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut  wrote:
 On 08/14/2018 03:46 AM, Bin Meng wrote:
> Hi Marek,
>
> On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut  
> wrote:
>> On 08/13/2018 04:24 AM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut  
>>> wrote:
 On 08/10/2018 02:01 PM, Tom Rini wrote:
> On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
>> On 08/08/2018 05:32 PM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut 
>>>  wrote:
 On 08/08/2018 03:39 PM, Bin Meng wrote:
> Hi Marek,
>
> On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut 
>  wrote:
>> On 08/08/2018 03:14 PM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut 
>>>  wrote:
 The PCI controller can have DT subnodes describing extra 
 properties
 of particular PCI devices, ie. a PHY attached to an EHCI 
 controller
 on a PCI bus. This patch parses those DT subnodes and assigns 
 a node
 to the PCI device instance, so that the driver can extract 
 details
 from that node and ie. configure the PHY using the PHY 
 subsystem.

 Signed-off-by: Marek Vasut 
 Cc: Simon Glass 
 ---
  drivers/pci/pci-uclass.c | 14 ++
  1 file changed, 14 insertions(+)

 diff --git a/drivers/pci/pci-uclass.c 
 b/drivers/pci/pci-uclass.c
 index 46e9c71bdf..306bea0dbf 100644
 --- a/drivers/pci/pci-uclass.c
 +++ b/drivers/pci/pci-uclass.c
 @@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct 
 udevice *parent,
 for (id = entry->match;
  id->vendor || id->subvendor || 
 id->class_mask;
  id++) {
 +   ofnode node;
 +
 if (!pci_match_one_id(id, find_id))
 continue;

 @@ -691,6 +693,18 @@ static int 
 pci_find_and_bind_driver(struct udevice *parent,
 goto error;
 debug("%s: Match found: %s\n", 
 __func__, drv->name);
 dev->driver_data = 
 find_id->driver_data;
 +
 +   dev_for_each_subnode(node, parent) {
 +   phys_addr_t df, size;
 +   df = 
 ofnode_get_addr_size(node, "reg", &size);
 +
 +   if (PCI_FUNC(df) == 
 PCI_FUNC(bdf) &&
 +   PCI_DEV(df) == 
 PCI_DEV(bdf)) {
 +   dev->node = node;
 +   break;
 +   }
>>>
>>> The function pci_find_and_bind_driver() is supposed to bind 
>>> devices
>>> that are NOT in the device tree. Adding device tree access in 
>>> this
>>> routine is quite odd. You can add the EHCI controller that need 
>>> such
>>> PHY subnodes in the device tree and there is no need to modify
>>> anything I believe. If you are looking for an example, please 
>>> check
>>> pciuart0 in arch/x86/dts/crownbay.dts.
>>
>> Well this does not work for me, the EHCI PCI doesn't get a DT 
>> node
>> assigned, check r8a7794.dtsi for the PCI devices I use.
>>
>
> I think that's because you don't specify a "compatible" string for
> these two EHCI PCI nodes.

 That's perfectly fine, why should I specify it ? Linux has no 
 problem
 with it either.

>>>
>>> Without a "compatible" string, DM does not bind any device in the
>>> device tree to a driver, hence no device node created. This is not
>>

Re: [U-Boot] [PATCH v2] spi: Add SPI driver for MT76xx SoCs


Hi Daniel,

On 11.08.2018 18:59, Daniel Schwierzeck wrote:

On 10.08.2018 08:56, Stefan Roese wrote:

This patch adds the SPI driver for the MediaTek MT7688 SoC (and
derivates). Its been tested on the LinkIt Smart 7688 and the Gardena
Smart Gateway with and SPI NOR on CS0 and on the Gardena Smart
Gateway additionally with an SPI NAND on CS1.

Note that the SPI controller only supports a max transfer size of 32
bytes. This driver implementes a workaround to enable bigger xfer
sizes to speed up the transfer especially for the SPI NAND support.

Signed-off-by: Stefan Roese 
Cc: Jagan Teki 
---
v2:
- Add some macros instead of hardcoded numbers
- Move compatible DT struct down in the file

  drivers/spi/Kconfig  |   8 +
  drivers/spi/Makefile |   1 +
  drivers/spi/mt76xx_spi.c | 319 +++
  3 files changed, 328 insertions(+)
  create mode 100644 drivers/spi/mt76xx_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9fbd26740d..6c4e50d3e9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -116,6 +116,14 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
  
+config MT76XX_SPI

+   bool "MediaTek MT76XX SPI driver"
+   depends on ARCH_MT7620
+   help
+ Enable the MT76XX SPI driver. This driver can be used to access
+ the SPI NOR flash on platforms embedding these MediaTek
+ SPI cores.
+
  config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
select CLK_ARMADA_3720
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bdb5b5a02f..3d13ba1b21 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
  obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
+obj-$(CONFIG_MT76XX_SPI) += mt76xx_spi.o
  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
  obj-$(CONFIG_MXC_SPI) += mxc_spi.o
  obj-$(CONFIG_MXS_SPI) += mxs_spi.o
diff --git a/drivers/spi/mt76xx_spi.c b/drivers/spi/mt76xx_spi.c
new file mode 100644
index 00..f26b5341ce
--- /dev/null
+++ b/drivers/spi/mt76xx_spi.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * Derived from the Linux driver version drivers/spi/spi-mt7621.c
+ *   Copyright (C) 2011 Sergiy 
+ *   Copyright (C) 2011-2013 Gabor Juhos 
+ *   Copyright (C) 2014-2015 Felix Fietkau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPI_MSG_SIZE_MAX   32  /* SPI message chunk size */
+/* Enough for SPI NAND page read / write with page size 2048 bytes */
+#define SPI_MSG_SIZE_OVERALL   (2048 + 16)
+
+#define MT7621_SPI_TRANS   0x00
+#define MT7621_SPI_TRANS_START BIT(8)
+#define MT7621_SPI_TRANS_BUSY  BIT(16)
+
+#define MT7621_SPI_OPCODE  0x04
+#define MT7621_SPI_DATA0   0x08
+#define MT7621_SPI_DATA4   0x18
+#define MT7621_SPI_MASTER  0x28
+#define MT7621_SPI_MOREBUF 0x2c
+#define MT7621_SPI_POLAR   0x38
+
+#define MT7621_LSB_FIRST   BIT(3)
+#define MT7621_CPOLBIT(4)
+#define MT7621_CPHABIT(5)
+
+#define MASTER_MORE_BUFMODEBIT(2)
+#define MASTER_RS_CLK_SEL  GENMASK(27, 16)
+#define MASTER_RS_CLK_SEL_SHIFT16
+#define MASTER_RS_SLAVE_SELGENMASK(31, 29)
+
+struct mt7621_spi {
+   void __iomem *base;
+   unsigned int sys_freq;
+   u32 data[(SPI_MSG_SIZE_OVERALL / 4) + 1];
+   int tx_len;
+};
+
+static inline u32 mt7621_spi_read(struct mt7621_spi *rs, u32 reg)
+{
+   return ioread32(rs->base + reg);
+}
+
+static inline void mt7621_spi_write(struct mt7621_spi *rs, u32 reg, u32 val)
+{
+   iowrite32(val, rs->base + reg);
+}
+
+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
+{
+   u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
+
+   master |= MASTER_RS_SLAVE_SEL;  /* CS control */
+   master |= MASTER_MORE_BUFMODE;  /* more_buf_mode */
+
+   mt7621_spi_write(rs, MT7621_SPI_MASTER, master);


if you omit the (actually unneeded) I/O wrappers, you could simplify
this with setbits_le32() (or setbits_32() for non-enforcing endianess)


Yes, you are correct. All this is derived / copied from the Linux
driver. Even though the main xfer routine is pretty much different,
so it makes not much sense any more to stick with this IO wrappers
for code compatibility.

I could work on a new version of this driver, omitting these IO
wrappers, if this is preferred. Or I could do this in a follow-up
patch, once this one is in mainline (time is a bit short right now).


+}
+
+static void mt7621_spi_set_cs(struct mt7621_spi *rs, int cs, int enable)
+{
+   u32 val = 0;
+
+   debug("%s: cs#%d -> %s\n", __func__, cs, enable ? "enable" : "disable");
+   if (enable)
+   val = BIT(cs);
+   mt7621_spi_write(rs, MT7621_SPI_POLAR, val);
+}
+
+static

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

On Wed, Aug 15, 2018 at 06:19:25PM +0800, Bin Meng wrote:
> Hi Marek,
> 
> On Wed, Aug 15, 2018 at 5:22 PM, Marek Vasut  wrote:
> > On 08/14/2018 11:40 AM, Bin Meng wrote:
> >> Hi Marek,
> >>
> >> On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut  wrote:
> >>> On 08/14/2018 03:46 AM, Bin Meng wrote:
>  Hi Marek,
> 
>  On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut  
>  wrote:
> > On 08/13/2018 04:24 AM, Bin Meng wrote:
> >> Hi Marek,
> >>
> >> On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut  
> >> wrote:
> >>> On 08/10/2018 02:01 PM, Tom Rini wrote:
>  On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
> > On 08/08/2018 05:32 PM, Bin Meng wrote:
> >> Hi Marek,
> >>
> >> On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut 
> >>  wrote:
> >>> On 08/08/2018 03:39 PM, Bin Meng wrote:
>  Hi Marek,
> 
>  On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut 
>   wrote:
> > On 08/08/2018 03:14 PM, Bin Meng wrote:
> >> Hi Marek,
> >>
> >> On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut 
> >>  wrote:
> >>> The PCI controller can have DT subnodes describing extra 
> >>> properties
> >>> of particular PCI devices, ie. a PHY attached to an EHCI 
> >>> controller
> >>> on a PCI bus. This patch parses those DT subnodes and assigns 
> >>> a node
> >>> to the PCI device instance, so that the driver can extract 
> >>> details
> >>> from that node and ie. configure the PHY using the PHY 
> >>> subsystem.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Simon Glass 
> >>> ---
> >>>  drivers/pci/pci-uclass.c | 14 ++
> >>>  1 file changed, 14 insertions(+)
> >>>
> >>> diff --git a/drivers/pci/pci-uclass.c 
> >>> b/drivers/pci/pci-uclass.c
> >>> index 46e9c71bdf..306bea0dbf 100644
> >>> --- a/drivers/pci/pci-uclass.c
> >>> +++ b/drivers/pci/pci-uclass.c
> >>> @@ -662,6 +662,8 @@ static int 
> >>> pci_find_and_bind_driver(struct udevice *parent,
> >>> for (id = entry->match;
> >>>  id->vendor || id->subvendor || 
> >>> id->class_mask;
> >>>  id++) {
> >>> +   ofnode node;
> >>> +
> >>> if (!pci_match_one_id(id, find_id))
> >>> continue;
> >>>
> >>> @@ -691,6 +693,18 @@ static int 
> >>> pci_find_and_bind_driver(struct udevice *parent,
> >>> goto error;
> >>> debug("%s: Match found: %s\n", 
> >>> __func__, drv->name);
> >>> dev->driver_data = 
> >>> find_id->driver_data;
> >>> +
> >>> +   dev_for_each_subnode(node, parent) {
> >>> +   phys_addr_t df, size;
> >>> +   df = 
> >>> ofnode_get_addr_size(node, "reg", &size);
> >>> +
> >>> +   if (PCI_FUNC(df) == 
> >>> PCI_FUNC(bdf) &&
> >>> +   PCI_DEV(df) == 
> >>> PCI_DEV(bdf)) {
> >>> +   dev->node = node;
> >>> +   break;
> >>> +   }
> >>
> >> The function pci_find_and_bind_driver() is supposed to bind 
> >> devices
> >> that are NOT in the device tree. Adding device tree access in 
> >> this
> >> routine is quite odd. You can add the EHCI controller that 
> >> need such
> >> PHY subnodes in the device tree and there is no need to modify
> >> anything I believe. If you are looking for an example, please 
> >> check
> >> pciuart0 in arch/x86/dts/crownbay.dts.
> >
> > Well this does not work for me, the EHCI PCI doesn't get a DT 
> > node
> > assigned, check r8a7794.dtsi for the PCI devices I use.
> >
> 
>  I think that's because you don't specify a "compatible" string 
>  for
>  these two EHCI PCI nodes.
> >>>
> >>> That's perfectly fine, why should I specify it ? Linux has no 
> >>> problem
> >>> with it either.
> >>>
> >>
> >> Without

Re: [U-Boot] [ANN] U-Boot v2018.09-rc2 released

On Wed, Aug 15, 2018 at 07:14:16AM +0100, Peter Robinson wrote:
> On Wed, Aug 15, 2018 at 7:13 AM, Jagan Teki  
> wrote:
> > On Wed, Aug 15, 2018 at 11:40 AM, Peter Robinson  
> > wrote:
> >> On Wed, Aug 15, 2018 at 6:55 AM, Jagan Teki  
> >> wrote:
> >>> On Wed, Aug 15, 2018 at 2:35 AM, Peter Robinson  
> >>> wrote:
>  On Tue, Aug 14, 2018 at 2:22 AM, Tom Rini  wrote:
> > Hey all,
> >
> > It is release day and despite Travis-CI being really bad about network
> > connections over the weekend, it's back to normal today at least.  So
> > I'm putting out v2018.09-rc2 now.  I plan on looking at Kconfig
> > migrations and similar things that I can size-test.  I think there's
> > still a code removal patch or two I can apply as well at this point.
> >
> > Things look on track for -rc3 on the 27th, -rc4 on September 3rd and
> > then final release on September 10th.  Thanks all!
> 
>  So the AllWinner H3 SoC still appears to be broken in rc2 from the
>  regression that happened just before 2018.07 GA, it was discussed in a
>  couple of threads but I had no answer from previous inquiry [1], does
>  anyone know if there was a conclusion as to the best fix for this?
> 
>  ## Flattened Device Tree blob at 4300
> Booting using the fdt blob at 0x4300
>  EHCI failed to shut down host controller.
>  EHCI failed to shut down host controller.
>  EHCI failed to shut down host controller.
>  EHCI failed to shut down host controller.
> Loading Ramdisk to 4935, end 49fff4f9 ... OK
> Loading Device Tree to 49348000, end 4934fa97 ... OK
> 
>  Starting kernel ...
> 
>  and it just hangs
> 
>  [1] https://lists.denx.de/pipermail/u-boot/2018-August/336837.html
> >>>
> >>> What is this board? Is it reproducing GCC 6.3-2017.02? See this thread
> >>
> >> It's a Orange Pi PC built using gcc 8.2 in Fedora 29. Fedora has a
> >> policy of requiring the distro toolchain so I don't have an option of
> >> using some random toolkit how some users "fixed" it.
> >
> > That may be fedora choice, we just need to understand whether it work
> > with other toolchain or not?
> 
> It also works with 2018.07-rc3

Yes, we cannot say "Oh, you must use $toolchain only" as that means
there's some real bug that's being papered over by how things are
optimized or some compiler bug being tickled by the code.  But it's also
a good data point to have.  Can you please do a one-off manual build and
see if it does work with that toolchain?  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] arm: zynq: Remove useless comments from config file

2018-08-15 Thread Michal Simek

Moving options to Kconfig some comments are useless now.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 2506d2b80606..dded9cd3bf36 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -128,8 +128,6 @@
 /* Boot configuration */
 #define CONFIG_SYS_LOAD_ADDR   0 /* default? */
 
-/* Distro boot enablement */
-
 #ifdef CONFIG_SPL_BUILD
 #define BOOTENV
 #else
@@ -249,10 +247,6 @@
 
 #define CONFIG_SYS_LDSCRIPT  "arch/arm/mach-zynq/u-boot.lds"
 
-/* Commands */
-
-/* SPL part */
-
 /* MMC support */
 #ifdef CONFIG_MMC_SDHCI_ZYNQ
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
@@ -284,8 +278,6 @@
CONFIG_SYS_SPI_ARGS_SIZE)
 #endif
 
-/* for booting directly linux */
-
 /* SP location before relocation, must use scratch RAM */
 #define CONFIG_SPL_TEXT_BASE   0x0
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: socfpga: stratix10: Move reset manager node to top

On Wed, Aug 15, 2018 at 6:31 PM, Marek Vasut  wrote:
> On 08/15/2018 12:28 PM, Ley Foon Tan wrote:
>> On Wed, Aug 15, 2018 at 6:13 PM, Marek Vasut  wrote:
>>> On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
 Move reset manager node to top, so reset driver can be load before
 other drivers. Peripheral drivers have dependency on reset framework
 to reset the hardware.

 Signed-off-by: Ley Foon Tan 
>>>
>>> This will break the next time you sync DTs with Linux, NAK.
>>> The reset manager should just load when it's needed by other drivers. If
>>> it doesn't work that way, something is seriously broken and that is what
>>> needs to be fixed.
>> Yes, seem that it doesn't load the reset manager driver automatically
>> when other driver depend on it.
>> Notice this issue when enable reset framework in GPIO, GPIO driver is
>> loaded at very beginning before go to command prompt.
>> Found this can work in SPL, but not in U-boot (load reset manager
>> driver automatically).
>
> That's probably because you're using the reset in .bind instead of
> .probe , as it should be used ? .bind is ONLY for binding the driver
> with the DM core.
>
Yes, you are right.
Will fix that.

Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask

On Wed, Aug 15, 2018 at 6:21 PM, Marek Vasut  wrote:
> On 08/15/2018 08:20 PM, Ley Foon Tan wrote:
>> Bitmask for EMAC should be bit-0, EMAC1 bit-8 and EMAC2 bit-16.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  arch/arm/mach-socfpga/include/mach/system_manager_s10.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h 
>> b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>> index 813dff2..297f9e1 100644
>> --- a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>> +++ b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
>> @@ -146,9 +146,9 @@ struct socfpga_system_manager {
>>  #define SYSMGR_FPGAINTF_SDMMCBIT(8)
>>  #define SYSMGR_FPGAINTF_SPIM0BIT(16)
>>  #define SYSMGR_FPGAINTF_SPIM1BIT(24)
>> -#define SYSMGR_FPGAINTF_EMAC0(0x11 << 0)
>> -#define SYSMGR_FPGAINTF_EMAC1(0x11 << 8)
>> -#define SYSMGR_FPGAINTF_EMAC2(0x11 << 16)
>
> Wasn't the point here to unreset the OCP bits alongside the standard
> EMAC resets too ?
No, these registers are nothing related to reset. These for FPGA
interface registers if we route the peripheral pins to use FPGA IO.
>
>> +#define SYSMGR_FPGAINTF_EMAC0BIT(0)
>> +#define SYSMGR_FPGAINTF_EMAC1BIT(8)
>> +#define SYSMGR_FPGAINTF_EMAC2BIT(16)
>>
>>  #define SYSMGR_SDMMC_SMPLSEL_SHIFT   4
>>  #define SYSMGR_SDMMC_DRVSEL_SHIFT0
>>
>
>
> --
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: socfpga: stratix10: Move reset manager node to top

On 08/15/2018 12:28 PM, Ley Foon Tan wrote:
> On Wed, Aug 15, 2018 at 6:13 PM, Marek Vasut  wrote:
>> On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
>>> Move reset manager node to top, so reset driver can be load before
>>> other drivers. Peripheral drivers have dependency on reset framework
>>> to reset the hardware.
>>>
>>> Signed-off-by: Ley Foon Tan 
>>
>> This will break the next time you sync DTs with Linux, NAK.
>> The reset manager should just load when it's needed by other drivers. If
>> it doesn't work that way, something is seriously broken and that is what
>> needs to be fixed.
> Yes, seem that it doesn't load the reset manager driver automatically
> when other driver depend on it.
> Notice this issue when enable reset framework in GPIO, GPIO driver is
> loaded at very beginning before go to command prompt.
> Found this can work in SPL, but not in U-boot (load reset manager
> driver automatically).

That's probably because you're using the reset in .bind instead of
.probe , as it should be used ? .bind is ONLY for binding the driver
with the DM core.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb_gpio: Enable get_function support

On Wed, Aug 15, 2018 at 6:12 PM, Marek Vasut  wrote:
> On 08/15/2018 08:05 PM, Ley Foon Tan wrote:
>> Enabled get_function support for dwapb where the function will
>> return the state of GPIO port.
>>
>> Signed-off-by: Chin Liang See 
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  drivers/gpio/dwapb_gpio.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
>> index 680b11a..3b5c181 100644
>> --- a/drivers/gpio/dwapb_gpio.c
>> +++ b/drivers/gpio/dwapb_gpio.c
>> @@ -78,11 +78,26 @@ static int dwapb_gpio_set_value(struct udevice *dev, 
>> unsigned pin, int val)
>>   return 0;
>>  }
>>
>> +static int dwapb_gpio_get_function(struct udevice *dev, unsigned offset)
>> +{
>> + struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
>> + int gpio;
>> +
>> + gpio = readl(plat->base + GPIO_SWPORT_DDR(plat->bank));
>> + gpio = (gpio >> offset) & 1;
>> +
>> + if (gpio)
>
> if (gpio & BIT(offset)) ?
Will change this.
>
>> + return GPIOF_OUTPUT;
>> + else
>> + return GPIOF_INPUT;
>> +}
>> +
>>  static const struct dm_gpio_ops gpio_dwapb_ops = {
>>   .direction_input= dwapb_gpio_direction_input,
>>   .direction_output   = dwapb_gpio_direction_output,
>>   .get_value  = dwapb_gpio_get_value,
>>   .set_value  = dwapb_gpio_set_value,
>> + .get_function   = dwapb_gpio_get_function,
>>  };
>>
>>  static int gpio_dwapb_probe(struct udevice *dev)
>>
>
>
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: socfpga: stratix10: Move reset manager node to top

On Wed, Aug 15, 2018 at 6:13 PM, Marek Vasut  wrote:
> On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
>> Move reset manager node to top, so reset driver can be load before
>> other drivers. Peripheral drivers have dependency on reset framework
>> to reset the hardware.
>>
>> Signed-off-by: Ley Foon Tan 
>
> This will break the next time you sync DTs with Linux, NAK.
> The reset manager should just load when it's needed by other drivers. If
> it doesn't work that way, something is seriously broken and that is what
> needs to be fixed.
Yes, seem that it doesn't load the reset manager driver automatically
when other driver depend on it.
Notice this issue when enable reset framework in GPIO, GPIO driver is
loaded at very beginning before go to command prompt.
Found this can work in SPL, but not in U-boot (load reset manager
driver automatically).


Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc2: Add reset ctrl to driver

On Wed, Aug 15, 2018 at 6:13 PM, Marek Vasut  wrote:
> On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
>> Add code to reset all reset signals as in usb DT node. A reset property
>> is an optional feature, so only print out a warning and do not fail if a
>> reset property is not present.
>>
>> If a reset property is discovered, then use it to deassert, thus
>> bringing the IP out of reset.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  drivers/usb/host/dwc2.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>> index cbe065b..b77e0c6 100644
>> --- a/drivers/usb/host/dwc2.c
>> +++ b/drivers/usb/host/dwc2.c
>> @@ -15,6 +15,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "dwc2.h"
>>
>> @@ -1124,12 +1125,28 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
>> usb_device *dev,
>>   }
>>  }
>>
>> +static void dwc2_reset(struct udevice *dev)
>> +{
>> + struct reset_ctl_bulk reset_bulk;
>> + int ret;
>> +
>> + ret = reset_get_bulk(dev, &reset_bulk);
>> + if (ret) {
>> + dev_warn(dev, "Can't get reset: %d\n", ret);
>> + return;
>> + }
>> +
>> + reset_deassert_bulk(&reset_bulk);
>> +}
>> +
>>  static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>>  {
>>   struct dwc2_core_regs *regs = priv->regs;
>>   uint32_t snpsid;
>>   int i, j;
>>
>> + dwc2_reset(dev);
>> +
>>   snpsid = readl(®s->gsnpsid);
>>   dev_info(dev, "Core Release: %x.%03x\n",
>>snpsid >> 12 & 0xf, snpsid & 0xfff);
>>
>
> .remove() should assert the reset again.
Okay. Will add it.

Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask

On 08/15/2018 08:20 PM, Ley Foon Tan wrote:
> Bitmask for EMAC should be bit-0, EMAC1 bit-8 and EMAC2 bit-16.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/include/mach/system_manager_s10.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h 
> b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> index 813dff2..297f9e1 100644
> --- a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> +++ b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> @@ -146,9 +146,9 @@ struct socfpga_system_manager {
>  #define SYSMGR_FPGAINTF_SDMMCBIT(8)
>  #define SYSMGR_FPGAINTF_SPIM0BIT(16)
>  #define SYSMGR_FPGAINTF_SPIM1BIT(24)
> -#define SYSMGR_FPGAINTF_EMAC0(0x11 << 0)
> -#define SYSMGR_FPGAINTF_EMAC1(0x11 << 8)
> -#define SYSMGR_FPGAINTF_EMAC2(0x11 << 16)

Wasn't the point here to unreset the OCP bits alongside the standard
EMAC resets too ?

> +#define SYSMGR_FPGAINTF_EMAC0BIT(0)
> +#define SYSMGR_FPGAINTF_EMAC1BIT(8)
> +#define SYSMGR_FPGAINTF_EMAC2BIT(16)
>  
>  #define SYSMGR_SDMMC_SMPLSEL_SHIFT   4
>  #define SYSMGR_SDMMC_DRVSEL_SHIFT0
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask

Bitmask for EMAC should be bit-0, EMAC1 bit-8 and EMAC2 bit-16.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/mach-socfpga/include/mach/system_manager_s10.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h 
b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
index 813dff2..297f9e1 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
@@ -146,9 +146,9 @@ struct socfpga_system_manager {
 #define SYSMGR_FPGAINTF_SDMMC  BIT(8)
 #define SYSMGR_FPGAINTF_SPIM0  BIT(16)
 #define SYSMGR_FPGAINTF_SPIM1  BIT(24)
-#define SYSMGR_FPGAINTF_EMAC0  (0x11 << 0)
-#define SYSMGR_FPGAINTF_EMAC1  (0x11 << 8)
-#define SYSMGR_FPGAINTF_EMAC2  (0x11 << 16)
+#define SYSMGR_FPGAINTF_EMAC0  BIT(0)
+#define SYSMGR_FPGAINTF_EMAC1  BIT(8)
+#define SYSMGR_FPGAINTF_EMAC2  BIT(16)
 
 #define SYSMGR_SDMMC_SMPLSEL_SHIFT 4
 #define SYSMGR_SDMMC_DRVSEL_SHIFT  0
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

2018-08-15 Thread Bin Meng

Hi Marek,

On Wed, Aug 15, 2018 at 5:22 PM, Marek Vasut  wrote:
> On 08/14/2018 11:40 AM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut  wrote:
>>> On 08/14/2018 03:46 AM, Bin Meng wrote:
 Hi Marek,

 On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut  wrote:
> On 08/13/2018 04:24 AM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut  
>> wrote:
>>> On 08/10/2018 02:01 PM, Tom Rini wrote:
 On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
> On 08/08/2018 05:32 PM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut  
>> wrote:
>>> On 08/08/2018 03:39 PM, Bin Meng wrote:
 Hi Marek,

 On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut 
  wrote:
> On 08/08/2018 03:14 PM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut 
>>  wrote:
>>> The PCI controller can have DT subnodes describing extra 
>>> properties
>>> of particular PCI devices, ie. a PHY attached to an EHCI 
>>> controller
>>> on a PCI bus. This patch parses those DT subnodes and assigns a 
>>> node
>>> to the PCI device instance, so that the driver can extract 
>>> details
>>> from that node and ie. configure the PHY using the PHY 
>>> subsystem.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Simon Glass 
>>> ---
>>>  drivers/pci/pci-uclass.c | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
>>> index 46e9c71bdf..306bea0dbf 100644
>>> --- a/drivers/pci/pci-uclass.c
>>> +++ b/drivers/pci/pci-uclass.c
>>> @@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct 
>>> udevice *parent,
>>> for (id = entry->match;
>>>  id->vendor || id->subvendor || 
>>> id->class_mask;
>>>  id++) {
>>> +   ofnode node;
>>> +
>>> if (!pci_match_one_id(id, find_id))
>>> continue;
>>>
>>> @@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct 
>>> udevice *parent,
>>> goto error;
>>> debug("%s: Match found: %s\n", 
>>> __func__, drv->name);
>>> dev->driver_data = find_id->driver_data;
>>> +
>>> +   dev_for_each_subnode(node, parent) {
>>> +   phys_addr_t df, size;
>>> +   df = ofnode_get_addr_size(node, 
>>> "reg", &size);
>>> +
>>> +   if (PCI_FUNC(df) == 
>>> PCI_FUNC(bdf) &&
>>> +   PCI_DEV(df) == 
>>> PCI_DEV(bdf)) {
>>> +   dev->node = node;
>>> +   break;
>>> +   }
>>
>> The function pci_find_and_bind_driver() is supposed to bind 
>> devices
>> that are NOT in the device tree. Adding device tree access in 
>> this
>> routine is quite odd. You can add the EHCI controller that need 
>> such
>> PHY subnodes in the device tree and there is no need to modify
>> anything I believe. If you are looking for an example, please 
>> check
>> pciuart0 in arch/x86/dts/crownbay.dts.
>
> Well this does not work for me, the EHCI PCI doesn't get a DT node
> assigned, check r8a7794.dtsi for the PCI devices I use.
>

 I think that's because you don't specify a "compatible" string for
 these two EHCI PCI nodes.
>>>
>>> That's perfectly fine, why should I specify it ? Linux has no 
>>> problem
>>> with it either.
>>>
>>
>> Without a "compatible" string, DM does not bind any device in the
>> device tree to a driver, hence no device node created. This is not
>> Linux.
>
> DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
> hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken 
> and
> must

Re: [U-Boot] [PATCH] arm: dts: socfpga: stratix10: Move reset manager node to top

On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
> Move reset manager node to top, so reset driver can be load before
> other drivers. Peripheral drivers have dependency on reset framework
> to reset the hardware.
> 
> Signed-off-by: Ley Foon Tan 

This will break the next time you sync DTs with Linux, NAK.
The reset manager should just load when it's needed by other drivers. If
it doesn't work that way, something is seriously broken and that is what
needs to be fixed.

> ---
>  arch/arm/dts/socfpga_stratix10.dtsi | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/dts/socfpga_stratix10.dtsi 
> b/arch/arm/dts/socfpga_stratix10.dtsi
> index ccd3f32..748a436 100644
> --- a/arch/arm/dts/socfpga_stratix10.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> @@ -87,6 +87,14 @@
>   reg = <0xffd1 0x1000>;
>   };
>  
> + rst: rstmgr@ffd11000 {
> + #reset-cells = <1>;
> + compatible = "altr,rst-mgr";
> + reg = <0xffd11000 0x1000>;
> + altr,modrst-offset = <0x20>;
> + u-boot,dm-pre-reloc;
> + };
> +
>   gmac0: ethernet@ff80 {
>   compatible = "altr,socfpga-stmmac", "snps,dwmac-3.74a", 
> "snps,dwmac";
>   reg = <0xff80 0x2000>;
> @@ -234,14 +242,6 @@
>   reg = <0xffe0 0x10>;
>   };
>  
> - rst: rstmgr@ffd11000 {
> - #reset-cells = <1>;
> - compatible = "altr,rst-mgr";
> - reg = <0xffd11000 0x1000>;
> - altr,modrst-offset = <0x20>;
> - u-boot,dm-pre-reloc;
> - };
> -
>   spi0: spi@ffda4000 {
>   compatible = "snps,dw-apb-ssi";
>   #address-cells = <1>;
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb_gpio: Enable get_function support

On 08/15/2018 08:05 PM, Ley Foon Tan wrote:
> Enabled get_function support for dwapb where the function will
> return the state of GPIO port.
> 
> Signed-off-by: Chin Liang See 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/gpio/dwapb_gpio.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> index 680b11a..3b5c181 100644
> --- a/drivers/gpio/dwapb_gpio.c
> +++ b/drivers/gpio/dwapb_gpio.c
> @@ -78,11 +78,26 @@ static int dwapb_gpio_set_value(struct udevice *dev, 
> unsigned pin, int val)
>   return 0;
>  }
>  
> +static int dwapb_gpio_get_function(struct udevice *dev, unsigned offset)
> +{
> + struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
> + int gpio;
> +
> + gpio = readl(plat->base + GPIO_SWPORT_DDR(plat->bank));
> + gpio = (gpio >> offset) & 1;
> +
> + if (gpio)

if (gpio & BIT(offset)) ?

> + return GPIOF_OUTPUT;
> + else
> + return GPIOF_INPUT;
> +}
> +
>  static const struct dm_gpio_ops gpio_dwapb_ops = {
>   .direction_input= dwapb_gpio_direction_input,
>   .direction_output   = dwapb_gpio_direction_output,
>   .get_value  = dwapb_gpio_get_value,
>   .set_value  = dwapb_gpio_set_value,
> + .get_function   = dwapb_gpio_get_function,
>  };
>  
>  static int gpio_dwapb_probe(struct udevice *dev)
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc2: Add reset ctrl to driver

On 08/15/2018 08:01 PM, Ley Foon Tan wrote:
> Add code to reset all reset signals as in usb DT node. A reset property
> is an optional feature, so only print out a warning and do not fail if a
> reset property is not present.
> 
> If a reset property is discovered, then use it to deassert, thus
> bringing the IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/usb/host/dwc2.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index cbe065b..b77e0c6 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "dwc2.h"
>  
> @@ -1124,12 +1125,28 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
> usb_device *dev,
>   }
>  }
>  
> +static void dwc2_reset(struct udevice *dev)
> +{
> + struct reset_ctl_bulk reset_bulk;
> + int ret;
> +
> + ret = reset_get_bulk(dev, &reset_bulk);
> + if (ret) {
> + dev_warn(dev, "Can't get reset: %d\n", ret);
> + return;
> + }
> +
> + reset_deassert_bulk(&reset_bulk);
> +}
> +
>  static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>  {
>   struct dwc2_core_regs *regs = priv->regs;
>   uint32_t snpsid;
>   int i, j;
>  
> + dwc2_reset(dev);
> +
>   snpsid = readl(®s->gsnpsid);
>   dev_info(dev, "Core Release: %x.%03x\n",
>snpsid >> 12 & 0xf, snpsid & 0xfff);
> 

.remove() should assert the reset again.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb_gpio: Change to use dev_read_addr()

On 08/15/2018 08:05 PM, Ley Foon Tan wrote:
> This changes the driver to use dev_read_addr() which is safe both for
> flat trees and live trees.
> 
> Signed-off-by: Ley Foon Tan 

Acked-by: Marek Vasut 

> ---
>  drivers/gpio/dwapb_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> index a118f58..680b11a 100644
> --- a/drivers/gpio/dwapb_gpio.c
> +++ b/drivers/gpio/dwapb_gpio.c
> @@ -111,7 +111,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
>   if (plat)
>   return 0;
>  
> - base = fdtdec_get_addr(blob, dev_of_offset(dev), "reg");
> + base = dev_read_addr(dev);
>   if (base == FDT_ADDR_T_NONE) {
>   debug("Can't get the GPIO register base address\n");
>   return -ENXIO;
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb_gpio: Add reset ctrl to driver

On 08/15/2018 08:05 PM, Ley Foon Tan wrote:
> Add code to reset all reset signals as in gpio DT node. A reset property
> is an optional feature, so only print out a warning and do not fail if a
> reset property is not present.
> 
> If a reset property is discovered, then use it to deassert, thus
> bringing the IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/gpio/dwapb_gpio.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> index 3b5c181..e2b6e69 100644
> --- a/drivers/gpio/dwapb_gpio.c
> +++ b/drivers/gpio/dwapb_gpio.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -114,6 +115,20 @@ static int gpio_dwapb_probe(struct udevice *dev)
>   return 0;
>  }
>  
> +static void gpio_dwapb_reset(struct udevice *dev)
> +{
> + struct reset_ctl_bulk reset_bulk;
> + int ret;
> +
> + ret = reset_get_bulk(dev, &reset_bulk);
> + if (ret) {
> + dev_warn(dev, "Can't get reset: %d\n", ret);
> + return;
> + }
> +
> + reset_deassert_bulk(&reset_bulk);
> +}
> +
>  static int gpio_dwapb_bind(struct udevice *dev)
>  {
>   struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
> @@ -126,6 +141,8 @@ static int gpio_dwapb_bind(struct udevice *dev)
>   if (plat)
>   return 0;
>  
> + gpio_dwapb_reset(dev);

This should be done in probe, not bind. Also, it should be undone in
.remove.

>   base = dev_read_addr(dev);
>   if (base == FDT_ADDR_T_NONE) {
>   debug("Can't get the GPIO register base address\n");
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] gpio: dwapb_gpio: Enable get_function support

Enabled get_function support for dwapb where the function will
return the state of GPIO port.

Signed-off-by: Chin Liang See 
Signed-off-by: Ley Foon Tan 
---
 drivers/gpio/dwapb_gpio.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 680b11a..3b5c181 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -78,11 +78,26 @@ static int dwapb_gpio_set_value(struct udevice *dev, 
unsigned pin, int val)
return 0;
 }
 
+static int dwapb_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
+   int gpio;
+
+   gpio = readl(plat->base + GPIO_SWPORT_DDR(plat->bank));
+   gpio = (gpio >> offset) & 1;
+
+   if (gpio)
+   return GPIOF_OUTPUT;
+   else
+   return GPIOF_INPUT;
+}
+
 static const struct dm_gpio_ops gpio_dwapb_ops = {
.direction_input= dwapb_gpio_direction_input,
.direction_output   = dwapb_gpio_direction_output,
.get_value  = dwapb_gpio_get_value,
.set_value  = dwapb_gpio_set_value,
+   .get_function   = dwapb_gpio_get_function,
 };
 
 static int gpio_dwapb_probe(struct udevice *dev)
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] gpio: dwapb_gpio: Add reset ctrl to driver

Add code to reset all reset signals as in gpio DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 
---
 drivers/gpio/dwapb_gpio.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 3b5c181..e2b6e69 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -114,6 +115,20 @@ static int gpio_dwapb_probe(struct udevice *dev)
return 0;
 }
 
+static void gpio_dwapb_reset(struct udevice *dev)
+{
+   struct reset_ctl_bulk reset_bulk;
+   int ret;
+
+   ret = reset_get_bulk(dev, &reset_bulk);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   return;
+   }
+
+   reset_deassert_bulk(&reset_bulk);
+}
+
 static int gpio_dwapb_bind(struct udevice *dev)
 {
struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
@@ -126,6 +141,8 @@ static int gpio_dwapb_bind(struct udevice *dev)
if (plat)
return 0;
 
+   gpio_dwapb_reset(dev);
+
base = dev_read_addr(dev);
if (base == FDT_ADDR_T_NONE) {
debug("Can't get the GPIO register base address\n");
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] gpio: dwapb_gpio: Change to use dev_read_addr()

This changes the driver to use dev_read_addr() which is safe both for
flat trees and live trees.

Signed-off-by: Ley Foon Tan 
---
 drivers/gpio/dwapb_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index a118f58..680b11a 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -111,7 +111,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
if (plat)
return 0;
 
-   base = fdtdec_get_addr(blob, dev_of_offset(dev), "reg");
+   base = dev_read_addr(dev);
if (base == FDT_ADDR_T_NONE) {
debug("Can't get the GPIO register base address\n");
return -ENXIO;
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: dts: socfpga: stratix10: Move reset manager node to top

Move reset manager node to top, so reset driver can be load before
other drivers. Peripheral drivers have dependency on reset framework
to reset the hardware.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/dts/socfpga_stratix10.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/socfpga_stratix10.dtsi 
b/arch/arm/dts/socfpga_stratix10.dtsi
index ccd3f32..748a436 100644
--- a/arch/arm/dts/socfpga_stratix10.dtsi
+++ b/arch/arm/dts/socfpga_stratix10.dtsi
@@ -87,6 +87,14 @@
reg = <0xffd1 0x1000>;
};
 
+   rst: rstmgr@ffd11000 {
+   #reset-cells = <1>;
+   compatible = "altr,rst-mgr";
+   reg = <0xffd11000 0x1000>;
+   altr,modrst-offset = <0x20>;
+   u-boot,dm-pre-reloc;
+   };
+
gmac0: ethernet@ff80 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.74a", 
"snps,dwmac";
reg = <0xff80 0x2000>;
@@ -234,14 +242,6 @@
reg = <0xffe0 0x10>;
};
 
-   rst: rstmgr@ffd11000 {
-   #reset-cells = <1>;
-   compatible = "altr,rst-mgr";
-   reg = <0xffd11000 0x1000>;
-   altr,modrst-offset = <0x20>;
-   u-boot,dm-pre-reloc;
-   };
-
spi0: spi@ffda4000 {
compatible = "snps,dw-apb-ssi";
#address-cells = <1>;
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] usb: dwc2: Add reset ctrl to driver

Add code to reset all reset signals as in usb DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 
---
 drivers/usb/host/dwc2.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index cbe065b..b77e0c6 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dwc2.h"
 
@@ -1124,12 +1125,28 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
usb_device *dev,
}
 }
 
+static void dwc2_reset(struct udevice *dev)
+{
+   struct reset_ctl_bulk reset_bulk;
+   int ret;
+
+   ret = reset_get_bulk(dev, &reset_bulk);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   return;
+   }
+
+   reset_deassert_bulk(&reset_bulk);
+}
+
 static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
 {
struct dwc2_core_regs *regs = priv->regs;
uint32_t snpsid;
int i, j;
 
+   dwc2_reset(dev);
+
snpsid = readl(®s->gsnpsid);
dev_info(dev, "Core Release: %x.%03x\n",
 snpsid >> 12 & 0xf, snpsid & 0xfff);
-- 
2.2.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

On 08/14/2018 11:40 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut  wrote:
>> On 08/14/2018 03:46 AM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut  wrote:
 On 08/13/2018 04:24 AM, Bin Meng wrote:
> Hi Marek,
>
> On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut  
> wrote:
>> On 08/10/2018 02:01 PM, Tom Rini wrote:
>>> On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
 On 08/08/2018 05:32 PM, Bin Meng wrote:
> Hi Marek,
>
> On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut  
> wrote:
>> On 08/08/2018 03:39 PM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut  
>>> wrote:
 On 08/08/2018 03:14 PM, Bin Meng wrote:
> Hi Marek,
>
> On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut 
>  wrote:
>> The PCI controller can have DT subnodes describing extra 
>> properties
>> of particular PCI devices, ie. a PHY attached to an EHCI 
>> controller
>> on a PCI bus. This patch parses those DT subnodes and assigns a 
>> node
>> to the PCI device instance, so that the driver can extract 
>> details
>> from that node and ie. configure the PHY using the PHY subsystem.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Simon Glass 
>> ---
>>  drivers/pci/pci-uclass.c | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
>> index 46e9c71bdf..306bea0dbf 100644
>> --- a/drivers/pci/pci-uclass.c
>> +++ b/drivers/pci/pci-uclass.c
>> @@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct 
>> udevice *parent,
>> for (id = entry->match;
>>  id->vendor || id->subvendor || 
>> id->class_mask;
>>  id++) {
>> +   ofnode node;
>> +
>> if (!pci_match_one_id(id, find_id))
>> continue;
>>
>> @@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct 
>> udevice *parent,
>> goto error;
>> debug("%s: Match found: %s\n", __func__, 
>> drv->name);
>> dev->driver_data = find_id->driver_data;
>> +
>> +   dev_for_each_subnode(node, parent) {
>> +   phys_addr_t df, size;
>> +   df = ofnode_get_addr_size(node, 
>> "reg", &size);
>> +
>> +   if (PCI_FUNC(df) == 
>> PCI_FUNC(bdf) &&
>> +   PCI_DEV(df) == PCI_DEV(bdf)) 
>> {
>> +   dev->node = node;
>> +   break;
>> +   }
>
> The function pci_find_and_bind_driver() is supposed to bind 
> devices
> that are NOT in the device tree. Adding device tree access in this
> routine is quite odd. You can add the EHCI controller that need 
> such
> PHY subnodes in the device tree and there is no need to modify
> anything I believe. If you are looking for an example, please 
> check
> pciuart0 in arch/x86/dts/crownbay.dts.

 Well this does not work for me, the EHCI PCI doesn't get a DT node
 assigned, check r8a7794.dtsi for the PCI devices I use.

>>>
>>> I think that's because you don't specify a "compatible" string for
>>> these two EHCI PCI nodes.
>>
>> That's perfectly fine, why should I specify it ? Linux has no problem
>> with it either.
>>
>
> Without a "compatible" string, DM does not bind any device in the
> device tree to a driver, hence no device node created. This is not
> Linux.

 DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
 hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken 
 and
 must be fixed.

 This is a fix. If there is a better fix, I am open to it.
>>>
>>> DT should but isn't always OS agnostic.  DTS files that reside in the
>>> Linux Kernel are in practice is Linux-ce

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

On 08/14/2018 11:35 AM, Bin Meng wrote:
[...]

>> I think knowing where Linux does this
>> would be instructive to figure out where we need to have some additional
>> logic added OR we can make some cost/benefit analysis to see if it makes
>> more sense overall to add compatibles to some nodes rather than add to
>> the binary size.
>
> Adding compatible does not make any sense, the PCI ID provides that
> information. Adding compatible would only add redundancy which could
> possibly be even harmful (ie. if the controller got replaced with
> another one).

 To try and move things along rather than re-argue the same point, you're
 saying that our pci_find_and_bind_driver() is the rough equivalent of
 of_pci_find_child_device() or at least pci_set_of_node() (which calls
 of_pci_find_child_device()).

 So, Bin, if this isn't the right place to start down this path, where
 would be?  Given that Linux can take a DTB and PCI bus with devices and
 get things right, what would it look like for U-Boot to replicate the
 same behavior?  Instead of having to add explicit compatible nodes for
 each PCI device, as I understand (but correct me if I'm wrong) we're
 doing today.  Thanks!
>>>
>>> So is this a requirement for all U-Boot driver subsystems to replicate
>>> the same Linux behavior? If yes, can we have it officially documented
>>> somewhere?
>>
>> No, because we are not replicating Linux behavior.
>>
> 
> But you kept mentioning you wanted U-Boot to use exactly the same DT
> from Linux. And I pointed out that FreeBSD's DT files are not the same
> as Linux. Here you are saying you don't want U-Boot to replicate Linux
> behavior, if not the Linux behavior, what do you want to suggest then?

Just parse the information out of the DT fully and be done with it.
That is what I suggest.

>>> Since Marek refused to take the original U-Boot option 1 to support
>>> his case, and asked U-Boot to follow Linux's practice on PCI device
>>> binding, if we go that way, here is what we can do:
>>
>> You are inserting words into my mouth and I dislike that. I never said
>> anything about Linux. I said DT is OS agnostic and U-Boot should be able
>> to parse DT as fully as possible.
> 
> See above comment. I might have used some words that made you feel
> uncomfortable, and for me I felt the same way. Part of the reason is
> that I am not a native English speaker and I may mis-use/interpret
> words. If that's the case I apologize. Anyway I won't quarrel against
> this over and over again. This does not help to move things forward.

This is a technical discussion, we should use arguments, not feelings.
I am fine, but thanks for your concern.

>>> * Keep pci-uclass driver's post_bind() and child_post_bind() only for
>>> Sandbox configuration
>>> * Keep the call to pci_bus_find_devfn() in pci_bind_bus_devices() only
>>> for Sandbox configuration
>>> * Sandbox is special. We should limit the mechanism of matching PCI
>>> emulation device via "compatible" to sandbox only
>>
>> I don't think this is limited to sandbox, although I don't see a
>> real-world usecase right now.
>>
> 
> You are welcome to send patches against sandbox PCI codes to remove
> such limitation, to make it behave like a real-world bus device.
> 
>>> * Assign the DT node to the bound device in pci_find_and_bind_driver()
>>> if there is a valid PCI "reg" encoding for a specific PCI device in
>>> the device tree
>>> * Create DM PCI test case against the DT node assignment
>>> * Remove all compatible string in U-Boot's PCI device drivers: eg:
>>> ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers
>>> should only use U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
>>> * Fork a "pci-ns16550" driver to support U_BOOT_PCI_DEVICE(), as
>>> currently PCI ns16550 device driver uses "compatible" string to do the
>>> matching, and update crownbay.dts and galileo.dts (so far I only know
>>> two boards are using PCI ns16550 serial port)
>>
>> I cannot test such changes, but I believe there is
>> PCI_CLASS_COMMUNICATION_SERIAL and matching on that would suffice ?
>>
> 
> Maybe, but I need check the datasheet to confirm. This can be a good
> start though. Note I can test the changes, and I can do the whole
> bunch of such proposed design changes if you don't mind, but let's
> wait for Simon's comments.

All those sandbox changes can be done in parallel to this change though,
right ?

>>> * Make sure all DM PCI test cases are not broken
>>> * Document all of the above changes in doc/driver-model/pci-info.txt
>>>
>>> I am not sure if I missed anything. Simon, could you also comment on it?
> 
> Regards,
> Bin
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] spl: Weed out CONFIG_SYS_TEXT_BASE usage

2018-08-15 Thread Simon Goldschmidt

Marek Vasut  schrieb am Mi., 15. Aug. 2018, 10:57:

> On 08/14/2018 08:25 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 8:17 PM Marek Vasut  wrote:
> >>
> >> On 08/14/2018 02:56 PM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018 at 2:05 PM Marek Vasut  wrote:
> 
>  On 08/14/2018 12:22 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 12:10 PM Marek Vasut  wrote:
> >>
> >> On 08/14/2018 11:51 AM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018 at 11:27 AM Marek Vasut 
> wrote:
> 
>  The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory
> location
>  is available and can be corrupted by loading ie. uImage or
> fitImage
>  headers there. Sometimes it could be beneficial to load the
> headers
>  elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while
> we
>  still want to parse the image headers in some local onchip memory
> to
>  ie. extract firmware from that image.
> 
>  Add the possibility to override the location where the headers get
>  loaded by introducing new function, spl_get_load_buffer() which
> takes
>  two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of
> the
>  data that are to be loaded there -- and returns a valid buffer
> address
>  or hangs the system. The default behavior is the same as before,
> add
>  the offset to CONFIG_SYS_TEXT_BASE and return that address. User
> can
>  override the weak spl_get_load_buffer() function though.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Tom Rini 
>  ---
>  V2: Fix build issues on multiple boards due to incorrect pointer
> casting
> >>
> >> [...]
> >>
>  diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
>  index e594beaeaa..619b39a537 100644
>  --- a/common/spl/spl_ram.c
>  +++ b/common/spl/spl_ram.c
>  @@ -63,8 +63,9 @@ static int spl_ram_load_image(struct
> spl_image_info *spl_image,
>   * No binman support or no information.
> For now, fix it
>   * to the address pointed to by U-Boot.
>   */
>  -   u_boot_pos = CONFIG_SYS_TEXT_BASE -
>  -   sizeof(struct
> image_header);
>  +   header =
> spl_get_load_buffer(-sizeof(*header),
>  +
> sizeof(*header));
>  +
> >>>
> >>> Using "spl_get_load_buffer()" here seems to be a bit misleading, as
> >>> the address is used for "execute-in-place", not for loading.
> >>
> >> Do you have a better solution ? Instead of hard-coding the load
> buffer
> >> address with some macro, this uses function which could be
> overridden.
> >> Whether it's XIP or not has nothing to do with it.
> >
> > I meant the name is a bit misleading as it implies loading. But since
> > the preferred way to do this is using binman, it's probably not worth
> > adding yet another weak function for RAM boot?
> 
>  Do you have a better name that fits all the other usecases ? This
>  function just gets you buffer into which you can load the image.
> >>>
> >>> Not really. I just wonder if you have to override the location for
> >>> some board, RAM booting might not work any more as it relies on a
> >>> fixed address, not some generic buffer.
> >>
> >> I do, yeah, the board is not upstream completely yet though, so I am
> >> just sending this as a cleanup.
> >>
> >>> Maybe we could add the boot device to your new weak function? If we
> >>> add some comment to the new weak function, that would have made it
> >>> much more clear for me how to boot U-Boot from FPGA OnChip RAM when I
> >>> tried some months ago :-)
> >>
> >> This really just gives you a buffer. I don't need to know which boot
> >> media is used. If there is a usecase, sure, it can be added later.
> >
> > I may have a use case for one of our custom boards, but it's probably
> > not worth doing that now.
>
> Subsequent patch then ?
>

I'll send a patch if we really need that...


>  }
>  header = (struct image_header
> *)map_sysmem(u_boot_pos, 0);
> 
>  diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
>  index ba60a3a3c5..e10cf0124f 100644
>  --- a/common/spl/spl_spi.c
>  +++ b/common/spl/spl_spi.c
>  @@ -88,8 +88,7 @@ static int spl_spi_load_image(struct
> spl_image_info *spl_image,
>  return -ENODEV;
>  }
> 
>  -   /* use CONFIG_SYS_TEXT_BASE as temporary storage area */
>  -   header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
>  +   header = spl_get_load_buffer(-sizeof(*header), 0x40);
> >>>
> >>> Shouldn't the first argument be 0 here

Re: [U-Boot] [PATCH v4 4/5] arm: socfpga: fix SPL booting from fpga OnChip RAM

On 08/14/2018 10:26 PM, Simon Goldschmidt wrote:
> On Tue, Aug 14, 2018 at 8:12 AM Simon Goldschmidt
>  wrote:
>>
>>
>>
>> Marek Vasut  schrieb am Mo., 13. Aug. 2018, 22:36:
>>>
>>> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
 To boot from fpga OnChip RAM, some changes are required in SPL
 to ensure the code is linked to the correct address (in contrast
 to QSPI and MMC boot, FPGA boot executes SPL in place instead of
 copying it to SRAM) and that fpga OnChip RAM stays accessible while
 SPL runs (don't disable fpga bridges).

 This adds a new config option (CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA)
 for socfpga gen5 boards.

 Signed-off-by: Simon Goldschmidt 
 ---

 Changes in v4: Adapted to changed previous patch
 Changes in v3: this patch is new in v3
 Changes in v2: None

  arch/arm/mach-socfpga/Kconfig | 12 
  arch/arm/mach-socfpga/misc_gen5.c | 11 +--
  arch/arm/mach-socfpga/spl_gen5.c  |  6 --
  include/configs/socfpga_common.h  |  5 +
  4 files changed, 30 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
 index 5c1df2cf1f..a909395aac 100644
 --- a/arch/arm/mach-socfpga/Kconfig
 +++ b/arch/arm/mach-socfpga/Kconfig
 @@ -132,3 +132,15 @@ config SYS_CONFIG_NAME
   default "socfpga_vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA

  endif
 +
 +if TARGET_SOCFPGA_GEN5
 +
 +config SPL_SOCFPGA_BOOT_FROM_FPGA
 + bool "Allow booting SPL from FPGA OnChip RAM"
 + default n
 + help
 +   Boot from FPGA: this changes the linker address for SPL code to run
 +   from FPGA OnChip memory instead of SRAM and ensures FPGA OnChip RAM
 +   stays accessible while SPL runs.
 +
 +endif
 diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
 b/arch/arm/mach-socfpga/misc_gen5.c
 index 429c3d6cd5..c82c3584dc 100644
 --- a/arch/arm/mach-socfpga/misc_gen5.c
 +++ b/arch/arm/mach-socfpga/misc_gen5.c
 @@ -187,7 +187,13 @@ void socfpga_sdram_remap_zero(void)
   setbits_le32(&scu_regs->sacr, 0xfff);

   /* Configure the L2 controller to make SDRAM start at 0 */
 - writel(0x1, &nic301_regs->remap);   /* remap.mpuzero */
 + if (CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA)) {
 + /* remap.mpuzero, keep fpga bridge enabled */
 + writel(0x9, &nic301_regs->remap);
 + } else {
 + /* remap.mpuzero */
 + writel(0x1, &nic301_regs->remap);
 + }
   writel(0x1, &pl310->pl310_addr_filter_start);
  }

 @@ -209,7 +215,8 @@ int arch_early_init_r(void)
   for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
   iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);

 - socfpga_bridges_reset(1);
 + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
 + socfpga_bridges_reset(1);

   socfpga_sdram_remap_zero();

 diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
 b/arch/arm/mach-socfpga/spl_gen5.c
 index be318cc0d9..0c7f6a8c84 100644
 --- a/arch/arm/mach-socfpga/spl_gen5.c
 +++ b/arch/arm/mach-socfpga/spl_gen5.c
 @@ -93,7 +93,8 @@ void board_init_f(ulong dummy)
   /* Put everything into reset but L4WD0. */
   socfpga_per_reset_all();
   /* Put FPGA bridges into reset too. */
 - socfpga_bridges_reset(1);
 + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
 + socfpga_bridges_reset(1);

   socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
   socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
 @@ -163,5 +164,6 @@ void board_init_f(ulong dummy)
   hang();
   }

 - socfpga_bridges_reset(1);
 + if (!CONFIG_IS_ENABLED(SOCFPGA_BOOT_FROM_FPGA))
 + socfpga_bridges_reset(1);
  }
 diff --git a/include/configs/socfpga_common.h 
 b/include/configs/socfpga_common.h
 index d1148b838b..99c5e39086 100644
 --- a/include/configs/socfpga_common.h
 +++ b/include/configs/socfpga_common.h
 @@ -239,7 +239,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
   * 0xFFEz_ .. Malloc area (grows up to top)
   * 0xFFE3_ .. End of SRAM (top)
   */
 +#if CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA
 +/* SPL executed from FPGA */
 +#define CONFIG_SPL_TEXT_BASE 0xC000
 +#else
  #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR
 +#endif
  #define CONFIG_SPL_MAX_SIZE  CONFIG_SYS_INIT_RAM_SIZE

  #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
>>>
>>> What about converting the SPL_TEXT_BASE to Kconfig , cfr my comment on
>>> the previous version of the patch ?
> 
> Revisiting that request again, it seems like I would touch tons of

Re: [U-Boot] [PATCH v4 2/5] arm: socfpga: fix U-Boot running from fpga OnChip RAM

On 08/14/2018 10:19 PM, Simon Goldschmidt wrote:
> On Tue, Aug 14, 2018 at 10:37 AM Marek Vasut  wrote:
>>
>> On 08/14/2018 08:09 AM, Simon Goldschmidt wrote:
>>>
>>>
>>> Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 13.
>>> Aug. 2018, 22:36:
>>>
>>> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
>>> > gd->env_addr points to pre-relocation address even after
>>> > relocation. This leads to an abort in env_callback_init
>>> > when loading the environment.
>>> >
>>> > Fix this by enabling CONFIG_SYS_EXTRA_ENV_RELOC.
>>> >
>>> > Signed-off-by: Simon Goldschmidt >> >
>>> > ---
>>> >
>>> > Changes in v4: enable this fix for all socfpga, not for gen5 only
>>> > Changes in v3: this patch is new in v3
>>> > Changes in v2: None
>>> >
>>> >  include/configs/socfpga_common.h | 6 ++
>>> >  1 file changed, 6 insertions(+)
>>> >
>>> > diff --git a/include/configs/socfpga_common.h
>>> b/include/configs/socfpga_common.h
>>> > index 8ebf6b85fe..d1148b838b 100644
>>> > --- a/include/configs/socfpga_common.h
>>> > +++ b/include/configs/socfpga_common.h
>>> > @@ -284,6 +284,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>>> >  #define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START
>>> >  #endif
>>> >
>>> > +/* When U-Boot is started from FPGA, prevent gd->env_addr to
>>> point into
>>>
>>> Multi-line comment should have this format
>>> /*
>>>  * foo
>>>  * bar
>>>  */
>>>
>>>
>>> Right, of course. I wonder why patman didn't warm me about that...
>>>
>>>
>>> > + * FPGA OnChip RAM after relocation
>>> > + */
>>> > +#define CONFIG_SYS_EXTRA_ENV_RELOC
>>> > +#define CONFIG_SYS_MONITOR_BASE  CONFIG_SYS_TEXT_BASE/*
>>> start of monitor */
>>>
>>> What you don't explain in the commit message is this last line. Why is
>>> this needed ?
>>>
>>>
>>> The code enabled by CONFIG_SYS_EXTRA_ENV_RELOC used this to calculate
>>> the relocation offset. I do think that's a bit strange, but I wouldn't
>>> change it with this patchset, or should I?
>>
>> You should document _why_ this is needed. Not "because the code enabled
>> by foo needed this", but why that code enabled this and why setting it
>> to SYS_TEXT_BASE is correct.
> 
> Yes, I wouldn't have sent a patch like that. I rather wanted to phrase
> that I don't know why this is needed for env relocation, as fdt
> relocation just uses gd->reloc_off. That might work for env
> relocation, too, but changing that seems out of scope for this
> patchset.

Maybe the comment in board_r.c explains why?

143 #ifdef CONFIG_SYS_EXTRA_ENV_RELOC
144 /*
145  * Some systems need to relocate the env_addr pointer early
because the
146  * location it points to will get invalidated before
env_relocate is
147  * called.  One example is on systems that might use a L2 or
L3 cache
148  * in SRAM mode and initialize that cache from SRAM mode
back to being
149  * a cache in cpu_init_r.
150  */
151 gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE;
152 #endif

But then the env shouldn't point to pre-reloc address after relocation
according to the comment ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] spl: Weed out CONFIG_SYS_TEXT_BASE usage

On 08/14/2018 08:25 PM, Simon Goldschmidt wrote:
> On Tue, Aug 14, 2018 at 8:17 PM Marek Vasut  wrote:
>>
>> On 08/14/2018 02:56 PM, Simon Goldschmidt wrote:
>>> On Tue, Aug 14, 2018 at 2:05 PM Marek Vasut  wrote:

 On 08/14/2018 12:22 PM, Simon Goldschmidt wrote:
> On Tue, Aug 14, 2018 at 12:10 PM Marek Vasut  wrote:
>>
>> On 08/14/2018 11:51 AM, Simon Goldschmidt wrote:
>>> On Tue, Aug 14, 2018 at 11:27 AM Marek Vasut  wrote:

 The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
 is available and can be corrupted by loading ie. uImage or fitImage
 headers there. Sometimes it could be beneficial to load the headers
 elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while we
 still want to parse the image headers in some local onchip memory to
 ie. extract firmware from that image.

 Add the possibility to override the location where the headers get
 loaded by introducing new function, spl_get_load_buffer() which takes
 two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of the
 data that are to be loaded there -- and returns a valid buffer address
 or hangs the system. The default behavior is the same as before, add
 the offset to CONFIG_SYS_TEXT_BASE and return that address. User can
 override the weak spl_get_load_buffer() function though.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 ---
 V2: Fix build issues on multiple boards due to incorrect pointer 
 casting
>>
>> [...]
>>
 diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
 index e594beaeaa..619b39a537 100644
 --- a/common/spl/spl_ram.c
 +++ b/common/spl/spl_ram.c
 @@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info 
 *spl_image,
  * No binman support or no information. For 
 now, fix it
  * to the address pointed to by U-Boot.
  */
 -   u_boot_pos = CONFIG_SYS_TEXT_BASE -
 -   sizeof(struct image_header);
 +   header = spl_get_load_buffer(-sizeof(*header),
 +sizeof(*header));
 +
>>>
>>> Using "spl_get_load_buffer()" here seems to be a bit misleading, as
>>> the address is used for "execute-in-place", not for loading.
>>
>> Do you have a better solution ? Instead of hard-coding the load buffer
>> address with some macro, this uses function which could be overridden.
>> Whether it's XIP or not has nothing to do with it.
>
> I meant the name is a bit misleading as it implies loading. But since
> the preferred way to do this is using binman, it's probably not worth
> adding yet another weak function for RAM boot?

 Do you have a better name that fits all the other usecases ? This
 function just gets you buffer into which you can load the image.
>>>
>>> Not really. I just wonder if you have to override the location for
>>> some board, RAM booting might not work any more as it relies on a
>>> fixed address, not some generic buffer.
>>
>> I do, yeah, the board is not upstream completely yet though, so I am
>> just sending this as a cleanup.
>>
>>> Maybe we could add the boot device to your new weak function? If we
>>> add some comment to the new weak function, that would have made it
>>> much more clear for me how to boot U-Boot from FPGA OnChip RAM when I
>>> tried some months ago :-)
>>
>> This really just gives you a buffer. I don't need to know which boot
>> media is used. If there is a usecase, sure, it can be added later.
> 
> I may have a use case for one of our custom boards, but it's probably
> not worth doing that now.

Subsequent patch then ?

 }
 header = (struct image_header *)map_sysmem(u_boot_pos, 
 0);

 diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
 index ba60a3a3c5..e10cf0124f 100644
 --- a/common/spl/spl_spi.c
 +++ b/common/spl/spl_spi.c
 @@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info 
 *spl_image,
 return -ENODEV;
 }

 -   /* use CONFIG_SYS_TEXT_BASE as temporary storage area */
 -   header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
 +   header = spl_get_load_buffer(-sizeof(*header), 0x40);
>>>
>>> Shouldn't the first argument be 0 here instead of -sizeof(*header)?
>>
>> No, because then the payload doesn't end up at CONFIG_SYS_TEXT_BASE .
>
> Sorry, I haven't studied the code around the patch, only the patch.
> And I still think "header" has cha

[U-Boot] CONFIG_MIPS_BOOT_CMDLINE_LEGACY usage ?