Re: [U-Boot] [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands

2019-05-02 Thread Schrempf Frieder
Hi Ashish,

On 01.05.19 07:32, Ashish Kumar wrote:
> 
> 
>> -Original Message-
>> From: U-Boot  On Behalf Of Schrempf Frieder
>> Sent: Tuesday, April 30, 2019 1:14 PM
>> To: Vignesh Raghavendra ; Rajat Srivastava
>> ; u-boot@lists.denx.de; ja...@openedev.com
>> Subject: [EXT] Re: [U-Boot] [PATCH 2/2] fsl_qspi: Improve QSPI driver to
>> incorporate 4 byte commands
>>
>> Caution: EXT Email
>>
>> Hi,
>>
>> On 26.04.19 06:58, Vignesh Raghavendra wrote:
>>>
>>>
>>> On 25/04/19 5:20 PM, Rajat Srivastava wrote:


> -Original Message-
> From: Vignesh Raghavendra 
> Sent: Wednesday, April 24, 2019 10:17 PM
> To: Rajat Srivastava ;
> u-boot@lists.denx.de; ja...@openedev.com
> Cc: Ashish Kumar 
> Subject: [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to
> incorporate 4 byte commands
>
> Caution: EXT Email
>
> On 24-Apr-19 6:10 PM, Rajat Srivastava wrote:
>> Signed-off-by: Ashish Kumar 
>> Signed-off-by: Rajat Srivastava 
>
> Commit message is missing.

 I'll add proper commit message in the next patch version.

> But from $patch subject, I infer that $patch is adding new feature
> and not actually fixing something broken?

 Earlier the framework was designed to work for only 3-byte opcodes
 but our controller supports flashes of size greater than 16 MB. As a
 workaround, FSL QSPI driver used to explicitly send 4-byte opcodes
 for 3-byte opcodes sent by framework to the flash. Also there used to
 exist a temporary patch for framework which never got accepted In
>> upstream.
 Now the new framework supports 4-byte opcodes and FSL QSPI driver
 needs correction. I am not introducing any new feature. I am just
 fixing the driver to suit the current framework.

>>>
>>> With SPL_FLASH_BAR set fsl_qspi driver should never see 4 byte opcodes
>>> and should work like it did before. I guess you are disabling SPI_FLASH_BAR?
>>>
>>> Please add all details to the commit message and I recommend you to
>>> move the driver over to spi-mem as soon as possible. Else you would
>>> have to keep handling new opcodes in your driver as and when spi-nor-core
>> changes.
>>>
>>> Regards
>>> Vignesh
>>>
 Please let me know your feedback.

 Regards
 Rajat

> If so, you should move the driver over to use spi-mem APIs instead
> of adding more features and hard coding more flash specific commands in
>> the driver.
> This makes driver duplicate more of spi-nor core code. I discourage
> adding new features w/o moving driver over to spi-mem. IMHO,
> converting the driver would not be a huge effort. And I believe its 
> already
>> done in kernel.
>>
>> I started moving the driver to spi-mem, by porting the kernel driver over to 
>> U-
>> Boot. I still have some Kconfig dependency problem for the
>> LS2081 platform (CONFIG_SPI_MEM is not enabled implicitly), that needs to
>> be solved, otherwise it should be more or less ready.
> Hi Frieder,
> 
> What is the change, it seems it is moving the driver from Linux as it is to 
> uboot ?

Yes, it's moving the current Linux driver to U-Boot with some small 
compatibility changes and simplifications.

> I am not sure how stable is the current Linux driver, since it is not yet 
> tested by FSL/NXP system test team. Last time I tested the current Linux 
> driver(QSPI) it was functional in only 1-1-1 mode. Moving to u-boot may not 
> be good idea at this point of time.

The current mainline Linux driver is a SPI controller driver using the 
SPI MEM API and it replaced the old SPI NOR driver in Linux 5.1. If 
nothing went wrong in the upstreaming process, the driver should be just 
as good as the old one, while bringing all the advantages of the new SPI 
MEM interface. The driver does support 1-1-1 mode, just like all other 
modes supported by the QSPI controller.

While upstreaming to the kernel, the driver was tested by Han Xu and 
Yogesh Gaur.

> How do you plan to cater  CONFIG_SPI_BAR change in uboot now. Some old board 
> still uses flash that supports CONFIG_SPI_BAR.

The new driver is not a SPI NOR driver, so it does not care about 
CONFIG_SPI_BAR. It just handels SPI MEM operations created by the upper 
layer.

> Me and Rajat have recently posted patches to fix current u-boot driver to be 
> functional with new frame work pushed by Vignesh, and it serves all the 
> current supported board with and without CONFIG_SPI_BAR.
> 
> May be spi-nxp-fspi.c can be a good starting point, but then again I not sure 
> how booting from serial-nand will be taken care in that case.

Please have a look at the SPI MEM and SPI NAND APIs to understand why 
porting the Linux driver is the right thing to do instead of patching 
the old driver. By supporting the SPI MEM API, the driver will 
implicitly allow to interface SPI NAND chips.

Thanks,
Frieder
___
U-Boot mailing list
U-Boot@lists.d

Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND

2019-05-02 Thread Markus Klotzbuecher
Hello Heiko

On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote:

>Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher:
>> From: Markus Klotzbuecher 
>
>please add a commit message.
>
>> Signed-off-by: Markus Klotzbuecher 
>> Cc: Heiko Schocher 
>> Cc: Kyungmin Park 
>> ---
>>   env/Kconfig  | 6 ++
>>   scripts/config_whitelist.txt | 1 -
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/env/Kconfig b/env/Kconfig
>> index 78300660c7..44c47220c2 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME
>>  help
>>Name of the volume that you want to store the environment in.
>> +config ENV_UBI_VOLUME_REDUND
>> +string "UBI redundant volume name"
>> +depends on ENV_IS_IN_UBI
>> +help
>> +  Name of the redundant volume that you want to store the environment 
>> in.
>> +
>>   endif
>>   config USE_DEFAULT_ENV_FILE
>> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
>> index fa98efc24c..5d76c781d3 100644
>> --- a/scripts/config_whitelist.txt
>> +++ b/scripts/config_whitelist.txt
>> @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK
>>   CONFIG_ENV_TOTAL_SIZE
>>   CONFIG_ENV_UBIFS_OPTION
>>   CONFIG_ENV_UBI_MTD
>> -CONFIG_ENV_UBI_VOLUME_REDUND
>>   CONFIG_ENV_VERSION
>>   CONFIG_EP9302
>>   CONFIG_EP9307
>> 
>
>Please move from the config files:
>
>./include/configs/omap3_igep00x0.h
>./include/configs/gardena-smart-gateway-at91sam.h
>./include/configs/am335x_igep003x.h
>
>also the symbols to the defconfig files, thanks.
>
>BTW: you can use the tool tools/moveconfig.py in u-boot source
>for this purpose.
>
>Beside of this, you can add my:
>
>Reviewed-by: Heiko Schocher 

Thank you for your feedback! I will go through it and submit a v2
within a few days.

Best regards
Markus

-- 
Markus Klotzbuecher
Freelancer Embedded, Distributed & Real-time Systems
Am See 28, 78465 Konstanz, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address

2019-05-02 Thread Eugeniu Rosca
Hi Stephen,

On Tue, Apr 30, 2019 at 11:59:56AM -0600, Stephen Finucane wrote:
> On Tue, 2019-04-30 at 14:28 +0200, Eugeniu Rosca wrote:
> > Hi Jeremy,
> > 
> > Would you kindly feedback if it's possible to include commit
> > https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
> > into U-Boot's patchwork to avoid occasional glitches in the
> > description of U-Boot commits?
> 
> This is included in 2.1.1 [1] which patchwork.ozlabs.org was recently
> updated to [2], so you should have this fix now. Let me know if I've
> missed something.

Thanks for the input. I will let you know if there are any Reviewed-by
signatures climbing erratically in my next patches :)

> 
> Stephen
> 
> [1] https://github.com/getpatchwork/patchwork/commit/8060b9a671
> [2] https://lists.ozlabs.org/pipermail/patchwork/2019-April/005746.html

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


Re: [U-Boot] [PATCH] dma: ti: k3-udma: Do not touch RT registers before channel configuration

2019-05-02 Thread Keerthy



On 25/04/19 11:49 PM, Grygorii Strashko wrote:



On 25.04.19 09:38, Vignesh Raghavendra wrote:

From: Peter Ujfalusi 

Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.

Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vignesh Raghavendra 
---
  drivers/dma/ti/k3-udma.c | 33 +
  1 file changed, 9 insertions(+), 24 deletions(-)


Reviewed-by: Grygorii Strashko 


Tom,

This is needed for cpsw to work am65. Please pull this patch.

Thanks,
Keerthy




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


Re: [U-Boot] [PATCH 0/3] Add Avenger96 board support

2019-05-02 Thread Patrice CHOTARD
Hi Manivannan

On 4/29/19 2:03 PM, Manivannan Sadhasivam wrote:
> Hello,
> 
> This patchset adds board support for Avenger96, a 96Boards Consumer
> Edition board from Arrow Electronics. This board is based on the
> STM32MP1 MPU and the board support is added under st boards since
> there are no significance changes required to boot u-boot on this
> board other than the dts.
> 
> More information about this board can be found in 96Boards website:
> https://www.96boards.org/product/avenger96/
> 
> PS: I only managed to boot u-boot as SSBL with TF-A as FSBL. U-boot
> SPL way of booting is not working.

What are the symptoms ?

Patrice

> 
> Thanks,
> Mani
> 
> Manivannan Sadhasivam (3):
>   arm: dts: stm32mp157: Add missing pinctrl definitions
>   board: stm32mp1: Add Avenger96 board support
>   arm: mach-stm32mp: Add newline to the MAC error message
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/stm32mp157-pinctrl.dtsi  |  63 +++
>  .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 177 +
>  arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
>  arch/arm/mach-stm32mp/cpu.c   |   2 +-
>  board/st/stm32mp1/README  |  23 ++
>  6 files changed, 627 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v6 0/3] arm64: rockchip: dts: Add rk3399 -u-boot.dtsi files

2019-05-02 Thread Paul Kocialkowski
Hi,

On Sat, 2019-04-27 at 17:11 +0530, Jagan Teki wrote:
> This series is a rework of v5 patch that send it in separate series[1]
> 
> All these changes are creating an initial rk3399-u-boot.dtsi and rk3399
> board -u-boot.dtsi files and u-boot specific dts changes like
> - sdram dtsi
> - sdmmc, u-boot,dm-pre-reloc
> - spi1, u-boot,dm-pre-reloc

For the whole series:
Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Changes for v6:
> - spilt the existing patch[1] into multiple patches
>   and send as a separate series.
> 
> [1] https://patchwork.ozlabs.org/patch/1091720/
> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (3):
>   arm64: rockchip: dts: rk3399: Add board -u-boot.dtsi files
>   arm64: rockchip: dts: Add initial rk3399-u-boot.dtsi file
>   arm64: rockchip: dts: rk3399: Use rk3399-u-boot.dtsi
> 
>  arch/arm/dts/rk3399-evb-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-evb.dts |  2 --
>  arch/arm/dts/rk3399-ficus-u-boot.dtsi   |  6 ++
>  arch/arm/dts/rk3399-ficus.dts   |  1 -
>  arch/arm/dts/rk3399-firefly-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-firefly.dts |  2 --
>  arch/arm/dts/rk3399-gru-bob-u-boot.dtsi |  7 +++
>  arch/arm/dts/rk3399-gru-bob.dts |  1 -
>  arch/arm/dts/rk3399-gru-u-boot.dtsi |  6 ++
>  arch/arm/dts/rk3399-gru.dtsi|  1 -
>  arch/arm/dts/rk3399-puma-ddr1600.dts|  1 +
>  arch/arm/dts/rk3399-puma.dtsi   |  3 ---
>  arch/arm/dts/rk3399-rock960-u-boot.dtsi |  6 ++
>  arch/arm/dts/rk3399-rock960.dts |  1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 12 
>  15 files changed, 52 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-evb-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-ficus-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-firefly-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-bob-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-rock960-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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


Re: [U-Boot] [PATCH v12 5/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

2019-05-02 Thread Chee, Tien Fong
On Tue, 2019-04-30 at 14:24 +0200, Simon Goldschmidt wrote:
> On Tue, Apr 30, 2019 at 2:09 PM Chee, Tien Fong
>  wrote:
> > 
> > 
> > On Sat, 2019-04-27 at 21:57 +0200, Simon Goldschmidt wrote:
> > > 
> > > 
> > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add FPGA driver to support program FPGA with FPGA bitstream
> > > > loading
> > > > from
> > > > filesystem. The driver are designed based on generic firmware
> > > > loader
> > > > framework. The driver can handle FPGA program operation from
> > > > loading FPGA
> > > > bitstream in flash to memory and then to program FPGA.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > 
> > > > ---
> > > > 
> > > > changes for v12
> > > > - No changes.
> > > > 
> > > > changes for v11
> > > > - No changes.
> > > > 
> > > > changes for v10
> > > > -Cleaned up the codes.
> > > > -Return -EPERM when programing core on non early IO release
> > > > mode. >
> > > > -Using live function to get rid of gd->
> > > You got rid of gd-> in v10? How come I see numerous references to
> > > it
> > > below?
> > get rid of using gd->fdt_blob for finding the node_offset.
> > Details in https://patchwork.ozlabs.org/patch/1044415/
> Ah, ok. But still, here you're introducing yet more references to gd-
> >fdt_blob.
> That wouldn't work with a live tree, either, or would it?

Yeah, few direct call to config_pin function are still using gd-
fdt_blob as argument. But, i'm not sure i should fix this function in
this series patch set, or separately patch after this series patch set?

What do you think?

Thanks,
TF
> 
> > 
> > 
> > -/*
> > - * FPGA Manager to program the FPGA. This is the interface used by
> > FPGA driver.
> > - * Return 0 for sucess, non-zero for error.
> > - */
> > +ofnode get_fpga_mgr_ofnode(void)
> > +{
> > +   int node_offset;
> > +
> > +   fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr",
> > 
> > nit: using of live functions would be better to get rid of gd->.
> > 
> > +   COMPAT_ALTERA_SOCFPGA_FPGA0,
> > +   &node_offset, 1);
> > 
> > Thanks.
> > > 
> > > 
> > > > 
> > > > 
> > > > -Removed @0 for fs-loader node
> > > > 
> > > > changes for v9
> > > > - Support data offset
> > > > - Added default DDR load address
> > > > - Squashed the image.h
> > > > - Changed to phandle
> > > > - Ensure the DDR is fully up running by checking the gd->ram
> > > > 
> > > > changes for v8
> > > > - Added codes to discern bitstream type based on fpga node
> > > > name.
> > > > 
> > > > changes for v7
> > > > - Restructure the FPGA driver to support both peripheral
> > > > bitstream
> > > > and core
> > > >    bitstream bundled into FIT image.
> > > > - Support loadable property for core bitstream. User can set
> > > > loadable
> > > >    in DDR for better performance. This loading would be done in
> > > > one
> > > > large
> > > >    chunk instead of chunk by chunk loading with small memory
> > > > buffer.
> > > > ---
> > > >   arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> > > >   .../include/mach/fpga_manager_arria10.h|  39 +-
> > > >   drivers/fpga/socfpga_arria10.c | 497
> > > > -
> > > >   include/image.h|   4 +
> > > >   4 files changed, 542 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > index 998d811210..cc761967c7 100644
> > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > @@ -18,6 +18,23 @@
> > > >   /dts-v1/;
> > > >   #include "socfpga_arria10_socdk.dtsi"
> > > > 
> > > > +/ {
> > > > +   chosen {
> > > > +   firmware-loader = <&fs_loader0>;
> > > > +   };
> > > > +
> > > > +   fs_loader0: fs-loader {
> > > > +   u-boot,dm-pre-reloc;
> > > > +   compatible = "u-boot,fs-loader";
> > > > +   phandlepart = <&mmc 1>;
> > > > +   };
> > > > +};
> > > > +
> > > > +&fpga_mgr {
> > > > +   u-boot,dm-pre-reloc;
> > > > +   altr,bitstream = "fit_spl_fpga.itb";
> > > > +};
> > > > +
> > > >   &mmc {
> > > > u-boot,dm-pre-reloc;
> > > > status = "okay";
> > > > diff --git a/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h
> > > > index 09d13f6fd3..c5f67714aa 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > @@ -1,9 +1,13 @@
> > > >   /* SPDX-License-Identifier: GPL-2.0 */
> > > >   /*
> > > > - * Copyright (C) 2017 Intel Corporation 
> > > > + * Copyright (C) 2017-2019 Intel Corporation 
> > > >    * All rights reserved.
> > > >    */
> > > > 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > >   #if

Re: [U-Boot] [PATCH 0/3] Add Avenger96 board support

2019-05-02 Thread Manivannan Sadhasivam
Hi Patrick,

On Thu, May 02, 2019 at 07:27:14AM +, Patrice CHOTARD wrote:
> Hi Manivannan
> 
> On 4/29/19 2:03 PM, Manivannan Sadhasivam wrote:
> > Hello,
> > 
> > This patchset adds board support for Avenger96, a 96Boards Consumer
> > Edition board from Arrow Electronics. This board is based on the
> > STM32MP1 MPU and the board support is added under st boards since
> > there are no significance changes required to boot u-boot on this
> > board other than the dts.
> > 
> > More information about this board can be found in 96Boards website:
> > https://www.96boards.org/product/avenger96/
> > 
> > PS: I only managed to boot u-boot as SSBL with TF-A as FSBL. U-boot
> > SPL way of booting is not working.
> 
> What are the symptoms ?
> 

It was my bad. Just found that I missed few `u-boot,dm-pre-reloc` properties
in DTS!

Will send the next version of the patchset incorporating those changes.

Thanks,
Mani

> Patrice
> 
> > 
> > Thanks,
> > Mani
> > 
> > Manivannan Sadhasivam (3):
> >   arm: dts: stm32mp157: Add missing pinctrl definitions
> >   board: stm32mp1: Add Avenger96 board support
> >   arm: mach-stm32mp: Add newline to the MAC error message
> > 
> >  arch/arm/dts/Makefile |   1 +
> >  arch/arm/dts/stm32mp157-pinctrl.dtsi  |  63 +++
> >  .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 177 +
> >  arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
> >  arch/arm/mach-stm32mp/cpu.c   |   2 +-
> >  board/st/stm32mp1/README  |  23 ++
> >  6 files changed, 627 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 0/3] Add Avenger96 board support

2019-05-02 Thread Manivannan Sadhasivam
Hello,

This patchset adds board support for Avenger96, a 96Boards Consumer
Edition board from Arrow Electronics. This board is based on the
STM32MP1 MPU and the board support is added under st boards since
there are no significance changes required to boot u-boot on this
board other than the dts.

More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/

Thanks,
Mani

Changes in v2:

* Added missing `u-boot,dm-pre-reloc` property to UART and SDMMC nodes
  and verified SPL boot.

Manivannan Sadhasivam (3):
  arm: dts: stm32mp157: Add missing pinctrl definitions
  board: stm32mp1: Add Avenger96 board support
  arm: mach-stm32mp: Add newline to the MAC error message

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/stm32mp157-pinctrl.dtsi  |  63 +++
 .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 191 +
 arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
 arch/arm/mach-stm32mp/cpu.c   |   2 +-
 board/st/stm32mp1/README  |  23 ++
 6 files changed, 641 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts

-- 
2.17.1

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


Re: [U-Boot] [PATCH v12 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

2019-05-02 Thread Chee, Tien Fong
On Tue, 2019-04-30 at 14:26 +0200, Simon Goldschmidt wrote:
> On Tue, Apr 30, 2019 at 2:19 PM Chee, Tien Fong
>  wrote:
> > 
> > 
> > On Sat, 2019-04-27 at 21:50 +0200, Simon Goldschmidt wrote:
> > > 
> > > 
> > > On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Increasing Malloc pool size up to 0x15000 is required to
> > > > support
> > > > FAT in SPL
> > > > . The result of calculation is come from after applying some
> > > > few
> > > > patches
> > > "Some few patches"? What should that mean? Either you refer to
> > > the
> > > current state or you can refer to the patchwork items.
> > > 
> > > > 
> > > > 
> > > > which are required for optimizing vfat and maximizing resusable
> > > > of
> > > > the
> > > > memory pool, and then followed by the size required come from
> > > > default max
> > > > cluster(0x1) + others(0x2000) + additional memory for
> > > > headroom(0x3000).
> > > > Previous records of describing these few patches can be checked
> > > > from here
> > > > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg3145
> > > > 11.h
> > > > tml .
> > > Why do you refer to mail-archive.com instead of patchwork?
> > Contains the cover letter in case reviewer need to know more
> > information.
> I think you understood that wrong. Why do you reference a 3rd party
> host (mail-archive.com) instead of the official list archive or
> patchwork?
> 
> And please note patchwork keeps the cover letter as well.

Okay, i can't find any cover letter from this link https://patchwork.oz
labs.org/project/uboot/list/?series=&submitter=70549&state=*&q=&archive
=both&delegate= . Do you know how to find it?

> 
> Also note, this is the commit message which will got into the git
> lot.
> Referencing v7 and older history seems misplaced here. Better move
> it below the '---'.

Okay, noted. So, what should i do with this patch now? Should i send
next version with new commit message?

Thanks.
TF

> 
> > 
> > 
> > Thanks.
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > 
> > > > ---
> > > > 
> > > > changes for v12
> > > > - Improved the commit messages.
> > > > 
> > > > changes for v11
> > > > - No changes.
> > > > 
> > > > changes for v10
> > > > - No changes.
> > > > 
> > > > changes for v9
> > > > - No changes.
> > > > 
> > > > changes for v8
> > > > - Moved the FIT related configs to the patch of configuration
> > > > for
> > > > FPGA
> > > >    SoCFPGA A10 SoCDK.
> > > > 
> > > > changes for v7
> > > > - Keep minimal configs.
> > > > ---
> > > >   include/configs/socfpga_common.h | 4 ++--
> > > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/include/configs/socfpga_common.h
> > > > b/include/configs/socfpga_common.h
> > > > index 181af9b646..22533036ed 100644
> > > > --- a/include/configs/socfpga_common.h
> > > > +++ b/include/configs/socfpga_common.h
> > > > @@ -1,6 +1,6 @@
> > > >   /* SPDX-License-Identifier: GPL-2.0+ */
> > > >   /*
> > > > - * Copyright (C) 2012 Altera Corporation 
> > > > + * Copyright (C) 2012-2019 Altera Corporation 
> > > >    */
> > > >   #ifndef __CONFIG_SOCFPGA_COMMON_H__
> > > >   #define __CONFIG_SOCFPGA_COMMON_H__
> > > > @@ -254,7 +254,7 @@ unsigned int
> > > > cm_get_qspi_controller_clk_hz(void);
> > > >   #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > > >   /* SPL memory allocation configuration, this is for FAT
> > > > implementation */
> > > >   #ifndef CONFIG_SYS_SPL_MALLOC_START
> > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
> > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000
> > > >   #define
> > > > CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_S
> > > > IZE - \
> > > >  CONFIG_SYS_SPL_MALLOC_SI
> > > > ZE + \
> > > >  CONFIG_SYS_INIT_RAM_ADDR
> > > > )
> > > > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/3] arm: dts: stm32mp157: Add missing pinctrl definitions

2019-05-02 Thread Manivannan Sadhasivam
Add missing pinctrl definitions for STM32MP157.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/dts/stm32mp157-pinctrl.dtsi | 63 
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi 
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 0aae69b0a04..200d2c00c5f 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -220,6 +220,16 @@
};
};
 
+   i2c1_pins_b: i2c1-1 {
+   pins {
+   pinmux = , 
/* I2C1_SCL */
+; 
/* I2C1_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
i2c2_pins_a: i2c2-0 {
pins {
pinmux = , 
/* I2C2_SCL */
@@ -230,6 +240,16 @@
};
};
 
+   i2c2_pins_b: i2c2-1 {
+   pins {
+   pinmux = , 
/* I2C2_SCL */
+; 
/* I2C2_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
i2c5_pins_a: i2c5-0 {
pins {
pinmux = , 
/* I2C5_SCL */
@@ -375,6 +395,21 @@
};
};
 
+   spi2_pins_a: spi2-0 {
+   pins1 {
+   pinmux = , 
/* SPI2_SCK */
+, 
/* SPI2_NSS */
+; 
/* SPI2_MOSI */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <3>;
+   };
+   pins2 {
+   pinmux = ; 
/* SPI2_MISO */
+   bias-disable;
+   };
+   };
+
stusb1600_pins_a: stusb1600-0 {
pins {
pinmux = ;
@@ -395,6 +430,34 @@
};
};
 
+   uart4_pins_b: uart4-1 {
+   pins1 {
+   pinmux = ; 
/* UART4_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = ; 
/* UART4_RX */
+   bias-disable;
+   };
+   };
+
+   uart7_pins_a: uart7-0 {
+   pins1 {
+   pinmux = ; 
/* UART4_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = , 
/* UART4_RX */
+, 
/* UART4_CTS */
+; 
/* UART4_RTS */
+   bias-disable;
+   };
+   };
+
usbotg_hs_pins_a: usbotg_hs-0 {
pins {
pinmux = ; /* OTG_ID */
-- 
2.17.1

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


Re: [U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot

2019-05-02 Thread Faiz Abbas
Hi,

On 14/02/19 6:56 PM, Marek Vasut wrote:
> Older kernel versions or systems which do not connect eMMC reset line
> properly may not be able to handle situations where either the eMMC
> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader
> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card
> to non-UHS mode before booting the kernel to allow such older kernels
> to work with modern U-Boot.

This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go
through and all following commands timeout.

Log:

U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200)

CPU  : DRA752-GP ES2.0
Model: TI DRA742
Board: DRA74x EVM REV H.0
DRAM:  4 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

Loading Environment from MMC... OK
Net:   eth0: ethernet@48484000
Hit any key to stop autoboot:  0
=>
=> boot
Booting from network ...
link up on port 0, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.1.52 (246 ms)
link up on port 0, speed 1000, full duplex
Using ethernet@48484000 device
TFTP from server 192.168.1.36; our IP address is 192.168.1.52
Filename 'zImage'.
Load address: 0x8700
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 3.3 MiB/s
done
Bytes transferred = 3556144 (364330 hex)
link up on port 0, speed 1000, full duplex
Using ethernet@48484000 device
TFTP from server 192.168.1.36; our IP address is 192.168.1.52
Filename 'dra7-evm.dtb'.
Load address: 0x8800
Loading: ##
 2.9 MiB/s
done
Bytes transferred = 108307 (1a713 hex)
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8ffe2000, end 8712 ... OK
Using machid 0xfe6 from environment

Starting kernel ...

omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear

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


[U-Boot] [PATCH v2 2/3] board: stm32mp1: Add Avenger96 board support

2019-05-02 Thread Manivannan Sadhasivam
Add support for Avenger96 board from Arrow Electronics based on STM32MP157
MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
family and has the following features:

SoC: STM32MP157AAC
PMIC: STPMIC1A
RAM: 1024 Mbyte @ 533MHz
Storage: eMMC v4.51: 8 Gbyte
 microSD Socket: UHS-1 v3.01
Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
  Bluetooth®v4.2 (BR/EDR/BLE)
USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
LED: 4x User LED, 1x WiFi LED, 1x BT LED

More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/dts/Makefile |   1 +
 .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 191 +
 arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
 board/st/stm32mp1/README  |  23 ++
 4 files changed, 577 insertions(+)
 create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b4dc57edbd1..97a182f3abc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -711,6 +711,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
 
 dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157a-dk1.dtb \
+   stm32mp157a-avenger96.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
new file mode 100644
index 000..1ff681afb87
--- /dev/null
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright : STMicroelectronics 2018
+ *
+ * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
+ * Author: Manivannan Sadhasivam 
+ */
+
+#include 
+#include "stm32mp157-u-boot.dtsi"
+#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
+
+/ {
+   aliases {
+   mmc0 = &sdmmc1;
+   mmc1 = &sdmmc2;
+   usb0 = &usbotg_hs;
+   };
+
+   config {
+   u-boot,boot-led = "led1";
+   u-boot,error-led = "led4";
+   };
+};
+
+&i2c4 {
+   u-boot,dm-pre-reloc;
+};
+
+&i2c4_pins_a {
+   u-boot,dm-pre-reloc;
+   pins {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+&pmic {
+   u-boot,dm-pre-reloc;
+};
+
+&rcc {
+   st,clksrc = <
+   CLK_MPU_PLL1P
+   CLK_AXI_PLL2P
+   CLK_MCU_PLL3P
+   CLK_PLL12_HSE
+   CLK_PLL3_HSE
+   CLK_PLL4_HSE
+   CLK_RTC_LSE
+   CLK_MCO1_DISABLED
+   CLK_MCO2_DISABLED
+   >;
+
+   st,clkdiv = <
+   1 /*MPU*/
+   0 /*AXI*/
+   0 /*MCU*/
+   1 /*APB1*/
+   1 /*APB2*/
+   1 /*APB3*/
+   1 /*APB4*/
+   2 /*APB5*/
+   23 /*RTC*/
+   0 /*MCO1*/
+   0 /*MCO2*/
+   >;
+
+   st,pkcs = <
+   CLK_CKPER_HSE
+   CLK_FMC_ACLK
+   CLK_QSPI_ACLK
+   CLK_ETH_DISABLED
+   CLK_SDMMC12_PLL4P
+   CLK_DSI_DSIPLL
+   CLK_STGEN_HSE
+   CLK_USBPHY_HSE
+   CLK_SPI2S1_PLL3Q
+   CLK_SPI2S23_PLL3Q
+   CLK_SPI45_HSI
+   CLK_SPI6_HSI
+   CLK_I2C46_HSI
+   CLK_SDMMC3_PLL4P
+   CLK_USBO_USBPHY
+   CLK_ADC_CKPER
+   CLK_CEC_LSE
+   CLK_I2C12_HSI
+   CLK_I2C35_HSI
+   CLK_UART1_HSI
+   CLK_UART24_HSI
+   CLK_UART35_HSI
+   CLK_UART6_HSI
+   CLK_UART78_HSI
+   CLK_SPDIF_PLL4P
+   CLK_FDCAN_PLL4Q
+   CLK_SAI1_PLL3Q
+   CLK_SAI2_PLL3Q
+   CLK_SAI3_PLL3Q
+   CLK_SAI4_PLL3Q
+   CLK_RNG1_LSI
+   CLK_RNG2_LSI
+   CLK_LPTIM1_PCLK1
+   CLK_LPTIM23_PCLK3
+   CLK_LPTIM45_LSE
+   >;
+
+   /* VCO = 1300.0 MHz => P = 650 (CPU) */
+   pll1: st,pll@0 {
+   cfg = < 2 80 0 0 0 PQR(1,0,0) >;
+   frac = < 0x800 >;
+   u-boot,dm-pre-reloc;
+   };
+
+   /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
+   pll2: st,pll@1 {
+   cfg = < 2 65 1 0 0 PQR(1,1,1) >;
+   frac = < 0x1400 >;
+   u-boot,dm-pre-reloc;
+   };
+
+   /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
+   pll3: st,pll@2 {
+   cfg = < 1 33 1 16 36 PQR(1,1,1) >;
+   frac = < 0x1a04 >;
+   u-boot,dm-pre-reloc;
+  

[U-Boot] [PATCH v2 3/3] arm: mach-stm32mp: Add newline to the MAC error message

2019-05-02 Thread Manivannan Sadhasivam
Without newline, the error message appears for non prgrammed OTP boards
looks messsy. Hence add it to look more clean.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/mach-stm32mp/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 7b4431c9c75..e1a0a136809 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -481,7 +481,7 @@ static int setup_mac_address(void)
enetaddr[i] = ((uint8_t *)&otp)[i];
 
if (!is_valid_ethaddr(enetaddr)) {
-   pr_err("invalid MAC address in OTP %pM", enetaddr);
+   pr_err("invalid MAC address in OTP %pM\n", enetaddr);
return -EINVAL;
}
pr_debug("OTP MAC address = %pM\n", enetaddr);
-- 
2.17.1

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


Re: [U-Boot] [RESEND PATCH] board: toradex: drop support.arm maintainer email

2019-05-02 Thread Stefan Agner
On 26.04.19 20:53, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Drop Toradex ARM Support  from maintainer email
> list as this just clogs our support ticketing system.

Acked-by: Stefan Agner 

--
Stefan

> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  board/toradex/colibri-imx6ull/MAINTAINERS | 1 -
>  board/toradex/colibri_imx7/MAINTAINERS| 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS 
> b/board/toradex/colibri-imx6ull/MAINTAINERS
> index 7cda555984..626c1f94f9 100644
> --- a/board/toradex/colibri-imx6ull/MAINTAINERS
> +++ b/board/toradex/colibri-imx6ull/MAINTAINERS
> @@ -1,6 +1,5 @@
>  Colibri iMX6ULL
>  M:   Stefan Agner 
> -M:   Toradex ARM Support 
>  W:   http://developer.toradex.com/software/linux/linux-software
>  W:   https://www.toradex.com/community
>  S:   Maintained
> diff --git a/board/toradex/colibri_imx7/MAINTAINERS 
> b/board/toradex/colibri_imx7/MAINTAINERS
> index f55f8045f4..cd0f9c9b2d 100644
> --- a/board/toradex/colibri_imx7/MAINTAINERS
> +++ b/board/toradex/colibri_imx7/MAINTAINERS
> @@ -1,6 +1,5 @@
>  Colibri iMX7
>  M:   Stefan Agner 
> -M:   Toradex ARM Support 
>  W:   http://developer.toradex.com/software/linux/linux-software
>  W:   https://www.toradex.com/community
>  S:   Maintained
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] board: stm32mp1: Add Avenger96 board support

2019-05-02 Thread Patrice CHOTARD
Hi Manivannan

On 4/29/19 2:03 PM, Manivannan Sadhasivam wrote:
> Add support for Avenger96 board from Arrow Electronics based on STM32MP157
> MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
> family and has the following features:
> 
> SoC: STM32MP157AAC
> PMIC: STPMIC1A
> RAM: 1024 Mbyte @ 533MHz
> Storage: eMMC v4.51: 8 Gbyte
>  microSD Socket: UHS-1 v3.01
> Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
> Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
>   Bluetooth®v4.2 (BR/EDR/BLE)
> USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
> Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
> LED: 4x User LED, 1x WiFi LED, 1x BT LED
> 
> More information about this board can be found in 96Boards website:
> https://www.96boards.org/product/avenger96/
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm/dts/Makefile |   1 +
>  .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 177 +
>  arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
>  board/st/stm32mp1/README  |  23 ++
>  4 files changed, 563 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b4dc57edbd1..97a182f3abc 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -711,6 +711,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  
>  dtb-$(CONFIG_TARGET_STM32MP1) += \
>   stm32mp157a-dk1.dtb \
> + stm32mp157a-avenger96.dtb \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
>   stm32mp157c-ev1.dtb
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> new file mode 100644
> index 000..dd6f0cf8b5f
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright : STMicroelectronics 2018
> + *
> + * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> + * Author: Manivannan Sadhasivam 
> + */
> +
> +#include 
> +#include "stm32mp157-u-boot.dtsi"
> +#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = &sdmmc1;
> + mmc1 = &sdmmc2;
> + usb0 = &usbotg_hs;
> + };
> +
> + config {
> + u-boot,boot-led = "led1";
> + u-boot,error-led = "led4";
> + };
> +};
> +
> +&i2c4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&i2c4_pins_a {

Shouldn't be i2c4_pins_b instead ? This should be the root cause of your
SPL issue.

> + u-boot,dm-pre-reloc;
> + pins {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&pmic {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&rcc {
> + st,clksrc = <
> + CLK_MPU_PLL1P
> + CLK_AXI_PLL2P
> + CLK_MCU_PLL3P
> + CLK_PLL12_HSE
> + CLK_PLL3_HSE
> + CLK_PLL4_HSE
> + CLK_RTC_LSE
> + CLK_MCO1_DISABLED
> + CLK_MCO2_DISABLED
> + >;
> +
> + st,clkdiv = <
> + 1 /*MPU*/
> + 0 /*AXI*/
> + 0 /*MCU*/
> + 1 /*APB1*/
> + 1 /*APB2*/
> + 1 /*APB3*/
> + 1 /*APB4*/
> + 2 /*APB5*/
> + 23 /*RTC*/
> + 0 /*MCO1*/
> + 0 /*MCO2*/
> + >;
> +
> + st,pkcs = <
> + CLK_CKPER_HSE
> + CLK_FMC_ACLK
> + CLK_QSPI_ACLK
> + CLK_ETH_DISABLED
> + CLK_SDMMC12_PLL4P
> + CLK_DSI_DSIPLL
> + CLK_STGEN_HSE
> + CLK_USBPHY_HSE
> + CLK_SPI2S1_PLL3Q
> + CLK_SPI2S23_PLL3Q
> + CLK_SPI45_HSI
> + CLK_SPI6_HSI
> + CLK_I2C46_HSI
> + CLK_SDMMC3_PLL4P
> + CLK_USBO_USBPHY
> + CLK_ADC_CKPER
> + CLK_CEC_LSE
> + CLK_I2C12_HSI
> + CLK_I2C35_HSI
> + CLK_UART1_HSI
> + CLK_UART24_HSI
> + CLK_UART35_HSI
> + CLK_UART6_HSI
> + CLK_UART78_HSI
> + CLK_SPDIF_PLL4P
> + CLK_FDCAN_PLL4Q
> + CLK_SAI1_PLL3Q
> + CLK_SAI2_PLL3Q
> + CLK_SAI3_PLL3Q
> + CLK_SAI4_PLL3Q
> + CLK_RNG1_LSI
> + CLK_RNG2_LSI
> + CLK_LPTIM1_PCLK1
> + CLK_LPTIM23_PCLK3
> + CLK_LPTIM45_LSE
> + >;
> +
> + /* VCO = 1300.0 MHz => P = 650 (CPU) */
> + pll1: st,pll@0 {
> + cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> + frac = < 0x800 >;
> + u-boot,dm-pre-reloc;
> + };
> +
> + /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> + pll2: st,pll@1 {
> + cfg = < 2 65 1 0 0 PQR(1,1,1) 

Re: [U-Boot] [PATCH 2/3] board: stm32mp1: Add Avenger96 board support

2019-05-02 Thread Manivannan Sadhasivam
On Thu, May 02, 2019 at 08:41:29AM +, Patrice CHOTARD wrote:
> Hi Manivannan
> 
> On 4/29/19 2:03 PM, Manivannan Sadhasivam wrote:
> > Add support for Avenger96 board from Arrow Electronics based on STM32MP157
> > MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
> > family and has the following features:
> > 
> > SoC: STM32MP157AAC
> > PMIC: STPMIC1A
> > RAM: 1024 Mbyte @ 533MHz
> > Storage: eMMC v4.51: 8 Gbyte
> >  microSD Socket: UHS-1 v3.01
> > Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
> > Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
> >   Bluetooth®v4.2 (BR/EDR/BLE)
> > USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
> > Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
> > LED: 4x User LED, 1x WiFi LED, 1x BT LED
> > 
> > More information about this board can be found in 96Boards website:
> > https://www.96boards.org/product/avenger96/
> > 
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  arch/arm/dts/Makefile |   1 +
> >  .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 177 +
> >  arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
> >  board/st/stm32mp1/README  |  23 ++
> >  4 files changed, 563 insertions(+)
> >  create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index b4dc57edbd1..97a182f3abc 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -711,6 +711,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
> >  
> >  dtb-$(CONFIG_TARGET_STM32MP1) += \
> > stm32mp157a-dk1.dtb \
> > +   stm32mp157a-avenger96.dtb \
> > stm32mp157c-dk2.dtb \
> > stm32mp157c-ed1.dtb \
> > stm32mp157c-ev1.dtb
> > diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi 
> > b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> > new file mode 100644
> > index 000..dd6f0cf8b5f
> > --- /dev/null
> > +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +/*
> > + * Copyright : STMicroelectronics 2018
> > + *
> > + * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> > + * Author: Manivannan Sadhasivam 
> > + */
> > +
> > +#include 
> > +#include "stm32mp157-u-boot.dtsi"
> > +#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> > +
> > +/ {
> > +   aliases {
> > +   mmc0 = &sdmmc1;
> > +   mmc1 = &sdmmc2;
> > +   usb0 = &usbotg_hs;
> > +   };
> > +
> > +   config {
> > +   u-boot,boot-led = "led1";
> > +   u-boot,error-led = "led4";
> > +   };
> > +};
> > +
> > +&i2c4 {
> > +   u-boot,dm-pre-reloc;
> > +};
> > +
> > +&i2c4_pins_a {
> 
> Shouldn't be i2c4_pins_b instead ? This should be the root cause of your
> SPL issue.
> 

Nope. As I mentioned in v2, the culprit was UART and SDMMC. Please review that
one.

Thanks,
Mani

> > +   u-boot,dm-pre-reloc;
> > +   pins {
> > +   u-boot,dm-pre-reloc;
> > +   };
> > +};
> > +
> > +&pmic {
> > +   u-boot,dm-pre-reloc;
> > +};
> > +
> > +&rcc {
> > +   st,clksrc = <
> > +   CLK_MPU_PLL1P
> > +   CLK_AXI_PLL2P
> > +   CLK_MCU_PLL3P
> > +   CLK_PLL12_HSE
> > +   CLK_PLL3_HSE
> > +   CLK_PLL4_HSE
> > +   CLK_RTC_LSE
> > +   CLK_MCO1_DISABLED
> > +   CLK_MCO2_DISABLED
> > +   >;
> > +
> > +   st,clkdiv = <
> > +   1 /*MPU*/
> > +   0 /*AXI*/
> > +   0 /*MCU*/
> > +   1 /*APB1*/
> > +   1 /*APB2*/
> > +   1 /*APB3*/
> > +   1 /*APB4*/
> > +   2 /*APB5*/
> > +   23 /*RTC*/
> > +   0 /*MCO1*/
> > +   0 /*MCO2*/
> > +   >;
> > +
> > +   st,pkcs = <
> > +   CLK_CKPER_HSE
> > +   CLK_FMC_ACLK
> > +   CLK_QSPI_ACLK
> > +   CLK_ETH_DISABLED
> > +   CLK_SDMMC12_PLL4P
> > +   CLK_DSI_DSIPLL
> > +   CLK_STGEN_HSE
> > +   CLK_USBPHY_HSE
> > +   CLK_SPI2S1_PLL3Q
> > +   CLK_SPI2S23_PLL3Q
> > +   CLK_SPI45_HSI
> > +   CLK_SPI6_HSI
> > +   CLK_I2C46_HSI
> > +   CLK_SDMMC3_PLL4P
> > +   CLK_USBO_USBPHY
> > +   CLK_ADC_CKPER
> > +   CLK_CEC_LSE
> > +   CLK_I2C12_HSI
> > +   CLK_I2C35_HSI
> > +   CLK_UART1_HSI
> > +   CLK_UART24_HSI
> > +   CLK_UART35_HSI
> > +   CLK_UART6_HSI
> > +   CLK_UART78_HSI
> > +   CLK_SPDIF_PLL4P
> > +   CLK_FDCAN_PLL4Q
> > +   CLK_SAI1_PLL3Q
> > +   CLK_SAI2_PLL3Q
> > +   CLK_SAI3_PLL3Q
> > +   CLK_SAI4_PLL3Q
> > +   CLK_RNG1_LSI
> > +   CLK_RNG2_LSI
> > +   CLK_LPTIM1_PCLK1
> > +   CLK_LPTIM23_PCLK3
> > +   CLK_LPTIM45_LSE
> > +   >;
> > +
> > +   /* VCO = 1300.0 MHz => P =

Re: [U-Boot] WaRP7 nok on master

2019-05-02 Thread Stefano Babic
Hi Piere, Lukasz,

On 01/05/19 20:49, Pierre-Jean Texier wrote:
> Hi Fabio, Stefano,
> 
> Just FYI, I just tested the U-Boot master branch (with u-boot-imx merges).
> And I have some problems when the WaRP7 boot-up.
> In fact, no output...
> 
> However, on u-boot-imx, everything works well (tags/u-boot-imx-20190426).
> 
> After some manipulation with git bisect, it appears that the problem
> comes from commit [1].
> So, with a git revert 3a7c45f6a7725808e2e82908be4bc90d4d78e737,
> everything works again.
> 
> Without this revert, the WaRP7 is not
> functional (also the pico-pi i.MX7 if DM_SERIAL is implemented, tested
> by Joris in CC)

This is painful - Lukasz, can you comment this ? Your patch is small and
it seems to fix just qemu, it is difficult to understand why it has side
effects on real SOCs like i.MX.

Regards,
Stefano



> 
> 
> 
> Thanks
> 
> BR
> /Pierre-Jean
> 
> [1]
> https://github.com/trini/u-boot/commit/3a7c45f6a7725808e2e82908be4bc90d4d78e737
> 
> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/3] arm: dts: stm32mp157: Add missing pinctrl definitions

2019-05-02 Thread Patrice CHOTARD


On 5/2/19 9:56 AM, Manivannan Sadhasivam wrote:
> Add missing pinctrl definitions for STM32MP157.
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm/dts/stm32mp157-pinctrl.dtsi | 63 
>  1 file changed, 63 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> index 0aae69b0a04..200d2c00c5f 100644
> --- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> @@ -220,6 +220,16 @@
>   };
>   };
>  
> + i2c1_pins_b: i2c1-1 {
> + pins {
> + pinmux = , 
> /* I2C1_SCL */
> +  ; 
> /* I2C1_SDA */
> + bias-disable;
> + drive-open-drain;
> + slew-rate = <0>;
> + };
> + };
> +
>   i2c2_pins_a: i2c2-0 {
>   pins {
>   pinmux = , 
> /* I2C2_SCL */
> @@ -230,6 +240,16 @@
>   };
>   };
>  
> + i2c2_pins_b: i2c2-1 {
> + pins {
> + pinmux = , 
> /* I2C2_SCL */
> +  ; 
> /* I2C2_SDA */
> + bias-disable;
> + drive-open-drain;
> + slew-rate = <0>;
> + };
> + };
> +
>   i2c5_pins_a: i2c5-0 {
>   pins {
>   pinmux = , 
> /* I2C5_SCL */
> @@ -375,6 +395,21 @@
>   };
>   };
>  
> + spi2_pins_a: spi2-0 {
> + pins1 {
> + pinmux = , 
> /* SPI2_SCK */
> +  , 
> /* SPI2_NSS */
> +  ; 
> /* SPI2_MOSI */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <3>;
> + };
> + pins2 {
> + pinmux = ; 
> /* SPI2_MISO */
> + bias-disable;
> + };
> + };
> +
>   stusb1600_pins_a: stusb1600-0 {
>   pins {
>   pinmux =  ANALOG)>;
> @@ -395,6 +430,34 @@
>   };
>   };
>  
> + uart4_pins_b: uart4-1 {
> + pins1 {
> + pinmux = ; 
> /* UART4_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ; 
> /* UART4_RX */
> + bias-disable;
> + };
> + };
> +
> + uart7_pins_a: uart7-0 {
> + pins1 {
> + pinmux = ; 
> /* UART4_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = , 
> /* UART4_RX */
> +  , 
> /* UART4_CTS */
> +  ; 
> /* UART4_RTS */
> + bias-disable;
> + };
> + };
> +
>   usbotg_hs_pins_a: usbotg_hs-0 {
>   pins {
>   pinmux =  ANALOG)>; /* OTG_ID */
> 

Reviewed-by: Patrice Chotard 

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


[U-Boot] [PATCH] board/BuR/brsmarc1: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds support for the B&R brsmarc1 SoM.

The SoM is based on TI's AM335x SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.

Signed-off-by: Hannes Schmelzer 

---

 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/am335x-brsmarc1.dts   | 408 +
 arch/arm/mach-omap2/Kconfig|   1 +
 arch/arm/mach-omap2/am33xx/Kconfig |   3 +
 board/BuR/brsmarc1/Kconfig |  15 ++
 board/BuR/brsmarc1/MAINTAINERS |   6 +
 board/BuR/brsmarc1/Makefile|  13 ++
 board/BuR/brsmarc1/board.c | 168 +++
 board/BuR/brsmarc1/config.mk   |  34 
 board/BuR/brsmarc1/mux.c   | 266 
 configs/brsmarc1_defconfig | 107 ++
 include/configs/brsmarc1.h |  87 
 12 files changed, 1109 insertions(+)
 create mode 100644 arch/arm/dts/am335x-brsmarc1.dts
 create mode 100644 board/BuR/brsmarc1/Kconfig
 create mode 100644 board/BuR/brsmarc1/MAINTAINERS
 create mode 100644 board/BuR/brsmarc1/Makefile
 create mode 100644 board/BuR/brsmarc1/board.c
 create mode 100644 board/BuR/brsmarc1/config.mk
 create mode 100644 board/BuR/brsmarc1/mux.c
 create mode 100644 configs/brsmarc1_defconfig
 create mode 100644 include/configs/brsmarc1.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..8ac057a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -250,6 +250,7 @@ dtb-$(CONFIG_AM33XX) += \
am335x-brppt1-nand.dtb \
am335x-brppt1-spi.dtb \
am335x-brxre1.dtb \
+   am335x-brsmarc1.dtb \
am335x-draco.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/dts/am335x-brsmarc1.dts b/arch/arm/dts/am335x-brsmarc1.dts
new file mode 100644
index 000..e5e2761
--- /dev/null
+++ b/arch/arm/dts/am335x-brsmarc1.dts
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 B&R Industrial Automation GmbH
+ * http://www.br-automation.com
+ *
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+
+/ {
+   model = "BRSMARC1 SoM";
+   compatible = "ti,am33xx";
+
+   fset: factory-settings {
+   bl-version  = "";
+   order-no= "";
+   cpu-order-no= "";
+   hw-revision = "";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   hw-platform = <0x7>;
+   fram-offset = <0x100>;
+   fram-size   = <0x1F00>;
+   cache-disable   = <0x0>;
+   cpu-clock   = <0x0>;
+   };
+
+   chosen {
+   bootargs = "console=ttyO0,115200 earlyprintk";
+   stdout-path = &uart0;
+   };
+
+   aliases {
+   fset = &fset;
+   mmc = &mmc2;
+   spi0 = &spi0;
+   spi1 = &spi1;
+   touch0 = &burtouch0;
+   screen0 = &lcdscreen0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   vmmcsd_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   lcdscreen0: lcdscreen@0 {
+   /*backlight = <&tps_bl>; */
+   compatible = "ti,tilcdc,panel";
+   status = "okay";
+
+   panel-info {
+   ac-bias = <255>;
+   ac-bias-intrpt  = <0>;
+   dma-burst-sz= <16>;
+   bpp = <32>;
+   fdd = <0x80>;
+   sync-edge   = <0>;
+   sync-ctrl   = <1>;
+   raster-order= <0>;
+   fifo-th = <0>;
+   rotation= <0>;
+   pupdelay= <0>;
+   pondelay= <0>;
+   pwrpin  = <0x00B1>;
+   brightdrv   = <0>;
+   brightfdim  = <100>;
+   brightdef   = <50>;
+   };
+
+   display-timings {
+   default {
+   clock-frequency = <0>;
+   hactive = <0>;
+   vactive = <0>;
+   hfront-porch= <0>;
+   hback-porch = <0>;
+   hsync-len   = <0>;
+ 

Re: [U-Boot] [PATCH v2 2/3] board: stm32mp1: Add Avenger96 board support

2019-05-02 Thread Patrice CHOTARD
Hi Manivannan

On 5/2/19 9:56 AM, Manivannan Sadhasivam wrote:
> Add support for Avenger96 board from Arrow Electronics based on STM32MP157
> MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
> family and has the following features:
> 
> SoC: STM32MP157AAC
> PMIC: STPMIC1A
> RAM: 1024 Mbyte @ 533MHz
> Storage: eMMC v4.51: 8 Gbyte
>  microSD Socket: UHS-1 v3.01
> Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
> Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
>   Bluetooth®v4.2 (BR/EDR/BLE)
> USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
> Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
> LED: 4x User LED, 1x WiFi LED, 1x BT LED
> 
> More information about this board can be found in 96Boards website:
> https://www.96boards.org/product/avenger96/
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm/dts/Makefile |   1 +
>  .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 191 +
>  arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
>  board/st/stm32mp1/README  |  23 ++
>  4 files changed, 577 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b4dc57edbd1..97a182f3abc 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -711,6 +711,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  
>  dtb-$(CONFIG_TARGET_STM32MP1) += \
>   stm32mp157a-dk1.dtb \
> + stm32mp157a-avenger96.dtb \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
>   stm32mp157c-ev1.dtb
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> new file mode 100644
> index 000..1ff681afb87
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright : STMicroelectronics 2018
> + *
> + * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> + * Author: Manivannan Sadhasivam 
> + */
> +
> +#include 
> +#include "stm32mp157-u-boot.dtsi"
> +#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = &sdmmc1;
> + mmc1 = &sdmmc2;
> + usb0 = &usbotg_hs;
> + };
> +
> + config {
> + u-boot,boot-led = "led1";
> + u-boot,error-led = "led4";
> + };
> +};
> +
> +&i2c4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&i2c4_pins_a {
> + u-boot,dm-pre-reloc;
> + pins {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&pmic {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&rcc {
> + st,clksrc = <
> + CLK_MPU_PLL1P
> + CLK_AXI_PLL2P
> + CLK_MCU_PLL3P
> + CLK_PLL12_HSE
> + CLK_PLL3_HSE
> + CLK_PLL4_HSE
> + CLK_RTC_LSE
> + CLK_MCO1_DISABLED
> + CLK_MCO2_DISABLED
> + >;
> +
> + st,clkdiv = <
> + 1 /*MPU*/
> + 0 /*AXI*/
> + 0 /*MCU*/
> + 1 /*APB1*/
> + 1 /*APB2*/
> + 1 /*APB3*/
> + 1 /*APB4*/
> + 2 /*APB5*/
> + 23 /*RTC*/
> + 0 /*MCO1*/
> + 0 /*MCO2*/
> + >;
> +
> + st,pkcs = <
> + CLK_CKPER_HSE
> + CLK_FMC_ACLK
> + CLK_QSPI_ACLK
> + CLK_ETH_DISABLED
> + CLK_SDMMC12_PLL4P
> + CLK_DSI_DSIPLL
> + CLK_STGEN_HSE
> + CLK_USBPHY_HSE
> + CLK_SPI2S1_PLL3Q
> + CLK_SPI2S23_PLL3Q
> + CLK_SPI45_HSI
> + CLK_SPI6_HSI
> + CLK_I2C46_HSI
> + CLK_SDMMC3_PLL4P
> + CLK_USBO_USBPHY
> + CLK_ADC_CKPER
> + CLK_CEC_LSE
> + CLK_I2C12_HSI
> + CLK_I2C35_HSI
> + CLK_UART1_HSI
> + CLK_UART24_HSI
> + CLK_UART35_HSI
> + CLK_UART6_HSI
> + CLK_UART78_HSI
> + CLK_SPDIF_PLL4P
> + CLK_FDCAN_PLL4Q
> + CLK_SAI1_PLL3Q
> + CLK_SAI2_PLL3Q
> + CLK_SAI3_PLL3Q
> + CLK_SAI4_PLL3Q
> + CLK_RNG1_LSI
> + CLK_RNG2_LSI
> + CLK_LPTIM1_PCLK1
> + CLK_LPTIM23_PCLK3
> + CLK_LPTIM45_LSE
> + >;
> +
> + /* VCO = 1300.0 MHz => P = 650 (CPU) */
> + pll1: st,pll@0 {
> + cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> + frac = < 0x800 >;
> + u-boot,dm-pre-reloc;
> + };
> +
> + /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> + pll2: st,pll@1 {
> + cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> + frac = < 0x1400 >;
> + u-boot,dm-pre-reloc;
> + };
>

Re: [U-Boot] [PATCH v2 3/3] arm: mach-stm32mp: Add newline to the MAC error message

2019-05-02 Thread Patrice CHOTARD


On 5/2/19 9:56 AM, Manivannan Sadhasivam wrote:
> Without newline, the error message appears for non prgrammed OTP boards
> looks messsy. Hence add it to look more clean.
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm/mach-stm32mp/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 7b4431c9c75..e1a0a136809 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -481,7 +481,7 @@ static int setup_mac_address(void)
>   enetaddr[i] = ((uint8_t *)&otp)[i];
>  
>   if (!is_valid_ethaddr(enetaddr)) {
> - pr_err("invalid MAC address in OTP %pM", enetaddr);
> + pr_err("invalid MAC address in OTP %pM\n", enetaddr);
>   return -EINVAL;
>   }
>   pr_debug("OTP MAC address = %pM\n", enetaddr);
> 


Reviewed-by: Patrice Chotard 

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


Re: [U-Boot] [PATCH v2 10/19] spi: mpc8xxx: Simplify logic a bit

2019-05-02 Thread Joakim Tjernlund
On Thu, 2019-05-02 at 07:31 +0200, Mario Six wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi Jagan and Jocke,
> 
> I'm back from vacation, so here's my answer:
> 
> On Mon, Apr 29, 2019 at 12:41 PM Jagan Teki  
> wrote:
> > + Mario
> > 
> > On Mon, Apr 29, 2019 at 2:48 PM Joakim Tjernlund
> >  wrote:
> > > On Mon, 2019-04-29 at 01:58 +0530, Jagan Teki wrote:
> > > > From: Mario Six 
> > > > 
> > > > We do nothing in the loop if the "not empty" event was not detected. To
> > > > simplify the logic, check if this is the case, and skip the execution of
> > > > the loop early to reduce the nesting level and flag checking.
> > > 
> > > Looked at the driver to refresh memory and noticed:
> > > if (charSize == 32) {
> > > /* Advance output buffer by 32 bits */
> > > din += 4;
> > > }
> > > which suggests that only 32 bit char will increase the din ptr so does 
> > > other bitlens
> > > work for reading?
> Yes, It will work. When charSize < 32 in a loop execution, we necessarily also
> have numBlks == 0, since numBlks = DIV_ROUND_UP(bitlen, 32) and charSize =
> (bitlen >= 32 ? 32 : bitlen); in other words: we're at the very end of the 
> data
> to be sent/received and also the final loop execution, so we don't have to
> advance the pointer anymore.

Ahh, I see now.

But this over use of always 32 bits cause complexity/subtile bugs. The driver 
should use
the requested charsize(wordlen) throughout. As is now you cannot use the NF/NE 
flag as intended or
toggle LSB_FIRST
I think fsl_espi driver is worse though.

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


Re: [U-Boot] [PATCH 1/3] Add fit-dtb.blob* to .gitignore to also exclude compressed blobs.

2019-05-02 Thread Marek Vasut
On 5/2/19 2:42 AM, Vagrant Cascadian wrote:
> Signed-off-by: Vagrant Cascadian 
> ---

Commit message is missing on this and 2/3 patch , otherwise the series
looks good, thanks.

>  .gitignore | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.gitignore b/.gitignore
> index c2afcfbca2..d8b7b77844 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -35,7 +35,7 @@
>  #
>  # Top-level generic files
>  #
> -fit-dtb.blob
> +fit-dtb.blob*
>  /MLO*
>  /SPL*
>  /System.map
> 


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


Re: [U-Boot] [PATCH v2 45/50] Revert "pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS"

2019-05-02 Thread Thierry Reding
On Thu, May 02, 2019 at 12:09:49AM +0800, Bin Meng wrote:
> +Thierry
> 
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d.
> >
> > Unfortunately this has a dramatic impact on the pre-relocation memory
> > used on x86 platforms (increasing it by 2KB) since it increases the
> > overhead for each PCI device from 220 bytes to 412 bytes.
> >
> > The offending line is in UCLASS_DRIVER(pci):
> >
> > .per_device_auto_alloc_size = sizeof(struct pci_controller),
> >
> > This means that all PCI devices have the controller struct associated
> > with them. The solution is to move the regions[] member out of the array,
> > makes its size dynamic, or split UCLASS_PCI into controllers and
> > non-controllers, as the comment suggests.
> >
> > For now, revert the commit to get things running again.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2: None
> >
> >  include/pci.h | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> 
> Reviewed-by: Bin Meng 

Ugh... so we're trading one regression for another? Can we not live with
the 2 KiB increase on x86 until this has been properly fixed? Currently
this will cause Jetson TX2 to crash if it starts using PCI.

Thierry


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


Re: [U-Boot] [PATCH u-boot-marvell v2.1 15/15] i2c: mvtwsi: fix reading status register after interrupt

2019-05-02 Thread Marek Behun
> This still looks a bit strange. Looking at the Linux driver, there
> is no delay after reading the control register. But its using
> interrupts and therefore an implicit delay is added before this
> interrupt service routine is called (instead of the busy loop here
> in the U-Boot driver).

Exactly my opinion as well.

> BTW: Whats the value of "tick" in twsi_wait() in your case?

requested I2C freq is 10 Hz, actual 97656 Hz (nearest lower
possible). This calculates the tick to 10340 ns with calc_tick, and
u-boot sleeps for 11 ms (DIV_ROUND_UP).

When tick was 10 ms this bug did not occur, because of the different
timing when the control value was read it already was set for a while
by the controller, it seems.

Btw should I sent these first 14 patches with Reviewed-by tags?

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


Re: [U-Boot] [PATCH u-boot-marvell v2 14/15] arm: mvebu: turris_omnia: add RESET button handling

2019-05-02 Thread Marek Behun
On Thu, 2 May 2019 08:10:36 +0200
Stefan Roese  wrote:

> I fail to see a real reason to introduce these Kconfig options. Is
> TURRIS_OMNIA_RSTBTN_OVERWRITE_BOOTCMD enabled for your board? If not
> it just adds dead code, as no other board will ever enable it. So do
> you plan to add 2 Omnia build targets, one with and one w/o this
> option enabled? Or what is your plan here?
> 
> Thanks,
> Stefan

My idea was that the users should be able to disable this functionality,
if they are compiling u-boot themselves, but we are going to ship
Omnias with this config enabled.

I can of course remove the Kconfig options and enable this reset button
handling all times.

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


Re: [U-Boot] [PATCH u-boot-marvell v2.1 15/15] i2c: mvtwsi: fix reading status register after interrupt

2019-05-02 Thread Stefan Roese

On 02.05.19 11:36, Marek Behun wrote:

This still looks a bit strange. Looking at the Linux driver, there
is no delay after reading the control register. But its using
interrupts and therefore an implicit delay is added before this
interrupt service routine is called (instead of the busy loop here
in the U-Boot driver).


Exactly my opinion as well.


BTW: Whats the value of "tick" in twsi_wait() in your case?


requested I2C freq is 10 Hz, actual 97656 Hz (nearest lower
possible). This calculates the tick to 10340 ns with calc_tick, and
u-boot sleeps for 11 ms (DIV_ROUND_UP).

When tick was 10 ms this bug did not occur, because of the different
timing when the control value was read it already was set for a while
by the controller, it seems.

Btw should I sent these first 14 patches with Reviewed-by tags?


No need for that, thanks. Patchwork will pick up the tags automatically.

Next time, please switch to v3 instead of v2.1 though.

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


Re: [U-Boot] [PATCH u-boot-marvell v2 14/15] arm: mvebu: turris_omnia: add RESET button handling

2019-05-02 Thread Stefan Roese

On 02.05.19 11:39, Marek Behun wrote:

On Thu, 2 May 2019 08:10:36 +0200
Stefan Roese  wrote:


I fail to see a real reason to introduce these Kconfig options. Is
TURRIS_OMNIA_RSTBTN_OVERWRITE_BOOTCMD enabled for your board? If not
it just adds dead code, as no other board will ever enable it. So do
you plan to add 2 Omnia build targets, one with and one w/o this
option enabled? Or what is your plan here?

Thanks,
Stefan


My idea was that the users should be able to disable this functionality,
if they are compiling u-boot themselves, but we are going to ship
Omnias with this config enabled.


Understood, thanks.
 

I can of course remove the Kconfig options and enable this reset button
handling all times.


Please do so. If someone whats to disable this functionality or change
the reset button bootcmd, then he/she/it must do some changes (defconfig
or code).

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


Re: [U-Boot] Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board

2019-05-02 Thread Marcel Ziswiler
Hi Peng

On Thu, 2019-05-02 at 03:57 +, Peng Fan wrote:
> Hi Marcel,
> 
> > Subject: Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
> > 
> > Hi Peng, Stefano and Fabio
> > 
> > We are currently trying to boot the Linux kernel from NXP's
> > downstream Linux
> > BSP 4.14.98_2.0.0_ga with mainline U-Boot. However, that currently
> > seems
> > to crash as follows:
> > 
> > ...
> > 
> > Does any of you know what exactly could be going on?
> 
> SMMU is not powered up, so smmu driver probe triggers abort when
> accessing
> SMMU registers. Need power up SC_R_SMMU.

I see, this is actually done in downstream U-Boot:

https://source.codeaurora.org/external/imx/uboot-imx/commit/?h=imx_v2018.03_4.14.98_2.0.0_ga&id=45308e7da90f342c2de7fbec1f8c5b8bd3f1b8e5

Wondering how that is supposed to work with mainline U-Boot at the end.

> > BTW: The exact same crash is observed on Apalis iMX8 as well, while
> > both the
> > i.MX8QXP MEK as well as Colibri iMX8QXP boot that same downstream
> > Linux
> > kernel just fine. Must be something i.MX 8QuadMax specific...
> 
> There is no SMMU on i.MX8QXP.

Funny, at least in downstream U-Boot the same SMMU setup is done (;-p).

> Regards,
> Peng.

Thanks, Peng!

> > Cheers
> > 
> > Marcel

Cheers

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


Re: [U-Boot] [PATCH v2] ARM: am335x: Add phyCORE AM335x R2 support

2019-05-02 Thread Niel Fourie

Hi All,

Thank you Marek for the feedback. I addressed all of your concerns, the 
most important of is mentioned below:


On 4/25/19 12:52 PM, Marek Vasut wrote:

The Linux commit from which the DTs came is missing.


Added


Keep the list sorted alphabetically please. (PHY... is below PCM...)



Fixed. Sorry, that was as howler.


Just curious , was there ever AM335x_R1 ? Why do we use the _R2 suffix
here ?> 


The AM335x (without the R2) was the Phytec pcm051. So I stuck with 
adding R2 to distinguish the two. (I don't have a pcm051, so I did not 
want to mess with it.)



+#ifndef CONFIG_DM_I2C


CONFIG_IS_ENABLED(DM_I2C)



This one is causing some headaches. I can't find any references to 
CONFIG_SPL_DM_I2C, even though we actually use DM for I2C in the SPL, so 
that change causes things to break a bit. As an improvement, I changed 
the code to use #if defined(CONFIG_DM_I2C) instead of #ifndef. We could 
always simply drop the Non-DM support instead, I guess?


On 4/25/19 12:43 PM, Marek Vasut wrote:> Take a look at
> configs/am335x_evm_defconfig:CONFIG_DM_USB_GADGET=y
>
> Maybe we can at least get rid of some of the hard-coded USB non-DM
> stuff.

I simply removed the hard-coded USB stuff, as the DM_USB was already 
enabled and working anyways. DM_USB_GADGET was also enabled. Thanks for 
the recommendation.


Best regards,
Niel Fourie

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-21 Fax: +49-8142-66989-80  Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3] ARM: am335x: Add phyCORE AM335x R2 support

2019-05-02 Thread Niel Fourie
Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
phyBOARD-Wega AM335x.

CPU  : AM335X-GP rev 2.1
Model: Phytec AM335x phyBOARD-WEGA
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
eth0: ethernet@4a10

Working:
 - Eth0
 - i2C
 - MMC/SD
 - NAND
 - UART
 - USB (host)

Device trees were taken from Linux mainline revision
37624b58542fb9f2d9a70e6ea006ef8a5f66c30b

Signed-off-by: Niel Fourie 
---
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/am335x-phycore-som.dtsi   | 322 +
 arch/arm/dts/am335x-wega-rdk-u-boot.dtsi   |  40 +++
 arch/arm/dts/am335x-wega-rdk.dts   |  23 ++
 arch/arm/dts/am335x-wega.dtsi  | 230 +++
 arch/arm/mach-omap2/Kconfig|   1 +
 arch/arm/mach-omap2/am33xx/Kconfig |   7 +
 board/phytec/phycore_am335x_r2/Kconfig |  15 +
 board/phytec/phycore_am335x_r2/MAINTAINERS |   7 +
 board/phytec/phycore_am335x_r2/Makefile|  11 +
 board/phytec/phycore_am335x_r2/board.c | 263 +
 board/phytec/phycore_am335x_r2/board.h |  24 ++
 board/phytec/phycore_am335x_r2/mux.c   | 117 
 configs/phycore-am335x-r2-wega_defconfig   |  79 +
 include/configs/phycore_am335x_r2.h| 130 +
 15 files changed, 1271 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/am335x-phycore-som.dtsi
 create mode 100644 arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
 create mode 100644 arch/arm/dts/am335x-wega-rdk.dts
 create mode 100644 arch/arm/dts/am335x-wega.dtsi
 create mode 100644 board/phytec/phycore_am335x_r2/Kconfig
 create mode 100644 board/phytec/phycore_am335x_r2/MAINTAINERS
 create mode 100644 board/phytec/phycore_am335x_r2/Makefile
 create mode 100644 board/phytec/phycore_am335x_r2/board.c
 create mode 100644 board/phytec/phycore_am335x_r2/board.h
 create mode 100644 board/phytec/phycore_am335x_r2/mux.c
 create mode 100644 configs/phycore-am335x-r2-wega_defconfig
 create mode 100644 include/configs/phycore_am335x_r2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b4dc57edbd..611be64314 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -262,7 +262,8 @@ dtb-$(CONFIG_AM33XX) += \
am335x-chiliboard.dtb \
am335x-sl50.dtb \
am335x-base0033.dtb \
-   am335x-guardian.dtb
+   am335x-guardian.dtb \
+   am335x-wega-rdk.dtb
 dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb \
diff --git a/arch/arm/dts/am335x-phycore-som.dtsi 
b/arch/arm/dts/am335x-phycore-som.dtsi
new file mode 100644
index 00..8d7c19e5e1
--- /dev/null
+++ b/arch/arm/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am33xx.dtsi"
+#include 
+
+/ {
+   model = "Phytec AM335x phyCORE";
+   compatible = "phytec,am335x-phycore-som", "ti,am33xx";
+
+   aliases {
+   rtc0 = &i2c_rtc;
+   rtc1 = &rtc;
+   };
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = <&vdd1_reg>;
+   };
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   vcc5v: fixedregulator0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+};
+
+/* Crypto Module */
+&aes {
+   status = "okay";
+};
+
+&sham {
+   status = "okay";
+};
+
+/* Ethernet */
+&am33xx_pinmux {
+   ethernet0_pins: pinmux_ethernet0 {
+   pinctrl-single,pins = <
+   AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1) 
/* mii1_crs.rmii1_crs_dv */
+   AM33XX_IOPAD(0x910, PIN_INPUT_PULLDOWN | MUX_MODE1) 
/* mii1_rxerr.rmii1_rxerr */
+   AM33XX_IOPAD(0x914, PIN_OUTPUT | MUX_MODE1) 
/* mii1_txen.rmii1_txen */
+   AM33XX_IOPAD(0x924, PIN_OUTPUT | MUX_MODE1) 
/* mii1_txd1.rmii1_txd1 */
+   AM33XX_IOPAD(0x928, PIN_OUTPUT | MUX_MODE1) 
/* mii1_txd0.rmii1_txd0 */
+   AM33XX_IOPAD(0x93c, PIN_INPUT_PULLDOWN | MUX_MODE1) 
/* mii1_rxd1.rmii1_rxd1 */
+   AM33XX_IOPAD(0x940, PIN_INPUT_PULLDOWN | MUX_MODE1) 
/* mii1_rxd0.rmii1_rxd0 */
+   

Re: [U-Boot] Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board

2019-05-02 Thread Peng Fan


> -Original Message-
> From: Marcel Ziswiler [mailto:marcel.ziswi...@toradex.com]
> Sent: 2019年5月2日 17:47
> To: Peng Fan ; Fabio Estevam
> ; sba...@denx.de
> Cc: u-boot@lists.denx.de; dl-uboot-imx 
> Subject: Re: Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
> 
> Hi Peng
> 
> On Thu, 2019-05-02 at 03:57 +, Peng Fan wrote:
> > Hi Marcel,
> >
> > > Subject: Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
> > >
> > > Hi Peng, Stefano and Fabio
> > >
> > > We are currently trying to boot the Linux kernel from NXP's
> > > downstream Linux BSP 4.14.98_2.0.0_ga with mainline U-Boot. However,
> > > that currently seems to crash as follows:
> > >
> > > ...
> > >
> > > Does any of you know what exactly could be going on?
> >
> > SMMU is not powered up, so smmu driver probe triggers abort when
> > accessing SMMU registers. Need power up SC_R_SMMU.
> 
> I see, this is actually done in downstream U-Boot:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
> .codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Fcommit%2F%3Fh%3Di
> mx_v2018.03_4.14.98_2.0.0_ga%26id%3D45308e7da90f342c2de7fbec1f8c5
> b8bd3f1b8e5&data=02%7C01%7Cpeng.fan%40nxp.com%7C4ba5e68e20
> 6341af29df08d6cee328ab%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C636923872368096043&sdata=tj%2B9CGkzJhsidj8HvniZ7%2B%2
> FFK%2BbbE4GrP%2FJ5aeu5NiE%3D&reserved=0
> 
> Wondering how that is supposed to work with mainline U-Boot at the end.

I think just power up SMMU is fine in mainline U-Boot.

> 
> > > BTW: The exact same crash is observed on Apalis iMX8 as well, while
> > > both the i.MX8QXP MEK as well as Colibri iMX8QXP boot that same
> > > downstream Linux kernel just fine. Must be something i.MX 8QuadMax
> > > specific...
> >
> > There is no SMMU on i.MX8QXP.
> 
> Funny, at least in downstream U-Boot the same SMMU setup is done (;-p).

CONFIG_IMX_SMMU is not defined for i.MX8QXP.

Regards,
Peng.

> 
> > Regards,
> > Peng.
> 
> Thanks, Peng!
> 
> > > Cheers
> > >
> > > Marcel
> 
> Cheers
> 
> Marcel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/3] arm: k3: Update build support

2019-05-02 Thread Lokesh Vutla
This series updates the build support for k3 devices to use rsa degenerate
key. This significantly improves the boot time. While at it update the
timeout for initializing system controller which cover a valid boot scenario.

Lokesh Vutla (3):
  tools: k3_get_x509 cert: Add a script to generate x509 certificate for
K3 devices
  arm: k3: config.mk: Use k3_gen_x509_cert.sh to generate boot images
  remoteproc: k3_system_controller: Increase rx timeout

 arch/arm/mach-k3/config.mk|  33 +--
 drivers/remoteproc/k3_system_controller.c |   2 +-
 tools/k3_gen_x509_cert.sh | 244 ++
 tools/k3_x509template.txt |  48 -
 4 files changed, 249 insertions(+), 78 deletions(-)
 create mode 100755 tools/k3_gen_x509_cert.sh
 delete mode 100644 tools/k3_x509template.txt

-- 
2.21.0

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


[U-Boot] [PATCH 1/3] tools: k3_get_x509 cert: Add a script to generate x509 certificate for K3 devices

2019-05-02 Thread Lokesh Vutla
TI's K3 boot architecture mandates a x509 certificate for every boot image.
While signing the image K3 ROM allows for two types of keys based on which
the boot image gets loaded in different ways:
- Degenerate RSA keys: This generates a signature which is equal to the digest.
   When ROM sees this, it does a DMA for copying the images,
   which significantly improves the boot time.
- Any other key: Does a memcpy to load the image. This is introduced as a
 fallback for DMA copy.

Add a script for generating boot images with the above options. Default
generates image using rsa degenerate key in order to improve boot time.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Dave Gerlach 
Signed-off-by: Andreas Dannenberg 
---
 tools/k3_gen_x509_cert.sh | 244 ++
 1 file changed, 244 insertions(+)
 create mode 100755 tools/k3_gen_x509_cert.sh

diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh
new file mode 100755
index 00..b6d055f6f5
--- /dev/null
+++ b/tools/k3_gen_x509_cert.sh
@@ -0,0 +1,244 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+#
+# Script to add K3 specific x509 cetificate to a binary.
+#
+
+# Variables
+OUTPUT=tiboot3.bin
+TEMP_X509=x509-temp.cert
+CERT=certificate.bin
+RAND_KEY=eckey.pem
+LOADADDR=0x41c0
+BOOTCORE_OPTS=0
+BOOTCORE=16
+
+gen_degen_template() {
+cat << 'EOF' > degen-template.txt
+
+asn1=SEQUENCE:rsa_key
+
+[rsa_key]
+version=INTEGER:0
+modulus=INTEGER:0xDEGEN_MODULUS
+pubExp=INTEGER:1
+privExp=INTEGER:1
+p=INTEGER:0xDEGEN_P
+q=INTEGER:0xDEGEN_Q
+e1=INTEGER:1
+e2=INTEGER:1
+coeff=INTEGER:0xDEGEN_COEFF
+EOF
+}
+
+# Generate x509 Template
+gen_template() {
+cat << 'EOF' > x509-template.txt
+ [ req ]
+ distinguished_name = req_distinguished_name
+ x509_extensions= v3_ca
+ prompt = no
+ dirstring_type = nobmp
+
+ [ req_distinguished_name ]
+ C  = US
+ ST = TX
+ L  = Dallas
+ O  = Texas Instruments Incorporated
+ OU = Processors
+ CN = TI support
+ emailAddress   = supp...@ti.com
+
+ [ v3_ca ]
+ basicConstraints = CA:true
+ 1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq
+ 1.3.6.1.4.1.294.1.2 = ASN1:SEQUENCE:image_integrity
+ 1.3.6.1.4.1.294.1.3 = ASN1:SEQUENCE:swrv
+# 1.3.6.1.4.1.294.1.4 = ASN1:SEQUENCE:encryption
+ 1.3.6.1.4.1.294.1.8 = ASN1:SEQUENCE:debug
+
+ [ boot_seq ]
+ certType = INTEGER:TEST_CERT_TYPE
+ bootCore = INTEGER:TEST_BOOT_CORE
+ bootCoreOpts = INTEGER:TEST_BOOT_CORE_OPTS
+ destAddr = FORMAT:HEX,OCT:TEST_BOOT_ADDR
+ imageSize = INTEGER:TEST_IMAGE_LENGTH
+
+ [ image_integrity ]
+ shaType = OID:2.16.840.1.101.3.4.2.3
+ shaValue = FORMAT:HEX,OCT:TEST_IMAGE_SHA_VAL
+
+ [ swrv ]
+ swrv = INTEGER:0
+
+# [ encryption ]
+# initalVector = FORMAT:HEX,OCT:TEST_IMAGE_ENC_IV
+# randomString = FORMAT:HEX,OCT:TEST_IMAGE_ENC_RS
+# iterationCnt = INTEGER:TEST_IMAGE_KEY_DERIVE_INDEX
+# salt = FORMAT:HEX,OCT:TEST_IMAGE_KEY_DERIVE_SALT
+
+ [ debug ]
+ debugUID = 
FORMAT:HEX,OCT:
+ debugType = INTEGER:4
+ coreDbgEn = INTEGER:0
+ coreDbgSecEn = INTEGER:0
+EOF
+}
+
+parse_key() {
+   sed '/\ \ \ \ /s/://g' key.txt | awk  '!/\ \ \ \ / {printf("\n%s\n", 
$0)}; /\ \ \ \ / {printf("%s", $0)}' | sed 's/\ \ \ \ //g' | awk 
"/$1:/{getline; print}"
+}
+
+gen_degen_key() {
+# Generate a 4096 bit RSA Key
+   openssl genrsa -out key.pem 1024 >>/dev/null 2>&1
+   openssl rsa -in key.pem -text -out key.txt >>/dev/null 2>&1
+   DEGEN_MODULUS=$( parse_key 'modulus' )
+   DEGEN_P=$( parse_key 'prime1' )
+   DEGEN_Q=$( parse_key 'prime2' )
+   DEGEN_COEFF=$( parse_key 'coefficient' )
+   gen_degen_template
+
+   sed -e "s/DEGEN_MODULUS/$DEGEN_MODULUS/"\
+   -e "s/DEGEN_P/$DEGEN_P/" \
+   -e "s/DEGEN_Q/$DEGEN_Q/" \
+   -e "s/DEGEN_COEFF/$DEGEN_COEFF/" \
+degen-template.txt > degenerateKey.txt
+
+   openssl asn1parse -genconf degenerateKey.txt -out degenerateKey.der 
>>/dev/null 2>&1
+   openssl rsa -in degenerateKey.der -inform DER -outform PEM -out 
$RAND_KEY >>/dev/null 2>&1
+   KEY=$RAND_KEY
+   rm key.pem key.txt degen-template.txt degenerateKey.txt 
degenerateKey.der
+}
+
+declare -A options_help
+usage() {
+   if [ -n "$*" ]; then
+   echo "ERROR: $*"
+   fi
+   echo -n "Usage: $0 "
+   for option in "${!options_help[@]}"
+   do
+   arg=`echo ${options_help[$option]}|cut -d ':' -f1`
+   if [ -n "$arg" ]; then
+   arg=" $arg"
+   fi
+   echo -n "[-$option$arg] "
+   done
+   echo
+   echo -e "\nWhere:"
+   for option in "${!options_help[@]}"
+   do
+   arg=`echo ${options_help[$option]}|cut -d ':' -f1`
+   

[U-Boot] [PATCH 2/3] arm: k3: config.mk: Use k3_gen_x509_cert.sh to generate boot images

2019-05-02 Thread Lokesh Vutla
Instead of overlading makefile, use the k3_gen_x509_cert.sh script
to generate boot images.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/config.mk | 33 --
 tools/k3_x509template.txt  | 48 --
 2 files changed, 4 insertions(+), 77 deletions(-)
 delete mode 100644 tools/k3_x509template.txt

diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index 2d8f61f9db..f6b63db349 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -11,31 +11,11 @@ ifeq ($(shell which openssl),)
 $(error "No openssl in $(PATH), consider installing openssl")
 endif
 
-SHA_VALUE=  $(shell openssl dgst -sha512 -hex $(obj)/u-boot-spl.bin | sed -e 
"s/^.*= //g")
 IMAGE_SIZE= $(shell cat $(obj)/u-boot-spl.bin | wc -c)
-LOADADDR= $(shell echo $(CONFIG_SPL_TEXT_BASE) | sed -e "s/^0x//g")
 MAX_SIZE= $(shell printf "%d" $(CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE))
 
-# Parameters to get populated into the x509 template
-SED_OPTS=  -e s/TEST_IMAGE_LENGTH/$(IMAGE_SIZE)/
-SED_OPTS+= -e s/TEST_IMAGE_SHA_VAL/$(SHA_VALUE)/
-SED_OPTS+= -e s/TEST_CERT_TYPE/1/  # CERT_TYPE_PRIMARY_IMAGE_BIN
-SED_OPTS+= -e s/TEST_BOOT_CORE/$(CONFIG_SYS_K3_BOOT_CORE_ID)/
-SED_OPTS+= -e s/TEST_BOOT_ARCH_WIDTH/32/
-SED_OPTS+= -e s/TEST_BOOT_ADDR/$(LOADADDR)/
-
-# Command to generate ecparam key
-quiet_cmd_genkey = OPENSSL $@
-cmd_genkey = openssl ecparam -out $@ -name prime256v1 -genkey
-
-# Command to generate x509 certificate
-quiet_cmd_gencert = OPENSSL $@
-cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | sed $(SED_OPTS) > 
u-boot-spl-x509.txt; \
-   openssl req -new -x509 -key $(KEY) -nodes -outform DER -out $@ -config 
u-boot-spl-x509.txt -sha512
-
-# If external key is not provided, generate key using openssl.
 ifeq ($(CONFIG_SYS_K3_KEY), "")
-KEY=u-boot-spl-eckey.pem
+KEY=""
 # On HS use real key or warn if not available
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
@@ -48,15 +28,9 @@ else
 KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
 endif
 
-u-boot-spl-eckey.pem: FORCE
-   $(call if_changed,genkey)
-
 # tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
 # So restrict tiboot3.bin creation for CPU_V7R.
 ifdef CONFIG_CPU_V7R
-u-boot-spl-cert.bin: $(KEY) $(obj)/u-boot-spl.bin image_check FORCE
-   $(call if_changed,gencert)
-
 image_check: $(obj)/u-boot-spl.bin FORCE
@if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \
echo "===" >&2; \
@@ -66,8 +40,9 @@ image_check: $(obj)/u-boot-spl.bin FORCE
exit 1; \
fi
 
-tiboot3.bin: u-boot-spl-cert.bin $(obj)/u-boot-spl.bin FORCE
-   $(call if_changed,cat)
+tiboot3.bin: image_check FORCE
+   $(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \
+   -o $@ -l $(CONFIG_SPL_TEXT_BASE) -k $(KEY)
 
 ALL-y  += tiboot3.bin
 endif
diff --git a/tools/k3_x509template.txt b/tools/k3_x509template.txt
deleted file mode 100644
index f176ff3ad2..00
--- a/tools/k3_x509template.txt
+++ /dev/null
@@ -1,48 +0,0 @@
- [ req ]
- distinguished_name = req_distinguished_name
- x509_extensions= v3_ca
- prompt = no
- dirstring_type = nobmp
-
- [ req_distinguished_name ]
- C  = US
- ST = TX
- L  = Dallas
- O  = Texas Instruments Incorporated
- OU = Processors
- CN = TI Support
- emailAddress   = supp...@ti.com
-
- [ v3_ca ]
- basicConstraints = CA:true
- 1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq
- 1.3.6.1.4.1.294.1.2 = ASN1:SEQUENCE:image_integrity
- 1.3.6.1.4.1.294.1.3 = ASN1:SEQUENCE:swrv
-# 1.3.6.1.4.1.294.1.4 = ASN1:SEQUENCE:encryption
- 1.3.6.1.4.1.294.1.8 = ASN1:SEQUENCE:debug
-
- [ boot_seq ]
- certType = INTEGER:TEST_CERT_TYPE
- bootCore = INTEGER:TEST_BOOT_CORE
- bootCoreOpts = INTEGER:TEST_BOOT_ARCH_WIDTH
- destAddr = FORMAT:HEX,OCT:TEST_BOOT_ADDR
- imageSize = INTEGER:TEST_IMAGE_LENGTH
-
- [ image_integrity ]
- shaType = OID:2.16.840.1.101.3.4.2.3
- shaValue = FORMAT:HEX,OCT:TEST_IMAGE_SHA_VAL
-
- [ swrv ]
- swrv = INTEGER:0
-
-# [ encryption ]
-# initalVector = FORMAT:HEX,OCT:TEST_IMAGE_ENC_IV
-# randomString = FORMAT:HEX,OCT:TEST_IMAGE_ENC_RS
-# iterationCnt = INTEGER:TEST_IMAGE_KEY_DERIVE_INDEX
-# salt = FORMAT:HEX,OCT:TEST_IMAGE_KEY_DERIVE_SALT
-
- [ debug ]
- debugUID = 
FORMAT:HEX,OCT:
- debugType = INTEGER:4
- coreDbgEn = INTEGER:0
- coreDbgSecEn = INTEGER:0
-- 
2.21.0

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


[U-Boot] [PATCH 3/3] remoteproc: k3_system_controller: Increase rx timeout

2019-05-02 Thread Lokesh Vutla
There is one case where 400ms is not sufficient for loading the
system firmware:
- System firmware is not signed with rsa degenerate key.
- ROM loading the sysfw directly from SPI flash which is in memory
  mapped mode.

The above scenario is definitely not desired in production use cases
as it effects boot time. But still keeping this support as this is
a valid boot scenario.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/k3_system_controller.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/k3_system_controller.c 
b/drivers/remoteproc/k3_system_controller.c
index 214ea18d8a..44e56c759f 100644
--- a/drivers/remoteproc/k3_system_controller.c
+++ b/drivers/remoteproc/k3_system_controller.c
@@ -301,7 +301,7 @@ static int k3_sysctrler_probe(struct udevice *dev)
 
 static const struct k3_sysctrler_desc k3_sysctrler_am654_desc = {
.host_id = 4,   /* HOST_ID_R5_1 */
-   .max_rx_timeout_us = 40,
+   .max_rx_timeout_us = 80,
.max_msg_size = 60,
 };
 
-- 
2.21.0

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


Re: [U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot

2019-05-02 Thread Marek Vasut
On 5/2/19 9:57 AM, Faiz Abbas wrote:
> Hi,

Hi,

> On 14/02/19 6:56 PM, Marek Vasut wrote:
>> Older kernel versions or systems which do not connect eMMC reset line
>> properly may not be able to handle situations where either the eMMC
>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader
>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card
>> to non-UHS mode before booting the kernel to allow such older kernels
>> to work with modern U-Boot.
> 
> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go
> through and all following commands timeout.
> 
> Log:
> 
> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200)
> 
> CPU  : DRA752-GP ES2.0
> Model: TI DRA742
> Board: DRA74x EVM REV H.0
> DRAM:  4 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
> 
> Loading Environment from MMC... OK
> Net:   eth0: ethernet@48484000
> Hit any key to stop autoboot:  0
> =>
> => boot
> Booting from network ...
> link up on port 0, speed 1000, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.1.52 (246 ms)
> link up on port 0, speed 1000, full duplex
> Using ethernet@48484000 device
> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
> Filename 'zImage'.
> Load address: 0x8700
> Loading: #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  3.3 MiB/s
> done
> Bytes transferred = 3556144 (364330 hex)
> link up on port 0, speed 1000, full duplex
> Using ethernet@48484000 device
> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
> Filename 'dra7-evm.dtb'.
> Load address: 0x8800
> Loading: ##
>  2.9 MiB/s
> done
> Bytes transferred = 108307 (1a713 hex)
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Device Tree to 8ffe2000, end 8712 ... OK
> Using machid 0xfe6 from environment
> 
> Starting kernel ...
> 
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear

This seems to be a kernel bug ?

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


Re: [U-Boot] [PATCH v2] arm: socfpga: Move Stratix 10 SDRAM driver to DM

2019-05-02 Thread Marek Vasut
On 5/2/19 5:46 AM, Ley Foon Tan wrote:
> On Tue, Apr 30, 2019 at 5:56 PM Marek Vasut  wrote:
>>
>> On 4/30/19 9:40 AM, Ley Foon Tan wrote:
>> [...]
>>> +static int altera_sdram_probe(struct udevice *dev)
>>> +{
>>> + int ret;
>>> + struct reset_ctl_bulk resets;
>>> +
>>> + ret = reset_get_bulk(dev, &resets);
>>> + if (ret) {
>>> + dev_err(dev, "Can't get reset: %d\n", ret);
>>> + return -ENODEV;
>>> + }
>>> + reset_deassert_bulk(&resets);
>>> +
>>> + if (sdram_mmr_init_full(dev) != 0) {
>>> + puts("SDRAM init failed.\n");
>>> + goto failed;
>>> + }
>>> +
>>> + return 0;
>>> +
>>> +failed:
>>> + reset_release_bulk(&resets);
>>> + return -ENODEV;
>>>  }
>> Are you missing altera_sdram_remove() , which would assert reset here ?
> Will add it.

 But won't that prevent the DRAM controller from working ?
>>> Added assert reset in _remove, SDRAM controller still can work after
>>> boot to Uboot.
>>> Seem _remove is not called when boot to Uboot.
>>
>> Look at DM_FLAG_OS_PREPARE
> Tested add DM_FLAG_OS_PREPARE flag, but still didn't see it call to _remove().
> 
> BTW, I think we shouldn't assert SDRAM controller. Otherwise, SDRAM is
> not working in next boot stage.

Hence my question above -- "But won't that prevent the DRAM controller
from working ?"

I think you're right.

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


Re: [U-Boot] WaRP7 nok on master

2019-05-02 Thread Auer, Lukas
Hi Stefano,

On Thu, 2019-05-02 at 10:55 +0200, Stefano Babic wrote:
> Hi Piere, Lukasz,
> 
> On 01/05/19 20:49, Pierre-Jean Texier wrote:
> > Hi Fabio, Stefano,
> > 
> > Just FYI, I just tested the U-Boot master branch (with u-boot-imx merges).
> > And I have some problems when the WaRP7 boot-up.
> > In fact, no output...
> > 
> > However, on u-boot-imx, everything works well (tags/u-boot-imx-20190426).
> > 
> > After some manipulation with git bisect, it appears that the problem
> > comes from commit [1].
> > So, with a git revert 3a7c45f6a7725808e2e82908be4bc90d4d78e737,
> > everything works again.
> > 
> > Without this revert, the WaRP7 is not
> > functional (also the pico-pi i.MX7 if DM_SERIAL is implemented, tested
> > by Joris in CC)
> 
> This is painful - Lukasz, can you comment this ? Your patch is small and
> it seems to fix just qemu, it is difficult to understand why it has side
> effects on real SOCs like i.MX.
> 

I was able to reproduce the issue on my side. With the patch, U-Boot
probes the drivers for devices under simple-bus device tree nodes in
the pre-relocation device model. The default value of
CONFIG_SYS_MALLOC_LEN (0x400) leaves U-Boot with not enough memory to
do this, causing it to hang. If it is increased, for example to 0x1000,
everything works again.

Let me know, how you want to fix this. If you want, I can send a patch
to increase CONFIG_SYS_MALLOC_LEN for the i.MX parts.

Thanks,
Lukas

> > 
> > [1]
> > https://github.com/trini/u-boot/commit/3a7c45f6a7725808e2e82908be4bc90d4d78e737
> > 

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


Re: [U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot

2019-05-02 Thread Faiz Abbas
Hi Marek,

On 02/05/19 3:39 PM, Marek Vasut wrote:
> On 5/2/19 9:57 AM, Faiz Abbas wrote:
>> Hi,
> 
> Hi,
> 
>> On 14/02/19 6:56 PM, Marek Vasut wrote:
>>> Older kernel versions or systems which do not connect eMMC reset line
>>> properly may not be able to handle situations where either the eMMC
>>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader
>>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card
>>> to non-UHS mode before booting the kernel to allow such older kernels
>>> to work with modern U-Boot.
>>
>> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go
>> through and all following commands timeout.
>>
>> Log:
>>
>> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200)
>>
>> CPU  : DRA752-GP ES2.0
>> Model: TI DRA742
>> Board: DRA74x EVM REV H.0
>> DRAM:  4 GiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> Loading Environment from FAT... *** Warning - bad CRC, using default
>> environment
>>
>> Loading Environment from MMC... OK
>> Net:   eth0: ethernet@48484000
>> Hit any key to stop autoboot:  0
>> =>
>> => boot
>> Booting from network ...
>> link up on port 0, speed 1000, full duplex
>> BOOTP broadcast 1
>> DHCP client bound to address 192.168.1.52 (246 ms)
>> link up on port 0, speed 1000, full duplex
>> Using ethernet@48484000 device
>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
>> Filename 'zImage'.
>> Load address: 0x8700
>> Loading: #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  #
>>  3.3 MiB/s
>> done
>> Bytes transferred = 3556144 (364330 hex)
>> link up on port 0, speed 1000, full duplex
>> Using ethernet@48484000 device
>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
>> Filename 'dra7-evm.dtb'.
>> Load address: 0x8800
>> Loading: ##
>>  2.9 MiB/s
>> done
>> Bytes transferred = 108307 (1a713 hex)
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Device Tree to 8ffe2000, end 8712 ... OK
>> Using machid 0xfe6 from environment
>>
>> Starting kernel ...
>>
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> 
> This seems to be a kernel bug ?

Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is
coming from drivers/mmc/omap_hsmmc.c:1066

Here's the Log with MMC_TRACE
enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/

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


Re: [U-Boot] WaRP7 nok on master

2019-05-02 Thread Pierre-Jean Texier

Hi Lucas,

Le 02/05/2019 à 12:21, Auer, Lukas a écrit :

Hi Stefano,

On Thu, 2019-05-02 at 10:55 +0200, Stefano Babic wrote:

Hi Piere, Lukasz,

On 01/05/19 20:49, Pierre-Jean Texier wrote:

Hi Fabio, Stefano,

Just FYI, I just tested the U-Boot master branch (with u-boot-imx merges).
And I have some problems when the WaRP7 boot-up.
In fact, no output...

However, on u-boot-imx, everything works well (tags/u-boot-imx-20190426).

After some manipulation with git bisect, it appears that the problem
comes from commit [1].
So, with a git revert 3a7c45f6a7725808e2e82908be4bc90d4d78e737,
everything works again.

Without this revert, the WaRP7 is not
functional (also the pico-pi i.MX7 if DM_SERIAL is implemented, tested
by Joris in CC)

This is painful - Lukasz, can you comment this ? Your patch is small and
it seems to fix just qemu, it is difficult to understand why it has side
effects on real SOCs like i.MX.


I was able to reproduce the issue on my side. With the patch, U-Boot
probes the drivers for devices under simple-bus device tree nodes in
the pre-relocation device model. The default value of
CONFIG_SYS_MALLOC_LEN (0x400) leaves U-Boot with not enough memory to
do this, causing it to hang. If it is increased, for example to 0x1000,
everything works again.

Let me know, how you want to fix this. If you want, I can send a patch
to increase CONFIG_SYS_MALLOC_LEN for the i.MX parts.



Indeed, everything works again with 0x1000 for CONFIG_SYS_MALLOC_LEN.

Thanks


Pierre-Jean




Thanks,
Lukas


[1]
https://github.com/trini/u-boot/commit/3a7c45f6a7725808e2e82908be4bc90d4d78e737


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


Re: [U-Boot] [BUG] test_avb_persistent_values() fails

2019-05-02 Thread Igor Opaniuk
On Tue, Apr 30, 2019, 23:14 Heinrich Schuchardt  wrote:

> Hello Igor,
>
> when I run `make tests` with current origin/master
> commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7
> I get an error. I think your submitted this test recently:
> commit fc1fe01b08ce ("avb: add support for named persistent values")
>
> u_boot_console =  0x7ff056222cd0>
>
>  @pytest.mark.buildconfigspec('cmd_avb')
>  @pytest.mark.buildconfigspec('optee_ta_avb')
>  def test_avb_persistent_values(u_boot_console):
>  """Test reading/writing persistent storage to avb
>  """
>
>  response = u_boot_console.run_command('avb init %s' %
> str(mmc_dev))
>  assert response == ''
>
>  response = u_boot_console.run_command('avb write_pvalue test
> value_value')
>  assert response == 'Wrote 12 bytes'
>
>  response = u_boot_console.run_command('avb read_pvalue test 12')
>  >   assert response == 'Read 12 bytes, value = value_value'
> E   AssertionError: assert 'Read 12 byte...alue_value/XU' == 'Read
> 12 bytes...= value_value'
> E - Read 12 bytes, value = value_value/XU
> E ?   ---
> E + Read 12 bytes, value = value_value
>
> test/py/tests/test_avb.py:134: AssertionError
>
> Best regards
>
> Heinrich
>

Hi Heinrich,

Thanks for reporting this. Interesting, that when I sent v5 everything was
ok (where I addressed an issue reported by Tom, actually I played a lot
with `make tests` and all tests were passing successfully) and the only
thing I did in v6 - adding R-b tag(v5 was posted ~3 month ago, so I assume
something probably was changed in py/tests).

Unfortunately I am AFK till Sunday, will look into this ASAP(Monday
morning).

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


Re: [U-Boot] Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board

2019-05-02 Thread Marcel Ziswiler
Hi Peng

On Thu, 2019-05-02 at 10:06 +, Peng Fan wrote:
> > -Original Message-
> > From: Marcel Ziswiler [mailto:marcel.ziswi...@toradex.com]
> > Sent: 2019年5月2日 17:47
> > To: Peng Fan ; Fabio Estevam
> > ; sba...@denx.de
> > Cc: u-boot@lists.denx.de; dl-uboot-imx 
> > Subject: Re: Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
> > 
> > Hi Peng
> > 
> > On Thu, 2019-05-02 at 03:57 +, Peng Fan wrote:
> > > Hi Marcel,
> > > 
> > > > Subject: Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
> > > > 
> > > > Hi Peng, Stefano and Fabio
> > > > 
> > > > We are currently trying to boot the Linux kernel from NXP's
> > > > downstream Linux BSP 4.14.98_2.0.0_ga with mainline U-Boot.
> > > > However,
> > > > that currently seems to crash as follows:
> > > > 
> > > > ...
> > > > 
> > > > Does any of you know what exactly could be going on?
> > > 
> > > SMMU is not powered up, so smmu driver probe triggers abort when
> > > accessing SMMU registers. Need power up SC_R_SMMU.
> > 
> > I see, this is actually done in downstream U-Boot:
> > 
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
> > .codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Fcommit%2F%3Fh%3Di
> > mx_v2018.03_4.14.98_2.0.0_ga%26id%3D45308e7da90f342c2de7fbec1f8c5
> > b8bd3f1b8e5&data=02%7C01%7Cpeng.fan%40nxp.com%7C4ba5e68e20
> > 6341af29df08d6cee328ab%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C636923872368096043&sdata=tj%2B9CGkzJhsidj8HvniZ7%2B%2
> > FFK%2BbbE4GrP%2FJ5aeu5NiE%3D&reserved=0
> > 
> > Wondering how that is supposed to work with mainline U-Boot at the
> > end.

Any comment/suggestion?

> I think just power up SMMU is fine in mainline U-Boot.
> 
> > > > BTW: The exact same crash is observed on Apalis iMX8 as well,
> > > > while
> > > > both the i.MX8QXP MEK as well as Colibri iMX8QXP boot that same
> > > > downstream Linux kernel just fine. Must be something i.MX
> > > > 8QuadMax
> > > > specific...
> > > 
> > > There is no SMMU on i.MX8QXP.
> > 
> > Funny, at least in downstream U-Boot the same SMMU setup is done
> > (;-p).
> 
> CONFIG_IMX_SMMU is not defined for i.MX8QXP.

I am wondering why exactly you would come to such a conclusion. At
least the following configuration header file still seems to define it:

https://source.codeaurora.org/external/imx/uboot-imx/tree/include/configs/imx8qxp_mek.h?h=imx_v2018.03_4.14.98_2.0.0_ga#n370

> Regards,
> Peng.
> 
> > > Regards,
> > > Peng.
> > 
> > Thanks, Peng!
> > 
> > > > Cheers
> > > > 
> > > > Marcel
> > 
> > Cheers
> > 
> > Marcel

Cheers

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


Re: [U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot

2019-05-02 Thread Marek Vasut
On 5/2/19 12:24 PM, Faiz Abbas wrote:
> Hi Marek,
> 
> On 02/05/19 3:39 PM, Marek Vasut wrote:
>> On 5/2/19 9:57 AM, Faiz Abbas wrote:
>>> Hi,
>>
>> Hi,
>>
>>> On 14/02/19 6:56 PM, Marek Vasut wrote:
 Older kernel versions or systems which do not connect eMMC reset line
 properly may not be able to handle situations where either the eMMC
 is left in HS200/HS400 mode or SD card in UHS modes by the bootloader
 and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card
 to non-UHS mode before booting the kernel to allow such older kernels
 to work with modern U-Boot.
>>>
>>> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go
>>> through and all following commands timeout.
>>>
>>> Log:
>>>
>>> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200)
>>>
>>> CPU  : DRA752-GP ES2.0
>>> Model: TI DRA742
>>> Board: DRA74x EVM REV H.0
>>> DRAM:  4 GiB
>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>> Loading Environment from FAT... *** Warning - bad CRC, using default
>>> environment
>>>
>>> Loading Environment from MMC... OK
>>> Net:   eth0: ethernet@48484000
>>> Hit any key to stop autoboot:  0
>>> =>
>>> => boot
>>> Booting from network ...
>>> link up on port 0, speed 1000, full duplex
>>> BOOTP broadcast 1
>>> DHCP client bound to address 192.168.1.52 (246 ms)
>>> link up on port 0, speed 1000, full duplex
>>> Using ethernet@48484000 device
>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
>>> Filename 'zImage'.
>>> Load address: 0x8700
>>> Loading: #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  #
>>>  3.3 MiB/s
>>> done
>>> Bytes transferred = 3556144 (364330 hex)
>>> link up on port 0, speed 1000, full duplex
>>> Using ethernet@48484000 device
>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52
>>> Filename 'dra7-evm.dtb'.
>>> Load address: 0x8800
>>> Loading: ##
>>>  2.9 MiB/s
>>> done
>>> Bytes transferred = 108307 (1a713 hex)
>>> ## Flattened Device Tree blob at 8800
>>>Booting using the fdt blob at 0x8800
>>>Loading Device Tree to 8ffe2000, end 8712 ... OK
>>> Using machid 0xfe6 from environment
>>>
>>> Starting kernel ...
>>>
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
>>
>> This seems to be a kernel bug ?
> 
> Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is
> coming from drivers/mmc/omap_hsmmc.c:1066
> 
> Here's the Log with MMC_TRACE
> enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/

Oh, could it be the clock were disabled at this point already ?
Or something along those lines. I don't have any omap board to test it
on, can you debug it ?

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


[U-Boot] [PATCH] board/BuR/brppt2: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds support for the brppt2 board. The board is based on the
i.mx6 dual-lite SoC.

Signed-off-by: Hannes Schmelzer 

---

 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/imx6dl-brppt2.dts | 278 +
 arch/arm/mach-imx/mx6/Kconfig  |  19 ++
 board/BuR/brppt2/Kconfig   |  18 ++
 board/BuR/brppt2/MAINTAINERS   |   6 +
 board/BuR/brppt2/Makefile  |  10 +
 board/BuR/brppt2/board.c   | 542 +
 board/BuR/brppt2/config.mk |  37 +++
 configs/brppt2_defconfig   |  92 +++
 include/configs/brppt2.h   | 125 ++
 10 files changed, 1129 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6dl-brppt2.dts
 create mode 100644 board/BuR/brppt2/Kconfig
 create mode 100644 board/BuR/brppt2/MAINTAINERS
 create mode 100644 board/BuR/brppt2/Makefile
 create mode 100644 board/BuR/brppt2/board.c
 create mode 100644 board/BuR/brppt2/config.mk
 create mode 100644 configs/brppt2_defconfig
 create mode 100644 include/configs/brppt2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..288c3e8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -529,7 +529,8 @@ dtb-$(CONFIG_MX6QDL) += \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
imx6qp-sabreauto.dtb \
-   imx6qp-sabresd.dtb
+   imx6qp-sabresd.dtb \
+   imx6dl-brppt2.dtb
 
 dtb-$(CONFIG_TARGET_WANDBOARD) += \
imx6dl-wandboard-revb1.dtb
diff --git a/arch/arm/dts/imx6dl-brppt2.dts b/arch/arm/dts/imx6dl-brppt2.dts
new file mode 100644
index 000..4f1c52b
--- /dev/null
+++ b/arch/arm/dts/imx6dl-brppt2.dts
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 B&R Industrial Automation GmbH
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-u-boot.dtsi"
+#include 
+#include 
+
+/ {
+   model = "PPT50";
+   compatible = "fsl,imx6dl";
+
+   config {
+   u-boot,spl-payload-offset = <0x10>;
+   };
+
+   fset: factory-settings {
+   bl-version  = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   order-no= "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   hw-revision = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   };
+
+   aliases {
+   ds1timing0 = &timing0;
+   ds1timing1 = &timing1;
+   ds1bkl = &backlight;
+   fset = &fset;
+   mxcfb0 = &mxcfb0;
+   touch0 = &touch0;
+   touch1 = &touch1;
+   touch2 = &touch2;
+   display_regulator = &display_regulator;
+   ldb = &ldb;
+   mmc0 = &usdhc4;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   mxcfb0: fb@0 {
+   compatible = "fsl,mxc_sdc_fb";
+   disp_dev = "ldb";
+   interface_pix_fmt = "RGB24";
+   default_bpp = <32>;
+   int_clk = <0>;
+   late_init = <0>;
+   rotation = <0>;
+   status = "okay";
+   };
+
+   lcd@0 {
+   compatible = "fsl,lcd";
+   vlcd-supply = <&display_regulator>;
+   ipu_id = <0>;
+   disp_id = <0>;
+   default_ifmt = "RGB24";
+   status = "disabled";
+
+   display-timings {
+   native-mode = <&timing1>;
+   timing1: lcd {
+   };
+   };
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm4 0 500>;
+   brightness-levels = <0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100>;
+   default-brightness-level = <0>;
+   st

[U-Boot] u boot boot error

2019-05-02 Thread froglike6
I was updating the router, but it took a long time to turn off and it became
a brick. I connected it by serial communication, and the following log only
stopped. What should I do? Actual ram and nand is 128mb.

U-Boot 1.1.4 (Mar 1 2015 - 22:07:55)

ap135 - Scorpion 1.0
DRAM: 4 MB



--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] riscv:Add Microchip MPFS Icicle board support

2019-05-02 Thread Padmarao Begari
This patch adds Microchip MPFS Icicle board support.
For now, NS16550 serial driver is only enabled.
The Microchip MPFS Icicle defconfig by default builds
U-Boot for M-Mode with SMP support.

Signed-off-by: Padmarao Begari 

Changes in v2
- Fix some typos
- Rename target board to TARGET_MICROCHIP_ICICLE
- select CONFIG_BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS
- Remove #ifdef CONFIG_BOARD_EARLY_INIT_F
---
 arch/riscv/Kconfig|  4 ++
 board/microchip/mpfs_icicle/Kconfig   | 21 +++
 board/microchip/mpfs_icicle/MAINTAINERS   |  7 
 board/microchip/mpfs_icicle/Makefile  |  7 
 board/microchip/mpfs_icicle/mpfs_icicle.c | 30 +++
 configs/microchip_mpfs_icicle_defconfig   | 15 
 include/configs/microchip_mpfs_icicle.h   | 63 +++
 7 files changed, 147 insertions(+)
 create mode 100644 board/microchip/mpfs_icicle/Kconfig
 create mode 100644 board/microchip/mpfs_icicle/MAINTAINERS
 create mode 100644 board/microchip/mpfs_icicle/Makefile
 create mode 100644 board/microchip/mpfs_icicle/mpfs_icicle.c
 create mode 100644 configs/microchip_mpfs_icicle_defconfig
 create mode 100644 include/configs/microchip_mpfs_icicle.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ae8ff7b..d83b260 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -11,6 +11,9 @@ choice
 config TARGET_AX25_AE350
bool "Support ax25-ae350"
 
+config TARGET_MICROCHIP_ICICLE
+   bool "Support Microchip PolarFire-SoC Icicle Board"
+
 config TARGET_QEMU_VIRT
bool "Support QEMU Virt Board"
 
@@ -22,6 +25,7 @@ endchoice
 # board-specific options below
 source "board/AndesTech/ax25-ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
+source "board/microchip/mpfs_icicle/Kconfig"
 source "board/sifive/fu540/Kconfig"
 
 # platform-specific options below
diff --git a/board/microchip/mpfs_icicle/Kconfig 
b/board/microchip/mpfs_icicle/Kconfig
new file mode 100644
index 000..9cfa83c
--- /dev/null
+++ b/board/microchip/mpfs_icicle/Kconfig
@@ -0,0 +1,21 @@
+if TARGET_MICROCHIP_ICICLE
+
+config SYS_BOARD
+   default "mpfs_icicle"
+
+config SYS_VENDOR
+   default "microchip"
+
+config SYS_CPU
+   default "generic"
+
+config SYS_CONFIG_NAME
+   default "microchip_mpfs_icicle"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+   select GENERIC_RISCV
+   imply SMP
+   imply BOARD_EARLY_INIT_F
+
+endif
diff --git a/board/microchip/mpfs_icicle/MAINTAINERS 
b/board/microchip/mpfs_icicle/MAINTAINERS
new file mode 100644
index 000..9987efe
--- /dev/null
+++ b/board/microchip/mpfs_icicle/MAINTAINERS
@@ -0,0 +1,7 @@
+Microchip MPFS icicle
+M: Padmarao Begari 
+M: Cyril Jean 
+S: Maintained
+F: board/microchip/mpfs-icicle/
+F: include/configs/microchip-mpfs-icicle.h
+F: configs/microchip-mpfs-icicle_defconfig
diff --git a/board/microchip/mpfs_icicle/Makefile 
b/board/microchip/mpfs_icicle/Makefile
new file mode 100644
index 000..72b0410
--- /dev/null
+++ b/board/microchip/mpfs_icicle/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2019 Microchip Technology Inc.
+# Padmarao Begari 
+#
+
+obj-y  += mpfs_icicle.o
diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c 
b/board/microchip/mpfs_icicle/mpfs_icicle.c
new file mode 100644
index 000..0ef2431
--- /dev/null
+++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Microchip Technology Inc.
+ * Padmarao Begari 
+ */
+
+#include 
+#include 
+#include 
+
+#define MPFS_SYSREG_SOFT_RESET ((unsigned int *)0x20002088)
+
+int board_init(void)
+{
+   /* For now nothing to do here. */
+
+   return 0;
+}
+
+int board_early_init_f(void)
+{
+   unsigned int val;
+
+   /* Reset uart peripheral */
+   val = readl(MPFS_SYSREG_SOFT_RESET);
+   val = (val & ~(1u << 5u));
+   writel(val, MPFS_SYSREG_SOFT_RESET);
+
+   return 0;
+}
diff --git a/configs/microchip_mpfs_icicle_defconfig 
b/configs/microchip_mpfs_icicle_defconfig
new file mode 100644
index 000..7073196
--- /dev/null
+++ b/configs/microchip_mpfs_icicle_defconfig
@@ -0,0 +1,15 @@
+CONFIG_RISCV=y
+CONFIG_SYS_TEXT_BASE=0x8000
+CONFIG_ARCH_RV64I=y
+CONFIG_NR_CPUS=5
+CONFIG_TARGET_MICROCHIP_ICICLE=y
+CONFIG_BOOTDELAY=3
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_FIT=y
+CONFIG_DM=y
+CONFIG_BAUDRATE=57600
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_OF_PRIOR_STAGE=y
diff --git a/include/configs/microchip_mpfs_icicle.h 
b/include/configs/microchip_mpfs_icicle.h
new file mode 100644
index 000..82c7fbb
--- /dev/null
+++ b/include/configs/microchip_mpfs_icicle.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Microchip Technology Inc.
+ * Padmarao Begari 
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * CPU and Board Configuration Opti

[U-Boot] U-Boot bootefi MVPP2 Bug

2019-05-02 Thread Sven Auhagen
Hi everyone,

I discovered a problem when using upstream U-Boot with Kernel 5.0 and MVPP2 
when booting with the bootefi command on the Macchiatobin.
The Macchiatobin runs ARM64 based Armada 8040.

How to reproduce this:


  1.  Compile and flush upstream U-Boot:
UBOOT_VERSION=v2019.04
BINARIES_VERSION=binaries-marvell-armada-18.12
ATF_VERSION=atf-v1.5-armada-18.12
MV_DDR_VERSION=mv_ddr-armada-18.12


  1.  Compile Upstream Kernel 5.0 with MVPP2 builtin.

  2.  Boot Kernel with boot efi from UBoot (either builtin the efi stub or 
install grub2)
  3.  Enable the eth2 network interface: ip link set dev eth2 up
  4.  Connect a USB Stick with files ~1GB to the mcbin and mount it: mount 
/dev/sda1 /mnt
  5.  Copy files to eMMC
  6.  Error message is:


[  225.587186] BUG: Bad page state in process cp  pfn:7fc40
[  225.592541] page:7e0001ff1000 count:-1 mapcount:0 
mapping: index:0x1
[  225.592548] flags: 0x000()
[  225.592557] raw: 0000 dead0100 dead0200 

[  225.592563] raw: 0001   

[  225.592567] page dumped because: nonzero _count
[  225.592570] Modules linked in: overlay sd_mod sg uas usb_storage bonding 
xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo 
cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_ondemand 
cfg80211 rfkill 8021q garp mrp nls_ascii nls_cp437 vfat fat aes_ce_blk 
crypto_simd cryptd ofpart aes_ce_cipher m25p80 ghash_ce gf128mul spi_nor mtd 
sha2_ce sha256_arm64 sha1_ce spi_orion efi_pstore efivars armada_thermal 
br_netfilter bridge stp llc efivarfs autofs4 ext4 crc16 mbcache jbd2 fscrypto 
aes_arm64 ahci_platform libahci_platform libahci xhci_plat_hcd xhci_hcd libata 
phy_generic fixed scsi_mod i2c_mux_pca954x i2c_mux usbcore usb_common
[  225.592658] CPU: 0 PID: 1383 Comm: cp Not tainted 5.0.0-3-vtair-arm64 #1 
Debian 5.0.9-2~vtair
[  225.592662] Hardware name: Marvell mvebu_armada-8k/mvebu_armada-8k, BIOS 
2019.04 05/02/2019
[  225.592665] Call trace:
[  225.592676]  dump_backtrace+0x0/0x1a0
[  225.592681]  show_stack+0x24/0x30
[  225.592690]  dump_stack+0x8c/0xac
[  225.592696]  bad_page+0xec/0x148
[  225.592700]  check_new_page_bad+0x80/0xb8
[  225.592706]  get_page_from_freelist+0x9e8/0x1710
[  225.592710]  __alloc_pages_nodemask+0x158/0xe40
[  225.592717]  alloc_pages_current+0x88/0xf0
[  225.592723]  __page_cache_alloc+0xac/0xc0
[  225.592730]  __do_page_cache_readahead+0xe4/0x1f8
[  225.592735]  ondemand_readahead+0x164/0x2f0
[  225.592741]  page_cache_async_readahead+0xd4/0xd8
[  225.592746]  generic_file_read_iter+0x590/0x808
[  225.592752]  new_sync_read+0xf8/0x178
[  225.592758]  __vfs_read+0x74/0x90
[  225.592763]  vfs_read+0x94/0x150
[  225.592768]  ksys_read+0x6c/0xd8
[  225.592773]  __arm64_sys_read+0x24/0x30
[  225.592780]  el0_svc_common+0xd0/0x130
[  225.592786]  el0_svc_handler+0x38/0x78
[  225.592791]  el0_svc+0x8/0xc
[  225.592795] Disabling lock debugging due to kernel taint

The copy is actually just a way of triggering the problem.
It will happen eventually with another process.
When all mvpp2 interfaces are down, the error is not happening.
When booting the kernel via booti the error also does not happen.
I added an intel NIC on the PCIe slot and tested it with that and the error 
does not happen with the Intel NIC up.

Best
Sven


Beste Grüße/Best regards

Sven Auhagen
Dipl. Math. oec., M.Sc.

Voleatech GmbH
HRB: B 754643
USTID: DE303643180
Grathwohlstr. 5
72762 Reutlingen
Tel: +49 7121539550
Fax: +49 7121539551
E-Mail: sven.auha...@voleatech.de

www.voleatech.de
Diese Information ist ausschließlich für den Adressaten bestimmt und kann 
vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht 
der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es 
untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren 
Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die 
Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung 
darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle 
Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns 
zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung 
aus.

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


[U-Boot] [PATCH] board/BuR/zynq/brsmarc2: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds the first of a few more Xilinx ZYNQ based SoM boards.

The SoM is based on Xilinx Zynq 7000 SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.

Signed-off-by: Hannes Schmelzer 

---

 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/zynq-brsmarc2.dts  |  15 +
 arch/arm/dts/zynq-brsmarc2.dtsi | 278 ++
 arch/arm/dts/zynq-brsmarc2_r512.dts |  16 +
 board/BuR/zynq/.gitignore   |   1 +
 board/BuR/zynq/MAINTAINERS  |   6 +
 board/BuR/zynq/Makefile |  16 +
 board/BuR/zynq/brsmarc2/board.c |  84 +++
 board/BuR/zynq/brsmarc2/ps7_init_gpl.c  | 814 
 board/BuR/zynq/brsmarc2_r512/board.c|   2 +
 board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c | 813 +++
 board/BuR/zynq/config.mk|  50 ++
 board/BuR/zynq/take_vivadoHandoff.sh|  36 ++
 board/BuR/zynq/uncrustify.cfg   |  91 
 configs/brsmarc2_defconfig  |  72 +++
 configs/brsmarc2_r512_defconfig |  72 +++
 include/configs/brsmarc2.h  | 166 ++
 17 files changed, 2534 insertions(+)
 create mode 100644 arch/arm/dts/zynq-brsmarc2.dts
 create mode 100644 arch/arm/dts/zynq-brsmarc2.dtsi
 create mode 100644 arch/arm/dts/zynq-brsmarc2_r512.dts
 create mode 100644 board/BuR/zynq/.gitignore
 create mode 100644 board/BuR/zynq/MAINTAINERS
 create mode 100644 board/BuR/zynq/Makefile
 create mode 100644 board/BuR/zynq/brsmarc2/board.c
 create mode 100644 board/BuR/zynq/brsmarc2/ps7_init_gpl.c
 create mode 100644 board/BuR/zynq/brsmarc2_r512/board.c
 create mode 100644 board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c
 create mode 100644 board/BuR/zynq/config.mk
 create mode 100755 board/BuR/zynq/take_vivadoHandoff.sh
 create mode 100644 board/BuR/zynq/uncrustify.cfg
 create mode 100644 configs/brsmarc2_defconfig
 create mode 100644 configs/brsmarc2_r512_defconfig
 create mode 100644 include/configs/brsmarc2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..2b00129 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011-x16.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
+   zynq-brsmarc2.dtb \
+   zynq-brsmarc2_r512.dtb \
zynq-zed.dtb \
zynq-zturn.dtb \
zynq-zybo.dtb \
diff --git a/arch/arm/dts/zynq-brsmarc2.dts b/arch/arm/dts/zynq-brsmarc2.dts
new file mode 100644
index 000..5ad5113
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * B&R BRSMARC2 board base DTS file
+ *
+ *  Copyright (C) 2018 B&R Industrial Automation GmbH
+ *
+ */
+/dts-v1/;
+#include "zynq-brsmarc2.dtsi"
+/ {
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+};
diff --git a/arch/arm/dts/zynq-brsmarc2.dtsi b/arch/arm/dts/zynq-brsmarc2.dtsi
new file mode 100644
index 000..d1aeffd
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2.dtsi
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * B&R BRSMARC2 board base DTS file
+ *
+ *  Copyright (C) 2017 B&R Industrial Automation GmbH
+ *  Copyright (C) 2011 - 2015 Xilinx
+ *  Copyright (C) 2012 National Instruments Corp.
+ */
+
+/include/ "zynq-7000.dtsi"
+#include 
+#include 
+
+/ {
+   model = "BRSMARC2 Zynq SoM";
+   compatible = "xlnx,zynq-7000";
+
+   fset: factory-settings {
+   bl-version  = "";
+   order-no= "";
+   cpu-order-no= "";
+   hw-revision = "";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   hw-platform = <0x0>;
+   fram-offset = <0x0>;
+   fram-size   = <0x0>;
+   cache-disable   = <0x0>;
+   cpu-clock   = <0x0>;
+   };
+
+   aliases {
+   ethernet0 = &gem0;
+   ethernet1 = &gem1;
+   i2c0 = &i2c0;
+   serial0 = &uart0;
+   spi0 = &qspi;
+   mmc0 = &sdhci0;
+   fset = &fset;
+   can0 = &can0;
+   can1 = &can1;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   board {
+   status = "okay";
+   compatible = "bur,brsmarc2-som";
+   usb0mux-gpios = <&gpio0 68 GPIO_ACTIVE_HIGH>;
+   usb1mux-gpios = <&gpio0 69 GPIO_ACTIVE_HIGH>;
+   powerdown-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+   rese

Re: [U-Boot] [PATCH u-boot-marvell v2 14/15] arm: mvebu: turris_omnia: add RESET button handling

2019-05-02 Thread Marek Behún
On Thu, 2 May 2019 11:43:12 +0200
Stefan Roese  wrote:

> Please do so. If someone whats to disable this functionality or change
> the reset button bootcmd, then he/she/it must do some changes
> (defconfig or code).

So should I remove the options from Kconfig or enable them by default?

BTW: We are going to ship omnia with several other options enabled?
Should I push them also to defconfig?

They are:

CONFIG_FIT=y
CONFIG_FIT_ENABLE_SHA256_SUPPORT=y
CONFIG_FIT_VERBOSE=y
CONFIG_CMD_LZMADEC=y
CONFIG_CMD_AES=y
CONFIG_CMD_HASH=y
CONFIG_CMD_SHA1SUM=y

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


Re: [U-Boot] [PATCH] board/BuR/brsmarc1: initial commit

2019-05-02 Thread Tom Rini
On Thu, May 02, 2019 at 11:01:48AM +0200, Hannes Schmelzer wrote:

> This commit adds support for the B&R brsmarc1 SoM.
> 
> The SoM is based on TI's AM335x SoC.
> Mainly vxWorks 6.9.4.x is running on the board,
> doing some PLC stuff on various carrier boards.
> 
> Signed-off-by: Hannes Schmelzer 
> 
> ---
> 
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/am335x-brsmarc1.dts   | 408 
> +
>  arch/arm/mach-omap2/Kconfig|   1 +
>  arch/arm/mach-omap2/am33xx/Kconfig |   3 +
>  board/BuR/brsmarc1/Kconfig |  15 ++
>  board/BuR/brsmarc1/MAINTAINERS |   6 +
>  board/BuR/brsmarc1/Makefile|  13 ++
>  board/BuR/brsmarc1/board.c | 168 +++
>  board/BuR/brsmarc1/config.mk   |  34 
>  board/BuR/brsmarc1/mux.c   | 266 
>  configs/brsmarc1_defconfig | 107 ++
>  include/configs/brsmarc1.h |  87 
>  12 files changed, 1109 insertions(+)

A few small things.  Makefile / config.mk need the SDPX tag as the top
line.  Next:

> diff --git a/arch/arm/mach-omap2/am33xx/Kconfig 
> b/arch/arm/mach-omap2/am33xx/Kconfig
> index 500df1a..3ec154e 100644
> --- a/arch/arm/mach-omap2/am33xx/Kconfig
> +++ b/arch/arm/mach-omap2/am33xx/Kconfig
> @@ -121,6 +121,9 @@ config TARGET_BRXRE1
>   bool "Support BRXRE1"
>   select BOARD_LATE_INIT
>  
> +config TARGET_BRSMARC1
> +bool "Support BRSMARC1"
> +select BOARD_LATE_INIT
>  config TARGET_BRPPT1
>   bool "Support BRPPT1"
>   select BOARD_LATE_INIT

You missed adding a newline after the new TARGET.

Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH u-boot-marvell v2 14/15] arm: mvebu: turris_omnia: add RESET button handling

2019-05-02 Thread Stefan Roese

On 02.05.19 13:53, Marek Behún wrote:

On Thu, 2 May 2019 11:43:12 +0200
Stefan Roese  wrote:


Please do so. If someone whats to disable this functionality or change
the reset button bootcmd, then he/she/it must do some changes
(defconfig or code).


So should I remove the options from Kconfig or enable them by default?


Yes.
 

BTW: We are going to ship omnia with several other options enabled?
Should I push them also to defconfig?


Yes please. Or why would it make sense to have a stripped down version
of this board port in mainline?
 

They are:

CONFIG_FIT=y
CONFIG_FIT_ENABLE_SHA256_SUPPORT=y
CONFIG_FIT_VERBOSE=y
CONFIG_CMD_LZMADEC=y
CONFIG_CMD_AES=y
CONFIG_CMD_HASH=y
CONFIG_CMD_SHA1SUM=y

Marek



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


Re: [U-Boot] [PATCH] board/BuR/zynq/brsmarc2: initial commit

2019-05-02 Thread Tom Rini
On Thu, May 02, 2019 at 01:38:22PM +0200, Hannes Schmelzer wrote:

> This commit adds the first of a few more Xilinx ZYNQ based SoM boards.
> 
> The SoM is based on Xilinx Zynq 7000 SoC.
> Mainly vxWorks 6.9.4.x is running on the board,
> doing some PLC stuff on various carrier boards.
> 
> Signed-off-by: Hannes Schmelzer 
> 
> ---
> 
>  arch/arm/dts/Makefile   |   2 +
>  arch/arm/dts/zynq-brsmarc2.dts  |  15 +
>  arch/arm/dts/zynq-brsmarc2.dtsi | 278 ++
>  arch/arm/dts/zynq-brsmarc2_r512.dts |  16 +
>  board/BuR/zynq/.gitignore   |   1 +
>  board/BuR/zynq/MAINTAINERS  |   6 +
>  board/BuR/zynq/Makefile |  16 +
>  board/BuR/zynq/brsmarc2/board.c |  84 +++
>  board/BuR/zynq/brsmarc2/ps7_init_gpl.c  | 814 
> 
>  board/BuR/zynq/brsmarc2_r512/board.c|   2 +
>  board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c | 813 +++
>  board/BuR/zynq/config.mk|  50 ++
>  board/BuR/zynq/take_vivadoHandoff.sh|  36 ++
>  board/BuR/zynq/uncrustify.cfg   |  91 
>  configs/brsmarc2_defconfig  |  72 +++
>  configs/brsmarc2_r512_defconfig |  72 +++
>  include/configs/brsmarc2.h  | 166 ++
>  17 files changed, 2534 insertions(+)

Same comment about new Makefile / config.mk files and SDPX tags, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] board/BuR/brppt2: initial commit

2019-05-02 Thread Tom Rini
On Thu, May 02, 2019 at 01:41:55PM +0200, Hannes Schmelzer wrote:

> This commit adds support for the brppt2 board. The board is based on the
> i.mx6 dual-lite SoC.
> 
> Signed-off-by: Hannes Schmelzer 

Same comment about Makefile / config.mk and SPDX tags, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v3] ARM: am335x: Add phyCORE AM335x R2 support

2019-05-02 Thread Heiko Schocher

Hello Niel,

Am 02.05.2019 um 11:52 schrieb Niel Fourie:

Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
phyBOARD-Wega AM335x.

CPU  : AM335X-GP rev 2.1
Model: Phytec AM335x phyBOARD-WEGA
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
eth0: ethernet@4a10

Working:
  - Eth0
  - i2C
  - MMC/SD
  - NAND
  - UART
  - USB (host)

Device trees were taken from Linux mainline revision
37624b58542fb9f2d9a70e6ea006ef8a5f66c30b

Signed-off-by: Niel Fourie 
---
  arch/arm/dts/Makefile  |   3 +-
  arch/arm/dts/am335x-phycore-som.dtsi   | 322 +
  arch/arm/dts/am335x-wega-rdk-u-boot.dtsi   |  40 +++
  arch/arm/dts/am335x-wega-rdk.dts   |  23 ++
  arch/arm/dts/am335x-wega.dtsi  | 230 +++
  arch/arm/mach-omap2/Kconfig|   1 +
  arch/arm/mach-omap2/am33xx/Kconfig |   7 +
  board/phytec/phycore_am335x_r2/Kconfig |  15 +
  board/phytec/phycore_am335x_r2/MAINTAINERS |   7 +
  board/phytec/phycore_am335x_r2/Makefile|  11 +
  board/phytec/phycore_am335x_r2/board.c | 263 +
  board/phytec/phycore_am335x_r2/board.h |  24 ++
  board/phytec/phycore_am335x_r2/mux.c   | 117 
  configs/phycore-am335x-r2-wega_defconfig   |  79 +
  include/configs/phycore_am335x_r2.h| 130 +
  15 files changed, 1271 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/am335x-phycore-som.dtsi
  create mode 100644 arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
  create mode 100644 arch/arm/dts/am335x-wega-rdk.dts
  create mode 100644 arch/arm/dts/am335x-wega.dtsi
  create mode 100644 board/phytec/phycore_am335x_r2/Kconfig
  create mode 100644 board/phytec/phycore_am335x_r2/MAINTAINERS
  create mode 100644 board/phytec/phycore_am335x_r2/Makefile
  create mode 100644 board/phytec/phycore_am335x_r2/board.c
  create mode 100644 board/phytec/phycore_am335x_r2/board.h
  create mode 100644 board/phytec/phycore_am335x_r2/mux.c
  create mode 100644 configs/phycore-am335x-r2-wega_defconfig
  create mode 100644 include/configs/phycore_am335x_r2.h


[...]


diff --git a/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi 
b/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
new file mode 100644
index 00..b7678e98ff
--- /dev/null
+++ b/arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 DENX Software Engineering GmbH
+ */
+
+/ {
+   chosen {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bootargs = "console=ttyO0,115200 earlyprintk";
+   stdout-path = &uart0;
+   };
+
+   ocp {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+   };
+
+   memory@8000 {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+   };
+};


could we move the entries for "ocp" and "memory" to

arch/arm/dts/am33xx-u-boot.dtsi ?

I think, this values are so common, that other am33xx based boards needs
them too ...


+&scm {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};


May this one too?

Beside of this nitpick:

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] board/BuR/brsmarc1: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds support for the B&R brsmarc1 SoM.

The SoM is based on TI's AM335x SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.

Signed-off-by: Hannes Schmelzer 

---

Changes in v2:
- fix style issue in arch/arm/mach-omap2/am33xx/Kconfig
- fix SDPX tag in Make-files/rules

 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/am335x-brsmarc1.dts   | 408 +
 arch/arm/mach-omap2/Kconfig|   1 +
 arch/arm/mach-omap2/am33xx/Kconfig |   4 +
 board/BuR/brsmarc1/Kconfig |  15 ++
 board/BuR/brsmarc1/MAINTAINERS |   6 +
 board/BuR/brsmarc1/Makefile|  10 +
 board/BuR/brsmarc1/board.c | 168 +++
 board/BuR/brsmarc1/config.mk   |  33 +++
 board/BuR/brsmarc1/mux.c   | 266 
 configs/brsmarc1_defconfig | 107 ++
 include/configs/brsmarc1.h |  87 
 12 files changed, 1106 insertions(+)
 create mode 100644 arch/arm/dts/am335x-brsmarc1.dts
 create mode 100644 board/BuR/brsmarc1/Kconfig
 create mode 100644 board/BuR/brsmarc1/MAINTAINERS
 create mode 100644 board/BuR/brsmarc1/Makefile
 create mode 100644 board/BuR/brsmarc1/board.c
 create mode 100644 board/BuR/brsmarc1/config.mk
 create mode 100644 board/BuR/brsmarc1/mux.c
 create mode 100644 configs/brsmarc1_defconfig
 create mode 100644 include/configs/brsmarc1.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..8ac057a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -250,6 +250,7 @@ dtb-$(CONFIG_AM33XX) += \
am335x-brppt1-nand.dtb \
am335x-brppt1-spi.dtb \
am335x-brxre1.dtb \
+   am335x-brsmarc1.dtb \
am335x-draco.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/dts/am335x-brsmarc1.dts b/arch/arm/dts/am335x-brsmarc1.dts
new file mode 100644
index 000..e5e2761
--- /dev/null
+++ b/arch/arm/dts/am335x-brsmarc1.dts
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 B&R Industrial Automation GmbH
+ * http://www.br-automation.com
+ *
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+
+/ {
+   model = "BRSMARC1 SoM";
+   compatible = "ti,am33xx";
+
+   fset: factory-settings {
+   bl-version  = "";
+   order-no= "";
+   cpu-order-no= "";
+   hw-revision = "";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   hw-platform = <0x7>;
+   fram-offset = <0x100>;
+   fram-size   = <0x1F00>;
+   cache-disable   = <0x0>;
+   cpu-clock   = <0x0>;
+   };
+
+   chosen {
+   bootargs = "console=ttyO0,115200 earlyprintk";
+   stdout-path = &uart0;
+   };
+
+   aliases {
+   fset = &fset;
+   mmc = &mmc2;
+   spi0 = &spi0;
+   spi1 = &spi1;
+   touch0 = &burtouch0;
+   screen0 = &lcdscreen0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   vmmcsd_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   lcdscreen0: lcdscreen@0 {
+   /*backlight = <&tps_bl>; */
+   compatible = "ti,tilcdc,panel";
+   status = "okay";
+
+   panel-info {
+   ac-bias = <255>;
+   ac-bias-intrpt  = <0>;
+   dma-burst-sz= <16>;
+   bpp = <32>;
+   fdd = <0x80>;
+   sync-edge   = <0>;
+   sync-ctrl   = <1>;
+   raster-order= <0>;
+   fifo-th = <0>;
+   rotation= <0>;
+   pupdelay= <0>;
+   pondelay= <0>;
+   pwrpin  = <0x00B1>;
+   brightdrv   = <0>;
+   brightfdim  = <100>;
+   brightdef   = <50>;
+   };
+
+   display-timings {
+   default {
+   clock-frequency = <0>;
+   hactive = <0>;
+   vactive = <0>;
+   hfront-porch= <0>;
+  

[U-Boot] [PATCH v2] board/BuR/brppt2: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds support for the brppt2 board. The board is based on the
i.mx6 dual-lite SoC.

Signed-off-by: Hannes Schmelzer 

---

Changes in v2:
- fix SDPX tag in Make-files/rules

 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/imx6dl-brppt2.dts | 278 +
 arch/arm/mach-imx/mx6/Kconfig  |  19 ++
 board/BuR/brppt2/Kconfig   |  18 ++
 board/BuR/brppt2/MAINTAINERS   |   6 +
 board/BuR/brppt2/Makefile  |   8 +
 board/BuR/brppt2/board.c   | 542 +
 board/BuR/brppt2/config.mk |  36 +++
 configs/brppt2_defconfig   |  92 +++
 include/configs/brppt2.h   | 125 ++
 10 files changed, 1126 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6dl-brppt2.dts
 create mode 100644 board/BuR/brppt2/Kconfig
 create mode 100644 board/BuR/brppt2/MAINTAINERS
 create mode 100644 board/BuR/brppt2/Makefile
 create mode 100644 board/BuR/brppt2/board.c
 create mode 100644 board/BuR/brppt2/config.mk
 create mode 100644 configs/brppt2_defconfig
 create mode 100644 include/configs/brppt2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..288c3e8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -529,7 +529,8 @@ dtb-$(CONFIG_MX6QDL) += \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
imx6qp-sabreauto.dtb \
-   imx6qp-sabresd.dtb
+   imx6qp-sabresd.dtb \
+   imx6dl-brppt2.dtb
 
 dtb-$(CONFIG_TARGET_WANDBOARD) += \
imx6dl-wandboard-revb1.dtb
diff --git a/arch/arm/dts/imx6dl-brppt2.dts b/arch/arm/dts/imx6dl-brppt2.dts
new file mode 100644
index 000..4f1c52b
--- /dev/null
+++ b/arch/arm/dts/imx6dl-brppt2.dts
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 B&R Industrial Automation GmbH
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-u-boot.dtsi"
+#include 
+#include 
+
+/ {
+   model = "PPT50";
+   compatible = "fsl,imx6dl";
+
+   config {
+   u-boot,spl-payload-offset = <0x10>;
+   };
+
+   fset: factory-settings {
+   bl-version  = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   order-no= "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   hw-revision = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   };
+
+   aliases {
+   ds1timing0 = &timing0;
+   ds1timing1 = &timing1;
+   ds1bkl = &backlight;
+   fset = &fset;
+   mxcfb0 = &mxcfb0;
+   touch0 = &touch0;
+   touch1 = &touch1;
+   touch2 = &touch2;
+   display_regulator = &display_regulator;
+   ldb = &ldb;
+   mmc0 = &usdhc4;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   mxcfb0: fb@0 {
+   compatible = "fsl,mxc_sdc_fb";
+   disp_dev = "ldb";
+   interface_pix_fmt = "RGB24";
+   default_bpp = <32>;
+   int_clk = <0>;
+   late_init = <0>;
+   rotation = <0>;
+   status = "okay";
+   };
+
+   lcd@0 {
+   compatible = "fsl,lcd";
+   vlcd-supply = <&display_regulator>;
+   ipu_id = <0>;
+   disp_id = <0>;
+   default_ifmt = "RGB24";
+   status = "disabled";
+
+   display-timings {
+   native-mode = <&timing1>;
+   timing1: lcd {
+   };
+   };
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm4 0 500>;
+   brightness-levels = <0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100>;
+  

[U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

2019-05-02 Thread Hannes Schmelzer
This commit adds the first of a few more Xilinx ZYNQ based SoM boards.

The SoM is based on Xilinx Zynq 7000 SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.

Signed-off-by: Hannes Schmelzer 

---

Changes in v2:
- fix SDPX tag in Make-files/rules

 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/zynq-brsmarc2.dts  |  15 +
 arch/arm/dts/zynq-brsmarc2.dtsi | 278 ++
 arch/arm/dts/zynq-brsmarc2_r512.dts |  16 +
 board/BuR/zynq/.gitignore   |   1 +
 board/BuR/zynq/MAINTAINERS  |   6 +
 board/BuR/zynq/Makefile |  16 +
 board/BuR/zynq/brsmarc2/board.c |  84 +++
 board/BuR/zynq/brsmarc2/ps7_init_gpl.c  | 814 
 board/BuR/zynq/brsmarc2_r512/board.c|   2 +
 board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c | 813 +++
 board/BuR/zynq/config.mk|  49 ++
 board/BuR/zynq/take_vivadoHandoff.sh|  36 ++
 board/BuR/zynq/uncrustify.cfg   |  91 
 configs/brsmarc2_defconfig  |  72 +++
 configs/brsmarc2_r512_defconfig |  72 +++
 include/configs/brsmarc2.h  | 166 ++
 17 files changed, 2533 insertions(+)
 create mode 100644 arch/arm/dts/zynq-brsmarc2.dts
 create mode 100644 arch/arm/dts/zynq-brsmarc2.dtsi
 create mode 100644 arch/arm/dts/zynq-brsmarc2_r512.dts
 create mode 100644 board/BuR/zynq/.gitignore
 create mode 100644 board/BuR/zynq/MAINTAINERS
 create mode 100644 board/BuR/zynq/Makefile
 create mode 100644 board/BuR/zynq/brsmarc2/board.c
 create mode 100644 board/BuR/zynq/brsmarc2/ps7_init_gpl.c
 create mode 100644 board/BuR/zynq/brsmarc2_r512/board.c
 create mode 100644 board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c
 create mode 100644 board/BuR/zynq/config.mk
 create mode 100755 board/BuR/zynq/take_vivadoHandoff.sh
 create mode 100644 board/BuR/zynq/uncrustify.cfg
 create mode 100644 configs/brsmarc2_defconfig
 create mode 100644 configs/brsmarc2_r512_defconfig
 create mode 100644 include/configs/brsmarc2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..2b00129 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011-x16.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
+   zynq-brsmarc2.dtb \
+   zynq-brsmarc2_r512.dtb \
zynq-zed.dtb \
zynq-zturn.dtb \
zynq-zybo.dtb \
diff --git a/arch/arm/dts/zynq-brsmarc2.dts b/arch/arm/dts/zynq-brsmarc2.dts
new file mode 100644
index 000..5ad5113
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * B&R BRSMARC2 board base DTS file
+ *
+ *  Copyright (C) 2018 B&R Industrial Automation GmbH
+ *
+ */
+/dts-v1/;
+#include "zynq-brsmarc2.dtsi"
+/ {
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+};
diff --git a/arch/arm/dts/zynq-brsmarc2.dtsi b/arch/arm/dts/zynq-brsmarc2.dtsi
new file mode 100644
index 000..d1aeffd
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2.dtsi
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * B&R BRSMARC2 board base DTS file
+ *
+ *  Copyright (C) 2017 B&R Industrial Automation GmbH
+ *  Copyright (C) 2011 - 2015 Xilinx
+ *  Copyright (C) 2012 National Instruments Corp.
+ */
+
+/include/ "zynq-7000.dtsi"
+#include 
+#include 
+
+/ {
+   model = "BRSMARC2 Zynq SoM";
+   compatible = "xlnx,zynq-7000";
+
+   fset: factory-settings {
+   bl-version  = "";
+   order-no= "";
+   cpu-order-no= "";
+   hw-revision = "";
+   serial-no   = <0>;
+   device-id   = <0x0>;
+   parent-id   = <0x0>;
+   hw-variant  = <0x0>;
+   hw-platform = <0x0>;
+   fram-offset = <0x0>;
+   fram-size   = <0x0>;
+   cache-disable   = <0x0>;
+   cpu-clock   = <0x0>;
+   };
+
+   aliases {
+   ethernet0 = &gem0;
+   ethernet1 = &gem1;
+   i2c0 = &i2c0;
+   serial0 = &uart0;
+   spi0 = &qspi;
+   mmc0 = &sdhci0;
+   fset = &fset;
+   can0 = &can0;
+   can1 = &can1;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   board {
+   status = "okay";
+   compatible = "bur,brsmarc2-som";
+   usb0mux-gpios = <&gpio0 68 GPIO_ACTIVE_HIGH>;
+   usb1mux-gpios = <&gpio0 69 GPIO_ACTIVE_HIGH>;
+   powerdown-gpios

[U-Boot] [PATCH v2 0/4] Misc EFI/GPT/UUID fixes

2019-05-02 Thread Eugeniu Rosca
This is a collection of fixes addressing issues on R-Car H3ULCB-KF.
All have been tested on H3ULCB-KF and boot-tested on sandbox.

Changes in v2:
 - Reworded the description and summary line of
   ("lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y")
   to emphasize it is a fix rather than an improvement.
 - No code changes.

Eugeniu Rosca (4):
  disk: efi: Fix memory leak on 'gpt guid'
  disk: efi: Fix memory leak on 'gpt verify'
  cmd: gpt: fix and tidy up help message
  lib: uuid: Fix unseeded PRNG on RANDOM_UUID=y

 cmd/gpt.c   | 12 ++--
 disk/part_efi.c |  6 ++
 lib/uuid.c  |  2 ++
 3 files changed, 14 insertions(+), 6 deletions(-)

-- 
2.21.0

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


[U-Boot] [PATCH v2 1/4] disk: efi: Fix memory leak on 'gpt guid'

2019-05-02 Thread Eugeniu Rosca
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt guid mmc 1
 21200400-0804-0146-9dcc-a8c51255994f
 success!
 => ### keep calling 'gpt guid mmc 1'
 => ### on 59th call, we are out of memory:
 => gpt guid mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid GPT ***
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid Backup GPT ***
 error!

After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().

With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.

Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca 
Reviewed-by: Heinrich Schuchardt 
--
v2:
 - Added Reviewed-by: Heinrich Schuchardt
v1:
 - https://patchwork.ozlabs.org/patch/1092942/
---
 disk/part_efi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 239455b8161e..812d14cdd871 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid)
guid_bin = gpt_head->disk_guid.b;
uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID);
 
+   /* Remember to free pte */
+   free(gpt_pte);
return 0;
 }
 
-- 
2.21.0

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


[U-Boot] [PATCH v2 2/4] disk: efi: Fix memory leak on 'gpt verify'

2019-05-02 Thread Eugeniu Rosca
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt verify mmc 1
 No partition list provided - only basic check
 Verify GPT: success!
 => ### keep calling 'gpt verify mmc 1'
 => ### on 58th call, we are out of memory:
 => gpt verify mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
 Verify GPT: error!

This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().

With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.

[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions

Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT 
verification functions")
Signed-off-by: Eugeniu Rosca 
Reviewed-by: Heinrich Schuchardt 
--
v2:
 - Added Reviewed-by: Heinrich Schuchardt
v1:
 - https://patchwork.ozlabs.org/patch/1092943/
---
 disk/part_efi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 812d14cdd871..c0fa753339c8 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -698,6 +698,10 @@ int gpt_verify_headers(struct blk_desc *dev_desc, 
gpt_header *gpt_head,
   __func__);
return -1;
}
+
+   /* Free pte before allocating again */
+   free(*gpt_pte);
+
if (is_gpt_valid(dev_desc, (dev_desc->lba - 1),
 gpt_head, gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid Backup GPT ***\n",
-- 
2.21.0

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


[U-Boot] [PATCH v2 3/4] cmd: gpt: fix and tidy up help message

2019-05-02 Thread Eugeniu Rosca
Apply the following changes:
 - Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
   since 'gpt read' is not available on CMD_GPT_RENAME=n
 - Prefix the {read,swap,rename} commands with one space for consistency
 - Prefix the 'guid' commands with 'gpt' for consistency

Signed-off-by: Eugeniu Rosca 
Reviewed-by: Heinrich Schuchardt 
--
v2:
 - Added Reviewed-by: Heinrich Schuchardt
v1:
 - https://patchwork.ozlabs.org/patch/1092944/
---
 cmd/gpt.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 638870352f40..33cda513969f 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -876,21 +876,21 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" Example usage:\n"
" gpt write mmc 0 $partitions\n"
" gpt verify mmc 0 $partitions\n"
-   " read  \n"
-   "- read GPT into a data structure for manipulation\n"
-   " guid  \n"
+   " gpt guid  \n"
"- print disk GUID\n"
-   " guid   \n"
+   " gpt guid   \n"
"- set environment variable to disk GUID\n"
" Example usage:\n"
" gpt guid mmc 0\n"
" gpt guid mmc 0 varname\n"
 #ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
-   "gpt swap\n"
+   " gpt read  \n"
+   "- read GPT into a data structure for manipulation\n"
+   " gpt swap\n"
"- change all partitions named name1 to name2\n"
"  and vice-versa\n"
-   "gpt rename\n"
+   " gpt rename\n"
"- rename the specified partition\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"
-- 
2.21.0

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


[U-Boot] [PATCH v2 4/4] lib: uuid: Fix unseeded PRNG on RANDOM_UUID=y

2019-05-02 Thread Eugeniu Rosca
The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:

 => ### interrupt autoboot
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7

While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.

Assuming U-Boot with RANDOM_UUID=y is deployed on a large number of
devices, all those devices would essentially expose the same UUID,
breaking the assumption of system/RFS/application designers who rely
on UUID as being globally unique (e.g. a database using UUID as key
would alias/mix up entries/records due to duplicated UUID).

The root cause seems to be simply _not_ seeding PRNG before generating
a random value. It turns out this belongs to an established class of
PRNG-specific problems, commonly known as "unseeded randomness", for
which I am able to find below bugs/CVE/CWE:
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
   ("CVE-2015-0285 openssl: handshake with unseeded PRNG")
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
   ("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded
   randomness")
 - https://cwe.mitre.org/data/definitions/336.html
   ("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")

The first revision [1] of this patch updated the seed based on the
output of get_timer(), similar to [4].

There are two problems with this approach:
 - get_timer() has a poor _ms_ resolution
 - when gen_rand_uuid() is called in a loop, get_timer() returns the
   same result, leading to the same seed being passed to srand(),
   leading to the same uuid being generated for several partitions
   with different names

The above drawbacks have been addressed in the second version [2].
In its third revision (current), the patch reworded the description
and summary line to emphasize it is a *fix* rather than an improvement.

Testing [3] consisted of running 'gpt write mmc 1 $partitions' in a
loop on R-Car3 for several minutes, collecting 8844 randomly generated
UUIDS. Two consecutive cold boots are concatenated in the log.
As a result, all uuid values are unique (scripted check).

Thanks to Roman, who reported the issue and provided support in fixing.

[1] https://patchwork.ozlabs.org/patch/1091802/
[2] https://patchwork.ozlabs.org/patch/1092945/
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
[4] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function")

Reported-by: Roman Stratiienko 
Signed-off-by: Eugeniu Rosca 
--
v3:
 - Reworked the patch summary line and description to emphasize this is
   a fix rather than an improvement by precisely pointing out the root
   cause and mentioning related CVE/CWE.
v2:
 - https://patchwork.ozlabs.org/patch/1092945/
 - Replaced get_timer(0) with get_ticks() and added rand() to seed value
 - Performed extensive testing on R-Car3 (ARMv8). See:
   https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
v1:
 - https://patchwork.ozlabs.org/patch/1092944/
---
 lib/uuid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/uuid.c b/lib/uuid.c
index fa20ee39fc32..2d4d6ef7e461 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin)
unsigned int *ptr = (unsigned int *)&uuid;
int i;
 
+   srand(get_ticks() + rand());
+
/* Set all fields randomly */
for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++)
*(ptr + i) = cpu_to_be32(rand());
-- 
2.21.0

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


Re: [U-Boot] [PATCH v2] board/BuR/brsmarc1: initial commit

2019-05-02 Thread Felix Brack
Hi Hannes,

On 02.05.19 14:09, Hannes Schmelzer wrote:
> This commit adds support for the B&R brsmarc1 SoM.
> 
> The SoM is based on TI's AM335x SoC.
> Mainly vxWorks 6.9.4.x is running on the board,
> doing some PLC stuff on various carrier boards.
> 
> Signed-off-by: Hannes Schmelzer 
> 
> ---
> 
> Changes in v2:
> - fix style issue in arch/arm/mach-omap2/am33xx/Kconfig
> - fix SDPX tag in Make-files/rules
> 
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/am335x-brsmarc1.dts   | 408 
> +
>  arch/arm/mach-omap2/Kconfig|   1 +
>  arch/arm/mach-omap2/am33xx/Kconfig |   4 +
>  board/BuR/brsmarc1/Kconfig |  15 ++
>  board/BuR/brsmarc1/MAINTAINERS |   6 +
>  board/BuR/brsmarc1/Makefile|  10 +
>  board/BuR/brsmarc1/board.c | 168 +++
>  board/BuR/brsmarc1/config.mk   |  33 +++
>  board/BuR/brsmarc1/mux.c   | 266 
>  configs/brsmarc1_defconfig | 107 ++
>  include/configs/brsmarc1.h |  87 
>  12 files changed, 1106 insertions(+)
>  create mode 100644 arch/arm/dts/am335x-brsmarc1.dts
>  create mode 100644 board/BuR/brsmarc1/Kconfig
>  create mode 100644 board/BuR/brsmarc1/MAINTAINERS
>  create mode 100644 board/BuR/brsmarc1/Makefile
>  create mode 100644 board/BuR/brsmarc1/board.c
>  create mode 100644 board/BuR/brsmarc1/config.mk
>  create mode 100644 board/BuR/brsmarc1/mux.c
>  create mode 100644 configs/brsmarc1_defconfig
>  create mode 100644 include/configs/brsmarc1.h
> 
> diff --git a/board/BuR/brsmarc1/mux.c b/board/BuR/brsmarc1/mux.c
> new file mode 100644
> index 000..33c214d
> --- /dev/null
> +++ b/board/BuR/brsmarc1/mux.c
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * mux.c
> + *
> + * Pinmux Setting for B&R BRSMARC1 Board (HW-Rev. 1)
> + *
> + * Copyright (C) 2017 Hannes Schmelzer 
> + * B&R Industrial Automation GmbH - http://www.br-automation.com
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +

Is there any particular reason for not using the existing pinctrl driver
to do all this pin configuration?

> +static struct module_pin_mux spi0_pin_mux[] = {
> + /* SPI0_SCLK */
> + {OFFSET(spi0_sclk), MODE(0) | PULLUDEN | RXACTIVE},
> + /* SPI0_D0 */
> + {OFFSET(spi0_d0),   MODE(0) | PULLUDEN | RXACTIVE},
> + /* SPI0_D1 */
> + {OFFSET(spi0_d1),   MODE(0) | PULLUDEN | RXACTIVE},
> + /* SPI0_CS0 */
> + {OFFSET(spi0_cs0),  MODE(7) | PULLUDEN | PULLUP_EN | RXACTIVE},
> + /* SPI0_CS1 */
> + {OFFSET(spi0_cs1),  MODE(7) | PULLUDEN | PULLUP_EN | RXACTIVE},
> + {-1},
> +};
> +
> +static struct module_pin_mux spi1_pin_mux[] = {
> + /* SPI1_SCLK */
> + {OFFSET(mcasp0_aclkx),  MODE(3) | PULLUDEN | RXACTIVE},
> + /* SPI1_D0 */
> + {OFFSET(mcasp0_fsx),MODE(3) | PULLUDEN | RXACTIVE},
> + /* SPI1_D1 */
> + {OFFSET(mcasp0_axr0),   MODE(3) | PULLUDEN | RXACTIVE},
> + /* SPI1_CS0 */
> + {OFFSET(mcasp0_ahclkr), MODE(7) | PULLUDEN | PULLUP_EN | RXACTIVE},
> + /* SPI1_CS1 */
> + {OFFSET(xdma_event_intr0), MODE(7) | PULLUDEN | PULLUP_EN | RXACTIVE},
> + {-1},
> +};
> +
> +static struct module_pin_mux dcan0_pin_mux[] = {
> + /* DCAN0 TX */
> + {OFFSET(uart1_ctsn),MODE(2) | PULLUDEN | PULLUP_EN},
> + /* DCAN0 RX */
> + {OFFSET(uart1_rtsn),MODE(2) | RXACTIVE},
> + {-1},
> +};
> +
> +static struct module_pin_mux dcan1_pin_mux[] = {
> + /* DCAN1 TX */
> + {OFFSET(uart0_ctsn),MODE(2) | PULLUDEN | PULLUP_EN},
> + /* DCAN1 RX */
> + {OFFSET(uart0_rtsn),MODE(2) | RXACTIVE},
> + {-1},
> +};
> +
> +static struct module_pin_mux gpios[] = {
> + /* GPIO0_7 - LVDS_EN */
> + {OFFSET(ecap0_in_pwm0_out), (MODE(7) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO0_20 - BKLT_PWM (timer7) */
> + {OFFSET(xdma_event_intr1), (MODE(4) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO2_4 - DISON */
> + {OFFSET(gpmc_wen), (MODE(7) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO1_24 - RGB_EN */
> + {OFFSET(gpmc_a8), (MODE(7) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO1_28 - nPD */
> + {OFFSET(gpmc_be1n), (MODE(7) | PULLUDEN | PULLUP_EN)},
> + /* GPIO2_5 - Watchdog */
> + {OFFSET(gpmc_be0n_cle), (MODE(7) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO2_0 - ResetOut */
> + {OFFSET(gpmc_csn3), (MODE(7) | PULLUDEN | PULLUP_EN)},
> + /* GPIO2_2 - BKLT_EN */
> + {OFFSET(gpmc_advn_ale), (MODE(7) | PULLUDDIS | PULLDOWN_EN)},
> + /* GPIO1_17 - GPIO0 */
> + {OFFSET(gpmc_a1), (MODE(7) | PULLUDDIS | RXACTIVE)},
> + /* GPIO1_18 - GPIO1 */
> + {OFFSET(gpmc_a2), (MODE(7) | PULLUDDIS | RXACTIVE)},
> + /* GPIO1_19 - GPIO2 */
> + {OFFSET(gpmc_a3), (MODE(7) | PULLUDDIS | RXACTIVE)},
> + /* GPIO1_22 - GPIO3 */
> + {OFFSET(gpmc_a6), (MODE(7) | PULLUDDIS | RXACTIVE)},
> + /* GPIO1_23 - GPIO4 */
> + {OFFSET

[U-Boot] [PATCH] fs: btrfs: fix btrfs methods return values on failure

2019-05-02 Thread Marek Behún
The btrfs implementation methods .ls(), .size() and .read() returns 1 on
failure, but the command handlers expect values <0 on failure.

For example if given a nonexistent path, the load command currently
returns success, and hush scripting does not work.

Fix this by setting return values of these methods to -1 instead of 1 on
failure.

Signed-off-by: Marek Behún 
---
 fs/btrfs/btrfs.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
index 6f35854823..cb7e182742 100644
--- a/fs/btrfs/btrfs.c
+++ b/fs/btrfs/btrfs.c
@@ -119,17 +119,17 @@ int btrfs_ls(const char *path)
 
if (inr == -1ULL) {
printf("Cannot lookup path %s\n", path);
-   return 1;
+   return -1;
}
 
if (type != BTRFS_FT_DIR) {
printf("Not a directory: %s\n", path);
-   return 1;
+   return -1;
}
 
if (btrfs_readdir(&root, inr, readdir_callback)) {
printf("An error occured while listing directory %s\n", path);
-   return 1;
+   return -1;
}
 
return 0;
@@ -158,12 +158,12 @@ int btrfs_size(const char *file, loff_t *size)
 
if (inr == -1ULL) {
printf("Cannot lookup file %s\n", file);
-   return 1;
+   return -1;
}
 
if (type != BTRFS_FT_REG_FILE) {
printf("Not a regular file: %s\n", file);
-   return 1;
+   return -1;
}
 
*size = inode.size;
@@ -183,12 +183,12 @@ int btrfs_read(const char *file, void *buf, loff_t 
offset, loff_t len,
 
if (inr == -1ULL) {
printf("Cannot lookup file %s\n", file);
-   return 1;
+   return -1;
}
 
if (type != BTRFS_FT_REG_FILE) {
printf("Not a regular file: %s\n", file);
-   return 1;
+   return -1;
}
 
if (!len)
@@ -200,7 +200,7 @@ int btrfs_read(const char *file, void *buf, loff_t offset, 
loff_t len,
rd = btrfs_file_read(&root, inr, offset, len, buf);
if (rd == -1ULL) {
printf("An error occured while reading file %s\n", file);
-   return 1;
+   return -1;
}
 
*actread = rd;
-- 
2.21.0

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


[U-Boot] [PATCH] cmd: pxe: add board specific PXE default path

2019-05-02 Thread Marek Behún
The list of PXE default paths contains ARCH and SOC specific paths, but
one PXE server can serve different board with the same ARCH and SOC.
This is the case for Turris Omnia and Turris Mox, where ARCH=arm and
SOC=mvebu.

If CONFIG_SYS_BOARD is defined, also try "default-$ARCH-$SOC-$BOARD"
path.

Signed-off-by: Marek Behún 
---
 cmd/pxe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cmd/pxe.c b/cmd/pxe.c
index 274555319b..127751642e 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -22,6 +22,9 @@
 
 const char *pxe_default_paths[] = {
 #ifdef CONFIG_SYS_SOC
+#ifdef CONFIG_SYS_BOARD
+   "default-" CONFIG_SYS_ARCH "-" CONFIG_SYS_SOC "-" CONFIG_SYS_BOARD,
+#endif
"default-" CONFIG_SYS_ARCH "-" CONFIG_SYS_SOC,
 #endif
"default-" CONFIG_SYS_ARCH,
-- 
2.21.0

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


Re: [U-Boot] WaRP7 nok on master

2019-05-02 Thread Fabio Estevam
Hi Lukas,

On Thu, May 2, 2019 at 7:21 AM Auer, Lukas
 wrote:

> I was able to reproduce the issue on my side. With the patch, U-Boot
> probes the drivers for devices under simple-bus device tree nodes in
> the pre-relocation device model. The default value of
> CONFIG_SYS_MALLOC_LEN (0x400) leaves U-Boot with not enough memory to
> do this, causing it to hang. If it is increased, for example to 0x1000,
> everything works again.
>
> Let me know, how you want to fix this. If you want, I can send a patch
> to increase CONFIG_SYS_MALLOC_LEN for the i.MX parts.

I guess you mean CONFIG_SYS_MALLOC_F_LEN instead?

Could you please send a patch setting CONFIG_SYS_MALLOC_F_LEN as
0x2000 by default for i.MX?

0x1000 seems not to be enough:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=8b9cba0295dcdce5eb8bb10d79f6dafb5a167349;hp=b7de88cd5cb8c213fb158b37fcf0662c1d2332cd
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3] ARM: am335x: Add phyCORE AM335x R2 support

2019-05-02 Thread Marek Vasut
On 5/2/19 11:52 AM, Niel Fourie wrote:
[...]
> +++ b/board/phytec/phycore_am335x_r2/board.c
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * board.c
> + *
> + * Board functions for Phytec phyCORE-AM335x R2 (pcl060) based boards
> + *
> + * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
> + * Copyright (C) 2013 Lars Poeschel, Lemonage Software GmbH
> + * Copyright (C) 2015 Wadim Egorov, PHYTEC Messtechnik GmbH
> + * Copyright (C) 2019 DENX Software Engineering GmbH
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "board.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifdef CONFIG_SPL_BUILD
> +
> +static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
> +
> +#if CONFIG_IS_ENABLED(OS_BOOT)
> +int spl_start_uboot(void)
> +{
> + return 1;

Can this be removed completely ?

> +}
> +#endif
> +
> +/* DDR RAM defines */
> +#define DDR_CLK_MHZ  400 /* DDR_DPLL_MULT value */
> +
> +#define OSC  (V_OSCK / 100)
> +const struct dpll_params dpll_ddr = {
> + DDR_CLK_MHZ, OSC - 1, 1, -1, -1, -1, -1};
> +
> +const struct dpll_params *get_dpll_ddr_params(void)
> +{
> + return &dpll_ddr;
> +}
> +
> +const struct ctrl_ioregs ioregs = {
> + .cm0ioctl   = 0x18B,
> + .cm1ioctl   = 0x18B,
> + .cm2ioctl   = 0x18B,
> + .dt0ioctl   = 0x18B,
> + .dt1ioctl   = 0x18B,
> +};
> +
> +static const struct cmd_control ddr3_cmd_ctrl_data = {
> + .cmd0csratio = 0x80,
> + .cmd0iclkout = 0x0,
> +
> + .cmd1csratio = 0x80,
> + .cmd1iclkout = 0x0,
> +
> + .cmd2csratio = 0x80,
> + .cmd2iclkout = 0x0,
> +};
> +
> +enum {
> + PHYCORE_R2_MT41K128M16JT_256MB,
> + PHYCORE_R2_MT41K256M16TW107IT_512MB,
> + PHYCORE_R2_MT41K512M16HA125IT_1024MB,
> +};
> +
> +struct am335x_sdram_timings {
> + struct emif_regs ddr3_emif_reg_data;
> + struct ddr_data ddr3_data;
> +};
> +
> +static struct am335x_sdram_timings physom_timings[] = {
> + [PHYCORE_R2_MT41K128M16JT_256MB] = {
> + .ddr3_emif_reg_data = {
> + .sdram_config = 0x61C052B2,
> + .ref_ctrl = 0x0C30,
> + .sdram_tim1 = 0x0AAAD4DB,
> + .sdram_tim2 = 0x26437FDA,
> + .sdram_tim3 = 0x501F83FF,
> + .zq_config = 0x50074BE4,
> + .emif_ddr_phy_ctlr_1 = 0x7,
> + .ocp_config = 0x003d3d3d,

There's one tab too many .

> + },
> + .ddr3_data = {
> + .datardsratio0 = 0x36,
> + .datawdsratio0 = 0x38,
> + .datafwsratio0 = 0x99,
> + .datawrsratio0 = 0x73,
> + },
> + },

[...]

> +void scale_vcores_generic(int freq)
> +{
> + int sil_rev, mpu_vdd;
> +
> + /*
> +  * We use a TPS65910 PMIC. For all  MPU frequencies we support we use a
> +  * CORE voltage of 1.10V. For MPU voltage we need to switch based on
> +  * the frequency we are running at.
> +  */
> +#if defined(CONFIG_DM_I2C)

Can we not support non-DM i2c ?

> + if (power_tps65910_init(0))
> + return;
> +#else

And drop this part ?

> + if (i2c_probe(TPS65910_CTRL_I2C_ADDR))
> + return;
> +#endif
[...]


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


[U-Boot] [PATCH u-boot-marvell v3 00/17] Fixes for Turris Omnia

2019-05-02 Thread Marek Behún
Hi, this is the third version of my fixes for Turris Omnia.

Added since v2:
 - patch 16: adds GPIO support so that boot script can recognize if SFP
 module is inserted and select appropriate device tree for
 kernel
 - patch 17: enable CONFIG_FIT and other options needed by vendor

Changes since v2:
 - added Reviewed-by tags for first 13 patches (sorry Stefan, I already
   did it before reading your email that Patchwork does this
   automatically)
 - patch 14 (Factory RESET button handling): remove the Kconfig options,
   this functionality is now always enabled
 - patch 15: added comment as requested by Heiko

Marek Behún (17):
  arm: mvebu: turris_omnia: remove redundant code
  arm: mvebu: turris_omnia: add XHCI to defconfig
  arm: mvebu: turris_omnia: use AHCI and SATA driver model
  arm: mvebu: turris_omnia: remove legacy macros from board header
  arm: mvebu: turris_omnia: move I2C dependencies to Kconfig
  arm: mvebu: turris_omnia: add SCSI as boot target
  arm: mvebu: turris_omnia: refactor I2C accessing code
  arm: mvebu: turris_omnia: fix checkpatch warnings
  arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig
  arm: mvebu: turris_omnia: refactor more code
  arm: mvebu: turris_omnia: print board info as Turris Mox
  arm: mvebu: turris_*: remove watchdog include
  arm: mvebu: turris_omnia: fix regdomain env var setting
  arm: mvebu: turris_omnia: add RESET button handling
  i2c: mvtwsi: fix reading status register after interrupt
  arm: mvebu: turris_omnia: add GPIO support to defconfig
  arm: mvebu: turris_omnia: enable defconfig options needed by vendor

 arch/arm/mach-mvebu/Kconfig  |   7 +
 board/CZ.NIC/turris_mox/turris_mox.c |   4 -
 board/CZ.NIC/turris_omnia/turris_omnia.c | 348 ---
 configs/turris_omnia_defconfig   |  24 +-
 drivers/i2c/mvtwsi.c |  11 +
 include/configs/turris_omnia.h   |  32 +--
 6 files changed, 233 insertions(+), 193 deletions(-)

-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 02/17] arm: mvebu: turris_omnia: add XHCI to defconfig

2019-05-02 Thread Marek Behún
Add XHCI_HOST and XHCI_MVEBU to defconfig, so that user's can by default
boot from USB on Turris Omnia.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 configs/turris_omnia_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index a528a9b5bc..2ad2f6e431 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -58,5 +58,7 @@ CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_MVEBU=y
 CONFIG_WDT=y
 CONFIG_WDT_ORION=y
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 04/17] arm: mvebu: turris_omnia: remove legacy macros from board header

2019-05-02 Thread Marek Behún
These are not needed if MMC and SCSI DM drivers are used.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 include/configs/turris_omnia.h | 14 --
 1 file changed, 14 deletions(-)

diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h
index 0e65a12345..5e692e6829 100644
--- a/include/configs/turris_omnia.h
+++ b/include/configs/turris_omnia.h
@@ -29,20 +29,6 @@
 #define CONFIG_SPL_I2C_MUX
 #define CONFIG_SYS_I2C_MVTWSI
 
-/*
- * SDIO/MMC Card Configuration
- */
-#define CONFIG_SYS_MMC_BASEMVEBU_SDIO_BASE
-
-/*
- * SATA/SCSI/AHCI configuration
- */
-#define CONFIG_SCSI_AHCI_PLAT
-#define CONFIG_SYS_SCSI_MAX_SCSI_ID2
-#define CONFIG_SYS_SCSI_MAX_LUN1
-#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
-CONFIG_SYS_SCSI_MAX_LUN)
-
 /* USB/EHCI configuration */
 #define CONFIG_EHCI_IS_TDI
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 01/17] arm: mvebu: turris_omnia: remove redundant code

2019-05-02 Thread Marek Behún
The i2c slave disabling is done by mvtwsi driver and is not needed here.

Signed-off-by: Marek Behún 
Acked-by: Heiko Schocher 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 4c08f810a2..055ebad000 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -50,8 +50,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define OMNIA_ATSHA204_OTP_MAC03
 #define OMNIA_ATSHA204_OTP_MAC14
 
-#define MVTWSI_ARMADA_DEBUG_REG0x8c
-
 /*
  * Those values and defines are taken from the Marvell U-Boot version
  * "u-boot-2013.01-2014_T3.0"
@@ -297,8 +295,6 @@ static int set_regdomain(void)
 
 int board_early_init_f(void)
 {
-   u32 i2c_debug_reg;
-
/* Configure MPP */
writel(0x, MVEBU_MPP_BASE + 0x00);
writel(0x, MVEBU_MPP_BASE + 0x04);
@@ -321,15 +317,6 @@ int board_early_init_f(void)
writel(OMNIA_GPP_OUT_ENA_LOW, MVEBU_GPIO0_BASE + 0x04);
writel(OMNIA_GPP_OUT_ENA_MID, MVEBU_GPIO1_BASE + 0x04);
 
-   /*
-* Disable I2C debug mode blocking 0x64 I2C address.
-* Note: that would be redundant once Turris Omnia migrates to DM_I2C,
-* because the mvtwsi driver includes equivalent code.
-*/
-   i2c_debug_reg = readl(MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
-   i2c_debug_reg &= ~(1<<18);
-   writel(i2c_debug_reg, MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
-
return 0;
 }
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 03/17] arm: mvebu: turris_omnia: use AHCI and SATA driver model

2019-05-02 Thread Marek Behún
Enable AHCI, SCSI and SATA for compliance with the driver model
migration.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 configs/turris_omnia_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 2ad2f6e431..5086da13a5 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -26,6 +26,8 @@ CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
+CONFIG_CMD_SATA=y
+CONFIG_CMD_SCSI=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -39,6 +41,11 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_USE_ENV_SPI_MAX_HZ=y
 CONFIG_ENV_SPI_MAX_HZ=5000
 CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_AHCI_MVEBU=y
+CONFIG_SATA=y
+CONFIG_SCSI=y
 CONFIG_SCSI_AHCI=y
 CONFIG_ATSHA204A=y
 CONFIG_DM_MMC=y
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 14/17] arm: mvebu: turris_omnia: add RESET button handling

2019-05-02 Thread Marek Behún
There is a Factory RESET button on the back side of the Turris Omnia
router. When user presses this button before powering the device up and
keeps it pressed, the microcontroller prevents the main CPU from booting
and counts how long the RESET button is being pressed (and indicates
this by lighting up front LEDs).

The idea behind this is that the user can boot the device into several
Factory RESET modes.

This patch adds support for U-Boot to read into which Factory RESET mode
the user booted the device. The value is an integer stored into the
omnia_reset environment variable. It is 0 if the button was not pressed
at all during power up, otherwise it is the number identifying the
Factory RESET mode.

This patch also changes bootcmd to a special hardcoded value if Factory
RESET button was pressed during device powerup. This special bootcmd
value sets the colors of all the LEDs on the front panel to green and
then tries to load the rescue image from the SPI flash memory and boot
it.

Signed-off-by: Marek Behún 
---
 arch/arm/mach-mvebu/Kconfig  |  1 +
 board/CZ.NIC/turris_omnia/turris_omnia.c | 38 
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index fc29c3b084..a832e1dc8c 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -116,6 +116,7 @@ config TARGET_DB_88F6820_AMC
 config TARGET_TURRIS_OMNIA
bool "Support Turris Omnia"
select 88F6820
+   select BOARD_LATE_INIT
select DM_I2C
select I2C_MUX
select I2C_MUX_PCA954x
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index af43ee23d9..ad6e29021e 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -328,6 +328,43 @@ static int set_regdomain(void)
printf("Regdomain set to %s\n", rd);
return env_set("regdomain", rd);
 }
+
+/*
+ * default factory reset bootcommand on Omnia first sets all the front LEDs
+ * to green and then tries to load the rescue image from SPI flash memory and
+ * boot it
+ */
+#define OMNIA_FACTORY_RESET_BOOTCMD \
+   "i2c dev 2; " \
+   "i2c mw 0x2a.1 0x3 0x1c 1; " \
+   "i2c mw 0x2a.1 0x4 0x1c 1; " \
+   "mw.l 0x0100 0x00ff000c; " \
+   "i2c write 0x0100 0x2a.1 0x5 4 -s; " \
+   "setenv bootargs \"$bootargs omniarescue=$omnia_reset\"; " \
+   "sf probe; " \
+   "sf read 0x100 0x10 0x70; " \
+   "bootm 0x100; " \
+   "bootz 0x100"
+
+static void handle_reset_button(void)
+{
+   int ret;
+   u8 reset_status;
+
+   ret = omnia_mcu_read(CMD_GET_RESET, &reset_status, 1);
+   if (ret) {
+   printf("omnia_mcu_read failed: %i, reset status unknown!\n",
+  ret);
+   return;
+   }
+
+   env_set_ulong("omnia_reset", reset_status);
+
+   if (reset_status) {
+   printf("RESET button was pressed, overwriting bootcmd!\n");
+   env_set("bootcmd", OMNIA_FACTORY_RESET_BOOTCMD);
+   }
+}
 #endif
 
 int board_early_init_f(void)
@@ -373,6 +410,7 @@ int board_late_init(void)
 {
 #ifndef CONFIG_SPL_BUILD
set_regdomain();
+   handle_reset_button();
 #endif
 
return 0;
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 15/17] i2c: mvtwsi: fix reading status register after interrupt

2019-05-02 Thread Marek Behún
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.

On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.

My theory is that the controller does approximately this:
  1. sets interrupt flag in control register,
  2. sets the value of status register,
  3. causes an interrupt

In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.

The bug does not appear if I add a small delay before reading status
register.

Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.

Signed-off-by: Marek Behún 
Reviewed-by: Heiko Schocher 
Reviewed-by: Stefan Roese 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/i2c/mvtwsi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 74ac0a4aa7..0a2dafcec6 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -271,6 +271,17 @@ static int twsi_wait(struct mvtwsi_registers *twsi, int 
expected_status,
do {
control = readl(&twsi->control);
if (control & MVTWSI_CONTROL_IFLG) {
+   /*
+* On Armada 38x it seems that the controller works as
+* if it first set the MVTWSI_CONTROL_IFLAG in the
+* control register and only after that it changed the
+* status register.
+* This sometimes caused weird bugs which only appeared
+* on selected I2C speeds and even then only sometimes.
+* We therefore add here a simple ndealy(100), which
+* seems to fix this weird bug.
+*/
+   ndelay(100);
status = readl(&twsi->status);
if (status == expected_status)
return 0;
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 05/17] arm: mvebu: turris_omnia: move I2C dependencies to Kconfig

2019-05-02 Thread Marek Behún
The I2C dependencies are defined in include/configs/turris_omnia.h,
because Turris Omnia won't boot correctly without I2C support.

Move these dependencies to Kconfig, so that they are selected if Turris
Omnia is selected as target.

Signed-off-by: Marek Behún 
Reviewed-by: Heiko Schocher 
Reviewed-by: Stefan Roese 
---
 arch/arm/mach-mvebu/Kconfig|  5 +
 include/configs/turris_omnia.h | 11 ---
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index f99bd3bf65..2bf829d10a 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -116,6 +116,11 @@ config TARGET_DB_88F6820_AMC
 config TARGET_TURRIS_OMNIA
bool "Support Turris Omnia"
select 88F6820
+   select DM_I2C
+   select I2C_MUX
+   select I2C_MUX_PCA954x
+   select SPL_I2C_MUX
+   select SYS_I2C_MVTWSI
 
 config TARGET_TURRIS_MOX
bool "Support Turris Mox"
diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h
index 5e692e6829..5a7539c9be 100644
--- a/include/configs/turris_omnia.h
+++ b/include/configs/turris_omnia.h
@@ -18,17 +18,6 @@
  */
 #define CONFIG_SYS_TCLK25000   /* 250MHz */
 
-/*
- * Commands configuration
- */
-
-/* I2C support */
-#define CONFIG_DM_I2C
-#define CONFIG_I2C_MUX
-#define CONFIG_I2C_MUX_PCA954x
-#define CONFIG_SPL_I2C_MUX
-#define CONFIG_SYS_I2C_MVTWSI
-
 /* USB/EHCI configuration */
 #define CONFIG_EHCI_IS_TDI
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 16/17] arm: mvebu: turris_omnia: add GPIO support to defconfig

2019-05-02 Thread Marek Behún
Add support for the gpio command and driver for the I2C connected
pca9538 controller, to be able to determine if SFP module is present in
the Turris Omnia router.

Signed-off-by: Marek Behún 
---
 configs/turris_omnia_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 5a09dc3033..bba14bbcaf 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -23,6 +23,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 # CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
@@ -47,6 +48,10 @@ CONFIG_AHCI_MVEBU=y
 CONFIG_SATA=y
 CONFIG_SCSI=y
 CONFIG_SCSI_AHCI=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_DM_GPIO=y
+# CONFIG_MVEBU_GPIO is not set
+CONFIG_DM_PCA953X=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_MV=y
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 17/17] arm: mvebu: turris_omnia: enable defconfig options needed by vendor

2019-05-02 Thread Marek Behún
This options will be enabled by default by CZ.NIC shipped U-Boot. Enable
them in defconfig.

Signed-off-by: Marek Behún 
---
 configs/turris_omnia_defconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index bba14bbcaf..f3ce56f6d7 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -22,6 +22,15 @@ CONFIG_MISC_INIT_R=y
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
+CONFIG_FIT=y
+CONFIG_FIT_ENABLE_SHA256_SUPPORT=y
+# CONFIG_FIT_SIGNATURE is not set
+CONFIG_FIT_VERBOSE=y
+# CONFIG_FIT_BEST_MATCH is not set
+CONFIG_CMD_LZMADEC=y
+CONFIG_CMD_AES=y
+CONFIG_CMD_HASH=y
+CONFIG_CMD_SHA1SUM=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 10/17] arm: mvebu: turris_omnia: refactor more code

2019-05-02 Thread Marek Behún
Refactor RAM size reading from EEPROM in preparation for next patch.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 58 
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 640ee2a2a3..8571541b0a 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -236,6 +236,31 @@ static bool omnia_read_eeprom(struct omnia_eeprom *oep)
return true;
 }
 
+static int omnia_get_ram_size_gb(void)
+{
+   static int ram_size;
+   struct omnia_eeprom oep;
+
+   if (!ram_size) {
+   /* Get the board config from EEPROM */
+   if (omnia_read_eeprom(&oep)) {
+   debug("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
+
+   if (oep.ramsize == 0x2)
+   ram_size = 2;
+   else
+   ram_size = 1;
+   } else {
+   /* Hardcoded fallback */
+   puts("Memory config from EEPROM read failed!\n");
+   puts("Falling back to default 1 GiB!\n");
+   ram_size = 1;
+   }
+   }
+
+   return ram_size;
+}
+
 /*
  * Define the DDR layout / topology here in the board file. This will
  * be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -287,37 +312,10 @@ static struct mv_ddr_topology_map board_topology_map_2g = 
{
 
 struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
 {
-   static int mem;
-   struct omnia_eeprom oep;
-
-   /* Get the board config from EEPROM */
-   if (!mem) {
-   if (!omnia_read_eeprom(&oep))
-   goto out;
-
-   printf("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
-
-   if (oep.ramsize == 0x2)
-   mem = 2;
-   else
-   mem = 1;
-   }
-
-out:
-   /* Hardcoded fallback */
-   if (mem == 0) {
-   puts("WARNING: Memory config from EEPROM read failed.\n");
-   puts("Falling back to default 1GiB map.\n");
-   mem = 1;
-   }
-
-   /* Return the board topology as defined in the board code */
-   if (mem == 1)
-   return &board_topology_map_1g;
-   if (mem == 2)
+   if (omnia_get_ram_size_gb() == 2)
return &board_topology_map_2g;
-
-   return &board_topology_map_1g;
+   else
+   return &board_topology_map_1g;
 }
 
 #ifndef CONFIG_SPL_BUILD
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 11/17] arm: mvebu: turris_omnia: print board info as Turris Mox

2019-05-02 Thread Marek Behún
Unify the way how Omnia and Mox print board information (RAM size and
serial number).

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 8571541b0a..54efd2d4c9 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -426,11 +426,13 @@ int checkboard(void)
}
 
 out:
+   printf("Turris Omnia:\n");
+   printf("  RAM size: %i MiB\n", omnia_get_ram_size_gb() * 1024);
if (err)
-   printf("Board: Turris Omnia (ver N/A). SN: N/A\n");
+   printf("  Serial Number: unknown\n");
else
-   printf("Board: Turris Omnia SNL %08X%08X\n",
-  be32_to_cpu(version_num), be32_to_cpu(serial_num));
+   printf("  Serial Number: %08X%08X\n", be32_to_cpu(version_num),
+  be32_to_cpu(serial_num));
 
return 0;
 }
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 08/17] arm: mvebu: turris_omnia: fix checkpatch warnings

2019-05-02 Thread Marek Behún
Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 6b8fa53c98..d4fb89f15f 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -290,12 +290,12 @@ static struct mv_ddr_topology_map board_topology_map_2g = 
{
 
 struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
 {
-   static int mem = 0;
+   static int mem;
struct omnia_eeprom oep;
 
/* Get the board config from EEPROM */
-   if (mem == 0) {
-   if(!omnia_read_eeprom(&oep))
+   if (!mem) {
+   if (!omnia_read_eeprom(&oep))
goto out;
 
printf("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
@@ -368,7 +368,7 @@ int board_early_init_f(void)
 
 int board_init(void)
 {
-   /* adress of boot parameters */
+   /* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
 
 #ifndef CONFIG_SPL_BUILD
@@ -391,9 +391,9 @@ int board_late_init(void)
 #ifdef CONFIG_ATSHA204A
 static struct udevice *get_atsha204a_dev(void)
 {
-   static struct udevice *dev = NULL;
+   static struct udevice *dev;
 
-   if (dev != NULL)
+   if (dev)
return dev;
 
if (uclass_get_device_by_name(UCLASS_MISC, "atsha204a@64", &dev)) {
@@ -420,13 +420,13 @@ int checkboard(void)
 
err = atsha204a_read(dev, ATSHA204A_ZONE_OTP, false,
 OMNIA_ATSHA204_OTP_VERSION,
-(u8 *) &version_num);
+(u8 *)&version_num);
if (err)
goto out;
 
err = atsha204a_read(dev, ATSHA204A_ZONE_OTP, false,
 OMNIA_ATSHA204_OTP_SERIAL,
-(u8 *) &serial_num);
+(u8 *)&serial_num);
if (err)
goto out;
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 13/17] arm: mvebu: turris_omnia: fix regdomain env var setting

2019-05-02 Thread Marek Behún
The regdomain environment variable is set according to value read from
EEPROM. This has to be done in board_late_init, after the environment
variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig
for the Turris Omnia target.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index b073a985a5..af43ee23d9 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -364,7 +364,6 @@ int board_init(void)
 
 #ifndef CONFIG_SPL_BUILD
disable_mcu_watchdog();
-   set_regdomain();
 #endif
 
return 0;
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 06/17] arm: mvebu: turris_omnia: add SCSI as boot target

2019-05-02 Thread Marek Behún
If SCSI is enabled, U-Boot should try to boot also from SCSI device on
Turris Omnia.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 include/configs/turris_omnia.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h
index 5a7539c9be..5b9639e050 100644
--- a/include/configs/turris_omnia.h
+++ b/include/configs/turris_omnia.h
@@ -90,9 +90,16 @@
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
 
+#ifdef CONFIG_SCSI
+#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0)
+#else
+#define BOOT_TARGET_DEVICES_SCSI(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
BOOT_TARGET_DEVICES_MMC(func) \
BOOT_TARGET_DEVICES_USB(func) \
+   BOOT_TARGET_DEVICES_SCSI(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 12/17] arm: mvebu: turris_*: remove watchdog include

2019-05-02 Thread Marek Behún
Since board watchdog is now unified and not handled in board files,
remove the unnecessary includes.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 4 
 board/CZ.NIC/turris_omnia/turris_omnia.c | 4 
 2 files changed, 8 deletions(-)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 8a4872343b..3818e3752a 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -16,10 +16,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_WDT_ARMADA_37XX
-#include 
-#endif
-
 #include "mox_sp.h"
 
 #define MAX_MOX_MODULES10
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 54efd2d4c9..b073a985a5 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -20,10 +20,6 @@
 #include 
 # include 
 
-#ifdef CONFIG_WDT_ORION
-# include 
-#endif
-
 #include "../drivers/ddr/marvell/a38x/ddr3_init.h"
 #include <../serdes/a38x/high_speed_env_spec.h>
 
-- 
2.21.0

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


[U-Boot] [PATCH u-boot-marvell v3 07/17] arm: mvebu: turris_omnia: refactor I2C accessing code

2019-05-02 Thread Marek Behún
Refactor code which accesses the microcontroller and EEPROM via I2C.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 205 ---
 1 file changed, 109 insertions(+), 96 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 055ebad000..6b8fa53c98 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -32,18 +32,25 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define OMNIA_I2C_EEPROM_DM_NAME   "i2c@11000->i2cmux@70->i2c@0"
-#define OMNIA_I2C_EEPROM   0x54
-#define OMNIA_I2C_EEPROM_CONFIG_ADDR   0x0
-#define OMNIA_I2C_EEPROM_ADDRLEN   2
+#define OMNIA_I2C_BUS_NAME "i2c@11000->i2cmux@70->i2c@0"
+
+#define OMNIA_I2C_MCU_CHIP_ADDR0x2a
+#define OMNIA_I2C_MCU_CHIP_LEN 1
+
+#define OMNIA_I2C_EEPROM_CHIP_ADDR 0x54
+#define OMNIA_I2C_EEPROM_CHIP_LEN  2
 #define OMNIA_I2C_EEPROM_MAGIC 0x0341a034
 
-#define OMNIA_I2C_MCU_DM_NAME  "i2c@11000->i2cmux@70->i2c@0"
-#define OMNIA_I2C_MCU_ADDR_STATUS  0x1
-#define OMNIA_I2C_MCU_SATA 0x20
-#define OMNIA_I2C_MCU_CARDDET  0x10
-#define OMNIA_I2C_MCU  0x2a
-#define OMNIA_I2C_MCU_WDT_ADDR 0x0b
+enum mcu_commands {
+   CMD_GET_STATUS_WORD = 0x01,
+   CMD_GET_RESET   = 0x09,
+   CMD_WATCHDOG_STATE  = 0x0b,
+};
+
+enum status_word_bits {
+   CARD_DET_STSBIT = 0x0010,
+   MSATA_IND_STSBIT= 0x0020,
+};
 
 #define OMNIA_ATSHA204_OTP_VERSION 0
 #define OMNIA_ATSHA204_OTP_SERIAL  1
@@ -85,48 +92,97 @@ static struct serdes_map board_serdes_map_sata[] = {
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0}
 };
 
-static bool omnia_detect_sata(void)
+static struct udevice *omnia_get_i2c_chip(const char *name, uint addr,
+ uint offset_len)
 {
struct udevice *bus, *dev;
-   int ret, retry = 3;
-   u16 mode;
-
-   puts("SERDES0 card detect: ");
+   int ret;
 
-   if (uclass_get_device_by_name(UCLASS_I2C, OMNIA_I2C_MCU_DM_NAME, &bus)) 
{
-   puts("Cannot find MCU bus!\n");
-   return false;
+   ret = uclass_get_device_by_name(UCLASS_I2C, OMNIA_I2C_BUS_NAME, &bus);
+   if (ret) {
+   printf("Cannot get I2C bus %s: uclass_get_device_by_name 
failed: %i\n",
+  OMNIA_I2C_BUS_NAME, ret);
+   return NULL;
}
 
-   ret = i2c_get_chip(bus, OMNIA_I2C_MCU, 1, &dev);
+   ret = i2c_get_chip(bus, addr, offset_len, &dev);
if (ret) {
-   puts("Cannot get MCU chip!\n");
-   return false;
+   printf("Cannot get %s I2C chip: i2c_get_chip failed: %i\n",
+  name, ret);
+   return NULL;
}
 
-   for (; retry > 0; --retry) {
-   ret = dm_i2c_read(dev, OMNIA_I2C_MCU_ADDR_STATUS, (uchar *) 
&mode, 2);
-   if (!ret)
-   break;
-   }
+   return dev;
+}
+
+static int omnia_mcu_read(u8 cmd, void *buf, int len)
+{
+   struct udevice *chip;
+
+   chip = omnia_get_i2c_chip("MCU", OMNIA_I2C_MCU_CHIP_ADDR,
+ OMNIA_I2C_MCU_CHIP_LEN);
+   if (!chip)
+   return -ENODEV;
+
+   return dm_i2c_read(chip, cmd, buf, len);
+}
 
-   if (!retry) {
-   puts("I2C read failed! Default PEX\n");
+#ifndef CONFIG_SPL_BUILD
+static int omnia_mcu_write(u8 cmd, const void *buf, int len)
+{
+   struct udevice *chip;
+
+   chip = omnia_get_i2c_chip("MCU", OMNIA_I2C_MCU_CHIP_ADDR,
+ OMNIA_I2C_MCU_CHIP_LEN);
+   if (!chip)
+   return -ENODEV;
+
+   return dm_i2c_write(chip, cmd, buf, len);
+}
+
+static bool disable_mcu_watchdog(void)
+{
+   int ret;
+
+   puts("Disabling MCU watchdog... ");
+
+   ret = omnia_mcu_write(CMD_WATCHDOG_STATE, "\x00", 1);
+   if (ret) {
+   printf("omnia_mcu_write failed: %i\n", ret);
return false;
}
 
-   if (!(mode & OMNIA_I2C_MCU_CARDDET)) {
-   puts("NONE\n");
+   puts("disabled\n");
+
+   return true;
+}
+#endif
+
+static bool omnia_detect_sata(void)
+{
+   int ret;
+   u16 stsword;
+
+   puts("MiniPCIe/mSATA card detection... ");
+
+   ret = omnia_mcu_read(CMD_GET_STATUS_WORD, &stsword, sizeof(stsword));
+   if (ret) {
+   printf("omnia_mcu_read failed: %i, defaulting to MiniPCIe 
card\n",
+  ret);
return false;
}
 
-   if (mode & OMNIA_I2C_MCU_SATA) {
-   puts("SATA\n");
-   return true;
-   } else {
-   puts("PEX\n");
+   if (!(stsword & CARD_DET_STSBIT)) {
+   puts("none\n");
return false;

[U-Boot] [PATCH u-boot-marvell v3 09/17] arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig

2019-05-02 Thread Marek Behún
This driver is required for Turris Omnia to read ethernet addresses.
Move the dependency from turris_omnia_defconfig to Kconfig.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
---
 arch/arm/mach-mvebu/Kconfig  |  1 +
 board/CZ.NIC/turris_omnia/turris_omnia.c | 11 ---
 configs/turris_omnia_defconfig   |  1 -
 3 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 2bf829d10a..fc29c3b084 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -121,6 +121,7 @@ config TARGET_TURRIS_OMNIA
select I2C_MUX_PCA954x
select SPL_I2C_MUX
select SYS_I2C_MVTWSI
+   select ATSHA204A
 
 config TARGET_TURRIS_MOX
bool "Support Turris Mox"
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index d4fb89f15f..640ee2a2a3 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -18,10 +18,7 @@
 #include 
 #include 
 #include 
-
-#ifdef CONFIG_ATSHA204A
 # include 
-#endif
 
 #ifdef CONFIG_WDT_ORION
 # include 
@@ -388,7 +385,6 @@ int board_late_init(void)
return 0;
 }
 
-#ifdef CONFIG_ATSHA204A
 static struct udevice *get_atsha204a_dev(void)
 {
static struct udevice *dev;
@@ -403,14 +399,12 @@ static struct udevice *get_atsha204a_dev(void)
 
return dev;
 }
-#endif
 
 int checkboard(void)
 {
u32 version_num, serial_num;
int err = 1;
 
-#ifdef CONFIG_ATSHA204A
struct udevice *dev = get_atsha204a_dev();
 
if (dev) {
@@ -434,8 +428,6 @@ int checkboard(void)
}
 
 out:
-#endif
-
if (err)
printf("Board: Turris Omnia (ver N/A). SN: N/A\n");
else
@@ -458,7 +450,6 @@ static void increment_mac(u8 *mac)
 
 int misc_init_r(void)
 {
-#ifdef CONFIG_ATSHA204A
int err;
struct udevice *dev = get_atsha204a_dev();
u8 mac0[4], mac1[4], mac[6];
@@ -503,8 +494,6 @@ int misc_init_r(void)
eth_env_set_enetaddr("eth2addr", mac);
 
 out:
-#endif
-
return 0;
 }
 
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 5086da13a5..5a09dc3033 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -47,7 +47,6 @@ CONFIG_AHCI_MVEBU=y
 CONFIG_SATA=y
 CONFIG_SCSI=y
 CONFIG_SCSI_AHCI=y
-CONFIG_ATSHA204A=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_MV=y
-- 
2.21.0

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


[U-Boot] [PATCH] board: toradex: drop support.arm maintainer email

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Drop Toradex ARM Support  from maintainer email
list as this just clogs our support ticketing system.

Signed-off-by: Marcel Ziswiler 
Acked-by: Stefan Agner 

---

 board/toradex/colibri-imx6ull/MAINTAINERS | 1 -
 board/toradex/colibri_imx7/MAINTAINERS| 1 -
 2 files changed, 2 deletions(-)

diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS 
b/board/toradex/colibri-imx6ull/MAINTAINERS
index 7cda555984..626c1f94f9 100644
--- a/board/toradex/colibri-imx6ull/MAINTAINERS
+++ b/board/toradex/colibri-imx6ull/MAINTAINERS
@@ -1,6 +1,5 @@
 Colibri iMX6ULL
 M: Stefan Agner 
-M: Toradex ARM Support 
 W: http://developer.toradex.com/software/linux/linux-software
 W: https://www.toradex.com/community
 S: Maintained
diff --git a/board/toradex/colibri_imx7/MAINTAINERS 
b/board/toradex/colibri_imx7/MAINTAINERS
index f55f8045f4..cd0f9c9b2d 100644
--- a/board/toradex/colibri_imx7/MAINTAINERS
+++ b/board/toradex/colibri_imx7/MAINTAINERS
@@ -1,6 +1,5 @@
 Colibri iMX7
 M: Stefan Agner 
-M: Toradex ARM Support 
 W: http://developer.toradex.com/software/linux/linux-software
 W: https://www.toradex.com/community
 S: Maintained
-- 
2.20.1

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


[U-Boot] [PATCH v6 1/2] imx: fix building for i.mx8 without spl

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Building with Travis CI complained and stopped with the following error:
+cc1: fatal error: opening output file spl/u-boot-spl.cfgout: No such
file or directory
+compilation terminated.

This fixes commit caceb739ea07 ("imx: build flash.bin for i.MX8") which
took SPL being enabled on i.MX8 for granted.

Reported-by: Stefano Babic 
Signed-off-by: Marcel Ziswiler 
Reviewed-by: Peng Fan 

---

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

 arch/arm/mach-imx/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 37675d0558..6531c67fc6 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -107,7 +107,9 @@ IMX_CONFIG = $(CONFIG_IMX_CONFIG:"%"=%)
 ifeq ($(CONFIG_ARCH_IMX8), y)
 CNTR_DEPFILES := $(srctree)/tools/imx_cntr_image.sh
 IMAGE_TYPE := imx8image
+ifeq ($(CONFIG_SPL_BUILD),y)
 SPL_DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o 
spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG); if [ -f spl/u-boot-spl.cfgout 
]; then $(CNTR_DEPFILES) spl/u-boot-spl.cfgout; echo $$?; fi)
+endif
 DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o u-boot-dtb.cfgout 
$(srctree)/$(IMX_CONFIG); if [ -f u-boot-dtb.cfgout ]; then $(CNTR_DEPFILES) 
u-boot-dtb.cfgout; echo $$?; fi)
 else ifeq ($(CONFIG_ARCH_IMX8M), y)
 IMAGE_TYPE := imx8mimage
-- 
2.20.1

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


[U-Boot] [PATCH v6 2/2] board: toradex: add colibri imx8qxp 2gb wb it v1.0b module support

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

This commit adds initial support for the Toradex Colibri iMX8QXP 2GB WB
IT V1.0B module. Unlike the V1.0A early access samples exclusively
booting from SD card, they are now strapped to boot from eFuses which
are factory fused to properly boot from their on-module eMMC. U-Boot
supports either booting from the on-module eMMC or may be used for
recovery purpose using the universal update utility (uuu) aka mfgtools
3.0.

Functionality wise the following is known to be working:
- eMMC and MMC/SD card
- Ethernet
- GPIOs
- I2C

Unfortunately, there is no USB functionality for the i.MX 8QXP as of
yet.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Igor Opaniuk 

---

Changes in v6:
- Use firmware-imx-8.0 matching NXP's sumo-4.14.78-1.0.0_ga BSP as
  suggested by Max during review of Apalis iMX8QM.
- Drop anyway commented out board_gpio_init() stuff.
- Drop Qualcomm (formwerly Atheros) AR8031 specific board_phy_config()
  stuff not applicable to the Micrel PHY we are using as suggested by
  Max during review of Apalis iMX8QM.

Changes in v5:
- Keep alphabetical order of device trees in Makefile.
- Order targets in Kconfig alphabetically.
- Fix indentation in SPDX.
- Remove stale includes from board file.
- Take into account ahab-container being platform specific.
- Use vidargs instead of multiple discrete video= in configuration.
- Fix console baudrate specification.
- Remove redundant CONFIG_SYS_MMC_ENV_DEV define and add some clarifying
  comment.
- Fix product name being Colibri iMX8X in a comment.
- Remove obsolete CONFIG_NR_DRAM_BANKS.

Changes in v4:
- Fixed SPDX as well as using SZ_ macros where applicable as suggested
  by Igor.
- Fixed superfluous trailing line continuation introduced by commit
  0d331c035a09 ("imx: support i.MX8QM MEK board") in the Makefile plus
  sorted stuff alphabetically again.
- Applied changes similar to commit 3b9ac5415084 ("imx: 8qxp_mek: fix
  fdt_file and console"). However, note that using ${baudrate} in
  console= like that won't actually work!
- Applied changes similar to commit e5b8f7e665aa ("imx8qxp: mek: enable
  dm-spl for pm").

Changes in v3:
- Added Igor's reviewed-by tag.

Changes in v2:
- Changed imx-atf git clone command to include initial branch
  information as suggested by Igor.
- Sorted board file includes alphabetically as suggested by Igor.
- Got rid of SPL configuration in legacy header file as suggested by
  Igor and the whole use of SPL on i.MX 8X anyway neither works well
  nor makes any much sense at all.

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi  | 117 +++
 arch/arm/dts/fsl-imx8qxp-colibri.dts  | 328 ++
 arch/arm/mach-imx/imx8/Kconfig|  12 +-
 board/toradex/colibri-imx8qxp/Kconfig |  30 ++
 board/toradex/colibri-imx8qxp/MAINTAINERS |   9 +
 board/toradex/colibri-imx8qxp/Makefile|   6 +
 board/toradex/colibri-imx8qxp/README  |  66 
 .../toradex/colibri-imx8qxp/colibri-imx8qxp.c | 160 +
 board/toradex/colibri-imx8qxp/imximage.cfg|  24 ++
 configs/colibri-imx8qxp_defconfig |  53 +++
 include/configs/colibri-imx8qxp.h | 210 +++
 12 files changed, 1014 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri.dts
 create mode 100644 board/toradex/colibri-imx8qxp/Kconfig
 create mode 100644 board/toradex/colibri-imx8qxp/MAINTAINERS
 create mode 100644 board/toradex/colibri-imx8qxp/Makefile
 create mode 100644 board/toradex/colibri-imx8qxp/README
 create mode 100644 board/toradex/colibri-imx8qxp/colibri-imx8qxp.c
 create mode 100644 board/toradex/colibri-imx8qxp/imximage.cfg
 create mode 100644 configs/colibri-imx8qxp_defconfig
 create mode 100644 include/configs/colibri-imx8qxp.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e56a39e0b1..598dc213e3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -576,8 +576,9 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
 dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
 
 dtb-$(CONFIG_ARCH_IMX8) += \
-   fsl-imx8qxp-mek.dtb \
fsl-imx8qm-mek.dtb \
+   fsl-imx8qxp-colibri.dtb \
+   fsl-imx8qxp-mek.dtb
 
 dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb
 
diff --git a/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi 
b/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
new file mode 100644
index 00..5b061f94ba
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+&{/imx8qx-pm} {
+
+   u-boot,dm-spl;
+};
+
+&mu {
+   u-boot,dm-spl;
+};
+
+&clk {
+   u-boot,dm-spl;
+};
+
+&iomuxc {
+   u-boot,dm-spl;
+};
+
+&pd_lsio {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio0 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio1 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio2 {
+   u-bo

[U-Boot] [PATCH v6 0/2] colibri imx8qxp 2gb wb it v1.0b module support

2019-05-02 Thread Marcel Ziswiler

This series fixes building for i.MX8 without SPL and adds support for
more lpuart instances, cleans-up and extends the Toradex SKU handling
and last but not least introduces support for the Toradex Colibri
iMX8QXP 2GB WB IT V1.0B module.

This series is available together with the last few clean-up patches
on our git server [1] as well.

[1] http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v6:
- Use firmware-imx-8.0 matching NXP's sumo-4.14.78-1.0.0_ga BSP as
  suggested by Max during review of Apalis iMX8QM.
- Drop anyway commented out board_gpio_init() stuff.
- Drop Qualcomm (formwerly Atheros) AR8031 specific board_phy_config()
  stuff not applicable to the Micrel PHY we are using as suggested by
  Max during review of Apalis iMX8QM.

Changes in v5:
- Keep alphabetical order of device trees in Makefile.
- Order targets in Kconfig alphabetically.
- Fix indentation in SPDX.
- Remove stale includes from board file.
- Take into account ahab-container being platform specific.
- Use vidargs instead of multiple discrete video= in configuration.
- Fix console baudrate specification.
- Remove redundant CONFIG_SYS_MMC_ENV_DEV define and add some clarifying
  comment.
- Fix product name being Colibri iMX8X in a comment.
- Remove obsolete CONFIG_NR_DRAM_BANKS.

Changes in v4:
- Fixed SPDX as well as using SZ_ macros where applicable as suggested
  by Igor.
- Fixed superfluous trailing line continuation introduced by commit
  0d331c035a09 ("imx: support i.MX8QM MEK board") in the Makefile plus
  sorted stuff alphabetically again.
- Applied changes similar to commit 3b9ac5415084 ("imx: 8qxp_mek: fix
  fdt_file and console"). However, note that using ${baudrate} in
  console= like that won't actually work!
- Applied changes similar to commit e5b8f7e665aa ("imx8qxp: mek: enable
  dm-spl for pm").

Changes in v3:
- Added Igor's reviewed-by tag.

Changes in v2:
- Changed imx-atf git clone command to include initial branch
  information as suggested by Igor.
- Sorted board file includes alphabetically as suggested by Igor.
- Got rid of SPL configuration in legacy header file as suggested by
  Igor and the whole use of SPL on i.MX 8X anyway neither works well
  nor makes any much sense at all.

Marcel Ziswiler (2):
  imx: fix building for i.mx8 without spl
  board: toradex: add colibri imx8qxp 2gb wb it v1.0b module support

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi  | 117 +++
 arch/arm/dts/fsl-imx8qxp-colibri.dts  | 328 ++
 arch/arm/mach-imx/Makefile|   2 +
 arch/arm/mach-imx/imx8/Kconfig|  12 +-
 board/toradex/colibri-imx8qxp/Kconfig |  30 ++
 board/toradex/colibri-imx8qxp/MAINTAINERS |   9 +
 board/toradex/colibri-imx8qxp/Makefile|   6 +
 board/toradex/colibri-imx8qxp/README  |  66 
 .../toradex/colibri-imx8qxp/colibri-imx8qxp.c | 160 +
 board/toradex/colibri-imx8qxp/imximage.cfg|  24 ++
 configs/colibri-imx8qxp_defconfig |  53 +++
 include/configs/colibri-imx8qxp.h | 210 +++
 13 files changed, 1016 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri.dts
 create mode 100644 board/toradex/colibri-imx8qxp/Kconfig
 create mode 100644 board/toradex/colibri-imx8qxp/MAINTAINERS
 create mode 100644 board/toradex/colibri-imx8qxp/Makefile
 create mode 100644 board/toradex/colibri-imx8qxp/README
 create mode 100644 board/toradex/colibri-imx8qxp/colibri-imx8qxp.c
 create mode 100644 board/toradex/colibri-imx8qxp/imximage.cfg
 create mode 100644 configs/colibri-imx8qxp_defconfig
 create mode 100644 include/configs/colibri-imx8qxp.h

-- 
2.20.1

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


[U-Boot] [PATCH v2 1/6] arm: dts: imx8qm: add lpuart1, lpuart2, lpuart3, lpuart4

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Add support for lpuart1, lpuart2, lpuart3 and lpuart4.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2: None

 arch/arm/dts/fsl-imx8qm.dtsi | 80 
 1 file changed, 80 insertions(+)

diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
index b39c40bd98..db01959990 100644
--- a/arch/arm/dts/fsl-imx8qm.dtsi
+++ b/arch/arm/dts/fsl-imx8qm.dtsi
@@ -22,6 +22,10 @@
ethernet0 = &fec1;
ethernet1 = &fec2;
serial0 = &lpuart0;
+   serial1 = &lpuart1;
+   serial2 = &lpuart2;
+   serial3 = &lpuart3;
+   serial4 = &lpuart4;
mmc0 = &usdhc1;
mmc1 = &usdhc2;
mmc2 = &usdhc3;
@@ -193,6 +197,30 @@
power-domains = <&pd_dma>;
wakeup-irq = <345>;
};
+   pd_dma_lpuart1: PD_DMA_UART1 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_dma>;
+   wakeup-irq = <346>;
+   };
+   pd_dma_lpuart2: PD_DMA_UART2 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_dma>;
+   wakeup-irq = <347>;
+   };
+   pd_dma_lpuart3: PD_DMA_UART3 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_dma>;
+   wakeup-irq = <348>;
+   };
+   pd_dma_lpuart4: PD_DMA_UART4 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_dma>;
+   wakeup-irq = <349>;
+   };
};
};
 
@@ -297,6 +325,58 @@
status = "disabled";
};
 
+   lpuart1: serial@5a07 {
+   compatible = "fsl,imx8qm-lpuart";
+   reg = <0x0 0x5a07 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&clk IMX8QM_UART1_CLK>,
+<&clk IMX8QM_UART1_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_UART1_CLK>;
+   assigned-clock-rates = <8000>;
+   power-domains = <&pd_dma_lpuart1>;
+   status = "disabled";
+   };
+
+   lpuart2: serial@5a08 {
+   compatible = "fsl,imx8qm-lpuart";
+   reg = <0x0 0x5a08 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&clk IMX8QM_UART2_CLK>,
+<&clk IMX8QM_UART2_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_UART2_CLK>;
+   assigned-clock-rates = <8000>;
+   power-domains = <&pd_dma_lpuart2>;
+   status = "disabled";
+   };
+
+   lpuart3: serial@5a09 {
+   compatible = "fsl,imx8qm-lpuart";
+   reg = <0x0 0x5a09 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&clk IMX8QM_UART3_CLK>,
+<&clk IMX8QM_UART3_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_UART3_CLK>;
+   assigned-clock-rates = <8000>;
+   power-domains = <&pd_dma_lpuart3>;
+   status = "disabled";
+   };
+
+   lpuart4: serial@5a0a {
+   compatible = "fsl,imx8qm-lpuart";
+   reg = <0x0 0x5a0a 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&clk IMX8QM_UART4_CLK>,
+<&clk IMX8QM_UART4_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_UART4_CLK>;
+   assigned-clock-rates = <8000>;
+   power-domains = <&pd_dma_lpuart4>;
+   status = "disabled";
+   };
+
usdhc1: usdhc@5b01 {
compatible = "fsl,imx8qm-usdhc", "fsl,imx6sl-usdhc";
interrupt-parent = <&gic>;
-- 
2.20.1

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


[U-Boot] [PATCH v2 0/6] apalis imx8qm 4gb wb it v1.0b module support

2019-05-02 Thread Marcel Ziswiler

This series adds support for more lpuart instances, support for i2c0,
i2c1, i2c2, i2c3, i2c4, fixes support for uSDHC2, fixes CPU frequency
reporting, fixes fuse driver and last but not least introduces support
for the Toradex Apalis iMX8QM 4GB WB IT V1.0B module.

This series is available together with the last few clean-up patches
and the Colibri iMX8QXP patch series on our git server [1] as well.

[1] http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v2:
- Use firmware-imx-8.0 matching NXP's sumo-4.14.78-1.0.0_ga BSP as
  suggested by Max.
- Drop Qualcomm (formwerly Atheros) AR8031 specific board_phy_config()
  stuff not applicable to the Micrel PHY we are using as suggested by Max.
- Drop CONFIG_FEC_XCV_TYPE in favour of device tree configuration therof
  as suggested by Max.

Marcel Ziswiler (6):
  arm: dts: imx8qm: add lpuart1, lpuart2, lpuart3, lpuart4
  arm: dts: imx8qm: add support for i2c0, i2c1, i2c2, i2c3 and i2c4
  clk: imx8qm: fix usdhc2 clocks
  imx8qm: fix cpu frequency reporting
  imx8: fuse: fix fuse driver
  board: toradex: add apalis imx8qm 4gb wb it v1.0b module support

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi  | 128 
 arch/arm/dts/fsl-imx8qm-apalis.dts  | 615 
 arch/arm/dts/fsl-imx8qm.dtsi| 155 +
 arch/arm/mach-imx/imx8/Kconfig  |   6 +
 arch/arm/mach-imx/imx8/cpu.c|   4 +-
 board/toradex/apalis-imx8qm/Kconfig |  30 +
 board/toradex/apalis-imx8qm/MAINTAINERS |   9 +
 board/toradex/apalis-imx8qm/Makefile|   6 +
 board/toradex/apalis-imx8qm/README  |  66 +++
 board/toradex/apalis-imx8qm/apalis-imx8qm.c | 149 +
 board/toradex/apalis-imx8qm/imximage.cfg|  24 +
 configs/apalis-imx8qm_defconfig |  56 ++
 drivers/clk/imx/clk-imx8qm.c|  18 +
 drivers/misc/imx8/fuse.c|   2 -
 include/configs/apalis-imx8qm.h | 177 ++
 16 files changed, 1443 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-imx8qm-apalis.dts
 create mode 100644 board/toradex/apalis-imx8qm/Kconfig
 create mode 100644 board/toradex/apalis-imx8qm/MAINTAINERS
 create mode 100644 board/toradex/apalis-imx8qm/Makefile
 create mode 100644 board/toradex/apalis-imx8qm/README
 create mode 100644 board/toradex/apalis-imx8qm/apalis-imx8qm.c
 create mode 100644 board/toradex/apalis-imx8qm/imximage.cfg
 create mode 100644 configs/apalis-imx8qm_defconfig
 create mode 100644 include/configs/apalis-imx8qm.h

-- 
2.20.1

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


[U-Boot] [PATCH v2 6/6] board: toradex: add apalis imx8qm 4gb wb it v1.0b module support

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

This commit adds initial support for the Toradex Apalis iMX8QM 4GB WB IT
V1.0B module. Unlike the V1.0A early access samples exclusively booting
from SD card, they are now strapped to boot from eFuses which are
factory fused to properly boot from their on-module eMMC. U-Boot
supports either booting from the on-module eMMC or may be used for
recovery purpose using the universal update utility (uuu) aka mfgtools
3.0.

Functionality wise the following is known to be working:
- eMMC, 8-bit and 4-bit MMC/SD card slots
- Gigabit Ethernet
- GPIOs
- I2C

Unfortunately, there is no USB functionality for the i.MX 8QM as of yet.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2:
- Use firmware-imx-8.0 matching NXP's sumo-4.14.78-1.0.0_ga BSP as
  suggested by Max.
- Drop Qualcomm (formwerly Atheros) AR8031 specific board_phy_config()
  stuff not applicable to the Micrel PHY we are using as suggested by Max.
- Drop CONFIG_FEC_XCV_TYPE in favour of device tree configuration therof
  as suggested by Max.

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi  | 128 
 arch/arm/dts/fsl-imx8qm-apalis.dts  | 615 
 arch/arm/mach-imx/imx8/Kconfig  |   6 +
 board/toradex/apalis-imx8qm/Kconfig |  30 +
 board/toradex/apalis-imx8qm/MAINTAINERS |   9 +
 board/toradex/apalis-imx8qm/Makefile|   6 +
 board/toradex/apalis-imx8qm/README  |  66 +++
 board/toradex/apalis-imx8qm/apalis-imx8qm.c | 149 +
 board/toradex/apalis-imx8qm/imximage.cfg|  24 +
 configs/apalis-imx8qm_defconfig |  56 ++
 include/configs/apalis-imx8qm.h | 177 ++
 12 files changed, 1267 insertions(+)
 create mode 100644 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-imx8qm-apalis.dts
 create mode 100644 board/toradex/apalis-imx8qm/Kconfig
 create mode 100644 board/toradex/apalis-imx8qm/MAINTAINERS
 create mode 100644 board/toradex/apalis-imx8qm/Makefile
 create mode 100644 board/toradex/apalis-imx8qm/README
 create mode 100644 board/toradex/apalis-imx8qm/apalis-imx8qm.c
 create mode 100644 board/toradex/apalis-imx8qm/imximage.cfg
 create mode 100644 configs/apalis-imx8qm_defconfig
 create mode 100644 include/configs/apalis-imx8qm.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 598dc213e3..2c1cf3122a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -576,6 +576,7 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
 dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
 
 dtb-$(CONFIG_ARCH_IMX8) += \
+   fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi 
b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
new file mode 100644
index 00..7b1a9550e4
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+&mu {
+   u-boot,dm-spl;
+};
+
+&clk {
+   u-boot,dm-spl;
+};
+
+&iomuxc {
+   u-boot,dm-spl;
+};
+
+&pd_lsio {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio0 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio1 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio2 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio3 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio4 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio5 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio6 {
+   u-boot,dm-spl;
+};
+
+&pd_lsio_gpio7 {
+   u-boot,dm-spl;
+};
+
+&pd_conn {
+   u-boot,dm-spl;
+};
+
+&pd_conn_sdch0 {
+   u-boot,dm-spl;
+};
+
+&pd_conn_sdch1 {
+   u-boot,dm-spl;
+};
+
+&pd_conn_sdch2 {
+   u-boot,dm-spl;
+};
+
+&gpio0 {
+   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;
+};
+
+&gpio6 {
+   u-boot,dm-spl;
+};
+
+&gpio7 {
+   u-boot,dm-spl;
+};
+
+&lpuart0 {
+   u-boot,dm-spl;
+};
+
+&lpuart1 {
+   u-boot,dm-spl;
+};
+
+&lpuart2 {
+   u-boot,dm-spl;
+};
+
+&lpuart3 {
+   u-boot,dm-spl;
+};
+
+&usdhc1 {
+   u-boot,dm-spl;
+};
+
+&usdhc2 {
+   u-boot,dm-spl;
+};
+
+&usdhc3 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qm-apalis.dts 
b/arch/arm/dts/fsl-imx8qm-apalis.dts
new file mode 100644
index 00..9b1f8aa32d
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qm-apalis.dts
@@ -0,0 +1,615 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2017-2019 Toradex
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+#include "fsl-imx8qm-apalis-u-boot.dtsi"
+
+/ {
+   model = "Toradex Apalis iMX8QM";
+   compatible = "toradex,apalis-imx8qm", "fsl,imx8qm";
+
+   chosen {
+   bootargs = "consol

[U-Boot] [PATCH v2 2/6] arm: dts: imx8qm: add support for i2c0, i2c1, i2c2, i2c3 and i2c4

2019-05-02 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Add support for i2c0, i2c1, i2c2, i2c3 and i2c4.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2: None

 arch/arm/dts/fsl-imx8qm.dtsi | 75 
 1 file changed, 75 insertions(+)

diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
index db01959990..af060db3a1 100644
--- a/arch/arm/dts/fsl-imx8qm.dtsi
+++ b/arch/arm/dts/fsl-imx8qm.dtsi
@@ -29,6 +29,11 @@
mmc0 = &usdhc1;
mmc1 = &usdhc2;
mmc2 = &usdhc3;
+   i2c0 = &i2c0;
+   i2c1 = &i2c1;
+   i2c2 = &i2c2;
+   i2c3 = &i2c3;
+   i2c4 = &i2c4;
};
 
memory@8000 {
@@ -224,6 +229,76 @@
};
};
 
+   i2c0: i2c@5a80 {
+   compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
+   reg = <0x0 0x5a80 0x0 0x4000>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   clocks = <&clk IMX8QM_I2C0_CLK>,
+<&clk IMX8QM_I2C0_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_I2C0_CLK>;
+   assigned-clock-rates = <2400>;
+   power-domains = <&pd_dma_lpi2c0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@5a81 {
+   compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
+   reg = <0x0 0x5a81 0x0 0x4000>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   clocks = <&clk IMX8QM_I2C1_CLK>,
+<&clk IMX8QM_I2C1_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_I2C1_CLK>;
+   assigned-clock-rates = <2400>;
+   power-domains = <&pd_dma_lpi2c1>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@5a82 {
+   compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
+   reg = <0x0 0x5a82 0x0 0x4000>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   clocks = <&clk IMX8QM_I2C2_CLK>,
+<&clk IMX8QM_I2C2_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_I2C2_CLK>;
+   assigned-clock-rates = <2400>;
+   power-domains = <&pd_dma_lpi2c2>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@5a83 {
+   compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
+   reg = <0x0 0x5a83 0x0 0x4000>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   clocks = <&clk IMX8QM_I2C3_CLK>,
+<&clk IMX8QM_I2C3_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_I2C3_CLK>;
+   assigned-clock-rates = <2400>;
+   power-domains = <&pd_dma_lpi2c3>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@5a84 {
+   compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
+   reg = <0x0 0x5a84 0x0 0x4000>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   clocks = <&clk IMX8QM_I2C4_CLK>,
+<&clk IMX8QM_I2C4_IPG_CLK>;
+   clock-names = "per", "ipg";
+   assigned-clocks = <&clk IMX8QM_I2C4_CLK>;
+   assigned-clock-rates = <2400>;
+   power-domains = <&pd_dma_lpi2c4>;
+   status = "disabled";
+   };
+
gpio0: gpio@5d08 {
compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio";
reg = <0x0 0x5d08 0x0 0x1>;
-- 
2.20.1

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


[U-Boot] [PATCH v2 3/6] clk: imx8qm: fix usdhc2 clocks

2019-05-02 Thread Marcel Ziswiler
Trying to bring up uSDHC2 the following error message was observed:

MMC:   imx8_clk_set_rate(Invalid clk ID #60)
imx8_clk_set_rate(Invalid clk ID #60)
usdhc@5b03 - probe failed: -22

This commit fixes this by properly setting resp. clocks.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2: None

 drivers/clk/imx/clk-imx8qm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c
index 6b5561e178..a6b09d2109 100644
--- a/drivers/clk/imx/clk-imx8qm.c
+++ b/drivers/clk/imx/clk-imx8qm.c
@@ -80,6 +80,12 @@ ulong imx8_clk_get_rate(struct clk *clk)
resource = SC_R_SDHC_1;
pm_clk = SC_PM_CLK_PER;
break;
+   case IMX8QM_SDHC2_IPG_CLK:
+   case IMX8QM_SDHC2_CLK:
+   case IMX8QM_SDHC2_DIV:
+   resource = SC_R_SDHC_2;
+   pm_clk = SC_PM_CLK_PER;
+   break;
case IMX8QM_UART0_IPG_CLK:
case IMX8QM_UART0_CLK:
resource = SC_R_UART_0;
@@ -185,6 +191,12 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long 
rate)
resource = SC_R_SDHC_1;
pm_clk = SC_PM_CLK_PER;
break;
+   case IMX8QM_SDHC2_IPG_CLK:
+   case IMX8QM_SDHC2_CLK:
+   case IMX8QM_SDHC2_DIV:
+   resource = SC_R_SDHC_2;
+   pm_clk = SC_PM_CLK_PER;
+   break;
case IMX8QM_ENET0_IPG_CLK:
case IMX8QM_ENET0_AHB_CLK:
case IMX8QM_ENET0_REF_DIV:
@@ -273,6 +285,12 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
resource = SC_R_SDHC_1;
pm_clk = SC_PM_CLK_PER;
break;
+   case IMX8QM_SDHC2_IPG_CLK:
+   case IMX8QM_SDHC2_CLK:
+   case IMX8QM_SDHC2_DIV:
+   resource = SC_R_SDHC_2;
+   pm_clk = SC_PM_CLK_PER;
+   break;
case IMX8QM_ENET0_IPG_CLK:
case IMX8QM_ENET0_AHB_CLK:
case IMX8QM_ENET0_REF_DIV:
-- 
2.20.1

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


[U-Boot] [PATCH v2 5/6] imx8: fuse: fix fuse driver

2019-05-02 Thread Marcel Ziswiler
This fixes the i.MX 8 fuse driver to actually build for i.MX 8QM as
well.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2: None

 drivers/misc/imx8/fuse.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/misc/imx8/fuse.c b/drivers/misc/imx8/fuse.c
index 29d2256a22..2f2fad2c17 100644
--- a/drivers/misc/imx8/fuse.c
+++ b/drivers/misc/imx8/fuse.c
@@ -15,13 +15,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define FSL_ECC_WORD_START_10x10
 #define FSL_ECC_WORD_END_1  0x10F
 
-#ifdef CONFIG_IMX8QXP
 #define FSL_ECC_WORD_START_20x220
 #define FSL_ECC_WORD_END_2  0x31F
 
 #define FSL_QXP_FUSE_GAP_START  0x110
 #define FSL_QXP_FUSE_GAP_END0x21F
-#endif
 
 #define FSL_SIP_OTP_READ 0xc20A
 #define FSL_SIP_OTP_WRITE0xc20B
-- 
2.20.1

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


[U-Boot] [PATCH v2 4/6] imx8qm: fix cpu frequency reporting

2019-05-02 Thread Marcel Ziswiler
CPU frequency reporting failed with the following error message being
printed:

sc_pm_get_clock_rate: resource:507 clk:2: res:3
Could not read CPU frequency: -22
CPU:   NXP i.MX8QM RevB A53 at 0 MHz

Fix this by differentiating between the A35 as found on the i.MX 8QXP
and the A53 as found on the i.MX 8QM SoCs.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Max Krummenacher 

---

Changes in v2: None

 arch/arm/mach-imx/imx8/cpu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 12716e7e9e..12596c6387 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -654,8 +654,10 @@ static ulong imx8_get_cpu_rate(void)
 {
ulong rate;
int ret;
+   int type = is_cortex_a35() ? SC_R_A35 : is_cortex_a53() ?
+  SC_R_A53 : SC_R_A72;
 
-   ret = sc_pm_get_clock_rate(-1, SC_R_A35, SC_PM_CLK_CPU,
+   ret = sc_pm_get_clock_rate(-1, type, SC_PM_CLK_CPU,
   (sc_pm_clock_rate_t *)&rate);
if (ret) {
printf("Could not read CPU frequency: %d\n", ret);
-- 
2.20.1

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


Re: [U-Boot] [PATCH] board: toradex: drop support.arm maintainer email

2019-05-02 Thread Marcel Ziswiler
Hi Tom

Sorry, this is a v2 and the only change is Stefan's ack being added.
Please apply, thanks!

Cheers

Marcel

On Thu, 2019-05-02 at 17:14 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Drop Toradex ARM Support  from maintainer
> email
> list as this just clogs our support ticketing system.
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Stefan Agner 
> 
> ---
> 
>  board/toradex/colibri-imx6ull/MAINTAINERS | 1 -
>  board/toradex/colibri_imx7/MAINTAINERS| 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS
> b/board/toradex/colibri-imx6ull/MAINTAINERS
> index 7cda555984..626c1f94f9 100644
> --- a/board/toradex/colibri-imx6ull/MAINTAINERS
> +++ b/board/toradex/colibri-imx6ull/MAINTAINERS
> @@ -1,6 +1,5 @@
>  Colibri iMX6ULL
>  M:   Stefan Agner 
> -M:   Toradex ARM Support 
>  W:   http://developer.toradex.com/software/linux/linux-software
>  W:   https://www.toradex.com/community
>  S:   Maintained
> diff --git a/board/toradex/colibri_imx7/MAINTAINERS
> b/board/toradex/colibri_imx7/MAINTAINERS
> index f55f8045f4..cd0f9c9b2d 100644
> --- a/board/toradex/colibri_imx7/MAINTAINERS
> +++ b/board/toradex/colibri_imx7/MAINTAINERS
> @@ -1,6 +1,5 @@
>  Colibri iMX7
>  M:   Stefan Agner 
> -M:   Toradex ARM Support 
>  W:   http://developer.toradex.com/software/linux/linux-software
>  W:   https://www.toradex.com/community
>  S:   Maintained
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)

2019-05-02 Thread Simon Glass
Hi Julius,

On Thu, 18 Apr 2019 at 15:09, Julius Werner  wrote:
>
> This patch adds support for compressing non-kernel image nodes in a FIT
> image (kernel nodes could already be compressed previously). This can
> reduce the size of FIT images and therefore improve boot times
> (especially when an image bundles many different kernel FDTs). The
> images will automatically be decompressed on load.
>
> This patch does not support extracting compatible strings from
> compressed FDTs, so it's not very helpful in conjunction with
> CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
> that select the configuration to load explicitly.
>
> Signed-off-by: Julius Werner 
> ---
>  common/image-fit.c | 83 +++---
>  1 file changed, 49 insertions(+), 34 deletions(-)

We should get a test together for this. There is an existing
test_fit.py which might be expanded, or perhaps create a new one and
share some code.

>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index ac901e131c..006e828b79 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -22,6 +22,7 @@
>  DECLARE_GLOBAL_DATA_PTR;
>  #endif /* !USE_HOSTCC*/
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void 
> *fdt)
>   kfdt_name);
> continue;
> }
> +
> +   if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
> +   debug("Can't extract compat from \"%s\" 
> (compressed)\n",
> + kfdt_name);
> +   continue;
> +   }
> +
> /*
>  * Get a pointer to this configuration's fdt.
>  */
> @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong 
> addr,
> const char *fit_uname_config;
> const char *fit_base_uname_config;
> const void *fit;
> -   const void *buf;
> +   void *buf;
> +   void *loadbuf;
> size_t size;
> int type_ok, os_ok;
> -   ulong load, data, len;
> -   uint8_t os;
> +   ulong load, load_end, data, len;
> +   uint8_t os, comp;
>  #ifndef USE_HOSTCC
> uint8_t os_arch;
>  #endif
> @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
> images->os.arch = os_arch;
>  #endif
>
> -   if (image_type == IH_TYPE_FLATDT &&
> -   !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
> -   puts("FDT image is compressed");
> -   return -EPROTONOSUPPORT;
> -   }
> -
> bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
> type_ok = fit_image_check_type(fit, noffset, image_type) ||
>   fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
> @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
> bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
>
> /* get image data address and length */
> -   if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) {
> +   if (fit_image_get_data_and_size(fit, noffset,
> +   (const void **)&buf, &size)) {
> printf("Could not find %s subimage data!\n", prop_name);
> bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
> return -ENOENT;
> @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong 
> addr,
>
>  #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
> /* perform any post-processing on the image data */
> -   board_fit_image_post_process((void **)&buf, &size);
> +   board_fit_image_post_process(&buf, &size);
>  #endif
>
> len = (ulong)size;
>
> -   /* verify that image data is a proper FDT blob */
> -   if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
> -   puts("Subimage data is not a FDT");
> -   return -ENOEXEC;
> -   }
> -
> bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
>
> -   /*
> -* Work-around for eldk-4.2 which gives this warning if we try to
> -* cast in the unmap_sysmem() call:
> -* warning: initialization discards qualifiers from pointer target 
> type
> -*/
> -   {
> -   void *vbuf = (void *)buf;
> -
> -   data = map_to_sysmem(vbuf);
> -   }
> -

We don't support gcc 4.2 now so this code can be simplified to the
line you have below, but perhaps this should be in a separate patch?

> +   data = map_to_sysmem(buf);
> +   load = data;
> if (load_op == FIT_LOAD_IGNORED) {
> /* Don't load */
> } else if (fit_image_get_load(fit, noffset, &load)) {
> @@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
> }
> } else if (load_op != FIT_LOAD_OPT

  1   2   >