Re: u-boot 32-bit on Raspberry Pi 4

2020-01-17 Thread Alexander von Gluck IV
January 17, 2020 7:59 PM, "Jaehoon Chung"  wrote:
> On 1/18/20 10:53 AM, Jaehoon Chung wrote:
> 
>> Hi
>> 
>> On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:
>>> Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?
>> 
>> I'm using 32-bit u-boot on RPI4 board with Tizen Platform.
>> You can refer to tizen u-boot git. Also I modified some configurations.
>> 
>> https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-40c2c54dba31c6f3=https:
>> /git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen
>>
>> enable_uart=1
>> uart_2ndstage=1

uart_2ndstate=1 helped a lot :-)

I have it figured out now.

I wasn't aware of the change around Raspberry Pi's FDT's needing to
be on the boot partition for start4.elf.

All of our existing bootloader code depends on the FDT embedded
into u-boot.  (fdtcontroladdr, see below for our boot.scr)

Does u-boot "pick-up" the FDT from the Pi foundation's start4.elf and place it 
at fdtcontroladdr?


test -e mmc 0 uEnv.txt && fatload mmc 0 ${scriptaddr} uEnv.txt && env import -t 
${scriptaddr} ${filesize} \
fatload mmc 0 ${kernel_addr_r} haiku_loader.ub \
fatload mmc 0 ${ramdisk_addr_r} haiku_floppyboot.ub \
env exists dtb && fatload mmc 0 ${fdt_addr_r} ${dtb} && fdt 
addr ${fdt_addr_r} && bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} \
fdt addr ${fdtcontroladdr} && bootm ${kernel_addr_r} 
${ramdisk_addr_r} ${fdtcontroladdr}"


I thought the FDT embedded into u-boot was the "best way" to get it :-|

 -- Alex


Re: u-boot 32-bit on Raspberry Pi 4

2020-01-17 Thread Jaehoon Chung
On 1/18/20 10:53 AM, Jaehoon Chung wrote:
> Hi
> 
> On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:
>> Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?
> 
> I'm using 32-bit u-boot on RPI4 board with Tizen Platform.
> You can refer to tizen u-boot git. Also I modified some configurations. 
> 
> https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-40c2c54dba31c6f3=https://git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen

Oops.
https://git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen


> 
> So you may modify some configs about your environment.
> 
> 
>>
>> Building via the following:
>>
>> make rpi_4_32b_defconfig
>> ARCH=arm CROSS_COMPILE=arm-none-eabi- make
>>
>> Booting via:
>>
>>  * u-boot.bin on Fat32 partition
>>  * start.elf from 
>>  * config.txt on Fat32 partition
>>kernel=u-boot.bin
>>enable_uart=1
>>arm_64bit=0
>>
> 
> Our config.txt is below,
> 
> enable_uart=1
> uart_2ndstage=1
> 
> I didn't add "arm_64bit" config.
> 
> Best Regards,
> Jaehoon Chung
> 
>> Just a black screen, however, no serial uart output
>>
>> Thanks!
>>
>>  -- Alex
>>
>>
> 
> 
> 



Re: [PATCH 0/3] Fix Odroid U3/X2 SD-card boot

2020-01-17 Thread Jaehoon Chung
Hi Marek,

On 1/17/20 12:25 AM, Marek Szyprowski wrote:
> Hi All
> 
> This patchset restores booting from SD-card on Exynos4412-based Odroid
> U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and
> PMIC device name fixes:
> https://patchwork.ozlabs.org/patch/1223558/
> https://patchwork.ozlabs.org/patch/1224228/

Thanks for patches. I will check this patch-set.

Best Regard,
Jaehoon Chung

> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> Patch summary:
> 
> Marek Szyprowski (3):
>   mmc: s5p_sdhci: Read generic MMC properties from DT
>   arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
>   arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
> 
>  arch/arm/dts/exynos4412-odroid.dts | 3 ++-
>  drivers/mmc/s5p_sdhci.c| 5 +
>  include/configs/odroid.h   | 2 +-
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 



Re: u-boot 32-bit on Raspberry Pi 4

2020-01-17 Thread Jaehoon Chung
Hi

On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:
> Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?

I'm using 32-bit u-boot on RPI4 board with Tizen Platform.
You can refer to tizen u-boot git. Also I modified some configurations. 

https://git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen

So you may modify some configs about your environment.


> 
> Building via the following:
> 
> make rpi_4_32b_defconfig
> ARCH=arm CROSS_COMPILE=arm-none-eabi- make
> 
> Booting via:
> 
>  * u-boot.bin on Fat32 partition
>  * start.elf from 
>  * config.txt on Fat32 partition
>kernel=u-boot.bin
>enable_uart=1
>arm_64bit=0
> 

Our config.txt is below,

enable_uart=1
uart_2ndstage=1

I didn't add "arm_64bit" config.

Best Regards,
Jaehoon Chung

> Just a black screen, however, no serial uart output
> 
> Thanks!
> 
>  -- Alex
> 
> 



u-boot 32-bit on Raspberry Pi 4

2020-01-17 Thread Alexander von Gluck IV
Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?

Building via the following:

make rpi_4_32b_defconfig
ARCH=arm CROSS_COMPILE=arm-none-eabi- make

Booting via:

 * u-boot.bin on Fat32 partition
 * start.elf from 
 * config.txt on Fat32 partition
   kernel=u-boot.bin
   enable_uart=1
   arm_64bit=0

Just a black screen, however, no serial uart output

Thanks!

 -- Alex


Re: [RFC WIP PATCH v1 6/7] wandboard: add u-boot specific *wandboard-revd1-u-boot.dtsi

2020-01-17 Thread Fabio Estevam
Hi Heiko,

On Thu, Jan 16, 2020 at 3:18 AM Heiko Schocher  wrote:

> Ah, ok, I can add it ... wait for your testing results.

I haven't had a chance to test this series, sorry, but after thinking
more about it I would prefer to test an improved version of this
series because:

1. is_revd1() needs to be done in SPL (if we manage to fix this, it
seems we would not need some of the patches of this current series)

2. This series still causes issues on your board: "On hardreset, the
PMIC does not respond
on i2c bus"

Thanks


[PATCH] rockchip: make the global board_fit_config_name_match __weak

2020-01-17 Thread Heiko Stuebner
From: Heiko Stuebner 

The core Rockchip spl code contains a default board_fit_config_name_match
implementation doing nothing. Individual boards may want to handle this
differently, so add a __weak atribute to make it possible to override
this function in other places.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-rockchip/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 1c091295b4..7339a789fd 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -143,7 +143,7 @@ void board_init_f(ulong dummy)
 }
 
 #ifdef CONFIG_SPL_LOAD_FIT
-int board_fit_config_name_match(const char *name)
+int __weak board_fit_config_name_match(const char *name)
 {
/* Just empty function now - can't decide what to choose */
debug("%s: %s\n", __func__, name);
-- 
2.24.1



[PATCH] rockchip: make_fit_atf: use correct fdt_x references in config nodes

2020-01-17 Thread Heiko Stuebner
From: Heiko Stuebner 

The script iterates over the given devicetrees and creates both
fdt_x node as well as a conf-node for each passed dt.

But there is a slight bug in that it always references fdt_1 in each
conf node instead of the matching fdt_x as expected.

So fix that by referencing the number of the current dt similar to
how the fdt_x nodes gets created.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-rockchip/make_fit_atf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
b/arch/arm/mach-rockchip/make_fit_atf.py
index 3c045a5e17..aaec2cd270 100755
--- a/arch/arm/mach-rockchip/make_fit_atf.py
+++ b/arch/arm/mach-rockchip/make_fit_atf.py
@@ -107,7 +107,7 @@ def append_conf_section(file, cnt, dtname, segments):
 file.write(';\n')
 if segments <= 1:
 file.write(';\n')
-file.write('\t\t\tfdt = "fdt_1";\n')
+file.write('\t\t\tfdt = "fdt_%d";\n' % cnt)
 file.write('\t\t};\n')
 file.write('\n')
 
-- 
2.24.1



[PATCH v4 1/2] Kconfig: add btrfs to distro boot

2020-01-17 Thread matthias . bgg
From: Matthias Brugger 

Some distributions use btrfs as the default file system.
Enable btrfs support by default when using distro boot for all
architectures but riscv, as it breaks compilation due to size problems.

Signed-off-by: Matthias Brugger 

---

Changes in v4:
- do not build for MIPS either

Changes in v3:
- use imply instead of select

Changes in v2:
- disable default btrfs support riscv

 Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Kconfig b/Kconfig
index d9be0daf23..f96f785c55 100644
--- a/Kconfig
+++ b/Kconfig
@@ -93,6 +93,7 @@ config DISTRO_DEFAULTS
select HUSH_PARSER
select SUPPORT_RAW_INITRD
select SYS_LONGHELP
+   imply CMD_BTRFS if !RISCV && !MIPS
imply CMD_MII if NET
imply USB_STORAGE
imply USE_BOOTCOMMAND
-- 
2.24.0



[PATCH v4 2/2] configs: Re-sync with CONFIG_DISTRO_DEFAULTS

2020-01-17 Thread matthias . bgg
From: Matthias Brugger 

CONFIG_DISTRO_DEFAULTS now enables CMD_BTRFS by default,
we can delete the config option in the corresponding default
configs. Other boards won't build with btrfs enabled so disable
the support by default.

Signed-off-by: Matthias Brugger 

---

Changes in v4:
- disable for some boards

Changes in v3: None
Changes in v2: None

 configs/am335x_evm_defconfig  | 2 ++
 configs/sandbox64_defconfig   | 1 -
 configs/sandbox_defconfig | 1 -
 configs/socfpga_arria10_defconfig | 2 ++
 configs/turris_mox_defconfig  | 1 -
 configs/turris_omnia_defconfig| 1 -
 6 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 335aa8cfa1..bae0571ed7 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -80,3 +80,5 @@ CONFIG_DYNAMIC_CRC_TABLE=y
 CONFIG_RSA=y
 CONFIG_LZO=y
 # CONFIG_OF_LIBFDT_OVERLAY is not set
+# CONFIG_CMD_BTRFS is not set
+# CONFIG_FS_BTRFS is not set
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 64d1d3102f..0826c06aa9 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -63,7 +63,6 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_AES=y
 CONFIG_CMD_TPM=y
 CONFIG_CMD_TPM_TEST=y
-CONFIG_CMD_BTRFS=y
 CONFIG_CMD_CBFS=y
 CONFIG_CMD_CRAMFS=y
 CONFIG_CMD_EXT4_WRITE=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index d8d8645425..f2d5572f99 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -71,7 +71,6 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_AES=y
 CONFIG_CMD_TPM=y
 CONFIG_CMD_TPM_TEST=y
-CONFIG_CMD_BTRFS=y
 CONFIG_CMD_CBFS=y
 CONFIG_CMD_CRAMFS=y
 CONFIG_CMD_EXT4_WRITE=y
diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index b4826548eb..fa7a5681ec 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -50,3 +50,5 @@ CONFIG_TIMER=y
 CONFIG_SPL_TIMER=y
 CONFIG_DESIGNWARE_APB_TIMER=y
 # CONFIG_SPL_WDT is not set
+# CONFIG_CMD_BTRFS is not set
+# CONFIG_FS_BTRFS is not set
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index b88cc4b842..89a1c73957 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -32,7 +32,6 @@ CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_MVEBU_BUBT=y
-CONFIG_CMD_BTRFS=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_MAC_PARTITION=y
 CONFIG_OF_BOARD_FIXUP=y
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index b6cb9a5f9d..160f1de656 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -49,7 +49,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_AES=y
 CONFIG_CMD_HASH=y
-CONFIG_CMD_BTRFS=y
 # CONFIG_SPL_PARTITION_UUIDS is not set
 CONFIG_DEFAULT_DEVICE_TREE="armada-385-turris-omnia"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-- 
2.24.0



[PATCH] riscv: Try to get cpu frequency from device tree

2020-01-17 Thread Sean Anderson
Instead of always using the "clock-frequency" property to determine cpu
frequency, try using a clock in "clocks" if it exists.

Signed-off-by Sean Anderson 
---
This patch depends on .

 drivers/cpu/riscv_cpu.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 1e32bb5678..280c9de376 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -3,6 +3,7 @@
  * Copyright (C) 2018, Bin Meng 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -27,11 +28,24 @@ static int riscv_cpu_get_desc(struct udevice *dev, char 
*buf, int size)
 
 static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info)
 {
+   int err;
+   struct clk clk;
const char *mmu;
 
/* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
info->cpu_freq = 0;
-   dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
+
+   /* First try getting the frequency from the assigned clock */
+   err = clk_get_by_index(dev, 0, );
+   if (!err) {
+   err = clk_get_rate();
+   if (!IS_ERR_VALUE(err))
+   info->cpu_freq = err;
+   clk_free();
+   }
+
+   if (!info->cpu_freq)
+   dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
 
mmu = dev_read_string(dev, "mmu-type");
if (!mmu)
-- 
2.24.1



[PATCH] cmd: Add command to dump drivers and compatible strings

2020-01-17 Thread Sean Anderson
This adds a subcommand to dm to dump out what drivers are installed, and their
compatible strings. I have found this useful in ensuring that I have the correct
drivers compiled, and that I have put in the correct compatible strings.

Signed-off-by Sean Anderson 
---
 cmd/dm.c| 12 +++-
 drivers/core/dump.c | 19 +++
 include/dm/util.h   |  3 +++
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/cmd/dm.c b/cmd/dm.c
index 7b271db0bb..108707c298 100644
--- a/cmd/dm.c
+++ b/cmd/dm.c
@@ -40,10 +40,19 @@ static int do_dm_dump_devres(cmd_tbl_t *cmdtp, int flag, 
int argc,
return 0;
 }
 
+static int do_dm_dump_drivers(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   dm_dump_drivers();
+
+   return 0;
+}
+
 static cmd_tbl_t test_commands[] = {
U_BOOT_CMD_MKENT(tree, 0, 1, do_dm_dump_all, "", ""),
U_BOOT_CMD_MKENT(uclass, 1, 1, do_dm_dump_uclass, "", ""),
U_BOOT_CMD_MKENT(devres, 1, 1, do_dm_dump_devres, "", ""),
+   U_BOOT_CMD_MKENT(drivers, 1, 1, do_dm_dump_drivers, "", ""),
 };
 
 static __maybe_unused void dm_reloc(void)
@@ -84,5 +93,6 @@ U_BOOT_CMD(
"Driver model low level access",
"tree  Dump driver model tree ('*' = activated)\n"
"dm uclassDump list of instances for each uclass\n"
-   "dm devresDump list of device resources for each device"
+   "dm devresDump list of device resources for each device\n"
+   "dm drivers   Dump list of drivers and their compatible strings\n"
 );
diff --git a/drivers/core/dump.c b/drivers/core/dump.c
index 4704049aee..e73ebeabcc 100644
--- a/drivers/core/dump.c
+++ b/drivers/core/dump.c
@@ -96,3 +96,22 @@ void dm_dump_uclass(void)
puts("\n");
}
 }
+
+void dm_dump_drivers(void)
+{
+   struct driver *d = ll_entry_start(struct driver, driver);
+   const int n_ents = ll_entry_count(struct driver, driver);
+   struct driver *entry;
+   const struct udevice_id *match;
+
+   puts("DriverCompatible\n");
+   puts("\n");
+   for (entry = d; entry < d + n_ents; entry++) {
+   for (match = entry->of_match; match->compatible; match++)
+   printf("%-20.20s  %s\n",
+  match == entry->of_match ? entry->name : "",
+  match->compatible);
+   if (match == entry->of_match)
+   printf("%-20.20s\n", entry->name);
+   }
+}
diff --git a/include/dm/util.h b/include/dm/util.h
index 348c2ace3c..0ccb3fbadf 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -39,6 +39,9 @@ static inline void dm_dump_devres(void)
 }
 #endif
 
+/* Dump out a list of drivers */
+void dm_dump_drivers(void);
+
 /**
  * Check if an of node should be or was bound before relocation.
  *
-- 
2.24.1



[PATCH] mx7ulp: Only enable LDO if it is not already enabled

2020-01-17 Thread Fabio Estevam
LDO mode may be already enabled by the ROM and enabling it again
can cause U-Boot to hang.

Avoid this problem by only enabling LDO mode if it is initially disabled.

Reported-by: Jorge Ramirez-Ortiz 
Signed-off-by: Fabio Estevam 
---
 arch/arm/mach-imx/mx7ulp/soc.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 8345b01398..4d84193dec 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -117,11 +117,28 @@ void init_wdog(void)
disable_wdog(WDG2_RBASE);
 }
 
+#define PMC0_BASE_ADDR 0x410a1000
+#define PMC0_CTRL  0x28
+#define PMC0_CTRL_LDOENBIT(31)
+
+static bool ldo_mode_is_enabled(void)
+{
+   unsigned int reg;
+
+   reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
+   if (reg & PMC0_CTRL_LDOEN)
+   return true;
+   else
+   return false;
+}
 #if defined(CONFIG_LDO_ENABLED_MODE)
 static void init_ldo_mode(void)
 {
unsigned int reg;
 
+   if (ldo_mode_is_enabled())
+   return;
+
/* Set LDOOKDIS */
setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
 
@@ -190,21 +207,6 @@ const char *get_imx_type(u32 imxtype)
return "7ULP";
 }
 
-#define PMC0_BASE_ADDR 0x410a1000
-#define PMC0_CTRL  0x28
-#define PMC0_CTRL_LDOENBIT(31)
-
-static bool ldo_mode_is_enabled(void)
-{
-   unsigned int reg;
-
-   reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
-   if (reg & PMC0_CTRL_LDOEN)
-   return true;
-   else
-   return false;
-}
-
 int print_cpuinfo(void)
 {
u32 cpurev;
-- 
2.17.1



Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Jorge Ramirez-Ortiz, Gmail
On 17/01/20 15:53:28, Fabio Estevam wrote:
> On Fri, Jan 17, 2020 at 3:40 PM Jorge Ramirez-Ortiz, Gmail
>  wrote:
> 
> > thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
> > Is that the same as yours?
> 
> On the Embedded Artists board there is a 08SC i.MX7ULP version.
> 
> On the i.MX7ULP EVK that I have access to there is a 05SC.
> 
> On the 08SC part I do see that it comes with LDOEN turned on by default.
> 
> On the 05SC part it comes with LDOEN turned off by default.
> 
> I wondering if we should go ahead with this fix:
> http://code.bulix.org/5gfb8t-1094747

yes I think so.

> 
> In case LDO is already enabled, then we use the LDO settings that were
> configured by the ROM.

yeah sounds good to me. I triple check in case the M4 was setting the
LDO (who knows) but is not being done by my firmware. So it must be
the ROM

> 
> Does this fix the hang problem?

yes


Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Fabio Estevam
On Fri, Jan 17, 2020 at 3:40 PM Jorge Ramirez-Ortiz, Gmail
 wrote:

> thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
> Is that the same as yours?

On the Embedded Artists board there is a 08SC i.MX7ULP version.

On the i.MX7ULP EVK that I have access to there is a 05SC.

On the 08SC part I do see that it comes with LDOEN turned on by default.

On the 05SC part it comes with LDOEN turned off by default.

I wondering if we should go ahead with this fix:
http://code.bulix.org/5gfb8t-1094747

In case LDO is already enabled, then we use the LDO settings that were
configured by the ROM.

Does this fix the hang problem?


Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Jorge Ramirez-Ortiz, Gmail
On 17/01/20 14:18:55, Fabio Estevam wrote:
> On Fri, Jan 17, 2020 at 1:51 PM Jorge Ramirez-Ortiz, Gmail
>  wrote:
> 
> > btw was checking the TRM manual (Chapter 28, PMC - page 1172)
> >
> > [..]
> > PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation 
> > voltage levels
> > required by the system. Such operation voltage requirements can be found on 
> > i.MX 7ULP
> > Data Sheet. In this sense, no power transition should be performed before 
> > ensuring the
> > mentioned register fields are matching the required operation voltage 
> > levels expressed on
> > the data sheet.
> >
> > =>  0.95V in the ldt_init function, is it in the data sheet?
> > I just cant find that particular document
> 
> Yes, please take a look at 
> https://www.nxp.com/docs/en/data-sheet/IMX7ULPCEC.pdf
> 
> (Table 5 - Search for PMC1_STOP[LDOVL] where it shows 0.95V as the
> typical value)

thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
Is that the same as yours?

wondering if something is different for this part...


Re: [PATCH 2/2] u-boot: fit: add support to decrypt fit with aes

2020-01-17 Thread Tom Rini
On Wed, Dec 18, 2019 at 06:25:42PM +0100, Philippe Reynes wrote:

> This commit add to u-boot the support to decrypt
> fit image encrypted with aes. The FIT image contains
> the key name and the IV name. Then u-boot look for
> the key and IV in his device tree and decrypt images
> before moving to the next stage.
> 
> Signed-off-by: Philippe Reynes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] mkimage: fit: add support to encrypt image with aes

2020-01-17 Thread Tom Rini
On Wed, Dec 18, 2019 at 06:25:41PM +0100, Philippe Reynes wrote:

> This commit add the support of encrypting image with aes
> in mkimage. To enable the ciphering, a node cipher with
> a reference to a key and IV (Initialization Vector) must
> be added to the its file. Then mkimage add the encrypted
> image to the FIT and add the key and IV to the u-boot
> device tree.
> 
> Signed-off-by: Philippe Reynes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V4 4/4] aes: add test unit for aes196 and aes256

2020-01-17 Thread Tom Rini
On Mon, Jan 06, 2020 at 03:22:37PM +0100, Philippe Reynes wrote:

> This commit add test unit for aes196 and aes256.
> 
> Signed-off-by: Philippe Reynes 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V4 1/4] aes: add a define for the size of a block

2020-01-17 Thread Tom Rini
On Mon, Jan 06, 2020 at 03:22:34PM +0100, Philippe Reynes wrote:

> In the code, we use the size of the key for the
> size of the block. It's true when the key is 128 bits,
> but it become false for key of 192 bits and 256 bits.
> So to prepare the support of aes192  and 256,
> we introduce a constant for the iaes block size.
> 
> Signed-off-by: Philippe Reynes 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V4 3/4] aes: add test unit for aes128

2020-01-17 Thread Tom Rini
On Mon, Jan 06, 2020 at 03:22:36PM +0100, Philippe Reynes wrote:

> This commit add test unit for aes128.
> 
> Signed-off-by: Philippe Reynes 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V4 2/4] aes: add support of aes192 and aes256

2020-01-17 Thread Tom Rini
On Mon, Jan 06, 2020 at 03:22:35PM +0100, Philippe Reynes wrote:

> Until now, we only support aes128. This commit add the support
> of aes192 and aes256.
> 
> Signed-off-by: Philippe Reynes 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] gitlab/azure: Update to latest container tag

2020-01-17 Thread Tom Rini
- Based on bionic-20200112 tag from Ubuntu
- Add graphviz (Heinrich)

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 2 +-
 .gitlab-ci.yml   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 3b7744ce3c38..916ab84ea0c4 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -1,7 +1,7 @@
 variables:
   windows_vm: vs2015-win2012r2
   ubuntu_vm: ubuntu-18.04
-  ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20191202-10Jan2020
+  ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200112-17Jan2020
   # Add '-u 0' options for Azure pipelines, otherwise we get "permission
   # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
   # since our $(ci_runner_image) user is not root.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d799cc30a8b9..c7ca5967dd49 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,7 +2,7 @@
 
 # Grab our configured image.  The source for this is found at:
 # https://gitlab.denx.de/u-boot/gitlab-ci-runner
-image: trini/u-boot-gitlab-ci-runner:bionic-20191202-10Jan2020
+image: trini/u-boot-gitlab-ci-runner:bionic-20200112-17Jan2020
 
 # We run some tests in different order, to catch some failures quicker.
 stages:
-- 
2.17.1



Re: Double free vulnerability in do_rename_gpt_parts

2020-01-17 Thread Jordy
Hey Tom,

The patch looks good to me, I do agree with simon that you'd have to initialize 
the pointers to 0, because uninitialized pointers could contain garbage, unless 
it's a global variable (those are automagically initialized to 0).


Btw I really appreciate the fast and friendly responses, I've seen that 
different at other software packages thumbs-up for that!

Best Regards,

Jordy
> On January 17, 2020 11:31 AM Tom Rini  wrote:
> 
>  
> On Fri, Jan 17, 2020 at 04:29:52PM +0100, Simon Goldschmidt wrote:
> > + Some contributors of this file
> > 
> > On Fri, Jan 17, 2020 at 1:03 PM Jordy  wrote:
> > >
> > > Hello U-Boot lists!
> > >
> > > I think I found a double free bug in U-Boot, in /cmp/gpt.c in the 
> > > function do_rename_gpt_parts().
> > >
> > > On line 702 the partition_list is being free'd if ret is smaller than 0.
> > > If the return value is not -ENOMEM it will go to the out: label and free 
> > > the partition_list again.
> > 
> > Reading the code, I can confirm that. Funny enough, the code in question was
> > introduced by commit 18030d04 ("GPT: fix memory leaks identified by 
> > Coverity").
> > Although I think Coverity should have detected the resulting double-free...
> > 
> > However, I'm not sure of the fix: the code just continues for -ENOMEM and 
> > then
> > goes on using partitions_list at line 757...
> 
> So, Coverity later did complain about that change (but not immediately,
> funny enough).  I posted http://patchwork.ozlabs.org/patch/1192036/ and
> was hoping for a review on it as it's complex enough I'd like to avoid
> adding a 3rd round of issues there.  Thanks!
> 
> -- 
> Tom


Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Fabio Estevam
On Fri, Jan 17, 2020 at 1:51 PM Jorge Ramirez-Ortiz, Gmail
 wrote:

> btw was checking the TRM manual (Chapter 28, PMC - page 1172)
>
> [..]
> PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation voltage 
> levels
> required by the system. Such operation voltage requirements can be found on 
> i.MX 7ULP
> Data Sheet. In this sense, no power transition should be performed before 
> ensuring the
> mentioned register fields are matching the required operation voltage levels 
> expressed on
> the data sheet.
>
> =>  0.95V in the ldt_init function, is it in the data sheet?
> I just cant find that particular document

Yes, please take a look at https://www.nxp.com/docs/en/data-sheet/IMX7ULPCEC.pdf

(Table 5 - Search for PMC1_STOP[LDOVL] where it shows 0.95V as the
typical value)


Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Jorge Ramirez-Ortiz, Gmail
On 17/01/20 10:26:11, Fabio Estevam wrote:
> Hi Jorge,
> 
> On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
>  wrote:
> >
> > Hi Fabio,
> >
> > I am trying to enable LDO in an imx7ulp based board but somehow the
> > board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> > sequence).
> >
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
> >
> > I also noticed that if I dont execute the init_ldo_mode sequence and
> > just check for the LODEN bit [see snipet below], this is already set
> > which too seems strange.
> 
> On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
> set after POR too.
> 
> Should we do something like this to avoid re-initializing the PMC1?
> 
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,6 +122,9 @@ static void init_ldo_mode(void)
>  {
> unsigned int reg;
> 
> +   if (ldo_mode_is_enabled())
> +   return;
> +
> /* Set LDOOKDIS */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);

btw was checking the TRM manual (Chapter 28, PMC - page 1172)

[..]
PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation voltage 
levels
required by the system. Such operation voltage requirements can be found on 
i.MX 7ULP
Data Sheet. In this sense, no power transition should be performed before 
ensuring the
mentioned register fields are matching the required operation voltage levels 
expressed on
the data sheet.

=>  0.95V in the ldt_init function, is it in the data sheet?
I just cant find that particular document




Re: Double free vulnerability in do_rename_gpt_parts

2020-01-17 Thread Simon Goldschmidt

Am 17.01.2020 um 17:31 schrieb Tom Rini:

On Fri, Jan 17, 2020 at 04:29:52PM +0100, Simon Goldschmidt wrote:

+ Some contributors of this file

On Fri, Jan 17, 2020 at 1:03 PM Jordy  wrote:


Hello U-Boot lists!

I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function 
do_rename_gpt_parts().

On line 702 the partition_list is being free'd if ret is smaller than 0.
If the return value is not -ENOMEM it will go to the out: label and free the 
partition_list again.


Reading the code, I can confirm that. Funny enough, the code in question was
introduced by commit 18030d04 ("GPT: fix memory leaks identified by Coverity").
Although I think Coverity should have detected the resulting double-free...

However, I'm not sure of the fix: the code just continues for -ENOMEM and then
goes on using partitions_list at line 757...


So, Coverity later did complain about that change (but not immediately,
funny enough).  I posted http://patchwork.ozlabs.org/patch/1192036/ and
was hoping for a review on it as it's complex enough I'd like to avoid
adding a 3rd round of issues there.  Thanks!



Ah, yes. I've just responded there.

Regards,
Simon


Re: [U-Boot] [PATCH] cmd/gpt: Address error cases during gpt rename more correctly

2020-01-17 Thread Simon Goldschmidt

+ Jordy, who just found a bug here...

Am 08.11.2019 um 17:24 schrieb Tom Rini:

New analysis by the tool has shown that we have some cases where we
weren't handling the error exit condition correctly.  When we ran into
the ENOMEM case we wouldn't exit the function and thus incorrect things
could happen.  Rework the unwinding such that we don't need a helper
function now and free what we may have allocated.

Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity")
Reported-by: Coverity (CID: 275475, 275476)
Cc: Alison Chaiken 
Signed-off-by: Tom Rini 
---
  cmd/gpt.c | 35 ---
  1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 0c4349f4b249..2da8df60dca3 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -633,21 +633,6 @@ static int do_disk_guid(struct blk_desc *dev_desc, char * 
const namestr)
  }
  
  #ifdef CONFIG_CMD_GPT_RENAME

-/*
- * There are 3 malloc() calls in set_gpt_info() and there is no info about 
which
- * failed.
- */
-static void set_gpt_cleanup(char **str_disk_guid,
-   disk_partition_t **partitions)
-{
-#ifdef CONFIG_RANDOM_UUID
-   if (str_disk_guid)
-   free(str_disk_guid);
-#endif
-   if (partitions)
-   free(partitions);
-}
-
  static int do_rename_gpt_parts(struct blk_desc *dev_desc, char *subcomm,
   char *name1, char *name2)
  {
@@ -699,11 +684,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
   _partitions, _count);
if (ret < 0) {
del_gpt_info();
-   free(partitions_list);
-   if (ret == -ENOMEM)
-   set_gpt_cleanup(_disk_guid, _partitions);
-   else
-   goto out;
+   goto out;
}
  
  	if (!strcmp(subcomm, "swap")) {

@@ -768,11 +749,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
 */
if (ret < 0) {
del_gpt_info();
-   free(partitions_list);
-   if (ret == -ENOMEM)
-   set_gpt_cleanup(_disk_guid, _partitions);
-   else
-   goto out;
+   goto out;
}
  
  	debug("Writing new partition table\n");

@@ -797,8 +774,12 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
print_gpt_info();
del_gpt_info();
   out:
-   free(new_partitions);
-   free(str_disk_guid);
+#ifdef CONFIG_RANDOM_UUID
+   if (str_disk_guid)


Looks good overall, but could it be required to initialize str_disk_guid 
and new_partitions to 0 to make this test here work? Because 
set_gpt_info does not always seem to set these pointers in the error 
case, so they could be left uninitialized?


Regards,
Simon


+   free(str_disk_guid);
+#endif
+   if (new_partitions)
+   free(new_partitions);
free(partitions_list);
return ret;
  }





RE: [PATCH 5/5] ARM: dts: stm32: Add DH Electronics DHCOM SoM and PDK2 board

2020-01-17 Thread Patrick DELAUNAY
Hi Marek,

> From: Patrick DELAUNAY
> Sent: lundi 13 janvier 2020 15:05
> 
> Hi Marek,
> 
> > From: Marek Vasut 
> > Sent: vendredi 10 janvier 2020 01:29
> >
> > Add support for DH Electronics DHCOM SoM and PDK2 rev. 400 carrier board.
> > This is an SoM with STM32MP157C and an evaluation kit. The baseboard
> > provides Ethernet, UART, USB, CAN and optional display.
> > Signed-off-by: Marek Vasut 
> > Cc: Patrick Delaunay 
> > Cc: Patrice Chotard 
> > ---

For information, I merge the serie, except this patch 5/5 on master brach and I 
sent a pull request for u-boot-stm32-20200117.

For this patch, I propose a rebase and also many modification liked to my 
previous remark
(I remove ST only parts for stboard command, and also led and key management) .

This proposal is present in the branch 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/tree/next

https://gitlab.denx.de/u-boot/custodians/u-boot-stm/commit/db48e11b1eccf23f3f9ba26e886a798e74df6a01

your initial patch is in applied 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/tree/dh


Can you test the "next" branch and check the difference with your initial patch 
( applied in dh branch
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/tree/dh 
=> 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/commit/0ab3ce72f82b946ac0924dfcdc082792f325eb68
 )

I hope that I don't remove something really present on the SOM.

If you are OK, can you send a V2 version with the "next" branch content and I 
will integrate it in master branch for next pull request.

Thanks, 

Patrick


> >  arch/arm/dts/Makefile |   1 +
> >  .../arm/dts/stm32mp157c-dhcom-pdk2-u-boot.dts |   7 +
> >  arch/arm/dts/stm32mp157c-dhcom-pdk2.dts   |  88 ++
> >  arch/arm/dts/stm32mp157c-dhcom-u-boot.dtsi| 238 ++
> >  arch/arm/dts/stm32mp157c-dhcom.dtsi   | 379 +
> >  arch/arm/mach-stm32mp/Kconfig |   1 +
> >  board/dhelectronics/dh_stm32mp1/Kconfig   |  25 +
> >  board/dhelectronics/dh_stm32mp1/MAINTAINERS   |   7 +
> >  board/dhelectronics/dh_stm32mp1/Makefile  |  12 +
> >  board/dhelectronics/dh_stm32mp1/board.c   | 777 ++
> >  configs/stm32mp15_dhcom_basic_defconfig   | 140 
> >  11 files changed, 1675 insertions(+)
> >  create mode 100644 arch/arm/dts/stm32mp157c-dhcom-pdk2-u-boot.dts
> >  create mode 100644 arch/arm/dts/stm32mp157c-dhcom-pdk2.dts
> >  create mode 100644 arch/arm/dts/stm32mp157c-dhcom-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/stm32mp157c-dhcom.dtsi
> >  create mode 100644 board/dhelectronics/dh_stm32mp1/Kconfig
> >  create mode 100644 board/dhelectronics/dh_stm32mp1/MAINTAINERS
> >  create mode 100644 board/dhelectronics/dh_stm32mp1/Makefile
> >  create mode 100644 board/dhelectronics/dh_stm32mp1/board.c
> >  create mode 100644 configs/stm32mp15_dhcom_basic_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> > 983e235f44..82489bc09c 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -859,6 +859,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
> >  dtb-$(CONFIG_TARGET_STM32MP1) += \
> > stm32mp157a-dk1.dtb \
> > stm32mp157a-avenger96.dtb \
> > +   stm32mp157c-dhcom-pdk2-u-boot.dtb \
> > stm32mp157c-dk2.dtb \
> > stm32mp157c-ed1.dtb \
> > stm32mp157c-ev1.dtb
> > diff --git a/arch/arm/dts/stm32mp157c-dhcom-pdk2-u-boot.dts
> > b/arch/arm/dts/stm32mp157c-dhcom-pdk2-u-boot.dts
> > new file mode 100644
> > index 00..fd99988570
> > --- /dev/null
> > +++ b/arch/arm/dts/stm32mp157c-dhcom-pdk2-u-boot.dts
> > @@ -0,0 +1,7 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> > +/*
> > + * Copyright (C) 2019 Marek Vasut   */
> > +
> > +#include "stm32mp157c-dhcom-pdk2.dts"
> > +#include "stm32mp157c-dhcom-u-boot.dtsi"
> > diff --git a/arch/arm/dts/stm32mp157c-dhcom-pdk2.dts
> > b/arch/arm/dts/stm32mp157c-dhcom-pdk2.dts
> > new file mode 100644
> > index 00..05aa545f55
> > --- /dev/null
> > +++ b/arch/arm/dts/stm32mp157c-dhcom-pdk2.dts
> > @@ -0,0 +1,88 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> > +/*
> > + * Copyright (C) 2019 Marek Vasut   */
> > +
> > +#include "stm32mp157c-dhcom.dtsi"
> > +
> > +/ {
> > +   model = "STMicroelectronics STM32MP157C DHCOM Premium
> > Developer Kit (2)";
> > +   compatible = "dh,stm32mp157c-dhcom-pdk2", "st,stm32mp157";
> > +
> > +   aliases {
> &

Re: Double free vulnerability in do_rename_gpt_parts

2020-01-17 Thread Tom Rini
On Fri, Jan 17, 2020 at 04:29:52PM +0100, Simon Goldschmidt wrote:
> + Some contributors of this file
> 
> On Fri, Jan 17, 2020 at 1:03 PM Jordy  wrote:
> >
> > Hello U-Boot lists!
> >
> > I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function 
> > do_rename_gpt_parts().
> >
> > On line 702 the partition_list is being free'd if ret is smaller than 0.
> > If the return value is not -ENOMEM it will go to the out: label and free 
> > the partition_list again.
> 
> Reading the code, I can confirm that. Funny enough, the code in question was
> introduced by commit 18030d04 ("GPT: fix memory leaks identified by 
> Coverity").
> Although I think Coverity should have detected the resulting double-free...
> 
> However, I'm not sure of the fix: the code just continues for -ENOMEM and then
> goes on using partitions_list at line 757...

So, Coverity later did complain about that change (but not immediately,
funny enough).  I posted http://patchwork.ozlabs.org/patch/1192036/ and
was hoping for a review on it as it's complex enough I'd like to avoid
adding a 3rd round of issues there.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] Dockerfile: add graphviz

2020-01-17 Thread Tom Rini
On Thu, Jan 16, 2020 at 08:51:09PM +0100, Heinrich Schuchardt wrote:

> In reStructured text documentation we somtimes find formatting problems.
> Therefore I would like to add 'make htmldocs' to our Gitlab Ci steps and
> let all warning result in a build failure.
> 
> For building the htmldocs target without warnings we need the Graphviz
> package.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to gitlab-ci-runner/master, thanks!

There's a new bionic tag so I'll be updating all of the images shortly
to contain this as well.

-- 
Tom


signature.asc
Description: PGP signature


RE: [PULL] Pull request: u-boot-stm32 u-boot-stm32-20200117

2020-01-17 Thread Patrick DELAUNAY
Hi Tom

Please pull the first STM32 related patches for v2020.04

Gitlab CI status:
 https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/1900

With the following fixes:
- stm32mp1: split SOC and board and cleanup config

It is a preliminary step for DH Electronics DHCOM SoM and PDK2 board

Thanks,
Patrick

git request-pull origin/master 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20200117
The following changes since commit d7bb6aceb2e99a832efbb96f9bf480bf95602192:

  Merge tag 'mmc-1-16-2020' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2020-01-16 13:20:51 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
tags/u-boot-stm32-20200117

for you to fetch changes up to db48e11b1eccf23f3f9ba26e886a798e74df6a01:

  ARM: dts: stm32: Add missing ETHCK clock to ethernet node (2020-01-17 
16:26:42 +0100)


- stm32mp1: split SOC and board and cleanup config


Marek Vasut (4):
  ARM: stm32: Allow overriding setup_mac_address()
  stm32mp1: configs: Make all boot devices in distro boot conditional
  ARM: stm32: Fill in missing loadaddr
  ARM: dts: stm32: Add missing ETHCK clock to ethernet node

Patrick Delaunay (3):
  stm32mp1: move stboard command in board/st/common directory
  board: stm32mp1: move CONFIG_ENV_XXX in defconfig
  stm32mp1: split board and SOC support for STM32MP15x family

Thomas Hebb (1):
  stm32mp: remove redundant SYS_TEXT_BASE prompt

 arch/arm/dts/Makefile  |  2 +-
 arch/arm/dts/stm32mp157c.dtsi  |  2 ++
 arch/arm/mach-stm32mp/Kconfig  | 37 
-
 arch/arm/mach-stm32mp/cpu.c|  2 +-
 arch/arm/mach-stm32mp/include/mach/sys_proto.h |  2 ++
 board/st/common/Kconfig|  7 +++
 board/st/common/MAINTAINERS|  6 ++
 board/st/common/Makefile   |  6 ++
 board/st/{stm32mp1 => common}/cmd_stboard.c|  3 +++
 board/st/stm32mp1/Kconfig  | 20 ++--
 board/st/stm32mp1/Makefile |  1 -
 board/st/stm32mp1/stm32mp1.c   |  2 +-
 configs/stm32mp15_basic_defconfig  |  4 +++-
 configs/stm32mp15_optee_defconfig  |  4 +++-
 configs/stm32mp15_trusted_defconfig|  4 +++-
 include/configs/stm32mp1.h | 39 
+++
 16 files changed, 95 insertions(+), 46 deletions(-)
 create mode 100644 board/st/common/Kconfig
 create mode 100644 board/st/common/MAINTAINERS
 create mode 100644 board/st/common/Makefile
 rename board/st/{stm32mp1 => common}/cmd_stboard.c (98%)


Re: [PATCH v2 2/2] spi: cadence-qspi: Add direct mode support

2020-01-17 Thread Simon Goldschmidt
On Fri, Jan 17, 2020 at 2:20 PM Simon Goldschmidt
 wrote:
>
> On Fri, Jan 17, 2020 at 2:01 PM Vignesh Raghavendra  wrote:
> >
> >
> >
> > On 17/01/20 6:21 pm, Simon Goldschmidt wrote:
> > > On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  
> > > wrote:
> > >>
> > >> Add support for Direct Access Controller mode of Cadence QSPI. This
> > >> allows MMIO access to SPI NOR flash providing better read performance.
> > >> Direct mode is only exercised if AHB window size is greater than 8MB.
> > >> Support for flash address remapping is also not supported at the moment
> > >> and can be added in future.
> > >>
> > >> For better performance, driver uses DMA to copy data from flash in
> > >> direct mode using dma_memcpy().
> > >
> > > This v2 doesn't compile for socfpa as dma_memcpy() isn't available. Since 
> > > direct
> > > mode isn't used on that platform (due to your 8MB check), dma_memcpy() is 
> > > not
> > > required, but still it doesn't link as this is a runtime decision.
> > >
> >
> > Could you try with latest master and make sure it has [1] and [2]
> > applied? Thanks!
> >
> > [1]http://patchwork.ozlabs.org/patch/1195557/
> > [2]http://patchwork.ozlabs.org/patch/1195556/
>
> Right, Tom merged that yesterday. Compiles now, sorry for the noise.

Tested on socfpga_gen5 (due to the platform layout, this test only says
it still works in indirect mode - direct mode is not activated on socfgpa):

Tested-by: Simon Goldschmidt 

>
> Regards,
> Simon
>
> >
> > Regards
> > Vignesh
> >
> > > Regards,
> > > Simon
> > >
> > >>
> > >> Signed-off-by: Vignesh Raghavendra 
> > >> ---
> > >> v2: Add DMA support and update commit message
> > >>
> > >>  drivers/spi/cadence_qspi.c | 40 -
> > >>  drivers/spi/cadence_qspi.h | 19 +-
> > >>  drivers/spi/cadence_qspi_apb.c | 65 +-
> > >>  3 files changed, 91 insertions(+), 33 deletions(-)
> > >>
> > >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > >> index 673a2e9a6c4c..6c98cbf39ae4 100644
> > >> --- a/drivers/spi/cadence_qspi.c
> > >> +++ b/drivers/spi/cadence_qspi.c
> > >> @@ -12,12 +12,13 @@
> > >>  #include 
> > >>  #include 
> > >>  #include 
> > >> +#include 
> > >>  #include "cadence_qspi.h"
> > >>
> > >>  #define CQSPI_STIG_READ0
> > >>  #define CQSPI_STIG_WRITE   1
> > >> -#define CQSPI_INDIRECT_READ2
> > >> -#define CQSPI_INDIRECT_WRITE   3
> > >> +#define CQSPI_READ 2
> > >> +#define CQSPI_WRITE3
> > >>
> > >>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
> > >>  {
> > >> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
> > >>
> > >>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> > >>  {
> > >> +   struct cadence_spi_platdata *plat = bus->platdata;
> > >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> > >>
> > >> /* Disable QSPI */
> > >> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice 
> > >> *bus, uint mode)
> > >> /* Set SPI mode */
> > >> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
> > >>
> > >> +   /* Enable Direct Access Controller */
> > >> +   if (plat->use_dac_mode)
> > >> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> > >> +
> > >> /* Enable QSPI */
> > >> cadence_qspi_apb_controller_enable(priv->regbase);
> > >>
> > >> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct 
> > >> spi_slave *spi,
> > >> if (!op->addr.nbytes)
> > >> mode = CQSPI_STIG_READ;
> > >> else
> > >> -   mode = CQSPI_INDIRECT_READ;
> > >> +   mode = CQSPI_READ;
> > >> } else {
> > >> if (!op->addr.nbytes || !op->data.buf.out)
> > >> mode = CQSPI_STIG_WRITE;
> > >> else
> > >> -   mode = CQSPI_INDIRECT_WRITE;
> > >> +   mode = CQSPI_WRITE;
> > >> }
> > >>
> > >> switch (mode) {
> > >> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct 
> > >> spi_slave *spi,
> > >> case CQSPI_STIG_WRITE:
> > >> err = cadence_qspi_apb_command_write(base, op);
> > >> break;
> > >> -   case CQSPI_INDIRECT_READ:
> > >> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
> > >> -   if (!err) {
> > >> -   err = cadence_qspi_apb_indirect_read_execute
> > >> -   (plat, op->data.nbytes, op->data.buf.in);
> > >> -   }
> > >> +   case CQSPI_READ:
> > >> +   err = cadence_qspi_apb_read_setup(plat, op);
> > >> +   if (!err)
> > >> +   err = cadence_qspi_apb_read_execute(plat, op);
> > >> break;
> > >> -   case 

Re: [PATCH v2 1/2] spi: cadence_qspi: Move to spi-mem framework

2020-01-17 Thread Simon Goldschmidt
On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  wrote:
>
> Current Cadence QSPI driver has few limitations. It assumes all read
> operations to be in Quad mode and thus does not support SFDP parsing.
> Also, adding support for new mode such as Octal mode would not be
> possible with current configuration. Therefore move the driver over to spi-mem
> framework. This has added advantage that driver can be used to support
> SPI NAND memories too.
> Hence, move driver over to new spi-mem APIs.
>
> Please note that this gets rid of mode bit setting done when
> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
> that config option.
>
> Signed-off-by: Vignesh Raghavendra 

Tested on socfpga_gen5:
Tested-by: Simon Goldschmidt 

> ---
> v2: No change
>
>  drivers/spi/cadence_qspi.c | 136 +
>  drivers/spi/cadence_qspi.h |   9 +--
>  drivers/spi/cadence_qspi_apb.c | 124 --
>  3 files changed, 91 insertions(+), 178 deletions(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index e2e54cd27723..673a2e9a6c4c 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "cadence_qspi.h"
>
> @@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice *bus, 
> uint hz)
> return 0;
>  }
>
> +static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
> +{
> +   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
> + SPI_MEM_OP_NO_ADDR,
> + SPI_MEM_OP_NO_DUMMY,
> + SPI_MEM_OP_DATA_IN(len, idcode, 1));
> +
> +   return cadence_qspi_apb_command_read(reg_base, );
> +}
> +
>  /* Calibration sequence to determine the read data capture delay register */
>  static int spi_calibration(struct udevice *bus, uint hz)
>  {
> struct cadence_spi_priv *priv = dev_get_priv(bus);
> void *base = priv->regbase;
> -   u8 opcode_rdid = 0x9F;
> unsigned int idcode = 0, temp = 0;
> int err = 0, i, range_lo = -1, range_hi = -1;
>
> @@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> cadence_qspi_apb_controller_enable(base);
>
> /* read the ID which will be our golden value */
> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> -   3, (u8 *));
> +   err = cadence_spi_read_id(base, 3, (u8 *));
> if (err) {
> puts("SF: Calibration failed (read)\n");
> return err;
> @@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> cadence_qspi_apb_controller_enable(base);
>
> /* issue a RDID to get the ID value */
> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> -   3, (u8 *));
> +   err = cadence_spi_read_id(base, 3, (u8 *));
> if (err) {
> puts("SF: Calibration failed (read)\n");
> return err;
> @@ -195,96 +203,56 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> uint mode)
> return 0;
>  }
>
> -static int cadence_spi_xfer(struct udevice *dev, unsigned int bitlen,
> -   const void *dout, void *din, unsigned long flags)
> +static int cadence_spi_mem_exec_op(struct spi_slave *spi,
> +  const struct spi_mem_op *op)
>  {
> -   struct udevice *bus = dev->parent;
> +   struct udevice *bus = spi->dev->parent;
> struct cadence_spi_platdata *plat = bus->platdata;
> struct cadence_spi_priv *priv = dev_get_priv(bus);
> -   struct dm_spi_slave_platdata *dm_plat = dev_get_parent_platdata(dev);
> void *base = priv->regbase;
> -   u8 *cmd_buf = priv->cmd_buf;
> -   size_t data_bytes;
> int err = 0;
> -   u32 mode = CQSPI_STIG_WRITE;
> -
> -   if (flags & SPI_XFER_BEGIN) {
> -   /* copy command to local buffer */
> -   priv->cmd_len = bitlen / 8;
> -   memcpy(cmd_buf, dout, priv->cmd_len);
> -   }
> -
> -   if (flags == (SPI_XFER_BEGIN | SPI_XFER_END)) {
> -   /* if start and end bit are set, the data bytes is 0. */
> -   data_bytes = 0;
> -   } else {
> -   data_bytes = bitlen / 8;
> -   }
> -   debug("%s: len=%zu [bytes]\n", __func__, data_bytes);
> +   u32 mode;
>
> /* Set Chip select */
> -   cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
> +   cadence_qspi_apb_chipselect(base, spi_chip_select(spi->dev),
> plat->is_decoded_cs);
>
> -   if ((flags & SPI_XFER_END) || (flags == 0)) {
> -   if (priv->cmd_len == 0) {
> -   printf("QSPI: Error, command is 

Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework

2020-01-17 Thread Simon Goldschmidt
On Thu, Oct 17, 2019 at 3:48 PM  wrote:
>
> Hi, Simon, Vignesh,
>
> On 10/17/2019 02:20 PM, Simon Goldschmidt wrote:
> > On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
> >> Current Cadence QSPI driver has few limitations. It assumes all read
> >> operations to be in Quad mode and thus does not support SFDP parsing.
> >> Also, adding support for new mode such as Octal mode would not be
> >> possible with current configuration. Therefore move the driver over to 
> >> spi-mem
> >> framework. This has added advantage that driver can be used to support
> >> SPI NAND memories too.
> >> Hence, move driver over to new spi-mem APIs.
> >>
> >> Please note that this gets rid of mode bit setting done when
> >> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
> >> that config option.
> > I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
> > it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
> > at 4 in my devicetree, SFDP parsing works, but reading data afterwards
> > produces invalid results (I haven't tested what's wrong there).
> >
> > It works as expected when not parsing SFDP or setting the bus-width to 1.
> > So the change itself probably works, but SFDP parsing is broken?
>
> This can happen if the quad enable method is not correctly set/called. Would 
> you
> try the patch form below?

I tried, but of course that didn't help. And I fail to see why it would, unless
you do something wrong in the flash device manufacturer selection.

Doing the patch like below would only make sense if enabling SFDP parsing would
at the same time completely remove the manufacturer selection (e.g. manufacturer
selection in Kconfig would depend on SFDP not being set).

Regards,
Simon

>
> I don't see much benefit in having those guards, especially that we have
> SPI_FLASH_SFDP_SUPPORT defined - it trims most of the SFDP logic.
>
> More, these #ifdef guards are not scalable and with the addition of flashes 
> that
> support SFDP the #ifdefs will look uglier and uglier.
>
> Cheers,
> ta
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index e5b9899c64b2..3002f97a7342 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -188,7 +188,6 @@ static int read_fsr(struct spi_nor *nor)
>   * location. Return the configuration register value.
>   * Returns negative if error occurred.
>   */
> -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
>  static int read_cr(struct spi_nor *nor)
>  {
> int ret;
> @@ -202,7 +201,6 @@ static int read_cr(struct spi_nor *nor)
>
> return val;
>  }
> -#endif
>
>  /*
>   * Write status register 1 byte
> @@ -591,7 +589,6 @@ erase_err:
> return ret;
>  }
>
> -#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
>  /* Write status register and ensure bits in mask match written values */
>  static int write_sr_and_check(struct spi_nor *nor, u8 status_new, u8 mask)
>  {
> @@ -877,7 +874,6 @@ static int stm_is_locked(struct spi_nor *nor, loff_t ofs,
> uint64_t len)
>
> return stm_is_locked_sr(nor, ofs, len, status);
>  }
> -#endif /* CONFIG_SPI_FLASH_STMICRO */
>
>  static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>  {
> @@ -1116,7 +1112,6 @@ write_err:
> return ret;
>  }
>
> -#ifdef CONFIG_SPI_FLASH_MACRONIX
>  /**
>   * macronix_quad_enable() - set QE bit in Status Register.
>   * @nor:   pointer to a 'struct spi_nor'
> @@ -1153,9 +1148,7 @@ static int macronix_quad_enable(struct spi_nor *nor)
>
> return 0;
>  }
> -#endif
>
> -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
>  /*
>   * Write status Register and configuration register with 2 bytes
>   * The first byte will be written to the status register, while the
> @@ -1269,7 +1262,6 @@ static int spansion_no_read_cr_quad_enable(struct 
> spi_nor
> *nor)
>  }
>
>  #endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */
> -#endif /* CONFIG_SPI_FLASH_SPANSION */
>
>  struct spi_nor_read_command {
> u8  num_mode_clocks;
> @@ -1787,22 +1779,16 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> case BFPT_DWORD15_QER_NONE:
> params->quad_enable = NULL;
> break;
> -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
> case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
> case BFPT_DWORD15_QER_SR2_BIT1_NO_RD:
> params->quad_enable = spansion_no_read_cr_quad_enable;
> break;
> -#endif
> -#ifdef CONFIG_SPI_FLASH_MACRONIX
> case BFPT_DWORD15_QER_SR1_BIT6:
> params->quad_enable = macronix_quad_enable;
> break;
> -#endif
> -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
> case BFPT_DWORD15_QER_SR2_BIT1:
> params->quad_enable = spansion_read_cr_quad_enable;
> 

Re: [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework

2020-01-17 Thread Simon Goldschmidt
On Thu, Oct 17, 2019 at 2:31 PM Vignesh Raghavendra  wrote:
>
> Hi Simon,
>
> On 17/10/19 4:50 PM, Simon Goldschmidt wrote:
> > On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
> >>
> >> Current Cadence QSPI driver has few limitations. It assumes all read
> >> operations to be in Quad mode and thus does not support SFDP parsing.
> >> Also, adding support for new mode such as Octal mode would not be
> >> possible with current configuration. Therefore move the driver over to 
> >> spi-mem
> >> framework. This has added advantage that driver can be used to support
> >> SPI NAND memories too.
> >> Hence, move driver over to new spi-mem APIs.
> >>
> >> Please note that this gets rid of mode bit setting done when
> >> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
> >> that config option.
> >
> > I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
> > it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
> > at 4 in my devicetree, SFDP parsing works, but reading data afterwards
> > produces invalid results (I haven't tested what's wrong there).
> >
>
> Thanks for testing!
>
> spi-tx-bus-width = 4 was not supported before so I haven't added support
> for that mode in this series. That change will be a separate series.
>
> Could you try with spi-tx-bus-width = 1 and spi-rx-bus-width = 4 and see
> if that works?

Yes, that works. So from my side, v2 of this patch is OK. I'll send my TB.

Regards,
Simon

>
> If that does not work then could you disable SFDP parsing (but keep
> spi-rx-bus-width = 4) and see if that works. This should narrow down
> whether SFDP parsing is broken or if driver has an issue.
>
> Regards
> Vignesh
>
> > It works as expected when not parsing SFDP or setting the bus-width to 1.
> > So the change itself probably works, but SFDP parsing is broken?
> >
> > I did the tests with this applied first:
> > https://patchwork.ozlabs.org/project/uboot/list/?series=135505
> >
> > Regards,
> > Simon
> >
> >
> >>
> >> Signed-off-by: Vignesh Raghavendra 
> >> ---
> >>  drivers/spi/cadence_qspi.c | 136 +
> >>  drivers/spi/cadence_qspi.h |   9 +--
> >>  drivers/spi/cadence_qspi_apb.c | 124 --
> >>  3 files changed, 91 insertions(+), 178 deletions(-)
> >>
> >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> >> index e2e54cd27723..673a2e9a6c4c 100644
> >> --- a/drivers/spi/cadence_qspi.c
> >> +++ b/drivers/spi/cadence_qspi.c
> >> @@ -10,6 +10,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include "cadence_qspi.h"
> >>
> >> @@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice 
> >> *bus, uint hz)
> >> return 0;
> >>  }
> >>
> >> +static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
> >> +{
> >> +   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
> >> + SPI_MEM_OP_NO_ADDR,
> >> + SPI_MEM_OP_NO_DUMMY,
> >> + SPI_MEM_OP_DATA_IN(len, idcode, 
> >> 1));
> >> +
> >> +   return cadence_qspi_apb_command_read(reg_base, );
> >> +}
> >> +
> >>  /* Calibration sequence to determine the read data capture delay register 
> >> */
> >>  static int spi_calibration(struct udevice *bus, uint hz)
> >>  {
> >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> >> void *base = priv->regbase;
> >> -   u8 opcode_rdid = 0x9F;
> >> unsigned int idcode = 0, temp = 0;
> >> int err = 0, i, range_lo = -1, range_hi = -1;
> >>
> >> @@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> >> cadence_qspi_apb_controller_enable(base);
> >>
> >> /* read the ID which will be our golden value */
> >> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> >> -   3, (u8 *));
> >> +   err = cadence_spi_read_id(base, 3, (u8 *));
> >> if (err) {
> >> puts("SF: Calibration failed (read)\n");
> >> return err;
> >> @@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> >> cadence_qspi_apb_controller_enable(base);
> >>
> >> /* issue a RDID to get the ID value */
> >> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> >> -   3, (u8 *));
> >> +   err = cadence_spi_read_id(base, 3, (u8 *));
> >> if (err) {
> >> puts("SF: Calibration failed (read)\n");
> >> return err;
> >> @@ -195,96 +203,56 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> >> uint mode)
> >> return 0;
> >>  }
> >>
> >> -static int cadence_spi_xfer(struct udevice *dev, unsigned int bitlen,
> >> -   const void *dout, void *din, unsigned long 
> >> flags)
> >> 

Re: Double free vulnerability in do_rename_gpt_parts

2020-01-17 Thread Simon Goldschmidt
+ Some contributors of this file

On Fri, Jan 17, 2020 at 1:03 PM Jordy  wrote:
>
> Hello U-Boot lists!
>
> I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function 
> do_rename_gpt_parts().
>
> On line 702 the partition_list is being free'd if ret is smaller than 0.
> If the return value is not -ENOMEM it will go to the out: label and free the 
> partition_list again.

Reading the code, I can confirm that. Funny enough, the code in question was
introduced by commit 18030d04 ("GPT: fix memory leaks identified by Coverity").
Although I think Coverity should have detected the resulting double-free...

However, I'm not sure of the fix: the code just continues for -ENOMEM and then
goes on using partitions_list at line 757...

Regards,
Simon

>
> Double freeing may result in a write-what-where condition, allowing an 
> attacker to execute arbitrary code.
>
> My advice would be to not free the parition_list on line 702 as nothing is 
> being done with it there afterwards anyway and leave your clean_up in the 
> out: label :)
>
> Kind Regards,
>
> Jordy Zomer


RE: [PATCH 4/5] ARM: dts: stm32: Add missing ETHCK clock to ethernet node

2020-01-17 Thread Patrick DELAUNAY
Hi Marek,

> From: Christophe ROULLIER 
> Sent: lundi 13 janvier 2020 17:15
> 
> 
> On 1/13/20 2:33 PM, Marek Vasut wrote:
> > On 1/13/20 2:26 PM, Patrick DELAUNAY wrote:
> >> Hi Marek,
> > Hi,
> >
> >> + Christophe (Maintainer in kernel)
> >>
> >>> From: Marek Vasut 
> >>> Sent: vendredi 10 janvier 2020 01:29
> >>>
> >>> Add missing 'eth-ck' clock to the ethernet node. These clock are
> >>> used to generate external clock signal for the PHY in case 
> >>> 'st,eth_ref_clk_sel'
> >>> is specified.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Patrick Delaunay 
> >>> Cc: Patrice Chotard 
> >>> ---
> >>>   arch/arm/dts/stm32mp157c.dtsi | 2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/arch/arm/dts/stm32mp157c.dtsi
> >>> b/arch/arm/dts/stm32mp157c.dtsi index
> >>> 6c670cf9a3..41aea75213 100644
> >>> --- a/arch/arm/dts/stm32mp157c.dtsi
> >>> +++ b/arch/arm/dts/stm32mp157c.dtsi
> >>> @@ -1404,11 +1404,13 @@
> >>>   clock-names = "stmmaceth",
> >>> "mac-clk-tx",
> >>> "mac-clk-rx",
> >>> +   "eth-ck",
> >>> "ethstp",
> >>> "syscfg-clk";
> >>>   clocks = < ETHMAC>,
> >>>< ETHTX>,
> >>>< ETHRX>,
> >>> +  < ETHCK_K>,
> >>>< ETHSTP>,
> >>>< SYSCFG>;
> >>>   st,syscon = < 0x4>;
> >> This clock is optional, not needed by default for STM32MP15x:
> >> this clock is used only for a specific case: Phy without quartz, for all 
> >> the other
> case we don't need to switch on this clock.
> > That's the usecase here.
> >
> >> Normally if it is the case, it should be done in board part, not in SOC 
> >> device
> tree (is is the strategy chosen by kernel).
> >> Moreover stm32mp157c.dtsi is just a copy of the kernel one, so this patch 
> >> also
> need to be accepted by Kernel Maintainers.
> >>
> >> NB: if you are in the Phy without crytal 50MHz (rmii + 
> >> "st,eth_ref_clk_sel" +
> "eth-ck"),
> >> You should have also the associated pin in the device tree of the 
> >> board :
> >>
> >> + , /* ETH_RMII_ETHCK */
> > My PHY is _NOT_ connected to this pin, the output clock of the SoC are PA1.
> >
> >> Christophe you can complete my answer if it is not enough clear.
> > I would expect that you should describe _all_ the clock which are
> > routed into the ethernet IP in the DT and if the driver doesn't need
> > some of those clock, the driver should just not enable such clock.
> 
> Hi Marek,
> 
> You are right, we will add by default all clocks used by stm32mp157, and 
> modify
> driver to decide if we need to enable it or not.
> 
> So ACK to add ETHCK_K in stm32mp157c.dtsi

Christophe: thanks for ACK,

Reviewed-by: Patrick Delaunay 

And I add the patch in U-Boot device tree by advance
(the only possible impact is to switch on a not used clock).

Applied to u-boot-stm32/master, thanks!

Regards
Patrick



RE: [PATCH 3/5] ARM: stm32: Fill in missing loadaddr

2020-01-17 Thread Patrick DELAUNAY
Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 15 janvier 2020 10:51
> 
> On 1/13/20 10:06 AM, Patrick DELAUNAY wrote:
> > Hi Marek,
> >
> >> From: Marek Vasut 
> >> Sent: vendredi 10 janvier 2020 01:29
> >>
> >> Since CONFIG_LOADADDR is not set, the default value of $loadaddr
> >> variable is not set in the environment either. Set the default load
> >> address to 256 MiB from the start of DRAM.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Patrick Delaunay 
> >> Cc: Patrice Chotard 
> >> ---
> >>  include/configs/stm32mp1.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> >> index
> >> 655833428e..b23dd38794 100644
> >> --- a/include/configs/stm32mp1.h
> >> +++ b/include/configs/stm32mp1.h
> >> @@ -36,6 +36,7 @@
> >>   * Needed by "loadb"
> >>   */
> >>  #define CONFIG_SYS_LOAD_ADDR
>   STM32_DDR_BASE
> >> +#define CONFIG_LOADADDR   0xd000
> >
> > A offset a 256 MiB is really huge...
> > And I don't sure that will fit all the commands (bootm with zImage as
> > it is xpecting to be placed in the first 128 MiB of RAM) and all the
> > products (with lower memory)
> >
> > I propose to have the same value for the 2 defines which define the
> > default loadaddr with 32MB offset (same value that kernel_addr_r).
> 
> That's OK.

I take the patch with thte proposed offset = 32MB.

/*
- * Needed by "loadb"
+ * default load address used for command tftp,  bootm , loadb, ...
  */
-#define CONFIG_SYS_LOAD_ADDR   STM32_DDR_BASE
+#define CONFIG_LOADADDR0xc200
+#define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR


Applied to u-boot-stm32/master, thanks!

Regards
Patrick


[PATCH] pinctrl: renesas: r8a7796: Fix PRESET# bias setting

2020-01-17 Thread Shunsuke Tokumoto
There's no bias setting for PRESET#. Therefore add entry to set PRESET#
bias.

Signed-off-by: Shunsuke Tokumoto 
Signed-off-by: Keiya Nobuta 
---
 drivers/pinctrl/renesas/pfc-r8a7796.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/renesas/pfc-r8a7796.c 
b/drivers/pinctrl/renesas/pfc-r8a7796.c
index a92c8ad18c..dbb57042a5 100644
--- a/drivers/pinctrl/renesas/pfc-r8a7796.c
+++ b/drivers/pinctrl/renesas/pfc-r8a7796.c
@@ -1570,6 +1570,7 @@ static const struct sh_pfc_pin pinmux_pins[] = {
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('P'),  8, DU_DOTCLKIN1, CFG_FLAGS),
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('R'),  8, DU_DOTCLKIN2, CFG_FLAGS),
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('R'), 26, TRST#, 
SH_PFC_PIN_CFG_PULL_UP | SH_PFC_PIN_CFG_PULL_DOWN),
+   SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('R'), 28, PRESET#, 
SH_PFC_PIN_CFG_PULL_DOWN),
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('R'), 29, TDI, SH_PFC_PIN_CFG_PULL_UP 
| SH_PFC_PIN_CFG_PULL_DOWN),
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('R'), 30, TMS, CFG_FLAGS),
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('T'), 27, TCK, SH_PFC_PIN_CFG_PULL_UP 
| SH_PFC_PIN_CFG_PULL_DOWN),
@@ -6077,7 +6078,7 @@ static const struct pinmux_bias_reg pinmux_bias_regs[] = {
[ 4] = RCAR_GP_PIN(6, 29),  /* USB30_OVC */
[ 5] = RCAR_GP_PIN(6, 30),  /* GP6_30 */
[ 6] = RCAR_GP_PIN(6, 31),  /* GP6_31 */
-   [ 7] = PIN_NONE,
+   [ 7] = PIN_A_NUMBER('R', 28),   /* PRESET# */
[ 8] = PIN_NONE,
[ 9] = PIN_NONE,
[10] = PIN_NONE,
-- 
2.24.1



RE: [PATCH 3/3] stm32mp1: split board and SOC support for STM32MP15x family

2020-01-17 Thread Patrick DELAUNAY
Hi,

> From: Patrick DELAUNAY 
> Sent: lundi 13 janvier 2020 15:18
> 
> Split the board and SOC support for STM32MP15x family and prepare the
> introduction of new boards with STM32MP15x.
> 
> This path define the 2 configurations:
> - STM32MP15x: STM32MP15x soc support (new)
> - TARGET_ST_STM32MP15x: STMicroelectronics board support (choice)
> 
> Signed-off-by: Patrick Delaunay 
> ---

Applied to u-boot-stm32/master, thanks!

Regards
Patrick


RE: [PATCH 2/3] board: stm32mp1: move CONFIG_ENV_XXX in defconfig

2020-01-17 Thread Patrick DELAUNAY
Hi,

> From: Patrick DELAUNAY 
> Sent: lundi 13 janvier 2020 15:18
> 
> Move CONFIG_ENV_SECT_SIZE and CONFIG_ENV_OFFSET in
> stm32mp15_*_defconfig for ST board with NOR support (STM32MP15xx-EV1
> boards)
> - CONFIG_SECT_SIZE values = the max supported NOR erase size (256KB)
> - CONFIG_ENV_OFFSET = offset for NOR (ENV_IS_IN_SPI_FLASH)
> 
> This Patch prepares the U-Boot support of boards with STM32MP15x SOC not
> provided by STMicroelectronics.
> 
> Signed-off-by: Patrick Delaunay 
> ---

Applied to u-boot-stm32/master, thanks!

Regards
Patrick


RE: [PATCH 1/3] stm32mp1: move stboard command in board/st/common directory

2020-01-17 Thread Patrick DELAUNAY
Hi,

> From: Patrick DELAUNAY 
> Sent: lundi 13 janvier 2020 15:18
> 
> Move the ST command in board/st/common, as this command is only used by ST
> board. Prepare the support in U-Boot of boards with STM32MP15x SOC but not
> STMicroelectronics.
> 
> Signed-off-by: Patrick Delaunay 
> ---

Applied to u-boot-stm32/master, thanks!

Regards
Patrick


Re: [U-Boot] [RFC PATCH] pxe: add support for FDT overlays

2020-01-17 Thread Andre Heider

Hi Neil,

On 07/05/2019 14:50, Neil Armstrong wrote:

This adds support for specicyinf FDT overlays in an extlinux/pxelinux
configuration file.

Without this, there is no simple way to apply overlays when the kernel
and ftd is loaded by the pxe command.

This change adds the 'fdtoverlays' keyword for a label, supporting multiple
overlay files to be applied on top of the fdt specific in the 'fdt' or
'devicetree' keyword.


Do you have a rebased version of this patch?

Thanks!
Andre


Re: [PATCH v2 19/21] mips: mtmips: add SPL support

2020-01-17 Thread Stefan Roese

On 17.01.20 14:15, Daniel Schwierzeck wrote:



Am 17.01.20 um 08:46 schrieb Weijie Gao:

This patch adds SPL support for mtmips platform. The lowlevel architecture
is split into SPL and the rest parts are built into a memory loadable
u-boot image. Optional SPL_DM and OF_CONTROL are also supported.

The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
not enabled and the memory bootable u-boot (u-boot.img) is generated
automatically so there is not need to add a separate config for it.

A lzma compressed payload (u-boot-lzma.img) is also generated and it will
be combined with u-boot-spl.bin to form the unified ROM bootable binary
u-boot-mtmips.bin.

A spl loader is added to support uncompress the payload.

Signed-off-by: Weijie Gao 
---
Changes since v1:
   move spl loader into this patch.
   add full pinmux for all three uarts.
   add optional DM & DT support.
---
  Makefile|   9 ++
  arch/mips/Kconfig   |   3 +
  arch/mips/dts/mt7628-u-boot.dtsi|  24 
  arch/mips/mach-mtmips/Kconfig   |  24 
  arch/mips/mach-mtmips/Makefile  |   1 +
  arch/mips/mach-mtmips/include/mach/serial.h |  13 +++
  arch/mips/mach-mtmips/include/mach/spl.h|  14 +++
  arch/mips/mach-mtmips/mt7628/Makefile   |   1 +
  arch/mips/mach-mtmips/mt7628/serial.c   |  34 ++
  arch/mips/mach-mtmips/spl.c |  31 +
  arch/mips/mach-mtmips/spl_load.c| 121 
  11 files changed, 275 insertions(+)
  create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
  create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
  create mode 100644 arch/mips/mach-mtmips/include/mach/spl.h
  create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
  create mode 100644 arch/mips/mach-mtmips/spl.c
  create mode 100644 arch/mips/mach-mtmips/spl_load.c

diff --git a/Makefile b/Makefile
index 8013cbd9f9..1e18a37913 100644
--- a/Makefile
+++ b/Makefile
@@ -895,6 +895,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
  endif
  
  ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin

+ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mtmips.bin
  
  # Add optional build target if defined in board/cpu/soc headers

  ifneq ($(CONFIG_BUILD_TARGET),)
@@ -1664,6 +1665,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
$(call if_changed,mkimage)
  endif
  
+ifeq ($(CONFIG_SPL),y)

+u-boot-mtmips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
+   $(call if_changed,binman)
+else
+u-boot-mtmips.bin: u-boot.bin FORCE
+   $(call if_changed,copy)
+endif
+
  ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
  
  # Rule to link u-boot

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5f82caf8be..5f74f549b5 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -98,6 +98,9 @@ config ARCH_MTMIPS
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
select SYSRESET
+   select SUPPORT_SPL
+   select SPL_LZMA
+   select BINMAN
  
  config ARCH_JZ47XX

bool "Support Ingenic JZ47xx"
diff --git a/arch/mips/dts/mt7628-u-boot.dtsi b/arch/mips/dts/mt7628-u-boot.dtsi
new file mode 100644
index 00..213959105f
--- /dev/null
+++ b/arch/mips/dts/mt7628-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao 
+ */
+
+/ {
+   binman {
+   filename = "u-boot-mtmips.bin";
+   pad-byte = <0xff>;
+
+#ifdef CONFIG_SPL
+   u-boot-spl {
+   };
+
+   u-boot-lzma-img {
+   };
+#else
+   u-boot {
+   };
+#endif
+   };
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 3f25de8b85..9b42d5b581 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -20,8 +20,16 @@ config SYS_ICACHE_LINE_SIZE
default 32
  
  config SYS_TEXT_BASE

+   default 0x9c00 if !SPL
+   default 0x8020 if SPL
+
+config SPL_TEXT_BASE
default 0x9c00
  
+config SPL_LOADER_SUPPORT

+   bool
+   default y
+


this option should be moved to arch/mips/Kconfig and should be added
with patch 15/21 because you use reference that option in the generic
MIPS u-boot-spl.lds


  choice
prompt "MediaTek MIPS SoC select"
  
@@ -34,6 +42,14 @@ config SOC_MT7628

select PINCTRL_MT7628
select MTK_SERIAL
select SYSRESET_RESETCTL
+   select SPL_SEPARATE_BSS if SPL
+   select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
+   select SPL_OF_CONTROL if SPL_DM
+   select SPL_SIMPLE_BUS if SPL_DM
+   select SPL_DM_SERIAL if SPL_DM
+   select SPL_CLK if SPL_DM && SPL_SERIAL_SUPPORT
+   select SPL_SYSRESET if SPL_DM
+   select SPL_OF_LIBFDT if SPL_OF_CONTROL
help
  This supports MediaTek MT7628/MT7688.
  
@@ -88,6 +104,14 @@ endchoice

  

Re: [PATCH v2 19/21] mips: mtmips: add SPL support

2020-01-17 Thread Stefan Roese

Added Mauro to Cc

On 17.01.20 08:46, Weijie Gao wrote:

This patch adds SPL support for mtmips platform. The lowlevel architecture
is split into SPL and the rest parts are built into a memory loadable
u-boot image. Optional SPL_DM and OF_CONTROL are also supported.

The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
not enabled and the memory bootable u-boot (u-boot.img) is generated
automatically so there is not need to add a separate config for it.

A lzma compressed payload (u-boot-lzma.img) is also generated and it will
be combined with u-boot-spl.bin to form the unified ROM bootable binary
u-boot-mtmips.bin.

A spl loader is added to support uncompress the payload.

Signed-off-by: Weijie Gao 
---
Changes since v1:
   move spl loader into this patch.
   add full pinmux for all three uarts.
   add optional DM & DT support.
---
  Makefile|   9 ++
  arch/mips/Kconfig   |   3 +
  arch/mips/dts/mt7628-u-boot.dtsi|  24 
  arch/mips/mach-mtmips/Kconfig   |  24 
  arch/mips/mach-mtmips/Makefile  |   1 +
  arch/mips/mach-mtmips/include/mach/serial.h |  13 +++
  arch/mips/mach-mtmips/include/mach/spl.h|  14 +++
  arch/mips/mach-mtmips/mt7628/Makefile   |   1 +
  arch/mips/mach-mtmips/mt7628/serial.c   |  34 ++
  arch/mips/mach-mtmips/spl.c |  31 +
  arch/mips/mach-mtmips/spl_load.c| 121 
  11 files changed, 275 insertions(+)
  create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
  create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
  create mode 100644 arch/mips/mach-mtmips/include/mach/spl.h
  create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
  create mode 100644 arch/mips/mach-mtmips/spl.c
  create mode 100644 arch/mips/mach-mtmips/spl_load.c

diff --git a/Makefile b/Makefile
index 8013cbd9f9..1e18a37913 100644
--- a/Makefile
+++ b/Makefile
@@ -895,6 +895,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
  endif
  
  ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin

+ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mtmips.bin
  
  # Add optional build target if defined in board/cpu/soc headers

  ifneq ($(CONFIG_BUILD_TARGET),)
@@ -1664,6 +1665,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
$(call if_changed,mkimage)
  endif
  
+ifeq ($(CONFIG_SPL),y)

+u-boot-mtmips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
+   $(call if_changed,binman)
+else
+u-boot-mtmips.bin: u-boot.bin FORCE
+   $(call if_changed,copy)
+endif
+
  ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
  
  # Rule to link u-boot

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5f82caf8be..5f74f549b5 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -98,6 +98,9 @@ config ARCH_MTMIPS
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
select SYSRESET
+   select SUPPORT_SPL
+   select SPL_LZMA
+   select BINMAN
  
  config ARCH_JZ47XX

bool "Support Ingenic JZ47xx"
diff --git a/arch/mips/dts/mt7628-u-boot.dtsi b/arch/mips/dts/mt7628-u-boot.dtsi
new file mode 100644
index 00..213959105f
--- /dev/null
+++ b/arch/mips/dts/mt7628-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao 
+ */
+
+/ {
+   binman {
+   filename = "u-boot-mtmips.bin";
+   pad-byte = <0xff>;
+
+#ifdef CONFIG_SPL
+   u-boot-spl {
+   };
+
+   u-boot-lzma-img {
+   };
+#else
+   u-boot {
+   };
+#endif
+   };
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 3f25de8b85..9b42d5b581 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -20,8 +20,16 @@ config SYS_ICACHE_LINE_SIZE
default 32
  
  config SYS_TEXT_BASE

+   default 0x9c00 if !SPL
+   default 0x8020 if SPL
+
+config SPL_TEXT_BASE
default 0x9c00
  
+config SPL_LOADER_SUPPORT

+   bool
+   default y
+
  choice
prompt "MediaTek MIPS SoC select"
  
@@ -34,6 +42,14 @@ config SOC_MT7628

select PINCTRL_MT7628
select MTK_SERIAL
select SYSRESET_RESETCTL
+   select SPL_SEPARATE_BSS if SPL
+   select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
+   select SPL_OF_CONTROL if SPL_DM
+   select SPL_SIMPLE_BUS if SPL_DM
+   select SPL_DM_SERIAL if SPL_DM
+   select SPL_CLK if SPL_DM && SPL_SERIAL_SUPPORT
+   select SPL_SYSRESET if SPL_DM
+   select SPL_OF_LIBFDT if SPL_OF_CONTROL
help
  This supports MediaTek MT7628/MT7688.
  
@@ -88,6 +104,14 @@ endchoice

  config SUPPORTS_BOOT_RAM
bool
  
+config SPL_UART2_SPIS_PINMUX

+   bool "Use alternative pinmux for UART2 in SPL stage"
+   depends on SPL_SERIAL_SUPPORT
+   default n
+   

Re: fat: handle Windows formatted partition (thru USB Mass Storage)

2020-01-17 Thread Tom Rini
On Fri, Jan 17, 2020 at 11:47:03AM +0200, Andy Shevchenko wrote:
> On Fri, Jan 17, 2020 at 8:13 AM AKASHI Takahiro
>  wrote:
> > On Thu, Jan 16, 2020 at 10:31:49PM +0200, Andy Shevchenko wrote:
> 
> ...
> 
> > > Prerequisites:
> > >  - the board with U-Boot and installed Linux OS on eMMC
> > >  - g_multi module in Linux OS that shares *one of the eMMC partitions*
> > > (pay attention here) as a disk to Windows host
> >
> > I also misunderstood your assumption above; You are developing
> > a linux-based USB gadget for Windows (10)?
> 
> No.
> 
> > > Now, when you format that exposed disk (which is actually a partition
> > > on eMMC!) in Windows, you will get nested partitioning.
> >
> > So why do you want to access *that* partition from U-Boot on the board?
> > I don't think it is a common case.
> 
> What I'm trying to do is to copy some bootables to that partition from
> Windows machine in order to boot them via U-Boot.
> That's allow me not to disturb stock image on that board.
> 
> If U-Boot is not going to support nested partitioning, perhaps I can
> submit a documentation fix to advertise this explicitly.

I'm confused here, sorry.  I thought one of the described examples was
how to have Windows use the whole device it was given, without partition
table, as FAT and thus it would be shareable.  Is that not possible?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 13/21] dts: mtmips: add alternative pinmux node for uart2

2020-01-17 Thread Stefan Roese

Added Mauro to Cc

On 17.01.20 08:46, Weijie Gao wrote:

This patch adds a new pinmux for UART2, which shares the pins with SPIS.

Signed-off-by: Weijie Gao 
---
Changes since v1: newly added
---
  arch/mips/dts/mt7628a.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 744594c45a..f265cb6ad9 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -93,6 +93,11 @@
function = "uart2";
};
  
+			uart2_pwm_pins: uart2_pwm_pins {

+   groups = "spis";
+   function = "pwm_uart2";
+   };
+


Thanks. AFAIK, this will not be used by any of the currently supported
boards. Is this correct?

Mauro is currently trying to port mainline U-Boot to the VoCore2 board
which also uses UART2. I did not look to close, but might this pin mux
option here be necessary for this VoCore2 board?

Thanks,
Stefan


Re: [PATCH v2 12/21] dts: mtmips: add u-boot, dm-pre-reloc for some nodes in mt7628a.dtsi

2020-01-17 Thread Stefan Roese

On 17.01.20 08:45, Weijie Gao wrote:

To enable DM support in SPL, some necessary nodes must be reserved for
serial, clk, sysreset and other drivers.

This patch adds u-boot,dm-pre-reloc for these nodes.

Signed-off-by: Weijie Gao 
---
Changes since v1: newly added
---
  arch/mips/dts/mt7628a.dtsi | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 3d7b839e6d..744594c45a 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -23,11 +23,14 @@
#address-cells = <1>;
#size-cells = <1>;
  
+		u-boot,dm-pre-reloc;

+


Please don't add these U-Boot specific properties into these dts/dtsi
files. The preferred way is to create a new dtsi file with the U-Boot
specific additions. This will get included automatically in the build
process. Please see this file for example:

arch/arm/dts/mt7622-u-boot.dtsi

This will also enable us to stay in sync with the Linux DT files.


resetctl-reboot {
compatible = "resetctl-reboot";
  
  			resets = < MT7628_SYS_RST>;

reset-names = "sysreset";
+   u-boot,dm-pre-reloc;
};
  
  		clkctrl: clkctrl@0x2c {

@@ -42,6 +45,7 @@
reg = <0x34 0x4>;
compatible = "mediatek,mtmips-reset";
#reset-cells = <1>;
+   u-boot,dm-pre-reloc;
};
  
  		pinctrl: pinctrl@60 {

@@ -52,6 +56,8 @@
pinctrl-names = "default";
pinctrl-0 = <_default>;
  
+			u-boot,dm-pre-reloc;

+
state_default: pin_state {
};
  
@@ -260,6 +266,8 @@

reset-names = "uart0";
  
  			reg-shift = <2>;

+
+   u-boot,dm-pre-reloc;
};
  
  		uart1: uart1@d00 {

@@ -275,6 +283,8 @@
reset-names = "uart1";
  
  			reg-shift = <2>;

+
+   u-boot,dm-pre-reloc;
};
  
  		uart2: uart2@e00 {

@@ -290,6 +300,8 @@
reset-names = "uart2";
  
  			reg-shift = <2>;

+
+   u-boot,dm-pre-reloc;
};
};
  



Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH v2 11/21] dts: mtmips: remove all unusable nodes and properties from mt7628s.dtsi

2020-01-17 Thread Stefan Roese

On 17.01.20 08:45, Weijie Gao wrote:

This patch removes all unused and unusable nodes and properties from
mt7628s.dtsi.

Signed-off-by: Weijie Gao 
---
Changes since v1: splitted from another patch


Please don't remove the unused parts. As mentioned before, we try to
stay as close to the official DT files from the Linux tree as possible.
Goal is to sync with Linux at some time. This is already done on other
architectures / boards.

Thanks,
Stefan


---
  arch/mips/dts/mt7628a.dtsi | 68 --
  1 file changed, 68 deletions(-)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index cdc643fe37..3d7b839e6d 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -7,24 +7,6 @@
#size-cells = <1>;
compatible = "ralink,mt7628a-soc";
  
-	cpus {

-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu@0 {
-   compatible = "mti,mips24KEc";
-   device_type = "cpu";
-   reg = <0>;
-   };
-   };
-
-   cpuintc: interrupt-controller {
-   #address-cells = <0>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   compatible = "mti,cpu-interrupt-controller";
-   };
-
clk48m: clk48m@0 {
compatible = "fixed-clock";
  
@@ -41,11 +23,6 @@

#address-cells = <1>;
#size-cells = <1>;
  
-		sysc: system-controller@0 {

-   compatible = "ralink,mt7620a-sysc", "syscon";
-   reg = <0x0 0x100>;
-   };
-
resetctl-reboot {
compatible = "resetctl-reboot";
  
@@ -223,32 +200,6 @@
  
  			resets = < MT7628_TIMER_RST>;

reset-names = "wdt";
-
-   interrupt-parent = <>;
-   interrupts = <24>;
-   };
-
-   intc: interrupt-controller@200 {
-   compatible = "ralink,rt2880-intc";
-   reg = <0x200 0x100>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
-
-   resets = < MT7628_INT_RST>;
-   reset-names = "intc";
-
-   interrupt-parent = <>;
-   interrupts = <2>;
-
-   ralink,intc-registers = <0x9c 0xa0
-0x6c 0xa4
-0x80 0x78>;
-   };
-
-   memory-controller@300 {
-   compatible = "ralink,mt7620a-memc";
-   reg = <0x300 0x100>;
};
  
  		gpio@600 {

@@ -261,9 +212,6 @@
resets = < MT7628_PIO_RST>;
reset-names = "pio";
  
-			interrupt-parent = <>;

-   interrupts = <6>;
-
gpio0: bank@0 {
reg = <0>;
compatible = "mtk,mt7621-gpio-bank";
@@ -311,9 +259,6 @@
resets = < MT7628_UART0_RST>;
reset-names = "uart0";
  
-			interrupt-parent = <>;

-   interrupts = <20>;
-
reg-shift = <2>;
};
  
@@ -329,9 +274,6 @@

resets = < MT7628_UART1_RST>;
reset-names = "uart1";
  
-			interrupt-parent = <>;

-   interrupts = <21>;
-
reg-shift = <2>;
};
  
@@ -347,9 +289,6 @@

resets = < MT7628_UART2_RST>;
reset-names = "uart2";
  
-			interrupt-parent = <>;

-   interrupts = <22>;
-
reg-shift = <2>;
};
};
@@ -361,8 +300,6 @@
  
  		resets = < MT7628_EPHY_RST>;

reset-names = "ephy";
-
-   syscon = <>;
};
  
  	usb_phy: usb-phy@1012 {

@@ -371,8 +308,6 @@
  
  		#phy-cells = <0>;
  
-		ralink,sysctl = <>;

-
resets = < MT7628_UPHY_RST>;
reset-names = "phy";
  
@@ -386,9 +321,6 @@
  
  		phys = <_phy>;

phy-names = "usb";
-
-   interrupt-parent = <>;
-   interrupts = <18>;
};
  
  	mmc: mmc@1013 {




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH v2 00/21] Refactor the architecture parts of mt7628

2020-01-17 Thread Stefan Roese

Hi Weijie,

I've added another of my mail addresses to cc (m...@roese.nl) as the
sending to the other 2 addresses does not seem to work.

On 17.01.20 08:45, Weijie Gao wrote:

This patch series are divided into two parts:

The main part is to rewrite the whole architecture code of mt7628:
1. Lock parts of the d-cache for initial stack so the rest of the code can
be reimplemented in C.
2. Memory controller & DDR initialization have been fully written to support
detecting DDR size automatically.
3. DDR calibration has also been reimplemented with a clear logic.
4. Implemented a new sysreset driver to take advantage of the reset
controller so we can drop the use of syscon-based sysreset to reduce size.

The second part is to add SPL support for mt7628:
1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary
simultaneously, and we can drop RAM boot related configs and defconfig
files.
2. Generate compressed u-boot.bin image for SPL to reduce size of final
combined binary.
3. Enable DM support for SPL for a more flexible device probing.
4. Add a demo board (mt7628_rfb) aims at router application.

Changes since v1:
1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple patches.
2. Dropped a patch which tried to use customized get_tbclk().
3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi
4. Refactor the patch which restores exception vector base before booting linux.
5. Define a new option to enable u_boot_list in SPL.
6. Enable compressed spl payload for all boards.
7. Enable DM and DT support for linkit and gardena-smart-gateway.
8. Complete pinmux for all three UARTs for SPL.
9. Rewrite u_boot_lzma_img.py.

Weijie Gao (21):


It seems that patch 09/21 is missing on the list. Is it stuck in
moderation? Or is the patch numbering corrupt?

Thanks,
Stefan


Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Jorge Ramirez-Ortiz, Gmail
On 17/01/20 10:26:11, Fabio Estevam wrote:
> Hi Jorge,
> 
> On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
>  wrote:
> >
> > Hi Fabio,
> >
> > I am trying to enable LDO in an imx7ulp based board but somehow the
> > board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> > sequence).
> >
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
> >
> > I also noticed that if I dont execute the init_ldo_mode sequence and
> > just check for the LODEN bit [see snipet below], this is already set
> > which too seems strange.
> 
> On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
> set after POR too.
> 
> Should we do something like this to avoid re-initializing the PMC1?
> 
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,6 +122,9 @@ static void init_ldo_mode(void)
>  {
> unsigned int reg;
> 
> +   if (ldo_mode_is_enabled())
> +   return;
> +
> /* Set LDOOKDIS */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);

not sure about this but I guess it makes sense (btw have you checked in your 
boards if the init_ldo_mode code executes all the write steps?)

when I check the voltage configuration for PMC1_RUN it does not show 0.95V but 
the default (1.0V - ie: 0x28 at offset 0x08 bits 21-16).
I still havent figured out who might be configuring/enabling it for the A7 
though.


Re: [PATCH 0/3] Fix Odroid U3/X2 SD-card boot

2020-01-17 Thread Marek Szyprowski
Hi Anand

On 17.01.2020 06:00, Anand Moon wrote:
> On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski  
> wrote:
>> This patchset restores booting from SD-card on Exynos4412-based Odroid
>> U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and
>> PMIC device name fixes:
>> https://patchwork.ozlabs.org/patch/1223558/
>> https://patchwork.ozlabs.org/patch/1224228/
>>
>> Best regards
>> Marek Szyprowski
>> Samsung R Institute Poland
>>
> Thanks for this fix, I have am issue with my odroid u3 boards,
> All my board will not boot up until I connect UART to usb port.
> basically the fan spin but will not load the kernel.
> So it their a solution to this problem.
>
> I tried the patch from Tobias Jakobi (odroid: defconfig: configure
> keyed autoboot)
> but this did not work at my end.

I remember I observed a few times the lack of boot when uart adapter was 
not connect, but now I didn't manage to reproduce it.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R Institute Poland



Re: question: mx7ulp - LDO_ENABLED_MODE

2020-01-17 Thread Fabio Estevam
Hi Jorge,

On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
 wrote:
>
> Hi Fabio,
>
> I am trying to enable LDO in an imx7ulp based board but somehow the
> board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> sequence).
>
> I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> I am wondering if you think it is possible - in your experience- that
> ROM might have already configured LDO? or was this also the case -
> this bit already set- when you tested the feature?
>
> I also noticed that if I dont execute the init_ldo_mode sequence and
> just check for the LODEN bit [see snipet below], this is already set
> which too seems strange.

On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
set after POR too.

Should we do something like this to avoid re-initializing the PMC1?

--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -122,6 +122,9 @@ static void init_ldo_mode(void)
 {
unsigned int reg;

+   if (ldo_mode_is_enabled())
+   return;
+
/* Set LDOOKDIS */
setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);


Re: [PATCH v2 2/2] spi: cadence-qspi: Add direct mode support

2020-01-17 Thread Simon Goldschmidt
On Fri, Jan 17, 2020 at 2:01 PM Vignesh Raghavendra  wrote:
>
>
>
> On 17/01/20 6:21 pm, Simon Goldschmidt wrote:
> > On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  
> > wrote:
> >>
> >> Add support for Direct Access Controller mode of Cadence QSPI. This
> >> allows MMIO access to SPI NOR flash providing better read performance.
> >> Direct mode is only exercised if AHB window size is greater than 8MB.
> >> Support for flash address remapping is also not supported at the moment
> >> and can be added in future.
> >>
> >> For better performance, driver uses DMA to copy data from flash in
> >> direct mode using dma_memcpy().
> >
> > This v2 doesn't compile for socfpa as dma_memcpy() isn't available. Since 
> > direct
> > mode isn't used on that platform (due to your 8MB check), dma_memcpy() is 
> > not
> > required, but still it doesn't link as this is a runtime decision.
> >
>
> Could you try with latest master and make sure it has [1] and [2]
> applied? Thanks!
>
> [1]http://patchwork.ozlabs.org/patch/1195557/
> [2]http://patchwork.ozlabs.org/patch/1195556/

Right, Tom merged that yesterday. Compiles now, sorry for the noise.

Regards,
Simon

>
> Regards
> Vignesh
>
> > Regards,
> > Simon
> >
> >>
> >> Signed-off-by: Vignesh Raghavendra 
> >> ---
> >> v2: Add DMA support and update commit message
> >>
> >>  drivers/spi/cadence_qspi.c | 40 -
> >>  drivers/spi/cadence_qspi.h | 19 +-
> >>  drivers/spi/cadence_qspi_apb.c | 65 +-
> >>  3 files changed, 91 insertions(+), 33 deletions(-)
> >>
> >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> >> index 673a2e9a6c4c..6c98cbf39ae4 100644
> >> --- a/drivers/spi/cadence_qspi.c
> >> +++ b/drivers/spi/cadence_qspi.c
> >> @@ -12,12 +12,13 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "cadence_qspi.h"
> >>
> >>  #define CQSPI_STIG_READ0
> >>  #define CQSPI_STIG_WRITE   1
> >> -#define CQSPI_INDIRECT_READ2
> >> -#define CQSPI_INDIRECT_WRITE   3
> >> +#define CQSPI_READ 2
> >> +#define CQSPI_WRITE3
> >>
> >>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
> >>  {
> >> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
> >>
> >>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> >>  {
> >> +   struct cadence_spi_platdata *plat = bus->platdata;
> >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> >>
> >> /* Disable QSPI */
> >> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> >> uint mode)
> >> /* Set SPI mode */
> >> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
> >>
> >> +   /* Enable Direct Access Controller */
> >> +   if (plat->use_dac_mode)
> >> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> >> +
> >> /* Enable QSPI */
> >> cadence_qspi_apb_controller_enable(priv->regbase);
> >>
> >> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> >> *spi,
> >> if (!op->addr.nbytes)
> >> mode = CQSPI_STIG_READ;
> >> else
> >> -   mode = CQSPI_INDIRECT_READ;
> >> +   mode = CQSPI_READ;
> >> } else {
> >> if (!op->addr.nbytes || !op->data.buf.out)
> >> mode = CQSPI_STIG_WRITE;
> >> else
> >> -   mode = CQSPI_INDIRECT_WRITE;
> >> +   mode = CQSPI_WRITE;
> >> }
> >>
> >> switch (mode) {
> >> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> >> *spi,
> >> case CQSPI_STIG_WRITE:
> >> err = cadence_qspi_apb_command_write(base, op);
> >> break;
> >> -   case CQSPI_INDIRECT_READ:
> >> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
> >> -   if (!err) {
> >> -   err = cadence_qspi_apb_indirect_read_execute
> >> -   (plat, op->data.nbytes, op->data.buf.in);
> >> -   }
> >> +   case CQSPI_READ:
> >> +   err = cadence_qspi_apb_read_setup(plat, op);
> >> +   if (!err)
> >> +   err = cadence_qspi_apb_read_execute(plat, op);
> >> break;
> >> -   case CQSPI_INDIRECT_WRITE:
> >> -   err = cadence_qspi_apb_indirect_write_setup(plat, op);
> >> -   if (!err) {
> >> -   err = cadence_qspi_apb_indirect_write_execute
> >> -   (plat, op->data.nbytes, op->data.buf.out);
> >> -   }
> >> +   case CQSPI_WRITE:
> >> +   err = cadence_qspi_apb_write_setup(plat, op);
> >> +   if (!err)
> >> +   err = 

Re: [PATCH v2 19/21] mips: mtmips: add SPL support

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:46 schrieb Weijie Gao:
> This patch adds SPL support for mtmips platform. The lowlevel architecture
> is split into SPL and the rest parts are built into a memory loadable
> u-boot image. Optional SPL_DM and OF_CONTROL are also supported.
> 
> The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
> not enabled and the memory bootable u-boot (u-boot.img) is generated
> automatically so there is not need to add a separate config for it.
> 
> A lzma compressed payload (u-boot-lzma.img) is also generated and it will
> be combined with u-boot-spl.bin to form the unified ROM bootable binary
> u-boot-mtmips.bin.
> 
> A spl loader is added to support uncompress the payload.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1:
>   move spl loader into this patch.
>   add full pinmux for all three uarts.
>   add optional DM & DT support.
> ---
>  Makefile|   9 ++
>  arch/mips/Kconfig   |   3 +
>  arch/mips/dts/mt7628-u-boot.dtsi|  24 
>  arch/mips/mach-mtmips/Kconfig   |  24 
>  arch/mips/mach-mtmips/Makefile  |   1 +
>  arch/mips/mach-mtmips/include/mach/serial.h |  13 +++
>  arch/mips/mach-mtmips/include/mach/spl.h|  14 +++
>  arch/mips/mach-mtmips/mt7628/Makefile   |   1 +
>  arch/mips/mach-mtmips/mt7628/serial.c   |  34 ++
>  arch/mips/mach-mtmips/spl.c |  31 +
>  arch/mips/mach-mtmips/spl_load.c| 121 
>  11 files changed, 275 insertions(+)
>  create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
>  create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
>  create mode 100644 arch/mips/mach-mtmips/include/mach/spl.h
>  create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
>  create mode 100644 arch/mips/mach-mtmips/spl.c
>  create mode 100644 arch/mips/mach-mtmips/spl_load.c
> 
> diff --git a/Makefile b/Makefile
> index 8013cbd9f9..1e18a37913 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -895,6 +895,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
>  endif
>  
>  ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
> +ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mtmips.bin
>  
>  # Add optional build target if defined in board/cpu/soc headers
>  ifneq ($(CONFIG_BUILD_TARGET),)
> @@ -1664,6 +1665,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
>   $(call if_changed,mkimage)
>  endif
>  
> +ifeq ($(CONFIG_SPL),y)
> +u-boot-mtmips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
> + $(call if_changed,binman)
> +else
> +u-boot-mtmips.bin: u-boot.bin FORCE
> + $(call if_changed,copy)
> +endif
> +
>  ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
>  
>  # Rule to link u-boot
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 5f82caf8be..5f74f549b5 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -98,6 +98,9 @@ config ARCH_MTMIPS
>   select SUPPORTS_CPU_MIPS32_R2
>   select SUPPORTS_LITTLE_ENDIAN
>   select SYSRESET
> + select SUPPORT_SPL
> + select SPL_LZMA
> + select BINMAN
>  
>  config ARCH_JZ47XX
>   bool "Support Ingenic JZ47xx"
> diff --git a/arch/mips/dts/mt7628-u-boot.dtsi 
> b/arch/mips/dts/mt7628-u-boot.dtsi
> new file mode 100644
> index 00..213959105f
> --- /dev/null
> +++ b/arch/mips/dts/mt7628-u-boot.dtsi
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + *
> + * Author: Weijie Gao 
> + */
> +
> +/ {
> + binman {
> + filename = "u-boot-mtmips.bin";
> + pad-byte = <0xff>;
> +
> +#ifdef CONFIG_SPL
> + u-boot-spl {
> + };
> +
> + u-boot-lzma-img {
> + };
> +#else
> + u-boot {
> + };
> +#endif
> + };
> +};
> diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
> index 3f25de8b85..9b42d5b581 100644
> --- a/arch/mips/mach-mtmips/Kconfig
> +++ b/arch/mips/mach-mtmips/Kconfig
> @@ -20,8 +20,16 @@ config SYS_ICACHE_LINE_SIZE
>   default 32
>  
>  config SYS_TEXT_BASE
> + default 0x9c00 if !SPL
> + default 0x8020 if SPL
> +
> +config SPL_TEXT_BASE
>   default 0x9c00
>  
> +config SPL_LOADER_SUPPORT
> + bool
> + default y
> +

this option should be moved to arch/mips/Kconfig and should be added
with patch 15/21 because you use reference that option in the generic
MIPS u-boot-spl.lds

>  choice
>   prompt "MediaTek MIPS SoC select"
>  
> @@ -34,6 +42,14 @@ config SOC_MT7628
>   select PINCTRL_MT7628
>   select MTK_SERIAL
>   select SYSRESET_RESETCTL
> + select SPL_SEPARATE_BSS if SPL
> + select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
> + select SPL_OF_CONTROL if SPL_DM
> + select SPL_SIMPLE_BUS if SPL_DM
> + select SPL_DM_SERIAL if SPL_DM
> + select SPL_CLK if SPL_DM && SPL_SERIAL_SUPPORT
> + select SPL_SYSRESET if SPL_DM
> + select SPL_OF_LIBFDT 

[PATCH] arm: exynos: odroid: Change autoboot script to use ${mmcbootdev}

2020-01-17 Thread Marek Szyprowski
This fixes the default boot command for the SD-card boot case.

Signed-off-by: Marek Szyprowski 
---
This is the continuation of the fixes from this patchset:
https://patchwork.ozlabs.org/cover/1224290/
---
 include/configs/odroid.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 7989fb29d1..a7e2a3d9a2 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -146,13 +146,13 @@
"run kernel_args;" \
"bootz ${kernel_addr_r} ${initrd_addr} ${fdt_addr};\0" \
"autoboot=" \
-   "if test -e mmc 0 boot.scr; then; " \
+   "if test -e mmc ${mmcbootdev} boot.scr; then; " \
"run boot_script; " \
-   "elif test -e mmc 0 Image.itb; then; " \
+   "elif test -e mmc ${mmcbootdev} Image.itb; then; " \
"run boot_fit;" \
-   "elif test -e mmc 0 zImage; then; " \
+   "elif test -e mmc ${mmcbootdev} zImage; then; " \
"run boot_zimg;" \
-   "elif test -e mmc 0 uImage; then; " \
+   "elif test -e mmc ${mmcbootdev} uImage; then; " \
"run boot_uimg;" \
"fi;\0" \
"console=" CONFIG_DEFAULT_CONSOLE \
-- 
2.17.1



[PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins

2020-01-17 Thread Marek Szyprowski
XOM pins provide information for iROM bootloader about the boot device.
Those pins are mapped to lower bits of OP_MODE register (0x1008),
which is common for all Exynos SoC variants. Set the default MMC device id
to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
the eMMC).

Signed-off-by: Marek Szyprowski 
---
v2:
- store mmc boot device to ${mmcbootdev} env
- print information about boot mmc device
---
 arch/arm/mach-exynos/include/mach/cpu.h |  1 +
 board/samsung/common/board.c| 28 +
 configs/odroid-xu3_defconfig|  1 +
 configs/odroid_defconfig|  1 +
 4 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
b/arch/arm/mach-exynos/include/mach/cpu.h
index 766edeeb29..fb5fdaf3ba 100644
--- a/arch/arm/mach-exynos/include/mach/cpu.h
+++ b/arch/arm/mach-exynos/include/mach/cpu.h
@@ -17,6 +17,7 @@
 
 #define EXYNOS4_GPIO_PART3_BASE0x0386
 #define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_OP_MODE0x1008
 #define EXYNOS4_SYSREG_BASE0x1001
 #define EXYNOS4_POWER_BASE 0x1002
 #define EXYNOS4_SWRESET0x10020400
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ee2fc7971e..cb94ced54e 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
return 0;
 }
 
+/**
+ * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
+ */
+static int get_boot_mmc_dev(void)
+{
+   u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
+
+   if (mode == 0x04)
+   return 2; /* MMC2: SD */
+
+   /* MMC0: eMMC or unknown */
+   return 0;
+}
+
 #if defined CONFIG_EXYNOS_TMU
 /* Boot Time Thermal Analysis for SoC temperature threshold breach */
 static void boot_temp_check(void)
@@ -280,6 +296,8 @@ int board_late_init(void)
 {
struct udevice *dev;
int ret;
+   int mmcbootdev = get_boot_mmc_dev();
+   char mmcbootdev_str[16];
 
stdio_print_current_devices();
ret = uclass_first_device_err(UCLASS_CROS_EC, );
@@ -292,6 +310,11 @@ int board_late_init(void)
panic("Cannot init cros-ec device");
return -1;
}
+
+   printf("Boot device: MMC(%u)\n", mmcbootdev);
+   sprintf(mmcbootdev_str, "%u", mmcbootdev);
+   env_set("mmcbootdev", mmcbootdev_str);
+
return 0;
 }
 #endif
@@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type init)
 #endif
return 0;
 }
+
+int mmc_get_env_dev(void)
+{
+   return get_boot_mmc_dev();
+}
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index 20038d4197..2e982e1b53 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
 CONFIG_SILENT_CONSOLE=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_MISC_INIT_R=y
+CONFIG_BOARD_LATE_INIT=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_TYPES=y
diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
index be914e4caf..e4392e477e 100644
--- a/configs/odroid_defconfig
+++ b/configs/odroid_defconfig
@@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_MISC_INIT_R=y
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_BOARD_TYPES=y
 CONFIG_SYS_PROMPT="Odroid # "
 # CONFIG_CMD_XIMG is not set
-- 
2.17.1



Re: [PATCH v2 2/2] spi: cadence-qspi: Add direct mode support

2020-01-17 Thread Vignesh Raghavendra



On 17/01/20 6:21 pm, Simon Goldschmidt wrote:
> On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  wrote:
>>
>> Add support for Direct Access Controller mode of Cadence QSPI. This
>> allows MMIO access to SPI NOR flash providing better read performance.
>> Direct mode is only exercised if AHB window size is greater than 8MB.
>> Support for flash address remapping is also not supported at the moment
>> and can be added in future.
>>
>> For better performance, driver uses DMA to copy data from flash in
>> direct mode using dma_memcpy().
> 
> This v2 doesn't compile for socfpa as dma_memcpy() isn't available. Since 
> direct
> mode isn't used on that platform (due to your 8MB check), dma_memcpy() is not
> required, but still it doesn't link as this is a runtime decision.
> 

Could you try with latest master and make sure it has [1] and [2]
applied? Thanks!

[1]http://patchwork.ozlabs.org/patch/1195557/
[2]http://patchwork.ozlabs.org/patch/1195556/

Regards
Vignesh

> Regards,
> Simon
> 
>>
>> Signed-off-by: Vignesh Raghavendra 
>> ---
>> v2: Add DMA support and update commit message
>>
>>  drivers/spi/cadence_qspi.c | 40 -
>>  drivers/spi/cadence_qspi.h | 19 +-
>>  drivers/spi/cadence_qspi_apb.c | 65 +-
>>  3 files changed, 91 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> index 673a2e9a6c4c..6c98cbf39ae4 100644
>> --- a/drivers/spi/cadence_qspi.c
>> +++ b/drivers/spi/cadence_qspi.c
>> @@ -12,12 +12,13 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "cadence_qspi.h"
>>
>>  #define CQSPI_STIG_READ0
>>  #define CQSPI_STIG_WRITE   1
>> -#define CQSPI_INDIRECT_READ2
>> -#define CQSPI_INDIRECT_WRITE   3
>> +#define CQSPI_READ 2
>> +#define CQSPI_WRITE3
>>
>>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
>>  {
>> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
>>
>>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
>>  {
>> +   struct cadence_spi_platdata *plat = bus->platdata;
>> struct cadence_spi_priv *priv = dev_get_priv(bus);
>>
>> /* Disable QSPI */
>> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
>> uint mode)
>> /* Set SPI mode */
>> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
>>
>> +   /* Enable Direct Access Controller */
>> +   if (plat->use_dac_mode)
>> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
>> +
>> /* Enable QSPI */
>> cadence_qspi_apb_controller_enable(priv->regbase);
>>
>> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
>> *spi,
>> if (!op->addr.nbytes)
>> mode = CQSPI_STIG_READ;
>> else
>> -   mode = CQSPI_INDIRECT_READ;
>> +   mode = CQSPI_READ;
>> } else {
>> if (!op->addr.nbytes || !op->data.buf.out)
>> mode = CQSPI_STIG_WRITE;
>> else
>> -   mode = CQSPI_INDIRECT_WRITE;
>> +   mode = CQSPI_WRITE;
>> }
>>
>> switch (mode) {
>> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
>> *spi,
>> case CQSPI_STIG_WRITE:
>> err = cadence_qspi_apb_command_write(base, op);
>> break;
>> -   case CQSPI_INDIRECT_READ:
>> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
>> -   if (!err) {
>> -   err = cadence_qspi_apb_indirect_read_execute
>> -   (plat, op->data.nbytes, op->data.buf.in);
>> -   }
>> +   case CQSPI_READ:
>> +   err = cadence_qspi_apb_read_setup(plat, op);
>> +   if (!err)
>> +   err = cadence_qspi_apb_read_execute(plat, op);
>> break;
>> -   case CQSPI_INDIRECT_WRITE:
>> -   err = cadence_qspi_apb_indirect_write_setup(plat, op);
>> -   if (!err) {
>> -   err = cadence_qspi_apb_indirect_write_execute
>> -   (plat, op->data.nbytes, op->data.buf.out);
>> -   }
>> +   case CQSPI_WRITE:
>> +   err = cadence_qspi_apb_write_setup(plat, op);
>> +   if (!err)
>> +   err = cadence_qspi_apb_write_execute(plat, op);
>> break;
>> default:
>> err = -1;
>> @@ -264,13 +266,17 @@ static int cadence_spi_ofdata_to_platdata(struct 
>> udevice *bus)
>> ofnode subnode;
>>
>> plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
>> -   plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
>> +   plat->ahbbase = (void 

Re: [PATCH v2 2/2] spi: cadence-qspi: Add direct mode support

2020-01-17 Thread Simon Goldschmidt
On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  wrote:
>
> Add support for Direct Access Controller mode of Cadence QSPI. This
> allows MMIO access to SPI NOR flash providing better read performance.
> Direct mode is only exercised if AHB window size is greater than 8MB.
> Support for flash address remapping is also not supported at the moment
> and can be added in future.
>
> For better performance, driver uses DMA to copy data from flash in
> direct mode using dma_memcpy().

This v2 doesn't compile for socfpa as dma_memcpy() isn't available. Since direct
mode isn't used on that platform (due to your 8MB check), dma_memcpy() is not
required, but still it doesn't link as this is a runtime decision.

Regards,
Simon

>
> Signed-off-by: Vignesh Raghavendra 
> ---
> v2: Add DMA support and update commit message
>
>  drivers/spi/cadence_qspi.c | 40 -
>  drivers/spi/cadence_qspi.h | 19 +-
>  drivers/spi/cadence_qspi_apb.c | 65 +-
>  3 files changed, 91 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 673a2e9a6c4c..6c98cbf39ae4 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -12,12 +12,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "cadence_qspi.h"
>
>  #define CQSPI_STIG_READ0
>  #define CQSPI_STIG_WRITE   1
> -#define CQSPI_INDIRECT_READ2
> -#define CQSPI_INDIRECT_WRITE   3
> +#define CQSPI_READ 2
> +#define CQSPI_WRITE3
>
>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
>  {
> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
>
>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
>  {
> +   struct cadence_spi_platdata *plat = bus->platdata;
> struct cadence_spi_priv *priv = dev_get_priv(bus);
>
> /* Disable QSPI */
> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> uint mode)
> /* Set SPI mode */
> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
>
> +   /* Enable Direct Access Controller */
> +   if (plat->use_dac_mode)
> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> +
> /* Enable QSPI */
> cadence_qspi_apb_controller_enable(priv->regbase);
>
> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> *spi,
> if (!op->addr.nbytes)
> mode = CQSPI_STIG_READ;
> else
> -   mode = CQSPI_INDIRECT_READ;
> +   mode = CQSPI_READ;
> } else {
> if (!op->addr.nbytes || !op->data.buf.out)
> mode = CQSPI_STIG_WRITE;
> else
> -   mode = CQSPI_INDIRECT_WRITE;
> +   mode = CQSPI_WRITE;
> }
>
> switch (mode) {
> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> *spi,
> case CQSPI_STIG_WRITE:
> err = cadence_qspi_apb_command_write(base, op);
> break;
> -   case CQSPI_INDIRECT_READ:
> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
> -   if (!err) {
> -   err = cadence_qspi_apb_indirect_read_execute
> -   (plat, op->data.nbytes, op->data.buf.in);
> -   }
> +   case CQSPI_READ:
> +   err = cadence_qspi_apb_read_setup(plat, op);
> +   if (!err)
> +   err = cadence_qspi_apb_read_execute(plat, op);
> break;
> -   case CQSPI_INDIRECT_WRITE:
> -   err = cadence_qspi_apb_indirect_write_setup(plat, op);
> -   if (!err) {
> -   err = cadence_qspi_apb_indirect_write_execute
> -   (plat, op->data.nbytes, op->data.buf.out);
> -   }
> +   case CQSPI_WRITE:
> +   err = cadence_qspi_apb_write_setup(plat, op);
> +   if (!err)
> +   err = cadence_qspi_apb_write_execute(plat, op);
> break;
> default:
> err = -1;
> @@ -264,13 +266,17 @@ static int cadence_spi_ofdata_to_platdata(struct 
> udevice *bus)
> ofnode subnode;
>
> plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
> -   plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
> +   plat->ahbbase = (void *)devfdt_get_addr_size_index(bus, 1,
> +   >ahbsize);
> plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs");
> plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128);
> plat->fifo_width = dev_read_u32_default(bus, "cdns,fifo-width", 4);
> plat->trigger_address = dev_read_u32_default(bus,
> 

[PATCH v2 9/9] doc: update FU540 RISC-V documentation

2020-01-17 Thread Pragnesh Patel
Add descriptions about U-Boot SPL feature and how to build and run.

Signed-off-by: Pragnesh Patel 
---
 doc/board/sifive/fu540.rst | 370 +
 1 file changed, 370 insertions(+)

diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
index 3937222c6c..e15427414d 100644
--- a/doc/board/sifive/fu540.rst
+++ b/doc/board/sifive/fu540.rst
@@ -363,3 +363,373 @@ load uImage.
 
Please press Enter to activate this console.
/ #
+
+
+Running U-Boot SPL
+--
+The U-Boot SPL will boot in M mode and load the FIT image which include
+OpenSBI and U-Boot proper images. After loading progress, it will jump
+to OpenSBI first and then U-Boot proper which will run in S mode.
+
+
+How to build U-Boot SPL
+---
+Before building U-Boot SPL, OpenSBI must be build first. OpenSBI can be
+cloned and build for FU540 as below:
+
+git clone https://github.com/riscv/opensbi.git
+cd opensbi
+make PLATFORM=sifive/fu540
+
+Copy OpenSBI FW_DYNAMIC image 
(build/platform/sifive/fu540/firmware/fw_dynamic.bin)
+into U-Boot root directory
+
+
+How to build U-Boot SPL booting from MMC
+
+With sifive_fu540_spl_defconfig:
+
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation enviornment variable:
+
+.. code-block:: none
+
+   export ARCH=riscv
+   export CROSS_COMPILE=
+
+3. make sifive_fu540_spl_defconfig
+4. make
+
+
+Flashing
+
+
+The current U-Boot port is supported in S-mode only.
+
+A prior stage M-mode firmware/bootloader (e.g OpenSBI) is required to
+boot the u-boot.bin in S-mode and provide M-mode runtime services.
+
+First partition of the sdcard should contain "u-boot.itb" and
+Partition type should be of "8300  Linux filesystem".
+
+.. code-block:: none
+
+sudo dd if=spl/u-boot-spl.bin of=/dev/disk2s4 bs=1024
+sudo dd if=u-boot.itb of=/dev/disk2s1 bs=1024
+
+Booting
+---
+Once you plugin the sdcard and power up, you should see the U-Boot prompt.
+
+Sample boot log from HiFive Unleashed board
+---
+
+.. code-block:: none
+
+   U-Boot SPL 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530)
+   Trying to boot from MMC1
+
+
+   U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530)
+
+   CPU:   rv64imafdc
+   Model: SiFive HiFive Unleashed A00
+   DRAM:  8 GiB
+   MMC:   spi@1005:mmc@0: 0
+   In:serial@1001
+   Out:   serial@1001
+   Err:   serial@1001
+   Board serial number should not be 0 !!
+   Net:   
+   Warning: ethernet@1009 (eth0) using random MAC address - 
9e:33:74:04:6a:eb
+   eth0: ethernet@1009
+   Hit any key to stop autoboot:  0
+   => version
+   U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530)
+
+   riscv64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0.37-3f461da) 9.2.0
+   GNU ld (crosstool-NG 1.24.0.37-3f461da) 2.32
+   => mmc info
+   Device: spi@1005:mmc@0
+   Manufacturer ID: 3
+   OEM: 5344
+   Name: SC16G
+   Bus Speed: 2000
+   Mode: SD Legacy
+   Rd Block Len: 512
+   SD version 2.0
+   High Capacity: Yes
+   Capacity: 14.8 GiB
+   Bus Width: 1-bit
+   Erase Group Size: 512 Bytes
+   => mmc part
+
+   Partition Map for MMC device 0  --   Partition Type: EFI
+
+   PartStart LBA   End LBA Name
+   Attributes
+   Type GUID
+   Partition GUID
+   1 0x0800  0x000107ff  "Linux filesystem"
+   attrs:  0x
+   type:   0fc63daf-8483-4772-8e79-3d69d8477de4
+   guid:   36aab838-b418-4342-929e-678d85fb4438
+   2 0x00040800  0x00ecdfde  "Linux filesystem"
+   attrs:  0x
+   type:   0fc63daf-8483-4772-8e79-3d69d8477de4
+   guid:   118ac296-e3ff-4ef2-b435-ec6a7bebdd6e
+
+Now you can configure your networking, tftp server and use tftp boot method to
+load uImage.
+
+.. code-block:: none
+
+   => setenv serverip 172.16.35.74
+   => setenv ipaddr 172.16.35.40
+   => tftpboot 0x8300 fit.itb
+   ethernet@1009: PHY present at 0
+   ethernet@1009: Starting autonegotiation...
+   ethernet@1009: Autonegotiation complete
+   ethernet@1009: link up, 100Mbps full-duplex (lpa: 0x41e1)
+   Using ethernet@1009 device
+   TFTP from server 172.16.35.74; our IP address is 172.16.35.40
+   Filename 'fit.itb'.
+   Load address: 0x8300
+   Loading: #
+   #
+   #
+   #
+   #
+   #
+   #
+   #
+   #
+   

[PATCH v2 7/9] riscv: sifive: fu540: Add U-boot SPL header files

2020-01-17 Thread Pragnesh Patel
Add header files needed for U-boot SPL

Signed-off-by: Pragnesh Patel 
---
 board/sifive/fu540/ccache.h   |   43 +
 board/sifive/fu540/fu540-memory-map.h |   59 ++
 board/sifive/fu540/regconfig-ctl.h|  274 ++
 board/sifive/fu540/regconfig-phy.h| 1224 +
 board/sifive/fu540/ux00ddr.h  |  276 ++
 board/sifive/fu540/ux00prci.h |   69 ++
 6 files changed, 1945 insertions(+)
 create mode 100644 board/sifive/fu540/ccache.h
 create mode 100644 board/sifive/fu540/fu540-memory-map.h
 create mode 100644 board/sifive/fu540/regconfig-ctl.h
 create mode 100644 board/sifive/fu540/regconfig-phy.h
 create mode 100644 board/sifive/fu540/ux00ddr.h
 create mode 100644 board/sifive/fu540/ux00prci.h

diff --git a/board/sifive/fu540/ccache.h b/board/sifive/fu540/ccache.h
new file mode 100644
index 00..0e5e40a1ef
--- /dev/null
+++ b/board/sifive/fu540/ccache.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 SiFive, Inc
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ *   Troy Benjegerdes 
+ */
+
+#ifndef FU540_CCACHE_H
+#define FU540_CCACHE_H
+
+#include 
+
+#ifndef __ASSEMBLER__
+
+#include 
+#include 
+
+/* Block memory access until operation completed */
+static inline void ccache_barrier_0(void)
+{
+   asm volatile("fence rw, io" : : : "memory");
+}
+
+static inline void ccache_barrier_1(void)
+{
+   asm volatile("fence io, rw" : : : "memory");
+}
+
+/* Enable ways; allow cache to use these ways */
+static inline void ccache_enable_ways(u64 base_addr, u8 value)
+{
+   volatile u32 *enable = (volatile u32 *)(base_addr +
+ CCACHE_ENABLE);
+   ccache_barrier_0();
+   (*enable) = value;
+   ccache_barrier_1();
+}
+
+#endif
+
+#endif /* FU540_CCACHE_H */
diff --git a/board/sifive/fu540/fu540-memory-map.h 
b/board/sifive/fu540/fu540-memory-map.h
new file mode 100644
index 00..c0df07d6fd
--- /dev/null
+++ b/board/sifive/fu540/fu540-memory-map.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 SiFive, Inc
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ *   Troy Benjegerdes 
+ */
+
+#ifndef FU540_MEMORY_MAP
+#define FU540_MEMORY_MAP
+
+#include 
+#include 
+#include 
+#include "ccache.h"
+#include "i2c.h"
+#include "spi.h"
+#include "ux00prci.h"
+
+/
+ * Platform definitions
+ */
+
+/* Memory map */
+#define CCACHE_CTRL_ADDR   _AC(0x201, UL)
+#define CCACHE_CTRL_SIZE   _AC(0x1000, UL)
+
+#define GPIO_CTRL_ADDR _AC(0x1006, UL)
+#define GPIO_CTRL_SIZE _AC(0x1000, UL)
+
+#define PHYSICAL_FILTER_CTRL_ADDR  _AC(0x100b8000, UL)
+#define PHYSICAL_FILTER_CTRL_SIZE  _AC(0x1000, UL)
+
+#define UART0_CTRL_ADDR_AC(0x1001, UL)
+#define UART0_CTRL_SIZE_AC(0x1000, UL)
+#define UART1_CTRL_ADDR_AC(0x10011000, UL)
+#define UART1_CTRL_SIZE_AC(0x1000, UL)
+#ifndef UART_CTRL_ADDR
+#define UART_CTRL_ADDR UART0_CTRL_ADDR
+#endif
+#ifndef UART_CTRL_SIZE
+#define UART_CTRL_SIZE UART0_CTRL_SIZE
+#endif
+#define UX00DDR_CTRL_ADDR  _AC(0x100b, UL)
+#define UX00DDR_CTRL_SIZE  _AC(0x4000, UL)
+#define UX00PRCI_CTRL_ADDR _AC(0x1000, UL)
+#define UX00PRCI_CTRL_SIZE _AC(0x1000, UL)
+
+/* Helper functions */
+#define _REG32(p, i)(*(volatile uint32_t *)((p) + (i)))
+
+#define UX00PRCI_REG(offset)  \
+   _REG32(UX00PRCI_CTRL_ADDR, \
+   offset)
+#define GPIO_REG(offset)  _REG32(GPIO_CTRL_ADDR, offset)
+#define UART0_REG(offset)_REG32(UART0_CTRL_ADDR, offset)
+
+#endif /* FU540_MEMORY_MAP */
diff --git a/board/sifive/fu540/regconfig-ctl.h 
b/board/sifive/fu540/regconfig-ctl.h
new file mode 100644
index 00..19a52e7996
--- /dev/null
+++ b/board/sifive/fu540/regconfig-ctl.h
@@ -0,0 +1,274 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 SiFive, Inc
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ *   Troy Benjegerdes 
+ */
+
+#define   DENALI_CTL_00_DATA 0x0a00
+#define   DENALI_CTL_01_DATA 0x
+#define   DENALI_CTL_02_DATA 0x
+#define   DENALI_CTL_03_DATA 0x
+#define   DENALI_CTL_04_DATA 0x
+#define   DENALI_CTL_05_DATA 0x
+#define   DENALI_CTL_06_DATA 0x000a
+#define   DENALI_CTL_07_DATA 0x0002d362
+#define   DENALI_CTL_08_DATA 0x00071073
+#define   DENALI_CTL_09_DATA 0x0a1c0255
+#define   DENALI_CTL_10_DATA 0x1c1c0400
+#define   DENALI_CTL_11_DATA 0x0404990b
+#define   DENALI_CTL_12_DATA 0x2b050405
+#define   DENALI_CTL_13_DATA 

[PATCH v2 6/9] riscv: sifive: dts: fu540: Add board -u-boot.dtsi files

2020-01-17 Thread Pragnesh Patel
Devicetree files in FU540 platform is synced from Linux, like other
platforms does. Apart from these u-boot in FU540 would also require
some u-boot specific node like clint.

So, create board specific -u-boot.dtsi files. This would help of
maintain u-boot specific changes separately without touching Linux
dts(i) files which indeed easy for syncing from Linux between
releases.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/dts/fu540-c000-u-boot.dtsi | 43 +++
 .../dts/hifive-unleashed-a00-u-boot.dtsi  | 18 
 2 files changed, 61 insertions(+)

diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi 
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
index 615a68c0e9..e9b2799a7b 100644
--- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
@@ -4,10 +4,53 @@
  */
 
 / {
+   cpus {
+   u-boot,dm-spl;
+   cpu0: cpu@0 {
+   u-boot,dm-spl;
+   status = "okay";
+   cpu0_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+   cpu1: cpu@1 {
+   u-boot,dm-spl;
+   };
+   cpu2: cpu@2 {
+   u-boot,dm-spl;
+   };
+   cpu3: cpu@3 {
+   u-boot,dm-spl;
+   };
+   cpu4: cpu@4 {
+   u-boot,dm-spl;
+   };
+   };
+
soc {
+   u-boot,dm-spl;
otp: otp@1007 {
compatible = "sifive,fu540-otp";
reg = <0x0 0x1007 0x0 0x0FFF>;
};
+   clint@200 {
+   compatible = "riscv,clint0";
+   interrupts-extended = <_intc 3 _intc 7 >;
+   reg = <0x0 0x200 0x0 0xc>;
+   u-boot,dm-spl;
+   };
};
+
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
 };
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index bec0d19134..9b59f4ee14 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -4,3 +4,21 @@
  */
 
 #include "fu540-c000-u-boot.dtsi"
+
+/ {
+   hfclk {
+   u-boot,dm-spl;
+   };
+
+   rtcclk {
+   u-boot,dm-spl;
+   };
+};
+
+ {
+
+   mmc@0 {
+   u-boot,dm-spl;
+   };
+
+};
-- 
2.17.1



[PATCH v2 8/9] riscv: sifive: fu540: add SPL configuration

2020-01-17 Thread Pragnesh Patel
This patch provides sifive_fu540_spl_defconfig which can support
U-boot SPL to boot from L2 LIM (0x0800_) and then boot U-boot
FIT image including OpenSBI FW_DYNAMIC firmware and U-Boot proper
images from MMC boot devices.

With sifive_fu540_spl_defconfig:

U-Boot SPL will be loaded by ZSBL from SD card (replace fsbl.bin with
u-boot-spl.bin) and runs in L2 LIM in machine mode and then load FIT
image u-boot.itb from SD card (replace fw_payload.bin with u-boot.itb)
into RAM.

SPL related code is leverage from FSBL
(https://github.com/sifive/freedom-u540-c000-bootloader.git)

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/include/asm/csr.h   |   2 +
 board/sifive/fu540/Kconfig |   8 +
 board/sifive/fu540/MAINTAINERS |   1 +
 board/sifive/fu540/Makefile|   5 +
 board/sifive/fu540/ddrregs.c   | 625 +
 board/sifive/fu540/fu540.c |  27 +-
 board/sifive/fu540/spl.c   | 307 ++
 configs/sifive_fu540_spl_defconfig |  26 ++
 include/configs/sifive-fu540.h |  18 +
 9 files changed, 1018 insertions(+), 1 deletion(-)
 create mode 100644 board/sifive/fu540/ddrregs.c
 create mode 100644 board/sifive/fu540/spl.c
 create mode 100644 configs/sifive_fu540_spl_defconfig

diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index d1520743a2..125c05dd8a 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -103,6 +103,8 @@
 #define CSR_TIMEH  0xc81
 #define CSR_INSTRETH   0xc82
 #define CSR_MHARTID0xf14
+#define CSR_MCYCLE 0xb00
+#define CSR_MCYCLEH0xb80
 
 #ifndef __ASSEMBLY__
 
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 816a135b21..ac7c6bff37 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -16,12 +16,20 @@ config SYS_SOC
default "fu540"
 
 config SYS_TEXT_BASE
+   default 0x8020 if SPL
default 0x8000 if !RISCV_SMODE
default 0x8020 if RISCV_SMODE
 
+config SPL_TEXT_BASE
+   default 0x0800
+
+config SPL_OPENSBI_LOAD_ADDR
+   default 0x8000
+
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select GENERIC_RISCV
+   select SUPPORT_SPL
imply CMD_DHCP
imply CMD_EXT2
imply CMD_EXT4
diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
index 702d803ad8..42c3f3deb0 100644
--- a/board/sifive/fu540/MAINTAINERS
+++ b/board/sifive/fu540/MAINTAINERS
@@ -7,3 +7,4 @@ S:  Maintained
 F: board/sifive/fu540/
 F: include/configs/sifive-fu540.h
 F: configs/sifive_fu540_defconfig
+F: configs/sifive_fu540_spl_defconfig
diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile
index 6e1862c475..f01e731913 100644
--- a/board/sifive/fu540/Makefile
+++ b/board/sifive/fu540/Makefile
@@ -3,3 +3,8 @@
 # Copyright (c) 2019 Western Digital Corporation or its affiliates.
 
 obj-y  += fu540.o
+
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+obj-y += ddrregs.o
+endif
diff --git a/board/sifive/fu540/ddrregs.c b/board/sifive/fu540/ddrregs.c
new file mode 100644
index 00..5c9c238aa1
--- /dev/null
+++ b/board/sifive/fu540/ddrregs.c
@@ -0,0 +1,625 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 SiFive, Inc
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ *   Troy Benjegerdes 
+ */
+
+#include 
+
+#include "regconfig-ctl.h"
+#include "regconfig-phy.h"
+
+u32 ddr_phy_settings[1215] = {
+   DENALI_PHY_00_DATA, DENALI_PHY_01_DATA, DENALI_PHY_02_DATA,
+   DENALI_PHY_03_DATA, DENALI_PHY_04_DATA, DENALI_PHY_05_DATA,
+   DENALI_PHY_06_DATA, DENALI_PHY_07_DATA, DENALI_PHY_08_DATA,
+   DENALI_PHY_09_DATA,
+   DENALI_PHY_10_DATA, DENALI_PHY_11_DATA, DENALI_PHY_12_DATA,
+   DENALI_PHY_13_DATA, DENALI_PHY_14_DATA, DENALI_PHY_15_DATA,
+   DENALI_PHY_16_DATA, DENALI_PHY_17_DATA, DENALI_PHY_18_DATA,
+   DENALI_PHY_19_DATA,
+   DENALI_PHY_20_DATA, DENALI_PHY_21_DATA, DENALI_PHY_22_DATA,
+   DENALI_PHY_23_DATA, DENALI_PHY_24_DATA, DENALI_PHY_25_DATA,
+   DENALI_PHY_26_DATA, DENALI_PHY_27_DATA, DENALI_PHY_28_DATA,
+   DENALI_PHY_29_DATA,
+   DENALI_PHY_30_DATA, DENALI_PHY_31_DATA, DENALI_PHY_32_DATA,
+   DENALI_PHY_33_DATA, DENALI_PHY_34_DATA, DENALI_PHY_35_DATA,
+   DENALI_PHY_36_DATA, DENALI_PHY_37_DATA, DENALI_PHY_38_DATA,
+   DENALI_PHY_39_DATA,
+   DENALI_PHY_40_DATA, DENALI_PHY_41_DATA, DENALI_PHY_42_DATA,
+   DENALI_PHY_43_DATA, DENALI_PHY_44_DATA, DENALI_PHY_45_DATA,
+   DENALI_PHY_46_DATA, DENALI_PHY_47_DATA, DENALI_PHY_48_DATA,
+   DENALI_PHY_49_DATA,
+   DENALI_PHY_50_DATA, DENALI_PHY_51_DATA, DENALI_PHY_52_DATA,
+   DENALI_PHY_53_DATA, DENALI_PHY_54_DATA, DENALI_PHY_55_DATA,
+   DENALI_PHY_56_DATA, DENALI_PHY_57_DATA, DENALI_PHY_58_DATA,
+   DENALI_PHY_59_DATA,
+   DENALI_PHY_60_DATA, DENALI_PHY_61_DATA, DENALI_PHY_62_DATA,
+   DENALI_PHY_63_DATA, 

[PATCH v2 5/9] lib: Makefile: build crc7.c when CONFIG_MMC_SPI

2020-01-17 Thread Pragnesh Patel
When build U-boot SPL, meet an issue of undefined reference to
'crc7' for drivers/mmc/mmc_spi.c, so let's compile crc7.c when
CONFIG_MMC_SPI selected.

Signed-off-by: Pragnesh Patel 
---
 lib/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Makefile b/lib/Makefile
index 6b7b9ce85c..8e3a071786 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,6 +77,7 @@ endif
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o
+obj-$(CONFIG_MMC_SPI) += crc7.o
 obj-$(CONFIG_$(SPL_TPL_)HASH_SUPPORT) += crc16.o
 obj-y += net_utils.o
 endif
-- 
2.17.1



[PATCH v2 4/9] riscv: Add _image_binary_end for SPL

2020-01-17 Thread Pragnesh Patel
For SPL_SEPARATE_BSS, Device tree will put at _image_binary_end

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/cpu/u-boot-spl.lds | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
index 955dd3106d..d0495ce248 100644
--- a/arch/riscv/cpu/u-boot-spl.lds
+++ b/arch/riscv/cpu/u-boot-spl.lds
@@ -72,6 +72,7 @@ SECTIONS
. = ALIGN(4);
 
_end = .;
+   _image_binary_end = .;
 
.bss : {
__bss_start = .;
-- 
2.17.1



[PATCH v2 2/9] Sifive: FU540: Add place-holder for FU540 clk

2020-01-17 Thread Pragnesh Patel
Added FU540 place-holder so that SoC specific values
will be kept here.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/include/asm/arch-fu540/clk.h | 14 ++
 board/sifive/fu540/Kconfig  |  3 +++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/riscv/include/asm/arch-fu540/clk.h

diff --git a/arch/riscv/include/asm/arch-fu540/clk.h 
b/arch/riscv/include/asm/arch-fu540/clk.h
new file mode 100644
index 00..b39f5b55c9
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu540/clk.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 SiFive, Inc.
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ */
+
+#ifndef _CLK_FU540_H
+#define _CLK_FU540_H
+
+/* Note: This is a placeholder header for driver compilation. */
+
+#endif
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 5ca21474de..816a135b21 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -12,6 +12,9 @@ config SYS_CPU
 config SYS_CONFIG_NAME
default "sifive-fu540"
 
+config SYS_SOC
+   default "fu540"
+
 config SYS_TEXT_BASE
default 0x8000 if !RISCV_SMODE
default 0x8020 if RISCV_SMODE
-- 
2.17.1



[PATCH v2 1/9] misc: add driver for the Sifive otp controller

2020-01-17 Thread Pragnesh Patel
Added a misc driver to handle OTP memory in FU540.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/dts/fu540-c000-u-boot.dtsi |  13 ++
 .../dts/hifive-unleashed-a00-u-boot.dtsi  |   6 +
 board/sifive/fu540/fu540.c| 113 --
 configs/sifive_fu540_defconfig|   2 +
 drivers/misc/Kconfig  |   7 +
 drivers/misc/Makefile |   1 +
 drivers/misc/ememory-otp.c| 209 ++
 7 files changed, 278 insertions(+), 73 deletions(-)
 create mode 100644 arch/riscv/dts/fu540-c000-u-boot.dtsi
 create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
 create mode 100644 drivers/misc/ememory-otp.c

diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi 
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
new file mode 100644
index 00..615a68c0e9
--- /dev/null
+++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 SiFive, Inc
+ */
+
+/ {
+   soc {
+   otp: otp@1007 {
+   compatible = "sifive,fu540-otp";
+   reg = <0x0 0x1007 0x0 0x0FFF>;
+   };
+   };
+};
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
new file mode 100644
index 00..bec0d19134
--- /dev/null
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 SiFive, Inc
+ */
+
+#include "fu540-c000-u-boot.dtsi"
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 47a2090251..3a5e74f1fb 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -10,94 +10,61 @@
 #include 
 #include 
 #include 
+#include 
 
-#ifdef CONFIG_MISC_INIT_R
-
-#define FU540_OTP_BASE_ADDR0x1007
-
-struct fu540_otp_regs {
-   u32 pa; /* Address input */
-   u32 paio;   /* Program address input */
-   u32 pas;/* Program redundancy cell selection input */
-   u32 pce;/* OTP Macro enable input */
-   u32 pclk;   /* Clock input */
-   u32 pdin;   /* Write data input */
-   u32 pdout;  /* Read data output */
-   u32 pdstb;  /* Deep standby mode enable input (active low) */
-   u32 pprog;  /* Program mode enable input */
-   u32 ptc;/* Test column enable input */
-   u32 ptm;/* Test mode enable input */
-   u32 ptm_rep;/* Repair function test mode enable input */
-   u32 ptr;/* Test row enable input */
-   u32 ptrim;  /* Repair function enable input */
-   u32 pwe;/* Write enable input (defines program cycle) */
-} __packed;
-
-#define BYTES_PER_FUSE 4
-#define NUM_FUSES  0x1000
-
-static int fu540_otp_read(int offset, void *buf, int size)
-{
-   struct fu540_otp_regs *regs = (void __iomem *)FU540_OTP_BASE_ADDR;
-   unsigned int i;
-   int fuseidx = offset / BYTES_PER_FUSE;
-   int fusecount = size / BYTES_PER_FUSE;
-   u32 fusebuf[fusecount];
-
-   /* check bounds */
-   if (offset < 0 || size < 0)
-   return -EINVAL;
-   if (fuseidx >= NUM_FUSES)
-   return -EINVAL;
-   if ((fuseidx + fusecount) > NUM_FUSES)
-   return -EINVAL;
-
-   /* init OTP */
-   writel(0x01, >pdstb); /* wake up from stand-by */
-   writel(0x01, >ptrim); /* enable repair function */
-   writel(0x01, >pce);   /* enable input */
-
-   /* read all requested fuses */
-   for (i = 0; i < fusecount; i++, fuseidx++) {
-   writel(fuseidx, >pa);
-
-   /* cycle clock to read */
-   writel(0x01, >pclk);
-   mdelay(1);
-   writel(0x00, >pclk);
-   mdelay(1);
-
-   /* read the value */
-   fusebuf[i] = readl(>pdout);
-   }
-
-   /* shut down */
-   writel(0, >pce);
-   writel(0, >ptrim);
-   writel(0, >pdstb);
-
-   /* copy out */
-   memcpy(buf, fusebuf, size);
+/*
+ * This define is a value used for error/unknown serial.
+ * If we really care about distinguishing errors and 0 is
+ * valid, we'll need a different one.
+ */
+#define ERROR_READING_SERIAL_NUMBER   0
 
-   return 0;
-}
+#ifdef CONFIG_MISC_INIT_R
 
-static u32 fu540_read_serialnum(void)
+#if CONFIG_IS_ENABLED(EMEMORY_OTP)
+static u32 otp_read_serialnum(struct udevice *dev)
 {
int ret;
u32 serial[2] = {0};
 
for (int i = 0xfe * 4; i > 0; i -= 8) {
-   ret = fu540_otp_read(i, serial, sizeof(serial));
+   ret = misc_read(dev, i, serial, sizeof(serial));
+
if (ret) {
-   printf("%s: error reading from OTP\n", __func__);
+   printf("%s: error reading serial from OTP\n", __func__);
break;
}
+
 

[PATCH v2 3/9] Sifive: FU540: Add header files for SoC

2020-01-17 Thread Pragnesh Patel
Add fu540 SoC specific header files

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/include/asm/arch-fu540/cache.h  | 42 ++
 arch/riscv/include/asm/arch-fu540/gpio.h   | 14 
 arch/riscv/include/asm/arch-fu540/otp.h| 80 +++
 arch/riscv/include/asm/arch-fu540/spi.h| 15 
 arch/riscv/include/asm/arch-fu540/uart.h   | 14 
 arch/riscv/include/asm/arch-generic/gpio.h | 32 +---
 arch/riscv/include/asm/arch-sifive/gpio.h  | 42 ++
 arch/riscv/include/asm/arch-sifive/spi.h   | 93 ++
 arch/riscv/include/asm/arch-sifive/uart.h  | 35 
 drivers/spi/spi-sifive.c   | 81 +--
 10 files changed, 339 insertions(+), 109 deletions(-)
 create mode 100644 arch/riscv/include/asm/arch-fu540/cache.h
 create mode 100644 arch/riscv/include/asm/arch-fu540/gpio.h
 create mode 100644 arch/riscv/include/asm/arch-fu540/otp.h
 create mode 100644 arch/riscv/include/asm/arch-fu540/spi.h
 create mode 100644 arch/riscv/include/asm/arch-fu540/uart.h
 create mode 100644 arch/riscv/include/asm/arch-sifive/gpio.h
 create mode 100644 arch/riscv/include/asm/arch-sifive/spi.h
 create mode 100644 arch/riscv/include/asm/arch-sifive/uart.h

diff --git a/arch/riscv/include/asm/arch-fu540/cache.h 
b/arch/riscv/include/asm/arch-fu540/cache.h
new file mode 100644
index 00..e84d56774c
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu540/cache.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 SiFive, Inc.
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ */
+
+#ifndef _CACHE_FU540_H
+#define _CACHE_FU540_H
+
+/* Register offsets */
+#define CCACHE_INFO 0x000
+#define CCACHE_ENABLE   0x008
+#define CCACHE_INJECT   0x040
+#define CCACHE_META_FIX 0x100
+#define CCACHE_DATA_FIX 0x140
+#define CCACHE_DATA_FAIL0x160
+#define CCACHE_FLUSH64  0x200
+#define CCACHE_FLUSH32  0x240
+#define CCACHE_WAYS 0x800
+
+/* Bytes inside the INFO field */
+#define CCACHE_INFO_BANKS   0
+#define CCACHE_INFO_WAYS1
+#define CCACHE_INFO_LG_SETS 2
+#define CCACHE_INFO_LG_BLOCKBYTES   3
+
+/* INJECT types */
+#define CCACHE_ECC_TOGGLE_DATA  0x0
+#define CCACHE_ECC_TOGGLE_META  0x1
+
+/* Offsets per FIX/FAIL */
+#define CCACHE_ECC_ADDR 0x0
+#define CCACHE_ECC_COUNT0x8
+
+/* Interrupt Number offsets from Base */
+#define CCACHE_INT_META_FIX 0
+#define CCACHE_INT_DATA_FIX 1
+#define CCACHE_INT_DATA_FAIL2
+
+#endif /* _CACHE_FU540_H */
diff --git a/arch/riscv/include/asm/arch-fu540/gpio.h 
b/arch/riscv/include/asm/arch-fu540/gpio.h
new file mode 100644
index 00..8210ff8551
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu540/gpio.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 SiFive, Inc.
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ */
+
+#ifndef _GPIO_FU540_H
+#define _GPIO_FU540_H
+
+#include 
+
+#endif /* _GPIO_FU540_H */
diff --git a/arch/riscv/include/asm/arch-fu540/otp.h 
b/arch/riscv/include/asm/arch-fu540/otp.h
new file mode 100644
index 00..a498593d39
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu540/otp.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 SiFive, Inc.
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ *   Troy Benjegerdes 
+ */
+
+#ifndef _OTP_FU540_H
+#define _OTP_FU540_H
+
+/* Register offsets */
+#define EMEMORYOTP_PA  0x00
+#define EMEMORYOTP_PAIO0x04
+#define EMEMORYOTP_PAS 0x08
+#define EMEMORYOTP_PCE 0x0C
+#define EMEMORYOTP_PCLK0x10
+#define EMEMORYOTP_PDIN0x14
+#define EMEMORYOTP_PDOUT   0x18
+#define EMEMORYOTP_PDSTB   0x1C
+#define EMEMORYOTP_PPROG   0x20
+#define EMEMORYOTP_PTC 0x24
+#define EMEMORYOTP_PTM 0x28
+#define EMEMORYOTP_PTM_REP 0x2C
+#define EMEMORYOTP_PTR 0x30
+#define EMEMORYOTP_PTRIM   0x34
+#define EMEMORYOTP_PWE 0x38
+
+/* Timing delays (in us)
+ * MIN indicates that there is no maximum.
+ * TYP indicates that there is a maximum
+ * that should not be exceeded.
+ * When the minimums are < 1us, I just put 1us.
+ */
+
+#define EMEMORYOTP_MIN_TVDS1
+#define EMEMORYOTP_MIN_TSAS2
+#define EMEMORYOTP_MIN_TTAS50
+#define EMEMORYOTP_MIN_TTAH1
+#define EMEMORYOTP_MIN_TASH1
+#define EMEMORYOTP_MIN_TMS 1
+#define EMEMORYOTP_MIN_TCS 10
+#define EMEMORYOTP_MIN_TMH 1
+#define EMEMORYOTP_MIN_TAS 50
+
+#define EMEMORYOTP_MAX_TCD 1
+#define EMEMORYOTP_MIN_TKH 1
+
+/* Note: This has an upper limit of 100 */
+#define EMEMORYOTP_MIN_TCSP10
+#define EMEMORYOTP_TYP_TCSP11
+
+/* This has an upper limit of 20 */
+#define EMEMORYOTP_MIN_TPPS5
+#define EMEMORYOTP_TYP_TPPS6
+
+/* This has an upper limit of 20 */
+#define EMEMORYOTP_MIN_TPPH1
+#define EMEMORYOTP_TYP_TPPH2
+
+/* This has 

[PATCH v2 0/9] RISC-V SiFive FU540 support SPL

2020-01-17 Thread Pragnesh Patel
This series add support for SPL to FU540. This series depends on
https://patchwork.ozlabs.org/patch/1196703/
(riscv: dts: Add hifive-unleashed-a00 dts from Linux)

U-Boot SPL can boot from L2 LIM (0x0800_) and jump to
OpenSBI(FW_DYNAMIC firmware) and U-Boot proper from MMC devices.

How to test this patch:
1) Go to OpenSBI-dir : make PLATFORM=sifive/fu540 O=build_dir I=install_dir 
FW_DYNAMIC=y install
2) cp install_dir/platform/sifive/fu540/firmware/fw_dynamic.bin /
3) Change to u-boot-dir
4) make sifive_fu540_spl_defconfig
5) make all
6) SD card partition which contains "fw_payload.bin" previously
/dev/sdc1 - SiFive bare-metal (or s ->5202)
   should be now of
/dev/sdc1 - 8300  Linux filesystem.
6) sudo dd if=spl/u-boot-spl.bin of=/dev/sdc4 bs=1M
7) sudo dd if=u-boot.itb of=/dev/sdc1 bs=1M

Following are the boot messages on FU540 five cores SMP platform:

U-Boot SPL 2020.01-00177-ga3fabe50f9 (Jan 17 2020 - 14:20:12 +0530)
Trying to boot from MMC1


U-Boot 2020.01-00177-ga3fabe50f9 (Jan 17 2020 - 14:20:12 +0530)

CPU:   rv64imafdc
Model: SiFive HiFive Unleashed A00
DRAM:  8 GiB
MMC:   spi@1005:mmc@0: 0
In:serial@1001
Out:   serial@1001
Err:   serial@1001
Board serial number should not be 0 !!
Net:   
Warning: ethernet@1009 (eth0) using random MAC address - c6:3a:5b:53:64:8b
eth0: ethernet@1009
Hit any key to stop autoboot:  0 
=> setenv serverip 172.16.35.74;setenv ipaddr 172.16.35.40;tftpboot 0x8300 
fit.itb;bootm 0x8300
ethernet@1009: PHY present at 0
ethernet@1009: Starting autonegotiation...
ethernet@1009: Autonegotiation complete
ethernet@1009: link up, 100Mbps full-duplex (lpa: 0x41e1)
Using ethernet@1009 device
TFTP from server 172.16.35.74; our IP address is 172.16.35.40
Filename 'fit.itb'.
Load address: 0x8300
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 ###
 879.9 KiB/s
done
Bytes transferred 

Re: [PATCH 3/3] stm32mp1: split board and SOC support for STM32MP15x family

2020-01-17 Thread Patrice CHOTARD
Hi

On 1/13/20 3:17 PM, Patrick Delaunay wrote:
> Split the board and SOC support for STM32MP15x family and
> prepare the introduction of new boards with STM32MP15x.
>
> This path define the 2 configurations:
> - STM32MP15x: STM32MP15x soc support (new)
> - TARGET_ST_STM32MP15x: STMicroelectronics board support (choice)
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/dts/Makefile   |  2 +-
>  arch/arm/mach-stm32mp/Kconfig   | 32 +
>  board/st/common/Kconfig |  3 ++-
>  board/st/stm32mp1/Kconfig   |  7 +--
>  board/st/stm32mp1/stm32mp1.c|  2 +-
>  configs/stm32mp15_basic_defconfig   |  2 +-
>  configs/stm32mp15_optee_defconfig   |  2 +-
>  configs/stm32mp15_trusted_defconfig |  2 +-
>  8 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 983e235f44..6aabdabdaa 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -856,7 +856,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
>  
>  dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  
> -dtb-$(CONFIG_TARGET_STM32MP1) += \
> +dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
>   stm32mp157c-dk2.dtb \
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index bf8a18a0c3..137178aa45 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -33,8 +33,8 @@ config SYS_MALLOC_LEN
>  config ENV_SIZE
>   default 0x2000
>  
> -config TARGET_STM32MP1
> - bool "Support stm32mp1xx"
> +config STM32MP15x
> + bool "Support STMicroelectronics STM32MP15x Soc"
>   select ARCH_SUPPORT_PSCI if !STM32MP1_TRUSTED
>   select CPU_V7A
>   select CPU_V7_HAS_NONSEC if !STM32MP1_TRUSTED
> @@ -45,19 +45,35 @@ config TARGET_STM32MP1
>   select STM32_RESET
>   select STM32_SERIAL
>   select SYS_ARCH_TIMER
> + imply SYSRESET_PSCI if STM32MP1_TRUSTED
> + imply SYSRESET_SYSCON if !STM32MP1_TRUSTED
> + help
> + support of STMicroelectronics SOC STM32MP15x family
> + STM32MP157, STM32MP153 or STM32MP151
> + STMicroelectronics MPU with core ARMv7
> + dual core A7 for STM32MP157/3, monocore for STM32MP151
> + target all the STMicroelectronics board with SOC STM32MP1 family
> +
> +choice
> + prompt "STM32MP15x board select"
> + optional
> +
> +config TARGET_ST_STM32MP15x
> + bool "STMicroelectronics STM32MP15x boards"
> + select STM32MP15x
>   imply BOOTCOUNT_LIMIT
>   imply CMD_BOOTCOUNT
>   imply CMD_CLS if CMD_BMP
>   imply DISABLE_CONSOLE
>   imply PRE_CONSOLE_BUFFER
>   imply SILENT_CONSOLE
> - imply SYSRESET_PSCI if STM32MP1_TRUSTED
> - imply SYSRESET_SYSCON if !STM32MP1_TRUSTED
>   help
> - target STMicroelectronics SOC STM32MP1 family
> - STM32MP157, STM32MP153 or STM32MP151
> - STMicroelectronics MPU with core ARMv7
> - dual core A7 for STM32MP157/3, monocore for STM32MP151
> + target the STMicroelectronics board with SOC STM32MP15x
> + managed by board/st/stm32mp1:
> + Evalulation board (EV1) or Discovery board (DK1 and DK2).
> + The difference between board are managed with devicetree
> +
> +endchoice
>  
>  config STM32MP1_TRUSTED
>   bool "Support trusted boot with TF-A"
> diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
> index 1824087afc..af01ca4891 100644
> --- a/board/st/common/Kconfig
> +++ b/board/st/common/Kconfig
> @@ -1,6 +1,7 @@
>  config CMD_STBOARD
>   bool "stboard - command for OTP board information"
> - default y
> + depends on ARCH_STM32MP
> + default y if TARGET_ST_STM32MP15x
>   help
> This compile the stboard command to
> read and write the board in the OTP.
> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> index 89fc562746..c5ab7553d4 100644
> --- a/board/st/stm32mp1/Kconfig
> +++ b/board/st/stm32mp1/Kconfig
> @@ -1,4 +1,4 @@
> -if TARGET_STM32MP1
> +if TARGET_ST_STM32MP15x
>  
>  config SYS_BOARD
>   default "stm32mp1"
> @@ -9,10 +9,5 @@ config SYS_VENDOR
>  config SYS_CONFIG_NAME
>   default "stm32mp1"
>  
> -config TARGET_STM32MP157C_DK2
> - bool "support of STMicroelectronics STM32MP157C-DK2 Discovery Board"
> - default y
> -
>  source "board/st/common/Kconfig"
> -
>  endif
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 1d4a54c902..4e298dabcb 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -607,7 +607,7 @@ error:
>  
>  static bool board_is_dk2(void)
>  {
> - if (CONFIG_IS_ENABLED(TARGET_STM32MP157C_DK2) &&
> + if (CONFIG_IS_ENABLED(TARGET_ST_STM32MP15x) &&
>   of_machine_is_compatible("st,stm32mp157c-dk2"))
>   return true;
>  
> diff --git 

Re: [Uboot-stm32] [PATCH 1/3] stm32mp1: move stboard command in board/st/common directory

2020-01-17 Thread Patrice CHOTARD
Hi Patrick

On 1/13/20 3:17 PM, Patrick Delaunay wrote:
> Move the ST command in board/st/common, as this command is only used
> by ST board. Prepare the support in U-Boot of boards with STM32MP15x
> SOC but not STMicroelectronics.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/common/Kconfig | 6 ++
>  board/st/common/MAINTAINERS | 6 ++
>  board/st/common/Makefile| 6 ++
>  board/st/{stm32mp1 => common}/cmd_stboard.c | 3 +++
>  board/st/stm32mp1/Kconfig   | 9 ++---
>  board/st/stm32mp1/Makefile  | 1 -
>  6 files changed, 23 insertions(+), 8 deletions(-)
>  create mode 100644 board/st/common/Kconfig
>  create mode 100644 board/st/common/MAINTAINERS
>  create mode 100644 board/st/common/Makefile
>  rename board/st/{stm32mp1 => common}/cmd_stboard.c (98%)
>
> diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
> new file mode 100644
> index 00..1824087afc
> --- /dev/null
> +++ b/board/st/common/Kconfig
> @@ -0,0 +1,6 @@
> +config CMD_STBOARD
> + bool "stboard - command for OTP board information"
> + default y
> + help
> +   This compile the stboard command to
> +   read and write the board in the OTP.
> diff --git a/board/st/common/MAINTAINERS b/board/st/common/MAINTAINERS
> new file mode 100644
> index 00..3b02f4ab98
> --- /dev/null
> +++ b/board/st/common/MAINTAINERS
> @@ -0,0 +1,6 @@
> +ST BOARDS
> +M:   Patrick Delaunay 
> +L:   uboot-st...@st-md-mailman.stormreply.com (moderated for non-subscribers)
> +T:   git https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> +S:   Maintained
> +F:   board/st/common/
> diff --git a/board/st/common/Makefile b/board/st/common/Makefile
> new file mode 100644
> index 00..8553606b90
> --- /dev/null
> +++ b/board/st/common/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +#
> +# Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> +#
> +
> +obj-$(CONFIG_CMD_STBOARD) += cmd_stboard.o
> diff --git a/board/st/stm32mp1/cmd_stboard.c b/board/st/common/cmd_stboard.c
> similarity index 98%
> rename from board/st/stm32mp1/cmd_stboard.c
> rename to board/st/common/cmd_stboard.c
> index 04352ae8ed..e994a88e71 100644
> --- a/board/st/stm32mp1/cmd_stboard.c
> +++ b/board/st/common/cmd_stboard.c
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
>   */
>  
> +#ifndef CONFIG_SPL_BUILD
>  #include 
>  #include 
>  #include 
> @@ -143,3 +144,5 @@ U_BOOT_CMD(stboard, 6, 0, do_stboard,
>  "  - Variant: 1 ... 15\n"
>  "  - Revision: A...O\n"
>  "  - BOM: 1...15\n");
> +
> +#endif
> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> index 4fa2360b4f..9f985e5775 100644
> --- a/board/st/stm32mp1/Kconfig
> +++ b/board/st/stm32mp1/Kconfig
> @@ -15,15 +15,10 @@ config ENV_SECT_SIZE
>  config ENV_OFFSET
>   default 0x28 if ENV_IS_IN_SPI_FLASH
>  
> -config CMD_STBOARD
> - bool "stboard - command for OTP board information"
> - default y
> - help
> -   This compile the stboard command to
> -   read and write the board in the OTP.
> -
>  config TARGET_STM32MP157C_DK2
>   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery Board"
>   default y
>  
> +source "board/st/common/Kconfig"
> +
>  endif
> diff --git a/board/st/stm32mp1/Makefile b/board/st/stm32mp1/Makefile
> index 3c6c035b11..8188075b1a 100644
> --- a/board/st/stm32mp1/Makefile
> +++ b/board/st/stm32mp1/Makefile
> @@ -7,7 +7,6 @@ ifdef CONFIG_SPL_BUILD
>  obj-y += spl.o
>  else
>  obj-y += stm32mp1.o
> -obj-$(CONFIG_CMD_STBOARD) += cmd_stboard.o
>  endif
>  
>  obj-y += board.o

Reviewed-by: Patrice Chotard 

Thanks


Re: [Uboot-stm32] [PATCH 2/3] board: stm32mp1: move CONFIG_ENV_XXX in defconfig

2020-01-17 Thread Patrice CHOTARD
Hi

On 1/13/20 3:17 PM, Patrick Delaunay wrote:
> Move CONFIG_ENV_SECT_SIZE and CONFIG_ENV_OFFSET in stm32mp15_*_defconfig
> for ST board with NOR support (STM32MP15xx-EV1 boards)
> - CONFIG_SECT_SIZE values = the max supported NOR erase size (256KB)
> - CONFIG_ENV_OFFSET = offset for NOR (ENV_IS_IN_SPI_FLASH)
>
> This Patch prepares the U-Boot support of boards with STM32MP15x SOC
> not provided by STMicroelectronics.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/stm32mp1/Kconfig   | 6 --
>  configs/stm32mp15_basic_defconfig   | 2 ++
>  configs/stm32mp15_optee_defconfig   | 2 ++
>  configs/stm32mp15_trusted_defconfig | 2 ++
>  4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> index 9f985e5775..89fc562746 100644
> --- a/board/st/stm32mp1/Kconfig
> +++ b/board/st/stm32mp1/Kconfig
> @@ -9,12 +9,6 @@ config SYS_VENDOR
>  config SYS_CONFIG_NAME
>   default "stm32mp1"
>  
> -config ENV_SECT_SIZE
> - default 0x4 if ENV_IS_IN_SPI_FLASH
> -
> -config ENV_OFFSET
> - default 0x28 if ENV_IS_IN_SPI_FLASH
> -
>  config TARGET_STM32MP157C_DK2
>   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery Board"
>   default y
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 713a7e6c57..8f0c7e9339 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -1,6 +1,8 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_STM32MP=y
>  CONFIG_SYS_MALLOC_F_LEN=0x3000
> +CONFIG_ENV_SECT_SIZE=0x4
> +CONFIG_ENV_OFFSET=0x28
>  CONFIG_SPL_MMC_SUPPORT=y
>  CONFIG_SPL=y
>  CONFIG_TARGET_STM32MP1=y
> diff --git a/configs/stm32mp15_optee_defconfig 
> b/configs/stm32mp15_optee_defconfig
> index f9161fd7d1..b036bb738b 100644
> --- a/configs/stm32mp15_optee_defconfig
> +++ b/configs/stm32mp15_optee_defconfig
> @@ -1,6 +1,8 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_STM32MP=y
>  CONFIG_SYS_MALLOC_F_LEN=0x3000
> +CONFIG_ENV_SECT_SIZE=0x4
> +CONFIG_ENV_OFFSET=0x28
>  CONFIG_TARGET_STM32MP1=y
>  CONFIG_STM32MP1_OPTEE=y
>  CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index a5ea528ae3..956ba90153 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -1,6 +1,8 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_STM32MP=y
>  CONFIG_SYS_MALLOC_F_LEN=0x3000
> +CONFIG_ENV_SECT_SIZE=0x4
> +CONFIG_ENV_OFFSET=0x28
>  CONFIG_TARGET_STM32MP1=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y


Reviewed-by: Patrice Chotard 

Thanks


RE: [PATCH V3] stm32mp1: configs: Make all boot devices in distro boot conditional

2020-01-17 Thread Patrick DELAUNAY
Hi

> From: Marek Vasut 
> Sent: lundi 13 janvier 2020 11:46
> To: Patrick DELAUNAY ; u-boot@lists.denx.de
> Cc: Patrice CHOTARD 
> Subject: Re: [PATCH V3] stm32mp1: configs: Make all boot devices in distro 
> boot
> conditional
> Importance: High
> 
> On 1/13/20 11:44 AM, Patrick DELAUNAY wrote:
> > Hi Marek,
> 
> Hi,
> 
> >> From: Marek Vasut 
> >> Sent: vendredi 10 janvier 2020 01:27
> >>
> >> Not all systems have all the boot devices enabled, e.g. not all
> >> systems have MTD devices and thus do not enable UBI. Make all the
> >> boot devices in the distro bootcmd conditional to avoid failures.
> >
> > Reviewed-by: Patrick Delaunay 
> 
> Are you planning to pick those up ?

Applied to u-boot-stm32/master, thanks!

Regards
Patrick





RE: [PATCH V2] ARM: stm32: Allow overriding setup_mac_address()

2020-01-17 Thread Patrick DELAUNAY
Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 16:52
> 
> Let board code override setup_mac_address(), which is useful e.g. if the board
> derives the MAC address from another source, like an I2C EEPROM.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---

Applied to u-boot-stm32/master, thanks!

Regards
Patrick



RE: [Uboot-stm32] [PATCH] stm32mp: remove redundant SYS_TEXT_BASE prompt

2020-01-17 Thread Patrick DELAUNAY
Hi Thomas,

> From: Uboot-stm32  On
> Behalf Of Thomas Hebb
> 
> The main prompt for this (defined in /Kconfig) is visible at all times, which 
> means
> there's no reason to have an additional, machine-specific prompt to set the 
> same
> option.
> 
> Signed-off-by: Thomas Hebb 
> ---

Acked-by: Patrick Delaunay 

Applied to u-boot-stm32/master, thanks!

Regards
Patrick 


Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL

2020-01-17 Thread Marek Vasut
On 1/17/20 3:33 AM, Peng Fan wrote:
> Hi Marek,

Hi,

>> Subject: Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset
>> driver for SPL
>>
>> On 1/16/20 3:21 AM, Peng Fan wrote:
>>
>> Hello Peng,
>>
 Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset
 driver for SPL

>>>
>>> NAK, this will not work on i.MX8MM/N.
>>>
>>> Currently sysreset psci is enabled, however psci will not work for
>>> SPL, because SPL boots before BL31.
>>
>> Thank you for the constructive feedback.
>>
>> So basically , what we need is a real sysreset driver for iMX8MM , which can
>> work with bare-bones hardware interface, that is, poking some register,
>> correct ?
> 
> Yes.
> 
>>
>> So, either you or Claudius needs to implement a driver in drivers/sysreset,
>> which will bind in SPL and if needed, do some writel() into some registers to
>> reset the board, correct ?
> 
> Yes.
> 
>>
>> Because, I believe we can both agree that dumping such ad-hoc code which
>> implements reset in board code is not the right way, esp. nowadays with all
>> the DM/DT stuff in.
> 
> Alought we still have ocram space, but our SPL is huge now, 100KB+

How so ?

How much does DM sysreset add to that ?


Re: [PATCH v2 17/21] Makefile: add support to generate LZMA compressed u-boot image

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:46 schrieb Weijie Gao:
> This patch adds support for generating LZMA compressed u-boot image.
> The compressed image can be used for SPL to reduce the size of the u-boot
> binary.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: none
> ---
>  Makefile | 13 +
>  1 file changed, 13 insertions(+)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 15/21] mips: add an option to enable u_boot_list section for SPL loaders in u-boot-spl.lds

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:46 schrieb Weijie Gao:
> u_boot_list is not only used by DM, but also by some SPL image load methods
> such as spl_nor.c.
> 
> This patch adds an option CONFIG_SPL_LOADER_SUPPORT in conjunction with
> CONFIG_SPL_DM surrounding the u_boot_list section to make sure SPL image
> loaders can be correctly built into u-boot SPL without DM enabled.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: uses a new config instead of removing CONFIG_SPL_DM
> ---
>  arch/mips/cpu/u-boot-spl.lds | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 14/21] mips: enable support for appending dtb to spl binary

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:46 schrieb Weijie Gao:
> If CONFIG_SPL_OF_CONTROL is enabled for SPL and CONFIG_OF_SEPARATE is also
> enabled, the dtb will be appended to the u-boot-spl.bin.
> 
> When calling dm_init_and_scan() in SPL, fdtdec_setup() will try to locate
> dtb at the end of u-boot-spl.bin, by referencing to _image_binary_end.
> 
> However _image_binary_end is currently missing in u-boot-spl.lds.
> This patch adds _image_binary_end to u-boot-spl.lds to make sure linking
> u-boot-spl will not fail.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: newly added
> ---
>  arch/mips/cpu/u-boot-spl.lds | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 08/21] mips: add a mtmips-specific field to architecture-specific global data

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:45 schrieb Weijie Gao:
> SoCs of mtmips can use different CPU frequencies depending on the HW/SW
> configurations. For example mt7628 uses 580MHz clock if the input xtal
> frequency is 40MHz, and 575MHz clock if the xtal is 25MHz. Upon cold boot
> the CPU uses the xtal frequency directly.
> 
> So hardcoding the timer frequency (half of the CPU frequency) in
> CONFIG_SYS_MIPS_TIMER_FREQ is not a good idea for this case.
> 
> This patch adds a mtmips-specific field timer_freq to arch_global_data.
> This field will be used later in mtmips-specific get_tbclk() to provide
> accurate timer frequency in different boot stage.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: splitted from another patch.
> ---
>  arch/mips/include/asm/global_data.h | 3 +++
>  1 file changed, 3 insertions(+)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 07/21] configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips boards

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:45 schrieb Weijie Gao:
> This patch enables CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips
> boards.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: Splitted from another patch.
> ---
>  configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 +
>  configs/gardena-smart-gateway-mt7688_defconfig | 1 +
>  configs/linkit-smart-7688-ram_defconfig| 1 +
>  configs/linkit-smart-7688_defconfig| 1 +
>  4 files changed, 4 insertions(+)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 06/21] mips: mtmips: make use of sysreset-resetctrl for mt7628 soc

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:45 schrieb Weijie Gao:
> This patch replaces sysreset-syscon with sysreset-resetctrl for mt7628 soc.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: splitted from another patch.
> ---
>  arch/mips/dts/mt7628a.dtsi | 10 +-
>  arch/mips/mach-mtmips/Kconfig  |  1 +
>  configs/gardena-smart-gateway-mt7688-ram_defconfig |  1 -
>  configs/gardena-smart-gateway-mt7688_defconfig |  1 -
>  configs/linkit-smart-7688-ram_defconfig|  1 -
>  configs/linkit-smart-7688_defconfig|  1 -
>  6 files changed, 6 insertions(+), 9 deletions(-)
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 05/21] sysreset: add reset controller based reboot driver

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:45 schrieb Weijie Gao:
> Some chips provide their sysreset function in reset controller, which is
> normally a bit written to 1 to perform the sysreset.
> 
> This patch adds a new sysreset driver to take advantage of it.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1: none
> ---
>  drivers/sysreset/Kconfig |  6 
>  drivers/sysreset/Makefile|  1 +
>  drivers/sysreset/sysreset_resetctl.c | 48 
>  3 files changed, 55 insertions(+)
>  create mode 100644 drivers/sysreset/sysreset_resetctl.c
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel


Re: [PATCH v2 01/21] mips: add support to restore exception vector base before booting linux

2020-01-17 Thread Daniel Schwierzeck



Am 17.01.20 um 08:45 schrieb Weijie Gao:
> In U-Boot the exception vector base will be moved to top of memory, to be
> used to display register dump when exception occurs.
> 
> But some old linux kernel does not honor the base set in CP0_EBASE. A
> modified exception vector base will cause kernel crash.
> 
> This patch adds an option to enable reset exception vector base to its
> previous value, or a user configured value before booting linux kernel.
> 
> Signed-off-by: Weijie Gao 
> ---
> Changes since v1:
>   Moved core operations to trap_restore() in arch/mips/lib/traps.c.
>   Save previous ebase instead of using 0x8000 directly.
>   Add options to use customized ebase.
> ---
>  arch/mips/Kconfig   | 30 +
>  arch/mips/include/asm/u-boot-mips.h |  2 ++
>  arch/mips/lib/bootm.c   |  3 +++
>  arch/mips/lib/traps.c   | 19 ++
>  4 files changed, 54 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index a3ae603044..5e20feeefb 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -287,6 +287,36 @@ config MIPS_RELOCATION_TABLE_SIZE
>  
> If unsure, leave at the default value.
>  
> +config RESTORE_EXCEPTION_VECTOR_BASE
> + bool "Restore exception vector base before booting linux kernel"
> + default n
> + help
> +   In U-Boot the exception vector base will be moved to top of memory,
> +   to be used to display register dump when exception occurs.
> +   But some old linux kernel does not honor the base set in CP0_EBASE.
> +   A modified exception vector base will cause kernel crash.
> +
> +   This option will restore the exception vector base to its previous
> +   value.
> +
> +   If unsure, say N.
> +
> +config OVERRIDE_EXCEPTION_VECTOR_BASE
> + bool "Override the exception vector base to be restored"
> + depends on RESTORE_EXCEPTION_VECTOR_BASE
> + default n
> + help
> +   Enable this option if you want to use a different exception vector
> +   base rather than the previously saved one.
> +
> +config NEW_EXCEPTION_VECTOR_BASE
> + hex "New exception vector base"
> + depends on OVERRIDE_EXCEPTION_VECTOR_BASE
> + range 0x8000 0xb000
> + default 0x8000
> + help
> +   The exception vector base to be restored before booting linux kernel
> +
>  endmenu
>  
>  menu "OS boot interface"
> diff --git a/arch/mips/include/asm/u-boot-mips.h 
> b/arch/mips/include/asm/u-boot-mips.h
> index 88438b9576..8b37cc4029 100644
> --- a/arch/mips/include/asm/u-boot-mips.h
> +++ b/arch/mips/include/asm/u-boot-mips.h
> @@ -9,4 +9,6 @@ void except_vec_ejtag_debug(void);
>  
>  int arch_misc_init(void);
>  
> +void trap_restore(void);
> +
>  #endif /* _U_BOOT_MIPS_H_ */
> diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
> index 8c0d7672f2..f1db6d23b8 100644
> --- a/arch/mips/lib/bootm.c
> +++ b/arch/mips/lib/bootm.c
> @@ -294,6 +294,9 @@ static void boot_jump_linux(bootm_headers_t *images)
>   bootstage_report();
>  #endif
>  
> + if (CONFIG_IS_ENABLED(RESTORE_EXCEPTION_VECTOR_BASE))
> + trap_restore();
> +
>   if (images->ft_len)
>   kernel(-2, (ulong)images->ft_addr, 0, 0);
>   else
> diff --git a/arch/mips/lib/traps.c b/arch/mips/lib/traps.c
> index 6fe8ebd16b..20f45fc4ed 100644
> --- a/arch/mips/lib/traps.c
> +++ b/arch/mips/lib/traps.c
> @@ -19,6 +19,8 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +static unsigned long saved_ebase;
> +
>  static void show_regs(const struct pt_regs *regs)
>  {
>   const int field = 2 * sizeof(unsigned long);
> @@ -101,7 +103,24 @@ void trap_init(ulong reloc_addr)
>   set_handler(0x180, _vec3_generic, 0x80);
>   set_handler(0x280, _vec_ejtag_debug, 0x80);
>  
> + saved_ebase = read_c0_ebase() & 0xf000;
> +
>   write_c0_ebase(ebase);
>   clear_c0_status(ST0_BEV);
>   execution_hazard_barrier();
>  }
> +
> +void trap_restore(void)
> +{
> + set_c0_status(ST0_BEV);
> + execution_hazard_barrier();
> +
> +#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
> + write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
> +#else
> + write_c0_ebase(saved_ebase);
> +#endif
> +
> + clear_c0_status(ST0_BEV);
> + execution_hazard_barrier();
> +}
> 

looks actually good now, thanks. But now I'm thinking that it should be
enough to simply set ST0_BEV to use the CPU's default EBase. Restoring
the original EBase and clearing ST0_BEV again seems redundant. How about
this?

void trap_restore(void)
{
set_c0_status(ST0_BEV);
execution_hazard_barrier();

#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
clear_c0_status(ST0_BEV);
execution_hazard_barrier();
#endif
}

-- 
- Daniel


Re: [PATCH] mx7ulp: soc: s_init should only be executed once

2020-01-17 Thread Jorge Ramirez-Ortiz, Gmail
On 17/01/20 08:53:03, Fabio Estevam wrote:
> Hi Jorge,
> 
> On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz  
> wrote:
> >
> > On SPL enabled systems, the current s_init code (wdog, clock and ldo
> > init) is executed twice (by SPL and u-boot). This is not necessary and
> > might lead to boot issues (ie, starting PMC1 when it is already running).
> >
> > Signed-off-by: Jorge Ramirez-Ortiz 
> 
> The target I use to test LDO-enabled mode does not use SPL, so that's
> why I did not notice the problem.
> 
> Thanks for the fix:

Hi Favio,

sorry I forgot to mention: this does not fix the issue I see when executing the 
LDO init code - that still locks when run from SPL or U-Boot.
This commit is just because I noticed that s_init was being called twice (for 
SPL and U-Boot)  and I dont think it makes sense.

> 
> Reviewed-by: Fabio Estevam 


[PATCH v2 3/3] clk: imx: pllv3: fix potential 'divide by zero' in av_set_rate()

2020-01-17 Thread Giulio Benetti
Guard 'parent_rate==0' to prevent 'divide by zero' issue in
clk_pplv3_av_set_rate(). If it is 0, let's return with -EINVAL.

Signed-off-by: Giulio Benetti 
---
V1->V2
* check only if parent_rate==0, as signalled by Adam
---
 drivers/clk/imx/clk-pllv3.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 72e6750615..0cdb9df45d 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -176,13 +176,19 @@ static ulong clk_pllv3_av_set_rate(struct clk *clk, ulong 
rate)
 {
struct clk_pllv3 *pll = to_clk_pllv3(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
-   unsigned long min_rate = parent_rate * 27;
-   unsigned long max_rate = parent_rate * 54;
+   unsigned long min_rate;
+   unsigned long max_rate;
u32 val, div;
u32 mfn, mfd = 100;
u32 max_mfd = 0x3FFF;
u64 temp64;
 
+   if (parent_rate == 0)
+   return -EINVAL;
+
+   min_rate = parent_rate * 27;
+   max_rate = parent_rate * 54;
+
if (rate < min_rate || rate > max_rate)
return -EINVAL;
 
-- 
2.20.1



[PATCH v2 0/3] fix pllv3 defects reported by Coverity

2020-01-17 Thread Giulio Benetti
V1->V2
* check only if parent_rate==0, as signalled by Adam

Giulio Benetti (3):
  clk: imx: pllv3: fix potential 'divide by zero' in sys_get_rate()
  clk: imx: pllv3: fix potential 'divide by zero' in av_get_rate()
  clk: imx: pllv3: fix potential 'divide by zero' in av_set_rate()

 drivers/clk/imx/clk-pllv3.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

-- 
2.20.1



[PATCH v2 1/3] clk: imx: pllv3: fix potential 'divide by zero' in sys_get_rate()

2020-01-17 Thread Giulio Benetti
Guard 'parent_rate==0' to prevent 'divide by zero' issue in
clk_pplv3_sys_get_rate(). If it is 0, let's return with -EINVAL.

Signed-off-by: Giulio Benetti 
---
V1->V2
* check only if parent_rate==0, as signalled by Adam
---
 drivers/clk/imx/clk-pllv3.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index fc16416d5f..a540a5b68c 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -121,10 +121,16 @@ static ulong clk_pllv3_sys_set_rate(struct clk *clk, 
ulong rate)
 {
struct clk_pllv3 *pll = to_clk_pllv3(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
-   unsigned long min_rate = parent_rate * 54 / 2;
-   unsigned long max_rate = parent_rate * 108 / 2;
+   unsigned long min_rate;
+   unsigned long max_rate;
u32 val, div;
 
+   if (parent_rate == 0)
+   return -EINVAL;
+
+   min_rate = parent_rate * 54 / 2;
+   max_rate = parent_rate * 108 / 2;
+
if (rate < min_rate || rate > max_rate)
return -EINVAL;
 
-- 
2.20.1



[PATCH v2 2/3] clk: imx: pllv3: fix potential 'divide by zero' in av_get_rate()

2020-01-17 Thread Giulio Benetti
Guard 'mfd==0' to prevent 'divide by zero' issue in
clk_pplv3_av_get_rate(). If it is 0, let's return with EIO since mfd
should never be 0 at all.

Signed-off-by: Giulio Benetti 
---
V1->V2
* improved a little commit log
---
 drivers/clk/imx/clk-pllv3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index a540a5b68c..72e6750615 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -163,6 +163,9 @@ static ulong clk_pllv3_av_get_rate(struct clk *clk)
u32 div = readl(pll->base) & pll->div_mask;
u64 temp64 = (u64)parent_rate;
 
+   if (mfd == 0)
+   return -EIO;
+
temp64 *= mfn;
do_div(temp64, mfd);
 
-- 
2.20.1



Double free vulnerability in do_rename_gpt_parts

2020-01-17 Thread Jordy
Hello U-Boot lists!

I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function 
do_rename_gpt_parts().

On line 702 the partition_list is being free'd if ret is smaller than 0.
If the return value is not -ENOMEM it will go to the out: label and free the 
partition_list again.

Double freeing may result in a write-what-where condition, allowing an attacker 
to execute arbitrary code.

My advice would be to not free the parition_list on line 702 as nothing is 
being done with it there afterwards anyway and leave your clean_up in the out: 
label :)

Kind Regards,

Jordy Zomer


[PATCH] mx7ulp_evk_plugin: Disable CONFIG_NET

2020-01-17 Thread Fabio Estevam
Currently the following build warning is seen:

= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
===

Since the mx7ulp-evk board does not have networking support, explicitly
disable networking.

Signed-off-by: Fabio Estevam 
---
 configs/mx7ulp_evk_plugin_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx7ulp_evk_plugin_defconfig 
b/configs/mx7ulp_evk_plugin_defconfig
index 1c37d6bc02..54ff93ea5e 100644
--- a/configs/mx7ulp_evk_plugin_defconfig
+++ b/configs/mx7ulp_evk_plugin_defconfig
@@ -17,6 +17,7 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx7ulp-evk"
 CONFIG_ENV_IS_IN_MMC=y
+# CONFIG_NET is not set
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_GPIO=y
-- 
2.17.1



Antwort: Re: Apollo Lake GPIO driver with Coreboot/U-Boot

2020-01-17 Thread Wolfgang Wallner
Hello Simon, 
 
> -"Simon Glass"  schrieb: -
> On Thu, 16 Jan 2020 at 02:55, Wolfgang Wallner
>  wrote:
> >
> > Hello Simon, Bin, all,
> >
> > I have an Apollo Lake based device, where U-Boot is booted as a Coreboot
> > payload. I would like to utilize the Apollo Lake GPIO driver
> > (drivers/gpio/intel_gpio.c), but I struggle with the dependencies.
> >
> > For my use case, I face 2 obstacles:
> >
> >   1) Some required drivers are not built
> >
> > The Apollo Lake GPIO driver requires the P2SB and ITSS drivers, but 
> > those
> > are located in arch/x86/cpu/apollolake. Drivers in this directory are 
> > not
> > included in my build as it builds for Coreboot, not for Apollo Lake.
> >
> >   2) Some header files are not found
> >
> > The header files gpio.h and itss.h are located in
> > arch/x86/include/asm/arch-apollolake, but as I build for Coreboot the
> > symlink arch/x86/include/asm/arch points to arch-coreboot instead of
> > arch-apollolake, so those header files are not found.
> >
> > Does anyone have recommendations on how to solve those issues?
> > Would it be possible to move the drivers for P2SB and ITSS out of
> > arch/x86/cpu/apollolake to the generic drivers/ directory?
> 
> I don't have any great ideas. At present we rely on the device tree to
> bind these drivers but I suppose we could add the PCI IDs and then the
> coreboot target could bind them.

I have added the relevant entries in my device tree, the point is that the
required drivers are not even built, because they are located in the
Apollo Lake directory. This is why I asked wheter we could move them to the
generic drivers directory. (This could also make sense IMHO as they are not
specific for Apollo Lake, but could be used for mulitple generations of chips)

Also the header files are not found during compilation, as the symlink for
"arch" points to "arch-coreboot" in my case, not to "arch-apollolake" where
the header files are located.

At the moment I have modified the build system so taht the drivers are
compiled for my setup. This works, and the drivers are correctly bound
according to the device tree entries. But this is just a hack, not a proper
solution.

> I did send a series to add checks to skip low-level init as needed
> when running from coreboot:
> 
> http://patchwork.ozlabs.org/project/uboot/list/?series=149993

Thanks for pointing that out, I have missed it on the mailing list.
I will have a look at them.

Btw, did you see my patches regarding fixes for Apollo Lake GPIO and SPI?

GPIO:   https://patchwork.ozlabs.org/patch/1220857/
SPI:https://patchwork.ozlabs.org/patch/1222779/

> You're welcome. I'm expecting to have full ACPI support around the end
> of the month.

If I can help by testing I would be interested.
What is the current state? What is still missing?

regards, Wolfgang



Re: [PATCH] mx7ulp: soc: s_init should only be executed once

2020-01-17 Thread Fabio Estevam
Hi Jorge,

On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz  wrote:
>
> On SPL enabled systems, the current s_init code (wdog, clock and ldo
> init) is executed twice (by SPL and u-boot). This is not necessary and
> might lead to boot issues (ie, starting PMC1 when it is already running).
>
> Signed-off-by: Jorge Ramirez-Ortiz 

The target I use to test LDO-enabled mode does not use SPL, so that's
why I did not notice the problem.

Thanks for the fix:

Reviewed-by: Fabio Estevam 


Re: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration

2020-01-17 Thread Fabio Estevam
On Thu, Jan 16, 2020 at 4:40 AM Jorge Ramirez-Ortiz, Foundries
 wrote:
>
> On 16/01/20 02:22:35, Peng Fan wrote:
> > > Subject: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad
> > > configuration
> > >
> > > The mux mode is embedded in the PAD definition and therefore there is no
> > > need to repeat it in the PAD configuration value (more over since this
> > > information will be masked out when the configuration value is applied).
> >
> > Has this been accepted by Shawn?
>
> added to DL now

Mainline dts does not have backlight support, so this only affects U-Boot.


Re: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration

2020-01-17 Thread Fabio Estevam
On Wed, Jan 15, 2020 at 2:50 PM Jorge Ramirez-Ortiz  wrote:
>
> The mux mode is embedded in the PAD definition and therefore there is
> no need to repeat it in the PAD configuration value (more over since
> this information will be masked out when the configuration value is
> applied).
>
> Signed-off-by: Jorge Ramirez-Ortiz 

Reviewed-by: Fabio Estevam 


Re: [PATCH 1/3] clk: imx: pllv3: fix potential 'divide by zero' in sys_get_rate()

2020-01-17 Thread Giulio Benetti

Hi Adam,

On 1/17/20 12:30 PM, Adam Ford wrote:

On Fri, Jan 17, 2020 at 5:02 AM Giulio Benetti
 wrote:


Guard 'parent_rate==0' to prevent 'divide by zero' issue in
clk_pplv3_sys_get_rate(). Also, guard 'parent_rate<0' that would mean
that clk_get_parent_rate() returned an error, so better to return
early with error EINVAL.

Signed-off-by: Giulio Benetti 
---
  drivers/clk/imx/clk-pllv3.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index fc16416d5f..0d8e39cfbb 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -121,10 +121,16 @@ static ulong clk_pllv3_sys_set_rate(struct clk *clk, 
ulong rate)
  {
 struct clk_pllv3 *pll = to_clk_pllv3(clk);
 unsigned long parent_rate = clk_get_parent_rate(clk);


parent_rate is unsigned here...


Oops, I didn't notice it. I'm going to guard "parent_rate==0" only then.
Same for other patches I've submitted.

Thank you
Best regards
--
Giulio Benetti
Benetti Engineering sas


-   unsigned long min_rate = parent_rate * 54 / 2;
-   unsigned long max_rate = parent_rate * 108 / 2;
+   unsigned long min_rate;
+   unsigned long max_rate;
 u32 val, div;

+   if (parent_rate <= 0)


So I don't see how it is possible that it could be < 0.



+   return -EINVAL;
+
+   min_rate = parent_rate * 54 / 2;
+   max_rate = parent_rate * 108 / 2;
+
 if (rate < min_rate || rate > max_rate)
 return -EINVAL;

--



adam


2.20.1





Re: [PATCH 1/3] clk: imx: pllv3: fix potential 'divide by zero' in sys_get_rate()

2020-01-17 Thread Adam Ford
On Fri, Jan 17, 2020 at 5:02 AM Giulio Benetti
 wrote:
>
> Guard 'parent_rate==0' to prevent 'divide by zero' issue in
> clk_pplv3_sys_get_rate(). Also, guard 'parent_rate<0' that would mean
> that clk_get_parent_rate() returned an error, so better to return
> early with error EINVAL.
>
> Signed-off-by: Giulio Benetti 
> ---
>  drivers/clk/imx/clk-pllv3.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index fc16416d5f..0d8e39cfbb 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -121,10 +121,16 @@ static ulong clk_pllv3_sys_set_rate(struct clk *clk, 
> ulong rate)
>  {
> struct clk_pllv3 *pll = to_clk_pllv3(clk);
> unsigned long parent_rate = clk_get_parent_rate(clk);

parent_rate is unsigned here...

> -   unsigned long min_rate = parent_rate * 54 / 2;
> -   unsigned long max_rate = parent_rate * 108 / 2;
> +   unsigned long min_rate;
> +   unsigned long max_rate;
> u32 val, div;
>
> +   if (parent_rate <= 0)

So I don't see how it is possible that it could be < 0.


> +   return -EINVAL;
> +
> +   min_rate = parent_rate * 54 / 2;
> +   max_rate = parent_rate * 108 / 2;
> +
> if (rate < min_rate || rate > max_rate)
> return -EINVAL;
>
> --


adam

> 2.20.1
>


[PATCH 3/3] clk: imx: pllv3: fix potential 'divide by zero' in av_set_rate()

2020-01-17 Thread Giulio Benetti
Guard 'parent_rate==0' to prevent 'divide by zero' issue in
clk_pplv3_av_set_rate(). Also, guard 'parent_rate<0' that would mean
that clk_get_parent_rate() returned an error, so better to return
early with error EINVAL.

Signed-off-by: Giulio Benetti 
---
 drivers/clk/imx/clk-pllv3.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index d2bb1e86e1..5383ef4816 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -176,13 +176,19 @@ static ulong clk_pllv3_av_set_rate(struct clk *clk, ulong 
rate)
 {
struct clk_pllv3 *pll = to_clk_pllv3(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
-   unsigned long min_rate = parent_rate * 27;
-   unsigned long max_rate = parent_rate * 54;
+   unsigned long min_rate;
+   unsigned long max_rate;
u32 val, div;
u32 mfn, mfd = 100;
u32 max_mfd = 0x3FFF;
u64 temp64;
 
+   if (parent_rate <= 0)
+   return -EINVAL;
+
+   min_rate = parent_rate * 27;
+   max_rate = parent_rate * 54;
+
if (rate < min_rate || rate > max_rate)
return -EINVAL;
 
-- 
2.20.1



[PATCH 2/3] clk: imx: pllv3: fix potential 'divide by zero' in av_get_rate()

2020-01-17 Thread Giulio Benetti
Guard 'mfd==0' to prevent 'divide by zero' issue in
clk_pplv3_av_get_rate() and returning early with error EIO since mfd
should never be 0 at all.

Signed-off-by: Giulio Benetti 
---
 drivers/clk/imx/clk-pllv3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 0d8e39cfbb..d2bb1e86e1 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -163,6 +163,9 @@ static ulong clk_pllv3_av_get_rate(struct clk *clk)
u32 div = readl(pll->base) & pll->div_mask;
u64 temp64 = (u64)parent_rate;
 
+   if (mfd == 0)
+   return -EIO;
+
temp64 *= mfn;
do_div(temp64, mfd);
 
-- 
2.20.1



  1   2   >