MMC on I.MX7/8MM break on U-Boot 2020.01-00630-gad647690b1

2020-01-26 Thread Joris Offouga

Hi Tom

I tested latest U-Boot master and it looks like commit 1526bcce (common: 
add blkcache init)[1] breaks load environment in mmc on my Pico-imx7d, 
imx7dsabre and imx8mm-evk:


see logs after:

U-Boot 2020.01-00731-g40521a6c90-dirty (Jan 26 2020 - 12:12:49 +0100)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 29C
Reset cause: POR
Model: TechNexion PICO-IMX7D Board and PI baseboard
Board: i.MX7D PICOSOM
I2C:   ready
DRAM:  512 MiB
PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... data abort
pc : [<9feb0d4e>]       lr : [<9feab5e5>]
reloc pc : [<8781ad4e>]       lr : [<878155e5>]
sp : 9de8ac60  ip : 0002     fp : 9fef3d1c
r10:   r9 : 9de95ea0     r8 : 
r7 : 0006  r6 : fe7f     r5 : 9fefb620  r4 : fe7f
r3 : efff  r2 : 62168365     r1 :   r0 : 0006
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32 (T)
Code: 3b01 f8cb 3008 4634 (6836) e7df
Resetting CPU ...

resetting ...

after revert it :

U-Boot SPL 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
Trying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 482142 to 0x877fffc0... done
Jumping to header at 0x877fffc0
Header Tag is not an IMX image

-Boot 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 40C
Reset cause: POR
Model: TechNexion PICO-IMX7D Board and PI baseboard
Board: i.MX7D PICOSOM
I2C:   ready
DRAM:  512 MiB
PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@30be
Hit any key to stop autoboot:  0

So, can you consider this commit 'not applicable' for next release ?

[1] 
https://gitlab.denx.de/u-boot/u-boot/commit/1526bcce0f7285087621e16e6720636d01839da8


Best regards,

Joris Offouga



Aw: Re: [U-boot,0/4] Add ethernet support for MT7622

2020-01-26 Thread Frank Wunderlich
Hi

> Gesendet: Mittwoch, 22. Januar 2020 um 09:43 Uhr
> Von: "mtk15127" 

>   This patches set just focus on adding mt7622 into mtk eth MAC driver
> with sgmii support, and yes for some mt7622 product(bpi-r64..etc) that
> has a internal switch(mt7531) still need patches to support mt7531 to
> make networking function work fully.

i wondered about changes in ref-board dts. does it contain also mt7531 as 
switch?
imho we need an extra dts for bpi-r64 because ram is different (1G instead of 
256M) and
for future changes which are only for r64.

> We do have plan to send a separate patches for mt7531 switch once this
> mt7622 eth patch set accepted by uBoot.

@tom is this Patchset ok or does it need any changes? any way to merge it in 
actual merge-window,
so mark can work on switch-part?

@Mark, is there any pre-release of switch-driver that i can try before you post 
to mailinglist?

regards Frank


Re: [PATCH] imx: mx6ul_14x14_evk: turn of backlight and LCD before booting OS

2020-01-26 Thread Fabio Estevam
HI Anatolij,

On Sat, Jan 25, 2020 at 8:36 PM Anatolij Gustschin  wrote:
>
> This should help keeping the screen black when booting the kernel.
>
> Signed-off-by: Anatolij Gustschin 
> Reported-by: Fabio Estevam 

Excellent! This keeps the screen black before booting the kernel:

Tested-by: Fabio Estevam 


Re: [PATCH] video: mxsfb: call remove() when booting OS

2020-01-26 Thread Fabio Estevam
Hi Anatolij,

On Sat, Jan 25, 2020 at 8:43 PM Anatolij Gustschin  wrote:

> Maybe turning off the backlight could help to keep it black?
> I've sent a patch, could you please test it? Thanks!

Yes, your patch worked! Thanks!


Re: U-Boot Logo showing incorrect colors with eLCDIF

2020-01-26 Thread Fabio Estevam
Hi Anatolij,

On Sat, Jan 25, 2020 at 3:36 PM Anatolij Gustschin  wrote:

> Now I see that bitmap rendering code for video-uclass driver
> doesn't support displaying 8bpp bitmaps on 24bpp frame buffer.
>
> Before DM_VIDEO conversion cfb_console driver was used and
> it supports such rendering. I'm working on a fix for this.
> Thanks for testing!

Excellent, I will be glad to test it when you have it ready.

I think this is the last remaining issue with mxsfb DM_VIDEO conversion.

Thanks!


Re: [PATCH] video: mxsfb: call remove() when booting OS

2020-01-26 Thread Michael Nazzareno Trimarchi
HI

On Sun, Jan 26, 2020 at 1:24 PM Fabio Estevam  wrote:
>
> Hi Anatolij,
>
> On Sat, Jan 25, 2020 at 8:43 PM Anatolij Gustschin  wrote:
>
> > Maybe turning off the backlight could help to keep it black?
> > I've sent a patch, could you please test it? Thanks!
>
> Yes, your patch worked! Thanks!

This is not a general use case. We want sometime to preserve the
graphics framebuffer in order
to linux to show persistent one.

Michael


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |


[PATCH] configs: Orange Pi Win: enable ethernet

2020-01-26 Thread Jernej Skrabec
Orange Pi Win has gigabit ethernet port, but default U-Boot
configuration for that board didn't enable it.

Fix that.

Signed-off-by: Jernej Skrabec 
---
 configs/orangepi_win_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/orangepi_win_defconfig b/configs/orangepi_win_defconfig
index ad74febe10..7a713ff0e2 100644
--- a/configs/orangepi_win_defconfig
+++ b/configs/orangepi_win_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SPL=y
 CONFIG_MACH_SUN50I=y
+CONFIG_MACPWR="PD14"
 CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_SPL_SPI_SUNXI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
@@ -12,6 +13,7 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-orangepi-win"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_PHY_REALTEK=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.25.0



Re: [PATCH v1 3/5] board: toradex: add Verdin iMX8MM 2GB WB IT v1.0a

2020-01-26 Thread Marcel Ziswiler
Hi Igor

On Thu, 2020-01-23 at 13:31 +0200, Igor Opaniuk wrote:
> From: Igor Opaniuk 
> 
> This introduces initial support for the Toradex Verdin iMX8MM 2GB WB
> IT
> V1.0A module. They are now strapped to boot from eFuses which are
> factory fused to properly boot from their on-module eMMC. U-Boot
> supports booting from the on-module eMMC only, SDP support is
> disabled
> for now.
> 
> Functionality wise the following is known to be working:
> - eMMC, 8-bit and 4-bit MMC/SD card slots
> - Ethernet
> - GPIOs
> - I2C
> 
> Boot sequence is:
> SPL ---> ATF (TF-A) ---> U-boot proper
> 
> ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
> loaded by SPL.
> 
> U-Boot SPL 2020.01-01840-gd92bdc79cf-dirty (Jan 22 2020 - 18:50:57
> +0200)
> Normal Boot
> Trying to boot from MMC1
> 
> U-Boot 2020.01-01840-gd92bdc79cf-dirty (Jan 22 2020 - 18:50:57 +0200)
> 
> CPU:   Freescale i.MX8MMQ rev1.0 at 0 MHz
> Reset cause: POR
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... OK
> In:serial
> Out:   serial
> Err:   serial
> Model: Toradex Verdin iMX8M Mini 2GB Wi-Fi / BT IT V1.0A, Serial#
> 06535148
> Net:   Could not get PHY for FEC0: addr 7
> eth0: ethernet@30be
> Hit any key to stop autoboot:  0
> 
> Signed-off-by: Igor Opaniuk 
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Marcel Ziswiler 
> ---
> 
>  arch/arm/dts/Makefile   |3 +-
>  arch/arm/dts/imx8mm-verdin-u-boot.dtsi  |  103 ++
>  arch/arm/dts/imx8mm-verdin.dts  |  854 +
>  arch/arm/mach-imx/imx8m/Kconfig |7 +
>  board/toradex/verdin-imx8mm/Kconfig |   30 +
>  board/toradex/verdin-imx8mm/Makefile|   12 +
>  board/toradex/verdin-imx8mm/imximage.cfg|   16 +
>  board/toradex/verdin-imx8mm/lpddr4_timing.c | 1851
> +++
>  board/toradex/verdin-imx8mm/spl.c   |  183 ++
>  board/toradex/verdin-imx8mm/verdin-imx8mm.c |   74 +
>  configs/verdin-imx8mm_defconfig |   88 +
>  include/configs/verdin-imx8mm.h |  121 ++
>  12 files changed, 3341 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/imx8mm-verdin-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx8mm-verdin.dts
>  create mode 100644 board/toradex/verdin-imx8mm/Kconfig
>  create mode 100644 board/toradex/verdin-imx8mm/Makefile
>  create mode 100644 board/toradex/verdin-imx8mm/imximage.cfg
>  create mode 100644 board/toradex/verdin-imx8mm/lpddr4_timing.c
>  create mode 100644 board/toradex/verdin-imx8mm/spl.c
>  create mode 100644 board/toradex/verdin-imx8mm/verdin-imx8mm.c
>  create mode 100644 configs/verdin-imx8mm_defconfig
>  create mode 100644 include/configs/verdin-imx8mm.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 44f742017e..4c5ae923e4 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -711,7 +711,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
>   imx8mm-evk.dtb \
>   imx8mn-ddr4-evk.dtb \
>   imx8mq-evk.dtb \
> - imx8mp-evk.dtb
> + imx8mp-evk.dtb \
> + imx8mm-verdin.dtb

We should preserve the alphabetical order.

>  dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb
>  
> diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> new file mode 100644
> index 00..628d9af151
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)

I don't think any parentheses are needed.

> +/*
> + * Copyright 2019 Toradex AG

It's already 2020 now (;-p).

> + */
> +
> +&{/soc@0} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> +&clk {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +};
> +
> +&osc_24m {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&aips1 {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&aips2 {
> + u-boot,dm-spl;
> +};
> +
> +&aips3 {
> + u-boot,dm-spl;
> +};
> +
> +&iomuxc {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_uart1 {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio1 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio2 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio3 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio4 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio5 {
> + u-boot,dm-spl;
> +};
> +
> +&uart1 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc3 {
> + u-boot,dm-spl;
> +};
> +
> +&i2c1 {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_i2c1 {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_pmic {
> + u-boot,dm-spl;
> +

Re: MMC on I.MX7/8MM break on U-Boot 2020.01-00630-gad647690b1

2020-01-26 Thread Fabio Estevam
Hi Joris,

Thanks for reporting the regression.

Adding Angelo.

On Sun, Jan 26, 2020 at 8:38 AM Joris Offouga  wrote:
>
> Hi Tom
>
> I tested latest U-Boot master and it looks like commit 1526bcce (common:
> add blkcache init)[1] breaks load environment in mmc on my Pico-imx7d,
> imx7dsabre and imx8mm-evk:
>
> see logs after:
>
> U-Boot 2020.01-00731-g40521a6c90-dirty (Jan 26 2020 - 12:12:49 +0100)
>
> CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 29C
> Reset cause: POR
> Model: TechNexion PICO-IMX7D Board and PI baseboard
> Board: i.MX7D PICOSOM
> I2C:   ready
> DRAM:  512 MiB
> PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> Loading Environment from MMC... data abort
> pc : [<9feb0d4e>]   lr : [<9feab5e5>]
> reloc pc : [<8781ad4e>]   lr : [<878155e5>]
> sp : 9de8ac60  ip : 0002 fp : 9fef3d1c
> r10:   r9 : 9de95ea0 r8 : 
> r7 : 0006  r6 : fe7f r5 : 9fefb620  r4 : fe7f
> r3 : efff  r2 : 62168365 r1 :   r0 : 0006
> Flags: NzCv  IRQs off  FIQs off  Mode SVC_32 (T)
> Code: 3b01 f8cb 3008 4634 (6836) e7df
> Resetting CPU ...
>
> resetting ...
>
> after revert it :
>
> U-Boot SPL 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
> Trying to boot from USB SDP
> SDP: initialize...
> SDP: handle requests...
> Downloading file of size 482142 to 0x877fffc0... done
> Jumping to header at 0x877fffc0
> Header Tag is not an IMX image
>
> -Boot 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
>
> CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 40C
> Reset cause: POR
> Model: TechNexion PICO-IMX7D Board and PI baseboard
> Board: i.MX7D PICOSOM
> I2C:   ready
> DRAM:  512 MiB
> PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> Loading Environment from MMC... OK
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@30be
> Hit any key to stop autoboot:  0
>
> So, can you consider this commit 'not applicable' for next release ?
>
> [1]
> https://gitlab.denx.de/u-boot/u-boot/commit/1526bcce0f7285087621e16e6720636d01839da8
>
> Best regards,
>
> Joris Offouga
>


Re: [PATCH] cmd: spi: Permit setting bus frequency

2020-01-26 Thread Jagan Teki
On Fri, Dec 20, 2019 at 5:15 PM Marek Vasut  wrote:
>
> The 'sspi' command hard-coded 1 MHz bus frequency for all transmissions.
> Allow changing that at runtime by specifying '@freq' bus frequency in Hz.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> ---

Applied to u-boot-spi/master


Re: MMC on I.MX7/8MM break on U-Boot 2020.01-00630-gad647690b1

2020-01-26 Thread Tom Rini
On Sun, Jan 26, 2020 at 10:25:10AM -0300, Fabio Estevam wrote:
> Hi Joris,
> 
> Thanks for reporting the regression.
> 
> Adding Angelo.
> 
> On Sun, Jan 26, 2020 at 8:38 AM Joris Offouga  wrote:
> >
> > Hi Tom
> >
> > I tested latest U-Boot master and it looks like commit 1526bcce (common:
> > add blkcache init)[1] breaks load environment in mmc on my Pico-imx7d,
> > imx7dsabre and imx8mm-evk:
> >
> > see logs after:
> >
> > U-Boot 2020.01-00731-g40521a6c90-dirty (Jan 26 2020 - 12:12:49 +0100)
> >
> > CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> > CPU:   Commercial temperature grade (0C to 95C) at 29C
> > Reset cause: POR
> > Model: TechNexion PICO-IMX7D Board and PI baseboard
> > Board: i.MX7D PICOSOM
> > I2C:   ready
> > DRAM:  512 MiB
> > PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> > MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> > Loading Environment from MMC... data abort
> > pc : [<9feb0d4e>]   lr : [<9feab5e5>]
> > reloc pc : [<8781ad4e>]   lr : [<878155e5>]
> > sp : 9de8ac60  ip : 0002 fp : 9fef3d1c
> > r10:   r9 : 9de95ea0 r8 : 
> > r7 : 0006  r6 : fe7f r5 : 9fefb620  r4 : fe7f
> > r3 : efff  r2 : 62168365 r1 :   r0 : 0006
> > Flags: NzCv  IRQs off  FIQs off  Mode SVC_32 (T)
> > Code: 3b01 f8cb 3008 4634 (6836) e7df
> > Resetting CPU ...
> >
> > resetting ...
> >
> > after revert it :
> >
> > U-Boot SPL 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
> > Trying to boot from USB SDP
> > SDP: initialize...
> > SDP: handle requests...
> > Downloading file of size 482142 to 0x877fffc0... done
> > Jumping to header at 0x877fffc0
> > Header Tag is not an IMX image
> >
> > -Boot 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
> >
> > CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> > CPU:   Commercial temperature grade (0C to 95C) at 40C
> > Reset cause: POR
> > Model: TechNexion PICO-IMX7D Board and PI baseboard
> > Board: i.MX7D PICOSOM
> > I2C:   ready
> > DRAM:  512 MiB
> > PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> > MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> > Loading Environment from MMC... OK
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   eth0: ethernet@30be
> > Hit any key to stop autoboot:  0
> >
> > So, can you consider this commit 'not applicable' for next release ?
> >
> > [1]
> > https://gitlab.denx.de/u-boot/u-boot/commit/1526bcce0f7285087621e16e6720636d01839da8

Ugh, yes, thanks for the report.  Lets see what we need to do here to
fix everyone as this was for fixing another set of platforms.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] spi: prevent overriding established bus settings

2020-01-26 Thread Jagan Teki
On Thu, Nov 21, 2019 at 10:09 AM Marcin Wojtas  wrote:
>
> The SPI stack relies on a proper bus speed/mode configuration
> by calling dm_spi_claim_bus(). However the hitherto code
> allowed to accidentally override those settings in
> the spi_get_bus_and_cs() routine.
>
> The initially established speed could be discarded by using
> the slave platdata, which turned out to be an issue on
> the platforms whose slave maximum supported frequency
> is not on par with the maximum frequency of the bus controller.
>
> This patch fixes above issue by configuring the bus from
> spi_get_bus_and_cs() only in case it was not done before.
>
> Signed-off-by: Marcin Wojtas 
> ---

Applied to u-boot-spi/master


Re: [PATCH] spi: prevent overriding established bus settings

2020-01-26 Thread Marcin Wojtas
niedz., 26 sty 2020 o 14:30 Jagan Teki  napisał(a):
>
> On Thu, Nov 21, 2019 at 10:09 AM Marcin Wojtas  wrote:
> >
> > The SPI stack relies on a proper bus speed/mode configuration
> > by calling dm_spi_claim_bus(). However the hitherto code
> > allowed to accidentally override those settings in
> > the spi_get_bus_and_cs() routine.
> >
> > The initially established speed could be discarded by using
> > the slave platdata, which turned out to be an issue on
> > the platforms whose slave maximum supported frequency
> > is not on par with the maximum frequency of the bus controller.
> >
> > This patch fixes above issue by configuring the bus from
> > spi_get_bus_and_cs() only in case it was not done before.
> >
> > Signed-off-by: Marcin Wojtas 
> > ---
>
> Applied to u-boot-spi/master

Great, thanks!
Marcin


Re: [PATCH] spi: ti_qspi: Add support for CS other than CS0

2020-01-26 Thread Jagan Teki
On Wed, Dec 11, 2019 at 6:59 PM Vignesh Raghavendra  wrote:
>
> Make sure corresponding setup registers are updated depending on CS.
> This ensures that driver can support QSPI flashes on ChipSelects other
> than on CS0
>
> Reported-by: Andreas Dannenberg 
> Signed-off-by: Vignesh Raghavendra 
> ---

Applied to u-boot-spi/master


Re: [PATCH] mtd: spinand: winbond: Add support for W25N01GV

2020-01-26 Thread Jagan Teki
On Thu, Jan 16, 2020 at 6:33 PM Robert Marko  wrote:
>
> Linux has supported W25N01GV for a long time, so lets import it.
>
> Signed-off-by: Robert Marko 
> Cc: Luka Perkov 
> ---

Applied to u-boot-spi/master


Re: [Patch v4 0/7] Transition of fsl qspi driver to spi-mem framework

2020-01-26 Thread Jagan Teki
Hi Vignesh,

On Mon, Jan 13, 2020 at 12:57 PM Kuldeep Singh  wrote:
>
> This entire patch series migrate freescale qspi driver to spi-mem
> framework.
>
> v4 version of series include removal of buildman failure on LS2080AQDS
> build which was observed in cleanup patches. Also, more clear commit
> message of patch 5.
>
> v3 version of series includes correction of copyright in qspi driver and
> also move SPI_FLASH_SPANSION from header to defconfigs in same patch.
>
> v2 version of series includes changes in qspi driver to have 1k size
> instead of complete flash size so as to make driver independent of flash
> size. This also makes it align with linux version of driver. Also added
> support for imx platforms to set TDH bits correctly. There are other minor
> changes in commit messages.
>
> Dependency on patches[1][2]. These patches are required to resolve booting
> crash observed in LS1012ARDB. One crash was related to pfe driver as it was
> accessing flash memory directly and other was based on environment.
> [1] https://patchwork.ozlabs.org/patch/1219462/
> [2] https://patchwork.ozlabs.org/patch/1208299/
>
> Patch 1 adds new qspi driver incorporating spi-mem framework and also
> removal of old driver which was based on spi-nor. The driver is a ported
> version of linux qspi driver. Initial port was done by Frieder. Now, no
> more direct memory access to spi-nor memory is possible i.e accessing flash
> memory using absolute address is not possible.
>
> Patch 2 removes unused qspi config options.
>
> Patch 3 moves FSL_QSPI to defconfig instead of defining it in header files.
>
> Patch 4 removes unused num-cs property from imx platforms.
>
> Patch 5 enables SPI_FLASH_SPANSION in ls1012a defconfig as FSL_QSPI is
> already enabled.
>
> Patch 6 enables SPI_FLASH_SPANSION in defconfigs of LS1046a boards instead
> of defining in header files.
>
> Patch 7 updates the device-tree properties treewide for layerscape boards
> by aligning with linux device-tree properties.
>
> Frieder Schrempf (1):
>   imx: imx6sx: Remove unused 'num-cs' property
>
> Kuldeep Singh (6):
>   spi: Transform the FSL QuadSPI driver to use the SPI MEM API
>   treewide: Remove unused FSL QSPI config options
>   configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
>   configs: ls1012a: Enable CONFIG_SPI_FLASH_SPANSION in defconfigs
>   configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
>   treewide: Update fsl qspi node dt properties as per spi-mem driver
>
>  arch/arm/dts/fsl-ls1012a-2g5rdb.dts   |5 +-
>  arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
>  arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
>  arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
>  arch/arm/dts/fsl-ls1012a.dtsi |4 +-
>  arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
>  arch/arm/dts/fsl-ls1043a.dtsi |6 +-
>  arch/arm/dts/fsl-ls1046a-frwy.dts |5 +-
>  arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +-
>  arch/arm/dts/fsl-ls1046a-rdb.dts  |5 +-
>  arch/arm/dts/fsl-ls1046a.dtsi |4 +-
>  arch/arm/dts/fsl-ls1088a-qds.dts  |5 +-
>  arch/arm/dts/fsl-ls1088a-rdb.dts  |5 +-
>  arch/arm/dts/fsl-ls1088a.dtsi |2 +-
>  arch/arm/dts/fsl-ls2080a-qds.dts  |5 +-
>  arch/arm/dts/fsl-ls2080a.dtsi |4 +-
>  arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +-
>  arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 -
>  arch/arm/dts/imx6sx-sdb-u-boot.dtsi   |2 -
>  arch/arm/dts/ls1021a-twr.dtsi |5 +-
>  arch/arm/dts/ls1021a.dtsi |6 +-
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |1 -
>  arch/arm/include/asm/arch-ls102xa/config.h|1 -
>  configs/ls1012a2g5rdb_qspi_defconfig  |1 +
>  configs/ls1012a2g5rdb_tfa_defconfig   |1 +
>  configs/ls1012afrdm_qspi_defconfig|1 +
>  configs/ls1012afrdm_tfa_defconfig |1 +
>  configs/ls1012aqds_qspi_defconfig |1 +
>  configs/ls1012aqds_tfa_SECURE_BOOT_defconfig  |1 +
>  configs/ls1012aqds_tfa_defconfig  |1 +
>  configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |1 +
>  configs/ls1012ardb_qspi_defconfig |1 +
>  configs/ls1012ardb_tfa_SECURE_BOOT_defconfig  |1 +
>  configs/ls1012ardb_tfa_defconfig  |1 +
>  configs/ls1043aqds_qspi_defconfig |1 +
>  configs/ls1043aqds_sdcard_qspi_defconfig  |1 +
>  configs/ls1043aqds_tfa_SECURE_BOOT_defconfig  |2 +
>  configs/ls1043aqds_tfa_defconfig  |1 +
>  configs/ls1046aqds_qspi_defconfig |1 +
>  configs/ls1046aqds_sdcard_qspi_defconfig  |1 +
>  configs/ls1046aqds_tfa_SECURE

Re: [PATCH 0/3] spi-nor: Add octal mode support

2020-01-26 Thread Jagan Teki
On Thu, Dec 5, 2019 at 3:45 PM Vignesh Raghavendra  wrote:
>
> This series adds Octal mode support for Micron's mt35x flash.
> Also adds Octal mode support for Cadance OSPI/QSPI controller.
> Currently only 1-1-8 mode is supported.
>
> Vignesh Raghavendra (3):
>   mtd: spi-nor-core: Add octal mode support
>   spi: cadence-qspi: Add support for Cadence Octal SPI controller
>   spi: cadence-qspi: Add compatible for TI AM654
>
>  drivers/mtd/spi/sf_internal.h  |  3 ++-
>  drivers/mtd/spi/spi-nor-core.c | 20 +++-
>  drivers/spi/cadence_qspi.c |  2 ++
>  drivers/spi/cadence_qspi_apb.c |  8 ++--
>  drivers/spi/spi-mem.c  |  6 ++
>  drivers/spi/spi-uclass.c   |  6 ++
>  include/linux/mtd/spi-nor.h|  8 
>  include/spi.h  |  2 ++
>  8 files changed, 51 insertions(+), 4 deletions(-)

Reviewed-by: Jagan Teki 


Re: [PATCH V2 2/3] mtd: rawnand: denali_dt: make the core clock optional

2020-01-26 Thread Masahiro Yamada
On Wed, Jan 22, 2020 at 4:03 AM Marek Vasut  wrote:
>
> From: Masahiro Yamada 
>
> The "nand_x" and "ecc" clocks are currently optional. Make the core
> clock optional in the same way. This will allow platforms with no clock
> driver support to use this driver.
>
> Signed-off-by: Masahiro Yamada 
> Tested-by: Marek Vasut  # On SoCFPGA Arria V


Applied to u-boot-uniphier.
Thanks.

> ---
> V2: No change
> ---
>  drivers/mtd/nand/raw/denali_dt.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/denali_dt.c 
> b/drivers/mtd/nand/raw/denali_dt.c
> index 0ce81324b9..b1e14982c4 100644
> --- a/drivers/mtd/nand/raw/denali_dt.c
> +++ b/drivers/mtd/nand/raw/denali_dt.c
> @@ -91,7 +91,7 @@ static int denali_dt_probe(struct udevice *dev)
> if (ret)
> ret = clk_get_by_index(dev, 0, &clk);
> if (ret)
> -   return ret;
> +   clk.dev = NULL;
>
> ret = clk_get_by_name(dev, "nand_x", &clk_x);
> if (ret)
> @@ -101,9 +101,11 @@ static int denali_dt_probe(struct udevice *dev)
> if (ret)
> clk_ecc.dev = NULL;
>
> -   ret = clk_enable(&clk);
> -   if (ret)
> -   return ret;
> +   if (clk.dev) {
> +   ret = clk_enable(&clk);
> +   if (ret)
> +   return ret;
> +   }
>
> if (clk_x.dev) {
> ret = clk_enable(&clk_x);
> --
> 2.24.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH V2 1/3] mtd: rawnand: denali-spl: Add missing hardware init on SoCFPGA

2020-01-26 Thread Masahiro Yamada
On Wed, Jan 22, 2020 at 4:03 AM Marek Vasut  wrote:
>
> On Altera SoCFPGA, upon either cold-boot or power-on reset, the
> Denali NAND IP is initialized by the BootROM ; upon warm-reset,
> the Denali NAND IP is NOT initialized by BootROM. In fact, upon
> warm-reset, the SoCFPGA BootROM checks whether the SPL image in
> on-chip RAM is valid and if so, completely skips re-loading the
> SPL from the boot media.
>
> This does sometimes leads to problems where the software left
> the boot media in inconsistent state before warm-reset, and
> because the BootROM does not reset the boot media, the boot
> media is left in this inconsistent state, often until another
> component attempts to access the boot media and fails with an
> difficult to debug failure. To mitigate this problem, the SPL
> on Altera SoCFPGA always resets all the IPs on the SoC early
> on boot.
>
> This results in a couple of register values, pre-programmed by
> the BootROM, to be lost during this reset. To restore correct
> operation of the IP on SoCFPGA, these values must be programmed
> back into the controller by the driver. Note that on other SoCs
> which do not use the HW-controlled bootstrap, more registers
> may have to be programmed.
>
> This also aligns the SPL behavior with the full Denali NAND
> driver, which sets these values in denali_hw_init().
>
> Signed-off-by: Marek Vasut 
> Cc: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.
Thanks.




> V2: Reword the commit message
> ---
>  drivers/mtd/nand/raw/denali_spl.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/denali_spl.c 
> b/drivers/mtd/nand/raw/denali_spl.c
> index dbaba3cab2..b8b29812aa 100644
> --- a/drivers/mtd/nand/raw/denali_spl.c
> +++ b/drivers/mtd/nand/raw/denali_spl.c
> @@ -173,6 +173,13 @@ void nand_init(void)
> page_size = readl(denali_flash_reg + DEVICE_MAIN_AREA_SIZE);
> oob_size = readl(denali_flash_reg + DEVICE_SPARE_AREA_SIZE);
> pages_per_block = readl(denali_flash_reg + PAGES_PER_BLOCK);
> +
> +   /* Do as denali_hw_init() does. */
> +   writel(CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES,
> +  denali_flash_reg + SPARE_AREA_SKIP_BYTES);
> +   writel(0x0F, denali_flash_reg + RB_PIN_ENABLED);
> +   writel(CHIP_EN_DONT_CARE__FLAG, denali_flash_reg + 
> CHIP_ENABLE_DONT_CARE);
> +   writel(0x, denali_flash_reg + SPARE_AREA_MARKER);
>  }
>
>  int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> --
> 2.24.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH V2 3/3] mtd: rawnand: denali: Do not reset the block before booting the kernel

2020-01-26 Thread Masahiro Yamada
On Wed, Jan 22, 2020 at 4:03 AM Marek Vasut  wrote:
>
> The register values programmed into the Denali NAND IP are not preserved
> when the IP reset signal is asserted. Depending on whether the Denali NAND
> IP implementation uses HW-assisted bootstrap or not, some of the register
> values are restored automatically after the IP is released from reset.
>
> If HW-assisted bootstrap is used, only RB_PIN_ENABLED, CHIP_ENABLE_DONT_CARE,
> SPARE_AREA_SKIP_BYTES and SPARE_AREA_MARKER need to be restored after reset,
> this is the case on Altera SoCFPGA. Otherwise, many more registers must be
> restored. Since mainline Linux currently does not handle this correctly, do
> not reset the Denali NAND IP before booting Linux. This permits Linux to use
> the register values retained in the Denali NAND IP and thus correctly access
> the NAND.
>
> Fixes: ed784ac3822b ("mtd: rawnand: denali: add reset handling")
> Signed-off-by: Marek Vasut 
> Cc: Masahiro Yamada 
> Cc: Simon Goldschmidt 
> ---



I talked to Marek off-list, and he acked me
to reword the commit log like follows when applied.

-->8--
commit 9a230b0072504511454912a9e301f0beabc270c6 (HEAD -> uniphier,
origin/uniphier)
Author: Marek Vasut 
Date:   Tue Jan 21 20:03:11 2020 +0100

mtd: rawnand: denali: Do not reset the block before booting the kernel

The Denali NAND driver in mainline Linux currently cannot deassert the
reset. The upcoming Linux 5.6 will support the reset controlling, and
also set up SPARE_AREA_SKIP_BYTES correctly. So, the Denali driver in
the future kernel will work without relying on any bootloader or firmware.
However, we still need to take care of stable kernel versions for a while.
U-boot should not assert the reset of this controller.

Fixes: ed784ac3822b ("mtd: rawnand: denali: add reset handling")
Signed-off-by: Marek Vasut 
[yamada.masahiro: reword the commit description]
Signed-off-by: Masahiro Yamada 

-->8--

Applied to u-boot-uniphier.
Thanks.




> V2: - Make resets into local variable
> - Update patch description
> ---
>  drivers/mtd/nand/raw/denali.h|  2 --
>  drivers/mtd/nand/raw/denali_dt.c | 15 ---
>  2 files changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
> index 63ae828768..019deda094 100644
> --- a/drivers/mtd/nand/raw/denali.h
> +++ b/drivers/mtd/nand/raw/denali.h
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>
>  #define DEVICE_RESET   0x0
>  #define DEVICE_RESET__BANK(bank)   BIT(bank)
> @@ -316,7 +315,6 @@ struct denali_nand_info {
> void (*host_write)(struct denali_nand_info *denali, u32 addr, u32 
> data);
> void (*setup_dma)(struct denali_nand_info *denali, dma_addr_t 
> dma_addr,
>   int page, int write);
> -   struct reset_ctl_bulk resets;
>  };
>
>  #define DENALI_CAP_HW_ECC_FIXUPBIT(0)
> diff --git a/drivers/mtd/nand/raw/denali_dt.c 
> b/drivers/mtd/nand/raw/denali_dt.c
> index b1e14982c4..91d0f20aae 100644
> --- a/drivers/mtd/nand/raw/denali_dt.c
> +++ b/drivers/mtd/nand/raw/denali_dt.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "denali.h"
>
> @@ -63,6 +64,7 @@ static int denali_dt_probe(struct udevice *dev)
> struct denali_nand_info *denali = dev_get_priv(dev);
> const struct denali_dt_data *data;
> struct clk clk, clk_x, clk_ecc;
> +   struct reset_ctl_bulk resets;
> struct resource res;
> int ret;
>
> @@ -133,30 +135,21 @@ static int denali_dt_probe(struct udevice *dev)
> denali->clk_x_rate = 2;
> }
>
> -   ret = reset_get_bulk(dev, &denali->resets);
> +   ret = reset_get_bulk(dev, &resets);
> if (ret)
> dev_warn(dev, "Can't get reset: %d\n", ret);
> else
> -   reset_deassert_bulk(&denali->resets);
> +   reset_deassert_bulk(&resets);
>
> return denali_init(denali);
>  }
>
> -static int denali_dt_remove(struct udevice *dev)
> -{
> -   struct denali_nand_info *denali = dev_get_priv(dev);
> -
> -   return reset_release_bulk(&denali->resets);
> -}
> -
>  U_BOOT_DRIVER(denali_nand_dt) = {
> .name = "denali-nand-dt",
> .id = UCLASS_MISC,
> .of_match = denali_nand_dt_ids,
> .probe = denali_dt_probe,
> .priv_auto_alloc_size = sizeof(struct denali_nand_info),
> -   .remove = denali_dt_remove,
> -   .flags = DM_FLAG_OS_PREPARE,
>  };
>
>  void board_nand_init(void)
> --
> 2.24.1
>


--
Best Regards
Masahiro Yamada


Re: [PATCH] configs: Orange Pi Win: enable ethernet

2020-01-26 Thread Jagan Teki
On Sun, Jan 26, 2020 at 6:09 PM Jernej Skrabec  wrote:
>
> Orange Pi Win has gigabit ethernet port, but default U-Boot
> configuration for that board didn't enable it.
>
> Fix that.

The missing one is ethernet phy not the ethernet since sun8i_emac
already enabled? if agree I will update commit message while applying?


Re: [PATCH] configs: Orange Pi Win: enable ethernet

2020-01-26 Thread Jernej Škrabec
Dne nedelja, 26. januar 2020 ob 15:03:55 CET je Jagan Teki napisal(a):
> On Sun, Jan 26, 2020 at 6:09 PM Jernej Skrabec  
wrote:
> > Orange Pi Win has gigabit ethernet port, but default U-Boot
> > configuration for that board didn't enable it.
> > 
> > Fix that.
> 
> The missing one is ethernet phy not the ethernet since sun8i_emac
> already enabled? if agree I will update commit message while applying?

Agreed, thank you.

Best regards,
Jernej





Re: MMC on I.MX7/8MM break on U-Boot 2020.01-00630-gad647690b1

2020-01-26 Thread Angelo Dureghello
Hi Fabio and Joris,

sorry, couldn't test this on imx7/8 stuff.
I'll fix this asap, likely, restricting this operation to m68k.

Regards,
Angelo


On Sun, Jan 26, 2020 at 2:25 PM Fabio Estevam  wrote:
>
> Hi Joris,
>
> Thanks for reporting the regression.
>
> Adding Angelo.
>
> On Sun, Jan 26, 2020 at 8:38 AM Joris Offouga  wrote:
> >
> > Hi Tom
> >
> > I tested latest U-Boot master and it looks like commit 1526bcce (common:
> > add blkcache init)[1] breaks load environment in mmc on my Pico-imx7d,
> > imx7dsabre and imx8mm-evk:
> >
> > see logs after:
> >
> > U-Boot 2020.01-00731-g40521a6c90-dirty (Jan 26 2020 - 12:12:49 +0100)
> >
> > CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> > CPU:   Commercial temperature grade (0C to 95C) at 29C
> > Reset cause: POR
> > Model: TechNexion PICO-IMX7D Board and PI baseboard
> > Board: i.MX7D PICOSOM
> > I2C:   ready
> > DRAM:  512 MiB
> > PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> > MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> > Loading Environment from MMC... data abort
> > pc : [<9feb0d4e>]   lr : [<9feab5e5>]
> > reloc pc : [<8781ad4e>]   lr : [<878155e5>]
> > sp : 9de8ac60  ip : 0002 fp : 9fef3d1c
> > r10:   r9 : 9de95ea0 r8 : 
> > r7 : 0006  r6 : fe7f r5 : 9fefb620  r4 : fe7f
> > r3 : efff  r2 : 62168365 r1 :   r0 : 0006
> > Flags: NzCv  IRQs off  FIQs off  Mode SVC_32 (T)
> > Code: 3b01 f8cb 3008 4634 (6836) e7df
> > Resetting CPU ...
> >
> > resetting ...
> >
> > after revert it :
> >
> > U-Boot SPL 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
> > Trying to boot from USB SDP
> > SDP: initialize...
> > SDP: handle requests...
> > Downloading file of size 482142 to 0x877fffc0... done
> > Jumping to header at 0x877fffc0
> > Header Tag is not an IMX image
> >
> > -Boot 2020.01-00732-g80dd068886-dirty (Jan 26 2020 - 12:19:49 +0100)
> >
> > CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> > CPU:   Commercial temperature grade (0C to 95C) at 40C
> > Reset cause: POR
> > Model: TechNexion PICO-IMX7D Board and PI baseboard
> > Board: i.MX7D PICOSOM
> > I2C:   ready
> > DRAM:  512 MiB
> > PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> > MMC:   FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0
> > Loading Environment from MMC... OK
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   eth0: ethernet@30be
> > Hit any key to stop autoboot:  0
> >
> > So, can you consider this commit 'not applicable' for next release ?
> >
> > [1]
> > https://gitlab.denx.de/u-boot/u-boot/commit/1526bcce0f7285087621e16e6720636d01839da8
> >
> > Best regards,
> >
> > Joris Offouga
> >



-- 
Angelo Dureghello
Timesys
email: angelo.dureghe...@timesys.com
cell.:  +39 388 8550663


Re: [PATCH] configs: Orange Pi Win: enable ethernet

2020-01-26 Thread Jagan Teki
On Sun, Jan 26, 2020 at 7:42 PM Jernej Škrabec  wrote:
>
> Dne nedelja, 26. januar 2020 ob 15:03:55 CET je Jagan Teki napisal(a):
> > On Sun, Jan 26, 2020 at 6:09 PM Jernej Skrabec 
> wrote:
> > > Orange Pi Win has gigabit ethernet port, but default U-Boot
> > > configuration for that board didn't enable it.
> > >
> > > Fix that.
> >
> > The missing one is ethernet phy not the ethernet since sun8i_emac
> > already enabled? if agree I will update commit message while applying?
>
> Agreed, thank you.

Applied to u-boot-sunxi/master


Re: [PATCH 0/2] sunxi: Support automated booting from 128KB

2020-01-26 Thread Jagan Teki
On Fri, Jan 10, 2020 at 7:17 AM Andre Przywara  wrote:
>
> The Allwinner Boot ROM on all later SoCs can load the initial SPL code
> from offset 128KB or from offset 8KB of an SD card or eMMC.
> We support this in the SPL for a while now, but so far needed to manually
> adjust the U-Boot image MMC load sector during compile time.
>
> Since the Boot ROM writes a different boot source ID into the SRAM when
> loaded from the higher offset, we can check this value and dynamically
> adjust the raw MMC load sector for the U-Boot proper image.
>
> This allows to generate *one* image file, which can be written to either
> offset 8KB or to offset 128KB. The latter has the advantange of not
> overlapping with a standard GPT partition table.
>
> Tested on Bananapi M2 Berry (R40), Orangepi Zero (H2+), Orangepi PC 2 (H5),
> Pine64-LTS (A64), Bananapi-M64 (A64, both SD card and eMMC) and
> Pine H64 (H6), on all boards writing the same image to both 8K and 128K.
>
> Cheers,
> Andre.
>
> Andre Przywara (2):
>   sunxi: SPL: Factor out sunxi_get_boot_source()
>   sunxi: Automate loading from 128KB MMC offset

Applied to u-boot-sunxi/master


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

2020-01-26 Thread Lukas Auer
Hi Sean,

On Fri, 2020-01-17 at 14:51 -0500, Sean Anderson wrote:
> Instead of always using the "clock-frequency" property to determine cpu
> frequency, try using a clock in "clocks" if it exists.
> 
> Signed-off-by Sean Anderson 
> ---
> This patch depends on ;.
> 
>  drivers/cpu/riscv_cpu.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
> index 1e32bb5678..280c9de376 100644
> --- a/drivers/cpu/riscv_cpu.c
> +++ b/drivers/cpu/riscv_cpu.c
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2018, Bin Meng 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -27,11 +28,24 @@ static int riscv_cpu_get_desc(struct udevice *dev, char 
> *buf, int size)
>  
>  static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info)
>  {
> + int err;
> + struct clk clk;
>   const char *mmu;
>  
>   /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
>   info->cpu_freq = 0;
> - dev_read_u32(dev, "clock-frequency", (u32 *)&info->cpu_freq);
> +
> + /* First try getting the frequency from the assigned clock */
> + err = clk_get_by_index(dev, 0, &clk);

Usually, ret is used as a variable name here. I think it would actually
make the code a bit nicer to read here, because the clock rate is not
read from variable err.

But that's just nit-picking. The patch looks good otherwise!

Reviewed-by: Lukas Auer 

> + if (!err) {
> + err = clk_get_rate(&clk);
> + if (!IS_ERR_VALUE(err))
> + info->cpu_freq = err;
> + clk_free(&clk);
> + }
> +
> + if (!info->cpu_freq)
> + dev_read_u32(dev, "clock-frequency", (u32 *)&info->cpu_freq);
>  
>   mmu = dev_read_string(dev, "mmu-type");
>   if (!mmu)


Pull request: u-boot-sunxi/master

2020-01-26 Thread Jagan Teki
Hi Tom,

Please pull this PR.

Summary:
- Libre Computer ALL-H3-IT/ALL-H5-CC board (Chen-Yu Tsai)
- Allwinner R40 Ethernet, usb phy enablement (Andre Przywara)
- Sunxi auto load from 128KB MMC offset (Andre Przywara)
- Orange Pi Win Ethernet phy enablement (Jernej Skrabec)

Thanks,
Jagan.

The following changes since commit 5692e8f7b44c0794ecfe8de92bc64897518623d0:

  common: Update comment to show progress (2020-01-24 23:06:49 +0530)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master

for you to fetch changes up to 2936eb2d550a642275113464fc9dcbb03357c049:

  configs: Orange Pi Win: enable ethernet phy (2020-01-26 20:59:51 +0530)


Andre Przywara (7):
  sunxi: dts: R40: Update Bananapi M2 Berry .dts
  sunxi: defconfig: Bananapi M2 Berry: enable Ethernet
  phy: sun4i-usb: Add Allwinner R40 support
  sunxi: defconfig: R40 boards: enable USB
  sunxi: move CONFIG_SYS_SPI_U_BOOT_OFFS out of defconfig
  sunxi: SPL: Factor out sunxi_get_boot_source()
  sunxi: Automate loading from 128KB MMC offset

Chen-Yu Tsai (3):
  sunxi: H3/H5 Sync DT files from upstream Linux kernel as of next-20200108
  sunxi: Add Libre Computer ALL-H3-IT H5 board
  sunxi: Add Libre Computer ALL-H5-CC H5 board

Jernej Skrabec (1):
  configs: Orange Pi Win: enable ethernet phy

 arch/arm/dts/Makefile  |   9 +-
 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
 .../arm/dts/sun50i-h5-emlid-neutis-n5-devboard.dts | 137 ++-
 arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi|  95 +--
 arch/arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 +++
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts|  53 +-
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts |  45 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts|  47 +-
 arch/arm/dts/sun50i-h5-orangepi-prime.dts  |  52 +-
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts  |  11 +-
 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
 arch/arm/dts/sun50i-h5.dtsi| 186 +++--
 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 -
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts |   2 -
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts   |  22 ++-
 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
 arch/arm/dts/sun8i-h3-beelink-x2.dts   |  11 +-
 .../dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts|  72 
 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi   |  11 ++
 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts | 152 +
 arch/arm/dts/sun8i-h3-nanopi-duo2.dts  | 173 +++
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts   |  28 +++-
 arch/arm/dts/sun8i-h3-nanopi-m1.dts|   2 +-
 arch/arm/dts/sun8i-h3-nanopi-neo-air.dts   |   2 +-
 arch/arm/dts/sun8i-h3-nanopi.dtsi  |  25 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts   |  34 +---
 arch/arm/dts/sun8i-h3-orangepi-lite.dts|  27 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts |  28 +---
 arch/arm/dts/sun8i-h3-orangepi-pc.dts  |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts|  23 ++-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts  |   2 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts| 114 +
 arch/arm/dts/sun8i-h3.dtsi |  86 +-
 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts   | 135 +--
 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi  |  30 
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi   |   7 +-
 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi | 170 +++
 arch/arm/dts/sunxi-h3-h5.dtsi  | 137 +--
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi|  65 ++-
 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi| 180 
 arch/arm/mach-sunxi/Kconfig|   1 +
 arch/arm/mach-sunxi/board.c|  38 -
 board/sunxi/MAINTAINERS|  10 ++
 common/spl/Kconfig |   1 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig |   1 -
 configs/Bananapi_M2_Ultra_defconfig|   4 +
 configs/bananapi_m2_berry_defconfig|   6 +
 configs/libretech_all_h3_it_h5_defconfig   |  21 +++
 configs/libretech_all_h5_cc_h5_defconfig   |  22 +++
 configs/oceanic_5205_5inmfd_defconfig  |   1 -
 configs/orangepi_pc2_defconfig |   1 -
 configs/orangepi_r1_defconfig  |   1 -
 configs/orangepi_win_defconfig |   3 +-
 configs/orangepi_z

Re: [PATCH 0/3] spi-nor: Add octal mode support

2020-01-26 Thread Jagan Teki
On Sun, Jan 26, 2020 at 7:21 PM Jagan Teki  wrote:
>
> On Thu, Dec 5, 2019 at 3:45 PM Vignesh Raghavendra  wrote:
> >
> > This series adds Octal mode support for Micron's mt35x flash.
> > Also adds Octal mode support for Cadance OSPI/QSPI controller.
> > Currently only 1-1-8 mode is supported.
> >
> > Vignesh Raghavendra (3):
> >   mtd: spi-nor-core: Add octal mode support
> >   spi: cadence-qspi: Add support for Cadence Octal SPI controller
> >   spi: cadence-qspi: Add compatible for TI AM654
> >
> >  drivers/mtd/spi/sf_internal.h  |  3 ++-
> >  drivers/mtd/spi/spi-nor-core.c | 20 +++-
> >  drivers/spi/cadence_qspi.c |  2 ++
> >  drivers/spi/cadence_qspi_apb.c |  8 ++--
> >  drivers/spi/spi-mem.c  |  6 ++
> >  drivers/spi/spi-uclass.c   |  6 ++
> >  include/linux/mtd/spi-nor.h|  8 
> >  include/spi.h  |  2 ++
> >  8 files changed, 51 insertions(+), 4 deletions(-)
>
> Reviewed-by: Jagan Teki 

Need rebase to master, look like it is not apply directly.

Jagan.


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

2020-01-26 Thread Jagan Teki
On Fri, Jan 17, 2020 at 9:23 PM Simon Goldschmidt
 wrote:
>
> On Fri, Jan 17, 2020 at 2:20 PM Simon Goldschmidt
>  wrote:
> >
> > On Fri, Jan 17, 2020 at 2:01 PM Vignesh Raghavendra  wrote:
> > >
> > >
> > >
> > > On 17/01/20 6:21 pm, Simon Goldschmidt wrote:
> > > > On Tue, Nov 19, 2019 at 11:12 AM Vignesh Raghavendra  
> > > > wrote:
> > > >>
> > > >> Add support for Direct Access Controller mode of Cadence QSPI. This
> > > >> allows MMIO access to SPI NOR flash providing better read performance.
> > > >> Direct mode is only exercised if AHB window size is greater than 8MB.
> > > >> Support for flash address remapping is also not supported at the moment
> > > >> and can be added in future.
> > > >>
> > > >> For better performance, driver uses DMA to copy data from flash in
> > > >> direct mode using dma_memcpy().
> > > >
> > > > This v2 doesn't compile for socfpa as dma_memcpy() isn't available. 
> > > > Since direct
> > > > mode isn't used on that platform (due to your 8MB check), dma_memcpy() 
> > > > is not
> > > > required, but still it doesn't link as this is a runtime decision.
> > > >
> > >
> > > Could you try with latest master and make sure it has [1] and [2]
> > > applied? Thanks!
> > >
> > > [1]http://patchwork.ozlabs.org/patch/1195557/
> > > [2]http://patchwork.ozlabs.org/patch/1195556/
> >
> > Right, Tom merged that yesterday. Compiles now, sorry for the noise.
>
> Tested on socfpga_gen5 (due to the platform layout, this test only says
> it still works in indirect mode - direct mode is not activated on socfgpa):
>
> Tested-by: Simon Goldschmidt 
>
> >
> > Regards,
> > Simon
> >
> > >
> > > Regards
> > > Vignesh
> > >
> > > > Regards,
> > > > Simon
> > > >
> > > >>
> > > >> Signed-off-by: Vignesh Raghavendra 
> > > >> ---
> > > >> v2: Add DMA support and update commit message
> > > >>
> > > >>  drivers/spi/cadence_qspi.c | 40 -
> > > >>  drivers/spi/cadence_qspi.h | 19 +-
> > > >>  drivers/spi/cadence_qspi_apb.c | 65 +-
> > > >>  3 files changed, 91 insertions(+), 33 deletions(-)
> > > >>
> > > >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > > >> index 673a2e9a6c4c..6c98cbf39ae4 100644
> > > >> --- a/drivers/spi/cadence_qspi.c
> > > >> +++ b/drivers/spi/cadence_qspi.c
> > > >> @@ -12,12 +12,13 @@
> > > >>  #include 
> > > >>  #include 
> > > >>  #include 
> > > >> +#include 
> > > >>  #include "cadence_qspi.h"
> > > >>
> > > >>  #define CQSPI_STIG_READ0
> > > >>  #define CQSPI_STIG_WRITE   1
> > > >> -#define CQSPI_INDIRECT_READ2
> > > >> -#define CQSPI_INDIRECT_WRITE   3
> > > >> +#define CQSPI_READ 2
> > > >> +#define CQSPI_WRITE3
> > > >>
> > > >>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
> > > >>  {
> > > >> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
> > > >>
> > > >>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> > > >>  {
> > > >> +   struct cadence_spi_platdata *plat = bus->platdata;
> > > >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> > > >>
> > > >> /* Disable QSPI */
> > > >> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice 
> > > >> *bus, uint mode)
> > > >> /* Set SPI mode */
> > > >> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
> > > >>
> > > >> +   /* Enable Direct Access Controller */
> > > >> +   if (plat->use_dac_mode)
> > > >> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> > > >> +
> > > >> /* Enable QSPI */
> > > >> cadence_qspi_apb_controller_enable(priv->regbase);
> > > >>
> > > >> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct 
> > > >> spi_slave *spi,
> > > >> if (!op->addr.nbytes)
> > > >> mode = CQSPI_STIG_READ;
> > > >> else
> > > >> -   mode = CQSPI_INDIRECT_READ;
> > > >> +   mode = CQSPI_READ;
> > > >> } else {
> > > >> if (!op->addr.nbytes || !op->data.buf.out)
> > > >> mode = CQSPI_STIG_WRITE;
> > > >> else
> > > >> -   mode = CQSPI_INDIRECT_WRITE;
> > > >> +   mode = CQSPI_WRITE;
> > > >> }
> > > >>
> > > >> switch (mode) {
> > > >> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct 
> > > >> spi_slave *spi,
> > > >> case CQSPI_STIG_WRITE:
> > > >> err = cadence_qspi_apb_command_write(base, op);
> > > >> break;
> > > >> -   case CQSPI_INDIRECT_READ:
> > > >> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
> > > >> -   if (!err) {
> > > >> -   err = cadence_qspi_apb_indirect_read_execute
> > > >> -   (plat, op->data.nbytes, 

[PATCH 1/2] arm: mvebu: fix A38x breakage from commit bb872dd930cc

2020-01-26 Thread Joel Johnson
This function parameter usage of load_addr was incorrectly caught in
the clarifying renames of commit bb872dd930cc, which results in boot
failures on Marvell A38x.

Signed-off-by: Joel Johnson 
Patch-to: Simon Glass 
---

 drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c 
b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
index 9293d54e5a..1eababeebd 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
@@ -615,7 +615,7 @@ int ddr3_tip_load_pattern_to_odpg(u32 dev_num, enum 
hws_access_type access_type,
 
CHECK_STATUS(ddr3_tip_if_write(dev_num, access_type, if_id,
   ODPG_DATA_BUFFER_OFFS_REG,
-  image_load_addr, MASK_ALL_BITS));
+  load_addr, MASK_ALL_BITS));
 
return MV_OK;
 }
-- 
2.20.1



[PATCH 2/2] Revert "common: add blkcache init"

2020-01-26 Thread Joel Johnson
This reverts commit 1526bcce0f7285087621e16e6720636d01839da8.

The commit causes boot failure using MMC environment for Marvell A38x
(tested with SolidRun Clearfog). The boot hangs after the following
message is printed to console:
Loading Environment from MMC...

Other than bisecting to identify the problematic commit I haven't
tested further to determine a better possible fix to be compatible
with both A38x and m68k.

Signed-off-by: Joel Johnson 
---

 common/board_r.c | 3 ---
 drivers/block/blkcache.c | 9 +
 include/blk.h| 6 --
 3 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 4f56c19fcc..8a0c1114e7 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -864,9 +864,6 @@ static init_fnc_t init_sequence_r[] = {
 #endif
 #if defined(CONFIG_PRAM)
initr_mem,
-#endif
-#ifdef CONFIG_BLOCK_CACHE
-   blkcache_init,
 #endif
run_main_loop,
 };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index f603aa129d..1fa64989d3 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,20 +21,13 @@ struct block_cache_node {
char *cache;
 };
 
-static struct list_head block_cache;
+static LIST_HEAD(block_cache);
 
 static struct block_cache_stats _stats = {
.max_blocks_per_entry = 8,
.max_entries = 32
 };
 
-int blkcache_init(void)
-{
-   INIT_LIST_HEAD(&block_cache);
-
-   return 0;
-}
-
 static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index 6f541bb2ba..ccc66e6a20 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,12 +113,6 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
 
 #if CONFIG_IS_ENABLED(BLOCK_CACHE)
-
-/**
- * blkcache_init() - initialize the block cache list pointers
- */
-int blkcache_init(void);
-
 /**
  * blkcache_read() - attempt to read a set of blocks from cache
  *
-- 
2.20.1



Re: [PATCH] mtd: spinand: winbond: Add support for W25N01GV

2020-01-26 Thread Robert Marko
On Sun, Jan 26, 2020 at 2:47 PM Jagan Teki  wrote:
>
> On Thu, Jan 16, 2020 at 6:33 PM Robert Marko  wrote:
> >
> > Linux has supported W25N01GV for a long time, so lets import it.
> >
> > Signed-off-by: Robert Marko 
> > Cc: Luka Perkov 
> > ---
>
> Applied to u-boot-spi/master
Great, can you also take a look at my Toshiba SPI-NAND related patches?


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

2020-01-26 Thread Sean Anderson
On 1/26/20 11:34 AM, Lukas Auer wrote:
> Hi Sean,
> Usually, ret is used as a variable name here. I think it would actually
> make the code a bit nicer to read here, because the clock rate is not
> read from variable err.

Hm, I chose err instead of ret since that variable is never the return
value of the function. I can change that for v2 if you'd like.

> But that's just nit-picking. The patch looks good otherwise!
> 
> Reviewed-by: Lukas Auer 




[PATCH] common: fix regression on block cache init

2020-01-26 Thread Angelo Dureghello
From: Angelo Durgehello 

m68k needs block cache list initialized after relocation.
Other architectures must not be involved.

Fixing regression related to:

commit 1526bcce0f7285087621e16e6720636d01839da8
("common: add blkcache init")

Signed-off-by: Angelo Durgehello 
---
 common/board_r.c | 2 +-
 drivers/block/blkcache.c | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 4f56c19fcc..0bbeaa7594 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -865,7 +865,7 @@ static init_fnc_t init_sequence_r[] = {
 #if defined(CONFIG_PRAM)
initr_mem,
 #endif
-#ifdef CONFIG_BLOCK_CACHE
+#if defined(CONFIG_M68K) && defined(CONFIG_BLOCK_CACHE)
blkcache_init,
 #endif
run_main_loop,
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index f603aa129d..ea40929e3e 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,19 +21,25 @@ struct block_cache_node {
char *cache;
 };
 
+#ifndef CONFIG_M68K
+static LIST_HEAD(block_cache);
+#else
 static struct list_head block_cache;
+#endif
 
 static struct block_cache_stats _stats = {
.max_blocks_per_entry = 8,
.max_entries = 32
 };
 
+#ifdef CONFIG_M68K
 int blkcache_init(void)
 {
INIT_LIST_HEAD(&block_cache);
 
return 0;
 }
+#endif
 
 static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
-- 
2.24.1



Re: [PATCH 2/2] Revert "common: add blkcache init"

2020-01-26 Thread Angelo Dureghello
Hi Joel, Tom and all,

just sent a fix, you can check it here:
https://patchwork.ozlabs.org/project/uboot/list/?series=155358

Sorry again,
Regards,
Angelo

On Sun, Jan 26, 2020 at 5:49 PM Joel Johnson  wrote:
>
> This reverts commit 1526bcce0f7285087621e16e6720636d01839da8.
>
> The commit causes boot failure using MMC environment for Marvell A38x
> (tested with SolidRun Clearfog). The boot hangs after the following
> message is printed to console:
> Loading Environment from MMC...
>
> Other than bisecting to identify the problematic commit I haven't
> tested further to determine a better possible fix to be compatible
> with both A38x and m68k.
>
> Signed-off-by: Joel Johnson 
> ---
>
>  common/board_r.c | 3 ---
>  drivers/block/blkcache.c | 9 +
>  include/blk.h| 6 --
>  3 files changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 4f56c19fcc..8a0c1114e7 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -864,9 +864,6 @@ static init_fnc_t init_sequence_r[] = {
>  #endif
>  #if defined(CONFIG_PRAM)
> initr_mem,
> -#endif
> -#ifdef CONFIG_BLOCK_CACHE
> -   blkcache_init,
>  #endif
> run_main_loop,
>  };
> diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
> index f603aa129d..1fa64989d3 100644
> --- a/drivers/block/blkcache.c
> +++ b/drivers/block/blkcache.c
> @@ -21,20 +21,13 @@ struct block_cache_node {
> char *cache;
>  };
>
> -static struct list_head block_cache;
> +static LIST_HEAD(block_cache);
>
>  static struct block_cache_stats _stats = {
> .max_blocks_per_entry = 8,
> .max_entries = 32
>  };
>
> -int blkcache_init(void)
> -{
> -   INIT_LIST_HEAD(&block_cache);
> -
> -   return 0;
> -}
> -
>  static struct block_cache_node *cache_find(int iftype, int devnum,
>lbaint_t start, lbaint_t blkcnt,
>unsigned long blksz)
> diff --git a/include/blk.h b/include/blk.h
> index 6f541bb2ba..ccc66e6a20 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -113,12 +113,6 @@ struct blk_desc {
> (PAD_SIZE(size, blk_desc->blksz))
>
>  #if CONFIG_IS_ENABLED(BLOCK_CACHE)
> -
> -/**
> - * blkcache_init() - initialize the block cache list pointers
> - */
> -int blkcache_init(void);
> -
>  /**
>   * blkcache_read() - attempt to read a set of blocks from cache
>   *
> --
> 2.20.1
>


-- 
Angelo Dureghello
Timesys
email: angelo.dureghe...@timesys.com
cell.:  +39 388 8550663


Re: [PATCH 1/2] arm: mvebu: fix A38x breakage from commit bb872dd930cc

2020-01-26 Thread Tom Rini
On Sun, Jan 26, 2020 at 09:48:58AM -0700, Joel Johnson wrote:

> This function parameter usage of load_addr was incorrectly caught in
> the clarifying renames of commit bb872dd930cc, which results in boot
> failures on Marvell A38x.
> 
> Signed-off-by: Joel Johnson 
> Patch-to: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request: u-boot-sunxi/master

2020-01-26 Thread Tom Rini
On Sun, Jan 26, 2020 at 10:08:26PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Summary:
> - Libre Computer ALL-H3-IT/ALL-H5-CC board (Chen-Yu Tsai)
> - Allwinner R40 Ethernet, usb phy enablement (Andre Przywara)
> - Sunxi auto load from 128KB MMC offset (Andre Przywara)
> - Orange Pi Win Ethernet phy enablement (Jernej Skrabec)
> 
> Thanks,
> Jagan.
> 
> The following changes since commit 5692e8f7b44c0794ecfe8de92bc64897518623d0:
> 
>   common: Update comment to show progress (2020-01-24 23:06:49 +0530)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master
> 
> for you to fetch changes up to 2936eb2d550a642275113464fc9dcbb03357c049:
> 
>   configs: Orange Pi Win: enable ethernet phy (2020-01-26 20:59:51 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] common: fix regression on block cache init

2020-01-26 Thread Tom Rini
On Sun, Jan 26, 2020 at 07:31:22PM +0100, Angelo Dureghello wrote:

> From: Angelo Durgehello 
> 
> m68k needs block cache list initialized after relocation.
> Other architectures must not be involved.
> 
> Fixing regression related to:
> 
> commit 1526bcce0f7285087621e16e6720636d01839da8
>   ("common: add blkcache init")
> 
> Signed-off-by: Angelo Durgehello 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


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

2020-01-26 Thread Giulio Benetti

On 1/17/20 1:06 PM, Giulio Benetti wrote:

V1->V2
* check only if parent_rate==0, as signalled by Adam

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

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



Kindly ping

--
Giulio Benetti
Benetti Engineering sas


[GIT] Pull request: u-boot-dfu (26.01.2020)

2020-01-26 Thread Lukasz Majewski
Dear Marek,

The following changes since commit
40521a6c90d4adfb7f3041033c8cbbeff087a5ca:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
  (2020-01-25 12:20:51 -0500)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git 

for you to fetch changes up to d34375267f521dc76b1875a905cec914a47b0712:

  dfu: Add option to skip empty pages when flashing UBI images to NAND
  (2020-01-26 11:44:15 +0100)


Guillermo Rodríguez (1):
  dfu: Add option to skip empty pages when flashing UBI images to
NAND

 drivers/dfu/Kconfig| 7 +++
 drivers/dfu/dfu_nand.c | 7 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

BRANCH: master
https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master

Merge tag info:
- Add option to DFU NAND to skip empty pages when flashing UBI images


Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/618507384

Best regards,

Lukasz Majewski

--

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


pgpgxLg31kiFi.pgp
Description: OpenPGP digital signature


Re: [PATCH 1/2] clk: Move clk-gate2 to clock driver directory

2020-01-26 Thread Lukasz Majewski
Hi Sean

> Make clk-gate2 available for use outside of imx.
> 
> Signed-off-by: Sean Anderson 
> ---
>  drivers/clk/Makefile  |  1 +
>  drivers/clk/{imx => }/clk-gate2.c | 20 
>  drivers/clk/imx/Makefile  |  2 +-
>  drivers/clk/imx/clk.h |  5 -
>  include/linux/clk-provider.h  | 24 
>  5 files changed, 26 insertions(+), 26 deletions(-)
>  rename drivers/clk/{imx => }/clk-gate2.c (85%)
> 

This patch is OK.

Unfortunately, it causes buildman errors for sandbox:
https://travis-ci.org/lmajewski/u-boot-dfu/jobs/641984485

The problem is with local sandbox copy of struct clk_gate2

In the clk_sandbox_ccf.c file we can re-use the 'flags' member (instead
of defined for sandbox 'state') of now widely exposed struct clk_gate2
(@ clk-provider.h) and 

#define SANDBOX_CCF_ENABLE (1UL << 31)
#define SANDBOX_CCF_DISABLE (0UL << 31)

and remove the local sandbox copy.


How to reproduce:

make mrproper; make sandbox_defconfig; make -j4
./u-boot -i -d arch/sandbox/dts/test.dtb
=> ut dm clk


(I'm going to drop this patch from PR which I'm preparing now and
depending on it "clk: Add option to restrict clk-gate2 to one bit
toggle").


> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 06131edb9f..fef3280f16 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
>  obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
>  obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o
> clk-gate.o obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
> +obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-gate2.o
>  obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
> 
>  obj-y += analogbits/
> diff --git a/drivers/clk/imx/clk-gate2.c b/drivers/clk/clk-gate2.c
> similarity index 85%
> rename from drivers/clk/imx/clk-gate2.c
> rename to drivers/clk/clk-gate2.c
> index 1b9db6e791..cfe21e5496 100644
> --- a/drivers/clk/imx/clk-gate2.c
> +++ b/drivers/clk/clk-gate2.c
> @@ -10,8 +10,7 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   *
> - * Gated clock implementation
> - *
> + * Gated clock which redirects rate functions to its parent clock
>   */
> 
>  #include 
> @@ -21,19 +20,8 @@
>  #include 
>  #include 
>  #include 
> -#include "clk.h"
> -
> -#define UBOOT_DM_CLK_IMX_GATE2 "imx_clk_gate2"
> -
> -struct clk_gate2 {
> - struct clk clk;
> - void __iomem*reg;
> - u8  bit_idx;
> - u8  cgr_val;
> - u8  flags;
> -};
> 
> -#define to_clk_gate2(_clk) container_of(_clk, struct clk_gate2, clk)
> +#define UBOOT_DM_CLK_GATE2 "clk_gate2"
> 
>  static int clk_gate2_enable(struct clk *clk)
>  {
> @@ -97,7 +85,7 @@ struct clk *clk_register_gate2(struct device *dev,
> const char *name,
> 
>   clk = &gate->clk;
> 
> - ret = clk_register(clk, UBOOT_DM_CLK_IMX_GATE2, name,
> parent_name);
> + ret = clk_register(clk, UBOOT_DM_CLK_GATE2, name,
> parent_name); if (ret) {
>   kfree(gate);
>   return ERR_PTR(ret);
> @@ -107,7 +95,7 @@ struct clk *clk_register_gate2(struct device *dev,
> const char *name, }
> 
>  U_BOOT_DRIVER(clk_gate2) = {
> - .name   = UBOOT_DM_CLK_IMX_GATE2,
> + .name   = UBOOT_DM_CLK_GATE2,
>   .id = UCLASS_CLK,
>   .ops= &clk_gate2_ops,
>   .flags = DM_FLAG_PRE_RELOC,
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
> index 222c5a4e08..5328e9265a 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -2,7 +2,7 @@
>  #
>  # SPDX-License-Identifier: GPL-2.0
> 
> -obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-gate2.o clk-pllv3.o clk-pfd.o
> +obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-pllv3.o clk-pfd.o
>  obj-$(CONFIG_$(SPL_TPL_)CLK_IMX6Q) += clk-imx6q.o
>  obj-$(CONFIG_CLK_IMX8) += clk-imx8.o
> 
> diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
> index 07dcf94ea5..c46570e9f4 100644
> --- a/drivers/clk/imx/clk.h
> +++ b/drivers/clk/imx/clk.h
> @@ -45,11 +45,6 @@ struct clk *imx_clk_pll14xx(const char *name,
> const char *parent_name, void __iomem *base,
>   const struct imx_pll14xx_clk *pll_clk);
> 
> -struct clk *clk_register_gate2(struct device *dev, const char *name,
> - const char *parent_name, unsigned long flags,
> - void __iomem *reg, u8 bit_idx, u8 cgr_val,
> - u8 clk_gate_flags);
> -
>  struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const char *name,
> const char *parent_name, void __iomem
> *base, u32 div_mask);
> diff --git a/include/linux/clk-provider.h
> b/include/linux/clk-provider.h index 0ef6e685ad..f510291018 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -90,10 +90,6 @@ struct clk_gate {
>  #define CLK_GATE_HIWORD_MASK BIT(1)
> 
>  extern const struct clk_ops clk_gate

Re: [PATCH v2 01/11] clk: Always use the supplied struct clk

2020-01-26 Thread Lukasz Majewski
Hi Sean,

> CCF clocks should always use the struct clock passed to their methods
> for extracting the driver-specific clock information struct.

This couldn't be done for i.MX8 at least. There was an issue with
composite clock on this SoC.

(I've CC'ed Peng, who did this work for i.MX8 - I was
testing/developing the framework for i.MX6Q which doesn't support
composite clocks).

For some design decisions and the "overall picture" of CCF , please see
following doc entry:
https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/clk/ccf.txt


> Previously, many functions would use the clk->dev->priv if the device
> was bound. This could cause problems with composite clocks. 

The problem (in short) is with combining Linux CCF design and U-Boot's
DM (more details in the link above).

All the clocks are linked with struct udevice (one search the linked
list for proper clock).

However, with Linux the "main" clock structure is 'struct clk, which is
embedded in CLK IP block specific structure (i.e. struct clk_gate2).

Problem is that from struct clk we do have pointer to struct udevice
(*dev), but there is no direct pointer "up" from struct udevice to
struct clk (now we do use udevice's->uclass_priv).

So far so good 

Problem started with iMX8, where we do have a composite clocks, which
would like to be seen as a single one (like struct pllX), but they
comprise of a few other "clocks".

To distinct them the clk_dev_binded() was added, which checks if the
struct udevice represents "top" composite clock (which shall be visible
with e.g. 'clk' command)



> The
> individual clocks in a composite clock did not have the ->dev field
> filled in. This was fine, because the device-specific clock
> information would be used. However, since there was no ->dev, there
> was no way to get the parent clock. 

Wasn't there any back pointer available? Or do we need to search the
clocks linked list and look for "bind" flag in top level composite
clock?

> This caused the recalc_rate
> method of the CCF divider clock to fail. One option would be to use
> the clk->priv field to get the composite clock and from there get the
> appropriate parent device. However, this would tie the implementation
> to the composite clock. In general, different devices should not rely
> on the contents of ->priv from another device.

Maybe we shall follow:
https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/clk/ccf.txt#L40

> 
> The simple solution to this problem is to just always use the
> supplied struct clock. 

I think that we took this approach in the past. Unfortunately, this
caused all clocks being exposed when 'clk' command was run.

Peng - were there any other issues with i.MX8 composite clock
implementation?

> The composite clock now fills in the ->dev
> pointer of its child clocks. This allows child clocks to make calls
> like clk_get_parent() without issue.
> 
> imx avoided the above problem by using a custom get_rate function
> with composite clocks.

Do you refer to:
https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/clk/imx/clk-composite-8m.c#L30

There the clk is cast from (struct clk_composite *)clk->data

(now in U-Boot we do have 4! different implementations of struct clk).

> 
> Signed-off-by: Sean Anderson 
> ---
>  drivers/clk/clk-composite.c|  8 
>  drivers/clk/clk-divider.c  |  6 ++
>  drivers/clk/clk-fixed-factor.c |  3 +--
>  drivers/clk/clk-gate.c |  6 ++
>  drivers/clk/clk-mux.c  | 12 
>  drivers/clk/imx/clk-gate2.c|  4 ++--
>  6 files changed, 19 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index a5626c33d1..d0f273d47f 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -145,6 +145,14 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, goto err;
>   }
>  
> + if (composite->mux)
> + composite->mux->dev = clk->dev;
> + if (composite->rate)
> + composite->rate->dev = clk->dev;
> + if (composite->gate)
> + composite->gate->dev = clk->dev;
> +
> +
>   return clk;
>  
>  err:
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 822e09b084..bfa05f24a3 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -70,8 +70,7 @@ unsigned long divider_recalc_rate(struct clk *hw,
> unsigned long parent_rate, 
>  static ulong clk_divider_recalc_rate(struct clk *clk)
>  {
> - struct clk_divider *divider =
> to_clk_divider(clk_dev_binded(clk) ?
> - dev_get_clk_ptr(clk->dev) : clk);
> + struct clk_divider *divider = to_clk_divider(clk);

How do you differentiate the "top" level of composite clock from the
clocks from which the composite clock is built?

Now we do use the clk_dev_binded().

>   unsigned long parent_rate = clk_get_parent_rate(clk);
>   unsigned int val;
>  
> @@ -150,8 +149,7 @@ int divider_get_val

Re: [PATCH v2 02/11] clk: Check that ops of composite clock components, exist before calling

2020-01-26 Thread Lukasz Majewski
Hi Sean,

> clk_composite_ops was shared between all devices in the composite
> clock driver. If one clock had a feature (such as supporting
> set_parent) which another clock did not, it could call a null pointer
> dereference.
> 
> This patch does three things
> 1. It adds null-pointer checks to all composite clock functions.
> 2. It makes clk_composite_ops const and sets its functions at
> compile-time. 3. It adds some basic sanity checks to num_parents.
> 
> The combined effect of these changes is that any of mux, rate, or
> gate can be NULL, and composite clocks will still function normally.
> Previously, at least mux had to exist, since clk_composite_get_parent
> was used to determine the parent for clk_register.
> 

Thank you for those checks - up till now this code was tuned for i.MX
(and in-fact this SoC's clock tree).

However, I would like to first wait for the consensus regarding the
shape of composite clocks (and reply to this mail):

"clk: Always use the supplied struct clk"

> Signed-off-by: Sean Anderson 
> ---
>  drivers/clk/clk-composite.c | 57
> +++-- 1 file changed, 35
> insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index d0f273d47f..ea9982fd57 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -22,7 +22,10 @@ static u8 clk_composite_get_parent(struct clk *clk)
>   (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
>   struct clk *mux = composite->mux;
>  
> - return clk_mux_get_parent(mux);
> + if (mux)
> + return clk_mux_get_parent(mux);
> + else
> + return 0;
>  }
>  
>  static int clk_composite_set_parent(struct clk *clk, struct clk
> *parent) @@ -32,7 +35,10 @@ static int
> clk_composite_set_parent(struct clk *clk, struct clk *parent) const
> struct clk_ops *mux_ops = composite->mux_ops; struct clk *mux =
> composite->mux; 
> - return mux_ops->set_parent(mux, parent);
> + if (mux && mux_ops)
> + return mux_ops->set_parent(mux, parent);
> + else
> + return -ENOTSUPP;
>  }
>  
>  static unsigned long clk_composite_recalc_rate(struct clk *clk)
> @@ -42,7 +48,10 @@ static unsigned long
> clk_composite_recalc_rate(struct clk *clk) const struct clk_ops
> *rate_ops = composite->rate_ops; struct clk *rate = composite->rate;
>  
> - return rate_ops->get_rate(rate);
> + if (rate && rate_ops)
> + return rate_ops->get_rate(rate);
> + else
> + return clk_get_parent_rate(clk);
>  }
>  
>  static ulong clk_composite_set_rate(struct clk *clk, unsigned long
> rate) @@ -52,7 +61,10 @@ static ulong clk_composite_set_rate(struct
> clk *clk, unsigned long rate) const struct clk_ops *rate_ops =
> composite->rate_ops; struct clk *clk_rate = composite->rate;
>  
> - return rate_ops->set_rate(clk_rate, rate);
> + if (rate && rate_ops)
> + return rate_ops->set_rate(clk_rate, rate);
> + else
> + return -ENOTSUPP;
>  }
>  
>  static int clk_composite_enable(struct clk *clk)
> @@ -62,7 +74,10 @@ static int clk_composite_enable(struct clk *clk)
>   const struct clk_ops *gate_ops = composite->gate_ops;
>   struct clk *gate = composite->gate;
>  
> - return gate_ops->enable(gate);
> + if (gate && gate_ops)
> + return gate_ops->enable(gate);
> + else
> + return -ENOTSUPP;
>  }
>  
>  static int clk_composite_disable(struct clk *clk)
> @@ -72,15 +87,12 @@ static int clk_composite_disable(struct clk *clk)
>   const struct clk_ops *gate_ops = composite->gate_ops;
>   struct clk *gate = composite->gate;
>  
> - gate_ops->disable(gate);
> -
> - return 0;
> + if (gate && gate_ops)
> + return gate_ops->disable(gate);
> + else
> + return -ENOTSUPP;
>  }
>  
> -struct clk_ops clk_composite_ops = {
> - /* This will be set according to clk_register_composite */
> -};
> -
>  struct clk *clk_register_composite(struct device *dev, const char
> *name, const char * const *parent_names,
>  int num_parents, struct clk *mux,
> @@ -94,7 +106,9 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, struct clk *clk;
>   struct clk_composite *composite;
>   int ret;
> - struct clk_ops *composite_ops = &clk_composite_ops;
> +
> + if (!num_parents || (num_parents != 1 && !mux))
> + return ERR_PTR(-EINVAL);
>  
>   composite = kzalloc(sizeof(*composite), GFP_KERNEL);
>   if (!composite)
> @@ -103,8 +117,6 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, if (mux && mux_ops) {
>   composite->mux = mux;
>   composite->mux_ops = mux_ops;
> - if (mux_ops->set_parent)
> - composite_ops->set_parent =
> clk_composite_set_parent; mux->data = (ulong)composite;
>   }
>  
> @@ -113,11 +125,6 @@ struct 

Re: [GIT] Pull request: u-boot-dfu (26.01.2020)

2020-01-26 Thread Marek Vasut
On 1/26/20 9:26 PM, Lukasz Majewski wrote:
Hi,

[...]

> 
> Guillermo Rodríguez (1):
>   dfu: Add option to skip empty pages when flashing UBI images to

Can that option be enabled/disabled at runtime instead of being hardcoded?


Re: [PATCH 2/2] Revert "common: add blkcache init"

2020-01-26 Thread Joel Johnson

Thanks for the quick response and update!

Joel

On 2020-01-26 11:34, Angelo Dureghello wrote:

Hi Joel, Tom and all,

just sent a fix, you can check it here:
https://patchwork.ozlabs.org/project/uboot/list/?series=155358

Sorry again,
Regards,
Angelo

On Sun, Jan 26, 2020 at 5:49 PM Joel Johnson  wrote:


This reverts commit 1526bcce0f7285087621e16e6720636d01839da8.

The commit causes boot failure using MMC environment for Marvell A38x
(tested with SolidRun Clearfog). The boot hangs after the following
message is printed to console:
Loading Environment from MMC...

Other than bisecting to identify the problematic commit I haven't
tested further to determine a better possible fix to be compatible
with both A38x and m68k.

Signed-off-by: Joel Johnson 
---

 common/board_r.c | 3 ---
 drivers/block/blkcache.c | 9 +
 include/blk.h| 6 --
 3 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 4f56c19fcc..8a0c1114e7 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -864,9 +864,6 @@ static init_fnc_t init_sequence_r[] = {
 #endif
 #if defined(CONFIG_PRAM)
initr_mem,
-#endif
-#ifdef CONFIG_BLOCK_CACHE
-   blkcache_init,
 #endif
run_main_loop,
 };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index f603aa129d..1fa64989d3 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,20 +21,13 @@ struct block_cache_node {
char *cache;
 };

-static struct list_head block_cache;
+static LIST_HEAD(block_cache);

 static struct block_cache_stats _stats = {
.max_blocks_per_entry = 8,
.max_entries = 32
 };

-int blkcache_init(void)
-{
-   INIT_LIST_HEAD(&block_cache);
-
-   return 0;
-}
-
 static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t 
blkcnt,

   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index 6f541bb2ba..ccc66e6a20 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,12 +113,6 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))

 #if CONFIG_IS_ENABLED(BLOCK_CACHE)
-
-/**
- * blkcache_init() - initialize the block cache list pointers
- */
-int blkcache_init(void);
-
 /**
  * blkcache_read() - attempt to read a set of blocks from cache
  *
--
2.20.1



Re: [PATCH v2 06/11] riscv: Fix incorrect cpu frequency on RV64

2020-01-26 Thread Lukas Auer
On Wed, 2020-01-15 at 17:55 -0500, Sean Anderson wrote:

> The riscv_cpu_get_info function does not always zero-out cpu_freq. This can
> cause spurious higher frequencies.
> 
> Signed-off-by Sean Anderson 
> ---
> Changes for v2:
>   New.
> 
>  drivers/cpu/riscv_cpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Lukas Auer 


Re: [PATCH v2 03/11] riscv: Add headers for asm/global_data.h

2020-01-26 Thread Lukas Auer
Hi Sean,


On Wed, 2020-01-15 at 17:50 -0500, Sean Anderson wrote:
> This header depended on bd_t and ulong, but did not include the appropriate
> headers.
> 
> Signed-off-by: Sean Anderson 
> ---
>  arch/riscv/include/asm/global_data.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/riscv/include/asm/global_data.h 
> b/arch/riscv/include/asm/global_data.h
> index b74bd7e738..4f0c12b402 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -11,6 +11,8 @@
>  #define __ASM_GBL_DATA_H
>  
>  #include 
> +#include 
> +#include 
>  

asm/u-boot.h is usually included with common.h. ulong is defined in
linux/types.h (also included in common.h). It should be sufficient to
include common.h in your source files.

Thanks,
Lukas


Re: [PATCH v2 01/11] clk: Always use the supplied struct clk

2020-01-26 Thread Sean Anderson
Hi Lukasz,

Thanks for the feedback.

On 1/26/20 4:20 PM, Lukasz Majewski wrote:
> Hi Sean,
> 
>> CCF clocks should always use the struct clock passed to their methods
>> for extracting the driver-specific clock information struct.
> 
> This couldn't be done for i.MX8 at least. There was an issue with
> composite clock on this SoC.
> 
> (I've CC'ed Peng, who did this work for i.MX8 - I was
> testing/developing the framework for i.MX6Q which doesn't support
> composite clocks).
> 
> For some design decisions and the "overall picture" of CCF , please see
> following doc entry:
> https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/clk/ccf.txt

That documentation was helpful, but it tends to focus more on the "what"
than the "why." Perhaps I can help update it when I have a better grasp
on the CCF.

>> Previously, many functions would use the clk->dev->priv if the device
>> was bound. This could cause problems with composite clocks. 
> 
> The problem (in short) is with combining Linux CCF design and U-Boot's
> DM (more details in the link above).
> 
> All the clocks are linked with struct udevice (one search the linked
> list for proper clock).
> 
> However, with Linux the "main" clock structure is 'struct clk, which is
> embedded in CLK IP block specific structure (i.e. struct clk_gate2).
> 
> Problem is that from struct clk we do have pointer to struct udevice
> (*dev), but there is no direct pointer "up" from struct udevice to
> struct clk (now we do use udevice's->uclass_priv).
> 
> So far so good 
> 
> Problem started with iMX8, where we do have a composite clocks, which
> would like to be seen as a single one (like struct pllX), but they
> comprise of a few other "clocks".
> 
> To distinct them the clk_dev_binded() was added, which checks if the
> struct udevice represents "top" composite clock (which shall be visible
> with e.g. 'clk' command)
>
>> The
>> individual clocks in a composite clock did not have the ->dev field
>> filled in. This was fine, because the device-specific clock
>> information would be used. However, since there was no ->dev, there
>> was no way to get the parent clock. 
> 
> Wasn't there any back pointer available? Or do we need to search the
> clocks linked list and look for "bind" flag in top level composite
> clock?

This is just what the clk_get_parent [1] function does.

[1] 
https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/clk/clk-uclass.c#L447

> 
>> This caused the recalc_rate
>> method of the CCF divider clock to fail. One option would be to use
>> the clk->priv field to get the composite clock and from there get the
>> appropriate parent device. However, this would tie the implementation
>> to the composite clock. In general, different devices should not rely
>> on the contents of ->priv from another device.
> 
> Maybe we shall follow:
> https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/clk/ccf.txt#L40

I think this might be a better option. I just didn't see any other uses of this 
pointer in the u-boot
code. 

>>
>> The simple solution to this problem is to just always use the
>> supplied struct clock. 
> 
> I think that we took this approach in the past. Unfortunately, this
> caused all clocks being exposed when 'clk' command was run.

This is discussed further below, but an easy option is to just not
register the component clocks.

The real problem with the current approach (IMO) is that there is a
mismatch between the clock structure and the clock function. If one
calls clk_get_rate on some clock, the get_rate function is chosen based
on clk->dev->ops. If that clock is a composite clock, the
clk_composite_get_rate will then choose the *real* get_rate function to
call, and will call it with the appropriate component clock. But then,
the get_rate function says "Aha, I know better than you what clock
should be passed to me" and calls itself with the composite clock struct
instead! This is really unintitive behaviour. If anything, this kind of
behaviour should be moved up to clk_get_rate, where it can't cause any
harm in composite clocks.

> 
> Peng - were there any other issues with i.MX8 composite clock
> implementation?
> 
>> The composite clock now fills in the ->dev
>> pointer of its child clocks. This allows child clocks to make calls
>> like clk_get_parent() without issue.
>>
>> imx avoided the above problem by using a custom get_rate function
>> with composite clocks.
> 
> Do you refer to:
> https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/clk/imx/clk-composite-8m.c#L30
> 
> There the clk is cast from (struct clk_composite *)clk->data
> 
> (now in U-Boot we do have 4! different implementations of struct clk).
>

Yes. This was really surprising when I saw it the first time, since it
is effectively bypassing clk_composite_*.

>>
>> Signed-off-by: Sean Anderson 
>> ---
>>  drivers/clk/clk-composite.c|  8 
>>  drivers/clk/clk-divider.c  |  6 ++
>>  drivers/clk/clk-fixed-factor.c |  3 +--
>>  drivers/clk/clk-gate.c 

Re: [PATCH v2 05/11] riscv: Add option to disable writes to mcounteren

2020-01-26 Thread Lukas Auer
+ Bin, Anup, Atish


On Wed, 2020-01-15 at 17:53 -0500, Sean Anderson wrote:
> On the kendryte k210, writes to mcounteren result in an illegal instruction
> exception.
> 
> Signed-off-by: Sean Anderson 
> ---
> Changes for v2:
>  Moved forward in the patch series
> 
>  arch/riscv/Kconfig   | 3 +++
>  arch/riscv/cpu/cpu.c | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 9a7b0334c2..4f8c62dcff 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -226,6 +226,9 @@ config XIP
> from a NOR flash memory without copying the code to ram.
> Say yes here if U-Boot boots from flash directly.
>  
> +config SYS_RISCV_NOCOUNTER
> + bool "Disable accesses to the mcounteren CSR"
> +

Can you rename this to something like RISCV_PRIV_1_9_1?

The k210 implements version 1.9.1 of the privileged spec (if I remember
correctly). The mcounteren CSR doesn't exist in that version and
therefore triggers the illegal instruction exception. By renaming the
config entry, it is clearer why the CSR is missing and is therefore not
accessed.
I am not too familiar with the changes between the versions of the
spec. Are there other parts of the code we need to adapt?

Thanks,
Lukas

>  config STACK_SIZE_SHIFT
>   int
>   default 14
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index e457f6acbf..df9eae663c 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -89,7 +89,9 @@ int arch_cpu_init_dm(void)
>* Enable perf counters for cycle, time,
>* and instret counters only
>*/
> +#ifndef CONFIG_SYS_RISCV_NOCOUNTER
>   csr_write(CSR_MCOUNTEREN, GENMASK(2, 0));
> +#endif
>  
>   /* Disable paging */
>   if (supports_extension('s'))


Re: [PATCH v2 03/11] riscv: Add headers for asm/global_data.h

2020-01-26 Thread Sean Anderson
On 1/26/20 5:04 PM, Lukas Auer wrote:
> asm/u-boot.h is usually included with common.h. ulong is defined in
> linux/types.h (also included in common.h). It should be sufficient to
> include common.h in your source files.
> 
> Thanks,
> Lukas

So shouldn't asm/u-boot.h include common.h? Or is that header implicitly
assumed to be included with every source file? Is that documented
anywhere? To me, the "default" assumption is that any header should be
able to be included anywhere and to pull in all of its own dependencies.

--Sean


Re: [PATCH v2 07/11] riscv: Add initial Sipeed Maix support

2020-01-26 Thread Lukas Auer
Hi Sean,


On Wed, 2020-01-15 at 18:04 -0500, Sean Anderson wrote:
> The Sipeed Maix series is a collection of boards built around the RISC-V
> Kendryte K210 processor. This processor contains several peripherals to
> accelerate neural network processing and other "ai" tasks. This includes a 
> "KPU"
> neural network processor, an audio processor supporting beamforming reception,
> and a digital video port supporting capture and output at VGA resolution. 
> Other
> peripherals include 8M of sram (accessible with and without caching);
> remappable pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA
> controller; and I2C, I2S, and SPI controllers. Maix peripherals vary, but
> include spi flash; on-board usb-serial bridges; ports for cameras, displays, 
> and
> sd cards; and ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is
> supported, but the boards are fairly similar.
> 
> Documentation for Maix boards is located at ;.
> Documentation for the Kendryte K210 is located at
> ;. However, hardware details are rather 
> lacking,
> so most technical reference has been taken from the standalone sdk located at
> ;.
> 
> Signed-off-by: Sean Anderson 

This patch should be the last in the patch series, because it requires
all other patches in the series.

> ---
> Changes for v2:
>   Select CONFIG_SYS_RISCV_NOCOUNTER.
>   Imply CONFIG_CLK_K210.
>   Remove spurious references to CONFIG_ARCH_K210.
>   Remove many configs from defconfig where the defaults were fine.
>   Add a few "not set" lines to suppress unneeded defaults.
>   Reduce pre-reloc malloc space, now that clocks initialization happens
>   later.
>   
>  arch/riscv/Kconfig |  4 ++
>  board/sipeed/maix/Kconfig  | 41 +
>  board/sipeed/maix/MAINTAINERS  | 13 +
>  board/sipeed/maix/Makefile |  5 ++
>  board/sipeed/maix/maix.c   |  9 +++
>  configs/sipeed_maix_bitm_defconfig | 93 ++
>  include/configs/sipeed-maix.h  | 19 ++
>  7 files changed, 184 insertions(+)
>  create mode 100644 board/sipeed/maix/Kconfig
>  create mode 100644 board/sipeed/maix/MAINTAINERS
>  create mode 100644 board/sipeed/maix/Makefile
>  create mode 100644 board/sipeed/maix/maix.c
>  create mode 100644 configs/sipeed_maix_bitm_defconfig
>  create mode 100644 include/configs/sipeed-maix.h
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 4f8c62dcff..4c62b8dd77 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
>  config TARGET_SIFIVE_FU540
>   bool "Support SiFive FU540 Board"
>  
> +config TARGET_SIPEED_MAIX
> + bool "Support Sipeed Maix Board"
> +
>  endchoice
>  
>  config SYS_ICACHE_OFF
> @@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"
>  source "board/microchip/mpfs_icicle/Kconfig"
>  source "board/sifive/fu540/Kconfig"
> +source "board/sipeed/maix/Kconfig"
>  
>  # platform-specific options below
>  source "arch/riscv/cpu/ax25/Kconfig"
> diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
> new file mode 100644
> index 00..9259eb34aa
> --- /dev/null
> +++ b/board/sipeed/maix/Kconfig
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2019 Sean Anderson 
> +
> +if TARGET_SIPEED_MAIX
> +
> +config SYS_BOARD
> + default "maix"
> +
> +config SYS_VENDOR
> + default "sipeed"
> +
> +config SYS_CPU
> + default "generic"
> +
> +config SYS_CONFIG_NAME
> + default "sipeed-maix"
> +
> +config SYS_TEXT_BASE
> + default 0x8000
> +
> +config NR_CPUS
> + default 2
> +
> +config NR_DRAM_BANKS
> + default 2
> +
> +config BOARD_SPECIFIC_OPTIONS
> + def_bool y
> + select GENERIC_RISCV
> + select DM_SERIAL
> + select SIFIVE_SERIAL
> + select ARCH_DEFAULT_RV64I
> + select ENV_IS_NOWHERE

ENV_IS_NOWHERE is automatically selected if no other environment
provider is available, so no need to include it here.
Also, why are you not using the SD card to store the environment?

> + select SYS_RISCV_NOCOUNTER
> + imply SIFIVE_CLINT
> + imply SPI
> + imply DM_GPIO
> + imply CMD_GPIO
> + imply SYS_NS16550
> + imply SYS_MALLOC_F
> +endif
> diff --git a/board/sipeed/maix/MAINTAINERS b/board/sipeed/maix/MAINTAINERS
> new file mode 100644
> index 00..217de45970
> --- /dev/null
> +++ b/board/sipeed/maix/MAINTAINERS
> @@ -0,0 +1,13 @@
> +Sipeed Maix BOARD
> +M:   Sean Anderson 
> +S:   Maintained
> +F:   arch/riscv/dts/k210.dtsi
> +F:   arch/riscv/dts/k210-maix-bit.dts
> +F:   arch/riscv/include/asm/k210_sysctl.h
> +F:   arch/riscv/lib/k210_sysctl.c
> +F:   board/sipeed/maix/
> +F:   configs/sipeed_maix_defconfig
> +F:   drivers/clk/kendryte/
> +F:   include/configs/sipeed-maix.h
> +F:   include/dt-bindings/cloc

Re: [PATCH v2 03/11] riscv: Add headers for asm/global_data.h

2020-01-26 Thread Lukas Auer
On Sun, 2020-01-26 at 17:12 -0500, Sean Anderson wrote:
> On 1/26/20 5:04 PM, Lukas Auer wrote:
> > asm/u-boot.h is usually included with common.h. ulong is defined in
> > linux/types.h (also included in common.h). It should be sufficient to
> > include common.h in your source files.
> > 
> > Thanks,
> > Lukas
> 
> So shouldn't asm/u-boot.h include common.h? Or is that header implicitly
> assumed to be included with every source file? Is that documented
> anywhere? To me, the "default" assumption is that any header should be
> able to be included anywhere and to pull in all of its own dependencies.
> 

You are right, it is not entirely correct like this. I think common.h
is assumed to always be included. Unfortunately, I don't know if this
is documented anywhere.

Thanks,
Lukas


Re: [PATCH v2 05/11] riscv: Add option to disable writes to mcounteren

2020-01-26 Thread Sean Anderson
On 1/26/20 5:09 PM, Lukas Auer wrote:
> + Bin, Anup, Atish
> 
> 
> On Wed, 2020-01-15 at 17:53 -0500, Sean Anderson wrote:
>> On the kendryte k210, writes to mcounteren result in an illegal instruction
>> exception.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>> Changes for v2:
>>  Moved forward in the patch series
>>
>>  arch/riscv/Kconfig   | 3 +++
>>  arch/riscv/cpu/cpu.c | 2 ++
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 9a7b0334c2..4f8c62dcff 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -226,6 +226,9 @@ config XIP
>>from a NOR flash memory without copying the code to ram.
>>Say yes here if U-Boot boots from flash directly.
>>  
>> +config SYS_RISCV_NOCOUNTER
>> +bool "Disable accesses to the mcounteren CSR"
>> +
> 
> Can you rename this to something like RISCV_PRIV_1_9_1?
> 
> The k210 implements version 1.9.1 of the privileged spec (if I remember
> correctly). The mcounteren CSR doesn't exist in that version and
> therefore triggers the illegal instruction exception. By renaming the
> config entry, it is clearer why the CSR is missing and is therefore not
> accessed.

Thanks, I was not aware that the k210 was following a different spec
when I made the change. For v3 I can add this functionality back using
the old counter CSRs.

> I am not too familiar with the changes between the versions of the
> spec. Are there other parts of the code we need to adapt?

>From reading the changelog, most of the changes seem related to virtual
memory, which doesn't apply to u-boot.

--Sean


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

2020-01-26 Thread Lukas Auer
On Sun, 2020-01-26 at 13:20 -0500, Sean Anderson wrote:
> On 1/26/20 11:34 AM, Lukas Auer wrote:
> > Hi Sean,
> > Usually, ret is used as a variable name here. I think it would actually
> > make the code a bit nicer to read here, because the clock rate is not
> > read from variable err.
> 
> Hm, I chose err instead of ret since that variable is never the return
> value of the function. I can change that for v2 if you'd like.
> 

Makes sense. I think it's fine to keep it as is.

> > But that's just nit-picking. The patch looks good otherwise!
> > 
> > Reviewed-by: Lukas Auer 
> 
> 


[PATCH v4 08/12] arm: mvebu: enable working default boot support

2020-01-26 Thread Joel Johnson
With the move to driver model usage, ensure that the required driver
support for SPI and MMC booting is available in SPL.

Tested on SolidRun ClearFog devices.

Signed-off-by: Joel Johnson 
---

v2 changes:
  - change "select" for ENV_IS_IN_X to "imply" to allow disabling the
default env location and configuring a different one if desired
  - remove SPL_DM_GPIO from defconfig, only include if needed for
MMC booting
v3 changes:
  - none
v4 changes:
  - none

---
 arch/arm/mach-mvebu/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 161dee937f..32191e7157 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -235,9 +235,19 @@ choice
 
 config MVEBU_SPL_BOOT_DEVICE_SPI
bool "SPI NOR flash"
+   imply ENV_IS_IN_SPI_FLASH
+   select SPL_DM_SPI
+   select SPL_MTD_SUPPORT
+   select SPL_SPI_FLASH_SUPPORT
+   select SPL_SPI_LOAD
+   select SPL_SPI_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_MMC
bool "SDIO/MMC card"
+   imply ENV_IS_IN_MMC
+   # GPIO required for SD card presence detection line
+   select SPL_DM_GPIO
+   select SPL_DM_MMC
select SPL_LIBDISK_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
-- 
2.20.1



[PATCH v4 01/12] arm: mvebu: fix SerDes table alignment

2020-01-26 Thread Joel Johnson
Tested on Solidrun ClearFog Base. Table alignment was:
 | Lane #  | Speed |  Type   |
 
 |   0|  3   |  SATA0   |
 |   1|  0   |  SGMII1  |
 |   2|  3   |  SATA1   |
 |   3|  5   |  USB3 HOST1  |
 |   4|  5   |  USB3 HOST0  |
 |   5|  4   |  SGMII2  |
 

After the change, it's correctly aligned as:
 | Lane # | Speed |  Type   |
 
 |   0|   3   | SATA0   |
 |   1|   0   | SGMII1  |
 |   2|   5   | PCIe1   |
 |   3|   5   | USB3 HOST1  |
 |   4|   5   | PCIe2   |
 |   5|   0   | SGMII2  |
 

Signed-off-by: Joel Johnson 

---

v2 changes
  - none
v3 changes
  - none
v4 changes
  - none

---
 arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 33e70569bc..66409a50c0 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -1366,16 +1366,16 @@ static void print_topology_details(const struct 
serdes_map *serdes_map,
 
DEBUG_INIT_S("board SerDes lanes topology details:\n");
 
-   DEBUG_INIT_S(" | Lane #  | Speed |  Type   |\n");
+   DEBUG_INIT_S(" | Lane # | Speed |  Type   |\n");
DEBUG_INIT_S(" \n");
for (lane_num = 0; lane_num < count; lane_num++) {
if (serdes_map[lane_num].serdes_type == DEFAULT_SERDES)
continue;
DEBUG_INIT_S(" |   ");
DEBUG_INIT_D(hws_get_physical_serdes_num(lane_num), 1);
-   DEBUG_INIT_S("|  ");
+   DEBUG_INIT_S("|   ");
DEBUG_INIT_D(serdes_map[lane_num].serdes_speed, 2);
-   DEBUG_INIT_S("   |  ");
+   DEBUG_INIT_S("   | ");
DEBUG_INIT_S((char *)
 serdes_type_to_string[serdes_map[lane_num].
   serdes_type]);
-- 
2.20.1



[PATCH v4 03/12] arm: mvebu: clearfog: use Pro name by default

2020-01-26 Thread Joel Johnson
Make the board version printed indicate the Pro variant default.
Also adjust static name casing to match what is expected for
EEPROM product name to share string constants.

---


Baruch - can you confirm expected/desired branding casing? The SolidRun
website and prior to this commit uses "ClearFog", however the EEPROM
checked values use "Clearfog", so I changed to match to be able to use
the same string constant values for consistency.

Signed-off-by: Joel Johnson 
---
 board/solidrun/clearfog/clearfog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index e268ef55a2..9b31902c70 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -170,7 +170,7 @@ int board_init(void)
 
 int checkboard(void)
 {
-   char *board = "ClearFog";
+   char *board = "Clearfog Pro";
 
cf_read_tlv_data();
if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
-- 
2.20.1



[PATCH v4 04/12] arm: mvebu: clearfog: initial ClearFog Base variant

2020-01-26 Thread Joel Johnson
Add a unique entry for ClearFog Base variant, reflected in the board
name and adjusted SerDes topology.

Signed-off-by: Joel Johnson 

---

v2 changes:
  - reworked based on Baruch's run-time TLV EEPROM detection series
v3 changes:
  - rebased on mvebu merged run-time TLV EEPROM detection series
  - minor update to help test regarding runtime detection failures
v4 changes:
  - use runtime static config adjust instead of #ifdef in cases where
hardware EEPROM detection fails or is disabled in build
SPL size change for defconfig increases 36 bytes (122893 to 122929)
SPL size change for defconfig+Base increases 60 bytes (122893 to 122953)
  - add placeholder support for EEPROM based Clearfog Pro, based on
initial name confirmation from Baruch. I wanted to include the check
at least in the patch for review to indicate expected usage to
ensure that a Clearfog Pro EEPROM device boots correctly even if the
image is built with Base static configuration. If there are other
prerelease concerns and this should be added separately later, I'd
be fine with that too.
  - Note that this approach *does not* currently provide any mechanism
for EEPROM detected boards to have their SFP speed changed or switch
between PCIE/SATA signalling. I'm assuming that will be done based on
hardware detection, but confirmation/acceptance in review would be
appreciated so it can be revisited if needed.

---
 arch/arm/mach-mvebu/Kconfig|  2 ++
 board/solidrun/clearfog/Kconfig| 18 ++
 board/solidrun/clearfog/clearfog.c | 25 ++---
 3 files changed, 42 insertions(+), 3 deletions(-)
 create mode 100644 board/solidrun/clearfog/Kconfig

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index bc5eaa5a76..161dee937f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
default 0
depends on SECURED_MODE_IMAGE
 
+source "board/solidrun/clearfog/Kconfig"
+
 endif
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
new file mode 100644
index 00..936d5918f8
--- /dev/null
+++ b/board/solidrun/clearfog/Kconfig
@@ -0,0 +1,18 @@
+menu "ClearFog configuration"
+   depends on TARGET_CLEARFOG
+
+config TARGET_CLEARFOG_BASE
+   bool "Use ClearFog Base static configuration"
+   help
+ Use the ClearFog Base as the static configuration instead of the
+ default which uses the ClearFog Pro.
+
+ Runtime board detection is always attempted and used if available. The
+ static configuration is used as a fallback in cases where runtime
+ detection is disabled, is not available in hardware, or otherwise 
fails.
+
+ Only newer revisions of the ClearFog product line support runtime
+ detection via additional EEPROM hardware. This option enables 
selecting
+ the Base variant for older hardware revisions.
+
+endmenu
diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 9b31902c70..04238d2b05 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -42,6 +42,7 @@ static void cf_read_tlv_data(void)
read_tlv_data(&cf_tlv_data);
 }
 
+/* The starting board_serdes_map reflects original Clearfog Pro usage */
 static struct serdes_map board_serdes_map[] = {
{SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
@@ -51,6 +52,15 @@ static struct serdes_map board_serdes_map[] = {
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 };
 
+void config_static_serdes_map(void)
+{
+   if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
+   board_serdes_map[4].serdes_type = USB3_HOST0;
+   board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
+   board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+   }
+}
+
 int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 {
cf_read_tlv_data();
@@ -59,12 +69,17 @@ int hws_board_topology_load(struct serdes_map 
**serdes_map_array, u8 *count)
board_serdes_map[0].serdes_type = PEX0;
board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
-   }
-
-   if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
+   } else if (sr_product_is(&cf_tlv_data, "Clearfog Pro")) {
+   /* handle recognized product as noop, no adjustment required */
+   } else if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
board_serdes_map[4].serdes_type = USB3_HOST0;
board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+   } else {
+   /* fallback to static default since runtime 

[PATCH v4 07/12] arm: mvebu: clearfog: add SPI offsets

2020-01-26 Thread Joel Johnson
Add reasonable default SPI offsets and ENV size when configured to
boot from SPI flash.

Signed-off-by: Joel Johnson 

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none

There was some reasonable concern raised about duplicating config
entries within a board specific config file rather than making
board specific configurations within defconfig. This seems to offer
a more board localized mechanism to provide platform defaults for
core values. As mentioned in the review, this usage seems to match
the Kconfig documented intended usage. As noted at
https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html:
"Default values are not limited to the menu entry where
 they are defined. This means the default can be defined
 somewhere else or be overridden by an earlier definition."

Given that there is some dependency variability with these values I
prefer keeping them as Kconfig values, but defer to maintainers.
Notably, for the ENV values in this and a later commit, I'm using a
pattern already in used several other board configs.

---
 board/solidrun/clearfog/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index c910e17093..d3209d9b8e 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -22,4 +22,16 @@ config CLEARFOG_SFP_25GB
  SGMII connection (requires a supporting SFP). By default, transfer 
speed
  of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
 
+config ENV_SECT_SIZE
+   hex "Environment Sector-Size"
+   # Use SPI flash erase block size of 4 KiB
+   default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
+   # Use optimistic 64 KiB erase block, will vary between actual media
+   default 0x1 if MVEBU_SPL_BOOT_DEVICE_MMC
+
+config SYS_SPI_U_BOOT_OFFS
+   hex "address of u-boot payload in SPI flash"
+   default 0x2
+   depends on MVEBU_SPL_BOOT_DEVICE_SPI
+
 endmenu
-- 
2.20.1



[PATCH v4 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address

2020-01-26 Thread Joel Johnson
Using a consistent hardcoded MAC address from the DTS file causes
issues when using multiple devices on the same network segment.
Instead rely on environment configuration or random generation.

Signed-off-by: Joel Johnson 

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none

---
 arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi 
b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
index a322a28c21..9bbeafc53b 100644
--- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
@@ -39,7 +39,6 @@
 
 ð0 {
/* ethernet@7 */
-   mac-address = [00 50 43 02 02 01];
pinctrl-0 = <&ge0_rgmii_pins>;
pinctrl-names = "default";
phy = <&phy_dedicated>;
-- 
2.20.1



[PATCH v4 09/12] arm: mvebu: clearfog: move ENV params to Kconfig

2020-01-26 Thread Joel Johnson
Migrate the values for ENV_SIZE and ENV_OFFSET into board specific
Kconfig defaults so they're more accessible for configuration.

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none

Signed-off-by: Joel Johnson 
---
 board/solidrun/clearfog/Kconfig | 8 
 configs/clearfog_defconfig  | 2 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index d3209d9b8e..fbaeed1a4f 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -22,6 +22,14 @@ config CLEARFOG_SFP_25GB
  SGMII connection (requires a supporting SFP). By default, transfer 
speed
  of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
 
+config ENV_SIZE
+   hex "Environment Size"
+   default 0x1
+
+config ENV_OFFSET
+   hex "Environment offset"
+   default 0xF
+
 config ENV_SECT_SIZE
hex "Environment Sector-Size"
# Use SPI flash erase block size of 4 KiB
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index c938448c30..6db8b8acf6 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -9,8 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
-CONFIG_ENV_SIZE=0x1
-CONFIG_ENV_OFFSET=0xF
 CONFIG_DM_GPIO=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
-- 
2.20.1



[PATCH v4 00/12] ClearFog Base static variant support

2020-01-26 Thread Joel Johnson


This patch series adds support for ClearFog Base static configuration,
as well as updating and fixing the ClearFog support for MMC and SPI
booting.

v2 changes:
  - updated against, and dependent on, 
https://patchwork.ozlabs.org/cover/1200324
v3 changes:
  - rebased against ClearFog runtime TLV EEPROM changes merged into mvebu/master
v4
  - adjust static SerDes configuration at runtime instead of #ifdef


Joel Johnson (12):
  arm: mvebu: fix SerDes table alignment
  arm: mvebu: solidrun: remove hardcoded DTS MAC address
  arm: mvebu: clearfog: use Pro name by default
  arm: mvebu: clearfog: initial ClearFog Base variant
  arm: mvebu: clearfog: Unify DT selection paths
  arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  arm: mvebu: clearfog: add SPI offsets
  arm: mvebu: enable working default boot support
  arm: mvebu: clearfog: move ENV params to Kconfig
  arm: mvebu: clearfog: don't always use SPL MMC
  arm: mvebu: clearfog: Add SATA mode flags
  arm: mvebu: clearfog: Use Pro DT by default

 .../arm/dts/armada-38x-solidrun-microsom.dtsi |  1 -
 arch/arm/mach-mvebu/Kconfig   | 13 
 .../serdes/a38x/high_speed_env_spec.c |  6 +-
 board/solidrun/clearfog/Kconfig   | 62 +++
 board/solidrun/clearfog/clearfog.c| 44 +++--
 configs/clearfog_defconfig|  4 --
 include/configs/clearfog.h|  1 -
 7 files changed, 118 insertions(+), 13 deletions(-)
 create mode 100644 board/solidrun/clearfog/Kconfig

-- 
2.20.1



[PATCH v4 10/12] arm: mvebu: clearfog: don't always use SPL MMC

2020-01-26 Thread Joel Johnson
Move MMC booting assuptions from defconfig to Kconfig which
includes as needed based on dependent options.

Signed-off-by: Joel Johnson 
---

v2 changes:
  - rebased on master to use Baruch's dynamic MMC/SD offset logic
  - update description, will revisit removal of
CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC in separate future path if a
more viable option is identified
v3 changes:
  - none
v4 changes:
  - none

---
 arch/arm/mach-mvebu/Kconfig | 1 +
 configs/clearfog_defconfig  | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 32191e7157..4b381a2936 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -249,6 +249,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
select SPL_DM_GPIO
select SPL_DM_MMC
select SPL_LIBDISK_SUPPORT
+   select SPL_MMC_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
bool "SATA"
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 6db8b8acf6..601b1997ed 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
 CONFIG_DM_GPIO=y
-CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL=y
@@ -42,7 +41,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 # CONFIG_SPL_PARTITION_UUIDS is not set
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
-CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_AHCI_MVEBU=y
-- 
2.20.1



[PATCH v4 06/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP

2020-01-26 Thread Joel Johnson
While newer Linux kernels provide autoconfiguration of SFP, provide
an option for setting in U-Boot Kconfig for use prior to booting.

Signed-off-by: Joel Johnson 

---

v2 changes:
  - fixed help indentation
v3 changes:
  - none
v4 changes:
  - adjust static SerDes configuration at runtime instead of #ifdef

---
 board/solidrun/clearfog/Kconfig| 7 +++
 board/solidrun/clearfog/clearfog.c | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 936d5918f8..c910e17093 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
  detection via additional EEPROM hardware. This option enables 
selecting
  the Base variant for older hardware revisions.
 
+config CLEARFOG_SFP_25GB
+   bool "Enable 2.5 Gbps mode for SFP"
+   help
+ Set the SFP module connection to support 2.5 Gbps transfer speed for 
the
+ SGMII connection (requires a supporting SFP). By default, transfer 
speed
+ of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
+
 endmenu
diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 4019e37016..6c5b9a784f 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -59,6 +59,9 @@ void config_static_serdes_map(void)
board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
}
+
+   if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
+   board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
 }
 
 int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
-- 
2.20.1



[PATCH v4 11/12] arm: mvebu: clearfog: Add SATA mode flags

2020-01-26 Thread Joel Johnson
The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
configured for SATA usage.

Signed-off-by: Joel Johnson 

---

v2 changes:
  - fixed help indentation
v3 changes:
  - none
v4 changes:
  - adjust static SerDes configuration at runtime instead of #ifdef
  - add setting of swap_rx for SATA (as yet untested on hardware)

Baruch, thanks for the pointer on the swap_rx flags. I've added them
here based on your input, my drives for testing are in another office so
I won't be able to do final testing on the updated series for another
day or so.

---
 board/solidrun/clearfog/Kconfig| 17 +
 board/solidrun/clearfog/clearfog.c | 12 
 2 files changed, 29 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index fbaeed1a4f..e8c3f53d84 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -15,6 +15,23 @@ config TARGET_CLEARFOG_BASE
  detection via additional EEPROM hardware. This option enables 
selecting
  the Base variant for older hardware revisions.
 
+config CLEARFOG_CON3_SATA
+   bool "Use CON3 slot in SATA mode"
+   help
+ Use the CON3 port with SATA protocol instead of the default PCIe.
+ The ClearFog port allows usage of either mSATA or miniPCIe
+ modules, but the desired protocol must be configured at build
+ time since it affects the SerDes topology layout.
+
+config CLEARFOG_CON2_SATA
+   bool "Use CON2 slot in SATA mode"
+   depends on !TARGET_CLEARFOG_BASE
+   help
+ Use the CON2 port with SATA protocol instead of the default PCIe.
+ The ClearFog port allows usage of either mSATA or miniPCIe
+ modules, but the desired protocol must be configured at build
+ time since it affects the SerDes topology layout.
+
 config CLEARFOG_SFP_25GB
bool "Enable 2.5 Gbps mode for SFP"
help
diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 6c5b9a784f..3867855aff 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -58,6 +58,18 @@ void config_static_serdes_map(void)
board_serdes_map[4].serdes_type = USB3_HOST0;
board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+   } else if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA)) {
+   board_serdes_map[4].serdes_type = SATA2;
+   board_serdes_map[4].serdes_speed = SERDES_SPEED_3_GBPS;
+   board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+   board_serdes_map[4].swap_rx = 1;
+   }
+
+   if (IS_ENABLED(CONFIG_CLEARFOG_CON3_SATA)) {
+   board_serdes_map[2].serdes_type = SATA1;
+   board_serdes_map[2].serdes_speed = SERDES_SPEED_3_GBPS;
+   board_serdes_map[2].serdes_mode = SERDES_DEFAULT_MODE;
+   board_serdes_map[2].swap_rx = 1;
}
 
if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
-- 
2.20.1



[PATCH v4 05/12] arm: mvebu: clearfog: Unify DT selection paths

2020-01-26 Thread Joel Johnson
Unify the location of DT selection into board_late_init instead of
split between detection and static configuration paths.

---

v2 changes
  - newly added in V2 series based on run-time rebasing
v3 changes
  - none
v4 changes
  - separate change to explicit pro DT into separate commit

Signed-off-by: Joel Johnson 
---
 board/solidrun/clearfog/clearfog.c | 2 ++
 include/configs/clearfog.h | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 04238d2b05..4019e37016 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -219,6 +219,8 @@ int board_late_init(void)
env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
env_set("fdtfile", "armada-388-clearfog-base.dtb");
+   else
+   env_set("fdtfile", "armada-388-clearfog.dtb");
 
return 0;
 }
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index 633187d86f..6ca0474461 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -134,7 +134,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
RELOCATION_LIMITS_ENV_SETTINGS \
LOAD_ADDRESS_ENV_SETTINGS \
-   "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"console=ttyS0,115200\0" \
BOOTENV
 
-- 
2.20.1



[PATCH v4 12/12] arm: mvebu: clearfog: Use Pro DT by default

2020-01-26 Thread Joel Johnson
Switch to explicitly using the Pro variant DT, which has been
available since Linux 4.11.

---


I separated out this change to the end of the series since it drew
questioning on prior review. I'd still advocate for making the change,
since especially with the additions of static variants and runtime
detection, it becomes easier from within a booted kernel to identify the
type and version of U-Boot image installed. Without making this change,
it becomes less direct to determine an actual Pro vs. Base, vs old
U-Boot image maybe supporting some hybrid variant configuration.

Even in the Linux kernel adding of the Pro DTS, it is indicated that it
was meant for backwards compatibility.

Except for cases where checking is done directly against the product
name from userspace, I don't see downsides even from a compatibility
perspective for not making this change. In cases where checking *is*
done from userspace, the broadening of the Clearfog product line would
seem to mean that userspace checking should be flagged as needing to be
udpated as well (or glob/regex matched as needed).

Signed-off-by: Joel Johnson 
---
 board/solidrun/clearfog/clearfog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 3867855aff..31b279d365 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -235,7 +235,7 @@ int board_late_init(void)
else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
env_set("fdtfile", "armada-388-clearfog-base.dtb");
else
-   env_set("fdtfile", "armada-388-clearfog.dtb");
+   env_set("fdtfile", "armada-388-clearfog-pro.dtb");
 
return 0;
 }
-- 
2.20.1



Re: [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT

2020-01-26 Thread Marek Vasut
On 8/20/19 7:41 PM, Vagrant Cascadian wrote:
> On 2019-08-19, Marek Vasut wrote:
>> On 6/4/19 9:06 AM, Vagrant Cascadian wrote:
>>> On 2019-05-17, Marek Vasut wrote:
 Update Kosagi Novena to DM / DT and remove the warnings.
> ...
>>> I have two oustanding issues... with some files it sometimes fails to
>>> load one or more from SATA:
>>>
>>> Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp
>>> 20077960 bytes read in 375 ms (51.1 MiB/s)
>>> Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp
>>> 4215296 bytes read in 40 ms (100.5 MiB/s)
>>> append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet
>>> Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb
>>> CACHE: Misaligned operation at range [fafb5398, fafb6398]
>>> CACHE: Misaligned operation at range [fafb5398, fafb6398]
>>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>>> 0xfafb5398
>>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>>> 0xfafb6398
>>> invalid extent block
>>>
>>> It then falls back to one of the other kernels (using the extlinux.conf
>>> parsing) and succeeds. It consistantly gets a cache/alignment error with
>>> this specific file. A bit-for-bit identical .dtb loaded from another
>>> path works just fine. Older versions of u-boot boot this fine. Would
>>> some particular EXT4 flag possibly be causing issues?
>>
>> I don't know. Do you still run into this with u-boot/master ?
> 
> Still occurring with 2019.10-rc2. Haven't tested with master yet.
> 
> Using "dcache off" before booting still outputs the CACHE and ERROR
> messages, but does successfully boot.
> 
> 
>>> The second issue is still using one out of four exposed USB ports fails
>>> and resets the board:
>>>
>>> load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image
>>> data abort
>>> pc : []  lr : []
>>> reloc pc : [<1783367a>]lr : [<178330fd>]
>>> sp : faf7c6e8  ip : 0003 fp : 0005
>>> r10: faf8b200  r9 : faf87ea0 r8 : 0001
>>> r7 : faf8b2c0  r6 : f9f7a040 r5 : faf7c710  r4 : 0038
>>> r3 : 006d  r2 : f9f7a0a3 r1 : faf8b32c  r0 : f9f7a09f
>>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>>> Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c)
>>> Resetting CPU ...
>>>
>>> The three other usb ports work just fine with the same USB stick and
>>> file. All four ports work with 2019.01.
>>
>> Can you debug it ? I think some of this was due to the EFI stuff , which
>> I think was fixed since. Can you re-check that ?
> 
> USB appears to be working fine with 2019.10-rc2.

So what's the current status ?


[PATCH 2/3] ARM: imx: novena: Enable DM ethernet

2020-01-26 Thread Marek Vasut
Convert to DM ethernet to prevent board removal.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Stefano Babic 
Cc: Vagrant Cascadian 
---
 arch/arm/mach-imx/mx6/Kconfig | 1 +
 configs/novena_defconfig  | 2 ++
 include/configs/novena.h  | 9 ++---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 811c41d906..f9f576d403 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -259,6 +259,7 @@ config TARGET_GW_VENTANA
 config TARGET_KOSAGI_NOVENA
bool "Kosagi Novena"
select BOARD_LATE_INIT
+   select DM_ETH
select DM_GPIO
select DM_MMC
select DM_PCI
diff --git a/configs/novena_defconfig b/configs/novena_defconfig
index 2fd89b2939..b20bbab454 100644
--- a/configs/novena_defconfig
+++ b/configs/novena_defconfig
@@ -53,6 +53,8 @@ CONFIG_FSL_USDHC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_FEC_MXC=y
+CONFIG_RGMII=y
 CONFIG_MII=y
 CONFIG_PCI=y
 CONFIG_PINCTRL=y
diff --git a/include/configs/novena.h b/include/configs/novena.h
index c03b8db2ba..2b8419563c 100644
--- a/include/configs/novena.h
+++ b/include/configs/novena.h
@@ -53,13 +53,8 @@
 #include "imx6_spl.h"  /* common IMX6 SPL configuration */
 
 /* Ethernet Configuration */
-#ifdef CONFIG_CMD_NET
-#define CONFIG_FEC_MXC
-#define IMX_FEC_BASE   ENET_BASE_ADDR
-#define CONFIG_FEC_XCV_TYPERGMII
-#define CONFIG_ETHPRIME"FEC"
-#define CONFIG_FEC_MXC_PHYADDR 0x7
-#define CONFIG_ARP_TIMEOUT 200UL
+#ifdef CONFIG_SPL_BUILD
+#undef CONFIG_DM_ETH
 #endif
 
 /* I2C */
-- 
2.24.1



[PATCH 1/3] ARM: imx: novena: Move defconfig bits to arch Kconfig

2020-01-26 Thread Marek Vasut
Just move the defconfig entries which are required into the Novena
entry in arch Kconfig, no functional change.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Stefano Babic 
Cc: Vagrant Cascadian 
---
 arch/arm/mach-imx/mx6/Kconfig | 8 
 configs/novena_defconfig  | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 9d91f9ab44..811c41d906 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -259,7 +259,15 @@ config TARGET_GW_VENTANA
 config TARGET_KOSAGI_NOVENA
bool "Kosagi Novena"
select BOARD_LATE_INIT
+   select DM_GPIO
+   select DM_MMC
+   select DM_PCI
+   select DM_SCSI
+   select DM_USB
+   select DM_VIDEO
+   select OF_CONTROL
select SUPPORT_SPL
+   imply CMD_DM
 
 config TARGET_MCCMON6
bool "mccmon6"
diff --git a/configs/novena_defconfig b/configs/novena_defconfig
index f14f82b9a6..2fd89b2939 100644
--- a/configs/novena_defconfig
+++ b/configs/novena_defconfig
@@ -8,7 +8,6 @@ CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_KOSAGI_NOVENA=y
 CONFIG_ENV_SIZE=0x4000
 CONFIG_ENV_OFFSET=0x8
-CONFIG_DM_GPIO=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
@@ -33,7 +32,6 @@ CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_EEPROM=y
-CONFIG_CMD_DM=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
@@ -44,7 +42,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_PARTITION_UUIDS is not set
-CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-novena"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
@@ -52,19 +49,15 @@ CONFIG_ENV_OFFSET_REDUND=0x84000
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-CONFIG_DM_MMC=y
 CONFIG_FSL_USDHC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_MII=y
 CONFIG_PCI=y
-CONFIG_DM_PCI=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
-CONFIG_DM_SCSI=y
 CONFIG_USB=y
-CONFIG_DM_USB=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
@@ -74,7 +67,6 @@ CONFIG_USB_ETH_CDC=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_SMSC95XX=y
-CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_BPP16=y
 CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_VIDEO_IPUV3=y
-- 
2.24.1



[PATCH 3/3] ARM: imx: novena: Enable DM thermal

2020-01-26 Thread Marek Vasut
Enable DM thermal driver and iMX thermal driver to get accurate
CPU frequency reporting in the boot log.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Stefano Babic 
Cc: Vagrant Cascadian 
---
 configs/novena_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/novena_defconfig b/configs/novena_defconfig
index b20bbab454..0967d2d284 100644
--- a/configs/novena_defconfig
+++ b/configs/novena_defconfig
@@ -59,6 +59,8 @@ CONFIG_MII=y
 CONFIG_PCI=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
+CONFIG_DM_THERMAL=y
+CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
-- 
2.24.1



Re: [PATCH v2 07/11] riscv: Add initial Sipeed Maix support

2020-01-26 Thread Sean Anderson
On 1/26/20 5:17 PM, Lukas Auer wrote:
> Hi Sean,
> 
> 
> On Wed, 2020-01-15 at 18:04 -0500, Sean Anderson wrote:
>> The Sipeed Maix series is a collection of boards built around the RISC-V
>> Kendryte K210 processor. This processor contains several peripherals to
>> accelerate neural network processing and other "ai" tasks. This includes a 
>> "KPU"
>> neural network processor, an audio processor supporting beamforming 
>> reception,
>> and a digital video port supporting capture and output at VGA resolution. 
>> Other
>> peripherals include 8M of sram (accessible with and without caching);
>> remappable pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA
>> controller; and I2C, I2S, and SPI controllers. Maix peripherals vary, but
>> include spi flash; on-board usb-serial bridges; ports for cameras, displays, 
>> and
>> sd cards; and ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is
>> supported, but the boards are fairly similar.
>>
>> Documentation for Maix boards is located at 
>> ;.
>> Documentation for the Kendryte K210 is located at
>> ;. However, hardware details are rather 
>> lacking,
>> so most technical reference has been taken from the standalone sdk located at
>> ;.
>>
>> Signed-off-by: Sean Anderson 
> 
> This patch should be the last in the patch series, because it requires
> all other patches in the series.

Ok, will reorder it for v3.

>> ---
>> Changes for v2:
>>   Select CONFIG_SYS_RISCV_NOCOUNTER.
>>   Imply CONFIG_CLK_K210.
>>   Remove spurious references to CONFIG_ARCH_K210.
>>   Remove many configs from defconfig where the defaults were fine.
>>   Add a few "not set" lines to suppress unneeded defaults.
>>   Reduce pre-reloc malloc space, now that clocks initialization happens
>>   later.
>>   
>>  arch/riscv/Kconfig |  4 ++
>>  board/sipeed/maix/Kconfig  | 41 +
>>  board/sipeed/maix/MAINTAINERS  | 13 +
>>  board/sipeed/maix/Makefile |  5 ++
>>  board/sipeed/maix/maix.c   |  9 +++
>>  configs/sipeed_maix_bitm_defconfig | 93 ++
>>  include/configs/sipeed-maix.h  | 19 ++
>>  7 files changed, 184 insertions(+)
>>  create mode 100644 board/sipeed/maix/Kconfig
>>  create mode 100644 board/sipeed/maix/MAINTAINERS
>>  create mode 100644 board/sipeed/maix/Makefile
>>  create mode 100644 board/sipeed/maix/maix.c
>>  create mode 100644 configs/sipeed_maix_bitm_defconfig
>>  create mode 100644 include/configs/sipeed-maix.h
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 4f8c62dcff..4c62b8dd77 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
>>  config TARGET_SIFIVE_FU540
>>  bool "Support SiFive FU540 Board"
>>  
>> +config TARGET_SIPEED_MAIX
>> +bool "Support Sipeed Maix Board"
>> +
>>  endchoice
>>  
>>  config SYS_ICACHE_OFF
>> @@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
>>  source "board/emulation/qemu-riscv/Kconfig"
>>  source "board/microchip/mpfs_icicle/Kconfig"
>>  source "board/sifive/fu540/Kconfig"
>> +source "board/sipeed/maix/Kconfig"
>>  
>>  # platform-specific options below
>>  source "arch/riscv/cpu/ax25/Kconfig"
>> diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
>> new file mode 100644
>> index 00..9259eb34aa
>> --- /dev/null
>> +++ b/board/sipeed/maix/Kconfig
>> @@ -0,0 +1,41 @@
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (C) 2019 Sean Anderson 
>> +
>> +if TARGET_SIPEED_MAIX
>> +
>> +config SYS_BOARD
>> +default "maix"
>> +
>> +config SYS_VENDOR
>> +default "sipeed"
>> +
>> +config SYS_CPU
>> +default "generic"
>> +
>> +config SYS_CONFIG_NAME
>> +default "sipeed-maix"
>> +
>> +config SYS_TEXT_BASE
>> +default 0x8000
>> +
>> +config NR_CPUS
>> +default 2
>> +
>> +config NR_DRAM_BANKS
>> +default 2
>> +
>> +config BOARD_SPECIFIC_OPTIONS
>> +def_bool y
>> +select GENERIC_RISCV
>> +select DM_SERIAL
>> +select SIFIVE_SERIAL
>> +select ARCH_DEFAULT_RV64I
>> +select ENV_IS_NOWHERE
> 
> ENV_IS_NOWHERE is automatically selected if no other environment
> provider is available, so no need to include it here.

Ok, I will remove that in v3. As a general rule, what sort of things
should be in Kconfig vs in the default config? I initially thought that
all dependencies should be in Kconfig, but "imply" just seems to set the
default, which means it won't be changed if you pick another board and
then pick this one.

> Also, why are you not using the SD card to store the environment?

I haven't managed to get my SD card working yet. I think it may be too
big (it's 32G), so I am planning to find a smaller one. 

>> +select SYS_RISCV_NOCOUNTER
>> +imply SIFIVE_CLINT
>> +imply SPI
>> +imply DM_GPIO
>> +imply CMD_GPIO
>> +imply SYS_NS16550

[PATCH v3 0/3] Ethernet support for Raspberry Pi 4

2020-01-26 Thread Andre Przywara
This series adds Ethernet support for the Raspberry Pi 4. The SoC
includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
device (no USB anymore!). Patch 1 provides a driver for that. There does
not seem to be publicly available documentation, so this is based on the
Linux driver, but stripped down to just provide what U-Boot needs.
Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
MAC lives in, while patch 3 enables it in the respective defconfigs.

This version fixes the nasty SError issue that showed when booting Linux.
To see the changes as patches, refer to [1].

Please have a look and test it, I hope this helps to simplify
development, as you spare the SD card and its slot from heavy swapping.

Cheers,
Andre.

[1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v3

Changelog v2 ... v3:
- properly reset MAC in eth_probe() to avoid SError in Linux
- disable RX DMA upon stopping the device

Changelog v1 ... v2:
- use native endianess functions when accessing MMIO registers
- use dev_* DM wrappers for accessing devicetree data
- round base and length for flush_dcache_range, plus a comment
- check and round length for invalidate_cache_range
- support RGMII_RXID PHY mode, to support mainline .dtb

Amit Singh Tomar (3):
  net: Add support for Broadcom GENETv5 Ethernet controller
  rpi4: Update memory map to accommodate scb devices
  rpi4: Enable GENET Ethernet controller

 arch/arm/mach-bcm283x/init.c |   6 +-
 configs/rpi_4_32b_defconfig  |   2 +
 configs/rpi_4_defconfig  |   2 +
 configs/rpi_arm64_defconfig  |   1 +
 drivers/net/Kconfig  |   7 +
 drivers/net/Makefile |   1 +
 drivers/net/bcmgenet.c   | 729 +++
 7 files changed, 745 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/bcmgenet.c

-- 
2.14.5



[PATCH v3 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

2020-01-26 Thread Andre Przywara
From: Amit Singh Tomar 

The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
There is no publicly available documentation, so this driver is based
on the Linux driver. Compared to that the queue management is
drastically simplified, also we only support version 5 of the IP and
RGMII connections between MAC and PHY, as used on the RPi4.

Signed-off-by: Amit Singh Tomar 
Reviewed-by: Andre Przywara 
[Andre: heavy cleanup and a few fixes]
Signed-off-by: Andre Przywara 
---
 drivers/net/Kconfig|   7 +
 drivers/net/Makefile   |   1 +
 drivers/net/bcmgenet.c | 729 +
 3 files changed, 737 insertions(+)
 create mode 100644 drivers/net/bcmgenet.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 01d087f229..4d1013c984 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -136,6 +136,13 @@ config BCM6368_ETH
help
  This driver supports the BCM6368 Ethernet MAC.
 
+config BCMGENET
+   bool "BCMGENET V5 support"
+   depends on DM_ETH
+   select PHYLIB
+   help
+ This driver supports the BCMGENET Ethernet MAC.
+
 config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 30991834ec..6e0a68834d 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
 obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
 obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
 obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
+obj-$(CONFIG_BCMGENET) += bcmgenet.o
 obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
 obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
new file mode 100644
index 00..8f4848aec6
--- /dev/null
+++ b/drivers/net/bcmgenet.c
@@ -0,0 +1,729 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amit Singh Tomar 
+ *
+ * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4)
+ * This driver is based on the Linux driver:
+ *  drivers/net/ethernet/broadcom/genet/bcmgenet.c
+ *  which is: Copyright (c) 2014-2017 Broadcom
+ *
+ * The hardware supports multiple queues (16 priority queues and one
+ * default queue), both for RX and TX. There are 256 DMA descriptors (both
+ * for TX and RX), and they live in MMIO registers. The hardware allows
+ * assigning descriptor ranges to queues, but we choose the most simple setup:
+ * All 256 descriptors are assigned to the default queue (#16).
+ * Also the Linux driver supports multiple generations of the MAC, whereas
+ * we only support v5, as used in the Raspberry Pi 4.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register definitions derived from Linux source */
+#define SYS_REV_CTRL   0x00
+
+#define SYS_PORT_CTRL  0x04
+#define PORT_MODE_EXT_GPHY 3
+
+#define GENET_SYS_OFF  0x
+#define SYS_RBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x08)
+#define SYS_TBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x0c)
+
+#define GENET_EXT_OFF  0x0080
+#define EXT_RGMII_OOB_CTRL (GENET_EXT_OFF + 0x0c)
+#define RGMII_LINK BIT(4)
+#define OOB_DISABLEBIT(5)
+#define RGMII_MODE_EN  BIT(6)
+#define ID_MODE_DISBIT(16)
+
+#define GENET_RBUF_OFF 0x0300
+#define RBUF_TBUF_SIZE_CTRL(GENET_RBUF_OFF + 0xb4)
+#define RBUF_CTRL  (GENET_RBUF_OFF + 0x00)
+#define RBUF_ALIGN_2B  BIT(1)
+
+#define GENET_UMAC_OFF 0x0800
+#define UMAC_MIB_CTRL  (GENET_UMAC_OFF + 0x580)
+#define UMAC_MAX_FRAME_LEN (GENET_UMAC_OFF + 0x014)
+#define UMAC_MAC0  (GENET_UMAC_OFF + 0x00c)
+#define UMAC_MAC1  (GENET_UMAC_OFF + 0x010)
+#define UMAC_CMD   (GENET_UMAC_OFF + 0x008)
+#define MDIO_CMD   (GENET_UMAC_OFF + 0x614)
+#define UMAC_TX_FLUSH  (GENET_UMAC_OFF + 0x334)
+#define MDIO_START_BUSYBIT(29)
+#define MDIO_READ_FAIL BIT(28)
+#define MDIO_RD(2 << 26)
+#define MDIO_WRBIT(26)
+#define MDIO_PMD_SHIFT 21
+#define MDIO_PMD_MASK  0x1f
+#define MDIO_REG_SHIFT 16
+#define MDIO_REG_MASK  0x1f
+
+#define CMD_TX_EN  BIT(0)
+#define CMD_RX_EN  BIT(1)
+#define UMAC_SPEED_10  0
+#define UMAC_SPEED_100 1
+#define UMAC_SPEED_10002
+#define 

[PATCH v3 2/3] rpi4: Update memory map to accommodate scb devices

2020-01-26 Thread Andre Przywara
From: Amit Singh Tomar 

Some of the devices(for instance, pcie and gnet controller) sitting on
SCB bus falls behind/below the memory range that we currenty have.

This patch updates the memory range to map those devices correctly.

Signed-off-by: Amit Singh Tomar 
Reviewed-by: Andre Przywara 
Signed-off-by: Andre Przywara 
---
 arch/arm/mach-bcm283x/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 3b5f45b431..9966d6c833 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -42,9 +42,9 @@ static struct mm_region bcm2711_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-   .virt = 0xfe00UL,
-   .phys = 0xfe00UL,
-   .size = 0x0180UL,
+   .virt = 0xfc00UL,
+   .phys = 0xfc00UL,
+   .size = 0x0380UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-- 
2.14.5



[PATCH v3 3/3] rpi4: Enable GENET Ethernet controller

2020-01-26 Thread Andre Przywara
From: Amit Singh Tomar 

The Raspberry Pi 4 SoC features an integrated Gigabit Ethernet
controller, connected as a platform device.

Enable the new driver in the three applicable defconfigs, to allow
TFTP booting on the board.

Signed-off-by: Amit Singh Tomar 
[Andre: Add joined and 32-bit configs]
Signed-off-by: Andre Przywara 
---
 configs/rpi_4_32b_defconfig | 2 ++
 configs/rpi_4_defconfig | 2 ++
 configs/rpi_arm64_defconfig | 1 +
 3 files changed, 5 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 00f80f71ad..e7ea88bd4b 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_DM_ETH=y
+CONFIG_BCMGENET=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 8cf1bb81ff..b0f9cf1c0e 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_DM_ETH=y
+CONFIG_BCMGENET=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 10fbe0db92..00b3096481 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -36,6 +36,7 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_LAN78XX=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_BCMGENET=y
 CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_BPP32=y
 CONFIG_SYS_WHITE_ON_BLACK=y
-- 
2.14.5



Re: [PATCH 1/2] clk: Move clk-gate2 to clock driver directory

2020-01-26 Thread Sean Anderson


On 1/26/20 3:55 PM, Lukasz Majewski wrote:
> Hi Sean
> 
>> Make clk-gate2 available for use outside of imx.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>  drivers/clk/Makefile  |  1 +
>>  drivers/clk/{imx => }/clk-gate2.c | 20 
>>  drivers/clk/imx/Makefile  |  2 +-
>>  drivers/clk/imx/clk.h |  5 -
>>  include/linux/clk-provider.h  | 24 
>>  5 files changed, 26 insertions(+), 26 deletions(-)
>>  rename drivers/clk/{imx => }/clk-gate2.c (85%)
>>
> 
> This patch is OK.
> 
> Unfortunately, it causes buildman errors for sandbox:
> https://travis-ci.org/lmajewski/u-boot-dfu/jobs/641984485
> 
> The problem is with local sandbox copy of struct clk_gate2
> 
> In the clk_sandbox_ccf.c file we can re-use the 'flags' member (instead
> of defined for sandbox 'state') of now widely exposed struct clk_gate2
> (@ clk-provider.h) and 
> 
> #define SANDBOX_CCF_ENABLE (1UL << 31)
> #define SANDBOX_CCF_DISABLE (0UL << 31)
> 
> and remove the local sandbox copy.
> 
> 
> How to reproduce:
> 
> make mrproper; make sandbox_defconfig; make -j4
> ./u-boot -i -d arch/sandbox/dts/test.dtb
> => ut dm clk
> 
> 
> (I'm going to drop this patch from PR which I'm preparing now and
> depending on it "clk: Add option to restrict clk-gate2 to one bit
> toggle").

That's fine. This may be a bit of duplicate effort wrt the patches I
submitted regarding clk_composite. I originally used clk_gate2 in my
k210 patch series, but I switched over to using clk_composite because it
could function in the same manner.



Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

2020-01-26 Thread André Przywara
On 26/01/2020 02:28, Matthias Brugger wrote:
> On 24/01/2020 01:26, André Przywara wrote:

[ ... ]

>> Found the culprit, after following a lead started by an over-lunch
>> discussion: Colleagues pointed out the SError (interrupts) early in the
>> kernel could just show because they just got unmasked when dropping into
>> EL1. And indeed in AArch64 U-Boot we keep Aborts masked - we don't clear
>> the A bit in DAIF normally (only for Freescale).
>> So allowing SError exceptions in U-Boot's start.S revealed that the
>> SError interrupt was actually triggered by the writel in write_hwaddr(),
>> I guess because the MAC wasn't reset before. And the SError condition
>> stayed pending all the time, until the kernel announced its interest in
>> being told about fatal errors - then it inherited U-Boot's error.
> 
> Thanks for the explanation. I think the situation leaves space for improving.
> Either should we warn about a pending Abort before leaving U-Boot or we should
> allow aborts in general.

Definitively we should unmasks SErrors in U-Boot, since they point us to
serious problems, with this one here actually being somewhat on the
harmless side. Also U-Boot has exception handlers that dump useful
information, so we should use them.

But doing so would need to be done for all ARMv8 ports (in start.S), so
I am a bit reluctant to post something this late in the merge window
without proper testing on multiple platforms.

>> So for me the issue is fixed after adding the reset routine I sketched
>> in that thread before.
>>
>> But you mentioned that it still didn't work for you?
>>
> 
> I just double checked and everything works fine. Please feel free to send a 
> new
> version :)

Great, thanks! Did just that.

Cheers,
Andre


Re: [PATCH 3/6] sunxi: SPL SPI: Introduce is_new_gen_spi()

2020-01-26 Thread André Przywara
On 21/01/2020 08:20, Jagan Teki wrote:

Hi Jagan,

first: many thanks for merging those other patches of mine, much
appreciated!

> On Mon, Jan 6, 2020 at 6:59 AM Andre Przywara  wrote:
>>
>> So far we were using the CONFIG_SUNXI_GEN_SUN6I symbol to select between
>> the two SPI controller generations used on Allwinner SoCs. This is a
>> convenience symbol to roughly differentiate between "older" and "newer"
>> generation of SoCs.
>>
>> The H6 SoCs is the newest SoC so far, but is sufficiently different to
>> not define this symbol. However it is using a SPI controller compatible
>> to the "new gen" SoCs.
>>
>> To prepare for H6 support, we replace the check for this single symbol
>> with an explicit function, which can later be extended.
>> For now we just return CONFIG_SUNXI_GEN_SUN6I in there, so this does not
>> create a functional change.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm/mach-sunxi/spl_spi_sunxi.c | 22 ++
>>  1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c 
>> b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> index 5b4598a25b..b19f1bf4af 100644
>> --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> @@ -100,9 +100,14 @@ static void spi0_pinmux_setup(unsigned int pin_function)
>> sunxi_gpio_set_cfgpin(SUNXI_GPC(3), pin_function);
>>  }
>>
>> +static bool is_new_gen_spi(void)
>> +{
>> +   return IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I);
>> +}
> 
> Doesn't it confusing? new gen is H6, but it returns 6I?

Well, naming ...
For the purpose of U-Boot there are two generations of SPI controller
*register interfaces*, the "old" one used in the older SoCs like the
A20, and the "newer" one used in everything halfway recent. The H6 uses
the same "new" generation, just at a different address. Yes, it adds
quad-SPI, but this is not relevant for this driver.
I have seen this old/new terminology at different places, so just went
with it.
I could rename it to is_spi_sun6i_gen() or something if that makes you
happy...

Cheers,
Andre


Re: [PATCH v4 01/10] env: nowhere: set default enviroment

2020-01-26 Thread Keerthy




On 24/01/20 8:22 pm, Tom Rini wrote:

On Wed, Jan 22, 2020 at 09:29:56AM +0530, Keerthy wrote:


Set default enviroment so that set_env calls succeed when only
ENV_IS_NOWHERE set.

Signed-off-by: Keerthy 
---

Changes in v4:

   * Reworded commit log

  env/nowhere.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/env/nowhere.c b/env/nowhere.c
index f5b0a17652..70c3b3e011 100644
--- a/env/nowhere.c
+++ b/env/nowhere.c
@@ -23,6 +23,7 @@ static int env_nowhere_init(void)
  {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid= ENV_INVALID;
+   (NULL, 0);
  
  	return 0;

  }


What exactly do you mean by this?  Can you give an example or two (code
and/or shell) where things didn't work before but do now?  And please
CC Joe/Wolfgang in the future on env patches, thanks.


Tom,

I have a case where only ENV_IS_NOWHERE is set in SPL without any of the 
memory based env configs like ENV_IS_IN_FAT or ENV_IS_IN_MMC. With that 
if i try to use env_set it does not work.


env_set checks for (gd->flags & GD_FLG_ENV_READY) which never is true 
for the nowhere case and hence env_set returns 1.


If any of the memory based ENV config is set i see that env_set_default 
is called hence env_set works nicely. So we need to have env_set_default

in the case of nowhere configuration as well.

Best Regards,
Keerthy





Re: [PATCH v4 02/10] lib: elf: Move the generic elf loading/validating functions to lib

2020-01-26 Thread Keerthy




On 24/01/20 8:24 pm, Tom Rini wrote:

On Wed, Jan 22, 2020 at 09:29:57AM +0530, Keerthy wrote:

Move the generic elf loading/validating functions to lib/
so that they can be re-used and accessed by code existing
outside cmd.

Signed-off-by: Keerthy 
Suggested-by: Simon Goldschmidt 
Reviewed-by: Simon Goldschmidt 

[snip]

diff --git a/lib/Kconfig b/lib/Kconfig
index d040a87d26..5ca86cd7fb 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -601,4 +601,7 @@ config TEST_FDTDEC
  config LIB_DATE
bool
  
+config LIB_ELF

+   bool "enable basic elf loading/validating functions"
+
  endmenu


This shouldn't be a user-selectable symbol, it should be select'd as
needed.  So no bool text but a help text that mentions what it does
provide is needed.  Thanks!


Okay. I will change that.





Re: [PATCH v4 06/10] arm: dts: k3-j721e-r5: Add fs_loader node

2020-01-26 Thread Keerthy




On 24/01/20 8:25 pm, Tom Rini wrote:

On Wed, Jan 22, 2020 at 09:30:01AM +0530, Keerthy wrote:

Add fs_loader node which will be needed for loading firmwares
from the boot media/filesystem.

Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
---
  arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 28a355d49c..caeee8defe 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -18,6 +18,12 @@
chosen {
stdout-path = "serial2:115200n8";
tick-timer = &timer1;
+   firmware-loader = &fs_loader0;
+   };
+
+   fs_loader0: fs_loader@0 {
+   u-boot,dm-pre-reloc;
+   compatible = "u-boot,fs-loader";
};
  
  	a72_0: a72@0 {


All u-boot, properties need to be in a -u-boot.dtsi file so it's very
clear what things we are adding and what files can be replaced directly
from Linux.  Please fixup anything else in this area that wasn't already
doing this and then add what you need here, thanks!


Tom,

I believe we are safe here as the k3-j721e-r5-common-proc-board.dts 
entire file is u-boot specific. k3-j721e-r5-common-proc-board.dts is not 
present in Linux DT.


Thanks,
Keerthy





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

2020-01-26 Thread Vignesh Raghavendra
Add support for Direct Access Controller mode of Cadence QSPI. This
allows MMIO access to SPI NOR flash providing better read performance.
Direct mode is only exercised if AHB window size is greater than 8MB.
Support for flash address remapping is also not supported at the moment
and can be added in future.

For better performance, driver uses DMA to copy data from flash in
direct mode using dma_memcpy().

Signed-off-by: Vignesh Raghavendra 
Tested-by: Simon Goldschmidt 
---
 drivers/spi/cadence_qspi.c | 40 -
 drivers/spi/cadence_qspi.h | 19 +-
 drivers/spi/cadence_qspi_apb.c | 65 +-
 3 files changed, 91 insertions(+), 33 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 86c910a8dac3..619fff70de2f 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -13,12 +13,13 @@
 #include 
 #include 
 #include 
+#include 
 #include "cadence_qspi.h"
 
 #define CQSPI_STIG_READ0
 #define CQSPI_STIG_WRITE   1
-#define CQSPI_INDIRECT_READ2
-#define CQSPI_INDIRECT_WRITE   3
+#define CQSPI_READ 2
+#define CQSPI_WRITE3
 
 static int cadence_spi_write_speed(struct udevice *bus, uint hz)
 {
@@ -190,6 +191,7 @@ static int cadence_spi_remove(struct udevice *dev)
 
 static int cadence_spi_set_mode(struct udevice *bus, uint mode)
 {
+   struct cadence_spi_platdata *plat = bus->platdata;
struct cadence_spi_priv *priv = dev_get_priv(bus);
 
/* Disable QSPI */
@@ -198,6 +200,10 @@ static int cadence_spi_set_mode(struct udevice *bus, uint 
mode)
/* Set SPI mode */
cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
 
+   /* Enable Direct Access Controller */
+   if (plat->use_dac_mode)
+   cadence_qspi_apb_dac_mode_enable(priv->regbase);
+
/* Enable QSPI */
cadence_qspi_apb_controller_enable(priv->regbase);
 
@@ -222,12 +228,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
if (!op->addr.nbytes)
mode = CQSPI_STIG_READ;
else
-   mode = CQSPI_INDIRECT_READ;
+   mode = CQSPI_READ;
} else {
if (!op->addr.nbytes || !op->data.buf.out)
mode = CQSPI_STIG_WRITE;
else
-   mode = CQSPI_INDIRECT_WRITE;
+   mode = CQSPI_WRITE;
}
 
switch (mode) {
@@ -237,19 +243,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
case CQSPI_STIG_WRITE:
err = cadence_qspi_apb_command_write(base, op);
break;
-   case CQSPI_INDIRECT_READ:
-   err = cadence_qspi_apb_indirect_read_setup(plat, op);
-   if (!err) {
-   err = cadence_qspi_apb_indirect_read_execute
-   (plat, op->data.nbytes, op->data.buf.in);
-   }
+   case CQSPI_READ:
+   err = cadence_qspi_apb_read_setup(plat, op);
+   if (!err)
+   err = cadence_qspi_apb_read_execute(plat, op);
break;
-   case CQSPI_INDIRECT_WRITE:
-   err = cadence_qspi_apb_indirect_write_setup(plat, op);
-   if (!err) {
-   err = cadence_qspi_apb_indirect_write_execute
-   (plat, op->data.nbytes, op->data.buf.out);
-   }
+   case CQSPI_WRITE:
+   err = cadence_qspi_apb_write_setup(plat, op);
+   if (!err)
+   err = cadence_qspi_apb_write_execute(plat, op);
break;
default:
err = -1;
@@ -267,13 +269,17 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
int ret;
 
plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
-   plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
+   plat->ahbbase = (void *)devfdt_get_addr_size_index(bus, 1,
+   &plat->ahbsize);
plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs");
plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128);
plat->fifo_width = dev_read_u32_default(bus, "cdns,fifo-width", 4);
plat->trigger_address = dev_read_u32_default(bus,
 "cdns,trigger-address",
 0);
+   /* Use DAC mode only when MMIO window is at least 8M wide */
+   if (plat->ahbsize >= SZ_8M)
+   plat->use_dac_mode = true;
 
/* All other paramters are embedded in the child node */
subnode = dev_read_first_subnode(bus);
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index d66201ec923d..ae459c74a192 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h

[PATCH 000/108] RFC: dm: Add programatic generation of ACPI tables

2020-01-26 Thread Simon Glass
At present on x86 U-Boot supports creating ACPI (Advanced Configuration
and Power Interface) tables using the Intel ACPI Source Language (ASL)
compiler.

This is good enough for basic operation but some devices need to add
their information dynamically at runtime. An example is a device that
needs to report its enable GPIO. This is described in the device tree,
so we want to add code in the driver to convert that device-tree
description into an ACPI description for use on Linux.

This series adds support for generation of ACPI tables and fragments by
devices. The core support is built into driver model.

Several files are brought over from coreboot to do the actual generation.

As an example of using this new feature, chromebook_coral is updated to
write out a wide array of ACPI tables including DSDT and SSDT.

This initial version of the series lays out the general approach. More
work is needed to figure out the difference between CONFIG_ACPIGEN and
CONFIG_GENERATE_ACPI_TABLE with respect to what is built.


Simon Glass (108):
  cpu: Support querying the address width
  spi: Add SPI mode enums
  tpm: cr50: Release locality on exit
  tpm: cr50: Tidy up various comments
  tpm: cr50: Use the correct GPIO binding
  tpm: Don't cleanup unless an error happens
  dm: pci: Allow disabling auto-config for a device
  x86: Correct wording of coreboot source code
  x86: apl: Move p2sb ofdata reading to the correct method
  pci: Adjust dm_pci_read_bar32() to return errors correctly
  x86: apl: Add Global NVS table header
  dm: core: Add basic ACPI support
  acpi: Add a binding for ACPI settings in the device tree
  acpi: Add a simple sandbox test
  x86: Move acpi_table header to main include/ directory
  acpi: Add an __ACPI__ preprocessor symbol
  acpi: Add a central location for table version numbers
  acpi: Add support for DMAR
  acpi: Move acpi_fill_header() to generic code
  acpi: Add a method to write tables for a device
  acpi: Convert part of acpi_table to use acpi_ctx
  x86: Allow devices to write ACPI tables
  acpi: Drop code for missing XSDT from acpi_write_rsdp()
  acpi: Move acpi_add_table() to generic code
  acpi: Put table-setup code in its own function
  acpi: Move the xsdt pointer to acpi_ctx
  acpi: Add an acpi command
  acpi: Add some tables required by the generation code
  acpi: Add generation code for devices
  acpi: Add functions to generate ACPI code
  gpio: Add a method to convert a GPIO to ACPI
  irq: Add a method to convert an interrupt to ACPI
  acpi: Add support for SSDT generation
  x86: acpi: Move MADT up a bit
  acpi: Record the items added to SSDT
  acpi: Support ordering SSDT data by device
  x86: Allow devices to write an SSDT
  acpi: Add support for DSDT generation
  x86: Allow devices to write to DSDT
  dm: core: Add an ACPI name for the root node
  dm: acpi: Enhance acpi_get_name()
  acpi: Add an acpi split command
  acpi: Allow creating the GNVS to fail
  dtoc: Support ACPI paths in of-platdata
  acpi: mmc: Generate ACPI info for the PCI SD Card
  sound: Add an ACPI driver for Dialog Semicondutor da7219
  sound: Add an ACPI driver for Maxim MAX98357ac
  x86: pinctrl: Add a way to get the pinctrl reg address
  x86: pinctrl: Update comment for intel_pinctrl_get_pad()
  x86: pinctrl: Add multi-ACPI control
  x86: pinctrl: Set up itss in the probe() method
  x86: pinctrl: Drop the acpi_name member
  dm: core: Add a way of overriding the ACPI device path
  x86: gpio: Add support for obtaining ACPI info for a GPIO
  i2c: designware_i2c: Support ACPI table generation
  i2c: Add a generic driver to generate ACPI info
  p2sb: Add a method to hide the bus
  x86: apl: Support set_hide() in p2sb driver
  x86: apl: Hide the p2sb on exit from U-Boot
  pmc: Move common registers to the header file
  x86: irq: Support flags for acpi_gpe
  x86: Add debugging to table writing
  x86: Rename board_final_cleanup() to board_final_init()
  acpi: Enable ACPI table generation by default on x86
  acpi: Add cros_ec tables
  x86: acpi: Add base asl files for common x86 devices
  x86: acpi: apl: Add asl files for Apollo Lake
  x86: acpi: Add DPTF asl files
  x86: apl: Correct PCIE_ECAM_BASE
  x86: coral: Add ACPI tables for coral
  x86: acpi: Support external GNVS tables
  x86: acpi: Expand the GNVS
  x86: Add wake sources for the acpi_gpe driver
  x86: Add a config for the systemagent PCIEX regions size
  x86: apl: Support writing the IntelGraphicsMem table
  x86: acpi: Add a common routine to write WiFi info
  x86: Add some definitions for SMM
  x86: apl: Add power-management definitions
  x86: Add a common global NVS structure
  cpu: Convert the methods to use a const udevice *
  x86: apl: Update iomap for ACPI
  x86: Add a few common Intel CPU functions
  x86: acpi: Support generation of the HPET table
  x86: acpi: Support generation of the DBG2 table
  x86: acpi: Add common Intel ACPI tables
  x86: Support Atom SoCs using SWSMISCI rather than the SWSCI
  x86: apl: Add a check for reading the FSP-S config

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

2020-01-26 Thread Vignesh Raghavendra
Current Cadence QSPI driver has few limitations. It assumes all read
operations to be in Quad mode and thus does not support SFDP parsing.
Also, adding support for new mode such as Octal mode would not be
possible with current configuration. Therefore move the driver over to spi-mem
framework. This has added advantage that driver can be used to support
SPI NAND memories too.
Hence, move driver over to new spi-mem APIs.

Please note that this gets rid of mode bit setting done when
CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
that config option.

Signed-off-by: Vignesh Raghavendra 
Tested-by: Simon Goldschmidt 
---
 drivers/spi/cadence_qspi.c | 136 +
 drivers/spi/cadence_qspi.h |   9 +--
 drivers/spi/cadence_qspi_apb.c | 124 --
 3 files changed, 91 insertions(+), 178 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 8fd23a770276..86c910a8dac3 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "cadence_qspi.h"
 
@@ -35,12 +36,21 @@ static int cadence_spi_write_speed(struct udevice *bus, 
uint hz)
return 0;
 }
 
+static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
+{
+   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_IN(len, idcode, 1));
+
+   return cadence_qspi_apb_command_read(reg_base, &op);
+}
+
 /* Calibration sequence to determine the read data capture delay register */
 static int spi_calibration(struct udevice *bus, uint hz)
 {
struct cadence_spi_priv *priv = dev_get_priv(bus);
void *base = priv->regbase;
-   u8 opcode_rdid = 0x9F;
unsigned int idcode = 0, temp = 0;
int err = 0, i, range_lo = -1, range_hi = -1;
 
@@ -54,8 +64,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
 
/* read the ID which will be our golden value */
-   err = cadence_qspi_apb_command_read(base, 1, &opcode_rdid,
-   3, (u8 *)&idcode);
+   err = cadence_spi_read_id(base, 3, (u8 *)&idcode);
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -74,8 +83,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
 
/* issue a RDID to get the ID value */
-   err = cadence_qspi_apb_command_read(base, 1, &opcode_rdid,
-   3, (u8 *)&temp);
+   err = cadence_spi_read_id(base, 3, (u8 *)&temp);
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -196,96 +204,56 @@ static int cadence_spi_set_mode(struct udevice *bus, uint 
mode)
return 0;
 }
 
-static int cadence_spi_xfer(struct udevice *dev, unsigned int bitlen,
-   const void *dout, void *din, unsigned long flags)
+static int cadence_spi_mem_exec_op(struct spi_slave *spi,
+  const struct spi_mem_op *op)
 {
-   struct udevice *bus = dev->parent;
+   struct udevice *bus = spi->dev->parent;
struct cadence_spi_platdata *plat = bus->platdata;
struct cadence_spi_priv *priv = dev_get_priv(bus);
-   struct dm_spi_slave_platdata *dm_plat = dev_get_parent_platdata(dev);
void *base = priv->regbase;
-   u8 *cmd_buf = priv->cmd_buf;
-   size_t data_bytes;
int err = 0;
-   u32 mode = CQSPI_STIG_WRITE;
-
-   if (flags & SPI_XFER_BEGIN) {
-   /* copy command to local buffer */
-   priv->cmd_len = bitlen / 8;
-   memcpy(cmd_buf, dout, priv->cmd_len);
-   }
-
-   if (flags == (SPI_XFER_BEGIN | SPI_XFER_END)) {
-   /* if start and end bit are set, the data bytes is 0. */
-   data_bytes = 0;
-   } else {
-   data_bytes = bitlen / 8;
-   }
-   debug("%s: len=%zu [bytes]\n", __func__, data_bytes);
+   u32 mode;
 
/* Set Chip select */
-   cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
+   cadence_qspi_apb_chipselect(base, spi_chip_select(spi->dev),
plat->is_decoded_cs);
 
-   if ((flags & SPI_XFER_END) || (flags == 0)) {
-   if (priv->cmd_len == 0) {
-   printf("QSPI: Error, command is empty.\n");
-   return -1;
-   }
-
-   if (din && data_bytes) {
-   /* read */
-   /* Use STIG if no address. */
-   if (!CQSPI_IS_ADDR(priv->cmd_len))
-   mo

[RESEND v2 0/2] spi: cadence-qspi: Move to spi-mem APIs

2020-01-26 Thread Vignesh Raghavendra
First patch moves driver over to spi-mem framework and implement
spi_mem_ops. This is require to support more SPI Flash opcodes like SFDP
parsing etc. Series is in prepartion to add Octal mode for support for
the same driver to support OSPI version of the controller.

Second patch adds DAC mode that provide memory mapped access to flash.
This greatly increases the read throughput.

Tested with mt25qu512 flash and s25fl512 flash

Resend v2:

Rebase onto the latest master (no functional change)

Vignesh Raghavendra (2):
  spi: cadence_qspi: Move to spi-mem framework
  spi: cadence-qspi: Add direct mode support

 drivers/spi/cadence_qspi.c | 148 +++---
 drivers/spi/cadence_qspi.h |  24 +++--
 drivers/spi/cadence_qspi_apb.c | 185 -
 3 files changed, 164 insertions(+), 193 deletions(-)

-- 
2.25.0



[PATCH 006/108] tpm: Don't cleanup unless an error happens

2020-01-26 Thread Simon Glass
At present the cleanup() method is called on every transfer. It should
only be called on failing transfers. Fix this and tidy up the error
handling a little.

Signed-off-by: Simon Glass 
---

 drivers/tpm/tpm-uclass.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
index 1b11c93194..71d5807006 100644
--- a/drivers/tpm/tpm-uclass.c
+++ b/drivers/tpm/tpm-uclass.c
@@ -72,7 +72,7 @@ int tpm_xfer(struct udevice *dev, const uint8_t *sendbuf, 
size_t send_size,
struct tpm_ops *ops = tpm_get_ops(dev);
ulong start, stop;
uint count, ordinal;
-   int ret, ret2;
+   int ret, ret2 = 0;
 
if (ops->xfer)
return ops->xfer(dev, sendbuf, send_size, recvbuf, recv_size);
@@ -120,9 +120,16 @@ int tpm_xfer(struct udevice *dev, const uint8_t *sendbuf, 
size_t send_size,
}
} while (ret);
 
-   ret2 = ops->cleanup ? ops->cleanup(dev) : 0;
+   if (ret) {
+   if (ops->cleanup) {
+   ret2 = ops->cleanup(dev);
+   if (ret2)
+   return log_msg_ret("cleanup", ret2);
+   }
+   return log_msg_ret("xfer", ret);
+   }
 
-   return ret2 ? ret2 : ret;
+   return 0;
 }
 
 UCLASS_DRIVER(tpm) = {
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 003/108] tpm: cr50: Release locality on exit

2020-01-26 Thread Simon Glass
At present the cr50 driver claims the locality and does not release it for
Linux. This causes problems. Fix this by tracking what is claimed, and
adding a 'remove' method.

Signed-off-by: Simon Glass 
---

 drivers/tpm/cr50_i2c.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index 880da37835..42faee4d9b 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -208,7 +208,7 @@ static int release_locality(struct udevice *dev, int force)
cr50_i2c_write(dev, addr, &buf, 1);
}
 
-   priv->locality = 0;
+   priv->locality = -1;
 
return 0;
 }
@@ -500,6 +500,7 @@ static int process_reset(struct udevice *dev)
 static int claim_locality(struct udevice *dev, int loc)
 {
const u8 mask = TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY;
+   struct cr50_priv *priv = dev_get_priv(dev);
u8 access;
int ret;
 
@@ -526,6 +527,7 @@ static int claim_locality(struct udevice *dev, int loc)
return -EPERM;
}
log_info("Claimed locality %d\n", loc);
+   priv->locality = loc;
 
return 0;
 }
@@ -560,7 +562,11 @@ static int cr50_i2c_open(struct udevice *dev)
 
 static int cr50_i2c_cleanup(struct udevice *dev)
 {
-   release_locality(dev, 1);
+   struct cr50_priv *priv = dev_get_priv(dev);
+
+   printf("%s: cleanup %d\n", __func__, priv->locality);
+   if (priv->locality != -1)
+   release_locality(dev, 1);
 
return 0;
 }
@@ -632,6 +638,7 @@ static int cr50_i2c_probe(struct udevice *dev)
return log_msg_ret("vendor-id", -EXDEV);
}
priv->vendor = vendor;
+   priv->locality = -1;
 
return 0;
 }
@@ -656,5 +663,7 @@ U_BOOT_DRIVER(cr50_i2c) = {
.ops= &cr50_i2c_ops,
.ofdata_to_platdata = cr50_i2c_ofdata_to_platdata,
.probe  = cr50_i2c_probe,
+   .remove = cr50_i2c_cleanup,
.priv_auto_alloc_size = sizeof(struct cr50_priv),
+   .flags  = DM_FLAG_OS_PREPARE,
 };
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 002/108] spi: Add SPI mode enums

2020-01-26 Thread Simon Glass
With ACPI we need to describe the settings of the SPI bus. Add enums to
handle this.

Signed-off-by: Simon Glass 
---

 include/spi.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/include/spi.h b/include/spi.h
index ef5d87f476..77fa3800fd 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -62,6 +62,39 @@ struct dm_spi_slave_platdata {
uint mode;
 };
 
+/**
+ * enum spi_clock_phase - indicates  the clock phase to use for SPI (CPHA)
+ *
+ * @SPI_CLOCK_PHASE_FIRST: Data sampled on the first phase
+ * @SPI_CLOCK_PHASE_SECOND: Data sampled on the second phase
+ */
+enum spi_clock_phase {
+   SPI_CLOCK_PHASE_FIRST,
+   SPI_CLOCK_PHASE_SECOND
+};
+
+/**
+ * enum spi_wire_mode - indicates the number of wires used for SPI
+ *
+ * @SPI_4_WIRE_MODE: Normal bidirectional mode with MOSI and MISO
+ * @SPI_3_WIRE_MODE: Unidirectional version with a single data line SISO
+ */
+enum spi_wire_mode {
+   SPI_4_WIRE_MODE,
+   SPI_3_WIRE_MODE
+};
+
+/**
+ * enum spi_polarity - indicates the polarity of the SPI bus (CPOL)
+ *
+ * @SPI_POLARITY_LOW: Clock is low in idle state
+ * @SPI_POLARITY_HIGH: Clock is high in idle state
+ */
+enum spi_polarity {
+   SPI_POLARITY_LOW,
+   SPI_POLARITY_HIGH
+};
+
 #endif /* CONFIG_DM_SPI */
 
 /**
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 001/108] cpu: Support querying the address width

2020-01-26 Thread Simon Glass
Different CPUs may support different address widths, meaning the amount of
memory they can address. Add a property for this to the cpu_info struct.

Signed-off-by: Simon Glass 
---

 drivers/cpu/cpu_sandbox.c | 1 +
 include/cpu.h | 2 ++
 test/dm/cpu.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/cpu/cpu_sandbox.c b/drivers/cpu/cpu_sandbox.c
index ff87e8adca..05b384f6a4 100644
--- a/drivers/cpu/cpu_sandbox.c
+++ b/drivers/cpu/cpu_sandbox.c
@@ -19,6 +19,7 @@ int cpu_sandbox_get_info(struct udevice *dev, struct cpu_info 
*info)
 {
info->cpu_freq = 42 * 42 * 42 * 42 * 42;
info->features = 0x42424242;
+   info->address_width = IS_ENABLED(CONFIG_PHYS_64BIT) ? 64 : 32;
 
return 0;
 }
diff --git a/include/cpu.h b/include/cpu.h
index 28dd48feb8..6b1b6b37b3 100644
--- a/include/cpu.h
+++ b/include/cpu.h
@@ -44,10 +44,12 @@ enum {
  *
  * @cpu_freq:  Current CPU frequency in Hz
  * @features:  Flags for supported CPU features
+ * @address_width: Width of the CPU address space in bits (e.g. 32)
  */
 struct cpu_info {
ulong cpu_freq;
ulong features;
+   uint address_width;
 };
 
 struct cpu_ops {
diff --git a/test/dm/cpu.c b/test/dm/cpu.c
index f5f1caef71..e6dc576ea3 100644
--- a/test/dm/cpu.c
+++ b/test/dm/cpu.c
@@ -33,6 +33,7 @@ static int dm_test_cpu(struct unit_test_state *uts)
ut_assertok(cpu_get_info(dev, &info));
ut_asserteq(info.cpu_freq, 42 * 42 * 42 * 42 * 42);
ut_asserteq(info.features, 0x42424242);
+   ut_asserteq(info.address_width, 32);
 
ut_asserteq(cpu_get_count(dev), 42);
 
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 004/108] tpm: cr50: Tidy up various comments

2020-01-26 Thread Simon Glass
Add a comment for the private structure and drop the incorrect coreboot
reference in one function.

Signed-off-by: Simon Glass 
---

 drivers/tpm/cr50_i2c.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index 42faee4d9b..1af943d6ff 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -34,6 +34,15 @@ enum {
CR50_MAX_BUF_SIZE = 63,
 };
 
+/**
+ * struct cr50_priv - Private driver data
+ *
+ * @ready_gpio: GPIO to use to check if the TPM is ready
+ * @irq: IRQ to use check if the TPM is ready (has priority over @ready_gpio)
+ * @locality: Currenttly claimed locality (-1 if none)
+ * @vendor: vendor: Vendor ID for TPM
+ * @use_irq: true to use @irq, false to use @ready if available
+ */
 struct cr50_priv {
struct gpio_desc ready_gpio;
struct irq irq;
@@ -493,8 +502,8 @@ static int process_reset(struct udevice *dev)
 }
 
 /*
- * Locality could be already claimed (if this is a later coreboot stage and
- * the RO did not release it), or not yet claimed, if this is verstage or the
+ * Locality could be already claimed (if this is a later U-Boot phase and
+ * RO did not release it), or not yet claimed, if this is TPL or the
  * older RO did release it.
  */
 static int claim_locality(struct udevice *dev, int loc)
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 009/108] x86: apl: Move p2sb ofdata reading to the correct method

2020-01-26 Thread Simon Glass
With P2SB the initial BAR (base-address register) is set up by TPL and
this is used unchanged right through U-Boot.

At present the reading of this address is split between the ofdata() and
probe() methods. There are a few problems that are unique to the p2sb.
One is that its children need to call pcr_read32(), etc. which needs to
have the p2sb address correct. Also some of its children are pinctrl
devices and pinctrl is used when any device is probed. So p2sb really
needs to get its base address set up in ofdata_to_platdata(), before it is
probed.

Another point is that reading the p2sb BAR will not work if the p2sb is
hidden. The FSP-S seems to hide it, presumably to avoid confusing PCI
enumeration.

Reading ofdata in ofdata_to_platdata() is the correct place anyway, so
this is easy to fix.

Move the code into one place and use the early-regs property in all cases
for simplicity and to avoid needing to probe any PCI devices just to read
the BAR.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/apollolake/p2sb.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/arch/x86/cpu/apollolake/p2sb.c b/arch/x86/cpu/apollolake/p2sb.c
index 7b5a473bbd..a3d8e094e7 100644
--- a/arch/x86/cpu/apollolake/p2sb.c
+++ b/arch/x86/cpu/apollolake/p2sb.c
@@ -92,27 +92,25 @@ int apl_p2sb_ofdata_to_platdata(struct udevice *dev)
 
 #if !CONFIG_IS_ENABLED(OF_PLATDATA)
int ret;
+   u32 base[2];
 
+   ret = dev_read_u32_array(dev, "early-regs", base, ARRAY_SIZE(base));
+   if (ret)
+   return log_msg_ret("Missing/short early-regs", ret);
+   plat->mmio_base = base[0];
+   /* TPL sets up the initial BAR */
if (spl_phase() == PHASE_TPL) {
-   u32 base[2];
-
-   /* TPL sets up the initial BAR */
-   ret = dev_read_u32_array(dev, "early-regs", base,
-ARRAY_SIZE(base));
-   if (ret)
-   return log_msg_ret("Missing/short early-regs", ret);
-   plat->mmio_base = base[0];
plat->bdf = pci_get_devfn(dev);
if (plat->bdf < 0)
return log_msg_ret("Cannot get p2sb PCI address",
-  plat->bdf);
+   plat->bdf);
}
+   upriv->mmio_base = plat->mmio_base;
 #else
plat->mmio_base = plat->dtplat.early_regs[0];
plat->bdf = pci_ofplat_get_devfn(plat->dtplat.reg[0]);
-#endif
upriv->mmio_base = plat->mmio_base;
-   debug("p2sb: mmio_base=%x\n", (uint)plat->mmio_base);
+#endif
 
return 0;
 }
@@ -121,17 +119,8 @@ static int apl_p2sb_probe(struct udevice *dev)
 {
if (spl_phase() == PHASE_TPL)
return apl_p2sb_early_init(dev);
-   else {
-   struct p2sb_platdata *plat = dev_get_platdata(dev);
-
-   plat->mmio_base = dev_read_addr_pci(dev);
-   /* Don't set BDF since it should not be used */
-   if (!plat->mmio_base || plat->mmio_base == FDT_ADDR_T_NONE)
-   return -EINVAL;
-
-   if (spl_phase() == PHASE_SPL)
-   return apl_p2sb_spl_init(dev);
-   }
+   else if (spl_phase() == PHASE_SPL)
+   return apl_p2sb_spl_init(dev);
 
return 0;
 }
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 008/108] x86: Correct wording of coreboot source code

2020-01-26 Thread Simon Glass
Some files are taken or modified from coreboot, but the files are
no-longer part of the coreboot project. Fix the wording in a few places.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/coreboot/timestamp.c  | 4 ++--
 arch/x86/include/asm/arch-coreboot/timestamp.h | 4 ++--
 arch/x86/include/asm/intel_pinctrl_defs.h  | 2 --
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/x86/cpu/coreboot/timestamp.c 
b/arch/x86/cpu/coreboot/timestamp.c
index e698200d70..e8ccaf2212 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * This file is part of the coreboot project.
- *
  * Copyright (C) 2011 The ChromiumOS Authors.  All rights reserved.
+ *
+ * Modified from the coreboot version
  */
 
 #include 
diff --git a/arch/x86/include/asm/arch-coreboot/timestamp.h 
b/arch/x86/include/asm/arch-coreboot/timestamp.h
index 9320afba56..85d42c02c4 100644
--- a/arch/x86/include/asm/arch-coreboot/timestamp.h
+++ b/arch/x86/include/asm/arch-coreboot/timestamp.h
@@ -1,8 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * This file is part of the coreboot project.
- *
  * Copyright (C) 2011 The ChromiumOS Authors.  All rights reserved.
+ *
+ * Taken from the coreboot version
  */
 
 #ifndef __COREBOOT_TIMESTAMP_H__
diff --git a/arch/x86/include/asm/intel_pinctrl_defs.h 
b/arch/x86/include/asm/intel_pinctrl_defs.h
index 6da06bb52b..1ea141f082 100644
--- a/arch/x86/include/asm/intel_pinctrl_defs.h
+++ b/arch/x86/include/asm/intel_pinctrl_defs.h
@@ -1,7 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * This file is part of the coreboot project.
- *
  * Copyright (C) 2015-2016 Intel Corp.
  * Copyright 2019 Google LLC
  *
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 011/108] x86: apl: Add Global NVS table header

2020-01-26 Thread Simon Glass
Add the C version of this header. It includes a few Chrome OS bits which
are disabled for a normal build.

Signed-off-by: Simon Glass 
---

 .../include/asm/arch-apollolake/global_nvs.h  | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 arch/x86/include/asm/arch-apollolake/global_nvs.h

diff --git a/arch/x86/include/asm/arch-apollolake/global_nvs.h 
b/arch/x86/include/asm/arch-apollolake/global_nvs.h
new file mode 100644
index 00..0ea6da5cf9
--- /dev/null
+++ b/arch/x86/include/asm/arch-apollolake/global_nvs.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2015-2017 Intel Corp.
+ * (Written by Lance Zhao  for Intel Corp.)
+ * Copyright Google LLC 2019
+ *
+ * Modified from coreboot apollolake/include/soc/nvs.h
+ */
+
+#ifndef _GLOBAL_NVS_H_
+#define _GLOBAL_NVS_H_
+
+struct __packed acpi_global_nvs {
+   /* Miscellaneous */
+   u8  pcnt; /* 0x00 - Processor Count */
+   u8  ppcm; /* 0x01 - Max PPC State */
+   u8  lids; /* 0x02 - LID State */
+   u8  pwrs; /* 0x03 - AC Power State */
+   u8  dpte; /* 0x04 - Enable DPTF */
+   u32 cbmc; /* 0x05 - 0x08 - coreboot Memory Console */
+   u64 pm1i; /* 0x09 - 0x10 - System Wake Source - PM1 Index */
+   u64 gpei; /* 0x11 - 0x18 - GPE Wake Source */
+   u64 nhla; /* 0x19 - 0x20 - NHLT Address */
+   u32 nhll; /* 0x21 - 0x24 - NHLT Length */
+   u32 prt0; /* 0x25 - 0x28 - PERST_0 Address */
+   u8  scdp; /* 0x29 - SD_CD GPIO portid */
+   u8  scdo; /* 0x2A - GPIO pad offset relative to the community */
+   u8  uior; /* 0x2B - UART debug controller init on S3 resume */
+   u8  ecps; /* 0x2C - SGX Enabled status */
+   u64 emna; /* 0x2D - 0x34 EPC base address */
+   u64 elng; /* 0x35 - 0x3C EPC Length */
+   u8  unused[195];
+#ifdef CONFIG_CHROMEOS
+   /* ChromeOS specific (0x100 - 0xfff) */
+   struct chromeos_acpi chromeos;
+#else
+   u8  unused2[0xf00];
+#endif
+};
+#ifdef CONFIG_CHROMEOS
+check_member(acpi_global_nvs, chromeos, GNVS_CHROMEOS_ACPI_OFFSET);
+#endif
+
+#endif /* _GLOBAL_NVS_H_ */
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 005/108] tpm: cr50: Use the correct GPIO binding

2020-01-26 Thread Simon Glass
This device should use ready-gpios rather than ready-gpio. Fix it.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/chromebook_coral.dts   | 2 +-
 doc/device-tree-bindings/gpio/intel,apl-gpio.txt| 2 +-
 .../interrupt-controller/intel,acpi-gpe.txt | 2 +-
 drivers/tpm/cr50_i2c.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/dts/chromebook_coral.dts 
b/arch/x86/dts/chromebook_coral.dts
index 4e8c0a6c8a..7ba38d7791 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -292,7 +292,7 @@
reg = <0x50>;
compatible = "google,cr50";
u-boot,i2c-offset-len = <0>;
-   ready-gpio = <&gpio_n 28 GPIO_ACTIVE_LOW>;
+   ready-gpios = <&gpio_n 28 GPIO_ACTIVE_LOW>;
interrupts-extended = <&acpi_gpe 0x3c 0>;
};
};
diff --git a/doc/device-tree-bindings/gpio/intel,apl-gpio.txt 
b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
index e27a40b437..e12dc37233 100644
--- a/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
+++ b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
@@ -47,7 +47,7 @@ Example:
reg = <0x50>;
compatible = "google,cr50";
u-boot,i2c-offset-len = <0>;
-   ready-gpio = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
+   ready-gpios = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
};
};
 
diff --git a/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt 
b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
index d9252bf29f..2fe02d8a22 100644
--- a/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
+++ b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
@@ -25,6 +25,6 @@ Example:
tpm@50 {
reg = <0x50>;
compatible = "google,cr50";
-   ready-gpio = <&gpio_n 0x1c GPIO_ACTIVE_LOW>;
+   ready-gpios = <&gpio_n 0x1c GPIO_ACTIVE_LOW>;
interrupts-extended = <&acpi_gpe 0x3c 0>;
};
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index 1af943d6ff..d68534e7a9 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -608,7 +608,7 @@ static int cr50_i2c_ofdata_to_platdata(struct udevice *dev)
priv->irq = irq;
priv->use_irq = true;
} else {
-   ret = gpio_request_by_name(dev, "ready-gpio", 0,
+   ret = gpio_request_by_name(dev, "ready-gpios", 0,
   &priv->ready_gpio, GPIOD_IS_IN);
if (ret) {
log_warning("Cr50 does not have an ready GPIO/interrupt 
(err=%d)\n",
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 007/108] dm: pci: Allow disabling auto-config for a device

2020-01-26 Thread Simon Glass
Add a means to avoid configuring a device when needed. Add an explanation
of why this is useful to the binding file.

Signed-off-by: Simon Glass 
---

 doc/device-tree-bindings/pci/x86-pci.txt | 24 
 drivers/pci/pci-uclass.c |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/doc/device-tree-bindings/pci/x86-pci.txt 
b/doc/device-tree-bindings/pci/x86-pci.txt
index 3aa5bd9a46..62b29a4e36 100644
--- a/doc/device-tree-bindings/pci/x86-pci.txt
+++ b/doc/device-tree-bindings/pci/x86-pci.txt
@@ -10,6 +10,17 @@ Optional properties:
configuration in TPL/SPL to reduce code size and boot time, since these
phases only know about a small subset of PCI devices.
 
+For PCI devices the following optional property is available:
+
+- pci,no-autoconfig : Don't automatically configure this PCI device at all.
+   This is used when the device is statically configured and must maintain
+   this same config throughout the boot process. An example is a serial
+   UART being used to debug PCI configuration, since reconfiguring it stops
+   the UART from working until the driver is re-probed, and this can cause
+   output to be lost. This should not generally be used in production code,
+   although it is often harmless.
+
+
 Example:
 
 pci {
@@ -21,4 +32,17 @@ pci {
0x4200 0x0 0xb000 0xb000 0 0x1000
0x0100 0x0 0x1000 0x1000 0 0xefff>;
u-boot,skip-auto-config-until-reloc;
+
+
+   serial: serial@18,2 {
+   reg = <0x0200c210 0 0 0 0>;
+   u-boot,dm-pre-reloc;
+   compatible = "intel,apl-ns16550";
+   early-regs = <0xde00 0x20>;
+   reg-shift = <2>;
+   clock-frequency = <1843200>;
+   current-speed = <115200>;
+   acpi,name = "URT3";
+   pci,no-autoconfig;
+   };
 };
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index bb272b67a1..f5f713fdf4 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -535,6 +535,8 @@ int pci_auto_config_devices(struct udevice *bus)
int ret;
 
debug("%s: device %s\n", __func__, dev->name);
+   if (dev_read_bool(dev, "pci,no-autoconfig"))
+   continue;
ret = dm_pciauto_config_device(dev);
if (ret < 0)
return ret;
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 012/108] dm: core: Add basic ACPI support

2020-01-26 Thread Simon Glass
ACPI (Advanced Configuration and Power Interface) is an Intel standard
for specifying information about a platform. It is a little like device
tree but considerably more complicated and with more backslashes. A
primary difference is that it supports an interpreted bytecode language.

Driver model does not use ACPI for U-Boot's configuration, but it is
convenient to have it support generation of ACPI tables for passing to
Linux, etc.

As a starting point, add an optional set of ACPI operations to each
device. Initially only a single operation is available, to obtain the
ACPI name for the device. More operations are added later.

Enable ACPI for sandbox to ensure build coverage and so that we can add
tests.

Signed-off-by: Simon Glass 
---

 drivers/core/Kconfig  |  9 ++
 drivers/core/Makefile |  1 +
 drivers/core/acpi.c   | 32 +++
 include/dm/acpi.h | 73 +++
 include/dm/device.h   |  5 +++
 5 files changed, 120 insertions(+)
 create mode 100644 drivers/core/acpi.c
 create mode 100644 include/dm/acpi.h

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 3b95b5387b..a3b0399342 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -261,4 +261,13 @@ config DM_DEV_READ_INLINE
bool
default y if !OF_LIVE
 
+config ACPIGEN
+   bool "Support ACPI table generation in driver model"
+   default y if SANDBOX || GENERATE_ACPI_TABLE
+   help
+ This option enables generation of ACPI tables using driver-model
+ devices. It adds a new operation struct to each driver, to support
+ things like generating device-specific tables and returning the ACPI
+ name of a device.
+
 endmenu
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index bce7467da1..c707026a3a 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -3,6 +3,7 @@
 # Copyright (c) 2013 Google, Inc
 
 obj-y  += device.o fdtaddr.o lists.o root.o uclass.o util.o
+obj-$(CONFIG_$(SPL_TPL_)ACPIGEN) += acpi.o
 obj-$(CONFIG_DEVRES) += devres.o
 obj-$(CONFIG_$(SPL_)DM_DEVICE_REMOVE)  += device-remove.o
 obj-$(CONFIG_$(SPL_)SIMPLE_BUS)+= simple-bus.o
diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
new file mode 100644
index 00..45542199f5
--- /dev/null
+++ b/drivers/core/acpi.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Core driver model support for ACPI table generation
+ *
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass 
+ */
+
+#define LOG_CATEOGRY   LOGC_ACPI
+
+#include 
+#include 
+#include 
+#include 
+
+int acpi_return_name(char *out_name, const char *name)
+{
+   strcpy(out_name, name);
+
+   return 0;
+}
+
+int acpi_get_name(const struct udevice *dev, char *out_name)
+{
+   struct acpi_ops *aops;
+
+   aops = device_get_acpi_ops(dev);
+   if (aops && aops->get_name)
+   return aops->get_name(dev, out_name);
+
+   return -ENOSYS;
+}
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
new file mode 100644
index 00..120576adc0
--- /dev/null
+++ b/include/dm/acpi.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Core ACPI (Advanced Configuration and Power Interface) support
+ *
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass 
+ */
+
+#ifndef __DM_ACPI_H__
+#define __DM_ACPI_H__
+
+/* Allow operations to be optional for ACPI */
+#if CONFIG_IS_ENABLED(ACPIGEN)
+#define acpi_ops_ptr(_ptr) .acpi_ops   = _ptr,
+#else
+#define acpi_ops_ptr(_ptr)
+#endif
+
+/* Length of an ACPI name string, excluding nul terminator */
+#define ACPI_NAME_LEN  4
+
+/* Length of an ACPI name string including nul terminator */
+#define ACPI_NAME_MAX  5
+
+/**
+ * struct acpi_ops - ACPI operations supported by driver model
+ */
+struct acpi_ops {
+   /**
+* get_name() - Obtain the ACPI name of a device
+*
+* @dev: Device to check
+* @out_name: Place to put the name, must hold at least ACPI_NAME_MAX
+*  bytes
+* @return 0 if OK, -ENOENT if no name is available, other -ve value on
+*  other error
+*/
+   int (*get_name)(const struct udevice *dev, char *out_name);
+};
+
+#define device_get_acpi_ops(dev)   ((dev)->driver->acpi_ops)
+
+/**
+ * acpi_get_name() - Obtain the ACPI name of a device
+ *
+ * @dev: Device to check
+ * @out_name: Place to put the name, must hold at least ACPI_NAME_MAX
+ * bytes
+ * @return 0 if OK, -ENOENT if no name is available, other -ve value on
+ * other error
+ */
+int acpi_get_name(const struct udevice *dev, char *out_name);
+
+/**
+ * acpi_return_name() - Copy an ACPI name to an output buffer
+ *
+ * This convenience function can be used to return a literal string as a name
+ * in functions that implement the get_name() method.
+ *
+ * For example:
+ *
+ * static int mydev_get_name(const struct udevice *dev, char *out_name)
+ * {
+ * return acpi_return_name(out_name, "WIB

[PATCH 013/108] acpi: Add a binding for ACPI settings in the device tree

2020-01-26 Thread Simon Glass
Devices need to report various identifiers in the ACPI tables. Rather than
hard-coding these in drivers it is typically better to put them in the
device tree.

Add a binding file to describe this.

Signed-off-by: Simon Glass 
---

 doc/device-tree-bindings/device.txt | 37 +
 1 file changed, 37 insertions(+)
 create mode 100644 doc/device-tree-bindings/device.txt

diff --git a/doc/device-tree-bindings/device.txt 
b/doc/device-tree-bindings/device.txt
new file mode 100644
index 00..e625e67f43
--- /dev/null
+++ b/doc/device-tree-bindings/device.txt
@@ -0,0 +1,37 @@
+Devices
+===
+
+Device bindings are described by their own individual binding files.
+
+U-Boot provides for some optional properties which are documented here.
+
+ - acpi,has-power-resource : (boolean) true if this device has a power 
resource.
+This causes a PRIC (ACPI PowerResource) to be written containing the
+properties provided by this binding, to describe how to handle powering the
+device up and down using GPIOs
+ - acpi,cid : Contains the string to use as the compatible ID (_CID)
+ - acpi,compatible : compatible string to report
+ - acpi,desc : Contains the string to use as the _DDN (DOS (Disk Operating
+System) Device Name)
+ - acpi,hid : Contains the string to use as the HID (Human Interface Device)
+identifier _HID
+ - acpi,hid-desc-reg-offset : HID register offset (for Human Interface Devices)
+ - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
+Linux will not re-init the device
+ - acpi,uid : _UID value for device
+
+
+Example
+---
+
+synaptics_touchpad: synaptics-touchpad@2c {
+   compatible = "i2c-chip";
+   reg = <0x2c>;
+   acpi,hid = "PNP0C50";
+   acpi,cid = "PNP0C50";
+   acpi,desc = "Synaptics Touchpad";
+   interrupts-extended = <&acpi_gpe GPIO_18_IRQ
+   IRQ_TYPE_EDGE_FALLING>;
+   acpi,probed;
+   acpi,hid-desc-reg-offset = <0x20>;
+};
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 019/108] acpi: Move acpi_fill_header() to generic code

2020-01-26 Thread Simon Glass
This function needs to be used by sandbox for tests. Move it into the
generic directory.

Signed-off-by: Simon Glass 
---

 include/acpi_table.h  | 10 ++
 lib/acpi/acpi_table.c | 10 ++
 test/dm/acpi.c| 28 
 3 files changed, 48 insertions(+)

diff --git a/include/acpi_table.h b/include/acpi_table.h
index d5a9e1c96f..9904e421c3 100644
--- a/include/acpi_table.h
+++ b/include/acpi_table.h
@@ -501,6 +501,16 @@ int acpi_get_table_revision(enum acpi_tables table);
  */
 int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags);
 
+/**
+ * acpi_fill_header() - Set up a new table header
+ *
+ * This sets all fields except length, revision, checksum and aslc_revision
+ *
+ * @header: ACPI header to update
+ * @signature: Table signature to use (4 characters)
+ */
+void acpi_fill_header(struct acpi_table_header *header, char *signature);
+
 #endif /* !__ACPI__*/
 
 #include 
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 85147ac61a..771a3580ce 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags)
 {
@@ -83,3 +84,12 @@ int acpi_get_table_revision(enum acpi_tables table)
return -EINVAL;
}
 }
+
+void acpi_fill_header(struct acpi_table_header *header, char *signature)
+{
+   memcpy(header->signature, signature, 4);
+   memcpy(header->oem_id, OEM_ID, 6);
+   memcpy(header->oem_table_id, OEM_TABLE_ID, 8);
+   header->oem_revision = U_BOOT_BUILD_DATE;
+   memcpy(header->aslc_id, ASLC_ID, 4);
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 2737896643..e28ebf4f90 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,3 +82,30 @@ static int dm_test_acpi_create_dmar(struct unit_test_state 
*uts)
return 0;
 }
 DM_TEST(dm_test_acpi_create_dmar, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test acpi_fill_header() */
+static int dm_test_acpi_fill_header(struct unit_test_state *uts)
+{
+   struct acpi_table_header hdr;
+
+   /* Make sure these 5 fields are not changed */
+   hdr.length = 0x11;
+   hdr.revision = 0x22;
+   hdr.checksum = 0x33;
+   hdr.aslc_revision = 0x44;
+   acpi_fill_header(&hdr, "ABCD");
+
+   ut_assertok(memcmp("ABCD", hdr.signature, sizeof(hdr.signature)));
+   ut_asserteq(0x11, hdr.length);
+   ut_asserteq(0x22, hdr.revision);
+   ut_asserteq(0x33, hdr.checksum);
+   ut_assertok(memcmp(OEM_ID, hdr.oem_id, sizeof(hdr.oem_id)));
+   ut_assertok(memcmp(OEM_TABLE_ID, hdr.oem_table_id,
+  sizeof(hdr.oem_table_id)));
+   ut_asserteq(U_BOOT_BUILD_DATE, hdr.oem_revision);
+   ut_assertok(memcmp(ASLC_ID, hdr.aslc_id, sizeof(hdr.aslc_id)));
+   ut_asserteq(0x44, hdr.aslc_revision);
+
+   return 0;
+}
+DM_TEST(dm_test_acpi_fill_header, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.25.0.341.g760bfbb309-goog



[PATCH 010/108] pci: Adjust dm_pci_read_bar32() to return errors correctly

2020-01-26 Thread Simon Glass
At present if reading a BAR returns 0x (e.g. the device is not
present) then the value is masked and a different value is returned.
This makes it harder to detect the problem when debugging.

Update the function to avoid masking in this case.

Signed-off-by: Simon Glass 
---

 drivers/pci/pci-uclass.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index f5f713fdf4..ed57ff9ebe 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1210,7 +1210,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int 
barnum)
 
bar = PCI_BASE_ADDRESS_0 + barnum * 4;
dm_pci_read_config32(dev, bar, &addr);
-   if (addr & PCI_BASE_ADDRESS_SPACE_IO)
+
+   /*
+* If we get an invalid address, return this so that comparisons with
+* FDT_ADDR_T_NONE work correctly
+*/
+   if (addr == 0x)
+   return addr;
+   else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
return addr & PCI_BASE_ADDRESS_IO_MASK;
else
return addr & PCI_BASE_ADDRESS_MEM_MASK;
-- 
2.25.0.341.g760bfbb309-goog



  1   2   3   >