Re: [U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support

[Simon Goldschmidt]

On 22.02.2018 07:29, See, Chin Liang wrote:

On Wed, 2018-02-21 at 20:23 +0100, Marek Vasut wrote:

On 02/21/2018 08:39 AM, chin.liang@intel.com wrote:

From: Chin Liang See 

Enable Macronix flash support for Cyclone5 SoC

Do these boards actually have a macronix flash ? Most of the ones I
know
of do not.

Good question.

Actually they are pin compatible and customer can replace the existing
one. FYI, there seems a NOR flash shortage worldwide which lead to
requests by customer to change the BOM list.


But at least the Socrates seems to be out of production. I don't see why 
we would have to change the defconfig here.


Simon



Thanks
Chin Liang


Signed-off-by: Chin Liang See 
---
  configs/socfpga_cyclone5_defconfig| 1 +
  configs/socfpga_is1_defconfig | 1 +
  configs/socfpga_sockit_defconfig  | 1 +
  configs/socfpga_socrates_defconfig| 1 +
  configs/socfpga_sr1500_defconfig  | 1 +
  configs/socfpga_vining_fpga_defconfig | 1 +
  6 files changed, 6 insertions(+)

diff --git a/configs/socfpga_cyclone5_defconfig
b/configs/socfpga_cyclone5_defconfig
index 6ebd8a9..aa535c6 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
  CONFIG_MMC_DW=y
  CONFIG_SPI_FLASH=y
  CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
  CONFIG_SPI_FLASH_STMICRO=y
  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
diff --git a/configs/socfpga_is1_defconfig
b/configs/socfpga_is1_defconfig
index 08628ab..7be720a 100644
--- a/configs/socfpga_is1_defconfig
+++ b/configs/socfpga_is1_defconfig
@@ -48,6 +48,7 @@ CONFIG_SYS_I2C_DW=y
  # CONFIG_MMC is not set
  CONFIG_SPI_FLASH=y
  CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_STMICRO=y
  CONFIG_PHY_MICREL=y
  CONFIG_PHY_MICREL_KSZ90X1=y
diff --git a/configs/socfpga_sockit_defconfig
b/configs/socfpga_sockit_defconfig
index 8ebe394..6edb47f 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
  CONFIG_MMC_DW=y
  CONFIG_SPI_FLASH=y
  CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
  CONFIG_SPI_FLASH_STMICRO=y
  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
diff --git a/configs/socfpga_socrates_defconfig
b/configs/socfpga_socrates_defconfig
index 9f42481..7c2428a 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -54,6 +54,7 @@ CONFIG_DM_MMC=y
  CONFIG_MMC_DW=y
  CONFIG_SPI_FLASH=y
  CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
  CONFIG_SPI_FLASH_STMICRO=y
  CONFIG_PHY_MICREL=y
diff --git a/configs/socfpga_sr1500_defconfig
b/configs/socfpga_sr1500_defconfig
index f9ed1a3..df1ee31 100644
--- a/configs/socfpga_sr1500_defconfig
+++ b/configs/socfpga_sr1500_defconfig
@@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
  CONFIG_MMC_DW=y
  CONFIG_SPI_FLASH=y
  CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_STMICRO=y
  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
  CONFIG_DM_ETH=y
diff --git a/configs/socfpga_vining_fpga_defconfig
b/configs/socfpga_vining_fpga_defconfig
index 6670b9f..512d701 100644
--- a/configs/socfpga_vining_fpga_defconfig
+++ b/configs/socfpga_vining_fpga_defconfig
@@ -69,6 +69,7 @@ CONFIG_LED_STATUS_CMD=y
  CONFIG_DM_MMC=y
  CONFIG_MMC_DW=y
  CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
  CONFIG_SPI_FLASH_STMICRO=y
  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set


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


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

Re: [U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support

[See, Chin Liang]

On Wed, 2018-02-21 at 20:23 +0100, Marek Vasut wrote:
> On 02/21/2018 08:39 AM, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Enable Macronix flash support for Cyclone5 SoC
> Do these boards actually have a macronix flash ? Most of the ones I
> know
> of do not.

Good question. 

Actually they are pin compatible and customer can replace the existing
one. FYI, there seems a NOR flash shortage worldwide which lead to
requests by customer to change the BOM list.

Thanks
Chin Liang

> 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >  configs/socfpga_cyclone5_defconfig| 1 +
> >  configs/socfpga_is1_defconfig | 1 +
> >  configs/socfpga_sockit_defconfig  | 1 +
> >  configs/socfpga_socrates_defconfig| 1 +
> >  configs/socfpga_sr1500_defconfig  | 1 +
> >  configs/socfpga_vining_fpga_defconfig | 1 +
> >  6 files changed, 6 insertions(+)
> > 
> > diff --git a/configs/socfpga_cyclone5_defconfig
> > b/configs/socfpga_cyclone5_defconfig
> > index 6ebd8a9..aa535c6 100644
> > --- a/configs/socfpga_cyclone5_defconfig
> > +++ b/configs/socfpga_cyclone5_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > diff --git a/configs/socfpga_is1_defconfig
> > b/configs/socfpga_is1_defconfig
> > index 08628ab..7be720a 100644
> > --- a/configs/socfpga_is1_defconfig
> > +++ b/configs/socfpga_is1_defconfig
> > @@ -48,6 +48,7 @@ CONFIG_SYS_I2C_DW=y
> >  # CONFIG_MMC is not set
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  CONFIG_PHY_MICREL=y
> >  CONFIG_PHY_MICREL_KSZ90X1=y
> > diff --git a/configs/socfpga_sockit_defconfig
> > b/configs/socfpga_sockit_defconfig
> > index 8ebe394..6edb47f 100644
> > --- a/configs/socfpga_sockit_defconfig
> > +++ b/configs/socfpga_sockit_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > diff --git a/configs/socfpga_socrates_defconfig
> > b/configs/socfpga_socrates_defconfig
> > index 9f42481..7c2428a 100644
> > --- a/configs/socfpga_socrates_defconfig
> > +++ b/configs/socfpga_socrates_defconfig
> > @@ -54,6 +54,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  CONFIG_PHY_MICREL=y
> > diff --git a/configs/socfpga_sr1500_defconfig
> > b/configs/socfpga_sr1500_defconfig
> > index f9ed1a3..df1ee31 100644
> > --- a/configs/socfpga_sr1500_defconfig
> > +++ b/configs/socfpga_sr1500_defconfig
> > @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> >  CONFIG_SPI_FLASH_BAR=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> >  CONFIG_DM_ETH=y
> > diff --git a/configs/socfpga_vining_fpga_defconfig
> > b/configs/socfpga_vining_fpga_defconfig
> > index 6670b9f..512d701 100644
> > --- a/configs/socfpga_vining_fpga_defconfig
> > +++ b/configs/socfpga_vining_fpga_defconfig
> > @@ -69,6 +69,7 @@ CONFIG_LED_STATUS_CMD=y
> >  CONFIG_DM_MMC=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_SPI_FLASH=y
> > +CONFIG_SPI_FLASH_MACRONIX=y
> >  CONFIG_SPI_FLASH_SPANSION=y
> >  CONFIG_SPI_FLASH_STMICRO=y
> >  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 3/4] cmd: ubifs: Factor out some checking codes into cmd_ubifs_mount()

[Chee, Tien Fong]

On Thu, 2018-02-15 at 15:59 +0100, Marek Vasut wrote:
> On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > cmd_ubifs_mount() function would be called directly instead of
> > involving whole command machinery for mounting ubifs in
> > generic firmware loader, so some checking codes need to be factored
> > out
> > into cmd_ubifs_mount() without breaking original functionality
> > design.
> > 
> > Signed-off-by: Tien Fong Chee 
> [...]
> 
> > 
> > diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
> > index 827dbfc..fb300e8 100644
> > --- a/include/ubi_uboot.h
> > +++ b/include/ubi_uboot.h
> > @@ -76,5 +76,6 @@ extern int ubi_volume_read(char *volume, char
> > *buf, size_t size);
> >  
> >  extern struct ubi_device *ubi_devices[];
> >  int cmd_ubifs_umount(void);
> > +int cmd_ubifs_mount(char *vol_name);
> Swap these two -- mount first and umount seconds.
> 
Okay. noted.

> With that
> Reviewed-by: Marek Vasut 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/13] LS1012A PFE driver patch series

[Calvin Johnson]

Hi Joe,

> -Original Message-
> From: Calvin Johnson [mailto:calvin.john...@nxp.com]
> Sent: Thursday, February 15, 2018 7:47 PM
> To: u-boot@lists.denx.de
> Cc: joe.hershber...@ni.com; York Sun ; Anji Jagarlmudi
> ; Calvin Johnson 
> Subject: [PATCH v2 00/13] LS1012A PFE driver patch series
> 



> Changes in v2 series:
> 1. PFE patches submitted on top of this base patch are now merged to
> this patch.
> 2. Platform changes are segregated into different patches.
> 3. Network enabled on 2g5rdb platform
> 4. Moved from legacy to new driver model.

Gentle reminder. Hope the PFE patches didn't miss your sight.

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

[U-Boot] [PATCH for 2018.03] sunxi: README.sunxi64: Add hint about non-debug ATF

[Andre Przywara]

As we are running into issues where the final U-Boot FIT image file is
exceeding our size limit, add a hint to the README.sunxi64 file
to point out the possibility of building non-debug versions of the ATF
binary. This is about 12KB smaller than the standard debug build, and
so again allows successful U-Boot builds for many boards with the
Allwinner H5 SoC.
Please note that under normal circumstances the debug build is still
recommended, as it gives valuable clues in case something goes wrong in
the ATF.

Signed-off-by: Andre Przywara 
---
Hi,

as the level of desperation about Allwinner 64-bit FIT image sizes rises,
we are getting more into the slightly cheaty section with our mitigations.
However as my previous attempts in fixing this issue were not that warmly
welcomed, I now suggest this rather pragmatic solution, which avoids hacking
U-Boot badly. This fixes the various H5 builds for me.

Cheers,
Andre.

 board/sunxi/README.sunxi64 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index c492f749b8..eefa5001a2 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -38,6 +38,12 @@ the root of your U-Boot build directory (or create a 
symbolic link).
 $ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin
   (adjust the actual path accordingly)
 
+If you run into size issues with the resulting U-Boot image file, it might
+help to use a release build, by using "DEBUG=0" when building bl31.bin.
+As sometimes the ATF build process is a bit picky about the toolchain used,
+or if you can't be bothered with building ATF, there are known working
+binaries in the firmware repository[3], purely for convenience reasons.
+
  SPL/U-Boot
 
 Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
-- 
2.14.1

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

Re: [U-Boot] TCP Patch Set

[Joe Hershberger]

Hi Duncan,

On Wed, Feb 21, 2018 at 6:39 PM, Duncan Hare  wrote:
> On Mon, 12 Feb 2018 13:35:11 -0600
> Joe Hershberger  wrote:
>
>
>> >> >>
>> >> >> > I need to determine if it
>> >> >> > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the
>> >> >> > "net_rx_packets" buffer pool defined in net/net.c
>> >> >> >
>
>> >> >
>> >> > Two solutions:
>> >> >
>> >> > Option 1.
>> >> >
>> >>
>> >> I think option 1 is the way to go.
>> >>
>> >> Thanks,
>> >> -Joe
>> >
>> > Joe
>> >
>> > The overruns were caused by printing error messages. The print
>> > process is (very) slow compared with packet and computer speeds, and
>> > causes overruns.
>> >
>> > I turned off all the error messages in tcp.c and the overruns also
>> > stopped.
>
>> >
>> > Duncan
> ---
> Joe
>
> I'm now at the state where I'm satisfied the selective
> acknowledgment implementation is working well, having re-written the
> code.
>
> I've transferred 20 4 Mbyte kernels from cloud to desktop without a
> failure.
>
> How to proceed?
>
> Issue the patch set again? Or just the TCP module?
>
> Then what's the next step?

I think the next step is to rework your patch submission process,
sending the patches to just yourself, until they meet the standard (
http://www.denx.de/wiki/U-Boot/Patches ) so that all of the tooling I
use can work with them. Otherwise I spend lots of time, sometimes
hours, trying to shove malformed patches through the process. I really
don't have time for that, so I have to ask that you use patman and
send properly formatted patches. Once you have that down, I'll
re-review what you have at this point and go from there.

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

[U-Boot] [PATCH 2/2] doc: mxc_hab: Update i.MX HAB documentation

[Breno Lima]

From: Breno Lima 

The README.mxc_hab is outdated and need improvements, add the following
modifications:

- Reorganize document and remove duplicate content
- Add CST download link
- Update CST package name
- Align command lines with CST v2.3.3
- Update U-Boot binary name
- Remove CSF padding since is not documented in AN4581

Signed-off-by: Breno Lima 
---
 doc/README.mxc_hab | 72 +-
 1 file changed, 33 insertions(+), 39 deletions(-)

diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
index 056ade7..75390a5 100644
--- a/doc/README.mxc_hab
+++ b/doc/README.mxc_hab
@@ -11,14 +11,22 @@ In addition, the U-Boot image to be programmed into the
 boot media needs to be properly constructed, i.e. it must contain a
 proper Command Sequence File (CSF).
 
-The Initial Vector Table contains a pointer to the CSF. Please see
-doc/README.imximage for how to prepare u-boot.imx.
+The CSF itself is generated by the i.MX High Assurance Boot Reference
+Code Signing Tool.
+https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL
 
-The CSF itself is being generated by Freescale HAB tools.
+More information about the CSF and HAB can be found in the AN4581.
+https://www.nxp.com/docs/en/application-note/AN4581.pdf
+
+We don't want to explain how to create a PKI tree or SRK table as
+this is well explained in the Application Note.
 
-mkimage will output additional information about "HAB Blocks"
-which can be used in the Freescale tooling to authenticate U-Boot
-(entries in the CSF file).
+2. Secure Boot on non-SPL targets
+-
+
+On non-SPL targets a singe U-Boot binary is generated, mkimage will
+output additional information about "HAB Blocks" which can be used
+in the CST to authenticate the U-Boot image (entries in the CSF file).
 
 Image Type:   Freescale IMX Boot Image
 Image Ver:2 (i.MX53/6 compatible)
@@ -34,46 +42,35 @@ HAB Blocks:   177ff400  0004dc00
|
--- (3)
 
-(1)Size of area in file u-boot.imx to sign
+(1)Size of area in file u-boot-dtb.imx to sign
This area should include the IVT, the Boot Data the DCD
and U-Boot itself.
-(2)Start of area in u-boot.imx to sign
+(2)Start of area in u-boot-dtb.imx to sign
 (3)Start of area in RAM to authenticate
 
 CONFIG_SECURE_BOOT currently enables only an additional command
 'hab_status' in U-Boot to retrieve the HAB status and events. This
 can be useful while developing and testing HAB.
 
-Commands to generate a signed U-Boot using Freescale HAB tools:
-cst --o U-Boot_CSF.bin < U-Boot.CSF
-objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 \
-   U-Boot_CSF.bin U-Boot_CSF_pad.bin
-cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx
-
-NOTE: U-Boot_CSF.bin needs to be padded to the value specified in
-the imximage.cfg file.
-
+Commands to generate a signed U-Boot using i.MX HAB CST tool:
+# Compile CSF and create signature
+cst --o csf-u-boot.bin --i command_sequence_uboot.csf
+# Append compiled CSF to Binary
+cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx
 
-2. Using Secure Boot on i.MX6 machines with SPL support

+3. Secure Boot on SPL targets
+-
 
 This version of U-Boot is able to build a signable version of the SPL
 as well as a signable version of the U-Boot image. The signature can
 be verified through High Assurance Boot (HAB).
 
-CONFIG_SECURE_BOOT is needed to build those two binaries.
 After building, you need to create a command sequence file and use
-Freescales Code Signing Tool to sign both binaries. After creation,
+i.MX HAB Code Signing Tool to sign both binaries. After creation,
 the mkimage tool outputs the required information about the HAB Blocks
 parameter for the CSF. During the build, the information is preserved
 in log files named as the binaries. (SPL.log and u-boot-ivt.log).
 
-More information about the CSF and HAB can be found in the AN4581.
-https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf
-
-We don't want to explain how to create a PKI tree or SRK table as
-this is well explained in the Application Note.
-
 Example Output of the SPL (imximage) creation:
  Image Type:   Freescale IMX Boot Image
  Image Ver:2 (i.MX53/6/7 compatible)
@@ -92,23 +89,22 @@ Example Output of the u-boot-ivt.img (firmware_ivt) 
creation:
  Entry Point:  
  HAB Blocks:   0x177fffc0   0x   0x00054020
 
-The CST (Code Signing Tool) can be downloaded from NXP.
 # Compile CSF and create signature
-./cst --o csf-u-boot.bin < command_sequence_uboot.csf
-./cst --o csf-SPL.bin < command_sequence_spl.csf
+cst --o csf-u-boot.bin --i command_sequence_uboot.csf
+cst --o csf-SPL.bin --i command_sequence_spl.csf
 # Append compiled CSF to Binary
 cat SPL csf-SPL.bin > SPL-signed
 cat u-boot-ivt.img csf-u-boot.bin > 

[U-Boot] [PATCH 1/2] doc: mxc_hab: Move HAB related info to the appropriate doc

[Breno Lima]

From: Breno Lima 

Currently the High Assurance Boot procedure is documented in two
places:

- doc/README.imx6
- doc/README.mxc_hab

It is better to consolidate all HAB related information into
README.mxc_hab file, so move the content from README.imx6 to
README.mxc_hab.

Signed-off-by: Breno Lima 
---
 doc/README.imx6| 48 -
 doc/README.mxc_hab | 57 +++---
 2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/doc/README.imx6 b/doc/README.imx6
index 2e8f1d8..b0644f8 100644
--- a/doc/README.imx6
+++ b/doc/README.imx6
@@ -113,51 +113,3 @@ issue the command:
 In order to load SPL and u-boot.img via imx_usb_loader tool,
 please refer to doc/README.sdp.
 
-3. Using Secure Boot on i.MX6 machines with SPL support

-
-This version of U-Boot is able to build a signable version of the SPL
-as well as a signable version of the U-Boot image. The signature can
-be verified through High Assurance Boot (HAB).
-
-CONFIG_SECURE_BOOT is needed to build those two binaries.
-After building, you need to create a command sequence file and use
-Freescales Code Signing Tool to sign both binaries. After creation,
-the mkimage tool outputs the required information about the HAB Blocks
-parameter for the CSF. During the build, the information is preserved
-in log files named as the binaries. (SPL.log and u-boot-ivt.log).
-
-More information about the CSF and HAB can be found in the AN4581.
-https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf
-
-We don't want to explain how to create a PKI tree or SRK table as
-this is well explained in the Application Note.
-
-Example Output of the SPL (imximage) creation:
- Image Type:   Freescale IMX Boot Image
- Image Ver:2 (i.MX53/6/7 compatible)
- Mode: DCD
- Data Size:61440 Bytes = 60.00 kB = 0.06 MB
- Load Address: 00907420
- Entry Point:  00908000
- HAB Blocks:   00907400  cc00
-
-Example Output of the u-boot-ivt.img (firmware_ivt) creation:
- Image Name:   U-Boot 2016.11-rc1-31589-g2a4411
- Created:  Sat Nov  5 21:53:28 2016
- Image Type:   ARM U-Boot Firmware with HABv4 IVT (uncompressed)
- Data Size:352192 Bytes = 343.94 kB = 0.34 MB
- Load Address: 1780
- Entry Point:  
- HAB Blocks:   0x177fffc0   0x   0x00054020
-
-The CST (Code Signing Tool) can be downloaded from NXP.
-# Compile CSF and create signature
-./cst --o csf-u-boot.bin < command_sequence_uboot.csf
-./cst --o csf-SPL.bin < command_sequence_spl.csf
-# Append compiled CSF to Binary
-cat SPL csf-SPL.bin > SPL-signed
-cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img
-
-These two signed binaries can be used on an i.MX6 in closed
-configuration when the according SRK Table Hash has been flashed.
diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
index 4bd07d3..056ade7 100644
--- a/doc/README.mxc_hab
+++ b/doc/README.mxc_hab
@@ -1,4 +1,5 @@
-High Assurance Boot (HAB) for i.MX6 CPUs
+1. High Assurance Boot (HAB) for i.MX CPUs
+--
 
 To enable the authenticated or encrypted boot mode of U-Boot, it is
 required to set the proper configuration for the target board. This
@@ -52,8 +53,58 @@ cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx
 NOTE: U-Boot_CSF.bin needs to be padded to the value specified in
 the imximage.cfg file.
 
-Setup U-Boot Image for Encrypted Boot
--
+
+2. Using Secure Boot on i.MX6 machines with SPL support
+---
+
+This version of U-Boot is able to build a signable version of the SPL
+as well as a signable version of the U-Boot image. The signature can
+be verified through High Assurance Boot (HAB).
+
+CONFIG_SECURE_BOOT is needed to build those two binaries.
+After building, you need to create a command sequence file and use
+Freescales Code Signing Tool to sign both binaries. After creation,
+the mkimage tool outputs the required information about the HAB Blocks
+parameter for the CSF. During the build, the information is preserved
+in log files named as the binaries. (SPL.log and u-boot-ivt.log).
+
+More information about the CSF and HAB can be found in the AN4581.
+https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf
+
+We don't want to explain how to create a PKI tree or SRK table as
+this is well explained in the Application Note.
+
+Example Output of the SPL (imximage) creation:
+ Image Type:   Freescale IMX Boot Image
+ Image Ver:2 (i.MX53/6/7 compatible)
+ Mode: DCD
+ Data Size:61440 Bytes = 60.00 kB = 0.06 MB
+ Load Address: 00907420
+ Entry Point:  00908000
+ HAB Blocks:   00907400  cc00
+
+Example Output of the u-boot-ivt.img (firmware_ivt) creation:
+ Image Name:   U-Boot 2016.11-rc1-31589-g2a4411
+ Created:  Sat Nov  5 21:53:28 2016
+ Image Type:   ARM U-Boot 

Re: [U-Boot] TCP Patch Set

[Duncan Hare]

On Mon, 12 Feb 2018 13:35:11 -0600
Joe Hershberger  wrote:


> >> >>  
> >> >> > I need to determine if it
> >> >> > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the
> >> >> > "net_rx_packets" buffer pool defined in net/net.c
> >> >> >

> >> >
> >> > Two solutions:
> >> >
> >> > Option 1.
> >> >  
> >>
> >> I think option 1 is the way to go.
> >>
> >> Thanks,
> >> -Joe  
> >
> > Joe
> >
> > The overruns were caused by printing error messages. The print
> > process is (very) slow compared with packet and computer speeds, and
> > causes overruns.
> >
> > I turned off all the error messages in tcp.c and the overruns also
> > stopped.  

> >
> > Duncan
---
Joe

I'm now at the state where I'm satisfied the selective
acknowledgment implementation is working well, having re-written the
code.

I've transferred 20 4 Mbyte kernels from cloud to desktop without a
failure. 

How to proceed?

Issue the patch set again? Or just the TCP module?

Then what's the next step?

Regards
Duncan

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

Re: [U-Boot] [PATCH 3/3] cbfs: add support for cbfs header components

[Alexander Graf]

On 15.02.18 07:40, Andre Heider wrote:
> This fixes walking the cbfs file list because the bound checks do not
> apply to header components.
> 
> Output of coreboot's cbfstool:
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   21344 none
> fallback/ramstage  0x5440 stage   36848 none
> config 0xe480 raw   310 none
> revision   0xe600 raw   575 none
> fallback/bl31  0xe880 payload 15931 none
> fallback/payload   0x12700payload205449 none
> (empty)0x44a00null   111768 none
> header pointer 0x5fec0cbfs header 4 none
> 
> Output of u-boot's cbfsls:
>  size  type  name
> --
>32   cbfs header  cbfs master header
> 21344 stage  fallback/romstage
> 36848 stage  fallback/ramstage
>   310   raw  config
>   575   raw  revision
> 15931   payload  fallback/bl31
>205449   payload  fallback/payload
>111768  null  (empty)
> 4   cbfs header  header pointer

I don't see a before/after comparison? What output exactly did get fixed?

I don't quite understand what case exactly this fixes. The bounds check
seems to try to find out whether the header is within the master header
range, right?

So doesn't this just mean we're reading beyond the expected fs size?


Alex

> 
> Signed-off-by: Andre Heider 
> ---
>  cmd/cbfs.c |  3 +++
>  fs/cbfs/cbfs.c | 10 ++
>  include/cbfs.h |  1 +
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index 736f8c4527..f5ad04c45a 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -113,6 +113,9 @@ static int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   printf(" %8d", file_cbfs_size(file));
>  
>   switch (type) {
> + case CBFS_COMPONENT_CBFSHEADER:
> + type_name = "cbfs header";
> + break;
>   case CBFS_TYPE_STAGE:
>   type_name = "stage";
>   break;
> diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c
> index 46da8f134f..389f60702b 100644
> --- a/fs/cbfs/cbfs.c
> +++ b/fs/cbfs/cbfs.c
> @@ -97,10 +97,12 @@ static int file_cbfs_next_file(u8 *start, u32 size, u32 
> align,
>   }
>  
>   swap_file_header(, fileHeader);
> - if (header.offset < sizeof(struct cbfs_fileheader) ||
> - header.offset > header.len) {
> - file_cbfs_result = CBFS_BAD_FILE;
> - return -1;
> + if (header.type != CBFS_COMPONENT_CBFSHEADER) {
> + if (header.offset < sizeof(struct cbfs_fileheader) ||
> + header.offset > header.len) {
> + file_cbfs_result = CBFS_BAD_FILE;
> + return -1;
> + }
>   }
>   newNode->next = NULL;
>   newNode->type = header.type;
> diff --git a/include/cbfs.h b/include/cbfs.h
> index f50280107b..d5d9d8ce97 100644
> --- a/include/cbfs.h
> +++ b/include/cbfs.h
> @@ -19,6 +19,7 @@ enum cbfs_result {
>  };
>  
>  enum cbfs_filetype {
> + CBFS_COMPONENT_CBFSHEADER = 0x02,
>   CBFS_TYPE_STAGE = 0x10,
>   CBFS_TYPE_PAYLOAD = 0x20,
>   CBFS_TYPE_OPTIONROM = 0x30,
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] fs: cbfs: fix locating the cbfs header

[Alexander Graf]

On 15.02.18 07:40, Andre Heider wrote:
> The value at the end of the rom is not a pointer, it is an offset
> relative to the end of rom.

Do you have any documentation pointers to this? Even just pointing to a
specific line of code in coreboot would be helpful in case anyone wants
to read it up.

> 
> Signed-off-by: Andre Heider 
> ---
>  fs/cbfs/cbfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c
> index 6e1107d751..46da8f134f 100644
> --- a/fs/cbfs/cbfs.c
> +++ b/fs/cbfs/cbfs.c
> @@ -168,9 +168,9 @@ static int file_cbfs_load_header(uintptr_t end_of_rom,
>struct cbfs_header *header)
>  {
>   struct cbfs_header *header_in_rom;
> + int32_t offset = *(u32 *)(end_of_rom - 3);

Accessing a pointer that gets subtracted by 3 looks terribly wrong.
Unfortunately it's correct, because the pointer itself is unaligned.

How about we change the logic so that we calculate an aligned pointer
(after_rom?) which we sanity check for alignment and base all
calculations on that instead?

That way the next time someone comes around he's not getting puzzled why
we're subtracting 3 and adding 1 to the pointer ;).


Alex

>  
> - header_in_rom = (struct cbfs_header *)(uintptr_t)
> - *(u32 *)(end_of_rom - 3);
> + header_in_rom = (struct cbfs_header *)(end_of_rom + offset + 1);
>   swap_header(header, header_in_rom);
>  
>   if (header->magic != good_magic || header->offset >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] cmd: cbfs: fix reading the end_of_rom pointer for 64bit archs

[Alexander Graf]

On 15.02.18 07:40, Andre Heider wrote:
> The cast breaks the pointer on 64bit archs, so lets get rid of it.
> 
> Signed-off-by: Andre Heider 

Reviewed-by: Alexander Graf 


Alex

> ---
>  cmd/cbfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index 799ba01fcc..736f8c4527 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -22,7 +22,7 @@ static int do_cbfs_init(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   return 0;
>   }
>   if (argc == 2) {
> - end_of_rom = (int)simple_strtoul(argv[1], , 16);
> + end_of_rom = simple_strtoul(argv[1], , 16);
>   if (*ep) {
>   puts("\n** Invalid end of ROM **\n");
>   return 1;
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support

[Marek Vasut]

On 02/21/2018 08:39 AM, chin.liang@intel.com wrote:
> From: Chin Liang See 
> 
> Enable Macronix flash support for Cyclone5 SoC

Do these boards actually have a macronix flash ? Most of the ones I know
of do not.

> Signed-off-by: Chin Liang See 
> ---
>  configs/socfpga_cyclone5_defconfig| 1 +
>  configs/socfpga_is1_defconfig | 1 +
>  configs/socfpga_sockit_defconfig  | 1 +
>  configs/socfpga_socrates_defconfig| 1 +
>  configs/socfpga_sr1500_defconfig  | 1 +
>  configs/socfpga_vining_fpga_defconfig | 1 +
>  6 files changed, 6 insertions(+)
> 
> diff --git a/configs/socfpga_cyclone5_defconfig 
> b/configs/socfpga_cyclone5_defconfig
> index 6ebd8a9..aa535c6 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig
> index 08628ab..7be720a 100644
> --- a/configs/socfpga_is1_defconfig
> +++ b/configs/socfpga_is1_defconfig
> @@ -48,6 +48,7 @@ CONFIG_SYS_I2C_DW=y
>  # CONFIG_MMC is not set
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
> diff --git a/configs/socfpga_sockit_defconfig 
> b/configs/socfpga_sockit_defconfig
> index 8ebe394..6edb47f 100644
> --- a/configs/socfpga_sockit_defconfig
> +++ b/configs/socfpga_sockit_defconfig
> @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> diff --git a/configs/socfpga_socrates_defconfig 
> b/configs/socfpga_socrates_defconfig
> index 9f42481..7c2428a 100644
> --- a/configs/socfpga_socrates_defconfig
> +++ b/configs/socfpga_socrates_defconfig
> @@ -54,6 +54,7 @@ CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_PHY_MICREL=y
> diff --git a/configs/socfpga_sr1500_defconfig 
> b/configs/socfpga_sr1500_defconfig
> index f9ed1a3..df1ee31 100644
> --- a/configs/socfpga_sr1500_defconfig
> +++ b/configs/socfpga_sr1500_defconfig
> @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
>  CONFIG_DM_ETH=y
> diff --git a/configs/socfpga_vining_fpga_defconfig 
> b/configs/socfpga_vining_fpga_defconfig
> index 6670b9f..512d701 100644
> --- a/configs/socfpga_vining_fpga_defconfig
> +++ b/configs/socfpga_vining_fpga_defconfig
> @@ -69,6 +69,7 @@ CONFIG_LED_STATUS_CMD=y
>  CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> 


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

Re: [U-Boot] [GIT] Pull request: u-boot-dfu (20.02.2018)

[Marek Vasut]

On 02/20/2018 08:17 AM, Lukasz Majewski wrote:
> 
> Dear Marek, Tom,
> 
> Travis CI:
> https://travis-ci.org/lmajewski/u-boot-dfu/builds/343576773
> 
> Tested-by: Lukasz Majewski 
> Test HW: Beagle Bone Black
> 
> I've found another fix for gadget (fastboot), which was "delegated" to
> me on patchwork, but I wasn't added to CC of this patch
> 
> The following changes since commit
> 61a1c379964ae701759cf8d89497391c76ffe889:
> 
>   usb: gadget: sdp: fix pointer cast warnings for 64bit archs
>   (2018-02-19 05:20:00 +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dfu.git 

Applied, thanks


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

Re: [U-Boot] [PATCH 1/1] usb: kbd: select SYS_STDIO_DEREGISTER

[Marek Vasut]

On 02/21/2018 04:57 AM, Heinrich Schuchardt wrote:
> If SYS_STDIO_DEREGISTER is not selected and USB_KEYBOARD is selected
> U-Boot cannot be built due to missing function stdio_deregister_dev.
> 
> So USB_KEYBOARD should select SYS_STDIO_DEREGISTER.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/usb/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 7de41057ca1..4fbe172e05c 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -71,6 +71,7 @@ config USB_STORAGE
>  
>  config USB_KEYBOARD
>   bool "USB Keyboard support"
> + select SYS_STDIO_DEREGISTER
>   ---help---
> Say Y here if you want to use a USB keyboard for U-Boot command line
> input.
> 
Applied, thanks

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

Re: [U-Boot] [PATCH 1/2] mtd: nand: tegra: convert to driver model and live tree

[Simon Glass]

On 21 February 2018 at 08:16, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> The Tegra NAND driver recently got broken by ongoing driver model resp.
> live tree migration work:
>
> NAND:  Could not decode nand-flash in device tree
> Tegra NAND init failed
> 0 MiB
>
> A patch for NAND uclass support was proposed about a year ago:
> https://patchwork.ozlabs.org/patch/722282/
>
> It was not merged and I do not see on-going work for this.
>
> This commit just provides a driver model probe hook to retrieve further
> configuration from the live device tree. As there is no NAND ulass as of
> yet (ab)using UCLASS_MISC. Once UCLASS_NAND is supported, it would be
> possible to migrate to it.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  drivers/mtd/nand/tegra_nand.c | 98 
> ---
>  1 file changed, 55 insertions(+), 43 deletions(-)

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

Re: [U-Boot] [PATCH] usb: dwc2: Reduce data buffer size to 16kB

[Marek Vasut]

On 02/21/2018 10:48 AM, Alexey Brodkin wrote:
> If we use hardware with very small RAM (let's consider just a couple
> of hundreds of kB but not megabytes) it is not super convenient to lose
> 64kB for statically allocated bufer which most probably won't be used
> as big as it is. Typically we'll have much shorter data packages to
> excahnge and in the worst case longer packets will be split on separate
> transactions.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Marek Vasut 

I think it does make sense to make this configurable with 64 kiB as
default and tweak your platform to 16 kiB in it's defconfig.

> ---
>  drivers/usb/host/dwc2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index 0efe645044c5..20cd4a6d3d55 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DWC2_HC_CHANNEL  0
>  
>  #define DWC2_STATUS_BUF_SIZE 64
> -#define DWC2_DATA_BUF_SIZE   (64 * 1024)
> +#define DWC2_DATA_BUF_SIZE   (16 * 1024)
>  
>  #define MAX_DEVICE   16
>  #define MAX_ENDPOINT 16
> 


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

[U-Boot] [PATCH] sf: Add ISSI IS25LP256 entry

[Marek Vasut]

Add entry for ISSI IS25LP256 part.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
---
 drivers/mtd/spi/spi_flash_ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 262d81e98d..b789219e4e 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -71,6 +71,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"is25lp032",  INFO(0x9d6016, 0x0, 64 * 1024,64, 0) },
{"is25lp064",  INFO(0x9d6017, 0x0, 64 * 1024,   128, 0) },
{"is25lp128",  INFO(0x9d6018, 0x0, 64 * 1024,   256, 0) },
+   {"is25lp256",  INFO(0x9d6019, 0x0, 64 * 1024,   512, 0) },
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX   /* MACRONIX */
{"mx25l2006e", INFO(0xc22012, 0x0, 64 * 1024, 4, 0) },
-- 
2.16.1

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

Re: [U-Boot] [ANN] U-Boot v2018.03-rc3 released

[Jean-Jacques Hiblot]

On 21/02/2018 11:10, Alex Kiernan wrote:

On Wed, Feb 21, 2018 at 9:20 AM, Alex Kiernan  wrote:

On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini  wrote:

Hey all,

So, we're a day late.  That's because I wanted the MMC PR to come in for
some important fixes, and it was too late in my day to then push a
release.  I think we probably have a few more fixes that need to come
in, but hopefully no more new regressions to be found.  That said, if
you have your environment, well, anywhere, a little bit of hardware
testing wouldn't hurt.  I think we're still on track for -rc4 on March
5th and the release on March 12th.  But if we aren't, the release will
get delayed.


Something's broken my board (AM335x, not quite a BBB):

MMC:   mmc@481d8000 - probe failed: -1

Looks to be this commit:

2d7482cf793fe4d8a98906002708d6e1fa2c5ba3

Still looking, but I'd guess I'm now missing something from my DTB
which I didn't need previously.


mmc_of_parse says:

 /* f_max is obtained from the optional "max-frequency" property */
 dev_read_u32(dev, "max-frequency", >f_max);

I don't have a max-frequency (pretty much all my config comes direct
from am33xx.dtsi), so if I add a max-frequency to my tree I get a
working board, but the comment above suggests I shouldn't need to, so
do we need something like this added (or a refactor of mmc_of_parse so
it takes a default?)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 02970f2..b87ff01 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1825,6 +1825,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct
udevice *dev)
 if (ret < 0)
 return ret;

+   if (cfg->f_max == 0)
+   cfg->f_max = 5200;

Thanks for catching this.
I'll send a series soon related to am335x_evm and mmc. I'll include your 
fix.



 cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
 cfg->f_min = 40;
 cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;

I'm also seeing MMC_MODE_1BIT (which I didn't previously have set)
alongside MMC_MODE_4BIT and MMC_MODE_8BIT (which I previously did),
but I'm guessing that doesn't matter?

1Bit is always supported. So it doesn't matter.
JJ




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

[U-Boot] [PATCH 3/3] arm: zynq: Enable cadence driver on zc706

[Michal Simek]

Enable watchdog with reset-on-timeout feature.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-zc706.dts  | 4 
 configs/zynq_zc706_defconfig | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index d342306293b4..a88a83c16650 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -333,3 +333,7 @@
pinctrl-names = "default";
pinctrl-0 = <_usb0_default>;
 };
+
+ {
+   reset-on-timeout;
+};
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index 7b2e072581f6..add40308f6bd 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -70,3 +70,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x0300
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_FUNCTION_THOR=y
+CONFIG_WDT=y
+CONFIG_WDT_CDNS=y
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] arm: zynq: Wire watchdog internals

[Michal Simek]

Watchdog is only enabled in full u-boot. Adoption for SPL should be also
done because that's the right place where watchdog should be enabled.

Signed-off-by: Michal Simek 
---

 arch/arm/Kconfig  |  1 +
 board/xilinx/zynq/board.c | 49 +++
 2 files changed, 50 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 77cb20090c4f..bd3254d743e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -761,6 +761,7 @@ config ARCH_ZYNQ
select SUPPORT_SPL
select OF_CONTROL
select SPL_BOARD_INIT if SPL
+   select BOARD_EARLY_INIT_F if WDT
select SPL_OF_CONTROL if SPL
select DM
select DM_ETH if NET
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index fb8eab07d768..4feda7757cb8 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -6,9 +6,11 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +35,22 @@ static xilinx_desc fpga045 = XILINX_XC7Z045_DESC(0x45);
 static xilinx_desc fpga100 = XILINX_XC7Z100_DESC(0x100);
 #endif
 
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
+static struct udevice *watchdog_dev;
+#endif
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_BOARD_EARLY_INIT_F)
+int board_early_init_f(void)
+{
+# if defined(CONFIG_WDT)
+   /* bss is not cleared at time when watchdog_reset() is called */
+   watchdog_dev = NULL;
+# endif
+
+   return 0;
+}
+#endif
+
 int board_init(void)
 {
 #if (defined(CONFIG_FPGA) && !defined(CONFIG_SPL_BUILD)) || \
@@ -75,6 +93,15 @@ int board_init(void)
}
 #endif
 
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
+   if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
+   puts("Watchdog: Not found!\n");
+   } else {
+   wdt_start(watchdog_dev, 0, 0);
+   puts("Watchdog: Started\n");
+   }
+# endif
+
 #if (defined(CONFIG_FPGA) && !defined(CONFIG_SPL_BUILD)) || \
 (defined(CONFIG_SPL_FPGA_SUPPORT) && defined(CONFIG_SPL_BUILD))
fpga_init();
@@ -164,3 +191,25 @@ int dram_init(void)
return 0;
 }
 #endif
+
+#if defined(CONFIG_WDT)
+/* Called by macro WATCHDOG_RESET */
+void watchdog_reset(void)
+{
+# if !defined(CONFIG_SPL_BUILD)
+   static ulong next_reset;
+   ulong now;
+
+   if (!watchdog_dev)
+   return;
+
+   now = timer_get_us();
+
+   /* Do not reset the watchdog too often */
+   if (now > next_reset) {
+   wdt_reset(watchdog_dev);
+   next_reset = now + 1000;
+   }
+# endif
+}
+#endif
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] watchdog: Add Cadence watchdog driver

[Michal Simek]

From: Shreenidhi Shedi 

This IP can be found on Zynq and ZynqMP devices.
The driver was tested with reset-on-timeout; feature.

Also adding WATCHDOG symbol to Kconfig because it is required.

Signed-off-by: Shreenidhi Shedi 
Signed-off-by: Michal Simek 
---

 drivers/watchdog/Kconfig|  11 ++
 drivers/watchdog/Makefile   |   1 +
 drivers/watchdog/cdns_wdt.c | 276 
 3 files changed, 288 insertions(+)
 create mode 100644 drivers/watchdog/cdns_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fc46b6774d57..f5df53b115f1 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1,5 +1,8 @@
 menu "Watchdog Timer Support"
 
+config WATCHDOG
+   bool
+
 config HW_WATCHDOG
bool
 
@@ -78,4 +81,12 @@ config WDT_ORION
   Select this to enable Orion watchdog timer, which can be found on 
some
   Marvell Armada chips.
 
+config WDT_CDNS
+   bool "Cadence watchdog timer support"
+   depends on WDT
+   select WATCHDOG
+   help
+  Select this to enable Cadence watchdog timer, which can be found on 
some
+  Xilinx Microzed Platform.
+
 endmenu
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index ab6a6b79e1d7..4b97df3ab67b 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
 obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
 obj-$(CONFIG_BCM2835_WDT)   += bcm2835_wdt.o
 obj-$(CONFIG_WDT_ORION) += orion_wdt.o
+obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
diff --git a/drivers/watchdog/cdns_wdt.c b/drivers/watchdog/cdns_wdt.c
new file mode 100644
index ..12def7d27393
--- /dev/null
+++ b/drivers/watchdog/cdns_wdt.c
@@ -0,0 +1,276 @@
+/*
+ * Cadence WDT driver - Used by Xilinx Zynq
+ * Reference: Linux kernel Cadence watchdog driver.
+ *
+ * Author(s):  Shreenidhi Shedi 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct cdns_regs {
+   u32 zmr;/* WD Zero mode register, offset - 0x0 */
+   u32 ccr;/* Counter Control Register offset - 0x4 */
+   u32 restart;/* Restart key register, offset - 0x8 */
+   u32 status; /* Status Register, offset - 0xC */
+};
+
+struct cdns_wdt_priv {
+   bool rst;
+   u32 timeout;
+   void __iomem *reg;
+   struct cdns_regs *regs;
+};
+
+#define CDNS_WDT_DEFAULT_TIMEOUT   10
+
+/* Supports 1 - 516 sec */
+#define CDNS_WDT_MIN_TIMEOUT   1
+#define CDNS_WDT_MAX_TIMEOUT   516
+
+/* Restart key */
+#define CDNS_WDT_RESTART_KEY   0x1999
+
+/* Counter register access key */
+#define CDNS_WDT_REGISTER_ACCESS_KEY   0x0092
+
+/* Counter value divisor */
+#define CDNS_WDT_COUNTER_VALUE_DIVISOR 0x1000
+
+/* Clock prescaler value and selection */
+#define CDNS_WDT_PRESCALE_64   64
+#define CDNS_WDT_PRESCALE_512  512
+#define CDNS_WDT_PRESCALE_4096 4096
+#define CDNS_WDT_PRESCALE_SELECT_641
+#define CDNS_WDT_PRESCALE_SELECT_512   2
+#define CDNS_WDT_PRESCALE_SELECT_4096  3
+
+/* Input clock frequency */
+#define CDNS_WDT_CLK_75MHZ 7500
+
+/* Counter maximum value */
+#define CDNS_WDT_COUNTER_MAX   0xFFF
+
+/*Register Map**/
+
+/*
+ * Zero Mode Register - This register controls how the time out is indicated
+ * and also contains the access code to allow writes to the register (0xABC).
+ */
+#define CDNS_WDT_ZMR_WDEN_MASK 0x0001 /* Enable the WDT */
+#define CDNS_WDT_ZMR_RSTEN_MASK0x0002 /* Enable the reset output */
+#define CDNS_WDT_ZMR_IRQEN_MASK0x0004 /* Enable IRQ output */
+#define CDNS_WDT_ZMR_RSTLEN_16 0x0030 /* Reset pulse of 16 pclk cycles */
+#define CDNS_WDT_ZMR_ZKEY_VAL  0x00ABC000 /* Access key, 0xABC << 12 */
+
+/*
+ * Counter Control register - This register controls how fast the timer runs
+ * and the reset value and also contains the access code to allow writes to
+ * the register.
+ */
+#define CDNS_WDT_CCR_CRV_MASK  0x3FFC /* Counter reset value */
+
+/* Write access to Registers */
+static inline void cdns_wdt_writereg(u32 *addr, u32 val)
+{
+   writel(val, addr);
+}
+
+/**
+ * cdns_wdt_reset - Reload the watchdog timer (i.e. pat the watchdog).
+ *
+ * @dev: Watchdog device
+ *
+ * Write the restart key value (0x1999) to the restart register.
+ *
+ * Return: Always 0
+ */
+static int32_t cdns_wdt_reset(struct udevice *dev)
+{
+   struct cdns_wdt_priv *priv = dev_get_priv(dev);
+
+   debug("%s\n", __func__);
+
+   cdns_wdt_writereg(>regs->restart, CDNS_WDT_RESTART_KEY);
+
+   return 0;
+}
+
+/**
+ * cdns_wdt_start - Enable and start the watchdog.
+ *
+ * @dev: Watchdog device
+ * @timeout: Timeout value
+ * @flags: Driver flags
+ *
+ * The 

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Stefano Babic]

Hi Zoran,

On 21/02/2018 11:45, Zoran S wrote:
> Hello to U-Boot list,
> 
> I have encountered an interesting problem which I do not entirely
> understand. I am trying to boot MLO and u-boot.bin from the SD Card,
> and rest from the initramfs.
> 
> I tried several initramfs images, and so far I am always failing on
> the same place:
> [2.135533] No filesystem could mount root, tried:
> [2.135541]  ext2
> [2.140682]
> [2.144262] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(1,0)
> [2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to
> mount root fs on unknown-block(1,0)
> 
> I have tried mostly .gz images (cpio.gz and ext2.gz). Does not help.
> Even does not with ext2.gz after YOCTO is done. In order to do it
> correctly, I MUST to add U-Boot header, and I do this with the
> following command:
> 
> mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
> initramfs.ext2.gz initramfs.uImage
> 
> And the image I actually supply is: initramfs.uImage
> 
> Then, the following happens:
> 
> => run netloadfdt
> link up on port 0, speed 100, full duplex
> Using cpsw device
> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
> Filename 'am335x-boneblack.dtb'.
> Load address: 0x8800
> Loading: ###
>  697.3 KiB/s
> done
> Bytes transferred = 35016 (88c8 hex)
> => run netloadimage
> link up on port 0, speed 100, full duplex
> Using cpsw device
> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
> Filename 'zImage'.
> Load address: 0x8200
> Loading: #
>  #
>  #
>  #
>  
>  772.5 KiB/s
> done
> Bytes transferred = 4161160 (3f7e88 hex)
> => tftp 0x8808 initramfs.uImage
> link up on port 0, speed 100, full duplex
> Using cpsw device
> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
> Filename 'initramfs.uImage'.
> Load address: 0x8808
> Loading: #
>  #
> 
>  [snap]
> 
>  ###
>  767.6 KiB/s
> done
> Bytes transferred = 46599246 (2c70c4e hex)
> => dhcp
> link up on port 0, speed 100, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.15.159 (21 ms)
> => run ramboot
> Booting from ramdisk ...
> ## Loading init Ramdisk from Legacy Image at 8808 ...
>Image Name:   Ramdisk Image
>Created:  2018-02-21   9:46:15 UTC
>Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>Data Size:46599182 Bytes = 44.4 MiB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8d38f000, end 8c0e ... OK
>Loading Device Tree to 8d383000, end 8d38e8c7 ... OK
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.13.8-jumpnow (oe-user@oe-host) (gcc
> version 7.2.0 (GCC)) #1 Tue Jan 9 15:37:12 CET 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0x9f00
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon)
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 130048
> 
> Please, note the Kernal Command line in the log!
> [0.00] Kernel command line: console=ttyO0,115200n8
> root=/dev/ram0 rw rootfstype=ext2 << Kernel
> Command Line
> 
> [SNAP]
> 
> [1.770469] omap_voltage_late_init: Voltage driver support not added
> [1.777510] ThumbEE CPU extension supported.
> [1.791397] mmcblk0: mmc0:59b4 USD   1.87 GiB
> [1.801349]  mmcblk0: p1 p2
> [1.868955] mmc1: new high speed MMC card at address 0001
> [1.876511] mmcblk1: mmc1:0001 MMC04G 3.60 GiB
> [1.882230] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB
> [1.890172] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB
> [1.896948] mmcblk1rpmb: mmc1:0001 MMC04G partition 3 128 KiB
> [1.906237]  mmcblk1: p1 p2
> [1.925804] tps65217 0-0024: TPS65217 ID 0xe version 1.2
> [1.932470] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
> [1.948789] omap_rtc 44e3e000.rtc: setting system clock to
> 2017-12-04 18:09:58 UTC (1512410998)
> [1.963613] List of all partitions:
> [1.967311] 0100   

[U-Boot] Can't boot with initramfs but It's ok without

[Clément Péron]

Hi,

I'm working on a dev board the SoC is Broadcom Cygnus with 256MiB of RAM
Booting a Kernel and device tree works fine.
But booting a Kernel with initramfs and a device tree make a strange behavior.

Don't want to say stupid things but It seems that the Kernel didn't
find the device tree and try to fall back using the ATAGS, but since I
don't use them the machine ID is not set up.

Do you have any idea of what I did wrong in my setup ?

Thanks,
Clement



U-Boot 2018.03-rc2-00036-g427c1c7280-dirty (Feb 21 2018 - 16:40:00 +0100)

U-Boot code: 6100 -> 6103F578  BSS: -> 6104CACC
DRAM:  Monitor len: 0004CACC
Ram size: 0FA0
Ram top: 6FA0
TLB table from 6f9f to 6f9f4000
Reserving 306k for U-Boot at: 6f9a3000
Reserving 4101k for malloc() at: 6f5a1c00
Reserving 80 Bytes for Board Info at: 6f5a1bb0
Reserving 184 Bytes for Global Data at: 6f5a1af8

RAM Configuration:
Bank #0: 6000 250 MiB

DRAM:  250 MiB
New Stack Pointer is: 6f5a1ad0
Relocation Offset is: 0e9a3000
Relocating to 6f9a3000, new gd at 6f5a1af8, sp at 6f5a1ad0
Now running in RAM - U-Boot at: 6f9a3000
MMC:   iproc-sdhci: 0
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   Registering BCM sf2 eth
Broadcom Starfighter2 Ethernet driver 0.1
Using GMAC0
gmac_mac_init: Chip ID: 0xd300
srab_interface_reset: timeout sw_init_done
devid read succesfully via srab: 0xd300
devid32: 0xd300
Basic ethernet functionality initialized
bcm_sf2_gmac-0

Hit any key to stop autoboot:  0
Booting debug
bcm_sf2_gmac-0 Waiting for PHY auto negotiation to complete done
Change GMAC speed to 1000MB
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
DHCP client bound to address 192.168.0.113 (4043 ms)
Change GMAC speed to 1000MB
192.168.0.3
Change GMAC speed to 1000MB
Using bcm_sf2_gmac-0 device
TFTP from server 192.168.0.3; our IP address is 192.168.0.113
Filename 'boot/zImage'.
Load address: 0x6300
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 ##
 6.5 MiB/s
done
Bytes transferred = 73245400 (45da2d8 hex)
Change GMAC speed to 1000MB
Using bcm_sf2_gmac-0 device
TFTP from server 192.168.0.3; our IP address is 192.168.0.113
Filename 'boot/myboard.dtb'.
Load address: 0x6200
Loading: #
 6.2 MiB/s
done
Bytes transferred = 25911 (6537 hex)
Kernel image @ 0x6300 [ 0x00 - 0x45da2d8 ]
## Flattened Device Tree blob at 6200
   Booting using the fdt blob at 0x6200
   Using Device Tree in place at 6200, end 62009536

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x).

Available machine support:

ID (hex)NAME
Generic DT based system
Broadcom Cygnus SoC
Freescale i.MX6 Quad/DualLite (Device Tree)
Altera SOCFPGA

Please check your kernel config and/or bootloader.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC v3 15/15] bmips: enable nb4-ser enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/sfr,nb4-ser.dts | 24 
 configs/sfr_nb4-ser_ram_defconfig |  8 +++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sfr,nb4-ser.dts b/arch/mips/dts/sfr,nb4-ser.dts
index 473372faa1..73db45f9ea 100644
--- a/arch/mips/dts/sfr,nb4-ser.dts
+++ b/arch/mips/dts/sfr,nb4-ser.dts
@@ -54,6 +54,30 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "internal";
+
+   enet0phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/sfr_nb4-ser_ram_defconfig 
b/configs/sfr_nb4-ser_ram_defconfig
index fc323d879d..07b49a1a77 100644
--- a/configs/sfr_nb4-ser_ram_defconfig
+++ b/configs/sfr_nb4-ser_ram_defconfig
@@ -27,11 +27,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -40,6 +43,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC v3 09/15] bmips: bcm6338: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6338.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 4125f71d9f..621278c9d1 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -145,5 +145,20 @@
dma-channels = <6>;
resets = <_rst BCM6338_RST_DMAMEM>;
};
+
+   enet: ethernet@fffe2800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe2800 0x2dc>;
+   clocks = <_clk BCM6338_CLK_ENET>;
+   resets = <_rst BCM6338_RST_ENET>;
+   dmas = < BCM6338_DMA_ENET_RX>,
+  < BCM6338_DMA_ENET_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
};
 };
-- 
2.11.0

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

[U-Boot] [RFC v3 08/15] net: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: select DMA_CHANNELS.

 drivers/net/Kconfig|  10 +
 drivers/net/Makefile   |   1 +
 drivers/net/bcm6348-eth.c  | 517 +
 include/configs/bmips_common.h |   5 +-
 4 files changed, 532 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/bcm6348-eth.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index de1947ccc1..e532332d78 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -71,6 +71,16 @@ config BCM_SF2_ETH_GMAC
  by the BCM_SF2_ETH driver.
  Say Y to any bcmcygnus based platforms.
 
+config BCM6348_ETH
+   bool "BCM6348 EMAC support"
+   depends on DM_ETH && ARCH_BMIPS
+   select DMA
+   select DMA_CHANNELS
+   select MII
+   select PHYLIB
+   help
+ This driver supports the BCM6348 Ethernet MAC.
+
 config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ac5443c752..282adbc775 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
 obj-$(CONFIG_AG7XXX) += ag7xxx.o
 obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
+obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
 obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
 obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
diff --git a/drivers/net/bcm6348-eth.c b/drivers/net/bcm6348-eth.c
new file mode 100644
index 00..890b7d5396
--- /dev/null
+++ b/drivers/net/bcm6348-eth.c
@@ -0,0 +1,517 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ETH_ZLEN   60
+
+#define ETH_TX_WATERMARK   32
+#define ETH_MAX_MTU_SIZE   1518
+
+#define ETH_TIMEOUT100
+
+/* ETH Receiver Configuration register */
+#define ETH_RXCFG_REG  0x00
+#define ETH_RXCFG_ENFLOW_SHIFT 5
+#define ETH_RXCFG_ENFLOW_MASK  (1 << ETH_RXCFG_ENFLOW_SHIFT)
+
+/* ETH Receive Maximum Length register */
+#define ETH_RXMAXLEN_REG   0x04
+#define ETH_RXMAXLEN_SHIFT 0
+#define ETH_RXMAXLEN_MASK  (0x7ff << ETH_RXMAXLEN_SHIFT)
+
+/* ETH Transmit Maximum Length register */
+#define ETH_TXMAXLEN_REG   0x08
+#define ETH_TXMAXLEN_SHIFT 0
+#define ETH_TXMAXLEN_MASK  (0x7ff << ETH_TXMAXLEN_SHIFT)
+
+/* MII Status/Control register */
+#define MII_SC_REG 0x10
+#define MII_SC_MDCFREQDIV_SHIFT0
+#define MII_SC_MDCFREQDIV_MASK (0x7f << MII_SC_MDCFREQDIV_SHIFT)
+#define MII_SC_PREAMBLE_EN_SHIFT   7
+#define MII_SC_PREAMBLE_EN_MASK(1 << MII_SC_PREAMBLE_EN_SHIFT)
+
+/* MII Data register */
+#define MII_DAT_REG0x14
+#define MII_DAT_DATA_SHIFT 0
+#define MII_DAT_DATA_MASK  (0x << MII_DAT_DATA_SHIFT)
+#define MII_DAT_TA_SHIFT   16
+#define MII_DAT_TA_MASK(0x3 << MII_DAT_TA_SHIFT)
+#define MII_DAT_REG_SHIFT  18
+#define MII_DAT_REG_MASK   (0x1f << MII_DAT_REG_SHIFT)
+#define MII_DAT_PHY_SHIFT  23
+#define MII_DAT_PHY_MASK   (0x1f << MII_DAT_PHY_SHIFT)
+#define MII_DAT_OP_SHIFT   28
+#define MII_DAT_OP_WRITE   (0x5 << MII_DAT_OP_SHIFT)
+#define MII_DAT_OP_READ(0x6 << MII_DAT_OP_SHIFT)
+
+/* ETH Interrupts Mask register */
+#define ETH_IRMASK_REG 0x18
+
+/* ETH Interrupts register */
+#define ETH_IR_REG 0x1c
+#define ETH_IR_MII_SHIFT   0
+#define ETH_IR_MII_MASK(1 << ETH_IR_MII_SHIFT)
+
+/* ETH Control register */
+#define ETH_CTL_REG0x2c
+#define ETH_CTL_ENABLE_SHIFT   0
+#define ETH_CTL_ENABLE_MASK(1 << ETH_CTL_ENABLE_SHIFT)
+#define ETH_CTL_DISABLE_SHIFT  1
+#define ETH_CTL_DISABLE_MASK   (1 << ETH_CTL_DISABLE_SHIFT)
+#define ETH_CTL_RESET_SHIFT2
+#define ETH_CTL_RESET_MASK (1 << ETH_CTL_RESET_SHIFT)
+#define ETH_CTL_EPHY_SHIFT 3
+#define ETH_CTL_EPHY_MASK  (1 << ETH_CTL_EPHY_SHIFT)
+
+/* ETH Transmit Control register */
+#define ETH_TXCTL_REG  0x30
+#define ETH_TXCTL_FD_SHIFT 0
+#define ETH_TXCTL_FD_MASK  (1 << ETH_TXCTL_FD_SHIFT)
+
+/* ETH Transmit Watermask register */
+#define ETH_TXWMARK_REG0x34
+#define ETH_TXWMARK_WM_SHIFT   0
+#define 

[U-Boot] [RFC v3 10/15] bmips: enable f@st1704 enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/sagem,f...@st1704.dts | 12 
 configs/sagem_f@st1704_ram_defconfig |  9 -
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sagem,f...@st1704.dts 
b/arch/mips/dts/sagem,f...@st1704.dts
index dd0e5b8b7c..99d031f10a 100644
--- a/arch/mips/dts/sagem,f...@st1704.dts
+++ b/arch/mips/dts/sagem,f...@st1704.dts
@@ -40,6 +40,18 @@
};
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enetphy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/sagem_f@st1704_ram_defconfig 
b/configs/sagem_f@st1704_ram_defconfig
index 0adcd46d51..1a640781b7 100644
--- a/configs/sagem_f@st1704_ram_defconfig
+++ b/configs/sagem_f@st1704_ram_defconfig
@@ -28,11 +28,15 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
-# CONFIG_CMD_NET is not set
+CONFIG_CMD_DHCP=y
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -41,6 +45,9 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_BCM6345=y
 # CONFIG_SPL_SERIAL_PRESENT is not set
-- 
2.11.0

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

[U-Boot] [RFC v3 11/15] bmips: bcm6348: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6348.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index d774c59665..e540865019 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -162,6 +162,32 @@
u-boot,dm-pre-reloc;
};
 
+   enet0: ethernet@fffe6000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6000 0x2dc>;
+   dmas = < BCM6348_DMA_ENET0_RX>,
+  < BCM6348_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe6800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6800 0x2dc>;
+   dmas = < BCM6348_DMA_ENET1_RX>,
+  < BCM6348_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe7000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe7000 0x1c>,
-- 
2.11.0

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

[U-Boot] [RFC v3 07/15] phy: add support for internal phys

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 include/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/phy.h b/include/phy.h
index 0543ec10c2..8f3e53db01 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -50,6 +50,7 @@
 
 
 typedef enum {
+   PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
@@ -72,6 +73,7 @@ typedef enum {
 } phy_interface_t;
 
 static const char *phy_interface_strings[] = {
+   [PHY_INTERFACE_MODE_INTERNAL]   = "internal",
[PHY_INTERFACE_MODE_MII]= "mii",
[PHY_INTERFACE_MODE_GMII]   = "gmii",
[PHY_INTERFACE_MODE_SGMII]  = "sgmii",
-- 
2.11.0

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

[U-Boot] [RFC v3 12/15] bmips: enable ct-5361 enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/comtrend,ct-5361.dts| 12 
 configs/comtrend_ct5361_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/comtrend,ct-5361.dts 
b/arch/mips/dts/comtrend,ct-5361.dts
index 74dc09046c..a78aa877fc 100644
--- a/arch/mips/dts/comtrend,ct-5361.dts
+++ b/arch/mips/dts/comtrend,ct-5361.dts
@@ -35,6 +35,18 @@
};
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/comtrend_ct5361_ram_defconfig 
b/configs/comtrend_ct5361_ram_defconfig
index 8b842606f5..0737772dd2 100644
--- a/configs/comtrend_ct5361_ram_defconfig
+++ b/configs/comtrend_ct5361_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6348_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC v3 06/15] bmips: bcm6358: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6358.dtsi   | 18 ++
 include/dt-bindings/dma/bcm6358-dma.h | 17 +
 2 files changed, 35 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index b63b53baee..1468e4f63a 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -191,5 +192,22 @@
 
status = "disabled";
};
+
+   iudma: dma-controller@fffe5000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe5000 0x24>,
+ <0xfffe5100 0x80>,
+ <0xfffe5200 0x80>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   clocks = <_clk BCM6358_CLK_EMUSB>,
+<_clk BCM6358_CLK_USBSU>,
+<_clk BCM6358_CLK_EPHY>;
+   resets = <_rst BCM6358_RST_ENET>,
+<_rst BCM6358_RST_EPHY>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6358-dma.h 
b/include/dt-bindings/dma/bcm6358-dma.h
new file mode 100644
index 00..3b1fcf8540
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6358-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6358_H
+#define __DT_BINDINGS_DMA_BCM6358_H
+
+#define BCM6358_DMA_ENET0_RX   0
+#define BCM6358_DMA_ENET0_TX   1
+#define BCM6358_DMA_ENET1_RX   2
+#define BCM6358_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6358_H */
-- 
2.11.0

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

[U-Boot] [RFC v3 13/15] bmips: bcm6358: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6358.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index 1468e4f63a..04329864c2 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -193,6 +193,34 @@
status = "disabled";
};
 
+   enet0: ethernet@fffe4000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4000 0x2dc>;
+   clocks = <_clk BCM6358_CLK_ENET0>;
+   dmas = < BCM6358_DMA_ENET0_RX>,
+  < BCM6358_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe4800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4800 0x2dc>;
+   clocks = <_clk BCM6358_CLK_ENET1>;
+   dmas = < BCM6358_DMA_ENET1_RX>,
+  < BCM6358_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe5000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe5000 0x24>,
-- 
2.11.0

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

[U-Boot] [RFC v3 14/15] bmips: enable hg556a enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/huawei,hg556a.dts | 12 
 configs/huawei_hg556a_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/huawei,hg556a.dts b/arch/mips/dts/huawei,hg556a.dts
index a1e9c15ab9..2f99e0905c 100644
--- a/arch/mips/dts/huawei,hg556a.dts
+++ b/arch/mips/dts/huawei,hg556a.dts
@@ -94,6 +94,18 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   phy = <>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/configs/huawei_hg556a_ram_defconfig 
b/configs/huawei_hg556a_ram_defconfig
index 7f7f34ed61..c7c7c6554f 100644
--- a/configs/huawei_hg556a_ram_defconfig
+++ b/configs/huawei_hg556a_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC v3 04/15] bmips: bcm6338: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6338.dtsi   | 14 ++
 include/dt-bindings/dma/bcm6338-dma.h | 15 +++
 2 files changed, 29 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 0cab44cb8d..4125f71d9f 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -131,5 +132,18 @@
reg = <0xfffe3100 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe2400 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe2400 0x1c>,
+ <0xfffe2500 0x60>,
+ <0xfffe2600 0x60>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <6>;
+   resets = <_rst BCM6338_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6338-dma.h 
b/include/dt-bindings/dma/bcm6338-dma.h
new file mode 100644
index 00..5dd66239b4
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6338-dma.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6338_H
+#define __DT_BINDINGS_DMA_BCM6338_H
+
+#define BCM6338_DMA_ENET_RX0
+#define BCM6338_DMA_ENET_TX1
+
+#endif /* __DT_BINDINGS_DMA_BCM6338_H */
-- 
2.11.0

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

[U-Boot] [RFC v3 02/15] dma: add channels support

[Álvaro Fernández Rojas]

This adds channels support for dma controllers that have multiple channels
which can transfer data to/from different devices (enet, usb...).

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: Introduce changes reported by Simon Glass:
  - Improve dma-uclass.h documentation.
  - Switch to live tree API.

 drivers/dma/Kconfig  |   7 ++
 drivers/dma/dma-uclass.c | 188 +--
 include/dma-uclass.h |  78 
 include/dma.h| 174 ++-
 4 files changed, 439 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b92c7789d..21b2c0dcaa 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -12,6 +12,13 @@ config DMA
  buses that is used to transfer data to and from memory.
  The uclass interface is defined in include/dma.h.
 
+config DMA_CHANNELS
+   bool "Enable DMA channels support"
+   depends on DMA
+   help
+ Enable channels support for DMA. Some DMA controllers have multiple
+ channels which can either transfer data to/from different devices.
+
 config TI_EDMA3
bool "TI EDMA3 driver"
help
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 6fd4e1b35d..f4ba883b12 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -1,24 +1,200 @@
 /*
  * Direct Memory Access U-Class driver
  *
- * (C) Copyright 2015
- * Texas Instruments Incorporated, 
- *
- * Author: Mugunthan V N 
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ * Copyright (C) 2015 Texas Instruments Incorporated 
+ * Written by Mugunthan V N 
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
 
 #include 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_DMA_CHANNELS
+static inline struct dma_ops *dma_dev_ops(struct udevice *dev)
+{
+   return (struct dma_ops *)dev->driver->ops;
+}
+
+# if CONFIG_IS_ENABLED(OF_CONTROL)
+#  if CONFIG_IS_ENABLED(OF_PLATDATA)
+int dma_get_by_index_platdata(struct udevice *dev, int index,
+ struct phandle_1_arg *cells, struct dma *dma)
+{
+   int ret;
+
+   if (index != 0)
+   return -ENOSYS;
+   ret = uclass_get_device(UCLASS_DMA, 0, >dev);
+   if (ret)
+   return ret;
+   dma->id = cells[0].id;
+
+   return 0;
+}
+#  else
+static int dma_of_xlate_default(struct dma *dma,
+   struct ofnode_phandle_args *args)
+{
+   debug("%s(dma=%p)\n", __func__, dma);
+
+   if (args->args_count > 1) {
+   pr_err("Invaild args_count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   if (args->args_count)
+   dma->id = args->args[0];
+   else
+   dma->id = 0;
+
+   return 0;
+}
+
+int dma_get_by_index(struct udevice *dev, int index, struct dma *dma)
+{
+   int ret;
+   struct ofnode_phandle_args args;
+   struct udevice *dev_dma;
+   const struct dma_ops *ops;
+
+   debug("%s(dev=%p, index=%d, dma=%p)\n", __func__, dev, index, dma);
+
+   assert(dma);
+   dma->dev = NULL;
+
+   ret = dev_read_phandle_with_args(dev, "dmas", "#dma-cells", 0, index,
+);
+   if (ret) {
+   pr_err("%s: dev_read_phandle_with_args failed: err=%d\n",
+  __func__, ret);
+   return ret;
+   }
+
+   ret = uclass_get_device_by_ofnode(UCLASS_DMA, args.node, _dma);
+   if (ret) {
+   pr_err("%s: uclass_get_device_by_ofnode failed: err=%d\n",
+  __func__, ret);
+   return ret;
+   }
+
+   dma->dev = dev_dma;
+
+   ops = dma_dev_ops(dev_dma);
+
+   if (ops->of_xlate)
+   ret = ops->of_xlate(dma, );
+   else
+   ret = dma_of_xlate_default(dma, );
+   if (ret) {
+   pr_err("of_xlate() failed: %d\n", ret);
+   return ret;
+   }
+
+   return dma_request(dev_dma, dma);
+}
+#  endif /* OF_PLATDATA */
+
+int dma_get_by_name(struct udevice *dev, const char *name, struct dma *dma)
+{
+   int index;
+
+   debug("%s(dev=%p, name=%s, dma=%p)\n", __func__, dev, name, dma);
+   dma->dev = NULL;
+
+   index = dev_read_stringlist_search(dev, "dma-names", name);
+   if (index < 0) {
+   pr_err("dev_read_stringlist_search() failed: %d\n", index);
+   return index;
+   }
+
+   return dma_get_by_index(dev, index, dma);
+}
+# endif /* OF_CONTROL */
+
+int dma_request(struct udevice *dev, struct dma *dma)
+{
+   struct dma_ops *ops = dma_dev_ops(dev);
+
+   debug("%s(dev=%p, dma=%p)\n", __func__, dev, dma);
+
+   dma->dev = dev;
+
+   if (!ops->request)
+   return 0;

[U-Boot] [RFC v3 05/15] bmips: bcm6348: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: no changes

 arch/mips/dts/brcm,bcm6348.dtsi   | 16 
 include/dt-bindings/dma/bcm6348-dma.h | 17 +
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index 92fb91afc1..d774c59665 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -160,5 +161,20 @@
reg = <0xfffe2300 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe7000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe7000 0x1c>,
+ <0xfffe7100 0x40>,
+ <0xfffe7200 0x40>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <4>;
+   clocks = <_clk BCM6348_CLK_ENET>;
+   resets = <_rst BCM6348_RST_ENET>,
+<_rst BCM6348_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6348-dma.h 
b/include/dt-bindings/dma/bcm6348-dma.h
new file mode 100644
index 00..a1d3a6456d
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6348-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6348_H
+#define __DT_BINDINGS_DMA_BCM6348_H
+
+#define BCM6348_DMA_ENET0_RX   0
+#define BCM6348_DMA_ENET0_TX   1
+#define BCM6348_DMA_ENET1_RX   2
+#define BCM6348_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6348_H */
-- 
2.11.0

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

[U-Boot] [RFC v3 03/15] dma: add bcm6348-iudma support

[Álvaro Fernández Rojas]

BCM6348 IUDMA controller is present on multiple BMIPS (BCM63xx) SoCs.

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: no changes
 v2: Fix dma rx burst config and select DMA_CHANNELS.

 drivers/dma/Kconfig |   9 +
 drivers/dma/Makefile|   1 +
 drivers/dma/bcm6348-iudma.c | 505 
 3 files changed, 515 insertions(+)
 create mode 100644 drivers/dma/bcm6348-iudma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 21b2c0dcaa..9afa158b51 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -19,6 +19,15 @@ config DMA_CHANNELS
  Enable channels support for DMA. Some DMA controllers have multiple
  channels which can either transfer data to/from different devices.
 
+config BCM6348_IUDMA
+   bool "BCM6348 IUDMA driver"
+   depends on ARCH_BMIPS
+   select DMA_CHANNELS
+   help
+ Enable the BCM6348 IUDMA driver.
+ This driver support data transfer from devices to
+ memory and from memory to devices.
+
 config TI_EDMA3
bool "TI EDMA3 driver"
help
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 39b78b2a3d..b2b4147349 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DMA) += dma-uclass.o
 
 obj-$(CONFIG_FSLDMAFEC) += MCD_tasksInit.o MCD_dmaApi.o MCD_tasks.o
 obj-$(CONFIG_APBH_DMA) += apbh_dma.o
+obj-$(CONFIG_BCM6348_IUDMA) += bcm6348-iudma.o
 obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
diff --git a/drivers/dma/bcm6348-iudma.c b/drivers/dma/bcm6348-iudma.c
new file mode 100644
index 00..8016a58be2
--- /dev/null
+++ b/drivers/dma/bcm6348-iudma.c
@@ -0,0 +1,505 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/dma/bcm63xx-iudma.c:
+ * Copyright (C) 2015 Simon Arlott 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
+ * Copyright (C) 2000-2010 Broadcom Corporation
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/bcmdrivers/opensource/net/enet/impl4/bcmenet.c:
+ * Copyright (C) 2010 Broadcom Corporation
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ALIGN_END_ADDR(type, ptr, size)\
+   ((unsigned long)(ptr) + roundup((size) * sizeof(type), \
+ARCH_DMA_MINALIGN))
+
+/* DMA Channels */
+#define DMA_CHAN_FLOWC(x)  ((x) >> 1)
+#define DMA_CHAN_FLOWC_MAX 8
+#define DMA_CHAN_MAX   16
+#define DMA_CHAN_SIZE  0x10
+#define DMA_CHAN_TOUT  500
+
+/* DMA Global Configuration register */
+#define DMA_CFG_REG0x00
+#define DMA_CFG_ENABLE_SHIFT   0
+#define DMA_CFG_ENABLE_MASK(1 << DMA_CFG_ENABLE_SHIFT)
+#define DMA_CFG_FLOWC_ENABLE(x)BIT(DMA_CHAN_FLOWC(x) + 1)
+#define DMA_CFG_NCHANS_SHIFT   24
+#define DMA_CFG_NCHANS_MASK(0xf << DMA_CFG_NCHANS_SHIFT)
+
+/* DMA Global Flow Control Threshold registers */
+#define DMA_FLOWC_THR_LO_REG(x)(0x04 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_THR_LO_SHIFT 0
+#define DMA_FLOWC_THR_LO_MASK  (5 << DMA_FLOWC_THR_LO_SHIFT)
+
+#define DMA_FLOWC_THR_HI_REG(x)(0x08 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_THR_HI_SHIFT 0
+#define DMA_FLOWC_THR_HI_MASK  (10 << DMA_FLOWC_THR_HI_SHIFT)
+
+/* DMA Global Flow Control Buffer Allocation registers */
+#define DMA_FLOWC_ALLOC_REG(x) (0x0c + DMA_CHAN_FLOWC(x) * 0x0c)
+#define DMA_FLOWC_ALLOC_FORCE_SHIFT31
+#define DMA_FLOWC_ALLOC_FORCE_MASK (1 << DMA_FLOWC_ALLOC_FORCE_SHIFT)
+
+/* DMA Global Reset register */
+#define DMA_RST_REG0x34
+#define DMA_RST_CHAN_SHIFT 0
+#define DMA_RST_CHAN_MASK(x)   (1 << x)
+
+/* DMA Channel Configuration register */
+#define DMAC_CFG_REG(x)(DMA_CHAN_SIZE * (x) + 0x00)
+#define DMAC_CFG_ENABLE_SHIFT  0
+#define DMAC_CFG_ENABLE_MASK   (1 << DMAC_CFG_ENABLE_SHIFT)
+#define DMAC_CFG_PKT_HALT_SHIFT1
+#define DMAC_CFG_PKT_HALT_MASK (1 << DMAC_CFG_PKT_HALT_SHIFT)
+#define DMAC_CFG_BRST_HALT_SHIFT   2
+#define DMAC_CFG_BRST_HALT_MASK(1 << DMAC_CFG_BRST_HALT_SHIFT)
+
+/* DMA Channel Interrupts registers */
+#define DMAC_IR_ST_REG(x)  (DMA_CHAN_SIZE * (x) + 0x04)
+#define DMAC_IR_EN_REG(x)  (DMA_CHAN_SIZE * (x) + 0x08)
+
+#define DMAC_IR_DONE_SHIFT 2
+#define DMAC_IR_DONE_MASK  (1 << DMAC_IR_DONE_SHIFT)

[U-Boot] [RFC v3 01/15] dma: move dma_ops to dma-uclass.h

[Álvaro Fernández Rojas]

Move dma_ops to a separate header file, following other uclass implementations.
While doing so, this patch also improves dma_ops documentation.

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: Introduce changes reported by Simon Glass:
  - Improve dma-uclass.h documentation.
  - Switch to live tree API.

 drivers/dma/dma-uclass.c |  3 ++-
 include/dma-uclass.h | 39 +++
 include/dma.h| 22 --
 3 files changed, 41 insertions(+), 23 deletions(-)
 create mode 100644 include/dma-uclass.h

diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 3d0ce22fbc..6fd4e1b35d 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -10,10 +10,11 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/include/dma-uclass.h b/include/dma-uclass.h
new file mode 100644
index 00..abf750a5ce
--- /dev/null
+++ b/include/dma-uclass.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ * Copyright (C) 2015 Texas Instruments Incorporated 
+ * Written by Mugunthan V N 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _DMA_UCLASS_H
+#define _DMA_UCLASS_H
+
+/* See dma.h for background documentation. */
+
+#include 
+
+/*
+ * struct dma_ops - Driver model DMA operations
+ *
+ * The uclass interface is implemented by all DMA devices which use
+ * driver model.
+ */
+struct dma_ops {
+   /**
+* transfer() - Issue a DMA transfer. The implementation must
+*   wait until the transfer is done.
+*
+* @dev: The DMA device
+* @direction: direction of data transfer (should be one from
+*   enum dma_direction)
+* @dst: The destination pointer.
+* @src: The source pointer.
+* @len: Length of the data to be copied (number of bytes).
+* @return zero on success, or -ve error code.
+*/
+   int (*transfer)(struct udevice *dev, int direction, void *dst,
+   void *src, size_t len);
+};
+
+#endif /* _DMA_UCLASS_H */
diff --git a/include/dma.h b/include/dma.h
index 71fa77f2ea..89320f10d9 100644
--- a/include/dma.h
+++ b/include/dma.h
@@ -28,28 +28,6 @@ enum dma_direction {
 #define DMA_SUPPORTS_DEV_TO_DEVBIT(3)
 
 /*
- * struct dma_ops - Driver model DMA operations
- *
- * The uclass interface is implemented by all DMA devices which use
- * driver model.
- */
-struct dma_ops {
-   /*
-* Get the current timer count
-*
-* @dev: The DMA device
-* @direction: direction of data transfer should be one from
-  enum dma_direction
-* @dst: Destination pointer
-* @src: Source pointer
-* @len: Length of the data to be copied.
-* @return: 0 if OK, -ve on error
-*/
-   int (*transfer)(struct udevice *dev, int direction, void *dst,
-   void *src, size_t len);
-};
-
-/*
  * struct dma_dev_priv - information about a device used by the uclass
  *
  * @supported: mode of transfers that DMA can support, should be
-- 
2.11.0

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

[U-Boot] [RFC v3 00/15] bmips: add bcm6348-enet support

[Álvaro Fernández Rojas]

In order to add bcm6348-enet support, dma-uclass must be extended to support
dma channels and reworked to operate like the other dm uclass (clk, reset...).

This is a RFC, so please give you feedback on the things that I should
fix or rework.

v3: Introduce changes reported by Simon Glass:
 - Improve dma-uclass.h documentation.
 - Switch to live tree API.
v2: Introduce changes reported by Vignesh:
 - Respect current dma implementation.
 - Let dma_memcpy find a compatible dma device.
Other changes:
 - Fix bcm6348-iudma rx burst config.

Álvaro Fernández Rojas (15):
  dma: move dma_ops to dma-uclass.h
  dma: add channels support
  dma: add bcm6348-iudma support
  bmips: bcm6338: add bcm6348-iudma support
  bmips: bcm6348: add bcm6348-iudma support
  bmips: bcm6358: add bcm6348-iudma support
  phy: add support for internal phys
  net: add support for bcm6348-enet
  bmips: bcm6338: add support for bcm6348-enet
  bmips: enable f@st1704 enet support
  bmips: bcm6348: add support for bcm6348-enet
  bmips: enable ct-5361 enet support
  bmips: bcm6358: add support for bcm6348-enet
  bmips: enable hg556a enet support
  bmips: enable nb4-ser enet support

 arch/mips/dts/brcm,bcm6338.dtsi   |  29 ++
 arch/mips/dts/brcm,bcm6348.dtsi   |  42 +++
 arch/mips/dts/brcm,bcm6358.dtsi   |  46 +++
 arch/mips/dts/comtrend,ct-5361.dts|  12 +
 arch/mips/dts/huawei,hg556a.dts   |  12 +
 arch/mips/dts/sagem,f...@st1704.dts  |  12 +
 arch/mips/dts/sfr,nb4-ser.dts |  24 ++
 configs/comtrend_ct5361_ram_defconfig |   8 +-
 configs/huawei_hg556a_ram_defconfig   |   8 +-
 configs/sagem_f@st1704_ram_defconfig  |   9 +-
 configs/sfr_nb4-ser_ram_defconfig |   8 +-
 drivers/dma/Kconfig   |  16 ++
 drivers/dma/Makefile  |   1 +
 drivers/dma/bcm6348-iudma.c   | 505 +
 drivers/dma/dma-uclass.c  | 191 -
 drivers/net/Kconfig   |  10 +
 drivers/net/Makefile  |   1 +
 drivers/net/bcm6348-eth.c | 517 ++
 include/configs/bmips_common.h|   5 +-
 include/dma-uclass.h  | 117 
 include/dma.h | 196 +++--
 include/dt-bindings/dma/bcm6338-dma.h |  15 +
 include/dt-bindings/dma/bcm6348-dma.h |  17 ++
 include/dt-bindings/dma/bcm6358-dma.h |  17 ++
 include/phy.h |   2 +
 25 files changed, 1784 insertions(+), 36 deletions(-)
 create mode 100644 drivers/dma/bcm6348-iudma.c
 create mode 100644 drivers/net/bcm6348-eth.c
 create mode 100644 include/dma-uclass.h
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

-- 
2.11.0

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

Re: [U-Boot] [RFC v2 02/15] dma: add channels support

[Álvaro Fernández Rojas]

Hi Simon,

El 20/02/2018 a las 19:49, Simon Glass escribió:

Hi Alvaro,

On 20 February 2018 at 10:46, Álvaro Fernández Rojas  wrote:

This adds channels support for dma controllers that have multiple channels
which can transfer data to/from different devices (enet, usb...).

Signed-off-by: Álvaro Fernández Rojas 
---
  v2: Introduce changes reported by Vignesh:
   - Respect current dma implementation.
   - Let dma_memcpy find a compatible dma device.

  drivers/dma/Kconfig  |   7 ++
  drivers/dma/dma-uclass.c | 177 +++
  include/dma-uclass.h |  77 +
  include/dma.h| 169 
  4 files changed, 430 insertions(+)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b92c7789d..21b2c0dcaa 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -12,6 +12,13 @@ config DMA
   buses that is used to transfer data to and from memory.
   The uclass interface is defined in include/dma.h.

+config DMA_CHANNELS
+   bool "Enable DMA channels support"
+   depends on DMA
+   help
+ Enable channels support for DMA. Some DMA controllers have multiple
+ channels which can either transfer data to/from different devices.
+
  config TI_EDMA3
 bool "TI EDMA3 driver"
 help
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 6fd4e1b35d..a16c3a786c 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -15,10 +15,187 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  DECLARE_GLOBAL_DATA_PTR;

+#ifdef CONFIG_DMA_CHANNELS
+static inline struct dma_ops *dma_dev_ops(struct udevice *dev)
+{
+   return (struct dma_ops *)dev->driver->ops;
+}
+
+# if CONFIG_IS_ENABLED(OF_CONTROL)
+#  if CONFIG_IS_ENABLED(OF_PLATDATA)
+int dma_get_by_index_platdata(struct udevice *dev, int index,
+ struct phandle_2_cell *cells, struct dma *dma)
+{
+   int ret;
+
+   if (index != 0)
+   return -ENOSYS;
+   ret = uclass_get_device(UCLASS_DMA, 0, >dev);
+   if (ret)
+   return ret;
+   dma->id = cells[0].id;
+
+   return 0;
+}
+#  else
+static int dma_of_xlate_default(struct dma *dma,
+   struct fdtdec_phandle_args *args)
+{
+   debug("%s(dma=%p)\n", __func__, dma);
+
+   if (args->args_count > 1) {
+   pr_err("Invaild args_count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   if (args->args_count)
+   dma->id = args->args[0];
+   else
+   dma->id = 0;
+
+   return 0;
+}
+
+int dma_get_by_index(struct udevice *dev, int index, struct dma *dma)
+{
+   int ret;
+   struct fdtdec_phandle_args args;
+   struct udevice *dev_dma;
+   struct dma_ops *ops;
+
+   debug("%s(dev=%p, index=%d, dma=%p)\n", __func__, dev, index, dma);
+
+   assert(dma);
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev_of_offset(dev),
+"dmas", "#dma-cells", 0, index,
+);

Can you please use the livetree API? E.g. see dev_read_phandle_with_args()

Also please move this into an ofdata_to_platdata function rather than
doing it each time this function is called.
I don't really get what you mean by moving this into an 
ofdata_to_platdata function.

This code is copied from other uclasses:
https://github.com/Noltari/u-boot/blob/master/drivers/clk/clk-uclass.c#L71
https://github.com/Noltari/u-boot/blob/master/drivers/power/domain/power-domain-uclass.c#L43
https://github.com/Noltari/u-boot/blob/master/drivers/reset/reset-uclass.c#L47




+   if (ret) {
+   pr_err("%s: fdtdec_parse_phandle_with_args failed: err=%d\n",
+ __func__, ret);
+   return ret;
+   }
+
+   ret = uclass_get_device_by_of_offset(UCLASS_DMA, args.node, _dma);
+   if (ret) {
+   pr_err("%s: uclass_get_device_by_of_offset failed: err=%d\n",
+ __func__, ret);
+   return ret;
+   }
+
+   dma->dev = dev_dma;
+
+   ops = dma_dev_ops(dev_dma);
+
+   if (ops->of_xlate)
+   ret = ops->of_xlate(dma, );
+   else
+   ret = dma_of_xlate_default(dma, );
+   if (ret) {
+   pr_err("of_xlate() failed: %d\n", ret);
+   return ret;
+   }
+
+   return dma_request(dev_dma, dma);
+}
+#  endif /* OF_PLATDATA */
+
+int dma_get_by_name(struct udevice *dev, const char *name, struct dma *dma)
+{
+   int index;
+
+   debug("%s(dev=%p, name=%s, dma=%p)\n", __func__, dev, name, dma);
+
+   index = fdt_stringlist_search(gd->fdt_blob, dev_of_offset(dev),
+ "dma-names", name);

dev_read...


+   if (index < 0) {
+   

[U-Boot] [PATCH] clk: zynq: Show watchdog clock rate properly

[Michal Simek]

watchdog clock is also connected to cpu 1X clocksource.

Zynq> clk dump
...

Before:
  swdt  4294967290
After:
  swdt   0

Signed-off-by: Michal Simek 
---

 drivers/clk/clk_zynq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index 50f2a65c205e..3845e0730978 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -394,7 +394,7 @@ static ulong zynq_clk_get_rate(struct clk *clk)
return zynq_clk_get_peripheral_rate(priv, id, two_divs);
case dma_clk:
return zynq_clk_get_cpu_rate(priv, cpu_2x_clk);
-   case usb0_aper_clk ... smc_aper_clk:
+   case usb0_aper_clk ... swdt_clk:
return zynq_clk_get_cpu_rate(priv, cpu_1x_clk);
default:
return -ENXIO;
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] mtd: nand: tegra: convert to driver model and live tree

[Marcel Ziswiler]

From: Marcel Ziswiler 

The Tegra NAND driver recently got broken by ongoing driver model resp.
live tree migration work:

NAND:  Could not decode nand-flash in device tree
Tegra NAND init failed
0 MiB

A patch for NAND uclass support was proposed about a year ago:
https://patchwork.ozlabs.org/patch/722282/

It was not merged and I do not see on-going work for this.

This commit just provides a driver model probe hook to retrieve further
configuration from the live device tree. As there is no NAND ulass as of
yet (ab)using UCLASS_MISC. Once UCLASS_NAND is supported, it would be
possible to migrate to it.

Signed-off-by: Marcel Ziswiler 

---

 drivers/mtd/nand/tegra_nand.c | 98 ---
 1 file changed, 55 insertions(+), 43 deletions(-)

diff --git a/drivers/mtd/nand/tegra_nand.c b/drivers/mtd/nand/tegra_nand.c
index c03c9cb178..405018018c 100644
--- a/drivers/mtd/nand/tegra_nand.c
+++ b/drivers/mtd/nand/tegra_nand.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "tegra_nand.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -29,6 +30,13 @@ DECLARE_GLOBAL_DATA_PTR;
 /* ECC bytes to be generated for tag data */
 #define TAG_ECC_BYTES  4
 
+static const struct udevice_id tegra_nand_dt_ids[] = {
+   {
+   .compatible = "nvidia,tegra20-nand",
+   },
+   { /* sentinel */ }
+};
+
 /* 64 byte oob block info for large page (== 2KB) device
  *
  * OOB flash layout for Tegra with Reed-Solomon 4 symbol correct ECC:
@@ -91,9 +99,11 @@ struct nand_drv {
struct fdt_nand config;
 };
 
-static struct nand_drv nand_ctrl;
-static struct mtd_info *our_mtd;
-static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
+struct tegra_nand_info {
+   struct udevice *dev;
+   struct nand_drv nand_ctrl;
+   struct nand_chip nand_chip;
+};
 
 /**
  * Wait for command completion
@@ -453,8 +463,8 @@ static void stop_command(struct nand_ctlr *reg)
  * @param *reg_val address of reg_val
  * @return 0 if ok, -1 on error
  */
-static int set_bus_width_page_size(struct fdt_nand *config,
-   u32 *reg_val)
+static int set_bus_width_page_size(struct mtd_info *our_mtd,
+  struct fdt_nand *config, u32 *reg_val)
 {
if (config->width == 8)
*reg_val = CFG_BUS_WIDTH_8BIT;
@@ -514,7 +524,7 @@ static int nand_rw_page(struct mtd_info *mtd, struct 
nand_chip *chip,
 
info = (struct nand_drv *)nand_get_controller_data(chip);
config = >config;
-   if (set_bus_width_page_size(config, _val))
+   if (set_bus_width_page_size(mtd, config, _val))
return -EINVAL;
 
/* Need to be 4-byte aligned */
@@ -722,7 +732,7 @@ static int nand_rw_oob(struct mtd_info *mtd, struct 
nand_chip *chip,
if (((int)chip->oob_poi) & 0x03)
return -EINVAL;
info = (struct nand_drv *)nand_get_controller_data(chip);
-   if (set_bus_width_page_size(>config, _val))
+   if (set_bus_width_page_size(mtd, >config, _val))
return -EINVAL;
 
stop_command(info->reg);
@@ -883,51 +893,39 @@ static void setup_timing(unsigned 
timing[FDT_NAND_TIMING_COUNT],
 /**
  * Decode NAND parameters from the device tree
  *
- * @param blob Device tree blob
- * @param node Node containing "nand-flash" compatible node
+ * @param dev  Driver model device
+ * @param config   Device tree NAND configuration
  * @return 0 if ok, -ve on error (FDT_ERR_...)
  */
-static int fdt_decode_nand(const void *blob, int node, struct fdt_nand *config)
+static int fdt_decode_nand(struct udevice *dev, struct fdt_nand *config)
 {
int err;
 
-   config->reg = (struct nand_ctlr *)fdtdec_get_addr(blob, node, "reg");
-   config->enabled = fdtdec_get_is_enabled(blob, node);
-   config->width = fdtdec_get_int(blob, node, "nvidia,nand-width", 8);
-   err = gpio_request_by_name_nodev(offset_to_ofnode(node),
-   "nvidia,wp-gpios", 0, >wp_gpio, GPIOD_IS_OUT);
+   config->reg = (struct nand_ctlr *)dev_read_addr(dev);
+   config->enabled = dev_read_enabled(dev);
+   config->width = dev_read_u32_default(dev, "nvidia,nand-width", 8);
+   err = gpio_request_by_name(dev, "nvidia,wp-gpios", 0, >wp_gpio,
+  GPIOD_IS_OUT);
if (err)
return err;
-   err = fdtdec_get_int_array(blob, node, "nvidia,timing",
-   config->timing, FDT_NAND_TIMING_COUNT);
+   err = dev_read_u32_array(dev, "nvidia,timing", config->timing,
+FDT_NAND_TIMING_COUNT);
if (err < 0)
return err;
 
-   /* Now look up the controller and decode that */
-   node = fdt_next_node(blob, node, NULL);
-   if (node < 0)
-   return node;
-
return 0;
 }
 
-/**
- * Board-specific NAND initialization
- *
- * @param nand nand 

[U-Boot] [PATCH 2/2] configs: harmony: enable live tree, mtd and ubi

[Marcel Ziswiler]

From: Marcel Ziswiler 

U-Boot on Harmony recently got broken by ongoing driver model resp. live
tree migration work:

U-Boot 2018.03-rc3 (Feb 21 2018 - 15:43:08 +0100)

TEGRA20
Model: NVIDIA Tegra20 Harmony evaluation board
Board: NVIDIA Harmony
DRAM:  1 GiB
Video device 'dc@5420' cannot allocate frame buffer memory -ensure
the device is set up before relocation
Error binding driver 'tegra_lcd': -28
Some drivers failed to bind
Error binding driver 'generic_simple_bus': -28
Some drivers failed to bind
initcall sequence 3ffa86d0 failed at call 00121dc0 (err=-28)

This commit fixes this by enabling live tree, MTD and UBI for Harmony as
well.

Signed-off-by: Marcel Ziswiler 

---

 configs/harmony_defconfig | 5 +
 include/configs/harmony.h | 4 
 2 files changed, 9 insertions(+)

diff --git a/configs/harmony_defconfig b/configs/harmony_defconfig
index 33b3ba5fce..1d1a158691 100644
--- a/configs/harmony_defconfig
+++ b/configs/harmony_defconfig
@@ -18,14 +18,19 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
+CONFIG_MTDIDS_DEFAULT="nand0=tegra_nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=tegra_nand:2m(u-boot)ro,1m(u-boot-env),1m(cfgblock)ro,-(ubi)"
+CONFIG_CMD_UBI=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_LIVE=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
+CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
diff --git a/include/configs/harmony.h b/include/configs/harmony.h
index 9a0b1aff24..59fd6c4eb5 100644
--- a/include/configs/harmony.h
+++ b/include/configs/harmony.h
@@ -30,6 +30,10 @@
 #define CONFIG_TEGRA_NAND
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 
+/* Dynamic MTD partition support */
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE  /* needed for mtdparts commands */
+
 /* Environment in NAND (which is 512M), aligned to start of last sector */
 #define CONFIG_ENV_OFFSET  (SZ_512M - SZ_128K) /* 128K sector size */
 
-- 
2.14.3

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

Re: [U-Boot] [RFC] Make U-Boot log great again

[Tom Rini]

On Wed, Feb 21, 2018 at 04:07:03PM +0100, Maxime Ripard wrote:
> On Wed, Feb 21, 2018 at 09:54:41AM -0500, Tom Rini wrote:
> > On Wed, Feb 21, 2018 at 03:38:42PM +0100, Simon Goldschmidt wrote:
> > > On 21.02.2018 14:35, Tom Rini wrote:
> > > >On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:
> > > >>On Tue, 20 Feb 2018 09:00:56 +0100
> > > >>Maxime Ripard  wrote:
> > > >>
> > > >>>On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:
> > > On 18 February 2018 at 23:22, Wolfgang Denk  wrote:
> > > >Dear Sam,
> > > >
> > > >In message
> > > 

Re: [U-Boot] [RFC] Make U-Boot log great again

[Maxime Ripard]

On Wed, Feb 21, 2018 at 09:54:41AM -0500, Tom Rini wrote:
> On Wed, Feb 21, 2018 at 03:38:42PM +0100, Simon Goldschmidt wrote:
> > On 21.02.2018 14:35, Tom Rini wrote:
> > >On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:
> > >>On Tue, 20 Feb 2018 09:00:56 +0100
> > >>Maxime Ripard  wrote:
> > >>
> > >>>On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:
> > On 18 February 2018 at 23:22, Wolfgang Denk  wrote:
> > >Dear Sam,
> > >
> > >In message
> > 

Re: [U-Boot] [RFC] Make U-Boot log great again

[Simon Goldschmidt]

On 21.02.2018 15:54, Tom Rini wrote:

On Wed, Feb 21, 2018 at 03:38:42PM +0100, Simon Goldschmidt wrote:

On 21.02.2018 14:35, Tom Rini wrote:

On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:

On Tue, 20 Feb 2018 09:00:56 +0100
Maxime Ripard  wrote:


On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:

On 18 February 2018 at 23:22, Wolfgang Denk  wrote:

Dear Sam,

In message

Re: [U-Boot] [RFC] Make U-Boot log great again

[Tom Rini]

On Wed, Feb 21, 2018 at 02:55:29PM +0100, Maxime Ripard wrote:
> On Wed, Feb 21, 2018 at 08:35:47AM -0500, Tom Rini wrote:
> > On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:
> > > On Tue, 20 Feb 2018 09:00:56 +0100
> > > Maxime Ripard  wrote:
> > > 
> > > > On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:
> > > > > On 18 February 2018 at 23:22, Wolfgang Denk  wrote:  
> > > > > > Dear Sam,
> > > > > >
> > > > > > In message
> > > > > > 

Re: [U-Boot] [RFC] Make U-Boot log great again

[Tom Rini]

On Wed, Feb 21, 2018 at 03:38:42PM +0100, Simon Goldschmidt wrote:
> On 21.02.2018 14:35, Tom Rini wrote:
> >On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:
> >>On Tue, 20 Feb 2018 09:00:56 +0100
> >>Maxime Ripard  wrote:
> >>
> >>>On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:
> On 18 February 2018 at 23:22, Wolfgang Denk  wrote:
> >Dear Sam,
> >
> >In message
> 

Re: [U-Boot] [RFC] Make U-Boot log great again

[Simon Goldschmidt]

On 21.02.2018 14:35, Tom Rini wrote:

On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:

On Tue, 20 Feb 2018 09:00:56 +0100
Maxime Ripard  wrote:


On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:

On 18 February 2018 at 23:22, Wolfgang Denk  wrote:

Dear Sam,

In message

Re: [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Andrew F. Davis]

On 02/20/2018 09:27 PM, Bryan O'Donoghue wrote:
> 
> 
> On 19/02/18 15:44, Tom Rini wrote:
>> On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
>>> Bryan,
>>>
 On 2 Feb 2018, at 16:37, Bryan O'Donoghue
  wrote:



 On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use
> IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?

 I think because you aren't doing anything different with the image
 type you can reuse IH_TYPE_TEE

 This

 +#if CONFIG_IS_ENABLED(OPTEE)
 +    case IH_OS_OP_TEE:
 +    debug("Jumping to U-Boot via OP-TEE\n");
 +    spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
 +    (void *)spl_image.entry_point);
 +    break;
 +#endif

 could just as easily be this

 +#if CONFIG_IS_ENABLED(OPTEE)
 +    case IH_TYPE_TEE:
 +    debug("Jumping to U-Boot via OP-TEE\n");
 +    spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
 +    (void *)spl_image.entry_point);
 +    break;
 +#endif

 should be a matter of just replacing the call to mkimage to use

 mkimage -A arm -T tee

 instead of

 mkimage -A arm -T optee

 and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
>>>
>>> Thanks for summarising your suggestion.
>>>
>>> However, my mail was intended to test the waters to see what the
>>> consensus was.
>>> A it appears that none has yet emerged between all the involved
>>> parties (including
>>> our colleagues from TI that had also chimed in on the discussion).
>>> So for now, I’ll sit back and wait until some sort of consensus (or
>>> at least a majority
>>> for one solution or the other) emerges.
>>>
>>> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both
>>> refering to OP-TEE
>>> and the upstream OP-TEE documentation suggesting that their
>>> envisioned boot
>>> process was to boot through the OP-TEE (i.e. what the ‘tee’ image
>>> type does).
>>> However, with the ‘tee’ image type already being defined, we seem to
>>> have already
>>> backed ourselves into a situation where the naming is non-intuitive.
>>
>> Alright, I'm a little confused here.  I guess first, there's a
>> disconnect in upstream OP-TEE land about how 32bit ARM should be done?
>> I guess we have three different implemented and upstreamed flows:
>> - SPL->U-Boot->OP-TEE->U-Boot->Linux
>> - SPL->U-Boot->OP-TEE->Linux
>> - SPL->OP-TEE->U-Boot->Linux
> 
> I'd call that
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
> - SPL/BootROM->U-Boot->OP-TEE->Linux
> - SPL/BootROM->OP-TEE->U-Boot->Linux
> 
> But yes - fundamentally your flow is correct.
> 


I think it works better to have the secure/non-secure sides labeled,
here are two flows we support:

Non-Secure   Secure

 BootROM
   |
  -
 |
 v
SPL
 |
 v
   U-Boot -->
  <-  OP-TEE
  |
  V
Linux


Non-Secure   Secure

 BootROM
   |
  -
 |
 v
SPL --->
 <-  OP-TEE
 |
 v
   U-Boot
  |
  V
Linux

(Plus one were BootROM starts a TEE directly, but that is transparent to
SPL/U-Boot)

Both of these are handled by the IH_TEE type, which behaves much like a
regular function call in that it returns execution to were it was kicked
off from.

So to me there is only a need for two types, one like the above, and one
for when the TEE is a stage in the boot flow, whether in between
SPL->U-Boot or U-Boot->Linux, U-Boot needs to know it is not coming back
and so set it up like a regular OS payload.

>>
>> And in this last case we have a combined image that is passed from SPL
>> to OP-TEE.
>>
>> Since all 3 of these flows are in upstream OP-TEE, we need to support
>> them all. 
> 
> Agreed.
> 
>> The biggest constraint is that we have the first flow already
>> in and named "tee" (my fault, I should have made sure everyone would use
>> the same flow).  So we need to have descriptive enough names for the
>> other flows that we're going to add so that it's clear what's what.  How
>> about "tee-standalone" for "U-Boot starts OP-TEE, and is done"
> 
>> "tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
>> even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
>> I'm also happy to hear better suffixes but I don't want "tee" and
>> "optee".  And if we can cover two flows under the same name, that's good
>> too, we just need to name the last flow "tee-something".  Thanks all!
> 
> Yes I take your point "tee" and "optee" are the opposite of descriptive
> names.
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
>   Currently called "tee" - has type IH_TEE - maintained as is for
>   compatibility - deserves some documentation.
> 
> - 

Re: [U-Boot] [PATCH 2/2] arm: socfpga: cyclone5: Ensure spi-flash in the compatible string

[See, Chin Liang]

On Wed, 2018-02-21 at 10:34 +0100, Simon Goldschmidt wrote:
> On 21.02.2018 08:40, chin.liang@intel.com wrote:
> > 
> > From: Chin Liang See 
> > 
> > Ensure "spi-flash" is added into compatible string when there is
> > NOR flash being instantiated in DTS. Discovered "sf probe" command
> > without argument would hit error if spi-flash compatible string
> > is missing.
> This has already been fixed 5 days ago.
> 

Nice and thanks for the patch.
I was pulling from the source few days back for enabling the Macronix
flash and bumping into this same issue.

Thanks
Chin Liang

> Simon
> 
> > 
> > 
> > Signed-off-by: Chin Liang See 
> > ---
> >   arch/arm/dts/socfpga_cyclone5_is1.dts  | 2 +-
> >   arch/arm/dts/socfpga_cyclone5_socdk.dts| 2 +-
> >   arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 +-
> >   3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts
> > b/arch/arm/dts/socfpga_cyclone5_is1.dts
> > index 2e2b71f..549024c 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_is1.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
> > @@ -87,7 +87,7 @@
> >     u-boot,dm-pre-reloc;
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <1>;
> >     m25p,fast-read;
> > diff --git a/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > index 95a8e65..e30bf9a 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> > @@ -98,7 +98,7 @@
> >     u-boot,dm-pre-reloc;
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <1>;
> >     m25p,fast-read;
> > diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > b/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > index e3ae8a8..3e78038 100644
> > --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts
> > @@ -68,7 +68,7 @@
> >     flash0: n25q00@0 {
> >     #address-cells = <1>;
> >     #size-cells = <1>;
> > -   compatible = "n25q00";
> > +   compatible = "n25q00","spi-flash";
> >     reg = <0>;  /* chip select */
> >     spi-max-frequency = <5000>;
> >     m25p,fast-read;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Make U-Boot log great again

[Tom Rini]

On Tue, Feb 20, 2018 at 10:59:33AM +0100, Lukasz Majewski wrote:
> On Tue, 20 Feb 2018 09:00:56 +0100
> Maxime Ripard  wrote:
> 
> > On Mon, Feb 19, 2018 at 07:47:52PM +0200, Sam Protsenko wrote:
> > > On 18 February 2018 at 23:22, Wolfgang Denk  wrote:  
> > > > Dear Sam,
> > > >
> > > > In message
> > > > 

[U-Boot] [PATCH] arm64: zynqmp: Enable newer pmufw versions

[Michal Simek]

As of now newer pmufw is keeping old interfaces. That's why permit
u-boot to run on newer version. Recommended version will be setup later.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index bc77dd03c361..14e7d4006494 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -185,7 +185,7 @@ void zynqmp_pmufw_version(void)
   pm_api_version >> ZYNQMP_PM_VERSION_MAJOR_SHIFT,
   pm_api_version & ZYNQMP_PM_VERSION_MINOR_MASK);
 
-   if (pm_api_version != ZYNQMP_PM_VERSION)
+   if (pm_api_version < ZYNQMP_PM_VERSION)
panic("PMUFW version error. Expected: v%d.%d\n",
  ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR);
 }
-- 
1.9.1

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

Re: [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Dr. Philipp Tomsich]

Bryan,

> On 21 Feb 2018, at 04:27, Bryan O'Donoghue  wrote:
> 
> On 19/02/18 15:44, Tom Rini wrote:
>> On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
>>> Bryan,
>>> 
 On 2 Feb 2018, at 16:37, Bryan O'Donoghue  
 wrote:
 
 
 
 On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use 
> IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
 
 I think because you aren't doing anything different with the image type 
 you can reuse IH_TYPE_TEE
 
 This
 
 +#if CONFIG_IS_ENABLED(OPTEE)
 +  case IH_OS_OP_TEE:
 +  debug("Jumping to U-Boot via OP-TEE\n");
 +  spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
 +  (void *)spl_image.entry_point);
 +  break;
 +#endif
 
 could just as easily be this
 
 +#if CONFIG_IS_ENABLED(OPTEE)
 +  case IH_TYPE_TEE:
 +  debug("Jumping to U-Boot via OP-TEE\n");
 +  spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
 +  (void *)spl_image.entry_point);
 +  break;
 +#endif
 
 should be a matter of just replacing the call to mkimage to use
 
 mkimage -A arm -T tee
 
 instead of
 
 mkimage -A arm -T optee
 
 and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
>>> 
>>> Thanks for summarising your suggestion.
>>> 
>>> However, my mail was intended to test the waters to see what the consensus 
>>> was.
>>> A it appears that none has yet emerged between all the involved parties 
>>> (including
>>> our colleagues from TI that had also chimed in on the discussion).
>>> So for now, I’ll sit back and wait until some sort of consensus (or at 
>>> least a majority
>>> for one solution or the other) emerges.
>>> 
>>> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both refering 
>>> to OP-TEE
>>> and the upstream OP-TEE documentation suggesting that their envisioned boot
>>> process was to boot through the OP-TEE (i.e. what the ‘tee’ image type 
>>> does).
>>> However, with the ‘tee’ image type already being defined, we seem to have 
>>> already
>>> backed ourselves into a situation where the naming is non-intuitive.
>> Alright, I'm a little confused here.  I guess first, there's a
>> disconnect in upstream OP-TEE land about how 32bit ARM should be done?
>> I guess we have three different implemented and upstreamed flows:
>> - SPL->U-Boot->OP-TEE->U-Boot->Linux
>> - SPL->U-Boot->OP-TEE->Linux
>> - SPL->OP-TEE->U-Boot->Linux
> 
> I'd call that
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
> - SPL/BootROM->U-Boot->OP-TEE->Linux
> - SPL/BootROM->OP-TEE->U-Boot->Linux
> 
> But yes - fundamentally your flow is correct.
> 
>> And in this last case we have a combined image that is passed from SPL
>> to OP-TEE.
>> Since all 3 of these flows are in upstream OP-TEE, we need to support
>> them all. 
> 
> Agreed.
> 
>> The biggest constraint is that we have the first flow already
>> in and named "tee" (my fault, I should have made sure everyone would use
>> the same flow).  So we need to have descriptive enough names for the
>> other flows that we're going to add so that it's clear what's what.  How
>> about "tee-standalone" for "U-Boot starts OP-TEE, and is done"
> 
>> "tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
>> even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
>> I'm also happy to hear better suffixes but I don't want "tee" and
>> "optee".  And if we can cover two flows under the same name, that's good
>> too, we just need to name the last flow "tee-something".  Thanks all!
> 
> Yes I take your point "tee" and "optee" are the opposite of descriptive names.
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
>  Currently called "tee" - has type IH_TEE - maintained as is for
>  compatibility - deserves some documentation.
> 
> - SPL/BootROM->U-Boot->OP-TEE->Linux
>  New type "tee-standalone" this would be the type I've proposed
>  in my patch set. New type IH_TYPE_TEE_STANDALONE
> 
> - SPL/BootROM->OP-TEE->U-Boot->Linux
>  New type "tee-combo" this would be Kever's type IH_TYPE_TEE_COMBO
> 
> I've suggested to Kever that he doesn't actually need a separate type (though 
> I could be wrong).

My guess is that TEE_COMBO should cover Kever’s case.
We’ll probably need to wait and see if he encounters issues with this, once
he’s back after the Chinese New Year holiday.

> I resend my previous patchset renaming "optee" to "tee-standalone" and add 
> the type IH_TYPE_TEE_STANDALONE.

As it looks as you’ll have your series revised first—could you add some
documentation that summarises the various the ways of how OPTEE
and some info on your use-case?

I’d then make sure (prior to merging) that Kever provides an update
against this file that provides 

[U-Boot] [PATCH] ARM: dts: i.MX6QDL: icore-rqs: Fix eMMC detection during SPL

[Jagan Teki]

usdhc4 has eMMC on icore-rqs boards, SPL is not detecting
it becuase of u-boot,dm-spl flag so add it to make eMMC working.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6qdl-icore-rqs.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-icore-rqs.dtsi 
b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
index 816cdce2f3..1623838490 100644
--- a/arch/arm/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/dts/imx6qdl-icore-rqs.dtsi
@@ -114,6 +114,7 @@
 };
 
  {
+   u-boot,dm-spl;
pinctrl-names = "default";
pinctrl-0 = <_usdhc4>;
no-1-8-v;
@@ -183,6 +184,7 @@
};
 
pinctrl_usdhc4: usdhc4grp {
+   u-boot,dm-spl;
fsl,pins = <
MX6QDL_PAD_SD4_CMD__SD4_CMD0x17070
MX6QDL_PAD_SD4_CLK__SD4_CLK0x10070
-- 
2.14.3

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

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

[Tom Rini]

On Wed, Feb 21, 2018 at 09:41:10PM +0900, Masahiro Yamada wrote:
> 2018-02-21 21:19 GMT+09:00 Tom Rini :
> > On Wed, Feb 21, 2018 at 04:07:10PM +0900, Masahiro Yamada wrote:
> >> 2018-01-06 3:17 GMT+09:00 Masahiro Yamada :
> >> > U-Boot pulled in several core makefiles from Linux.  The following
> >> > are not used in U-Boot:
> >> >
> >> >   - CONFIG_DEBUG_SECTION_MISMATCH
> >> >   - CONFIG_FTRACE_MCOUNT_RECORD
> >> >   - CONFIG_GCOV_KERNEL
> >> >   - CONFIG_GCOV_PROFILE_ALL
> >> >   - CONFIG_KASAN
> >> >   - CONFIG_MODVERSIONS
> >> >
> >> > We can remove the unused code if we like. (although it will get the
> >> > scripts out of sync)
> >> >
> >> > CONFIG_BOOM and CONFIG_HIS_DRIVER are just mentioned in the comment
> >> > block of scripts/basic/fixdep.c
> >> >
> >> > CONFIG_SHELL is not configuration, but a variable for internal-use.
> >> > It is just a historical misnomer in Kbuild.
> >> >
> >> > Signed-off-by: Masahiro Yamada 
> >>
> >>
> >> Tom,
> >>
> >> Can you check this please?
> >
> > The problem is that it will get put back in by
> > ./scripts/build-whitelist.sh yes?
> 
> No.
> 
> If you incrementally run build-whitelist.sh,
> they will not get back.
> 
> 
> If you delete config_whitelist.txt and
> build it from scratch, yes, they will get back
> with other options we had already deleted.
> 
> For example, commit 8bb0f7c0c59e8c5b6f7a6869b802f593739c7ece
> 
> But we do not want to do this.
> 
> 
> 
> For detailed implementation, see below.
> 
> https://github.com/u-boot/u-boot/blob/v2018.03-rc3/scripts/build-whitelist.sh#L50

Ah, ok, thanks.  Yes, I'll grab this soon.

-- 
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] config_whitelist: remove false-positive CONFIG options

[Masahiro Yamada]

2018-02-21 21:19 GMT+09:00 Tom Rini :
> On Wed, Feb 21, 2018 at 04:07:10PM +0900, Masahiro Yamada wrote:
>> 2018-01-06 3:17 GMT+09:00 Masahiro Yamada :
>> > U-Boot pulled in several core makefiles from Linux.  The following
>> > are not used in U-Boot:
>> >
>> >   - CONFIG_DEBUG_SECTION_MISMATCH
>> >   - CONFIG_FTRACE_MCOUNT_RECORD
>> >   - CONFIG_GCOV_KERNEL
>> >   - CONFIG_GCOV_PROFILE_ALL
>> >   - CONFIG_KASAN
>> >   - CONFIG_MODVERSIONS
>> >
>> > We can remove the unused code if we like. (although it will get the
>> > scripts out of sync)
>> >
>> > CONFIG_BOOM and CONFIG_HIS_DRIVER are just mentioned in the comment
>> > block of scripts/basic/fixdep.c
>> >
>> > CONFIG_SHELL is not configuration, but a variable for internal-use.
>> > It is just a historical misnomer in Kbuild.
>> >
>> > Signed-off-by: Masahiro Yamada 
>>
>>
>> Tom,
>>
>> Can you check this please?
>
> The problem is that it will get put back in by
> ./scripts/build-whitelist.sh yes?

No.

If you incrementally run build-whitelist.sh,
they will not get back.


If you delete config_whitelist.txt and
build it from scratch, yes, they will get back
with other options we had already deleted.

For example, commit 8bb0f7c0c59e8c5b6f7a6869b802f593739c7ece

But we do not want to do this.



For detailed implementation, see below.

https://github.com/u-boot/u-boot/blob/v2018.03-rc3/scripts/build-whitelist.sh#L50






>  I try and run that at least every
> tag.  Thanks!
>
> --
> Tom
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>



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

[U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs

[Alexey Brodkin]

Synopsys Data Fusion subsystem (DFSS) is targeted to deeply built-in
use-cases and so to save some silicon area decision was made to
escape usage of any busses and use instead directly wired to CPU
peripherals. And one of those is DW APB UART.

Later DFSS became a part of larger and more complicated SoCs with
some other peripherals connected via common buses but default UART
is still used via ARC core's auxulary registers which are not mapped
to "normal" address space and we use very special instructions to access
them, thus we cannot simply reuse whatever accessor we have in 16550
UART as of now.

Also we cannot just switch inb()/outb() to access ARC AUX regs always
for DFSS because other peripherals have normal memory-mapped control
registers and we need to use normal accessors for them.

Frankly I don't like a lot what I did here but otherwise if I create
a special driver for this I'll need to reimplement
ns16550_serial_ops.putc()/getc() which will be pure copy-paseted from
ns16550.c because the only difference is only in
ns16550_{read|write}b().

As mentioned above we cannot remap those auxiliary registers to
normal memory address-space and thus we have to use very special
accessors write_aux_reg()/read_aux_reg() that directly use special
CPU intructions (namely LR/SR) for dealing with ARC AUX regs.

Also note here I just use a check for a particular SoC being selected
(CONFIG_ARCH_DFSS will be introduced shortly) but that is done just for
simplicity, otherwise it might be a slecial Kconfig option for NS16550
or anything else.

I'd like to know what people think about possible colutions here.
And as always any comments are much appreciated!

Signed-off-by: Alexey Brodkin 
Cc: Simon Glass 
Cc: Tom Rini 
Cc: Stefan Roese 
---
 drivers/serial/ns16550.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 6f9ce689cfff..75f342f337f1 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_ARCH_DFSS
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -53,7 +56,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static inline void serial_out_shift(void *addr, int shift, int value)
 {
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#ifdef CONFIG_ARCH_DFSS
+   write_aux_reg((int)addr, value);
+#elif defined(CONFIG_SYS_NS16550_PORT_MAPPED)
outb(value, (ulong)addr);
 #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
out_le32(addr, value);
@@ -70,7 +75,9 @@ static inline void serial_out_shift(void *addr, int shift, 
int value)
 
 static inline int serial_in_shift(void *addr, int shift)
 {
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#ifdef CONFIG_ARCH_DFSS
+   return read_aux_reg((int)addr);
+#elif defined(CONFIG_SYS_NS16550_PORT_MAPPED)
return inb((ulong)addr);
 #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
return in_le32(addr);
-- 
2.14.3

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

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

[Tom Rini]

On Wed, Feb 21, 2018 at 04:07:10PM +0900, Masahiro Yamada wrote:
> 2018-01-06 3:17 GMT+09:00 Masahiro Yamada :
> > U-Boot pulled in several core makefiles from Linux.  The following
> > are not used in U-Boot:
> >
> >   - CONFIG_DEBUG_SECTION_MISMATCH
> >   - CONFIG_FTRACE_MCOUNT_RECORD
> >   - CONFIG_GCOV_KERNEL
> >   - CONFIG_GCOV_PROFILE_ALL
> >   - CONFIG_KASAN
> >   - CONFIG_MODVERSIONS
> >
> > We can remove the unused code if we like. (although it will get the
> > scripts out of sync)
> >
> > CONFIG_BOOM and CONFIG_HIS_DRIVER are just mentioned in the comment
> > block of scripts/basic/fixdep.c
> >
> > CONFIG_SHELL is not configuration, but a variable for internal-use.
> > It is just a historical misnomer in Kbuild.
> >
> > Signed-off-by: Masahiro Yamada 
> 
> 
> Tom,
> 
> Can you check this please?

The problem is that it will get put back in by
./scripts/build-whitelist.sh yes?  I try and run that at least every
tag.  Thanks!

-- 
Tom


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

[U-Boot] malloc crash

[Ansuel Smith]

Trying to porting uboot to a new board. I'm testing new ubbo by
loading it in ram...
It does run but then it stops
I enabled debug
Here is the bootlog. any idea?
https://pastebin.com/d8LbHL2D
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Zoran S]

Hello to U-Boot list,

I have encountered an interesting problem which I do not entirely
understand. I am trying to boot MLO and u-boot.bin from the SD Card,
and rest from the initramfs.

I tried several initramfs images, and so far I am always failing on
the same place:
[2.135533] No filesystem could mount root, tried:
[2.135541]  ext2
[2.140682]
[2.144262] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(1,0)
[2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to
mount root fs on unknown-block(1,0)

I have tried mostly .gz images (cpio.gz and ext2.gz). Does not help.
Even does not with ext2.gz after YOCTO is done. In order to do it
correctly, I MUST to add U-Boot header, and I do this with the
following command:

mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
initramfs.ext2.gz initramfs.uImage

And the image I actually supply is: initramfs.uImage

Then, the following happens:

=> run netloadfdt
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.15.2; our IP address is 192.168.15.20
Filename 'am335x-boneblack.dtb'.
Load address: 0x8800
Loading: ###
 697.3 KiB/s
done
Bytes transferred = 35016 (88c8 hex)
=> run netloadimage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.15.2; our IP address is 192.168.15.20
Filename 'zImage'.
Load address: 0x8200
Loading: #
 #
 #
 #
 
 772.5 KiB/s
done
Bytes transferred = 4161160 (3f7e88 hex)
=> tftp 0x8808 initramfs.uImage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.15.2; our IP address is 192.168.15.20
Filename 'initramfs.uImage'.
Load address: 0x8808
Loading: #
 #

 [snap]

 ###
 767.6 KiB/s
done
Bytes transferred = 46599246 (2c70c4e hex)
=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.15.159 (21 ms)
=> run ramboot
Booting from ramdisk ...
## Loading init Ramdisk from Legacy Image at 8808 ...
   Image Name:   Ramdisk Image
   Created:  2018-02-21   9:46:15 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:46599182 Bytes = 44.4 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8d38f000, end 8c0e ... OK
   Loading Device Tree to 8d383000, end 8d38e8c7 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.13.8-jumpnow (oe-user@oe-host) (gcc
version 7.2.0 (GCC)) #1 Tue Jan 9 15:37:12 CET 2018
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
[0.00] Memory policy: Data cache writeback
[0.00] cma: Reserved 16 MiB at 0x9f00
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.1 (sgx neon)
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 130048

Please, note the Kernal Command line in the log!
[0.00] Kernel command line: console=ttyO0,115200n8
root=/dev/ram0 rw rootfstype=ext2 << Kernel
Command Line

[SNAP]

[1.770469] omap_voltage_late_init: Voltage driver support not added
[1.777510] ThumbEE CPU extension supported.
[1.791397] mmcblk0: mmc0:59b4 USD   1.87 GiB
[1.801349]  mmcblk0: p1 p2
[1.868955] mmc1: new high speed MMC card at address 0001
[1.876511] mmcblk1: mmc1:0001 MMC04G 3.60 GiB
[1.882230] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB
[1.890172] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB
[1.896948] mmcblk1rpmb: mmc1:0001 MMC04G partition 3 128 KiB
[1.906237]  mmcblk1: p1 p2
[1.925804] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[1.932470] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[1.948789] omap_rtc 44e3e000.rtc: setting system clock to
2017-12-04 18:09:58 UTC (1512410998)
[1.963613] List of all partitions:
[1.967311] 0100   16384 ram0
[1.967322]  (driver?)
[1.973831] 0101   16384 ram1
[1.973840]  (driver?)
[1.980294] 0102   16384 ram2
[1.980303]  (driver?)
[1.986703] 0103   16384 ram3
[1.986711]  (driver?)
[1.993144] 0104   16384 ram4
[

[U-Boot] [PATCH] arc: Fine-tune implementation of memory barriers

[Alexey Brodkin]

We improve on 2 things:
 1. Only ARC HS family has "dmb" instructions so do compile-time
check for automatically defined macro __ARCHS__.
Previous check for ARCv2 ISA was not good enough because ARC EM
family is v2 ISA as well but still "dmb" instaruction is not
supported in EM family.

 2. Still if there's no dedicated instruction for memory barrier
let's at least insert compile-time barrier to make sure
compiler deosn't reorder critical memory operations.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/include/asm/io.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index a12303bc7367..060cdf637bc0 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_ISA_ARCV2
+#ifdef __ARCHS__
 
 /*
  * ARCv2 based HS38 cores are in-order issue, but still weakly ordered
@@ -42,12 +42,12 @@
 #define mb()   asm volatile("sync\n" : : : "memory")
 #endif
 
-#ifdef CONFIG_ISA_ARCV2
+#ifdef __ARCHS__
 #define __iormb()  rmb()
 #define __iowmb()  wmb()
 #else
-#define __iormb()  do { } while (0)
-#define __iowmb()  do { } while (0)
+#define __iormb()  asm volatile("" : : : "memory")
+#define __iowmb()  asm volatile("" : : : "memory")
 #endif
 
 static inline void sync(void)
-- 
2.14.3

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

Re: [U-Boot] [ANN] U-Boot v2018.03-rc3 released

[Alex Kiernan]

On Wed, Feb 21, 2018 at 9:20 AM, Alex Kiernan  wrote:
> On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini  wrote:
>> Hey all,
>>
>> So, we're a day late.  That's because I wanted the MMC PR to come in for
>> some important fixes, and it was too late in my day to then push a
>> release.  I think we probably have a few more fixes that need to come
>> in, but hopefully no more new regressions to be found.  That said, if
>> you have your environment, well, anywhere, a little bit of hardware
>> testing wouldn't hurt.  I think we're still on track for -rc4 on March
>> 5th and the release on March 12th.  But if we aren't, the release will
>> get delayed.
>>
>
> Something's broken my board (AM335x, not quite a BBB):
>
> MMC:   mmc@481d8000 - probe failed: -1
>
> Looks to be this commit:
>
> 2d7482cf793fe4d8a98906002708d6e1fa2c5ba3
>
> Still looking, but I'd guess I'm now missing something from my DTB
> which I didn't need previously.
>

mmc_of_parse says:

/* f_max is obtained from the optional "max-frequency" property */
dev_read_u32(dev, "max-frequency", >f_max);

I don't have a max-frequency (pretty much all my config comes direct
from am33xx.dtsi), so if I add a max-frequency to my tree I get a
working board, but the comment above suggests I shouldn't need to, so
do we need something like this added (or a refactor of mmc_of_parse so
it takes a default?)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 02970f2..b87ff01 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1825,6 +1825,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct
udevice *dev)
if (ret < 0)
return ret;

+   if (cfg->f_max == 0)
+   cfg->f_max = 5200;
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
cfg->f_min = 40;
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;

I'm also seeing MMC_MODE_1BIT (which I didn't previously have set)
alongside MMC_MODE_4BIT and MMC_MODE_8BIT (which I previously did),
but I'm guessing that doesn't matter?

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

[U-Boot] [PATCH] Makefile: Don't mess with .text section location for selected arches

[Alexey Brodkin]

Most of architectures have .text section situated in the very beginning
of U-Boot binary and thus it is very logical that CONFIG_SYS_TEXT_BASE
is used on final linkage step to specify where U-Boot gets linked to.

For that we pass the following construction to the LD:
>8---
xxx-ld ...  -Ttext $(CONFIG_SYS_TEXT_BASE) ...
>8---

But there could be exceptions. For example:
 1. In case of ARCv2 we want to put vectors table in its own section
.ivt in front of .text section which means we need either add an
offset to CONFIG_SYS_TEXT_BASE to compensate for .ivt or don't
pass "-Ttext" to the LD at all and specify link base in linker
script directly.

 2. Some architectures even though have .text section in the very
beginning of the U-Boot image still use different symbols to
specify link-base:
   * NIOS2: CONFIG_SYS_MONITOR_BASE (which I really like because
 that exactly what makes sense - where out image starts but not
 beginning of its .text section which just happened to match the
 whole image beginning)
   * EXTENSA: CONFIG_SYS_TEXT_ADDR
   * X86: Which doesn't use CONFIG_SYS_MONITOR_BASE in case of EFI
 otherwise sets explicit link base in u-boot.lds

I think that's good to allow for flexibility and don't require each and
every architecture or even platform to specify CONFIG_SYS_TEXT_BASE as well
as use it to set .text section location.

So let's only pass "-Ttext xxx" for those architectures who don't set
link-base explicitly in their linker scripts.

This patch iaddresses comments for previously sent
https://patchwork.ozlabs.org/patch/867540/.

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Marek Vasut 
Cc: Max Filippov 
Cc: Simon Glass 
Cc: Tom Rini 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index cd265f546677..57cb4b87d930 100644
--- a/Makefile
+++ b/Makefile
@@ -820,7 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
 LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
 
-ifneq ($(CONFIG_SYS_TEXT_BASE),)
+ifeq ($(CONFIG_ARC)$(CONFIG_NIOS2)$(CONFIG_X86)$(CONFIG_XTENSA),)
 LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
 
-- 
2.14.3

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

Re: [U-Boot] [PATCH] usb: dwc2: Reduce data buffer size to 16kB

[Calvin Johnson]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alexey
> Brodkin
> Sent: Wednesday, February 21, 2018 3:18 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Alexey Brodkin
> 
> Subject: [U-Boot] [PATCH] usb: dwc2: Reduce data buffer size to 16kB
> 
> If we use hardware with very small RAM (let's consider just a couple
> of hundreds of kB but not megabytes) it is not super convenient to lose
> 64kB for statically allocated bufer which most probably won't be used
> as big as it is. Typically we'll have much shorter data packages to
> excahnge and in the worst case longer packets will be split on separate

s/ excahnge /exchange

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

[U-Boot] [PATCH] usb: dwc2: Reduce data buffer size to 16kB

[Alexey Brodkin]

If we use hardware with very small RAM (let's consider just a couple
of hundreds of kB but not megabytes) it is not super convenient to lose
64kB for statically allocated bufer which most probably won't be used
as big as it is. Typically we'll have much shorter data packages to
excahnge and in the worst case longer packets will be split on separate
transactions.

Signed-off-by: Alexey Brodkin 
Cc: Marek Vasut 
---
 drivers/usb/host/dwc2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 0efe645044c5..20cd4a6d3d55 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define DWC2_HC_CHANNEL0
 
 #define DWC2_STATUS_BUF_SIZE   64
-#define DWC2_DATA_BUF_SIZE (64 * 1024)
+#define DWC2_DATA_BUF_SIZE (16 * 1024)
 
 #define MAX_DEVICE 16
 #define MAX_ENDPOINT   16
-- 
2.14.3

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

Re: [U-Boot] [PATCH 2/2] arm: socfpga: cyclone5: Ensure spi-flash in the compatible string

[Simon Goldschmidt]

On 21.02.2018 08:40, chin.liang@intel.com wrote:

From: Chin Liang See 

Ensure "spi-flash" is added into compatible string when there is
NOR flash being instantiated in DTS. Discovered "sf probe" command
without argument would hit error if spi-flash compatible string
is missing.


This has already been fixed 5 days ago.

Simon



Signed-off-by: Chin Liang See 
---
  arch/arm/dts/socfpga_cyclone5_is1.dts  | 2 +-
  arch/arm/dts/socfpga_cyclone5_socdk.dts| 2 +-
  arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
index 2e2b71f..549024c 100644
--- a/arch/arm/dts/socfpga_cyclone5_is1.dts
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -87,7 +87,7 @@
u-boot,dm-pre-reloc;
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "n25q00";
+   compatible = "n25q00","spi-flash";
reg = <0>;  /* chip select */
spi-max-frequency = <1>;
m25p,fast-read;
diff --git a/arch/arm/dts/socfpga_cyclone5_socdk.dts 
b/arch/arm/dts/socfpga_cyclone5_socdk.dts
index 95a8e65..e30bf9a 100644
--- a/arch/arm/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/dts/socfpga_cyclone5_socdk.dts
@@ -98,7 +98,7 @@
u-boot,dm-pre-reloc;
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "n25q00";
+   compatible = "n25q00","spi-flash";
reg = <0>;  /* chip select */
spi-max-frequency = <1>;
m25p,fast-read;
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts 
b/arch/arm/dts/socfpga_cyclone5_socrates.dts
index e3ae8a8..3e78038 100644
--- a/arch/arm/dts/socfpga_cyclone5_socrates.dts
+++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts
@@ -68,7 +68,7 @@
flash0: n25q00@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "n25q00";
+   compatible = "n25q00","spi-flash";
reg = <0>;  /* chip select */
spi-max-frequency = <5000>;
m25p,fast-read;


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

Re: [U-Boot] [ANN] U-Boot v2018.03-rc3 released

[Alex Kiernan]

On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini  wrote:
> Hey all,
>
> So, we're a day late.  That's because I wanted the MMC PR to come in for
> some important fixes, and it was too late in my day to then push a
> release.  I think we probably have a few more fixes that need to come
> in, but hopefully no more new regressions to be found.  That said, if
> you have your environment, well, anywhere, a little bit of hardware
> testing wouldn't hurt.  I think we're still on track for -rc4 on March
> 5th and the release on March 12th.  But if we aren't, the release will
> get delayed.
>

Something's broken my board (AM335x, not quite a BBB):

MMC:   mmc@481d8000 - probe failed: -1

Looks to be this commit:

2d7482cf793fe4d8a98906002708d6e1fa2c5ba3

Still looking, but I'd guess I'm now missing something from my DTB
which I didn't need previously.

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

Re: [U-Boot] [PATCH] mmc: fix off-by-one bug in mmc_startup_v4()

[Jaehoon Chung]

Hi Alexander,

On 02/21/2018 05:44 PM, Alexander Kochetkov wrote:
> 
>> Do you mean SD-card or MMC-card? :)
>> SD doesn't have EXT_CSD register.
> 
> I see now. MMC-card. So, send v2? or you can simple fix SD with MMC in commit 
> msg.

If you're ok, i will apply yours after changing commit-msg.

Best Regards,
Jaehoon Chung

> 
>>
>> - Removed Pantelis's mail account. Instead, add my account, plz.
> 
> I took it from here:
> https://www.denx.de/wiki/U-Boot/Custodians
> 
> Regards,
> Alexander.
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH] mmc: fix off-by-one bug in mmc_startup_v4()

[Alexander Kochetkov]

> Do you mean SD-card or MMC-card? :)
> SD doesn't have EXT_CSD register.

I see now. MMC-card. So, send v2? or you can simple fix SD with MMC in commit 
msg.

> 
> - Removed Pantelis's mail account. Instead, add my account, plz.

I took it from here:
https://www.denx.de/wiki/U-Boot/Custodians

Regards,
Alexander.

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

Re: [U-Boot] [PATCH] mmc: fix off-by-one bug in mmc_startup_v4()

[Jaehoon Chung]

Hi,

On 02/21/2018 05:03 PM, Alexander Kochetkov wrote:
> 
>> 21 февр. 2018 г., в 9:37, Jaehoon Chung  написал(а):
>>
>> I'm confusing about commit-msg. "SD-card with EXT_CSD_REV"?
>>
>> Best Regards,
>> Jaehoon Chung
> 
> I glad to write better, but don’t know. Would this one better?
> 
> In future, SD-cards with revision 9 (with REV value 9 inside EXT_CSD register)

Do you mean SD-card or MMC-card? :)
SD doesn't have EXT_CSD register.

- Removed Pantelis's mail account. Instead, add my account, plz.

Best Regards,
Jaehoon Chung

> will trigger off-by-one bug while accessing mmc_versions array.
> 
> Regards,
> Alexander.
> 
> 

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

Re: [U-Boot] [PATCH] mmc: fix off-by-one bug in mmc_startup_v4()

[Alexander Kochetkov]

> 21 февр. 2018 г., в 9:37, Jaehoon Chung  написал(а):
> 
> I'm confusing about commit-msg. "SD-card with EXT_CSD_REV"?
> 
> Best Regards,
> Jaehoon Chung

I glad to write better, but don’t know. Would this one better?

In future, SD-cards with revision 9 (with REV value 9 inside EXT_CSD register)
will trigger off-by-one bug while accessing mmc_versions array.

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