Re: [U-Boot] [PATCH 1/5] mmc: sh_sdhi: Fix Kconfig entry

[Nobuhiro Iwamatsu]

Hi!

2017-05-31 11:06 GMT+09:00 Jaehoon Chung :
> On 05/31/2017 07:59 AM, Nobuhiro Iwamatsu wrote:
>> Hi, Jaehoon.
>>
>> Could you pickup this patch series to your mmc repository, and PR to u-boot?
>
> Sure, I will pick this patch series. After that, i will do PR..
> But i have sent the PR about a few days ago..but it doesn't accept yet..
> After accepting it, i will resend PR.

I see. Thanks for your great work!

>
> Thanks!
>
> Best Regards,
> Jaehoon Chung

Best regards,
  Nobuhiro

>
>>
>> Best regards,
>>   Nobuhiro
>>
>>
>> 2017-05-25 22:39 GMT+09:00 Jaehoon Chung :
>>> On 05/13/2017 10:51 PM, Marek Vasut wrote:
 The Kconfig entry depends on RMOBILE, but this was renamed
 to ARCH_RMOBILE in commit 1cc95f6e1b38 (ARM: Rmobile: Rename
 CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE) . Fix this omission.

 Signed-off-by: Marek Vasut 
 Cc: Hiroyuki Yokoyama 
 Cc: Nobuhiro Iwamatsu 
 Cc: Jaehoon Chung 
>>>
>>> Reviewed-by: Jaehoon Chung 
>>>
 ---
  drivers/mmc/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
 index 6ac26dd137..b2d70a37bd 100644
 --- a/drivers/mmc/Kconfig
 +++ b/drivers/mmc/Kconfig
 @@ -159,7 +159,7 @@ config MMC_OMAP36XX_PINS

  config SH_SDHI
   bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
 - depends on RMOBILE
 + depends on ARCH_RMOBILE
   help
 Support for the on-chip SDHI host controller on SuperH/Renesas ARM 
 SoCs platform


>>>
>>
>>
>>
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/11] drivers: usb: dwc3: add ti dwc3 misc driver for wrapper

[Vignesh R]

Hi,

On Wednesday 31 May 2017 09:20 AM, Simon Glass wrote:
> On 23 May 2017 at 05:55, Vignesh R  wrote:
>> From: Mugunthan V N 
>>
>> Add a misc driver for DWC3 wrapper, so that based on dr_mode the
>> USB devices can bind to USB host or USB device drivers.
>>
>> Signed-off-by: Mugunthan V N 
>> Signed-off-by: Vignesh R 
>> ---
>>  board/ti/am57xx/board.c  | 11 --
>>  drivers/usb/dwc3/core.h  |  4 
>>  drivers/usb/dwc3/dwc3-omap.c | 52 
>> 
>>  drivers/usb/dwc3/gadget.c|  2 +-
>>  4 files changed, 57 insertions(+), 12 deletions(-)
> 
> Can you explain why this is a misc driver, and how it will be instantiated?

Based on dr_mode property, the device node needs to bind to either
"host" driver or "peripheral" driver. Therefore, this wrapper is written
for DWC3, which on bind will read dr_mode property and appropriately
associate USB DT node with DWC3 peripheral driver or host driver.

This is similar to what exists today for MUSB[1] and is instantiated by
arch_misc_init() function for am33xx and am43xx

I got these patch from U-Boot list which the author had submitted
previously and got Reviewed-by and did not look deep into it. But looks
like this patch really needs be read along with patch 7/10. I will
re-split and reorder this patch in the next version.


[1]https://www.mail-archive.com/u-boot@lists.denx.de/msg231076.html

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

Re: [U-Boot] [PATCH 05/11] drivers: usb: dwc3: add ti dwc3 misc driver for wrapper

[Vignesh R]

Hi,

On Wednesday 31 May 2017 09:20 AM, Simon Glass wrote:
> On 23 May 2017 at 05:55, Vignesh R  wrote:
>> From: Mugunthan V N 
>>
>> Add a misc driver for DWC3 wrapper, so that based on dr_mode the
>> USB devices can bind to USB host or USB device drivers.
>>
>> Signed-off-by: Mugunthan V N 
>> Signed-off-by: Vignesh R 
>> ---
>>  board/ti/am57xx/board.c  | 11 --
>>  drivers/usb/dwc3/core.h  |  4 
>>  drivers/usb/dwc3/dwc3-omap.c | 52 
>> 
>>  drivers/usb/dwc3/gadget.c|  2 +-
>>  4 files changed, 57 insertions(+), 12 deletions(-)
> 
> Can you explain why this is a misc driver, and how it will be instantiated?

Based on dr_mode property, the device node needs to bind to either
"host" driver or "peripheral" driver. Therefore, this wrapper is written
for DWC3, which on bind will read dr_mode property and appropriately
associate USB DT node with DWC3 peripheral driver or host driver.

This is similar to what exists today for MUSB[1] and is instantiated by
arch_misc_init() function for am33xx and am43xx

I got these patch from U-Boot list which the author had submitted
previosuly and got Reviewed-by and did not look deep into it. But looks
like this patch really needs be read along with patch 7/10. I will
re-split and reorder this patch in the next version.


[1]https://www.mail-archive.com/u-boot@lists.denx.de/msg231076.html

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

Re: [U-Boot] __FILE__ usage and and SPL limits for SRAM

[Masahiro Yamada]

Hi Tom

2017-05-23 10:27 GMT+09:00 Tom Rini :

>> >
>> > 
>> >
>> >> I can do this, but
>> >> I'd like to move forward synced with Linux.
>> >>
>> >>
>> >> Yesterday, I took some time to write patches
>> >> and sent them to Linux ML.
>> >>
>> >>
>> >> Plan A:
>> >> https://lkml.org/lkml/2017/4/21/623
>> >> https://patchwork.kernel.org/patch/9693559/
>> >> https://patchwork.kernel.org/patch/9693563/
>> >>
>> >>
>> >> Plan B:
>> >> https://patchwork.kernel.org/patch/9693623/
>> >
>> > FWIW:
>> >
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
>>
>> Thanks for you pointer!
>>
>> If merged, it will reduce the image size, and also helpful for
>> reproducible build.
>>
>> (We can not save users of old GCC versions, though...)
>
> Did the kernel side of this die out?  Thanks!


It did not.
At least, I got some positive comments,
but I am still wondering what the best approach would be.



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

Re: [U-Boot] [PATCH 04/11] omap5/am57xx/dra7xx: board: do not register usb devices when CONFIG_DM_USB is defined

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> Do not register usb devices when CONFIG_DM_USB is define.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  board/ti/am57xx/board.c   | 2 +-
>  board/ti/dra7xx/evm.c | 2 +-
>  board/ti/omap5_uevm/evm.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

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

Re: [U-Boot] Please pull u-boot-dm (take 2)

[Simon Glass]

Hi Tom,

On 28 May 2017 at 05:55, Tom Rini  wrote:
> On Sat, May 27, 2017 at 04:01:29PM -0600, Simon Glass wrote:
>
>> Hi Tom,
>>
>> This is similar to the last attempt, but without this offending patch
>> which will be replaced by a little series sent today: (I'll pull in
>> that series later)
>>
>> 0a2980b dm: mmc: Avoid probing block devices in find_mmc_device()
>>
>>
>> The following changes since commit 380e86f361e4e2aef83295972863654fde157560:
>>
>>   Merge git://git.denx.de/u-boot-fsl-qoriq (2017-05-26 11:19:27 -0400)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-dm.git
>>
>> for you to fetch changes up to 40fcab41cbcace3ff5928f146dd15c1ee3bfac65:
>>
>>   sandbox: Move to use live tree (2017-05-27 10:38:13 -0600)
>>
>
> Two problems.  First, you need to add this to "dm: gpio: Add live tree
> support":
>
> diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
> b/board/st/stm32f746-disco/stm32f746-disco.c
> index aeaa31146a5a..addf82bbae8c 100644
> --- a/board/st/stm32f746-disco/stm32f746-disco.c
> +++ b/board/st/stm32f746-disco/stm32f746-disco.c
> @@ -101,8 +101,8 @@ int board_late_init(void)
> if (node < 0)
> return -1;
>
> -   gpio_request_by_name_nodev(gd->fdt_blob, node, "led-gpio", 0, ,
> -  GPIOD_IS_OUT);
> +   gpio_request_by_name_nodev(offset_to_ofnode(node), "led-gpio", 0,
> +  , GPIOD_IS_OUT);
>
> if (dm_gpio_is_valid()) {
> dm_gpio_set_value(, 0);
> @@ -115,8 +115,8 @@ int board_late_init(void)
> if (node < 0)
> return -1;
>
> -   gpio_request_by_name_nodev(gd->fdt_blob, node, "button-gpio", 0, 
> ,
> -  GPIOD_IS_IN);
> +   gpio_request_by_name_nodev(offset_to_ofnode(node), "button-gpio", 0,
> +  , GPIOD_IS_IN);
>
> if (dm_gpio_is_valid()) {
> if (dm_gpio_get_value())

OK, added, thanks. For me that board fails to build since it has something like:

for (int i = )

Is that allowed now?

>
> Second, the zynq_zc702 qemu instance is failing (and you need a new
> enough version of qemu, such as the one in .travis.yml, to be able to
> run it.  I need to upgrade my local qemu so I don't have the failure
> bisected atm).

OK I found that it was checking for -FDT_ERR_NOTFOUND which really
should not have been returned by a DM function.

I sent the two updated patches. Given that RC1 is coming out soon I'll
try to do a new pull after testing, but it won't be until the morning.

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

Re: [U-Boot] [PATCH 05/11] drivers: usb: dwc3: add ti dwc3 misc driver for wrapper

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> Add a misc driver for DWC3 wrapper, so that based on dr_mode the
> USB devices can bind to USB host or USB device drivers.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  board/ti/am57xx/board.c  | 11 --
>  drivers/usb/dwc3/core.h  |  4 
>  drivers/usb/dwc3/dwc3-omap.c | 52 
> 
>  drivers/usb/dwc3/gadget.c|  2 +-
>  4 files changed, 57 insertions(+), 12 deletions(-)

Can you explain why this is a misc driver, and how it will be instantiated?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] rockchip: evb-rk3328: update board maintainer

[Simon Glass]

On 23 May 2017 at 01:01, Kever Yang  wrote:
> Update maintainer to Kever Yang for William Zhang is not
> work for this board now.
>
> Signed-off-by: Kever Yang 
> ---
>
>  board/rockchip/evb_rk3328/MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 01/11] drivers: usb: dwc3: remove devm_zalloc from linux_compact

[Simon Glass]

+Masahiro

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> devm_zalloc() is already defined in dm/device.h header, so
> devm_zalloc can be removed from linux_compact.h beader file.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/dwc3/core.c | 7 +--
>  drivers/usb/dwc3/dwc3-omap.c| 3 ++-
>  drivers/usb/dwc3/linux-compat.h | 5 -
>  drivers/usb/dwc3/ti_usb_phy.c   | 1 +
>  4 files changed, 8 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH 08/11] dwc3: Add support for USB device boot

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> Add support to for USB device boot for dwc3 gadget, so that RNDIS can be
> used in SPL to download next stage.
> Provide a way to read MAC address for usb_ether device from board
> function.
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/gadget/ether.c| 9 -
>  drivers/usb/gadget/gadget_chips.h | 2 ++
>  2 files changed, 10 insertions(+), 1 deletion(-)

It looks like there are a few changes in here and it should be split
into 2-3 patches.

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

Re: [U-Boot] [PATCH 03/11] am437x: board: do not register usb devices when CONFIG_DM_USB is defined

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> Do not register usb devices when CONFIG_DM_USB is define.

I suggest s/define/enabled/

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

Re: [U-Boot] [PATCH 02/11] drivers: usb: dwc3-omap: move usb_gadget_handle_interrupts from board files to drivers

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> In board files of am437x, dra7xx, omap5 and am5xx,
> usb_gadget_handle_interrupts() is just a place holder to handle
> dwc3 interrupts, nothing related to board is handled here, so
> move usb_gadget_handle_interrupts() from board files to
> dwc3-omap.c to avoid code duplication based on boards.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  board/ti/am43xx/board.c  | 11 ---
>  board/ti/dra7xx/evm.c| 11 ---
>  board/ti/omap5_uevm/evm.c| 11 ---
>  drivers/usb/dwc3/dwc3-omap.c | 12 
>  4 files changed, 12 insertions(+), 33 deletions(-)
>

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

Re: [U-Boot] [PATCH 06/11] drivers: usb: common: add support to get maximum speed from dt

[Simon Glass]

On 23 May 2017 at 05:55, Vignesh R  wrote:
> From: Mugunthan V N 
>
> Add support to get maximum speed from dt so that usb drivers
> makes use of it for DT parsing.
>
> Signed-off-by: Mugunthan V N 
> Signed-off-by: Vignesh R 
> ---
>  drivers/usb/common/common.c | 29 +
>  include/linux/usb/otg.h |  9 +
>  scripts/Makefile.spl|  1 +
>  3 files changed, 39 insertions(+)

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

Re: [U-Boot] [PATCH 1/1] Kconfig: Add support for hash and sha1sum commands

[Simon Glass]

On 27 May 2017 at 08:59, Tom Rini  wrote:
> From: Daniel Thompson 
>
> Currently these (board agnostic) commands cannot be selected using
> menuconfig and friends. Fix this the obvious way.
>
> Signed-off-by: Daniel Thompson 
> [trini: Re-apply, add imply for a few cases, run moveconfig.py]
> Signed-off-by: Tom Rini 
> ---
>  README  | 11 ---
>  arch/Kconfig|  1 +
>  arch/arm/Kconfig|  1 +
>  arch/arm/mach-exynos/Kconfig|  1 +
>  cmd/Kconfig | 18 ++
>  configs/bcm958622hr_defconfig   |  1 +
>  include/configs/bcm_ep_board.h  |  3 ---
>  include/configs/exynos5-common.h|  3 ---
>  include/configs/imx6qdl_icore.h |  1 -
>  include/configs/imx6qdl_icore_rqs.h |  1 -
>  include/configs/imx6ul_geam.h   |  1 -
>  include/configs/imx6ul_isiot.h  |  1 -
>  include/configs/sandbox.h   |  2 --
>  include/hash.h  |  4 
>  scripts/config_whitelist.txt|  1 -
>  15 files changed, 22 insertions(+), 28 deletions(-)

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

Re: [U-Boot] [PATCH 2/3] MAINTAINERS: rockchip: add board/rockchip as maintained entry

[Simon Glass]

On 23 May 2017 at 01:01, Kever Yang  wrote:
> Directory board/rockchip/ are all boards for Rockchip SoCs,
> so add it to maintained entry.
>
> Signed-off-by: Kever Yang 
> ---
>
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] Fwd: arch/x86/cpu/x86_64/built-in.o: In function `checkcpu': (.text.checkcpu+0x0): multiple definition of `checkcpu' arch/x86/cpu/efi/built-in.o:(.text.checkcpu+0x0): first defined here

[Simon Glass]

Hi Jeroen,

On 23 May 2017 at 01:58, Jeroen Roovers  wrote:
> On 16 May 2017 at 09:26, Bin Meng  wrote:
>>> So I needed to adapt it for a 64-bit target by enabling CONFIG_X86_RUN_64BIT
>>
>> CONFIG_X86_RUN_64BIT is supposed to be turned on a 64-bit U-Boot
>> build, not for EFI application.
>
> Right, so I cannot use u-boot on a 64-bit only UEFI system?

You can - you need to build U-Boot as 32-bit and use the 64-bit stub.
This should be described in the README.x86 but please post if you have
questions.

Once U-Boot 64-bit support is fully complete you'll be able to run
U-Boot in 64-bit if you like. Even when running 32-bit U-Boot does
support natively starting a 64-bit kernel.

Regards,
Simon

>
> Kind regards,
>  jer
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] MAINTAINERS, git-mailrc: update maintainer for Rockchip

[Simon Glass]

On 23 May 2017 at 01:01, Kever Yang  wrote:
>
> Send patch to Kever Yang instead of Lin Huang for Rockchip patches,
> for Lin is not always working on upstream U-Boot.
>
> Signed-off-by: Kever Yang 
> ---
>
>  doc/git-mailrc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] RFC: Alternative command name for 'tftpput'

[Simon Glass]

Hi Joe,

On 30 May 2017 at 13:38, Joe Hershberger  wrote:
> On Mon, May 22, 2017 at 6:55 AM, Stefan Roese  wrote:
>> Hi,
>>
>> I'm stumbling again over a problem introduced with the "tftpput"
>> command and its naming, as it breaks some of the old scripts that
>> I and others still use. As you know, when this command is enabled
>> (which I find quite useful from time to time), "tftp" can't be
>> used any more as an shorthand for "tftpboot".
>>
>> What do others feel about this naming? Would it be acceptable, if
>> I post a patch to rename this "tftpput" command into something
>> else (e.g. netput, ethput, ...)? Or perhaps its possible to add
>> an alias for the "tftpboot" command as "tftp", allowing the
>> usage of all 3 commands:
>>
>> tftpboot:   TFTP get
>> tftp:   TFTP get
>> tftpput:TFTP put
>
> I'd be fine with a tftp command. Ideally we would then get rid of or
> phase out tftpput and instead have a "tftp put" sub-command.
>
> No idea if there are now scripts that use tftpput that we want to
> avoid breaking, or is it new enough / development-focused enough that
> it's unlikely.

I think it is unlikely.

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

[U-Boot] [PATCH v4 31/72] dm: gpio: Add live tree support

[Simon Glass]

Add support for requesting GPIOs with a live device tree.

This involves adjusting the function signature for the legacy function
gpio_request_by_name_nodev(), so fix up all callers.

Signed-off-by: Simon Glass 
Fixes to stm32f746-disco.c:
Signed-off-by: Tom Rini 
---

Changes in v4:
- Update stm32f746-disco.c to support live tree

Changes in v3: None
Changes in v2: None

 board/qualcomm/dragonboard410c/dragonboard410c.c | 12 +++---
 board/samsung/common/board.c |  4 +-
 board/samsung/common/exynos5-dt.c|  2 +-
 board/st/stm32f746-disco/stm32f746-disco.c   |  6 +--
 drivers/gpio/gpio-uclass.c   | 51 +++-
 drivers/i2c/mxc_i2c.c| 12 +++---
 drivers/mmc/fsl_esdhc.c  |  6 +--
 drivers/mmc/s5p_sdhci.c  |  8 ++--
 drivers/mtd/nand/sunxi_nand.c|  2 +-
 drivers/mtd/nand/tegra_nand.c|  4 +-
 drivers/net/pic32_eth.c  |  3 +-
 drivers/sound/max98095.c |  2 +
 drivers/sound/wm8994.c   |  2 +-
 drivers/spi/pic32_spi.c  |  2 +-
 drivers/usb/host/ehci-tegra.c|  7 ++--
 drivers/usb/host/ehci-vf.c   |  5 ++-
 include/asm-generic/gpio.h   | 10 ++---
 17 files changed, 68 insertions(+), 70 deletions(-)

diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c 
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index e923ddc2e2..37d0b85e0e 100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -53,8 +53,8 @@ int board_prepare_usb(enum usb_init_type type)
printf("Failed to find usb_hub_reset_pm dt node.\n");
return node;
}
-   ret = gpio_request_by_name_nodev(gd->fdt_blob, node, "gpios", 0,
-_reset, 0);
+   ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
+"gpios", 0, _reset, 0);
if (ret < 0) {
printf("Failed to request usb_hub_reset_pm gpio.\n");
return ret;
@@ -69,8 +69,8 @@ int board_prepare_usb(enum usb_init_type type)
printf("Failed to find usb_sw_sel_pm dt node.\n");
return 0;
}
-   ret = gpio_request_by_name_nodev(gd->fdt_blob, node, "gpios", 0,
-_sel, 0);
+   ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
+"gpios", 0, _sel, 0);
if (ret < 0) {
printf("Failed to request usb_sw_sel_pm gpio.\n");
return ret;
@@ -121,8 +121,8 @@ int misc_init_r(void)
return 0;
}
 
-   if (gpio_request_by_name_nodev(gd->fdt_blob, node, "gpios", 0, ,
-  0)) {
+   if (gpio_request_by_name_nodev(offset_to_ofnode(node), "gpios", 0,
+  , 0)) {
printf("Failed to request key_vol_down button.\n");
return 0;
}
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 17626966aa..88299f17e3 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -351,8 +351,8 @@ void reset_misc(void)
if (node < 0)
return;
 
-   gpio_request_by_name_nodev(gd->fdt_blob, node, "reset-gpio", 0, ,
-  GPIOD_IS_OUT);
+   gpio_request_by_name_nodev(offset_to_ofnode(node), "reset-gpio", 0,
+  , GPIOD_IS_OUT);
 
if (dm_gpio_is_valid()) {
/*
diff --git a/board/samsung/common/exynos5-dt.c 
b/board/samsung/common/exynos5-dt.c
index aec1f396b0..44f412db5d 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -45,7 +45,7 @@ static void board_enable_audio_codec(void)
if (node <= 0)
return;
 
-   ret = gpio_request_by_name_nodev(gd->fdt_blob, node,
+   ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
 "codec-enable-gpio", 0, _gpio,
 GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
if (ret == -FDT_ERR_NOTFOUND)
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index aeaa31146a..7a6d93cb67 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -101,7 +101,7 @@ int board_late_init(void)
if (node < 0)
return -1;
 
-   

[U-Boot] Please pull u-boot-fdt (take 3)

[Simon Glass]

Hi Tom,

Here it is again!


The following changes since commit 380e86f361e4e2aef83295972863654fde157560:

  Merge git://git.denx.de/u-boot-fsl-qoriq (2017-05-26 11:19:27 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-fdt.git

for you to fetch changes up to 2650c70aff2bbc39b2c4f02d84f1cf0e38993e52:

  fdt: Drop fdt_select.py (2017-05-29 15:18:36 -0600)


Simon Glass (20):
  fdt: Add Python bindings
  pci: Correct cast for sandbox
  fdt: Correct cast for sandbox in fdtdec_setup_memory_size()
  fdt: Use SPDX format for licenses in the libfdt headers
  fdt: Move header files into lib/libfdt
  fdt: Allow swig options to be provided by Makefile
  fdt: Add all source files to the libfdt build
  fdt: Rename existing python libfdt module
  fdt: Build the new python libfdt module
  fdt: Update fdt_test to use 'dt' instead of 'fdt'
  fdt: dtoc: Add a full set of property tests
  fdt: Support use of the new python libfdt library
  fdt: Makefile: Build python libfdt library if needed
  fdt: Stop building the old python libfdt module
  fdt: Drop use of the legacy libfdt python module
  fdt: Drop fdt_fallback library
  binman: Drop a special case related to fdt_fallback
  fdt: Merge fdt_normal with its base class
  binman: Rename fdt variable to dtb
  fdt: Drop fdt_select.py

 Makefile|   16 +-
 cmd/pci.c   |3 +-
 include/fdt.h   |  112 +-
 include/libfdt.h| 2138 +-
 lib/fdtdec.c|3 +-
 lib/libfdt/fdt.h|   67 +
 lib/libfdt/libfdt.h | 2144 +++
 lib/libfdt/libfdt.swig  |  113 --
 lib/libfdt/pylibfdt/libfdt.i|  389 +
 lib/libfdt/pylibfdt/setup.py|  123 ++
 lib/libfdt/setup.py |   38 -
 scripts/Makefile.spl|   17 +-
 tools/Makefile  |   54 +-
 tools/binman/binman.py  |3 +
 tools/binman/control.py |   12 +-
 tools/binman/etype/u_boot_dtb_with_ucode.py |   24 +-
 tools/binman/fdt_test.py|   64 +-
 tools/binman/func_test.py   |   48 +-
 tools/binman/test/45_prop_test.dts  |   23 +
 tools/dtoc/dtoc.py  |3 +-
 tools/dtoc/fdt.py   |  183 ++-
 tools/dtoc/fdt_fallback.py  |  181 ---
 tools/dtoc/fdt_normal.py|  225 ---
 tools/dtoc/fdt_select.py|   36 -
 24 files changed, 3060 insertions(+), 2959 deletions(-)
 create mode 100644 lib/libfdt/fdt.h
 create mode 100644 lib/libfdt/libfdt.h
 delete mode 100644 lib/libfdt/libfdt.swig
 create mode 100644 lib/libfdt/pylibfdt/libfdt.i
 create mode 100755 lib/libfdt/pylibfdt/setup.py
 delete mode 100644 lib/libfdt/setup.py
 create mode 100644 tools/binman/test/45_prop_test.dts
 delete mode 100644 tools/dtoc/fdt_fallback.py
 delete mode 100644 tools/dtoc/fdt_normal.py
 delete mode 100644 tools/dtoc/fdt_select.py

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

Re: [U-Boot] [PATCH 1/4] arm: iproc: add NAND driver

[Chris Packham]

(trying newer address for Steve, sorry for the spam)

> On Sat, Mar 12, 2016 at 9:18 AM, Scott Wood  wrote:
>> On Fri, 2016-03-11 at 12:13 -0800, Steve Rae wrote:
>>> On Fri, Mar 11, 2016 at 11:55 AM, Scott Wood  wrote:
>>> > On Fri, 2016-03-11 at 11:47 -0800, Steve Rae wrote:
>>> > > On Fri, Mar 11, 2016 at 11:29 AM, Scott Wood  wrote:
>>> > > > On Thu, 2016-03-10 at 14:26 -0800, Steve Rae wrote:
>>> > > > > From: Jiandong Zheng 
>>> > > > >
>>> > > > > Add support for the iproc NAND, and enable on Cygnus and NSP boards.
>>> > > > >
>>> > > > > Signed-off-by: Jiandong Zheng 
>>> > > > > Signed-off-by: Steve Rae 
>>> > > > > ---
>>> > > > > There was a previous attempt to implement this "iproc NAND"
>>> > > > > (see: http://patchwork.ozlabs.org/patch/505399), however, due to the
>>> > > > > amount of changes required, it seemed better to implement the code
>>> > > > > in a series of steps. This is the first step, where the
>>> > > > > "iproc_nand.c"
>>> > > > > is essentially an empty file (with one function required to allow
>>> > > > > this
>>> > > > > commit to build successfully).
>>> > > >
>>> > > > I don't see the value of applying a such a do-nothing patch.  It's
>>> > > > fine to
>>> > > > leave out unnecessary features, things that improve performance, etc.
>>> > > > but
>>> > > > to
>>> > > > be applied a patchset should accomplish something useful and correct,
>>> > > > not
>>> > > > just
>>> > > > be a staging area for future patches.
>>> > >
>>> > > I agree -- but with the previous attempt, there where so many things
>>> > > that went wrong, that I cannot comprehend what is needed.
>>> > > So, I wanted to break it down into pieces, so that I could get clear
>>> > > responses to help me get it right.
>>> > > right now, I understand that I need to move certain defines to Kconfig
>>> > > 
>>> >
>>> > Go through the previous comments and address (or respond to) them one by
>>> > one,
>>> > then submit again.  If you want to break it into multiple patches, that's
>>> > fine
>>> > as long as the intermediate states are sane, but it should all be
>>> > submitted at
>>> > once as part of a patchset (again, except for unnecessary features).
>>>
>>> OK - that was my plan (to address every previous comment)...
>>> I was hoping to get "incremental" comments to indicate that I was
>>> resolving them acceptably...
>>> My plan was to increment v2, v3, vxxx until it was acceptable.
>>> Would this be OK?
>>
>> It's OK if you mark them as [RFC PATCH] so it's clear that you don't mean 
>> them
>> to be applied, only commented on -- and include a TODO list so we know what
>> you plan to address before dropping the "RFC".
>>
>> Or just include a code fragment when replying to feedback, with a comment
>> like, "Is this what you're looking for?"
>>
>>> > > > > diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h
>>> > > > > b/arch/arm/include/asm/arch-bcmcygnus/configs.h
>>> > > > > index 3c07160..3bf7395 100644
>>> > > > > --- a/arch/arm/include/asm/arch-bcmcygnus/configs.h
>>> > > > > +++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h
>>> > > > > @@ -10,6 +10,7 @@
>>> > > > >  #include 
>>> > > > >
>>> > > > >  /* uArchitecture specifics */
>>> > > > > +#include <../../../drivers/mtd/nand/iproc_nand_cygnus.h>
>>> > > >
>>> > > > No.
>>> > >
>>> > > this "include" line is unacceptable?
>>> >
>>> > Using "../../.." to reach into a code directory's private headers is
>>> > unacceptable, yes.
>>> >
>>> > > could you propose something that would work?
>>> >
>>> > If you want the info to be in the driver directory, use an ifdef there,
>>> > based
>>> > on a config symbol.  This seems like the better approach.
>>>
>>> Maybe I misinterpreted the comments related to:
>>>
>>> +#if defined(CONFIG_CYGNUS)
>>> +#include "iproc_nand_cygnus.h"
>>> +#elif defined(CONFIG_NS_PLUS)
>>> +#include "iproc_nand_ns_plus.h"
>>> +#else
>>> +#error "Unsupported configuration"
>>> +#endif
>>>
>>> Scott - I thought the you did not like this logic -- now I am thinking
>>> you didn't like the "CONFIG_*" names
>>> I'm guessing that the names should be:
>>> CONFIG_SYS_BCM_CYGNUS
>>> CONFIG_SYS_BCM_NSPLUS
>>> and that they should be added to Kconfig?
>>
>> Correct.
>>
>> -Scott

Hi Steve,

Where did this get to? I find myself in need of a NAND driver for a
BCM58525 and this seems to be relevant.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Question about nfs_read_reply()

[Jaehoon Chung]

Hi Joe,

On 05/31/2017 05:37 AM, Joe Hershberger wrote:
> On Mon, Apr 10, 2017 at 6:24 PM, Joe Hershberger  
> wrote:
>> Hi Jaehoon,
>>
>> On Mon, Apr 10, 2017 at 5:23 AM, Jaehoon Chung  
>> wrote:
>>> Dear Joe,
>>>
>>> I have a question about nfs.
>>> I don't have a knowledge for NFS..So i don't know this is right or not..
>>>
>>> When i have tested the latest u-boot(v2017.03), nfs doesn't work fine with 
>>> Odroid-xu3.
>>
>> How does it fail? Did you print out what the value of "len" is in the
>> case where it was failing? How does it compare to the static size of
>> the struct?

I will share the information when it's failed.

>>
>>> My question is a below thing...In net/nfs.c, nfs_read_reply() function is 
>>> called the memcpy().
>>> it should be copied the sizeof(rpc_pkt.u.reply))...is it really right?
>>
>> It may be copying too much, but I wouldn't expect that to be an issue.
>>
>> If it is not copying enough, then maybe NFS_READ_SIZE is not set
>> appropriately? Or maybe there is an issue with how the server decides
>> what read size to use?

i didn't check in more detail..so i will debug more about what is main problem..

>>
>>> diff --git a/net/nfs.c b/net/nfs.c
>>> index 83ed0a7..09556c7 100644
>>> --- a/net/nfs.c
>>> +++ b/net/nfs.c
>>> @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
>>>
>>> debug("%s\n", __func__);
>>>
>>>memcpy(_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply));
>>>
>>>
>>> When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine.
>>>
>>> Maybe i'm wrong..so i asked this to you...
>>
>> Please do some debugging with the Odroid and report values.

Sure, I will do. 

>>
>> Thanks,
>> -Joe
>>
>>> Best Regards,
>>> Jaehoon Chung
> 
> Not sure that this email ever went out... I've been having trouble
> with sent emails in the last few months. :/
> 
> -Joe
> 
> 
> 

___
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

[Tom Rini]

On Mon, May 29, 2017 at 05:31:50PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could you pull these patches into u-boot/master?
> I have tested the buildman..but if there is a problem, let me know, plz.
> 
> The following changes since commit 380e86f361e4e2aef83295972863654fde157560:
> 
>   Merge git://git.denx.de/u-boot-fsl-qoriq (2017-05-26 11:19:27 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to de59d10cd0a4e79c85e4f791fb8f023164d0890e:
> 
>   doc: document u-boot, mmc-env-offset and u-boot, mmc-env-offset-redund 
> (2017-05-29 17:28:52 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/6] EFI: replace number with UUID_STR_LEN macro

[Tom Rini]

On Mon, May 29, 2017 at 09:49:28AM -0700, ali...@peloton-tech.com wrote:

> From: Alison Chaiken 
> 
> Signed-off-by: Alison Chaiken 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/5] mmc: sh_sdhi: Fix Kconfig entry

[Jaehoon Chung]

On 05/31/2017 07:59 AM, Nobuhiro Iwamatsu wrote:
> Hi, Jaehoon.
> 
> Could you pickup this patch series to your mmc repository, and PR to u-boot?

Sure, I will pick this patch series. After that, i will do PR..
But i have sent the PR about a few days ago..but it doesn't accept yet..
After accepting it, i will resend PR.

Thanks!

Best Regards,
Jaehoon Chung

> 
> Best regards,
>   Nobuhiro
> 
> 
> 2017-05-25 22:39 GMT+09:00 Jaehoon Chung :
>> On 05/13/2017 10:51 PM, Marek Vasut wrote:
>>> The Kconfig entry depends on RMOBILE, but this was renamed
>>> to ARCH_RMOBILE in commit 1cc95f6e1b38 (ARM: Rmobile: Rename
>>> CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE) . Fix this omission.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Hiroyuki Yokoyama 
>>> Cc: Nobuhiro Iwamatsu 
>>> Cc: Jaehoon Chung 
>>
>> Reviewed-by: Jaehoon Chung 
>>
>>> ---
>>>  drivers/mmc/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index 6ac26dd137..b2d70a37bd 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -159,7 +159,7 @@ config MMC_OMAP36XX_PINS
>>>
>>>  config SH_SDHI
>>>   bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
>>> - depends on RMOBILE
>>> + depends on ARCH_RMOBILE
>>>   help
>>> Support for the on-chip SDHI host controller on SuperH/Renesas ARM 
>>> SoCs platform
>>>
>>>
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH 1/4] arm: iproc: add NAND driver

[Chris Packham]

On Sat, Mar 12, 2016 at 9:18 AM, Scott Wood  wrote:
> On Fri, 2016-03-11 at 12:13 -0800, Steve Rae wrote:
>> On Fri, Mar 11, 2016 at 11:55 AM, Scott Wood  wrote:
>> > On Fri, 2016-03-11 at 11:47 -0800, Steve Rae wrote:
>> > > On Fri, Mar 11, 2016 at 11:29 AM, Scott Wood  wrote:
>> > > > On Thu, 2016-03-10 at 14:26 -0800, Steve Rae wrote:
>> > > > > From: Jiandong Zheng 
>> > > > >
>> > > > > Add support for the iproc NAND, and enable on Cygnus and NSP boards.
>> > > > >
>> > > > > Signed-off-by: Jiandong Zheng 
>> > > > > Signed-off-by: Steve Rae 
>> > > > > ---
>> > > > > There was a previous attempt to implement this "iproc NAND"
>> > > > > (see: http://patchwork.ozlabs.org/patch/505399), however, due to the
>> > > > > amount of changes required, it seemed better to implement the code
>> > > > > in a series of steps. This is the first step, where the
>> > > > > "iproc_nand.c"
>> > > > > is essentially an empty file (with one function required to allow
>> > > > > this
>> > > > > commit to build successfully).
>> > > >
>> > > > I don't see the value of applying a such a do-nothing patch.  It's
>> > > > fine to
>> > > > leave out unnecessary features, things that improve performance, etc.
>> > > > but
>> > > > to
>> > > > be applied a patchset should accomplish something useful and correct,
>> > > > not
>> > > > just
>> > > > be a staging area for future patches.
>> > >
>> > > I agree -- but with the previous attempt, there where so many things
>> > > that went wrong, that I cannot comprehend what is needed.
>> > > So, I wanted to break it down into pieces, so that I could get clear
>> > > responses to help me get it right.
>> > > right now, I understand that I need to move certain defines to Kconfig
>> > > 
>> >
>> > Go through the previous comments and address (or respond to) them one by
>> > one,
>> > then submit again.  If you want to break it into multiple patches, that's
>> > fine
>> > as long as the intermediate states are sane, but it should all be
>> > submitted at
>> > once as part of a patchset (again, except for unnecessary features).
>>
>> OK - that was my plan (to address every previous comment)...
>> I was hoping to get "incremental" comments to indicate that I was
>> resolving them acceptably...
>> My plan was to increment v2, v3, vxxx until it was acceptable.
>> Would this be OK?
>
> It's OK if you mark them as [RFC PATCH] so it's clear that you don't mean them
> to be applied, only commented on -- and include a TODO list so we know what
> you plan to address before dropping the "RFC".
>
> Or just include a code fragment when replying to feedback, with a comment
> like, "Is this what you're looking for?"
>
>> > > > > diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h
>> > > > > b/arch/arm/include/asm/arch-bcmcygnus/configs.h
>> > > > > index 3c07160..3bf7395 100644
>> > > > > --- a/arch/arm/include/asm/arch-bcmcygnus/configs.h
>> > > > > +++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h
>> > > > > @@ -10,6 +10,7 @@
>> > > > >  #include 
>> > > > >
>> > > > >  /* uArchitecture specifics */
>> > > > > +#include <../../../drivers/mtd/nand/iproc_nand_cygnus.h>
>> > > >
>> > > > No.
>> > >
>> > > this "include" line is unacceptable?
>> >
>> > Using "../../.." to reach into a code directory's private headers is
>> > unacceptable, yes.
>> >
>> > > could you propose something that would work?
>> >
>> > If you want the info to be in the driver directory, use an ifdef there,
>> > based
>> > on a config symbol.  This seems like the better approach.
>>
>> Maybe I misinterpreted the comments related to:
>>
>> +#if defined(CONFIG_CYGNUS)
>> +#include "iproc_nand_cygnus.h"
>> +#elif defined(CONFIG_NS_PLUS)
>> +#include "iproc_nand_ns_plus.h"
>> +#else
>> +#error "Unsupported configuration"
>> +#endif
>>
>> Scott - I thought the you did not like this logic -- now I am thinking
>> you didn't like the "CONFIG_*" names
>> I'm guessing that the names should be:
>> CONFIG_SYS_BCM_CYGNUS
>> CONFIG_SYS_BCM_NSPLUS
>> and that they should be added to Kconfig?
>
> Correct.
>
> -Scott

Hi Steve,

Where did this get to? I find myself in need of a NAND driver for a
BCM58525 and this seems to be relevant.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] nds32: mmc: Support ftsdc010 DM.

[rick]

Hi Jaehoon

Sorry for the late response because of the vacations.

I have splitted it to 3 parts.

Thanks

Rick

-Original Message-
From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jaehoon Chung
Sent: Thursday, May 25, 2017 10:03 PM
To: Open Source Project uboot; u-boot@lists.denx.de; w...@denx.de; d...@denx.de
Subject: Re: [U-Boot] [PATCH] nds32: mmc: Support ftsdc010 DM.

Hi,

On 05/24/2017 10:47 AM, Andes wrote:
> From: rick 
>
> Support Andestech ftsdc010 SD/MMC device tree flow on AG101P/AE3XX
> platforms.
> Verification : boot linux kernel from sd card

Split the patch...

>
> NDS32 # mmc rescan
> NDS32 # fatls mmc 0:1
> 13938796   boomimage-310y-ag101p.bin
>
> 1 file(s)
>
> NDS32 # fatload mmc 0:1 0x60 boomimage-310y-ag101p.bin reading
> boomimage-310y-ag101p.bin
> 13938796 bytes read in 17358 ms (784.2 KiB/s)
> NDS32 # bootm 0x60
>Image Name:
>Created:  2017-05-23   1:58:24 UTC
>Image Type:   NDS32 Linux Kernel Image (uncompressed)
>Data Size:13938732 Bytes = 13.3 MiB
>Load Address: c000
>Entry Point:  c000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> Linux version 3.10.102-20420-g301b0f6 (rick@app09) (gcc version 4.9.3
> (2016-07-06_nds32le-linux-glibc-v3_experimental) )#798 PREEMPT Tue May
> 23 09:57:59 CST 2017
> CPU: NDS32 N13, AndesCore ID(wb), CPU_VER 0x0d0c003f(id 13, rev 12, cfg 63)
>   ...
>   ...
> Signed-off-by: rick 
> ---
>  arch/nds32/dts/ae3xx.dts|8 ++
>  arch/nds32/dts/ag101p.dts   |8 ++
>  board/AndesTech/adp-ae3xx/adp-ae3xx.c   |4 +-
>  board/AndesTech/adp-ag101p/adp-ag101p.c |7 +-
>  configs/adp-ae3xx_defconfig |5 ++
>  configs/adp-ag101p_defconfig|5 ++
>  drivers/mmc/Kconfig |   12 +++
>  drivers/mmc/Makefile|1 +
>  drivers/mmc/ftsdc010_mci.c  |  140 
> ---
>  drivers/mmc/ftsdc010_mci.h  |   54 
>  drivers/mmc/nds32_mmc.c |  139 ++
>  include/configs/adp-ae3xx.h |1 -
>  include/configs/adp-ag101p.h|1 -
>  13 files changed, 344 insertions(+), 41 deletions(-)  create mode
> 100644 drivers/mmc/ftsdc010_mci.h  create mode 100644
> drivers/mmc/nds32_mmc.c
>
> diff --git a/arch/nds32/dts/ae3xx.dts b/arch/nds32/dts/ae3xx.dts index
> 4221e4b..781eabc 100644
> --- a/arch/nds32/dts/ae3xx.dts
> +++ b/arch/nds32/dts/ae3xx.dts
> @@ -62,6 +62,14 @@
>   interrupts = <25 4>;
>   };
>
> + mmc0: mmc@f0e0 {
> + compatible = "andestech,atsdc010";
> + clock-freq-min-max = <40 1>;
> + fifo-depth = <0x10>;
> + reg = <0xf0e0 0x1000>;
> + interrupts = <17 4>;
> + };
> +
>   nor@0,0 {
>   compatible = "cfi-flash";
>   reg = <0x8800 0x1000>;
> diff --git a/arch/nds32/dts/ag101p.dts b/arch/nds32/dts/ag101p.dts
> index 99cde2f..dd2bf8f 100644
> --- a/arch/nds32/dts/ag101p.dts
> +++ b/arch/nds32/dts/ag101p.dts
> @@ -60,4 +60,12 @@
>   reg = <0x9090 0x1000>;
>   interrupts = <25 4>;
>   };
> +
> + mmc0: mmc@98e0 {
> + compatible = "andestech,atsdc010";
> + clock-freq-min-max = <40 3000>;
> + fifo-depth = <0x10>;
> + reg = <0x98e0 0x1000>;
> + interrupts = <5 4>;
> + };
>  };
> diff --git a/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> index 98ed4d9..3903427 100644
> --- a/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> +++ b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> @@ -77,10 +77,8 @@ ulong board_flash_get_legacy(ulong base, int
> banknum, flash_info_t *info)
>
>  int board_mmc_init(bd_t *bis)
>  {
> -#ifndef CONFIG_DM_MMC
> -#ifdef CONFIG_FTSDC010
> +#if defined(CONFIG_FTSDC010) && !defined(CONFIG_DM_MMC)
>   ftsdc010_mmc_init(0);
>  #endif
> -#endif
>   return 0;
>  }
> diff --git a/board/AndesTech/adp-ag101p/adp-ag101p.c
> b/board/AndesTech/adp-ag101p/adp-ag101p.c
> index a462941..826ba14 100644
> --- a/board/AndesTech/adp-ag101p/adp-ag101p.c
> +++ b/board/AndesTech/adp-ag101p/adp-ag101p.c
> @@ -20,7 +20,6 @@ DECLARE_GLOBAL_DATA_PTR;
>  /*
>   * Miscellaneous platform dependent initializations
>   */
> -
>  int board_init(void)
>  {
>   /*
> @@ -30,7 +29,6 @@ int board_init(void)
>   printf("Board: %s\n" , CONFIG_SYS_BOARD);
>   gd->bd->bi_arch_number = MACH_TYPE_ADPAG101P;
>   gd->bd->bi_boot_params = PHYS_SDRAM_0 + 0x400;
> -
>   return 0;
>  }
>
> @@ -39,11 +37,8 @@ int dram_init(void)
>   unsigned long sdram_base = PHYS_SDRAM_0;
>   unsigned long expected_size = PHYS_SDRAM_0_SIZE + PHYS_SDRAM_1_SIZE;
>   unsigned long actual_size;
> -
>   actual_size = 

[U-Boot] [PATCH 2/3] nds32: dts: Support ftsdc010 DM.

[Andes]

From: rick 

Support Andestech ftsdc010 SD/MMC device tree flow
on AG101P/AE3XX platforms.

Signed-off-by: rick 
---
 arch/nds32/dts/ae3xx.dts  |8 
 arch/nds32/dts/ag101p.dts |8 
 2 files changed, 16 insertions(+)

diff --git a/arch/nds32/dts/ae3xx.dts b/arch/nds32/dts/ae3xx.dts
index 4221e4b..781eabc 100644
--- a/arch/nds32/dts/ae3xx.dts
+++ b/arch/nds32/dts/ae3xx.dts
@@ -62,6 +62,14 @@
interrupts = <25 4>;
};
 
+   mmc0: mmc@f0e0 {
+   compatible = "andestech,atsdc010";
+   clock-freq-min-max = <40 1>;
+   fifo-depth = <0x10>;
+   reg = <0xf0e0 0x1000>;
+   interrupts = <17 4>;
+   };
+
nor@0,0 {
compatible = "cfi-flash";
reg = <0x8800 0x1000>;
diff --git a/arch/nds32/dts/ag101p.dts b/arch/nds32/dts/ag101p.dts
index 99cde2f..dd2bf8f 100644
--- a/arch/nds32/dts/ag101p.dts
+++ b/arch/nds32/dts/ag101p.dts
@@ -60,4 +60,12 @@
reg = <0x9090 0x1000>;
interrupts = <25 4>;
};
+
+   mmc0: mmc@98e0 {
+   compatible = "andestech,atsdc010";
+   clock-freq-min-max = <40 3000>;
+   fifo-depth = <0x10>;
+   reg = <0x98e0 0x1000>;
+   interrupts = <5 4>;
+   };
 };
-- 
1.7.9.5

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

[U-Boot] [PATCH 3/3] nds32: board: Support ftsdc010 DM.

[Andes]

From: rick 

Support Andestech ftsdc010 SD/MMC device tree flow
on AG101P/AE3XX platforms.

Signed-off-by: rick 
---
 board/AndesTech/adp-ae3xx/adp-ae3xx.c   |4 +---
 board/AndesTech/adp-ag101p/adp-ag101p.c |7 +--
 configs/adp-ae3xx_defconfig |5 +
 configs/adp-ag101p_defconfig|5 +
 include/configs/adp-ae3xx.h |1 -
 include/configs/adp-ag101p.h|1 -
 6 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/board/AndesTech/adp-ae3xx/adp-ae3xx.c 
b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
index 98ed4d9..3903427 100644
--- a/board/AndesTech/adp-ae3xx/adp-ae3xx.c
+++ b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
@@ -77,10 +77,8 @@ ulong board_flash_get_legacy(ulong base, int banknum, 
flash_info_t *info)
 
 int board_mmc_init(bd_t *bis)
 {
-#ifndef CONFIG_DM_MMC
-#ifdef CONFIG_FTSDC010
+#if defined(CONFIG_FTSDC010) && !defined(CONFIG_DM_MMC)
ftsdc010_mmc_init(0);
 #endif
-#endif
return 0;
 }
diff --git a/board/AndesTech/adp-ag101p/adp-ag101p.c 
b/board/AndesTech/adp-ag101p/adp-ag101p.c
index a462941..826ba14 100644
--- a/board/AndesTech/adp-ag101p/adp-ag101p.c
+++ b/board/AndesTech/adp-ag101p/adp-ag101p.c
@@ -20,7 +20,6 @@ DECLARE_GLOBAL_DATA_PTR;
 /*
  * Miscellaneous platform dependent initializations
  */
-
 int board_init(void)
 {
/*
@@ -30,7 +29,6 @@ int board_init(void)
printf("Board: %s\n" , CONFIG_SYS_BOARD);
gd->bd->bi_arch_number = MACH_TYPE_ADPAG101P;
gd->bd->bi_boot_params = PHYS_SDRAM_0 + 0x400;
-
return 0;
 }
 
@@ -39,11 +37,8 @@ int dram_init(void)
unsigned long sdram_base = PHYS_SDRAM_0;
unsigned long expected_size = PHYS_SDRAM_0_SIZE + PHYS_SDRAM_1_SIZE;
unsigned long actual_size;
-
actual_size = get_ram_size((void *)sdram_base, expected_size);
-
gd->ram_size = actual_size;
-
if (expected_size != actual_size) {
printf("Warning: Only %lu of %lu MiB SDRAM is working\n",
actual_size >> 20, expected_size >> 20);
@@ -83,7 +78,7 @@ ulong board_flash_get_legacy(ulong base, int banknum, 
flash_info_t *info)
 
 int board_mmc_init(bd_t *bis)
 {
-#ifdef CONFIG_FTSDC010
+#if defined(CONFIG_FTSDC010) && !defined(CONFIG_DM_MMC)
ftsdc010_mmc_init(0);
 #endif
return 0;
diff --git a/configs/adp-ae3xx_defconfig b/configs/adp-ae3xx_defconfig
index cbef412..d12f307 100644
--- a/configs/adp-ae3xx_defconfig
+++ b/configs/adp-ae3xx_defconfig
@@ -18,6 +18,11 @@ CONFIG_BAUDRATE=38400
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
+CONFIG_MMC_NDS32=y
+CONFIG_FTSDC010=y
 CONFIG_MTD=y
 CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
diff --git a/configs/adp-ag101p_defconfig b/configs/adp-ag101p_defconfig
index 22b1182..85e2225 100644
--- a/configs/adp-ag101p_defconfig
+++ b/configs/adp-ag101p_defconfig
@@ -18,6 +18,11 @@ CONFIG_BAUDRATE=38400
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
+CONFIG_MMC_NDS32=y
+CONFIG_FTSDC010=y
 CONFIG_DM_ETH=y
 CONFIG_FTMAC100=y
 CONFIG_DM_SERIAL=y
diff --git a/include/configs/adp-ae3xx.h b/include/configs/adp-ae3xx.h
index 6bfc08e..011b2a8 100644
--- a/include/configs/adp-ae3xx.h
+++ b/include/configs/adp-ae3xx.h
@@ -92,7 +92,6 @@
 /*
  * SD (MMC) controller
  */
-#define CONFIG_FTSDC010
 #define CONFIG_FTSDC010_NUMBER 1
 #define CONFIG_FTSDC010_SDIO
 
diff --git a/include/configs/adp-ag101p.h b/include/configs/adp-ag101p.h
index 4cef64e..71a557b 100644
--- a/include/configs/adp-ag101p.h
+++ b/include/configs/adp-ag101p.h
@@ -98,7 +98,6 @@
 /*
  * SD (MMC) controller
  */
-#define CONFIG_FTSDC010
 #define CONFIG_FTSDC010_NUMBER 1
 #define CONFIG_FTSDC010_SDIO
 
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/3] nds32: mmc: Support ftsdc010 DM.

[Andes]

From: rick 

Support Andestech ftsdc010 SD/MMC device tree flow
on AG101P/AE3XX platforms.

Signed-off-by: rick 
---
 drivers/mmc/Kconfig|   12 
 drivers/mmc/Makefile   |1 +
 drivers/mmc/ftsdc010_mci.c |  140 ++--
 drivers/mmc/ftsdc010_mci.h |   54 +
 drivers/mmc/nds32_mmc.c|  139 +++
 5 files changed, 316 insertions(+), 30 deletions(-)
 create mode 100644 drivers/mmc/ftsdc010_mci.h
 create mode 100644 drivers/mmc/nds32_mmc.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 0dd4443..ca1376a 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -377,6 +377,18 @@ config GENERIC_ATMEL_MCI
  the SD Memory Card Specification V2.0, the SDIO V2.0 specification
  and CE-ATA V1.1.
 
+config MMC_NDS32
+   bool "Andestech SD/MMC controller support"
+   depends on DM_MMC && OF_CONTROL
+   help
+ This enables support for the Andestech SD/MMM controller, which is
+ based on Faraday IP.
+
+config FTSDC010
+   bool "Ftsdc010 SD/MMC controller Support"
+   help
+ This SD/MMC controller is present in Andestech SoCs which is based on 
Faraday IP.
+
 endif
 
 config TEGRA124_MMC_DISABLE_EXT_LOOPBACK
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index a078649..08a552a 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_S3C_SDI) += s3c_sdi.o
 obj-$(CONFIG_MMC_SANDBOX)  += sandbox_mmc.o
 obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
+obj-$(CONFIG_MMC_NDS32) += nds32_mmc.o
 
 # SDHCI
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c
index 652a718..ec0bc6b 100644
--- a/drivers/mmc/ftsdc010_mci.c
+++ b/drivers/mmc/ftsdc010_mci.c
@@ -12,24 +12,15 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
+#include "ftsdc010_mci.h"
 
 #define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 4) /* 250 ms */
 #define CFG_RST_TIMEOUT CONFIG_SYS_HZ /* 1 sec reset timeout */
 
-struct ftsdc010_chip {
-   void __iomem *regs;
-   uint32_t wprot;   /* write protected (locked) */
-   uint32_t rate;/* actual SD clock in Hz */
-   uint32_t sclk;/* FTSDC010 source clock in Hz */
-   uint32_t fifo;/* fifo depth in bytes */
-   uint32_t acmd;
-   struct mmc_config cfg;  /* mmc configuration */
-};
-
 static inline int ftsdc010_send_cmd(struct mmc *mmc, struct mmc_cmd *mmc_cmd)
 {
struct ftsdc010_chip *chip = mmc->priv;
@@ -127,9 +118,8 @@ static void ftsdc010_clkset(struct mmc *mmc, uint32_t rate)
 static int ftsdc010_wait(struct ftsdc010_mmc __iomem *regs, uint32_t mask)
 {
int ret = -ETIMEDOUT;
-   uint32_t st, ts;
-
-   for (ts = get_timer(0); get_timer(ts) < CFG_CMD_TIMEOUT; ) {
+   uint32_t st, timeout = 1000;
+   while (timeout--) {
st = readl(>status);
if (!(st & mask))
continue;
@@ -147,10 +137,16 @@ static int ftsdc010_wait(struct ftsdc010_mmc __iomem 
*regs, uint32_t mask)
 /*
  * u-boot mmc api
  */
-
+#ifdef CONFIG_DM_MMC_OPS
+static int ftsdc010_request(struct udevice *dev, struct mmc_cmd *cmd,
+   struct mmc_data *data)
+{
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
 static int ftsdc010_request(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
 {
+#endif
int ret = -EOPNOTSUPP;
uint32_t len = 0;
struct ftsdc010_chip *chip = mmc->priv;
@@ -251,8 +247,14 @@ static int ftsdc010_request(struct mmc *mmc, struct 
mmc_cmd *cmd,
return ret;
 }
 
+#ifdef CONFIG_DM_MMC_OPS
+static int ftsdc010_set_ios(struct udevice *dev)
+{
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
 static int ftsdc010_set_ios(struct mmc *mmc)
 {
+#endif
struct ftsdc010_chip *chip = mmc->priv;
struct ftsdc010_mmc __iomem *regs = chip->regs;
 
@@ -274,20 +276,46 @@ static int ftsdc010_set_ios(struct mmc *mmc)
return 0;
 }
 
-static int ftsdc010_init(struct mmc *mmc)
+#ifdef CONFIG_DM_MMC_OPS
+static int ftsdc010_get_cd(struct udevice *dev)
 {
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
+static int ftsdc010_getcd(struct mmc *mmc)
+{
+#endif
struct ftsdc010_chip *chip = mmc->priv;
struct ftsdc010_mmc __iomem *regs = chip->regs;
-   uint32_t ts;
-
if (readl(>status) & FTSDC010_STATUS_CARD_DETECT)
-   return -ENOMEDIUM;
+   return 0;
+
+   return 1;
+}
 
+#ifdef CONFIG_DM_MMC_OPS
+static int ftsdc010_get_wp(struct udevice *dev)
+{
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
+static int ftsdc010_getwp(struct mmc *mmc)
+{
+#endif
+   struct ftsdc010_chip *chip = mmc->priv;
+   struct ftsdc010_mmc __iomem *regs = chip->regs;
if (readl(>status) & 

Re: [U-Boot] [PATCH 1/5] mmc: sh_sdhi: Fix Kconfig entry

[Nobuhiro Iwamatsu]

Hi, Jaehoon.

Could you pickup this patch series to your mmc repository, and PR to u-boot?

Best regards,
  Nobuhiro


2017-05-25 22:39 GMT+09:00 Jaehoon Chung :
> On 05/13/2017 10:51 PM, Marek Vasut wrote:
>> The Kconfig entry depends on RMOBILE, but this was renamed
>> to ARCH_RMOBILE in commit 1cc95f6e1b38 (ARM: Rmobile: Rename
>> CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE) . Fix this omission.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Hiroyuki Yokoyama 
>> Cc: Nobuhiro Iwamatsu 
>> Cc: Jaehoon Chung 
>
> Reviewed-by: Jaehoon Chung 
>
>> ---
>>  drivers/mmc/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index 6ac26dd137..b2d70a37bd 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -159,7 +159,7 @@ config MMC_OMAP36XX_PINS
>>
>>  config SH_SDHI
>>   bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
>> - depends on RMOBILE
>> + depends on ARCH_RMOBILE
>>   help
>> Support for the on-chip SDHI host controller on SuperH/Renesas ARM 
>> SoCs platform
>>
>>
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/3] rockchip: mkimage: add support for verify_header/print_header

[Philipp Tomsich]

The rockchip image generation was previously missing the ability to
verify the generated header (and dump the image-type) without having
to resort to hexdump or od. Experience in our testing has showed it
to be very easy to get the rkspi and rksd images mixed up and the
lab... so we add the necessary support to have dumpimage tell us
what image type we're dealing with.

This change set adds the verify_header and print_header capability
to the rksd/rkspi image drivers (through shared code in rkcommon).

As of now, we only support images fully that are not RC4-encoded for
the SPL payload (i.e. header1 and payload). For RC4-encoded payloads,
the outer header (header0) is checked, but no detection of whether
this is a SD/MMC or SPI formatted payload takes place.

The output of dumpsys now prints the image type (spl_hdr), whether it
is a SD/MMC or SPI image, and the (padded) size of the image:
  $ ./tools/dumpimage -l ./spl.img
  Image Type:   Rockchip RK33 (SD/MMC) boot image
   ^^ SD/MMC vs. SPI indication
  spl_hdr indicated by the image
  Data Size:79872 bytes

Signed-off-by: Philipp Tomsich 
Acked-by: Simon Glass 

---

Changes in v3: None
Changes in v2:
- (in rkcommon_verify_header): changed to use a standard error
  (i.e. from errno.h) to convey 'header0 signature does not match'
  [squash of: "rockchip: mkimage: don't mix standard errors and FDT"]

 tools/rkcommon.c | 119 ++-
 tools/rkcommon.h |  19 +
 tools/rksd.c |  29 +++---
 tools/rkspi.c|  21 ++
 4 files changed, 146 insertions(+), 42 deletions(-)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index f0bf0d4..f9d9421 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -2,6 +2,8 @@
  * (C) Copyright 2015 Google,  Inc
  * Written by Simon Glass 
  *
+ * (C) 2017 Theobroma Systems Design und Consulting GmbH
+ *
  * SPDX-License-Identifier:GPL-2.0+
  *
  * Helper functions for Rockchip images
@@ -201,7 +203,7 @@ int rkcommon_set_header(void *buf, uint file_size,
 
rkcommon_set_header0(buf, file_size, params);
 
-   /* Set up the SPL name */
+   /* Set up the SPL name (i.e. copy spl_hdr over) */
memcpy(>magic, rkcommon_get_spl_hdr(params), RK_SPL_HDR_SIZE);
 
if (rkcommon_need_rc4_spl(params))
@@ -211,6 +213,121 @@ int rkcommon_set_header(void *buf, uint file_size,
return 0;
 }
 
+static inline unsigned rkcommon_offset_to_spi(unsigned offset)
+{
+   /*
+* While SD/MMC images use a flat addressing, SPI images are padded
+* to use the first 2K of every 4K sector only.
+*/
+   return ((offset & ~0x7ff) << 1) + (offset & 0x7ff);
+}
+
+static inline unsigned rkcommon_spi_to_offset(unsigned offset)
+{
+   return ((offset & ~0x7ff) >> 1) + (offset & 0x7ff);
+}
+
+static int rkcommon_parse_header(const void *buf, struct header0_info *header0,
+struct spl_info **spl_info)
+{
+   unsigned hdr1_offset;
+   struct header1_info *hdr1_sdmmc, *hdr1_spi;
+   int i;
+
+   if (spl_info)
+   *spl_info = NULL;
+
+   /*
+* The first header (hdr0) is always RC4 encoded, so try to decrypt
+* with the well-known key.
+*/
+   memcpy((void *)header0, buf, sizeof(struct header0_info));
+   rc4_encode((void *)header0, sizeof(struct header0_info), rc4_key);
+
+   if (header0->signature != RK_SIGNATURE)
+   return -EPROTO;
+
+   /* We don't support RC4 encoded image payloads here, yet... */
+   if (header0->disable_rc4 == 0)
+   return -ENOSYS;
+
+   hdr1_offset = header0->init_offset * RK_BLK_SIZE;
+   hdr1_sdmmc = (struct header1_info *)(buf + hdr1_offset);
+   hdr1_spi = (struct header1_info *)(buf +
+  rkcommon_offset_to_spi(hdr1_offset));
+
+   for (i = 0; i < ARRAY_SIZE(spl_infos); i++) {
+   if (!memcmp(_sdmmc->magic, spl_infos[i].spl_hdr, 4)) {
+   if (spl_info)
+   *spl_info = _infos[i];
+   return IH_TYPE_RKSD;
+   } else if (!memcmp(_spi->magic, spl_infos[i].spl_hdr, 4)) {
+   if (spl_info)
+   *spl_info = _infos[i];
+   return IH_TYPE_RKSPI;
+   }
+   }
+
+   return -1;
+}
+
+int rkcommon_verify_header(unsigned char *buf, int size,
+  struct image_tool_params *params)
+{
+   struct header0_info header0;
+   struct spl_info *img_spl_info, *spl_info;
+   int ret;
+
+   ret = rkcommon_parse_header(buf, , _spl_info);
+
+   /* If this is the (unimplemented) RC4 case, then rewrite the result */
+   if (ret == -ENOSYS)
+   return 0;
+
+   if (ret < 

[U-Boot] [PATCH v3 3/3] rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM

[Philipp Tomsich]

This change restores the earlier setting of init_boot_size to include
the maximum area covered by the the boot ROM of each chip for resolve
issues with back-to-bootrom functionality reported by Kever and Heiko.

To ensure that we don't run into the same issue again in the future,
I have updated the comments accordingly and added a reference to the
mailing list archive (there's some very helpful info from Andy Yan
that provides background on the BootROM requirements regarding these
fields).

See https://lists.denx.de/pipermail/u-boot/2017-May/293267.html for
some background (by Andy Yan) of how the BootROM processes this field.

Signed-off-by: Philipp Tomsich 

---

Changes in v3:
- added in v3

Changes in v2: None

 tools/rkcommon.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index f9d9421..014cceb 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -184,11 +184,14 @@ static void rkcommon_set_header0(void *buf, uint 
file_size,
 */
hdr->init_size = ROUND(hdr->init_size, 4);
/*
-* The images we create do not contain the stage following the SPL as
-* part of the SPL image, so the init_boot_size (which might have been
-* read by Rockchip's miniloder) should be the same as the init_size.
+* init_boot_size needs to be set, as it is read by the BootROM
+* to determine the size of the next-stage bootloader (e.g. U-Boot
+* proper), when used with the back-to-bootrom functionality.
+*
+* see https://lists.denx.de/pipermail/u-boot/2017-May/293267.html
+* for a more detailed explanation by Andy Yan
 */
-   hdr->init_boot_size = hdr->init_size;
+   hdr->init_boot_size = hdr->init_size + RK_MAX_BOOT_SIZE / RK_BLK_SIZE;
 
rc4_encode(buf, RK_BLK_SIZE, rc4_key);
 }
-- 
1.9.1

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

[U-Boot] [PATCH v3 2/3] rockchip: mkimage: force 2KB alignment for init_size

[Philipp Tomsich]

The Rockchip BootROM relies on init_size being aligned to 2KB
(see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html).

This pads the image to 2KB both for SD card images and SPI images
and uses a common symbolic constant for the alignment.

Signed-off-by: Philipp Tomsich 

---

Changes in v3:
- (added patch) forces the alignment/padding to 2KB for SD images, as
  this would otherwise break the back-to-bootrom functionality

Changes in v2: None

 tools/rkcommon.h | 1 +
 tools/rksd.c | 6 +++---
 tools/rkspi.c| 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/rkcommon.h b/tools/rkcommon.h
index 75a4ed6..8790f1c 100644
--- a/tools/rkcommon.h
+++ b/tools/rkcommon.h
@@ -10,6 +10,7 @@
 
 enum {
RK_BLK_SIZE = 512,
+   RK_INIT_SIZE_ALIGN  = 2048,
RK_INIT_OFFSET  = 4,
RK_MAX_BOOT_SIZE= 512 << 10,
RK_SPL_HDR_START= RK_INIT_OFFSET * RK_BLK_SIZE,
diff --git a/tools/rksd.c b/tools/rksd.c
index a880a26..c56153d 100644
--- a/tools/rksd.c
+++ b/tools/rksd.c
@@ -46,10 +46,10 @@ static int rksd_vrec_header(struct image_tool_params 
*params,
struct image_type_params *tparams)
 {
/*
-* Pad to the RK_BLK_SIZE (512 bytes) to be consistent with init_size
-* being encoded in RK_BLK_SIZE units in header0 (see rkcommon.c).
+* Pad to a 2KB alignment, as required for init_size by the ROM
+* (see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html)
 */
-   return rkcommon_vrec_header(params, tparams, RK_BLK_SIZE);
+   return rkcommon_vrec_header(params, tparams, RK_INIT_SIZE_ALIGN);
 }
 
 /*
diff --git a/tools/rkspi.c b/tools/rkspi.c
index f8a565d..4332ce1 100644
--- a/tools/rkspi.c
+++ b/tools/rkspi.c
@@ -63,7 +63,7 @@ static int rkspi_check_image_type(uint8_t type)
 static int rkspi_vrec_header(struct image_tool_params *params,
 struct image_type_params *tparams)
 {
-   int padding = rkcommon_vrec_header(params, tparams, 2048);
+   int padding = rkcommon_vrec_header(params, tparams, RK_INIT_SIZE_ALIGN);
/*
 * The file size has not been adjusted at this point (our caller will
 * eventually add the header/padding to the file_size), so we need to
-- 
1.9.1

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

[U-Boot] [PATCH v3 0/3] rockchip: mkimage: refactor rksd/rkspi padding calculation and add dumpimage support

[Philipp Tomsich]

We support booting both from SD/MMC images and SPI images on the
RK3399-Q7 for different use-cases (e.g. external boot in development
from the SD card, internal boot from MMC or SPI depending on whether
the SPI flash is populated on any given configuration option).

In getting the SPI image support ready for production, we found a
few areas that warranted improvements:
- we had broken SPI bootstrap earlier in the changes introducting
  boot0-style images for the RK3399 (this needed fixing)
- in fixing the broken SPI padding calculation, it became apparent
  that it's best to refactor and document things before we make
  the same mistake again in the future
- with both SD/MMC and SPI images being used for various purposes
  by various people, the wrong image style was inadvertendly used
  in some tests... so we support for 'dumpimage' (i.e. verify_header
  and print_header) had to be added to quickly check the image
  type being handled

With v3, we pad the images to 2KB again, as this is required by the
BootROM (see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html).

Changes in v3:
- (added patch) forces the alignment/padding to 2KB for SD images, as
  this would otherwise break the back-to-bootrom functionality
- added in v3

Changes in v2:
- (in rkcommon_verify_header): changed to use a standard error
  (i.e. from errno.h) to convey 'header0 signature does not match'
  [squash of: "rockchip: mkimage: don't mix standard errors and FDT"]

Philipp Tomsich (3):
  rockchip: mkimage: add support for verify_header/print_header
  rockchip: mkimage: force 2KB alignment for init_size
  rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM

 tools/rkcommon.c | 130 ---
 tools/rkcommon.h |  20 +
 tools/rksd.c |  35 ---
 tools/rkspi.c|  23 ++
 4 files changed, 158 insertions(+), 50 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] [PATCHv6 28/28] net: sunxi: Enable eeprom on OLinuXino Lime boards (again)

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> With commit 2681e78a5ee ("configs: Re-sync") we lost the EEPROM settings
> from the defconfig files. Let us re-add them.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 27/28] net: sun8i: fix whitespace

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Fix a few whitespaces errors in the sun8i driver.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 22/28] net: sun4i_mac: Add read_rom_hwaddr hook

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> With this patch sun4i_mac can now get the MAC address from the board in
> a predetermined board specific manner.

I think this patch should be squashed into to one before it.

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

Re: [U-Boot] [PATCHv6 21/28] net: sunxi: Have sunxi common functions together

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> The sun[8x]i network drivers have some common functions. Let's introduce
> a common file with the reading of the MAC address as a start.
>
> In the future, we can move more sunxi shared/common code into this file.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  drivers/net/sunxi_common.c | 33 +
>  drivers/net/sunxi_common.h | 13 +
>  2 files changed, 46 insertions(+)
>  create mode 100644 drivers/net/sunxi_common.c

I actually would like you to add this file to the Makefile in this change.

>  create mode 100644 drivers/net/sunxi_common.h

Nacked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCHv6 21/28] net: sunxi: Have sunxi common functions together

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> The sun[8x]i network drivers have some common functions. Let's introduce
> a common file with the reading of the MAC address as a start.
>
> In the future, we can move more sunxi shared/common code into this file.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 19/28] net: sunxi_emac: Write HW address via net_ops hook

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Expose the write_hwaddr net_ops hook to write the Ethernet address.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 18/28] arm: sunxi: Expose function to generate sunxi-specific a MAC address

[Joe Hershberger]

Typo in the subject line...

"arm: sunxi: Expose function to generate _a_ sunxi-specific MAC address"

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Expose the function to generate a MAC adddress based on the serial number.
> This can then later be moved completly out of the sunxi board specific stuff.
>
> The setup_environment quirky function still exists as it is still used
> to fixup the FDT for drivers that need the MAC address available in the
> FDT. Once that is changed, we can clean up some more.
>
> Signed-off-by: Olliver Schinagl 

Looks fine other than the subject.

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

Re: [U-Boot] [PATCHv6 17/28] fdt: fixup_eth: improve error catching/reduce identation

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Currently when checking for an error in ethernet aliases in the fdt, we
> only check for the error case -1. It is safer to ignore anything < 0.
>
> By rearranging logic a bit we can now also reduce identation.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 16/28] fdt: fixup_eth: Remove code duplication with a function

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> In fdt_support.c we use a loop to parse the mac address string from the
> fdt blob, net.h has a function for this however, so lets use it.
>
> Also, rename the variable from tmp to something more descriptive.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 15/28] net: core: Check return value of read_rom_hwaddr

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Currently, we silently ignore the return value of netops->read_rom_hwaddr().
> This naturally is bad and we should check if the code ran successfully.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 14/28] net: cosmetic: A MAC address is not limited to SROM

[Joe Hershberger]

On Mon, May 15, 2017 at 7:53 AM, Tom Rini  wrote:
> On Mon, May 15, 2017 at 10:02:30AM +0200, Olliver Schinagl wrote:
>> Currently, we print that the MAC from the SROM does not match. It can be
>> many forms of ROM, so lets drop the S.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  net/eth_legacy.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/eth_legacy.c b/net/eth_legacy.c
>> index 4276058800..800b91c327 100644
>> --- a/net/eth_legacy.c
>> +++ b/net/eth_legacy.c
>> @@ -146,7 +146,7 @@ int eth_write_hwaddr(struct eth_device *dev, const char 
>> *base_name,
>>   memcmp(dev->enetaddr, env_enetaddr, ARP_HLEN)) {
>>   printf("\nWarning: %s MAC addresses don't match:\n",
>>  dev->name);
>> - printf("Address in SROM is %pM\n",
>> + printf("Address in ROM is %pM\n",
>>  dev->enetaddr);
>>   printf("Address in environment is  %pM\n",
>>  env_enetaddr);
>
> We need to add a space in the print then as the output is manually
> aligned.

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

Re: [U-Boot] [PATCHv6 13/28] net: core: print the source of the MAC address

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> With many potential places where a MAC address can be read from, the
> user may not know where the MAC address originated from. Print the MAC
> source after initializing the Ethernet device.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 11/28] net: core: Add MAC address helper functions

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Universally administered and locally administered addresses are
> distinguished by setting the second-least-significant bit of the first
> octet of the address. Having a function to check and set this U/L bit
> from a function makes it nice for boards that want to generate their own
> mac address to ensure they are locally administered.
>
> Unicast and multicast addresses are distinguised by setting the
> least-significant bit of the first octet of the address. Having a
> function to check and set this U/M bit from a function it nice to
> make a generated mac address a unicast address.
>
> This patch introduces both these helper functions
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 10/28] net: core: Inform the user of the device MAC address

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> In certain conditions we currently print the MAC address. For example a
> warning when a random mac address is in use or a missmatch between HW
> and ENV.
>
> If all things went well however (but even if there is a miss-match) we
> do not inform the user what the final MAC address of the device is.
>
> Lets print the final MAC address of the device with which it has been
> setup.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCH v5 5/16] cmd: Add Kconfig option for CMD_MTDPARTS and related options

[Maxime Ripard]

Hi Jörg,

On Tue, May 30, 2017 at 09:39:57AM +0200, Jörg Krause wrote:
> On Mon, 2017-02-27 at 18:22 +0100, Maxime Ripard wrote:
> > CMD_MTDPARTS is something the user might or might not want to select,
> > and
> > might depends on (or be selected by) other options too.
> > 
> > This is even truer for the MTDIDS_DEFAULT and MTDPARTS_DEFAULT
> > options that
> > might change from one board to another, or from one user to the
> > other,
> > depending on what it expects and what storage devices are available.
> > 
> > In order to ease that configuration, add those options to Kconfig.
> > 
> > Signed-off-by: Maxime Ripard 
> > Reviewed-by: Tom Rini 
> > ---
> >  cmd/Kconfig| 20 
> >  cmd/mtdparts.c |  8 
> >  2 files changed, 28 insertions(+), 0 deletions(-)
> > 
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index ef5315631476..0734d669dbd7 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -801,6 +801,26 @@ config CMD_FS_GENERIC
> > help
> >   Enables filesystem commands (e.g. load, ls) that work for
> > multiple
> >   fs types.
> > +
> > +config CMD_MTDPARTS
> > +   depends on ARCH_SUNXI
> 
> Is there any reason to limit the command for the sunxi arch only?

Yes, if we don't, this will generate warnings for each architecture
that has not moved that option from their header to Kconfig.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCHv6 08/28] net: cosmetic: Do not use magic values for ARP_HLEN

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Previously overlooked magic value in commit a40db6d51171 ("net: cosmetic: Do
> not use magic values for ARP_HLEN")
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 09/28] net: core: Sanitize get/set operations for enetaddr

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> In the current net stack, we have a few functions to get and set
> the "ethaddr" and "ethNaddr" environment variables, which use magic
> values to get and set these environment variables. Remove the magicness
> of the buffer by defining it proper and also check the input for its
> length.
>
> Additionally use the define in fdt parser where the ethaddr variables
> are also used.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 07/28] net: sunxi: Move GMAC_TX_DELAY to the driver

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> The GMAC_TX_DELAY symbol sets and is dependent on the SUN7I_GMAC
> driver. Move it from the generic ARCH section to the driver specific
> section.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 06/28] net: sunxi: Restore sunxi_[eg]mac behavior

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Commit 4d43d065db326 ("sunxi: Move SUNXI_GMAC to Kconfig") renamed
> SUNXI_[EG]MAC but did not update include/configs/sunxi-common.h where
> based on these two symbols other config symbols where being set, such
> as CONFIG_PHY_REALTEK for SUNXI_GMAC boards and the CONFIG_PHY_ADDR
> being set to a safe default.
>
> This patch restores that behavior by adding the PHY_REALTEK to the
> defconfigs, where they belong and by setting the address based on the
> new config symbols.
>
> Additionally, we use the new renamed symbol in the Makefiles to
> actually compile the drivers.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  arch/arm/include/asm/arch-sunxi/sys_proto.h | 2 +-
>  board/sunxi/Makefile| 2 +-
>  configs/A20-OLinuXino-Lime2_defconfig   | 1 +
>  configs/A20-OLinuXino-Lime_defconfig| 1 +
>  configs/A20-OLinuXino_MICRO_defconfig   | 1 +
>  configs/A20-Olimex-SOM-EVB_defconfig| 1 +
>  configs/Bananapi_defconfig  | 1 +
>  configs/Bananapro_defconfig | 1 +
>  configs/CSQ_CS908_defconfig | 1 +
>  configs/Colombus_defconfig  | 1 +
>  configs/Cubieboard2_defconfig   | 1 +
>  configs/Cubietruck_defconfig| 1 +
>  configs/Hummingbird_A31_defconfig   | 1 +
>  configs/Itead_Ibox_A20_defconfig| 1 +
>  configs/Lamobo_R1_defconfig | 1 +
>  configs/Linksprite_pcDuino3_Nano_defconfig  | 1 +
>  configs/Linksprite_pcDuino3_defconfig   | 1 +
>  configs/Mele_A1000G_quad_defconfig  | 1 +
>  configs/Mele_I7_defconfig   | 1 +
>  configs/Mele_M3_defconfig   | 1 +
>  configs/Mele_M5_defconfig   | 1 +
>  configs/Mele_M9_defconfig   | 1 +
>  configs/Orangepi_defconfig  | 1 +
>  configs/Orangepi_mini_defconfig | 1 +
>  configs/Sinlinx_SinA31s_defconfig   | 1 +
>  configs/Sinovoip_BPI_M2_defconfig   | 1 +
>  configs/Wits_Pro_A20_DKT_defconfig  | 1 +
>  configs/i12-tvbox_defconfig | 1 +
>  configs/icnova-a20-swac_defconfig   | 1 +
>  configs/mixtile_loftq_defconfig | 1 +
>  drivers/net/Kconfig | 5 +
>  drivers/net/Makefile| 2 +-
>  include/configs/sunxi-common.h  | 9 +++--
>  scripts/config_whitelist.txt| 2 --
>  34 files changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h 
> b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> index a373319a2b..850236ed42 100644
> --- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
> +++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> @@ -24,7 +24,7 @@ void sdelay(unsigned long);
>  void return_to_fel(uint32_t lr, uint32_t sp);
>
>  /* Board / SoC level designware gmac init */
> -#if !defined CONFIG_SPL_BUILD && defined CONFIG_SUNXI_GMAC
> +#if !defined CONFIG_SPL_BUILD && defined CONFIG_SUN7I_MAC
>  void eth_init_board(void);
>  #else
>  static inline void eth_init_board(void) {}
> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
> index 43766e0ef4..b4768b9b9b 100644
> --- a/board/sunxi/Makefile
> +++ b/board/sunxi/Makefile
> @@ -9,7 +9,7 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>  obj-y  += board.o
> -obj-$(CONFIG_SUNXI_GMAC)   += gmac.o
> +obj-$(CONFIG_SUN7I_MAC)+= gmac.o
>  obj-$(CONFIG_SUNXI_AHCI)   += ahci.o
>  obj-$(CONFIG_MACH_SUN4I)   += dram_sun4i_auto.o
>  obj-$(CONFIG_MACH_SUN5I)   += dram_sun5i_auto.o
> diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
> b/configs/A20-OLinuXino-Lime2_defconfig
> index 14d1159ead..14a51ef3f9 100644
> --- a/configs/A20-OLinuXino-Lime2_defconfig
> +++ b/configs/A20-OLinuXino-Lime2_defconfig
> @@ -22,6 +22,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
>  # CONFIG_SPL_PARTITION_UUIDS is not set
>  CONFIG_DFU_RAM=y
>  CONFIG_SUN7I_GMAC=y
> +CONFIG_PHY_REALTEK=y

Would it make sense to either select this at the platform level or to
imply it in the driver Kconfig?

>  CONFIG_RTL8211X_PHY_FORCE_MASTER=y
>  CONFIG_AXP_ALDO3_VOLT=2800
>  CONFIG_AXP_ALDO4_VOLT=2800

[...]

> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index c0d141754f..04e8cf39c8 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -182,6 +182,9 @@ config SUN4I_EMAC
>   sun4i hardware. Newer hardware supports the SUN7I_EMAC driver,
>   which also works with 100 Megabit PHY's.
>
> +config SUN7I_MAC
> +   bool
> +
>  choice
> prompt "Allwinner Sun7i GMAC support"
> help
> @@ -196,6 +199,7 @@ config SUN7I_NONE
>  config SUN7I_EMAC
> bool "MII"
> select ETH_DESIGNWARE
> +   select SUN7I_MAC
> select PHYLIB
> select MII
> help
> @@ -205,6 +209,7 @@ config SUN7I_EMAC
>  config SUN7I_GMAC
> bool 

Re: [U-Boot] [PATCHv6 05/28] net: sunxi: Re-add RTL8211X_PHY_FORCE_MASTER

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Commit 8728c97eff5bd9 (" configs: Re-sync") potentially broke the lime2
> as it removed the RTL8211X_PHY_FORCE_MASTER flag.
>
> Re-add this flag.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCHv6 04/28] net: sunxi simplify defconfig

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> We currently have a few dependencies explicitly set in the sunxi
> defconfigs. Things such as, RGMII, DESIGNWARE_ETH in combination with
> SUN7I_GMAC. When selecting SUN7I_GMAC we already imply DESIGNWARE_ETH
> for example.
>
> This patch puts this logic into the Kconfig thus simplifying the
> defconfigs. For a user it is also no more logical when enabling one of
> the drivers in Kconfig to have the proper dependencies automatically
> selected.
>
> One thing to note, the sun7i driver can be connected in two modes,
> RGMII and MII mode and we use both throughout the boards. To make this
> easy we split up the CONFIG_SUNXI_GMAC symbol into the SUN7I_GMAC and
> the SUN7I_EMAC symbol, where the SUN7I_EMAC indicates a MII connected
> designware IP.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  configs/A20-OLinuXino-Lime2-eMMC_defconfig |  2 --
>  configs/A20-OLinuXino-Lime2_defconfig  |  2 --
>  configs/A20-OLinuXino-Lime_defconfig   |  3 +-
>  configs/A20-OLinuXino_MICRO_defconfig  |  3 +-
>  configs/A20-Olimex-SOM-EVB_defconfig   |  2 --
>  configs/Bananapi_defconfig |  2 --
>  configs/Bananapro_defconfig|  2 --
>  configs/CSQ_CS908_defconfig|  3 +-
>  configs/Colombus_defconfig |  2 --
>  configs/Cubieboard2_defconfig  |  3 +-
>  configs/Cubietruck_defconfig   |  2 --
>  configs/Hummingbird_A31_defconfig  |  2 --
>  configs/Itead_Ibox_A20_defconfig   |  3 +-
>  configs/Lamobo_R1_defconfig|  2 --
>  configs/Linksprite_pcDuino3_Nano_defconfig |  2 --
>  configs/Linksprite_pcDuino3_defconfig  |  3 +-
>  configs/Mele_A1000G_quad_defconfig |  3 +-
>  configs/Mele_I7_defconfig  |  3 +-
>  configs/Mele_M3_defconfig  |  3 +-
>  configs/Mele_M5_defconfig  |  3 +-
>  configs/Mele_M9_defconfig  |  3 +-
>  configs/Orangepi_defconfig |  2 --
>  configs/Orangepi_mini_defconfig|  2 --
>  configs/Sinlinx_SinA31s_defconfig  |  3 +-
>  configs/Sinovoip_BPI_M2_defconfig  |  2 --
>  configs/Wits_Pro_A20_DKT_defconfig |  2 --
>  configs/i12-tvbox_defconfig|  3 +-
>  configs/icnova-a20-swac_defconfig  |  3 +-
>  configs/mixtile_loftq_defconfig|  2 --
>  drivers/net/Kconfig| 54 
> --
>  include/configs/sunxi-common.h |  3 --
>  31 files changed, 57 insertions(+), 72 deletions(-)
>
[...]
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 336557f395..c0d141754f 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -149,11 +149,11 @@ config PCH_GBE
>   This MAC is present in Intel Platform Controller Hub EG20T. It
>   supports 10/100/1000 Mbps operation.
>
> +config MII
> +   bool
> +

This is a generic config that describes any MII - arguably it could be
cleaned up to mean MDIO.

>  config RGMII
> -   bool "Enable RGMII"

This wasn't a very generically useful config option (meaning there are
many devices which use RGMII and don't specify this) so it should
probably see expanded use or at least have some depends on in the
config that limit it's appearance to drivers that care.

> -   help
> - Enable the support of the Reduced Gigabit Media-Independent
> - Interface (RGMII).
> +   bool

It doesn't seem great to hide this, but maybe that's a better approach
than making it depend on the correct drivers.

>
>  config PHY_GIGE
> bool
> @@ -170,17 +170,49 @@ config RTL8169
>   This driver supports Realtek 8169 series gigabit ethernet family of
>   PCI/PCIe chipsets/adapters.
>
> -config SUN7I_GMAC
> -   bool "Enable Allwinner GMAC Ethernet support"
> -   select PHY_GIGE
> -   help
> - Enable the support for Sun7i GMAC Ethernet controller
> -
>  config SUN4I_EMAC
> bool "Allwinner Sun4i Ethernet MAC support"
> depends on DM_ETH
> +   select MII
> +   select PHYLIB
> +   help
> + This driver provides the Allwinner based SoCs with 100 Megabit
> + network support as it is found on the sun4i and sun7i. This driver
> + is known to have performance issues and should only be used on
> + sun4i hardware. Newer hardware supports the SUN7I_EMAC driver,
> + which also works with 100 Megabit PHY's.
> +
> +choice
> +   prompt "Allwinner Sun7i GMAC support"
> help
> - This driver supports the Allwinner based SUN4I Ethernet MAC.
> + This driver provides the Allwinner based SoCs network support based
> + on the Synopsys Designware gigabit driver. The driver supports both
> + RGMII and MII communications and can thus be used as a drop in
> + replacement of the 

Re: [U-Boot] [PATCHv6 03/28] net: core: Add PHY_GIGE as a Kconfig symbol

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Add the CONFIG_PHY_GIGE option as a hidden Kconfig symbol so that we
> can select it from the menu as a dependency.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCH 1/2] armv8/ls1043a: RGMII PHY requires internal delay on Tx

[Joe Hershberger]

On Mon, Apr 3, 2017 at 9:43 AM, Madalin Bucur  wrote:
> Signed-off-by: Madalin Bucur 

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

Re: [U-Boot] [PATCH 2/2] armv8/ls1046a: RGMII PHY requires internal delay on Tx

[Joe Hershberger]

On Mon, Apr 3, 2017 at 9:43 AM, Madalin Bucur  wrote:
> Signed-off-by: Madalin Bucur 

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

Re: [U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Maxime Ripard]

On Wed, May 24, 2017 at 05:34:52PM +0200, Jernej Škrabec wrote:
> Hi,
> 
> Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):
> > Hi Jernej,
> > 
> > On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> > > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> > > > > This commit adds support for TV (composite) output.
> > > > > 
> > > > > Because there is no mechanism to select TV standard, PAL is
> > > > > hardcoded.
> > > > 
> > > > I'd rather use a consistent mechanism with the old driver (even if we
> > > > only support PAL right now and reject any other option), and using
> > > > composite-pal as monitor.
> > > 
> > > I have few arguments against that:
> > > 
> > > 1. Code for parsing that env variable is in videomodes.[c|h], which is
> > > clearly a part of an older video framework (ctfb). I didn't want to
> > > include any legacy code.
> > > 
> > > 2. Even if this code is used for parsing, it would bring a lot of
> > > confusion. For now, we can say that docs/README.video does not apply to
> > > H3 and newer SoCs. If we implement this only partially, we would need to
> > > describe in details which of each setting is honored with the new driver
> > > and which not. Even then, a lot of users would skip that description and
> > > complain anyway.
> > The issue with this, and we've been bitten very hard on this one with
> > the CHIP, is that you don't really have a clear majority on that
> > one. If you support only PAL, half the world will be left out, and
> > same thing with NTSC (for some reason, we never needed to support the
> > less common ones like PAL-M or NTSC-J, but that just might be because
> > it never really sold that well in those countries, I don't have any
> > numbers on that).
> > 
> > The point is, if you just hardcode PAL for now, you will have half
> > your users complain, and then, when we will introduce NTSC support
> > eventually, we'll have to introduce some mechanism to switch between
> > the two, then we'll probably break the behaviour our users relied on
> > before, making the other half of our users pissed.
> > 
> > I'm not sure this is something we should just discard, or at least the
> > second part. Having the selection mechanism in place, even if we don't
> > support all the settings and just report an error in the logs in such
> > a case address the latter issue.
> > 
> > You'll also need to address how to setup the overscan, since this is
> > really something you want to have very quick.
> 
> Ok, I'm prepared to tackle this. Do you think it is worth to delay driver 
> merge?

Not per se, but that should definitely be part of the same release, so
if you can make it by then, then we can merge that right now, and
merge the rest later. If you can't, then we'll have to postpone it a
bit.

> > > 3. If anything is done in this direction, I think that it is better
> > > to extend DM video framework so other drivers would benefit from
> > > that work too.
> > 
> > That makes sense, but again, this is a pre-requisite for me. And it's
> > not that hard to support the video modelines with a device model
> > driver, Linux does it, and you have a string identifier at the
> > beginning of it. It just has to be deterministic, but I don't think
> > this is an issue with U-Boot's DM.
> 
> Ok, so how do you think we should implement this? If only composite
> modes are supported in the string, someone might try to set hdmi
> monitor. Should we just ignore such settings and maybe print a
> warning?

I'm not sure it was your question, but I would just reject any
improper configuration, and not display anything in such a case.

> Also the question for Simon, how should I merge code for parsing
> video string from drivers/video/videomodes.c to DM video in a way to
> be useful to most drivers?
> 
> I guess this is the first time to support analog video output in DM
> video driver and there are some things missing such as a way to
> select TV standard and define overscan.

I think it can be done in the same way linux does it here:
http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35

You basically check first that there is a string matching what your
driver expects, and then get the options.

We could imagine having some extra function to parse that string and
give back a structure filled with whatever was set in that command
line. We could imagine having the common custom properties to be
parsed at that same time.

> Or alternatively, I could make just quick edit to sunxi_tve.c driver
> and directly use old functions as they are. That way we could get
> something working very quickly, but I don't like much such approach.

That's another approach, I'm fine with it as a temporary measure, but
I'm not sure how Simon feels about it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering

Re: [U-Boot] [PATCH] net: mvpp2.c: Enable 10G support for port 0 (SFI)

[Joe Hershberger]

On Thu, Apr 6, 2017 at 8:39 AM, Stefan Roese  wrote:
> From: Stefan Chulski 
>
> This patch fixes some remaining issues in the mvpp2 driver for the 10GB
> support on port 0. These changes are:
>
> - Incorrect PCS configuration
> - Skip PHY configuration when no PHY is connected
> - Skip GMAC configurations if 10G SFI mode set
>
> Signed-off-by: Stefan Chulski 
> Signed-off-by: Stefan Roese 
> Cc: Kostya Porotchkin 
> Cc: Nadav Haklai 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH] net: mvpp2.c: Enable 10G support for port 0 (SFI)

[Joe Hershberger]

On Wed, Apr 19, 2017 at 2:14 AM, Joe Hershberger  wrote:
> Hi Stefan,
>
> On Wed, Apr 19, 2017 at 12:46 AM, Stefan Roese  wrote:
>> Hi Joe,
>>
>> On 06.04.2017 15:39, Stefan Roese wrote:
>>>
>>> From: Stefan Chulski 
>>>
>>> This patch fixes some remaining issues in the mvpp2 driver for the 10GB
>>> support on port 0. These changes are:
>>>
>>> - Incorrect PCS configuration
>>> - Skip PHY configuration when no PHY is connected
>>> - Skip GMAC configurations if 10G SFI mode set
>>>
>>> Signed-off-by: Stefan Chulski 
>>> Signed-off-by: Stefan Roese 
>>> Cc: Kostya Porotchkin 
>>> Cc: Nadav Haklai 
>>> Cc: Joe Hershberger 
>>
>>
>> Joe, are you okay with this patch? If yes, could you pull it via
>> your net repository or do I have your ACK so that I can pull it
>> via the marvell one?
>
> I'm travelling right now, so if it benefits you to have it in your
> tree in the next few weeks, then feel free to take it through your
> tree. Don't forget to delegate it to yourself in patchwork.
>
> Cheers,
> -Joe

It seems my emails that I've been sending the last few months have
been silently been getting dropped. Sorry about this.

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

Re: [U-Boot] [RFC] Question about nfs_read_reply()

[Joe Hershberger]

On Mon, Apr 10, 2017 at 6:24 PM, Joe Hershberger  wrote:
> Hi Jaehoon,
>
> On Mon, Apr 10, 2017 at 5:23 AM, Jaehoon Chung  wrote:
>> Dear Joe,
>>
>> I have a question about nfs.
>> I don't have a knowledge for NFS..So i don't know this is right or not..
>>
>> When i have tested the latest u-boot(v2017.03), nfs doesn't work fine with 
>> Odroid-xu3.
>
> How does it fail? Did you print out what the value of "len" is in the
> case where it was failing? How does it compare to the static size of
> the struct?
>
>> My question is a below thing...In net/nfs.c, nfs_read_reply() function is 
>> called the memcpy().
>> it should be copied the sizeof(rpc_pkt.u.reply))...is it really right?
>
> It may be copying too much, but I wouldn't expect that to be an issue.
>
> If it is not copying enough, then maybe NFS_READ_SIZE is not set
> appropriately? Or maybe there is an issue with how the server decides
> what read size to use?
>
>> diff --git a/net/nfs.c b/net/nfs.c
>> index 83ed0a7..09556c7 100644
>> --- a/net/nfs.c
>> +++ b/net/nfs.c
>> @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
>>
>> debug("%s\n", __func__);
>>
>>memcpy(_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply));
>>
>>
>> When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine.
>>
>> Maybe i'm wrong..so i asked this to you...
>
> Please do some debugging with the Odroid and report values.
>
> Thanks,
> -Joe
>
>> Best Regards,
>> Jaehoon Chung

Not sure that this email ever went out... I've been having trouble
with sent emails in the last few months. :/

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

Re: [U-Boot] [ PATCH v2] net: move Broadcom SF2 driver to Kconfig

[Joe Hershberger]

On Wed, Apr 12, 2017 at 2:00 PM, Tom Rini  wrote:
> On Wed, Apr 12, 2017 at 10:46:35AM -0700, Steve Rae wrote:
>
>> From: Suji Velupillai 
>>
>> move to Kconfig:
>>   CONFIG_BCM_SF2_ETH
>>   CONFIG_BCM_SF2_ETH_DEFAULT_PORT
>>   CONFIG_BCM_SF2_ETH_GMAC
>>
>> Also modified defconfigs of all platforms that use these configs.
>>
>> Signed-off-by: Suji Velupillai 
>> Tested-by: Suji Velupillai 
>> Reviewed-by: JD Zheng 
>> Reviewed-by: Scott Branden 
>> Signed-off-by: Steve Rae 
>>
>
> Reviewed-by: Tom Rini 
>
> That said, it looks like there's likely a place to do an 'imply BCM_SF2_ETH'
> as boards likely want this enabled, but can disable it safely if so
> desired.

I agree with Tom here.

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

Re: [U-Boot] [PATCHv2 01/21] net: cosmetic: Do not use magic values for ARP_HLEN

[Joe Hershberger]

On Mon, Apr 10, 2017 at 10:33 AM, Olliver Schinagl  wrote:
> Previously overlooked magic value in commit a40db6d51171 ("net: cosmetic: Do
> not use magic values for ARP_HLEN")
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCH v2] net: macb: Fix GMAC not work when enable DM_ETH

[Joe Hershberger]

On Wed, Apr 19, 2017 at 10:13 PM, Wenyou Yang  wrote:
> Always search the PHY to determine the macb->phy_addr before using
> the PHY to fix "No PHY present" error.
>
> Fix the wrong test of the GMAC's phy interface mode, it should be
> PHY_INTERFACE_MODE_RGMII.
>
> Signed-off-by: Wenyou Yang 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [RESEND PATCH v2 0/5] net/pch_gbe: updates for MIPS Boston board

[Joe Hershberger]

Hi Daniel,

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> This series is a resend of selected net/pch_gbe patches from the
> original patch series [1] which was blocked by other patch series.
> This series only contains the net/pch_gbe patches required for
> MIPS Boston board, but whose can be separately applied.
>
> [1] https://lists.denx.de/pipermail/u-boot/2016-September/268137.html
>
> Changes in v2:
> - move the switch to dm_pci_virt_to_mem() in pch_gbe_rx_descs_init()
>   to the next patch as suggested by Bin Meng
> - move the switch to dm_pci_virt_to_mem() in pch_gbe_rx_descs_init()
>   from the previous patch to this one as suggested by Bin Meng
>
> Paul Burton (5):
>   net: pch_gbe: Reset during probe
>   net: pch_gbe: Fix rx descriptor buffer addresses
>   net: pch_gbe: CPU accessible addresses are virtual
>   net: pch_gbe: Add cache maintenance
>   net: pch_gbe: Support PHY reset GPIOs

This series is assigned to you in patchwork. Does that mean you would
like to apply it? If you want me to apply it, please delegate it to
me.

Cheers,
-Joe

>
>  drivers/net/pch_gbe.c | 71 
> +--
>  drivers/net/pch_gbe.h |  1 +
>  2 files changed, 58 insertions(+), 14 deletions(-)
>
> --
> 2.11.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH v2 5/5] net: pch_gbe: Support PHY reset GPIOs

[Joe Hershberger]

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> From: Paul Burton 
>
> Add support to the pch_gbe driver for resetting the PHY using a GPIO
> specified in the device tree. This matches the support already in Linux.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
>
> Signed-off-by: Daniel Schwierzeck 
> ---
>
> Changes in v2: None
>
>  drivers/net/pch_gbe.c | 29 +++--
>  drivers/net/pch_gbe.h |  1 +
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
> index 8866f6632f..cc3ca8b3da 100644
> --- a/drivers/net/pch_gbe.c
> +++ b/drivers/net/pch_gbe.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "pch_gbe.h"
>
>  #if !defined(CONFIG_PHYLIB)
> @@ -72,6 +73,14 @@ static int pch_gbe_reset(struct udevice *dev)
> priv->rx_idx = 0;
> priv->tx_idx = 0;
>
> +   if (dm_gpio_is_valid(>gpio_phy_reset)) {
> +   /* Reset the PHY */
> +   dm_gpio_set_value(>gpio_phy_reset, 1);
> +   udelay(15000);

It seems these delays should come from the device tree as well.

Same as: http://www.mail-archive.com/u-boot@lists.denx.de/msg250563.html
or here: https://patchwork.ozlabs.org/patch/731278/

> +   dm_gpio_set_value(>gpio_phy_reset, 0);
> +   udelay(5000);
> +   }
> +
> writel(PCH_GBE_ALL_RST, _regs->reset);
>
> /*
> @@ -451,6 +460,11 @@ int pch_gbe_probe(struct udevice *dev)
> plat->iobase = (ulong)iobase;
> priv->mac_regs = (struct pch_gbe_regs *)iobase;
>
> +   err = gpio_request_by_name(dev, "phy-reset-gpios", 0,
> +  >gpio_phy_reset, GPIOD_IS_OUT);
> +   if (err && (err != -ENOENT))
> +   return err;
> +
> /* Read MAC address from SROM and initialize dev->enetaddr with it */
> pch_gbe_mac_read(priv->mac_regs, plat->enetaddr);
>
> @@ -460,9 +474,17 @@ int pch_gbe_probe(struct udevice *dev)
>
> err = pch_gbe_reset(dev);
> if (err)
> -   return err;
> +   goto out_err;
>
> -   return pch_gbe_phy_init(dev);
> +   err = pch_gbe_phy_init(dev);
> +   if (err)
> +   goto out_err;
> +
> +   return 0;
> +out_err:
> +   if (dm_gpio_is_valid(>gpio_phy_reset))
> +   dm_gpio_free(dev, >gpio_phy_reset);
> +   return err;
>  }
>
>  int pch_gbe_remove(struct udevice *dev)
> @@ -473,6 +495,9 @@ int pch_gbe_remove(struct udevice *dev)
> mdio_unregister(priv->bus);
> mdio_free(priv->bus);
>
> +   if (dm_gpio_is_valid(>gpio_phy_reset))
> +   dm_gpio_free(dev, >gpio_phy_reset);
> +
> return 0;
>  }
>
> diff --git a/drivers/net/pch_gbe.h b/drivers/net/pch_gbe.h
> index 0ea0c73a4f..1d13380837 100644
> --- a/drivers/net/pch_gbe.h
> +++ b/drivers/net/pch_gbe.h
> @@ -293,6 +293,7 @@ struct pch_gbe_priv {
> struct udevice *dev;
> int rx_idx;
> int tx_idx;
> +   struct gpio_desc gpio_phy_reset;
>  };
>
>  #endif /* _PCH_GBE_H_ */
> --
> 2.11.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH v2 4/5] net: pch_gbe: Add cache maintenance

[Joe Hershberger]

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> From: Paul Burton 
>
> On MIPS systems DMA isn't coherent with the CPU caches unless an IOCU is
> present. When there is no IOCU we need to writeback or invalidate the
> data caches at appropriate points. Perform this cache maintenance in
> the pch_gbe driver which is used on the MIPS Boston development board.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> Signed-off-by: Daniel Schwierzeck 

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

Re: [U-Boot] [RESEND PATCH v2 3/5] net: pch_gbe: CPU accessible addresses are virtual

[Joe Hershberger]

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> From: Paul Burton 
>
> Use the virt_to_bus & bus_to_virt functions rather than phys_to_bus &
> bus_to_phys, since the addresses accessed by the CPU will be virtual
> rather than physical. On MIPS physical & virtual addresses differ as we
> use virtual addresses in kseg0, and attempting to use physical addresses
> directly caused problems as they're in the user segment which would be
> mapped via the uninitialised TLB.
>
> Signed-off-by: Paul Burton 
> Signed-off-by: Daniel Schwierzeck 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

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

Re: [U-Boot] [RESEND PATCH v2 2/5] net: pch_gbe: Fix rx descriptor buffer addresses

[Joe Hershberger]

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> From: Paul Burton 
>
> The loop to set up buffer addresses in rx descriptors always operated on
> descriptor 0, rather than on each descriptor sequentially. Fix this in
> order to setup correct buffer addresses for each descriptor.
>
> Signed-off-by: Paul Burton 
> Signed-off-by: Daniel Schwierzeck 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

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

Re: [U-Boot] [RESEND PATCH v2 1/5] net: pch_gbe: Reset during probe

[Joe Hershberger]

On Sun, Apr 30, 2017 at 2:57 PM, Daniel Schwierzeck
 wrote:
> From: Paul Burton 
>
> Using the EG20T gigabit ethernet controller on the MIPS Boston board, we
> find that we have to reset the controller in order for the RGMII link to
> the PHY to become functional. Without doing so we constantly time out in
> pch_gbe_mdio_ready.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> Signed-off-by: Daniel Schwierzeck 

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

Re: [U-Boot] [PATCH] drivers: net: cpsw: abort init() on aneg timeout

[Joe Hershberger]

On Mon, May 8, 2017 at 10:19 AM, Sekhar Nori  wrote:
> Abort CPSW driver init when auto-negotiation of link
> times out. Currently, the code ignores return status
> of phy_startup(), and goes ahead with network operation
> (like DHCP) even though the link may be down.
>
> Instead, abort init process if link is down or if there
> is another error, so phy_startup() can easily be retried
> again. This also helps quick fallback to next network interface
> (like USB RNDIS) without inordinate delay.
>
> Tested on AM571x IDK and AM335x BeagleBone black.
>
> Signed-off-by: Sekhar Nori 

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

Re: [U-Boot] RFC: Alternative command name for 'tftpput'

[Joe Hershberger]

On Mon, May 22, 2017 at 6:55 AM, Stefan Roese  wrote:
> Hi,
>
> I'm stumbling again over a problem introduced with the "tftpput"
> command and its naming, as it breaks some of the old scripts that
> I and others still use. As you know, when this command is enabled
> (which I find quite useful from time to time), "tftp" can't be
> used any more as an shorthand for "tftpboot".
>
> What do others feel about this naming? Would it be acceptable, if
> I post a patch to rename this "tftpput" command into something
> else (e.g. netput, ethput, ...)? Or perhaps its possible to add
> an alias for the "tftpboot" command as "tftp", allowing the
> usage of all 3 commands:
>
> tftpboot:   TFTP get
> tftp:   TFTP get
> tftpput:TFTP put

I'd be fine with a tftp command. Ideally we would then get rid of or
phase out tftpput and instead have a "tftp put" sub-command.

No idea if there are now scripts that use tftpput that we want to
avoid breaking, or is it new enough / development-focused enough that
it's unlikely.

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

Re: [U-Boot] [PATCHv6 24/28] net: dw: Expose designware_eth_start

[Joe Hershberger]

On Mon, May 15, 2017 at 3:02 AM, Olliver Schinagl  wrote:
> Commit e72ced234045f ("net: designware: Export the operation functions")
> started to expose some of the net_ops. The sunxi_gmac glue driver also
> needs the start function, so let us expose that as well.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCH v8 14/17] net: fec_mxc: Add fec_phy_reset support

[Joe Hershberger]

On Tue, May 23, 2017 at 8:33 AM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> phy-reset-gpios and phy-reset-duration properties are
> needed for adding mii_dev reset bus operation,
> so the board code not take care of phy_reset anymore
> if it use DM_ETH.
>
> Cc: Joe Hershberger 
> Cc: Fabio Estevam 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v8:
> - Add 'phy-reset-duration' property support
>
>  drivers/net/fec_mxc.c | 83 
> ++-
>  drivers/net/fec_mxc.h |  9 ++
>  include/netdev.h  |  5 
>  3 files changed, 89 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 08bea8b..17fe27f 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -180,13 +180,27 @@ static int fec_mdio_write(struct ethernet_regs *eth, 
> uint8_t phyaddr,
>  static int fec_phy_read(struct mii_dev *bus, int phyaddr, int dev_addr,
> int regaddr)
>  {
> -   return fec_mdio_read(bus->priv, phyaddr, regaddr);
> +#ifdef CONFIG_DM_ETH
> +   struct fec_priv *priv = dev_get_priv((struct udevice *)bus->priv);
> +   struct ethernet_regs *eth = priv->eth;
> +#else
> +   struct ethernet_regs *eth = bus->priv;
> +#endif
> +
> +   return fec_mdio_read(eth, phyaddr, regaddr);
>  }
>
>  static int fec_phy_write(struct mii_dev *bus, int phyaddr, int dev_addr,
>  int regaddr, u16 data)
>  {
> -   return fec_mdio_write(bus->priv, phyaddr, regaddr, data);
> +#ifdef CONFIG_DM_ETH
> +   struct fec_priv *priv = dev_get_priv((struct udevice *)bus->priv);
> +   struct ethernet_regs *eth = priv->eth;
> +#else
> +   struct ethernet_regs *eth = bus->priv;
> +#endif
> +
> +   return fec_mdio_write(eth, phyaddr, regaddr, data);
>  }
>
>  #ifndef CONFIG_PHYLIB
> @@ -985,9 +999,44 @@ static void fec_free_descs(struct fec_priv *fec)
> free(fec->tbd_base);
>  }
>
> +#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_GPIO)
> +static int fec_phy_reset(struct mii_dev *bus)
> +{
> +   struct fec_priv *priv = dev_get_priv((struct udevice *)bus->priv);
> +   int ret;
> +
> +   if (!dm_gpio_is_valid(>reset_gpio))
> +   return 0;
> +
> +   /* phy reset */
> +   ret = dm_gpio_set_value(>reset_gpio, 0);
> +   if (ret)
> +   return ret;
> +
> +   mdelay(priv->reset_duration);
> +
> +   ret = dm_gpio_set_value(>reset_gpio, 1);
> +   if (ret)
> +   return ret;
> +
> +   mdelay(priv->reset_duration);
> +
> +   return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_DM_ETH
> +struct mii_dev *fec_get_miibus(struct udevice *dev, int dev_id)
> +#else
>  struct mii_dev *fec_get_miibus(uint32_t base_addr, int dev_id)
> +#endif
>  {
> +#ifdef CONFIG_DM_ETH
> +   struct fec_priv *priv = dev_get_priv(dev);
> +   struct ethernet_regs *eth = priv->eth;
> +#else
> struct ethernet_regs *eth = (struct ethernet_regs *)base_addr;
> +#endif
> struct mii_dev *bus;
> int ret;
>
> @@ -998,7 +1047,14 @@ struct mii_dev *fec_get_miibus(uint32_t base_addr, int 
> dev_id)
> }
> bus->read = fec_phy_read;
> bus->write = fec_phy_write;
> +#ifdef CONFIG_DM_ETH
> +   bus->priv = dev;
> +# ifdef CONFIG_DM_GPIO
> +   bus->reset = fec_phy_reset;
> +# endif
> +#else
> bus->priv = eth;
> +#endif
> fec_set_dev_name(bus->name, dev_id);
>
> ret = mdio_register(bus);
> @@ -1223,7 +1279,7 @@ static int fecmxc_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> -   bus = fec_get_miibus((uint32_t)priv->eth, dev_id);
> +   bus = fec_get_miibus(dev, dev_id);
> if (!bus)
> goto err_mii;
>
> @@ -1278,6 +1334,7 @@ static int fecmxc_ofdata_to_platdata(struct udevice 
> *dev)
> struct eth_pdata *pdata = dev_get_platdata(dev);
> struct fec_priv *priv = dev_get_priv(dev);
> const char *phy_mode;
> +   int ret = 0;
>
> pdata->iobase = (phys_addr_t)dev_get_addr(dev);
> priv->eth = (struct ethernet_regs *)pdata->iobase;
> @@ -1292,12 +1349,22 @@ static int fecmxc_ofdata_to_platdata(struct udevice 
> *dev)
> return -EINVAL;
> }
>
> -   /* TODO
> -* Need to get the reset-gpio and related properties from DT
> -* and implemet the enet reset code on .probe call
> -*/
> +#ifdef CONFIG_DM_GPIO
> +   /* phy reset gpio */
> +   ret = gpio_request_by_name(dev, "phy-reset-gpios", 0,
> +  >reset_gpio, GPIOD_IS_OUT);
> +   if (ret == 0) {
> +   priv->reset_duration = fdtdec_get_int(gd->fdt_blob,
> + dev_of_offset(dev),
> + "phy-reset-duration", 
> 1);

[U-Boot] [PATCH 2/2] sun50i: h5: Add initial NanoPi NEO2 support

[Jagan Teki]

From: Jagan Teki 

NanoPi M1 Plus is designed and developed by FriendlyElec
using the Allwinner 64-bit H5 SOC.

NanoPi Neo2 key features
- Allwinner H5, Quad-core 64-bit Cortex-A53
- 512MB DDR3 RAM
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC MicroUSB power-supply

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile  |  1 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 92 ++
 board/sunxi/MAINTAINERS|  5 ++
 configs/nanopi_neo2_defconfig  | 17 +++
 4 files changed, 115 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo2.dts
 create mode 100644 configs/nanopi_neo2_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bf16563..ec5221d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -317,6 +317,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
+   sun50i-h5-nanopi-neo2.dtb \
sun50i-h5-orangepi-pc2.dtb \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo2.dts 
b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index 000..c28779f
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * 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 library 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 library 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 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO2";
+   compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x4000 0x2000>;
+   };
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+};
+
+ {
+   compatible = "allwinner,sun50i-h5-mmc",
+"allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 531e6e0..b765853 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -262,6 +262,11 @@ M: Jelle van der Waa 
 S: Maintained
 F: configs/nanopi_neo_defconfig
 
+NANOPI-NEO2 BOARD
+M: Jagan Teki 
+S: 

[U-Boot] [PATCH 1/2] sun8i: h3: Add initial NanoPi M1 Plus support

[Jagan Teki]

From: Jagan Teki 

NanoPi M1 Plus is designed and developed by FriendlyElec
for professionals, enterprise users, makers and hobbyists
using the Allwinner H3 SOC.

NanoPi M1 Plus key features
- Allwinner H3, Quad-core Cortex-A7@1.2GHz
- 1GB DDR3 RAM
- 8GB eMMC
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC power-supply

Signed-off-by: Jagan Teki 
---
Note: Need to add mmc node for eMMC, will add it on
next version once tested

 arch/arm/dts/Makefile|  1 +
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 64 
 board/sunxi/MAINTAINERS  |  5 +++
 configs/nanopi_m1_plus_defconfig | 18 +
 4 files changed, 88 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
 create mode 100644 configs/nanopi_m1_plus_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eaf9ada..bf16563 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -309,6 +309,7 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-plus.dtb \
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-nanopi-m1.dtb \
+   sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-nanopi-neo-air.dtb
 dtb-$(CONFIG_MACH_SUN8I_R40) += \
diff --git a/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts 
b/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
new file mode 100644
index 000..8ddd1b2
--- /dev/null
+++ b/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * 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 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-h3-nanopi.dtsi"
+
+/ {
+   model = "FriendlyArm NanoPi M1 Plus";
+   compatible = "friendlyarm,nanopi-m1-plus", "allwinner,sun8i-h3";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 010e87c..531e6e0 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -252,6 +252,11 @@ M: Mylène Josserand 
 S: Maintained
 F: configs/nanopi_m1_defconfig
 
+NANOPI-M1 PLUS BOARD
+M: Jagan Teki 
+S: Maintained
+F: configs/nanopi_m1_plus_defconfig
+
 NANOPI-NEO BOARD
 M: Jelle van der Waa 
 S: Maintained
diff --git a/configs/nanopi_m1_plus_defconfig b/configs/nanopi_m1_plus_defconfig
new file mode 100644
index 000..d7a908d
--- /dev/null
+++ b/configs/nanopi_m1_plus_defconfig
@@ -0,0 +1,18 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=408
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y
+CONFIG_MMC0_CD_PIN="PH13"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-nanopi-m1-plus"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# 

Re: [U-Boot] [PATCH 02/10] drivers: spi: add config to consider command bytes when writting to flash

[Álvaro Fernández Rojas]

Hi Jagan,

El 30/05/2017 a las 7:04, Jagan Teki escribió:
> On Sat, May 20, 2017 at 1:36 PM, Álvaro Fernández Rojas
>  wrote:
>> Hi Simon,
>>
>> El 20/05/2017 a las 4:29, Simon Glass escribió:
>>> Hi Alvaro,
>>>
>>> On 18 May 2017 at 13:29, Álvaro Fernández Rojas  wrote:
 Command bytes are part of the written bytes and they should be taken into
 account when sending a spi transfer.

 Signed-off-by: Álvaro Fernández Rojas 
 ---
  drivers/mtd/spi/spi_flash.c | 2 +-
  drivers/spi/Kconfig | 3 +++
  include/spi.h   | 8 +++-
  3 files changed, 11 insertions(+), 2 deletions(-)
> 
> Is this patch not part of your v2 BCM-SPI changes?
Nope, I removed it and decided to always consider command bytes as suggested by
Simon:
https://lists.denx.de/pipermail/u-boot/2017-May/292445.html

> 
> thanks!
> 

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

Re: [U-Boot] [PATCH 1/1] net: core: avoid possible NULL pointer dereference

[Joe Hershberger]

On Mon, May 15, 2017 at 10:07 PM, Heinrich Schuchardt
 wrote:
> Checking if dev is NULL after dereferencing it does not make sense.

Yes, it was incorrect, but fortunately it was never used for anything,
so even though it's garbage if the dev is NULL, at least we didn't use
it for anything in that case.

> Signed-off-by: Heinrich Schuchardt 

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

Re: [U-Boot] [PATCH] Add support for Microchip LAN75xx and LAN78xx

[Joe Hershberger]

On Wed, May 24, 2017 at 10:14 AM,   wrote:
> From: Yuiko Oshino 
>
>>-Original Message-
>>From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
>>yuiko.osh...@microchip.com
>>Sent: Wednesday, May 10, 2017 11:25 AM
>>To: joe.hershber...@gmail.com
>>Cc: ma...@denx.de; u-boot@lists.denx.de
>>Subject: Re: [U-Boot] [PATCH] Add support for Microchip LAN75xx and
>>LAN78xx
>>
>>From: Yuiko Oshino 
>>>-Original Message-
>>>From: Joe Hershberger [mailto:joe.hershber...@gmail.com]
>>>Sent: Friday, May 5, 2017 4:59 PM
>>>To: Yuiko Oshino - C18177
>>>Cc: u-boot; Marek Vasut
>>>Subject: Re: [U-Boot] [PATCH] Add support for Microchip LAN75xx and
>>>LAN78xx
>>>
>>>Hi Yuiko,
>>
>>Hi Joe!
>>
>>[...]
[...]
 +
 +/* Loop until the read is completed with timeout */ int
 +lan7x_wait_for_bit(struct usb_device *udev,
 +  const char *prefix, const u32 index,
 +  const u32 mask, const bool set,
 +  unsigned int timeout_ms)
>>>
>>>Can you not use the generic one? include/wait_bit.h
>>
>>We need to use our own register read function as our device is an USB device.
>>It looks like wait_bit.h does not support function pointer to register read,
>>therefore we need our own.

At least copy the real one.

>>>
 +{
 +   u32 val;
 +
 +   while (--timeout_ms) {
 +   lan7x_read_reg(udev, index, );
 +
 +   if (!set)
 +   val = ~val;
 +
 +   if ((val & mask) == mask)
 +   return 0;
 +
 +   mdelay(1);
 +   }
 +
 +   debug("%s: Timeout (reg=0x%x mask=%08x wait_set=%i)\n",
 + prefix, index, mask, set);
 +
 +   return -ETIMEDOUT;
 +}
 +
 +static int lan7x_phy_wait_not_busy(struct usb_device *udev) {
 +   return lan7x_wait_for_bit(udev, __func__,
 + MII_ACC, MII_ACC_MII_BUSY,
 + false, 100); }
 +
 +int lan7x_mdio_read(struct usb_device *udev, int phy_id, int idx) {
 +   u32 val, addr;
 +
 +   /* confirm MII not busy */
 +   if (lan7x_phy_wait_not_busy(udev)) {
 +   debug("MII is busy in %s\n", __func__);
 +   return -ETIMEDOUT;
 +   }
 +
 +   /* set the address, index & direction (read from PHY) */
 +   addr = (phy_id << 11) | (idx << 6) |
 +   MII_ACC_MII_READ | MII_ACC_MII_BUSY;
 +   lan7x_write_reg(udev, MII_ACC, addr);
 +
 +   if (lan7x_phy_wait_not_busy(udev)) {
 +   debug("Timed out reading MII reg %02X\n", idx);
 +   return -ETIMEDOUT;
 +   }
 +
 +   lan7x_read_reg(udev, MII_DATA, );
 +
 +   return (u16) (val & 0x);
 +}
 +
 +int lan7x_mdio_wait_for_bit(struct usb_device *udev,
 +   const char *prefix,
 +   int phy_id, const u32 index,
 +   const u32 mask, const bool set,
 +   unsigned int timeout_ms) {
 +   u32 val;
 +
 +   while (--timeout_ms) {
 +   val = lan7x_mdio_read(udev, phy_id, index);
 +
 +   if (!set)
 +   val = ~val;
 +
 +   if ((val & mask) == mask)
 +   return 0;
 +
 +   mdelay(1);
 +   }
 +
 +   debug("%s: Timeout (reg=0x%x mask=%08x wait_set=%i)\n",
 + prefix, index, mask, set);
 +
 +   return -ETIMEDOUT;
 +}
 +
>>
>>[...]
>>
 +static int lan7x_mii_get_an(uint32_t advertising_reg) {
 +   int advertising = 0;
 +
 +   if (advertising_reg & LPA_LPACK)
 +   advertising |= ADVERTISED_Autoneg;
 +   if (advertising_reg & ADVERTISE_10HALF)
 +   advertising |= ADVERTISED_10baseT_Half;
 +   if (advertising_reg & ADVERTISE_10FULL)
 +   advertising |= ADVERTISED_10baseT_Full;
 +   if (advertising_reg & ADVERTISE_100HALF)
 +   advertising |= ADVERTISED_100baseT_Half;
 +   if (advertising_reg & ADVERTISE_100FULL)
 +   advertising |= ADVERTISED_100baseT_Full;
 +
 +   return advertising;
 +}
 +
 +int lan7x_update_flowcontrol(struct usb_device *udev,
 +struct ueth_data *dev,
 +uint32_t *flow, uint32_t *fct_flow) {
 +   uint32_t lcladv, rmtadv, ctrl1000, stat1000;
 +   uint32_t advertising = 0, lp_advertising = 0, nego = 0;
 +   uint32_t duplex = 0;
 +   u8 cap = 0;
 +
 +   lcladv = 

Re: [U-Boot] [PATCH] cmd/ethsw: Disable implicit enum conversion warning

[Joe Hershberger]

On Sun, May 28, 2017 at 7:49 AM, Tom Rini  wrote:
> With clang-3.8 we see warnings like:
> cmd/ethsw.c:304:6: warning: implicit conversion from
>   enumeration type 'enum ethsw_keyword_opt_id' to different enumeration 
> type
>   'enum ethsw_keyword_id' [-Wenum-conversion]
> ethsw_id_pvid_no,
> ^~~~
>
> Because we have one enum for ethsw_keyword_id and a second enum for
> ethsw_keyword_opt_id.  This ends up being safe as ethsw_keyword_opt_id
> explicitly starts after ethsw_keyword_id enum ends.   Disable the
> warning here rather than collapse these into one enum and rely on
> comments to denote where optional keywords begin.
>
> Cc: Codrin Ciubotariu 
> Cc: Joe Hershberger 
> Signed-off-by: Tom Rini 

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

Re: [U-Boot] [PATCH] net: phy: marvell 88e151x: Fix handling of RGMII interface types

[Joe Hershberger]

On Wed, May 24, 2017 at 8:43 AM, Phil Edworthy
 wrote:
> The 88E1518 code is programming the wrong registers for rgmii-id,
> rgmii-txid and rgmii-rxid interfaces.
>
> Since the PHY defaults to rgmii-id, it would appear that the code
> was previously only used with sgmii and rgmii-id interfaces.
>
> Tested on 88E1512 PHY in rgmii-id mode which is from the same family
> as 88E1518.
>
> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [PATCH 1/2] net: zynq_gem: Use wait_for_bit with non breakable

[Joe Hershberger]

On Tue, May 30, 2017 at 7:28 AM, Michal Simek  wrote:
> From: Siva Durga Prasad Paladugu 
>
> Use wait_for_bit to be non breakable as using it with
> breakable causes issue of un interruptible auto negotiation.
> This is due to the ctrlc pressed will taken for wait_for_bit()
> abort during phy_read() and hence not coming out of
> auto negotiation.
>
> 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 2/2] net: zynq_gem: Dont flush dummy descriptors

[Joe Hershberger]

On Tue, May 30, 2017 at 7:28 AM, Michal Simek  wrote:
> From: Siva Durga Prasad Paladugu 
>
> Dont flush dummy descriptors as they are already
> allocated from a region with dcache off. Tested
> this on Zynq(zc702) and ZynqMP(zcu102) boards.
>
> 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/freescale: Share qbman init between archs

[york sun]

On 05/12/2017 01:30 PM, Roy Pledge wrote:
> From: Ahmed Mansour 
> 
> This patch adds changes necessary to move functionality present in
> PowerPC folders with ARM architectures that have DPAA1 QBMan hardware
> 
> - Created new board/freescale/common/portals.c to house shared device
>tree fixups for DPAA1 devices with ARM and PowerPC cores

I don't think using board/freescale/common/portals.c is the best 
solution. QBMan is a SoC feature, not Freescale board specific. Please 
consider to move it to somewhere common.

> - Added new header file to top includes directory to allow files in
>both architectures to grab the function prototypes
> - Port inhibit_portals() from PowerPC to ARM. This function is used in
>setup to disable interrupts on all QMan and BMan portals. It is
>needed because the interrupts are enabled by default for all portals
>including unused/uninitialised portals. When the kernel attempts to
>go to deep sleep the unused portals prevent it from doing so
> 
> Signed-off-by: Ahmed Mansour 
> Signed-off-by: Roy Pledge 
> ---
>   arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   7 +
>   arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  15 +
>   .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |   3 +
>   .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  29 ++
>   arch/powerpc/cpu/mpc85xx/cpu_init.c|   3 +-
>   arch/powerpc/cpu/mpc85xx/fdt.c |   1 +
>   arch/powerpc/cpu/mpc85xx/portals.c | 281 ---
>   arch/powerpc/include/asm/fsl_liodn.h   |   5 +-
>   arch/powerpc/include/asm/fsl_portals.h |   4 -
>   arch/powerpc/include/asm/immap_85xx.h  |  60 
>   board/freescale/common/Makefile|   2 +
>   board/freescale/common/portals.c   | 312 
> +
>   include/configs/ls1043a_common.h   |   2 +
>   include/fsl_qbman.h|  75 +
>   14 files changed, 451 insertions(+), 348 deletions(-)
>   create mode 100644 board/freescale/common/portals.c
>   create mode 100644 include/fsl_qbman.h
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index bb02960..4b5b1b4 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -26,6 +26,10 @@
>   #ifdef CONFIG_SYS_FSL_DDR
>   #include 
>   #endif
> +#include 
> +#ifdef CONFIG_SYS_DPAA_QBMAN
> +#include 
> +#endif

Do not use ifdef if you can avoid it.



> diff --git a/include/configs/ls1043a_common.h 
> b/include/configs/ls1043a_common.h
> index e269248..e2d6ef1 100644
> --- a/include/configs/ls1043a_common.h
> +++ b/include/configs/ls1043a_common.h
> @@ -201,6 +201,8 @@
>   #endif
>   #endif
>   
> +#define CONFIG_SYS_DPAA_QBMAN/* Support Q/Bman */
> +

It's better to move this option to Kconfig.

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

[U-Boot] [PATCH 3/3] arm64: zynqmp: Check pmufw version

[Michal Simek]

If PMUFW version is not v0.3 then panic.
ZynqMP switch to CCF based clock driver which requires
PMUFW to be present at certain version.
This patch ensure that you use correct and tested PMUFW
binary.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c  | 35 
 arch/arm/include/asm/arch-zynqmp/sys_proto.h |  1 +
 board/xilinx/zynqmp/zynqmp.c |  8 +++
 include/configs/xilinx_zynqmp.h  |  2 ++
 4 files changed, 46 insertions(+)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index f7ed179c1866..94ecf9066028 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -129,6 +129,41 @@ int invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 
arg2, u32 arg3,
return regs.regs[0];
 }
 
+#define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
+
+#define ZYNQMP_PM_VERSION_MAJOR0
+#define ZYNQMP_PM_VERSION_MINOR3
+#define ZYNQMP_PM_VERSION_MAJOR_SHIFT  16
+#define ZYNQMP_PM_VERSION_MINOR_MASK   0x
+
+#define ZYNQMP_PM_VERSION  \
+   ((ZYNQMP_PM_VERSION_MAJOR << ZYNQMP_PM_VERSION_MAJOR_SHIFT) | \
+ZYNQMP_PM_VERSION_MINOR)
+
+#if defined(CONFIG_CLK_ZYNQMP)
+void zynqmp_pmufw_version(void)
+{
+   int ret;
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   u32 pm_api_version;
+
+   ret = invoke_smc(ZYNQMP_SIP_SVC_GET_API_VERSION, 0, 0, 0, 0,
+ret_payload);
+   pm_api_version = ret_payload[1];
+
+   if (ret)
+   panic("PMUFW is not found - Please load it!\n");
+
+   printf("PMUFW:\tv%d.%d\n",
+  pm_api_version >> ZYNQMP_PM_VERSION_MAJOR_SHIFT,
+  pm_api_version & ZYNQMP_PM_VERSION_MINOR_MASK);
+
+   if (pm_api_version != ZYNQMP_PM_VERSION)
+   panic("PMUFW version error. Expected: v%d.%d\n",
+ ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR);
+}
+#endif
+
 int zynqmp_mmio_write(const u32 address,
  const u32 mask,
  const u32 value)
diff --git a/arch/arm/include/asm/arch-zynqmp/sys_proto.h 
b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
index 4ae1bb6eef7c..d91d98a1196c 100644
--- a/arch/arm/include/asm/arch-zynqmp/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
@@ -18,6 +18,7 @@ void psu_init(void);
 
 void handoff_setup(void);
 
+void zynqmp_pmufw_version(void);
 int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
 int zynqmp_mmio_read(const u32 address, u32 *value);
 int invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2, u32 arg3,
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 3849b5885dfe..51a3d9f276b7 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -113,6 +113,14 @@ static char *zynqmp_get_silicon_idcode_name(void)
 }
 #endif
 
+int board_early_init_f(void)
+{
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_CLK_ZYNQMP)
+   zynqmp_pmufw_version();
+#endif
+   return 0;
+}
+
 #define ZYNQMP_VERSION_SIZE9
 
 int board_init(void)
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 87a5da3fb84b..a3ece28dc05a 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -300,4 +300,6 @@
 #endif
 #endif
 
+#define CONFIG_BOARD_EARLY_INIT_F
+
 #endif /* __XILINX_ZYNQMP_H */
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] fpga: zynqmppl: Reuse invoke_smc routine

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Reuse invoke_smc() routine which is already defined
instead of duplicating same at multiple places.

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

 drivers/fpga/zynqmppl.c | 25 -
 1 file changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 23039c3eb2d8..57a4e6c88e7a 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DUMMY_WORD 0x
 
@@ -191,25 +192,14 @@ static int zynqmp_validate_bitstream(xilinx_desc *desc, 
const void *buf,
return 0;
 }
 
-static int invoke_smc(ulong id, ulong reg0, ulong reg1, ulong reg2)
-{
-   struct pt_regs regs;
-   regs.regs[0] = id;
-   regs.regs[1] = reg0;
-   regs.regs[2] = reg1;
-   regs.regs[3] = reg2;
-
-   smc_call();
-
-   return regs.regs[0];
-}
-
 static int zynqmp_load(xilinx_desc *desc, const void *buf, size_t bsize,
 bitstream_type bstype)
 {
u32 swap;
-   ulong bin_buf, flags;
+   ulong bin_buf;
int ret;
+   u32 buf_lo, buf_hi;
+   u32 ret_payload[PAYLOAD_ARG_CNT];
 
if (zynqmp_validate_bitstream(desc, buf, bsize, bsize, ))
return FPGA_FAIL;
@@ -224,9 +214,10 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf, 
size_t bsize,
else
bsize = bsize / 4;
 
-   flags = (u32)bsize | ((u64)bstype << 32);
-
-   ret = invoke_smc(ZYNQMP_SIP_SVC_PM_FPGA_LOAD, bin_buf, flags, 0);
+   buf_lo = (u32)bin_buf;
+   buf_hi = upper_32_bits(bin_buf);
+   ret = invoke_smc(ZYNQMP_SIP_SVC_PM_FPGA_LOAD, buf_lo, buf_hi, bsize,
+bstype, ret_payload);
if (ret)
debug("PL FPGA LOAD fail\n");
 
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] zynqmp: Define routines for mmio write and read

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Define routines of mmio write and read functionalities
for zynqmp platform.

Also do not call SMC from SPL because SPL is running before ATF in EL3
that's why SMCs can't be called because there is nothing to call.
zynqmp_mmio*() are doing direct read/write accesses and this patch does
the same. PMUFW is up and running at this time and there is a way to talk
to pmufw via IPI but there is no reason to implement IPI stuff in SPL if
we need just simple read for getting clock driver to work.

Also make invoke_smc as global so that it can be reused in
multile places where ever possible.

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

 arch/arm/cpu/armv8/zynqmp/cpu.c  | 73 
 arch/arm/include/asm/arch-zynqmp/sys_proto.h |  7 +++
 2 files changed, 80 insertions(+)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 280e07ad3695..f7ed179c1866 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -98,3 +98,76 @@ unsigned int zynqmp_get_silicon_version(void)
 
return ZYNQMP_CSU_VERSION_SILICON;
 }
+
+#define ZYNQMP_MMIO_READ   0xC214
+#define ZYNQMP_MMIO_WRITE  0xC213
+
+#ifndef CONFIG_SPL_BUILD
+int invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2, u32 arg3,
+  u32 *ret_payload)
+{
+   /*
+* Added SIP service call Function Identifier
+* Make sure to stay in x0 register
+*/
+   struct pt_regs regs;
+
+   regs.regs[0] = pm_api_id;
+   regs.regs[1] = ((u64)arg1 << 32) | arg0;
+   regs.regs[2] = ((u64)arg3 << 32) | arg2;
+
+   smc_call();
+
+   if (ret_payload != NULL) {
+   ret_payload[0] = (u32)regs.regs[0];
+   ret_payload[1] = upper_32_bits(regs.regs[0]);
+   ret_payload[2] = (u32)regs.regs[1];
+   ret_payload[3] = upper_32_bits(regs.regs[1]);
+   ret_payload[4] = (u32)regs.regs[2];
+   }
+
+   return regs.regs[0];
+}
+
+int zynqmp_mmio_write(const u32 address,
+ const u32 mask,
+ const u32 value)
+{
+   return invoke_smc(ZYNQMP_MMIO_WRITE, address, mask, value, 0, NULL);
+}
+
+int zynqmp_mmio_read(const u32 address, u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   u32 ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = invoke_smc(ZYNQMP_MMIO_READ, address, 0, 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+#else
+int zynqmp_mmio_write(const u32 address,
+ const u32 mask,
+ const u32 value)
+{
+   u32 data;
+   u32 value_local = value;
+
+   zynqmp_mmio_read(address, );
+   data &= ~mask;
+   value_local &= mask;
+   value_local |= data;
+   writel(value_local, (ulong)address);
+   return 0;
+}
+
+int zynqmp_mmio_read(const u32 address, u32 *value)
+{
+   *value = readl((ulong)address);
+   return 0;
+}
+#endif
diff --git a/arch/arm/include/asm/arch-zynqmp/sys_proto.h 
b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
index 7b11895481be..4ae1bb6eef7c 100644
--- a/arch/arm/include/asm/arch-zynqmp/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
@@ -8,6 +8,8 @@
 #ifndef _ASM_ARCH_SYS_PROTO_H
 #define _ASM_ARCH_SYS_PROTO_H
 
+#define PAYLOAD_ARG_CNT5
+
 int zynq_slcr_get_mio_pin_status(const char *periph);
 
 unsigned int zynqmp_get_silicon_version(void);
@@ -16,4 +18,9 @@ void psu_init(void);
 
 void handoff_setup(void);
 
+int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
+int zynqmp_mmio_read(const u32 address, u32 *value);
+int invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2, u32 arg3,
+  u32 *ret_payload);
+
 #endif /* _ASM_ARCH_SYS_PROTO_H */
-- 
1.9.1

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

Re: [U-Boot] [PATCH v7 0/6] Add Intel Arria 10 SoC FPGA driver

[Dinh Nguyen]

On 05/28/2017 11:00 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This is the 6th version of patchset to adds support for Intel Arria 10 SoC 
> FPGA
> driver. This version mainly resolved comments from Dinh in [v6].
> This series is working on top of u-boot.git - http://git.denx.de/u-boot.git.
> 
> [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250687.html
> 
> v6 -> v7 changes:
> -
> - Changed commit header of patch 4/6 to more generic.
> 
> Patchset history
> 
> [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg247788.html
> [v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg248541.html
> [v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg249160.html
> [v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250149.html
> [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.html
> 
> Tien Fong Chee (6):
>   arm: socfpga: Remove unused passing parameter of socfpga_bridges_reset
>   arm: socfpga: Restructure FPGA driver in the preparation to support
> A10
>   arm: socfpga: Enable FPGA driver on SPL
>   drivers: Enable FPGA driver build on SPL
>   arm: socfpga: Move FPGA manager driver to FPGA driver
>   arm: socfpga: Add FPGA driver support for Arria 10
> 
>  arch/arm/mach-socfpga/Makefile |   1 -
>  arch/arm/mach-socfpga/fpga_manager.c   |  78 
>  arch/arm/mach-socfpga/include/mach/fpga_manager.h  |  70 +--
>  .../include/mach/fpga_manager_arria10.h| 100 +
>  .../mach/{fpga_manager.h => fpga_manager_gen5.h}   |  69 ++-
>  .../include/mach/reset_manager_arria10.h   |   2 +-
>  arch/arm/mach-socfpga/reset_manager_arria10.c  |   4 +-
>  drivers/Makefile   |   1 +
>  drivers/fpga/Makefile  |   2 +
>  drivers/fpga/socfpga.c | 241 +--
>  drivers/fpga/socfpga_arria10.c | 479 
> +
>  drivers/fpga/{socfpga.c => socfpga_gen5.c} |  98 ++---
>  include/configs/socfpga_common.h   |   4 +-
>  13 files changed, 685 insertions(+), 464 deletions(-)
>  delete mode 100644 arch/arm/mach-socfpga/fpga_manager.c
>  create mode 100644 arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
>  copy arch/arm/mach-socfpga/include/mach/{fpga_manager.h => 
> fpga_manager_gen5.h} (57%)
>  create mode 100644 drivers/fpga/socfpga_arria10.c
>  copy drivers/fpga/{socfpga.c => socfpga_gen5.c} (85%)
> 

For the series,

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

[U-Boot] [PATCH] drivers: ram: stm32: fix compilation issue

[patrice.chotard]

From: Patrice Chotard 

If CONFIG_CLK flag is not set, compilation raises the
following error message:

drivers/ram/stm32_sdram.c: In function 'stm32_fmc_probe':
drivers/ram/stm32_sdram.c:154:2: error: 'ret' undeclared (first use in this 
function)
  ret = stm32_sdram_init(dev);

Signed-off-by: Patrice Chotard 
cc: Vikas Manocha 
---
 drivers/ram/stm32_sdram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 48b4979..af463fc 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -132,8 +132,8 @@ static int stm32_fmc_ofdata_to_platdata(struct udevice *dev)
 
 static int stm32_fmc_probe(struct udevice *dev)
 {
-#ifdef CONFIG_CLK
int ret;
+#ifdef CONFIG_CLK
struct clk clk;
 
ret = clk_get_by_index(dev, 0, );
-- 
1.9.1

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

[U-Boot] [PATCH] cmd/fdt: support single value replacement within an array

[Hannes Schmelzer]

With this commit we can modify single values within an array of a dts
property.

This is useful if we have for example a pwm-backlight where we want to
modifiy the pwm frequency per u-boot script.

The pwm is described in dts like this:

backlight {
pwms = <0x002b 0x 0x004c4b40>;
};

For changing the frequency, here the 3rd parameter, we simply type:

fdt set /backlight pwms ;

For doing all this we:
- backup the property content into our 'SCRATCHPAD'
- only modify the array-cell if the new content doesn't start with '?'

Signed-off-by: Hannes Schmelzer 

---

 cmd/fdt.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/cmd/fdt.c b/cmd/fdt.c
index a21415d..e55102a 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -257,6 +257,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
char *prop; /* property */
int  nodeoffset;/* node offset from libfdt */
static char data[SCRATCHPAD];   /* storage for the property */
+   const void *ptmp;
int  len;   /* new length of the property */
int  ret;   /* return value */
 
@@ -268,13 +269,6 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
pathp  = argv[2];
prop   = argv[3];
-   if (argc == 4) {
-   len = 0;
-   } else {
-   ret = fdt_parse_prop([4], argc - 4, data, );
-   if (ret != 0)
-   return ret;
-   }
 
nodeoffset = fdt_path_offset (working_fdt, pathp);
if (nodeoffset < 0) {
@@ -286,6 +280,21 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return 1;
}
 
+   if (argc == 4) {
+   len = 0;
+   } else {
+   ptmp = fdt_getprop(working_fdt, nodeoffset, prop, );
+   if (len > SCRATCHPAD) {
+   printf("prop (%d) doesn't fit in scratchpad!\n",
+  len);
+   return 1;
+   }
+   memcpy(data, ptmp, len);
+   ret = fdt_parse_prop([4], argc - 4, data, );
+   if (ret != 0)
+   return ret;
+   }
+
ret = fdt_setprop(working_fdt, nodeoffset, prop, data, len);
if (ret < 0) {
printf ("libfdt fdt_setprop(): %s\n", 
fdt_strerror(ret));
@@ -766,7 +775,11 @@ static int fdt_parse_prop(char * const *newval, int count, 
char *data, int *len)
 
cp = newp;
tmp = simple_strtoul(cp, , 0);
-   *(fdt32_t *)data = cpu_to_fdt32(tmp);
+   if (*cp != '?')
+   *(fdt32_t *)data = cpu_to_fdt32(tmp);
+   else
+   newp++;
+
data  += 4;
*len += 4;
 
-- 
1.9.1


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

[U-Boot] [PATCH] fs: usbifs: Fix warning in ubifs

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch fixes the below warning by typecasting it properly
fs/ubifs/ubifs.c: In function 'ubifs_load':
fs/ubifs/ubifs.c:942:29: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
  err = ubifs_read(filename, (void *)addr, 0, size, );

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

 fs/ubifs/ubifs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index cc397d605b0e..db29489eca75 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -939,7 +939,7 @@ int ubifs_load(char *filename, u32 addr, u32 size)
 
printf("Loading file '%s' to addr 0x%08x...\n", filename, addr);
 
-   err = ubifs_read(filename, (void *)addr, 0, size, );
+   err = ubifs_read(filename, (void *)(uintptr_t)addr, 0, size, );
if (err == 0) {
setenv_hex("filesize", actread);
printf("Done\n");
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] net: zynq_gem: Use wait_for_bit with non breakable

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Use wait_for_bit to be non breakable as using it with
breakable causes issue of un interruptible auto negotiation.
This is due to the ctrlc pressed will taken for wait_for_bit()
abort during phy_read() and hence not coming out of
auto negotiation.

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

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

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 357f8c2917d2..9c0f5fba28cd 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -192,7 +192,7 @@ static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 
phy_addr, u32 regnum,
int err;
 
err = wait_for_bit(__func__, >nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK,
-   true, 2, true);
+   true, 2, false);
if (err)
return err;
 
@@ -205,7 +205,7 @@ static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 
phy_addr, u32 regnum,
writel(mgtcr, >phymntnc);
 
err = wait_for_bit(__func__, >nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK,
-   true, 2, true);
+   true, 2, false);
if (err)
return err;
 
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] net: zynq_gem: Dont flush dummy descriptors

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Dont flush dummy descriptors as they are already
allocated from a region with dcache off. Tested
this on Zynq(zc702) and ZynqMP(zcu102) boards.

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

 drivers/net/zynq_gem.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 9c0f5fba28cd..31bb3f17d835 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -407,10 +407,6 @@ static int zynq_gem_init(struct udevice *dev)
dummy_rx_bd->addr = ZYNQ_GEM_RXBUF_WRAP_MASK |
ZYNQ_GEM_RXBUF_NEW_MASK;
dummy_rx_bd->status = 0;
-   flush_dcache_range((ulong)_tx_bd, (ulong)_tx_bd +
-  sizeof(dummy_tx_bd));
-   flush_dcache_range((ulong)_rx_bd, (ulong)_rx_bd +
-  sizeof(dummy_rx_bd));
 
writel((ulong)dummy_tx_bd, >transmit_q1_ptr);
writel((ulong)dummy_rx_bd, >receive_q1_ptr);
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] bootstage: Modify routine timer_get_boot_us()

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Modify routine timer_get_boot_us(), as the base_time
will be stored in bss if initialized to zero(observed for
arm compilers, arm and arm64) and for most of the boards
bss was not initialized to zero before relocation and hence
causing a junk timestamp value in boot record if there is an
entry record before relocation(example would be board_init_f
entry). Also, as it is in bss which will be intialized to zero
after relocation, it causes the first entry after relocation
to be missed while printing bootstage report as the
timer_get_boot_us() returns zero if bss_time is zero.
This patch fixes the same by initialzing bss_time to 1 and also
returning current timestamp if bss_time is 1. Intializing it to
1 causes it to be placed in data section and hence no issues.

Before this patch:
ZynqMP> bootstage report
Timer summary in microseconds:
   MarkElapsed  Stage
  0  0  reset
491,000491,000  id=64
516,000 25,000  id=65
522,000  6,000  main_loop
112,092,989,575,347,436,48112,092,989,575,342,216,48  board_init_f

After this patch:
ZynqMP> bootstage report
Timer summary in microseconds:
   MarkElapsed  Stage
  0  0  reset
  9,969  9,969  board_init_f
  1,227,000  1,217,031  board_init_r
  1,713,000486,000  id=64
  1,733,000 20,000  id=65
  1,735,000  2,000  main_loop

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

 common/bootstage.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/common/bootstage.c b/common/bootstage.c
index bca74cd207fc..b65345c28105 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -294,16 +294,18 @@ void bootstage_report(void)
 
 ulong __timer_get_boot_us(void)
 {
-   static ulong base_time;
+   static ulong base_time = 1;
 
/*
 * We can't implement this properly. Return 0 on the first call and
 * larger values after that.
 */
-   if (base_time)
+   if (base_time != 1)
return get_timer(base_time) * 1000;
-   base_time = get_timer(0);
-   return 0;
+   else
+   base_time = get_timer(0);
+
+   return base_time;
 }
 
 ulong timer_get_boot_us(void)
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] bootstage: print all entries even if recorded time is zero

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Print all entries in boot stage report even if the recorded
time stamp is zero. This lets the user to know all the recorded
entries that are made into. This helps user to know if something
went wrong with timestamp for that entry.

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

 common/bootstage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/bootstage.c b/common/bootstage.c
index c8080dcab5d7..bca74cd207fc 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -277,7 +277,7 @@ void bootstage_report(void)
qsort(record, ARRAY_SIZE(record), sizeof(*rec), h_compare_record);
 
for (id = 0; id < BOOTSTAGE_ID_COUNT; id++, rec++) {
-   if (rec->time_us != 0 && !rec->start_us)
+   if ((rec->time_us != 0 && !rec->start_us) || rec->name)
prev = print_time_record(rec->id, rec, prev);
}
if (next_id > BOOTSTAGE_ID_COUNT)
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] bootstage: Dont print reset entry separately

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Printing the first entry reset separately is no longer
needed as it now prints the entries with valid name and
timestamp zero. This removes duplicate printing of the reset
record.

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

 common/bootstage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/bootstage.c b/common/bootstage.c
index 35bce3d881a5..c8080dcab5d7 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -271,7 +271,7 @@ void bootstage_report(void)
/* Fake the first record - we could get it from early boot */
rec->name = "reset";
rec->time_us = 0;
-   prev = print_time_record(BOOTSTAGE_ID_AWAKE, rec, 0);
+   prev = 0;
 
/* Sort records by increasing time */
qsort(record, ARRAY_SIZE(record), sizeof(*rec), h_compare_record);
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] zynq: Kconfig: Add Kconfig option for any DDR specific initialization

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Add Kconfig option for ddr init as this might be required
in cases like ddr less systems where we want to skip ddrc
init and this option is useful for it.

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

 arch/arm/mach-zynq/Kconfig | 8 
 arch/arm/mach-zynq/ddrc.c  | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index 2529c9ff449d..c428ce5cc70b 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -24,6 +24,14 @@ config SPL_SPI_FLASH_SUPPORT
 config SPL_SPI_SUPPORT
default y if ZYNQ_QSPI
 
+config ZYNQ_DDRC_INIT
+   bool "Zynq DDRC initialization"
+   default y
+   help
+ This option used to perform DDR specific initialization
+ if required. There might be cases like ddr less where we
+ want to skip ddr init and this option is useful for it.
+
 config SYS_BOARD
default "zynq"
 
diff --git a/arch/arm/mach-zynq/ddrc.c b/arch/arm/mach-zynq/ddrc.c
index d74f8dbbc45d..bde52d656203 100644
--- a/arch/arm/mach-zynq/ddrc.c
+++ b/arch/arm/mach-zynq/ddrc.c
@@ -12,6 +12,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_ZYNQ_DDRC_INIT
+void zynq_ddrc_init(void) {}
+#else
 /* Control regsiter bitfield definitions */
 #define ZYNQ_DDRC_CTRLREG_BUSWIDTH_MASK0xC
 #define ZYNQ_DDRC_CTRLREG_BUSWIDTH_SHIFT   2
@@ -46,3 +49,4 @@ void zynq_ddrc_init(void)
puts("ECC disabled ");
}
 }
+#endif
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] arm64: zynqmp: Do not map unused OCM/TCM region

[Michal Simek]

When OCM or TCM is protected this mapping still exist and it is causing access
violation.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index b0f12955a1ff..280e07ad3695 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -38,12 +38,6 @@ static struct mm_region zynqmp_mem_map[] = {
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
-   .virt = 0xffe0UL,
-   .phys = 0xffe0UL,
-   .size = 0x0020UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
.virt = 0x4UL,
.phys = 0x4UL,
.size = 0x2UL,
-- 
1.9.1

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