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

2018-02-20 Thread chin . liang . see
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.

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;
-- 
2.2.2

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


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

2018-02-20 Thread chin . liang . see
From: Chin Liang See 

Enable Macronix flash support for Cyclone5 SoC

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
-- 
2.2.2

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


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

2018-02-20 Thread Masahiro Yamada
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?




> ---
>
>  scripts/config_whitelist.txt | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 43a4ff0..2b07dee 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -154,7 +154,6 @@ CONFIG_BOARD_SIZE_LIMIT
>  CONFIG_BOARD_TAURUS
>  CONFIG_BOARD_TYPES
>  CONFIG_BOOGER
> -CONFIG_BOOM
>  CONFIG_BOOTBLOCK
>  CONFIG_BOOTCOUNT_ALEN
>  CONFIG_BOOTCOUNT_AM33XX
> @@ -387,7 +386,6 @@ CONFIG_DEBUG
>  CONFIG_DEBUG_FS
>  CONFIG_DEBUG_LED
>  CONFIG_DEBUG_LOCK_ALLOC
> -CONFIG_DEBUG_SECTION_MISMATCH
>  CONFIG_DEBUG_SEMIHOSTING
>  CONFIG_DEBUG_UART_LINFLEXUART
>  CONFIG_DEBUG_WRITECOUNT
> @@ -784,7 +782,6 @@ CONFIG_FTPMU010
>  CONFIG_FTPMU010_BASE
>  CONFIG_FTPMU010_POWER
>  CONFIG_FTPWM010_BASE
> -CONFIG_FTRACE_MCOUNT_RECORD
>  CONFIG_FTRTC010_BASE
>  CONFIG_FTRTC010_EXTCLK
>  CONFIG_FTRTC010_PCLK
> @@ -807,8 +804,6 @@ CONFIG_FTWDT010_BASE
>  CONFIG_FTWDT010_WATCHDOG
>  CONFIG_FZOTG266HD0A_BASE
>  CONFIG_GATEWAYIP
> -CONFIG_GCOV_KERNEL
> -CONFIG_GCOV_PROFILE_ALL
>  CONFIG_GICV2
>  CONFIG_GICV3
>  CONFIG_GLOBAL_DATA_NOT_REG10
> @@ -851,7 +846,6 @@ CONFIG_HETROGENOUS_CLUSTERS
>  CONFIG_HIDE_LOGO_VERSION
>  CONFIG_HIGH_BATS
>  CONFIG_HIKEY_GPIO
> -CONFIG_HIS_DRIVER
>  CONFIG_HITACHI_SX14
>  CONFIG_HOSTNAME
>  CONFIG_HOST_MAX_DEVICES
> @@ -1091,7 +1085,6 @@ CONFIG_JFFS2_PART_SIZE
>  CONFIG_JFFS2_SUMMARY
>  CONFIG_JRSTARTR_JR0
>  CONFIG_JTAG_CONSOLE
> -CONFIG_KASAN
>  CONFIG_KCLK_DIS
>  CONFIG_KEEP_SERVERADDR
>  CONFIG_KERNEL_OFFSET
> @@ -1373,7 +1366,6 @@ CONFIG_MMC_SPI_SPEED
>  CONFIG_MMC_SUNXI_SLOT
>  CONFIG_MMC_TRACE
>  CONFIG_MMU
> -CONFIG_MODVERSIONS
>  CONFIG_MONITOR_IS_IN_RAM
>  CONFIG_MP
>  CONFIG_MPC8308
> @@ -1947,7 +1939,6 @@ CONFIG_SHARP_LM8V31
>  CONFIG_SHARP_LQ035Q7DH06
>  CONFIG_SHEEVA_88SV131
>  CONFIG_SHEEVA_88SV331xV5
> -CONFIG_SHELL
>  CONFIG_SHMIN
>  CONFIG_SHOW_ACTIVITY
>  CONFIG_SHOW_BOOT_PROGRESS
> --
> 2.7.4
>
> ___
> 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


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

2018-02-20 Thread Jaehoon Chung
On 02/20/2018 08:35 PM, Alexander Kochetkov wrote:
> SD-card with EXT_CSD_REV value 9 will trigger off-by-one
> bug while accessing mmc_versions array. The patch fix that.

I'm confusing about commit-msg. "SD-card with EXT_CSD_REV"?

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Alexander Kochetkov 
> ---
>  drivers/mmc/mmc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 99e2a75..3aa153a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1974,7 +1974,7 @@ static int mmc_startup_v4(struct mmc *mmc)
>   return -ENOMEM;
>   memcpy(mmc->ext_csd, ext_csd, MMC_MAX_BLOCK_LEN);
>  
> - if (ext_csd[EXT_CSD_REV] > ARRAY_SIZE(mmc_versions))
> + if (ext_csd[EXT_CSD_REV] >= ARRAY_SIZE(mmc_versions))
>   return -EINVAL;
>  
>   mmc->version = mmc_versions[ext_csd[EXT_CSD_REV]];
> 

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


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

2018-02-20 Thread Heinrich Schuchardt
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.
-- 
2.16.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

2018-02-20 Thread Bryan O'Donoghue



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).


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


I leave it to Kever to decide next steps for his patches.

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


[U-Boot] [PATCH] arm64: show_regs: Dump the LRs HW values

2018-02-20 Thread Karl Beldan
These were dropped in [1], after relocation, for their values offset by
reloc_off.
Unconditionally show the HW values and add a '(reloc)' hint for the
offset values showed after relocation.
Also, the LRs' dumps are now formatted the same way the other regs' are.

[1] Commit 082693f4 ("arm64 :show_regs: show the address before relocation")

Signed-off-by: Karl Beldan 
---
 arch/arm/lib/interrupts_64.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
index cbcfeec2b0..8a5d82468b 100644
--- a/arch/arm/lib/interrupts_64.c
+++ b/arch/arm/lib/interrupts_64.c
@@ -30,13 +30,12 @@ void show_regs(struct pt_regs *regs)
 {
int i;
 
-   if (gd->flags & GD_FLG_RELOC) {
-   printf("ELR: %lx\n", regs->elr - gd->reloc_off);
-   printf("LR:  %lx\n", regs->regs[30] - gd->reloc_off);
-   } else {
-   printf("ELR: %lx\n", regs->elr);
-   printf("LR:  %lx\n", regs->regs[30]);
-   }
+   if (gd->flags & GD_FLG_RELOC)
+   printf("elr: %016lx lr : %016lx (reloc)\n",
+  regs->elr - gd->reloc_off,
+  regs->regs[30] - gd->reloc_off);
+   printf("elr: %016lx lr : %016lx\n", regs->elr, regs->regs[30]);
+
for (i = 0; i < 29; i += 2)
printf("x%-2d: %016lx x%-2d: %016lx\n",
   i, regs->regs[i], i+1, regs->regs[i+1]);
-- 
2.16.1.72.g5be1f00

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


Re: [U-Boot] [PATCH v2] Revert "spl: eMMC/SD: Provide one __weak spl_boot_mode() function"

2018-02-20 Thread Fabio Estevam
Hi Tom/Stefano,

On Thu, Feb 15, 2018 at 12:44 PM, Tom Rini  wrote:
> On Thu, Feb 15, 2018 at 03:33:29PM +0100, Lukasz Majewski wrote:
>> Hi Fabio,
>>
>> > This reverts commit d695d6627803dbb78a226e04b0436a01633a9936.
>> >
>> > Commit d695d6627803 ("spl: eMMC/SD: Provide one __weak spl_boot_mode()
>> > function") breaks the boot on several i.MX6 boards,
>> > such as cuboxi and wandboard:
>> >
>> > U-Boot SPL 2018.03-rc1-00212-g48914fc119 (Feb 10 2018 - 11:04:33
>> > +1300) Trying to boot from MMC1
>> > Failed to mount ext2 filesystem...
>> > spl_load_image_ext: ext4fs mount err - 0
>> >
>> > Revert it so that we can boot U-Boot again.
>>
>> This is IMHO throwing the baby with the batch
>
> I kind of feel we need to revert this too, sorry.  I'm also worried that
> we've broken some of the other platforms that also have funky if-else
> expected logic, and we'll be at the point soon where we have enough
> platforms that need to override the spl_boot_mode func with what they
> had before that it's not a huge win.

What is the resolution here? I also sent a partial revert on v3.

Please pick the one you prefer :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2018-02-20 Thread Tom Rini
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.

And on a related note, there has been more feedback on getting going
back to a longer release cycle.  I'm thinking about it and maybe trying
a longer cycle for a few releases to get a feel for everything again.

On a different note, I'm thinking that boards and SoC families, etc,
that have been orphaned for more than a year should probably get
dropped.  I've contacted a few people off-list (which is why we've had a
few pickups of late) for things, but if you know someone that would be
interested in something, please speak up.

Thanks all!

-- 
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] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-20 Thread Tom Rini
On Mon, Feb 12, 2018 at 07:24:31PM +0530, Faiz Abbas wrote:

> When booting from a non-MMC device, the MMC sub-system may not be
> initialized when the environment is first accessed.
> We need to make sure that the MMC sub-system is ready in even a non-MMC
> boot case.
> 
> Therefore, initialize mmc before loading environment from it.
> 
> Signed-off-by: Faiz Abbas 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3] script: Make the get_default_envs.sh script working with newest u-boot

2018-02-20 Thread Tom Rini
On Wed, Feb 14, 2018 at 11:39:48AM +0100, Lukasz Majewski wrote:

> This commit fixes several issues:
> 
> - After moving env related code to ./env directory the env_common.o file
> is no longer present in the system (has been replaced with built-in.o).
> 
> - Use ${OBJCOPY} if available, fallback to system default's objcopy if not
> present.
> 
> - Extend the script to accept different build directory than current one.
> It is extremely handy with OE usage, where source code is separated from
> build.
> 
> Signed-off-by: Lukasz Majewski 
> Tested-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] ARM: dts: Add support for stm32f746-evaluation board support

2018-02-20 Thread Vikas MANOCHA
Hi,

<-Original Message-
; u-boot@lists.denx.de; 
albert.u.b...@aribaud.net; s...@chromium.org
; Christophe KERELLO 
; Christophe PRIOUZEAU
<
 Hi,
<>
<> <-Original Message-
<>s...@chromium.org; Vikas MANOCHA 
<> ; Patrick DELAUNAY
<> ; Christophe KERELLO
<> <; Christophe PRIOUZEAU
<> 
<>  support <
<>  <  <  _ STM32F746NGH6 microcontroller with 1 Mbyte Flash and 320+4 Kbytes
<> RAM <  _ Six 5 V power supply options:
<>       <  _ SAI Audio DAC, stereo audio jack which supports headset with
<> microphone <  _ Stereo digital microphone, audio jack connector used to 
connect
<>  <  _ 2 Gbytes (or more) SDMMC interface microSD card <  _ RF-EEPROM on
<> I2C compatible serial interface <  _ RS-232 communication <  _ IrDA
<> transceiver <  _ JTAG/SWD and ETM trace debug support, ST-LINK/V2-1
<> embedded <  _ IEEE-802.3-2002 compliant Ethernet connector <  _ Camera
<> module <  _ 8Mx32 bit SDRAM, 1Mx16 bit SRAM & 8Mx16 bit Nor Flash <  _
<> 512 Mbits QuadSPI Nor Flash <  _ 5.7 inch 640x480 pixel TFT color LCD
<> with capacitive touch panel <  _ Joystick with 4-direction control and
<> selector <  _ Reset, WakeUp/Tamper or key button <  _ 4 color user
<> LEDs <  _ Extension connectors & memory connectors for daughterboard
<> or
<>  <  _ USB OTG HS and FS with Micro-AB connectors <  _ RTC with backup
<> battery <  _ CAN 2.0A/B compliant connection <  _ Potentiometer <  _
<> Motor control connector <  here :
<>  <
<>  stm32f746-disco, the only difference is to pass "DEVICE_TREE=stm32746g- 

<> Can we just make it "stm32f746-eval" to be consistent with the other device 
tree names.
<> If kernel uses this name, then it needs to be fixed there also.
<

<> <
<> 
<> 
<>
<> Acked-by: Vikas Manocha 
<>
<> Cheers,
<> Vikas
<>
<> <---
<> < arch/arm/dts/Makefile   |   3 +-
<> < arch/arm/dts/stm32746g-eval.dts | 240
<> 
<> < 2 files changed, 242 insertions(+), 1 deletion(-)  create mode
<> 100644 arch/arm/dts/stm32746g-eval.dts <  a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
<> c7695aa1f1dc..a2f6a10ae39d 100644
<> <--- a/arch/arm/dts/Makefile
<> <+++ b/arch/arm/dts/Makefile
<> <@@ -224,7 +224,8 @@ dtb-$(CONFIG_STM32F4) += stm32f429-disco.dtb \
<>  <
<> < dtb-$(CONFIG_STM32F7) += stm32f746-disco.dtb \
<> <-   stm32f769-disco.dtb
<> <+   stm32f769-disco.dtb \
<> <+   stm32746g-eval.dtb
<> < dtb-$(CONFIG_STM32H7) += stm32h743i-disco.dtb \
<>  <
<>  b/arch/arm/dts/stm32746g-eval.dts new file mode 100644 index
<> <..4f6d38acccd7
<> <--- /dev/null
<> <+++ b/arch/arm/dts/stm32746g-eval.dts <@@ -0,0 +1,240 @@
<> <+/*
<> <+ * Copyright 2018 - Christophe Priouzeau
<>  <+ * <+ * Based on:
<> <+ * stm32f746-disco.dts from U-boot 2018.01 <+ * Copyright 2016 - Lee
<> Jones  <+ * <+ * This file is dual-licensed: you
<> can use it either under the terms <+ * of the GPL or the X11 license,
<> at your option. Note that this dual <+ * licensing only applies to
<> this file, and not this project as a <+ * whole.
<> <+ *
<> <+ *  a) This file is free software; you can redistribute it and/or
<> <+ * modify it under the terms of the GNU General Public License as
<> <+ * published by the Free Software Foundation; either version 2 of the
<> <+ * License, or (at your option) any later version.
<> <+ *
<> <+ * This file is distributed in the hope that it will be useful,
<> <+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
<> <+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
<> <+ * GNU General Public License for more details.
<> <+ *
<> <+ * Or, alternatively,
<> <+ *
<> <+ *  b) Permission is hereby granted, free of charge, to any person
<> <+ * obtaining a copy of this software and associated documentation
<> <+ * files (the "Software"), to deal in the Software without
<> <+ * restriction, including without limitation the rights to use,
<> <+ * copy, modify, merge, publish, distribute, sublicense, and/or
<> <+ * sell copies of the Software, and to permit persons to whom the
<> <+ * Software is furnished to do so, subject to the following
<> <+ * conditions:
<> <+ *
<> <+ * The above copyright notice and this permission notice shall be
<> <+ * included in all copies or substantial portions of the Software.
<> <+ *
<> <+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
<> <+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
<> <+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
<> <+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
<> <+ * HOLDERS BE LIA

[U-Boot] [PATCH 2/2] test/py: highlight warnings in the log summary

2018-02-20 Thread Stephen Warren
From: Stephen Warren 

Currently, if a test emits a warning message but otherwise passes, there's
no indication of this in the log summary, which can lead to warnings being
missed. Enhance the test logic to explicitly mention warnings in otherwise
passing tests, and not to collapse the log sections for tests with
warnings, so that they're more easily seen when scanning the log.

Signed-off-by: Stephen Warren 
---
 test/py/conftest.py | 19 ---
 test/py/multiplexed_log.css |  4 
 test/py/multiplexed_log.py  | 30 ++
 3 files changed, 50 insertions(+), 3 deletions(-)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 3fe91e874606..83eaca46a908 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -344,6 +344,7 @@ tests_failed = []
 tests_xpassed = []
 tests_xfailed = []
 tests_skipped = []
+tests_warning = []
 tests_passed = []
 
 def pytest_itemcollected(item):
@@ -380,6 +381,11 @@ def cleanup():
 if log:
 with log.section('Status Report', 'status_report'):
 log.status_pass('%d passed' % len(tests_passed))
+if tests_warning:
+log.status_warning('%d passed with warning' % 
len(tests_warning))
+for test in tests_warning:
+anchor = anchors.get(test, None)
+log.status_warning('... ' + test, anchor)
 if tests_skipped:
 log.status_skipped('%d skipped' % len(tests_skipped))
 for test in tests_skipped:
@@ -520,7 +526,9 @@ def pytest_runtest_protocol(item, nextitem):
 A list of pytest reports (test result data).
 """
 
+log.get_and_reset_warning()
 reports = runtestprotocol(item, nextitem=nextitem)
+was_warning = log.get_and_reset_warning()
 
 # In pytest 3, runtestprotocol() may not call pytest_runtest_setup() if
 # the test is skipped. That call is required to create the test's section
@@ -531,9 +539,14 @@ def pytest_runtest_protocol(item, nextitem):
 start_test_section(item)
 
 failure_cleanup = False
-test_list = tests_passed
-msg = 'OK'
-msg_log = log.status_pass
+if not was_warning:
+test_list = tests_passed
+msg = 'OK'
+msg_log = log.status_pass
+else:
+test_list = tests_warning
+msg = 'OK (with warning)'
+msg_log = log.status_warning
 for report in reports:
 if report.outcome == 'failed':
 if hasattr(report, 'wasxfail'):
diff --git a/test/py/multiplexed_log.css b/test/py/multiplexed_log.css
index 9b7c44fe4de0..562f69f3b6f7 100644
--- a/test/py/multiplexed_log.css
+++ b/test/py/multiplexed_log.css
@@ -70,6 +70,10 @@ pre {
 color: #00ff00
 }
 
+.status-warning {
+color: #00
+}
+
 .status-skipped {
 color: #00
 }
diff --git a/test/py/multiplexed_log.py b/test/py/multiplexed_log.py
index 8ca515319ce9..a2cfd7174619 100644
--- a/test/py/multiplexed_log.py
+++ b/test/py/multiplexed_log.py
@@ -224,6 +224,7 @@ class Logfile(object):
 self.timestamp_start = self._get_time()
 self.timestamp_prev = self.timestamp_start
 self.timestamp_blocks = []
+self.seen_warning = False
 
 shutil.copy(mod_dir + '/multiplexed_log.css', os.path.dirname(fn))
 self.f.write('''\
@@ -252,6 +253,7 @@ $(document).ready(function () {
 passed_bcs = passed_bcs.not(":has(.status-xfail)");
 passed_bcs = passed_bcs.not(":has(.status-xpass)");
 passed_bcs = passed_bcs.not(":has(.status-skipped)");
+passed_bcs = passed_bcs.not(":has(.status-warning)");
 // Hide the passed blocks
 passed_bcs.addClass("hidden");
 // Flip the expand/contract button hiding for those blocks.
@@ -478,8 +480,23 @@ $(document).ready(function () {
 Nothing.
 """
 
+self.seen_warning = True
 self._note("warning", msg)
 
+def get_and_reset_warning(self):
+"""Get and reset the log warning flag.
+
+Args:
+None
+
+Returns:
+Whether a warning was seen since the last call.
+"""
+
+ret = self.seen_warning
+self.seen_warning = False
+return ret
+
 def info(self, msg):
 """Write an informational note to the log file.
 
@@ -542,6 +559,19 @@ $(document).ready(function () {
 
 self._note("status-pass", msg, anchor)
 
+def status_warning(self, msg, anchor=None):
+"""Write a note to the log file describing test(s) which passed.
+
+Args:
+msg: A message describing the passed test(s).
+anchor: Optional internal link target.
+
+Returns:
+Nothing.
+"""
+
+self._note("status-warning", msg, anchor)
+
 def status_skipped(self, msg, anchor=None):
 """Write a note to the log file describing skipped test(s).
 
-- 
2.16.1

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

[U-Boot] [PATCH 1/2] test/py: add MMC/SD block read test

2018-02-20 Thread Stephen Warren
From: Stephen Warren 

Add a standalone MMC block read test. This allows direct testing of MMC
access rather than relying on doing so as a side-effect of e.g. DFU or
UMS testing, which may not be enabled on all platforms.

Signed-off-by: Stephen Warren 
---
 test/py/tests/test_mmc_rd.py | 129 +++
 1 file changed, 129 insertions(+)
 create mode 100644 test/py/tests/test_mmc_rd.py

diff --git a/test/py/tests/test_mmc_rd.py b/test/py/tests/test_mmc_rd.py
new file mode 100644
index ..7ff76228e2e9
--- /dev/null
+++ b/test/py/tests/test_mmc_rd.py
@@ -0,0 +1,129 @@
+# Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+#
+# SPDX-License-Identifier: GPL-2.0
+
+# Test U-Boot's "mmc read" command. The test reads data from the eMMC or SD
+# card, and validates the no errors occurred, and that the expected data was
+# read if the test configuration contains a CRC of the expected data.
+
+import pytest
+import u_boot_utils
+
+"""
+This test relies on boardenv_* to containing configuration values to define
+which MMC devices should be tested. For example:
+
+env__mmc_rd_configs = (
+{
+"fixture_id": "emmc-boot0",
+"is_emmc": True,
+"devid": 0,
+"partid": 1,
+"sector": 0x10,
+"count": 1,
+},
+{
+"fixture_id": "emmc-boot1",
+"is_emmc": True,
+"devid": 0,
+"partid": 2,
+"sector": 0x10,
+"count": 1,
+},
+{
+"fixture_id": "emmc-data",
+"is_emmc": True,
+"devid": 0,
+"partid": 0,
+"sector": 0x10,
+"count": 0x1000,
+},
+{
+"fixture_id": "sd-mbr",
+"is_emmc": False,
+"devid": 1,
+"partid": None,
+"sector": 0,
+"count": 1,
+"crc32": "8f6ecf0d",
+},
+{
+"fixture_id": "sd-large",
+"is_emmc": False,
+"devid": 1,
+"partid": None,
+"sector": 0x10,
+"count": 0x1000,
+},
+)
+"""
+
+@pytest.mark.buildconfigspec('cmd_mmc')
+def test_mmc_rd(u_boot_console, env__mmc_rd_config):
+"""Test the "mmc read" command.
+
+Args:
+u_boot_console: A U-Boot console connection.
+env__mmc_rd_config: The single MMC configuration on which
+to run the test. See the file-level comment above for details
+of the format.
+
+Returns:
+Nothing.
+"""
+
+is_emmc = env__mmc_rd_config['is_emmc']
+devid = env__mmc_rd_config['devid']
+partid = env__mmc_rd_config.get('partid', 0)
+sector = env__mmc_rd_config.get('sector', 0)
+count_sectors = env__mmc_rd_config.get('count', 1)
+expected_crc32 = env__mmc_rd_config.get('crc32', None)
+
+count_bytes = count_sectors * 512
+bcfg = u_boot_console.config.buildconfig
+has_cmd_memory = bcfg.get('config_cmd_memory', 'n') == 'y'
+has_cmd_crc32 = bcfg.get('config_cmd_crc32', 'n') == 'y'
+ram_base = u_boot_utils.find_ram_base(u_boot_console)
+addr = '0x%08x' % ram_base
+
+# Select MMC device
+cmd = 'mmc dev %d' % devid
+if is_emmc:
+cmd += ' %d' % partid
+response = u_boot_console.run_command(cmd)
+assert 'no card present' not in response
+if is_emmc:
+partid_response = "(part %d)" % partid
+else:
+partid_response = ""
+good_response = 'mmc%d%s is current device' % (devid, partid_response)
+assert good_response in response
+
+# Clear target RAM
+if expected_crc32:
+if has_cmd_memory and has_cmd_crc32:
+cmd = 'mw.b %s 0 0x%x' % (addr, count_bytes)
+u_boot_console.run_command(cmd)
+
+cmd = 'crc32 %s 0x%x' % (addr, count_bytes)
+response = u_boot_console.run_command(cmd)
+assert expected_crc32 not in response
+else:
+u_boot_console.log.warning(
+'CONFIG_CMD_MEMORY or CONFIG_CMD_CRC32 != y: Skipping RAM 
clear')
+
+# Read data
+cmd = 'mmc read %s %x %x' % (addr, sector, count_sectors)
+response = u_boot_console.run_command(cmd)
+good_response = 'MMC read: dev # %d, block # %d, count %d ... %d blocks 
read: OK' % (
+devid, sector, count_sectors, count_sectors)
+assert good_response in response
+
+# Check target RAM
+if expected_crc32:
+if has_cmd_crc32:
+cmd = 'crc32 %s 0x%x' % (addr, count_bytes)
+response = u_boot_console.run_command(cmd)
+assert expected_crc32 in response
+else:
+u_boot_console.log.warning('CONFIG_CMD_CRC32 != y: Skipping check')
-- 
2.16.1

___
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

2018-02-20 Thread Á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, &dma->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,
+&args);

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.
Ok, I did this some time ago and I used an older version of clk-uclass 
as a starting point.

I will switch to livetree in the next patch version.



+   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, &dev_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, &args);
+   else
+   ret = dma_of_xlate_default(dma, &args);
+   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...

Ok.



+   if (index < 0) {
+   pr_err("fdt_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)
+{
+   str

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

2018-02-20 Thread Á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:

Move dma_ops to a separate header file, following other uclass implementations.

Signed-off-by: Álvaro Fernández Rojas 
---
  drivers/dma/dma-uclass.c |  3 ++-
  include/dma-uclass.h | 38 ++
  include/dma.h| 22 --
  3 files changed, 40 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..e29ad103f2
--- /dev/null
+++ b/include/dma-uclass.h
@@ -0,0 +1,38 @@
+/*
+ * 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 {
+   /*
+* Get the current timer count

Is this the correct purpose for the transfer() method?

This is just a copy&paste, that's what you can find in upstream dma.h ;D
Anyway, I will fix that.

+*
+* @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.

Is this the number of bytes

What does this function actually do? Does it queue a transfer which
completes later? How do I check if it is done?

Please add a lot more docs here.

Same as above.



+* @return: 0 if OK, -ve on error
+*/
+   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


Regards,
Simon

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


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

2018-02-20 Thread Simon Glass
Hi Alvaro,

On 20 February 2018 at 10:46, Álvaro Fernández Rojas  wrote:
> Move dma_ops to a separate header file, following other uclass 
> implementations.
>
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  drivers/dma/dma-uclass.c |  3 ++-
>  include/dma-uclass.h | 38 ++
>  include/dma.h| 22 --
>  3 files changed, 40 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..e29ad103f2
> --- /dev/null
> +++ b/include/dma-uclass.h
> @@ -0,0 +1,38 @@
> +/*
> + * 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 {
> +   /*
> +* Get the current timer count

Is this the correct purpose for the transfer() method?
> +*
> +* @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.

Is this the number of bytes

What does this function actually do? Does it queue a transfer which
completes later? How do I check if it is done?

Please add a lot more docs here.

> +* @return: 0 if OK, -ve on error
> +*/
> +   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
>

Regards,
Simon
___
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

2018-02-20 Thread Simon Glass
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, &dma->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,
> +&args);

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.

> +   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, &dev_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, &args);
> +   else
> +   ret = dma_of_xlate_default(dma, &args);
> +   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) {
> +   pr_err("fdt_stringlist_search() failed: %d\n", index);
> +   return index;
> +   }
> +
> +   return dma_get_by_index(dev, index, dma);
> +}
> +# endif /* OF_CONTROL */
> +
> +int dma_requ

Re: [U-Boot] [PATCH] arc: Introduce a possibility to not relocate U-boot

2018-02-20 Thread Alexey Brodkin
Hi Simon, Tom,

On Sun, 2018-02-04 at 06:40 -0700, Simon Glass wrote:
> On 25 January 2018 at 11:22, Alexey Brodkin  
> wrote:
> > From: Alexey Brodkin 
> > 
> > Disabling relocation might be useful on ARC for 2 reasons:
> >  a) For advanced debugging with Synopsys proprietary MetaWare debugger
> > which is capable of accessing much more specific hardware resources
> > compared to gdb. For example it may show contents of L1 and L2 caches,
> > internal states of some hardware blocks etc.
> > 
> > But on the downside MetaWare debugger still cannot work with PIE.
> > Even though that limitation could be work-arounded with change of ELF's
> > header and stripping down all debug info but with it we won't have
> > debug info for source-level debugging which is quite inconvenient.
> > 
> >  b) Some platforms which might benefit from usage of U-Boot basically
> > don't have enough RAM to accommodate relocation of U-Boot so we
> > keep code in flash and use as much of RAM as possible for more
> > interesting things.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Simon Glass 
> > Cc: Bin Meng 
> > Cc: Heiko Schocher 
> > Cc: York Sun 
> > Cc: Stefan Roese 
> > ---
> >  arch/arc/lib/relocate.c | 6 ++
> >  arch/arc/lib/start.S| 8 +++-
> >  common/board_f.c| 3 ++-
> >  3 files changed, 15 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Simon Glass 

Is it OK if I pull this into my "next" tree?

I'm asking because common/board_f.c is affected even though
that's just an addition of CONFIG_ARC in one #ifdef.

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


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

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&periph_rst BCM6338_RST_DMAMEM>;
};
+
+   enet: ethernet@fffe2800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe2800 0x2dc>;
+   clocks = <&periph_clk BCM6338_CLK_ENET>;
+   resets = <&periph_rst BCM6338_RST_ENET>;
+   dmas = <&iudma BCM6338_DMA_ENET_RX>,
+  <&iudma 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 v2 10/15] bmips: enable f@st1704 enet support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 @@
};
 };
 
+&enet {
+   status = "okay";
+   phy = <&enetphy>;
+   phy-mode = "mii";
+
+   enetphy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio {
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 v2 13/15] bmips: bcm6358: add support for bcm6348-enet

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&periph_clk BCM6358_CLK_ENET0>;
+   dmas = <&iudma BCM6358_DMA_ENET0_RX>,
+  <&iudma 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 = <&periph_clk BCM6358_CLK_ENET1>;
+   dmas = <&iudma BCM6358_DMA_ENET1_RX>,
+  <&iudma 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 v2 15/15] bmips: enable nb4-ser enet support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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";
 };
 
+&enet0 {
+   status = "okay";
+   phy = <&enet0phy>;
+   phy-mode = "internal";
+
+   enet0phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
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 v2 11/15] bmips: bcm6348: add support for bcm6348-enet

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&iudma BCM6348_DMA_ENET0_RX>,
+  <&iudma 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 = <&iudma BCM6348_DMA_ENET1_RX>,
+  <&iudma 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 v2 12/15] bmips: enable ct-5361 enet support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 @@
};
 };
 
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
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 v2 03/15] dma: add bcm6348-iudma support

2018-02-20 Thread Álvaro Fernández Rojas
BCM6348 IUDMA controller is present on multiple BMIPS (BCM63xx) SoCs.

Signed-off-by: Álvaro Fernández Rojas 
---
 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)
+
+/* DMA Channel Max Burst Length register */
+#define DMAC_BURST_REG(x)  (DMA_C

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

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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";
 };
 
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
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 v2 06/15] bmips: bcm6358: add bcm6348-iudma support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&periph_clk BCM6358_CLK_EMUSB>,
+<&periph_clk BCM6358_CLK_USBSU>,
+<&periph_clk BCM6358_CLK_EPHY>;
+   resets = <&periph_rst BCM6358_RST_ENET>,
+<&periph_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 v2 07/15] phy: add support for internal phys

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 v2 05/15] bmips: bcm6348: add bcm6348-iudma support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&periph_clk BCM6348_CLK_ENET>;
+   resets = <&periph_rst BCM6348_RST_ENET>,
+<&periph_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 v2 04/15] bmips: bcm6338: add bcm6348-iudma support

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 = <&periph_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 v2 08/15] net: add support for bcm6348-enet

2018-02-20 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 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 ETH_TXWMARK_WM_MASK(0x3f << ETH_TXWMARK_WM_SHIFT)
+
+/* MIB Control 

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

2018-02-20 Thread Á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 
---
 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, &dma->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,
+&args);
+   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, &dev_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, &args);
+   else
+   ret = dma_of_xlate_default(dma, &args);
+   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);
+   if (index < 0) {
+   pr_err("fdt_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;
+
+   return ops->request(dma);
+}
+
+int dma_free(struct dma *dma)
+{
+   struct dma_ops *ops = dma_dev_ops(dma->dev);
+
+   debug("%s(dma=%p)\n", __func__, dma);
+
+   if (!ops->free)
+   return 0;
+
+   return ops->free(dma);
+}
+
+int dma_enable(struct dma *dma)
+{
+   struct dma_ops *ops = dm

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

2018-02-20 Thread Álvaro Fernández Rojas
Move dma_ops to a separate header file, following other uclass implementations.

Signed-off-by: Álvaro Fernández Rojas 
---
 drivers/dma/dma-uclass.c |  3 ++-
 include/dma-uclass.h | 38 ++
 include/dma.h| 22 --
 3 files changed, 40 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..e29ad103f2
--- /dev/null
+++ b/include/dma-uclass.h
@@ -0,0 +1,38 @@
+/*
+ * 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 {
+   /*
+* 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);
+};
+
+#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 v2 00/15] bmips: add bcm6348-enet support

2018-02-20 Thread Á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.

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  | 180 +++-
 drivers/net/Kconfig   |  10 +
 drivers/net/Makefile  |   1 +
 drivers/net/bcm6348-eth.c | 517 ++
 include/configs/bmips_common.h|   5 +-
 include/dma-uclass.h  | 115 
 include/dma.h | 191 +++--
 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, 1774 insertions(+), 28 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] [PATCH v3 07/21] efi: sandbox: Adjust memory usage for sandbox

2018-02-20 Thread Heinrich Schuchardt

On 02/19/2018 04:48 PM, Simon Glass wrote:

With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.

Also use mapmem instead of a cast to convert a memory address to a
pointer.

Signed-off-by: Simon Glass 
---

Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast

  lib/efi_loader/efi_memory.c | 31 ++-
  1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index c273a7ba30..b113e08783 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -389,7 +390,7 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t 
size, void **buffer)
r = efi_allocate_pages(0, pool_type, num_pages, &t);
  
  	if (r == EFI_SUCCESS) {

-   struct efi_pool_allocation *alloc = (void *)(uintptr_t)t;
+   struct efi_pool_allocation *alloc = map_sysmem(t, size);


The AllocatePages Service has to return 4096 byte aligned memory.
AllocatePool has to return 8 byte aligned memory.

I cannot see that this page makes these guarantees.


alloc->num_pages = num_pages;
*buffer = alloc->data;
}
@@ -500,18 +501,22 @@ int efi_memory_init(void)
  
  	efi_add_known_memory();


You fail guarantee that the known memory is 4096 byte aligned.

  
-	/* Add U-Boot */

-   uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
-   uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
-   efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
-
-   /* Add Runtime Services */
-   runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
-   runtime_end = (ulong)&__efi_runtime_stop;
-   runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
-   runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
-   efi_add_memory_map(runtime_start, runtime_pages,
-  EFI_RUNTIME_SERVICES_CODE, false);
+   if (!IS_ENABLED(CONFIG_SANDBOX)) {


You are passing all memory aquired via mmap() in the above 
efi_add_known_memory() table.


So here you have to mark any memory range as occupied that has already 
been given away or may be allocated by non-EFI functions from the mmap() 
assigned memory.


Best regards

Heinrich


+   /* Add U-Boot */
+   uboot_start = (gd->start_addr_sp - uboot_stack_size) &
+   ~EFI_PAGE_MASK;
+   uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
+   efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA,
+  false);
+
+   /* Add Runtime Services */
+   runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
+   runtime_end = (ulong)&__efi_runtime_stop;
+   runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+   runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
+   efi_add_memory_map(runtime_start, runtime_pages,
+  EFI_RUNTIME_SERVICES_CODE, false);
+   }
  
  #ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER

/* Request a 32bit 64MB bounce buffer region */



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


Re: [U-Boot] [PATCH] net: zynq_gem: Dont run any phy detection logic for GMII case

2018-02-20 Thread Joe Hershberger
On Tue, Feb 20, 2018 at 2:38 AM, Michal Simek  wrote:
> From: Siva Durga Prasad Paladugu 
>
> This patch bypasses phy detection logic for GMII interface
> and just depend on phy address received from DT. This patch
> is required as phy detection logic is different for some phys
> like xilinx phy which can be connected over SGMII and GMII
> interface.
> This fixes the issue of ethernet failures when xilinx phy is
> connected over GMII interface.
>
> Signed-off-by: Siva Durga Prasad Paladugu 
> Signed-off-by: Michal Simek 

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


Re: [U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

2018-02-20 Thread Alexey Brodkin
Hi Simon,

On Sun, 2018-02-04 at 06:40 -0700, Simon Glass wrote:
> Hi Alexey,
> 
> On 25 January 2018 at 10:56, Alexey Brodkin  
> wrote:
> > In case of no relocation we'll just waste some paceat the very end
> 
> space at?

Sure, thanks for pointing out!

> 
> > of usable memory area. If U-Boot is huge and we cannot use a lot of memory 
> > this
> 
> What do you mean by 'U-Boot is huge'? How huge, and why would it be huge?

I was talking about relative sizes of U-Boot compared to available RAM.
Consider we have less than 1 Mb of RAM and U-Boot's size is ~200 kB - in that
case looking 20% of RAM is not what we really want.

In more typical case when we have tens, hundreds or thousands of megabytes of 
RAM
essentially loosing even another megabyte makes not much sense :)


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


[U-Boot] [PATCH] tools/kwbimage: fix LibreSSL build

2018-02-20 Thread Jonathan Gray
Fix build after addition of RSA_get0_key() to LibreSSL.
Patch from Theo Buehler and Stuart Henderson.

Signed-off-by: Theo Buehler 
Signed-off-by: Stuart Henderson 
---
 tools/kwbimage.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ccecf87185..3ca3b3b4a6 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -24,7 +24,8 @@
 #include 
 #include 
 
-#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x207fL)
 static void RSA_get0_key(const RSA *r,
  const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
 {
@@ -36,7 +37,7 @@ static void RSA_get0_key(const RSA *r,
*d = r->d;
 }
 
-#else
+#elif !defined(LIBRESSL_VERSION_NUMBER)
 void EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx)
 {
EVP_MD_CTX_reset(ctx);
-- 
2.16.0

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


Re: [U-Boot] [PATCH] Revert "mx6: ddr: Allow changing REFSEL and REFR fields"

2018-02-20 Thread Stefano Babic
On 20/02/2018 11:08, Maxim Yu. Osipov wrote:
> This reverts commit edf0093732225c2fd0791c3864e9a3eef1f92f19 for
> cm_fx6 iMX.6 Solo module as it causes frequent (around 10 percent of
> power cycles) board's hangs.
> 
> These hangs happen in SPL when BSS is being initialized in SDRAM -
> it appear that variables from BSS contain trash values which lead to board
> hangs. Looks like that SDRAM doesn't yet finish initialization in these
> cases.
> 
> Signed-off-by: Maxim Yu. Osipov 
> ---
>  board/compulab/cm_fx6/spl.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/board/compulab/cm_fx6/spl.c b/board/compulab/cm_fx6/spl.c
> index 56aac60239..16e5bf8dfa 100644
> --- a/board/compulab/cm_fx6/spl.c
> +++ b/board/compulab/cm_fx6/spl.c
> @@ -107,8 +107,6 @@ static struct mx6_ddr_sysinfo cm_fx6_sysinfo_s = {
>   .mif3_mode  = 3,
>   .rst_to_cke = 0x23,
>   .sde_to_rst = 0x10,
> - .refsel = 1,/* Refresh cycles at 32KHz */
> - .refr = 7,  /* 8 refresh commands per refresh cycle */
>  };
>  
>  static struct mx6_ddr3_cfg cm_fx6_ddr3_cfg_s = {
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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


Re: [U-Boot] [GIT PULL ] Please pull u-boot-mmc master

2018-02-20 Thread Tom Rini
On Tue, Feb 20, 2018 at 12:57:28PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could you pull these patches into u-boot/master?
> 
> 
> The following changes since commit 02b0895c215e252cff50d9edf53a972d2bbbfd30:
> 
>   Merge git://git.denx.de/u-boot-sh (2018-02-17 16:06:59 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to 4a41fec589b5f57bc83fca423222c6a1860a50f5:
> 
>   mmc: Fix uninitialised priv member (2018-02-19 17:00:33 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 01/10] mmc: uniphier-sd: Add compatible strings for RCar Gen2

2018-02-20 Thread Marek Vasut
On 02/20/2018 01:54 AM, Jaehoon Chung wrote:
> On 02/20/2018 02:02 AM, Marek Vasut wrote:
>> On 02/19/2018 12:23 PM, Jaehoon Chung wrote:
>>> On 02/01/2018 12:21 AM, Marek Vasut wrote:
 Add DT compatible strings for RCar Gen2 SoCs, so that this driver
 can bind with them. Unlike Gen3, which uses 64bit FIFO, the Gen2
 uses 16bit FIFO.

 Signed-off-by: Marek Vasut 
 Cc: Jaehoon Chung 
 Cc: Masahiro Yamada 
>>>
>>> Applied to u-boot-mmc. Thanks! Sorry for late.
>>> I have checked the previous version..
>>
>> Yes, this is so late that it has to be scheduled for 2018.05 cycle.
>> Another cycle missed, sigh.
> 
> 
> I will revert your patch on master. instead i will apply this patch on next 
> branch.
> Is it ok?

Why would you revert it ? Just drop it from the PR and resend the PR.

And then apply it for -next branch, yes.

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


Re: [U-Boot] [PATCH] mmc: fix eMMC v5.1 incorrect version detection

2018-02-20 Thread Alexander Kochetkov

> 20 февр. 2018 г., в 13:02, Jaehoon Chung  написал(а):
> 
>> Also the patch fix mmc_versions array bounds check. Value 8
>> produced out of array access.
> 
> It was already fixed. 
> 
> http://git.denx.de/?p=u-boot/u-boot-mmc.git;a=commit;h=ace1bed327411cf3cade45599864df2d461045a0
> 
> Best Regards,
> Jaehoon Chung

Thank you for pointing updated git tree.
I sent off-by-one bug fix from the patch as new patch.

Regards,
Alexander.

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


[U-Boot] [PATCH] Revert "mx6: ddr: Allow changing REFSEL and REFR fields"

2018-02-20 Thread Maxim Yu. Osipov
This reverts commit edf0093732225c2fd0791c3864e9a3eef1f92f19 for
cm_fx6 iMX.6 Solo module as it causes frequent (around 10 percent of
power cycles) board's hangs.

These hangs happen in SPL when BSS is being initialized in SDRAM -
it appear that variables from BSS contain trash values which lead to board
hangs. Looks like that SDRAM doesn't yet finish initialization in these
cases.

Signed-off-by: Maxim Yu. Osipov 
---
 board/compulab/cm_fx6/spl.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/board/compulab/cm_fx6/spl.c b/board/compulab/cm_fx6/spl.c
index 56aac60239..16e5bf8dfa 100644
--- a/board/compulab/cm_fx6/spl.c
+++ b/board/compulab/cm_fx6/spl.c
@@ -107,8 +107,6 @@ static struct mx6_ddr_sysinfo cm_fx6_sysinfo_s = {
.mif3_mode  = 3,
.rst_to_cke = 0x23,
.sde_to_rst = 0x10,
-   .refsel = 1,/* Refresh cycles at 32KHz */
-   .refr = 7,  /* 8 refresh commands per refresh cycle */
 };
 
 static struct mx6_ddr3_cfg cm_fx6_ddr3_cfg_s = {
-- 
2.11.0

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


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

2018-02-20 Thread Alexander Kochetkov
SD-card with EXT_CSD_REV value 9 will trigger off-by-one
bug while accessing mmc_versions array. The patch fix that.

Signed-off-by: Alexander Kochetkov 
---
 drivers/mmc/mmc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 99e2a75..3aa153a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1974,7 +1974,7 @@ static int mmc_startup_v4(struct mmc *mmc)
return -ENOMEM;
memcpy(mmc->ext_csd, ext_csd, MMC_MAX_BLOCK_LEN);
 
-   if (ext_csd[EXT_CSD_REV] > ARRAY_SIZE(mmc_versions))
+   if (ext_csd[EXT_CSD_REV] >= ARRAY_SIZE(mmc_versions))
return -EINVAL;
 
mmc->version = mmc_versions[ext_csd[EXT_CSD_REV]];
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH 3/5] imx: hab: Check if CSF is valid before authenticating image

2018-02-20 Thread Fabio Estevam
On Mon, Feb 19, 2018 at 10:19 PM, Breno Lima  wrote:
> From: Utkarsh Gupta 
>
> For proper authentication the HAB code must check if the CSF is valid.
> Users must call the csf_is_valid() function to parse the CSF prior to
> authenticating any additional images. The function will return a failure
> if any of the following invalid conditions are met:
>
> - CSF pointer is NULL
> - CSF Header does not exist
> - CSF does not lie within the image bounds
> - CSF command length zero
>
> Signed-off-by: Utkarsh Gupta 
> Signed-off-by: Breno Lima 

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


Re: [U-Boot] [PATCH 5/5] arm: imx: hab: Define HAB_RVT_BASE according to the processor version

2018-02-20 Thread Fabio Estevam
On Mon, Feb 19, 2018 at 10:19 PM, Breno Lima  wrote:
> From: Breno Lima 
>
> Currently the following devices are using a different definition for ROM
> Vector Table addresses:
>
> - i.MX6DQP =  All rev
> - i.MX6DQ >= rev 1.5
> - i.MX6SDL >= rev 1.2
>
> There is no need to create a new RVT macros since the only update were the
> RVT base address. Remove HAB_RVT_*_NEW macros and define a new RVT base
> address.
>
> More details about RVT base address can be found on processors Reference
> Manual and in the following documents:
>
> EB803: i.MX 6Dual/6Quad Applications Processor Silicon Revision 1.2 to 1.3
> Comparison
>
> EB804: i.MX 6Solo/6DualLite Application Processor Silicon Revision 1.1
> to 1.2/1.3 Comparison
>
> Signed-off-by: Breno Lima 

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


Re: [U-Boot] [PATCH 4/5] imx: hab: Check if CSF contains deprecated commands

2018-02-20 Thread Fabio Estevam
On Mon, Feb 19, 2018 at 10:19 PM, Breno Lima  wrote:
> From: Utkarsh Gupta 
>
> Write, Check and Set MID commands have been deprecated from the Code
> Signing Tool (CST) v2.3.3 and will not be implemented in newer versions
> of HAB, hence the following features are no longer available:
>
> - Write Data
> - Clear Mask
> - Set Mask
> - Check All Clear
> - Check All Set
> - Check Any Clear
> - Check Any Set
> - Set MID
>
> The inappropriate use of Write Data command may lead to an incorrect
> authentication boot flow. Since no specific application has been identified
> that requires the use of any of these features, it is highly recommended to
> add this check.
>
> Signed-off-by: Utkarsh Gupta 
> Signed-off-by: Breno Lima 

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


Re: [U-Boot] [PATCH 2/5] imx: hab: Ensure the IVT DCD pointer is Null prior to calling HAB authenticate function.

2018-02-20 Thread Fabio Estevam
On Mon, Feb 19, 2018 at 10:19 PM, Breno Lima  wrote:
> From: Utkarsh Gupta 
>
> DCD commands should only be present in the initial boot image loaded by
> the SoC ROM. DCD should not be present in images that will be verified
> by software using HAB RVT authentication APIs. Newer versions of HAB
> will generate an error if a DCD pointer is present in an image being
> authenticated by calling the HAB RVT API. Older versions of HAB will
> process and run DCD if it is present, and this could lead to an incorrect
> authentication boot flow.
>
> It is highly recommended this check is in place to ensure additional HAB
> verified images do not include a DCD table.
>
> Signed-off-by: Utkarsh Gupta 
> Signed-off-by: Breno Lima 

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


Re: [U-Boot] [PATCH 1/5] imx: hab: Keep CAAM clock enabled after authenticating additional images

2018-02-20 Thread Fabio Estevam
On Mon, Feb 19, 2018 at 10:19 PM, Breno Lima  wrote:
> From: Breno Lima 
>
> Currently it is not possible to run CMD_DEK on i.MX SPL targets:
>
> => dek_blob 0x1200 0x12001000 128
>
> The system hangs after running dek_blob because the CAAM clock is being
> disabled by the HAB code. There is no need to disable CAAM clock after
> authenticating additional boot images, thus keep CAAM clock enabled to
> address this issue.
>
> Signed-off-by: Breno Lima 

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


Re: [U-Boot] [PATCH] mmc: fix eMMC v5.1 incorrect version detection

2018-02-20 Thread Jaehoon Chung
Hi,

On 02/20/2018 06:29 PM, Alexander Kochetkov wrote:
> eMMC cards v5.1 has value 8 inside EXT_CSD_REV register.
> The patch make EXT_CSD_REV value 8 match v5.1
> 
> The is a hole inside version enumeration. EXT_CSD_REV value 4
> doens't correspond to any valid eMMC version. So EXT_CSD_REV
> value 4 assigned undefined version.
> 
> Also the patch fix mmc_versions array bounds check. Value 8
> produced out of array access.

It was already fixed. 

http://git.denx.de/?p=u-boot/u-boot-mmc.git;a=commit;h=ace1bed327411cf3cade45599864df2d461045a0

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Alexander Kochetkov 
> ---
>  drivers/mmc/mmc.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 255310a..c8c13bd 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1950,6 +1950,7 @@ static int mmc_startup_v4(struct mmc *mmc)
>   MMC_VERSION_4_1,
>   MMC_VERSION_4_2,
>   MMC_VERSION_4_3,
> + MMC_VERSION_UNKNOWN,
>   MMC_VERSION_4_41,
>   MMC_VERSION_4_5,
>   MMC_VERSION_5_0,
> @@ -1973,7 +1974,8 @@ static int mmc_startup_v4(struct mmc *mmc)
>   return -ENOMEM;
>   memcpy(mmc->ext_csd, ext_csd, MMC_MAX_BLOCK_LEN);
>  
> - if (ext_csd[EXT_CSD_REV] > ARRAY_SIZE(mmc_versions))
> + if (ext_csd[EXT_CSD_REV] >= ARRAY_SIZE(mmc_versions) ||
> + ext_csd[EXT_CSD_REV] == 4)
>   return -EINVAL;
>  
>   mmc->version = mmc_versions[ext_csd[EXT_CSD_REV]];
> 

___
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

2018-02-20 Thread Lukasz Majewski
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
> > > 
> > > you wrote:  
> > >>
> > >> Right now U-Boot and SPL logs are cluttered with bogus warnings
> > >> like these (on X15 board, but I'm pretty sure it should appear
> > >> on many others):
> > >>
> > >> Loading Environment from FAT...
> > >> *** Warning - bad CRC, using default environment  
> > >
> > > I donpt want to question the purpose of your patch series in
> > > genral, but:
> > >  
> > 
> > Oh, it's merely a discussion, not a patch series. I probably
> > shouldn't have been added that RFC tag, it's confusing, sorry.
> >   
> > > This is NOT a bogus warning - actually it is something which is
> > > not supposed to happen on any sane system.  If it does on your
> > > board even after first boot and running "env save" at least once,
> > > then you have some problem either in the design or implementation
> > > of your board code.
> > >
> > > So this is a very valid warning which means: FIX ME!
> > >  
> > 
> > AFAIU, that behavior was changed in the mentioned patch (please see
> > my original message). Let me elaborate a bit. In v2018.01 everything
> > works fine and none errors/warnings are present on my boards (AM57x
> > EVM and X15 board). The problem appears after commit fb69464eae1e
> > ("env: Allow to build multiple environments in Kconfig"). Now U-Boot
> > tries to load the environment from SD card first (uEnv.txt file on
> > FAT partition), and then from eMMC partition. In case when SD card
> > is not inserted, I observe mentioned errors. So I'm not sure how to
> > handle this properly, that's why I created this thread... Let me
> > try and explain my concerns better:
> >  1. On the one hand, it's good to check the environment on both SD
> > card and eMMC (that was done in mentioned patch). This case seems to
> > be legit (at least as far as I understand it), i.e. when SD card is
> > not inserted, it's fine, we just check the env on eMMC
> >  2. But on the other hand, errors shouldn't appear in boot log, if
> > it's legit case, it's confusing the user  
> 
> That patch intent was to keep the current behaviour as is for all
> users, so the fact that you now have the FAT environment enabled is an
> unwanted side-effect.

The same situation is on Beagle Bone Black. Even though with OE it is
built to use eMMC for storing its envs, by default it also has envs in
FAT support enabled.

For that reason, u-boot on this board looks for envs in FAT first and
similar message is printed.

IMHO, we now have (unintentionally) the situation where implicitly
reading envs from FAT has the highest priority.

> 
> Maxime
> 




Best regards,

Lukasz Majewski

--

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


pgpLw7GesxTiB.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] mmc: fix eMMC v5.1 incorrect version detection

2018-02-20 Thread Alexander Kochetkov
eMMC cards v5.1 has value 8 inside EXT_CSD_REV register.
The patch make EXT_CSD_REV value 8 match v5.1

The is a hole inside version enumeration. EXT_CSD_REV value 4
doens't correspond to any valid eMMC version. So EXT_CSD_REV
value 4 assigned undefined version.

Also the patch fix mmc_versions array bounds check. Value 8
produced out of array access.

Signed-off-by: Alexander Kochetkov 
---
 drivers/mmc/mmc.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 255310a..c8c13bd 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1950,6 +1950,7 @@ static int mmc_startup_v4(struct mmc *mmc)
MMC_VERSION_4_1,
MMC_VERSION_4_2,
MMC_VERSION_4_3,
+   MMC_VERSION_UNKNOWN,
MMC_VERSION_4_41,
MMC_VERSION_4_5,
MMC_VERSION_5_0,
@@ -1973,7 +1974,8 @@ static int mmc_startup_v4(struct mmc *mmc)
return -ENOMEM;
memcpy(mmc->ext_csd, ext_csd, MMC_MAX_BLOCK_LEN);
 
-   if (ext_csd[EXT_CSD_REV] > ARRAY_SIZE(mmc_versions))
+   if (ext_csd[EXT_CSD_REV] >= ARRAY_SIZE(mmc_versions) ||
+   ext_csd[EXT_CSD_REV] == 4)
return -EINVAL;
 
mmc->version = mmc_versions[ext_csd[EXT_CSD_REV]];
-- 
1.7.9.5

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


[U-Boot] [PATCH v2] net: Remove Xilinx ll_temac driver

2018-02-20 Thread Michal Simek
ll_temac driver was used by Xilinx Microblaze big endian and
Xilinx ppc405/ppc440 SoCs.

ppc support was removed by: "powerpc: remove 4xx support"
(sha1: 98f705c9cefdfdba62c069821bbba10273a0a8ed)
and Microblaze BE is not tested for a long time that's why this driver
can be removed because none is going to updated it to DM anyway.

Signed-off-by: Michal Simek 
Acked-by: Joe Hershberger 
---

Changes in v2:
- fix netdev.h

Travis build in progress
https://travis-ci.org/michalsimek/u-boot/builds/342284080

---
 drivers/net/Makefile   |   2 -
 drivers/net/xilinx_ll_temac.c  | 394 -
 drivers/net/xilinx_ll_temac.h  | 307 -
 drivers/net/xilinx_ll_temac_fifo.c | 139 -
 drivers/net/xilinx_ll_temac_fifo.h | 118 ---
 drivers/net/xilinx_ll_temac_mdio.c | 177 -
 drivers/net/xilinx_ll_temac_mdio.h |  50 -
 drivers/net/xilinx_ll_temac_sdma.c | 307 -
 drivers/net/xilinx_ll_temac_sdma.h | 266 -
 include/netdev.h   |  11 --
 scripts/config_whitelist.txt   |   1 -
 11 files changed, 1772 deletions(-)
 delete mode 100644 drivers/net/xilinx_ll_temac.c
 delete mode 100644 drivers/net/xilinx_ll_temac.h
 delete mode 100644 drivers/net/xilinx_ll_temac_fifo.c
 delete mode 100644 drivers/net/xilinx_ll_temac_fifo.h
 delete mode 100644 drivers/net/xilinx_ll_temac_mdio.c
 delete mode 100644 drivers/net/xilinx_ll_temac_mdio.h
 delete mode 100644 drivers/net/xilinx_ll_temac_sdma.c
 delete mode 100644 drivers/net/xilinx_ll_temac_sdma.h

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ac5443c752c2..4a16c62bac09 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -66,8 +66,6 @@ obj-$(CONFIG_ULI526X) += uli526x.o
 obj-$(CONFIG_VSC7385_ENET) += vsc7385.o
 obj-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o
 obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
-obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \
-   xilinx_ll_temac_fifo.o xilinx_ll_temac_sdma.o
 obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
 obj-$(CONFIG_FSL_MC_ENET) += fsl-mc/
 obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.c
deleted file mode 100644
index 1e7e2e49af9c..
--- a/drivers/net/xilinx_ll_temac.c
+++ /dev/null
@@ -1,394 +0,0 @@
-/*
- * Xilinx xps_ll_temac ethernet driver for u-boot
- *
- * supports SDMA or FIFO access and MDIO bus communication
- *
- * Copyright (C) 2011 - 2012 Stephan Linz 
- * Copyright (C) 2008 - 2011 Michal Simek 
- * Copyright (C) 2008 - 2011 PetaLogix
- *
- * Based on Yoshio Kashiwagi kashiw...@co-nss.co.jp driver
- * Copyright (C) 2008 Nissin Systems Co.,Ltd.
- * March 2008 created
- *
- * SPDX-License-Identifier:GPL-2.0+
- *
- * [0]: http://www.xilinx.com/support/documentation
- *
- * [S]:[0]/ip_documentation/xps_ll_temac.pdf
- * [A]:[0]/application_notes/xapp1041.pdf
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "xilinx_ll_temac.h"
-#include "xilinx_ll_temac_fifo.h"
-#include "xilinx_ll_temac_sdma.h"
-#include "xilinx_ll_temac_mdio.h"
-
-#if !defined(CONFIG_MII)
-# error "LL_TEMAC requires MII -- missing CONFIG_MII"
-#endif
-
-#if !defined(CONFIG_PHYLIB)
-# error "LL_TEMAC requires PHYLIB -- missing CONFIG_PHYLIB"
-#endif
-
-struct ll_temac_info {
-   int flags;
-   unsigned long   base_addr;
-   unsigned long   ctrl_addr;
-   char*devname;
-   unsigned intphyaddr;
-   char*mdio_busname;
-};
-
-/* Ethernet interface ready status */
-int ll_temac_check_status(struct temac_reg *regs, u32 mask)
-{
-   unsigned timeout = 50;  /* 1usec * 50 = 50usec */
-
-   /*
-* Quote from LL TEMAC documentation: The bits in the RDY
-* register are asserted when there is no access in progress.
-* When an access is in progress, a bit corresponding to the
-* type of access is automatically de-asserted. The bit is
-* automatically re-asserted when the access is complete.
-*/
-   while (timeout && (!(in_be32(®s->rdy) & mask))) {
-   timeout--;
-   udelay(1);
-   }
-
-   if (!timeout) {
-   printf("%s: Timeout on 0x%08x @%p\n", __func__,
-   mask, ®s->rdy);
-   return 1;
-   }
-
-   return 0;
-}
-
-/*
- * Indirect write to ll_temac.
- *
- * 
http://www.xilinx.com/support/documentation/ip_documentation/xps_ll_temac.pdf
- * page 23, second paragraph, The use of CTL0 register or CTL1 register
- */
-int ll_temac_indirect_set(struct temac_reg *regs, u16 regn, u32 reg_data)
-{
-   out_be32(®s->lsw, (reg_data & MLSW_MASK));
-   out_be32(®s->ctl, CTL_WEN | (regn & CTL_ADDR_MASK));
-
-   if (ll_temac_check_status(reg

Re: [U-Boot] [U-Boot, 3/6] rockchip: clk: rk322x: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rk322x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, 6/6] rockchip: clk: rk1108: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rv1108.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] rockchip: add text_offset to kernel_addr_r on aarch64 platforms

2018-02-20 Thread Philipp Tomsich
> Booting a aarch64 Linux kernel requires the image to be placed
> text_offset bytes from a 2MB aligned address.
> See https://www.kernel.org/doc/Documentation/arm64/booting.txt
> 
> booti_setup() takes care about this alignment and will relocate the
> image if not properly aligned with memmove(). This can require up
> to double the size of the loaded image and therefore accidentally
> overwrite content placed there (i.e ramdisk_addr_r) for large kernel
> images.
> 
> By adding text_offset to the default kernel_addr_r we can prevent that
> from happening for kernels larger 18MB and also save a few cycles.
> 
> We can assume a text_offset of 0x8 for most cases, all others will be
> handled by booti_setup() anyway.
> 
> Signed-off-by: Klaus Goger 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  include/configs/rk3328_common.h | 2 +-
>  include/configs/rk3399_common.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 2/6] rockchip: clk: rk3188: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rk3188.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, 5/6] rockchip: clk: rk3328: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rk3328.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, 4/6] rockchip: clk: rk3288: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rk3288.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] rockchip: pwm: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> use live dt api to get base addr
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/pwm/rk_pwm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot, 1/6] rockchip: clk: rk3036: convert to use live dt

2018-02-20 Thread Philipp Tomsich
> Use live dt api to get cru base addr.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  drivers/clk/rockchip/clk_rk3036.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


[U-Boot] [PATCH] rockchip: i2c: enable I2C inside GRF for rk3066 and rk3188

2018-02-20 Thread Alexander Kochetkov
In order to make I2C work on rk3066 and rk3188 boards GFR
must be updated.

Signed-off-by: Alexander Kochetkov 
---
 drivers/i2c/rk_i2c.c |   85 +++---
 1 file changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 332280c..3ec5474 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,13 @@ struct rk_i2c {
unsigned int speed;
 };
 
+/**
+ * @grf_offset: offset inside the grf regmap for setting the i2c type
+ */
+struct rk_i2c_soc_data {
+   int grf_offset;
+};
+
 static inline void rk_i2c_get_div(int div, int *divh, int *divl)
 {
*divl = div / 2;
@@ -381,9 +389,37 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice 
*bus)
 static int rockchip_i2c_probe(struct udevice *bus)
 {
struct rk_i2c *priv = dev_get_priv(bus);
+   struct rk_i2c_soc_data *soc_data;
+   uint32_t value;
+   int bus_nr;
+   void *grf;
+   int ret;
 
priv->regs = dev_read_addr_ptr(bus);
 
+   soc_data = (struct rk_i2c_soc_data*)dev_get_driver_data(bus);
+
+   if (soc_data->grf_offset >= 0) {
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   if (IS_ERR(grf)) {
+   ret = PTR_ERR(grf);
+   debug("%s: Could not get syscon for %s: %d\n",
+__func__, bus->name, ret);
+   return ret;
+   }
+
+   ret = dev_read_alias_seq(bus, &bus_nr);
+   if (ret < 0) {
+   debug("%s: Could not get alias for %s: %d\n",
+__func__, bus->name, ret);
+   return ret;
+   }
+
+   /* 27+i: write mask, 11+i: value */
+   value = BIT(27 + bus_nr) | BIT(11 + bus_nr);
+   writel(value, grf + soc_data->grf_offset);
+   }
+
return 0;
 }
 
@@ -392,12 +428,51 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
.set_bus_speed  = rockchip_i2c_set_bus_speed,
 };
 
+static const struct rk_i2c_soc_data rk3066_soc_data = {
+   .grf_offset = 0x154,
+};
+
+static const struct rk_i2c_soc_data rk3188_soc_data = {
+   .grf_offset = 0x0a4,
+};
+
+static const struct rk_i2c_soc_data rk3228_soc_data = {
+   .grf_offset = -1,
+};
+
+static const struct rk_i2c_soc_data rk3288_soc_data = {
+   .grf_offset = -1,
+};
+
+static const struct rk_i2c_soc_data rk3328_soc_data = {
+   .grf_offset = -1,
+};
+
+static const struct rk_i2c_soc_data rk3399_soc_data = {
+   .grf_offset = -1,
+};
+
 static const struct udevice_id rockchip_i2c_ids[] = {
-   { .compatible = "rockchip,rk3066-i2c" },
-   { .compatible = "rockchip,rk3188-i2c" },
-   { .compatible = "rockchip,rk3288-i2c" },
-   { .compatible = "rockchip,rk3328-i2c" },
-   { .compatible = "rockchip,rk3399-i2c" },
+   {
+   .compatible = "rockchip,rk3066-i2c",
+   .data = (ulong)&rk3066_soc_data,
+   },
+   {
+   .compatible = "rockchip,rk3188-i2c",
+   .data = (ulong)&rk3188_soc_data,
+   },
+   {
+   .compatible = "rockchip,rk3288-i2c",
+   .data = (ulong)&rk3288_soc_data,
+   },
+   {
+   .compatible = "rockchip,rk3328-i2c",
+   .data = (ulong)&rk3328_soc_data,
+   },
+   {
+   .compatible = "rockchip,rk3399-i2c",
+   .data = (ulong)&rk3399_soc_data,
+   },
{ }
 };
 
-- 
1.7.9.5

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


[U-Boot] [PATCH] net: zynq_gem: Dont run any phy detection logic for GMII case

2018-02-20 Thread Michal Simek
From: Siva Durga Prasad Paladugu 

This patch bypasses phy detection logic for GMII interface
and just depend on phy address received from DT. This patch
is required as phy detection logic is different for some phys
like xilinx phy which can be connected over SGMII and GMII
interface.
This fixes the issue of ethernet failures when xilinx phy is
connected over GMII interface.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/zynq_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 33245ec36e67..9802144d0c40 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -326,7 +326,8 @@ static int zynq_phy_init(struct udevice *dev)
/* Enable only MDIO bus */
writel(ZYNQ_GEM_NWCTRL_MDEN_MASK, ®s_mdio->nwctrl);
 
-   if (priv->interface != PHY_INTERFACE_MODE_SGMII) {
+   if ((priv->interface != PHY_INTERFACE_MODE_SGMII) &&
+   (priv->interface != PHY_INTERFACE_MODE_GMII)) {
ret = phy_detection(dev);
if (ret) {
printf("GEM PHY init failed\n");
-- 
1.9.1

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


Re: [U-Boot] [RFC 01/14] dma: add dma channels support and improve uclass

2018-02-20 Thread Vignesh R
Please add a commit message as this is a pretty big change providing a
overview what is being added and why?

On Monday 12 February 2018 10:08 PM, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  drivers/dma/dma-uclass.c| 212 ++---


This patch definitely breaks drivers/dma/ti-edma3.c which implements
current definition of dma-uclass.

One of the assumption of current dma_memcpy() implementation is that the
client's DT node need not have "dmas" entry to specify which DMA
provider and DMA channel to use for dma memcpy. (This is true in linux
kernel as well). Most DMA HWs have general purpose channels that are not
tied to any peripherals and can be used for mem to mem transfers.
So, if the client device's DT node does not populate "dmas" property
then dma_memcpy() API should try to find a DMA provider that supports
memcpy operation, request a memcpy capable channel from the provider and
use it to transfer data. Please keep the current behavior as is.
Or, provide a API for clients to request such a channel.

>  drivers/mtd/spi/sf-uclass.c |  17 
>  drivers/mtd/spi/spi_flash.c |  11 ++-
>  include/dma-uclass.h| 110 +
>  include/dma.h   | 226 
> +---
>  include/spi_flash.h |   3 +
>  6 files changed, 485 insertions(+), 94 deletions(-)
>  create mode 100644 include/dma-uclass.h
> 
> diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
> index 3d0ce22fbc..7d04d98493 100644
> --- a/drivers/dma/dma-uclass.c
> +++ b/drivers/dma/dma-uclass.c
> @@ -1,59 +1,176 @@
>  /*
> - * Direct Memory Access U-Class driver
> + * Copyright (C) 2018 Álvaro Fernández Rojas 
> + * Copyright (C) 2015 Texas Instruments Incorporated, 
> + * Written by Mugunthan V N 
>   *
> - * (C) Copyright 2015
> - * Texas Instruments Incorporated, 
> - *
> - * Author: Mugunthan V N 
> - *
> - * SPDX-License-Identifier: GPL-2.0+
> + * SPDX-License-Identifier:  GPL-2.0+
>   */
>  
>  #include 
> -#include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -int dma_get_device(u32 transfer_type, struct udevice **devp)
> +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)
>  {
> - struct udevice *dev;
>   int ret;
>  
> - for (ret = uclass_first_device(UCLASS_DMA, &dev); dev && !ret;
> -  ret = uclass_next_device(&dev)) {
> - struct dma_dev_priv *uc_priv;
> + if (index != 0)
> + return -ENOSYS;
> + ret = uclass_get_device(UCLASS_DMA, 0, &dma->dev);
> + if (ret)
> + return ret;
> + dma->id = cells[0].id;
>  
> - uc_priv = dev_get_uclass_priv(dev);
> - if (uc_priv->supported & transfer_type)
> - break;
> - }
> + 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 (!dev) {
> - pr_err("No DMA device found that supports %x type\n",
> -   transfer_type);
> - return -EPROTONOSUPPORT;
> + if (args->args_count > 1) {
> + pr_err("Invaild args_count: %d\n", args->args_count);
> + return -EINVAL;
>   }
>  
> - *devp = dev;
> + if (args->args_count)
> + dma->id = args->args[0];
> + else
> + dma->id = 0;
>  
> - return ret;
> + return 0;
>  }
>  
> -int dma_memcpy(void *dst, void *src, size_t len)
> +int dma_get_by_index(struct udevice *dev, int index, struct dma *dma)
>  {
> - struct udevice *dev;
> - const struct dma_ops *ops;
>   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);
>  
> - ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev);
> - if (ret < 0)
> + assert(dma);
> + ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev_of_offset(dev),
> +  "dmas", "#dma-cells", 0, index,
> +  &args);
> + 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, &dev_dma);
> + if (ret) {
> + pr_err("%s: uclass_get_device_by_of_offset failed: err=%d\n",
> +   __func__, ret);
> + 

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

2018-02-20 Thread Maxime Ripard
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 
> >  you 
> > wrote:
> >>
> >> Right now U-Boot and SPL logs are cluttered with bogus warnings like
> >> these (on X15 board, but I'm pretty sure it should appear on many
> >> others):
> >>
> >> Loading Environment from FAT...
> >> *** Warning - bad CRC, using default environment
> >
> > I donpt want to question the purpose of your patch series in genral,
> > but:
> >
> 
> Oh, it's merely a discussion, not a patch series. I probably shouldn't
> have been added that RFC tag, it's confusing, sorry.
> 
> > This is NOT a bogus warning - actually it is something which is not
> > supposed to happen on any sane system.  If it does on your board
> > even after first boot and running "env save" at least once, then you
> > have some problem either in the design or implementation of your
> > board code.
> >
> > So this is a very valid warning which means: FIX ME!
> >
> 
> AFAIU, that behavior was changed in the mentioned patch (please see my
> original message). Let me elaborate a bit. In v2018.01 everything
> works fine and none errors/warnings are present on my boards (AM57x
> EVM and X15 board). The problem appears after commit fb69464eae1e
> ("env: Allow to build multiple environments in Kconfig"). Now U-Boot
> tries to load the environment from SD card first (uEnv.txt file on FAT
> partition), and then from eMMC partition. In case when SD card is not
> inserted, I observe mentioned errors. So I'm not sure how to handle
> this properly, that's why I created this thread... Let me try and
> explain my concerns better:
>  1. On the one hand, it's good to check the environment on both SD
> card and eMMC (that was done in mentioned patch). This case seems to
> be legit (at least as far as I understand it), i.e. when SD card is
> not inserted, it's fine, we just check the env on eMMC
>  2. But on the other hand, errors shouldn't appear in boot log, if
> it's legit case, it's confusing the user

That patch intent was to keep the current behaviour as is for all
users, so the fact that you now have the FAT environment enabled is an
unwanted side-effect.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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