Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

2018-01-07 Thread Marek Vasut
On 01/06/2018 10:09 PM, Jason Rush wrote:
> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>> On 01/06/2018 07:46 PM, Jason Rush wrote:
>>> On 1/6/2018 9:42 AM, Marek Vasut wrote:
> 
> 
> 
>>> There was a minor upstream change to one of the files since I submitted v4 
>>> of my
>>> cadence device-tree patchset, so I rebased and resent the patchset as a v5. 
>>>  I
>>> included everyone that was originally involved with the patches and added a 
>>> CC
>>> for Marek.
>>>
>>> This is only the patchset for the device tree changes for the cadence qspi 
>>> driver,
>>> Simon will still have to add the patch that fixes the cache invalidation 
>>> bug in the
>>> cadence driver.
>> Sigh, can we get a single patchset out which fixes the problem ?
>>
>> I mean, if I understand this correctly, you're all addressing one single
>> problem, but with two patchsets, yes ?
>>
> Well... The one issue we're trying to fix is that the cadence QSPI hasn't 
> worked on
> the socfpga arch since late 2016.  However, it's two different issues that 
> have caused
> this bigger problem:
> 
> 1. The indaddrtrig register was being programmed with an incorrect value for 
> socfpga
> as the result of assuming it should be programmed with the same address as the
> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, 
> which has
> an independent setting for the indaddrtrig register so the register can be 
> set correctly
> on all architectures.  Plus it aligns the DT between u-boot and Linux.

That should be an easy patch, so this is the patchset 0/5..5/5 that you
just submitted ?

> 2. The cadence driver was modified at one point to use the bouncebuf 
> functions to fix
> an issue on a TI architecture that expected, where if I recall correctly all 
> reads except
> the last have to be 32-bit reads.  However, since the bouncebuf was designed 
> for DMA
> transfers, it invalidates the data cache after reading, but since the cadence 
> is using cpu
> transfers the newly read data is thrown away when the cache is invalidated.  
> This issue
> is resolved by reverting the commit that introduced using the bounce buffer 
> for read
> operations, which according to Vignesh don't cause any issues to the TI 
> architecture.

Hm, I wonder why you need bounce buffer at all here. The CQSPI
literally reads/writes a register space (or some FIFO in register
space), there is no DMA involved at all. I also wonder why we have to
manipulate with cache at all here.

> So, would you prefer two patchsets or one that fixes both issues?  If you'd 
> like just one,
> Simon can collapse my patches along with his revert patch into a single 
> patchset and
> resubmit.

If 1) is fixed by this patchset 0/5..5/5 and 2) is fixed by some other
patchset, then that's fine as is. Thanks for explaining it like so, it
really did help.

> -- Jason
> 


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


Re: [U-Boot] [PATCH v5 0/5] spi: cadence_spi: Adopt Linux DT bindings

2018-01-07 Thread Marek Vasut
On 01/06/2018 07:17 PM, Jason Rush wrote:
> Adopt the Linux DT bindings. This also fixes an issue
> with the indaddrtrig register on the Cadence QSPI
> device being programmed with the wrong value for the
> socfpga arch.
> 
> Tested on TI K2G platform:
> Tested-by: Vignesh R 
> 
> Tested on a socfpga-cyclonev board:
> Tested-by: Simon Goldschmidt 
> 
> Signed-off-by: Jason Rush 
> 
> Jason Rush (5):
>   spi: cadence_spi: Sync DT bindings with Linux
>   dts: cadence_spi: Sync DT bindings with Linux
>   config: cadence_spi: Remove defines read from DT
>   dts: k2g: Clean-up indentation
>   dts: cadence_spi: Update documentation for DT bindings
> 
>  arch/arm/dts/keystone-k2g-evm.dts | 75 
> +--
>  arch/arm/dts/keystone-k2g.dtsi|  5 +-
>  arch/arm/dts/socfpga.dtsi |  5 +-
>  arch/arm/dts/socfpga_arria10.dtsi |  4 +-
>  arch/arm/dts/socfpga_arria5_socdk.dts |  9 ++--
>  arch/arm/dts/socfpga_cyclone5_is1.dts |  9 ++--
>  arch/arm/dts/socfpga_cyclone5_socdk.dts   |  9 ++--
>  arch/arm/dts/socfpga_cyclone5_sockit.dts  |  9 ++--
>  arch/arm/dts/socfpga_cyclone5_socrates.dts|  9 ++--
>  arch/arm/dts/socfpga_cyclone5_sr1500.dts  |  9 ++--
>  arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 18 +++
>  arch/arm/dts/stv0991.dts  | 12 +++--
>  doc/device-tree-bindings/spi/spi-cadence.txt  | 13 +++--
>  drivers/spi/cadence_qspi.c| 20 ---
>  drivers/spi/cadence_qspi.h|  6 ++-
>  drivers/spi/cadence_qspi_apb.c| 15 ++
>  include/configs/k2g_evm.h |  1 -
>  include/configs/socfpga_common.h  |  1 -
>  include/configs/stv0991.h |  1 -
>  19 files changed, 113 insertions(+), 117 deletions(-)
> 

Whole series

Acked-by: Marek Vasut 

So please apply after 2018.01 is out .
Thanks

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


[U-Boot] "fdt" commands in extlinux.conf ?

2018-01-07 Thread Ken Harris
I'd like to enable the CANbus on a Beagle Bone Black (on Fedora ...
which doesn't do "cape manager").

The crux is a fdt command in u-boot :

fdt set d_can1 status okay

Is there a way to do this in extlinux.conf ?

I didn't see a way (in uboot 2017.09), so I wrote a uEnv.txt script
(see attached).

That's a bit verbose and duplicates a bunch of stuff already in uboot
(also : uEnv.txt doesn't exist on my "Orange Pi One").

It there a simpler way to state "fdt" commands ?

Thanks

##run findfdt; run init_console
##mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device 
${mmcdev};fi
###run distro_bootcmd

##run loadbootenv; run importbootenv

devtype=mmc
bootpart=0:1

## scan_dev_for_boot_part ??
## finduuid ??

uuid=b2c019d9-2401-4a22-9a40-36a92a00cdfe

#u0=-4.13.11-200.fc26.armv7hl
#u0=-4.13.12-300.fc27.armv7hl
u0=-4.13.13-300.fc27.armv7hl

loadfdt=load ${devtype} ${bootpart} ${fdtaddr} dtb${u0}/${fdtfile}

loadramdisk=load ${devtype} ${bootpart} ${rdaddr} uInitrd${u0}

loadimage=load ${devtype} ${bootpart} ${loadaddr} vmlinuz${u0}

##fdt addr ${fdtaddr}

### CBB-Serial :
#fdt set d_can1 status okay
#fdt set d_can0 status okay
#fdt set serial1 status disable
#fdt set serial2 status okay
#fdt set i2c2 status disable
#fdt set serial4 status okay

uenvcmd=run loadimage; run loadramdisk; run loadfdt; fdt addr ${fdtaddr} ; fdt 
set d_can1 status okay ; fdt set d_can0 status okay ; fdt set serial1 status 
disable ; fdt set serial2 status okay ; fdt set i2c2 status disable ; fdt set 
serial4 status okay ; setenv bootargs ro root=UUID=${uuid}; bootz ${loadaddr} 
${rdaddr} ${fdtaddr}

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


Re: [U-Boot] [PATCH V2] imx: mx7: psci: add system reset support

2018-01-07 Thread Anson Huang


Best Regards!
Anson Huang


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 6:48 AM
> To: Anson Huang 
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Christian Gmeiner ; Peng Fan
> ; U-Boot-Denx 
> Subject: Re: [U-Boot] [PATCH V2] imx: mx7: psci: add system reset support
> 
> Hi Anson,
> 
> On Fri, Jan 5, 2018 at 4:25 AM, Anson Huang  wrote:
> 
> > Thanks for the comments, the current reboot command works is just
> > because wdog driver is enabled and when system reboot, the reboot
> > notification callback in wdog driver will do reset. But if wdog is
> > disabled in dtb, the reboot command will fail.
> >
> > As now we use PSCI, the reboot operation will eventually call into
> > u-boot's psci reset callback, we should support this feature, the
> > reboot feature in Linux kernel should NOT depends on wdog's existence.
> 
> Ok, but what about erratum e10574 (Watchdog: A watchdog timeout or
> software trigger will not reset the SOC)?
> 
> According to this erratum WDOG_B pin needs to generate a system power on.

Correct, we need to enable WDA to toggle WDOG_B for reset, thanks.
Will send a V3 patch set.

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


Re: [U-Boot] [PATCH V2 1/3] mx7_common: use psci 1.0 instead of 0.1

2018-01-07 Thread Anson Huang


Best Regards!
Anson Huang


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 12:05 AM
> To: Anson Huang 
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Troy Kisky ; Christian Gmeiner
> ; Peng Fan ; U-Boot-
> Denx 
> Subject: Re: [U-Boot] [PATCH V2 1/3] mx7_common: use psci 1.0 instead of 0.1
> 
> Hi Anson,
> 
> On Sat, Jan 6, 2018 at 12:17 AM, Anson Huang  wrote:
> > Use PSCI 1.0 instead of 0.1 to support more power management feature
> > like system reset, power off etc..
> >
> > Signed-off-by: Anson Huang 
> 
> Thanks for this patch series.
> 
> Do you also plan to add suspend/resume support for i.MX7 via PSCI.
> 
> Thanks


Yes, I plan to add suspend/resume & cpu-idle support for i.MX7 vis PSCI soon, 
will do it step
by step.

Anson.

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


Re: [U-Boot] [PATCH V2] imx: mx7: psci: add system reset support

2018-01-07 Thread Anson Huang


Best Regards!
Anson Huang


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018-01-07 6:48 AM
> To: Anson Huang 
> Cc: Stefano Babic ; Fabio Estevam
> ; Albert ARIBAUD ;
> Christian Gmeiner ; Peng Fan
> ; U-Boot-Denx 
> Subject: Re: [U-Boot] [PATCH V2] imx: mx7: psci: add system reset support
> 
> Hi Anson,
> 
> On Fri, Jan 5, 2018 at 4:25 AM, Anson Huang  wrote:
> 
> > Thanks for the comments, the current reboot command works is just
> > because wdog driver is enabled and when system reboot, the reboot
> > notification callback in wdog driver will do reset. But if wdog is
> > disabled in dtb, the reboot command will fail.
> >
> > As now we use PSCI, the reboot operation will eventually call into
> > u-boot's psci reset callback, we should support this feature, the
> > reboot feature in Linux kernel should NOT depends on wdog's existence.
> 
> Ok, but what about erratum e10574 (Watchdog: A watchdog timeout or
> software trigger will not reset the SOC)?
> 
> According to this erratum WDOG_B pin needs to generate a system power on.

What should we do here? Writing 0x4 into WCR register will cause WDOG reset
and WDOG_B will be asserted, if the board has WDOG_B connected to PMIC, then
everything is right. Do you mean we need to handle the case of WDOG_B pin NOT
connected to PMIC case? If the board has no such design, then the reset will be
NOT safe using wdog.

Anson 

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


[U-Boot] [PATCH V3 1/3] mx7_common: use psci 1.0 instead of 0.1

2018-01-07 Thread Anson Huang
Use PSCI 1.0 instead of 0.1 to support more power
management feature like system reset, power off etc..

Signed-off-by: Anson Huang 
---
 include/configs/mx7_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index 16e4d95..7861712 100644
--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -62,6 +62,8 @@
 
 #define CONFIG_ARMV7_SECURE_BASE   0x0090
 
+#define CONFIG_ARMV7_PSCI_1_0
+
 /* Secure boot (HAB) support */
 #ifdef CONFIG_SECURE_BOOT
 #define CONFIG_CSF_SIZE0x2000
-- 
1.9.1

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


[U-Boot] [PATCH V3 2/3] imx: mx7: psci: add system reset support

2018-01-07 Thread Anson Huang
Add i.MX7 PSCI system reset support, linux
kernel can use "reboot" command to reset
system even wdog driver is disabled in kernel.

Signed-off-by: Anson Huang 
---
 arch/arm/mach-imx/mx7/psci-mx7.c | 15 ++-
 arch/arm/mach-imx/mx7/psci.S |  7 +++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index 7f429b0..b26be89 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
 #define GPC_CPU_PGC_SW_PDN_REQ 0xfc
 #define GPC_CPU_PGC_SW_PUP_REQ 0xf0
@@ -26,6 +26,9 @@
 #define BP_SRC_A7RCR0_A7_CORE_RESET0   0
 #define BP_SRC_A7RCR1_A7_CORE1_ENABLE  1
 
+#define CCM_ROOT_WDOG  0xbb80
+#define CCM_CCGR_WDOG1 0x49c0
+
 static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset)
 {
writel(enable, GPC_IPS_BASE_ADDR + offset);
@@ -74,3 +77,13 @@ __secure int imx_cpu_off(int cpu)
writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
return 0;
 }
+
+__secure void imx_system_reset(void)
+{
+   struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
+
+   /* make sure WDOG1 clock is enabled */
+   writel(0x1 << 28, CCM_BASE_ADDR + CCM_ROOT_WDOG);
+   writel(0x3, CCM_BASE_ADDR + CCM_CCGR_WDOG1);
+   writew(WCR_WDE, &wdog->wcr);
+}
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
index fc5eb34..e23db24 100644
--- a/arch/arm/mach-imx/mx7/psci.S
+++ b/arch/arm/mach-imx/mx7/psci.S
@@ -43,4 +43,11 @@ psci_cpu_off:
 1: wfi
b 1b
 
+.globl psci_system_reset
+psci_system_reset:
+   bl  imx_system_reset
+
+2: wfi
+   b 2b
+
.popsection
-- 
1.9.1

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


[U-Boot] [PATCH V3 3/3] imx: mx7: psci: add system power off support

2018-01-07 Thread Anson Huang
Add i.MX7 PSCI system power off support, linux
kernel can use "poweroff" command to power off
system via SNVS, PMIC power will be disabled.

Signed-off-by: Anson Huang 
---
 arch/arm/mach-imx/mx7/psci-mx7.c | 18 ++
 arch/arm/mach-imx/mx7/psci.S |  7 +++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index b26be89..d5db511 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -26,6 +26,12 @@
 #define BP_SRC_A7RCR0_A7_CORE_RESET0   0
 #define BP_SRC_A7RCR1_A7_CORE1_ENABLE  1
 
+#define SNVS_LPCR  0x38
+#define BP_SNVS_LPCR_DP_EN 0x20
+#define BP_SNVS_LPCR_TOP   0x40
+
+#define CCM_CCGR_SNVS  0x4250
+
 #define CCM_ROOT_WDOG  0xbb80
 #define CCM_CCGR_WDOG1 0x49c0
 
@@ -87,3 +93,15 @@ __secure void imx_system_reset(void)
writel(0x3, CCM_BASE_ADDR + CCM_CCGR_WDOG1);
writew(WCR_WDE, &wdog->wcr);
 }
+
+__secure void imx_system_off(void)
+{
+   u32 val;
+
+   /* make sure SNVS clock is enabled */
+   writel(0x3, CCM_BASE_ADDR + CCM_CCGR_SNVS);
+
+   val = readl(SNVS_BASE_ADDR + SNVS_LPCR);
+   val |= BP_SNVS_LPCR_DP_EN | BP_SNVS_LPCR_TOP;
+   writel(val, SNVS_BASE_ADDR + SNVS_LPCR);
+}
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
index e23db24..bc2cd8a 100644
--- a/arch/arm/mach-imx/mx7/psci.S
+++ b/arch/arm/mach-imx/mx7/psci.S
@@ -50,4 +50,11 @@ psci_system_reset:
 2: wfi
b 2b
 
+.globl psci_system_off
+psci_system_off:
+   bl  imx_system_off
+
+3: wfi
+   b 3b
+
.popsection
-- 
1.9.1

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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-07 Thread Anand Moon
Hi Lukasz,

On 3 January 2018 at 14:08, Lukasz Majewski  wrote:
> Hi Anand,
>
>> Hi Lukasz
>>
>> On 3 January 2018 at 03:47, Lukasz Majewski  wrote:
>> > On Wed, 3 Jan 2018 01:54:57 +0530
>> > Anand Moon  wrote:
>> >
>> >> Hi All,
>> >>
>> >> I would like to get the s2mps11 regulator binding for u-boot to
>> >> work on Odroid XU3/XU4
>> >> as in case of Odroid U3 we have max77686_bind function which dose
>> >> the job.
>> >>
>> >> what will be the correct way to reset s2mps11 control register to
>> >> the default values
>> >> in-order to support reset of some regulators.
>> >>
>> >> Below is the command I tried to gather some information but it
>> >> failed.
>> >>
>> >> Best Regards
>> >> -Anand Moon
>> >> -
>> >> U-Boot 2018.01-rc3-00060-g1314bd1 (Jan 02 2018 - 17:56:26 +)
>> >> for ODROID-XU3/XU4/HC1
>> >>
>> >> CPU:   Exynos5422 @ 800 MHz
>> >> Model: Odroid XU3 based on EXYNOS5422
>> >> Board: Odroid XU3 based on EXYNOS5422
>> >> Type:  xu4
>> >> DRAM:  2 GiB
>> >> MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
>> >> *** Warning - bad CRC, using default environment
>> >>
>> >> In:serial
>> >> Out:   serial
>> >> Err:   serial
>> >> Net:   No ethernet found.
>> >> Hit any key to stop autoboot:  0
>> >> Card did not respond to voltage select!
>> >> mmc_init: -95, time 11
>> >> switch to partitions #0, OK
>> >> mmc0 is current device
>> >> Scanning mmc 0:1...
>> >> reading /exynos5422-odroidxu4.dtb
>> >> 62815 bytes read in 9 ms (6.7 MiB/s)
>> >> starting USB...
>> >> USB0:   USB EHCI 1.00
>> >> USB1:   Register 2000140 NbrPorts 2
>> >> Starting the controller
>> >> USB XHCI 1.00
>> >> USB2:   Register 2000140 NbrPorts 2
>> >> Starting the controller
>> >> USB XHCI 1.00
>> >> scanning bus 0 for devices... 1 USB Device(s) found
>> >> scanning bus 1 for devices... 3 USB Device(s) found
>> >> scanning bus 2 for devices... 2 USB Device(s) found
>> >>scanning usb for storage devices... 0 Storage Device(s)
>> >> found scanning usb for ethernet devices... 1 Ethernet Device(s)
>> >> found Waiting for Ethernet connection... done.
>> >> BOOTP broadcast 1
>> >> BOOTP broadcast 2
>> >> DHCP client bound to address 10.0.0.144 (1200 ms)
>> >> *** Warning: no boot file name; using '0A90.img'
>> >> Using r8152#0 device
>> >> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> >> through gateway 10.0.0.1
>> >> Filename '0A90.img'.
>> >> Load address: 0x43e0
>> >> Loading: *
>> >> TFTP error: 'File not found' (1)
>> >> Not retrying...
>> >> missing environment variable: pxeuuid
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A90
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A9
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A000
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A00
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A0
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0A
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/0
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/default-arm-exynos
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/default-arm
>> >> *** ERROR: `serverip' not set
>> >> missing environment variable: bootfile
>> >> Retrieving file: pxelinux.cfg/default
>> >> *** ERROR: `serverip' not set
>> >> Config file not found
>> >> BOOTP broadcast 1
>> >> DHCP client bound to address 10.0.0.144 (644 ms)
>> >> Using r8152#0 device
>> >> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> >> through gateway 10.0.0.1
>> >> Filename 'boot.scr.uimg'.
>> >> Load address: 0x5000
>> >> Loading: *
>> >> TFTP error: 'File not found' (1)
>> >> Not retrying...
>> >> BOOTP broadcast 1
>> >> BOOTP broadcast 2
>> >> DHCP client bound to address 10.0.0.144 (1257 ms)
>> >> Using r8152#0 device
>> >> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> >> through gateway 10.0.0.1
>> >> Filename 'boot.scr.uimg'.
>> >> Load address: 0x4200
>> >> Loading: *
>> >> TFTP error: 'File not found' (1)
>> >> Not retrying...
>> >> ODROID-XU3 #
>> >> ODROID-XU3 #
>> >> ODROID-XU3 # pmic s2mps11 dump
>> >> pmic -  operations
>> >>
>> >> Usage:
>> >> pmic list  - list pmic devices
>> >> pmic dev [name]- show or [se

[U-Boot] [PATCH] rpi_0_w: Add configs consistent with RpI3

2018-01-07 Thread drew . moseley
From: Drew Moseley 

CONFIG_OF_EMBED in particular is needed to allow the Raspberry Pi
firmware to pass the DTB to U-Boot and on to the kernel.

Signed-off-by: Drew Moseley 
---
 configs/rpi_0_w_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 9a6d24b..1248294 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -12,14 +12,21 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_OF_EMBED=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
+CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
 CONFIG_DM_ETH=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
+CONFIG_USB_DWC2=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_DM_VIDEO=y
 CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
-- 
2.7.4

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


Re: [U-Boot] [PATCH v6 01/11] wait_bit: add big endian version of wait_for_bit function

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> This is needed for reading registers that are not aligned to 32 bits.
>
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  v6: Introduce changes suggested by Jagan Teki:
>  - Switch to wait_for_bit instead of infinite loop.
>
>  include/wait_bit.h | 44 
>  1 file changed, 44 insertions(+)
>
> diff --git a/include/wait_bit.h b/include/wait_bit.h
> index 06ad43a122..47891fa75c 100644
> --- a/include/wait_bit.h
> +++ b/include/wait_bit.h
> @@ -69,5 +69,49 @@ static inline int wait_for_bit(const char *prefix, const 
> u32 *reg,
> return -ETIMEDOUT;
>  }
>
> +#define BUILD_WAIT_FOR_BIT(sfx, type, read)\
> +   \
> +static inline int wait_for_bit_##sfx(const char *prefix,   \
> +const u32 *reg,\
> +const type mask,   \
> +const bool set,\
> +const unsigned int timeout_ms, \
> +const bool breakable)  \
> +{  \
> +   type val;   \
> +   unsigned long start = get_timer(0); \
> +   \
> +   while (1) { \
> +   val = read(reg);\
> +   \
> +   if (!set)   \
> +   val = ~val; \
> +   \
> +   if ((val & mask) == mask)   \
> +   return 0;   \
> +   \
> +   if (get_timer(start) > timeout_ms)  \
> +   break;  \
> +   \
> +   if (breakable && ctrlc()) { \
> +   puts("Abort\n");\
> +   return -EINTR;  \
> +   }   \
> +   \
> +   udelay(1);  \
> +   WATCHDOG_RESET();   \
> +   }   \
> +   \
> +   debug("%s: Timeout (reg=%p mask=%x wait_set=%i)\n", prefix, \
> + reg, mask, set);  \
> +   \
> +   return -ETIMEDOUT;  \
> +}
> +
> +BUILD_WAIT_FOR_BIT(8, u8, readb)
> +BUILD_WAIT_FOR_BIT(le16, u16, readw)
> +BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
> +BUILD_WAIT_FOR_BIT(le32, u32, readl)

look like existing wait_for_bit is of this type, better add these
macros to existing code and update wait_for_bit from callers if less
changes or add macro to redirect wait_for_bit_le32 but I prefer first
one because this even need to update in future.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v6 04/11] dm: spi: add BCM63xx SPI driver

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver is a simplified version of linux/drivers/spi/spi-bcm63xx.c
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Simon Glass 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 05/11] mips: bmips: add bcm63xx-spi driver support for BCM6338

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 06/11] mips: bmips: add bcm63xx-spi driver support for BCM6348

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 07/11] mips: bmips: add bcm63xx-spi driver support for BCM6358

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 

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


Re: [U-Boot] [PATCH v6 08/11] mips: bmips: add bcm63xx-spi driver support for BCM3380

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver manages the SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 09/11] mips: bmips: add bcm63xx-spi driver support for BCM63268

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> This driver manages the low speed SPI controller present on this SoC.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 11/11] mips: bmips: enable the SPI flash on the Netgear CG3100D

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> It's a Spansion (s25fl064a) 8 MB SPI flash.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


Re: [U-Boot] [PATCH v6 10/11] mips: bmips: enable the SPI flash on the Sagem F@ST1704

2018-01-07 Thread Jagan Teki
On Wed, Jan 3, 2018 at 12:31 AM, Álvaro Fernández Rojas
 wrote:
> It's a Winbond (w25x32) 4 MB SPI flash.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> ---

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


[U-Boot] [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation

2018-01-07 Thread Clemens Gruber
The blob_encap and blob_decap functions were not flushing the dcache
before passing data to CAAM/DMA and not invalidating the dcache when
getting data back.
Therefore, blob encapsulation and decapsulation failed with errors like
the following due to data cache incoherency:
"4006: DECO: desc idx 0: Invalid KEY command"

To ensure coherency, we require the key_mod, src and dst buffers to be
aligned to the cache line size and flush/invalidate the memory regions.
The same requirements apply to the job descriptor.

Tested on an i.MX6Q board.

Signed-off-by: Clemens Gruber 
---

Changes since v2:
- Removed copying to aligned buffers and require addresses to be aligned
- Added function comments and notes about the alignment requirements
- Added parentheses around BLOB_SIZE macro parameter x
- Adapted commit text

Changes since v1:
- Moved BLOB_SIZE define to be available for all platforms (Fabio)

 drivers/crypto/fsl/fsl_blob.c | 103 --
 include/fsl_sec.h |   4 +-
 2 files changed, 91 insertions(+), 16 deletions(-)

diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
index 38c6f9486b..cb315dfd89 100644
--- a/drivers/crypto/fsl/fsl_blob.c
+++ b/drivers/crypto/fsl/fsl_blob.c
@@ -7,63 +7,138 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "jobdesc.h"
 #include "desc.h"
 #include "jr.h"
 
+/**
+ * blob_decap() - Decapsulate the data from a blob
+ * @key_mod:- Key modifier address
+ * @src:- Source address (blob)
+ * @dst:- Destination address (data)
+ * @len:- Size of decapsulated data
+ *
+ * Note: Start and end of the key_mod, src and dst buffers have to be aligned 
to
+ * the cache line size (ARCH_DMA_MINALIGN) for the CAAM operation to succeed.
+ *
+ * Returns zero on success, negative on error.
+ */
 int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
 {
-   int ret, i = 0;
+   int ret, size, i = 0;
u32 *desc;
 
+   if (!IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN) ||
+   !IS_ALIGNED((uintptr_t)src, ARCH_DMA_MINALIGN) ||
+   !IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
+   puts("Error: blob_decap: Address arguments are not aligned!\n");
+   return -EINVAL;
+   }
+
printf("\nDecapsulating blob to get data\n");
-   desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE);
+   desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
if (!desc) {
debug("Not enough memory for descriptor allocation\n");
-   return -1;
+   return -ENOMEM;
}
 
+   size = ALIGN(16, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)key_mod,
+  (unsigned long)key_mod + size);
+
+   size = ALIGN(BLOB_SIZE(len), ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)src,
+  (unsigned long)src + size);
+
inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len);
 
debug("Descriptor dump:\n");
for (i = 0; i < 14; i++)
debug("Word[%d]: %08x\n", i, *(desc + i));
+
+   size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)desc,
+  (unsigned long)desc + size);
+
ret = run_descriptor_jr(desc);
 
-   if (ret)
-   printf("Error in Decapsulation %d\n", ret);
-   else
-   printf("Decapsulation Success\n");
+   if (ret) {
+   printf("Error in blob decapsulation: %d\n", ret);
+   } else {
+   size = ALIGN(len, ARCH_DMA_MINALIGN);
+   invalidate_dcache_range((unsigned long)dst,
+   (unsigned long)dst + size);
+
+   puts("Blob decapsulation successful.\n");
+   }
 
free(desc);
return ret;
 }
 
+/**
+ * blob_encap() - Encapsulate the data as a blob
+ * @key_mod:- Key modifier address
+ * @src:- Source address (data)
+ * @dst:- Destination address (blob)
+ * @len:- Size of data to be encapsulated
+ *
+ * Note: Start and end of the key_mod, src and dst buffers have to be aligned 
to
+ * the cache line size (ARCH_DMA_MINALIGN) for the CAAM operation to succeed.
+ *
+ * Returns zero on success, negative on error.
+ */
 int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
 {
-   int ret, i = 0;
+   int ret, size, i = 0;
u32 *desc;
 
+   if (!IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN) ||
+   !IS_ALIGNED((uintptr_t)src, ARCH_DMA_MINALIGN) ||
+   !IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
+   puts("Error: blob_encap: Address arguments are not aligned!\n");
+   return -EINVAL;
+   }
+
printf("\nEncapsulating data to form blob\n");
-   desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE);
+   desc = malloc_cache_aligned(sizeof(int) * MAX

[U-Boot] [PATCH 1/1] efi_loader: allocate correct memory type for EFI image

2018-01-07 Thread Heinrich Schuchardt
The category of memory allocated for an EFI image should depend on
its type (application, bootime service driver, runtime service driver).

Our helloworld.efi built on arm64 has an illegal image type. Treat it
like an EFI application.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_image_loader.c | 64 ---
 1 file changed, 40 insertions(+), 24 deletions(-)

diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index af29cc4f04..63d71e0d96 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -73,6 +73,40 @@ void __weak invalidate_icache_all(void)
/* If the system doesn't support icache_all flush, cross our fingers */
 }
 
+/*
+ * Determine the memory types to be used for code and data.
+ *
+ * @loaded_image_info  image descriptor
+ * @image_type field Subsystem of the optional header for
+ * Windows specific field
+ */
+static void efi_set_code_and_data_type(
+   struct efi_loaded_image *loaded_image_info,
+   uint16_t image_type)
+{
+   switch (image_type) {
+   case IMAGE_SUBSYSTEM_EFI_APPLICATION:
+   loaded_image_info->image_code_type = EFI_LOADER_CODE;
+   loaded_image_info->image_data_type = EFI_LOADER_DATA;
+   break;
+   case IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER:
+   loaded_image_info->image_code_type = EFI_BOOT_SERVICES_CODE;
+   loaded_image_info->image_data_type = EFI_BOOT_SERVICES_DATA;
+   break;
+   case IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER:
+   case IMAGE_SUBSYSTEM_SAL_RUNTIME_DRIVER:
+   loaded_image_info->image_code_type = EFI_RUNTIME_SERVICES_CODE;
+   loaded_image_info->image_data_type = EFI_RUNTIME_SERVICES_DATA;
+   break;
+   default:
+   printf("%s: invalid image type: %u\n", __func__, image_type);
+   /* Let's assume it is an application */
+   loaded_image_info->image_code_type = EFI_LOADER_CODE;
+   loaded_image_info->image_data_type = EFI_LOADER_DATA;
+   break;
+   }
+}
+
 /*
  * This function loads all sections from a PE binary into a newly reserved
  * piece of memory. On successful load it then returns the entry point for
@@ -94,7 +128,6 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
unsigned long virt_size = 0;
bool can_run_nt64 = true;
bool can_run_nt32 = true;
-   uint16_t image_type;
 
 #if defined(CONFIG_ARM64)
can_run_nt32 = false;
@@ -131,7 +164,9 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
image_size = opt->SizeOfImage;
-   efi_reloc = efi_alloc(virt_size, EFI_LOADER_DATA);
+   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
+   efi_reloc = efi_alloc(virt_size,
+ loaded_image_info->image_code_type);
if (!efi_reloc) {
printf("%s: Could not allocate %lu bytes\n",
   __func__, virt_size);
@@ -140,12 +175,13 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
-   image_type = opt->Subsystem;
} else if (can_run_nt32 &&
   (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
{
IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
image_size = opt->SizeOfImage;
-   efi_reloc = efi_alloc(virt_size, EFI_LOADER_DATA);
+   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
+   efi_reloc = efi_alloc(virt_size,
+ loaded_image_info->image_code_type);
if (!efi_reloc) {
printf("%s: Could not allocate %lu bytes\n",
   __func__, virt_size);
@@ -154,32 +190,12 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
-   image_type = opt->Subsystem;
} else {
printf("%s: Invalid optional header magic %x\n", __func__,
   nt->OptionalHeader.Magic);
return NULL;
}
 
-   switch (image_type) {
-   case IMAGE_SUBSYSTEM_EFI_APPLICATION:
-   loaded_image_info->image_code

Re: [U-Boot] [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation

2018-01-07 Thread Tom Rini
On Sun, Jan 07, 2018 at 08:26:29PM +0100, Clemens Gruber wrote:

> The blob_encap and blob_decap functions were not flushing the dcache
> before passing data to CAAM/DMA and not invalidating the dcache when
> getting data back.
> Therefore, blob encapsulation and decapsulation failed with errors like
> the following due to data cache incoherency:
> "4006: DECO: desc idx 0: Invalid KEY command"
> 
> To ensure coherency, we require the key_mod, src and dst buffers to be
> aligned to the cache line size and flush/invalidate the memory regions.
> The same requirements apply to the job descriptor.
> 
> Tested on an i.MX6Q board.
> 
> Signed-off-by: Clemens Gruber 

This has passed Travis-CI here, and I will apply it directly if there's
no objections, 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] "fdt" commands in extlinux.conf ?

2018-01-07 Thread Peter Robinson
On Sun, Jan 7, 2018 at 4:04 AM, Ken Harris  wrote:
> I'd like to enable the CANbus on a Beagle Bone Black (on Fedora ...
> which doesn't do "cape manager").

Well Fedora doesn't so stuff that's not upstream, and while there's
been a bunch of discussion there's been no decision upstream of how
best to do overlay management.

> The crux is a fdt command in u-boot :
>
> fdt set d_can1 status okay
>
> Is there a way to do this in extlinux.conf ?

You could probably load an overlay and save the environment? Dealing
with this better in Fedora is on my
 todo list to get to eventually.

> I didn't see a way (in uboot 2017.09), so I wrote a uEnv.txt script
> (see attached).
>
> That's a bit verbose and duplicates a bunch of stuff already in uboot
> (also : uEnv.txt doesn't exist on my "Orange Pi One").
>
> It there a simpler way to state "fdt" commands ?
>
> Thanks
>
> ___
> 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 v2] x86: Move commands from under arch/x86 to cmd/x86/

2018-01-07 Thread Bin Meng
On Wed, Jan 3, 2018 at 9:54 PM, Tom Rini  wrote:
> We only need to compile and link these files when building for full
> U-Boot.  Move them to under cmd/x86/ to make sure they aren't linked in
> and undiscarded due to u_boot_list_2_cmd_* being included).
>
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Format patch with -M
> - Drop 'cmd_' from the new file name (and checked file content for now
>   erroneous cmd in comments, none found).
>
>  arch/x86/lib/Makefile   | 1 -
>  arch/x86/lib/fsp/Makefile   | 1 -
>  cmd/Makefile| 2 ++
>  cmd/x86/Makefile| 6 ++
>  arch/x86/lib/fsp/cmd_fsp.c => cmd/x86/fsp.c | 0
>  arch/x86/lib/cmd_mtrr.c => cmd/x86/mtrr.c   | 0
>  6 files changed, 8 insertions(+), 2 deletions(-)
>  create mode 100644 cmd/x86/Makefile
>  rename arch/x86/lib/fsp/cmd_fsp.c => cmd/x86/fsp.c (100%)
>  rename arch/x86/lib/cmd_mtrr.c => cmd/x86/mtrr.c (100%)
>

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


Re: [U-Boot] [PATCH 1/1] configs: x86: allow to override CONFIG_BOOTCOMMAND

2018-01-07 Thread Bin Meng
On Wed, Jan 3, 2018 at 11:23 PM, Heinrich Schuchardt  wrote:
> Allow to override CONFIG_BOOTCOMMAND in .config.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/configs/x86-common.h | 2 ++
>  1 file changed, 2 insertions(+)
>

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


[U-Boot] [PATCH] ARM: mvebu: correct reference for "ethernet1" on DB-88F6820-AMC

2018-01-07 Thread Chris Packham
The DB-88F6820-AMC connects ethernet@34000 and ethernet@7 which are
labeled as eth2 and eth0 in armada-38x.dts. The ethernet@3 (eth1) is
not used on the AMC board.

This eliminates the following bootup message

  Device 'ethernet@7': seq 0 is in use by 'ethernet@34000'

Signed-off-by: Chris Packham 
---

 arch/arm/dts/armada-385-amc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-385-amc.dts b/arch/arm/dts/armada-385-amc.dts
index 5e1588d57438..d4d127fa024b 100644
--- a/arch/arm/dts/armada-385-amc.dts
+++ b/arch/arm/dts/armada-385-amc.dts
@@ -53,7 +53,7 @@
 
aliases {
ethernet0 = ð0;
-   ethernet1 = ð1;
+   ethernet1 = ð2;
i2c0 = &i2c0;
spi1 = &spi1;
};
-- 
2.15.1

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


Re: [U-Boot] [PATCH v1 1/2] x86: tangier: Use actual GPIO hardware numbers

2018-01-07 Thread Bin Meng
On Fri, Jan 5, 2018 at 12:40 AM, Andy Shevchenko
 wrote:
> The recent commit 03c4749dd6c7
>   ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
> in the Linux kernel reveals the issue we have in ACPI tables here,
> i.e. we must use hardware numbers for GPIO resources and,
> taking into consideration that GPIO and pin control are *different* IPs
> on Intel Tangier, we need to supply numbers properly.
>
> Besides that, it improves user experience since the official documentation
> for Intel Edison board is referring to GPIO hardware numbering scheme.
>
> Signed-off-by: Andy Shevchenko 
> ---
>
> Bin, this is kinda urgent fix. I wouldn't like to have a release with
> wrong numbering scheme, although there is none users yet, only couple
> amateurs that are experimenting with the code.
>
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

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


Re: [U-Boot] [PATCH v1 2/2] x86: tangier: Add Bluetooth to ACPI table

2018-01-07 Thread Bin Meng
On Fri, Jan 5, 2018 at 12:40 AM, Andy Shevchenko
 wrote:
> As defined on reference board followed by Intel Edison a Bluetooth
> device is attached to HSU0, i.e. PCI :04.1.
>
> Describe it in ACPI accordingly.
>
> Note, we use BCM2E95 ID here as one most suitable for such device based
> on the description in commit message of commit 89ab37b489d1
> ("Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96")
> in the Linux kernel source tree.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../include/asm/arch-tangier/acpi/southcluster.asl | 51 
> ++
>  1 file changed, 51 insertions(+)
>

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


Re: [U-Boot] [PATCH 01/16] efi_selftest: colored test output

2018-01-07 Thread Simon Glass
Hi Heinrich,

On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Add color coding to output:
> test sectionblue
> success green
> errors  red
> todoyellow
> summary white
> others  light gray
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_selftest.h  | 27 +--
>  lib/efi_selftest/efi_selftest.c | 25 ++---
>  lib/efi_selftest/efi_selftest_console.c | 13 +
>  3 files changed, 40 insertions(+), 25 deletions(-)

Reviewed-by: Simon Glass 

comments below

>
> diff --git a/include/efi_selftest.h b/include/efi_selftest.h
> index be5ba4bfa9..344f28ed36 100644
> --- a/include/efi_selftest.h
> +++ b/include/efi_selftest.h
> @@ -18,14 +18,20 @@
>  #define EFI_ST_SUCCESS 0
>  #define EFI_ST_FAILURE 1
>
> +/*
> + * Prints a message.
> + */
> +#define efi_st_printf(...) \
> +   (efi_st_printc(-1, __VA_ARGS__))
> +
>  /*
>   * Prints an error message.
>   *
>   * @...format string followed by fields to print
>   */
>  #define efi_st_error(...) \
> -   (efi_st_printf("%s(%u):\nERROR: ", __FILE__, __LINE__), \
> -   efi_st_printf(__VA_ARGS__)) \
> +   (efi_st_printc(EFI_LIGHTRED, "%s(%u):\nERROR: ", __FILE__, __LINE__), 
> \
> +   efi_st_printc(EFI_LIGHTRED, __VA_ARGS__))
>
>  /*
>   * Prints a TODO message.
> @@ -33,8 +39,8 @@
>   * @...format string followed by fields to print
>   */
>  #define efi_st_todo(...) \
> -   (efi_st_printf("%s(%u):\nTODO: ", __FILE__, __LINE__), \
> -   efi_st_printf(__VA_ARGS__)) \
> +   (efi_st_printc(EFI_YELLOW, "%s(%u):\nTODO: ", __FILE__, __LINE__), \
> +   efi_st_printc(EFI_YELLOW, __VA_ARGS__)) \
>
>  /*
>   * A test may be setup and executed at boottime,
> @@ -61,14 +67,15 @@ extern struct efi_simple_input_interface *con_in;
>  void efi_st_exit_boot_services(void);
>
>  /*
> - * Print a pointer to an u16 string
> + * Print a colored message
>   *
> - * @pointer: pointer
> - * @buf: pointer to buffer address
> - * on return position of terminating zero word
> + * @color  color

Can you please point to the enum to use? Also it seems like -1 means
no colour? That should bementioned also

> + * @fmtprintf format
> + * @...arguments to be printed
> + * on return position of terminating zero word
>   */
> -void efi_st_printf(const char *fmt, ...)
> -__attribute__ ((format (__printf__, 1, 2)));
> +void efi_st_printc(int color, const char *fmt, ...)
> +__attribute__ ((format (__printf__, 2, 3)));
>
>  /*
>   * Compare memory.
> diff --git a/lib/efi_selftest/efi_selftest.c b/lib/efi_selftest/efi_selftest.c
> index 4e5a12c47c..fc5ef254a1 100644
> --- a/lib/efi_selftest/efi_selftest.c
> +++ b/lib/efi_selftest/efi_selftest.c
> @@ -65,7 +65,7 @@ void efi_st_exit_boot_services(void)
> efi_st_error("ExitBootServices did not return EFI_SUCCESS\n");
> return;
> }
> -   efi_st_printf("\nBoot services terminated\n");
> +   efi_st_printc(EFI_WHITE, "\nBoot services terminated\n");
>  }
>
>  /*
> @@ -81,13 +81,14 @@ static int setup(struct efi_unit_test *test, unsigned int 
> *failures)
>
> if (!test->setup)
> return EFI_ST_SUCCESS;
> -   efi_st_printf("\nSetting up '%s'\n", test->name);
> +   efi_st_printc(EFI_LIGHTBLUE, "\nSetting up '%s'\n", test->name);
> ret = test->setup(handle, systable);
> if (ret != EFI_ST_SUCCESS) {
> efi_st_error("Setting up '%s' failed\n", test->name);
> ++*failures;
> } else {
> -   efi_st_printf("Setting up '%s' succeeded\n", test->name);
> +   efi_st_printc(EFI_LIGHTGREEN,
> + "Setting up '%s' succeeded\n", test->name);
> }
> return ret;
>  }
> @@ -105,13 +106,14 @@ static int execute(struct efi_unit_test *test, unsigned 
> int *failures)
>
> if (!test->execute)
> return EFI_ST_SUCCESS;
> -   efi_st_printf("\nExecuting '%s'\n", test->name);
> +   efi_st_printc(EFI_LIGHTBLUE, "\nExecuting '%s'\n", test->name);
> ret = test->execute();
> if (ret != EFI_ST_SUCCESS) {
> efi_st_error("Executing '%s' failed\n", test->name);
> ++*failures;
> } else {
> -   efi_st_printf("Executing '%s' succeeded\n", test->name);
> +   efi_st_printc(EFI_LIGHTGREEN,
> + "Executing '%s' succeeded\n", test->name);
> }
> return ret;
>  }
> @@ -129,13 +131,14 @@ static int teardown(struct efi_unit_test *test, 
> unsigned int *failures)
>
> if (!test->teardown)
> return EFI_ST_SUCCESS;
> -   efi_st_printf("\nTearing down '%s'\n", test->name);
> +   efi_st_printc(EFI_LIGHTBLUE, "\nTearing down '%s'\n", test->name);
> ret = test->teardown

Re: [U-Boot] [PATCH 02/16] efi_loader: simplify efi_remove_all_protocols

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Replace list_for_each_safe() and list_entry() by
> list_for_each_entry_safe().
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

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


Re: [U-Boot] [PATCH 03/16] efi_selftest: do not try to close device path protocol

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> CloseProtocol cannot be called without agent handle.
>
> There is no need to close the device path protocol if
> it has been opened without agent handle.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_selftest/efi_selftest_devicepath.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

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


Re: [U-Boot] [PATCH 04/16] efi_loader: list of open protocol infos

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Add a list of open protocol infos to each protocol of a handle.
>
> Provide helper functions to access the list items.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  | 15 ++-
>  lib/efi_loader/efi_boottime.c | 35 +++
>  2 files changed, 49 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 07/16] efi_loader: implement OpenProtocolInformation

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> efi_open_protocol_information provides the agent and controller
> handles as well as the attributes and open count of an protocol
> on a handle.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 41 -
>  1 file changed, 40 insertions(+), 1 deletion(-)


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


Re: [U-Boot] [PATCH 05/16] efi_loader: open_info in OpenProtocol

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> efi_open_protocol has to keep track of opened protocols.
>
> OpenProtocol enters the agent and controller handle
> information into this list.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 107 
> --
>  1 file changed, 103 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

Would be good to mention that the test for this code comes later.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 06/16] efi_loader: open_info in CloseProtocol

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> efi_open_protocol and efi_close_protocol have to keep track of
> opened protocols.
>
> Check if the protocol was opened for the same agent and
> controller.
>
> Remove all open protocol information for this pair.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 09/16] efi_loader: implement ConnectController

2018-01-07 Thread Simon Glass
Hi Heinrick,

On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Implement the ConnectController boot service.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h |  22 ++
>  include/efi_loader.h  |   2 +
>  lib/efi_loader/efi_boottime.c | 178 
> --
>  3 files changed, 178 insertions(+), 24 deletions(-)

Reviewed-by: Simon Glass 

Please see below. Also please mention when tests come for these.

>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 46963f2891..81e580dbbc 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -805,4 +805,26 @@ struct efi_file_info {
> s16 file_name[0];
>  };
>
> +#define EFI_DRIVER_BINDING_PROTOCOL_GUID \
> +   EFI_GUID(0x18a031ab, 0xb443, 0x4d1a,\
> +0xa5, 0xc0, 0x0c, 0x09, 0x26, 0x1e, 0x9f, 0x71)
> +struct efi_driver_binding_protocol {
> +   efi_status_t (EFIAPI * supported)(
> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   struct efi_device_path *remaining_device_path);
> +   efi_status_t (EFIAPI * start)(
> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   struct efi_device_path *remaining_device_path);
> +   efi_status_t (EFIAPI * stop)(
> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   efi_uintn_t number_of_children,
> +   efi_handle_t *child_handle_buffer);
> +   u32 version;
> +   efi_handle_t image_handle;
> +   efi_handle_t driver_binding_handle;
> +};
> +
>  #endif
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 637e6e166d..9e1ae8866b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -88,6 +88,8 @@ uint16_t *efi_dp_str(struct efi_device_path *dp);
>  extern const efi_guid_t efi_global_variable_guid;
>  extern const efi_guid_t efi_guid_console_control;
>  extern const efi_guid_t efi_guid_device_path;
> +/* GUID of the EFI_DRIVER_BINDING_PROTOCOL */
> +extern const efi_guid_t efi_guid_driver_binding_protocol;
>  extern const efi_guid_t efi_guid_loaded_image;
>  extern const efi_guid_t efi_guid_device_path_to_text_protocol;
>  extern const efi_guid_t efi_simple_file_system_protocol_guid;
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index b5d6808bf7..6cc0659eb9 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -56,6 +56,9 @@ static volatile void *efi_gd, *app_gd;
>
>  static int entry_count;
>  static int nesting_level;
> +/* GUID of the EFI_DRIVER_BINDING_PROTOCOL */
> +const efi_guid_t efi_guid_driver_binding_protocol =
> +   EFI_DRIVER_BINDING_PROTOCOL_GUID;
>
>  /* Called on every callback entry */
>  int __efi_entry_check(void)
> @@ -1619,30 +1622,6 @@ static efi_status_t EFIAPI 
> efi_set_watchdog_timer(unsigned long timeout,
> return EFI_EXIT(efi_set_watchdog(timeout));
>  }
>
> -/*
> - * Connect a controller to a driver.
> - *
> - * This function implements the ConnectController service.
> - * See the Unified Extensible Firmware Interface (UEFI) specification
> - * for details.
> - *
> - * @controller_handle  handle of the controller
> - * @driver_image_handlehandle of the driver
> - * @remain_device_path device path of a child controller
> - * @recursive  true to connect all child controllers
> - * @return status code
> - */
> -static efi_status_t EFIAPI efi_connect_controller(
> -   efi_handle_t controller_handle,
> -   efi_handle_t *driver_image_handle,
> -   struct efi_device_path *remain_device_path,
> -   bool recursive)
> -{
> -   EFI_ENTRY("%p, %p, %p, %d", controller_handle, driver_image_handle,
> - remain_device_path, recursive);
> -   return EFI_EXIT(EFI_NOT_FOUND);
> -}
> -
>  /*
>   * Disconnect a controller from a driver.
>   *
> @@ -2352,6 +2331,157 @@ static efi_status_t EFIAPI efi_handle_protocol(void 
> *handle,
>  NULL, EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);
>  }
>
> +static efi_status_t efi_bind_controller(
> +   efi_handle_t controller_handle,
> +   efi_handle_t driver_image_handle,
> +   struct efi_device_path *remain_device_path)
> +{
> +   struct efi_driver_binding_protocol *binding_protocol;
> +   efi_status_t r;
> +
> +   r = EFI_CALL(efi_open_protocol(driver_image_handle,
> +  &efi_guid_driver_binding_protocol,
> +  (void **)&binding_protocol,
> +  driver_image_handle, NULL,
> +   

Re: [U-Boot] [PATCH 11/16] efi_loader: implement DisconnectController

2018-01-07 Thread Simon Glass
Hi Heinrich,

On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Unfortunately we need a forward declaration because both
> OpenProtocol and CloseProtocol have to call DisconnectController.
> And DisconnectController calls both OpenProtcol and CloseProtocol.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 283 
> ++
>  1 file changed, 261 insertions(+), 22 deletions(-)

Reviewed-by: Simon Glass 

I think it would be good to reduce the length of some of the identifies.

e.g. numbers_of_children -> child_count or num_children

It's just too verbose for U-Boot IMO.

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


Re: [U-Boot] [PATCH 08/16] efi_loader: debug output installed device path

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> When a device path protocol is installed write the device
> path to the console in debug mode.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 7 +++
>  1 file changed, 7 insertions(+)

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


Re: [U-Boot] [PATCH 15/16] efi_selftest: test for (Dis)ConnectController

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> This unit test checks the following protocol services:
> ConnectController, DisconnectController,
> InstallProtocol, UninstallProtocol,
> OpenProtocol, CloseProtcol, OpenProtocolInformation
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_selftest/Makefile   |   1 +
>  lib/efi_selftest/efi_selftest_controllers.c | 385 
> 
>  2 files changed, 386 insertions(+)
>  create mode 100644 lib/efi_selftest/efi_selftest_controllers.c

Reviewed-by: Simon Glass 

Again I think some identifiers should be shorter.

The EFI_SUCCESS thing shows up again, i.e. instead of

return 0;
if (ret)

we do:

return EFI_SUCCESS;
if (ret != EFI_SUCCESS)

which to me is an obfuscation. The error code indicates an error, and
is 0 if there is no error, which is the normal case. This is how
U-Boot works in general and I would prefer that the EFI code followed
that.

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


Re: [U-Boot] [PATCH 10/16] efi_loader: fix signature of efi_disconnect_controller

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> Handles should be passed as efi_handle_t and not as void *.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h | 6 --
>  lib/efi_loader/efi_boottime.c | 7 ---
>  2 files changed, 8 insertions(+), 5 deletions(-)

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


Re: [U-Boot] [PATCH 14/16] efi_selftest: remove todo in device path test

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> The installation of UninstallProtocol is functional now.
> So we do not expect errors when calling it.
>
> Call UninstallProtocol with correct level of indirection
> for parameter handle.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_selftest/efi_selftest_devicepath.c | 40 
> +++---
>  1 file changed, 25 insertions(+), 15 deletions(-)

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


Re: [U-Boot] [PATCH 12/16] efi_loader: disconnect controllers in UninstallProtocol

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> The UninstallProtocol boot service should first try to
> disconnect controllers that have been connected with
> EFI_OPEN_PROTOCOL_BY_DRIVER.
>
> If the protocol is still opened by an agent, it should be
> closed.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 29 +++--
>  1 file changed, 23 insertions(+), 6 deletions(-)

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


Re: [U-Boot] [PATCH 13/16] efi_selftest: remove todo in manage protocols

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> The installation of UninstallProtocols is functional now.
> So we do not expect errors when calling it.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_selftest/efi_selftest_manageprotocols.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

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


Re: [U-Boot] [PATCH 16/16] efi_loader: consistently use efi_handle_t for handles

2018-01-07 Thread Simon Glass
On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:
> We should consistently use the efi_handle_t typedef when
> referring to handles.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/bootefi.c | 10 -
>  include/efi_api.h | 20 ++
>  include/efi_loader.h  | 14 +++--
>  lib/efi_loader/efi_boottime.c | 49 
> +++
>  lib/efi_loader/efi_console.c  |  6 +++---
>  5 files changed, 53 insertions(+), 46 deletions(-)
>

Reviewed-by: Simon Glass 

[...]

> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 98497db612..56b079cee8 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -503,21 +503,21 @@ int efi_console_register(void)
> struct efi_object *efi_console_input_obj;
>
> /* Create handles */
> -   r = efi_create_handle((void **)&efi_console_control_obj);
> +   r = efi_create_handle((efi_handle_t *)&efi_console_control_obj);

How come we need this cast?

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


Re: [U-Boot] [PATCH 3/4] ARMv8: Allow dynamic early stack pointer

2018-01-07 Thread Simon Glass
Hi Stephen,

On 19 December 2017 at 18:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> U-Boot typically uses a hard-coded value for the stack pointer before
> relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
> the initial SP at run-time. This is useful to avoid hard-coding addresses
> into U-Boot, so that can be loaded and executed at arbitrary addresses and
> thus avoid using arbitrary addresses at runtime. This option's value is
> the offset added to &_bss_start in order to calculate the stack pointer.
> This offset should be large enough so that the early malloc region, global
> data (gd), and early stack usage do not overlap any appended DTB.

I don't see why this is an offset from bss_start - shouldn't it be bss_end?

Also this seems error-prone since we don't know how large the DTB is.
Can we improve this, e.g. by:

- using binman to provide the stack start value or offset
- checking the DTB size and automatically using the address
immediately after it finishes (again I suppose binman could provide
that)

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


Re: [U-Boot] [PATCH 2/4] ARM: tegra: remove SPL config for non-SPL SoCs

2018-01-07 Thread Simon Glass
On 19 December 2017 at 18:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> No 64-bit Tegra uses SPL. Remove various unused definitions from config
> headers.
>
> Signed-off-by: Stephen Warren 
> ---
>  include/configs/tegra-common.h| 2 ++
>  include/configs/tegra186-common.h | 5 -
>  include/configs/tegra210-common.h | 5 -
>  3 files changed, 2 insertions(+), 10 deletions(-)

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


Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

2018-01-07 Thread Jason Rush
On 1/7/2018 5:39 AM, Marek Vasut wrote:
> On 01/06/2018 10:09 PM, Jason Rush wrote:
>> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>>> On 01/06/2018 07:46 PM, Jason Rush wrote:
 On 1/6/2018 9:42 AM, Marek Vasut wrote:
>> 
>>
 There was a minor upstream change to one of the files since I submitted v4 
 of my
 cadence device-tree patchset, so I rebased and resent the patchset as a 
 v5.  I
 included everyone that was originally involved with the patches and added 
 a CC
 for Marek.

 This is only the patchset for the device tree changes for the cadence qspi 
 driver,
 Simon will still have to add the patch that fixes the cache invalidation 
 bug in the
 cadence driver.
>>> Sigh, can we get a single patchset out which fixes the problem ?
>>>
>>> I mean, if I understand this correctly, you're all addressing one single
>>> problem, but with two patchsets, yes ?
>>>
>> Well... The one issue we're trying to fix is that the cadence QSPI hasn't 
>> worked on
>> the socfpga arch since late 2016.  However, it's two different issues that 
>> have caused
>> this bigger problem:
>>
>> 1. The indaddrtrig register was being programmed with an incorrect value for 
>> socfpga
>> as the result of assuming it should be programmed with the same address as 
>> the
>> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, 
>> which has
>> an independent setting for the indaddrtrig register so the register can be 
>> set correctly
>> on all architectures.  Plus it aligns the DT between u-boot and Linux.
> That should be an easy patch, so this is the patchset 0/5..5/5 that you
> just submitted ?
Yes. I saw you Acked it, thank you.
>> 2. The cadence driver was modified at one point to use the bouncebuf 
>> functions to fix
>> an issue on a TI architecture that expected, where if I recall correctly all 
>> reads except
>> the last have to be 32-bit reads.  However, since the bouncebuf was designed 
>> for DMA
>> transfers, it invalidates the data cache after reading, but since the 
>> cadence is using cpu
>> transfers the newly read data is thrown away when the cache is invalidated.  
>> This issue
>> is resolved by reverting the commit that introduced using the bounce buffer 
>> for read
>> operations, which according to Vignesh don't cause any issues to the TI 
>> architecture.
> Hm, I wonder why you need bounce buffer at all here. The CQSPI
> literally reads/writes a register space (or some FIFO in register
> space), there is no DMA involved at all. I also wonder why we have to
> manipulate with cache at all here.

I agree, I don't believe this needs a bounce buffer at all.  This isn't a DMA, 
there is
no need for cache manipulation.  Vignesh understands the problem better than I 
do
on the TI platform, but I believe it was used since it was an easy way to 
ensure the
register read/writes were all 32-bits wide up until the last read/write.  I 
believe the
bounce buffer should be removed from the CQSPI driver and a different solution
should be implemented, but Vignesh should weigh in on that since it effects his
architecture.

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


Re: [U-Boot] [PATCH 4/4] ARM: tegra: use CONFIG_SYS_INIT_SP_BSS_OFFSET

2018-01-07 Thread Simon Glass
On 19 December 2017 at 18:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Enable CONFIG_SYS_INIT_SP_BSS_OFFSET for all 64-bit Tegra boards. Place
> the stack/... 512KiB from the end of the U-Boot binary. This should be
> plenty to accommodate the current DTBs (max 64 KiB), early malloc region
> (6KiB), stack usage, and plenty of slack, while still not placing it too
> far away from the U-Boot binary.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/tegra186/Kconfig | 3 +++
>  arch/arm/mach-tegra/tegra210/Kconfig | 3 +++
>  include/configs/tegra-common.h   | 2 ++
>  include/configs/tegra186-common.h| 5 -
>  include/configs/tegra210-common.h| 5 -
>  5 files changed, 8 insertions(+), 10 deletions(-)

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


Re: [U-Boot] [PATCH v10 23/27] board_r: initialize spi_nor

2018-01-07 Thread Simon Glass
Hi Jagan,

On 27 December 2017 at 23:12, Jagan Teki  wrote:
> initialize spi-nor framework during boot, so-that detected
> buses can appears at boot log.
>
> Signed-off-by: Suneel Garapati 
> Signed-off-by: Jagan Teki 
> ---
>  common/board_r.c | 13 +
>  drivers/mtd/spi-nor/spi-nor-uclass.c | 17 +
>  include/linux/mtd/spi-nor.h  |  1 +
>  3 files changed, 31 insertions(+)
>

We should rely on driver model to init this when it is first probed,
so this should not be needed.

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


Re: [U-Boot] [PATCH v3 1/1] vsprintf.c: add EFI device path printing

2018-01-07 Thread Simon Glass
On 26 December 2017 at 03:07, Heinrich Schuchardt  wrote:
> For debugging efi_loader we need the capability to print EFI
> device paths. With this patch we can write:
>
> debug("device path: %pD", dp);
>
> A possible output would be
>
> device path: /MemoryMapped(0x0,0x3ff93a82,0x3ff93a82)
>
> This enhancement is not available when building without EFI support
> and neither in the SPL nor in the API example.
>
> Cc: Wolfgang Denk 
> Cc: Simon Glass 
> Suggested-by: Rob Clark 
> Signed-off-by: Heinrich Schuchardt 
> ---
> I propose Alex picks up this patch for the EFI tree.
>
> v3:
> Return -ENOMEM if out of memory.
> Avoid missing dependency error when building the SPL of the
> API example.
> v2:
> Panic if out of memory.
> Wolfgang suggested not to silently ignore an out of memory
> situation.
> ---
>  examples/api/Makefile |  3 +++
>  lib/vsprintf.c| 47 +--
>  2 files changed, 44 insertions(+), 6 deletions(-)

Can you please add a test for this? It could go in the print unit
tests, perhaps?

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


Re: [U-Boot] [PATCH 1/9] fit: Fix CONFIG_FIT_SPL_PRINT

2018-01-07 Thread Simon Glass
On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Rename CONFIG_FIT_SPL_PRINT to CONFIG_SPL_FIT_PRINT and add Kconfig
> entry for it.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  Kconfig| 6 ++
>  README | 2 +-
>  common/image-fit.c | 4 ++--
>  3 files changed, 9 insertions(+), 3 deletions(-)

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


Re: [U-Boot] [PATCH 2/9] fit: Add empty fit_print_contents() and fit_image_print()

2018-01-07 Thread Simon Glass
On 28 December 2017 at 05:06, Marek Vasut  wrote:
> These functions may be needed in SPL, so add empty variants of them
> if CONFIG_SPL_FIT_PRINT is disabled.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/image-fit.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 3/9] fit: Add standalone image type handling

2018-01-07 Thread Simon Glass
On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Just add IH_TYPE_STANDALONE to fit_get_image_type_property().
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/image-fit.c | 2 ++
>  include/image.h| 1 +
>  2 files changed, 3 insertions(+)

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


Re: [U-Boot] [PATCH 4/9] fit: Verify all configuration signatures

2018-01-07 Thread Simon Glass
On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Rather than verifying configuration signature of the configuration node
> containing the kernel image types, verify all configuration nodes, even
> those that do not contain kernel images. This is useful when the nodes
> contain ie. standalone OSes or U-Boot.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/image-fit.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index 8871e2dcd3..f559032691 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1766,22 +1766,24 @@ int fit_image_load(bootm_headers_t *images, ulong 
> addr,
> }
> fit_base_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
> printf("   Using '%s' configuration\n", 
> fit_base_uname_config);
> -   if (image_type == IH_TYPE_KERNEL) {
> -   /* Remember (and possibly verify) this config */
> +   /* Remember this config */
> +   if (image_type == IH_TYPE_KERNEL)
> images->fit_uname_cfg = fit_base_uname_config;
> -   if (IMAGE_ENABLE_VERIFY && images->verify) {
> -   puts("   Verifying Hash Integrity ... ");
> -   if (fit_config_verify(fit, cfg_noffset)) {
> -   puts("Bad Data Hash\n");
> -   bootstage_error(bootstage_id +
> -   BOOTSTAGE_SUB_HASH);
> -   return -EACCES;
> -   }
> -   puts("OK\n");
> +
> +   /* Verify this config */
> +   if (IMAGE_ENABLE_VERIFY && images->verify) {
> +   puts("   Verifying Hash Integrity ... ");
> +   if (fit_config_verify(fit, cfg_noffset)) {
> +   puts("Bad Data Hash\n");
> +   bootstage_error(bootstage_id +
> +   BOOTSTAGE_SUB_HASH);
> +   return -EACCES;
> }
> -   bootstage_mark(BOOTSTAGE_ID_FIT_CONFIG);
> +   puts("OK\n");

What is this for? Doesn't the above function print the hash type or an error?

> }
>
> +   bootstage_mark(BOOTSTAGE_ID_FIT_CONFIG);
> +
> noffset = fit_conf_get_prop_node(fit, cfg_noffset,
>  prop_name);
> fit_uname = fit_get_name(fit, noffset, NULL);
> --
> 2.15.0
>

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


Re: [U-Boot] [PATCH 5/9] spl: Add full fitImage support

2018-01-07 Thread Simon Glass
Hi Marek,

On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Add support for loading U-Boot and optionally FDT from a fitImage
> in SPL by using the full fitImage support from U-Boot. While we do
> have limited SPL loading support in SPL with a small footprint, it
> is missing a lot of important features, like checking signatures.
> This support has all the fitImage features, while the footprint is
> obviously larger.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  Kconfig  | 11 +++
>  common/spl/spl.c | 43 +++
>  2 files changed, 54 insertions(+)
>
> diff --git a/Kconfig b/Kconfig
> index cd32096f21..4d0c1a01c1 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -293,6 +293,17 @@ config SPL_LOAD_FIT
>   particular it can handle selecting from multiple device tree
>   and passing the correct one to U-Boot.
>
> +config SPL_LOAD_FIT_FULL
> +   bool "Enable SPL loading U-Boot as a FIT"
> +   select SPL_FIT
> +   help
> + Normally with the SPL framework a legacy image is generated as part
> + of the build. This contains U-Boot along with information as to
> + where it should be loaded. This option instead enables generation

generation? Do you mean loading?

> + of a FIT (Flat Image Tree) which provides more flexibility. In
> + particular it can handle selecting from multiple device tree

trees

> + and passing the correct one to U-Boot.

Can you reword this to mention the 'limited' FIT support in SPL, and
how to enable that. There needs to be a cross-reference between the
two in the docs.

> +
>  config SPL_FIT_IMAGE_POST_PROCESS
> bool "Enable post-processing of FIT artifacts after loading by the 
> SPL"
> depends on SPL_LOAD_FIT
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 76c1963611..d429ea2c82 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -139,9 +139,52 @@ void spl_set_header_raw_uboot(struct spl_image_info 
> *spl_image)
> spl_image->name = "U-Boot";
>  }
>
> +#ifdef CONFIG_SPL_LOAD_FIT_FULL
> +/* Parse and load full fitImage in SPL */
> +static int spl_load_fit_image(struct spl_image_info *spl_image,
> + const struct image_header *header)
> +
> +{
> +   bootm_headers_t images;
> +   const char *fit_uname_config = NULL;
> +   const char *fit_uname_fdt = FIT_FDT_PROP;
> +   ulong fw_data = 0, dt_data = 0;
> +   ulong fw_len = 0, dt_len = 0;
> +   int ret;
> +
> +   ret = fit_image_load(&images, (ulong)header,
> +NULL, &fit_uname_config,
> +IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
> +FIT_LOAD_REQUIRED, &fw_data, &fw_len);
> +   if (ret < 0)
> +   return ret;
> +
> +   spl_image->size = fw_len;
> +   spl_image->entry_point = fw_data;
> +   spl_image->load_addr = fw_data;
> +   spl_image->os = IH_OS_U_BOOT;
> +   spl_image->name = "U-Boot";
> +
> +   debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
> +   (int)sizeof(spl_image->name), spl_image->name,
> +   spl_image->load_addr, spl_image->size);
> +
> +   ret = fit_image_load(&images, (ulong)header,
> +&fit_uname_fdt, &fit_uname_config,
> +IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
> +FIT_LOAD_OPTIONAL, &dt_data, &dt_len);
> +   return 0;
> +}
> +#endif
> +
>  int spl_parse_image_header(struct spl_image_info *spl_image,
>const struct image_header *header)
>  {
> +#ifdef CONFIG_SPL_LOAD_FIT_FULL

Can you use if (IS_ENABLED()) and thus avoid the #ifdef above?

> +   int ret = spl_load_fit_image(spl_image, header);
> +   if (!ret)
> +   return ret;
> +#endif
> if (image_get_magic(header) == IH_MAGIC) {
>  #ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT
> u32 header_size = sizeof(struct image_header);
> --
> 2.15.0
>

Is there a test for this code?

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


Re: [U-Boot] [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation

2018-01-07 Thread Sumit Garg
> -Original Message-
> From: Clemens Gruber [mailto:clemens.gru...@pqgruber.com]
> Sent: Monday, January 08, 2018 12:56 AM
> To: York Sun 
> Cc: u-boot@lists.denx.de; Fabio Estevam ; Tom Rini
> ; Vini Pillai ; Ruchika Gupta
> ; Breno Matheus Lima ;
> Fabio Estevam ; Sumit Garg ;
> Arun Pathak ; Jaiprakash Singh
> ; Clemens Gruber
> 
> Subject: [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation
> 
> The blob_encap and blob_decap functions were not flushing the dcache
> before passing data to CAAM/DMA and not invalidating the dcache when
> getting data back.
> Therefore, blob encapsulation and decapsulation failed with errors like the
> following due to data cache incoherency:
> "4006: DECO: desc idx 0: Invalid KEY command"
> 
> To ensure coherency, we require the key_mod, src and dst buffers to be
> aligned to the cache line size and flush/invalidate the memory regions.
> The same requirements apply to the job descriptor.
> 
> Tested on an i.MX6Q board.
> 
> Signed-off-by: Clemens Gruber 
> ---
> 
> Changes since v2:
> - Removed copying to aligned buffers and require addresses to be aligned
> - Added function comments and notes about the alignment requirements
> - Added parentheses around BLOB_SIZE macro parameter x
> - Adapted commit text
> 
> Changes since v1:
> - Moved BLOB_SIZE define to be available for all platforms (Fabio)
> 

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


Re: [U-Boot] [PATCH 6/9] spl: Add support for overlaying U-Boot DT

2018-01-07 Thread Simon Glass
Hi Marek,

On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Add support for loading fitImage with device tree overlay image, which
> is applied to the U-Boot's own device tree. Once the DT is applied, the
> fitImage loading process is restarted.
>
> This patch allows a usecase where the DTO patches ie. load address in
> the U-Boot's DT or patches in a new public key for authenticating the
> subsequently loaded fitImages.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl.c | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
>

This needs a test.

> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index d429ea2c82..2444abbb08 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -140,6 +140,38 @@ void spl_set_header_raw_uboot(struct spl_image_info 
> *spl_image)
>  }
>
>  #ifdef CONFIG_SPL_LOAD_FIT_FULL
> +#ifdef CONFIG_OF_LIBFDT_OVERLAY

Can we avoid this by doing

if (IS_ENABLED(...))

below?

> +static int spl_fit_overlay_uboot_fdt_full(const struct image_header *header)
> +{
> +   bootm_headers_t images;
> +   const char *fit_uname_config = NULL;
> +   const char *fit_uname_dtbo = "u-boot-dtbo";
> +   ulong dto_data = 0;
> +   ulong dto_len = 0;
> +   int ret;
> +
> +   ret = fit_image_load(&images, (ulong)header,
> +&fit_uname_dtbo, &fit_uname_config,
> +IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
> +FIT_LOAD_OPTIONAL, &dto_data, &dto_len);
> +   if (ret < 0)
> +   return 0;
> +
> +   ret = fdt_overlay_apply_verbose((struct fdt_header *)gd->fdt_blob,
> +   (void *)dto_data);
> +   if (ret)
> +   hang();
> +
> +   /* Restart the loading process to cater for the DT changes */
> +   return -EAGAIN;
> +}
> +#else
> +static int spl_fit_overlay_uboot_fdt_full(const struct image_header *header)
> +{
> +   return 0;
> +}
> +#endif
> +
>  /* Parse and load full fitImage in SPL */
>  static int spl_load_fit_image(struct spl_image_info *spl_image,
>   const struct image_header *header)
> @@ -152,6 +184,10 @@ static int spl_load_fit_image(struct spl_image_info 
> *spl_image,
> ulong fw_len = 0, dt_len = 0;
> int ret;
>
> +   ret = spl_fit_overlay_uboot_fdt_full(header);
> +   if (ret)
> +   return ret;
> +
> ret = fit_image_load(&images, (ulong)header,
>  NULL, &fit_uname_config,
>  IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
> @@ -182,7 +218,7 @@ int spl_parse_image_header(struct spl_image_info 
> *spl_image,
>  {
>  #ifdef CONFIG_SPL_LOAD_FIT_FULL
> int ret = spl_load_fit_image(spl_image, header);
> -   if (!ret)
> +   if (!ret || ret == -EAGAIN)
> return ret;
>  #endif
> if (image_get_magic(header) == IH_MAGIC) {
> --
> 2.15.0
>

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


Re: [U-Boot] [PATCH 8/9] spl: ram: Add support for fetching image position from control DT

2018-01-07 Thread Simon Glass
Hi Marek,

On 28 December 2017 at 05:06, Marek Vasut  wrote:
> Add support for fetching the image position in RAM from control DT
> rather than hard-coding it. While doing so, return the return value
> of spl_parse_header_image() to make it possible to test application
> of DTOs on U-Boot's control DT.
>
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl_ram.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)

Should this use the binman support instead? It seems to already do
what you want.

If not, this should have docs and a test.

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


Re: [U-Boot] [PATCH 9/9] spl: spi: Add support for fetching image position from control DT

2018-01-07 Thread Simon Glass
Hi Marek,

On 28 December 2017 at 07:29, Lukasz Majewski  wrote:
> Hi Marek,
>
>> Add support for fetching the image position in RAM from control DT
>> rather than hard-coding it. While doing so, return the return value
>> of spl_parse_header_image() to make it possible to test application
>> of DTOs on U-Boot's control DT.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Pantelis Antoniou 
>> Cc: Simon Glass 
>> ---
>>  common/spl/spl_spi.c | 13 +
>>  1 file changed, 13 insertions(+)

See comments on previous patch about using binman / adding docs/test.

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


Re: [U-Boot] [PATCH 0/8] mmc: some fixes for core and add HS200 support for sdhci-cadence

2018-01-07 Thread Simon Glass
On 29 December 2017 at 10:00, Masahiro Yamada
 wrote:
> This series can be cleanly applied to u-boot-mmc/next.
>
> I really hope the HS200 support will be pulled in the next MW.

Yes please, it has been too long.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] cmd: go: Make do_go available to outside boot.c

2018-01-07 Thread Simon Glass
Hi Emmanuel,

On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
> Some commands (like sysboot) might want to call go as they can encounter
> a raw binary.
> Make do_go callable for everyone.
>
> Signed-off-by: Emmanuel Vadot 
> ---
>  cmd/boot.c| 2 +-
>  include/command.h | 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)

Can we instead move the code out of do_go() into another function
which accepts C arguments, and then call that from do_go()?

>
> diff --git a/cmd/boot.c b/cmd/boot.c
> index 72f2cf362d..5691c5f883 100644
> --- a/cmd/boot.c
> +++ b/cmd/boot.c
> @@ -22,7 +22,7 @@ unsigned long do_go_exec(ulong (*entry)(int, char * const 
> []), int argc,
> return entry (argc, argv);
>  }
>
> -static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
> ulong   addr, rc;
> int rcode = 0;
> diff --git a/include/command.h b/include/command.h
> index 767cabb3df..377e2eadd4 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -105,6 +105,10 @@ extern int do_bootz(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[]);
>
>  extern int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
>
> +#ifdef CONFIG_CMD_GO
> +extern int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
> +#endif
> +
>  extern int common_diskboot(cmd_tbl_t *cmdtp, const char *intf, int argc,
>char *const argv[]);
>
> --
> 2.15.1
>

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


Re: [U-Boot] [PATCH 1/8] dm: add dev_read_u32()

2018-01-07 Thread Simon Glass
Hi Masahiro,

On 29 December 2017 at 10:00, Masahiro Yamada
 wrote:
> dev_read_u32_default() always returns something even when the property
> is missing.  So, it is impossible to do nothing in the case.  One
> solution is to use ofnode_read_u32() instead, but adding dev_read_u32()
> will be helpful.
>
> BTW, Linux has an equvalent function, device_property_read_u32();
> it is clearer that it reads a property.  I cannot understand the
> behavior of dev_read_u32() from its name.

I decided that 'property' was an unnecessary word since there is
nothing else you can ready a value from in the DT.

>
> Signed-off-by: Masahiro Yamada 
> ---
>
> BTW, I do not understand why we want *_default helpers.
> It is pretty easy to do equivalent without _default.
>
>   priv->val = default;/* default in case property is missing */
>   dev_read_u32(dev, "foo-property", &priv->val);
>

Your example explains it. Instead, we can do:

priv->val = dev_read_u32_default(dev,"foo-property", default);

which is simpler to understand and does not need a comment.

> On the other hand, if we want to do nothing for missing property,
> we will end up with clumsy code.
>
>   /* we do not want to overwrite priv->val if property is missing */
>   if (dev_read_bool(dev, "foo-property") {
>  /* default value '0' will not be used anyway */
>  priv->val = dev_read_u32_default(dev, "foo-property", 0);
>   }

priv->val = dev_read_u32_default(dev,"foo-property", priv->val);

>
> One more BTW, it was just painful to write equivalent code twice
> for CONFIG_DM_DEV_READ_INLINE.

This helps reduce code size for the case where we don't use livetree
(SPL). Any ideas on how to make it easier?

>
>
>  drivers/core/read.c |  5 +
>  include/dm/read.h   | 16 
>  2 files changed, 21 insertions(+)

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


Re: [U-Boot] [PATCH 2/2] sysboot: Call bootm booti bootz then go on label_boot

2018-01-07 Thread Simon Glass
Hi Emmanuel,

On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
> As do_bootm/do_booti/do_bootz will not return if the boot succeded, always
> call them if enable by the config.
> Also add a fallback to go if the binary is a raw one.

Do we not know which type of binary it is? It seems like we should
have some error checking here.

>
> Signed-off-by: Emmanuel Vadot 
> ---
>  cmd/pxe.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/pxe.c b/cmd/pxe.c
> index 7043ad11fd..0ca6a964bc 100644
> --- a/cmd/pxe.c
> +++ b/cmd/pxe.c
> @@ -796,12 +796,14 @@ static int label_boot(cmd_tbl_t *cmdtp, struct 
> pxe_label *label)
> do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
>  #ifdef CONFIG_CMD_BOOTI
> /* Try booting an AArch64 Linux kernel image */
> -   else
> -   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
> -#elif defined(CONFIG_CMD_BOOTZ)
> +   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
> +#endif
> +#if defined(CONFIG_CMD_BOOTZ)
> /* Try booting a Image */
> -   else
> -   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> +   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> +#endif
> +#if defined(CONFIG_CMD_GO)
> +   do_go(cmdtp, 0, bootm_argc, bootm_argv);
>  #endif
> unmap_sysmem(buf);
> return 1;
> --
> 2.15.1
>

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


Re: [U-Boot] [PATCH 2/2] ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER

2018-01-07 Thread Simon Glass
Hi Stephen,

On 2 January 2018 at 16:54, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Enable CONFIG_LINUX_KERNEL_IMAGE_HEADER for all 64-bit Tegra boards.
> cboot (the boot SW that runs before U-Boot) will eventually use this
> information.

How does U-Boot use it? Does it not come from the FIT?

>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> index 51d143687b06..fd0082d22a33 100644
> --- a/arch/arm/mach-tegra/Kconfig
> +++ b/arch/arm/mach-tegra/Kconfig
> @@ -60,8 +60,14 @@ config TEGRA_ARMV7_COMMON
>  config TEGRA_ARMV8_COMMON
> bool "Tegra 64-bit common options"
> select ARM64
> +   select LINUX_KERNEL_IMAGE_HEADER
> select TEGRA_COMMON
>
> +if TEGRA_ARMV8_COMMON
> +config LNX_KRNL_IMG_TEXT_OFFSET_BASE
> +   default 0x8000
> +endif
> +
>  choice
> prompt "Tegra SoC select"
> optional
> --
> 2.15.1
>

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


Re: [U-Boot] [PATCH] GPIO: pca953x: Rework to not include commands in SPL

2018-01-07 Thread Simon Glass
On 3 January 2018 at 07:23, Tom Rini  wrote:
> The command portion of the GPIO driver can only be used in full SPL so
> re-work to guard the command related portions and mark it as static.
>
> Cc: Bin Meng 
> Cc: Simon Glass 
> Cc: Philipp Tomsich 
> Signed-off-by: Tom Rini 
> ---
>  drivers/gpio/pca953x.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

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


Re: [U-Boot] [PATCH 1/3] ARM: Tegra186: mem parsing fixes from downstream

2018-01-07 Thread Simon Glass
On 3 January 2018 at 14:32, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Apply a few small fixes for the DTB /memory node parsing from NVIDIA's
> downstream U-Boot:
>
> - Allow arbitrary number of DRAM banks.
> - Correctly calculate the number of DRAM banks.
> - Clip PCIe memory in the same way as U-Boot CPU memory use.
>
> Signed-off-by: Stephen Warren 
> ---
> This series relies (at the very least for diff context) on the previous
> series I sent Jan 2/3: ARMv8: add optional Linux kernel image header ...
> ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER.
> ---
>  arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)

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


Re: [U-Boot] [PATCH 00/11] Introduce variables whitelisting in environment

2018-01-07 Thread Simon Glass
Hi Quentin,

On 3 January 2018 at 02:18, Quentin Schulz
 wrote:
> Hi Simon,
>
> On 29/12/2017 04:13, Simon Glass wrote:
>> Hi Quentin,
>>
>> On 22 December 2017 at 14:13, Quentin Schulz
>>  wrote:
>>> This patch series is based on this[1] patch series from Maxime.
>>>
>>> This is an RFC. It's been only tested in a specific use case on a custom
>>> i.MX6 board. It's known to break compilation on a few boards.
>>>
>>> I have a use case where we want some variables from a first environment to
>>> be overriden by variables from a second environment. For example, we want
>>> to load variables from the default env (ENV_IS_NOWHERE) and then load only
>>> a handful of other variables from, e.g., NAND.
>>>
>>> In our use case, we basically can be sure that the default env in the
>>> U-Boot binary is secure but we want only a few variables to be modified,
>>> thus keeping control over the overall behaviour of U-Boot in secure mode.
>>>
>>> It works in that way:
>>>   - from highest to lowest priority, the first environment that can be
>>>   loaded (that has successfully init and whose load function has returned
>>>   no errors) will be the main environment,
>>>   - then, all the following environment that could be successfully loaded
>>>   (same conditions as the main environment) are secondary environment. The
>>>   env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and
>>>   in the secondary environments override the ones in the main environment,
>>>   - for saving, we save the whole environment to all environments
>>>   available, be they main or secondary (it does not matter to save the
>>>   whole environment on secondary environments as only the whitelisted
>>>   variables will be overriden in the loading process,
>>>
>>> I have also a few questions that could help me to get the whole thing to
>>> work.
>>>
>>> 1) I can't really get my head around the use of gd->env_addr, what is it 
>>> used
>>> for? It is set in a bunch of different places but only once is it
>>> explicitly used (basically to alternate the env_addr between the one
>>> associated to main and redundant environment (in NAND for example)).
>>>
>>> 2) Why do we consider ENV_IS_NOWHERE an invalid environment? The only place 
>>> I
>>> found a use for it was to just say that if the environment is invalid, we
>>> should set to default environment (in env_relocate in env/common.c). With
>>> my patch series I guess that we could remove this fallback and force
>>> ENV_IS_NOWHERE to be always there.
>>>
>>> 3) There are a few (20) boards that set gd->env_addr and gd->env_valid in
>>> their board file. What is the reason to do such a thing? Isn't those
>>> overriden anyway by the environment driver?
>>>
>>> I'm looking forward to getting your feedback on this patch series.
>>>
>>
>> I certainly understand the goal and it seems generally useful.
>>
>> But I wonder whether this is the best way to implement it.
>>
>> We could have a UCLASS_ENV uclass, with driver-model drivers which
>> load the environment (i.e. have load() and save() methods). Config for
>> the drivers would come from the device tree. Useful drivers would be:
>>
>
> I'm not sure the device tree is the place to set/get such info. That has
> nothing to do with hardware, it's only logic for the bootloader.
>
>> - one that loads the env from a single location
>> - one that loads multiple envs from different locations in priority order
>> - one that does what you want
>>
>> Then people could set their own policy by adding a driver.
>>
>
> I'll have to document myself on driver-model and how U-Boot implement it
> then :)
>
>> I worry that what we have here is quite heavyweight, and will be
>> imposed on all users, e.g. the size increase of gd, the new logic.
>> Where does it end? I think splitting things up into different use
>> cases makes sense.
>>
>
> Agree on that.
>
>> When I did the env refactor I envisaged using driver-model for the
>> post-reloc env load/save at some point in the future. It solves the
>> problem of getting the config (can use device tree) and different
>> boards wanting to do different things (boards can provide an env
>> driver).
>>
>
> Overall, I prefer Lukasz's suggestion as it's quicker and easier to
> implement and require (I think) less changes in the code.

Do you mean selecting from different locations? Yes that is a good
thing, but is orthogonal to this series.

Here you are trying to add functionality which will apply to any env
location, or to them as a whole. So we should think of your change as
implementing a new policy rather than a new env location.

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


Re: [U-Boot] [PATCH 1/1] configs: x86: allow to override CONFIG_BOOTCOMMAND

2018-01-07 Thread Simon Glass
Hi Heinrich,

On 3 January 2018 at 08:23, Heinrich Schuchardt  wrote:
> Allow to override CONFIG_BOOTCOMMAND in .config.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/configs/x86-common.h | 2 ++
>  1 file changed, 2 insertions(+)

This is a Chrome OS boot line. I think you should consider whether it
should move into x86-chromebook.h or similar? Then you can just remove
it from the common file.

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


Re: [U-Boot] [PATCH 3/3] ARM: tegra: p2771-000: increase max DRAM bank count

2018-01-07 Thread Simon Glass
On 3 January 2018 at 14:32, Stephen Warren  wrote:
> From: Stephen Warren 
>
> On this platform, there may be up to 1024 unusable chunks of memory.
> Increase CONFIG_NR_DRAM_BANKS so that U-Boot can remember all the banks
> required to represent such fragmented memory.
>
> Signed-off-by: Stephen Warren 
> ---
>  include/configs/p2771-.h | 3 +++
>  1 file changed, 3 insertions(+)

Ick, that's horrible.

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


Re: [U-Boot] [PATCH 2/3] ARM: Tegra186: search for best RAM bank

2018-01-07 Thread Simon Glass
On 3 January 2018 at 14:32, Stephen Warren  wrote:
> From: Stephen Warren 
>
> In the future, the list of DRAM regions passed to U-Boot in the DTB may
> be quite long and fragmented. Due to this, U-Boot must search through the
> regions to find the best region to relocate into, rather than relying on
> the current assumption that the top of bank 0 is a reasonable relocation
> target. This change implements such searching.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 88 
> +++---
>  1 file changed, 69 insertions(+), 19 deletions(-)

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


Re: [U-Boot] [PATCH v1 1/2] x86: tangier: Use actual GPIO hardware numbers

2018-01-07 Thread Simon Glass
On 4 January 2018 at 09:40, Andy Shevchenko
 wrote:
> The recent commit 03c4749dd6c7
>   ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
> in the Linux kernel reveals the issue we have in ACPI tables here,
> i.e. we must use hardware numbers for GPIO resources and,
> taking into consideration that GPIO and pin control are *different* IPs
> on Intel Tangier, we need to supply numbers properly.
>
> Besides that, it improves user experience since the official documentation
> for Intel Edison board is referring to GPIO hardware numbering scheme.
>
> Signed-off-by: Andy Shevchenko 
> ---
>
> Bin, this is kinda urgent fix. I wouldn't like to have a release with
> wrong numbering scheme, although there is none users yet, only couple
> amateurs that are experimenting with the code.

Reviewed-by: Simon Glass 

>
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: bootm: don't assume sp is in DRAM bank 0

2018-01-07 Thread Simon Glass
On 5 January 2018 at 13:04, Stephen Warren  wrote:
> From: Stephen Warren 
>
> arch_lmb_reserve() currently assumes that the stack pointer is within DRAM
> bank 0. This is not necessarily true. Enhance the code to search through
> DRAM banks until the bank that does contain SP is found, and then reserve
> the tail of that bank.
>
> Fixes: 2d1916e48bd8 ("ARM: add flat device tree support")
> Signed-off-by: Stephen Warren 
> ---
> It would be best to apply this patch before "ARM: Tegra186: search for
> best RAM bank" is applied.
> ---
>  arch/arm/lib/bootm.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

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


Re: [U-Boot] [PATCH] dm: pinctrl: sync with Linux to use pin_config_param

2018-01-07 Thread Simon Glass
+masahiro

On 4 January 2018 at 23:05, Peng Fan  wrote:
> Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6")
> to use enum pin_config_param.
>
> Signed-off-by: Peng Fan 
> ---
>  include/dm/pinctrl.h | 112 
> ++-
>  1 file changed, 66 insertions(+), 46 deletions(-)
>

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


Re: [U-Boot] [PATCH v1 2/2] x86: tangier: Add Bluetooth to ACPI table

2018-01-07 Thread Simon Glass
On 4 January 2018 at 09:40, Andy Shevchenko
 wrote:
> As defined on reference board followed by Intel Edison a Bluetooth
> device is attached to HSU0, i.e. PCI :04.1.
>
> Describe it in ACPI accordingly.
>
> Note, we use BCM2E95 ID here as one most suitable for such device based
> on the description in commit message of commit 89ab37b489d1
> ("Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96")
> in the Linux kernel source tree.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../include/asm/arch-tangier/acpi/southcluster.asl | 51 
> ++
>  1 file changed, 51 insertions(+)

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


Re: [U-Boot] [PATCH 1/1] board_r: remove superfluous #ifdef CONFIG_PRAM

2018-01-07 Thread Simon Glass
On 6 January 2018 at 16:54, Heinrich Schuchardt  wrote:
> initr_mem() is already enclosed by
> #if defined(CONFIG_PRAM)
> #endif
>
> So there is no need to check CONFIG_PRAM again inside the
> function.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/board_r.c | 2 --
>  1 file changed, 2 deletions(-)

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


Re: [U-Boot] [PATCH 12/14] env: Mark env_get_location as weak

2018-01-07 Thread Simon Glass
Hi Maxime,

On 5 January 2018 at 02:29, Maxime Ripard
 wrote:
> Hi Simon,
>
> On Thu, Dec 28, 2017 at 08:13:42PM -0700, Simon Glass wrote:
>> Hi Maxime,
>>
>> On 28 November 2017 at 03:24, Maxime Ripard
>>  wrote:
>> > Allow boards and architectures to override the default environment lookup
>> > code by overriding env_get_location.
>> >
>> > Reviewed-by: Lukasz Majewski 
>> > Signed-off-by: Maxime Ripard 
>> > ---
>> >  env/env.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/env/env.c b/env/env.c
>> > index b4d8886e7a69..9b8b38cf3c2b 100644
>> > --- a/env/env.c
>> > +++ b/env/env.c
>> > @@ -62,7 +62,7 @@ static enum env_location env_locations[] = {
>> >
>> >  static enum env_location env_load_location;
>> >
>> > -static enum env_location env_get_location(enum env_operation op, int prio)
>> > +__weak enum env_location env_get_location(enum env_operation op, int prio)
>>
>> Is it possible instead to make this deterministic, so that the board
>> sets up the location during boot?
>
> I'm not really sure what you mean here. The default implementation is
> deterministic, and the board implementations should make sure that it
> is if it's of any value to them.
>
> Do you want me to add a comment to make that clearer?

I mean that the board presumably knows the location, so could set it
up (perhaps in global_data). Then env_get_location() can use it.

Making functions weak means everything becomes non-deterministic -
e.g. I cannot tell from the code what it is going to do.

>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

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


Re: [U-Boot] [PATCH] config_whitelist: remove false-positive CONFIG options

2018-01-07 Thread Simon Glass
On 5 January 2018 at 11:17, Masahiro Yamada
 wrote:
> U-Boot pulled in several core makefiles from Linux.  The following
> are not used in U-Boot:
>
>   - CONFIG_DEBUG_SECTION_MISMATCH
>   - CONFIG_FTRACE_MCOUNT_RECORD
>   - CONFIG_GCOV_KERNEL
>   - CONFIG_GCOV_PROFILE_ALL
>   - CONFIG_KASAN
>   - CONFIG_MODVERSIONS
>
> We can remove the unused code if we like. (although it will get the
> scripts out of sync)
>
> CONFIG_BOOM and CONFIG_HIS_DRIVER are just mentioned in the comment
> block of scripts/basic/fixdep.c
>
> CONFIG_SHELL is not configuration, but a variable for internal-use.
> It is just a historical misnomer in Kbuild.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/config_whitelist.txt | 9 -
>  1 file changed, 9 deletions(-)

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


Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

2018-01-07 Thread Vignesh R


On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
[...]
>>> 1. The indaddrtrig register was being programmed with an incorrect value 
>>> for socfpga
>>> as the result of assuming it should be programmed with the same address as 
>>> the
>>> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, 
>>> which has
>>> an independent setting for the indaddrtrig register so the register can be 
>>> set correctly
>>> on all architectures.  Plus it aligns the DT between u-boot and Linux.
>> That should be an easy patch, so this is the patchset 0/5..5/5 that you
>> just submitted ?
> Yes. I saw you Acked it, thank you.
>>> 2. The cadence driver was modified at one point to use the bouncebuf 
>>> functions to fix
>>> an issue on a TI architecture that expected, where if I recall correctly 
>>> all reads except
>>> the last have to be 32-bit reads.  However, since the bouncebuf was 
>>> designed for DMA
>>> transfers, it invalidates the data cache after reading, but since the 
>>> cadence is using cpu
>>> transfers the newly read data is thrown away when the cache is invalidated. 
>>>  This issue
>>> is resolved by reverting the commit that introduced using the bounce buffer 
>>> for read
>>> operations, which according to Vignesh don't cause any issues to the TI 
>>> architecture.
>> Hm, I wonder why you need bounce buffer at all here. The CQSPI
>> literally reads/writes a register space (or some FIFO in register
>> space), there is no DMA involved at all. I also wonder why we have to
>> manipulate with cache at all here.
> 
> I agree, I don't believe this needs a bounce buffer at all.  This isn't a 
> DMA, there is
> no need for cache manipulation.  Vignesh understands the problem better than 
> I do
> on the TI platform, but I believe it was used since it was an easy way to 
> ensure the
> register read/writes were all 32-bits wide up until the last read/write.  

Yes, that was the intention. Unfortunately, I chose to use common bounce
buffer implementation which was doing cache manipulations.

> I believe the bounce buffer should be removed from the CQSPI driver and a 
> different solution
> should be implemented, but Vignesh should weigh in on that since it effects 
> his
> architecture.
> 

CQSPI on TI K2G has problems with non 32 bit aligned write operations.
But read operations are unaffected. Therefore I have Ack'ed Simon's
patch reverting bouncebuf for read. For writes, I have patches to revert
common bouncebuf usage and use a local pagesize buffer for overcome
alignment issue. I am waiting for current patch backlogs to be merged so
that its easy for testing w/o specifying bunch of dependent patches.

Or if Simon agrees, I can add his patch to my series post it to mailing
list (rebased on top of Jason's series)?


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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-07 Thread Jaehoon Chung
On 01/08/2018 12:34 AM, Anand Moon wrote:
> Hi Lukasz,
> 
> On 3 January 2018 at 14:08, Lukasz Majewski  wrote:
>> Hi Anand,
>>
>>> Hi Lukasz
>>>
>>> On 3 January 2018 at 03:47, Lukasz Majewski  wrote:
 On Wed, 3 Jan 2018 01:54:57 +0530
 Anand Moon  wrote:

> Hi All,
>
> I would like to get the s2mps11 regulator binding for u-boot to
> work on Odroid XU3/XU4
> as in case of Odroid U3 we have max77686_bind function which dose
> the job.
>
> what will be the correct way to reset s2mps11 control register to
> the default values
> in-order to support reset of some regulators.
>
> Below is the command I tried to gather some information but it
> failed.
>
> Best Regards
> -Anand Moon
> -
> U-Boot 2018.01-rc3-00060-g1314bd1 (Jan 02 2018 - 17:56:26 +)
> for ODROID-XU3/XU4/HC1
>
> CPU:   Exynos5422 @ 800 MHz
> Model: Odroid XU3 based on EXYNOS5422
> Board: Odroid XU3 based on EXYNOS5422
> Type:  xu4
> DRAM:  2 GiB
> MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
> *** Warning - bad CRC, using default environment
>
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select!
> mmc_init: -95, time 11
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /exynos5422-odroidxu4.dtb
> 62815 bytes read in 9 ms (6.7 MiB/s)
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> USB2:   Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 1 for devices... 3 USB Device(s) found
> scanning bus 2 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s)
> found scanning usb for ethernet devices... 1 Ethernet Device(s)
> found Waiting for Ethernet connection... done.
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 10.0.0.144 (1200 ms)
> *** Warning: no boot file name; using '0A90.img'
> Using r8152#0 device
> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
> through gateway 10.0.0.1
> Filename '0A90.img'.
> Load address: 0x43e0
> Loading: *
> TFTP error: 'File not found' (1)
> Not retrying...
> missing environment variable: pxeuuid
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A90
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A9
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A000
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A00
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A0
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0A
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/0
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/default-arm-exynos
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/default-arm
> *** ERROR: `serverip' not set
> missing environment variable: bootfile
> Retrieving file: pxelinux.cfg/default
> *** ERROR: `serverip' not set
> Config file not found
> BOOTP broadcast 1
> DHCP client bound to address 10.0.0.144 (644 ms)
> Using r8152#0 device
> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
> through gateway 10.0.0.1
> Filename 'boot.scr.uimg'.
> Load address: 0x5000
> Loading: *
> TFTP error: 'File not found' (1)
> Not retrying...
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 10.0.0.144 (1257 ms)
> Using r8152#0 device
> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
> through gateway 10.0.0.1
> Filename 'boot.scr.uimg'.
> Load address: 0x4200
> Loading: *
> TFTP error: 'File not found' (1)
> Not retrying...
> ODROID-XU3 #
> ODROID-XU3 #
> ODROID-XU3 # pmic s2mps11 dump
> pmic -  operations
>
> Usage:
> pmic list  - lis

[U-Boot] [PATCH] board/ls2081ard: Correct code to get QMAP value in checkboard

2018-01-07 Thread Priyanka Jain
QMAP value contains information about QSPI chip-selects.
These bits are used to display information of boot device
in checkboard() function.

QMAP value is stored in most significant 3-bits
of 8-bit register brdcfg[0] in Qixis, this patch
corrects code to get QMAP bits using below logic:
(brdcfg[0] >> 5) & 0x7

Signed-off-by: Priyanka Jain 
---
This patch is split version of another patch
https://patchwork.ozlabs.org/patch/803117/

 board/freescale/ls2080ardb/ls2080ardb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index ee0f3a2..34843d7 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -75,7 +75,7 @@ int checkboard(void)
printf("Board version: %c, ", (sw & 0xf) + 'A');
 
sw = QIXIS_READ(brdcfg[0]);
-   sw = (sw & QIXIS_QMAP_MASK) >> QIXIS_QMAP_SHIFT;
+   sw = (sw >> QIXIS_QMAP_SHIFT) & QIXIS_QMAP_MASK;
switch (sw) {
case 0:
puts("boot from QSPI DEV#0\n");
-- 
2.7.4

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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-07 Thread Anand Moon
Hi Jaehoon,

On 8 January 2018 at 11:56, Jaehoon Chung  wrote:
> On 01/08/2018 12:34 AM, Anand Moon wrote:
>> Hi Lukasz,
>>
>> On 3 January 2018 at 14:08, Lukasz Majewski  wrote:
>>> Hi Anand,
>>>
 Hi Lukasz

 On 3 January 2018 at 03:47, Lukasz Majewski  wrote:
> On Wed, 3 Jan 2018 01:54:57 +0530
> Anand Moon  wrote:
>
>> Hi All,
>>
>> I would like to get the s2mps11 regulator binding for u-boot to
>> work on Odroid XU3/XU4
>> as in case of Odroid U3 we have max77686_bind function which dose
>> the job.
>>
>> what will be the correct way to reset s2mps11 control register to
>> the default values
>> in-order to support reset of some regulators.
>>
>> Below is the command I tried to gather some information but it
>> failed.
>>
>> Best Regards
>> -Anand Moon
>> -
>> U-Boot 2018.01-rc3-00060-g1314bd1 (Jan 02 2018 - 17:56:26 +)
>> for ODROID-XU3/XU4/HC1
>>
>> CPU:   Exynos5422 @ 800 MHz
>> Model: Odroid XU3 based on EXYNOS5422
>> Board: Odroid XU3 based on EXYNOS5422
>> Type:  xu4
>> DRAM:  2 GiB
>> MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
>> *** Warning - bad CRC, using default environment
>>
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> Card did not respond to voltage select!
>> mmc_init: -95, time 11
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc 0:1...
>> reading /exynos5422-odroidxu4.dtb
>> 62815 bytes read in 9 ms (6.7 MiB/s)
>> starting USB...
>> USB0:   USB EHCI 1.00
>> USB1:   Register 2000140 NbrPorts 2
>> Starting the controller
>> USB XHCI 1.00
>> USB2:   Register 2000140 NbrPorts 2
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus 0 for devices... 1 USB Device(s) found
>> scanning bus 1 for devices... 3 USB Device(s) found
>> scanning bus 2 for devices... 2 USB Device(s) found
>>scanning usb for storage devices... 0 Storage Device(s)
>> found scanning usb for ethernet devices... 1 Ethernet Device(s)
>> found Waiting for Ethernet connection... done.
>> BOOTP broadcast 1
>> BOOTP broadcast 2
>> DHCP client bound to address 10.0.0.144 (1200 ms)
>> *** Warning: no boot file name; using '0A90.img'
>> Using r8152#0 device
>> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> through gateway 10.0.0.1
>> Filename '0A90.img'.
>> Load address: 0x43e0
>> Loading: *
>> TFTP error: 'File not found' (1)
>> Not retrying...
>> missing environment variable: pxeuuid
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A90
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A9
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A000
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A00
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A0
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0A
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/0
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/default-arm-exynos
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/default-arm
>> *** ERROR: `serverip' not set
>> missing environment variable: bootfile
>> Retrieving file: pxelinux.cfg/default
>> *** ERROR: `serverip' not set
>> Config file not found
>> BOOTP broadcast 1
>> DHCP client bound to address 10.0.0.144 (644 ms)
>> Using r8152#0 device
>> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> through gateway 10.0.0.1
>> Filename 'boot.scr.uimg'.
>> Load address: 0x5000
>> Loading: *
>> TFTP error: 'File not found' (1)
>> Not retrying...
>> BOOTP broadcast 1
>> BOOTP broadcast 2
>> DHCP client bound to address 10.0.0.144 (1257 ms)
>> Using r8152#0 device
>> TFTP from server 0.0.0.0; our IP address is 10.0.0.144; sending
>> through gateway 10.0.0.1
>> Filename 'boot.scr.uimg'.
>> Load address: 0x4200
>> Loading: *
>> TFTP err

[U-Boot] [PATCH] board/ls2081ardb: Update board related prints

2018-01-07 Thread Priyanka Jain
Remove Board Arch print as its value is always
constant '1' and does not contain any important
information to display during boot

Add print to display Board FPGA version.

Signed-off-by: Priyanka Jain 
---
This patch is split version of another patch
https://patchwork.ozlabs.org/patch/803117/

 board/freescale/ls2080ardb/ls2080ardb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index 34843d7..802e497 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -71,7 +71,6 @@ int checkboard(void)
 #ifdef CONFIG_TARGET_LS2081ARDB
 #ifdef CONFIG_FSL_QIXIS
sw = QIXIS_READ(arch);
-   printf("Board Arch: V%d, ", sw >> 4);
printf("Board version: %c, ", (sw & 0xf) + 'A');
 
sw = QIXIS_READ(brdcfg[0]);
@@ -101,6 +100,7 @@ int checkboard(void)
printf("invalid setting of SW%u\n", sw);
break;
}
+   printf("FPGA: v%d.%d\n", QIXIS_READ(scver), QIXIS_READ(tagdata));
 #endif
puts("SERDES1 Reference : ");
printf("Clock1 = 100MHz ");
-- 
2.7.4

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