date:20190114

The NXP's FEC driver can be reused on vf610 device (with DM).

Signed-off-by: Lukasz Majewski 
---

 drivers/net/fec_mxc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 32fb34b793..be388ead30 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1465,6 +1465,7 @@ static const struct udevice_id fecmxc_ids[] = {
{ .compatible = "fsl,imx6ul-fec" },
{ .compatible = "fsl,imx53-fec" },
{ .compatible = "fsl,imx7d-fec" },
+   { .compatible = "fsl,mvf600-fec" },
{ }
 };
 
-- 
2.11.0

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

[U-Boot] [PATCH v1 01/21] ARM: DTS: vybrid: Add vf-u-boot.dtsi to set 'u-boot, dm-pre-reloc' in soc

This property is necessary to allow pinctrl configuration before
relocation (uart, DDR pins).

Separate file will facilitate updating vf.dtsi from the Linux kernel.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/vf-u-boot.dtsi | 11 +++
 arch/arm/dts/vf.dtsi|  1 +
 2 files changed, 12 insertions(+)
 create mode 100644 arch/arm/dts/vf-u-boot.dtsi

diff --git a/arch/arm/dts/vf-u-boot.dtsi b/arch/arm/dts/vf-u-boot.dtsi
new file mode 100644
index 00..5db5f779e5
--- /dev/null
+++ b/arch/arm/dts/vf-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+/ {
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
index ad30059b9a..65b17db13c 100644
--- a/arch/arm/dts/vf.dtsi
+++ b/arch/arm/dts/vf.dtsi
@@ -3,6 +3,7 @@
  * Copyright 2013 Freescale Semiconductor, Inc.
  */
 /include/ "skeleton.dtsi"
+#include "vf-u-boot.dtsi"
 #include 
 
 / {
-- 
2.11.0

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

Re: [U-Boot] [PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

2019-01-14 Thread Vignesh R

Hi Jagan,

Could you please review v2? If we plan to merge this series for
v2019.04, we should probably plan to take it a bit early so as to
address any regression or fall out in time. Thanks!

Regards
Vignesh

On 21/12/18 12:08 PM, Vignesh R wrote:
> U-Boot SPI NOR support (sf layer) is quite outdated as it does not
> support 4 byte addressing opcodes, SFDP table parsing and different types of
> quad mode enable sequences. Many newer flashes no longer support BANK
> registers used by sf layer to a access >16MB space.
> Also, many SPI controllers have special MMIO interfaces which provide
> accelerated read/write access but require knowledge of flash parameters
> to make use of it. Recent spi-mem layer provides a way to support such
> flashes but sf layer isn't using that.
> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
> spi-mem support on top.
> So, we gain 4byte addressing support and SFDP support. This makes
> migrating to U-Boot MTD framework easier.
> 
> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
> I would greatly appreciate testing on other platforms. Complete series
> with dependencies here[1]
> 
> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration
> to defconfigs [2]
> 
> [1] https://github.com/r-vignesh/u-boot.git  branch: spi-nor-mig-patch-v2
> [2] https://patchwork.ozlabs.org/patch/1007485/
> 
> Simon, Stefan, Thanks for testing previous versions.
> I haven't carried Tested-by's here as I have added back SPI_FLASH_BAR
> support (but isn't enabled by default). Would be great if you could
> retest this series.
> I am hoping there won't be any major rework/changes after this round.
> 
> Change log:
> Since v1:
> Remove #ifindef __UBOOT__
> Add back BAR support, but dont enable as default for all platform (see
> 10/11 for more details)
> Enable SPI_FLASH_TINY on boards where there is SPL size constraint as
> seen on travis ci builds.
> Drop sf_mtd changes for now as it seems to cause issues.
> v1: https://patchwork.ozlabs.org/cover/1012146/
> 
> Since RFC v2:
> Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode
> Fix issues in compiling SFDP code
> Re organize file names and Makefile to simply spi-nor-tiny inclusion
> Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used
> RFC v2: https://patchwork.ozlabs.org/cover/1007589/
> 
> Since RFC v1:
> Add lightweight SPI flash stack for boards with SPL size constraints
> Provide non DM version of spi-mem
> Fix build issues on different platforms as reported by travis-ci on v1
> 
> RFC v1: https://patchwork.ozlabs.org/cover/1004689/
> 
> Vignesh R (11):
>   spi-mem: Claim SPI bus before spi mem access
>   spi: Add non DM version of SPI_MEM
>   sh: bitops: add hweight*() macros
>   mtd: spi: Port SPI NOR framework from Linux
>   mtd: spi: Switch to new SPI NOR framework
>   mtd: spi: Remove unused files
>   mtd: spi: Add lightweight SPI flash stack for SPL
>   configs: Enable SPI_FLASH_TINY for resource constrained boards
>   configs: Remove SF_DUAL_FLASH
>   configs: Don't use SPI_FLASH_BAR as default
>   MAINTAINERS: Add an entry for SPI NOR
> 
>  MAINTAINERS   |9 +
>  arch/arm/mach-omap2/am33xx/Kconfig|1 -
>  arch/sh/include/asm/bitops.h  |4 +
>  common/spl/Kconfig|   21 +-
>  configs/alt_defconfig |1 -
>  configs/am57xx_evm_defconfig  |1 -
>  configs/am57xx_hs_evm_defconfig   |1 -
>  configs/ap121_defconfig   |1 -
>  configs/ap143_defconfig   |1 -
>  configs/avnet_ultra96_rev1_defconfig  |1 -
>  configs/axm_defconfig |1 +
>  configs/axs101_defconfig  |1 -
>  configs/axs103_defconfig  |1 -
>  configs/bg0900_defconfig  |1 -
>  configs/blanche_defconfig |1 -
>  configs/cl-som-am57x_defconfig|1 -
>  configs/clearfog_defconfig|1 -
>  configs/cm_t43_defconfig  |1 -
>  configs/da850_am18xxevm_defconfig |1 +
>  configs/da850evm_nand_defconfig   |2 +-
>  configs/db-88f6820-amc_defconfig  |1 -
>  configs/db-88f6820-gp_defconfig   |1 +
>  configs/display5_defconfig|1 -
>  configs/display5_factory_defconfig|1 -
>  configs/dra7xx_evm_defconfig  |1 -
>  configs/dra7xx_hs_evm_defconfig   |1 -
>  configs/ds109_defconfig   |1 -
>  configs/ds414_defconfig   |1 -
>  configs/evb-rv1108_defconfig  |1 -
>  configs/gose_defconfig|1 -
>

Re: [U-Boot] [PATCH 1/2] net: designware: fix tx packet length


Joe,

Am 10.12.2018 um 05:08 schrieb Marek Vasut:

On 12/09/2018 09:50 PM, Simon Goldschmidt wrote:

Am 17.11.2018 um 17:02 schrieb Joe Hershberger:

On Sat, Nov 17, 2018 at 3:25 AM Simon Goldschmidt
 wrote:


The designware driver has a bug in setting the tx length into the dma
descriptor: it always or's the length into the descriptor without
zeroing out the length mask before.

This results in occasional packets being transmitted with a length
greater than they should be (trailer). Due to the nature of Ethernet
allowing such a trailer, most packets seem to be parsed fine by remote
hosts, which is probably why this hasn't been noticed.

Fix this by correctly clearing the size mask before setting the new
length.

Tested on socfpga gen5.

Signed-off-by: Simon Goldschmidt 


Acked-by: Joe Hershberger 



Marek, this and 2/2 is a assigned to you in patchwork, will you push
them or is it Joe's code as u-boot-net maintainer?


This is net , so Joe should pick it .


I've assigned this one and 2/2 to you in patchwork, is that OK? Could 
you pick these after the release?


Thanks,
Simon

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

[U-Boot] [PATCH v1 14/21] config: bk4: Update include/configs/bk4r1.h file

The BK4's config file has changed since its initial posting to main line.
This commit reflects those changes.

Signed-off-by: Lukasz Majewski 
---

 include/configs/bk4r1.h | 214 ++--
 1 file changed, 206 insertions(+), 8 deletions(-)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index a012705870..bbd3e4e636 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -1,24 +1,222 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
+ * Copyright (C) 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
  * Copyright 2016 3ADEV 
  * Written-by: Albert ARIBAUD 
  *
- * Configuration settings for the phytec PCM-052 SoM-based BK4R1.
+ * Configuration settings for BK4R1.
  */
 
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
 /* Define the BK4r1-specific env commands */
-#define PCM052_EXTRA_ENV_SETTINGS \
+#define BK4_EXTRA_ENV_SETTINGS \
+   "bootlimit=3\0" \
+   "eraseuserdata=false\0" \
+   "altbootcmd=led 5 on; " \
+   "boot\0" \
"set_gpio103=mw 0x400ff0c4 0x0080; mw 0x4004819C 0x11bf\0" \
-   "set_gpio122=mw 0x400481e8 0x0282; mw 0x400ff0c4 0x0400\0"
+   "set_gpio102=mw 0x400ff0c4 0x40; mw 0x40048198 0x11bf\0" \
+   "set_gpio96=mw 0x40048180 0x282; mw 0x400ff0c4 0x1\0"\
+   "set_gpio122=mw 0x400481e8 0x0282; mw 0x400ff0c4 0x0400\0"\
+   "set_gpio6=mw 0x40048018 0x282; mw 0x400ff008 0x40\0"\
+   "manage_userdata=" MANAGE_USERDATA "\0"\
+   "ncenable=true\0"\
+   "ncserverip=192.168.0.77\0"\
+   "if_netconsole=ping $ncserverip\0"\
+   "start_netconsole=setenv ncip $serverip; setenv bootdelay 10;" \
+"setenv stdin nc; setenv stdout nc; setenv stderr nc; version;\0" \
+   "preboot=" BK4_NET_INIT \
+   "if ${ncenable}; then run if_netconsole start_netconsole; fi\0"
 
 /* BK4r1 boot command sets GPIO103/PTC30 to force USB hub out of reset*/
-#define PCM052_BOOTCOMMAND "run set_gpio103; sf probe; "
+#define BK4_BOOTCOMMAND "run set_gpio122; run set_gpio96; sf probe; " \
+   "run manage_userdata; "
+
+/* Enable PREBOOT variable */
+#define CONFIG_PREBOOT
+
+/* Set ARP_TIMEOUT to 500ms */
+#define CONFIG_ARP_TIMEOUT 500UL
+
+/* Set ARP_TIMEOUT_COUNT to 3 repetitions */
+#define CONFIG_NET_RETRY_COUNT 5
 
 /* BK4r1 net init sets GPIO122/PTE17 to enable Ethernet */
-#define PCM052_NET_INIT "run set_gpio122; "
+#define BK4_NET_INIT "run set_gpio122;"
+
+/* Check if userdata volume shall be erased */
+#define MANAGE_USERDATA "if ${eraseuserdata}; " \
+   "then ubi part system; " \
+   "ubi remove userdata; " \
+   "ubi create userdata; " \
+   "ubi detach; " \
+   "setenv eraseuserdata false; " \
+   "saveenv; " \
+   "fi; "
+
+/* Autoboot options */
+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_PROMPT \
+   "Enter passphrase to stop autoboot, booting in %d seconds\n"
+#define CONFIG_AUTOBOOT_STOP_STR "123"
+
+#include 
+#include 
+
+#define CONFIG_SKIP_LOWLEVEL_INIT
+
+/* Enable passing of ATAGs */
+#define CONFIG_CMDLINE_TAG
+
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 4 * SZ_1M)
+
+/* Allow to overwrite serial and ethaddr */
+#define CONFIG_ENV_OVERWRITE
+
+/* NAND support */
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+
+#define IMX_FEC1_BASE  ENET1_BASE_ADDR
+
+/* QSPI Configs*/
+#ifdef CONFIG_FSL_QSPI
+#define FSL_QSPI_FLASH_SIZE(SZ_16M)
+#define FSL_QSPI_FLASH_NUM 2
+#define CONFIG_SYS_FSL_QSPI_LE
+#endif
+
+#define CONFIG_LOADADDR0x8200
+
+/* We boot from the gfxRAM area of the OCRAM. */
+#define CONFIG_BOARD_SIZE_LIMIT520192
+
+/* boot command, including the target-defined one if any */
+#define CONFIG_BOOTCOMMAND BK4_BOOTCOMMAND "run bootcmd_nand"
+
+/* Extra env settings (including the target-defined ones if any) */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   BK4_EXTRA_ENV_SETTINGS \
+   "autoload=no\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0" \
+   "blimg_file=u-boot.vyb\0" \
+   "blimg_addr=0x8100\0" \
+   "dtbkernel_file=fitImage\0" \
+   "dtbkernel_addr=0x8200\0" \
+   "ram_file=uRamdisk\0" \
+   "ram_addr=0x8300\0" \
+   "filesys=rootfs.ubifs\0" \
+   "sys_addr=0x8100\0" \
+   "nfs_root=/path/to/nfs/root\0" \
+   "tftptimeout=1000\0" \
+   "tftptimeoutcountmax=100\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+   "ipaddr=192.168.0.60\0" \
+   "serverip=192.168.0.1\0" \
+

[U-Boot] [PATCH v1 13/21] config: pcm052: Use SZ_X{MK} from linux/sizes.h for include/configs/pcm052.h

Signed-off-by: Lukasz Majewski 
---

 include/configs/pcm052.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/configs/pcm052.h b/include/configs/pcm052.h
index c2ecb7ec18..fb8f3c8609 100644
--- a/include/configs/pcm052.h
+++ b/include/configs/pcm052.h
@@ -9,6 +9,7 @@
 #define __CONFIG_H
 
 #include 
+#include 
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
@@ -16,7 +17,7 @@
 #define CONFIG_CMDLINE_TAG
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * SZ_1M)
 
 /* Allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
@@ -27,7 +28,7 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 /* QSPI Configs*/
 #ifdef CONFIG_FSL_QSPI
-#define FSL_QSPI_FLASH_SIZE(1 << 24)
+#define FSL_QSPI_FLASH_SIZE(SZ_16M)
 #define FSL_QSPI_FLASH_NUM 2
 #define CONFIG_SYS_FSL_QSPI_LE
 #endif
@@ -154,7 +155,7 @@
 
 /* Physical memory map */
 #define PHYS_SDRAM (0x8000)
-#define PHYS_SDRAM_SIZE(CONFIG_PCM052_DDR_SIZE * 1024 
* 1024)
+#define PHYS_SDRAM_SIZE(CONFIG_PCM052_DDR_SIZE * SZ_1M)
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
 #define CONFIG_SYS_INIT_RAM_ADDR   IRAM_BASE_ADDR
@@ -167,17 +168,17 @@
 
 /* environment organization */
 #ifdef CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_SIZE(8 * 1024)
+#define CONFIG_ENV_SIZE(SZ_8K)
 
-#define CONFIG_ENV_OFFSET  (12 * 64 * 1024)
+#define CONFIG_ENV_OFFSET  (12 * SZ_64K)
 #define CONFIG_SYS_MMC_ENV_DEV 0
 #endif
 
 #ifdef CONFIG_ENV_IS_IN_NAND
-#define CONFIG_ENV_SECT_SIZE   (128 * 1024)
-#define CONFIG_ENV_SIZE(8 * 1024)
+#define CONFIG_ENV_SECT_SIZE   (SZ_128K)
+#define CONFIG_ENV_SIZE(SZ_8K)
 #define CONFIG_ENV_OFFSET  0xA
-#define CONFIG_ENV_SIZE_REDUND (8 * 1024)
+#define CONFIG_ENV_SIZE_REDUND (SZ_8K)
 #define CONFIG_ENV_OFFSET_REDUND   0xC
 #endif
 
-- 
2.11.0

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

Re: [U-Boot] imx7d SPL driver fails to allocate memory.

2019-01-14 Thread Rens Dol

Finally found the issue, It was a ddr configuration issue after all,   I 
missed one value when copying the settings from our imximage.cfg to the 
structures required for 'mx7_dram_cfg(...)'.


Should the register name "offset_lp_con0"  in the ddr_phy structure not 
be called  "lp_con0" as it is called DDR_PHY_LP_CON0 in i.MX7 dual 
application processor reference manual?


Regards,

Rens.



On 9-1-2019 18:31, Rens Dol wrote:

Hi all,

I am trying to get SPL working on a imx7 based board. I need to 
configure the DDR voltage before u-boot can be loaded from NAND. I am 
using the pico-imx7_defconfig as a starting point. It already has SPL 
configured to initialize ddr.


From board_init_f I call spl_early_init() to initialize malloc_simple 
so that I can use the pmic driver to set the DDR voltage and configure 
DDR . So far everything is working as expected, I can write/read from 
DDR.


But this is as far as SPL wants to go.. my guess is that switching 
from malloc_simple in board_init_f() to the full malloc implementation 
is not working.


- I use boundarydevices/imx_usb_loader to load u-boot-nand-spl.imx -

- git.denx.de/u-boot-imx version 2019.01-rc1 -

This what my debug output shows.

U-Boot SPL 2019.01-rc1-dirty (Jan 09 2019 - 16:07:51 +0100)
spl_early_init
power_init Set ddr regulator to 1.50V
 -- mALLOc --
0040
pmic_alloc: new pmic struct: 0x009467b0
pmic_get: pmic BD71815 -> 0x009467b0
Bus: 1 PMIC:BD71815 probed!
i2c_write_data: chip=0x4b, len=0x0
write_data:
i2c_read_data: chip=0x4b, len=0x1
 0x41
PMIC:  BD71815 DEV_ID=0x41
i2c_write_data: chip=0x4b, len=0x1
write_data:  0x10
setup drr controller!
 Testing ram
>>SPL: board_init_r()
using memory 0x8830-0x8840 for malloc()
spl_init
spl_board_init
Trying to boot from NAND
spl: nand - using hw ecc
 Trying to load image from CONFIG_SYS_NAND_U_BOOT_OFFS 40 8780
nand_spl_load_image
mxs_nand_init
 -- mALLOc --
0598
 -- malloc_extend_top --  pagesz  = 1000
 nb  = 05A0
 top  = 0091F010
-- sbrk
 increment = 05B0 returns  = 8830-- sbrk end
 brk  = 8830
-- sbrk
 increment = 0A50 returns  = 883005B0-- sbrk end
top = 8830
old_top = 0091F010
old_top_size = 
top_size = 1000

MXS NAND: Failed to allocate private data.

Attached the spl/u-boot.cfg  and pico-imx7d.h files.

Here are my questions.

- Has anyone tried this before on a imx7d?

- Do I have conflicting configuration options?

- Do I need to relocate the complete SPL from SRAM to DDR to make this 
work?


- Should malloc be available in spl_board_init()?

By enabling CONFIG_SPL_SYS_MALLOC_SIMPLE it boots a little further, 
but gets stuck in the nand driver after reading the onfi data and 
searching for a bad block table.


Should it be possible to have usb + nand + i2c working using only 
CONFIG_SPL_SYS_MALLOC_SIMPLE?



Met vriendelijke groeten
Kind regards,

Rens Dol
Software Engineer
Opticon Sensors Europe B.V.
Opaallaan 35
2132 XV  HOOFDDORP
The Netherlands
Tel.+31(0)235692720
rens@opticon.com 1

N�n�r)em�h�yhiם�w^���


--
Met vriendelijke groeten
Kind regards,

Rens Dol
Software Engineer
Opticon Sensors Europe B.V.
Opaallaan 35
2132 XV  HOOFDDORP
The Netherlands
Tel.+31(0)235692720
rens@opticon.com

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

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()

2019-01-14 Thread Fabio Estevam

Hi Tom/Stefano,

On Sat, Dec 8, 2018 at 12:58 PM Fabio Estevam  wrote:
>
> Hi Jaehoon,
>
> On Mon, Nov 19, 2018 at 10:31 AM Fabio Estevam  wrote:
> >
> > The following hang is observed on a Hummingboard 2 MicroSOM
> > i2eX iMX6D - rev 1.3 with no eMMC populated on board:
> >
> > U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +)
> > Trying to boot from MMC1
> >
> > U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +)
> >
> > CPU:   Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz)
> > CPU:   Extended Commercial temperature grade (-20C to 105C) at 33C
> > Reset cause: POR
> > Board: MX6 HummingBoard2
> > DRAM:  1 GiB
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> > Loading Environment from MMC... *** Warning - bad CRC, using default 
> > environment
> >
> > No panel detected: default to HDMI
> > Display: HDMI (1024x768)
> > In:serial
> > Out:   serial
> > Err:   serial
> > ---> hangs
> >
> > which is caused by the following infinite loop inside 
> > esdhc_send_cmd_common()
> >
> > while (!(esdhc_read32(>irqstat) & flags))
> > ;
> >
> > Instead of looping forever, provide an exit path so that a timeout
> > error can be propagated in the case irqstat does not report
> > any interrupts, which may happen when no eMMC is populated on
> > board.
> >
> > Reported-by: Ricardo Salveti 
> > Signed-off-by: Fabio Estevam 
>
> Could this one be applied to 2019.01?

I haven't heard back from Jaehoon.

Can we have this one applied for 2019.01 in order to fix a regression?

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

Re: [U-Boot] [PATCH] serial: Get rid of CONFIG_DW_SERIAL

On Mon, Jan 14, 2019 at 01:56:56PM +, Alexey Brodkin wrote:
> Hi Simon, Tom,
> 
> > -Original Message-
> > From: Simon Glass [mailto:s...@chromium.org]
> > Sent: Thursday, January 10, 2019 3:57 PM
> > To: Alexey Brodkin 
> > Cc: U-Boot Mailing List ; 
> > uboot-snps-...@synopsys.com; Tom Rini
> > ; Adam Ford ; Mario Six 
> > ; Tuomas Tynkkynen
> > ; Alex Kiernan ; Jörg 
> > Krause
> > ; Stephen Warren 
> > Subject: Re: [PATCH] serial: Get rid of CONFIG_DW_SERIAL
> > 
> > On Wed, 9 Jan 2019 at 01:28, Alexey Brodkin  
> > wrote:
> > >
> > > CONFIG_DW_SERIAL is no longer used anywhere so let's forget about it.
> > >
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Tom Rini 
> > > Cc: Adam Ford 
> > > Cc: Mario Six 
> > > Cc: Tuomas Tynkkynen 
> > > Cc: Alex Kiernan 
> > > Cc: Simon Glass 
> > > Cc: "Jörg Krause" 
> > > Cc: Stephen Warren 
> > > ---
> > >  include/configs/axs10x.h | 1 -
> > >  include/configs/hsdk.h   | 1 -
> > >  scripts/config_whitelist.txt | 1 -
> > >  3 files changed, 3 deletions(-)
> > 
> > Reviewed-by: Simon Glass 
> 
> Should I apply it to my tree or either of you is
> going to pick this one up as it's not strictly
> ARC-related change (even though other arches are not affected)?

I think I had assigned it to you in patchwork, so please take it,
thanks!

-- 
Tom


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

[U-Boot] [PATCH v1 05/21] vybrid: clock: Provide enable_i2c_clk() function for Vybrid

Provide function to enable I2C2 clock for vf610 (BK4) - in the
generic code.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/cpu/armv7/vf610/generic.c  | 19 +++
 arch/arm/include/asm/arch-vf610/clock.h |  3 +++
 board/phytec/pcm052/pcm052.c|  2 +-
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
index cbd3391918..f1e6c7816e 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -375,3 +375,22 @@ void enable_caches(void)
mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE, option);
 }
 #endif
+
+#ifdef CONFIG_SYS_I2C_MXC
+/* i2c_num can be from 0 - 3 */
+int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
+{
+   struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
+
+   switch (i2c_num) {
+   case 2:
+   clrsetbits_le32(>ccgr10, CCM_CCGR10_I2C2_CTRL_MASK,
+   CCM_CCGR10_I2C2_CTRL_MASK);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+#endif
diff --git a/arch/arm/include/asm/arch-vf610/clock.h 
b/arch/arm/include/asm/arch-vf610/clock.h
index 3bd73a01f3..72184fd608 100644
--- a/arch/arm/include/asm/arch-vf610/clock.h
+++ b/arch/arm/include/asm/arch-vf610/clock.h
@@ -22,6 +22,9 @@ enum mxc_clock {
 void enable_ocotp_clk(unsigned char enable);
 unsigned int mxc_get_clock(enum mxc_clock clk);
 u32 get_lpuart_clk(void);
+#ifdef CONFIG_SYS_I2C_MXC
+int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
+#endif
 
 #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
 
diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index f988af2abc..cfc8009102 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -485,7 +485,7 @@ static void clock_init(void)
clrsetbits_le32(>ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
clrsetbits_le32(>ccgr10, CCM_REG_CTRL_MASK,
-   CCM_CCGR10_NFC_CTRL_MASK | CCM_CCGR10_I2C2_CTRL_MASK);
+   CCM_CCGR10_NFC_CTRL_MASK);
 
clrsetbits_le32(>pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
-- 
2.11.0

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

[U-Boot] [PATCH v1 10/21] pcm052: board: cosmetic: Add copyright notice to pcm052.c

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 5f2c9a9c12..95df0be6c1 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -1,5 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
  * Copyright 2013 Freescale Semiconductor, Inc.
  */
 
-- 
2.11.0

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

[U-Boot] [PATCH v1 19/21] pcm052: board: Add code to setup LED default states

As one has moved to DM based LEDs, this code is required to setup the
default state.

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index d4f170a503..721e25105a 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -314,6 +315,9 @@ int board_late_init(void)
struct src *psrc = (struct src *)SRC_BASE_ADDR;
u32 reg;
 
+   if (IS_ENABLED(CONFIG_LED))
+   led_default_state();
+
/*
 * BK4r1 handle emergency/service SD card boot
 * Checking the SBMR1 register BOOTCFG1 byte:
-- 
2.11.0

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

[U-Boot] [PATCH v1 11/21] ARM: DTS: Update pcm052 based dts files (bk4r1/pcm052.dts)

This commit provides update to the bk4r1.dts file with
more on SoC HW description.
Moreover, a new vf610-pcm052.drsi file has been introduced
to reuse the common code between devices based on Phytec's
pcm052 modules.
Ported from Linux kernel - v4.20 (tag)

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/bk4r1.dts | 108 -
 arch/arm/dts/pcm052.dts|   6 +-
 arch/arm/dts/vf610-pcm052.dtsi | 266 +
 3 files changed, 346 insertions(+), 34 deletions(-)
 create mode 100644 arch/arm/dts/vf610-pcm052.dtsi

diff --git a/arch/arm/dts/bk4r1.dts b/arch/arm/dts/bk4r1.dts
index 866b80e0b0..55cd53384a 100644
--- a/arch/arm/dts/bk4r1.dts
+++ b/arch/arm/dts/bk4r1.dts
@@ -1,47 +1,97 @@
 // SPDX-License-Identifier: GPL-2.0+ OR X11
 /*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
  * Copyright 2016 Toradex AG
  */
 
 /dts-v1/;
-#include "vf.dtsi"
+#include "vf610-pcm052.dtsi"
+#include "vf610-pinfunc.h"
 
 / {
-   model = "Phytec phyCORE-Vybrid";
-   compatible = "phytec,pcm052", "fsl,vf610";
+   model = "Liebherr (LVF) BK4 Vybrid Board";
+   compatible = "lvf,bk4", "fsl,vf610";
 
-   chosen {
-   stdout-path = 
-   };
+   leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_leds>;
 
-   aliases {
-   spi0 = 
-   };
+   compatible = "gpio-leds";
 
-};
+   /* PTE15 PORT3[24] H6 green */
+   led@0 {
+   label = "0";
+   gpios = < 24 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTA12 PORT0[5] H5 green */
+   led@1 {
+   label = "1";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE20 PORT3[39] H4 green */
+   led@2 {
+   label = "2";
+   gpios = < 29 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
 
- {
-   status = "okay";
+   /* PTE12 PORT3[21] H3 green */
+   led@3 {
+   label = "3";
+   gpios = < 21 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* LED6 is now PRESET ETH -> PTA16 PORT0[6]  H6 red */
+   /* PTE9  PORT3[18] H5 red */
+   led@4 {
+   label = "5";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE23 PORT4[0]  H4 red */
+   led@5 {
+   label = "6";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   /* PTE16 PORT3[25] H3 red */
+   led@6 {
+   label = "7";
+   gpios = < 25 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+   };
 };
 
- {
-   bus-num = <0>;
-   num-cs = <2>;
-   status = "okay";
-
-   qflash0: spi_flash@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "spi-flash";
-   spi-max-frequency = <10800>;
-   reg = <0>;
+ {
+   pinctrl-0 = <_ddr _hog>;
+
+   pinctrl_hog: hoggrp {
+   fsl,pins = <
+   /* ETH control pins */
+   VF610_PAD_PTE17__GPIO_122   0x1183
+   VF610_PAD_PTA16__GPIO_6 0x1183
+   >;
};
 
-   qflash1: spi_flash@1 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "spi-flash";
-   spi-max-frequency = <6600>;
-   reg = <1>;
+   pinctrl_gpio_leds: gpioledsgrp {
+   fsl,pins = <
+   /* LEDS */
+   VF610_PAD_PTE15__GPIO_120   0x1183
+   VF610_PAD_PTA12__GPIO_5 0x1183
+   VF610_PAD_PTE9__GPIO_1140x1183
+   VF610_PAD_PTE20__GPIO_125   0x1183
+   VF610_PAD_PTE23__GPIO_128   0x1183
+   VF610_PAD_PTE16__GPIO_121   0x1183
+   >;
};
 };
diff --git a/arch/arm/dts/pcm052.dts b/arch/arm/dts/pcm052.dts
index 6489fdc6f4..22026024ea 100644
--- a/arch/arm/dts/pcm052.dts
+++ b/arch/arm/dts/pcm052.dts
@@ -4,7 +4,7 @@
  */
 
 /dts-v1/;
-#include "vf.dtsi"
+#include "vf610-pcm052.dtsi"
 
 / {
model = "Phytec phyCORE-Vybrid";
@@ -15,7 +15,3 @@
};
 
 };
-
- {
-   status = "okay";
-};
diff --git a/arch/arm/dts/vf610-pcm052.dtsi b/arch/arm/dts/vf610-pcm052.dtsi
new file mode 100644
index

[U-Boot] [PATCH v1 20/21] pcm052: mac: Provide board specific imx_get_mac_from_fuse() function

This commit introduces the board specific function to read fused mac
address.

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 721e25105a..1e443a5850 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -310,6 +310,47 @@ int board_init(void)
 }
 
 #ifdef CONFIG_TARGET_BK4R1
+void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+{
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[4];
+   struct fuse_bank4_regs *fuse =
+   (struct fuse_bank4_regs *)bank->fuse_regs;
+   u32 value;
+
+   /*
+* BK4 has different layout of stored MAC address
+* than one used in imx_get_mac_from_fuse() @ generic.c
+*/
+
+   switch (dev_id) {
+   case 0:
+   value = readl(>mac_addr1);
+
+   mac[0] = value >> 8;
+   mac[1] = value;
+
+   value = readl(>mac_addr0);
+   mac[2] = value >> 24;
+   mac[3] = value >> 16;
+   mac[4] = value >> 8;
+   mac[5] = value;
+   break;
+   case 1:
+   value = readl(>mac_addr2);
+
+   mac[0] = value >> 24;
+   mac[1] = value >> 16;
+   mac[2] = value >> 8;
+   mac[3] = value;
+
+   value = readl(>mac_addr1);
+   mac[4] = value >> 24;
+   mac[5] = value >> 16;
+   break;
+   }
+}
+
 int board_late_init(void)
 {
struct src *psrc = (struct src *)SRC_BASE_ADDR;
-- 
2.11.0

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

[U-Boot] [PATCH v1 12/21] defconfig: bk4/pcm052: Update bk4r1|pcm052_defconfig to support DM/DT

This commit updates BK4's and PCM052's config files to support as much
as possible device tree and model in u-boot.

Moreover, remove CONFIG_* from pmc052.h (as those are now in
bk4|pcm052_defconfig)

Signed-off-by: Lukasz Majewski 
---

 configs/bk4r1_defconfig  | 46 ++
 configs/pcm052_defconfig | 32 +++-
 include/configs/pcm052.h | 34 --
 3 files changed, 73 insertions(+), 39 deletions(-)

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index 9e31b4ac97..e02078bbea 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -2,15 +2,20 @@ CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_SYS_TEXT_BASE=0x3f401000
+CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_TARGET_BK4R1=y
 CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/phytec/pcm052/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_BOOTEFI is not set
+# CONFIG_CMD_ELF is not set
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_DM=y
+CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
@@ -19,19 +24,45 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
-CONFIG_CMD_DATE=y
+CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_FAT=y
-CONFIG_MTDIDS_DEFAULT="nand0=NAND,nor0=NOR"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=NAND:640k(bootloader),128k(env1),128k(env2),128k(dtb),6144k(kernel),-(root);NOR:-(nor)"
+CONFIG_MTDIDS_DEFAULT="nand0=vf610_nfc,nor0=NOR"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=vf610_nfc:2048k(bootloader),128k(env1),128k(env2),10240k(initrd),40960k(dtbkernel),-(system);NOR:-(nor)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="bk4r1"
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_NETCONSOLE=y
 CONFIG_DM=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
+CONFIG_SYS_BOOTCOUNT_ADDR=0x4006e02c
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2
+CONFIG_SYS_I2C_MXC=y
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_SYS_I2C_MXC_I2C4=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_MXC_OCOTP=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_ADDR=0x50
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_EEPROM_SIZE=32768
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=6
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND_VF610_NFC=y
+CONFIG_NAND_VF610_NFC_DT=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
@@ -39,8 +70,15 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y
 CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_VYBRID=y
+CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+# CONFIG_TPL_SERIAL_PRESENT is not set
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_SPI=y
diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
index e207df51a8..217fa6a050 100644
--- a/configs/pcm052_defconfig
+++ b/configs/pcm052_defconfig
@@ -18,7 +18,6 @@ CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
-CONFIG_CMD_DATE=y
 CONFIG_CMD_FAT=y
 CONFIG_MTDIDS_DEFAULT="nand0=NAND"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=NAND:640k(bootloader),128k(env1),128k(env2),128k(dtb),6144k(kernel),-(root)"
@@ -29,12 +28,43 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2
+CONFIG_SYS_I2C_MXC=y
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_SYS_I2C_MXC_I2C4=y
+CONFIG_MISC=y
+CONFIG_MXC_OCOTP=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_ADDR=0x50
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_EEPROM_SIZE=32768
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=6
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND_VF610_NFC=y
+CONFIG_NAND_VF610_NFC_DT=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y
 CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_VYBRID=y
+CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_QSPI=y
diff --git a/include/configs/pcm052.h b/include/configs/pcm052.h
index e125a38e7d..c2ecb7ec18 100644
--- a/include/configs/pcm052.h
+++ b/include/configs/pcm052.h
@@ -24,48 +24,14 @@
 /* NAND support */
 #define CONFIG_SYS_NAND_ONFI_DETECTION
 
-#ifdef CONFIG_CMD_NAND
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
-#define CONFIG_SYS_NAND_BASE   NFC_BASE_ADDR
-
-#define CONFIG_JFFS2_NAND
-
-/* Dynamic MTD partition support */
-
-#endif
-
-#define

Re: [U-Boot] [PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

On Mon, Jan 14, 2019 at 08:32:29PM +0530, Vignesh R wrote:

> Hi Jagan,
> 
> Could you please review v2? If we plan to merge this series for
> v2019.04, we should probably plan to take it a bit early so as to
> address any regression or fall out in time. Thanks!

Yes, please, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] imx8mq_evk_defconfig: Move file system options to Kconfig

On Sat, Dec 29, 2018 at 10:02:24AM -0200, Fabio Estevam wrote:

> Chris Spencer reports that when enabling ext4 read support without
> also enabling write support the following error is seen:
> 
> fs/fs.c:198:12: error: 'ext4_write_file' undeclared here (not in a
> function); did you mean 'ext4_read_file'?
>.write = ext4_write_file,
> ^~~
> Fix this problem by moving these options to Kconfig.
> 
> Reported-by: Chris Spencer 
> Acked-by: Peng Fan 
> Signed-off-by: Fabio Estevam 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()

On Mon, Nov 19, 2018 at 10:31:53AM -0200, Fabio Estevam wrote:

> The following hang is observed on a Hummingboard 2 MicroSOM
> i2eX iMX6D - rev 1.3 with no eMMC populated on board:
> 
> U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +)
> Trying to boot from MMC1
> 
> U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +)
> 
> CPU:   Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 33C
> Reset cause: POR
> Board: MX6 HummingBoard2
> DRAM:  1 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
> 
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out:   serial
> Err:   serial

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] net: fix env flags for eth10addr and above

On Mon, Jan 14, 2019 at 04:42:10PM +0100, Simon Goldschmidt wrote:
> Am 14.12.2018 um 14:28 schrieb Tom Rini:
> >On Fri, Dec 14, 2018 at 09:56:19AM +0100, Simon Goldschmidt wrote:
> >
> >>+Tom
> >>
> >>On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
> >> wrote:
> >>>
> >>>Am 22.11.2018 um 17:06 schrieb Simon Goldschmidt:
> With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10
> interfaces (0..9) as the number can only have one digit.
> 
> On boards with more than 10 interfaces, this leads to the protection
> and format checks being absent for eth10addr and above.
> 
> Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow
> more than one digit.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>    include/env_flags.h | 2 +-
>    1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/env_flags.h b/include/env_flags.h
> index cc2c34f939..23744e395c 100644
> --- a/include/env_flags.h
> +++ b/include/env_flags.h
> @@ -38,7 +38,7 @@ enum env_flags_varaccess {
> 
>    #ifdef CONFIG_CMD_NET
>    #ifdef CONFIG_REGEX
> -#define ETHADDR_WILDCARD "\\d?"
> +#define ETHADDR_WILDCARD "\\d*"
>    #else
>    #define ETHADDR_WILDCARD
>    #endif
> 
> >>>
> >>>Ping?
> >>
> >>I haven't gotten an answer to this for nearly one month. It's a small
> >>change, can this go in for v2019.01 please?
> >
> >I'd filed this off to Joe to grab since it is indeed small and a
> >clean-up.
> 
> Will you be taking this after the release or is there anything missing? It's
> assigned to you in patchwork but I didn't get any real reply...

Yes, I'll be picking it up then, thanks for your patience.

-- 
Tom


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

[U-Boot] [PATCH v1 00/21] imx: vybrid: Update BK4 and PCM052 boards to only use DM/DTS

This patch series converts PCM052 and BK4 to use Driver Model and Device
Tree.
Some notable changes:
- The way how MAC address is read from fuses can now be adjusted
- DTS improvement/sync with kernel
- Using generic code instead of one from board

The output of u-boot boot:
U-Boot 2019.01-rc3-00076-gc149229be0 (Jan 14 2019 - 08:38:48 +0100)

CPU: Freescale Vybrid VF610 at 396 MHz
Reset cause: POWER ON RESET
Model: Liebherr (LVF) BK4 Vybrid Board
Board: BK4r1 (L333)
DRAM:  512 MiB
NAND:  1024 MiB
MMC:   FSL_SDHC: 0
Loading Environment from NAND... OK
In:serial@40028000
Out:   serial@40028000
Err:   serial@40028000
Net:   eth0: fec@400d, eth1: fec@400d1000
Enter passphrase to stop autoboot, booting in 3 seconds

Buildman CI:
./tools/buildman/buildman.py --branch=HEAD~3  vf610 mx6 vybrid --detail 
--verbose --show_errors --force-build --count=21 --output-dir=../BUILD/

Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/jobs/479284276
[omitting test_efi_selftest failure - as PCM052/BK4 is not supporting EFI]

U-boot master branch: SHA1: b3a69c246915bd704d6073bcf4614d6881c0da04



Lukasz Majewski (21):
  ARM: DTS: vybrid: Add vf-u-boot.dtsi to set 'u-boot,dm-pre-reloc' in
soc
  net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver
  net: Kconfig: FEC: Add dependency on VF610
  vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions
  vybrid: clock: Provide enable_i2c_clk() function for Vybrid
  vybrid: Define the imx_get_mac_from_fuse() as a __weak function
  pcm052: board: Remove "m4go" command as it is superseded by "bootaux"
  pcm052: board: vybrid: Update the board name for BK4 device
  ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware
  pcm052: board: cosmetic: Add copyright notice to pcm052.c
  ARM: DTS: Update pcm052 based dts files (bk4r1/pcm052.dts)
  defconfig: bk4/pcm052: Update bk4r1|pcm052_defconfig to support DM/DT
  config: pcm052: Use SZ_X{MK} from linux/sizes.h for
include/configs/pcm052.h
  config: bk4: Update include/configs/bk4r1.h file
  pcm052: board: Remove in-board setup code (it is now replaced by DM
setup)
  config: bk4: Update u-boot script to support recovery via SD card
  config: bk4: Update u-boot envs to support NOR memories initial setup
  pcm052: bk4: sdcard: Add support for SD card booting/recovery
  pcm052: board: Add code to setup LED default states
  pcm052: mac: Provide board specific imx_get_mac_from_fuse() function
  pcm052: bk4: Add board_phy_config() for BK4 to setup ksz8081 phy

 arch/arm/cpu/armv7/vf610/Kconfig   |   1 +
 arch/arm/cpu/armv7/vf610/generic.c |  21 +-
 arch/arm/dts/bk4r1.dts | 108 +---
 arch/arm/dts/pcm052.dts|   6 +-
 arch/arm/dts/vf-u-boot.dtsi|  11 +
 arch/arm/dts/vf.dtsi   |  63 +
 arch/arm/dts/vf610-pcm052.dtsi | 266 
 arch/arm/dts/vf610-pinfunc.h   |  50 
 arch/arm/include/asm/arch-vf610/clock.h|   3 +
 arch/arm/include/asm/arch-vf610/imx-regs.h |   2 +
 board/phytec/pcm052/pcm052.c   | 386 +++--
 configs/bk4r1_defconfig|  46 +++-
 configs/pcm052_defconfig   |  32 ++-
 drivers/net/Kconfig|   2 +-
 drivers/net/fec_mxc.c  |   1 +
 include/configs/bk4r1.h| 263 +++-
 include/configs/pcm052.h   |  51 +---
 17 files changed, 925 insertions(+), 387 deletions(-)
 create mode 100644 arch/arm/dts/vf-u-boot.dtsi
 create mode 100644 arch/arm/dts/vf610-pcm052.dtsi

-- 
2.11.0

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

[U-Boot] [PATCH v1 08/21] pcm052: board: vybrid: Update the board name for BK4 device

This commit provides distinction between PCM052 and BK4.

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 4e4b870304..5f2c9a9c12 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -573,7 +573,10 @@ int board_init(void)
 
 int checkboard(void)
 {
+#ifdef CONFIG_TARGET_BK4R1
+   puts("Board: BK4r1 (L333)\n");
+#else
puts("Board: PCM-052\n");
-
+#endif
return 0;
 }
-- 
2.11.0

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

[U-Boot] [PATCH v1 18/21] pcm052: bk4: sdcard: Add support for SD card booting/recovery

This code allows reusing the default u-boot as in the late board init, the
default envs are restored and proper recovery scripts executed.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/cpu/armv7/vf610/Kconfig   |  1 +
 arch/arm/include/asm/arch-vf610/imx-regs.h |  2 ++
 board/phytec/pcm052/pcm052.c   | 32 ++
 3 files changed, 35 insertions(+)

diff --git a/arch/arm/cpu/armv7/vf610/Kconfig b/arch/arm/cpu/armv7/vf610/Kconfig
index 13905b5281..5d485a3ce2 100644
--- a/arch/arm/cpu/armv7/vf610/Kconfig
+++ b/arch/arm/cpu/armv7/vf610/Kconfig
@@ -23,6 +23,7 @@ config TARGET_BK4R1
bool "BK4r1"
select SYS_FSL_ERRATUM_ESDHC135
select SYS_FSL_ERRATUM_ESDHC_A001
+   select BOARD_LATE_INIT
 
 endchoice
 
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h 
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index 5d1f63c98b..ae0a187c4d 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -289,6 +289,8 @@
 #define SRC_SRSR_WDOG_M4   (0x1 << 4)
 #define SRC_SRSR_WDOG_A5   (0x1 << 3)
 #define SRC_SRSR_POR_RST   (0x1 << 0)
+#define SRC_SBMR1_BOOTCFG1_SDMMCBIT(6)
+#define SRC_SBMR1_BOOTCFG1_MMC  BIT(4)
 #define SRC_SBMR2_BMOD_MASK (0x3 << 24)
 #define SRC_SBMR2_BMOD_SHIFT24
 #define SRC_SBMR2_BMOD_FUSES0x0
diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 4a18b0e0f4..d4f170a503 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -307,6 +308,37 @@ int board_init(void)
return 0;
 }
 
+#ifdef CONFIG_TARGET_BK4R1
+int board_late_init(void)
+{
+   struct src *psrc = (struct src *)SRC_BASE_ADDR;
+   u32 reg;
+
+   /*
+* BK4r1 handle emergency/service SD card boot
+* Checking the SBMR1 register BOOTCFG1 byte:
+* NAND:
+*  bit [2] - NAND data width - 16
+*  bit [5] - NAND fast boot
+*  bit [7] = 1 - NAND as a source of booting
+* SD card (0x64):
+*  bit [4] = 0 - SD card source
+*  bit [6] = 1 - SD/MMC source
+*/
+
+   reg = readl(>sbmr1);
+   if ((reg & SRC_SBMR1_BOOTCFG1_SDMMC) &&
+   !(reg & SRC_SBMR1_BOOTCFG1_MMC)) {
+   printf("-- SD card boot ---\n");
+   set_default_env("!LVFBootloader", 0);
+   env_set("bootcmd",
+   "run prepare_install_bk4r1_envs; run install_bk4r1rs");
+   }
+
+   return 0;
+}
+#endif /* CONFIG_TARGET_BK4R1 */
+
 int checkboard(void)
 {
 #ifdef CONFIG_TARGET_BK4R1
-- 
2.11.0

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

[U-Boot] [PATCH v1 21/21] pcm052: bk4: Add board_phy_config() for BK4 to setup ksz8081 phy

BK4 requires setup of 50MHz reference clock for its KSZ8081 PHY devices.

Signed-off-by: Lukasz Majewski 

---

 board/phytec/pcm052/pcm052.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 1e443a5850..c30df5df9d 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -382,6 +383,21 @@ int board_late_init(void)
 
return 0;
 }
+
+/**
+ * KSZ8081
+ */
+#define MII_KSZ8081_REFERENCE_CLOCK_SELECT 0x1f
+#define RMII_50MHz_CLOCK   0x8180
+
+int board_phy_config(struct phy_device *phydev)
+{
+   /* Set 50 MHz reference clock */
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_KSZ8081_REFERENCE_CLOCK_SELECT,
+ RMII_50MHz_CLOCK);
+
+   return genphy_config(phydev);
+}
 #endif /* CONFIG_TARGET_BK4R1 */
 
 int checkboard(void)
-- 
2.11.0

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

Re: [U-Boot] [PATCH v1 11/21] ARM: DTS: Update pcm052 based dts files (bk4r1/pcm052.dts)

On Mon, Jan 14, 2019 at 03:17:30PM +0100, Lukasz Majewski wrote:
> This commit provides update to the bk4r1.dts file with
> more on SoC HW description.
> Moreover, a new vf610-pcm052.drsi file has been introduced
> to reuse the common code between devices based on Phytec's
> pcm052 modules.
> Ported from Linux kernel - v4.20 (tag)
> 
> Signed-off-by: Lukasz Majewski 
> ---
> 
>  arch/arm/dts/bk4r1.dts | 108 -
>  arch/arm/dts/pcm052.dts|   6 +-
>  arch/arm/dts/vf610-pcm052.dtsi | 266 
> +
>  3 files changed, 346 insertions(+), 34 deletions(-)
>  create mode 100644 arch/arm/dts/vf610-pcm052.dtsi
> 
> diff --git a/arch/arm/dts/bk4r1.dts b/arch/arm/dts/bk4r1.dts
> index 866b80e0b0..55cd53384a 100644
> --- a/arch/arm/dts/bk4r1.dts
> +++ b/arch/arm/dts/bk4r1.dts
> @@ -1,47 +1,97 @@
>  // SPDX-License-Identifier: GPL-2.0+ OR X11
>  /*
> + * (C) Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
> + *
>   * Copyright 2016 Toradex AG
>   */
>  
>  /dts-v1/;
> -#include "vf.dtsi"
> +#include "vf610-pcm052.dtsi"
> +#include "vf610-pinfunc.h"
>  
>  / {
> - model = "Phytec phyCORE-Vybrid";
> - compatible = "phytec,pcm052", "fsl,vf610";
> + model = "Liebherr (LVF) BK4 Vybrid Board";
> + compatible = "lvf,bk4", "fsl,vf610";
>  
> - chosen {
> - stdout-path = 
> - };
> + leds {
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_leds>;
>  
> - aliases {
> - spi0 = 
> - };
> + compatible = "gpio-leds";
>  
> -};
> + /* PTE15 PORT3[24] H6 green */
> + led@0 {
> + label = "0";
> + gpios = < 24 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + /* PTA12 PORT0[5] H5 green */
> + led@1 {
> + label = "1";
> + gpios = < 5 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + /* PTE20 PORT3[39] H4 green */
> + led@2 {
> + label = "2";
> + gpios = < 29 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
>  
> - {
> - status = "okay";
> + /* PTE12 PORT3[21] H3 green */
> + led@3 {
> + label = "3";
> + gpios = < 21 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + /* LED6 is now PRESET ETH -> PTA16 PORT0[6]  H6 red */
> + /* PTE9  PORT3[18] H5 red */
> + led@4 {
> + label = "5";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + /* PTE23 PORT4[0]  H4 red */
> + led@5 {
> + label = "6";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + /* PTE16 PORT3[25] H3 red */
> + led@6 {
> + label = "7";
> + gpios = < 25 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> + };
>  };
>  
> - {
> - bus-num = <0>;
> - num-cs = <2>;
> - status = "okay";
> -
> - qflash0: spi_flash@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - compatible = "spi-flash";
> - spi-max-frequency = <10800>;
> - reg = <0>;
> + {
> + pinctrl-0 = <_ddr _hog>;
> +
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + /* ETH control pins */
> + VF610_PAD_PTE17__GPIO_122   0x1183
> + VF610_PAD_PTA16__GPIO_6 0x1183
> + >;
>   };
>  
> - qflash1: spi_flash@1 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - compatible = "spi-flash";
> - spi-max-frequency = <6600>;
> - reg = <1>;
> + pinctrl_gpio_leds: gpioledsgrp {
> + fsl,pins = <
> + /* LEDS */
> + VF610_PAD_PTE15__GPIO_120   0x1183
> + VF610_PAD_PTA12__GPIO_5 0x1183
> + VF610_PAD_PTE9__GPIO_1140x1183
> + VF610_PAD_PTE20__GPIO_125   0x1183
> + VF610_PAD_PTE23__GPIO_128   0x1183
> + VF610_PAD_PTE16__GPIO_121   0x1183
> + >;
>   };
>  };
> diff --git a/arch/arm/dts/pcm052.dts b/arch/arm/dts/pcm052.dts
> index 6489fdc6f4..22026024ea 100644
> --- a/arch/arm/dts/pcm052.dts
> +++ b/arch/arm/dts/pcm052.dts
> @@ -4,7 +4,7 @@
>   */
>  
>  /dts-v1/;
> -#include "vf.dtsi"
> +#include "vf610-pcm052.dtsi"
>  
>  / {
>   model =

Re: [U-Boot] [PATCH v2] spl: implement CRC check on U-Boot uImage


Tom,

Am 11.12.2018 um 02:07 schrieb Simon Glass:

On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt
 wrote:


SPL currently does not check uImage CRCs when loading U-Boot.

This patch adds checking the uImage CRC when SPL loads U-Boot. It does
this by reusing the existing config option SPL_CRC32_SUPPORT to allow
leaving out the CRC check on boards where the additional code size or
boot time is a problem (adding the CRC check currently adds ~1.4 kByte
to flash).

The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL
support for legacy images is enabled to check the CRC on all boards
that don't actively take countermeasures.

Signed-off-by: Simon Goldschmidt 
---

Changes in v2:
- added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable
   checking CRC on legacy images

  common/spl/Kconfig | 21 +++--
  common/spl/spl.c   | 30 +-
  include/spl.h  |  5 +
  3 files changed, 49 insertions(+), 7 deletions(-)


Reviewed-by: Simon Glass 


This is assigned to you in patchwork, any reason you did not add it for 
the 2019.01 release? Is there anything missing or was this just lost?


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

Re: [U-Boot] [PATCH u-boot] pinctrl: meson: add pinconf support

2019-01-14 Thread Neil Armstrong

Hi Jerome,

On 04/01/2019 15:44, Jerome Brunet wrote:
> Adding pinconf support is necessary to enable boot from SPI
> without breaking the eMMC. When booting from SPI, the ROM code
> leave pull downs on the eMMC pad.
> 
> We need to set pinconf provided in DT to solve this
> 
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/pinctrl/meson/Kconfig |   1 +
>  drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c |  10 ++
>  drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c  |  10 ++
>  drivers/pinctrl/meson/pinctrl-meson.c | 101 --
>  drivers/pinctrl/meson/pinctrl-meson.h |   8 ++
>  5 files changed, 123 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
> index ee820a57a0e0..162642d7289b 100644
> --- a/drivers/pinctrl/meson/Kconfig
> +++ b/drivers/pinctrl/meson/Kconfig
> @@ -2,6 +2,7 @@ if ARCH_MESON
>  
>  config PINCTRL_MESON
>   select PINCTRL_GENERIC
> + select PINCONF
>   bool
>  
>  config PINCTRL_MESON_GX_PMX
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c 
> b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> index c82413d08f34..f9065723eea9 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> @@ -93,6 +93,12 @@ static int meson_axg_pinmux_group_set(struct udevice *dev,
>   return 0;
>  }
>  
> +const struct pinconf_param meson_axg_pinconf_params[] = {
> + { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
> + { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
> + { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
> +};
> +
>  const struct pinctrl_ops meson_axg_pinctrl_ops = {
>   .get_groups_count = meson_pinctrl_get_groups_count,
>   .get_group_name = meson_pinctrl_get_group_name,
> @@ -100,6 +106,10 @@ const struct pinctrl_ops meson_axg_pinctrl_ops = {
>   .get_function_name = meson_pinmux_get_function_name,
>   .pinmux_group_set = meson_axg_pinmux_group_set,
>   .set_state = pinctrl_generic_set_state,
> + .pinconf_params = meson_axg_pinconf_params
> + .pinconf_num_params = ARRAY_SIZE(meson_axg_pinconf_params),
> + .pinconf_set = meson_pinconf_set,
> + .pinconf_group_set = meson_pinconf_group_set,
>  };
>  
>  static int meson_axg_gpio_request(struct udevice *dev,
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c 
> b/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
> index fc1538ea719e..cf72576b6ce2 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
> @@ -72,6 +72,12 @@ static int meson_gx_pinmux_group_set(struct udevice *dev,
>   return 0;
>  }
>  
> +const struct pinconf_param meson_gx_pinconf_params[] = {
> + { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
> + { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
> + { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
> +};
> +
>  const struct pinctrl_ops meson_gx_pinctrl_ops = {
>   .get_groups_count = meson_pinctrl_get_groups_count,
>   .get_group_name = meson_pinctrl_get_group_name,
> @@ -79,6 +85,10 @@ const struct pinctrl_ops meson_gx_pinctrl_ops = {
>   .get_function_name = meson_pinmux_get_function_name,
>   .pinmux_group_set = meson_gx_pinmux_group_set,
>   .set_state = pinctrl_generic_set_state,
> + .pinconf_params = meson_gx_pinconf_params,
> + .pinconf_num_params = ARRAY_SIZE(meson_gx_pinconf_params),
> + .pinconf_set = meson_pinconf_set,
> + .pinconf_group_set = meson_pinconf_group_set,
>  };
>  
>  static const struct dm_gpio_ops meson_gx_gpio_ops = {
> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
> b/drivers/pinctrl/meson/pinctrl-meson.c
> index b539749752c8..fa3d78858a9e 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> @@ -57,7 +57,7 @@ static int meson_gpio_calc_reg_and_bit(struct udevice *dev, 
> unsigned int offset,
>  enum meson_reg_type reg_type,
>  unsigned int *reg, unsigned int *bit)
>  {
> - struct meson_pinctrl *priv = dev_get_priv(dev->parent);
> + struct meson_pinctrl *priv = dev_get_priv(dev);
>   struct meson_bank *bank = NULL;
>   struct meson_reg_desc *desc;
>   unsigned int pin;
> @@ -89,7 +89,8 @@ int meson_gpio_get(struct udevice *dev, unsigned int offset)
>   unsigned int reg, bit;
>   int ret;
>  
> - ret = meson_gpio_calc_reg_and_bit(dev, offset, REG_IN, , );
> + ret = meson_gpio_calc_reg_and_bit(dev->parent, offset, REG_IN, ,
> +   );
>   if (ret)
>   return ret;
>  
> @@ -102,7 +103,8 @@ int meson_gpio_set(struct udevice *dev, unsigned int 
> offset, int value)
>   unsigned int reg, bit;
>   int ret;
>  
> - ret = meson_gpio_calc_reg_and_bit(dev, offset, REG_OUT, , );
> + ret = meson_gpio_calc_reg_and_bit(dev->parent, offset, REG_OUT, ,
>

[U-Boot] Porting u-boot to flash micro with proprietary (non-GPL) flash programming library

2019-01-14 Thread Ulf Samuelsson

I am working in a project where we are considering using U-Boot as a 
bootloader for a flash microcontroller with an ARM Cortex-Rx core.

The chip is currently not supported by U-Boot.

The processor will not be running linux.

Our board will use
•   On Chip Flash
•   External Parallel Flash
•   External SPI Flash

Problem:
To program the internal flash, we need to use the a library from the CPU 
vendor which is only supplied to us in binary form.


Their license forbids us to link that library to open source code in a 
way that “contaminates” their code with GPL.


GPL forbids code to be linked with non-GPL code.

There are a few common exceptions to GPL when running linux.
1.  Linking with a shared library is OK.
2.  Using a device driver which was originally written for another
OS. (I think this has been primarily used for graphics drivers)

Right now, our idea is to do runtime linking to the flash programming 
library similar to a shared library.


For various reasons, we plan to have our own first level bootloader 
which has very simple functionality, and this will be contain the vendor 
flash programming library.


U-boot, can when started, query the first level bootloader for the 
location of the entry points in the library and use the result to fill 
in a struct containing the address of the entry points. As far as I 
understand, this will not be static linking, so this should be allowed 
in GPL.


Q:  Is this a reasonable approach to the problem?

Even if acceptable, there may be several ways of implementing this.
Here is what I can think of:
==
1) CALLING THROUGH AN EXTERNAL CALL TABLE
The first level bootloader has a call table containing the absolute
addresses of the flash library entry points.
The u-boot driver will declare the table external, and define the table 
in the linker command file.
u-boot needs a header file describing the call table (probably 
implemented as a struct)


==
2) COPYING A STRUCT FROM A KNOWN ADDRESS IN THE FIRST LEVEL BOOTLOADER

The simplest way I can envision, is that the first level bootloader has 
a struct containing an field for each entrypoint. The field contains the 
absolute address of the entry point.


The struct is copied into an u-boot datastructure as is.
u-boot can call any entry by an indirect call.

  (*externallib.function1)();

For this to work, u-boot needs to know the absolute address of the table 
inside the first level bootloader.
Both u-boot and the first level bootloader will contain a definition of 
the struct in a header file.



==
3) COPYING A STRUCT FROM AN UNKNOWN ADDRESS THROUGH A SUPERVISOR CALL.
The first level bootloader will reside in flash at the reset address. It 
has a supervisor call exception vector. A specific supervisor call can

return the address of the struct above.

With this method, U-boot does not need to have internal knowledge of 
where the struct is located in the first level bootloader.


It does need to have a header file describing the struct.

==
4) CREATING A CALL TABLE BY QUERYING FOR EACH ENTRY.

This assumes that u-boot should not have any knowledge of a struct. 
Instead a supervisor call is implemented which sends a parameter 
defining which entry point of interest. The supervisor call returns the 
absolute address of the entry point.


==
Q:  Are any of the methods above violating the GPL license?
==
Q:	Is there another method which is recommended to handle the problem 
with proprietary vendor flash libraries?

==
Q:	If a processor contains functionality in a bootROM, for which source 
is not available. How can that be used in u-boot?


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

[U-Boot] [PATCH v1 04/21] vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions

This patch provides definitions necessary for VF610 DDR pad configurations.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/vf610-pinfunc.h | 50 
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/dts/vf610-pinfunc.h b/arch/arm/dts/vf610-pinfunc.h
index fcad7132c8..24d7126756 100644
--- a/arch/arm/dts/vf610-pinfunc.h
+++ b/arch/arm/dts/vf610-pinfunc.h
@@ -807,4 +807,54 @@
 #define VF610_PAD_PTA7__GPIO_134   0x218 0x000 ALT0 0x0
 #define VF610_PAD_PTA7__VIU_PIX_CLK0x218 0x3AC ALT1 0x1
 
+#define VF610_PAD_DDR_RESETB   0x21c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A15__DDR_A_150x220 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A14__DDR_A_140x224 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A13__DDR_A_130x228 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A12__DDR_A_120x22c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A11__DDR_A_110x230 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A10__DDR_A_100x234 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A9__DDR_A_9  0x238 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A8__DDR_A_8  0x23c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A7__DDR_A_7  0x240 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A6__DDR_A_6  0x244 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A5__DDR_A_5  0x248 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A4__DDR_A_4  0x24c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A3__DDR_A_3  0x250 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A2__DDR_A_2  0x254 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A1__DDR_A_1  0x258 0x000 ALT0 0x0
+#define VF610_PAD_DDR_A0__DDR_A_0  0x25c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA2__DDR_BA_20x260 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA1__DDR_BA_10x264 0x000 ALT0 0x0
+#define VF610_PAD_DDR_BA0__DDR_BA_00x268 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CAS__DDR_CAS_B   0x26c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CKE__DDR_CKE_0   0x270 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CLK__DDR_CLK_0   0x274 0x000 ALT0 0x0
+#define VF610_PAD_DDR_CS__DDR_CS_B_0   0x278 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D15__DDR_D_150x27c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D14__DDR_D_140x280 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D13__DDR_D_130x284 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D12__DDR_D_120x288 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D11__DDR_D_110x28c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D10__DDR_D_100x290 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D9__DDR_D_9  0x294 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D8__DDR_D_8  0x298 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D7__DDR_D_7  0x29c 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D6__DDR_D_6  0x2a0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D5__DDR_D_5  0x2a4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D4__DDR_D_4  0x2a8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D3__DDR_D_3  0x2ac 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D2__DDR_D_2  0x2b0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D1__DDR_D_1  0x2b4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_D0__DDR_D_0  0x2b8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQM1__DDR_DQM_1  0x2bc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQM0__DDR_DQM_0  0x2c0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQS1__DDR_DQS_1  0x2c4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DQS0__DDR_DQS_0  0x2c8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_RAS__DDR_RAS_B   0x2cc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_WE__DDR_WE_B 0x2d0 0x000 ALT0 0x0
+#define VF610_PAD_DDR_ODT1__DDR_ODT_0  0x2d4 0x000 ALT0 0x0
+#define VF610_PAD_DDR_ODT0__DDR_ODT_1  0x2d8 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1   0x2dc 0x000 ALT0 0x0
+#define VF610_PAD_DDR_DDRBYTE0__DDR_DDRBYTE0   0x2e0 0x000 ALT0 0x0
 #endif
-- 
2.11.0

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

[U-Boot] [PATCH v1 06/21] vybrid: Define the imx_get_mac_from_fuse() as a __weak function

The proposed way of reading fused MAC in the imx_get_mac_from_fuse() may
be different for other boards.

This commit defines the imx_get_mac_from_fuse() as a weak function to allow
board file overriding it with customized function.

Signed-off-by: Lukasz Majewski 
---

 arch/arm/cpu/armv7/vf610/generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
index f1e6c7816e..cdc5b71f21 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -252,7 +252,7 @@ U_BOOT_CMD(
 );
 
 #ifdef CONFIG_FEC_MXC
-void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
+__weak void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
struct fuse_bank *bank = >bank[4];
-- 
2.11.0

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff". However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this function and
convert all drivers to provide appropriate 'resets' properties in the dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding some 
"resets" properties the the main dtsi and adding reset bulk code to the 
cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset 
code from arch/mach_socfpga.


The problem would be that now Linux cannot use peripherals that aren't 
enabled by U-Boot because it relies on them being enabled. How are such 
dependencies solved? Because even if I would add reset support in the 
corresponding Linux drivers, we probably could not bootolder Kernels 
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...


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

Re: [U-Boot] [PATCH v2] imx8mq_evk_defconfig: Move file system options to Kconfig

2019-01-14 Thread Fabio Estevam

Hi Tom/Stefano,

On Sat, Dec 29, 2018 at 10:02 AM Fabio Estevam  wrote:
>
> Chris Spencer reports that when enabling ext4 read support without
> also enabling write support the following error is seen:
>
> fs/fs.c:198:12: error: 'ext4_write_file' undeclared here (not in a
> function); did you mean 'ext4_read_file'?
>.write = ext4_write_file,
> ^~~
> Fix this problem by moving these options to Kconfig.
>
> Reported-by: Chris Spencer 
> Acked-by: Peng Fan 
> Signed-off-by: Fabio Estevam 

Can we have this one applied on 2019.01?

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

[U-Boot] [PATCH v1 03/21] net: Kconfig: FEC: Add dependency on VF610

Signed-off-by: Lukasz Majewski 
---

 drivers/net/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7044c6adf3..539db6d9f2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -187,7 +187,7 @@ config FEC_MXC_MDIO_BASE
 
 config FEC_MXC
bool "FEC Ethernet controller"
-   depends on MX5 || MX6 || MX7 || IMX8
+   depends on MX5 || MX6 || MX7 || IMX8 || VF610
help
  This driver supports the 10/100 Fast Ethernet controller for
  NXP i.MX processors.
-- 
2.11.0

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

[U-Boot] [PATCH v1 09/21] ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware

This patch allows moving vf610 based boards to a device tree and model.
Ported from Linux kernel - v4.20 (tag)

Signed-off-by: Lukasz Majewski 
---

 arch/arm/dts/vf.dtsi | 62 
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
index 65b17db13c..1c1ad04bf5 100644
--- a/arch/arm/dts/vf.dtsi
+++ b/arch/arm/dts/vf.dtsi
@@ -23,6 +23,10 @@
spi1 = 
ehci0 = 
ehci1 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
};
 
soc {
@@ -90,6 +94,22 @@
status = "disabled";
};
 
+   i2c0: i2c@40066000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x40066000 0x1000>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@40067000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x40067000 0x1000>;
+   status = "disabled";
+   };
+
iomuxc: iomuxc@40048000 {
compatible = "fsl,vf610-iomuxc";
reg = <0x40048000 0x1000>;
@@ -157,6 +177,48 @@
reg = <0x400b4000 0x800>;
status = "disabled";
};
+
+   esdhc1: esdhc@400b2000 {
+   compatible = "fsl,esdhc";
+   reg = <0x400b2000 0x1000>;
+   status = "disabled";
+   };
+
+   fec0: fec@400d {
+ compatible = "fsl,mvf600-fec";
+ reg = <0x400d 0x1000>;
+ status = "disabled";
+   };
+
+   fec1: fec@400d1000 {
+ compatible = "fsl,mvf600-fec";
+ reg = <0x400d1000 0x1000>;
+ status = "disabled";
+   };
+
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@400e6000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x400e6000 0x1000>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@400e7000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-i2c";
+   reg = <0x400e7000 0x1000>;
+   status = "disabled";
+   };
};
};
 };
-- 
2.11.0

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

[U-Boot] [PATCH v1 07/21] pcm052: board: Remove "m4go" command as it is superseded by "bootaux"

The "m4go" provides exactly the same functionality as the IMX generic
"bootaux" command. Remove it to not duplicate the code.

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 38 --
 1 file changed, 38 deletions(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index cfc8009102..4e4b870304 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -577,41 +577,3 @@ int checkboard(void)
 
return 0;
 }
-
-static int do_m4go(cmd_tbl_t *cmdtp, int flag, int argc,
-  char * const argv[])
-{
-   ulong addr;
-
-   /* Consume 'm4go' */
-   argc--; argv++;
-
-   /*
-* Parse provided address - default to load_addr in case not provided.
-*/
-
-   if (argc)
-   addr = simple_strtoul(argv[0], NULL, 16);
-   else
-   addr = load_addr;
-
-   /*
-* Write boot address in PERSISTENT_ENTRY1[31:0] aka SRC_GPR2[31:0]
-*/
-   writel(addr + 0x401, 0x4006E028);
-
-   /*
-* Start secondary processor by enabling its clock
-*/
-   writel(0x15a5a, 0x4006B08C);
-
-   return 1;
-}
-
-U_BOOT_CMD(
-   m4go, 2 /* one arg max */, 1 /* repeatable */, do_m4go,
-   "start the secondary Cortex-M4 from scatter file image",
-   "[]\n"
-   "- start secondary Cortex-M4 core using a scatter file image\n"
-   "The argument needs to be a scatter file\n"
-);
-- 
2.11.0

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

[U-Boot] [PATCH v1 17/21] config: bk4: Update u-boot envs to support NOR memories initial setup

Signed-off-by: Lukasz Majewski 
---

 include/configs/bk4r1.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index 7bd3411ff2..05ebb7d9c5 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -200,6 +200,24 @@
"ubi create rootfs2 15E15000 d; " \
"ubi create userdata; " \
"ubi detach\0" \
+   "setup_nor1=" BK4_NET_INIT \
+   "if tftp ${sys_addr} ${tftpdir}ubinor1.img; " \
+   "then sf probe 0:0; " \
+   "sf erase 0 0100; " \
+   "mtdparts default; " \
+   "ubi part nor; " \
+   "ubi create nor1fs; " \
+   "ubi write ${sys_addr} nor1fs ${filesize}; " \
+   "ubi detach; fi\0" \
+   "setup_nor2=" BK4_NET_INIT \
+   "if tftp ${sys_addr} ${tftpdir}ubinor2.img; " \
+   "then sf probe 0:1; " \
+   "sf erase 0 0100; " \
+   "mtdparts default; " \
+   "ubi part nor; " \
+   "ubi create nor2fs; " \
+   "ubi write ${sys_addr} nor2fs ${filesize}; " \
+   "ubi detach; fi\0" \
"prepare_install_bk4r1_envs=" \
"echo 'Preparing envs for SD card recovery!';" \
"setenv ipaddr 192.168.0.99;" \
-- 
2.11.0

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

Re: [U-Boot] [PATCH v1 01/21] ARM: DTS: vybrid: Add vf-u-boot.dtsi to set 'u-boot, dm-pre-reloc' in soc

On Mon, Jan 14, 2019 at 03:17:20PM +0100, Lukasz Majewski wrote:

> This property is necessary to allow pinctrl configuration before
> relocation (uart, DDR pins).
> 
> Separate file will facilitate updating vf.dtsi from the Linux kernel.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> 
>  arch/arm/dts/vf-u-boot.dtsi | 11 +++
>  arch/arm/dts/vf.dtsi|  1 +
>  2 files changed, 12 insertions(+)
>  create mode 100644 arch/arm/dts/vf-u-boot.dtsi

We should call the file 'vf610-u-boot.dtsi' which will get it
automatically included in all vf610 platforms but still allow boards
that need their own -u-boot.dtsi file to #include vf610-u-boot.dtsi

-- 
Tom


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

Re: [U-Boot] [PATCH v6 6/9] fs: prevent overwriting reserved memory

On Sat, Jan 5, 2019 at 2:56 AM Simon Glass  wrote:
>
> Hi Simon,
>
> On Fri, 14 Dec 2018 at 13:14, Simon Goldschmidt
>  wrote:
> >
> > This fixes CVE-2018-18440 ("insufficient boundary checks in filesystem
> > image load") by using lmb to check the load size of a file against
> > reserved memory addresses.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v6:
> > - fixed NULL pointer access in 'fdt_blob' passed to
> >   'boot_fdt_add_mem_rsv_regions'
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v2: None
> >
> >  fs/fs.c   | 56 ---
> >  include/lmb.h |  2 ++
> >  lib/lmb.c | 13 
> >  3 files changed, 68 insertions(+), 3 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> How about -ENOSPC instead of -1?

You mean in fs_read_lmb_check()? That would probably a good idea.

Not that you were replying to an old version, I had sent out v9 on 12/19/2018.
There's still -1 in there however. I'll send a v10 that fixes this.

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

Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5


Am 08.01.2019 um 13:56 schrieb Marek Vasut:

On 1/8/19 1:42 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:08 PM Marek Vasut  wrote:


On 1/8/19 1:06 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:


On 1/8/19 7:41 AM, Simon Goldschmidt wrote:

On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:


On 1/7/19 10:01 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:47 schrieb Marek Vasut:

On 1/7/19 9:33 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:25 schrieb Marek Vasut:

On 1/7/19 9:24 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:19 schrieb Marek Vasut:

On 1/7/19 8:36 PM, Simon Goldschmidt wrote:

When debug UART is enabled on socfpga_gen5, the debug uart driver
hangs
in an endless loop because 'socfpga_bridges_reset' calls printf
before
the debug UART is initialized.

After the generic fix for this in the UART driver did not work
due to
portability issues, let's just drop this printf statement when
called
from SPL with debug UART enabled.

Signed-off-by: Simon Goldschmidt 


Can we have an un-portable fix which at least works on SoCFPGA ? :)


This one worked on socfpga but broke rockchip:

https://patchwork.ozlabs.org/patch/992553/

However, the message below wasn't shown either with that patch
applied.
The code just runs too early to enable the UART.

Do you want to keep the message (although I failed to see in which
situation it can be printed) or do you just dislike the #ifdef thing?


I'd like to keep the error message if possible. Is it possible ?


I have *never* seen this message yet. I have failed to produce a
situation where it is shown.


I believe that.


This function ('socfpga_bridges_reset') is called 5 times throughout the
code, but only *one* single time with 'reset=0' as argument (only with
0, the code in question is executed). And this is in SPL before
initializing the console and even before the debug UART can be
initialized.

As I could see, the printf *is* executed on every boot (I saw the code
hanging when enabling debug UART). However, when not booting from FPGA,
it is just normal that the FPGA is not ready when running SPL. Why do
you want an error message here anyway?


I was under the impression this is an error message, but it might not be
so ? Maybe the wording is incorrect ?


Now that I re-read it, "aborting" is incorrect, yes.

So how should we proceed? This is an error message that can never be
shown (like the code is now) but breaks debug UART.

I'd say we can drop it altogether. It might only be interesint if (in
the future) that code would get called from somewhere else (i.e. later,
after console initialization).

Re-reading spl_gen5.c, there are some 'debug' calls before the debug
uart is initialized which probably would need to be removed as well, but
that's a different story...


How come those don't hang the system then ?


I just haven't enabled debug output in spl_gen5.c, yet. I guess they would hang
the system when enabling them.

While it would be easy to remove these debug statements, to be future-proof
it would of course make sense to make the debug UART robust against this.

But given the problems with Rockchip ns16550, we would need a dedicated
debug UART for socfpga to solve this. And that would probably mean code
duplication.


What is the problem with Rockchip ? I don't want various SoCs blocking
others.


I had sent a patch that does not wait for the TX fifo to hold more bytes if the
baudrate prescaler is 0 (according to both the socfgpa and the rockchip docs,
the UART is disabled if the prescaler is 0).

However, it seems that the prescaler was read back as 0 on a rockchip board
which caused chars to be missing from the console output.

See this mail:
https://lists.denx.de/pipermail/u-boot/2018-December/350355.html

I checked with Henri and did not find a solution so I reverted the patch:
https://patchwork.ozlabs.org/patch/1007211/

Keeping this patch but only for selected platforms would be my favourite, but it
would at least mean we need yet another debug UART selection, plus some changes
to make the "prescaler == 0" detection specific to this new debug UART.
Would this be better acceptable?


Doesn't the DT compatible tell you the UART type ? It does, so you can
match on that and apply the workaround accordingly .


We're talking about debug UART here only. No DT compatible involved.


Or you can cache the prescaler.


We already had that. Simon mentioned that on some platforms you neither have bss
available nor 'gd' at the point where the debug UART is inialized, so
there's not portable
storage to cache the prescaler, either :-(

The best I can think of right now would probably be to extend the list
of debug UARTS
with an socfpga specific type which compiles the same code as DEBUG_UART_NS16550
but enables this prescaler check.


Uhh, unless you find a better option, that'd be fine by me.


This patch should be dropped in favour to another patch taht adds a 
Kconfig option to check the

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

2019-01-14 Thread Dinh Nguyen

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
>> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the reset
> drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset controller ?
>>>
>>> I found that out just now: there's the function
>>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
>>> "De-assert reset for peripherals and bridges based on handoff". However,
>>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
>>> that, it enables *ALL* peripherals on the SoC (except for some DMA
>>> channels that aren't really used) :-)
>>>
>>> I guess that needs some cleaning up as well ;-)
>>
>> Yes
>>
>>> I think the proper thing to do here would be to remove this function and
>>> convert all drivers to provide appropriate 'resets' properties in the
>>> dts?
>>
>> Indeed
> 
> So I just did that and it works nice for SPL and U-Boot: By adding some
> "resets" properties the the main dtsi and adding reset bulk code to the
> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
> code from arch/mach_socfpga.
> 
> The problem would be that now Linux cannot use peripherals that aren't
> enabled by U-Boot because it relies on them being enabled. How are such
> dependencies solved? Because even if I would add reset support in the
> corresponding Linux drivers, we probably could not bootolder Kernels
> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> 

I added an early reset driver for SoCFPGA that should take care of this.
The patch is in v5.0-rc2[1].

Dinh

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/reset?id=b3ca9888f35fa6919569cf27c929dc0ac49e9716
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

Hi Dinh,

Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset
drivers
don't seem to work with it.

How do you un-reset IP blocks if you disable the reset controller ?

I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff". However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)

Yes

I think the proper thing to do here would be to remove this function and
convert all drivers to provide appropriate 'resets' properties in the
dts?

Indeed

So I just did that and it works nice for SPL and U-Boot: By adding some
"resets" properties the the main dtsi and adding reset bulk code to the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that aren't
enabled by U-Boot because it relies on them being enabled. How are such
dependencies solved? Because even if I would add reset support in the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...

I added an early reset driver for SoCFPGA that should take care of this.
The patch is in v5.0-rc2[1].

OK, it's good to know that this work is already done, I haven't
monitored this close enough.

But am I correct that my above problem remains even in v5.0 as not all
peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running with an
older kernel...

Regards,
Simon

Dinh

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/reset?id=b3ca9888f35fa6919569cf27c929dc0ac49e9716

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

Re: [U-Boot] [PATCH v2] spl: implement CRC check on U-Boot uImage

On Mon, Jan 14, 2019 at 04:38:24PM +0100, Simon Goldschmidt wrote:
> Tom,
> 
> Am 11.12.2018 um 02:07 schrieb Simon Glass:
> >On Wed, 28 Nov 2018 at 13:52, Simon Goldschmidt
> > wrote:
> >>
> >>SPL currently does not check uImage CRCs when loading U-Boot.
> >>
> >>This patch adds checking the uImage CRC when SPL loads U-Boot. It does
> >>this by reusing the existing config option SPL_CRC32_SUPPORT to allow
> >>leaving out the CRC check on boards where the additional code size or
> >>boot time is a problem (adding the CRC check currently adds ~1.4 kByte
> >>to flash).
> >>
> >>The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL
> >>support for legacy images is enabled to check the CRC on all boards
> >>that don't actively take countermeasures.
> >>
> >>Signed-off-by: Simon Goldschmidt 
> >>---
> >>
> >>Changes in v2:
> >>- added Kconfig option SPL_LEGACY_IMAGE_CRC_CHECK to enable/disable
> >>   checking CRC on legacy images
> >>
> >>  common/spl/Kconfig | 21 +++--
> >>  common/spl/spl.c   | 30 +-
> >>  include/spl.h  |  5 +
> >>  3 files changed, 49 insertions(+), 7 deletions(-)
> >
> >Reviewed-by: Simon Glass 
> 
> This is assigned to you in patchwork, any reason you did not add it for the
> 2019.01 release? Is there anything missing or was this just lost?

I think I might have filed this off mentally as "Did we still want to do
this?", so I'll pick it up for the next release, thanks!

-- 
Tom


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

[U-Boot] [PATCH v1 16/21] config: bk4: Update u-boot script to support recovery via SD card

Signed-off-by: Lukasz Majewski 
---

 include/configs/bk4r1.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/configs/bk4r1.h b/include/configs/bk4r1.h
index bbd3e4e636..7bd3411ff2 100644
--- a/include/configs/bk4r1.h
+++ b/include/configs/bk4r1.h
@@ -189,6 +189,37 @@
"ubi part system; " \
"ubi write ${sys_addr} rootfs${active_workset} ${filesize}; " \
"ubi detach; fi\0" \
+   "setup_dtbkernel=nand erase.part dtbkernel; " \
+   "ubi part dtbkernel; " \
+   "ubi create dtbkernel1 972000 s; " \
+   "ubi create dtbkernel2 972000 s; " \
+   "ubi detach\0" \
+   "setup_system=nand erase.part system; " \
+   "ubi part system; " \
+   "ubi create rootfs1 15E15000 d; " \
+   "ubi create rootfs2 15E15000 d; " \
+   "ubi create userdata; " \
+   "ubi detach\0" \
+   "prepare_install_bk4r1_envs=" \
+   "echo 'Preparing envs for SD card recovery!';" \
+   "setenv ipaddr 192.168.0.99;" \
+   "setenv serverip 192.168.0.50;" \
+   "\0" \
+   "install_bk4r1rs="\
+   "led 0 on; " \
+   "nand erase.chip; mtdparts default; "\
+   "led 1 on; "\
+   "run setup_dtbkernel; " \
+   "run setup_system; " \
+   "led 2 on;" \
+   "run update_bootloader_from_sd; "\
+   "run update_dtbkernel_from_sd; "\
+   "run update_rootfs_from_sd; "\
+   "setenv bootcmd 'run bootcmd_nand'; "\
+   "saveenv; " \
+   "led 3 on; " \
+   "echo Finished - Please Power off, REMOVE SDCARD and set boot" \
+   "source to NAND\0" \
"active_workset=1\0"
 
 /* Miscellaneous configurable options */
-- 
2.11.0

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

[U-Boot] [PATCH v1 15/21] pcm052: board: Remove in-board setup code (it is now replaced by DM setup)

This commit cleans up the pcm052.c file to remove dead code after moving to
DTS and DM.

Signed-off-by: Lukasz Majewski 
---

 board/phytec/pcm052/pcm052.c | 267 ---
 1 file changed, 267 deletions(-)

diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
index 95df0be6c1..4a18b0e0f4 100644
--- a/board/phytec/pcm052/pcm052.c
+++ b/board/phytec/pcm052/pcm052.c
@@ -13,79 +13,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/*
- * Default DDR pad settings in arch/arm/include/asm/arch-vf610/iomux-vf610.h
- * do not match our settings. Let us (re)define our own settings here.
- */
-
-#define PCM052_VF610_DDR_PAD_CTRL  PAD_CTL_DSE_20ohm
-#define PCM052_VF610_DDR_PAD_CTRL_1(PAD_CTL_DSE_20ohm | \
-   PAD_CTL_INPUT_DIFFERENTIAL)
-#define PCM052_VF610_DDR_RESET_PAD_CTL (PAD_CTL_DSE_150ohm | \
-   PAD_CTL_PUS_100K_UP | \
-   PAD_CTL_INPUT_DIFFERENTIAL)
-
-enum {
-   PCM052_VF610_PAD_DDR_RESETB = IOMUX_PAD(0x021c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_RESET_PAD_CTL),
-   PCM052_VF610_PAD_DDR_A15__DDR_A_15  = IOMUX_PAD(0x0220, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A14__DDR_A_14  = IOMUX_PAD(0x0224, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A13__DDR_A_13  = IOMUX_PAD(0x0228, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A12__DDR_A_12  = IOMUX_PAD(0x022c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A11__DDR_A_11  = IOMUX_PAD(0x0230, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A10__DDR_A_10  = IOMUX_PAD(0x0234, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A9__DDR_A_9= IOMUX_PAD(0x0238, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A8__DDR_A_8= IOMUX_PAD(0x023c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A7__DDR_A_7= IOMUX_PAD(0x0240, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A6__DDR_A_6= IOMUX_PAD(0x0244, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A5__DDR_A_5= IOMUX_PAD(0x0248, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A4__DDR_A_4= IOMUX_PAD(0x024c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A3__DDR_A_3= IOMUX_PAD(0x0250, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A2__DDR_A_2= IOMUX_PAD(0x0254, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A1__DDR_A_1= IOMUX_PAD(0x0258, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_A0__DDR_A_0= IOMUX_PAD(0x025c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA2__DDR_BA_2  = IOMUX_PAD(0x0260, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA1__DDR_BA_1  = IOMUX_PAD(0x0264, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_BA0__DDR_BA_0  = IOMUX_PAD(0x0268, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CAS__DDR_CAS_B = IOMUX_PAD(0x026c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CKE__DDR_CKE_0 = IOMUX_PAD(0x0270, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_CLK__DDR_CLK_0 = IOMUX_PAD(0x0274, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL_1),
-   PCM052_VF610_PAD_DDR_CS__DDR_CS_B_0 = IOMUX_PAD(0x0278, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D15__DDR_D_15  = IOMUX_PAD(0x027c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D14__DDR_D_14  = IOMUX_PAD(0x0280, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D13__DDR_D_13  = IOMUX_PAD(0x0284, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D12__DDR_D_12  = IOMUX_PAD(0x0288, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D11__DDR_D_11  = IOMUX_PAD(0x028c, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D10__DDR_D_10  = IOMUX_PAD(0x0290, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-   PCM052_VF610_PAD_DDR_D9__DDR_D_9= IOMUX_PAD(0x0294, 
__NA_, 0, __NA_, 0, PCM052_VF610_DDR_PAD_CTRL),
-

Re: [U-Boot] [PATCH] net: fix env flags for eth10addr and above


Am 14.12.2018 um 14:28 schrieb Tom Rini:

On Fri, Dec 14, 2018 at 09:56:19AM +0100, Simon Goldschmidt wrote:


+Tom

On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
 wrote:


Am 22.11.2018 um 17:06 schrieb Simon Goldschmidt:

With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10
interfaces (0..9) as the number can only have one digit.

On boards with more than 10 interfaces, this leads to the protection
and format checks being absent for eth10addr and above.

Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow
more than one digit.

Signed-off-by: Simon Goldschmidt 
---

   include/env_flags.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/env_flags.h b/include/env_flags.h
index cc2c34f939..23744e395c 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -38,7 +38,7 @@ enum env_flags_varaccess {

   #ifdef CONFIG_CMD_NET
   #ifdef CONFIG_REGEX
-#define ETHADDR_WILDCARD "\\d?"
+#define ETHADDR_WILDCARD "\\d*"
   #else
   #define ETHADDR_WILDCARD
   #endif



Ping?


I haven't gotten an answer to this for nearly one month. It's a small
change, can this go in for v2019.01 please?


I'd filed this off to Joe to grab since it is indeed small and a
clean-up.


Will you be taking this after the release or is there anything missing? 
It's assigned to you in patchwork but I didn't get any real reply...


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

Re: [U-Boot] [PATCH] net: remove duplicate definition of ETHADDR_WILDCARD


Joe,

Am 14.12.2018 um 14:43 schrieb Simon Goldschmidt:

On Fri, Dec 14, 2018 at 2:28 PM Tom Rini  wrote:


On Fri, Dec 14, 2018 at 09:55:32AM +0100, Simon Goldschmidt wrote:

+ Tom


On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
 wrote:


Am 22.11.2018 um 16:58 schrieb Simon Goldschmidt:

ETHADDR_WILDCARD is defined as the same value in both env_flags.h
and env_callback.h

As env_callback.h includes env_flags.h, remove the duplicate definition
from env_callback.h

Signed-off-by: Simon Goldschmidt 
---

   include/env_callback.h | 2 --
   1 file changed, 2 deletions(-)

diff --git a/include/env_callback.h b/include/env_callback.h
index 3c44ff574b..507a52e13c 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -32,10 +32,8 @@

   #ifdef CONFIG_REGEX
   #define ENV_DOT_ESCAPE "\\"
-#define ETHADDR_WILDCARD "\\d?"
   #else
   #define ENV_DOT_ESCAPE
-#define ETHADDR_WILDCARD
   #endif

   #ifdef CONFIG_CMD_DNS



Ping?


I haven't gotten an answer to this for nearly one month. It's a small
change, can this go in for v2019.01 please?


I'd filed this off to Joe to grab since it is indeed small and a
clean-up.


Well, I haven't heard from Joe since about one months now, that's why
I added you...


Will you be taking this after the release or is there anything missing? 
It's assigned to you in patchwork but I didn't get any real reply...


Regards,
Simon

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

Re: [U-Boot] [PATCH v2 5/9] arm: actions: add S700 SoC device tree

2019-01-14 Thread Rob Herring

On Mon, Jan 14, 2019 at 6:46 AM Amit Singh Tomar  wrote:
>
> This patch adds .dtsi file(sync with Linux 4.20) and required binding
> for S700 SoC that is a 64-bit Quad-core ARM Cortex-A53 cores.
>
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v1:
> * Moved the u-boot specific changes to s700-u-boot.dtsi, now
>   s700.dtsi is in complete sync with Linux 4.20.
> ---
>  arch/arm/dts/s700.dtsi   | 190 
> +++
>  include/dt-bindings/clock/actions,s700-cmu.h | 118 +
>  2 files changed, 308 insertions(+)
>  create mode 100644 arch/arm/dts/s700.dtsi
>  create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h
>
> diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
> new file mode 100644
> index 000..192c7b3
> --- /dev/null
> +++ b/arch/arm/dts/s700.dtsi
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Andreas Färber
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "actions,s700";
> +   interrupt-parent = <>;
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   cpus {
> +   #address-cells = <2>;
> +   #size-cells = <0>;
> +
> +   cpu0: cpu@0 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a53", "arm,armv8";

Drop the 'arm,armv8'. This was used inconsistently and is in the
process of being removed except for s/w models.

> +   reg = <0x0 0x0>;
> +   enable-method = "psci";
> +   };
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 7:58 PM, Simon Goldschmidt wrote:
> Am 14.01.2019 um 19:31 schrieb Marek Vasut:
>> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
>>> Hi Dinh,
>>
>> Hi,
>>
>>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
 Hi Simon,

 On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
>> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the reset
> drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset controller ?
>>>
>>> I found that out just now: there's the function
>>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
>>> "De-assert reset for peripherals and bridges based on handoff".
>>> However,
>>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
>>> that, it enables *ALL* peripherals on the SoC (except for some DMA
>>> channels that aren't really used) :-)
>>>
>>> I guess that needs some cleaning up as well ;-)
>>
>> Yes
>>
>>> I think the proper thing to do here would be to remove this
>>> function and
>>> convert all drivers to provide appropriate 'resets' properties in
>>> the
>>> dts?
>>
>> Indeed
>
> So I just did that and it works nice for SPL and U-Boot: By adding
> some
> "resets" properties the the main dtsi and adding reset bulk code to
> the
> cadence_qspi, denali_dt nand and drivers, I can nearly remove the
> reset
> code from arch/mach_socfpga.
>
> The problem would be that now Linux cannot use peripherals that aren't
> enabled by U-Boot because it relies on them being enabled. How are
> such
> dependencies solved? Because even if I would add reset support in the
> corresponding Linux drivers, we probably could not bootolder Kernels
> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>

 I added an early reset driver for SoCFPGA that should take care of
 this.
 The patch is in v5.0-rc2[1].
>>>
>>> OK, it's good to know that this work is already done, I haven't
>>> monitored this close enough.
>>
>> We had the same problem with A10, indeed.
>>
>>> But am I correct that my above problem remains even in v5.0 as not all
>>> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
>>> qspi) and would thuse not be taken out of reset by Linux?
>>>
>>> Plus: should U-Boot work with older Linux kernels? Because if so, we
>>> need fallback code in U-Boot to unreset peripherals when running with an
>>> older kernel...
>>
>> Yes, it'd break old broken kernels . The real question is, do we care ?
> 
> Ok, so that at leat shows me I'm going into the right direction :-)
> 
> There are some problems though:
> - I do care (we're running 4.9 currently) *g*
> - people running an RT kernel will care for a while (until the next
> stable RT after fixing this will be released)
> - we would currently be breaking *all* kernels, since no kernel should
> yet be able to deassert reset for mmc and qspi (unless this is already
> done by U-Boot)...
> 
> So would it be OK to add a Kconfig option to U-Boot to keep the current
> behaviour (for old broken kernels like you said) until that code is
> spread widely enough? Or is that a no-go?

Would be nice to be able to tweak the reset driver behavior at runtime,
to unreset things before booting the kernel if the user desires so.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 8:43 PM, Simon Goldschmidt wrote:
> Am 14.01.2019 um 20:33 schrieb Marek Vasut:
>> On 1/14/19 7:58 PM, Simon Goldschmidt wrote:
>>> Am 14.01.2019 um 19:31 schrieb Marek Vasut:
 On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> Hi Dinh,

 Hi,

> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>> Hi Simon,
>>
>> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
>>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
 On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
>>> disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset
>>> drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset
>> controller ?
>
> I found that out just now: there's the function
> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> "De-assert reset for peripherals and bridges based on handoff".
> However,
> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
> doing
> that, it enables *ALL* peripherals on the SoC (except for some DMA
> channels that aren't really used) :-)
>
> I guess that needs some cleaning up as well ;-)

 Yes

> I think the proper thing to do here would be to remove this
> function and
> convert all drivers to provide appropriate 'resets' properties in
> the
> dts?

 Indeed
>>>
>>> So I just did that and it works nice for SPL and U-Boot: By adding
>>> some
>>> "resets" properties the the main dtsi and adding reset bulk code to
>>> the
>>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the
>>> reset
>>> code from arch/mach_socfpga.
>>>
>>> The problem would be that now Linux cannot use peripherals that
>>> aren't
>>> enabled by U-Boot because it relies on them being enabled. How are
>>> such
>>> dependencies solved? Because even if I would add reset support in
>>> the
>>> corresponding Linux drivers, we probably could not bootolder Kernels
>>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>>>
>>
>> I added an early reset driver for SoCFPGA that should take care of
>> this.
>> The patch is in v5.0-rc2[1].
>
> OK, it's good to know that this work is already done, I haven't
> monitored this close enough.

 We had the same problem with A10, indeed.

> But am I correct that my above problem remains even in v5.0 as not all
> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> qspi) and would thuse not be taken out of reset by Linux?
>
> Plus: should U-Boot work with older Linux kernels? Because if so, we
> need fallback code in U-Boot to unreset peripherals when running
> with an
> older kernel...

 Yes, it'd break old broken kernels . The real question is, do we care ?
>>>
>>> Ok, so that at leat shows me I'm going into the right direction :-)
>>>
>>> There are some problems though:
>>> - I do care (we're running 4.9 currently) *g*
>>> - people running an RT kernel will care for a while (until the next
>>> stable RT after fixing this will be released)
>>> - we would currently be breaking *all* kernels, since no kernel should
>>> yet be able to deassert reset for mmc and qspi (unless this is already
>>> done by U-Boot)...
>>>
>>> So would it be OK to add a Kconfig option to U-Boot to keep the current
>>> behaviour (for old broken kernels like you said) until that code is
>>> spread widely enough? Or is that a no-go?
>>
>> Would be nice to be able to tweak the reset driver behavior at runtime,
>> to unreset things before booting the kernel if the user desires so.
> 
> Instead of tweaking the reset driver, we could just add a command that
> does that 'rstmgr->permodrst = 0;' thing my patch would remove.

I don't want a new custom command.

> Since noone has complained so far, I think writing 0 should be OK here.
> I don't think it would make too much sense to use the reset handoff
> defines from Quartus output for such a command. I think the way Quartus
> does this is strange anyway...
> 
> The question is if defconfigs should be able to use this to
> automatically build a U-Boot config for older kernels. If so, we'd still
> need a Kconfig option?

I'd much rather have this runtime configurable.

> Thinking further about cleanup: I guess the clock driver is not that
> hard to implement, either. The only thing that's driving me mad is
> pinmux. Is there any chance to get more info from Intel to

[U-Boot] Proposed fastboot changes

2019-01-14 Thread Douglas Zobel

I've made some changes to the fastboot handlers to meet my needs.  If there
is interest, I can prepare patches and submit them upstream.  The changes
are:

BUGFIX:  Currently the 'fastboot format [partition]' command (run from PC)
formats the partition smaller than expected.  Change
getvar_partition_size() to return partition size in # of bytes instead of
the current behavior of # of blocks.  The 'fastboot format [partition]'
command expect u-boot to return the size in number of bytes in order to
format the partition correctly.

Make the a fastboot oem command handler with a dynamic lookup like the base
fastboot command handler currently is.  This would allow easily adding new
oem commands in the baseline software (such as below).  It would also allow
for board files to extend the oem handler to handle OEM specific cases.  I
would use a weakly defined default oem command handler (empty function)
which a board file can optionally override to handle board specific
commands.

Currently the 'fastboot oem format' command (gpt write mmc # $partitions)
is supported.  I'd like to add a 'fastboot oem verify' (gpt verify mmc #
$partitions) to help the flashing PC detect when a board needs to be
re-formatted.

-Doug

-- 










This email and any attachments are for the exclusive use of the 
intended recipient(s) and may contain confidential and/or privileged 
information.  Inadvertent disclosure of this message does not constitute a 
waiver of any privilege, right or remedy.  If you are not the intended 
recipient, please do not directly or indirectly use, disclose or distribute 
this message, and please contact the sender and delete this email, any 
attachments and all copies.  Climate and its affiliates may use, read or 
archive email communications (including attachments) through its computer 
network, as permitted by applicable law.  Climate and its affiliates (or an 
external service provider) may also scan emails and attachments on its 
computer network to ensure systems operate efficiently and to minimize 
security risks. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 9:30 PM, Simon Goldschmidt wrote:
> On Mon, Jan 14, 2019 at 9:23 PM Marek Vasut  wrote:
>>
>> On 1/14/19 9:12 PM, Simon Goldschmidt wrote:
>>> Am 14.01.2019 um 21:01 schrieb Marek Vasut:
 On 1/14/19 8:43 PM, Simon Goldschmidt wrote:
> Am 14.01.2019 um 20:33 schrieb Marek Vasut:
>> On 1/14/19 7:58 PM, Simon Goldschmidt wrote:
>>> Am 14.01.2019 um 19:31 schrieb Marek Vasut:
 On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> Hi Dinh,

 Hi,

> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>> Hi Simon,
>>
>> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
>>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
 On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
>>> disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the
>>> reset
>>> drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset
>> controller ?
>
> I found that out just now: there's the function
> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> "De-assert reset for peripherals and bridges based on handoff".
> However,
> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
> doing
> that, it enables *ALL* peripherals on the SoC (except for
> some DMA
> channels that aren't really used) :-)
>
> I guess that needs some cleaning up as well ;-)

 Yes

> I think the proper thing to do here would be to remove this
> function and
> convert all drivers to provide appropriate 'resets'
> properties in
> the
> dts?

 Indeed
>>>
>>> So I just did that and it works nice for SPL and U-Boot: By adding
>>> some
>>> "resets" properties the the main dtsi and adding reset bulk
>>> code to
>>> the
>>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the
>>> reset
>>> code from arch/mach_socfpga.
>>>
>>> The problem would be that now Linux cannot use peripherals that
>>> aren't
>>> enabled by U-Boot because it relies on them being enabled. How are
>>> such
>>> dependencies solved? Because even if I would add reset support in
>>> the
>>> corresponding Linux drivers, we probably could not bootolder
>>> Kernels
>>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>>>
>>
>> I added an early reset driver for SoCFPGA that should take care of
>> this.
>> The patch is in v5.0-rc2[1].
>
> OK, it's good to know that this work is already done, I haven't
> monitored this close enough.

 We had the same problem with A10, indeed.

> But am I correct that my above problem remains even in v5.0 as
> not all
> peripherals in socfpga.dtsi have a "resets" property set (e.g.
> mmc and
> qspi) and would thuse not be taken out of reset by Linux?
>
> Plus: should U-Boot work with older Linux kernels? Because if so, we
> need fallback code in U-Boot to unreset peripherals when running
> with an
> older kernel...

 Yes, it'd break old broken kernels . The real question is, do we
 care ?
>>>
>>> Ok, so that at leat shows me I'm going into the right direction :-)
>>>
>>> There are some problems though:
>>> - I do care (we're running 4.9 currently) *g*
>>> - people running an RT kernel will care for a while (until the next
>>> stable RT after fixing this will be released)
>>> - we would currently be breaking *all* kernels, since no kernel should
>>> yet be able to deassert reset for mmc and qspi (unless this is already
>>> done by U-Boot)...
>>>
>>> So would it be OK to add a Kconfig option to U-Boot to keep the
>>> current
>>> behaviour (for old broken kernels like you said) until that code is
>>> spread widely enough? Or is that a no-go?
>>
>> Would be nice to be able to tweak the reset driver behavior at runtime,
>> to unreset things before booting the kernel if the user desires so.
>
> Instead of tweaking the reset driver, we could just add a command that
> does that 'rstmgr->permodrst = 0;'

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> Hi Dinh,

Hi,

> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>> Hi Simon,
>>
>> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
>>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
 On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
>>> disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset
>>> drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset controller ?
>
> I found that out just now: there's the function
> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> "De-assert reset for peripherals and bridges based on handoff".
> However,
> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
> that, it enables *ALL* peripherals on the SoC (except for some DMA
> channels that aren't really used) :-)
>
> I guess that needs some cleaning up as well ;-)

 Yes

> I think the proper thing to do here would be to remove this
> function and
> convert all drivers to provide appropriate 'resets' properties in the
> dts?

 Indeed
>>>
>>> So I just did that and it works nice for SPL and U-Boot: By adding some
>>> "resets" properties the the main dtsi and adding reset bulk code to the
>>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
>>> code from arch/mach_socfpga.
>>>
>>> The problem would be that now Linux cannot use peripherals that aren't
>>> enabled by U-Boot because it relies on them being enabled. How are such
>>> dependencies solved? Because even if I would add reset support in the
>>> corresponding Linux drivers, we probably could not bootolder Kernels
>>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>>>
>>
>> I added an early reset driver for SoCFPGA that should take care of this.
>> The patch is in v5.0-rc2[1].
> 
> OK, it's good to know that this work is already done, I haven't
> monitored this close enough.

We had the same problem with A10, indeed.

> But am I correct that my above problem remains even in v5.0 as not all
> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> qspi) and would thuse not be taken out of reset by Linux?
> 
> Plus: should U-Boot work with older Linux kernels? Because if so, we
> need fallback code in U-Boot to unreset peripherals when running with an
> older kernel...

Yes, it'd break old broken kernels . The real question is, do we care ?

> Regards,
> Simon
> 
>>
>> Dinh
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/reset?id=b3ca9888f35fa6919569cf27c929dc0ac49e9716
>>
>>
> 


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

Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5


Am 14.01.2019 um 19:26 schrieb Marek Vasut:

On 1/14/19 4:21 PM, Simon Goldschmidt wrote:

Am 08.01.2019 um 13:56 schrieb Marek Vasut:

On 1/8/19 1:42 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:08 PM Marek Vasut  wrote:


On 1/8/19 1:06 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:


On 1/8/19 7:41 AM, Simon Goldschmidt wrote:

On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:


On 1/7/19 10:01 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:47 schrieb Marek Vasut:

On 1/7/19 9:33 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:25 schrieb Marek Vasut:

On 1/7/19 9:24 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 21:19 schrieb Marek Vasut:

On 1/7/19 8:36 PM, Simon Goldschmidt wrote:

When debug UART is enabled on socfpga_gen5, the debug
uart driver
hangs
in an endless loop because 'socfpga_bridges_reset' calls
printf
before
the debug UART is initialized.

After the generic fix for this in the UART driver did not
work
due to
portability issues, let's just drop this printf statement
when
called
from SPL with debug UART enabled.

Signed-off-by: Simon Goldschmidt



Can we have an un-portable fix which at least works on
SoCFPGA ? :)


This one worked on socfpga but broke rockchip:

https://patchwork.ozlabs.org/patch/992553/

However, the message below wasn't shown either with that patch
applied.
The code just runs too early to enable the UART.

Do you want to keep the message (although I failed to see
in which
situation it can be printed) or do you just dislike the
#ifdef thing?


I'd like to keep the error message if possible. Is it
possible ?


I have *never* seen this message yet. I have failed to produce a
situation where it is shown.


I believe that.


This function ('socfpga_bridges_reset') is called 5 times
throughout the
code, but only *one* single time with 'reset=0' as argument
(only with
0, the code in question is executed). And this is in SPL before
initializing the console and even before the debug UART can be
initialized.

As I could see, the printf *is* executed on every boot (I saw
the code
hanging when enabling debug UART). However, when not booting
from FPGA,
it is just normal that the FPGA is not ready when running
SPL. Why do
you want an error message here anyway?


I was under the impression this is an error message, but it
might not be
so ? Maybe the wording is incorrect ?


Now that I re-read it, "aborting" is incorrect, yes.

So how should we proceed? This is an error message that can
never be
shown (like the code is now) but breaks debug UART.

I'd say we can drop it altogether. It might only be interesint
if (in
the future) that code would get called from somewhere else
(i.e. later,
after console initialization).

Re-reading spl_gen5.c, there are some 'debug' calls before the
debug
uart is initialized which probably would need to be removed as
well, but
that's a different story...


How come those don't hang the system then ?


I just haven't enabled debug output in spl_gen5.c, yet. I guess
they would hang
the system when enabling them.

While it would be easy to remove these debug statements, to be
future-proof
it would of course make sense to make the debug UART robust
against this.

But given the problems with Rockchip ns16550, we would need a
dedicated
debug UART for socfpga to solve this. And that would probably
mean code
duplication.


What is the problem with Rockchip ? I don't want various SoCs
blocking
others.


I had sent a patch that does not wait for the TX fifo to hold more
bytes if the
baudrate prescaler is 0 (according to both the socfgpa and the
rockchip docs,
the UART is disabled if the prescaler is 0).

However, it seems that the prescaler was read back as 0 on a
rockchip board
which caused chars to be missing from the console output.

See this mail:
https://lists.denx.de/pipermail/u-boot/2018-December/350355.html

I checked with Henri and did not find a solution so I reverted the
patch:
https://patchwork.ozlabs.org/patch/1007211/

Keeping this patch but only for selected platforms would be my
favourite, but it
would at least mean we need yet another debug UART selection, plus
some changes
to make the "prescaler == 0" detection specific to this new debug
UART.
Would this be better acceptable?


Doesn't the DT compatible tell you the UART type ? It does, so you can
match on that and apply the workaround accordingly .


We're talking about debug UART here only. No DT compatible involved.


Or you can cache the prescaler.


We already had that. Simon mentioned that on some platforms you
neither have bss
available nor 'gd' at the point where the debug UART is inialized, so
there's not portable
storage to cache the prescaler, either :-(

The best I can think of right now would probably be to extend the list
of debug UARTS
with an socfpga specific type which compiles the same code as
DEBUG_UART_NS16550
but enables this prescaler check.


Uhh, unless you find a better option, that'd be fine by me.


This patch

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 14.01.2019 um 20:33 schrieb Marek Vasut:

On 1/14/19 7:58 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 19:31 schrieb Marek Vasut:

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:

Hi Dinh,


Hi,


Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset
drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff".
However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this
function and
convert all drivers to provide appropriate 'resets' properties in
the
dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding
some
"resets" properties the the main dtsi and adding reset bulk code to
the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the
reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that aren't
enabled by U-Boot because it relies on them being enabled. How are
such
dependencies solved? Because even if I would add reset support in the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...



I added an early reset driver for SoCFPGA that should take care of
this.
The patch is in v5.0-rc2[1].


OK, it's good to know that this work is already done, I haven't
monitored this close enough.


We had the same problem with A10, indeed.


But am I correct that my above problem remains even in v5.0 as not all
peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running with an
older kernel...


Yes, it'd break old broken kernels . The real question is, do we care ?


Ok, so that at leat shows me I'm going into the right direction :-)

There are some problems though:
- I do care (we're running 4.9 currently) *g*
- people running an RT kernel will care for a while (until the next
stable RT after fixing this will be released)
- we would currently be breaking *all* kernels, since no kernel should
yet be able to deassert reset for mmc and qspi (unless this is already
done by U-Boot)...

So would it be OK to add a Kconfig option to U-Boot to keep the current
behaviour (for old broken kernels like you said) until that code is
spread widely enough? Or is that a no-go?


Would be nice to be able to tweak the reset driver behavior at runtime,
to unreset things before booting the kernel if the user desires so.


Instead of tweaking the reset driver, we could just add a command that 
does that 'rstmgr->permodrst = 0;' thing my patch would remove.


Since noone has complained so far, I think writing 0 should be OK here. 
I don't think it would make too much sense to use the reset handoff 
defines from Quartus output for such a command. I think the way Quartus 
does this is strange anyway...


The question is if defconfigs should be able to use this to 
automatically build a U-Boot config for older kernels. If so, we'd still 
need a Kconfig option?


Thinking further about cleanup: I guess the clock driver is not that 
hard to implement, either. The only thing that's driving me mad is 
pinmux. Is there any chance to get more info from Intel to write this 
properly so we can get rid of that iocsr scanchain defines?


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

Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5

On 1/14/19 4:21 PM, Simon Goldschmidt wrote:
> Am 08.01.2019 um 13:56 schrieb Marek Vasut:
>> On 1/8/19 1:42 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:08 PM Marek Vasut  wrote:

 On 1/8/19 1:06 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:

 On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
>> On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
 On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
>> On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
>>> When debug UART is enabled on socfpga_gen5, the debug
>>> uart driver
>>> hangs
>>> in an endless loop because 'socfpga_bridges_reset' calls
>>> printf
>>> before
>>> the debug UART is initialized.
>>>
>>> After the generic fix for this in the UART driver did not
>>> work
>>> due to
>>> portability issues, let's just drop this printf statement
>>> when
>>> called
>>> from SPL with debug UART enabled.
>>>
>>> Signed-off-by: Simon Goldschmidt
>>> 
>>
>> Can we have an un-portable fix which at least works on
>> SoCFPGA ? :)
>
> This one worked on socfpga but broke rockchip:
>
> https://patchwork.ozlabs.org/patch/992553/
>
> However, the message below wasn't shown either with that patch
> applied.
> The code just runs too early to enable the UART.
>
> Do you want to keep the message (although I failed to see
> in which
> situation it can be printed) or do you just dislike the
> #ifdef thing?

 I'd like to keep the error message if possible. Is it
 possible ?
>>>
>>> I have *never* seen this message yet. I have failed to produce a
>>> situation where it is shown.
>>
>> I believe that.
>>
>>> This function ('socfpga_bridges_reset') is called 5 times
>>> throughout the
>>> code, but only *one* single time with 'reset=0' as argument
>>> (only with
>>> 0, the code in question is executed). And this is in SPL before
>>> initializing the console and even before the debug UART can be
>>> initialized.
>>>
>>> As I could see, the printf *is* executed on every boot (I saw
>>> the code
>>> hanging when enabling debug UART). However, when not booting
>>> from FPGA,
>>> it is just normal that the FPGA is not ready when running
>>> SPL. Why do
>>> you want an error message here anyway?
>>
>> I was under the impression this is an error message, but it
>> might not be
>> so ? Maybe the wording is incorrect ?
>
> Now that I re-read it, "aborting" is incorrect, yes.
>
> So how should we proceed? This is an error message that can
> never be
> shown (like the code is now) but breaks debug UART.
>
> I'd say we can drop it altogether. It might only be interesint
> if (in
> the future) that code would get called from somewhere else
> (i.e. later,
> after console initialization).
>
> Re-reading spl_gen5.c, there are some 'debug' calls before the
> debug
> uart is initialized which probably would need to be removed as
> well, but
> that's a different story...

 How come those don't hang the system then ?
>>>
>>> I just haven't enabled debug output in spl_gen5.c, yet. I guess
>>> they would hang
>>> the system when enabling them.
>>>
>>> While it would be easy to remove these debug statements, to be
>>> future-proof
>>> it would of course make sense to make the debug UART robust
>>> against this.
>>>
>>> But given the problems with Rockchip ns16550, we would need a
>>> dedicated
>>> debug UART for socfpga to solve this. And that would probably
>>> mean code
>>> duplication.
>>
>> What is the problem with Rockchip ? I don't want various SoCs
>> blocking
>> others.
>
> I had sent a patch that does not wait for the TX fifo to hold more
> bytes if the
> baudrate prescaler is 0 (according to both the socfgpa and the
> rockchip docs,
> the UART is disabled if the prescaler is 0).
>
> However, it seems that the prescaler was read back

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 14.01.2019 um 21:01 schrieb Marek Vasut:

On 1/14/19 8:43 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 20:33 schrieb Marek Vasut:

On 1/14/19 7:58 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 19:31 schrieb Marek Vasut:

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:

Hi Dinh,


Hi,


Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset
drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset
controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff".
However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this
function and
convert all drivers to provide appropriate 'resets' properties in
the
dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding
some
"resets" properties the the main dtsi and adding reset bulk code to
the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the
reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that
aren't
enabled by U-Boot because it relies on them being enabled. How are
such
dependencies solved? Because even if I would add reset support in
the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...



I added an early reset driver for SoCFPGA that should take care of
this.
The patch is in v5.0-rc2[1].


OK, it's good to know that this work is already done, I haven't
monitored this close enough.


We had the same problem with A10, indeed.


But am I correct that my above problem remains even in v5.0 as not all
peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running
with an
older kernel...


Yes, it'd break old broken kernels . The real question is, do we care ?


Ok, so that at leat shows me I'm going into the right direction :-)

There are some problems though:
- I do care (we're running 4.9 currently) *g*
- people running an RT kernel will care for a while (until the next
stable RT after fixing this will be released)
- we would currently be breaking *all* kernels, since no kernel should
yet be able to deassert reset for mmc and qspi (unless this is already
done by U-Boot)...

So would it be OK to add a Kconfig option to U-Boot to keep the current
behaviour (for old broken kernels like you said) until that code is
spread widely enough? Or is that a no-go?


Would be nice to be able to tweak the reset driver behavior at runtime,
to unreset things before booting the kernel if the user desires so.


Instead of tweaking the reset driver, we could just add a command that
does that 'rstmgr->permodrst = 0;' thing my patch would remove.


I don't want a new custom command.


Since noone has complained so far, I think writing 0 should be OK here.
I don't think it would make too much sense to use the reset handoff
defines from Quartus output for such a command. I think the way Quartus
does this is strange anyway...

The question is if defconfigs should be able to use this to
automatically build a U-Boot config for older kernels. If so, we'd still
need a Kconfig option?


I'd much rather have this runtime configurable.


Then I'm afraid I don't know what you mean by "runtime configurable". 
What should be the configuration source that is evaluated at runtime?





Thinking further about cleanup: I guess the clock driver is not that
hard to implement, either. The only thing that's driving me mad is
pinmux. Is there any chance to get more info from Intel to write this
properly so we can get rid of that iocsr scanchain defines?


Clock driver should be easy, yes. Pinmux, I don't know, maybe project
chibi has some information (the cyclone I documentation project).


Interesing, I didn't know that project. The only thing I found is a repo 
on github. But it seems like that one only contains FPGA-related stuff, 
nothing about the HPS side...


Regards,
Simon

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 9:12 PM, Simon Goldschmidt wrote:
> Am 14.01.2019 um 21:01 schrieb Marek Vasut:
>> On 1/14/19 8:43 PM, Simon Goldschmidt wrote:
>>> Am 14.01.2019 um 20:33 schrieb Marek Vasut:
 On 1/14/19 7:58 PM, Simon Goldschmidt wrote:
> Am 14.01.2019 um 19:31 schrieb Marek Vasut:
>> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
>>> Hi Dinh,
>>
>> Hi,
>>
>>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
 Hi Simon,

 On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
>> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the
> reset
> drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset
 controller ?
>>>
>>> I found that out just now: there's the function
>>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
>>> "De-assert reset for peripherals and bridges based on handoff".
>>> However,
>>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
>>> doing
>>> that, it enables *ALL* peripherals on the SoC (except for
>>> some DMA
>>> channels that aren't really used) :-)
>>>
>>> I guess that needs some cleaning up as well ;-)
>>
>> Yes
>>
>>> I think the proper thing to do here would be to remove this
>>> function and
>>> convert all drivers to provide appropriate 'resets'
>>> properties in
>>> the
>>> dts?
>>
>> Indeed
>
> So I just did that and it works nice for SPL and U-Boot: By adding
> some
> "resets" properties the the main dtsi and adding reset bulk
> code to
> the
> cadence_qspi, denali_dt nand and drivers, I can nearly remove the
> reset
> code from arch/mach_socfpga.
>
> The problem would be that now Linux cannot use peripherals that
> aren't
> enabled by U-Boot because it relies on them being enabled. How are
> such
> dependencies solved? Because even if I would add reset support in
> the
> corresponding Linux drivers, we probably could not bootolder
> Kernels
> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>

 I added an early reset driver for SoCFPGA that should take care of
 this.
 The patch is in v5.0-rc2[1].
>>>
>>> OK, it's good to know that this work is already done, I haven't
>>> monitored this close enough.
>>
>> We had the same problem with A10, indeed.
>>
>>> But am I correct that my above problem remains even in v5.0 as
>>> not all
>>> peripherals in socfpga.dtsi have a "resets" property set (e.g.
>>> mmc and
>>> qspi) and would thuse not be taken out of reset by Linux?
>>>
>>> Plus: should U-Boot work with older Linux kernels? Because if so, we
>>> need fallback code in U-Boot to unreset peripherals when running
>>> with an
>>> older kernel...
>>
>> Yes, it'd break old broken kernels . The real question is, do we
>> care ?
>
> Ok, so that at leat shows me I'm going into the right direction :-)
>
> There are some problems though:
> - I do care (we're running 4.9 currently) *g*
> - people running an RT kernel will care for a while (until the next
> stable RT after fixing this will be released)
> - we would currently be breaking *all* kernels, since no kernel should
> yet be able to deassert reset for mmc and qspi (unless this is already
> done by U-Boot)...
>
> So would it be OK to add a Kconfig option to U-Boot to keep the
> current
> behaviour (for old broken kernels like you said) until that code is
> spread widely enough? Or is that a no-go?

 Would be nice to be able to tweak the reset driver behavior at runtime,
 to unreset things before booting the kernel if the user desires so.
>>>
>>> Instead of tweaking the reset driver, we could just add a command that
>>> does that 'rstmgr->permodrst = 0;' thing my patch would remove.
>>
>> I don't want a new custom command.
>>
>>> Since noone has complained so far, I think writing 0 should be OK here.
>>> I don't think it would make too much sense to use the reset handoff
>>> defines from Quartus output for such a command. I think the way Quartus
>>> does this is strange anyway...
>>>
>>>

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On Mon, Jan 14, 2019 at 9:23 PM Marek Vasut  wrote:
>
> On 1/14/19 9:12 PM, Simon Goldschmidt wrote:
> > Am 14.01.2019 um 21:01 schrieb Marek Vasut:
> >> On 1/14/19 8:43 PM, Simon Goldschmidt wrote:
> >>> Am 14.01.2019 um 20:33 schrieb Marek Vasut:
>  On 1/14/19 7:58 PM, Simon Goldschmidt wrote:
> > Am 14.01.2019 um 19:31 schrieb Marek Vasut:
> >> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> >>> Hi Dinh,
> >>
> >> Hi,
> >>
> >>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>  Hi Simon,
> 
>  On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> > Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> >> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > In order to build a smaller SPL, let's imply SPL_DM_RESET and
> > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> > disabled
> > via defconfig.
> >
> > This also seems to be required to use OF_PLATDATA, as the
> > reset
> > drivers
> > don't seem to work with it.
> 
>  How do you un-reset IP blocks if you disable the reset
>  controller ?
> >>>
> >>> I found that out just now: there's the function
> >>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> >>> "De-assert reset for peripherals and bridges based on handoff".
> >>> However,
> >>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
> >>> doing
> >>> that, it enables *ALL* peripherals on the SoC (except for
> >>> some DMA
> >>> channels that aren't really used) :-)
> >>>
> >>> I guess that needs some cleaning up as well ;-)
> >>
> >> Yes
> >>
> >>> I think the proper thing to do here would be to remove this
> >>> function and
> >>> convert all drivers to provide appropriate 'resets'
> >>> properties in
> >>> the
> >>> dts?
> >>
> >> Indeed
> >
> > So I just did that and it works nice for SPL and U-Boot: By adding
> > some
> > "resets" properties the the main dtsi and adding reset bulk
> > code to
> > the
> > cadence_qspi, denali_dt nand and drivers, I can nearly remove the
> > reset
> > code from arch/mach_socfpga.
> >
> > The problem would be that now Linux cannot use peripherals that
> > aren't
> > enabled by U-Boot because it relies on them being enabled. How are
> > such
> > dependencies solved? Because even if I would add reset support in
> > the
> > corresponding Linux drivers, we probably could not bootolder
> > Kernels
> > (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> >
> 
>  I added an early reset driver for SoCFPGA that should take care of
>  this.
>  The patch is in v5.0-rc2[1].
> >>>
> >>> OK, it's good to know that this work is already done, I haven't
> >>> monitored this close enough.
> >>
> >> We had the same problem with A10, indeed.
> >>
> >>> But am I correct that my above problem remains even in v5.0 as
> >>> not all
> >>> peripherals in socfpga.dtsi have a "resets" property set (e.g.
> >>> mmc and
> >>> qspi) and would thuse not be taken out of reset by Linux?
> >>>
> >>> Plus: should U-Boot work with older Linux kernels? Because if so, we
> >>> need fallback code in U-Boot to unreset peripherals when running
> >>> with an
> >>> older kernel...
> >>
> >> Yes, it'd break old broken kernels . The real question is, do we
> >> care ?
> >
> > Ok, so that at leat shows me I'm going into the right direction :-)
> >
> > There are some problems though:
> > - I do care (we're running 4.9 currently) *g*
> > - people running an RT kernel will care for a while (until the next
> > stable RT after fixing this will be released)
> > - we would currently be breaking *all* kernels, since no kernel should
> > yet be able to deassert reset for mmc and qspi (unless this is already
> > done by U-Boot)...
> >
> > So would it be OK to add a Kconfig option to U-Boot to keep the
> > current
> > behaviour (for old broken kernels like you said) until that code is
> > spread widely enough? Or is that a no-go?
> 
>  Would be nice to be able to tweak the reset driver behavior at runtime,
>  to unreset things before booting the kernel if the user desires so.
> >>>
> >>> Instead of tweaking the reset driver, we could just add a command that
> >>> does that 'rstmgr->permodrst = 0;' thing my patch would remove.
> >>
> >> I don't

[U-Boot] rk3288: firefly: flashing emmc from maskrom using USB

2019-01-14 Thread Jack Mitchell

I'm having issues flashing the emmc on my firefly board using USB. For
some reason it seems as though trying to write to the emmc flash sector
0x40 for uboot spl+proper from the Maskrom/Loader doesn't work. Can
anyone elaborate on what I'm doing wrong, or another way I could achieve
this?

The current state of the emmc is empty, so it boots into the maskrom on
reset.

I've tried with the Rockchip Loader binary as shown below:

$ tools/mkimage -n rk3288 -T rksd -d \
spl/u-boot-spl-dtb.bin out && \
cat u-boot-dtb.bin >> out

$ rkdeveloptool db RK3288Loader_uboot_V2.17.02.bin

$ rkdeveloptool wl 64 out

$ rkdeveloptool rd

This just loads back into the maskrom as if nothing was written to the emmc.

I've used the same method but writing to an sd card:

$ tools/mkimage -n rk3288 -T rksd -d \
spl/u-boot-spl-dtb.bin out && \
cat u-boot-dtb.bin >> out

$ dd if=out of=/dev/sdc seek=64

This works fine and boots into full uboot as I would expect, but from
the sd card rather than the emmc.

I have then flashed the emmc from the sd card running uboot, which then
enables me to boot uboot from the emmc.

I can also use rockusb from the sd card uboot to flash uboot to the emmc
using the following commands:

uboot> rockusb 0 mmc 0

$ rkdeveloptool wl 64 out

$ rkdeveloptool rd

This also works. However both working methods require me starting uboot
from an sd card in the first instance. How can I successfully flash the
emmc using just USB? Any input would be appreciated.

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

Re: [U-Boot] [PATCH] net: fix env flags for eth10addr and above


Hi Joe,

Am 14.01.2019 um 19:19 schrieb Joe Hershberger:

Hi Simon,

On Mon, Jan 14, 2019 at 10:29 AM Tom Rini  wrote:


On Mon, Jan 14, 2019 at 04:42:10PM +0100, Simon Goldschmidt wrote:

Am 14.12.2018 um 14:28 schrieb Tom Rini:

On Fri, Dec 14, 2018 at 09:56:19AM +0100, Simon Goldschmidt wrote:


+Tom

On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
 wrote:


Am 22.11.2018 um 17:06 schrieb Simon Goldschmidt:

With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10
interfaces (0..9) as the number can only have one digit.

On boards with more than 10 interfaces, this leads to the protection
and format checks being absent for eth10addr and above.

Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow
more than one digit.

Signed-off-by: Simon Goldschmidt 
---

   include/env_flags.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/env_flags.h b/include/env_flags.h
index cc2c34f939..23744e395c 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -38,7 +38,7 @@ enum env_flags_varaccess {

   #ifdef CONFIG_CMD_NET
   #ifdef CONFIG_REGEX
-#define ETHADDR_WILDCARD "\\d?"
+#define ETHADDR_WILDCARD "\\d*"
   #else
   #define ETHADDR_WILDCARD
   #endif



Ping?


I haven't gotten an answer to this for nearly one month. It's a small
change, can this go in for v2019.01 please?


I'd filed this off to Joe to grab since it is indeed small and a
clean-up.


Apologies for the dead air... I was out for about a month and then the
holidays hit. I've been trying to catch up on things that languished
in that time and missed this one.


I thought of something like that, given the time in the year :-)

Note that I sent 4 patches for net that are presumably in your area to 
pick up. This one and:


https://patchwork.ozlabs.org/patch/1001862/
https://patchwork.ozlabs.org/patch/999267/
https://patchwork.ozlabs.org/patch/999268/

Thanks,
Simon



-Joe


Will you be taking this after the release or is there anything missing? It's
assigned to you in patchwork but I didn't get any real reply...


Yes, I'll be picking it up then, thanks for your patience.

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


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

Re: [U-Boot] [PATCH] net: fix env flags for eth10addr and above

2019-01-14 Thread Joe Hershberger

Hi Simon,

On Mon, Jan 14, 2019 at 10:29 AM Tom Rini  wrote:
>
> On Mon, Jan 14, 2019 at 04:42:10PM +0100, Simon Goldschmidt wrote:
> > Am 14.12.2018 um 14:28 schrieb Tom Rini:
> > >On Fri, Dec 14, 2018 at 09:56:19AM +0100, Simon Goldschmidt wrote:
> > >
> > >>+Tom
> > >>
> > >>On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
> > >> wrote:
> > >>>
> > >>>Am 22.11.2018 um 17:06 schrieb Simon Goldschmidt:
> > With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10
> > interfaces (0..9) as the number can only have one digit.
> > 
> > On boards with more than 10 interfaces, this leads to the protection
> > and format checks being absent for eth10addr and above.
> > 
> > Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow
> > more than one digit.
> > 
> > Signed-off-by: Simon Goldschmidt 
> > ---
> > 
> >    include/env_flags.h | 2 +-
> >    1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/env_flags.h b/include/env_flags.h
> > index cc2c34f939..23744e395c 100644
> > --- a/include/env_flags.h
> > +++ b/include/env_flags.h
> > @@ -38,7 +38,7 @@ enum env_flags_varaccess {
> > 
> >    #ifdef CONFIG_CMD_NET
> >    #ifdef CONFIG_REGEX
> > -#define ETHADDR_WILDCARD "\\d?"
> > +#define ETHADDR_WILDCARD "\\d*"
> >    #else
> >    #define ETHADDR_WILDCARD
> >    #endif
> > 
> > >>>
> > >>>Ping?
> > >>
> > >>I haven't gotten an answer to this for nearly one month. It's a small
> > >>change, can this go in for v2019.01 please?
> > >
> > >I'd filed this off to Joe to grab since it is indeed small and a
> > >clean-up.

Apologies for the dead air... I was out for about a month and then the
holidays hit. I've been trying to catch up on things that languished
in that time and missed this one.

-Joe
> >
> > Will you be taking this after the release or is there anything missing? It's
> > assigned to you in patchwork but I didn't get any real reply...
>
> Yes, I'll be picking it up then, thanks for your patience.
>
> --
> Tom
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 14.01.2019 um 19:31 schrieb Marek Vasut:

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:

Hi Dinh,


Hi,


Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset
drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff".
However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this
function and
convert all drivers to provide appropriate 'resets' properties in the
dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding some
"resets" properties the the main dtsi and adding reset bulk code to the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that aren't
enabled by U-Boot because it relies on them being enabled. How are such
dependencies solved? Because even if I would add reset support in the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...



I added an early reset driver for SoCFPGA that should take care of this.
The patch is in v5.0-rc2[1].


OK, it's good to know that this work is already done, I haven't
monitored this close enough.


We had the same problem with A10, indeed.


But am I correct that my above problem remains even in v5.0 as not all
peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running with an
older kernel...


Yes, it'd break old broken kernels . The real question is, do we care ?


Ok, so that at leat shows me I'm going into the right direction :-)

There are some problems though:
- I do care (we're running 4.9 currently) *g*
- people running an RT kernel will care for a while (until the next 
stable RT after fixing this will be released)
- we would currently be breaking *all* kernels, since no kernel should 
yet be able to deassert reset for mmc and qspi (unless this is already 
done by U-Boot)...


So would it be OK to add a Kconfig option to U-Boot to keep the current 
behaviour (for old broken kernels like you said) until that code is 
spread widely enough? Or is that a no-go?


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

Re: [U-Boot] [PATCH v6 1/9] test: add test for lib/lmb.c


Am 05.01.2019 um 02:56 schrieb Simon Glass:

Hi Simon,

On Fri, 14 Dec 2018 at 13:14, Simon Goldschmidt
 wrote:


Add basic tests for the lmb memory allocation code used to reserve and
allocate memory during boot.

Signed-off-by: Simon Goldschmidt 
---

Changes in v6: None
Changes in v5:
- this patch is new in v5

Changes in v4: None
Changes in v2: None

  test/lib/Makefile |   1 +
  test/lib/lmb.c| 297 ++
  2 files changed, 298 insertions(+)
  create mode 100644 test/lib/lmb.c


Reviewed-by: Simon Glass 

Seems fine. I wonder if it would be easier to simulate a 10-byte
memory size? It shouldn't matter how big it is.


This one slipped through somehow, sorry.

I wrote the test by simulating real values. Since there is no memory 
involved, only numbers, personally, I don't think simulating 10 bytes 
makes it easier than simulating 512 MiB. I'd leave it like it is, unless 
you insist...


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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 10:28 PM, Tom Rini wrote:
> On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:
>> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
>>> Hi Dinh,
>>
>> Hi,
>>
>>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
 Hi Simon,

 On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
>> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the reset
> drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset controller ?
>>>
>>> I found that out just now: there's the function
>>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
>>> "De-assert reset for peripherals and bridges based on handoff".
>>> However,
>>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
>>> that, it enables *ALL* peripherals on the SoC (except for some DMA
>>> channels that aren't really used) :-)
>>>
>>> I guess that needs some cleaning up as well ;-)
>>
>> Yes
>>
>>> I think the proper thing to do here would be to remove this
>>> function and
>>> convert all drivers to provide appropriate 'resets' properties in the
>>> dts?
>>
>> Indeed
>
> So I just did that and it works nice for SPL and U-Boot: By adding some
> "resets" properties the the main dtsi and adding reset bulk code to the
> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
> code from arch/mach_socfpga.
>
> The problem would be that now Linux cannot use peripherals that aren't
> enabled by U-Boot because it relies on them being enabled. How are such
> dependencies solved? Because even if I would add reset support in the
> corresponding Linux drivers, we probably could not bootolder Kernels
> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>

 I added an early reset driver for SoCFPGA that should take care of this.
 The patch is in v5.0-rc2[1].
>>>
>>> OK, it's good to know that this work is already done, I haven't
>>> monitored this close enough.
>>
>> We had the same problem with A10, indeed.
>>
>>> But am I correct that my above problem remains even in v5.0 as not all
>>> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
>>> qspi) and would thuse not be taken out of reset by Linux?
>>>
>>> Plus: should U-Boot work with older Linux kernels? Because if so, we
>>> need fallback code in U-Boot to unreset peripherals when running with an
>>> older kernel...
>>
>> Yes, it'd break old broken kernels . The real question is, do we care ?
> 
> Yes, we care.  Especially since it sounds like we're talking about
> something that's an LTS and not super-ancient vendor kernel.  Off the
> top of my head I can't recall if we ever fully removed support in sunxi
> for the vendor kernel in some cases, or just made it, eventually, opt-in
> as it was a fairly annoying incompatible behavior case.
> 
> But yes, in general, we do care about old kernels and need to be loud
> and clear about when we're removing support for them on a given SoC due
> to it being a PITA to support both ways of doing X and people have had Y
> years to migrate or correct their kernel.

Then we have to add some fallback mechanism, possibly the env variable
to tell reset controller to unreset everything.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

Am Mo., 14. Jan. 2019, 22:50 hat Tom Rini  geschrieben:

> On Mon, Jan 14, 2019 at 10:30:36PM +0100, Marek Vasut wrote:
> > On 1/14/19 10:28 PM, Tom Rini wrote:
> > > On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:
> > >> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> > >>> Hi Dinh,
> > >>
> > >> Hi,
> > >>
> > >>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
> >  Hi Simon,
> > 
> >  On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> > > Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> > >> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> > >>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
> >  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > > In order to build a smaller SPL, let's imply SPL_DM_RESET and
> > > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> > > disabled
> > > via defconfig.
> > >
> > > This also seems to be required to use OF_PLATDATA, as the reset
> > > drivers
> > > don't seem to work with it.
> > 
> >  How do you un-reset IP blocks if you disable the reset
> controller ?
> > >>>
> > >>> I found that out just now: there's the function
> > >>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> > >>> "De-assert reset for peripherals and bridges based on handoff".
> > >>> However,
> > >>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
> doing
> > >>> that, it enables *ALL* peripherals on the SoC (except for some
> DMA
> > >>> channels that aren't really used) :-)
> > >>>
> > >>> I guess that needs some cleaning up as well ;-)
> > >>
> > >> Yes
> > >>
> > >>> I think the proper thing to do here would be to remove this
> > >>> function and
> > >>> convert all drivers to provide appropriate 'resets' properties
> in the
> > >>> dts?
> > >>
> > >> Indeed
> > >
> > > So I just did that and it works nice for SPL and U-Boot: By adding
> some
> > > "resets" properties the the main dtsi and adding reset bulk code
> to the
> > > cadence_qspi, denali_dt nand and drivers, I can nearly remove the
> reset
> > > code from arch/mach_socfpga.
> > >
> > > The problem would be that now Linux cannot use peripherals that
> aren't
> > > enabled by U-Boot because it relies on them being enabled. How are
> such
> > > dependencies solved? Because even if I would add reset support in
> the
> > > corresponding Linux drivers, we probably could not bootolder
> Kernels
> > > (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> > >
> > 
> >  I added an early reset driver for SoCFPGA that should take care of
> this.
> >  The patch is in v5.0-rc2[1].
> > >>>
> > >>> OK, it's good to know that this work is already done, I haven't
> > >>> monitored this close enough.
> > >>
> > >> We had the same problem with A10, indeed.
> > >>
> > >>> But am I correct that my above problem remains even in v5.0 as not
> all
> > >>> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc
> and
> > >>> qspi) and would thuse not be taken out of reset by Linux?
> > >>>
> > >>> Plus: should U-Boot work with older Linux kernels? Because if so, we
> > >>> need fallback code in U-Boot to unreset peripherals when running
> with an
> > >>> older kernel...
> > >>
> > >> Yes, it'd break old broken kernels . The real question is, do we care
> ?
> > >
> > > Yes, we care.  Especially since it sounds like we're talking about
> > > something that's an LTS and not super-ancient vendor kernel.  Off the
> > > top of my head I can't recall if we ever fully removed support in sunxi
> > > for the vendor kernel in some cases, or just made it, eventually,
> opt-in
> > > as it was a fairly annoying incompatible behavior case.
> > >
> > > But yes, in general, we do care about old kernels and need to be loud
> > > and clear about when we're removing support for them on a given SoC due
> > > to it being a PITA to support both ways of doing X and people have had
> Y
> > > years to migrate or correct their kernel.
> >
> > Then we have to add some fallback mechanism, possibly the env variable
> > to tell reset controller to unreset everything.
>
> Alright, so the prior art in question is:
> commit accc9e446be6c3bd129315a0c5830bddccfa16da
> Author: Hans de Goede 
> Date:   Wed Oct 22 14:56:36 2014 +0200
>
> sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option
>
> And is about supporting the sunxi 3.4 vendor kernel tree, and something
> we have still (and a single enabler of).  So, what's the range of broken
> / not broken kernels here?
>

I haven't yet tested but my idea is that it is still broken (some of the
devices won't come out of reset in some scenarios).

So I guess such a Kconfig option would even need to be enabled by default
for some time...

Regards,
Simon

>
___
U-Boot mailing list

[U-Boot] [PATCH v10 01/10] test: add test for lib/lmb.c

Add basic tests for the lmb memory allocation code used to reserve and
allocate memory during boot.

Signed-off-by: Simon Goldschmidt 
Reviewed-by: Simon Glass 
---

Changes in v10:
- add reviewed-by

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- this patch is new in v5

Changes in v4: None
Changes in v2: None

 test/lib/Makefile |   1 +
 test/lib/lmb.c| 297 ++
 2 files changed, 298 insertions(+)
 create mode 100644 test/lib/lmb.c

diff --git a/test/lib/Makefile b/test/lib/Makefile
index ea68fae566..5a636aac74 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -3,3 +3,4 @@
 # (C) Copyright 2018
 # Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
 obj-y += hexdump.o
+obj-y += lmb.o
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
new file mode 100644
index 00..dd7ba14b34
--- /dev/null
+++ b/test/lib/lmb.c
@@ -0,0 +1,297 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018 Simon Goldschmidt
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int check_lmb(struct unit_test_state *uts, struct lmb *lmb,
+phys_addr_t ram_base, phys_size_t ram_size,
+unsigned long num_reserved,
+phys_addr_t base1, phys_size_t size1,
+phys_addr_t base2, phys_size_t size2,
+phys_addr_t base3, phys_size_t size3)
+{
+   ut_asserteq(lmb->memory.cnt, 1);
+   ut_asserteq(lmb->memory.region[0].base, ram_base);
+   ut_asserteq(lmb->memory.region[0].size, ram_size);
+
+   ut_asserteq(lmb->reserved.cnt, num_reserved);
+   if (num_reserved > 0) {
+   ut_asserteq(lmb->reserved.region[0].base, base1);
+   ut_asserteq(lmb->reserved.region[0].size, size1);
+   }
+   if (num_reserved > 1) {
+   ut_asserteq(lmb->reserved.region[1].base, base2);
+   ut_asserteq(lmb->reserved.region[1].size, size2);
+   }
+   if (num_reserved > 2) {
+   ut_asserteq(lmb->reserved.region[2].base, base3);
+   ut_asserteq(lmb->reserved.region[2].size, size3);
+   }
+   return 0;
+}
+
+#define ASSERT_LMB(lmb, ram_base, ram_size, num_reserved, base1, size1, \
+  base2, size2, base3, size3) \
+  ut_assert(!check_lmb(uts, lmb, ram_base, ram_size, \
+num_reserved, base1, size1, base2, size2, base3, \
+size3))
+
+/*
+ * Test helper function that reserves 64 KiB somewhere in the simulated RAM and
+ * then does some alloc + free tests.
+ */
+static int test_multi_alloc(struct unit_test_state *uts,
+   const phys_addr_t ram, const phys_size_t ram_size,
+   const phys_addr_t alloc_64k_addr)
+{
+   const phys_addr_t ram_end = ram + ram_size;
+   const phys_addr_t alloc_64k_end = alloc_64k_addr + 0x1;
+
+   struct lmb lmb;
+   long ret;
+   phys_addr_t a, a2, b, b2, c, d;
+
+   /* check for overflow */
+   ut_assert(ram_end == 0 || ram_end > ram);
+   ut_assert(alloc_64k_end > alloc_64k_addr);
+   /* check input addresses + size */
+   ut_assert(alloc_64k_addr >= ram + 8);
+   ut_assert(alloc_64k_end <= ram_end - 8);
+
+   lmb_init();
+
+   ret = lmb_add(, ram, ram_size);
+   ut_asserteq(ret, 0);
+
+   /* reserve 64KiB somewhere */
+   ret = lmb_reserve(, alloc_64k_addr, 0x1);
+   ut_asserteq(ret, 0);
+   ASSERT_LMB(, ram, ram_size, 1, alloc_64k_addr, 0x1,
+  0, 0, 0, 0);
+
+   /* allocate somewhere, should be at the end of RAM */
+   a = lmb_alloc(, 4, 1);
+   ut_asserteq(a, ram_end - 4);
+   ASSERT_LMB(, ram, ram_size, 2, alloc_64k_addr, 0x1,
+  ram_end - 4, 4, 0, 0);
+   /* alloc below end of reserved region -> below reserved region */
+   b = lmb_alloc_base(, 4, 1, alloc_64k_end);
+   ut_asserteq(b, alloc_64k_addr - 4);
+   ASSERT_LMB(, ram, ram_size, 2,
+  alloc_64k_addr - 4, 0x1 + 4, ram_end - 4, 4, 0, 0);
+
+   /* 2nd time */
+   c = lmb_alloc(, 4, 1);
+   ut_asserteq(c, ram_end - 8);
+   ASSERT_LMB(, ram, ram_size, 2,
+  alloc_64k_addr - 4, 0x1 + 4, ram_end - 8, 8, 0, 0);
+   d = lmb_alloc_base(, 4, 1, alloc_64k_end);
+   ut_asserteq(d, alloc_64k_addr - 8);
+   ASSERT_LMB(, ram, ram_size, 2,
+  alloc_64k_addr - 8, 0x1 + 8, ram_end - 8, 8, 0, 0);
+
+   ret = lmb_free(, a, 4);
+   ut_asserteq(ret, 0);
+   ASSERT_LMB(, ram, ram_size, 2,
+  alloc_64k_addr - 8, 0x1 + 8, ram_end - 8, 4, 0, 0);
+   /* allocate again to ensure we get the same address */
+   a2 = lmb_alloc(, 4, 1);
+   ut_asserteq(a, a2);
+   ASSERT_LMB(, ram, ram_size, 2,
+  alloc_64k_addr - 8, 0x1 + 8, ram_end - 8, 8, 0, 0);
+

[U-Boot] [PATCH v10 10/10] arm: bootm: fix sp detection at end of address range

This fixes  'arch_lmb_reserve()' for ARM that tries to detect in which
DRAM bank 'sp' is in.

This code failed if a bank was at the end of physical address range
(i.e. size + length overflowed to 0).

To fix this, calculate 'bank_end' as 'size + length - 1' so that such
banks end at 0x, not 0.

Fixes: 15751403b6 ("ARM: bootm: don't assume sp is in DRAM bank 0")
Reported-by: Frank Wunderlich 
Signed-off-by: Simon Goldschmidt 
Reviewed-by: Stephen Warren 
---

Changes in v10: None
Changes in v9:
- fix compile error in arch/arm/lib/bootm.c

Changes in v8:
- this patch is new in v8

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v2: None

 arch/arm/lib/bootm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c3c1d2fdfa..329f20c2bf 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -64,13 +64,15 @@ void arch_lmb_reserve(struct lmb *lmb)
/* adjust sp by 4K to be safe */
sp -= 4096;
for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
-   if (sp < gd->bd->bi_dram[bank].start)
+   if (!gd->bd->bi_dram[bank].size ||
+   sp < gd->bd->bi_dram[bank].start)
continue;
+   /* Watch out for RAM at end of address space! */
bank_end = gd->bd->bi_dram[bank].start +
-   gd->bd->bi_dram[bank].size;
-   if (sp >= bank_end)
+   gd->bd->bi_dram[bank].size - 1;
+   if (sp > bank_end)
continue;
-   lmb_reserve(lmb, sp, bank_end - sp);
+   lmb_reserve(lmb, sp, bank_end - sp + 1);
break;
}
 }
-- 
2.17.1

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

[U-Boot] [PATCH v10 05/10] lib: lmb: extend lmb for checks at load time

This adds two new functions, lmb_alloc_addr and
lmb_get_unreserved_size.

lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a
pre-specified address range. Unlike lmb_reserve, this address range
must be inside one of the memory ranges that has been set up with
lmb_add.

lmb_get_unreserved_size returns the number of bytes that can be
used up to the next reserved region or the end of valid ram. This
can be 0 if the address passed is reserved.

Added test for these new functions.

Signed-off-by: Simon Goldschmidt 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- fixed lmb_alloc_addr when resulting reserved ranges get combined
- added test for these new functions

Changes in v4: None
Changes in v2:
- added lmb_get_unreserved_size() for tftp

 include/lmb.h  |   3 +
 lib/lmb.c  |  53 +
 test/lib/lmb.c | 202 +
 3 files changed, 258 insertions(+)

diff --git a/include/lmb.h b/include/lmb.h
index f04d058093..7d7e2a78dc 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -38,6 +38,9 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb, 
phys_size_t size, ulong align
phys_addr_t max_addr);
 extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong 
align,
  phys_addr_t max_addr);
+extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
+ phys_size_t size);
+extern phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr);
 extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
 extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 
diff --git a/lib/lmb.c b/lib/lmb.c
index cd297f8202..e380a0a722 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -313,6 +313,59 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
return 0;
 }
 
+/*
+ * Try to allocate a specific address range: must be in defined memory but not
+ * reserved
+ */
+phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t size)
+{
+   long j;
+
+   /* Check if the requested address is in one of the memory regions */
+   j = lmb_overlaps_region(>memory, base, size);
+   if (j >= 0) {
+   /*
+* Check if the requested end address is in the same memory
+* region we found.
+*/
+   if (lmb_addrs_overlap(lmb->memory.region[j].base,
+ lmb->memory.region[j].size, base + size -
+ 1, 1)) {
+   /* ok, reserve the memory */
+   if (lmb_reserve(lmb, base, size) >= 0)
+   return base;
+   }
+   }
+   return 0;
+}
+
+/* Return number of bytes from a given address that are free */
+phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr)
+{
+   int i;
+   long j;
+
+   /* check if the requested address is in the memory regions */
+   j = lmb_overlaps_region(>memory, addr, 1);
+   if (j >= 0) {
+   for (i = 0; i < lmb->reserved.cnt; i++) {
+   if (addr < lmb->reserved.region[i].base) {
+   /* first reserved range > requested address */
+   return lmb->reserved.region[i].base - addr;
+   }
+   if (lmb->reserved.region[i].base +
+   lmb->reserved.region[i].size > addr) {
+   /* requested addr is in this reserved range */
+   return 0;
+   }
+   }
+   /* if we come here: no reserved ranges above requested addr */
+   return lmb->memory.region[lmb->memory.cnt - 1].base +
+  lmb->memory.region[lmb->memory.cnt - 1].size - addr;
+   }
+   return 0;
+}
+
 int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
 {
int i;
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index e6acb70e76..058d3c332b 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -397,3 +397,205 @@ static int lib_test_lmb_overlapping_reserve(struct 
unit_test_state *uts)
 
 DM_TEST(lib_test_lmb_overlapping_reserve,
DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/*
+ * Simulate 512 MiB RAM, reserve 3 blocks, allocate addresses in between.
+ * Expect addresses outside the memory range to fail.
+ */
+static int test_alloc_addr(struct unit_test_state *uts, const phys_addr_t ram)
+{
+   const phys_size_t ram_size = 0x2000;
+   const phys_addr_t ram_end = ram + ram_size;
+   const phys_size_t alloc_addr_a = ram + 0x800;
+   const phys_size_t alloc_addr_b = ram + 0x800 * 2;
+   const phys_size_t alloc_addr_c = ram + 0x800 * 3;
+   struct lmb lmb;
+

[U-Boot] [PATCH v10 09/10] tftp: prevent overwriting reserved memory

This fixes CVE-2018-18439 ("insufficient boundary checks in network
image boot") by using lmb to check for a valid range to store
received blocks.

Signed-off-by: Simon Goldschmidt 
Acked-by: Joe Hershberger 
---

Changes in v10:
- add acked-by

Changes in v9: None
Changes in v8: None
Changes in v7:
- fix compiling without CONFIG_LMB

Changes in v6: None
Changes in v5: None
Changes in v4:
- this was patch 8, is now patch 7
- lines changed because v3 patch 7 got removed and MCAST_TFTP still
  exists

Changes in v2:
- this patch is new in v2

 net/tftp.c | 73 ++
 1 file changed, 63 insertions(+), 10 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index 68ffd81414..a9335b1b7e 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -17,6 +17,8 @@
 #include 
 #endif
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /* Well known TFTP port # */
 #define WELL_KNOWN_PORT69
 /* Millisecs to timeout for lost pkt */
@@ -81,6 +83,10 @@ static ulong tftp_block_wrap;
 /* memory offset due to wrapping */
 static ulong   tftp_block_wrap_offset;
 static int tftp_state;
+static ulong   tftp_load_addr;
+#ifdef CONFIG_LMB
+static ulong   tftp_load_size;
+#endif
 #ifdef CONFIG_TFTP_TSIZE
 /* The file size reported by the server */
 static int tftp_tsize;
@@ -164,10 +170,11 @@ static void mcast_cleanup(void)
 
 #endif /* CONFIG_MCAST_TFTP */
 
-static inline void store_block(int block, uchar *src, unsigned len)
+static inline int store_block(int block, uchar *src, unsigned int len)
 {
ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
ulong newsize = offset + len;
+   ulong store_addr = tftp_load_addr + offset;
 #ifdef CONFIG_SYS_DIRECT_FLASH_TFTP
int i, rc = 0;
 
@@ -175,24 +182,32 @@ static inline void store_block(int block, uchar *src, 
unsigned len)
/* start address in flash? */
if (flash_info[i].flash_id == FLASH_UNKNOWN)
continue;
-   if (load_addr + offset >= flash_info[i].start[0]) {
+   if (store_addr >= flash_info[i].start[0]) {
rc = 1;
break;
}
}
 
if (rc) { /* Flash is destination for this packet */
-   rc = flash_write((char *)src, (ulong)(load_addr+offset), len);
+   rc = flash_write((char *)src, store_addr, len);
if (rc) {
flash_perror(rc);
-   net_set_state(NETLOOP_FAIL);
-   return;
+   return rc;
}
} else
 #endif /* CONFIG_SYS_DIRECT_FLASH_TFTP */
{
-   void *ptr = map_sysmem(load_addr + offset, len);
-
+   void *ptr;
+
+#ifdef CONFIG_LMB
+   if (store_addr < tftp_load_addr ||
+   store_addr + len > tftp_load_addr + tftp_load_size) {
+   puts("\nTFTP error: ");
+   puts("trying to overwrite reserved memory...\n");
+   return -1;
+   }
+#endif
+   ptr = map_sysmem(store_addr, len);
memcpy(ptr, src, len);
unmap_sysmem(ptr);
}
@@ -203,6 +218,8 @@ static inline void store_block(int block, uchar *src, 
unsigned len)
 
if (net_boot_file_size < newsize)
net_boot_file_size = newsize;
+
+   return 0;
 }
 
 /* Clear our state ready for a new transfer */
@@ -606,7 +623,11 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
timeout_count_max = tftp_timeout_count_max;
net_set_timeout_handler(timeout_ms, tftp_timeout_handler);
 
-   store_block(tftp_cur_block - 1, pkt + 2, len);
+   if (store_block(tftp_cur_block - 1, pkt + 2, len)) {
+   eth_halt();
+   net_set_state(NETLOOP_FAIL);
+   break;
+   }
 
/*
 *  Acknowledge the block just received, which will prompt
@@ -695,6 +716,25 @@ static void tftp_timeout_handler(void)
}
 }
 
+/* Initialize tftp_load_addr and tftp_load_size from load_addr and lmb */
+static int tftp_init_load_addr(void)
+{
+#ifdef CONFIG_LMB
+   struct lmb lmb;
+   phys_size_t max_size;
+
+   lmb_init_and_reserve(, gd->bd->bi_dram[0].start,
+gd->bd->bi_dram[0].size, (void *)gd->fdt_blob);
+
+   max_size = lmb_get_unreserved_size(, load_addr);
+   if (!max_size)
+   return -1;
+
+   tftp_load_size = max_size;
+#endif
+   tftp_load_addr = load_addr;
+   return 0;
+}
 
 void tftp_start(enum proto_t protocol)
 {
@@ -791,7 +831,14 @@ void tftp_start(enum proto_t protocol)
} else
 #endif
{
-   printf("Load address: 0x%lx\n", load_addr);
+   if (tftp_init_load_addr()) {
+   eth_halt();
+

Re: [U-Boot] [PATCH v2 8/9] serial: actions: add uart support for s700

On 14/01/2019 12:41, Amit Singh Tomar wrote:
> UART controller present on S700 is compatible with existing
> S900 controller, this patch simply adds a proper compatible string
> so that owl uart driver can be reused for S700.
> 
> Signed-off-by: Amit Singh Tomar 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> Changes since v1:
>   * No changes.   
> ---
>  drivers/serial/serial_owl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
> index 7ead73e..76995bf 100644
> --- a/drivers/serial/serial_owl.c
> +++ b/drivers/serial/serial_owl.c
> @@ -121,6 +121,7 @@ static const struct dm_serial_ops owl_serial_ops = {
>  
>  static const struct udevice_id owl_serial_ids[] = {
>   { .compatible = "actions,s900-serial" },
> + { .compatible = "actions,owl-uart" },
>   { }
>  };
>  
> 

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

Re: [U-Boot] [PATCH v2 6/9] arm: add Cubieboard7 board support

On 14/01/2019 12:41, Amit Singh Tomar wrote:
> The Cubieboard is a single board computer containing a
> Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).
> 
> This patch adds respective defconfig alongwith device tree(sync with
> Linux 4.20).

This should come later in the series, as patch 8/9, just _after_
everything works. It compiles at this point, but you still need the next
two patches for it to work.

The _defconfig is still a bit too crowded, but so is the S900 version, so:

> Signed-off-by: Amit Singh Tomar 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes since v1:
>   * No changes.
> ---
>  arch/arm/dts/s700-cubieboard7.dts | 39 
> +++
>  configs/cubieboard7_defconfig | 16 
>  2 files changed, 55 insertions(+)
>  create mode 100644 arch/arm/dts/s700-cubieboard7.dts
>  create mode 100644 configs/cubieboard7_defconfig
> 
> diff --git a/arch/arm/dts/s700-cubieboard7.dts 
> b/arch/arm/dts/s700-cubieboard7.dts
> new file mode 100644
> index 000..28f3f4a
> --- /dev/null
> +++ b/arch/arm/dts/s700-cubieboard7.dts
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Andreas Färber
> + */
> +
> +/dts-v1/;
> +
> +#include "s700.dtsi"
> +
> +/ {
> + compatible = "cubietech,cubieboard7", "actions,s700";
> + model = "CubieBoard7";
> +
> + aliases {
> + serial3 = 
> + };
> +
> + chosen {
> + stdout-path = "serial3:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>;
> + };
> +
> + memory@1,e000 {
> + device_type = "memory";
> + reg = <0x1 0xe000 0x0 0x0>;
> + };
> +};
> +
> + {
> + clocks = <>;
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
> new file mode 100644
> index 000..0459997
> --- /dev/null
> +++ b/configs/cubieboard7_defconfig
> @@ -0,0 +1,16 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_OWL=y
> +CONFIG_MACH_S700=y
> +CONFIG_IDENT_STRING="\ncubieboard7"
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_BOOTDELAY=5
> +CONFIG_USE_BOOTARGS=y
> +CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +# CONFIG_DISPLAY_BOARDINFO is not set
> +CONFIG_SYS_PROMPT="U-Boot => "
> +CONFIG_CMD_MD5SUM=y
> +CONFIG_CMD_MEMINFO=y
> +CONFIG_CMD_TIMER=y
> +CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
> 

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 14.01.2019 um 21:49 schrieb Marek Vasut:

On 1/14/19 9:30 PM, Simon Goldschmidt wrote:

On Mon, Jan 14, 2019 at 9:23 PM Marek Vasut  wrote:


On 1/14/19 9:12 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 21:01 schrieb Marek Vasut:

On 1/14/19 8:43 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 20:33 schrieb Marek Vasut:

On 1/14/19 7:58 PM, Simon Goldschmidt wrote:

Am 14.01.2019 um 19:31 schrieb Marek Vasut:

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:

Hi Dinh,


Hi,


Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the
reset
drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset
controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff".
However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By
doing
that, it enables *ALL* peripherals on the SoC (except for
some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this
function and
convert all drivers to provide appropriate 'resets'
properties in
the
dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding
some
"resets" properties the the main dtsi and adding reset bulk
code to
the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the
reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that
aren't
enabled by U-Boot because it relies on them being enabled. How are
such
dependencies solved? Because even if I would add reset support in
the
corresponding Linux drivers, we probably could not bootolder
Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...



I added an early reset driver for SoCFPGA that should take care of
this.
The patch is in v5.0-rc2[1].


OK, it's good to know that this work is already done, I haven't
monitored this close enough.


We had the same problem with A10, indeed.


But am I correct that my above problem remains even in v5.0 as
not all
peripherals in socfpga.dtsi have a "resets" property set (e.g.
mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running
with an
older kernel...


Yes, it'd break old broken kernels . The real question is, do we
care ?


Ok, so that at leat shows me I'm going into the right direction :-)

There are some problems though:
- I do care (we're running 4.9 currently) *g*
- people running an RT kernel will care for a while (until the next
stable RT after fixing this will be released)
- we would currently be breaking *all* kernels, since no kernel should
yet be able to deassert reset for mmc and qspi (unless this is already
done by U-Boot)...

So would it be OK to add a Kconfig option to U-Boot to keep the
current
behaviour (for old broken kernels like you said) until that code is
spread widely enough? Or is that a no-go?


Would be nice to be able to tweak the reset driver behavior at runtime,
to unreset things before booting the kernel if the user desires so.


Instead of tweaking the reset driver, we could just add a command that
does that 'rstmgr->permodrst = 0;' thing my patch would remove.


I don't want a new custom command.


Since noone has complained so far, I think writing 0 should be OK here.
I don't think it would make too much sense to use the reset handoff
defines from Quartus output for such a command. I think the way Quartus
does this is strange anyway...

The question is if defconfigs should be able to use this to
automatically build a U-Boot config for older kernels. If so, we'd still
need a Kconfig option?


I'd much rather have this runtime configurable.


Then I'm afraid I don't know what you mean by "runtime configurable".
What should be the configuration source that is evaluated at runtime?


I wonder ... maybe an environment variable with a U_BOOT_ENV_CALLBACK()
hook ?


But when doing it like that, I'd still have to modify the U-Boot
sources to build a version of U-Boot that could successfully boot a
4.9 kernel.
I wanted to be able to do that without changing the sources, that's
why I would have added a Kconfig option...


If you have an environment variable which allows you to indicate that
your kernel is broken/old, you can set it and boot.


Fair enough. I'll try it like that.




Thinking further about cleanup: I guess the

[U-Boot] [PATCH v10 03/10] lib: lmb: reserving overlapping regions should fail

lmb_add_region handles overlapping regions wrong: instead of merging
or rejecting to add a new reserved region that overlaps an existing
one, it just adds the new region.

Since internally the same function is used for lmb_alloc, change
lmb_add_region to reject overlapping regions.

Also, to keep reserved memory correct after 'free', reserved entries
created by allocating memory must not set their size to a multiple
of alignment but to the original size. This ensures the reserved
region is completely removed when the caller calls 'lmb_free', as
this one takes the same size as passed to 'lmb_alloc' etc.

Add test to assert this.

Signed-off-by: Simon Goldschmidt 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- add braces around if/else with macros accross more than one line

Changes in v6:
- fix size of allocated regions that need alignment padding

Changes in v5:
- added a test for this bug

Changes in v4: None
Changes in v2: None

 lib/lmb.c  | 11 +++---
 test/lib/lmb.c | 95 +-
 2 files changed, 91 insertions(+), 15 deletions(-)

diff --git a/lib/lmb.c b/lib/lmb.c
index 6d3dcf4e09..cd297f8202 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -131,6 +131,9 @@ static long lmb_add_region(struct lmb_region *rgn, 
phys_addr_t base, phys_size_t
rgn->region[i].size += size;
coalesced++;
break;
+   } else if (lmb_addrs_overlap(base, size, rgnbase, rgnsize)) {
+   /* regions overlap */
+   return -1;
}
}
 
@@ -269,11 +272,6 @@ static phys_addr_t lmb_align_down(phys_addr_t addr, 
phys_size_t size)
return addr & ~(size - 1);
 }
 
-static phys_addr_t lmb_align_up(phys_addr_t addr, ulong size)
-{
-   return (addr + (size - 1)) & ~(size - 1);
-}
-
 phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align, 
phys_addr_t max_addr)
 {
long i, j;
@@ -302,8 +300,7 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
if (j < 0) {
/* This area isn't reserved, take it */
if (lmb_add_region(>reserved, base,
-   lmb_align_up(size,
-   align)) < 0)
+  size) < 0)
return 0;
return base;
}
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index fb7ca45ef1..e6acb70e76 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -227,13 +227,16 @@ static int lib_test_lmb_big(struct unit_test_state *uts)
 DM_TEST(lib_test_lmb_big, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
 /* Simulate 512 MiB RAM, allocate a block without previous reservation */
-static int test_noreserved(struct unit_test_state *uts, const phys_addr_t ram)
+static int test_noreserved(struct unit_test_state *uts, const phys_addr_t ram,
+  const phys_addr_t alloc_size, const ulong align)
 {
const phys_size_t ram_size = 0x2000;
const phys_addr_t ram_end = ram + ram_size;
struct lmb lmb;
long ret;
phys_addr_t a, b;
+   const phys_addr_t alloc_size_aligned = (alloc_size + align - 1) &
+   ~(align - 1);
 
/* check for overflow */
ut_assert(ram_end == 0 || ram_end > ram);
@@ -242,20 +245,43 @@ static int test_noreserved(struct unit_test_state *uts, 
const phys_addr_t ram)
 
ret = lmb_add(, ram, ram_size);
ut_asserteq(ret, 0);
+   ASSERT_LMB(, ram, ram_size, 0, 0, 0, 0, 0, 0, 0);
 
/* allocate a block */
-   a = lmb_alloc(, 4, 1);
+   a = lmb_alloc(, alloc_size, align);
ut_assert(a != 0);
-   /* and free it */
-   ret = lmb_free(, a, 4);
+   ASSERT_LMB(, ram, ram_size, 1, ram + ram_size - alloc_size_aligned,
+  alloc_size, 0, 0, 0, 0);
+   /* allocate another block */
+   b = lmb_alloc(, alloc_size, align);
+   ut_assert(b != 0);
+   if (alloc_size == alloc_size_aligned) {
+   ASSERT_LMB(, ram, ram_size, 1, ram + ram_size -
+  (alloc_size_aligned * 2), alloc_size * 2, 0, 0, 0,
+  0);
+   } else {
+   ASSERT_LMB(, ram, ram_size, 2, ram + ram_size -
+  (alloc_size_aligned * 2), alloc_size, ram + ram_size
+  - alloc_size_aligned, alloc_size, 0, 0);
+   }
+   /* and free them */
+   ret = lmb_free(, b, alloc_size);
ut_asserteq(ret, 0);
+   ASSERT_LMB(, ram, ram_size, 1, ram + ram_size - alloc_size_aligned,
+  alloc_size, 0, 0, 0, 0);
+   ret = lmb_free(, a, alloc_size);
+   ut_asserteq(ret, 0);
+

[U-Boot] [PATCH v10 06/10] fs: prevent overwriting reserved memory

This fixes CVE-2018-18440 ("insufficient boundary checks in filesystem
image load") by using lmb to check the load size of a file against
reserved memory addresses.

Signed-off-by: Simon Goldschmidt 
Reviewed-by: Simon Glass 
---

Changes in v10:
- return -ENOSPC from fs_read when read to reserved memory is rejected
- add reviewed-by

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- fixed NULL pointer access in 'fdt_blob' passed to
  'boot_fdt_add_mem_rsv_regions'

Changes in v5: None
Changes in v4: None
Changes in v2: None

 fs/fs.c   | 56 ---
 include/lmb.h |  2 ++
 lib/lmb.c | 13 
 3 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index cb265174e2..7fd22101ef 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -429,13 +429,57 @@ int fs_size(const char *filename, loff_t *size)
return ret;
 }
 
-int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
-   loff_t *actread)
+#ifdef CONFIG_LMB
+/* Check if a file may be read to the given address */
+static int fs_read_lmb_check(const char *filename, ulong addr, loff_t offset,
+loff_t len, struct fstype_info *info)
+{
+   struct lmb lmb;
+   int ret;
+   loff_t size;
+   loff_t read_len;
+
+   /* get the actual size of the file */
+   ret = info->size(filename, );
+   if (ret)
+   return ret;
+   if (offset >= size) {
+   /* offset >= EOF, no bytes will be written */
+   return 0;
+   }
+   read_len = size - offset;
+
+   /* limit to 'len' if it is smaller */
+   if (len && len < read_len)
+   read_len = len;
+
+   lmb_init_and_reserve(, gd->bd->bi_dram[0].start,
+gd->bd->bi_dram[0].size, (void *)gd->fdt_blob);
+   lmb_dump_all();
+
+   if (lmb_alloc_addr(, addr, read_len) == addr)
+   return 0;
+
+   printf("** Reading file would overwrite reserved memory **\n");
+   return -ENOSPC;
+}
+#endif
+
+static int _fs_read(const char *filename, ulong addr, loff_t offset, loff_t 
len,
+   int do_lmb_check, loff_t *actread)
 {
struct fstype_info *info = fs_get_info(fs_type);
void *buf;
int ret;
 
+#ifdef CONFIG_LMB
+   if (do_lmb_check) {
+   ret = fs_read_lmb_check(filename, addr, offset, len, info);
+   if (ret)
+   return ret;
+   }
+#endif
+
/*
 * We don't actually know how many bytes are being read, since len==0
 * means read the whole file.
@@ -452,6 +496,12 @@ int fs_read(const char *filename, ulong addr, loff_t 
offset, loff_t len,
return ret;
 }
 
+int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
+   loff_t *actread)
+{
+   return _fs_read(filename, addr, offset, len, 0, actread);
+}
+
 int fs_write(const char *filename, ulong addr, loff_t offset, loff_t len,
 loff_t *actwrite)
 {
@@ -622,7 +672,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
pos = 0;
 
time = get_timer(0);
-   ret = fs_read(filename, addr, pos, bytes, _read);
+   ret = _fs_read(filename, addr, pos, bytes, 1, _read);
time = get_timer(time);
if (ret < 0)
return 1;
diff --git a/include/lmb.h b/include/lmb.h
index 7d7e2a78dc..62da85e716 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -31,6 +31,8 @@ struct lmb {
 extern struct lmb lmb;
 
 extern void lmb_init(struct lmb *lmb);
+extern void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base,
+phys_size_t size, void *fdt_blob);
 extern long lmb_add(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 extern long lmb_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size);
 extern phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align);
diff --git a/lib/lmb.c b/lib/lmb.c
index e380a0a722..3407705fa7 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -98,6 +98,19 @@ void lmb_init(struct lmb *lmb)
lmb->reserved.size = 0;
 }
 
+/* Initialize the struct, add memory and call arch/board reserve functions */
+void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size,
+ void *fdt_blob)
+{
+   lmb_init(lmb);
+   lmb_add(lmb, base, size);
+   arch_lmb_reserve(lmb);
+   board_lmb_reserve(lmb);
+
+   if (IMAGE_ENABLE_OF_LIBFDT && fdt_blob)
+   boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
+}
+
 /* This routine called with relocation disabled. */
 static long lmb_add_region(struct lmb_region *rgn, phys_addr_t base, 
phys_size_t size)
 {
-- 
2.17.1

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On 1/14/19 10:53 PM, Simon Goldschmidt wrote:
> 
> 
> Am Mo., 14. Jan. 2019, 22:50 hat Tom Rini  > geschrieben:
> 
> On Mon, Jan 14, 2019 at 10:30:36PM +0100, Marek Vasut wrote:
> > On 1/14/19 10:28 PM, Tom Rini wrote:
> > > On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:
> > >> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> > >>> Hi Dinh,
> > >>
> > >> Hi,
> > >>
> > >>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
> >  Hi Simon,
> > 
> >  On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> > > Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> > >> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> > >>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
> >  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > > In order to build a smaller SPL, let's imply
> SPL_DM_RESET and
> > > SPL_WATCHDOG_SUPPORT instead of selecting them, so they
> can be
> > > disabled
> > > via defconfig.
> > >
> > > This also seems to be required to use OF_PLATDATA, as
> the reset
> > > drivers
> > > don't seem to work with it.
> > 
> >  How do you un-reset IP blocks if you disable the reset
> controller ?
> > >>>
> > >>> I found that out just now: there's the function
> > >>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that
> should
> > >>> "De-assert reset for peripherals and bridges based on
> handoff".
> > >>> However,
> > >>> at least for Gen5, it just writes a 0 to
> rstmgr->permodrst. By doing
> > >>> that, it enables *ALL* peripherals on the SoC (except for
> some DMA
> > >>> channels that aren't really used) :-)
> > >>>
> > >>> I guess that needs some cleaning up as well ;-)
> > >>
> > >> Yes
> > >>
> > >>> I think the proper thing to do here would be to remove this
> > >>> function and
> > >>> convert all drivers to provide appropriate 'resets'
> properties in the
> > >>> dts?
> > >>
> > >> Indeed
> > >
> > > So I just did that and it works nice for SPL and U-Boot: By
> adding some
> > > "resets" properties the the main dtsi and adding reset bulk
> code to the
> > > cadence_qspi, denali_dt nand and drivers, I can nearly
> remove the reset
> > > code from arch/mach_socfpga.
> > >
> > > The problem would be that now Linux cannot use peripherals
> that aren't
> > > enabled by U-Boot because it relies on them being enabled.
> How are such
> > > dependencies solved? Because even if I would add reset
> support in the
> > > corresponding Linux drivers, we probably could not bootolder
> Kernels
> > > (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> > >
> > 
> >  I added an early reset driver for SoCFPGA that should take
> care of this.
> >  The patch is in v5.0-rc2[1].
> > >>>
> > >>> OK, it's good to know that this work is already done, I haven't
> > >>> monitored this close enough.
> > >>
> > >> We had the same problem with A10, indeed.
> > >>
> > >>> But am I correct that my above problem remains even in v5.0 as
> not all
> > >>> peripherals in socfpga.dtsi have a "resets" property set (e.g.
> mmc and
> > >>> qspi) and would thuse not be taken out of reset by Linux?
> > >>>
> > >>> Plus: should U-Boot work with older Linux kernels? Because if
> so, we
> > >>> need fallback code in U-Boot to unreset peripherals when
> running with an
> > >>> older kernel...
> > >>
> > >> Yes, it'd break old broken kernels . The real question is, do
> we care ?
> > >
> > > Yes, we care.  Especially since it sounds like we're talking about
> > > something that's an LTS and not super-ancient vendor kernel. 
> Off the
> > > top of my head I can't recall if we ever fully removed support
> in sunxi
> > > for the vendor kernel in some cases, or just made it,
> eventually, opt-in
> > > as it was a fairly annoying incompatible behavior case.
> > >
> > > But yes, in general, we do care about old kernels and need to be
> loud
> > > and clear about when we're removing support for them on a given
> SoC due
> > > to it being a PITA to support both ways of doing X and people
> have had Y
> > > years to migrate or correct their kernel.
> >
> > Then we have to add some fallback mechanism, possibly the env variable
> > to tell reset controller to unreset everything.
> 
> Alright, so the prior art in question is:
> commit accc9e446be6c3bd129315a0c5830bddccfa16da
> Author: Hans de Goede

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

2019-01-14 Thread Dinh Nguyen



On 1/14/19 10:05 AM, Simon Goldschmidt wrote:
> Hi Dinh,
> 
> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>> Hi Simon,
>>
>> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
>>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
 On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
>>> disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset
>>> drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset controller ?
>
> I found that out just now: there's the function
> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> "De-assert reset for peripherals and bridges based on handoff".
> However,
> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
> that, it enables *ALL* peripherals on the SoC (except for some DMA
> channels that aren't really used) :-)
>
> I guess that needs some cleaning up as well ;-)

 Yes

> I think the proper thing to do here would be to remove this
> function and
> convert all drivers to provide appropriate 'resets' properties in the
> dts?

 Indeed
>>>
>>> So I just did that and it works nice for SPL and U-Boot: By adding some
>>> "resets" properties the the main dtsi and adding reset bulk code to the
>>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
>>> code from arch/mach_socfpga.
>>>
>>> The problem would be that now Linux cannot use peripherals that aren't
>>> enabled by U-Boot because it relies on them being enabled. How are such
>>> dependencies solved? Because even if I would add reset support in the
>>> corresponding Linux drivers, we probably could not bootolder Kernels
>>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
>>>
>>
>> I added an early reset driver for SoCFPGA that should take care of this.
>> The patch is in v5.0-rc2[1].
> 
> OK, it's good to know that this work is already done, I haven't
> monitored this close enough.
> 
> But am I correct that my above problem remains even in v5.0 as not all
> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> qspi) and would thuse not be taken out of reset by Linux?
> 

Yes, I see that. I will send a patch for those.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:
> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> > Hi Dinh,
> 
> Hi,
> 
> > Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
> >> Hi Simon,
> >>
> >> On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> >>> Am 11.01.2019 um 23:02 schrieb Marek Vasut:
>  On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 23:53 schrieb Marek Vasut:
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> >>> disabled
> >>> via defconfig.
> >>>
> >>> This also seems to be required to use OF_PLATDATA, as the reset
> >>> drivers
> >>> don't seem to work with it.
> >>
> >> How do you un-reset IP blocks if you disable the reset controller ?
> >
> > I found that out just now: there's the function
> > 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> > "De-assert reset for peripherals and bridges based on handoff".
> > However,
> > at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
> > that, it enables *ALL* peripherals on the SoC (except for some DMA
> > channels that aren't really used) :-)
> >
> > I guess that needs some cleaning up as well ;-)
> 
>  Yes
> 
> > I think the proper thing to do here would be to remove this
> > function and
> > convert all drivers to provide appropriate 'resets' properties in the
> > dts?
> 
>  Indeed
> >>>
> >>> So I just did that and it works nice for SPL and U-Boot: By adding some
> >>> "resets" properties the the main dtsi and adding reset bulk code to the
> >>> cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
> >>> code from arch/mach_socfpga.
> >>>
> >>> The problem would be that now Linux cannot use peripherals that aren't
> >>> enabled by U-Boot because it relies on them being enabled. How are such
> >>> dependencies solved? Because even if I would add reset support in the
> >>> corresponding Linux drivers, we probably could not bootolder Kernels
> >>> (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> >>>
> >>
> >> I added an early reset driver for SoCFPGA that should take care of this.
> >> The patch is in v5.0-rc2[1].
> > 
> > OK, it's good to know that this work is already done, I haven't
> > monitored this close enough.
> 
> We had the same problem with A10, indeed.
> 
> > But am I correct that my above problem remains even in v5.0 as not all
> > peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> > qspi) and would thuse not be taken out of reset by Linux?
> > 
> > Plus: should U-Boot work with older Linux kernels? Because if so, we
> > need fallback code in U-Boot to unreset peripherals when running with an
> > older kernel...
> 
> Yes, it'd break old broken kernels . The real question is, do we care ?

Yes, we care.  Especially since it sounds like we're talking about
something that's an LTS and not super-ancient vendor kernel.  Off the
top of my head I can't recall if we ever fully removed support in sunxi
for the vendor kernel in some cases, or just made it, eventually, opt-in
as it was a fairly annoying incompatible behavior case.

But yes, in general, we do care about old kernels and need to be loud
and clear about when we're removing support for them on a given SoC due
to it being a PITA to support both ways of doing X and people have had Y
years to migrate or correct their kernel.

-- 
Tom


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

[U-Boot] [PATCH v10 02/10] lmb: fix allocation at end of address range

The lmb code fails if base + size of RAM overflows to zero.

Fix this by calculating end as 'base + size - 1' instead of 'base + size'
where appropriate.

Added tests to assert this is fixed.

Signed-off-by: Simon Goldschmidt 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- this patch is new in v5

Changes in v4: None
Changes in v2: None

 lib/lmb.c  | 29 -
 test/lib/lmb.c | 29 ++---
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/lib/lmb.c b/lib/lmb.c
index 1705417348..6d3dcf4e09 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -43,7 +43,10 @@ void lmb_dump_all(struct lmb *lmb)
 static long lmb_addrs_overlap(phys_addr_t base1,
phys_size_t size1, phys_addr_t base2, phys_size_t size2)
 {
-   return ((base1 < (base2+size2)) && (base2 < (base1+size1)));
+   const phys_addr_t base1_end = base1 + size1 - 1;
+   const phys_addr_t base2_end = base2 + size2 - 1;
+
+   return ((base1 <= base2_end) && (base2 <= base1_end));
 }
 
 static long lmb_addrs_adjacent(phys_addr_t base1, phys_size_t size1,
@@ -89,18 +92,9 @@ static void lmb_coalesce_regions(struct lmb_region *rgn,
 
 void lmb_init(struct lmb *lmb)
 {
-   /* Create a dummy zero size LMB which will get coalesced away later.
-* This simplifies the lmb_add() code below...
-*/
-   lmb->memory.region[0].base = 0;
-   lmb->memory.region[0].size = 0;
-   lmb->memory.cnt = 1;
+   lmb->memory.cnt = 0;
lmb->memory.size = 0;
-
-   /* Ditto. */
-   lmb->reserved.region[0].base = 0;
-   lmb->reserved.region[0].size = 0;
-   lmb->reserved.cnt = 1;
+   lmb->reserved.cnt = 0;
lmb->reserved.size = 0;
 }
 
@@ -110,9 +104,10 @@ static long lmb_add_region(struct lmb_region *rgn, 
phys_addr_t base, phys_size_t
unsigned long coalesced = 0;
long adjacent, i;
 
-   if ((rgn->cnt == 1) && (rgn->region[0].size == 0)) {
+   if (rgn->cnt == 0) {
rgn->region[0].base = base;
rgn->region[0].size = size;
+   rgn->cnt = 1;
return 0;
}
 
@@ -183,7 +178,7 @@ long lmb_free(struct lmb *lmb, phys_addr_t base, 
phys_size_t size)
 {
struct lmb_region *rgn = &(lmb->reserved);
phys_addr_t rgnbegin, rgnend;
-   phys_addr_t end = base + size;
+   phys_addr_t end = base + size - 1;
int i;
 
rgnbegin = rgnend = 0; /* supress gcc warnings */
@@ -191,7 +186,7 @@ long lmb_free(struct lmb *lmb, phys_addr_t base, 
phys_size_t size)
/* Find the region where (base, size) belongs to */
for (i=0; i < rgn->cnt; i++) {
rgnbegin = rgn->region[i].base;
-   rgnend = rgnbegin + rgn->region[i].size;
+   rgnend = rgnbegin + rgn->region[i].size - 1;
 
if ((rgnbegin <= base) && (end <= rgnend))
break;
@@ -209,7 +204,7 @@ long lmb_free(struct lmb *lmb, phys_addr_t base, 
phys_size_t size)
 
/* Check to see if region is matching at the front */
if (rgnbegin == base) {
-   rgn->region[i].base = end;
+   rgn->region[i].base = end + 1;
rgn->region[i].size -= size;
return 0;
}
@@ -225,7 +220,7 @@ long lmb_free(struct lmb *lmb, phys_addr_t base, 
phys_size_t size)
 * beginging of the hole and add the region after hole.
 */
rgn->region[i].size = base - rgn->region[i].base;
-   return lmb_add_region(rgn, end, rgnend - end);
+   return lmb_add_region(rgn, end + 1, rgnend - end);
 }
 
 long lmb_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size)
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index dd7ba14b34..fb7ca45ef1 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -146,8 +146,15 @@ static int test_multi_alloc_512mb(struct unit_test_state 
*uts,
 /* Create a memory region with one reserved region and allocate */
 static int lib_test_lmb_simple(struct unit_test_state *uts)
 {
+   int ret;
+
/* simulate 512 MiB RAM beginning at 1GiB */
-   return test_multi_alloc_512mb(uts, 0x4000);
+   ret = test_multi_alloc_512mb(uts, 0x4000);
+   if (ret)
+   return ret;
+
+   /* simulate 512 MiB RAM beginning at 1.5GiB */
+   return test_multi_alloc_512mb(uts, 0xE000);
 }
 
 DM_TEST(lib_test_lmb_simple, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
@@ -206,7 +213,15 @@ static int test_bigblock(struct unit_test_state *uts, 
const phys_addr_t ram)
 
 static int lib_test_lmb_big(struct unit_test_state *uts)
 {
-   return test_bigblock(uts, 0x4000);
+   int ret;
+
+   /* simulate 512 MiB RAM beginning at 1GiB */
+   ret = test_bigblock(uts, 0x4000);
+   if (ret)
+   return ret;
+
+   /* simulate 512 MiB RAM beginning at 1.5GiB */
+   return test_bigblock(uts,

[U-Boot] [PATCH v10 04/10] fdt: parse "reserved-memory" for memory reservation

boot_fdt_add_mem_rsv_regions() adds reserved memory sections to an lmb
struct. Currently, it only parses regions described by /memreserve/
entries.

Extend this to the more commonly used scheme of the "reserved-memory"
node.

Signed-off-by: Simon Goldschmidt 
Reviewed-by: Simon Glass 
---

Changes in v10:
- add reviewed-by

Changes in v9: None
Changes in v8: None
Changes in v7:
- fix compiling without CONFIG_FIT

Changes in v6:
- fix compiling without OF_CONTROL

Changes in v5: None
Changes in v4:
- fixed invalid 'if' statement without braces in boot_fdt_reserve_region

Changes in v2:
- this patch is new in v2

 common/image-fdt.c | 53 +++---
 lib/Makefile   |  1 +
 2 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index 95748f0ae1..5c0d6db3fe 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -67,30 +68,66 @@ static const image_header_t *image_get_fdt(ulong fdt_addr)
 }
 #endif
 
+static void boot_fdt_reserve_region(struct lmb *lmb, uint64_t addr,
+   uint64_t size)
+{
+   int ret;
+
+   ret = lmb_reserve(lmb, addr, size);
+   if (!ret) {
+   debug("   reserving fdt memory region: addr=%llx size=%llx\n",
+ (unsigned long long)addr, (unsigned long long)size);
+   } else {
+   puts("ERROR: reserving fdt memory region failed ");
+   printf("(addr=%llx size=%llx)\n",
+  (unsigned long long)addr, (unsigned long long)size);
+   }
+}
+
 /**
- * boot_fdt_add_mem_rsv_regions - Mark the memreserve sections as unusable
+ * boot_fdt_add_mem_rsv_regions - Mark the memreserve and reserved-memory
+ * sections as unusable
  * @lmb: pointer to lmb handle, will be used for memory mgmt
  * @fdt_blob: pointer to fdt blob base address
  *
- * Adds the memreserve regions in the dtb to the lmb block.  Adding the
- * memreserve regions prevents u-boot from using them to store the initrd
- * or the fdt blob.
+ * Adds the and reserved-memorymemreserve regions in the dtb to the lmb block.
+ * Adding the memreserve regions prevents u-boot from using them to store the
+ * initrd or the fdt blob.
  */
 void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void *fdt_blob)
 {
uint64_t addr, size;
-   int i, total;
+   int i, total, ret;
+   int nodeoffset, subnode;
+   struct fdt_resource res;
 
if (fdt_check_header(fdt_blob) != 0)
return;
 
+   /* process memreserve sections */
total = fdt_num_mem_rsv(fdt_blob);
for (i = 0; i < total; i++) {
if (fdt_get_mem_rsv(fdt_blob, i, , ) != 0)
continue;
-   printf("   reserving fdt memory region: addr=%llx size=%llx\n",
-  (unsigned long long)addr, (unsigned long long)size);
-   lmb_reserve(lmb, addr, size);
+   boot_fdt_reserve_region(lmb, addr, size);
+   }
+
+   /* process reserved-memory */
+   nodeoffset = fdt_subnode_offset(fdt_blob, 0, "reserved-memory");
+   if (nodeoffset >= 0) {
+   subnode = fdt_first_subnode(fdt_blob, nodeoffset);
+   while (subnode >= 0) {
+   /* check if this subnode has a reg property */
+   ret = fdt_get_resource(fdt_blob, subnode, "reg", 0,
+  );
+   if (!ret) {
+   addr = res.start;
+   size = res.end - res.start + 1;
+   boot_fdt_reserve_region(lmb, addr, size);
+   }
+
+   subnode = fdt_next_subnode(fdt_blob, subnode);
+   }
}
 }
 
diff --git a/lib/Makefile b/lib/Makefile
index a6dd928a92..358789ff12 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -30,6 +30,7 @@ obj-y += crc7.o
 obj-y += crc8.o
 obj-y += crc16.o
 obj-$(CONFIG_ERRNO_STR) += errno_str.o
+obj-$(CONFIG_OF_LIBFDT) += fdtdec.o
 obj-$(CONFIG_FIT) += fdtdec_common.o
 obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
 obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
-- 
2.17.1

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

On Mon, Jan 14, 2019 at 10:30:36PM +0100, Marek Vasut wrote:
> On 1/14/19 10:28 PM, Tom Rini wrote:
> > On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:
> >> On 1/14/19 5:05 PM, Simon Goldschmidt wrote:
> >>> Hi Dinh,
> >>
> >> Hi,
> >>
> >>> Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:
>  Hi Simon,
> 
>  On 1/14/19 9:50 AM, Simon Goldschmidt wrote:
> > Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> >> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > In order to build a smaller SPL, let's imply SPL_DM_RESET and
> > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
> > disabled
> > via defconfig.
> >
> > This also seems to be required to use OF_PLATDATA, as the reset
> > drivers
> > don't seem to work with it.
> 
>  How do you un-reset IP blocks if you disable the reset controller ?
> >>>
> >>> I found that out just now: there's the function
> >>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
> >>> "De-assert reset for peripherals and bridges based on handoff".
> >>> However,
> >>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
> >>> that, it enables *ALL* peripherals on the SoC (except for some DMA
> >>> channels that aren't really used) :-)
> >>>
> >>> I guess that needs some cleaning up as well ;-)
> >>
> >> Yes
> >>
> >>> I think the proper thing to do here would be to remove this
> >>> function and
> >>> convert all drivers to provide appropriate 'resets' properties in the
> >>> dts?
> >>
> >> Indeed
> >
> > So I just did that and it works nice for SPL and U-Boot: By adding some
> > "resets" properties the the main dtsi and adding reset bulk code to the
> > cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
> > code from arch/mach_socfpga.
> >
> > The problem would be that now Linux cannot use peripherals that aren't
> > enabled by U-Boot because it relies on them being enabled. How are such
> > dependencies solved? Because even if I would add reset support in the
> > corresponding Linux drivers, we probably could not bootolder Kernels
> > (e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
> >
> 
>  I added an early reset driver for SoCFPGA that should take care of this.
>  The patch is in v5.0-rc2[1].
> >>>
> >>> OK, it's good to know that this work is already done, I haven't
> >>> monitored this close enough.
> >>
> >> We had the same problem with A10, indeed.
> >>
> >>> But am I correct that my above problem remains even in v5.0 as not all
> >>> peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
> >>> qspi) and would thuse not be taken out of reset by Linux?
> >>>
> >>> Plus: should U-Boot work with older Linux kernels? Because if so, we
> >>> need fallback code in U-Boot to unreset peripherals when running with an
> >>> older kernel...
> >>
> >> Yes, it'd break old broken kernels . The real question is, do we care ?
> > 
> > Yes, we care.  Especially since it sounds like we're talking about
> > something that's an LTS and not super-ancient vendor kernel.  Off the
> > top of my head I can't recall if we ever fully removed support in sunxi
> > for the vendor kernel in some cases, or just made it, eventually, opt-in
> > as it was a fairly annoying incompatible behavior case.
> > 
> > But yes, in general, we do care about old kernels and need to be loud
> > and clear about when we're removing support for them on a given SoC due
> > to it being a PITA to support both ways of doing X and people have had Y
> > years to migrate or correct their kernel.
> 
> Then we have to add some fallback mechanism, possibly the env variable
> to tell reset controller to unreset everything.

Alright, so the prior art in question is:
commit accc9e446be6c3bd129315a0c5830bddccfa16da
Author: Hans de Goede 
Date:   Wed Oct 22 14:56:36 2014 +0200

sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option

And is about supporting the sunxi 3.4 vendor kernel tree, and something
we have still (and a single enabler of).  So, what's the range of broken
/ not broken kernels here?

-- 
Tom


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

Re: [U-Boot] [PATCH v2 2/9] arm: actions: Add owl memory map regions

On 14/01/2019 12:41, Amit Singh Tomar wrote:

Hi,

> This adds memory regions needed to setup MMU for actions
> S900 and S700 SoCs.

Please change this sentence and the subject to state that this just
moves code, there is nothing new here that gets added. That helps later
when people browse through commit messages.
With that and the w/s nit below fixed:

> Signed-off-by: Amit Singh Tomar 

Reviewed-by: Andre Przywara 

> ---
> Changes since v1:
>   * compile sysmap-owl.c against CONFIG_ARM64 now.
> ---
>  arch/arm/mach-owl/Makefile  |  3 ++-
>  arch/arm/mach-owl/sysmap-owl.c  | 32 
>  arch/arm/mach-owl/sysmap-s900.c | 32 
>  3 files changed, 34 insertions(+), 33 deletions(-)
>  create mode 100644 arch/arm/mach-owl/sysmap-owl.c
>  delete mode 100644 arch/arm/mach-owl/sysmap-s900.c
> 
> diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
> index 0b181c6..b17fc14 100644
> --- a/arch/arm/mach-owl/Makefile
> +++ b/arch/arm/mach-owl/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  
>  obj-y += soc.o
> -obj-y += sysmap-s900.o
> +obj-$(CONFIG_ARM64) += sysmap-owl.o
> +

Please no empty line at the end of files. git should complain about it.

Cheers,
Andre.

> diff --git a/arch/arm/mach-owl/sysmap-owl.c b/arch/arm/mach-owl/sysmap-owl.c
> new file mode 100644
> index 000..9d30759
> --- /dev/null
> +++ b/arch/arm/mach-owl/sysmap-owl.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Memory map for Actions Semi S900/S700 based SoCs.
> + *
> + * Copyright (C) 2015 Actions Semi Co., Ltd.
> + * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> + */
> +
> +#include 
> +#include 
> +
> +static struct mm_region owl_mem_map[] = {
> + {
> + .virt = 0x0UL, /* DDR */
> + .phys = 0x0UL, /* DDR */
> + .size = 0x8000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +  PTE_BLOCK_INNER_SHARE
> + }, {
> + .virt = 0xE000UL, /* Peripheral block */
> + .phys = 0xE000UL, /* Peripheral block */
> + .size = 0x0800UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +  PTE_BLOCK_NON_SHARE |
> +  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* List terminator */
> + 0,
> + }
> +};
> +
> +struct mm_region *mem_map = owl_mem_map;
> diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
> deleted file mode 100644
> index f78b639..000
> --- a/arch/arm/mach-owl/sysmap-s900.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Actions Semi S900 Memory map
> - *
> - * Copyright (C) 2015 Actions Semi Co., Ltd.
> - * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> - */
> -
> -#include 
> -#include 
> -
> -static struct mm_region s900_mem_map[] = {
> - {
> - .virt = 0x0UL, /* DDR */
> - .phys = 0x0UL, /* DDR */
> - .size = 0x8000UL,
> - .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> -  PTE_BLOCK_INNER_SHARE
> - }, {
> - .virt = 0xE000UL, /* Peripheral block */
> - .phys = 0xE000UL, /* Peripheral block */
> - .size = 0x0800UL,
> - .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> -  PTE_BLOCK_NON_SHARE |
> -  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> - }, {
> - /* List terminator */
> - 0,
> - }
> -};
> -
> -struct mm_region *mem_map = s900_mem_map;
> 

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

Re: [U-Boot] [PATCH v2 1/9] arm: actions: Add common framework for Actions Semi SoCs

On 14/01/2019 12:41, Amit Singh Tomar wrote:

Hi,

> This adds common arch owl support that can drive, 64-bits SoCs
> from Actions Semi.
> 
> It also removes the Bubblegum specific board files.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v1:
>   * Moved S700 specific changes to patch 4 of 9.
>   * Moved couple of symbols from defconfig to arch/arm/Kconfig
>   and platform owl Kconfig.
> ---
>  arch/arm/Kconfig |  3 +-
>  arch/arm/mach-owl/Kconfig| 29 ++
>  arch/arm/mach-owl/Makefile   |  1 +
>  arch/arm/mach-owl/soc.c  | 56 
> 
>  board/ucRobotics/bubblegum_96/Kconfig| 15 
>  board/ucRobotics/bubblegum_96/MAINTAINERS|  6 ---
>  board/ucRobotics/bubblegum_96/Makefile   |  3 --
>  board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 
> 
>  configs/bubblegum_96_defconfig   |  4 +-
>  include/configs/bubblegum_96.h   | 42 -
>  include/configs/owl-common.h | 42 +
>  include/configs/s900.h   | 18 +
>  12 files changed, 131 insertions(+), 144 deletions(-)
>  create mode 100644 arch/arm/mach-owl/soc.c
>  delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig
>  delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
>  delete mode 100644 board/ucRobotics/bubblegum_96/Makefile
>  delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
>  delete mode 100644 include/configs/bubblegum_96.h
>  create mode 100644 include/configs/owl-common.h
>  create mode 100644 include/configs/s900.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d6b1629..1a2e561 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -761,9 +761,9 @@ config ARCH_MX5
>  
>  config ARCH_OWL
>   bool "Actions Semi OWL SoCs"
> - select ARM64
>   select DM
>   select DM_SERIAL
> + select OWL_SERIAL
>   select OF_CONTROL
>   imply CMD_DM
>  
> @@ -1555,7 +1555,6 @@ source "board/spear/spear600/Kconfig"
>  source "board/spear/x600/Kconfig"
>  source "board/st/stv0991/Kconfig"
>  source "board/tcl/sl50/Kconfig"
> -source "board/ucRobotics/bubblegum_96/Kconfig"
>  source "board/birdland/bav335x/Kconfig"
>  source "board/toradex/colibri_pxa270/Kconfig"
>  source "board/vscom/baltos/Kconfig"
> diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
> index 199e772..5eb93c9 100644
> --- a/arch/arm/mach-owl/Kconfig
> +++ b/arch/arm/mach-owl/Kconfig
> @@ -1,27 +1,22 @@
>  if ARCH_OWL
>  
> -config SYS_SOC
> - default "owl"
> -
>  choice
> -prompt "Actions Semi OWL SoCs board select"
> +prompt "Actions Semi SoC Variant"
>  optional
>  
> -config TARGET_BUBBLEGUM_96
> - bool "96Boards Bubblegum-96"
> - help
> -   Support for 96Boards Bubblegum-96. This board complies with
> -   96Board Consumer Edition Specification. Features:
> -   - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
> -   - 2GiB RAM
> -   - 8GiB eMMC, uSD slot
> -   - WiFi, Bluetooth and GPS module
> -   - 2x Host, 1x Device USB port
> -   - HDMI
> -   - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
> +config MACH_S900
> +bool "Actionss Semi S900"

One s at the end is enough.

> +select ARM64
>  
>  endchoice
>  
> -source "board/ucRobotics/bubblegum_96/Kconfig"
> +config SYS_CONFIG_NAME
> +default "s900" if MACH_S900
> +
> +config SYS_SOC
> +default "s900" if MACH_S900
> +
> +config SYS_TEXT_BASE
> +default 0x1100
>  
>  endif
> diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
> index 1b43dc2..0b181c6 100644
> --- a/arch/arm/mach-owl/Makefile
> +++ b/arch/arm/mach-owl/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  
> +obj-y += soc.o
>  obj-y += sysmap-s900.o
> diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c
> new file mode 100644
> index 000..d0630d2
> --- /dev/null
> +++ b/arch/arm/mach-owl/soc.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Actions Semi SoCs Boards Support.
> + *
> + * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * dram_init - sets uboots idea of sdram size
> + */
> +int dram_init(void)
> +{
> + gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
> + return 0;
> +}
> +
> +/* This is called after dram_init() so use get_ram_size result */
> +int dram_init_banksize(void)
> +{
> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> +
> + return 0;
> +}
> +
> +static void show_psci_version(void)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(ARM_PSCI_0_2_FN_PSCI_VERSION, 0,

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select


Am 14.01.2019 um 22:30 schrieb Marek Vasut:

On 1/14/19 10:28 PM, Tom Rini wrote:

On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote:

On 1/14/19 5:05 PM, Simon Goldschmidt wrote:

Hi Dinh,


Hi,


Am 14.01.2019 um 16:58 schrieb Dinh Nguyen:

Hi Simon,

On 1/14/19 9:50 AM, Simon Goldschmidt wrote:

Am 11.01.2019 um 23:02 schrieb Marek Vasut:

On 1/11/19 9:39 PM, Simon Goldschmidt wrote:

Am 07.01.2019 um 23:53 schrieb Marek Vasut:

On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be
disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset
drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


I found that out just now: there's the function
'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
"De-assert reset for peripherals and bridges based on handoff".
However,
at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
that, it enables *ALL* peripherals on the SoC (except for some DMA
channels that aren't really used) :-)

I guess that needs some cleaning up as well ;-)


Yes


I think the proper thing to do here would be to remove this
function and
convert all drivers to provide appropriate 'resets' properties in the
dts?


Indeed


So I just did that and it works nice for SPL and U-Boot: By adding some
"resets" properties the the main dtsi and adding reset bulk code to the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
code from arch/mach_socfpga.

The problem would be that now Linux cannot use peripherals that aren't
enabled by U-Boot because it relies on them being enabled. How are such
dependencies solved? Because even if I would add reset support in the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...



I added an early reset driver for SoCFPGA that should take care of this.
The patch is in v5.0-rc2[1].


OK, it's good to know that this work is already done, I haven't
monitored this close enough.


We had the same problem with A10, indeed.


But am I correct that my above problem remains even in v5.0 as not all
peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and
qspi) and would thuse not be taken out of reset by Linux?

Plus: should U-Boot work with older Linux kernels? Because if so, we
need fallback code in U-Boot to unreset peripherals when running with an
older kernel...


Yes, it'd break old broken kernels . The real question is, do we care ?


Yes, we care.  Especially since it sounds like we're talking about
something that's an LTS and not super-ancient vendor kernel.  Off the
top of my head I can't recall if we ever fully removed support in sunxi
for the vendor kernel in some cases, or just made it, eventually, opt-in
as it was a fairly annoying incompatible behavior case.

But yes, in general, we do care about old kernels and need to be loud
and clear about when we're removing support for them on a given SoC due
to it being a PITA to support both ways of doing X and people have had Y
years to migrate or correct their kernel.


Then we have to add some fallback mechanism, possibly the env variable
to tell reset controller to unreset everything.


So is an env variable good enough as opt-in or opt-out? How was the 
sunxi thing handled? My feeling is that it would be better to have a 
Kconfig option for such things, to make it just boot after compiling it, 
without relying on the manual act of changing the environment.


But I'm just some user, I'll leave it up to you two to decide ;-)

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

[U-Boot] [PATCH v10 00/10] Fix CVE-2018-18440 and CVE-2018-18439

This series fixes CVE-2018-18440 ("insufficient boundary checks in
filesystem image load") by adding restrictions to the 'load'
command and fixes CVE-2018-18439 ("insufficient boundary checks in
network image boot") by adding restrictions to the tftp code.
The functions from lmb.c are used to setup regions of allowed and
reserved memory. Then, the file size to load is checked against these
addresses and loading the file is aborted if it would overwrite
reserved memory.

The memory reservation code is reused from bootm/image.
Changes in v10:
- added acked-by and reviewed-by tags

Changes in v9:
- fixed compile error in patch 10/10 (in arch/arm/lib/bootm.c)

Changes in v8:
- fix address overflow in 'arch_lmb_reserve' for ARM

Changes in v7:
- add braces around if/else with macros accross more than one line
- fix compiling without CONFIG_FIT
- fix compiling without CONFIG_LMB

Changes in v6:
- fix size of allocated regions that need alignment padding
- fix compiling without OF_CONTROL
- fixed NULL pointer access in 'fdt_blob' passed to
  'boot_fdt_add_mem_rsv_regions'

Changes in v5:
- added tests for lib/lmb.c
- fixed bug in lmb.c when ram is at the end of 32-bit address range
- fixed a bug in lmb_alloc_addr when resulting reserved ranges get
  combined

Changes in v4:
- fixed invalid 'if' statement without braces in boot_fdt_reserve_region
- removed patch 7 ("net: remove CONFIG_MCAST_TFTP), adapted patch 8

Changes in v3:
- No patch changes, but needed to resend since patman added too many cc
  addresses that gmail seemed to detect as spam :-(

Changes in v2:
- added code to reserve devicetree reserved-memory in lmb
- added tftp fixes (patches 7 and 8)
- fixed a bug in new function lmb_alloc_addr

Simon Goldschmidt (10):
  test: add test for lib/lmb.c
  lmb: fix allocation at end of address range
  lib: lmb: reserving overlapping regions should fail
  fdt: parse "reserved-memory" for memory reservation
  lib: lmb: extend lmb for checks at load time
  fs: prevent overwriting reserved memory
  bootm: use new common function lmb_init_and_reserve
  lmb: remove unused extern declaration
  tftp: prevent overwriting reserved memory
  arm: bootm: fix sp detection at end of address range

 arch/arm/lib/bootm.c |  10 +-
 common/bootm.c   |   8 +-
 common/image-fdt.c   |  53 +++-
 fs/fs.c  |  56 +++-
 include/lmb.h|   7 +-
 lib/Makefile |   1 +
 lib/lmb.c| 106 ++--
 net/tftp.c   |  73 +-
 test/lib/Makefile|   1 +
 test/lib/lmb.c   | 601 +++
 10 files changed, 859 insertions(+), 57 deletions(-)
 create mode 100644 test/lib/lmb.c

-- 
2.17.1

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

[U-Boot] [PATCH v10 07/10] bootm: use new common function lmb_init_and_reserve

This reduces duplicate code only.

Signed-off-by: Simon Goldschmidt 
Reviewed-by: Simon Glass 

---

Changes in v10:
- add reviewed-by

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v2: None

 common/bootm.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 8bf84ebcb7..31e4f0f794 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -56,15 +56,11 @@ static void boot_start_lmb(bootm_headers_t *images)
ulong   mem_start;
phys_size_t mem_size;
 
-   lmb_init(>lmb);
-
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
 
-   lmb_add(>lmb, (phys_addr_t)mem_start, mem_size);
-
-   arch_lmb_reserve(>lmb);
-   board_lmb_reserve(>lmb);
+   lmb_init_and_reserve(>lmb, (phys_addr_t)mem_start, mem_size,
+NULL);
 }
 #else
 #define lmb_reserve(lmb, base, size)
-- 
2.17.1

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

[U-Boot] [PATCH v10 08/10] lmb: remove unused extern declaration

lmb.h includes an extern declaration of "struct lmb lmb;" which
is not used anywhere, so remove it.

Signed-off-by: Simon Goldschmidt 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v2:
- this patch is new in v2

 include/lmb.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index 62da85e716..1bb003e35e 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -28,8 +28,6 @@ struct lmb {
struct lmb_region reserved;
 };
 
-extern struct lmb lmb;
-
 extern void lmb_init(struct lmb *lmb);
 extern void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base,
 phys_size_t size, void *fdt_blob);
-- 
2.17.1

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

[U-Boot] [ANN] U-Boot v2019.01 released

Hey all,

So we're a week after the original release day, but on time for when I
said I would push things out to.  We had some more regression fixes, and
a few last minute reminders about other fixes, and here we are.

For a changelog from v2018.11, please see the other RC emails.

I'm now going to repeat what I said in the last release about changing
up the release cycle as here we are now.  Again, there's a few more
words on it here:
https://lists.denx.de/pipermail/u-boot/2018-November/347209.html But in
short, we're still doing v2019.01 on a 2-month cycle and after that
we'll do two 3-month cycle releases, v2019.04 and v2019.07 and see where
things are at towards the end of v2019.07.

So with that, the merge window is open and we're looking at doing the
v2019.04 release on April 8th, 2019.

Thanks all!

-- 
Tom


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

Re: [U-Boot] [PATCH v10 00/10] Fix CVE-2018-18440 and CVE-2018-18439

On Mon, Jan 14, 2019 at 10:38:13PM +0100, Simon Goldschmidt wrote:

> This series fixes CVE-2018-18440 ("insufficient boundary checks in
> filesystem image load") by adding restrictions to the 'load'
> command and fixes CVE-2018-18439 ("insufficient boundary checks in
> network image boot") by adding restrictions to the tftp code.
> The functions from lmb.c are used to setup regions of allowed and
> reserved memory. Then, the file size to load is checked against these
> addresses and loading the file is aborted if it would overwrite
> reserved memory.
> 
> The memory reservation code is reused from bootm/image.
> Changes in v10:
> - added acked-by and reviewed-by tags

Note that patchwork collects these automatically and we don't need to
re-post things just for tags.  Was anything else changed?  Thanks!

-- 
Tom


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

[U-Boot] [PATCH v2] efi_loader: move efi_init_obj_list() to a new efi_setup.c

# removed unnecessary "#if" statements from v1

The function, efi_init_obj_list(), can be shared in different pseudo efi
applications, like bootefi/bootmgr as well as my efishell. Moreover, it
will be utilized to extend efi initialization, for example, my "removable
disk support" patch and "capsule-on-disk support" patch in the future.

So with this patch, it will be moved to a new file, efi_setup.c, under
lib/efi_loader and exported, making no changes in functionality.

Signed-off-by: AKASHI Takahiro 
---
 cmd/bootefi.c  | 75 
 include/efi_loader.h   |  2 +
 lib/efi_loader/Makefile|  1 +
 lib/efi_loader/efi_setup.c | 89 ++
 4 files changed, 92 insertions(+), 75 deletions(-)
 create mode 100644 lib/efi_loader/efi_setup.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 38679ffc56a9..7012d72ab50d 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -30,84 +30,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define OBJ_LIST_NOT_INITIALIZED 1
 
-static efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
-
 static struct efi_device_path *bootefi_image_path;
 static struct efi_device_path *bootefi_device_path;
 
-/* Initialize and populate EFI object list */
-efi_status_t efi_init_obj_list(void)
-{
-   efi_status_t ret = EFI_SUCCESS;
-
-   /*
-* On the ARM architecture gd is mapped to a fixed register (r9 or x18).
-* As this register may be overwritten by an EFI payload we save it here
-* and restore it on every callback entered.
-*/
-   efi_save_gd();
-
-   /* Initialize once only */
-   if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
-   return efi_obj_list_initialized;
-
-   /* Initialize system table */
-   ret = efi_initialize_system_table();
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-   /* Initialize root node */
-   ret = efi_root_node_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-   /* Initialize EFI driver uclass */
-   ret = efi_driver_init();
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-   ret = efi_console_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#ifdef CONFIG_PARTITIONS
-   ret = efi_disk_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#endif
-#if defined(CONFIG_LCD) || defined(CONFIG_DM_VIDEO)
-   ret = efi_gop_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#endif
-#ifdef CONFIG_NET
-   ret = efi_net_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#endif
-#ifdef CONFIG_GENERATE_ACPI_TABLE
-   ret = efi_acpi_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#endif
-#ifdef CONFIG_GENERATE_SMBIOS_TABLE
-   ret = efi_smbios_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-#endif
-   ret = efi_watchdog_register();
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-   /* Initialize EFI runtime services */
-   ret = efi_reset_system_init();
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-out:
-   efi_obj_list_initialized = ret;
-   return ret;
-}
-
 /*
  * Allow unaligned memory access.
  *
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 16633d6da0d5..dd68cfce5c65 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -252,6 +252,8 @@ extern struct list_head efi_obj_list;
 /* List of all events */
 extern struct list_head efi_events;
 
+/* Initialize efi execution environment */
+efi_status_t efi_init_obj_list(void);
 /* Called by bootefi to initialize root node */
 efi_status_t efi_root_node_register(void);
 /* Called by bootefi to initialize runtime */
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 26b999bf7c51..3ba539314aee 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -29,6 +29,7 @@ obj-y += efi_image_loader.o
 obj-y += efi_memory.o
 obj-y += efi_root_node.o
 obj-y += efi_runtime.o
+obj-y += efi_setup.o
 obj-y += efi_unicode_collation.o
 obj-y += efi_variable.o
 obj-y += efi_watchdog.o
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
new file mode 100644
index ..38569af1f2c8
--- /dev/null
+++ b/lib/efi_loader/efi_setup.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  EFI setup code
+ *
+ *  Copyright (c) 2016 Alexander Graf
+ *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ */
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define OBJ_LIST_NOT_INITIALIZED 1
+
+static efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
+
+/* Initialize and populate EFI object list */
+efi_status_t efi_init_obj_list(void)
+{
+   efi_status_t ret = EFI_SUCCESS;
+
+   /*
+* On the ARM architecture gd is mapped to a fixed register (r9 or x18).
+* As this register may be overwritten by an EFI payload we save

[U-Boot] [PATCH v2 0/5] efi_loader: run a specific efi application more easily

This patch is a result from re-organizing my previous patches;
a combination of [1] and part of [2] so as to solely provide several ways
of executing a specific efi application explicitly.
  * bootmanager via BootNext variable
  * bootefi with boot id
  * run -e with Boot variable

Changes in v2 (Jan 15, 2019)
* not specify any attributes when deleting BootNext variable in
  efi_bootmgr_load()
* introduce EFI_BOOTMGR_DEFAULT_ORDER macro on behalf of BootOrder
  for use in efi_bootmgr_load()
* simplify the code around efi_handle_fdt() in do_bootefi()
* add do_bootefi_run() and call it at "run -e" so that we don't have to
  export internal efi helper functions

[1] https://lists.denx.de/pipermail/u-boot/2018-November/349281.html
[2] https://lists.denx.de/pipermail/u-boot/2018-November/346450.html

AKASHI Takahiro (5):
  efi_loader: bootmgr: support BootNext and BootCurrent variable
behavior
  efi_loader: bootmgr: allow for running a given load option
  cmd: bootefi: carve out fdt parameter handling
  cmd: bootefi: run an EFI application of a specific load option
  cmd: run: add "-e" option to run an EFI application

 cmd/bootefi.c| 114 +++
 cmd/nvedit.c |   9 ++-
 common/cli.c |  10 +++
 include/command.h|   3 +
 include/efi_loader.h |   5 +-
 lib/efi_loader/efi_bootmgr.c |  43 -
 6 files changed, 156 insertions(+), 28 deletions(-)

-- 
2.19.1

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

[U-Boot] [PATCH v4 7/9] cmd: efitool: add memmap command

"memmap" command prints uefi-specific memory map information.
=> efi memmap
Type StartEnd  Attributes
   ==
CONVENTIONAL 4000-7de27000 WB
RUNTIME DATA 7de27000-7de28000 WB|RT
RESERVED 7de28000-7de2a000 WB
RUNTIME DATA 7de2a000-7de2b000 WB|RT
RESERVED 7de2b000-7de2c000 WB
RUNTIME DATA 7de2c000-7de2d000 WB|RT
LOADER DATA  7de2d000-7ff37000 WB
RUNTIME CODE 7ff37000-7ff38000 WB|RT
LOADER DATA  7ff38000-8000 WB

Signed-off-by: AKASHI Takahiro 
---
 cmd/efitool.c | 78 ++-
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/cmd/efitool.c b/cmd/efitool.c
index e77273fc6e1e..f06718ea580d 100644
--- a/cmd/efitool.c
+++ b/cmd/efitool.c
@@ -540,6 +540,78 @@ static int do_efi_show_images(int argc, char * const 
argv[])
return CMD_RET_SUCCESS;
 }
 
+static const char * const efi_mem_type_string[] = {
+   [EFI_RESERVED_MEMORY_TYPE] = "RESERVED",
+   [EFI_LOADER_CODE] = "LOADER CODE",
+   [EFI_LOADER_DATA] = "LOADER DATA",
+   [EFI_BOOT_SERVICES_CODE] = "BOOT CODE",
+   [EFI_BOOT_SERVICES_DATA] = "BOOT DATA",
+   [EFI_RUNTIME_SERVICES_CODE] = "RUNTIME CODE",
+   [EFI_RUNTIME_SERVICES_DATA] = "RUNTIME DATA",
+   [EFI_CONVENTIONAL_MEMORY] = "CONVENTIONAL",
+   [EFI_UNUSABLE_MEMORY] = "UNUSABLE MEM",
+   [EFI_ACPI_RECLAIM_MEMORY] = "ACPI RECLAIM MEM",
+   [EFI_ACPI_MEMORY_NVS] = "ACPI NVS",
+   [EFI_MMAP_IO] = "IO",
+   [EFI_MMAP_IO_PORT] = "IO PORT",
+   [EFI_PAL_CODE] = "PAL",
+};
+
+#define EFI_MEM_ATTR(attribute, bit, string) \
+   if ((attribute) & (bit)) {  \
+   if (sep)\
+   putc('|');  \
+   sep = 1;\
+   printf(string); \
+   }
+
+static int do_efi_show_memmap(int argc, char * const argv[])
+{
+   struct efi_mem_desc *memmap = NULL, *map;
+   efi_uintn_t map_size = 0;
+   int i, sep;
+   efi_status_t ret;
+
+   ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
+   if (ret == EFI_BUFFER_TOO_SMALL) {
+   memmap = malloc(map_size);
+   if (!memmap)
+   return CMD_RET_FAILURE;
+   ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
+   }
+   if (ret != EFI_SUCCESS) {
+   free(memmap);
+   return CMD_RET_FAILURE;
+   }
+
+   printf("Type StartEnd  
Attributes\n");
+   printf("   
==\n");
+   for (i = 0, map = memmap; i < map_size / sizeof(*map); map++, i++) {
+   sep = 0;
+   printf("%-16s %016llx-%016llx ",
+  efi_mem_type_string[map->type],
+  map->physical_start,
+  map->physical_start + map->num_pages * EFI_PAGE_SIZE);
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UC, "UC");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WC, "WC");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WT, "WT");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WB, "WB");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UCE, "UCE");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WP, "WP");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RP, "RP");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_XP, "WP");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_NV, "NV");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_MORE_RELIABLE, "REL");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RO, "RO");
+   EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RUNTIME, "RT");
+   putc('\n');
+   }
+
+   free(memmap);
+
+   return CMD_RET_SUCCESS;
+}
+
 static int do_efi_boot_add(int argc, char * const argv[])
 {
int id;
@@ -955,6 +1027,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
return do_efi_show_handles(argc, argv);
else if (!strcmp(command, "images"))
return do_efi_show_images(argc, argv);
+   else if (!strcmp(command, "memmap"))
+   return do_efi_show_memmap(argc, argv);
else
return CMD_RET_USAGE;
 }
@@ -987,7 +1061,9 @@ static char efitool_help_text[] =
"efitool dh\n"
"  - show uefi handles\n"
"efitool images\n"
-   "  - show loaded images\n";
+   "  - show loaded images\n"
+   "efitool memmap\n"
+   "  - show uefi memory map\n";
 #endif
 
 U_BOOT_CMD(
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [PATCH v4 5/9] cmd: efitool: add dh command

"dh" command prints all the uefi handles used in the system.

=> efi dh
7ef3bfa0: Device Path, Device Path To Text, Device Path Utilities,
  Unicode Collation 2
7ef31d30: Driver Binding
7ef31da0: Simple Text Output
7ef31e10: Simple Text Input, Simple Text Input Ex
7ef3cca0: Block IO, Device Path
7ef3d070: Block IO, Device Path
7ef3d1b0: Block IO, Device Path, Simple File System
7ef3d3e0: Block IO, Device Path, Simple File System

Signed-off-by: AKASHI Takahiro 
---
 cmd/efitool.c | 103 +-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/cmd/efitool.c b/cmd/efitool.c
index 4d46721fbf91..4bd6367b4bd9 100644
--- a/cmd/efitool.c
+++ b/cmd/efitool.c
@@ -436,6 +436,103 @@ static int do_efi_show_drivers(int argc, char * const 
argv[])
return CMD_RET_SUCCESS;
 }
 
+static struct {
+   u16 *name;
+   efi_guid_t guid;
+} guid_list[] = {
+   {
+   L"Device Path",
+   DEVICE_PATH_GUID,
+   },
+   {
+   L"Device Path To Text",
+   EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID,
+   },
+   {
+   L"Device Path Utilities",
+   EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID,
+   },
+   {
+   L"Unicode Collation 2",
+   EFI_UNICODE_COLLATION_PROTOCOL2_GUID,
+   },
+   {
+   L"Driver Binding",
+   EFI_DRIVER_BINDING_PROTOCOL_GUID,
+   },
+   {
+   L"Simple Text Input",
+   EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID,
+   },
+   {
+   L"Simple Text Input Ex",
+   EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL_GUID,
+   },
+   {
+   L"Simple Text Output",
+   EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID,
+   },
+   {
+   L"Block IO",
+   BLOCK_IO_GUID,
+   },
+   {
+   L"Simple File System",
+   EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
+   },
+   {
+   NULL,
+   {{0,},},
+   },
+};
+
+static int do_efi_show_handles(int argc, char * const argv[])
+{
+   efi_handle_t *handles;
+   efi_guid_t **guid;
+   efi_uintn_t count;
+   int num, i, j, k;
+   efi_status_t ret;
+
+   handles = NULL;
+   num = 0;
+   if (efi_get_handles_by_proto(NULL, , ))
+   return CMD_RET_FAILURE;
+
+   if (!num)
+   return CMD_RET_SUCCESS;
+
+   for (i = 0; i < num; i++) {
+   printf("%16p:", handles[i]);
+   ret = BS->protocols_per_handle(handles[i], , );
+   if (ret || !count) {
+   putc('\n');
+   continue;
+   }
+
+   for (j = 0; j < count; j++) {
+   for (k = 0; guid_list[k].name; k++)
+   if (!guidcmp(_list[k].guid, guid[j]))
+   break;
+
+   if (j)
+   printf(", ");
+   else
+   putc(' ');
+
+   if (guid[j])
+   printf("%ls", guid_list[k].name);
+   else
+   printf("%pUl", guid[j]);
+   }
+   putc('\n');
+   }
+
+   free(handles);
+
+   return CMD_RET_SUCCESS;
+}
+
 static int do_efi_boot_add(int argc, char * const argv[])
 {
int id;
@@ -847,6 +944,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
return do_efi_show_devices(argc, argv);
else if (!strcmp(command, "drivers"))
return do_efi_show_drivers(argc, argv);
+   else if (!strcmp(command, "dh"))
+   return do_efi_show_handles(argc, argv);
else
return CMD_RET_USAGE;
 }
@@ -875,7 +974,9 @@ static char efitool_help_text[] =
"efitool devices\n"
"  - show uefi devices\n"
"efitool drivers\n"
-   "  - show uefi drivers\n";
+   "  - show uefi drivers\n"
+   "efitool dh\n"
+   "  - show uefi handles\n";
 #endif
 
 U_BOOT_CMD(
-- 
2.19.1

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

Re: [U-Boot] [PATCH v2] efi_loader: move efi_init_obj_list() to a new efi_setup.c

2019-01-14 Thread Heinrich Schuchardt

On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> # removed unnecessary "#if" statements from v1
> 
> The function, efi_init_obj_list(), can be shared in different pseudo efi
> applications, like bootefi/bootmgr as well as my efishell. Moreover, it
> will be utilized to extend efi initialization, for example, my "removable
> disk support" patch and "capsule-on-disk support" patch in the future.
> 
> So with this patch, it will be moved to a new file, efi_setup.c, under
> lib/efi_loader and exported, making no changes in functionality.
> 
> Signed-off-by: AKASHI Takahiro 

A corrected version 1 patch is already merged in efi-next:

https://github.com/agraf/u-boot/commits/efi-next

"efi_loader: move efi_init_obj_list() to a new efi_setup.c"
https://github.com/agraf/u-boot/commit/f30df235b5b5b3db65f89360ef114719d542ca0d

So I think this v2 patch is obsolete.

Should you find any mistake in the merged patch, please, provide a
follow up patch.

Best regards

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

Re: [U-Boot] [PATCH v4 1/9] cmd: add efitool command

2019-01-14 Thread Heinrich Schuchardt

On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> Currently, there is no easy way to add or modify UEFI variables.
> In particular, bootmgr supports BootOrder/Boot variables, it is
> quite hard to define them as u-boot variables because they are represented
> in a complicated and encoded format.
> 
> The new command, efitool, helps address these issues and give us
> more friendly interfaces:
>  * efitool boot add: add Boot variable
>  * efitool boot rm: remove Boot variable
>  * efitool boot dump: display all Boot variables
>  * efitool boot order: set/display a boot order (BootOrder)
>  * efitool setvar: set an UEFI variable (with limited functionality)
>  * efitool dumpvar: display all UEFI variables
> 
> As the name suggests, this command basically provides a subset fo UEFI
> shell commands with simplified functionality.
> 
> Signed-off-by: AKASHI Takahiro 

Hello Takahiro,

thanks a lot for your patch series. The additional command is really useful.

Unfortunately the implementation of sub-commands does not follow the
coding style of other sub-commands. Could you please have a look at the
current doc/README.commands

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.commands

I think it should be easy to convert your code to follow the
implementation style suggested there and used all over U-Boot.

Sorry that I did not put this into an earlier comment. I only learnt
about this recently by a review from Simon and then updated the README.

Please, add the new file in MAINTAINERS to the EFI PAYLOAD section.

Best regards

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

[U-Boot] [PATCH 0/4] Support nds32 pre-build toolchain

2019-01-14 Thread Andes

From: Rick Chen 

1. Support nds32 pre-build toolcahin for buildman.
2. Fix some bugs about fpu and toolchain issues.

Rick Chen (4):
  .travis.yml: Support nds32 prebuilt toolchain
  nds32: Remove gcc unused option
  nds32: Generate SW fpu instruction.
  nds32: Fix boot fail issue when build with elf-mculib.

 .travis.yml  | 9 +
 arch/nds32/config.mk | 6 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 7/9] cmd: efitool: add memmap command

2019-01-14 Thread Heinrich Schuchardt

On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> "memmap" command prints uefi-specific memory map information.
> => efi memmap
> Type StartEnd  Attributes
>    ==
> CONVENTIONAL 4000-7de27000 WB
> RUNTIME DATA 7de27000-7de28000 WB|RT
> RESERVED 7de28000-7de2a000 WB
> RUNTIME DATA 7de2a000-7de2b000 WB|RT
> RESERVED 7de2b000-7de2c000 WB
> RUNTIME DATA 7de2c000-7de2d000 WB|RT
> LOADER DATA  7de2d000-7ff37000 WB
> RUNTIME CODE 7ff37000-7ff38000 WB|RT
> LOADER DATA  7ff38000-8000 WB
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/efitool.c | 78 ++-
>  1 file changed, 77 insertions(+), 1 deletion(-)
> 
> diff --git a/cmd/efitool.c b/cmd/efitool.c
> index e77273fc6e1e..f06718ea580d 100644
> --- a/cmd/efitool.c
> +++ b/cmd/efitool.c
> @@ -540,6 +540,78 @@ static int do_efi_show_images(int argc, char * const 
> argv[])
>   return CMD_RET_SUCCESS;
>  }
>  
> +static const char * const efi_mem_type_string[] = {
> + [EFI_RESERVED_MEMORY_TYPE] = "RESERVED",
> + [EFI_LOADER_CODE] = "LOADER CODE",
> + [EFI_LOADER_DATA] = "LOADER DATA",
> + [EFI_BOOT_SERVICES_CODE] = "BOOT CODE",
> + [EFI_BOOT_SERVICES_DATA] = "BOOT DATA",
> + [EFI_RUNTIME_SERVICES_CODE] = "RUNTIME CODE",
> + [EFI_RUNTIME_SERVICES_DATA] = "RUNTIME DATA",
> + [EFI_CONVENTIONAL_MEMORY] = "CONVENTIONAL",
> + [EFI_UNUSABLE_MEMORY] = "UNUSABLE MEM",
> + [EFI_ACPI_RECLAIM_MEMORY] = "ACPI RECLAIM MEM",
> + [EFI_ACPI_MEMORY_NVS] = "ACPI NVS",
> + [EFI_MMAP_IO] = "IO",
> + [EFI_MMAP_IO_PORT] = "IO PORT",
> + [EFI_PAL_CODE] = "PAL",
> +};
> +
> +#define EFI_MEM_ATTR(attribute, bit, string) \
> + if ((attribute) & (bit)) {  \
> + if (sep)\
> + putc('|');  \
> + sep = 1;\
> + printf(string); \
> + }
> +
> +static int do_efi_show_memmap(int argc, char * const argv[])
> +{
> + struct efi_mem_desc *memmap = NULL, *map;
> + efi_uintn_t map_size = 0;
> + int i, sep;
> + efi_status_t ret;
> +
> + ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);

ret = EFI_SUCCCESS will only occur if the memory has not been setup yet.

So shouldn't we error out if ret != EFI_BUFFER_TOO_SMALL ?

> + if (ret == EFI_BUFFER_TOO_SMALL) {
> + memmap = malloc(map_size);
> + if (!memmap)
> + return CMD_RET_FAILURE;
> + ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> + }
> + if (ret != EFI_SUCCESS) {
> + free(memmap);
> + return CMD_RET_FAILURE;
> + }
> +
> + printf("Type StartEnd  
> Attributes\n");
> + printf("   
> ==\n");
> + for (i = 0, map = memmap; i < map_size / sizeof(*map); map++, i++) {
> + sep = 0;
> + printf("%-16s %016llx-%016llx ",
> +efi_mem_type_string[map->type],
> +map->physical_start,
> +map->physical_start + map->num_pages * EFI_PAGE_SIZE);
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UC, "UC");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WC, "WC");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WT, "WT");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WB, "WB");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UCE, "UCE");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WP, "WP");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RP, "RP");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_XP, "WP");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_NV, "NV");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_MORE_RELIABLE, "REL");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RO, "RO");
> + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RUNTIME, "RT");

Please, put that logic into a separate function which returns a const
char *. Then we need only a single printf().

I suggest to use an array for the mapping:

struct memory_attribute_name {
u64 attribute;
const char *short_name;
};

struct memory_attribute_name memory_attribute_names[] = {
{EFI_MEMORY_UC, "UC"},
...
};

For looping you can use ARRAY_SIZE(memory_attribute_names).

> + putc('\n');
> + }
> +
> + free(memmap);
> +
> + return CMD_RET_SUCCESS;
> +}
> +
>  static int do_efi_boot_add(int argc, char * const argv[])
>  {

Please, refer to doc/README.commands for the standard way of adding
sub-commands.

Best regards

Heinrich

>   int id;
> @@ -955,6

Re: [U-Boot] [PATCH v3 3/9] clk: actions: Add common clock driver

On 14/01/2019 12:41, Amit Singh Tomar wrote:

Hi,

> CMU block on most of the actions SoC seems to be identical(at-least, S900 and 
> S700).

Actually they are not. Not even for the small subset that we implement
here. Try "diff -wu arch/arm/include/asm/arch-owl/regs_s*.h" for a
start, plus the differences in the #ifdefs below.

> This patch converts S900 clock driver to something common that can
> be used for other SoCs, for instance S700(most of clk registres are same).

I am not sure this is a viable approach, really.
The driver claims to support both SoC's via their compatible strings,
but in fact is just implementing the one configured via Kconfig.
While we should be able to easily replace the #ifdefs with something
checking the .data member associated with the respective .compatible
string, it gets hairy with the #defines in regs_s[79]00.h.
So either it's two different .c files, with the register definitions in
there, or we change the CMU_* defines to CMU_S[79]00_* and include both.

Maybe you could try this and report how it looks like?
If half of the file is within if-else statements, separating is problem
more worthwhile.
Mani, you mentioned the S500, I guess this is even more different,
right? Which would point into the "separate files" direction.

> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v1:
>   * Moved CLK and CLK_OWL symbols from defconfig to arch/arm/Kconfig.
> ---
>  arch/arm/Kconfig  |   2 +
>  arch/arm/include/asm/arch-owl/clk_owl.h   |  61 +
>  arch/arm/include/asm/arch-owl/clk_s900.h  |  57 -
>  arch/arm/include/asm/arch-owl/regs_s700.h |  56 

This file doesn't define an interface, so should live in the
drivers/clk/owl directory. Same with the regs_s900.h.

>  configs/bubblegum_96_defconfig|   3 -
>  drivers/clk/owl/Kconfig   |  10 +--
>  drivers/clk/owl/Makefile  |   2 +-
>  drivers/clk/owl/clk_owl.c | 132 
>  drivers/clk/owl/clk_s900.c| 137 
> --
>  9 files changed, 255 insertions(+), 205 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
>  delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
>  create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
>  create mode 100644 drivers/clk/owl/clk_owl.c
>  delete mode 100644 drivers/clk/owl/clk_s900.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1a2e561..1daf3bf 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -764,6 +764,8 @@ config ARCH_OWL
>   select DM
>   select DM_SERIAL
>   select OWL_SERIAL
> + select CLK
> + select CLK_OWL
>   select OF_CONTROL
>   imply CMD_DM
>  
> diff --git a/arch/arm/include/asm/arch-owl/clk_owl.h 
> b/arch/arm/include/asm/arch-owl/clk_owl.h
> new file mode 100644
> index 000..962badd
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-owl/clk_owl.h
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Actions Semi SoCs Clock Definitions
> + *
> + * Copyright (C) 2015 Actions Semi Co., Ltd.
> + * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> + *
> + */
> +
> +#ifndef _OWL_CLK_H_
> +#define _OWL_CLK_H_
> +
> +#include 
> +
> +struct owl_clk_priv {
> + phys_addr_t base;
> +};
> +
> +/* BUSCLK register definitions */
> +#define CMU_PDBGDIV_87
> +#define CMU_PDBGDIV_SHIFT26
> +#define CMU_PDBGDIV_DIV  (CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
> +#define CMU_PERDIV_8 7
> +#define CMU_PERDIV_SHIFT 20
> +#define CMU_PERDIV_DIV   (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
> +#define CMU_NOCDIV_2 1
> +#define CMU_NOCDIV_SHIFT 19
> +#define CMU_NOCDIV_DIV   (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
> +#define CMU_DMMCLK_SRC_APLL  2
> +#define CMU_DMMCLK_SRC_SHIFT 10
> +#define CMU_DMMCLK_SRC   (CMU_DMMCLK_SRC_APLL << 
> CMU_DMMCLK_SRC_SHIFT)
> +#define CMU_APBCLK_DIV   BIT(8)
> +#define CMU_NOCCLK_SRC   BIT(7)
> +#define CMU_AHBCLK_DIV   BIT(4)
> +#define CMU_CORECLK_MASK 3
> +#define CMU_CORECLK_CPLL BIT(1)
> +#define CMU_CORECLK_HOSC BIT(0)
> +
> +/* COREPLL register definitions */
> +#define CMU_COREPLL_EN   BIT(9)
> +#define CMU_COREPLL_HOSC_EN  BIT(8)
> +#define CMU_COREPLL_OUT  (1104 / 24)
> +
> +/* DEVPLL register definitions */
> +#define CMU_DEVPLL_CLK   BIT(12)
> +#define CMU_DEVPLL_ENBIT(8)
> +#define CMU_DEVPLL_OUT   (660 / 6)
> +
> +/* UARTCLK register definitions */
> +#define CMU_UARTCLK_SRC_DEVPLL   BIT(16)
> +
> +/* DEVCLKEN1 register definitions */
> +#if defined(CONFIG_MACH_S900)

Meh.

> +#define CMU_DEVCLKEN1_UART5  BIT(21)
> +#elif defined(CONFIG_MACH_S700)
> +#define CMU_DEVCLKEN1_UART3 BIT(11)
> +#endif
> +
> +#define PLL_STABILITY_WAIT_US50
> +
> +#endif
> diff --git

Re: [U-Boot] [PATCH 2/2] lib: fdtdec: fixup fdtdec_get_addr_size

2019-01-14 Thread Simon Glass

Hi Keerthy,

On Thu, 3 Jan 2019 at 21:39, Keerthy  wrote:
>
>
>
> On Thursday 03 January 2019 11:44 PM, s...@google.com wrote:
> > On 12/21/18 9:24 AM, Keerthy wrote:
> >> fix up fdtdec_get_addr_size to use fdtdec_get_addr_size_auto_noparent
> >> so that the address cells and size cells are obtained from the
> >> parent instead of going by the fixed length.
> >
> > This patch makes perfect sense to me. However, I am worried about the
> > potential existence of code that assumes the current fixed-size logic;
> > in the past when fixing similar issues like this we've often run into
> > code that was use "get addr" functions when it should have been using
> > "get u32" functions and similar, which then broke when we fixed the
> > implementation to do the right thing. I guess we should still apply the
> > patch, and fix up any fallout as it appears.
>
> Thanks Simon!

Unfortunately this breaks the tests (make qcheck). Can you please take a look?

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

[U-Boot] [PATCH v4 8/9] cmd: efitool: export uefi variable helper functions

Those function will be used for integration with 'env' command
so as to handle uefi variables.

Signed-off-by: AKASHI Takahiro 
---
 cmd/efitool.c | 38 ++
 include/command.h |  4 
 2 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/cmd/efitool.c b/cmd/efitool.c
index f06718ea580d..b8fe28c53aaf 100644
--- a/cmd/efitool.c
+++ b/cmd/efitool.c
@@ -67,7 +67,7 @@ static void dump_var_data(char *data, unsigned long len)
  *
  *   efi_$guid_$varname = {attributes}(type)value
  */
-static int do_efi_dump_var(int argc, char * const argv[])
+static int _do_efi_dump_var(int argc, char * const argv[])
 {
char regex[256];
char * const regexlist[] = {regex};
@@ -130,6 +130,21 @@ static int do_efi_dump_var(int argc, char * const argv[])
return CMD_RET_SUCCESS;
 }
 
+int do_efi_dump_var(int argc, char * const argv[])
+{
+   efi_status_t r;
+
+   /* Initialize EFI drivers */
+   r = efi_init_obj_list();
+   if (r != EFI_SUCCESS) {
+   printf("Error: Cannot set up EFI drivers, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+   return CMD_RET_FAILURE;
+   }
+
+   return _do_efi_dump_var(argc, argv);
+}
+
 static int append_value(char **bufp, unsigned long *sizep, char *data)
 {
char *tmp_buf = NULL, *new_buf = NULL, *value;
@@ -227,7 +242,7 @@ out:
return 0;
 }
 
-static int do_efi_set_var(int argc, char * const argv[])
+static int _do_efi_set_var(int argc, char * const argv[])
 {
char *var_name, *value = NULL;
efi_uintn_t size = 0;
@@ -270,6 +285,21 @@ out:
return ret;
 }
 
+int do_efi_set_var(int argc, char * const argv[])
+{
+   efi_status_t r;
+
+   /* Initialize EFI drivers */
+   r = efi_init_obj_list();
+   if (r != EFI_SUCCESS) {
+   printf("Error: Cannot set up EFI drivers, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+   return CMD_RET_FAILURE;
+   }
+
+   return _do_efi_set_var(argc, argv);
+}
+
 static int efi_get_handles_by_proto(efi_guid_t *guid, efi_handle_t **handlesp,
int *num)
 {
@@ -1016,9 +1046,9 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
if (!strcmp(command, "boot"))
return do_efi_boot_opt(argc, argv);
else if (!strcmp(command, "dumpvar") || !strcmp(command, "dmpstore"))
-   return do_efi_dump_var(argc, argv);
+   return _do_efi_dump_var(argc, argv);
else if (!strcmp(command, "setvar"))
-   return do_efi_set_var(argc, argv);
+   return _do_efi_set_var(argc, argv);
else if (!strcmp(command, "devices"))
return do_efi_show_devices(argc, argv);
else if (!strcmp(command, "drivers"))
diff --git a/include/command.h b/include/command.h
index feddef300ccc..315e4b9aabfb 100644
--- a/include/command.h
+++ b/include/command.h
@@ -51,6 +51,10 @@ extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[]);
 #if defined(CONFIG_CMD_BOOTEFI)
 extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[]);
 #endif
+#if defined(CONFIG_CMD_EFITOOL)
+int do_efi_dump_var(int argc, char * const argv[]);
+int do_efi_set_var(int argc, char * const argv[]);
+#endif
 
 /* common/command.c */
 int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
-- 
2.19.1

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

[U-Boot] [PATCH v4 4/9] cmd: efitool: add drivers command

"drivers" command prints all the uefi drivers on the system.

=> efi drivers
D
r
vDriver Name  Image Path
  ==
7ef31d30 EFI block driver 

Signed-off-by: AKASHI Takahiro 
---
 cmd/efitool.c | 84 ++-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/cmd/efitool.c b/cmd/efitool.c
index 6b2df1beedb5..4d46721fbf91 100644
--- a/cmd/efitool.c
+++ b/cmd/efitool.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define BS systab.boottime
@@ -358,6 +360,82 @@ static int do_efi_show_devices(int argc, char * const 
argv[])
return CMD_RET_SUCCESS;
 }
 
+static int efi_get_driver_handle_info(efi_handle_t handle, u16 **name,
+ u16 **devname, u16 **filename)
+{
+   struct efi_handler *handler;
+   struct efi_driver_binding_extended_protocol *bp;
+   efi_status_t ret;
+
+   ret = efi_search_protocol(handle, _guid_driver_binding_protocol,
+ );
+   if (ret != EFI_SUCCESS)
+   return -1;
+   bp = handler->protocol_interface;
+
+   *name = malloc((strlen(bp->name) + 1) * sizeof(u16));
+   if (*name)
+   ascii2unicode(*name, bp->name);
+
+   /*
+* TODO:
+* handle image->device_handle,
+* use append_device_path()
+*/
+   *devname = NULL;
+   *filename = NULL;
+
+   return 0;
+}
+
+static int do_efi_show_drivers(int argc, char * const argv[])
+{
+   efi_handle_t *handles = NULL, *handle;
+   efi_uintn_t size = 0;
+   u16 *drvname, *devname, *filename;
+   efi_status_t ret;
+   int i;
+
+   ret = BS->locate_handle(BY_PROTOCOL, _guid_driver_binding_protocol,
+   NULL, , NULL);
+   if (ret == EFI_BUFFER_TOO_SMALL) {
+   handles = calloc(1, size);
+   if (!handles)
+   return CMD_RET_FAILURE;
+
+   ret = BS->locate_handle(BY_PROTOCOL,
+   _guid_driver_binding_protocol,
+   NULL, , handles);
+   }
+   if (ret != EFI_SUCCESS) {
+   free(handles);
+   return CMD_RET_FAILURE;
+   }
+
+   printf("D\n");
+   printf("r\n");
+   printf("vDriver Name  Image Path\n");
+   printf("  ==\n");
+   handle = handles;
+   for (i = 0; i < size / sizeof(*handle); i++) {
+   if (!efi_get_driver_handle_info(*handle, , ,
+   )) {
+   if (filename)
+   printf("%16p %-20ls %ls/%ls\n",
+  *handle, drvname, devname, filename);
+   else
+   printf("%16p %-20ls \n",
+  *handle, drvname);
+   free(drvname);
+   free(devname);
+   free(filename);
+   }
+   handle++;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
 static int do_efi_boot_add(int argc, char * const argv[])
 {
int id;
@@ -767,6 +845,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
return do_efi_set_var(argc, argv);
else if (!strcmp(command, "devices"))
return do_efi_show_devices(argc, argv);
+   else if (!strcmp(command, "drivers"))
+   return do_efi_show_drivers(argc, argv);
else
return CMD_RET_USAGE;
 }
@@ -793,7 +873,9 @@ static char efitool_help_text[] =
"  - set/delete uefi variable's value\n"
" may be \"=\"...\"\", \"=0x...\", \"=H...\", (set) or \"=\" 
(delete)\n"
"efitool devices\n"
-   "  - show uefi devices\n";
+   "  - show uefi devices\n"
+   "efitool drivers\n"
+   "  - show uefi drivers\n";
 #endif
 
 U_BOOT_CMD(
-- 
2.19.1

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

[U-Boot] [PATCH v2 3/5] cmd: bootefi: carve out fdt parameter handling