Re: [U-Boot] [PATCH 2/4 v3] pci: pci_mvebu: Add DM_PCI support and move CONFIG_PCI_MVEBU to defconfig

2019-01-31 Thread Stefan Roese

Hi Bin,

On 31.01.19 15:41, Bin Meng wrote:

On Fri, Jan 25, 2019 at 6:53 PM Stefan Roese  wrote:


This patch adds DM_PCI support to the MVEBU PCIe driver. This is
necessary, since all PCI drivers have to be moved to DM (driver model)
until the v2019.07 release.

To not break git bisect'ablility, this patch also moves CONFIG_PCI_MVEBU
from config headers to the defconfig files.

Signed-off-by: Stefan Roese 
Cc: Dirk Eibach 
Cc: Mario Six 
Cc: Chris Packham 
Cc: Phil Sutter 
Cc: Marek Behún 
Cc: VlaoMao 
---
v3:
- Add x530 defconfig / config/foo.h changes
- Remove misleading function comment
- Use PCI_DEV instead of PCI_SLOT
- Introduce mvebu_pcie_ofdata_to_platdata() to remove most functions
   from the loop in mvebu_pcie_bind(). This also enables to usage of
   a udevice pointer for the newly introduced function pci_get_devfn()


v2:
- Completely configure the controller based on DT properties. Now
   port and lane are read from the DT nodes and also the tgt and
   attr values are generated using the DT similar to how this is
   done in the Linux driver version. All A38x / XP specific defines
   can now be removed from this driver because of this.
- Please note that now the board specific dts file needs to enable
   the used PCIe ports, as this is also done in Linux.

  configs/clearfog_defconfig  |   1 +
  configs/controlcenterdc_defconfig   |   3 +
  configs/db-88f6820-amc_defconfig|   1 +
  configs/db-88f6820-gp_defconfig |   1 +
  configs/db-mv784mp-gp_defconfig |   1 +
  configs/ds414_defconfig |   1 +
  configs/theadorable_debug_defconfig |   2 +
  configs/turris_omnia_defconfig  |   3 +-
  configs/x530_defconfig  |   3 +-
  drivers/pci/Kconfig |   9 +
  drivers/pci/pci_mvebu.c | 470 
  include/configs/clearfog.h  |   1 -
  include/configs/controlcenterdc.h   |   3 -
  include/configs/db-88f6820-amc.h|   1 -
  include/configs/db-88f6820-gp.h |   1 -
  include/configs/db-mv784mp-gp.h |   1 -
  include/configs/ds414.h |   1 -
  include/configs/theadorable.h   |   7 -
  include/configs/turris_omnia.h  |   1 -
  include/configs/x530.h  |   1 -
  scripts/config_whitelist.txt|   1 -
  21 files changed, 296 insertions(+), 217 deletions(-)



[snip]


+static int mvebu_get_tgt_attr(ofnode node, int devfn,
+ unsigned long type,
+ unsigned int *tgt,
+ unsigned int *attr)
+{
+   const int na = 3, ns = 2;
+   const __be32 *range;
+   int rlen, nranges, rangesz, pna, i;
+
+   *tgt = -1;
+   *attr = -1;
+
+   range = ofnode_get_property(node, "ranges", );
+   if (!range)
+   return -EINVAL;
+
+   pna = 2; /* hardcoded for now because of lack of of_n_addr_cells() */


Why? U-Boot has of_n_addr_cells() API.


This function is only available with CONFIG_OF_LIVE:

obj-$(CONFIG_OF_LIVE) += of_access.o of_addr.o

I didn't want to risk breaking any of the existing MVEBU targets by
forcing OF_LIVE here. I could add a comment to remove the hardcoded
value there, once OF_LIVE is enabled for MVEBU per default.

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


Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Bin Meng
Hi Alex,

On Fri, Feb 1, 2019 at 8:01 AM Alexander Graf  wrote:
>
>
>
> > Am 01.02.2019 um 00:40 schrieb Bin Meng :
> >
> > Hi Alex,
> >
> >> On Fri, Feb 1, 2019 at 2:30 AM Alexander Graf  wrote:
> >>
> >>
> >>
> >>> Am 31.01.2019 um 17:22 schrieb Bin Meng :
> >>>
> >>> At present the 4-level page table base address for 64-bit U-Boot
> >>> proper is assigned an address that conflicts with CONFIG_LOADADDR.
> >>> Change it to an address within the low memory range instead.
> >>
> >> Can't you dynamically allocate the PT too?
> >>
> >
> > The dynamically allocated PT only makes sense when in SPL. It then
> > becomes an arbitrary address again when entering in the 64-bit proper.
>
> I'm not sure I follow? On aarch64, we allocate every level dynamically. I 
> feel like I'm missing a piece of the puzzle here :)
>

The current x86 implementation is the SPL allocates the page table for
the 64-bit U-Boot. We can certainly change the implementation but I
would leave that for future changes.

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


Re: [U-Boot] imx8mq-evk: Outbound network packets lost

2019-01-31 Thread Chris Spencer
On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn  wrote:
> OK, it worked. The second patch is irrelevant for me because I'm working on
> a custom device, not MCIMX8M-EVK (I don't have that, just using its
> schematic from time to time as reference to its drivers and such) and I
> _DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without
> actual driver...
>
> I wonder how come nobody noticed that so far? It should affect other
> functionality that relies on proper pin muxing...
>
> Anyway, it is solved so I'm on USB (host and peripheral) now. Next come
> PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)...

Turns out there's already a patch to add the driver as part of the
i.MX8MM patch series. [1] Go figure.

I guess that everything else must just happen to be usable in the
default reset state.

Chris

[1] https://lists.denx.de/pipermail/u-boot/2019-January/356400.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-01-31 Thread AKASHI Takahiro
Hi Simon,

Thank you for suggestive comments.
I've got no idea of making DM class for EFI protocol.

On Wed, Jan 30, 2019 at 06:22:47PM -0700, Simon Glass wrote:
> Hi AKASHI,
> 
> On Mon, 28 Jan 2019 at 19:59, AKASHI Takahiro
>  wrote:
> >
> > efi_disk_create() will initialize efi_disk attributes for each device,
> > either UCLASS_BLK or UCLASS_PARTITION.
> >
> > Currently (temporarily), efi_disk_obj structure is embedded into
> > blk_desc to hold efi-specific attributes.
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/block/blk-uclass.c |   9 ++
> >  drivers/core/device.c  |   3 +
> >  include/blk.h  |  24 +
> >  include/dm/device.h|   4 +
> >  lib/efi_loader/efi_disk.c  | 192 ++---
> >  5 files changed, 174 insertions(+), 58 deletions(-)
> >
> 
> I think the objective should be to drop the EFI data structures.

More or less so, yes.

> So your approach of just including them in DM structures seems about
> right to me, as a short-term migration measure. Given the large amount
> of code that has built up I don't think it is possible to do it any
> other way.

Right.

> It is very unfortunate though.
> 
> So basically migration could be something like this:
> 
> 1. Move each of the EFI structs into the DM structs one by one
> 2. Drop struct members that are not needed and can be calculated from DM 
> members
> 3. Update DM to have 1:1 uclasses for each EFI protocol
> 4. Move all the protocol structs into the DM uclasses
> 5. Whittle these down until they are just shells used by the API, with
> everything going through normal DM calls
> 
> Or would it be better to just start again and rewrite it with the
> existing code as a base?
> 
> Looking at it, efi_object is not very useful in DM. It contains two members:
> 
> 1. link - linked list link, which devices already have, although we
> don't have a single list of all them. Instead they are linked into
> separate lists for each uclass
>
> 2. protocols - list of protocols. But DM devices support only one
> protocol. Multiple protocols are handled using child devices. E.g a
> UCLASS_PMIC device that supports UCLASS_GPIO, UCLASS_REGULATOR and
> UCLASS_AUDIO_CODEC would have three children, one for each uclass. So
> perhaps with EFI we should create a separate child for each protocol
> in a similar way?
> 
> Which comes back to the idea of creating an EFI child device for every
> DM device. Perhaps instead we create one EFI child for each protocol
> supported by the parent device?

Well, "child device as a EFI protocol" is really workable, but
I have some concerns:
* Can a DM device be an abstract instance with no real hardware?
* There may be two different types of "children" mixed for an EFI object
   - some physical hierarchy, say disk partitions for a raw disk
   - these EFI protocols
  That is, for example, one raw disk has
 - partition 1 has
 - block io protocol
 - device path protocol
 - simple file system protocol
 - partition 2 has
 - block io protocol
 - device path protocol
 - simple file system protocol
 - block io protocol
 - device path protocol
* device path protocol can be annoying as almost all devices (visible
  to UEFI) have some sort of device path, while corresponding u-boot
  notion is, say, "scsi 0:1" which only appears on command interfaces.

I'm not sure if those concerns are acceptable.

> Another point is that the operations supported by EFI should be in DM
> operations structs. For example I think struct
> efi_simple_text_output_protocol should have methods which call into
> the corresponding uclass operations.

I have no idea on those "console" devices yet.

> It is confusing that an EFI disk is in fact a partition. Or do I have
> that wrong?

IMO, EFI disk is any type of EFI object which supports EFI_BLOCK_IO_PROTOCOL.
So a raw disk(UCLASS_BLK) as well as its partitions(UCLASS_PARTITION) are
EFI disks as well.
Is this an answer to you?

Those said, your suggestion is truly worth considering.

Thanks,
-Takahiro Akashi


> Anyway that's all the thoughts I have at present. Thanks for your
> efforts on this.
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] configs: fsl: move DDR specific defines to Kconfig

2019-01-31 Thread Rajesh Bhagat
Moves below DDR specific defines to Kconfig:

CONFIG_FSL_DDR_BIST
CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE
CONFIG_FSL_DDR_INTERACTIVE
CONFIG_FSL_DDR_SYNC_REFRESH

Signed-off-by: Rajesh Bhagat 
---
 arch/arm/Kconfig| 14 ++
 arch/powerpc/cpu/mpc85xx/Kconfig| 13 +
 arch/powerpc/cpu/mpc86xx/Kconfig|  1 +
 drivers/ddr/fsl/Kconfig | 12 
 include/configs/B4860QDS.h  |  3 ---
 include/configs/BSC9132QDS.h|  1 -
 include/configs/MPC8536DS.h |  1 -
 include/configs/MPC8540ADS.h|  1 -
 include/configs/MPC8541CDS.h|  1 -
 include/configs/MPC8544DS.h |  1 -
 include/configs/MPC8548CDS.h|  1 -
 include/configs/MPC8555CDS.h|  1 -
 include/configs/MPC8560ADS.h|  1 -
 include/configs/MPC8568MDS.h|  1 -
 include/configs/MPC8569MDS.h|  1 -
 include/configs/MPC8572DS.h |  1 -
 include/configs/MPC8610HPCD.h   |  1 -
 include/configs/MPC8641HPCN.h   |  1 -
 include/configs/P1023RDB.h  |  1 -
 include/configs/T102xRDB.h  |  1 -
 include/configs/T1040QDS.h  |  1 -
 include/configs/T208xQDS.h  |  2 --
 include/configs/T208xRDB.h  |  1 -
 include/configs/T4240RDB.h  |  1 -
 include/configs/UCP1020.h   |  1 -
 include/configs/km/kmp204x-common.h |  1 -
 include/configs/ls1021aqds.h|  1 -
 include/configs/ls1043aqds.h|  4 
 include/configs/ls1043ardb.h|  2 --
 include/configs/ls1046aqds.h|  4 
 include/configs/ls1046ardb.h|  4 
 include/configs/ls1088a_common.h|  4 
 include/configs/ls2080a_common.h|  3 ---
 include/configs/ls2080a_emu.h   |  2 --
 include/configs/ls2080aqds.h|  3 ---
 include/configs/ls2080ardb.h|  2 --
 include/configs/p1_p2_rdb_pc.h  |  1 -
 include/configs/sbc8548.h   |  1 -
 include/configs/socrates.h  |  1 -
 include/configs/t4qds.h |  1 -
 include/configs/xpedite520x.h   |  1 -
 include/configs/xpedite537x.h   |  1 -
 scripts/config_whitelist.txt|  4 
 43 files changed, 40 insertions(+), 64 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cefa8f40d0..829b34787a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -998,6 +998,7 @@ config TARGET_LS2080A_EMU
select ARCH_MISC_INIT
select ARM64
select ARMV8_MULTIENTRY
+   select FSL_DDR_SYNC_REFRESH
help
  Support for Freescale LS2080A_EMU platform
  The LS2080A Development System (EMULATOR) is a pre silicon
@@ -1024,6 +1025,7 @@ config TARGET_LS1088AQDS
select ARMV8_MULTIENTRY
select BOARD_LATE_INIT
select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SD_BOOT
help
  Support for NXP LS1088AQDS platform
  The LS1088A Development System (QDS) is a high-performance
@@ -1040,6 +1042,8 @@ config TARGET_LS2080AQDS
select SUPPORT_SPL
imply SCSI
imply SCSI_AHCI
+   select FSL_DDR_BIST
+   select FSL_DDR_INTERACTIVE if !SPL
help
  Support for Freescale LS2080AQDS platform
  The LS2080A Development System (QDS) is a high-performance
@@ -1054,6 +1058,8 @@ config TARGET_LS2080ARDB
select ARMV8_MULTIENTRY
select BOARD_LATE_INIT
select SUPPORT_SPL
+   select FSL_DDR_BIST
+   select FSL_DDR_INTERACTIVE if !SPL
imply SCSI
imply SCSI_AHCI
help
@@ -1172,6 +1178,7 @@ config TARGET_LS1088ARDB
select ARMV8_MULTIENTRY
select BOARD_LATE_INIT
select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SD_BOOT
help
  Support for NXP LS1088ARDB platform.
  The LS1088A Reference design board (RDB) is a high-performance
@@ -1190,6 +1197,7 @@ config TARGET_LS1021AQDS
select LS1_DEEP_SLEEP
select SUPPORT_SPL
select SYS_FSL_DDR
+   select FSL_DDR_INTERACTIVE
imply SCSI
 
 config TARGET_LS1021ATWR
@@ -1229,6 +1237,7 @@ config TARGET_LS1043AQDS
select BOARD_EARLY_INIT_F
select BOARD_LATE_INIT
select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SPL
imply SCSI
help
  Support for Freescale LS1043AQDS platform.
@@ -1241,6 +1250,8 @@ config TARGET_LS1043ARDB
select BOARD_EARLY_INIT_F
select BOARD_LATE_INIT
select SUPPORT_SPL
+   select FSL_DDR_BIST if !SPL
+   select FSL_DDR_INTERACTIVE  if !SPL
imply SCSI
help
  Support for Freescale LS1043ARDB platform.
@@ -1254,6 +1265,7 @@ config TARGET_LS1046AQDS
select BOARD_LATE_INIT
select DM_SPI_FLASH if DM_SPI
select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SPL
imply SCSI
help
  Support for Freescale LS1046AQDS platform.
@@ -1271,6 +1283,8 @@ config TARGET_LS1046ARDB
select DM_SPI_FLASH if DM_SPI

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

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:58 +0100, Marek Vasut wrote:
> On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > After some series of patches to maximise reusable of memory pool,
> > here come
> > to result of reasonable size required for whole SDMMC boot working
> > on A10
> > SoCDK. Size required come from default max cluster(0x10) +
> The max cluster size is 0x1 , one zero too many in the
> description.
Good catch!! Blurry vision on my eyes when i was working too late :).
> 
> > 
> > others(0x2000) + additional memory for headroom(0x3000).
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v7
> > - Added 0x3000 for memory headroom.
> > ---
> >  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 4551cb2..548b458 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__
> > @@ -258,7 +258,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_SI
> > ZE - \
> >      CONFIG_SYS_SPL_MALLOC_SIZ
> > E + \
> >      CONFIG_SYS_INIT_RAM_ADDR)
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 4/7] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:57 +0100, Marek Vasut wrote:
> On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Update the default configuration file to enable the necessary
> > functionality
> > to get the SoCFPGA loadfs driver support. This would enable the
> > implementation of programming bitstream into FPGA from MMC.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v7
> > - Removed limit set for CONFIG_FS_FAT_MAX_CLUSTSIZE
> > ---
> >  configs/socfpga_arria10_defconfig | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/configs/socfpga_arria10_defconfig
> > b/configs/socfpga_arria10_defconfig
> > index 0554f1b..fc0dfa4 100644
> > --- a/configs/socfpga_arria10_defconfig
> > +++ b/configs/socfpga_arria10_defconfig
> > @@ -27,9 +27,15 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
> >  # CONFIG_EFI_PARTITION is not set
> >  CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
> >  CONFIG_ENV_IS_IN_MMC=y
> > +CONFIG_SPL_ENV_SUPPORT=y
> >  CONFIG_SPL_DM=y
> >  CONFIG_SPL_DM_SEQ_ALIAS=y
> > +CONFIG_SPL_DM_MMC=y
> Oddly enough, only 6/7 enables CONFIG_DW_MMC=y, so unless you apply
> also
> 6/7, this patch cannot work as intended.
Good catch!! I think all FIT related configs from 6/7 should be moved
to here because the FPGA driver now is FPGA FIT image implementation.
> 
> > 
> > +CONFIG_SPL_MMC_SUPPORT=y
> > +CONFIG_SPL_EXT_SUPPORT=y
> >  CONFIG_SPL_FS_FAT=y
> > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> > +CONFIG_FS_LOADER=y
> >  CONFIG_FPGA_SOCFPGA=y
> >  CONFIG_DM_GPIO=y
> >  CONFIG_DWAPB_GPIO=y
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:55 +0100, Marek Vasut wrote:
> On 1/31/19 3:51 PM, 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 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   |  18 +
> >  .../include/mach/fpga_manager_arria10.h|  39 +-
> >  drivers/fpga/socfpga_arria10.c | 417
> > -
> >  3 files changed, 457 insertions(+), 17 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > index 998d811..dc55618 100644
> > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > @@ -18,6 +18,24 @@
> >  /dts-v1/;
> >  #include "socfpga_arria10_socdk.dtsi"
> >  
> > +/ {
> > +   chosen {
> > +   firmware-loader = _loader0;
> Shouldn't this be <_loader0>; ?
> How did this even pass the DTC ?
So <> is compulsory required for phandle? No error complaint from DTC.
> 
> > 
> > +   };
> > +
> > +   fs_loader0: fs-loader@0 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> > +   };
> > +};
> > +
> > +_mgr {
> > +   u-boot,dm-pre-reloc;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> > +   altr,bitstream-core = "fit_spl_fpga.itb";
> > +};
> > +
> >   {
> >     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 09d13f6..683c84c 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 
> > +
> >  #ifndef _FPGA_MANAGER_ARRIA10_H_
> >  #define _FPGA_MANAGER_ARRIA10_H_
> >  
> > @@ -51,6 +55,10 @@
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > BIT(24)
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > 16
> >  
> > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> >  #ifndef __ASSEMBLY__
> >  
> >  struct socfpga_fpga_manager {
> > @@ -88,12 +96,39 @@ struct socfpga_fpga_manager {
> >     u32  imgcfg_fifo_status;
> >  };
> >  
> > +enum rbf_type {
> > +   unknown,
> > +   periph_section,
> > +   core_section
> > +};
> [...]
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] fs: fat: Reduce default max clustersize 64KiB from malloc pool

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:23 +0100, Marek Vasut wrote:
> On 1/31/19 1:42 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Release cluster block immediately when no longer use would help to
> > reduce
> > 64KiB memory allocated to the memory pool.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v2
> > - Assigned NULL to itr after free.
> > - Added NULL checking to itr, avoid freeing twice.
> > ---
> >  fs/fat/fat.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> > index 347787e..fa846ff 100644
> > --- a/fs/fat/fat.c
> > +++ b/fs/fat/fat.c
> > @@ -1152,12 +1152,21 @@ int file_fat_read_at(const char *filename,
> > loff_t pos, void *buffer,
> >     goto out_free_both;
> >  
> >     debug("reading %s at pos %llu\n", filename, pos);
> > -   ret = get_contents(, itr->dent, pos, buffer,
> > maxsize, actread);
> > +
> > +   /* For saving default max clustersize memory allocated to
> > malloc pool */
> > +   dir_entry *dentptr = itr->dent;
> > +
> > +   free(itr);
> > +
> > +   itr = NULL;
> > +
> > +   ret = get_contents(, dentptr, pos, buffer, maxsize,
> > actread);
> >  
> >  out_free_both:
> >     free(fsdata.fatbuf);
> >  out_free_itr:
> > -   free(itr);
> > +   if (itr)
> > +   free(itr);
> free(NULL) is valid, so you can drop the if conditional.
Noted.
> 
> > 
> >     return ret;
> >  }
> >  
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote:
> On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  board/altera/arria10-socdk/fit_spl_fpga.its | 31
> > +
> >  1 file changed, 31 insertions(+)
> >  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> > 
> > diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
> > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > new file mode 100644
> > index 000..46b125c
> > --- /dev/null
> > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > + /*
> > + * Copyright (C) 2019 Intel Corporation 
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +   description = "FIT image with FPGA bistream";
> > +   #address-cells = <1>;
> > +
> > +   images {
> > +   fpga-2 {
> Why is fpga-2 before fpga-1 ?
1. The main purpose is for solving the performance issue as i described
in cover letter. We can decide the absolute data position for core
image, and ensure it is in allignment.

2. Users know where is the data position for core, so easy for them to
program themself with series commands on U-Boot console.
> 
> > 
> > +   description = "FPGA core bitstream";
> > +   data =
> > /incbin/("../../../ghrd_10as066n2.core.rbf");
> > +   type = "fpga";
> > +   arch = "arm";
> > +   compression = "none";
> > +   load = <0x400>;
> > +   };
> > +
> > +   fpga-1 {
> > +   description = "FPGA peripheral bitstream";
> > +   data =
> > /incbin/("../../../ghrd_10as066n2.periph.rbf");
> > +   type = "fpga";
> > +   arch = "arm";
> > +   compression = "none";
> > +   };
> > +   };
> > +};
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

2019-01-31 Thread Chee, Tien Fong
On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote:
> On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patch adds description on properties about file name used for
> > both
> > peripheral bitstream and core bitstream.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v7
> > - Provided example of setting FPGA FIT image for both early IO
> > release
> >   and full release FPGA configuration.
> > ---
> >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 34
> > +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > mgr.txt
> > index 2fd8e7a..5f81a32 100644
> > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > @@ -7,8 +7,39 @@ Required properties:
> > - The second index is for writing FPGA
> > configuration data.
> >  - resets : Phandle and reset specifier for the device's reset.
> >  - clocks : Clocks used by the device.
> > +- altr,bitstream : File name for FPGA peripheral bitstream which
> > is used
> > +      to initialize FPGA IOs, PLL, IO48 and DDR. This
> > bitstream is
> > +      required to get DDR up running.
> > +      or
> > +      File name for full bitstream, consist of
> > peripheral bitstream
> > +      and core bitstream.
> > +- altr,bitstream-core(optional) : File name for core bitstream
> > which contains
> Is the name of the property 'altr,bitstream-core(optional)' ? I think
> the "optional" part should be in the description.
Yes, you are right.
> 
> > 
> > +     FPGA design which is used to
> > program FPGA CRAM
> > +     and ERAM.
> >  
> > -Example:
> > +Example: Bundles both peripheral bitstream and core bitstream into
> > FIT image
> > +    called fit_spl_fpga.itb. This FIT image can be created
> > through running
> > +    this command: tools/mkimage
> > +      -E -p 400
> > +      -f board/altera/arria10-
> > socdk/fit_spl_fpga.its
> > +      fit_spl_fpga.itb
> > +
> > +    For details of describing structure and contents of the
> > FIT image,
> > +    please refer board/altera/arria10-socdk/fit_spl_fpga.its
> > +
> > +- Examples for booting with early IO release, and enter early user
> > mode:
> > +
> > +   fpga_mgr: fpga-mgr@ffd03000 {
> > +   compatible = "altr,socfpga-a10-fpga-mgr";
> > +   reg = <0xffd03000 0x100
> > +      0xffcfe400 0x20>;
> > +   clocks = <_mp_clk>;
> > +   resets = < FPGAMGR_RESET>;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> > +   altr,bitstream-core = "fit_spl_fpga.itb";
> It's the same file, why does it use two properties ? 
1. Allows user to run optional for program core. When "" is set to 
altr,bitstream-core, then SPL would skip programming FPGA with core, so
user can program it later on U-Boot or Linux.
2. Allows core in different FIT file.

> And where is this
> file loaded from ?
You need to set the default source in DTS, for example "firmware-loader 
= _loader0", that's for power boot up purpose. After that, generic
firmware loader would go to the dsignated storage as described below to
find the FPGA FIT image according description from above.

fs_loader0: fs-loader@0 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
phandlepart = < 1>;
};
> 
> > 
> > +   };
> > +
> > +- Examples for booting with full release, enter user mode with
> > full bitstream:
> >  
> >     fpga_mgr: fpga-mgr@ffd03000 {
> >     compatible = "altr,socfpga-a10-fpga-mgr";
> > @@ -16,4 +47,5 @@ Example:
> >        0xffcfe400 0x20>;
> >     clocks = <_mp_clk>;
> >     resets = < FPGAMGR_RESET>;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> >     };
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to dwmac-socfpga

2019-01-31 Thread Ooi, Joyce
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Saturday, January 26, 2019 4:34 PM
> To: Ooi, Joyce ; Joe Hershberger
> 
> Cc: See, Chin Liang ; Ong, Hean Loong
> ; Priyanka Jain ; u-
> b...@lists.denx.de; Tan, Ley Foon ; Chee, Tien Fong
> 
> Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to dwmac-
> socfpga
> 
> On 1/25/19 3:35 PM, Ooi, Joyce wrote:
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Friday, January 4, 2019 10:56 PM
> >> To: Ooi, Joyce ; Joe Hershberger
> >> 
> >> Cc: See, Chin Liang ; Ong, Hean Loong
> >> ; Priyanka Jain ; u-
> >> b...@lists.denx.de
> >> Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
> >> dwmac- socfpga
> >>
> >> On 1/4/19 10:26 AM, Ooi, Joyce wrote:
>  -Original Message-
>  From: Marek Vasut [mailto:ma...@denx.de]
>  Sent: Friday, December 28, 2018 6:08 PM
>  To: Ooi, Joyce ; Joe Hershberger
>  
>  Cc: See, Chin Liang ; Ong, Hean Loong
>  ; Priyanka Jain ;
>  u- b...@lists.denx.de
>  Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
>  dwmac- socfpga
> 
>  On 12/28/18 8:28 AM, Ooi, Joyce wrote:
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Thursday, December 27, 2018 2:55 AM
> >> To: Ooi, Joyce ; Joe Hershberger
> >> 
> >> Cc: See, Chin Liang ; Ong, Hean Loong
> >> ; Priyanka Jain
> >> ;
> >> u- b...@lists.denx.de
> >> Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
> >> dwmac- socfpga
> >>
> >> On 12/26/18 8:47 AM, Ooi, Joyce wrote:
> >>> Adding Marek.
> >>>
>  -Original Message-
>  From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
>  Ooi, Joyce
>  Sent: Tuesday, November 27, 2018 5:40 PM
>  To: Joe Hershberger 
>  Cc: Ong, Hean Loong ; Priyanka Jain
>  ; See, Chin Liang
>  ;
>  u- b...@lists.denx.de
>  Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support
>  to
>  dwmac- socfpga
> 
>  Hi Joe,
> 
>  Any comments/feedback on this v3 patch?
> >>
> >> I thought we already had TSE support in drivers/net/altera_tse.c
> >> , is this related ?
> >>
>  Thanks.
> 
>  Regards,
>  Joyce Ooi
> 
> > -Original Message-
> > From: Ooi, Joyce
> > Sent: Friday, November 9, 2018 6:16 PM
> > To: Joe Hershberger 
> > Cc: Grygorii Strashko ; Neil
> > Armstrong ; Mario Six
> > ; Florian Fainelli ;
> > Priyanka Jain ; Ooi, Joyce
> > ; See, Chin Liang
> > ; Ong, Hean Loong
> > ; u-boot@lists.denx.de
> > Subject: [PATCH v3] net: phy: add TSE PCS support to
> > dwmac-socfpga
> >
> > This adds support for TSE PCS (Triple Speed Ethernet Physical
> > Coding
> > Sublayer) that uses SGMII adapter when the phy-mode in device
> > tree is set to sgmii.
> >
> > Signed-off-by: Ooi, Joyce 
> > ---
> >  arch/arm/mach-socfpga/include/mach/misc.h |3 +
> >  arch/arm/mach-socfpga/misc_s10.c  |6 +
> >  drivers/net/Makefile  |3 +-
> >  drivers/net/designware.c  |5 +
> >  drivers/net/designware.h  |1 +
> >  drivers/net/dwmac_socfpga.c   |  122 
> > +++
> >  drivers/net/phy/altr_tse_pcs.c|  184
>  +
> >  drivers/net/phy/altr_tse_pcs.h|   56 +
> >  8 files changed, 379 insertions(+), 1 deletions(-)  create
> > mode
> > 100644 drivers/net/phy/altr_tse_pcs.c  create mode 100644
> > drivers/net/phy/altr_tse_pcs.h
> > ---
> > v2: add a __weak function to make it compatible for all
> > socfpga platforms
> > v3: remove __weak function and use board-specific
> > implementation instead
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> > b/arch/arm/mach- socfpga/include/mach/misc.h index
> > 4fc9570..751705e
> > 100644
> > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > @@ -30,6 +30,9 @@ void socfpga_init_security_policies(void);
> >  void socfpga_sdram_remap_zero(void);  #endif
> >
> > +#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 int
> > +socfpga_test_fpga_ready(void); #endif
> >  void do_bridge_reset(int enable);
> >
> >  #endif /* _MISC_H_ */
> > diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-
> > socfpga/misc_s10.c 

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now

2019-01-31 Thread andy....@rock-chips.com
Hi:

> This function causes a 5-second delay and stops the display working on
> minnie. This code should be in a driver and should only be enabled by
> a device-tree property, so that it does not affect devices which do not
> have this feature.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/boot_mode.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
 
》Applied to u-boot-rockchip, thanks!


According to the previous discussing, shouldn‘t this be fixed by  by setting 
CONFIG_BOOT_MODE_REG=0 ?
All rockchip products need this function,we really don't want it be turned off.
 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v6.2] cmd: env: add "-e" option for handling UEFI variables

2019-01-31 Thread AKASHI Takahiro
# This is a replacement of my patch#1[1] with minor updates to fix
# travis build errors. The other patches are the exact same as in v6.
# [1] https://lists.denx.de/pipermail/u-boot/2019-January/356035.html

"env [print|set] -e" allows for handling uefi variables without
knowing details about mapping to corresponding u-boot variables.

Signed-off-by: AKASHI Takahiro 
---
 MAINTAINERS   |   1 +
 cmd/Kconfig   |   6 +
 cmd/Makefile  |   1 +
 cmd/nvedit.c  |  28 +++-
 cmd/nvedit_efi.c  | 340 ++
 include/command.h |   4 +
 6 files changed, 379 insertions(+), 1 deletion(-)
 create mode 100644 cmd/nvedit_efi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ae825014bda9..22ac686ab2d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -438,6 +438,7 @@ F:  lib/efi*/
 F: test/py/tests/test_efi*
 F: test/unicode_ut.c
 F: cmd/bootefi.c
+F: cmd/nvedit_efi.c
 F: tools/file2include.c
 
 FPGA
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325eb301..c66333598d31 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -53,6 +53,12 @@ config SYS_PROMPT
  This string is displayed in the command line to the left of the
  cursor.
 
+config CMD_NVEDIT_EFI
+   bool
+   depends on EFI_LOADER
+   default y
+   imply HEXDUMP
+
 menu "Autoboot options"
 
 config AUTOBOOT
diff --git a/cmd/Makefile b/cmd/Makefile
index 15ae4d250f50..142e0ee222ca 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MTD) += mtd.o
 obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
 obj-$(CONFIG_CMD_NAND) += nand.o
 obj-$(CONFIG_CMD_NET) += net.o
+obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
 obj-$(CONFIG_CMD_ONENAND) += onenand.o
 obj-$(CONFIG_CMD_OSD) += osd.o
 obj-$(CONFIG_CMD_PART) += part.o
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index ce746bbf1b3e..07285b877f40 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -119,6 +119,11 @@ static int do_env_print(cmd_tbl_t *cmdtp, int flag, int 
argc,
int rcode = 0;
int env_flag = H_HIDE_DOT;
 
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
+   return do_env_print_efi(cmdtp, flag, --argc, ++argv);
+#endif
+
if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'a') {
argc--;
argv++;
@@ -216,6 +221,12 @@ static int _do_env_set(int flag, int argc, char * const 
argv[], int env_flag)
ENTRY e, *ep;
 
debug("Initial value for argc=%d\n", argc);
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_CMD_NVEDIT_EFI)
+   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
+   return do_env_set_efi(NULL, flag, --argc, ++argv);
+#endif
+
while (argc > 1 && **(argv + 1) == '-') {
char *arg = *++argv;
 
@@ -1263,14 +1274,21 @@ static char env_help_text[] =
"env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import 
environment\n"
 #endif
"env print [-a | name ...] - print environment\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+   "env print  -e [name ...] - print UEFI environment\n"
+#endif
 #if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
 #endif
 #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
"env save - save environment\n"
 #endif
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+   "env set [-e | -f] name [arg ...]\n";
+#else
"env set [-f] name [arg ...]\n";
 #endif
+#endif
 
 U_BOOT_CMD(
env, CONFIG_SYS_MAXARGS, 1, do_env,
@@ -1295,6 +1313,10 @@ U_BOOT_CMD_COMPLETE(
printenv, CONFIG_SYS_MAXARGS, 1,do_env_print,
"print environment variables",
"[-a]\n- print [all] values of all environment variables\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+   "printenv -e [ ...]\n"
+   "- print UEFI variable 'name' or all the variables\n"
+#endif
"printenv name ...\n"
"- print value of environment variable 'name'",
var_complete
@@ -1322,7 +1344,11 @@ U_BOOT_CMD_COMPLETE(
 U_BOOT_CMD_COMPLETE(
setenv, CONFIG_SYS_MAXARGS, 0,  do_env_set,
"set environment variables",
-   "[-f] name value ...\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+   "-e  [ ...]\n"
+   "- set UEFI variable 'name' to 'value' ...'\n"
+#endif
+   "setenv [-f] name value ...\n"
"- [forcibly] set environment variable 'name' to 'value ...'\n"
"setenv [-f] name\n"
"- [forcibly] delete environment variable 'name'",
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
new file mode 100644
index ..08a7889139e6
--- /dev/null
+++ b/cmd/nvedit_efi.c
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Integrate UEFI variables to u-boot env interface
+ *
+ *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * From efi_variable.c,

Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Alexander Graf


> Am 01.02.2019 um 00:40 schrieb Bin Meng :
> 
> Hi Alex,
> 
>> On Fri, Feb 1, 2019 at 2:30 AM Alexander Graf  wrote:
>> 
>> 
>> 
>>> Am 31.01.2019 um 17:22 schrieb Bin Meng :
>>> 
>>> At present the 4-level page table base address for 64-bit U-Boot
>>> proper is assigned an address that conflicts with CONFIG_LOADADDR.
>>> Change it to an address within the low memory range instead.
>> 
>> Can't you dynamically allocate the PT too?
>> 
> 
> The dynamically allocated PT only makes sense when in SPL. It then
> becomes an arbitrary address again when entering in the 64-bit proper.

I'm not sure I follow? On aarch64, we allocate every level dynamically. I feel 
like I'm missing a piece of the puzzle here :)

Alex

> 
> Regards,
> Bin

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


Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Bin Meng
Hi Alex,

On Fri, Feb 1, 2019 at 2:30 AM Alexander Graf  wrote:
>
>
>
> > Am 31.01.2019 um 17:22 schrieb Bin Meng :
> >
> > At present the 4-level page table base address for 64-bit U-Boot
> > proper is assigned an address that conflicts with CONFIG_LOADADDR.
> > Change it to an address within the low memory range instead.
>
> Can't you dynamically allocate the PT too?
>

The dynamically allocated PT only makes sense when in SPL. It then
becomes an arbitrary address again when entering in the 64-bit proper.

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


Re: [U-Boot] [U-Boot, v2, 9/9] ARM: dts: rk322x: Correct the uart2 default pin configuration

2019-01-31 Thread Philipp Tomsich
> To match the iomux setting of uart2 at SPL, correct the uart2
> default pin configuration, if not changed, the evb-rk3229 can't
> output the log message.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk322x.dtsi | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 15/19] rockchip: rk3399: Add ROCKCHIP_DEVICE_SETTINGS to set env

2019-01-31 Thread Philipp Tomsich
> Some boards use different stdio environment variables from the default.
> Provide a #define for this which can be set before including the header
> file.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  include/configs/rk3399_common.h | 5 +
>  1 file changed, 5 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 13/19] rockchip: clk: Add mention of four new clocks

2019-01-31 Thread Philipp Tomsich
> These clocks are needed to get MMC running. We don't actually support
> setting them yet.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2:
> - Use correct printf format for log message
> 
>  drivers/clk/rockchip/clk_rk3399.c | 12 
>  1 file changed, 12 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 17/19] rockchip: Implement spl_gpio in the GPIO driver

2019-01-31 Thread Philipp Tomsich
> Allow rockchip boards to use GPIOs before driver model is ready. This is
> really only useful for setting GPIOs to enable the early debug console, if
> needed on some platforms.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/gpio.h | 23 
>  drivers/gpio/rk_gpio.c| 46 +++
>  2 files changed, 69 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 14/19] rockchip: Tidy up board include-file ordering

2019-01-31 Thread Philipp Tomsich
> These board files have inconsistent #include ordering. Fix them.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3036-board.c |  2 +-
>  arch/arm/mach-rockchip/rk3188-board-spl.c |  2 +-
>  arch/arm/mach-rockchip/rk3188-board.c |  2 +-
>  arch/arm/mach-rockchip/rk322x-board.c |  2 +-
>  arch/arm/mach-rockchip/rk3368-board-spl.c |  2 +-
>  arch/arm/mach-rockchip/rk3368-board-tpl.c |  4 ++--
>  arch/arm/mach-rockchip/rk3399-board-spl.c | 12 ++--
>  7 files changed, 13 insertions(+), 13 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 12/19] rockchip: Add settings for Samsung LPDDR3 4GB SDRAM 1866MHz

2019-01-31 Thread Philipp Tomsich
> This memory is used on Bob. Add settings for this, taken from coreboot.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  .../rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi | 1542 +
>  1 file changed, 1542 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi
> 

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


Re: [U-Boot] [U-Boot, v2, 10/19] rockchip: Clarify docs on SPI writing

2019-01-31 Thread Philipp Tomsich
> We use every second block when creating a SPI image, so update the text to
> say this explicitly.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  doc/README.rockchip | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 18/19] rockchip: gru: Add extra device-tree settings

2019-01-31 Thread Philipp Tomsich
> Add some U-Boot-specific settings. These should really go in the
> *u-boot.dtsi file, but it seems that rk3399 does not use that yet.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk3399-gru-bob.dts |  1 +
>  arch/arm/dts/rk3399-gru-chromebook.dtsi |  1 +
>  arch/arm/dts/rk3399-gru.dtsi| 21 +
>  3 files changed, 19 insertions(+), 4 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 09/19] rockchip: evb_rk3399: Tidy up the README

2019-01-31 Thread Philipp Tomsich
> Add mention of a prerequisite needed to build the image. Also adjust the
> English wording in a few places.
> 
> Ideally this should move to using binman to produce images, and avoid the
> manual steps.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  board/rockchip/evb_rk3399/README | 33 
>  1 file changed, 21 insertions(+), 12 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 16/19] rockchip: Move pull-up/down enum into a common file

2019-01-31 Thread Philipp Tomsich
> At present this enum is only available to rk3288. Move it so that other
> rockchip SoCs can access it. It is needed for the SPL GPIO driver for
> rk3999 in a later patch.
> 
> Also adjust the enum name to lower case.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/gpio.h   | 7 +++
>  arch/arm/include/asm/arch-rockchip/grf_rk3288.h | 7 ---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 

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


Re: [U-Boot] [U-Boot,v2,11/19] rockchip: Allow booting from SPI

2019-01-31 Thread Philipp Tomsich
> The u-boot,spl-boot-device property only allows MMC at present. Add SPI as
> well for boards that boot from SPI flash.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/spl-boot-order.c | 3 +++
>  1 file changed, 3 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 19/19] rockchip: Add support for chromebook_bob

2019-01-31 Thread Philipp Tomsich
> Bob is a 10-inch chromebook produced by Asus. It has two USB 3.0 type-C
> ports, 4GB of SDRAM, WiFi and a 1280x800 display. It uses its USB ports
> for both power and external display. It includes a Chrome OS EC
> (Cortex-M3) to provide access to the keyboard and battery functions.
> 
> Support so far includes only:
> - UART
> - SDRAM
> - MMC, SD card
> - Cros EC (but not keyboard)
> 
> Not included:
> - Keyboard
> - Display
> - Sound
> - USB
> - TPM
> 
> Bob is quite similar to Kevin, the Samsung Chromebook Plus, but support
> for this is not provided in this series.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2:
> - Add #ifdef guard around variables in rk3399 board_debug_uart_init()
> 
>  .../arm/include/asm/arch-rockchip/sys_proto.h |   3 +
>  arch/arm/mach-rockchip/rk3399-board-spl.c |  39 ++-
>  arch/arm/mach-rockchip/rk3399/Kconfig |  10 ++
>  board/google/gru/Kconfig  |  15 +++
>  board/google/gru/MAINTAINERS  |   6 ++
>  board/google/gru/Makefile |   5 +
>  board/google/gru/gru.c|  16 +++
>  configs/chromebook_bob_defconfig  | 100 ++
>  doc/README.rockchip   |   6 +-
>  include/configs/gru.h |  18 
>  10 files changed, 215 insertions(+), 3 deletions(-)
>  create mode 100644 board/google/gru/Kconfig
>  create mode 100644 board/google/gru/MAINTAINERS
>  create mode 100644 board/google/gru/Makefile
>  create mode 100644 board/google/gru/gru.c
>  create mode 100644 configs/chromebook_bob_defconfig
>  create mode 100644 include/configs/gru.h
> 

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


Re: [U-Boot] [U-Boot, v2, 06/19] rockchip: Drop note about supporting other SoCs

2019-01-31 Thread Philipp Tomsich
> Quite a wide range of Rockchip SoCs are supported in mainline U-Boot now,
> so drop the comment about needing to add more.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  doc/README.rockchip | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 07/19] rockchip: Bring in device tree files for rk3399-gru

2019-01-31 Thread Philipp Tomsich
> Bring in these files from Linux v4.20.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk3399-gru-bob.dts |  79 +++
>  arch/arm/dts/rk3399-gru-chromebook.dtsi | 397 +++
>  arch/arm/dts/rk3399-gru-kevin.dts   | 309 +
>  arch/arm/dts/rk3399-gru.dtsi| 831 
>  arch/arm/dts/rk3399-op1-opp.dtsi| 141 
>  5 files changed, 1757 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-gru-bob.dts
>  create mode 100644 arch/arm/dts/rk3399-gru-chromebook.dtsi
>  create mode 100644 arch/arm/dts/rk3399-gru-kevin.dts
>  create mode 100644 arch/arm/dts/rk3399-gru.dtsi
>  create mode 100644 arch/arm/dts/rk3399-op1-opp.dtsi
> 

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


Re: [U-Boot] [U-Boot, v2, 08/19] rockchip: Adjust rk3399 device tree to be closer to linux

2019-01-31 Thread Philipp Tomsich
> This file has changed upstream, with some additions and changes. Move the
> U-Boot version towards this.
> 
> Some USB changes seem to be incompatible with how the bindings work on
> rockchip in U-Boot. Testing is needed to make sure that USB still works
> correct, and adjust the code (not device tree) if not.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk3399.dtsi | 432 +--
>  1 file changed, 371 insertions(+), 61 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 03/19] gpio: Use more command-specific enums values

2019-01-31 Thread Philipp Tomsich
> At present this file uses GPIO_OUTPUT and GPIO_INPUT as its sub-command
> values. These are pretty generic names. Add a 'C' suffix to avoid possible
> conflicts.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  cmd/gpio.c | 37 +++--
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 

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


Re: [U-Boot] [U-Boot,v2,04/19] gpio: Add a simple GPIO API for SPL

2019-01-31 Thread Philipp Tomsich
> In space-constrained environments or before driver model is available, it
> is sometimes necessary to set GPIO values. Add an SPL API for this, to
> allow early board code to change GPIOs. The caller must provide the
> register address, so that the drivers can be fairly generic.
> 
> This API can be implemented by GPIO drivers, behind a suitable guard,
> like #ifdef CONFIG_SPL_BUILD.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  include/spl_gpio.h | 62 ++
>  1 file changed, 62 insertions(+)
>  create mode 100644 include/spl_gpio.h
> 

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


Re: [U-Boot] [U-Boot, v2, 05/19] rockchip: Add mention of other boards

2019-01-31 Thread Philipp Tomsich
> At present some Rockchip SoCs and boards are not mentioned in the README.
> So that people can see which SoCs are supported, expand the list to
> include everything.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2:
> - Mention EVB RV1108
> - Fix the name of the firefly-rk3399 defconfig
> 
>  doc/README.rockchip | 44 ++--
>  1 file changed, 42 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 02/19] clk: Improve debug message in clk_set_default_rates()

2019-01-31 Thread Philipp Tomsich
> It is helpful to print the clock number as well as the index, so that this
> can be looked up in the binding file. Update the debug() statement to do
> this.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  drivers/clk/clk-uclass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 01/19] lib: Allow using display_buffer() in SPL

2019-01-31 Thread Philipp Tomsich
> At present this function uses printf() format strings that are not
> supported in SPL, so the output just consists of %llx strings on 64-bit.
> machines. Fix this by adding a special case.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  lib/display_options.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 3/9] ARM: rockchip: Kconfig: Remove the SPL_PINCTRL for rk3188

2019-01-31 Thread Philipp Tomsich
> It seems that pinctrl is not requested for rk3188 SPL, remove it so
> that can save more space for SPL image size.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Philipp Tomsich 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 8/9] pinctrl: rockchip: Clean the unused rockchip pinctrl drivers

2019-01-31 Thread Philipp Tomsich
> If we used the pinctrl-rockchip driver, these code is not needed,
> so remove them.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Simon Glass 
> Tested-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  drivers/pinctrl/rockchip/pinctrl_rk3036.c | 671 ---
>  drivers/pinctrl/rockchip/pinctrl_rk3128.c | 186 
>  drivers/pinctrl/rockchip/pinctrl_rk3188.c | 989 --
>  drivers/pinctrl/rockchip/pinctrl_rk322x.c | 894 ---
>  drivers/pinctrl/rockchip/pinctrl_rk3288.c | 869 ---
>  drivers/pinctrl/rockchip/pinctrl_rk3328.c | 705 ---
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c | 739 
>  drivers/pinctrl/rockchip/pinctrl_rk3399.c | 503 ---
>  drivers/pinctrl/rockchip/pinctrl_rv1108.c | 580 -
>  9 files changed, 6136 deletions(-)
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3036.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3128.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3188.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk322x.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3288.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3328.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3368.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3399.c
>  delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rv1108.c
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 7/9] rockchip: defconfig: Clean the unused pinctrl config

2019-01-31 Thread Philipp Tomsich
> If we used the pinctrl-rockchip driver, these config is not needed,
> so remove them.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  configs/chromebit_mickey_defconfig  | 2 --
>  configs/chromebook_jerry_defconfig  | 2 --
>  configs/chromebook_minnie_defconfig | 2 --
>  configs/evb-px5_defconfig   | 1 -
>  configs/evb-rk3128_defconfig| 1 -
>  configs/evb-rk3229_defconfig| 1 -
>  configs/evb-rk3288_defconfig| 2 --
>  configs/evb-rk3399_defconfig| 1 -
>  configs/evb-rv1108_defconfig| 1 -
>  configs/fennec-rk3288_defconfig | 2 --
>  configs/firefly-rk3288_defconfig| 2 --
>  configs/firefly-rk3399_defconfig| 1 -
>  configs/geekbox_defconfig   | 1 -
>  configs/kylin-rk3036_defconfig  | 1 -
>  configs/lion-rk3368_defconfig   | 1 -
>  configs/miqi-rk3288_defconfig   | 2 --
>  configs/phycore-rk3288_defconfig| 2 --
>  configs/popmetal-rk3288_defconfig   | 2 --
>  configs/puma-rk3399_defconfig   | 1 -
>  configs/rock2_defconfig | 2 --
>  configs/rock_defconfig  | 1 -
>  configs/sandbox_defconfig   | 2 --
>  configs/sandbox_flattree_defconfig  | 2 --
>  configs/sandbox_noblk_defconfig | 2 --
>  configs/sheep-rk3368_defconfig  | 1 -
>  configs/tinker-rk3288_defconfig | 2 --
>  configs/vyasa-rk3288_defconfig  | 2 --
>  27 files changed, 42 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 6/9] pinctrl: rockchip: Add common rockchip pinctrl driver

2019-01-31 Thread Philipp Tomsich
> Use this driver to fit all Rockchip SOCs and to support
> the desired pinctrl configuration via DTS.
> 
> Signed-off-by: David Wu 
> Acked-by: Heiko Stuebner 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2:
> - Remove px30, rk2928, rk3066*.
> - Split it to multiple files for the relevant per-SoC data structures.
> 
>  drivers/pinctrl/Kconfig   |  91 +-
>  drivers/pinctrl/Makefile  |   2 +-
>  drivers/pinctrl/rockchip/Kconfig  |  17 +
>  drivers/pinctrl/rockchip/Makefile |  19 +-
>  drivers/pinctrl/rockchip/pinctrl-rk3036.c |  65 ++
>  drivers/pinctrl/rockchip/pinctrl-rk3128.c | 155 
>  drivers/pinctrl/rockchip/pinctrl-rk3188.c |  82 ++
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c | 215 +
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 157 
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 227 +
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c | 116 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c | 193 +
>  .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 788 ++
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h   | 302 +++
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c | 203 +
>  15 files changed, 2532 insertions(+), 100 deletions(-)
>  create mode 100644 drivers/pinctrl/rockchip/Kconfig
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3036.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3128.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3188.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk322x.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3288.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3328.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3368.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3399.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip.h
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rv1108.c
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 4/9] ARM: rockchip: Remove the pinctrl request at rk3288-board-spl

2019-01-31 Thread Philipp Tomsich
> If we use the new pinctrl driver, the pinctrl setup will be done
> by device probe. Remove the pinctrl setup at rk3288-board-spl.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Philipp Tomsich 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 79 ---
>  1 file changed, 79 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 2/9] ARM: rockchip: rk3188: Remove the pinctrl setup and enable uart at SPL

2019-01-31 Thread Philipp Tomsich
> When the boot ROM sets up MMC we don't need to do it again. Remove the
> MMC setup code entirely, but we also need to enable uart for debug message.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3188-board-spl.c | 41 ++-
>  1 file changed, 2 insertions(+), 39 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 1/9] rockchip: rk3399-evb: defconfig: Enable FDT for new pinctrl driver

2019-01-31 Thread Philipp Tomsich
> The FDT is requested for new pinctrl driver, disable SPL_OF_PLATDATA
> to make FDT be built in.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Simon Glass 
> Tested-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
> 
> Changes in v2: None
> 
>  configs/evb-rk3399_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 5/9] rk3288: chrome: defconfig: Enable FDT for new pinctrl driver

2019-01-31 Thread Philipp Tomsich
> The FDT is requested for new pinctrl driver, disable SPL_OF_PLATDATA
> and enable SPL_OF_LIBFDT to make FDT be built in.
> 
> Signed-off-by: David Wu 
> ---
> 
> Changes in v2: None
> 
>  configs/chromebit_mickey_defconfig  | 2 --
>  configs/chromebook_jerry_defconfig  | 2 --
>  configs/chromebook_minnie_defconfig | 2 --
>  3 files changed, 6 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] rockchip: dts: rk3399-firely: add 'same-as-spl'

2019-01-31 Thread Philipp Tomsich
> Like on rk3399-puma we want to continue booting the fill U-Boot from
> the same device as the SPL stage.
> 
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/dts/rk3399-firefly.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

2019-01-31 Thread Philipp Tomsich
> This adds support for the ASUS C201, a RK3288-based clamshell
> device. The device tree comes from linus's linux tree at
> 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters
> are for 4GB Samsung LPDDR3, decoded from coreboot's
> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
> 
> Signed-off-by: Marty E. Plummer 
> ---
> v2: drop sf: Add GigaDevice gd25q32b entry: subsumed by commit
> b1f2b72e39465f2d4582bb4d8c426489ee94e2d9
> split out rk3288-veyron-speedy-u-boot.dtsi
> drop useless if (!size_mb)
> apply changes from chromebook_jerry_defconfig
> v3: drop rockchip: fix incorrect detection of ram size: subsumed by commit
> 3119ecc4accceb99cf931683567cc26148b7f99c
> sort defconfig option to match changes in chromebook_jerry_defconfig
> enable CONSOLE_TRUETYPE
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi |  31 
>  arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++
>  arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig |  11 ++
>  board/google/veyron/Kconfig   |  16 ++
>  configs/chromebook_speedy_defconfig   | 100 
>  7 files changed, 304 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
>  create mode 100644 configs/chromebook_speedy_defconfig
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now

2019-01-31 Thread Philipp Tomsich
> This function causes a 5-second delay and stops the display working on
> minnie. This code should be in a driver and should only be enabled by
> a device-tree property, so that it does not affect devices which do not
> have this feature.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/boot_mode.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190131

2019-01-31 Thread Tom Rini
On Thu, Jan 31, 2019 at 09:42:50AM +0100, Neil Armstrong wrote:

> [Oops, wrong subject, now fixed]
> 
> Hi Tom,
> 
> This PR adds support for HDMI & CVBS video output support for Amlogic GX SoCs.
> For simplicity, Anatolij acked to include the video patches along the platform
> changes in this PR.
> Video has been enabled only on libretech-cc, but will be enabled on the other
> boards after broader testing.
> 
> Thanks,
> Neil
> 
> 
> The following changes since commit 535d74a8ae8d194269cefdf59ae17a92cd6e75dc:
> 
>   MAINTAINERS: Add Amlogic entry (2019-01-30 21:22:53 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190131
> 
> for you to fetch changes up to fce1069bfb9b0b12fb760c408833c33243492257:
> 
>   arm: libretech-cc: enable video by default (2019-01-31 09:35:01 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] arm: dts: am33xx: add u-boot, dm-spl to ocp bus

2019-01-31 Thread Tom Rini
On Thu, Jan 31, 2019 at 09:18:01PM +0100, Hannes Schmelzer wrote:
> 
> On 1/31/19 4:59 PM, Tom Rini wrote:
> >On Thu, Jan 31, 2019 at 04:48:10PM +0100, Hannes Schmelzer wrote:
> >
> >>On 1/31/19 3:57 PM, Tom Rini wrote:
> >>>On Thu, Jan 31, 2019 at 08:03:19AM +0100, Hannes Schmelzer wrote:
> >>>
> commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
> did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
> introduced with
> commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")
> 
> Due to this the brppt1_spi board is broken because it cannot
> bind/probe the spi-interface during SPL stage.
> 
> This commit adds this flag again.
> 
> This flag is needed for having access to the devices below this bus,
> most important is uart and boot-device (spi, mmc, ...) in SPL stage.
> 
> Signed-off-by: Hannes Schmelzer 
> 
> ---
> 
>   arch/arm/dts/am33xx.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
> index d3dd6a1..0a6b177 100644
> --- a/arch/arm/dts/am33xx.dtsi
> +++ b/arch/arm/dts/am33xx.dtsi
> @@ -160,6 +160,7 @@
>    * the whole bus hierarchy.
>    */
>   ocp {
> + u-boot,dm-spl;
>   compatible = "simple-bus";
>   #address-cells = <1>;
>   #size-cells = <1>;
> >>>We need to put this into one of the -u-boot.dtsi files and then #include
> >>>it from the others, so that we don't keep dropping this flag.  Thanks!
> >>Hi Tom,
> >>i'm not sure if we can do that this way because the "ocp" bus has no valid
> >>label like other elements.
> >>So we have at least to adjust the am33xx.dtsi file like this:
> >>
> >>     ocp : ocp {
> >>     compatible = "simple-bus";
> >>                 .
> >>         }
> >>
> >>what do you suggest ?
> >Er, with the example of arch/arm/dts/am335x-pdu001-u-boot.dtsi should't
> >we be able to just do that, globally?  Or is that part _not_ working and
> >relied on the now removed hunk?
> Hi Tom,
> I'll verify this tomorrow. But the pdu001 looks good to me.
> This would be a solution for my boards too if it does the job.
> Keep you up to date.

Thanks.  Just keep in mind that if it works, we need am33xx-u-boot.dtsi
with that, so it unbreaks all the SoC.

-- 
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] arm: dts: am33xx: add u-boot, dm-spl to ocp bus

2019-01-31 Thread Hannes Schmelzer


On 1/31/19 4:59 PM, Tom Rini wrote:

On Thu, Jan 31, 2019 at 04:48:10PM +0100, Hannes Schmelzer wrote:


On 1/31/19 3:57 PM, Tom Rini wrote:

On Thu, Jan 31, 2019 at 08:03:19AM +0100, Hannes Schmelzer wrote:


commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
introduced with
commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")

Due to this the brppt1_spi board is broken because it cannot
bind/probe the spi-interface during SPL stage.

This commit adds this flag again.

This flag is needed for having access to the devices below this bus,
most important is uart and boot-device (spi, mmc, ...) in SPL stage.

Signed-off-by: Hannes Schmelzer 

---

  arch/arm/dts/am33xx.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
index d3dd6a1..0a6b177 100644
--- a/arch/arm/dts/am33xx.dtsi
+++ b/arch/arm/dts/am33xx.dtsi
@@ -160,6 +160,7 @@
 * the whole bus hierarchy.
 */
ocp {
+   u-boot,dm-spl;
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

We need to put this into one of the -u-boot.dtsi files and then #include
it from the others, so that we don't keep dropping this flag.  Thanks!

Hi Tom,
i'm not sure if we can do that this way because the "ocp" bus has no valid
label like other elements.
So we have at least to adjust the am33xx.dtsi file like this:

     ocp : ocp {
     compatible = "simple-bus";
                 .
         }

what do you suggest ?

Er, with the example of arch/arm/dts/am335x-pdu001-u-boot.dtsi should't
we be able to just do that, globally?  Or is that part _not_ working and
relied on the now removed hunk?

Hi Tom,
I'll verify this tomorrow. But the pdu001 looks good to me.
This would be a solution for my boards too if it does the job.
Keep you up to date.

cheers,
Hannes





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


Re: [U-Boot] Nand boot on imx6q board is broken

2019-01-31 Thread Michael Nazzareno Trimarchi
Hi



On Thu., 31 Jan. 2019, 6:26 pm Adam Ford  On Thu, Jan 31, 2019 at 7:58 AM Shyam Saini 
> wrote:
> >
> > Hi Adam,
> >
> > Thanks a lot for replying.
> >
> > >
> > > I spent some time trying to make the imx6q_logic board boot from SPL
> > > from NAND, but I needed to patch a few things.   Some of them have yet
> > > to be approved, but if they work for you, maybe it will help get them
> > > approved.
> > >
> > > There was a broken function pointer here that was fixed and applied
> > > the imx-master, but pending merge with master
> > > http://patchwork.ozlabs.org/patch/1019440/
> > >
> > > Configure ECC from SPL here:
> > > http://patchwork.ozlabs.org/patch/1020160/
> > >
> > > Remove hard-coded ECC parameters since the patch above can autoset
> them.
> > > http://patchwork.ozlabs.org/patch/1026638/
> > >
> > > With those 3 patches and some minor changes to my individual board
> > > file and config file, I was able to boot 2019.01 via SPL from NAND.
> > > Since it was working for you before, I am guessing the board file
> > > stuff and config file stuff is probably already for you.
> >
> >
> > I did apply the above mentioned 3 patches but nand boot is still not
> working.
> >
> > Here are debug enabled boot logs
> > https://paste.ubuntu.com/p/dmcwqzv6Sk/
> >
> Your U-Boot version shows the version is U-Boot SPL
> 2016.09-rc2-gc347b70c408b which is a couple years old.  Can you try
> 2019.01 with those patches I mentioned or the imx branch?  I know
> there have been changes to U-Boot over time.
>
> The last of the patches I applied to set the final configuration
> settings for my board to boot from NAND are here:
> http://patchwork.ozlabs.org/patch/1024016/
>
> I don't know if that helps your board or not.
>

Look the end ;)

Michael

>
> adam
> >
> > Best Regards,
> > Shyam
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] RISC-V Open source Supervisor Binary Interface (OpenSBI) Version 0.1 Released

2019-01-31 Thread Atish Patra

OpenSBI version 0.1 is now publicly available in GitHub at
https://github.com/riscv/opensbi.

OpenSBI is an open source implementation of the RISC-V Supervisor Binary
Interface (SBI). RISC-V SBI specifications are maintained as an 
independent project by the RISC-V Foundation in [Github].


This initial release of OpenSBI provides an implementation of the RISC-V 
SBI specifications version 0.1. These specifications define the legacy 
SBI interface currently in use by various products as well as by RISC-V 
QEMU virtual machines.


OpenSBI also implements SBI compliant early boot firmwares capable of 
handling various boot flows and payloads on various environments. 
OpenSBI firmwares have been tested with payloads such as U-Boot and 
Linux kernel, showing that these open firmwares can fully replace the 
legacy non-standard BBL intermediate boot loader.


The platforms supported with this first release are as follows.
* Sifive HiFive Unleashed board
* RISC-V QEMU *virt* and *sifive_u* virtual machines
* Kendryte K210 SoC based boards.

OpenSBI implementation can be easily extended by RISC-V platform vendors 
and System-on-Chip vendors to fit new hardware configurations.


As SBI specifications evolve and extend beyond the current base legacy
features, OpenSBI will be modified to provide a reference implementation 
for new SBI specifications.


More information on OpenSBI capabilities as well as a contribution 
guideline are available in OpenSBI documentation included with the 
source code in GitHub.


[Github]: https://github.com/riscv/riscv-sbi-doc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] imx8mq-evk: Outbound network packets lost

2019-01-31 Thread Sergey Kubushyn

On Thu, 31 Jan 2019, Chris Spencer wrote:


On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn  wrote:

OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin
muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it
can't talk to the PHY or whatever else.

I don't know yet if there is some setting that I've missed to force it to do
pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk
board configs or board source files.

Once pin muxing is done in the board file FEC comes up as expected, finds
the PHY and all network stuff works as expected.

Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is
patched for regulator (regulator_set_enable instead of regulator_autoset)
and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets
it to "1" to reset then resets it to "0").

So it is either pin muxing is missing and one should do it in his board's
file or I've missed some setting that I can't find to get the DM FEC driver
to do it itself from DTS file.


Welp. There's no pinctrl driver. That would explain a lot...

The attached patches fix the networking in U-Boot for me (I can at
least ping; haven't tried anything else). If it works for you then I
will submit the patches properly with your Tested-by.

Weirdly, I still get the issue in Linux where it intermittently uses
the wrong phy driver, but, with this change, the generic phy driver
now seems to work fine. I guess maybe U-Boot is now leaving the phy in
a different state that happens to work.


OK, it worked. The second patch is irrelevant for me because I'm working on
a custom device, not MCIMX8M-EVK (I don't have that, just using its
schematic from time to time as reference to its drivers and such) and I
_DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without
actual driver...

I wonder how come nobody noticed that so far? It should affect other
functionality that relies on proper pin muxing...

Anyway, it is solved so I'm on USB (host and peripheral) now. Next come
PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Alexander Graf


> Am 31.01.2019 um 17:22 schrieb Bin Meng :
> 
> At present the 4-level page table base address for 64-bit U-Boot
> proper is assigned an address that conflicts with CONFIG_LOADADDR.
> Change it to an address within the low memory range instead.

Can't you dynamically allocate the PT too?

Alex

> 
> Fixes crashes seen when 'dhcp' on QEMU x86_64 with
> "-net nic -net user,tftp=.,bootfile=u-boot".
> 
> Reported-by: Alexander Graf 
> Signed-off-by: Bin Meng 
> ---
> 
> arch/x86/cpu/i386/cpu.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
> index 208ef08..af42431 100644
> --- a/arch/x86/cpu/i386/cpu.c
> +++ b/arch/x86/cpu/i386/cpu.c
> @@ -462,6 +462,7 @@ int cpu_has_64bit(void)
>has_long_mode();
> }
> 
> +#define PAGETABLE_BASE0x8
> #define PAGETABLE_SIZE(6 * 4096)
> 
> /**
> @@ -523,10 +524,7 @@ int cpu_jump_to_64bit_uboot(ulong target)
>uint32_t *pgtable;
>func_t func;
> 
> -/* TODO(s...@chromium.org): Find a better place for this */
> -pgtable = (uint32_t *)0x100;
> -if (!pgtable)
> -return -ENOMEM;
> +pgtable = (uint32_t *)PAGETABLE_BASE;
> 
>build_pagetable(pgtable);
> 
> -- 
> 2.7.4
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag

2019-01-31 Thread Heinrich Schuchardt
On 1/31/19 3:54 PM, Patrick Wildt wrote:
> On Thu, Jan 31, 2019 at 03:31:34PM +0100, Alexander Graf wrote:
>> On 01/31/2019 03:25 PM, Patrick Wildt wrote:
>>> On Sun, Dec 02, 2018 at 10:21:12PM +0100, Alexander Graf wrote:
 On 27.03.18 18:05, Heinrich Schuchardt wrote:
> On 03/27/2018 02:24 PM, Patrick Wildt wrote:
>> The PXE object contains a flag that specifies whether or not a DHCP
>> ACK has been received.  This can be used by EFI Applications to find
>> out whether or not it is worth to read the DHCP information from our
>> object.
>>
>> Signed-off-by: Patrick Wildt 
>> ---
>>   lib/efi_loader/efi_net.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
>> index 8c5d5b492c..0b9c7b9345 100644
>> --- a/lib/efi_loader/efi_net.c
>> +++ b/lib/efi_loader/efi_net.c
>> @@ -332,8 +332,10 @@ int efi_net_register(void)
>>  netobj->net_mode.max_packet_size = PKTSIZE;
>>  netobj->pxe.mode = >pxe_mode;
>> -if (dhcp_ack)
>> +if (dhcp_ack) {
>>  netobj->pxe_mode.dhcp_ack = *dhcp_ack;
>> +netobj->pxe_mode.dhcp_ack_received = 1;
>> +}
> We have received a DHCPOFFER and we now send a DHCPREQUEST to the
> selected server. This is when efi_net_set_dhcp_ack() is called which
> sets the variable dhcp_ack.
>
> If the server sustains its offer it responds with a DHCPACK or with a
> DHCPNACK. Shouldn't we ensure a DHCPACK was received (and not a DHCNACK)
> before setting dhcp_ack_received?
 Patrick, ping? :)

 Alex
>>> Sorry, I had a bit of other stuff to take care of and didn't get to it.
>>> Turns out the change is rather easy to do, since we can just add another
>>> function in the EFI subsystem to call once we receive the actual ACK.
>>> This version works for me.
>>>
>>> Patrick
>>>
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 53f08161ab..3dcfc4b16f 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -285,6 +285,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>>   /* Called by networking code to memorize the dhcp ack package */
>>>   void efi_net_set_dhcp_ack(void *pkt, int len);
>>> +/* Called by networking code to memorize we got an ack */
>>> +void efi_net_set_dhcp_ack_received(void);
>>>   /* Called by efi_set_watchdog_timer to reset the timer */
>>>   efi_status_t efi_set_watchdog(unsigned long timeout);
>>> diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
>>> index c7d9da8521..96610c768e 100644
>>> --- a/lib/efi_loader/efi_net.c
>>> +++ b/lib/efi_loader/efi_net.c
>>> @@ -15,6 +15,7 @@ static struct efi_pxe_packet *dhcp_ack;
>>>   static bool new_rx_packet;
>>>   static void *new_tx_packet;
>>>   static void *transmit_buffer;
>>> +static int dhcp_ack_received;
>>>   /*
>>>* The notification function of this event is called in every timer cycle
>>> @@ -536,6 +537,16 @@ void efi_net_set_dhcp_ack(void *pkt, int len)
>>> memcpy(dhcp_ack, pkt, min(len, maxsize));
>>>   }
>>> +/**
>>> + * efi_net_set_dhcp_ack_received() - take note of a received ACK
>>> + *
>>> + * This function is called by dhcp_handler().
>>> + */
>>> +void efi_net_set_dhcp_ack_received(void)

Do we really need multiple functions to update the DHCP status?

I would prefer a single function with a parameter telling which DHCP
status has been reached.

>>> +{
>>> +   dhcp_ack_received = 1;
>>
>> Is there any way to pass an object reference in as parameter that allows us
>> to find the exact efi net object back again? IIRC the network code was
>> pretty much single target, but maybe we don't have to encode that in every
>> single place ...
> 
> I agree, but I have to say that I don't know the u-boot code enough to
> know that.

The current network device can be determined via eth_get_dev().
In function eth_current_changed() this eth_get_dev() function is used to
update the ethact environment variable.

If we have a single update function we can determine the active network
device there.

Best regards

Heinrich

> 
>>> +}
>>> +
>>>   /**
>>>* efi_net_push() - callback for received network packet
>>>*
>>> @@ -645,8 +656,10 @@ efi_status_t efi_net_register(void)
>>> netobj->net_mode.if_type = ARP_ETHER;
>>> netobj->pxe.mode = >pxe_mode;
>>> -   if (dhcp_ack)
>>> +   if (dhcp_ack) {
>>> netobj->pxe_mode.dhcp_ack = *dhcp_ack;
>>> +   netobj->pxe_mode.dhcp_ack_received = dhcp_ack_received;
>>> +   }
>>> /*
>>>  * Create WaitForPacket event.
>>> diff --git a/net/bootp.c b/net/bootp.c
>>> index 9a2b512e4a..b0c26418ca 100644
>>> --- a/net/bootp.c
>>> +++ b/net/bootp.c
>>> @@ -1087,6 +1087,7 @@ static void dhcp_handler(uchar *pkt, unsigned dest, 
>>> struct in_addr sip,
>>> dhcp_packet_process_options(bp);
>>> /* Store net 

[U-Boot] [PATCH 4/5] dt: bcm63158: add watchdog

2019-01-31 Thread Philippe Reynes
This commit add watchdog and sysreset watchdog
in the bcm63158 device tree.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm63158.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/dts/bcm63158.dtsi b/arch/arm/dts/bcm63158.dtsi
index be68205..6a3fbc9 100644
--- a/arch/arm/dts/bcm63158.dtsi
+++ b/arch/arm/dts/bcm63158.dtsi
@@ -81,5 +81,22 @@
 
status = "disabled";
};
+
+   wdt1: watchdog@ff800480 {
+   compatible = "brcm,bcm6345-wdt";
+   reg = <0x0 0xff800480 0x0 0x14>;
+   clocks = <_osc>;
+   };
+
+   wdt2: watchdog@ff8004c0 {
+   compatible = "brcm,bcm6345-wdt";
+   reg = <0x0 0xff8004c0 0x0 0x14>;
+   clocks = <_osc>;
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   };
};
 };
-- 
2.7.4

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


[U-Boot] [PATCH 5/5] bcm963158: enable watchdog and reboot with watchdog

2019-01-31 Thread Philippe Reynes
Enable watchdog and reboot with watchdog in the configuration.

Signed-off-by: Philippe Reynes 
---
 configs/bcm963158_ram_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig
index 6e3b688..9083f1d 100644
--- a/configs/bcm963158_ram_defconfig
+++ b/configs/bcm963158_ram_defconfig
@@ -36,5 +36,7 @@ CONFIG_DM_SERIAL=y
 CONFIG_SERIAL_SEARCH_ALL=y
 CONFIG_PL01X_SERIAL=y
 CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
+CONFIG_WDT_BCM6345=y
 CONFIG_REGEX=y
 # CONFIG_GENERATE_SMBIOS_TABLE is not set
-- 
2.7.4

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


[U-Boot] [PATCH 3/5] watchdog: bcm6345: allow to use this driver on arm bcm63158

2019-01-31 Thread Philippe Reynes
This IP is also used on some arm SoC, so we allow to
use it on arm bcm63158 too.

Signed-off-by: Philippe Reynes 
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9456abd..115fc45 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -88,7 +88,7 @@ config WDT_ASPEED
 
 config WDT_BCM6345
bool "BCM6345 watchdog timer support"
-   depends on WDT && (ARCH_BMIPS || ARCH_BCM6858)
+   depends on WDT && (ARCH_BMIPS || ARCH_BCM6858 || ARCH_BCM63158)
help
  Select this to enable watchdog timer for BCM6345 SoCs.
  The watchdog timer is stopped when initialized.
-- 
2.7.4

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


[U-Boot] [PATCH 2/5] bcm963158: add initial support

2019-01-31 Thread Philippe Reynes
This add the initial support of the broadcom reference
board bcm963158 with a bcm63158 SoC.

This board has 1 GB of ram, 512 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).

Signed-off-by: Philippe Reynes 
---
 arch/arm/Kconfig |  1 +
 arch/arm/dts/bcm963158.dts   | 31 ++
 board/broadcom/bcm963158/Kconfig | 17 ++
 board/broadcom/bcm963158/MAINTAINERS |  6 
 board/broadcom/bcm963158/Makefile|  3 ++
 board/broadcom/bcm963158/bcm963158.c | 61 
 configs/bcm963158_ram_defconfig  | 40 +++
 include/configs/broadcom_bcm963158.h | 37 ++
 8 files changed, 196 insertions(+)
 create mode 100644 arch/arm/dts/bcm963158.dts
 create mode 100644 board/broadcom/bcm963158/Kconfig
 create mode 100644 board/broadcom/bcm963158/MAINTAINERS
 create mode 100644 board/broadcom/bcm963158/Makefile
 create mode 100644 board/broadcom/bcm963158/bcm963158.c
 create mode 100644 configs/bcm963158_ram_defconfig
 create mode 100644 include/configs/broadcom_bcm963158.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4316de0..455f06c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1532,6 +1532,7 @@ source "board/armltd/vexpress/Kconfig"
 source "board/armltd/vexpress64/Kconfig"
 source "board/broadcom/bcm23550_w1d/Kconfig"
 source "board/broadcom/bcm28155_ap/Kconfig"
+source "board/broadcom/bcm963158/Kconfig"
 source "board/broadcom/bcm968580xref/Kconfig"
 source "board/broadcom/bcmcygnus/Kconfig"
 source "board/broadcom/bcmnsp/Kconfig"
diff --git a/arch/arm/dts/bcm963158.dts b/arch/arm/dts/bcm963158.dts
new file mode 100644
index 000..dc5afb5
--- /dev/null
+++ b/arch/arm/dts/bcm963158.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Philippe Reynes 
+ */
+
+/dts-v1/;
+
+#include "bcm63158.dtsi"
+
+/ {
+   model = "Broadcom bcm963158";
+   compatible = "broadcom,bcm963158", "brcm,bcm63158";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
diff --git a/board/broadcom/bcm963158/Kconfig b/board/broadcom/bcm963158/Kconfig
new file mode 100644
index 000..41b6adb
--- /dev/null
+++ b/board/broadcom/bcm963158/Kconfig
@@ -0,0 +1,17 @@
+if ARCH_BCM63158
+
+config SYS_VENDOR
+   default "broadcom"
+
+config SYS_BOARD
+   default "bcm963158"
+
+config SYS_CONFIG_NAME
+   default "broadcom_bcm963158"
+
+endif
+
+config TARGET_BCM963158
+   bool "Support Broadcom bcm963158"
+   depends on ARCH_BCM63158
+   select ARM64
diff --git a/board/broadcom/bcm963158/MAINTAINERS 
b/board/broadcom/bcm963158/MAINTAINERS
new file mode 100644
index 000..d28d971
--- /dev/null
+++ b/board/broadcom/bcm963158/MAINTAINERS
@@ -0,0 +1,6 @@
+BROADCOM BCM963158
+M: Philippe Reynes 
+S: Maintained
+F: board/broadcom/bcm963158/
+F: include/configs/broadcom_bcm963158.h
+F: configs/bcm963158_ram_defconfig
diff --git a/board/broadcom/bcm963158/Makefile 
b/board/broadcom/bcm963158/Makefile
new file mode 100644
index 000..0a902c9
--- /dev/null
+++ b/board/broadcom/bcm963158/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y  += bcm963158.o
diff --git a/board/broadcom/bcm963158/bcm963158.c 
b/board/broadcom/bcm963158/bcm963158.c
new file mode 100644
index 000..db82cd5
--- /dev/null
+++ b/board/broadcom/bcm963158/bcm963158.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Philippe Reynes 
+ */
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_ARM64
+#include 
+
+static struct mm_region broadcom_bcm963158_mem_map[] = {
+   {
+   /* RAM */
+   .virt = 0xUL,
+   .phys = 0xUL,
+   .size = 8UL * SZ_1G,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   /* SoC */
+   .virt = 0x8000UL,
+   .phys = 0x8000UL,
+   .size = 0xff8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = broadcom_bcm963158_mem_map;
+#endif
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   if (fdtdec_setup_mem_size_base() != 0)
+   printf("fdtdec_setup_mem_size_base() has failed\n");
+
+   return 0;
+}
+
+int dram_init_banksize(void)
+{
+   fdtdec_setup_memory_banksize();
+
+   return 0;
+}
+
+int print_cpuinfo(void)
+{

[U-Boot] [PATCH 1/5] bcm63158: add initial support

2019-01-31 Thread Philippe Reynes
This add the initial support of the broadcom bcm63158 SoC family,
only the cpu, dram and uart are supported.

Signed-off-by: Philippe Reynes 
---
 arch/arm/Kconfig   |  6 
 arch/arm/dts/bcm63158.dtsi | 85 ++
 2 files changed, 91 insertions(+)
 create mode 100644 arch/arm/dts/bcm63158.dtsi

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f0edb10..4316de0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -528,6 +528,12 @@ config ARCH_BCM283X
imply CMD_DM
imply FAT_WRITE
 
+config ARCH_BCM63158
+   bool "Broadcom BCM63158 family"
+   select DM
+   select OF_CONTROL
+   imply CMD_DM
+
 config ARCH_BCM6858
bool "Broadcom BCM6858 family"
select DM
diff --git a/arch/arm/dts/bcm63158.dtsi b/arch/arm/dts/bcm63158.dtsi
new file mode 100644
index 000..be68205
--- /dev/null
+++ b/arch/arm/dts/bcm63158.dtsi
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Philippe Reynes 
+ */
+
+#include "skeleton64.dtsi"
+
+/ {
+   compatible = "brcm,bcm63158";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+   u-boot,dm-pre-reloc;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x0>;
+   next-level-cache = <>;
+   u-boot,dm-pre-reloc;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x1>;
+   next-level-cache = <>;
+   u-boot,dm-pre-reloc;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x2>;
+   next-level-cache = <>;
+   u-boot,dm-pre-reloc;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x3>;
+   next-level-cache = <>;
+   u-boot,dm-pre-reloc;
+   };
+
+   l2: l2-cache0 {
+   compatible = "cache";
+   u-boot,dm-pre-reloc;
+   };
+   };
+
+   clocks {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   u-boot,dm-pre-reloc;
+
+   periph_osc: periph-osc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0xbebc200>;
+   u-boot,dm-pre-reloc;
+   };
+   };
+
+   ubus {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   u-boot,dm-pre-reloc;
+
+   uart0: serial@ff812000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x0 0xff812000 0x0 0x1000>;
+   clock = <5000>;
+
+   status = "disabled";
+   };
+   };
+};
-- 
2.7.4

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


Re: [U-Boot] [PATCH v3 16/20] mtd: spi: Add lightweight SPI flash stack for SPL

2019-01-31 Thread Vignesh R


On 31/01/19 5:36 PM, Jagan Teki wrote:
> On Tue, Jan 29, 2019 at 11:29 AM Vignesh R  wrote:
>>
>> Add a tiny SPI flash stack that just supports reading data/images from
>> SPI flash. This is useful for boards that have SPL size constraints and
>> would need to use SPI flash framework just to read images/data from
>> flash. There is approximately 1.5 to 2KB savings with this.
>>
>> Based on prior work of reducing spi flash id table by
>> Simon Goldschmidt 
>>
>> Signed-off-by: Vignesh R 
>> Tested-by: Simon Goldschmidt 
>> Tested-by: Stefan Roese 
>> Tested-by: Horatiu Vultur 
>> ---
>>  common/spl/Kconfig |  11 +-
>>  drivers/mtd/spi/Makefile   |  10 +-
>>  drivers/mtd/spi/sf_internal.h  |   2 +
>>  drivers/mtd/spi/spi-nor-core.c | 266 +--
>>  drivers/mtd/spi/spi-nor-ids.c  | 297 
>>  drivers/mtd/spi/spi-nor-tiny.c | 810 +
>>  6 files changed, 1132 insertions(+), 264 deletions(-)
>>  create mode 100644 drivers/mtd/spi/spi-nor-ids.c
>>  create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
>>
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index 2e1dd2705a62..416f5933b0d9 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -732,9 +732,18 @@ config SPL_SPI_FLASH_SUPPORT
>>
>>  if SPL_SPI_FLASH_SUPPORT
>>
>> +config SPL_SPI_FLASH_TINY
>> +   bool "Enable low footprint SPL SPI Flash support"
>> +   depends on !SPI_FLASH_BAR
>> +   help
>> +Enable lightweight SPL SPI Flash support that supports just reading
>> +data/images from flash. No support to write/erase flash. Enable
>> +this if you have SPL size limitations and don't need full
>> +fledged SPI flash support.
>> +
>>  config SPL_SPI_FLASH_SFDP_SUPPORT
>> bool "SFDP table parsing support for SPI NOR flashes"
>> -   depends on !SPI_FLASH_BAR
>> +   depends on !SPI_FLASH_BAR && !SPL_SPI_FLASH_TINY
>> help
>>  Enable support for parsing and auto discovery of parameters for
>>  SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
>> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
>> index 70058d3df2b9..f99f6cb16e29 100644
>> --- a/drivers/mtd/spi/Makefile
>> +++ b/drivers/mtd/spi/Makefile
>> @@ -4,12 +4,20 @@
>>  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>
>>  obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
>> +spi-nor-y := sf_probe.o spi-nor-ids.o
>>
>>  ifdef CONFIG_SPL_BUILD
>>  obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>> +ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
>> +spi-nor-y += spi-nor-tiny.o
>> +else
>> +spi-nor-y += spi-nor-core.o
>> +endif
>> +else
>> +spi-nor-y += spi-nor-core.o
>>  endif
>>
>> -obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
>> +obj-$(CONFIG_SPI_FLASH) += spi-nor.o
>>  obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
>>  obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
>>  obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
>> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
>> index fd00e0d1b23b..a6bf734830a7 100644
>> --- a/drivers/mtd/spi/sf_internal.h
>> +++ b/drivers/mtd/spi/sf_internal.h
>> @@ -16,7 +16,9 @@
>>  #define SPI_NOR_MAX_ADDR_WIDTH 4
>>
>>  struct flash_info {
>> +#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
>> char*name;
>> +#endif
>>
>> /*
>>  * This array stores the ID bytes.
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index dbaaf45c7e1e..80633f8fd070 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -879,284 +879,26 @@ static int stm_is_locked(struct spi_nor *nor, loff_t 
>> ofs, uint64_t len)
>>  }
>>  #endif /* CONFIG_SPI_FLASH_STMICRO */
>>
>> -/* Used when the "_ext_id" is two bytes at most */
>> -#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
>> -   .id = { \
>> -   ((_jedec_id) >> 16) & 0xff, \
>> -   ((_jedec_id) >> 8) & 0xff,  \
>> -   (_jedec_id) & 0xff, \
>> -   ((_ext_id) >> 8) & 0xff,\
>> -   (_ext_id) & 0xff,   \
>> -   },  \
>> -   .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),
>>\
>> -   .sector_size = (_sector_size),  \
>> -   .n_sectors = (_n_sectors),  \
>> -   .page_size = 256,   \
>> -   .flags = (_flags),
>> -
>> -#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)\
>> -   .id = { \
>> -   ((_jedec_id) >> 16) & 

[U-Boot] [PATCH 3/3] ARM: rmobile: Add possibility to debug main PSCI commands

2019-01-31 Thread Oleksandr Tyshchenko
From: Oleksandr Tyshchenko 

Also take care of the fact that Lager and Stout boards use
different serial interface for console.

Signed-off-by: Oleksandr Tyshchenko 
---
 arch/arm/mach-rmobile/debug.h | 91 +++
 arch/arm/mach-rmobile/psci.c  | 23 +++
 2 files changed, 114 insertions(+)
 create mode 100644 arch/arm/mach-rmobile/debug.h

diff --git a/arch/arm/mach-rmobile/debug.h b/arch/arm/mach-rmobile/debug.h
new file mode 100644
index 000..5d4ec77
--- /dev/null
+++ b/arch/arm/mach-rmobile/debug.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Contains functions used for PSCI debug.
+ *
+ * Copyright (C) 2018 EPAM Systems Inc.
+ *
+ * Based on arch/arm/mach-uniphier/debug.h
+ */
+
+#ifndef __DEBUG_H__
+#define __DEBUG_H__
+
+#include 
+
+/* SCIFA definitions */
+#define SCIFA_BASE 0xe6c4
+
+#define SCIFA_SCASSR   0x14/* Serial status register */
+#define SCIFA_SCAFTDR  0x20/* Transmit FIFO data register */
+
+/* SCIF definitions */
+#define SCIF_BASE  0xe6e6
+
+#define SCIF_SCFSR 0x10/* Serial status register */
+#define SCIF_SCFTDR0x0c/* Transmit FIFO data register */
+
+/* Common for both interfaces definitions */
+#define SCFSR_TDFE BIT(5) /* Transmit FIFO Data Empty */
+#define SCFSR_TEND BIT(6) /* Transmission End */
+
+#ifdef CONFIG_SCIF_A
+#define UART_BASE  SCIFA_BASE
+#define UART_STATUS_REGSCIFA_SCASSR
+#define UART_TX_FIFO_REG   SCIFA_SCAFTDR
+#else
+#define UART_BASE  SCIF_BASE
+#define UART_STATUS_REGSCIF_SCFSR
+#define UART_TX_FIFO_REG   SCIF_SCFTDR
+#endif
+
+/* All functions are inline so that they can be called from .secure section. */
+
+#ifdef DEBUG
+static inline void debug_putc(int c)
+{
+   void __iomem *base = (void __iomem *)UART_BASE;
+
+   while (!(readw(base + UART_STATUS_REG) & SCFSR_TDFE))
+   ;
+
+   writeb(c, base + UART_TX_FIFO_REG);
+   writew(readw(base + UART_STATUS_REG) & ~(SCFSR_TEND | SCFSR_TDFE),
+  base + UART_STATUS_REG);
+}
+
+static inline void debug_puts(const char *s)
+{
+   while (*s) {
+   if (*s == '\n')
+   debug_putc('\r');
+
+   debug_putc(*s++);
+   }
+}
+
+static inline void debug_puth(unsigned long val)
+{
+   int i;
+   unsigned char c;
+
+   for (i = 8; i--; ) {
+   c = ((val >> (i * 4)) & 0xf);
+   c += (c >= 10) ? 'a' - 10 : '0';
+   debug_putc(c);
+   }
+}
+#else
+static inline void debug_putc(int c)
+{
+}
+
+static inline void debug_puts(const char *s)
+{
+}
+
+static inline void debug_puth(unsigned long val)
+{
+}
+#endif
+
+#endif /* __DEBUG_H__ */
diff --git a/arch/arm/mach-rmobile/psci.c b/arch/arm/mach-rmobile/psci.c
index 95850b8..4d78b0f 100644
--- a/arch/arm/mach-rmobile/psci.c
+++ b/arch/arm/mach-rmobile/psci.c
@@ -14,6 +14,7 @@
 #include 
 
 #include "pm-r8a7790.h"
+#include "debug.h"
 
 #define R8A7790_PSCI_NR_CPUS   8
 #if R8A7790_PSCI_NR_CPUS > CONFIG_ARMV7_PSCI_NR_CPUS
@@ -105,6 +106,16 @@ int __secure psci_cpu_on(u32 function_id, u32 target_cpu, 
u32 entry_point,
 {
int cpu;
 
+   debug_puts("[U-Boot PSCI] cpu_on: cpu=");
+   debug_puth(get_current_cpu());
+   debug_puts(", target_cpu=");
+   debug_puth(target_cpu);
+   debug_puts(", entry_point=");
+   debug_puth(entry_point);
+   debug_puts(", context_id=");
+   debug_puth(context_id);
+   debug_puts("\n");
+
cpu = mpidr_to_cpu_index(target_cpu);
if (cpu == -1)
return ARM_PSCI_RET_INVAL;
@@ -130,6 +141,10 @@ int __secure psci_cpu_off(void)
 {
int cpu = get_current_cpu();
 
+   debug_puts("[U-Boot PSCI] cpu_off: cpu=");
+   debug_puth(cpu);
+   debug_puts("\n");
+
/*
 * Place the CPU interface in a state where it can never make a CPU
 * exit WFI as result of an asserted interrupt.
@@ -154,6 +169,10 @@ int __secure psci_cpu_off(void)
 
 void __secure psci_system_reset(u32 function_id)
 {
+   debug_puts("[U-Boot PSCI] system_reset: cpu=");
+   debug_puth(get_current_cpu());
+   debug_puts("\n");
+
r8a7790_system_reset();
 
/* Drain the WB before WFI */
@@ -166,6 +185,10 @@ void __secure psci_system_reset(u32 function_id)
 
 void __secure psci_system_off(u32 function_id)
 {
+   debug_puts("[U-Boot PSCI] system_off: cpu=");
+   debug_puth(get_current_cpu());
+   debug_puts("\n");
+
/* Drain the WB before WFI */
dsb();
 
-- 
2.7.4

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


[U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

2019-01-31 Thread Oleksandr Tyshchenko
From: Oleksandr Tyshchenko 

Also enable PSCI support for Stout and Lager boards where
actually the r8a7790 SoC is installed.

All secondary CPUs will be switched to a non-secure HYP mode
after booting.

Signed-off-by: Oleksandr Tyshchenko 
---
 arch/arm/mach-rmobile/Kconfig.32   |   2 +
 arch/arm/mach-rmobile/Makefile |   6 +
 arch/arm/mach-rmobile/pm-r8a7790.c | 408 +
 arch/arm/mach-rmobile/pm-r8a7790.h |  72 +++
 arch/arm/mach-rmobile/psci.c   | 193 ++
 include/configs/lager.h|   2 +
 include/configs/stout.h|   2 +
 7 files changed, 685 insertions(+)
 create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.c
 create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.h
 create mode 100644 arch/arm/mach-rmobile/psci.c

diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index a2e9e3d..728c323 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -78,6 +78,7 @@ config TARGET_LAGER
imply CMD_DM
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
+   select ARCH_SUPPORT_PSCI
 
 config TARGET_KZM9G
bool "KZM9D board"
@@ -119,6 +120,7 @@ config TARGET_STOUT
imply CMD_DM
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
+   select ARCH_SUPPORT_PSCI
 
 endchoice
 
diff --git a/arch/arm/mach-rmobile/Makefile b/arch/arm/mach-rmobile/Makefile
index 1f26ada..6f4c513 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -13,3 +13,9 @@ obj-$(CONFIG_SH73A0) += lowlevel_init.o cpu_info-sh73a0.o 
pfc-sh73a0.o
 obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
 obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
 obj-$(CONFIG_RCAR_GEN3) += lowlevel_init_gen3.o cpu_info-rcar.o memmap-gen3.o
+
+ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_R8A7790
+obj-$(CONFIG_ARMV7_PSCI) += psci.o pm-r8a7790.o
+endif
+endif
diff --git a/arch/arm/mach-rmobile/pm-r8a7790.c 
b/arch/arm/mach-rmobile/pm-r8a7790.c
new file mode 100644
index 000..c635cf6
--- /dev/null
+++ b/arch/arm/mach-rmobile/pm-r8a7790.c
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CPU power management support for Renesas r8a7790 SoC
+ *
+ * Contains functions to control ARM Cortex A15/A7 cores and
+ * related peripherals basically used for PSCI.
+ *
+ * Copyright (C) 2018 EPAM Systems Inc.
+ *
+ * Mainly based on Renesas R-Car Gen2 platform code from Linux:
+ *arch/arm/mach-shmobile/...
+ */
+
+#include 
+#include 
+#include 
+
+#include "pm-r8a7790.h"
+
+/*
+ * APMU definitions
+ */
+#define CA15_APMU_BASE 0xe6152000
+#define CA7_APMU_BASE  0xe6151000
+
+/* Wake Up Control Register */
+#define WUPCR_OFFS 0x10
+/* Power Status Register */
+#define PSTR_OFFS  0x40
+/* CPUn Power Status Control Register */
+#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
+
+#define CPUPWR_STANDBY 0x3
+
+/* Debug Resource Reset Control Register */
+#define DBGRCR_OFFS0x180
+
+#define DBGCPUREN  BIT(24) /* CPU Other Reset Req Enable */
+#define DBGCPUNREN(n)  BIT((n) + 20)   /* CPUn Reset Req Enable */
+#define DBGCPUPREN BIT(19) /* CPU Peripheral Reset Req Enable */
+
+/*
+ * RST definitions
+ */
+#define RST_BASE   0xe616
+
+/* Boot Address Registers */
+#define CA15BAR0x20
+#define CA7BAR 0x30
+
+/* Reset Control Registers */
+#define CA15RESCNT 0x40
+#define CA7RESCNT  0x44
+
+#define CA15RESCNT_CODE0xa5a5
+#define CA7RESCNT_CODE 0x5a5a
+
+/* SYS Boot Address Register */
+#define SBAR_BAREN BIT(4)  /* SBAR is valid */
+
+/* Watchdog Timer Reset Control Register */
+#define WDTRSTCR   0x54
+
+#define WDTRSTCR_CODE  0xa55a
+
+/*
+ * SYSC definitions
+ */
+#define SYSC_BASE  0xe618
+
+/* SYSC Status Register */
+#define SYSCSR 0x00
+/* Interrupt Status Register */
+#define SYSCISR0x04
+/* Interrupt Status Clear Register */
+#define SYSCISCR   0x08
+/* Interrupt Enable Register */
+#define SYSCIER0x0c
+/* Interrupt Mask Register */
+#define SYSCIMR0x10
+
+/* Power Status Register */
+#define PWRSR_OFFS 0x00
+/* Power Resume Control Register */
+#define PWRONCR_OFFS   0x0c
+/* Power Shutoff/Resume Error Register */
+#define PWRER_OFFS 0x14
+
+/* PWRSR5 .. PWRER5 */
+#define CA15_SCU_CHAN_OFFS 0x180
+/* PWRSR3 .. PWRER3 */
+#define 

[U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

2019-01-31 Thread Oleksandr Tyshchenko
From: Oleksandr Tyshchenko 

Both Lager and Stout boards are based on r8a7790 SoC.

Leave platform specific functions for bringing seconadary CPUs up empty,
since our target is to use PSCI for that.

Also take care of updating arch timer while we are in secure mode.

Signed-off-by: Oleksandr Tyshchenko 
---
 arch/arm/mach-rmobile/Kconfig.32 |  4 
 board/renesas/lager/lager.c  | 51 
 board/renesas/stout/stout.c  | 51 
 include/configs/lager.h  |  3 +++
 include/configs/stout.h  |  3 +++
 5 files changed, 112 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index 076a019..a2e9e3d 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -76,6 +76,8 @@ config TARGET_LAGER
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
 
 config TARGET_KZM9G
bool "KZM9D board"
@@ -115,6 +117,8 @@ config TARGET_STOUT
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
 
 endchoice
 
diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index 062e88c..9b96cc4 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -76,6 +76,53 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_ARMV7_NONSEC
+#define TIMER_BASE 0xE608
+#define TIMER_CNTCR0x00
+#define TIMER_CNTFID0  0x20
+
+/*
+ * Taking into the account that arch timer is only configurable in secure mode
+ * and we are going to enter kernel/hypervisor in a non-secure mode, update
+ * arch timer right now to avoid possible issues. Make sure arch timer is
+ * enabled and configured to use proper frequency.
+ */
+static void rcar_gen2_timer_init(void)
+{
+   u32 freq = RMOBILE_XTAL_CLK / 2;
+
+   /*
+* Update the arch timer if it is either not running, or is not at the
+* right frequency.
+*/
+   if ((readl(TIMER_BASE + TIMER_CNTCR) & 1) == 0 ||
+   readl(TIMER_BASE + TIMER_CNTFID0) != freq) {
+   /* Update registers with correct frequency */
+   writel(freq, TIMER_BASE + TIMER_CNTFID0);
+   asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+   /* Make sure arch timer is started by setting bit 0 of CNTCR */
+   writel(1, TIMER_BASE + TIMER_CNTCR);
+   }
+}
+
+/*
+ * In order not to break compilation if someone decides to build with PSCI
+ * support disabled, keep these dummy functions.
+ */
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+}
+
+void smp_kick_all_cpus(void)
+{
+}
+
+void smp_waitloop(unsigned int previous_address)
+{
+}
+#endif
+
 #define ETHERNET_PHY_RESET 185 /* GPIO 5 31 */
 
 int board_init(void)
@@ -89,6 +136,10 @@ int board_init(void)
mdelay(10);
gpio_direction_output(ETHERNET_PHY_RESET, 1);
 
+#ifdef CONFIG_ARMV7_NONSEC
+   rcar_gen2_timer_init();
+#endif
+
return 0;
 }
 
diff --git a/board/renesas/stout/stout.c b/board/renesas/stout/stout.c
index 85e30db..8d034a8 100644
--- a/board/renesas/stout/stout.c
+++ b/board/renesas/stout/stout.c
@@ -77,6 +77,53 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_ARMV7_NONSEC
+#define TIMER_BASE 0xE608
+#define TIMER_CNTCR0x00
+#define TIMER_CNTFID0  0x20
+
+/*
+ * Taking into the account that arch timer is only configurable in secure mode
+ * and we are going to enter kernel/hypervisor in a non-secure mode, update
+ * arch timer right now to avoid possible issues. Make sure arch timer is
+ * enabled and configured to use proper frequency.
+ */
+static void rcar_gen2_timer_init(void)
+{
+   u32 freq = RMOBILE_XTAL_CLK / 2;
+
+   /*
+* Update the arch timer if it is either not running, or is not at the
+* right frequency.
+*/
+   if ((readl(TIMER_BASE + TIMER_CNTCR) & 1) == 0 ||
+   readl(TIMER_BASE + TIMER_CNTFID0) != freq) {
+   /* Update registers with correct frequency */
+   writel(freq, TIMER_BASE + TIMER_CNTFID0);
+   asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+   /* Make sure arch timer is started by setting bit 0 of CNTCR */
+   writel(1, TIMER_BASE + TIMER_CNTCR);
+   }
+}
+
+/*
+ * In order not to break compilation if someone decides to build with PSCI
+ * support disabled, keep these dummy functions.
+ */
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+}
+
+void smp_kick_all_cpus(void)
+{
+}
+
+void smp_waitloop(unsigned int previous_address)
+{
+}
+#endif
+
 #define ETHERNET_PHY_RESET 123 /* GPIO 3 31 */
 
 int board_init(void)
@@ -92,6 +139,10 @@ int board_init(void)
mdelay(20);
  

[U-Boot] [PATCH 0/3] PSCI support for r8a7790 SoC (Lager/Stout boards)

2019-01-31 Thread Oleksandr Tyshchenko
From: Oleksandr Tyshchenko 

Hi, all.

The purpose of this patch series is to add PSCI support for Renesas boards
based on R-Car Gen2 r8a7790 SoC. Actually, our target in Stout board, but as
Lager board is also based on the same SoC, that patch series covers both.

The main goal of using PSCI is to have common interface to boot CPUs
from Hypervisor/Linux. PSCI is a generic well-known way to bring-up CPU
and proven to work. With this patch series applied all CPUs will be switched to
a non-secure Hypervisor mode. For running Type 1 Hypervisor (e.g. Xen) it is
mandatory requirement. From other side, there are recommendation to boot Linux
in Hypervisor mode on ARM. This allows KVM or other Hypervisor (e.g. Jailhouse)
to be useable on the platform. If there are no Hypervisor present, Linux will
just initialize the Hypervisor mode correctly and drop to Supervisor mode.

Till now, we have been using a *custom solution* for running Xen Hypervisor
on Lager/Stout boards, which requires a specific U-Boot version (which performs
СPUs boot in a non-generic way) and different hacks into R-Car Gen2 platform
code in Linux. We have a situation where different methods are used in order
to boot CPUs from Xen/Linux. Which results in a forced switching between 
different
U-Boot versions, when we need to switch between bare Linux and Xen,
which is quite inconvenient. This should be totally transparent to the user.

--

Current patch series is based on the following commit:
425c0a43fbbec36571f6a03b530695b8b16a841d “Prepare v2019.01-rc3”

It was tested with bare Linux 5.0.0-rc3 and Xen 4.12.0-rc with Linux 5.0.0-rc3
as guest OS. Everything worked as expected.
In case of bare Linux, all CPU cores started in HYP mode and PSCI checker
confirmed that hotplug tests had successfully passed.

Just one note. For each secondary CPU boot, Linux complains about
“Spectre v2: firmware did not set auxiliary control register IBE bit,
system vulnerable”.
Probably because the corresponding ARM errata 
(CONFIG_ARM_CORTEX_A15_CVE_2017_5715, etc)
is not propagated to non-boot (secondary) CPUs.

You can also find patch series here (last 3 patches):
https://github.com/otyshchenko1/u-boot/commits/r8a7790_psci_upstream

--

Please note:
1. Current patch series implies corresponding changes to Linux.

You can find them here (last 2 patches):
https://github.com/otyshchenko1/linux/commits/psci_upstream

I am about to push them as well.

2. As PSCI code expects a bigger “Maximum supported CPUs for PSCI” value (8)
than default option (4), you will get a compilation error:
arch/arm/mach-rmobile/psci.c:21:2: error: #error "invalid value for 
CONFIG_ARMV7_PSCI_NR_CPUS"
#error "invalid value for CONFIG_ARMV7_PSCI_NR_CPUS"

To resolve it, just run make menuconfig, set this option to 8
(or change in .config directly) and recompile.

--

Oleksandr Tyshchenko (3):
  ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based
boards
  ARM: rmobile: Add basic PSCI support for r8a7790 SoC
  ARM: rmobile: Add possibility to debug main PSCI commands

 arch/arm/mach-rmobile/Kconfig.32   |   6 +
 arch/arm/mach-rmobile/Makefile |   6 +
 arch/arm/mach-rmobile/debug.h  |  91 +
 arch/arm/mach-rmobile/pm-r8a7790.c | 408 +
 arch/arm/mach-rmobile/pm-r8a7790.h |  72 +++
 arch/arm/mach-rmobile/psci.c   | 216 
 board/renesas/lager/lager.c|  51 +
 board/renesas/stout/stout.c|  51 +
 include/configs/lager.h|   5 +
 include/configs/stout.h|   5 +
 10 files changed, 911 insertions(+)
 create mode 100644 arch/arm/mach-rmobile/debug.h
 create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.c
 create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.h
 create mode 100644 arch/arm/mach-rmobile/psci.c

-- 
2.7.4

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


Re: [U-Boot] [PATCH v3 19/20] configs: Don't use SPI_FLASH_BAR as default

2019-01-31 Thread Vignesh R


On 31/01/19 7:20 PM, Jagan Teki wrote:
> On Thu, 31 Jan, 2019, 7:16 PM Vignesh R   wrote:
> 
> On 31/01/19 7:06 PM, Jagan Teki wrote:
> [...]
> >     >>  configs/xilinx_zynqmp_mini_qspi_defconfig        | 1 -
> >     >>  configs/xilinx_zynqmp_zc1232_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zc1254_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zc1275_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zc1275_revB_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 -
> >     >>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 -
> >     >>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 -
> >     >>  configs/xilinx_zynqmp_zcu100_revC_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu102_rev1_0_defconfig    | 1 -
> >     >>  configs/xilinx_zynqmp_zcu102_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu102_revB_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu104_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu104_revC_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu106_revA_defconfig      | 1 -
> >     >>  configs/xilinx_zynqmp_zcu111_revA_defconfig      | 1 -
> >     >>  configs/zynq_cc108_defconfig                     | 1 -
> >     >>  configs/zynq_cse_qspi_defconfig                  | 1 -
> >     >>  configs/zynq_dlc20_rev1_0_defconfig              | 1 -
> >     >>  configs/zynq_microzed_defconfig                  | 1 -
> >     >>  configs/zynq_minized_defconfig                   | 1 -
> >     >>  configs/zynq_z_turn_defconfig                    | 1 -
> >     >>  configs/zynq_zc702_defconfig                     | 1 -
> >     >>  configs/zynq_zc706_defconfig                     | 1 -
> >     >>  configs/zynq_zc770_xm010_defconfig               | 1 -
> >     >>  configs/zynq_zc770_xm013_defconfig               | 1 -
> >     >>  configs/zynq_zed_defconfig                       | 1 -
> >     >>  configs/zynq_zybo_defconfig                      | 1 -
> >     >>  configs/zynq_zybo_z7_defconfig                   | 1 -
> >     >
> >     > zynq targets do need BAR, same has commented in previous mails.
> >
> >     Hmmm, Is this a  limitation of SPI controller on the SoC or
> flash on the
> >     board?
> >     AFAICS, zynq_spi.c, zynq_qspi.c zynq_spi.c zynqmp_gqspi.c are
> all FIFO
> >     based SPI controllers and ideally should not care about
> address length.
> >     Could you please explain why BAR is a requirement on these
> platforms?
> >
> >     Were you able to test this series on any of those platforms?
> >
> >
> > Go back to the log history, initial intension for adding BAR was
> on zynq.
> >
> 
> 
> Sorry, this is all I could find from mailing list (original series by
> you that adds BAR support):
> https://lists.denx.de/pipermail/u-boot/2013-June/157006.html
> 
> There is nothing that mentions why Zynq platforms need BAR support and
> cannot use 4 byte opcodes to access >16MB space?
> 
> 
> Yes, zynq qspi ia unable to handle larger than 16MiB flashes so we used
> BAR to access those.
> 

I wonder how those boards work in kernel that does not support BAR.
Anyways, if you provide a list of SPI controllers on zynq SoCs, I will
add an  imply SPI_FLASH_BAR for such Kconfigs and send a separate patch.

> Michal, Siva: can you confirm?
> 
> 



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


Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Heinrich Schuchardt
On 1/31/19 5:22 PM, Bin Meng wrote:
> At present the 4-level page table base address for 64-bit U-Boot
> proper is assigned an address that conflicts with CONFIG_LOADADDR.
> Change it to an address within the low memory range instead.
> 
> Fixes crashes seen when 'dhcp' on QEMU x86_64 with
> "-net nic -net user,tftp=.,bootfile=u-boot".
> 
> Reported-by: Alexander Graf 
> Signed-off-by: Bin Meng 

Thanks for addressing this. It fixes the problem reported in

x86: #define CONFIG_LOADADDR 0x110
https://lists.denx.de/pipermail/u-boot/2019-January/356108.html

I have set aforementioned patch to superseded.

Tested on qemu-x86_64.

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


Re: [U-Boot] Nand boot on imx6q board is broken

2019-01-31 Thread Adam Ford
On Thu, Jan 31, 2019 at 7:58 AM Shyam Saini  wrote:
>
> Hi Adam,
>
> Thanks a lot for replying.
>
> >
> > I spent some time trying to make the imx6q_logic board boot from SPL
> > from NAND, but I needed to patch a few things.   Some of them have yet
> > to be approved, but if they work for you, maybe it will help get them
> > approved.
> >
> > There was a broken function pointer here that was fixed and applied
> > the imx-master, but pending merge with master
> > http://patchwork.ozlabs.org/patch/1019440/
> >
> > Configure ECC from SPL here:
> > http://patchwork.ozlabs.org/patch/1020160/
> >
> > Remove hard-coded ECC parameters since the patch above can autoset them.
> > http://patchwork.ozlabs.org/patch/1026638/
> >
> > With those 3 patches and some minor changes to my individual board
> > file and config file, I was able to boot 2019.01 via SPL from NAND.
> > Since it was working for you before, I am guessing the board file
> > stuff and config file stuff is probably already for you.
>
>
> I did apply the above mentioned 3 patches but nand boot is still not working.
>
> Here are debug enabled boot logs
> https://paste.ubuntu.com/p/dmcwqzv6Sk/
>
Your U-Boot version shows the version is U-Boot SPL
2016.09-rc2-gc347b70c408b which is a couple years old.  Can you try
2019.01 with those patches I mentioned or the imx branch?  I know
there have been changes to U-Boot over time.

The last of the patches I applied to set the final configuration
settings for my board to boot from NAND are here:
http://patchwork.ozlabs.org/patch/1024016/

I don't know if that helps your board or not.

adam
>
> Best Regards,
> Shyam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] dfu: mmc: call fs functions instead of run_command

2019-01-31 Thread Stephen Warren

On 1/30/19 7:42 PM, Tom Rini wrote:

On Fri, Jan 25, 2019 at 07:58:01PM +0100, Simon Goldschmidt wrote:


This unbreaks dfu mmc_file_op which is currently broken since using the
load cmd on a buffer from heap is not allowed - added with
commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")

Fixes: commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
Reported-by: Stephen Warren 
Signed-off-by: Simon Goldschmidt 
Tested-by: Stephen Warren 
Acked-by: Lukasz Majewski 


Applied to u-boot/master, thanks!


Great, the testing is green again:-) Thanks. (Now we just need -video, 
-dm, and -net to rebase on u-boot/master so they go green again too).

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


Re: [U-Boot] Help: CONFIG_ENV_IS_IN_SPI_FLASH on AllWinner H5?

2019-01-31 Thread g4
Thank you Jagan, most kind. I will report back.

-Original Message-
From: Jagan Teki  
Sent: 31 January 2019 15:44
To: g...@novadsp.com
Cc: U-Boot-Denx 
Subject: Re: [U-Boot] Help: CONFIG_ENV_IS_IN_SPI_FLASH on AllWinner H5?

On Thu, Jan 31, 2019 at 8:57 PM  wrote:
>
> Greetings. Please let me know if there is a better place to ask this 
> question.
>
> Any clues here? I've got an AllWinner H5 with Winbond SPI flash 
> attached on SPI0. The flash is programmed using the sunxi FEL tools and boots 
> perfectly.
> Now I'd like to save the environment there too.
>
> Loading Environment from SPI Flash...
> Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default 
> environment
>
> TAIA
>
> Jerry.
> ---
> CONFIG_ARM=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_SPL=y
> CONFIG_MACH_SUN50I_H5=y
> CONFIG_DRAM_CLK=504
> CONFIG_DRAM_ZQ=3881977
> CONFIG_DRAM_ODT_EN=y
> CONFIG_MACPWR="PD6"
> CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> CONFIG_SPL_SPI_SUNXI=y
> CONFIG_SPL_SPI_FLASH_SUPPORT=y
> CONFIG_CMD_SF=y
> CONFIG_CMD_SF_TEST=y
> CONFIG_DEFAULT_DEVICE_TREE="anemos-sc5"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_MTD=y
> CONFIG_MTD_DEVICE=y
> CONFIG_DM_SPI_FLASH=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_SUN4I_SPI=y

Existing controller cann't handle SPI on H5, try below branch [1] it has sun6i 
spi driver and sample patch for sopine.

[1] https://github.com/amarula/u-boot-amarula/tree/spi

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


[U-Boot] [PATCH 3/3] x86: Use the existing GDT in the ROM for 64-bit U-Boot proper

2019-01-31 Thread Bin Meng
It is unnecessary to use a RAM version GDT for 64-bit U-Boot proper.
In fact we can just use the ROM version directly, which not only
eliminates the risk of being overwritten by application, but also
removes the complexity of patching the cpu_call64().

Signed-off-by: Bin Meng 

---

 arch/x86/cpu/i386/cpu.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index e4b5514..3bde44e 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -535,23 +535,9 @@ int cpu_jump_to_64bit_uboot(ulong target)
printf("Failed to allocate the cpu_call64 stub\n");
return -ENOMEM;
}
-   char *gdt = (char *)0x310;
-
-   extern char gdt64[];
-
memcpy(ptr, cpu_call64, call64_stub_size);
-   memcpy(gdt, gdt64, 0x100);
 
-   /*
-* TODO(s...@chromium.org): This manually inserts the pointers into
-* the code. Tidy this up to avoid this.
-*/
func = (func_t)ptr;
-   ulong ofs = (ulong)cpu_call64 - (ulong)ptr;
-   *(ulong *)(ptr + 7) = (ulong)gdt;
-   *(ulong *)(ptr + 0xc) = (ulong)gdt + 2;
-   *(ulong *)(ptr + 0x13) = (ulong)gdt;
-   *(ulong *)(ptr + 0x117 - 0xd4) -= ofs;
 
/*
 * Copy U-Boot from ROM
-- 
2.7.4

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


[U-Boot] [PATCH 2/3] x86: Don't copy the cpu_call64() function to a hardcoded address

2019-01-31 Thread Bin Meng
Before jumping to 64-bit U-Boot proper, SPL copies the cpu_call64()
function to a hardcoded address 0x300. This can have potential
conflicts with application usage. Switch the destination address
to be allocated from the heap to avoid such risk.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/i386/call64.S |  4 
 arch/x86/cpu/i386/cpu.c| 11 ---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/i386/call64.S b/arch/x86/cpu/i386/call64.S
index 8f86728..275063c 100644
--- a/arch/x86/cpu/i386/call64.S
+++ b/arch/x86/cpu/i386/call64.S
@@ -79,6 +79,10 @@ lret_target:
mov %eax, %eax  /* Clear bits 63:32 */
jmp *%eax   /* Jump to the 64-bit target */
 
+.globl call64_stub_size
+call64_stub_size:
+   .long   . - cpu_call64
+
.data
.align  16
.globl  gdt64
diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index af42431..e4b5514 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -523,18 +523,23 @@ int cpu_jump_to_64bit_uboot(ulong target)
typedef void (*func_t)(ulong pgtable, ulong setup_base, ulong target);
uint32_t *pgtable;
func_t func;
+   char *ptr;
 
pgtable = (uint32_t *)PAGETABLE_BASE;
 
build_pagetable(pgtable);
 
-   /* TODO(s...@chromium.org): Find a better place for this */
-   char *ptr = (char *)0x300;
+   extern long call64_stub_size;
+   ptr = malloc(call64_stub_size);
+   if (!ptr) {
+   printf("Failed to allocate the cpu_call64 stub\n");
+   return -ENOMEM;
+   }
char *gdt = (char *)0x310;
 
extern char gdt64[];
 
-   memcpy(ptr, cpu_call64, 0x1000);
+   memcpy(ptr, cpu_call64, call64_stub_size);
memcpy(gdt, gdt64, 0x100);
 
/*
-- 
2.7.4

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


[U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

2019-01-31 Thread Bin Meng
At present the 4-level page table base address for 64-bit U-Boot
proper is assigned an address that conflicts with CONFIG_LOADADDR.
Change it to an address within the low memory range instead.

Fixes crashes seen when 'dhcp' on QEMU x86_64 with
"-net nic -net user,tftp=.,bootfile=u-boot".

Reported-by: Alexander Graf 
Signed-off-by: Bin Meng 
---

 arch/x86/cpu/i386/cpu.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 208ef08..af42431 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -462,6 +462,7 @@ int cpu_has_64bit(void)
has_long_mode();
 }
 
+#define PAGETABLE_BASE 0x8
 #define PAGETABLE_SIZE (6 * 4096)
 
 /**
@@ -523,10 +524,7 @@ int cpu_jump_to_64bit_uboot(ulong target)
uint32_t *pgtable;
func_t func;
 
-   /* TODO(s...@chromium.org): Find a better place for this */
-   pgtable = (uint32_t *)0x100;
-   if (!pgtable)
-   return -ENOMEM;
+   pgtable = (uint32_t *)PAGETABLE_BASE;
 
build_pagetable(pgtable);
 
-- 
2.7.4

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


Re: [U-Boot] [PATCH] arm: dts: am33xx: add u-boot, dm-spl to ocp bus

2019-01-31 Thread Tom Rini
On Thu, Jan 31, 2019 at 04:48:10PM +0100, Hannes Schmelzer wrote:

> On 1/31/19 3:57 PM, Tom Rini wrote:
> >On Thu, Jan 31, 2019 at 08:03:19AM +0100, Hannes Schmelzer wrote:
> >
> >>commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
> >>did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
> >>introduced with
> >>commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")
> >>
> >>Due to this the brppt1_spi board is broken because it cannot
> >>bind/probe the spi-interface during SPL stage.
> >>
> >>This commit adds this flag again.
> >>
> >>This flag is needed for having access to the devices below this bus,
> >>most important is uart and boot-device (spi, mmc, ...) in SPL stage.
> >>
> >>Signed-off-by: Hannes Schmelzer 
> >>
> >>---
> >>
> >>  arch/arm/dts/am33xx.dtsi | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
> >>index d3dd6a1..0a6b177 100644
> >>--- a/arch/arm/dts/am33xx.dtsi
> >>+++ b/arch/arm/dts/am33xx.dtsi
> >>@@ -160,6 +160,7 @@
> >> * the whole bus hierarchy.
> >> */
> >>ocp {
> >>+   u-boot,dm-spl;
> >>compatible = "simple-bus";
> >>#address-cells = <1>;
> >>#size-cells = <1>;
> >We need to put this into one of the -u-boot.dtsi files and then #include
> >it from the others, so that we don't keep dropping this flag.  Thanks!
> Hi Tom,
> i'm not sure if we can do that this way because the "ocp" bus has no valid
> label like other elements.
> So we have at least to adjust the am33xx.dtsi file like this:
> 
>     ocp : ocp {
>     compatible = "simple-bus";
>                 .
>         }
> 
> what do you suggest ?

Er, with the example of arch/arm/dts/am335x-pdu001-u-boot.dtsi should't
we be able to just do that, globally?  Or is that part _not_ working and
relied on the now removed hunk?

-- 
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] Nand boot on imx6q board is broken

2019-01-31 Thread Shyam Saini
Hi Adam,

Thanks a lot for replying.

>
> I spent some time trying to make the imx6q_logic board boot from SPL
> from NAND, but I needed to patch a few things.   Some of them have yet
> to be approved, but if they work for you, maybe it will help get them
> approved.
>
> There was a broken function pointer here that was fixed and applied
> the imx-master, but pending merge with master
> http://patchwork.ozlabs.org/patch/1019440/
>
> Configure ECC from SPL here:
> http://patchwork.ozlabs.org/patch/1020160/
>
> Remove hard-coded ECC parameters since the patch above can autoset them.
> http://patchwork.ozlabs.org/patch/1026638/
>
> With those 3 patches and some minor changes to my individual board
> file and config file, I was able to boot 2019.01 via SPL from NAND.
> Since it was working for you before, I am guessing the board file
> stuff and config file stuff is probably already for you.


I did apply the above mentioned 3 patches but nand boot is still not working.

Here are debug enabled boot logs
https://paste.ubuntu.com/p/dmcwqzv6Sk/


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


Re: [U-Boot] [PATCH] arm: dts: am33xx: add u-boot, dm-spl to ocp bus

2019-01-31 Thread Hannes Schmelzer

On 1/31/19 3:57 PM, Tom Rini wrote:

On Thu, Jan 31, 2019 at 08:03:19AM +0100, Hannes Schmelzer wrote:


commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
introduced with
commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")

Due to this the brppt1_spi board is broken because it cannot
bind/probe the spi-interface during SPL stage.

This commit adds this flag again.

This flag is needed for having access to the devices below this bus,
most important is uart and boot-device (spi, mmc, ...) in SPL stage.

Signed-off-by: Hannes Schmelzer 

---

  arch/arm/dts/am33xx.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
index d3dd6a1..0a6b177 100644
--- a/arch/arm/dts/am33xx.dtsi
+++ b/arch/arm/dts/am33xx.dtsi
@@ -160,6 +160,7 @@
 * the whole bus hierarchy.
 */
ocp {
+   u-boot,dm-spl;
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

We need to put this into one of the -u-boot.dtsi files and then #include
it from the others, so that we don't keep dropping this flag.  Thanks!

Hi Tom,
i'm not sure if we can do that this way because the "ocp" bus has no 
valid label like other elements.

So we have at least to adjust the am33xx.dtsi file like this:

    ocp : ocp {
    compatible = "simple-bus";
                .
        }

what do you suggest ?

cheers,
Hannes

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


Re: [U-Boot] [PATCH v3 00/22] mx6sabre: Add DM and SPL FIT support

2019-01-31 Thread Tom Rini
On Thu, Jan 31, 2019 at 03:13:51PM +, Abel Vesa wrote:
> On 19-01-31 09:41:11, Tom Rini wrote:
> > On Thu, Jan 31, 2019 at 12:59:19PM +, Abel Vesa wrote:
> > > On 19-01-30 13:58:19, Tom Rini wrote:
> > > > On Wed, Jan 30, 2019 at 01:39:50PM +, Abel Vesa wrote:
> > > > 
> > > > > The second version is here:
> > > > > https://lists.denx.de/pipermail/u-boot/2019-January/356557.html
> > > > > 
> > > > > Changes since v2:
> > > > >  * Removed the unecessary SYS_MALLOC_F_LEN from both defocnfig
> > > > >  * Fixed the copyright for all the *u-boot.dtsi files
> > > > 
> > > > OK, but you didn't answer why you need to specify your own its file when
> > > > the TI examples show how to have mkimage generate this for you, thanks!
> > > > 
> > > 
> > > I might be wrong here but TI is doing this for MLO, which AFAIU, it's for
> > > SPL. The fit_spl.its I'm adding here is actually for u-boot proper.
> > > 
> > > SPL expects descriptions in the configurations and that can't be done
> > > without its file, again, AFAIK.
> > > 
> > > Please let me know what exactly am I missing here.
> > 
> > The flag to mkimage is not about SPL but rather "create a single
> > configurations its file on the fly".  This should also be fine for the
> > its file in patch 10/22 (of v2, don't have v3 in front of me in
> > patchwork).
> > 
> 
> Well, I tried something like this (manually):
> 
> $ ./tools/mkimage -f auto -C none -A ARM -T standalone -a 0x1780 -e 
> 0x1780 -d u-boot-fit-dtb.bin -n "U-Boot" u-boot.itb -E
> 
> and the output was:
> 
> FIT description: Standalone Program image with one or more FDT blobs  
> 
> Created: Thu Jan 31 13:58:01 2019 
> 
>  Image 0 (standalone-1)   
> 
>   Description:  U-Boot
> 
>   Created:  Thu Jan 31 13:58:01 2019  
> 
>   Type: Standalone Program
> 
>   Compression:  uncompressed  
> 
>   Data Size:646400 Bytes = 631.25 KiB = 0.62 MiB  
> 
>   Architecture: ARM   
> 
>   Load Address: 0x1780
> 
>   Entry Point:  0x1780
> 
>  Default Configuration: 'conf-1'  
> 
>  Configuration 0 (conf-1) 
> 
>   Description:  unavailable   
> 
>   Kernel:   unavailable   
> 
> 
> And then the SPL complains about the configuration description:
> 
> U-Boot SPL 2019.01-00374-gbe79a83 (Jan 31 2019 - 13:56:01 +0200)
> Trying to boot from MMC1
> fit_find_config_node: Missing FDT description in DTB
> No matching DT out of these options:
>Firmware image with one or more FDT blobs
> fit_find_config_node: Missing FDT description in DTB
> No matching DT out of these options:
>Firmware image with one or more FDT blobs
> fit_find_config_node: Missing FDT description in DTB
> No matching DT out of these options:
>Firmware image with one or more FDT blobs
> mmc_load_image_raw_sector: mmc block read error
> spl: no partition table found
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> But with the fit_spl.its file I added I have this and works:
> 
> FIT description: Image for u-boot proper (with dtb appended)
> Created: Thu Jan 31 13:57:02 2019   
>  Image 0 (uboot@1)  
>   Description:  U-Boot  
>   Created:  Thu Jan 31 13:57:02 2019
>   Type: Standalone Program  
>   Compression:  uncompressed
>   Data Size:646400 Bytes = 631.25 KiB = 0.62 MiB
>   Architecture: ARM 
>   Load Address: 0x1780  
>   Entry Point:  unavailable 
>  Default Configuration: 'conf@1'
>  Configuration 0 (conf@1)   
>   Description:  i.MX armv7  
>   Kernel:   unavailable 
>   Loadables:uboot@1 
> 
> So the differences between this and the one generated with mkimage+flags
> are the loadables and the description in the configuration 0.
> 
> Can I specify those 

Re: [U-Boot] Help: CONFIG_ENV_IS_IN_SPI_FLASH on AllWinner H5?

2019-01-31 Thread Jagan Teki
On Thu, Jan 31, 2019 at 8:57 PM  wrote:
>
> Greetings. Please let me know if there is a better place to ask this
> question.
>
> Any clues here? I've got an AllWinner H5 with Winbond SPI flash attached on
> SPI0. The flash is programmed using the sunxi FEL tools and boots perfectly.
> Now I'd like to save the environment there too.
>
> Loading Environment from SPI Flash...
> Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
>
> TAIA
>
> Jerry.
> ---
> CONFIG_ARM=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_SPL=y
> CONFIG_MACH_SUN50I_H5=y
> CONFIG_DRAM_CLK=504
> CONFIG_DRAM_ZQ=3881977
> CONFIG_DRAM_ODT_EN=y
> CONFIG_MACPWR="PD6"
> CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> CONFIG_SPL_SPI_SUNXI=y
> CONFIG_SPL_SPI_FLASH_SUPPORT=y
> CONFIG_CMD_SF=y
> CONFIG_CMD_SF_TEST=y
> CONFIG_DEFAULT_DEVICE_TREE="anemos-sc5"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_MTD=y
> CONFIG_MTD_DEVICE=y
> CONFIG_DM_SPI_FLASH=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_SUN4I_SPI=y

Existing controller cann't handle SPI on H5, try below branch [1] it
has sun6i spi driver and sample patch for sopine.

[1] https://github.com/amarula/u-boot-amarula/tree/spi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/7] dm: core: Add of_alias_get_highest_id()

2019-01-31 Thread Michal Simek
The same functionality was added to Linux for i2c bus registration with this
commit message:

"
of: base: add function to get highest id of an alias stem

I2C supports adding adapters using either a dynamic or fixed id. The
latter is provided by aliases in the DT case. To prevent id collisions
of those two types, install this function which gives us the highest
fixed id, so we can then let the dynamically created ones come after
this highest number.

Signed-off-by: Wolfram Sang 
Acked-by: Rob Herring 
Signed-off-by: Wolfram Sang 
"

Add it also to U-Boot for DM I2C support.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Update kernel-doc binding
- Return -1 in case of error. -1 means that the next free alias is 0.

 drivers/core/of_access.c | 18 ++
 include/dm/of_access.h   | 10 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 14c020a687b7..945b81448cce 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -812,6 +812,24 @@ int of_alias_get_id(const struct device_node *np, const 
char *stem)
return id;
 }
 
+int of_alias_get_highest_id(const char *stem)
+{
+   struct alias_prop *app;
+   int id = -1;
+
+   mutex_lock(_mutex);
+   list_for_each_entry(app, _lookup, link) {
+   if (strcmp(app->stem, stem) != 0)
+   continue;
+
+   if (app->id > id)
+   id = app->id;
+   }
+   mutex_unlock(_mutex);
+
+   return id;
+}
+
 struct device_node *of_get_stdout(void)
 {
return of_stdout;
diff --git a/include/dm/of_access.h b/include/dm/of_access.h
index 5ed1a0cdb427..13fedb7cf5e6 100644
--- a/include/dm/of_access.h
+++ b/include/dm/of_access.h
@@ -425,6 +425,16 @@ int of_alias_scan(void);
 int of_alias_get_id(const struct device_node *np, const char *stem);
 
 /**
+ * of_alias_get_highest_id - Get highest alias id for the given stem
+ * @stem:  Alias stem to be examined
+ *
+ * The function travels the lookup table to get the highest alias id for the
+ * given alias stem.
+ * @return alias ID, if found, else -1
+ */
+int of_alias_get_highest_id(const char *stem);
+
+/**
  * of_get_stdout() - Get node to use for stdout
  *
  * @return node referred to by stdout-path alias, or NULL if none
-- 
1.9.1

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


[U-Boot] [PATCH v2 5/7] i2c: dm: Record maximum id of devices before probing devices

2019-01-31 Thread Michal Simek
There is a need to find out the first free i2c ID which can be used for
i2s buses (including i2c buses connected to i2c mux). Do it early in
init and share this variable with other i2c classes for uniq bus
identification.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Use dev_read_alias_highest_id()
- Use uclass private data

 drivers/i2c/i2c-uclass.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 975318e5f254..b26602f3de95 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -619,6 +619,26 @@ static int i2c_child_post_bind(struct udevice *dev)
 #endif
 }
 
+struct i2c_priv {
+   int max_id;
+};
+
+int i2c_uclass_init(struct uclass *class)
+{
+   struct i2c_priv *priv = class->priv;
+
+   /* Just for sure */
+   if (!priv)
+   return -ENOMEM;
+
+   /* Get the last allocated alias. */
+   priv->max_id = dev_read_alias_highest_id("i2c");
+
+   debug("%s: highest alias id is %d\n", __func__, priv->max_id);
+
+   return 0;
+}
+
 UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name   = "i2c",
@@ -626,6 +646,8 @@ UCLASS_DRIVER(i2c) = {
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.post_bind  = dm_scan_fdt_dev,
 #endif
+   .init   = i2c_uclass_init,
+   .priv_auto_alloc_size = sizeof(struct i2c_priv),
.post_probe = i2c_post_probe,
.per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),
-- 
1.9.1

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


[U-Boot] [PATCH v2 7/7] i2c: mux: Generate longer i2c mux name

2019-01-31 Thread Michal Simek
For !DM case busses are listed as
ZynqMP> i2c bus
Bus 0:  zynq_0
Bus 1:  zynq_0->PCA9544A@0x75:0
Bus 2:  zynq_0->PCA9544A@0x75:1
Bus 3:  zynq_0->PCA9544A@0x75:2
Bus 4:  zynq_1
Bus 5:  zynq_1->PCA9548@0x74:0
Bus 6:  zynq_1->PCA9548@0x74:1
Bus 7:  zynq_1->PCA9548@0x74:2
Bus 8:  zynq_1->PCA9548@0x74:3
Bus 9:  zynq_1->PCA9548@0x74:4
Bus 10: zynq_1->PCA9548@0x75:0
Bus 11: zynq_1->PCA9548@0x75:1
Bus 12: zynq_1->PCA9548@0x75:2
Bus 13: zynq_1->PCA9548@0x75:3
Bus 14: zynq_1->PCA9548@0x75:4
Bus 15: zynq_1->PCA9548@0x75:5
Bus 16: zynq_1->PCA9548@0x75:6
Bus 17: zynq_1->PCA9548@0x75:7

where is exactly describing i2c bus topology.
By moving to DM case i2c mux buses are using names from DT and because
i2c-muxes describing sub busses with the same names like i2c@0, etc it
is hard to identify which bus is where.
Linux is adding topology information to i2c-mux busses to identify them
better.
This patch is doing the same and composing bus name with topology
information.

When patch is applied with topology information on zcu102-revA.
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 2:  i2c@ff02->i2c-mux@75->i2c@0
Bus 3:  i2c@ff02->i2c-mux@75->i2c@1
Bus 4:  i2c@ff02->i2c-mux@75->i2c@2
Bus 1:  i2c@ff03  (active 1)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 5:  i2c@ff03->i2c-mux@74->i2c@0  (active 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@ff03->i2c-mux@74->i2c@1
Bus 7:  i2c@ff03->i2c-mux@74->i2c@2
Bus 8:  i2c@ff03->i2c-mux@74->i2c@3
Bus 9:  i2c@ff03->i2c-mux@74->i2c@4
Bus 10: i2c@ff03->i2c-mux@75->i2c@0
Bus 11: i2c@ff03->i2c-mux@75->i2c@1
Bus 12: i2c@ff03->i2c-mux@75->i2c@2
Bus 13: i2c@ff03->i2c-mux@75->i2c@3
Bus 14: i2c@ff03->i2c-mux@75->i2c@4
Bus 15: i2c@ff03->i2c-mux@75->i2c@5
Bus 16: i2c@ff03->i2c-mux@75->i2c@6
Bus 17: i2c@ff03->i2c-mux@75->i2c@7

Behavior before the patch is applied.
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 2:  i2c@0
Bus 3:  i2c@1
Bus 4:  i2c@2
Bus 1:  i2c@ff03  (active 1)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 5:  i2c@0  (active 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@1
Bus 7:  i2c@2
Bus 8:  i2c@3
Bus 9:  i2c@4
Bus 10: i2c@0
Bus 11: i2c@1
Bus 12: i2c@2
Bus 13: i2c@3
Bus 14: i2c@4
Bus 15: i2c@5
Bus 16: i2c@6
Bus 17: i2c@7

Signed-off-by: Michal Simek 
---

Changes in v2:
- Fix headers
- Change patch description to focus only on bus name

 drivers/i2c/muxes/i2c-mux-uclass.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-uclass.c 
b/drivers/i2c/muxes/i2c-mux-uclass.c
index a680ee176253..8b1149997a19 100644
--- a/drivers/i2c/muxes/i2c-mux-uclass.c
+++ b/drivers/i2c/muxes/i2c-mux-uclass.c
@@ -59,11 +59,34 @@ static int i2c_mux_post_bind(struct udevice *mux)
dev_for_each_subnode(node, mux) {
struct udevice *dev;
const char *name;
+   const char *arrow = "->";
+   char *full_name;
+   int parent_name_len, arrow_len, mux_name_len, name_len;
 
name = ofnode_get_name(node);
-   ret = device_bind_driver_to_node(mux, "i2c_mux_bus_drv", name,
-node, );
-   debug("   - bind ret=%d, %s\n", ret, dev ? dev->name : NULL);
+
+   /* Calculate lenghts of strings */
+   parent_name_len = strlen(mux->parent->name);
+   arrow_len = strlen(arrow);
+   mux_name_len = strlen(mux->name);
+   name_len = strlen(name);
+
+   full_name = calloc(1, parent_name_len + arrow_len +
+  mux_name_len + arrow_len + name_len + 1);
+   if (!full_name)
+   return -ENOMEM;
+
+   /* Compose bus name */
+   strcat(full_name, mux->parent->name);
+   strcat(full_name, arrow);
+   strcat(full_name, mux->name);
+   strcat(full_name, arrow);
+   strcat(full_name, name);
+
+   ret = device_bind_driver_to_node(mux, "i2c_mux_bus_drv",
+full_name, node, );
+   debug("   - bind ret=%d, %s, req_seq %d\n", ret,
+ dev ? dev->name : NULL, dev->req_seq);
if (ret)
return ret;
}
-- 
1.9.1

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


[U-Boot] [PATCH v2 6/7] i2c: Fill req_seq in i2c_post_bind()

2019-01-31 Thread Michal Simek
For i2c controllers which are missing alias in DT there is no req_seq
setup. This function is setting up proper ID based on highest found
alias ID.

On zcu102 this is the behavior when patch is applied.
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 2:  i2c@0
Bus 3:  i2c@1
Bus 4:  i2c@2
Bus 1:  i2c@ff03  (active 1)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 5:  i2c@0  (active 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@1
Bus 7:  i2c@2
Bus 8:  i2c@3
Bus 9:  i2c@4
Bus 10: i2c@0
Bus 11: i2c@1
Bus 12: i2c@2
Bus 13: i2c@3
Bus 14: i2c@4
Bus 15: i2c@5
Bus 16: i2c@6
Bus 17: i2c@7

Before this patch applied (controllers have -1 ID)
ZynqMP> i2c bus
Bus 0:  i2c@ff02
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus 1:  i2c@ff03  (active 1)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus -1: i2c@0  (active 0)
   54: eeprom@54, offset len 1, flags 0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@5
Bus -1: i2c@6
Bus -1: i2c@7

Signed-off-by: Michal Simek 
---

Changes in v2:
- Use private uclass data

 drivers/i2c/i2c-uclass.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index b26602f3de95..6f3fca2d2326 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -623,6 +623,30 @@ struct i2c_priv {
int max_id;
 };
 
+static int i2c_post_bind(struct udevice *dev)
+{
+   struct uclass *class = dev->uclass;
+   struct i2c_priv *priv = class->priv;
+   int ret = 0;
+
+   /* Just for sure */
+   if (!priv)
+   return -ENOMEM;
+
+   debug("%s: %s, req_seq=%d\n", __func__, dev->name, dev->req_seq);
+
+   /* if there is no alias ID, use the first free */
+   if (dev->req_seq == -1)
+   dev->req_seq = ++priv->max_id;
+
+   debug("%s: %s, new req_seq=%d\n", __func__, dev->name, dev->req_seq);
+
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+   ret = dm_scan_fdt_dev(dev);
+#endif
+   return ret;
+}
+
 int i2c_uclass_init(struct uclass *class)
 {
struct i2c_priv *priv = class->priv;
@@ -643,9 +667,7 @@ UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name   = "i2c",
.flags  = DM_UC_FLAG_SEQ_ALIAS,
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-   .post_bind  = dm_scan_fdt_dev,
-#endif
+   .post_bind  = i2c_post_bind,
.init   = i2c_uclass_init,
.priv_auto_alloc_size = sizeof(struct i2c_priv),
.post_probe = i2c_post_probe,
-- 
1.9.1

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


[U-Boot] [PATCH v2 3/7] dm: core: Introduce dev_read_alias_highest_id()

2019-01-31 Thread Michal Simek
It is wrapper for calling of_alias_get_highest_id() when live tree is
enabled and fdtdec_get_alias_highest_id() if not.

Signed-off-by: Michal Simek 
---

Changes in v2:
- New patch

 drivers/core/read.c |  8 
 include/dm/read.h   | 16 
 2 files changed, 24 insertions(+)

diff --git a/drivers/core/read.c b/drivers/core/read.c
index 3c46b3674ed6..6bda077a34b9 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -264,3 +264,11 @@ u64 dev_translate_address(struct udevice *dev, const 
fdt32_t *in_addr)
 {
return ofnode_translate_address(dev_ofnode(dev), in_addr);
 }
+
+int dev_read_alias_highest_id(const char *stem)
+{
+   if (of_live_active())
+   return of_alias_get_highest_id(stem);
+
+   return fdtdec_get_alias_highest_id(gd->fdt_blob, stem);
+}
diff --git a/include/dm/read.h b/include/dm/read.h
index 389e30e7fb44..60b727cbd821 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -510,6 +510,17 @@ int dev_read_resource_byname(struct udevice *dev, const 
char *name,
  * @return the translated address; OF_BAD_ADDR on error
  */
 u64 dev_translate_address(struct udevice *dev, const fdt32_t *in_addr);
+
+/**
+ * dev_read_alias_highest_id - Get highest alias id for the given stem
+ * @stem:  Alias stem to be examined
+ *
+ * The function travels the lookup table to get the highest alias id for the
+ * given alias stem.
+ * @return alias ID, if found, else -1
+ */
+int dev_read_alias_highest_id(const char *stem);
+
 #else /* CONFIG_DM_DEV_READ_INLINE is enabled */
 
 static inline int dev_read_u32(struct udevice *dev,
@@ -740,6 +751,11 @@ static inline u64 dev_translate_address(struct udevice 
*dev, const fdt32_t *in_a
return ofnode_translate_address(dev_ofnode(dev), in_addr);
 }
 
+static inline int dev_read_alias_highest_id(const char *stem)
+{
+   return fdtdec_get_alias_highest_id(gd->fdt_blob, stem);
+}
+
 #endif /* CONFIG_DM_DEV_READ_INLINE */
 
 /**
-- 
1.9.1

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


[U-Boot] [PATCH v2 4/7] dm: core: Add tests for dev_read_alias_highest_id()

2019-01-31 Thread Michal Simek
It is checking the highest alias ID for eth, gpio, pci, i2c and error
code on non existing alias.

Signed-off-by: Michal Simek 
---

Changes in v2:
- New patch

 test/dm/test-fdt.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 984b80c02c81..be16c99e170e 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -219,6 +219,29 @@ static int dm_test_fdt(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_fdt, 0);
 
+static int dm_test_alias_highest_id(struct unit_test_state *uts)
+{
+   int ret;
+
+   ret = dev_read_alias_highest_id("eth");
+   ut_asserteq(5, ret);
+
+   ret = dev_read_alias_highest_id("gpio");
+   ut_asserteq(2, ret);
+
+   ret = dev_read_alias_highest_id("pci");
+   ut_asserteq(2, ret);
+
+   ret = dev_read_alias_highest_id("i2c");
+   ut_asserteq(0, ret);
+
+   ret = dev_read_alias_highest_id("deadbeef");
+   ut_asserteq(-1, ret);
+
+   return 0;
+}
+DM_TEST(dm_test_alias_highest_id, 0);
+
 static int dm_test_fdt_pre_reloc(struct unit_test_state *uts)
 {
struct uclass *uc;
-- 
1.9.1

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


[U-Boot] [PATCH v2 2/7] fdt: Introduce fdtdec_get_alias_highest_id()

2019-01-31 Thread Michal Simek
Find out the highest alias ID used for certain subsystem.
This call will be used for alocating IDs for i2c buses which are not
described in DT.

Signed-off-by: Michal Simek 
---

Changes in v2: None

 include/fdtdec.h | 13 +
 lib/fdtdec.c | 33 +
 2 files changed, 46 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index f1bcbf837ffb..c2dd87ede226 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -626,6 +626,19 @@ int fdtdec_get_alias_seq(const void *blob, const char 
*base, int node,
 int *seqp);
 
 /**
+ * Get the highest alias number for susbystem.
+ *
+ * It parses all aliases and find out highest recorded alias for subsystem.
+ * Aliases are of the form  where  is the sequence number.
+ *
+ * @param blob Device tree blob (if NULL, then error is returned)
+ * @param base Base name for alias susbystem (before the number)
+ *
+ * @return 0 highest alias ID, -1 if not found
+ */
+int fdtdec_get_alias_highest_id(const void *blob, const char *base);
+
+/**
  * Get a property from the /chosen node
  *
  * @param blob Device tree blob (if NULL, then NULL is returned)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 18663ce6bdac..55811975ef54 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -549,6 +549,39 @@ int fdtdec_get_alias_seq(const void *blob, const char 
*base, int offset,
return -ENOENT;
 }
 
+int fdtdec_get_alias_highest_id(const void *blob, const char *base)
+{
+   int base_len = strlen(base);
+   int prop_offset;
+   int aliases;
+   int max = -1;
+
+   debug("Looking for highest alias id for '%s'\n", base);
+
+   aliases = fdt_path_offset(blob, "/aliases");
+   for (prop_offset = fdt_first_property_offset(blob, aliases);
+prop_offset > 0;
+prop_offset = fdt_next_property_offset(blob, prop_offset)) {
+   const char *prop;
+   const char *name;
+   int len, val;
+
+   prop = fdt_getprop_by_offset(blob, prop_offset, , );
+   debug("   - %s, %s\n", name, prop);
+   if (*prop != '/' || prop[len - 1] ||
+   strncmp(name, base, base_len))
+   continue;
+
+   val = trailing_strtol(name);
+   if (val > max) {
+   debug("Found seq %d\n", val);
+   max = val;
+   }
+   }
+
+   return max;
+}
+
 const char *fdtdec_get_chosen_prop(const void *blob, const char *name)
 {
int chosen_node;
-- 
1.9.1

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


[U-Boot] [PATCH v2 0/7] Align U-Boot I2C DM bus ID handling with Linux

2019-01-31 Thread Michal Simek
U-Boot with I2C_DM enabled is not capable to list i2c busses connected
to i2c mux. For getting this work there is a need to find out highest
alias ID and use this uniq number for new buses connected to I2C mux.
This series is making this happen.

There is only one missing piece which is that also i2c controllers which
are not listed in DT are not using this feature.

Removing setting up aliases from i2c mux code and unifying it in the
same code ensures that numbering schema is proper if no alias is
specified.

ZynqMP> i2c bus
Bus 0:  i2c@ff02
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 1:  i2c@ff02->i2c-mux@75->i2c@0
Bus 2:  i2c@ff02->i2c-mux@75->i2c@1
Bus 3:  i2c@ff02->i2c-mux@75->i2c@2
Bus 4:  i2c@ff03  (active 4)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 5:  i2c@ff03->i2c-mux@74->i2c@0  (active 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@ff03->i2c-mux@74->i2c@1
Bus 7:  i2c@ff03->i2c-mux@74->i2c@2
Bus 8:  i2c@ff03->i2c-mux@74->i2c@3
Bus 9:  i2c@ff03->i2c-mux@74->i2c@4
Bus 10: i2c@ff03->i2c-mux@75->i2c@0
Bus 11: i2c@ff03->i2c-mux@75->i2c@1
Bus 12: i2c@ff03->i2c-mux@75->i2c@2
Bus 13: i2c@ff03->i2c-mux@75->i2c@3
Bus 14: i2c@ff03->i2c-mux@75->i2c@4
Bus 15: i2c@ff03->i2c-mux@75->i2c@5
Bus 16: i2c@ff03->i2c-mux@75->i2c@6
Bus 17: i2c@ff03->i2c-mux@75->i2c@7

Thanks,
Michal

Changes in v2:
- Update kernel-doc binding
- Return -1 in case of error. -1 means that the next free alias is 0.
- New patch
- New patch
- Use dev_read_alias_highest_id()
- Use uclass private data
- Use private uclass data
- Fix headers
- Change patch description to focus only on bus name

Michal Simek (7):
  dm: core: Add of_alias_get_highest_id()
  fdt: Introduce fdtdec_get_alias_highest_id()
  dm: core: Introduce dev_read_alias_highest_id()
  dm: core: Add tests for dev_read_alias_highest_id()
  i2c: dm: Record maximum id of devices before probing devices
  i2c: Fill req_seq in i2c_post_bind()
  i2c: mux: Generate longer i2c mux name

 drivers/core/of_access.c   | 18 ++
 drivers/core/read.c|  8 ++
 drivers/i2c/i2c-uclass.c   | 50 +++---
 drivers/i2c/muxes/i2c-mux-uclass.c | 29 +++---
 include/dm/of_access.h | 10 
 include/dm/read.h  | 16 
 include/fdtdec.h   | 13 ++
 lib/fdtdec.c   | 33 +
 test/dm/test-fdt.c | 23 ++
 9 files changed, 194 insertions(+), 6 deletions(-)

-- 
1.9.1

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


[U-Boot] Help: CONFIG_ENV_IS_IN_SPI_FLASH on AllWinner H5?

2019-01-31 Thread g4
Greetings. Please let me know if there is a better place to ask this
question.

Any clues here? I've got an AllWinner H5 with Winbond SPI flash attached on
SPI0. The flash is programmed using the sunxi FEL tools and boots perfectly.
Now I'd like to save the environment there too. 

Loading Environment from SPI Flash... 
Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

TAIA

Jerry.
---
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_SPL=y
CONFIG_MACH_SUN50I_H5=y
CONFIG_DRAM_CLK=504
CONFIG_DRAM_ZQ=3881977
CONFIG_DRAM_ODT_EN=y
CONFIG_MACPWR="PD6"
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_SPL_SPI_SUNXI=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_CMD_SF=y
CONFIG_CMD_SF_TEST=y
CONFIG_DEFAULT_DEVICE_TREE="anemos-sc5"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_MTD=y
CONFIG_MTD_DEVICE=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SUN8I_EMAC=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_SUN4I_SPI=y
CONFIG_SOFT_SPI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
CONFIG_USB_HOST_ETHER=y
...


Device tree looks sane but I am no judge.

---
=> fdt list /soc/spi@1c68000
spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
interrupts = <0x 0x0041 0x0004>;
clocks = <0x0003 0x001e 0x0003 0x0052>;
clock-names = "ahb", "mod";
dmas = <0x0014 0x0017 0x0014 0x0017>;
dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <0x0015>;
resets = <0x0003 0x000f>;
status = "okay";
#address-cells = <0x0001>;
#size-cells = <0x>;
spi_flash@0 {
};

---
=> fdt list /soc/spi@1c68000/spi_flash@0
spi_flash@0 {
compatible = "spi-flash";
reg = <0x>;
spi-max-frequency = <0x02faf080>;
u-boot,dm-pre-reloc;
};


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


Re: [U-Boot] Nand boot on imx6q board is broken

2019-01-31 Thread Jagan Teki
On Thu, Jan 31, 2019 at 8:53 PM Adam Ford  wrote:
>
> On Wed, Jan 30, 2019 at 11:40 PM Shyam Saini  
> wrote:
> >
> > Hi Everyone,
> >
> > I'm trying to boot imx6q board from nand but it seems like mainline
> > u-boot nand boot support for imx6q board is broken.
>
> I spent some time trying to make the imx6q_logic board boot from SPL
> from NAND, but I needed to patch a few things.   Some of them have yet
> to be approved, but if they work for you, maybe it will help get them
> approved.
>
> There was a broken function pointer here that was fixed and applied
> the imx-master, but pending merge with master
> http://patchwork.ozlabs.org/patch/1019440/
>
> Configure ECC from SPL here:
> http://patchwork.ozlabs.org/patch/1020160/
>
> Remove hard-coded ECC parameters since the patch above can autoset them.
> http://patchwork.ozlabs.org/patch/1026638/
>
> With those 3 patches and some minor changes to my individual board
> file and config file, I was able to boot 2019.01 via SPL from NAND.
> Since it was working for you before, I am guessing the board file
> stuff and config file stuff is probably already for you.

Thanks for your inputs Adam.

I was initially fixed the board and spl nand detection changes, I hope
these changes would resolve. let's see.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Nand boot on imx6q board is broken

2019-01-31 Thread Adam Ford
On Wed, Jan 30, 2019 at 11:40 PM Shyam Saini  wrote:
>
> Hi Everyone,
>
> I'm trying to boot imx6q board from nand but it seems like mainline
> u-boot nand boot support for imx6q board is broken.

I spent some time trying to make the imx6q_logic board boot from SPL
from NAND, but I needed to patch a few things.   Some of them have yet
to be approved, but if they work for you, maybe it will help get them
approved.

There was a broken function pointer here that was fixed and applied
the imx-master, but pending merge with master
http://patchwork.ozlabs.org/patch/1019440/

Configure ECC from SPL here:
http://patchwork.ozlabs.org/patch/1020160/

Remove hard-coded ECC parameters since the patch above can autoset them.
http://patchwork.ozlabs.org/patch/1026638/

With those 3 patches and some minor changes to my individual board
file and config file, I was able to boot 2019.01 via SPL from NAND.
Since it was working for you before, I am guessing the board file
stuff and config file stuff is probably already for you.

adam
>
> It is working till v2017.05 with this fix [1].
>
> I'm using this as my stub:
> https://github.com/openedev/u-boot-amarula/tree/icore-nand
>
>
>
> When I git bisect between v2017.05 and v2017.07, found this commit
> which is further breaking  the nand boot support:
> --
> ommit bc1fe9006dfaacc5103b5c7057a62215844957b7
> Author: Jagan Teki 
> Date:   Sun May 7 02:43:05 2017 +0530
>
> icorem6: Make SPL to pick suitable fdt
>
> SPL FIT is able to pick the suitable fdt file for u-boot,
> so add that function through board_fit_config_name_match.
>
> Cc: Stefano Babic 
> Cc: Matteo Lisi 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> -
> And It is fixed with this [2].
>
> In mainline u-boot we already  have fix [1] and [2] available but nand
> boot is still broken. It seems like problem is some where else, fix
> [1] and [2] are just making the bug appear less frequently.
>
> logs:
> [3] nand boot working
> [4] Nand boot not working
>
> Has anyone else faced or fixed the same issue on imx6 board.
> Please let me know.
>
>
> [1] https://paste.ubuntu.com/p/nKq7SNWDrn/
> [2] https://paste.ubuntu.com/p/tXqbx5dVPJ/
> [3] https://paste.ubuntu.com/p/DcBQ4gcSCM/
> [4] https://paste.ubuntu.com/p/WVtrqfdVQT/
>
>
> Thanks a lot,
> Shyam
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 8/8] configs: mscc_luton: Add network support.

2019-01-31 Thread Horatiu Vultur
Update default config to use network driver for Luton SoCs.

Signed-off-by: Horatiu Vultur 
---
 configs/mscc_luton_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mscc_luton_defconfig b/configs/mscc_luton_defconfig
index 7154e97..0fdd9b8 100644
--- a/configs/mscc_luton_defconfig
+++ b/configs/mscc_luton_defconfig
@@ -60,6 +60,7 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_DM_ETH=y
+CONFIG_MSCC_LUTON_SWITCH=y
 CONFIG_PINCTRL=y
 CONFIG_PINCONF=y
 CONFIG_DM_SERIAL=y
-- 
2.7.4

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


[U-Boot] [PATCH v3 7/8] net: Add MSCC Luton networkd driver.

2019-01-31 Thread Horatiu Vultur
Add network driver for Microsemi Ethernet switch, it is
present on Luton SoCs.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/Kconfig|   7 +
 drivers/net/mscc_eswitch/Makefile   |   1 +
 drivers/net/mscc_eswitch/luton_switch.c | 736 
 3 files changed, 744 insertions(+)
 create mode 100644 drivers/net/mscc_eswitch/luton_switch.c

diff --git a/drivers/net/mscc_eswitch/Kconfig b/drivers/net/mscc_eswitch/Kconfig
index 2f3c8cc..88e5a97 100644
--- a/drivers/net/mscc_eswitch/Kconfig
+++ b/drivers/net/mscc_eswitch/Kconfig
@@ -8,3 +8,10 @@ config MSCC_OCELOT_SWITCH
select PHYLIB
help
  This driver supports the Ocelot network switch device.
+
+config MSCC_LUTON_SWITCH
+   bool "Luton switch driver"
+   depends on DM_ETH && ARCH_MSCC
+   select PHYLIB
+   help
+ This driver supports the Luton network switch device.
diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
index 704f854..751a839 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -1,2 +1,3 @@
 
 obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o 
mscc_mac_table.o
+obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o 
mscc_mac_table.o
diff --git a/drivers/net/mscc_eswitch/luton_switch.c 
b/drivers/net/mscc_eswitch/luton_switch.c
new file mode 100644
index 000..6667614
--- /dev/null
+++ b/drivers/net/mscc_eswitch/luton_switch.c
@@ -0,0 +1,736 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Microsemi Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mscc_miim.h"
+#include "mscc_xfer.h"
+#include "mscc_mac_table.h"
+
+#define ANA_PORT_VLAN_CFG(x)   (0x00 + 0x80 * (x))
+#defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
+#defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
+#define ANA_PORT_CPU_FWD_CFG(x)(0x50 + 0x80 * (x))
+#defineANA_PORT_CPU_FWD_CFG_SRC_COPY_ENA   BIT(1)
+#define ANA_PORT_PORT_CFG(x)   (0x60 + 0x80 * (x))
+#defineANA_PORT_PORT_CFG_RECV_ENA  BIT(5)
+#define ANA_PGID(x)(0x1000 + 4 * (x))
+
+#define SYS_FRM_AGING  0x8300
+
+#define SYS_SYSTEM_RST_CFG 0x81b0
+#defineSYS_SYSTEM_RST_MEM_INIT BIT(0)
+#defineSYS_SYSTEM_RST_MEM_ENA  BIT(1)
+#defineSYS_SYSTEM_RST_CORE_ENA BIT(2)
+#define SYS_PORT_MODE(x)   (0x81bc + 0x4 * (x))
+#defineSYS_PORT_MODE_INCL_INJ_HDR  BIT(0)
+#define SYS_SWITCH_PORT_MODE(x)(0x8294 + 0x4 * (x))
+#defineSYS_SWITCH_PORT_MODE_PORT_ENA   BIT(3)
+#define SYS_EGR_NO_SHARING 0x8378
+#define SYS_SCH_CPU0x85a0
+
+#define REW_PORT_CFG(x)(0x8 + 0x80 * (x))
+#defineREW_PORT_CFG_IFH_INSERT_ENA BIT(7)
+
+#define GCB_DEVCPU_RST_SOFT_CHIP_RST   0x90
+#defineGCB_DEVCPU_RST_SOFT_CHIP_RST_SOFT_PHY   BIT(1)
+#define GCB_MISC_STAT  0x11c
+#defineGCB_MISC_STAT_PHY_READY BIT(3)
+
+#defineQS_XTR_MAP(x)   (0x10 + 4 * (x))
+#defineQS_XTR_MAP_GRP  BIT(4)
+#defineQS_XTR_MAP_ENA  BIT(0)
+
+#define HSIO_PLL5G_CFG_PLL5G_CFG2  0x8
+
+#define HSIO_RCOMP_CFG_CFG00x20
+#defineHSIO_RCOMP_CFG_CFG0_MODE_SEL(x) ((x) << 
8)
+#defineHSIO_RCOMP_CFG_CFG0_RUN_CAL BIT(12)
+#define HSIO_RCOMP_STATUS  0x24
+#defineHSIO_RCOMP_STATUS_BUSY  BIT(12)
+#defineHSIO_RCOMP_STATUS_RCOMP_M   
GENMASK(3, 0)
+#define HSIO_SERDES6G_ANA_CFG_DES_CFG  0x64
+#defineHSIO_SERDES6G_ANA_CFG_DES_CFG_BW_ANA(x) ((x) << 
1)
+#defineHSIO_SERDES6G_ANA_CFG_DES_CFG_BW_HYST(x)((x) << 
5)
+#defineHSIO_SERDES6G_ANA_CFG_DES_CFG_MBTR_CTRL(x)  ((x) << 
10)
+#defineHSIO_SERDES6G_ANA_CFG_DES_CFG_PHS_CTRL(x)   ((x) << 
13)
+#define HSIO_SERDES6G_ANA_CFG_IB_CFG   0x68
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG_RESISTOR_CTRL(x)   (x)
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG_VBCOM(x)   ((x) << 
4)
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG_VBAC(x)((x) << 
7)
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG_RT(x)  ((x) << 
9)
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG_RF(x)  ((x) << 
14)
+#define HSIO_SERDES6G_ANA_CFG_IB_CFG1  0x6c
+#defineHSIO_SERDES6G_ANA_CFG_IB_CFG1_RST   BIT(0)
+#define 

[U-Boot] [PATCH v3 6/8] mips: mscc: luton: Add ethernet nodes for Luton.

2019-01-31 Thread Horatiu Vultur
Add nodes for pcb090 and pcb091. There is currently no support
in Linux for this SoC.

Signed-off-by: Horatiu Vultur 
---
 arch/mips/dts/luton_pcb090.dts |  51 +
 arch/mips/dts/luton_pcb091.dts |  51 +
 arch/mips/dts/mscc,luton.dtsi  | 165 +
 3 files changed, 267 insertions(+)

diff --git a/arch/mips/dts/luton_pcb090.dts b/arch/mips/dts/luton_pcb090.dts
index 951d8da..315172b 100644
--- a/arch/mips/dts/luton_pcb090.dts
+++ b/arch/mips/dts/luton_pcb090.dts
@@ -55,3 +55,54 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
diff --git a/arch/mips/dts/luton_pcb091.dts b/arch/mips/dts/luton_pcb091.dts
index bf638b2..9b4d628 100644
--- a/arch/mips/dts/luton_pcb091.dts
+++ b/arch/mips/dts/luton_pcb091.dts
@@ -61,3 +61,54 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
+
+ {
+   phy-handle = <>;
+};
diff --git a/arch/mips/dts/mscc,luton.dtsi b/arch/mips/dts/mscc,luton.dtsi
index d11ec48..de354fe 100644
--- a/arch/mips/dts/mscc,luton.dtsi
+++ b/arch/mips/dts/mscc,luton.dtsi
@@ -92,5 +92,170 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   switch: switch@101 {
+   compatible = "mscc,vsc7527-switch";
+   reg = <0x1e 0x0100>, // VTSS_TO_DEV_0
+ <0x1f 0x0100>, // VTSS_TO_DEV_1
+ <0x20 0x0100>, // VTSS_TO_DEV_2
+ <0x21 0x0100>, // VTSS_TO_DEV_3
+ <0x22 0x0100>, // VTSS_TO_DEV_4
+ <0x23 0x0100>, // VTSS_TO_DEV_5
+ <0x24 0x0100>, // VTSS_TO_DEV_6
+ <0x25 0x0100>, // VTSS_TO_DEV_7
+ <0x26 0x0100>, // VTSS_TO_DEV_8
+ <0x27 0x0100>, // VTSS_TO_DEV_9
+ <0x28 0x0100>, // VTSS_TO_DEV_10
+ <0x29 0x0100>, // VTSS_TO_DEV_11
+ <0x2a 0x0100>, // VTSS_TO_DEV_12
+ <0x2b 0x0100>, // VTSS_TO_DEV_13
+ <0x2c 0x0100>, // VTSS_TO_DEV_14
+ <0x2d 0x0100>, // VTSS_TO_DEV_15
+ <0x2e 0x0100>, // VTSS_TO_DEV_16
+ <0x2f 0x0100>, // VTSS_TO_DEV_17
+ <0x30 0x0100>, // VTSS_TO_DEV_18
+ <0x31 0x0100>, // VTSS_TO_DEV_19
+ <0x32 0x0100>, // VTSS_TO_DEV_20
+ <0x33 0x0100>, // VTSS_TO_DEV_21
+ <0x34 0x0100>, // VTSS_TO_DEV_22
+ <0x35 0x0100>, // VTSS_TO_DEV_23
+ <0x01 0x1000>, // VTSS_TO_SYS
+ <0x02 0x1000>, // VTSS_TO_ANA
+ <0x03 0x1000>, // VTSS_TO_REW
+ <0x07 0x1000>, // VTSS_TO_DEVCPU_GCB
+ <0x08 0x0100>, // VTSS_TO_DEVCPU_QS
+ <0x0a 0x0100>; // VTSS_TO_HSIO
+   reg-names = "port0", "port1", "port2", "port3",
+   "port4", "port5", "port6", "port7",
+   "port8", "port9", "port10", "port11",
+   "port12", "port13", "port14", "port15",
+   "port16", "port17", "port18", "port19",
+   "port20", "port21", "port22", "port23",
+   "sys", "ana", "rew", "gcb", "qs", "hsio";
+   status = "okay";
+
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port0: port@0 {
+   reg = <0>;
+   };
+   port1: port@1 {
+  

[U-Boot] [PATCH v3 4/8] net: mscc: Move mac_table_add function into different file.

2019-01-31 Thread Horatiu Vultur
Move the function mac_table_add into a different file,
so it can be reused.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/Makefile |  2 +-
 drivers/net/mscc_eswitch/mscc_mac_table.c | 74 +
 drivers/net/mscc_eswitch/mscc_mac_table.h | 19 +++
 drivers/net/mscc_eswitch/ocelot_switch.c  | 90 +--
 4 files changed, 107 insertions(+), 78 deletions(-)
 create mode 100644 drivers/net/mscc_eswitch/mscc_mac_table.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_mac_table.h

diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
index 20e8e4c..704f854 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -1,2 +1,2 @@
 
-obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o
+obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o 
mscc_mac_table.o
diff --git a/drivers/net/mscc_eswitch/mscc_mac_table.c 
b/drivers/net/mscc_eswitch/mscc_mac_table.c
new file mode 100644
index 000..833e233
--- /dev/null
+++ b/drivers/net/mscc_eswitch/mscc_mac_table.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include 
+#include "mscc_mac_table.h"
+
+#define ANA_TABLES_MACACCESS_VALID BIT(11)
+#define ANA_TABLES_MACACCESS_ENTRYTYPE(x)  ((x) << 9)
+#define ANA_TABLES_MACACCESS_DEST_IDX(x)   ((x) << 3)
+#define ANA_TABLES_MACACCESS_MAC_TABLE_CMD(x)  (x)
+#define ANA_TABLES_MACACCESS_MAC_TABLE_CMD_M   GENMASK(2, 0)
+#define MACACCESS_CMD_IDLE 0
+#define MACACCESS_CMD_LEARN1
+
+/* MAC table entry types.
+ * ENTRYTYPE_NORMAL is subject to aging.
+ * ENTRYTYPE_LOCKED is not subject to aging.
+ */
+enum macaccess_entry_type {
+   ENTRYTYPE_NORMAL = 0,
+   ENTRYTYPE_LOCKED,
+};
+
+static int vlan_wait_for_completion(void __iomem *regs,
+   const unsigned long *mscc_mac_table_offset)
+{
+   unsigned int val, timeout = 10;
+
+   /* Wait for the issued mac table command to be completed, or timeout.
+* When the command read from ANA_TABLES_MACACCESS is
+* MACACCESS_CMD_IDLE, the issued command completed successfully.
+*/
+   do {
+   val = readl(regs +
+   mscc_mac_table_offset[MSCC_ANA_TABLES_MACACCESS]);
+   val &= ANA_TABLES_MACACCESS_MAC_TABLE_CMD_M;
+   } while (val != MACACCESS_CMD_IDLE && timeout--);
+
+   if (!timeout)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+int mscc_mac_table_add(void __iomem *regs,
+  const unsigned long *mscc_mac_table_offset,
+  const unsigned char mac[ETH_LEN], int pgid)
+{
+   u32 macl = 0, mach = 0;
+
+   /* Set the MAC address to handle and the vlan associated in a format
+* understood by the hardware.
+*/
+   mach |= MAC_VID << 16;
+   mach |= ((u32)mac[0]) << 8;
+   mach |= ((u32)mac[1]) << 0;
+   macl |= ((u32)mac[2]) << 24;
+   macl |= ((u32)mac[3]) << 16;
+   macl |= ((u32)mac[4]) << 8;
+   macl |= ((u32)mac[5]) << 0;
+
+   writel(macl, regs + mscc_mac_table_offset[MSCC_ANA_TABLES_MACLDATA]);
+   writel(mach, regs + mscc_mac_table_offset[MSCC_ANA_TABLES_MACHDATA]);
+
+   writel(ANA_TABLES_MACACCESS_VALID |
+  ANA_TABLES_MACACCESS_DEST_IDX(pgid) |
+  ANA_TABLES_MACACCESS_ENTRYTYPE(ENTRYTYPE_LOCKED) |
+  ANA_TABLES_MACACCESS_MAC_TABLE_CMD(MACACCESS_CMD_LEARN),
+  regs + mscc_mac_table_offset[MSCC_ANA_TABLES_MACACCESS]);
+
+   return vlan_wait_for_completion(regs, mscc_mac_table_offset);
+}
diff --git a/drivers/net/mscc_eswitch/mscc_mac_table.h 
b/drivers/net/mscc_eswitch/mscc_mac_table.h
new file mode 100644
index 000..17fed2e
--- /dev/null
+++ b/drivers/net/mscc_eswitch/mscc_mac_table.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include 
+
+#define ETH_LEN 6
+#define MAC_VID 1
+
+enum mscc_regs_ana_table {
+   MSCC_ANA_TABLES_MACHDATA,
+   MSCC_ANA_TABLES_MACLDATA,
+   MSCC_ANA_TABLES_MACACCESS,
+};
+
+int mscc_mac_table_add(void __iomem *regs,
+  const unsigned long *mscc_mac_table_offset,
+  const unsigned char mac[ETH_LEN], int pgid);
diff --git a/drivers/net/mscc_eswitch/ocelot_switch.c 
b/drivers/net/mscc_eswitch/ocelot_switch.c
index c33ecd4..40152e6 100644
--- a/drivers/net/mscc_eswitch/ocelot_switch.c
+++ b/drivers/net/mscc_eswitch/ocelot_switch.c
@@ -17,6 +17,7 @@
 
 #include "mscc_miim.h"
 #include "mscc_xfer.h"
+#include "mscc_mac_table.h"
 
 #define PHY_CFG0x0
 #define PHY_CFG_ENA0xF
@@ -30,17 +31,6 @@
 #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
 #define 

[U-Boot] [PATCH v3 5/8] net: mscc: Remove unused variables

2019-01-31 Thread Horatiu Vultur
Remove unused variables in the struct ocelot_private and make
miim variable static.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/ocelot_switch.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/net/mscc_eswitch/ocelot_switch.c 
b/drivers/net/mscc_eswitch/ocelot_switch.c
index 40152e6..bf08c35 100644
--- a/drivers/net/mscc_eswitch/ocelot_switch.c
+++ b/drivers/net/mscc_eswitch/ocelot_switch.c
@@ -123,19 +123,7 @@ enum ocelot_phy_id {
 
 struct ocelot_private {
void __iomem *regs[TARGET_MAX];
-
struct mii_dev *bus[NUM_PHY];
-   struct phy_device *phydev;
-   int phy_mode;
-   int max_speed;
-
-   int rx_pos;
-   int rx_siz;
-   int rx_off;
-   int tx_num;
-
-   u8 tx_adj_packetbuf[PKTSIZE_ALIGN + PKTALIGN];
-   void *tx_adj_buf;
 };
 
 static const unsigned long ocelot_regs_qs[] = {
@@ -152,7 +140,7 @@ static const unsigned long ocelot_regs_ana_table[] = {
[MSCC_ANA_TABLES_MACACCESS] = 0x8b3c,
 };
 
-struct mscc_miim_dev miim[NUM_PHY];
+static struct mscc_miim_dev miim[NUM_PHY];
 
 static int mscc_miim_reset(struct mii_dev *bus)
 {
-- 
2.7.4

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


Re: [U-Boot] [RFC 1/9] Arm: dts: imx7d-pico: Import Linux pico-pi dts

2019-01-31 Thread Joris Offouga


Le 31/01/2019 à 13:39, Otavio Salvador a écrit :

On Thu, Jan 31, 2019 at 9:54 AM Offouga Joris  wrote:

On 31 Jan 2019, at 12:36, Otavio Salvador  
wrote:

On Thu, Jan 31, 2019 at 1:59 AM Offouga Joris  wrote:
The PMIC problem occurs after the dm conversion

It'd be good if you could rework the things I commented on the
patchset and refresh the patches on top of imx/master so we can all be
on same page.

Yes I fix them and I send patche without RFC ?

Not yet, we need to fix the PMIC error before sending it. Please fix
the branch so we can keep contributing there until it is good to be
send here ;-)


I update the branche on my repo :)

https://github.com/jorisoffouga/u-boot/tree/pico-imx7d/convert_dm

The patches on top of u-boot master

Best Regards,

Joris




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


[U-Boot] [PATCH v3 3/8] net: mscc: Move ocelot_send and ocelot_recv in a different file.

2019-01-31 Thread Horatiu Vultur
This functions can be reused by other MSCC SoCs therefore,
make them more generic and move them in separate files.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/Makefile|   2 +-
 drivers/net/mscc_eswitch/mscc_xfer.c | 139 +++
 drivers/net/mscc_eswitch/mscc_xfer.h |  20 +
 drivers/net/mscc_eswitch/ocelot_switch.c | 130 -
 4 files changed, 175 insertions(+), 116 deletions(-)
 create mode 100644 drivers/net/mscc_eswitch/mscc_xfer.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_xfer.h

diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
index 1ceb92a..20e8e4c 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -1,2 +1,2 @@
 
-obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o
+obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o
diff --git a/drivers/net/mscc_eswitch/mscc_xfer.c 
b/drivers/net/mscc_eswitch/mscc_xfer.c
new file mode 100644
index 000..f412901
--- /dev/null
+++ b/drivers/net/mscc_eswitch/mscc_xfer.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include 
+#include "mscc_xfer.h"
+
+#define QS_XTR_FLUSH_FLUSH GENMASK(1, 0)
+#define QS_INJ_CTRL_GAP_SIZE(x)((x) << 21)
+#define QS_INJ_CTRL_EOFBIT(19)
+#define QS_INJ_CTRL_SOFBIT(18)
+#define QS_INJ_CTRL_VLD_BYTES(x)   ((x) << 16)
+
+#define XTR_EOF_0 ntohl(0x8000u)
+#define XTR_EOF_1 ntohl(0x8001u)
+#define XTR_EOF_2 ntohl(0x8002u)
+#define XTR_EOF_3 ntohl(0x8003u)
+#define XTR_PRUNEDntohl(0x8004u)
+#define XTR_ABORT ntohl(0x8005u)
+#define XTR_ESCAPEntohl(0x8006u)
+#define XTR_NOT_READY ntohl(0x8007u)
+
+#define BUF_CELL_SZ60
+#define XTR_VALID_BYTES(x) (4 - ((x) & 3))
+
+int mscc_send(void __iomem *regs, const unsigned long *mscc_qs_offset,
+ u32 *ifh, size_t ifh_len, u32 *buff, size_t buff_len)
+{
+   int i, count = (buff_len + 3) / 4, last = buff_len % 4;
+
+   writel(QS_INJ_CTRL_GAP_SIZE(1) | QS_INJ_CTRL_SOF,
+  regs + mscc_qs_offset[MSCC_QS_INJ_CTRL]);
+
+   for (i = 0; i < ifh_len; i++)
+   writel(ifh[i], regs + mscc_qs_offset[MSCC_QS_INJ_WR]);
+
+   for (i = 0; i < count; i++)
+   writel(buff[i], regs + mscc_qs_offset[MSCC_QS_INJ_WR]);
+
+   /* Add padding */
+   while (i < (BUF_CELL_SZ / 4)) {
+   writel(0, regs + mscc_qs_offset[MSCC_QS_INJ_WR]);
+   i++;
+   }
+
+   /* Indicate EOF and valid bytes in last word */
+   writel(QS_INJ_CTRL_GAP_SIZE(1) |
+  QS_INJ_CTRL_VLD_BYTES(buff_len < BUF_CELL_SZ ? 0 : last) |
+  QS_INJ_CTRL_EOF, regs + mscc_qs_offset[MSCC_QS_INJ_CTRL]);
+
+   /* Add dummy CRC */
+   writel(0, regs + mscc_qs_offset[MSCC_QS_INJ_WR]);
+
+   return 0;
+}
+
+int mscc_recv(void __iomem *regs, const unsigned long *mscc_qs_offset,
+ u32 *rxbuf, size_t ifh_len, bool byte_swap)
+{
+   u8 grp = 0; /* Recv everything on CPU group 0 */
+   int i, byte_cnt = 0;
+   bool eof_flag = false, pruned_flag = false, abort_flag = false;
+
+   if (!(readl(regs + mscc_qs_offset[MSCC_QS_XTR_DATA_PRESENT]) &
+ BIT(grp)))
+   return -EAGAIN;
+
+   /* skip IFH */
+   for (i = 0; i < ifh_len; i++)
+   readl(regs + mscc_qs_offset[MSCC_QS_XTR_RD]);
+
+   while (!eof_flag) {
+   u32 val = readl(regs + mscc_qs_offset[MSCC_QS_XTR_RD]);
+   u32 cmp = val;
+
+   if (byte_swap)
+   cmp = ntohl(val);
+
+   switch (cmp) {
+   case XTR_NOT_READY:
+   debug("%d NOT_READY...?\n", byte_cnt);
+   break;
+   case XTR_ABORT:
+   *rxbuf = readl(regs + mscc_qs_offset[MSCC_QS_XTR_RD]);
+   abort_flag = true;
+   eof_flag = true;
+   debug("XTR_ABORT\n");
+   break;
+   case XTR_EOF_0:
+   case XTR_EOF_1:
+   case XTR_EOF_2:
+   case XTR_EOF_3:
+   byte_cnt += XTR_VALID_BYTES(val);
+   *rxbuf = readl(regs + mscc_qs_offset[MSCC_QS_XTR_RD]);
+   eof_flag = true;
+   debug("EOF\n");
+   break;
+   case XTR_PRUNED:
+   /* But get the last 4 bytes as well */
+   eof_flag = true;
+   pruned_flag = true;
+   debug("PRUNED\n");
+   /* fallthrough */
+   case XTR_ESCAPE:
+   *rxbuf = readl(regs + 

[U-Boot] [PATCH v3 1/8] net: mscc: Move ocelot_switch to mscc_eswitch folder

2019-01-31 Thread Horatiu Vultur
Move file ocelot_switch to mscc_eswitch to prepare to add
new net drivers for other MSCC SoCs.

Signed-off-by: Horatiu Vultur 
---
 MAINTAINERS|  2 +-
 drivers/net/Kconfig|  7 +--
 drivers/net/Makefile   |  2 +-
 drivers/net/mscc_eswitch/Kconfig   | 10 ++
 drivers/net/mscc_eswitch/Makefile  |  2 ++
 drivers/net/{ => mscc_eswitch}/ocelot_switch.c |  0
 6 files changed, 15 insertions(+), 8 deletions(-)
 create mode 100644 drivers/net/mscc_eswitch/Kconfig
 create mode 100644 drivers/net/mscc_eswitch/Makefile
 rename drivers/net/{ => mscc_eswitch}/ocelot_switch.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1cb092e..edbb4ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -539,7 +539,7 @@ F:  drivers/gpio/mscc_sgpio.c
 F: drivers/spi/mscc_bb_spi.c
 F: include/configs/vcoreiii.h
 F: drivers/pinctrl/mscc/
-F: drivers/net/ocelot_switch.c
+F: drivers/net/mscc_eswitch/
 
 MIPS JZ4780
 M: Ezequiel Garcia 
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 39ce4e8..6a57028 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -432,12 +432,7 @@ config SNI_AVE
  This driver implements support for the Socionext AVE Ethernet
  controller, as found on the Socionext UniPhier family.
 
-config MSCC_OCELOT_SWITCH
-   bool "Ocelot switch driver"
-   depends on DM_ETH && ARCH_MSCC
-   select PHYLIB
-   help
- This driver supports the Ocelot network switch device.
+source "drivers/net/mscc_eswitch/Kconfig"
 
 config ETHER_ON_FEC1
bool "FEC1"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e38c164..51be72b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -75,4 +75,4 @@ obj-$(CONFIG_FSL_PFE) += pfe_eth/
 obj-$(CONFIG_SNI_AVE) += sni_ave.o
 obj-y += ti/
 obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
-obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o
+obj-y += mscc_eswitch/
diff --git a/drivers/net/mscc_eswitch/Kconfig b/drivers/net/mscc_eswitch/Kconfig
new file mode 100644
index 000..2f3c8cc
--- /dev/null
+++ b/drivers/net/mscc_eswitch/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2019 Microsemi Corporation
+
+config MSCC_OCELOT_SWITCH
+   bool "Ocelot switch driver"
+   depends on DM_ETH && ARCH_MSCC
+   select PHYLIB
+   help
+ This driver supports the Ocelot network switch device.
diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
new file mode 100644
index 000..32f411d
--- /dev/null
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -0,0 +1,2 @@
+
+obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o
diff --git a/drivers/net/ocelot_switch.c 
b/drivers/net/mscc_eswitch/ocelot_switch.c
similarity index 100%
rename from drivers/net/ocelot_switch.c
rename to drivers/net/mscc_eswitch/ocelot_switch.c
-- 
2.7.4

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


[U-Boot] [PATCH v3 2/8] net: mscc: Move miim commands into separate file.

2019-01-31 Thread Horatiu Vultur
Move miim functions that can be shared in a different file inside
mscc_eswitch.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/Makefile|  2 +-
 drivers/net/mscc_eswitch/mscc_miim.c | 74 
 drivers/net/mscc_eswitch/mscc_miim.h | 12 ++
 drivers/net/mscc_eswitch/ocelot_switch.c | 71 +-
 4 files changed, 88 insertions(+), 71 deletions(-)
 create mode 100644 drivers/net/mscc_eswitch/mscc_miim.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_miim.h

diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
index 32f411d..1ceb92a 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -1,2 +1,2 @@
 
-obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o
+obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o
diff --git a/drivers/net/mscc_eswitch/mscc_miim.c 
b/drivers/net/mscc_eswitch/mscc_miim.c
new file mode 100644
index 000..419dcc1
--- /dev/null
+++ b/drivers/net/mscc_eswitch/mscc_miim.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include 
+#include 
+#include "mscc_miim.h"
+
+#define MIIM_STATUS0x0
+#defineMIIM_STAT_BUSY  BIT(3)
+#define MIIM_CMD   0x8
+#defineMIIM_CMD_SCAN   BIT(0)
+#defineMIIM_CMD_OPR_WRITE  BIT(1)
+#defineMIIM_CMD_OPR_READ   BIT(2)
+#defineMIIM_CMD_SINGLE_SCANBIT(3)
+#defineMIIM_CMD_WRDATA(x)  ((x) << 4)
+#defineMIIM_CMD_REGAD(x)   ((x) << 20)
+#defineMIIM_CMD_PHYAD(x)   ((x) << 25)
+#defineMIIM_CMD_VLDBIT(31)
+#define MIIM_DATA  0xC
+#defineMIIM_DATA_ERROR (0x2 << 16)
+
+static int mscc_miim_wait_ready(struct mscc_miim_dev *miim)
+{
+   return wait_for_bit_le32(miim->regs + MIIM_STATUS, MIIM_STAT_BUSY,
+false, 250, false);
+}
+
+int mscc_miim_read(struct mii_dev *bus, int addr, int devad, int reg)
+{
+   struct mscc_miim_dev *miim = (struct mscc_miim_dev *)bus->priv;
+   u32 val;
+   int ret;
+
+   ret = mscc_miim_wait_ready(miim);
+   if (ret)
+   goto out;
+
+   writel(MIIM_CMD_VLD | MIIM_CMD_PHYAD(addr) |
+  MIIM_CMD_REGAD(reg) | MIIM_CMD_OPR_READ,
+  miim->regs + MIIM_CMD);
+
+   ret = mscc_miim_wait_ready(miim);
+   if (ret)
+   goto out;
+
+   val = readl(miim->regs + MIIM_DATA);
+   if (val & MIIM_DATA_ERROR) {
+   ret = -EIO;
+   goto out;
+   }
+
+   ret = val & 0x;
+ out:
+   return ret;
+}
+
+int mscc_miim_write(struct mii_dev *bus, int addr, int devad, int reg,
+   u16 val)
+{
+   struct mscc_miim_dev *miim = (struct mscc_miim_dev *)bus->priv;
+   int ret;
+
+   ret = mscc_miim_wait_ready(miim);
+   if (ret < 0)
+   goto out;
+
+   writel(MIIM_CMD_VLD | MIIM_CMD_PHYAD(addr) |
+  MIIM_CMD_REGAD(reg) | MIIM_CMD_WRDATA(val) |
+  MIIM_CMD_OPR_WRITE, miim->regs + MIIM_CMD);
+ out:
+   return ret;
+}
diff --git a/drivers/net/mscc_eswitch/mscc_miim.h 
b/drivers/net/mscc_eswitch/mscc_miim.h
new file mode 100644
index 000..0e5d5e3
--- /dev/null
+++ b/drivers/net/mscc_eswitch/mscc_miim.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+struct mscc_miim_dev {
+   void __iomem *regs;
+   void __iomem *phy_regs;
+};
+
+int mscc_miim_read(struct mii_dev *bus, int addr, int devad, int reg);
+int mscc_miim_write(struct mii_dev *bus, int addr, int devad, int reg, u16 
val);
diff --git a/drivers/net/mscc_eswitch/ocelot_switch.c 
b/drivers/net/mscc_eswitch/ocelot_switch.c
index 9fed26c..a4361e8 100644
--- a/drivers/net/mscc_eswitch/ocelot_switch.c
+++ b/drivers/net/mscc_eswitch/ocelot_switch.c
@@ -15,19 +15,7 @@
 #include 
 #include 
 
-#define MIIM_STATUS0x0
-#defineMIIM_STAT_BUSY  BIT(3)
-#define MIIM_CMD   0x8
-#defineMIIM_CMD_SCAN   BIT(0)
-#defineMIIM_CMD_OPR_WRITE  BIT(1)
-#defineMIIM_CMD_OPR_READ   BIT(2)
-#defineMIIM_CMD_SINGLE_SCANBIT(3)
-#defineMIIM_CMD_WRDATA(x)  ((x) << 4)
-#defineMIIM_CMD_REGAD(x)   ((x) << 20)
-#defineMIIM_CMD_PHYAD(x)   ((x) << 25)
-#defineMIIM_CMD_VLDBIT(31)
-#define MIIM_DATA  0xC
-#defineMIIM_DATA_ERROR (0x2 << 16)
+#include "mscc_miim.h"
 
 #define PHY_CFG0x0
 #define PHY_CFG_ENA  

[U-Boot] [PATCH v3 0/8] Add network support for Luton SoCs

2019-01-31 Thread Horatiu Vultur
This series adds network support for Luton SoCs. Currently
there is not support for Luton SoCs in Linux.

v3-changes:
 - reorder the changes of the commits and add Kconfig
   in mscc_eswitch folder

v2-changes:
 - reuse functions from ocelot for luton network driver

Horatiu Vultur (8):
  net: mscc: Move ocelot_switch to mscc_eswitch folder
  net: mscc: Move miim commands into separate file.
  net: mscc: Move ocelot_send and ocelot_recv in a different file.
  net: mscc: Move mac_table_add function into different file.
  net: mscc: Remove unused variables
  mips: mscc: luton: Add ethernet nodes for Luton.
  net: Add MSCC Luton networkd driver.
  configs: mscc_luton: Add network support.

 MAINTAINERS|   2 +-
 arch/mips/dts/luton_pcb090.dts |  51 ++
 arch/mips/dts/luton_pcb091.dts |  51 ++
 arch/mips/dts/mscc,luton.dtsi  | 165 ++
 configs/mscc_luton_defconfig   |   1 +
 drivers/net/Kconfig|   7 +-
 drivers/net/Makefile   |   2 +-
 drivers/net/mscc_eswitch/Kconfig   |  17 +
 drivers/net/mscc_eswitch/Makefile  |   3 +
 drivers/net/mscc_eswitch/luton_switch.c| 736 +
 drivers/net/mscc_eswitch/mscc_mac_table.c  |  74 +++
 drivers/net/mscc_eswitch/mscc_mac_table.h  |  19 +
 drivers/net/mscc_eswitch/mscc_miim.c   |  74 +++
 drivers/net/mscc_eswitch/mscc_miim.h   |  12 +
 drivers/net/mscc_eswitch/mscc_xfer.c   | 139 +
 drivers/net/mscc_eswitch/mscc_xfer.h   |  20 +
 drivers/net/{ => mscc_eswitch}/ocelot_switch.c | 299 +-
 17 files changed, 1392 insertions(+), 280 deletions(-)
 create mode 100644 drivers/net/mscc_eswitch/Kconfig
 create mode 100644 drivers/net/mscc_eswitch/Makefile
 create mode 100644 drivers/net/mscc_eswitch/luton_switch.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_mac_table.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_mac_table.h
 create mode 100644 drivers/net/mscc_eswitch/mscc_miim.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_miim.h
 create mode 100644 drivers/net/mscc_eswitch/mscc_xfer.c
 create mode 100644 drivers/net/mscc_eswitch/mscc_xfer.h
 rename drivers/net/{ => mscc_eswitch}/ocelot_switch.c (62%)

-- 
2.7.4

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


Re: [U-Boot] [PATCH v3 00/22] mx6sabre: Add DM and SPL FIT support

2019-01-31 Thread Abel Vesa
On 19-01-31 09:41:11, Tom Rini wrote:
> On Thu, Jan 31, 2019 at 12:59:19PM +, Abel Vesa wrote:
> > On 19-01-30 13:58:19, Tom Rini wrote:
> > > On Wed, Jan 30, 2019 at 01:39:50PM +, Abel Vesa wrote:
> > > 
> > > > The second version is here:
> > > > https://lists.denx.de/pipermail/u-boot/2019-January/356557.html
> > > > 
> > > > Changes since v2:
> > > >  * Removed the unecessary SYS_MALLOC_F_LEN from both defocnfig
> > > >  * Fixed the copyright for all the *u-boot.dtsi files
> > > 
> > > OK, but you didn't answer why you need to specify your own its file when
> > > the TI examples show how to have mkimage generate this for you, thanks!
> > > 
> > 
> > I might be wrong here but TI is doing this for MLO, which AFAIU, it's for
> > SPL. The fit_spl.its I'm adding here is actually for u-boot proper.
> > 
> > SPL expects descriptions in the configurations and that can't be done
> > without its file, again, AFAIK.
> > 
> > Please let me know what exactly am I missing here.
> 
> The flag to mkimage is not about SPL but rather "create a single
> configurations its file on the fly".  This should also be fine for the
> its file in patch 10/22 (of v2, don't have v3 in front of me in
> patchwork).
> 

Well, I tried something like this (manually):

$ ./tools/mkimage -f auto -C none -A ARM -T standalone -a 0x1780 -e 
0x1780 -d u-boot-fit-dtb.bin -n "U-Boot" u-boot.itb -E

and the output was:

FIT description: Standalone Program image with one or more FDT blobs
  
Created: Thu Jan 31 13:58:01 2019   
  
 Image 0 (standalone-1) 
  
  Description:  U-Boot  
  
  Created:  Thu Jan 31 13:58:01 2019
  
  Type: Standalone Program  
  
  Compression:  uncompressed
  
  Data Size:646400 Bytes = 631.25 KiB = 0.62 MiB
  
  Architecture: ARM 
  
  Load Address: 0x1780  
  
  Entry Point:  0x1780  
  
 Default Configuration: 'conf-1'
  
 Configuration 0 (conf-1)   
  
  Description:  unavailable 
  
  Kernel:   unavailable 
  

And then the SPL complains about the configuration description:

U-Boot SPL 2019.01-00374-gbe79a83 (Jan 31 2019 - 13:56:01 +0200)
Trying to boot from MMC1
fit_find_config_node: Missing FDT description in DTB
No matching DT out of these options:
   Firmware image with one or more FDT blobs
fit_find_config_node: Missing FDT description in DTB
No matching DT out of these options:
   Firmware image with one or more FDT blobs
fit_find_config_node: Missing FDT description in DTB
No matching DT out of these options:
   Firmware image with one or more FDT blobs
mmc_load_image_raw_sector: mmc block read error
spl: no partition table found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

But with the fit_spl.its file I added I have this and works:

FIT description: Image for u-boot proper (with dtb appended)
Created: Thu Jan 31 13:57:02 2019   
 Image 0 (uboot@1)  
  Description:  U-Boot  
  Created:  Thu Jan 31 13:57:02 2019
  Type: Standalone Program  
  Compression:  uncompressed
  Data Size:646400 Bytes = 631.25 KiB = 0.62 MiB
  Architecture: ARM 
  Load Address: 0x1780  
  Entry Point:  unavailable 
 Default Configuration: 'conf@1'
 Configuration 0 (conf@1)   
  Description:  i.MX armv7  
  Kernel:   unavailable 
  Loadables:uboot@1 

So the differences between this and the one generated with mkimage+flags
are the loadables and the description in the configuration 0.

Can I specify those through flags ?

> -- 
> Tom

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


  1   2   3   >