Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine

[Bin Meng]

Hi Tuomas,

On Fri, Sep 1, 2017 at 5:56 AM, Tuomas Tynkkynen  wrote:
> Hi,
>
>
> On 08/31/2017 09:55 AM, Bin Meng wrote:
>>
>> Hi Tuomas,
>>
>> On Wed, Aug 30, 2017 at 4:31 PM, Tuomas Tynkkynen
>>  wrote:
>>>
>>> This board builds an U-Boot binary that is bootable with QEMU's 'virt'
>>> machine on ARM. The minimal QEMU command line is:
>>>
>>>  qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
>>>
>>> (Note that the 'highmem=off' parameter to the 'virt' machine is required
>>> for
>>> PCI to work in U-Boot.) This command line enables the following:
>>>  - u-boot.bin loaded and executing in the emulated flash at address
>>> 0x0
>>>  - A generated device tree blob placed at the start of RAM
>>>  - A freely configurable amount of RAM, described by the DTB
>>>  - A PL011 serial port, discoverable via the DTB
>>>  - An ARMv7 architected timer
>>>  - PSCI for rebooting the system
>>>  - A generic ECAM-based PCI host controller, discoverable via the DTB
>>>
>>> Additionally, QEMU allows plugging a bunch of useful peripherals to the
>>> PCI bus.
>>> The following ones are supported by both U-Boot and Linux:
>>>
>>> - To enable a Serial ATA disk via an Intel ICH9 AHCI controller, pass
>>> e.g.:
>>>  -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci
>>> -device ide-drive,drive=mydisk,bus=ahci.0
>>> - To enable an Intel E1000 network adapter, pass e.g.:
>>>  -net nic,model=e1000 -net user
>>> - To add an EHCI-compliant USB host controller, pass e.g.:
>>>  -device usb-ehci,id=ehci
>>
>>
>> Can we enable the NVMe driver (CONFIG_NVME) here?
>>
>
> Yes, 'nvme scan' and 'nvme list' it appear to work. I'll enable it.
> There is a bunch of spew of this form though:
>
> CACHE: Misaligned operation at range [bef5d000, bef5d020]
>

I think I've fixed this already and is now in v2017.09-rc3. But rc3 is
still not shown on git.denx.de. Not sure why.

>
>
>>>
>>> Signed-off-by: Tuomas Tynkkynen 
>>> ---
>>>   arch/arm/Kconfig   | 10 
>>>   arch/arm/mach-qemu/Kconfig |  9 +++
>>>   board/qemu-arm/Makefile|  5 
>>>   board/qemu-arm/qemu-arm.c  | 35 ++
>>>   configs/qemu_arm_defconfig | 27 
>>>   include/configs/qemu-arm.h | 63
>>> ++
>>>   6 files changed, 149 insertions(+)
>>>   create mode 100644 arch/arm/mach-qemu/Kconfig
>>>   create mode 100644 board/qemu-arm/Makefile
>>>   create mode 100644 board/qemu-arm/qemu-arm.c
>>>   create mode 100644 configs/qemu_arm_defconfig
>>>   create mode 100644 include/configs/qemu-arm.h
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 53d0831935..0d01ba1b73 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -630,6 +630,14 @@ config ARCH_MX5
>>>  select CPU_V7
>>>  select BOARD_EARLY_INIT_F
>>>
>>> +config ARCH_QEMU
>>> +   bool "QEMU Virtual Platform"
>>> +   select CPU_V7
>>> +   select ARCH_SUPPORT_PSCI
>>> +   select DM
>>> +   select DM_SERIAL
>>> +   select OF_CONTROL
>>> +
>>>   config ARCH_RMOBILE
>>>  bool "Renesas ARM SoCs"
>>>  select DM
>>> @@ -1149,6 +1157,8 @@ source "arch/arm/mach-stm32/Kconfig"
>>>
>>>   source "arch/arm/mach-sunxi/Kconfig"
>>>
>>> +source "arch/arm/mach-qemu/Kconfig"
>>> +
>>
>>
>> Can you insert this by following alphabetical order?
>>
>
> Oops, yes of course.
>
>>>   source "arch/arm/mach-tegra/Kconfig"
>>>
>>>   source "arch/arm/mach-uniphier/Kconfig"
>>> diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
>>> new file mode 100644
>>> index 00..89d2a36719
>>> --- /dev/null
>>> +++ b/arch/arm/mach-qemu/Kconfig
>>> @@ -0,0 +1,9 @@
>>> +if ARCH_QEMU
>>> +
>>> +config SYS_BOARD
>>> +   default "qemu-arm"
>>> +
>>> +config SYS_CONFIG_NAME
>>> +   default "qemu-arm"
>>> +
>>> +endif
>>> diff --git a/board/qemu-arm/Makefile b/board/qemu-arm/Makefile
>>> new file mode 100644
>>> index 00..3e9907d983
>>> --- /dev/null
>>> +++ b/board/qemu-arm/Makefile
>>
>>
>> Can this new board be put into the board/emulation/qemu-arm directory?
>> Since qemu-x86 is put there.
>>
>
> Sure. There is still qemu-mips directly under board/ though.

Yep, so a separate patch to move all these qemu- boards into emulation
would be nice.

>
>>> @@ -0,0 +1,5 @@
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +#
>>> +
>>> +obj-y  += qemu-arm.o
>>> diff --git a/board/qemu-arm/qemu-arm.c b/board/qemu-arm/qemu-arm.c
>>> new file mode 100644
>>> index 00..90d7badbf4
>>> --- /dev/null
>>> +++ b/board/qemu-arm/qemu-arm.c
>>> @@ -0,0 +1,35 @@
>>> +/*
>>> + * Copyright (c) 2017 Tuomas Tynkkynen
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>
>>
>> This is not needed as gd is not referenced in this file.
>>
>
> Now removed.
>
> 

Re: [U-Boot] [PATCH 03/23] efi_loader: support 16 protocols per efi_object

[Heinrich Schuchardt]

On 08/31/2017 04:01 PM, Alexander Graf wrote:
> On 08/27/2017 12:51 AM, Heinrich Schuchardt wrote:
>> 8 protocols per efi_object is insufficient for iPXE.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>   include/efi_loader.h | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 6f71a6202b..e8fb4fbb0a 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -99,8 +99,8 @@ struct efi_handler {
>>   struct efi_object {
>>   /* Every UEFI object is part of a global object list */
>>   struct list_head link;
>> -/* We support up to 8 "protocols" an object can be accessed
>> through */
>> -struct efi_handler protocols[8];
>> +/* We support up to 16 "protocols" an object can be accessed
>> through */
>> +struct efi_handler protocols[16];
> 
> Can you try to convert it into a list instead? Leif tried to make the
> UEFI Shell work and stumbled over the same limitation, so I guess a
> static array won't cut it for long.
> 
> 
> Alex
> 
> 

Hello Alex,

is it safe to call malloc and free before efi_exit_boot_services?

Currently we do not check that boottime services are not called after
efi_exit_boot_services. Shouldn't every call to boottime services fail
thereafter? The spec says: "After successfully calling
ExitBootServices(), all boot services in the system are terminated."

We definitively do not want to call malloc at runtime because all
available memory (except for EFI_MEMORY_RUNTIME) is managed by the
operating system.

Best regards

Heinrich

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

Re: [U-Boot] [PATCH v3 1/8] spi: add support of SPI flash commands

[Wenyou.Yang]

Hi Jagan,

Thank you for your comments.

I will rework this patch set according to your advice. Thank you!


Best Regards,
Wenyou Yang

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: 2017年8月30日 21:50
> To: Wenyou Yang - A41535 
> Cc: U-Boot Mailing List ; Marek Vasut ;
> Cyrille Pitchen ; Jagan Teki 
> Subject: Re: [U-Boot] [PATCH v3 1/8] spi: add support of SPI flash commands
> 
> On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang 
> wrote:
> > From: Cyrille Pitchen 
> >
> > This patch introduces 'struct spi_flash_command' and functions
> > spi_is_flash_command_supported() / spi_exec_flash_command().
> >
> 
> Answer for why this shouldn't be part of SPI area.
> 
> [snip]
> 
> drivers/spi and include/spi.h is Generic SPI area code - this can deal all
> connected slave devices like EEPROM, SPI-NOR etc drivers/mtd/spi and
> include/spi_flash.h is SPI-Flash or SPI-NOR code - this can handle only SPI
> flashes.
> 
> >
> > +bool dm_spi_is_flash_command_supported(struct udevice *dev,
> > +  const struct spi_flash_command
> > +*cmd) {
> > +   struct udevice *bus = dev->parent;
> > +   struct dm_spi_ops *ops = spi_get_ops(bus);
> > +
> > +   if (ops->is_flash_command_supported)
> > +   return ops->is_flash_command_supported(dev, cmd);
> > +
> > +   return false;
> > +}
> > +
> > +int dm_spi_exec_flash_command(struct udevice *dev,
> > + const struct spi_flash_command *cmd) {
> > +   struct udevice *bus = dev->parent;
> > +   struct dm_spi_ops *ops = spi_get_ops(bus);
> > +
> > +   if (ops->exec_flash_command)
> > +   return ops->exec_flash_command(dev, cmd);
> > +
> > +   return -EINVAL;
> > +}
> > +
> >  int spi_claim_bus(struct spi_slave *slave)  {
> > return dm_spi_claim_bus(slave->dev); @@ -107,6 +131,18 @@ int
> > spi_xfer(struct spi_slave *slave, unsigned int bitlen,
> > return dm_spi_xfer(slave->dev, bitlen, dout, din, flags);  }
> >
> > +bool spi_is_flash_command_supported(struct spi_slave *slave,
> > +   const struct spi_flash_command
> > +*cmd) {
> > +   return dm_spi_is_flash_command_supported(slave->dev, cmd); }
> > +
> > +int spi_exec_flash_command(struct spi_slave *slave,
> > +  const struct spi_flash_command *cmd) {
> > +   return dm_spi_exec_flash_command(slave->dev, cmd); }
> 
> Handling spi-flash stuff in spi core is not proper way of dealing, and I saw 
> these
> functions are not-at-all needed for generic controller drivers in drivers/spi 
> except
> the Atmel QSPI driver (in v3,8/8).
> 
> > +
> >  #if !CONFIG_IS_ENABLED(OF_PLATDATA)
> >  static int spi_child_post_bind(struct udevice *dev)  { @@ -144,6
> > +180,10 @@ static int spi_post_probe(struct udevice *bus)
> > ops->set_mode += gd->reloc_off;
> > if (ops->cs_info)
> > ops->cs_info += gd->reloc_off;
> > +   if (ops->is_flash_command_supported)
> > +   ops->is_flash_command_supported += gd->reloc_off;
> > +   if (ops->exec_flash_command)
> > +   ops->exec_flash_command += gd->reloc_off;
> >  #endif
> >
> > return 0;
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index
> > 7d81fbd7f8..e47acdc9e4 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -5,6 +5,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -58,3 +59,15 @@ struct spi_slave *spi_base_setup_slave_fdt(const void
> *blob, int busnum,
> > return spi_setup_slave(busnum, cs, max_hz, mode);  }  #endif
> > +
> > +__weak bool spi_is_flash_command_supported(struct spi_slave *slave,
> > +  const struct
> > +spi_flash_command *cmd) {
> > +   return false;
> > +}
> > +
> > +__weak int spi_exec_flash_command(struct spi_slave *slave,
> > + const struct spi_flash_command *cmd)
> > +{
> > +   return -EINVAL;
> > +}
> > diff --git a/include/spi.h b/include/spi.h index
> > 8c4b882c54..a090266b52 100644
> > --- a/include/spi.h
> > +++ b/include/spi.h
> > @@ -10,6 +10,8 @@
> >  #ifndef _SPI_H_
> >  #define _SPI_H_
> >
> > +#include  /* memset() */
> > +
> >  /* SPI mode flags */
> >  #define SPI_CPHA   BIT(0)  /* clock phase */
> >  #define SPI_CPOL   BIT(1)  /* clock polarity */
> > @@ -64,6 +66,116 @@ struct dm_spi_slave_platdata {  #endif /*
> > CONFIG_DM_SPI */
> >
> >  /**
> > + * enum spi_flash_protocol - SPI flash command protocol  */ #define
> > +SPI_FPROTO_INST_SHIFT  16
> > +#define SPI_FPROTO_INST_MASK   GENMASK(23, 16)
> > +#define SPI_FPROTO_INST(nbits) \
> > +   unsigned 

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Troy Kisky]

On 8/31/2017 4:04 PM, Eric Nelson wrote:
> On 08/31/2017 03:53 PM, Troy Kisky wrote:
>> On 8/31/2017 2:28 PM, Troy Kisky wrote:
>>
>>>
>>> Maybe if you change the WDOG pinmux it might work ?
>>>
>>>
>>
>> Worked for me
>>
>> => mm.l 302c
>> 302c: 0003 ? 0
>> 302c0004: 0001 ? q
>> => bmod usb
>> resetting ...
>>
> 
> Hmm...
> 
> On SABRE-SD or Nitrogen7?
> 

Nitrogen7,

It does show up in lsusb afterwards
Bus 003 Device 100: ID 15a2:0076 Freescale Semiconductor, Inc.

But imx_usb gets errors afterwards

== work item
filename /tftpboot/u-boot.nitrogen7
load_size 0 bytes
load_addr 0x
dcd 1
clear_dcd 0
plug 1
jump_mode 2
jump_addr 0x
== end work item
loading DCD table @0x91

<<<-564, 1024 bytes>>>
report 3 in err=-7, last_trans=0  c4 34 03 32
report 4 in err=-7, last_trans=0  c4 34 03 32
failed (status 0x320334c4)



So, close but no cigar.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

On 08/31/2017 04:11 PM, Fabio Estevam wrote:

Troy,

On Thu, Aug 31, 2017 at 7:53 PM, Troy Kisky
 wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Ok, but did you manage to successfully transfer u-boot via imx_usb_loader?

It did not work for me.



Ditto here. The OTG port didn't re-enumerate.


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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Fabio Estevam]

Troy,

On Thu, Aug 31, 2017 at 7:53 PM, Troy Kisky
 wrote:
> On 8/31/2017 2:28 PM, Troy Kisky wrote:
>
>>
>> Maybe if you change the WDOG pinmux it might work ?
>>
>>
>
> Worked for me
>
> => mm.l 302c
> 302c: 0003 ? 0
> 302c0004: 0001 ? q
> => bmod usb
> resetting ...
>

Ok, but did you manage to successfully transfer u-boot via imx_usb_loader?

It did not work for me.

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

Re: [U-Boot] [PATCH] arm64: ls1043ardb: Add distro secure boot support

[York Sun]

On 06/04/2017 11:54 PM, Sumit Garg wrote:
> Enable validation of boot.scr script prior to its execution dependent
> on "secureboot" flag in environment. Disable fall back option to
> nor/qspi boot in case of secure boot. Also enable "secureboot=y"
> flag in environment for ARM based platforms instead of bootcmd.
> 
> Signed-off-by: Sumit Garg 
> Tested-by: Vinitha Pillai 
> ---
>   board/freescale/common/fsl_chain_of_trust.c |  6 ++
>   configs/ls1043ardb_SECURE_BOOT_defconfig|  1 +
>   configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig |  1 +
>   include/configs/ls1043a_common.h| 23 +--
>   4 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/board/freescale/common/fsl_chain_of_trust.c 
> b/board/freescale/common/fsl_chain_of_trust.c
> index 438e781..609e2b2 100644
> --- a/board/freescale/common/fsl_chain_of_trust.c
> +++ b/board/freescale/common/fsl_chain_of_trust.c
> @@ -80,7 +80,13 @@ int fsl_setenv_chain_of_trust(void)
>* bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)
>*/
>   setenv("bootdelay", "0");
> +
> +#ifdef CONFIG_ARM
> + setenv("secureboot", "y");
> +#else
>   setenv("bootcmd", CONFIG_CHAIN_BOOT_CMD);
> +#endif
> +
>   return 0;
>   }
>   #endif
> diff --git a/configs/ls1043ardb_SECURE_BOOT_defconfig 
> b/configs/ls1043ardb_SECURE_BOOT_defconfig
> index 861d49b..3f535cc 100644
> --- a/configs/ls1043ardb_SECURE_BOOT_defconfig
> +++ b/configs/ls1043ardb_SECURE_BOOT_defconfig
> @@ -40,3 +40,4 @@ CONFIG_USB_STORAGE=y
>   CONFIG_RSA=y
>   CONFIG_SPL_RSA=y
>   CONFIG_RSA_SOFTWARE_EXP=y
> +CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig 
> b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
> index 5f9b21d..2d57e79 100644
> --- a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
> +++ b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
> @@ -56,3 +56,4 @@ CONFIG_RSA=y
>   CONFIG_SPL_RSA=y
>   CONFIG_SPL_CRYPTO_SUPPORT=y
>   CONFIG_SPL_HASH_SUPPORT=y
> +CONFIG_DISTRO_DEFAULTS=y
> diff --git a/include/configs/ls1043a_common.h 
> b/include/configs/ls1043a_common.h
> index e8a756f..6e30427 100644
> --- a/include/configs/ls1043a_common.h
> +++ b/include/configs/ls1043a_common.h
> @@ -282,6 +282,7 @@
>   "fdt_addr=0x64f0\0"  \
>   "kernel_addr=0x6500\0"  \
>   "scriptaddr=0x8000\0"  \
> + "scripthdraddr=0x8008\0"\
>   "fdtheader_addr_r=0x8010\0" \
>   "kernelheader_addr_r=0x8020\0"  \
>   "kernel_addr_r=0x8100\0"\
> @@ -292,6 +293,7 @@
>   "mtdparts=" MTDPARTS_DEFAULT "\0"   \
>   BOOTENV \
>   "boot_scripts=ls1043ardb_boot.scr\0"\
> + "boot_script_hdr=hdr_ls1043ardb_bs.out\0"   \
>   "scan_dev_for_boot_part="  \
>"part list ${devtype} ${devnum} devplist; "   \
>"env exists devplist || setenv devplist 1; "  \
> @@ -302,6 +304,21 @@
> "run scan_dev_for_boot; " \
> "fi; "   \
> "done\0"\
> + "scan_dev_for_boot="  \
> + "echo Scanning ${devtype} "   \
> + "${devnum}:${distro_bootpart}...; "  \
> + "for prefix in ${boot_prefixes}; do " \
> + "run scan_dev_for_scripts; "  \
> + "done;"   \
> + "\0"  \
> + "boot_a_script="  \
> + "load ${devtype} ${devnum}:${distro_bootpart} "  \
> + "${scriptaddr} ${prefix}${script}; "\
> + "env exists secureboot && load ${devtype} " \
> + "${devnum}:${distro_bootpart} " \
> + "${scripthdraddr} ${prefix}${boot_script_hdr} " \
> + "&& esbc_validate ${scripthdraddr};"\
> + "source ${scriptaddr}\0"  \
>   "installer=load mmc 0:2 $load_addr "  \
>  "/flex_installer_arm64.itb; "  \
>  "bootm $load_addr#ls1043ardb\0"\
> @@ -315,9 +332,11 @@
>   
>   #undef CONFIG_BOOTCOMMAND
>   #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
> -#define CONFIG_BOOTCOMMAND "run distro_bootcmd;run qspi_bootcmd"
> +#define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot"   
> \
> +"&& esbc_halt; run qspi_bootcmd;"
>   #else
> -#define CONFIG_BOOTCOMMAND "run distro_bootcmd;run nor_bootcmd"
> +#define CONFIG_BOOTCOMMAND "run distro_bootcmd; env exists secureboot"   
> \
> +"&& esbc_halt; run nor_bootcmd;"
>   #endif
>   
>   #define CONFIG_BOOTARGS  

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

On 08/31/2017 03:53 PM, Troy Kisky wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Hmm...

On SABRE-SD or Nitrogen7?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Thanks Troy (and Peng),

On 08/31/2017 02:28 PM, Troy Kisky wrote:

On 8/31/2017 6:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam  wrote:

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson  wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson 


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C


Note the POR here (I would expect it to be WDOG).


Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB






I got this response from Peng when I asked him back in March of last year.


For now, bmode does not work. Since bmode use warm reset, but we now use
wdog to directly reset pmic. So bmode will not work.

Please check your code to see whether your board connect WDOG_B to pmic reset 
pin and have wdog

pinmux settings.


Thanks,
Peng.


Maybe if you change the WDOG pinmux it might work ?



The mx7dsabresd has GPIO1_IO00 configured for WDOG, and overriding it
does get rid of the POR.

Unfortunately, it also doesn't allow "bmode usb" to function.

=> mm 302c
302c: 0003 ? 0
302c0004:  ? x
=> bmode usb
resetting ...

(crickets here)

Based on this:

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Troy Kisky]

On 8/31/2017 2:28 PM, Troy Kisky wrote:

> 
> Maybe if you change the WDOG pinmux it might work ?
> 
> 

Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...

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

Re: [U-Boot] [PATCH 03/23] efi_loader: support 16 protocols per efi_object

[Alexander Graf]

On 08/27/2017 12:51 AM, Heinrich Schuchardt wrote:

8 protocols per efi_object is insufficient for iPXE.

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 6f71a6202b..e8fb4fbb0a 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -99,8 +99,8 @@ struct efi_handler {
  struct efi_object {
/* Every UEFI object is part of a global object list */
struct list_head link;
-   /* We support up to 8 "protocols" an object can be accessed through */
-   struct efi_handler protocols[8];
+   /* We support up to 16 "protocols" an object can be accessed through */
+   struct efi_handler protocols[16];


Can you try to convert it into a list instead? Leif tried to make the 
UEFI Shell work and stumbled over the same limitation, so I guess a 
static array won't cut it for long.



Alex

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Troy Kisky]

On 8/31/2017 6:56 AM, Fabio Estevam wrote:
> On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam  wrote:
>> Hi Eric,
>>
>> On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson  wrote:
>>> This adds support for two additional boot modes on the i.MX7D SoC, which
>>> is most useful when doing U-Boot development on this chip.
>>>
>>> 1. "bmode usb" can be used to force the ROM boot loader's serial
>>> 2. "bmode normal" can be used to revert to the normal boot mode
>>>as specified by fuses and BOOT_MODE pins
>>>
>>> Signed-off-by: Eric Nelson 
>>
>> I tried testing your patch on a imx7d sabresd, but it seems there is
>> an issue with bmode that is unrelated to your patch.
>>
>> I also did:
>>
>> diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
>> index 8f2e33a..c70fde8 100644
>> --- a/configs/mx7dsabresd_defconfig
>> +++ b/configs/mx7dsabresd_defconfig
>> @@ -5,7 +5,6 @@ CONFIG_VIDEO=y
>>  # CONFIG_ARMV7_VIRT is not set
>>  CONFIG_IMX_RDC=y
>>  CONFIG_IMX_BOOTAUX=y
>> -# CONFIG_CMD_BMODE is not set
>>  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
>>  
>> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
>>  CONFIG_BOOTDELAY=3
>>
>> so that bmode command can be added.
>>
>> However I am getting:
>>
>> => bmode usb
>> bmode - 
> 
> I missed to add 'add_board_boot_modes(board_boot_modes);'
> 
> Now I get:
> 
> => bmode usb
> resetting ...
> 
> 
> U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)
> 
> CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 41C
> Reset cause: POR
> Model: Freescale i.MX7 SabreSD Board
> Board: i.MX7D SABRESD in non-secure mode
> DRAM:  1 GiB
> PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:
> MMC Device 0 not found
> *** Warning - No MMC card found, using default environment
> 
> Video: 480x272x24
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC0
> Hit any key to stop autoboot:  0
> =>
> 
> So the board is resetting instead of going into serial download mode.
> 
> Any ideas?
> 
>


I got this response from Peng when I asked him back in March of last year.


> For now, bmode does not work. Since bmode use warm reset, but we now use
> wdog to directly reset pmic. So bmode will not work.
>
> Please check your code to see whether your board connect WDOG_B to pmic reset 
> pin and have wdog
pinmux settings.
>
> Thanks,
> Peng.



Maybe if you change the WDOG pinmux it might work ?


Troy

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

Re: [U-Boot] [PATCH 01/23] efi_loader: allow return value in EFI_CALL

[Alexander Graf]

On 08/31/2017 02:51 PM, Simon Glass wrote:

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:

Macro EFI_CALL was introduced to call an UEFI function.

Should this be 'an EFI'. Or 'a UEFI'?


In a nutshell, EFI is the v1, proprietary, for pay, closed protocol 
while UEFI is v2 and what edk2 implements, what you can get specs for, 
etc. But since people started implementing things for v1 back in the day 
and they are reasonable compatible, nobody calls UEFI UEFI, but just EFI :).


It's a mess and I certainly didn't help it by calling everything EFI, 
but it's what we're in and we should rather stay coherent IMHO. So 
EFI_CALL really does call UEFI functions ;).



Alex

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

Re: [U-Boot] [PATCH 1/1] usb: gadget: g_dnl: Use serial# variable to set g_dnl_serial

[Łukasz Majewski]

On 08/31/2017 08:45 PM, Sam Protsenko wrote:

On 31 August 2017 at 21:20, Sam Protsenko  wrote:

Since 842778a09104 commit, "fastboot devices" stopped to show correct
device serial number for TI boards, showing this line instead:

fastboot

This is because serial# env variable could be set after g_dnl gadget was
initialized (e.g. by using env_set() in the board file).

To fix this, before checking g_dnl_serial, let's re-check if we have
valid serial# value. And if so, let's set it as g_dnl_serial value.

Signed-off-by: Sam Protsenko 
---
 drivers/usb/gadget/g_dnl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 0491a0eea9..e4d0289757 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -226,6 +226,15 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)

g_dnl_bind_fixup(_desc, cdev->driver->name);

+   /* First try to obtain serial number from serial# variable */
+   if (strlen(g_dnl_serial) == 0) {
+   const char *s;
+
+   s = env_get("serial#");
+   if (s)
+   g_dnl_set_serialnumber((char *)s);
+   }
+
if (strlen(g_dnl_serial)) {
id = usb_string_id(cdev);
if (id < 0)
--
2.14.1



Similar commit: [1]. But I'm not sure that implementing
g_dnl_bind_fixup() in board file is the best way to fix it.

[1] 
http://git.denx.de/?p=u-boot.git;a=commit;h=e91ead868b536d0a0dc49aa48f4d8c80c1a94b79



I would opt for having g_dnl_bind_fixup() since it is generally used for 
tweaking board specific data to gadget subsystem (like vid, pid, serial 
number).



--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH v2] dm: core: Add livetree documentation

[Łukasz Majewski]

On 08/31/2017 02:00 PM, Simon Glass wrote:

On 31 August 2017 at 19:59, Simon Glass  wrote:

Add some documentation for the live device tree support in U-Boot. This
was missing from the initial series.

Signed-off-by: Simon Glass 
Suggested-by: Lukasz Majewski 


Reviewed-by: Łukasz Majewski 

(I hope this is OK, I just fixed the typos)



Thanks :-)

--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH 1/1] usb: gadget: g_dnl: Use serial# variable to set g_dnl_serial

[Sam Protsenko]

On 31 August 2017 at 21:20, Sam Protsenko  wrote:
> Since 842778a09104 commit, "fastboot devices" stopped to show correct
> device serial number for TI boards, showing this line instead:
>
> fastboot
>
> This is because serial# env variable could be set after g_dnl gadget was
> initialized (e.g. by using env_set() in the board file).
>
> To fix this, before checking g_dnl_serial, let's re-check if we have
> valid serial# value. And if so, let's set it as g_dnl_serial value.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/usb/gadget/g_dnl.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
> index 0491a0eea9..e4d0289757 100644
> --- a/drivers/usb/gadget/g_dnl.c
> +++ b/drivers/usb/gadget/g_dnl.c
> @@ -226,6 +226,15 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)
>
> g_dnl_bind_fixup(_desc, cdev->driver->name);
>
> +   /* First try to obtain serial number from serial# variable */
> +   if (strlen(g_dnl_serial) == 0) {
> +   const char *s;
> +
> +   s = env_get("serial#");
> +   if (s)
> +   g_dnl_set_serialnumber((char *)s);
> +   }
> +
> if (strlen(g_dnl_serial)) {
> id = usb_string_id(cdev);
> if (id < 0)
> --
> 2.14.1
>

Similar commit: [1]. But I'm not sure that implementing
g_dnl_bind_fixup() in board file is the best way to fix it.

[1] 
http://git.denx.de/?p=u-boot.git;a=commit;h=e91ead868b536d0a0dc49aa48f4d8c80c1a94b79
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imx: imx7d: remove CamelCase from ENET_xMHz macros

[Stefano Babic]

Hi Eric,

On 31/08/2017 17:34, Eric Nelson wrote:
> Update these macros to use all upper-case to avoid checkpatch
> warnings:
> 
>   ENET_25MHz,
>   ENET_50MHz,
>   ENET_125MHz,
> 
> Signed-off-by: Eric Nelson 
> ---
> V2 fixes a couple of references in mx7/clock.c
>  arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
>  arch/arm/mach-imx/mx7/clock.c | 6 +++---
>  board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
>  board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
>  board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
>  5 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
> b/arch/arm/include/asm/arch-mx7/clock.h
> index 688d236..3b115ad 100644
> --- a/arch/arm/include/asm/arch-mx7/clock.h
> +++ b/arch/arm/include/asm/arch-mx7/clock.h
> @@ -318,9 +318,9 @@ struct clk_root_map {
>  };
>  
>  enum enet_freq {
> - ENET_25MHz,
> - ENET_50MHz,
> - ENET_125MHz,
> + ENET_25MHZ,
> + ENET_50MHZ,
> + ENET_125MHZ,
>  };
>  
>  u32 get_root_clk(enum clk_root_index clock_id);
> diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
> index 2cfde46..8150faa 100644
> --- a/arch/arm/mach-imx/mx7/clock.c
> +++ b/arch/arm/mach-imx/mx7/clock.c
> @@ -966,15 +966,15 @@ int set_clk_enet(enum enet_freq type)
>   clock_enable(CCGR_ENET2, 0);
>  
>   switch (type) {
> - case ENET_125MHz:
> + case ENET_125MHZ:
>   enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
>   enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
>   break;
> - case ENET_50MHz:
> + case ENET_50MHZ:
>   enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
>   enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
>   break;
> - case ENET_25MHz:
> + case ENET_25MHZ:
>   enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
>   enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
>   break;
> diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
> b/board/freescale/mx7dsabresd/mx7dsabresd.c
> index a681ece..5819b18 100644
> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
> @@ -260,7 +260,7 @@ static int setup_fec(void)
>   (IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
>IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
>  
> - return set_clk_enet(ENET_125MHz);
> + return set_clk_enet(ENET_125MHZ);
>  }
>  
>  
> diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
> b/board/technexion/pico-imx7d/pico-imx7d.c
> index b4c9be7..67bab51 100644
> --- a/board/technexion/pico-imx7d/pico-imx7d.c
> +++ b/board/technexion/pico-imx7d/pico-imx7d.c
> @@ -182,7 +182,7 @@ static int setup_fec(void)
>   (IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
>   IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
>  
> - return set_clk_enet(ENET_125MHz);
> + return set_clk_enet(ENET_125MHZ);
>  }
>  
>  int board_phy_config(struct phy_device *phydev)
> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
> b/board/toradex/colibri_imx7/colibri_imx7.c
> index 5cb14b4..13b2b57 100644
> --- a/board/toradex/colibri_imx7/colibri_imx7.c
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -280,7 +280,7 @@ static int setup_fec(void)
>   IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
>  #endif
>  
> - return set_clk_enet(ENET_50MHz);
> + return set_clk_enet(ENET_50MHZ);
>  }
>  
>  int board_phy_config(struct phy_device *phydev)
> 


Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

[U-Boot] [PATCH 1/1] usb: gadget: g_dnl: Use serial# variable to set g_dnl_serial

[Sam Protsenko]

Since 842778a09104 commit, "fastboot devices" stopped to show correct
device serial number for TI boards, showing this line instead:

fastboot

This is because serial# env variable could be set after g_dnl gadget was
initialized (e.g. by using env_set() in the board file).

To fix this, before checking g_dnl_serial, let's re-check if we have
valid serial# value. And if so, let's set it as g_dnl_serial value.

Signed-off-by: Sam Protsenko 
---
 drivers/usb/gadget/g_dnl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 0491a0eea9..e4d0289757 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -226,6 +226,15 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)
 
g_dnl_bind_fixup(_desc, cdev->driver->name);
 
+   /* First try to obtain serial number from serial# variable */
+   if (strlen(g_dnl_serial) == 0) {
+   const char *s;
+
+   s = env_get("serial#");
+   if (s)
+   g_dnl_set_serialnumber((char *)s);
+   }
+
if (strlen(g_dnl_serial)) {
id = usb_string_id(cdev);
if (id < 0)
-- 
2.14.1

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

Re: [U-Boot] [ANN] U-Boot v2017.09-rc3 released

[Sam Protsenko]

On 29 August 2017 at 05:56, Tom Rini  wrote:
> Hey all,
>
> It's release day and v2017.09-rc3 is out.  I think there's still a few
> outstanding important bugfixes that need to come in, and probably a few
> more Kconfig migrations as well.
>
> If anyone has critical fixes I've missed please speak up.  I think I've
> got an idea on what they are but never the less, better to speak up now
> than assume i saw it.
>

"fastboot devices" is broken for TI boards (since 842778a09104
commit). Will send fix shortly.

> Things look on track for rc4 on the 4th of September and then a final
> release on the 11th..  Thanks all!
>
> --
> Tom
>
> ___
> 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] [ANN] U-Boot v2017.09-rc3 released

[Peter Robinson]

On Tue, Aug 29, 2017 at 5:44 AM, Jonathan Gray  wrote:
> On Mon, Aug 28, 2017 at 10:56:52PM -0400, Tom Rini wrote:
>> Hey all,
>>
>> It's release day and v2017.09-rc3 is out.  I think there's still a few
>> outstanding important bugfixes that need to come in, and probably a few
>> more Kconfig migrations as well.
>
> The tag/changes not pushed to git yet?

I'm still not seeing RC3 in git either.

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

Re: [U-Boot] [PATCH 12/23] efi_loader: implement OpenProtocolInformation

[Heinrich Schuchardt]

On 08/31/2017 02:51 PM, Simon Glass wrote:
> Hi Heinrich,
> 
> On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
>> efi_open_protocol_information provides the agent and controller
>> handles as well as the attributes and open count of an protocol
>> on a handle.
>>
>> Cc: Rob Clark 
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  lib/efi_loader/efi_boottime.c | 55 
>> ++-
>>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
> I can't help wondering if this would be better as a linked list?

This is an API function. The interface of the function has to be kept
the way it is.

Internally we could use other storage models.

Best regards

Heinrich

> 
>>
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index c9aec597a2..23b8894e73 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -985,9 +985,62 @@ static efi_status_t EFIAPI 
>> efi_open_protocol_information(efi_handle_t handle,
>> struct efi_open_protocol_info_entry **entry_buffer,
>> unsigned long *entry_count)
>>  {
>> +   unsigned long buffer_size;
>> +   unsigned long count;
>> +   struct efi_handler *handler;
>> +   size_t i;
>> +   efi_status_t r;
>> +
>> EFI_ENTRY("%p, %p, %p, %p", handle, protocol, entry_buffer,
>>   entry_count);
>> -   return EFI_EXIT(EFI_NOT_FOUND);
>> +
>> +   /* Check parameters */
>> +   if (!handle || !protocol || !entry_buffer) {
>> +   r = EFI_INVALID_PARAMETER;
>> +   goto out;
>> +   }
>> +
>> +   /* Find the protocol */
>> +   r = efi_search_protocol(handle, protocol, );
>> +   if (r != EFI_SUCCESS)
>> +   goto out;
>> +
>> +   *entry_buffer = NULL;
>> +
>> +   /* Count entries */
>> +   count = 0;
>> +   for (i = 0; i < ARRAY_SIZE(handler->open_info); ++i) {
>> +   struct efi_open_protocol_info_entry *open_info =
>> +   >open_info[i];
>> +
>> +   if (open_info->open_count)
>> +   ++count;
>> +   }
>> +   *entry_count = count;
>> +   if (!count) {
>> +   r = EFI_SUCCESS;
>> +   goto out;
>> +   }
>> +
>> +   /* Copy entries */
>> +   buffer_size = count * sizeof(struct efi_open_protocol_info_entry);
>> +   r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES, buffer_size,
>> + (void **)entry_buffer);
>> +   if (r != EFI_SUCCESS)
>> +   goto out;
>> +   count = 0;
>> +   for (i = 0; i < ARRAY_SIZE(handler->open_info); ++i) {
>> +   struct efi_open_protocol_info_entry *open_info =
>> +   >open_info[i];
>> +
>> +   if (!open_info->open_count)
>> +   continue;
>> +   (*entry_buffer)[count] = *open_info;
>> +   ++count;
>> +   }
>> +
>> +out:
>> +   return EFI_EXIT(r);
>>  }
>>
>>  static efi_status_t EFIAPI efi_protocols_per_handle(void *handle,
>> --
>> 2.14.1
>>
> 

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

Re: [U-Boot] ** Can't read Driver Desriptor Block **

[Heinrich Schuchardt]

On 08/31/2017 02:55 PM, Bin Meng wrote:
> Hi Simon,
> 
> On Thu, Aug 31, 2017 at 8:52 PM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 31 August 2017 at 10:53, Bin Meng  wrote:
>>> Hi Heinrich,
>>>
>>> On Thu, Aug 31, 2017 at 5:19 AM, Heinrich Schuchardt  
>>> wrote:
 On 08/30/2017 06:37 AM, Heinrich Schuchardt wrote:
>
>
> On 08/30/2017 03:54 AM, Bin Meng wrote:
>> Hi Heinrich,
>>
>> On Wed, Aug 30, 2017 at 4:26 AM, Heinrich Schuchardt 
>>  wrote:
>>> Hello Simon,
>>>
>>> U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
>>> partition in qemu-system-x86_64.
>>>
>>> By bisection I found this patch.
>>>
>>> b7c6baef2891ce8978cbfddb66e944943473ac21
>>> x86: Convert MMC to driver model
>>>
>>> With this patch I get
>>>
>>> IDE:   Bus 0: OK Bus 1: OK
>>>   Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>>> Type: Hard Disk
>>> Supports 48-bit addressing
>>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>>> ** Can't read Driver Desriptor Block **
>>>   Device 1: not available
>>>   Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>>> Type: Removable CD ROM
>>> Capacity: not available
>>>   Device 3: not available
>>>
>>> => ide info
>>> =>
>>>
>>> Without the patch I get=> ide info
>>> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>>> Type: Hard Disk
>>> Supports 48-bit addressing
>>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>>> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>>> Type: Removable CD ROM
>>> Capacity: not available
>>>
>>> I think we observe two independent errors here:
>>>
>>> - The hard disk Device 0 is not read.
>>> - The ide command stops at the first device that is not available.
>>>
>>> I guess only the first is caused by your patch.
>>
>> Both logs look fine to me. The "Can't read Driver Desriptor Block"
>> comes from part_mac.c. Did you verify the actual IDE read/write fails
>> with current HEAD?
>>
>> Regards,
>> Bin
>>
>
> Hello Bin,
>
> I have not checked block level read but used the shell commands for 
> testing.
>
> Before the patch I can read the directory of the drive:
>
> => ide info
> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
> Type: Removable CD ROM
> Capacity: not available
> => fat2ls ide 0:1
> Unknown command 'fat2ls' - try 'help'
> => fatls ide 0:1
>164768   snp.efi
> 0   file1
> 0   file2
>
>
> After the patch (including HEAD) I cannot read the directory and cannot
> load the file snp.efi either:
>
> => ide info
> => fatls ide 0:1
> ** Bad device ide 0 **
> =>
> => fatls mmc 0:1
> ** Bad device mmc 0 **
>
>
> In both cases I have loaded the same image with:
>
> export BUILD_ROM=y
> make distclean && make qemu-x86_defconfig && make -j6
>
> qemu-system-x86_64 -m 1G -bios u-boot.rom -nographic \
> -netdev \
> user,id=eth0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
> -device e1000,netdev=eth0 -machine pc-i440fx-2.8 -hda img
>
> Best regards
>
> Heinrich
>

 Hello Bin, hello Simon,

 I think the bug is in functions ide_init (drivers/block/ide.c).

 Platform X86 implies CONFIG_BLK=y.

 So we should initialize ide_dev_desc[i].bdev.

 We don't, so blk_dread fails after finding no read operation with ENOSYS
 when called from part_test_dos.

 The following comment in include/blk.h confirms that bdev has to be filled:

 #if CONFIG_IS_ENABLED(BLK)
 /*
 * For now we have a few functions which take struct blk_desc as a
 * parameter. This field allows them to look up the associated
 * device. Once these functions are removed we can drop this field.
 */
 struct udevice *bdev;
 #else

 I assume that we have the same issue in in __sata_initialize
 (drivers/ata/sata.c) but have not tested.

>>>
>>> Thanks for the testing!
>>>
>>> Simon, are you going to fix this?
>>
>> I am not going to race you to it, if you are thinking of fixing it. I
>> am back from travels in a few days but have a busy week ahead and the
>> release is imminent :-(
>>
> 
> Or maybe Heinrich, do you plan to work on a fix? If not, I will put it
> on my todo list.
> 
> Regards,
> Bin
> 

Hello hello Bin,

I am aware 

Re: [U-Boot] efi_loader: GOP fix for no display

[Alexander Graf]

> uclass_first_device() returns 0 if there is no device, but error if
> there is a device that failed to probe.
> 
> Signed-off-by: Rob Clark 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [U-Boot, v2] efi_loader: LocateHandle should return EFI_NOT_FOUND if none found

[Alexander Graf]

> Spotted this debugging OpenBSD's bootloader in qemu.  (Wouldn't really
> fix anything, the problem was not having any disks, but we should
> probably return the correct error code.)
> 
> Signed-off-by: Rob Clark 
> Reviewed-by: Heinrich Schuchardt 

Thanks, applied to efi-next

Alex

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

[U-Boot] [PATCH v2] imx: imx7d: remove CamelCase from ENET_xMHz macros

[Eric Nelson]

Update these macros to use all upper-case to avoid checkpatch
warnings:

ENET_25MHz,
ENET_50MHz,
ENET_125MHz,

Signed-off-by: Eric Nelson 
---
V2 fixes a couple of references in mx7/clock.c
 arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
 arch/arm/mach-imx/mx7/clock.c | 6 +++---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
 board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
 board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
b/arch/arm/include/asm/arch-mx7/clock.h
index 688d236..3b115ad 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -318,9 +318,9 @@ struct clk_root_map {
 };
 
 enum enet_freq {
-   ENET_25MHz,
-   ENET_50MHz,
-   ENET_125MHz,
+   ENET_25MHZ,
+   ENET_50MHZ,
+   ENET_125MHZ,
 };
 
 u32 get_root_clk(enum clk_root_index clock_id);
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 2cfde46..8150faa 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -966,15 +966,15 @@ int set_clk_enet(enum enet_freq type)
clock_enable(CCGR_ENET2, 0);
 
switch (type) {
-   case ENET_125MHz:
+   case ENET_125MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
break;
-   case ENET_50MHz:
+   case ENET_50MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
break;
-   case ENET_25MHz:
+   case ENET_25MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
break;
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index a681ece..5819b18 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -260,7 +260,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
 IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..67bab51 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -182,7 +182,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 5cb14b4..13b2b57 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -280,7 +280,7 @@ static int setup_fec(void)
IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
 #endif
 
-   return set_clk_enet(ENET_50MHz);
+   return set_clk_enet(ENET_50MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3 1/2] armv8: fsl-lsch3: Add SD boot support for LS1088ARDB

[York Sun]

On 08/31/2017 04:14 AM, Ashish Kumar wrote:
> Add SD boot support for LS1088ARDB
> 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> ---
> v3:
> Depends upon
 > http://patchwork.ozlabs.org/patch/794217/

You know your dependency is not going to be accepted. Why do you send 
this patch?

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

Re: [U-Boot] [PATCH v2 2/2] armv8: mmu: add space around operator

[York Sun]

On 08/17/2017 12:56 AM, Andy Yan wrote:
> Add space around operator "+", make it
> match the coding style.
> 
> Signed-off-by: Andy Yan 
> ---
> 
> Changes in v2: None

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

Re: [U-Boot] [PATCH v2 1/2] armv8: mmu: remove unused macro definition

[York Sun]

On 08/17/2017 12:55 AM, Andy Yan wrote:
> Macro VA_BITS and PTE_BLOCK_BITS are not used
> in the code, so remove them.
> 
> Signed-off-by: Andy Yan 
> Reviewed-by: Philipp Tomsich 
> 
> ---
> 
> Changes in v2:
> - remove CONFIG_SYS_PTL2_BITS from the whitelist
> 
>   arch/arm/include/asm/armv8/mmu.h | 9 -
>   scripts/config_whitelist.txt | 2 --
>   2 files changed, 11 deletions(-)
> 

Reviewed-by: York Sun 

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Leif Lindholm]

On Wed, Aug 30, 2017 at 08:59:31AM +0100, Leif Lindholm wrote:
> On Wed, Aug 30, 2017 at 12:03:16AM +0200, Heinrich Schuchardt wrote:
> > I am able to provide a test application that will cover the API
> > functions that I have focused on (events, protocols, (dis)connect
> > controllers). To limit my effort I would like to write it for the HEAD
> > of my patch queue and not break it down into one test patch per
> > implementation patch. I hope that is ok for you. My effort estimate is
> > 40h+ so, please, be patient.
> 
> I am not going to claim that getting SCT to run under U-Boot is going
> to come near the top of my priority queue any time soon, and it would
> certainly be useful for some sort of "make sure we don't break what we
> have" tests.

Well, I spent a few hours looking at what the immediate issues may be
with running the UEFI Shell (built with -D NO_SHELL_PROFILES), same as
edk2/ShellBinPkg/MinUefiShell. Alex suggested I post an update.

I've implemented stubs for the missing protocols preventing the Shell
from starting properly, and pushed everything to
https://git.linaro.org/people/leif.lindholm/u-boot.git/log/?h=uefi-shell

(As Alex points out, I forgot about the EFI_EXIT/EFI_ENTER macros.)

With this, execution fails with
Found 2 disks
new_package_list: 99

ASSERT_EFI_ERROR (Status = Device Error)
ASSERT [Shell]
/work/git/edk2/Build/Shell/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/AutoGen.c(615):
!EFI_ERROR (Status)
"Synchronous Abort" handler, esr 0x5600dbdb

The AutoGen.c failure is a library constructor
(ShellLevel2CommandsLibConstructor) returning error because
MdeModulePkg/Library/UefiHiiLib/HiiLib.c : HiiAddPackages() received
an error return from new_package_list (in the non-camel-case u-boot
form).

If you could look into implementing something useful in that function,
I could look into what causes the next stumbling block after that.

I did overrun the "maximum number of open protocols" limit, so
randomly bumped that up to 12. It will need to go higher (and
preferably dynamic). As long as we're not planning to support
protocols staying around at runtime, I'd say that shouldn't be too
hard to resolve properly.

I have pushed an update to the pre-built versions of UEFI Shell in edk2:
https://github.com/tianocore/edk2/tree/master/ShellBinPkg/MinUefiShell
These are built without ASSERTs, so won't actually give the above
messages, but should otherwise be identical to the one I've used here.

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Hi Fabio,

On 08/31/2017 06:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam  wrote:

Hi Eric,

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson  wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson 


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:
MMC Device 0 not found
*** Warning - No MMC card found, using default environment

Video: 480x272x24
In:serial
Out:   serial
Err:   serial
Net:   FEC0
Hit any key to stop autoboot:  0
=>

So the board is resetting instead of going into serial download mode.

Any ideas?



I'm not sure. Since I'm currently working with a board with no
fuses blown, I'm getting USB mode either way ;)...

I have an MX7 SABRE SD and I'll try it out there.

Regards,


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

Re: [U-Boot] [PATCH v2] mtd/spi: Add MT35XU512ABA1G12 NOR flash support

[Jagan Teki]

On Thu, Aug 31, 2017 at 10:26 AM, Yogesh Gaur
 wrote:
> Add MT35XU512ABA1G12 parameters to NOR flash parameters array.
>
> The MT35XU512ABA1G12 only supports 1 bit mode and 8 bits. It can't support
> dual and quad. Supports subsector erase with 4KB granularity, have support
> of FSR(flag status register) and flash size is 64MB.
>
> Signed-off-by: Yogesh Gaur 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: rename Bananapi M3 dts file name

[Jagan Teki]

On Thu, Aug 31, 2017 at 7:35 PM, Maxime Ripard
 wrote:
> On Thu, Aug 31, 2017 at 10:01:40PM +0800, Chen-Yu Tsai wrote:
>> The upstream (Linux) device tree file for the Bananapi M3 follows the
>> convention of using the well known brand name, instead of the vendor
>> name, for naming. The file was recently added to upstream in commit
>> 359b5a1e1c2d ("ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi
>> BPI-M3")
>>
>> Rename the device tree file in U-boot to match.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> Acked-by: Maxime Ripard 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: sunxi: Only update timing mode bit when enabling new timing mode

[Jagan Teki]

On Thu, Aug 31, 2017 at 7:34 PM, Maxime Ripard
 wrote:
> On Thu, Aug 31, 2017 at 09:57:48PM +0800, Chen-Yu Tsai wrote:
>> When enabling the new mmc timing mode, we inadvertently clear all the
>> remaining bits in the new timing mode register. The bits cleared
>> include a default phase delay on the output clock. The BSP kernel
>> states that the default values are supposed to be used. Clearing them
>> results in decreased performance or transfer errors on some boards.
>>
>> Fixes: de9b1771c3b6 ("mmc: sunxi: Support new mode")
>> Signed-off-by: Chen-Yu Tsai 
>
> Acked-by: Maxime Ripard 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: rename Bananapi M3 dts file name

[Maxime Ripard]

On Thu, Aug 31, 2017 at 10:01:40PM +0800, Chen-Yu Tsai wrote:
> The upstream (Linux) device tree file for the Bananapi M3 follows the
> convention of using the well known brand name, instead of the vendor
> name, for naming. The file was recently added to upstream in commit
> 359b5a1e1c2d ("ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi
> BPI-M3")
> 
> Rename the device tree file in U-boot to match.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
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] [PATCH] mmc: sunxi: Only update timing mode bit when enabling new timing mode

[Maxime Ripard]

On Thu, Aug 31, 2017 at 09:57:48PM +0800, Chen-Yu Tsai wrote:
> When enabling the new mmc timing mode, we inadvertently clear all the
> remaining bits in the new timing mode register. The bits cleared
> include a default phase delay on the output clock. The BSP kernel
> states that the default values are supposed to be used. Clearing them
> results in decreased performance or transfer errors on some boards.
> 
> Fixes: de9b1771c3b6 ("mmc: sunxi: Support new mode")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
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

[U-Boot] [PATCH] sunxi: rename Bananapi M3 dts file name

[Chen-Yu Tsai]

The upstream (Linux) device tree file for the Bananapi M3 follows the
convention of using the well known brand name, instead of the vendor
name, for naming. The file was recently added to upstream in commit
359b5a1e1c2d ("ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi
BPI-M3")

Rename the device tree file in U-boot to match.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile | 4 ++--
 .../{sun8i-a83t-sinovoip-bpi-m3.dts => sun8i-a83t-bananapi-m3.dts}| 0
 configs/Sinovoip_BPI_M3_defconfig | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/dts/{sun8i-a83t-sinovoip-bpi-m3.dts => 
sun8i-a83t-bananapi-m3.dts} (100%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 762429c463d1..b7550104c340 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -307,8 +307,8 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
sun8i-r16-parrot.dtb
 dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
-   sun8i-a83t-cubietruck-plus.dtb \
-   sun8i-a83t-sinovoip-bpi-m3.dtb
+   sun8i-a83t-bananapi-m3.dtb \
+   sun8i-a83t-cubietruck-plus.dtb
 dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
diff --git a/arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts 
b/arch/arm/dts/sun8i-a83t-bananapi-m3.dts
similarity index 100%
rename from arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts
rename to arch/arm/dts/sun8i-a83t-bananapi-m3.dts
diff --git a/configs/Sinovoip_BPI_M3_defconfig 
b/configs/Sinovoip_BPI_M3_defconfig
index c53ade0c9715..b4602d41e3df 100644
--- a/configs/Sinovoip_BPI_M3_defconfig
+++ b/configs/Sinovoip_BPI_M3_defconfig
@@ -13,7 +13,7 @@ CONFIG_USB1_VBUS_PIN="PD24"
 CONFIG_AXP_GPIO=y
 CONFIG_SATAPWR="PD25"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
-CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-sinovoip-bpi-m3"
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 CONFIG_SPL=y
-- 
2.14.1

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

[U-Boot] [PATCH] mmc: sunxi: Only update timing mode bit when enabling new timing mode

[Chen-Yu Tsai]

When enabling the new mmc timing mode, we inadvertently clear all the
remaining bits in the new timing mode register. The bits cleared
include a default phase delay on the output clock. The BSP kernel
states that the default values are supposed to be used. Clearing them
results in decreased performance or transfer errors on some boards.

Fixes: de9b1771c3b6 ("mmc: sunxi: Support new mode")
Signed-off-by: Chen-Yu Tsai 
---
 drivers/mmc/sunxi_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index a76e763bfd4f..4edb4be46c81 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -167,7 +167,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
if (new_mode) {
 #ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
val = CCM_MMC_CTRL_MODE_SEL_NEW;
-   writel(SUNXI_MMC_NTSR_MODE_SEL_NEW, >reg->ntsr);
+   setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
 #endif
} else {
val = CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
-- 
2.14.1

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Fabio Estevam]

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam  wrote:
> Hi Eric,
>
> On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson  wrote:
>> This adds support for two additional boot modes on the i.MX7D SoC, which
>> is most useful when doing U-Boot development on this chip.
>>
>> 1. "bmode usb" can be used to force the ROM boot loader's serial
>> 2. "bmode normal" can be used to revert to the normal boot mode
>>as specified by fuses and BOOT_MODE pins
>>
>> Signed-off-by: Eric Nelson 
>
> I tried testing your patch on a imx7d sabresd, but it seems there is
> an issue with bmode that is unrelated to your patch.
>
> I also did:
>
> diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
> index 8f2e33a..c70fde8 100644
> --- a/configs/mx7dsabresd_defconfig
> +++ b/configs/mx7dsabresd_defconfig
> @@ -5,7 +5,6 @@ CONFIG_VIDEO=y
>  # CONFIG_ARMV7_VIRT is not set
>  CONFIG_IMX_RDC=y
>  CONFIG_IMX_BOOTAUX=y
> -# CONFIG_CMD_BMODE is not set
>  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
>  
> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
>  CONFIG_BOOTDELAY=3
>
> so that bmode command can be added.
>
> However I am getting:
>
> => bmode usb
> bmode - 

I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:
MMC Device 0 not found
*** Warning - No MMC card found, using default environment

Video: 480x272x24
In:serial
Out:   serial
Err:   serial
Net:   FEC0
Hit any key to stop autoboot:  0
=>

So the board is resetting instead of going into serial download mode.

Any ideas?

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Fabio Estevam]

Hi Eric,

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson  wrote:
> This adds support for two additional boot modes on the i.MX7D SoC, which
> is most useful when doing U-Boot development on this chip.
>
> 1. "bmode usb" can be used to force the ROM boot loader's serial
> 2. "bmode normal" can be used to revert to the normal boot mode
>as specified by fuses and BOOT_MODE pins
>
> Signed-off-by: Eric Nelson 

I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
 # CONFIG_ARMV7_VIRT is not set
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
 CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
 CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 

Usage:
bmode
=> bmode normal
bmode - 

Usage:
bmode
=>

Any ideas?

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

[U-Boot] [PATCH] arm: am33xx: Make pin multiplexing functions optional

[Felix Brack]

Boards using the single-register-pin-controller can  configure all
pins by means of the device tree. This renders the implementation of
the two functions set_uart_mux_conf and set_mux_conf_regs obsolete.
Using the weak attribute for these two function declarations allows
the omission of the respective definitions.

Signed-off-by: Felix Brack 
---

 arch/arm/include/asm/arch-am33xx/sys_proto.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 4e78aaf..e31c25c 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -31,8 +31,8 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, const 
struct gpmc_cs *cs, u32
u32 size);
 int omap_nand_switch_ecc(uint32_t, uint32_t);
 
-void set_uart_mux_conf(void);
-void set_mux_conf_regs(void);
+__weak void set_uart_mux_conf(void);
+__weak void set_mux_conf_regs(void);
 void sdram_init(void);
 u32 wait_on_value(u32, u32, void *, u32);
 #ifdef CONFIG_NOR_BOOT
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 03/40] dm: blk: Add a generic function for block device commands

[Bin Meng]

Hi Simon,

On Thu, Aug 31, 2017 at 8:51 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 1 August 2017 at 12:56, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Sun, Jul 30, 2017 at 1:34 AM, Simon Glass  wrote:
>>> Most block devices provide a command (e.g. 'sata', 'scsi', 'ide') and
>>> these commands generally do the same thing. This makes it harder to
>>> maintain this code and keep it consistent.
>>>
>>> We now have a block device interface which is either implemented by driver
>>> model (when CONFIG_BLK is enabled) or with a legacy interface. Therefore
>>> it is possible to handle most of what these commands do with generic code.
>>>
>>> Add a new generic function to process block-device commands using the
>>> interface type and the current device number for that type.
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>  cmd/Makefile |   1 +
>>>  cmd/blk_common.c | 104 
>>> +++
>>>  include/blk.h|  12 +++
>>>  3 files changed, 117 insertions(+)
>>>  create mode 100644 cmd/blk_common.c
>>>
>>> diff --git a/cmd/Makefile b/cmd/Makefile
>>> index bd231f24d8..e2b3a9cc71 100644
>>> --- a/cmd/Makefile
>>> +++ b/cmd/Makefile
>>> @@ -15,6 +15,7 @@ obj-y += version.o
>>>  # command
>>>  obj-$(CONFIG_CMD_AES) += aes.o
>>>  obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
>>> +obj-y += blk_common.o
>>>  obj-$(CONFIG_SOURCE) += source.o
>>>  obj-$(CONFIG_CMD_SOURCE) += source.o
>>>  obj-$(CONFIG_CMD_BDI) += bdinfo.o
>>> diff --git a/cmd/blk_common.c b/cmd/blk_common.c
>>> new file mode 100644
>>> index 00..86c75e78d8
>>> --- /dev/null
>>> +++ b/cmd/blk_common.c
>>> @@ -0,0 +1,104 @@
>>> +/*
>>> + * Handling of common block commands
>>> + *
>>> + * Copyright (c) 2017 Google, Inc
>>> + *
>>> + * (C) Copyright 2000-2011
>>> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#ifdef HAVE_BLOCK_DEVICE
>>> +int blk_common_cmd(int argc, char * const argv[], enum if_type if_type,
>>> +  int *cur_devnump)
>>> +{
>>> +   const char *if_name = blk_get_if_type_name(if_type);
>>> +
>>> +   switch (argc) {
>>> +   case 0:
>>> +   case 1:
>>> +   return CMD_RET_USAGE;
>>> +   case 2:
>>> +   if (strncmp(argv[1], "inf", 3) == 0) {
>>> +   blk_list_devices(if_type);
>>> +   return 0;
>>> +   } else if (strncmp(argv[1], "dev", 3) == 0) {
>>> +   if (blk_print_device_num(if_type, *cur_devnump)) {
>>> +   printf("\nno %s devices available\n", 
>>> if_name);
>>> +   return CMD_RET_FAILURE;
>>> +   }
>>> +   return 0;
>>> +   } else if (strncmp(argv[1], "part", 4) == 0) {
>>> +   if (blk_list_part(if_type))
>>> +   printf("\nno %s devices available\n", 
>>> if_name);
>>> +   return 0;
>>> +   }
>>> +   return CMD_RET_USAGE;
>>> +   case 3:
>>> +   if (strncmp(argv[1], "dev", 3) == 0) {
>>> +   int dev = (int)simple_strtoul(argv[2], NULL, 10);
>>> +
>>> +   if (!blk_show_device(if_type, dev)) {
>>> +   *cur_devnump = dev;
>>> +   printf("... is now current device\n");
>>> +   } else {
>>> +   return CMD_RET_FAILURE;
>>> +   }
>>> +   return 0;
>>> +   } else if (strncmp(argv[1], "part", 4) == 0) {
>>> +   int dev = (int)simple_strtoul(argv[2], NULL, 10);
>>> +
>>> +   if (blk_print_part_devnum(if_type, dev)) {
>>> +   printf("\n%s device %d not available\n",
>>> +  if_name, dev);
>>> +   return CMD_RET_FAILURE;
>>> +   }
>>> +   return 0;
>>> +   }
>>> +   return CMD_RET_USAGE;
>>> +
>>> +   default: /* at least 4 args */
>>> +   if (strcmp(argv[1], "read") == 0) {
>>> +   ulong addr = simple_strtoul(argv[2], NULL, 16);
>>> +   lbaint_t blk = simple_strtoul(argv[3], NULL, 16);
>>> +   ulong cnt = simple_strtoul(argv[4], NULL, 16);
>>> +   ulong n;
>>> +
>>> +   printf("\n%s read: device %d block # %lld, count 
>>> %ld ... ",
>>> +  if_name, *cur_devnump, (unsigned long 
>>> long)blk,
>>> +  cnt);
>>
>> Please use LBAFU for parameter blk, to handle both 32-bit and 64-bit LBA.
>

Re: [U-Boot] [UBOOT] [PATCH] cmd: usb: ignore block devices under mass storage device

[Simon Glass]

Hi Suneel,

On 15 August 2017 at 11:06, Suneel Garapati  wrote:
> Hi Simon,
>
>
> On Sun, Aug 13, 2017 at 2:37 PM, Simon Glass  wrote:
>> Hi Suneel,
>>
>> On 10 August 2017 at 23:53, Suneel Garapati  wrote:
>>> usb tree and info commands may cause crash otherwise
>>>
>>> Signed-off-by: Suneel Garapati 
>>> ---
>>>  cmd/usb.c | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>
>> Thank you for the patch - it certainly looks like a bug. Can you
>> please expand the commit message a little? E.g. you have
>> UCLASS_USB_EMUL below.
>
> I will change the description
>
>>
>>> diff --git a/cmd/usb.c b/cmd/usb.c
>>> index 992d414..81e1a7b 100644
>>> --- a/cmd/usb.c
>>> +++ b/cmd/usb.c
>>> @@ -415,7 +415,8 @@ static void usb_show_tree_graph(struct usb_device *dev, 
>>> char *pre)
>>> udev = dev_get_parent_priv(child);
>>>
>>> /* Ignore emulators, we only want real devices */
>>> -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
>>> +   if (device_get_uclass_id(child) !=
>>> +   (UCLASS_USB_EMUL | UCLASS_BLK)) {
>>
>> This seems odd to me. Do you mean to check that the child uclass is
>> neither USB_EMUL nor BLK?
>>
>> Would it be possible to check that the parent is UCLASS_USB? That
>> seems like a better condition to determine whether the child has USB
>> parent data.
>
> It is possible to check parent uclass but would that ever fail?

How would it fail? The only device that does not have a parent is the
root device, and we know it cannot be that since it will be
UCLASS_ROOT.

> I assume, block device under usb storage device will always have
> parent as usb class.

Yes that sounds right.

> Also, tree is called on only usb class devices. Maybe I am missing something.

Maybe, but I think it is more robust to check for the thing you want
than the things you don't. If someone adds a new thing that can be a
child then this code will need updating.

>
> Regards,
> Suneel
>
>>
>>> usb_show_tree_graph(udev, pre);
>>> pre[index] = 0;
>>> }
>>> @@ -605,7 +606,8 @@ static void usb_show_info(struct usb_device *udev)
>>> for (device_find_first_child(udev->dev, );
>>>  child;
>>>  device_find_next_child()) {
>>> -   if (device_active(child)) {
>>> +   if (device_active(child) &&
>>> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
>>> udev = dev_get_parent_priv(child);
>>> usb_show_info(udev);
>>> }
>>> --
>>> 2.7.4
>>>

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

Re: [U-Boot] [PATCH 21/23] efi_loader: fix efi_net_get_status

[Simon Glass]

On 27 August 2017 at 06:54, Heinrich Schuchardt  wrote:
> The returned interrupt status was wrong.
>
> As out transmit buffer is empty we need to always set
> EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT.
>
> When we have received a packet we need to set
> EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT.
>
> Furthermore we should call efi_timer_check() to handle events.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h|  6 ++
>  lib/efi_loader/efi_net.c | 11 ---
>  2 files changed, 14 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] [PATCH 22/23] efi_loader: set parent handle in efi_load_image

[Simon Glass]

On 27 August 2017 at 06:54, Heinrich Schuchardt  wrote:
> The parent_handle of the loaded image must be set.
> Add the file path protocol from the provided parameter.
> Set system table.
> Add parameter checks.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass 

A function comment on this would be nice
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/16] dtoc: Add support for 64-bit addresses

[Simon Glass]

Hi Philipp,

On 30 August 2017 at 18:12, Dr. Philipp Tomsich
 wrote:
>
>> On 30 Aug 2017, at 11:37, Simon Glass  wrote:
>>
>> Hi Philipp,
>>
>> On 30 August 2017 at 04:31, Dr. Philipp Tomsich
>>  wrote:
>>> Simon,
>>>
>>> I should be able to give this a test drive on the RK3368 by the end of the 
>>> week.
>>> For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise
>>> this there.
>>>
>>> Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the
>>> default on Puma) and this only blocks the RK3368 TPL (which is not enabled
>>> for any other boards than Lion): should we try to get this merged for this 
>>> release
>>> cycle or let it slip into the new merge window?
>>
>> My preference would be to put it in a next branch, but if nothing else
>> uses it then I suppose it is possible (up to you and Tom)? What is
>> broken that this fixes?
>
> RK3399: SPL for all platforms using OF_PLATDATA
> RK3368: TPL (uses OF_PLATDATA)
>
> Given that TPL for the RK3368 is not used much (and we have a private branch
> for people that need it), I don’t mind going with the ‘next’ branch.
>
> I know that Kever has a few board configurations (EVB-RK3399, Firefly-RK3399)
> that are affected, but I’d rather see these moved to OF_CONTROL instead of
> OF_PLATDATA.

Yes, I see OF_PLATDATA as an extreme measure to be used when we really have to.

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

Re: [U-Boot] [PATCH 16/23] efi_loader: implement DisconnectController

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 77 
> ++-
>  1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 1069da7d79..c5a17b6252 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1052,9 +1052,84 @@ static efi_status_t EFIAPI 
> efi_disconnect_controller(void *controller_handle,
>  void 
> *driver_image_handle,
>  void *child_handle)

Can you add a function comment?

>  {
> +   struct efi_driver_binding_protocol *binding_protocol;
> +   efi_handle_t child_handle_buffer;
> +   unsigned long driver_count;
> +   efi_handle_t *driver_handle_buffer;
> +   size_t i;
> +   UINTN number_of_children;

Can we somehow use a lower-case type for this? Otherwise U-Boot will
start to look like EFI and I will have to start taking
antidepressants.

> +   efi_status_t r;
> +   size_t stop_count = 0;
> +
> EFI_ENTRY("%p, %p, %p", controller_handle, driver_image_handle,
>   child_handle);
> -   return EFI_EXIT(EFI_INVALID_PARAMETER);
> +
> +   if (!efi_search_obj(controller_handle)) {
> +   r = EFI_INVALID_PARAMETER;
> +   goto out;
> +   }
> +
> +   /* Create list of driver handles */
> +   if (driver_image_handle) {
> +   driver_handle_buffer = _image_handle,
> +   driver_count = 1;
> +   /* Check that the handle supports driver binding protocol */
> +   r = efi_search_protocol(driver_image_handle,
> +   _guid_driver_binding_protocol,
> +   NULL);
> +   } else {
> +   /* Get buffer with all handles with driver binding protocol */
> +   r = EFI_CALL(efi_locate_handle_buffer(
> +by_protocol, _guid_driver_binding_protocol,
> +NULL, _count, _handle_buffer));
> +   }
> +   if (r != EFI_SUCCESS)
> +   goto out;
> +
> +   /* Create list of child handles */
> +   if (child_handle) {
> +   number_of_children = 1;
> +   child_handle_buffer = _handle;
> +   } else {
> +   /*
> +* We do not fully support child handles.
> +*
> +* It is unclear from which handle and which protocols the
> +* list of child controllers should be collected.
> +*/
> +   number_of_children = 0;
> +   child_handle_buffer = NULL;
> +   }
> +
> +   for (i = 0; i < driver_count; ++i) {
> +   r = EFI_CALL(efi_open_protocol(
> +driver_handle_buffer[i],
> +_guid_driver_binding_protocol,
> +(void **)_protocol,
> +driver_handle_buffer[i], NULL,
> +EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> +   if (r != EFI_SUCCESS)
> +   continue;
> +
> +   r = EFI_CALL(binding_protocol->stop(binding_protocol,
> +   controller_handle,
> +   number_of_children,
> +   child_handle_buffer));
> +   if (r == EFI_SUCCESS)
> +   ++stop_count;
> +   EFI_CALL(efi_close_protocol(driver_handle_buffer[i],
> +   _guid_driver_binding_protocol,
> +   driver_handle_buffer[i], NULL));
> +   }
> +
> +   if (driver_image_handle)
> +   efi_free_pool(driver_handle_buffer);
> +   if (stop_count)
> +   r = EFI_SUCCESS;
> +   else
> +   r = EFI_NOT_FOUND;
> +out:
> +   return EFI_EXIT(r);
>  }
>
>  efi_status_t EFIAPI efi_close_protocol(void *handle, const efi_guid_t 
> *protocol,
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 08/23] efi_loader: allow creating new handles

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> In efi_install_protocol_interface support creating
> a new handle.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
Reviewed-by: Simon Glass 

The use of void ** seems odd. Is that mandated by EFI? Is there no way
to use a proper type?

> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 96cb1fa410..9f8d64659f 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -238,6 +238,23 @@ static efi_status_t EFIAPI efi_free_pool_ext(void 
> *buffer)
> return EFI_EXIT(r);
>  }
>
> +static efi_status_t efi_create_handle(void **handle)
> +{
> +   struct efi_object *obj;
> +   efi_status_t r;
> +
> +   r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES,
> + sizeof(struct efi_object),
> + (void **));
> +   if (r != EFI_SUCCESS)
> +   return r;
> +   memset(obj, 0, sizeof(struct efi_object));
> +   obj->handle = obj;
> +   list_add_tail(>link, _obj_list);
> +   *handle = obj;
> +   return r;
> +}
> +
>  /*
>   * Our event capabilities are very limited. Only a small limited
>   * number of events is allowed to coexist.
> @@ -497,8 +514,9 @@ static efi_status_t EFIAPI 
> efi_install_protocol_interface(void **handle,
>
> /* Create new handle if requested. */
> if (!*handle) {
> -   r = EFI_OUT_OF_RESOURCES;
> -   goto out;
> +   r = efi_create_handle(handle);
> +   if (r != EFI_SUCCESS)
> +   goto out;
> }
>
> /* Find object. */
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 23/23] efi_loader: implement SetWatchdogTimer

[Simon Glass]

On 27 August 2017 at 06:54, Heinrich Schuchardt  wrote:
> The watchdog is initialized with a 5 minute timeout period.
> It can be reset by SetWatchdogTimer.
> It is stopped by ExitBoottimeServices.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/bootefi.c |  1 +
>  include/efi_loader.h  |  4 +++
>  lib/efi_loader/Makefile   |  2 +-
>  lib/efi_loader/efi_boottime.c |  3 ++-
>  lib/efi_loader/efi_watchdog.c | 58 
> +++
>  5 files changed, 66 insertions(+), 2 deletions(-)
>  create mode 100644 lib/efi_loader/efi_watchdog.c
>

Reviewed-by: Simon Glass 

I'm wondering whether the efi_ prefix on all these files is
superfluous. What is the purpose?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 07/23] efi_loader: simplify efi_install_protocol_interface

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> Use function efi_search_obj and efi_search_protocol
> to simplify the coding.
>
> Do away with efi_install_protocol_interface_ext.
> We can use EFI_CALL for internal usage.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 76 
> ++-
>  1 file changed, 31 insertions(+), 45 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 17/23] efi_loader: efi_net: hwaddr_size = 6

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> The length of a MAC address is 6.
> We have to set this length in the EFI_SIMPLE_NETWORK_MODE
> structure of the EFI_SIMPLE_NETWORK_PROTOCOL.
>
> Without this patch iPXE fails to initialize the network with
> error message
> SNP MAC(001e0633bcbf,0x0) has invalid hardware address length 0
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_net.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Can you use ARP_HLEN?

>
> diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
> index 0b949d86e8..75d7974b0e 100644
> --- a/lib/efi_loader/efi_net.c
> +++ b/lib/efi_loader/efi_net.c
> @@ -259,6 +259,7 @@ int efi_net_register(void **handle)
> netobj->dp_end = dp_end;
> memcpy(netobj->dp_mac.mac.addr, eth_get_ethaddr(), 6);
> memcpy(netobj->net_mode.current_address.mac_addr, eth_get_ethaddr(), 
> 6);
> +   netobj->net_mode.hwaddr_size = 6;
> netobj->net_mode.max_packet_size = PKTSIZE;
>
> netobj->pxe.mode = >pxe_mode;
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 09/23] efi_loader: simplify efi_uninstall_protocol_interface

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> Use function efi_search_obj and efi_search_protocol
> to simplify the coding.
>
> Do away with efi_uninstall_protocol_interface_ext.
> We can use EFI_CALL for internal usage.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 56 
> ++-
>  1 file changed, 18 insertions(+), 38 deletions(-)

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

Re: [U-Boot] ** Can't read Driver Desriptor Block **

[Simon Glass]

Hi Bin,

On 31 August 2017 at 10:53, Bin Meng  wrote:
> Hi Heinrich,
>
> On Thu, Aug 31, 2017 at 5:19 AM, Heinrich Schuchardt  
> wrote:
>> On 08/30/2017 06:37 AM, Heinrich Schuchardt wrote:
>>>
>>>
>>> On 08/30/2017 03:54 AM, Bin Meng wrote:
 Hi Heinrich,

 On Wed, Aug 30, 2017 at 4:26 AM, Heinrich Schuchardt  
 wrote:
> Hello Simon,
>
> U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
> partition in qemu-system-x86_64.
>
> By bisection I found this patch.
>
> b7c6baef2891ce8978cbfddb66e944943473ac21
> x86: Convert MMC to driver model
>
> With this patch I get
>
> IDE:   Bus 0: OK Bus 1: OK
>   Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> ** Can't read Driver Desriptor Block **
>   Device 1: not available
>   Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
> Type: Removable CD ROM
> Capacity: not available
>   Device 3: not available
>
> => ide info
> =>
>
> Without the patch I get=> ide info
> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
> Type: Removable CD ROM
> Capacity: not available
>
> I think we observe two independent errors here:
>
> - The hard disk Device 0 is not read.
> - The ide command stops at the first device that is not available.
>
> I guess only the first is caused by your patch.

 Both logs look fine to me. The "Can't read Driver Desriptor Block"
 comes from part_mac.c. Did you verify the actual IDE read/write fails
 with current HEAD?

 Regards,
 Bin

>>>
>>> Hello Bin,
>>>
>>> I have not checked block level read but used the shell commands for testing.
>>>
>>> Before the patch I can read the directory of the drive:
>>>
>>> => ide info
>>> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>>> Type: Hard Disk
>>> Supports 48-bit addressing
>>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>>> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>>> Type: Removable CD ROM
>>> Capacity: not available
>>> => fat2ls ide 0:1
>>> Unknown command 'fat2ls' - try 'help'
>>> => fatls ide 0:1
>>>164768   snp.efi
>>> 0   file1
>>> 0   file2
>>>
>>>
>>> After the patch (including HEAD) I cannot read the directory and cannot
>>> load the file snp.efi either:
>>>
>>> => ide info
>>> => fatls ide 0:1
>>> ** Bad device ide 0 **
>>> =>
>>> => fatls mmc 0:1
>>> ** Bad device mmc 0 **
>>>
>>>
>>> In both cases I have loaded the same image with:
>>>
>>> export BUILD_ROM=y
>>> make distclean && make qemu-x86_defconfig && make -j6
>>>
>>> qemu-system-x86_64 -m 1G -bios u-boot.rom -nographic \
>>> -netdev \
>>> user,id=eth0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
>>> -device e1000,netdev=eth0 -machine pc-i440fx-2.8 -hda img
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>
>> Hello Bin, hello Simon,
>>
>> I think the bug is in functions ide_init (drivers/block/ide.c).
>>
>> Platform X86 implies CONFIG_BLK=y.
>>
>> So we should initialize ide_dev_desc[i].bdev.
>>
>> We don't, so blk_dread fails after finding no read operation with ENOSYS
>> when called from part_test_dos.
>>
>> The following comment in include/blk.h confirms that bdev has to be filled:
>>
>> #if CONFIG_IS_ENABLED(BLK)
>> /*
>> * For now we have a few functions which take struct blk_desc as a
>> * parameter. This field allows them to look up the associated
>> * device. Once these functions are removed we can drop this field.
>> */
>> struct udevice *bdev;
>> #else
>>
>> I assume that we have the same issue in in __sata_initialize
>> (drivers/ata/sata.c) but have not tested.
>>
>
> Thanks for the testing!
>
> Simon, are you going to fix this?

I am not going to race you to it, if you are thinking of fixing it. I
am back from travels in a few days but have a busy week ahead and the
release is imminent :-(

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

Re: [U-Boot] [PATCH v2] patman: add support for omitting bouncing addresses

[Simon Glass]

Hi Chris,

On 30 August 2017 at 05:48, Chris Packham  wrote:
> Add support for reading a list of bouncing addresses from a in-tree file
> (doc/bounces) and from the ~/.patman config file. These addresses are
> stripped from the Cc list.
>
> Signed-off-by: Chris Packham 
> ---
> This version supports an in-tree doc/bounces file as well as a section
> in the .patman config file. A slight annoyance is the config file parser
> expects key: value pairs whereas the bounces file is just a flat list. I
> started looking a modeling this after the aliases but then I actually
> thought that if we do want to tag someone as a bouncing address we
> probably want to be explicit about it.
>
> Changes in v2:
> - better integration with existing configuration
> - documentation
>
>  doc/bounces  |  3 +++
>  tools/patman/README  | 12 
>  tools/patman/series.py   |  2 ++
>  tools/patman/settings.py | 18 ++
>  4 files changed, 35 insertions(+)
>  create mode 100644 doc/bounces
>

Reviewed-by: Simon Glass 

> diff --git a/doc/bounces b/doc/bounces
> new file mode 100644
> index ..d1c5f0d246eb
> --- /dev/null
> +++ b/doc/bounces
> @@ -0,0 +1,3 @@
> +# List of addresses picked up by patman/get_maintainer.pl that are known to
> +# bounce. Addresses are listed one per line and need to match the author
> +# information recorded in git.
> diff --git a/tools/patman/README b/tools/patman/README
> index e36857dedea1..8582ed6ba12c 100644
> --- a/tools/patman/README
> +++ b/tools/patman/README
> @@ -84,6 +84,18 @@ Aliases are recursive.
>  The checkpatch.pl in the U-Boot tools/ subdirectory will be located and
>  used. Failing that you can put it into your path or ~/bin/checkpatch.pl
>
> +If you want to avoid sending patches to email addresses that are picked up
> +by patman but are known to bounce you can add a [bounces] section to your
> +.patman file. Unlike the [alias] section these are simple key: value pairs
> +that are not recursive.
> +
> +>>>
> +
> +[bounces]
> +gonefishing: Fred Bloggs 
> +
> +<<<
> +
>
>  If you want to change the defaults for patman's command-line arguments,
>  you can add a [settings] section to your .patman file.  This can be used
> diff --git a/tools/patman/series.py b/tools/patman/series.py
> index d3947a7c2ac5..ddc0993d9eac 100644
> --- a/tools/patman/series.py
> +++ b/tools/patman/series.py
> @@ -10,6 +10,7 @@ import os
>
>  import get_maintainer
>  import gitutil
> +import settings
>  import terminal
>
>  # Series-xxx tags that we understand
> @@ -233,6 +234,7 @@ class Series(dict):
>  cc += add_maintainers
>  elif add_maintainers:
>  cc += get_maintainer.GetMaintainer(commit.patch)
> +cc = set(cc) - set(settings.bounces)

Can you please arrange for it to print out the email addresses that
are skipped? I think it might be very confusing if someone tries to
send to an address and it does not work.

>  cc = [m.encode('utf-8') if type(m) != str else m for m in cc]
>  all_ccs += cc
>  print(commit.patch, ', '.join(set(cc)), file=fd)
> diff --git a/tools/patman/settings.py b/tools/patman/settings.py
> index 5f207f5ef1c4..d735ff9ba3c6 100644
> --- a/tools/patman/settings.py
> +++ b/tools/patman/settings.py
> @@ -269,6 +269,19 @@ def _ReadAliasFile(fname):
>  if bad_line:
>  print(bad_line)
>
> +def _ReadBouncesFile(fname):
> +"""Read in the bounces file if it exists
> +
> +Args:
> +fname: Filename to read.
> +"""
> +if os.path.exists(fname):
> +with open(fname) as fd:
> +for line in fd:
> +if line.startswith('#'):
> +continue
> +bounces.add(line.strip())
> +
>  def Setup(parser, project_name, config_fname=''):
>  """Set up the settings module by reading config files.
>
> @@ -293,10 +306,15 @@ def Setup(parser, project_name, config_fname=''):
>  for name, value in config.items('alias'):
>  alias[name] = value.split(',')
>
> +_ReadBouncesFile('doc/bounces')
> +for name, value in config.items('bounces'):
> +bounces.add(value)
> +
>  _UpdateDefaults(parser, config)
>
>  # These are the aliases we understand, indexed by alias. Each member is a 
> list.
>  alias = {}
> +bounces = set()
>
>  if __name__ == "__main__":
>  import doctest
> --
> 2.14.1
>

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

Re: [U-Boot] [PATCH 20/23] efi_loader: use events for efi_net_receive

[Simon Glass]

On 27 August 2017 at 06:54, Heinrich Schuchardt  wrote:
> A timer event is defined. The timer handler cares for receiving new
> packets.
>
> efi_timer_check is called both in efi_net_transmit and efi_net_receive
> to enable events during network communication.
>
> Calling efi_timer_check in efi_net_get_status is implemented in a
> separate patch.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_net.c | 35 ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass 

But this code should not support pre-DM networking. E.g. calling eth_rx()...

It should be adjusted to work only with boards that define
CONFIG_DM_ETH. Otherwise we will never be able to move things over.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gitignore: add intermediates from libfdt build

[Simon Glass]

On 29 August 2017 at 17:47, Philipp Tomsich
 wrote:
> Since ee95d10 (fdt: Build the new python libfdt module), a number of
> additional files are auto-generated/installed into the tools directory.
> List these in .gitignore to suppress having them listed as untracked.
>
> Signed-off-by: Philipp Tomsich 
> References: ee95d10 (fdt: Build the new python libfdt module)
>
> ---
>
>  .gitignore | 8 
>  1 file changed, 8 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 v3] rpi: Enable USB keyboard support

[Simon Glass]

Hi Alex,

On 28 August 2017 at 18:10, Alexander Graf  wrote:
>
>
>> Am 26.08.2017 um 19:43 schrieb Simon Glass :
>>
>> This is currently disabled, so USB keyboards are not detected in U-Boot.
>> Enable this option to fix that.
>>
>> Signed-off-by: Simon Glass 
>> Tested-by: Jonathan Gray 
>> Reviewed-by: Bin Meng 
>> Tested-by: Paul Barker 
>
> When did the default behavior on kbd usb support change? I'd be inclined to 
> say that we should restore the exact same functionality scope as before for 
> all affected boards, not just a few well tested ones ;).
>
> In fact, wouldn't it make sense to imply usb kbd support in kconfig always 
> when usb (and gfx?) is present?

Well I think it is odd to have to enable this option separately when
you already have decided to use the keyboard. I'm not sure what to do
in the interim, but once everything is using DM, we will drop
CONFIG_DM_KEYBOARD. So this is really just an interim state.

I don't have strong views either way.

>
> That said, this patch itself is good either way, just maybe not reaching far 
> enough ;).
>
>
> Alex
>
>

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

Re: [U-Boot] [PATCH 19/23] efi_loader: correct bits of receive_filters bit mask

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> Remove extraneous commas.
> Add comment.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h | 11 ++-
>  1 file changed, 6 insertions(+), 5 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 13/23] efi_loader: non-static efi_open_protocol, efi_close_protocol

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> We need efi_open_protocol and efi_close_protocol for
> implementing other functions. So they shouldn't be static.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  | 9 +
>  lib/efi_loader/efi_boottime.c | 9 -
>  2 files changed, 13 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 

But please document these two functions fully.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 18/23] efi_net: return EFI_UNSUPPORTED where appropriate

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> U-Boot does not implement all functions of the simple network
> protocol. The unimplemented functions return either of
> EFI_SUCCESS and EFI_INVALID_PARAMETER.
>
> The UEFI spec foresees to return EFI_UNSUPPORTED in these cases.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_net.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)

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

Re: [U-Boot] ** Can't read Driver Desriptor Block **

[Bin Meng]

Hi Simon,

On Thu, Aug 31, 2017 at 8:52 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 31 August 2017 at 10:53, Bin Meng  wrote:
>> Hi Heinrich,
>>
>> On Thu, Aug 31, 2017 at 5:19 AM, Heinrich Schuchardt  
>> wrote:
>>> On 08/30/2017 06:37 AM, Heinrich Schuchardt wrote:


 On 08/30/2017 03:54 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Wed, Aug 30, 2017 at 4:26 AM, Heinrich Schuchardt  
> wrote:
>> Hello Simon,
>>
>> U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
>> partition in qemu-system-x86_64.
>>
>> By bisection I found this patch.
>>
>> b7c6baef2891ce8978cbfddb66e944943473ac21
>> x86: Convert MMC to driver model
>>
>> With this patch I get
>>
>> IDE:   Bus 0: OK Bus 1: OK
>>   Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>> Type: Hard Disk
>> Supports 48-bit addressing
>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>> ** Can't read Driver Desriptor Block **
>>   Device 1: not available
>>   Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>> Type: Removable CD ROM
>> Capacity: not available
>>   Device 3: not available
>>
>> => ide info
>> =>
>>
>> Without the patch I get=> ide info
>> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>> Type: Hard Disk
>> Supports 48-bit addressing
>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>> Type: Removable CD ROM
>> Capacity: not available
>>
>> I think we observe two independent errors here:
>>
>> - The hard disk Device 0 is not read.
>> - The ide command stops at the first device that is not available.
>>
>> I guess only the first is caused by your patch.
>
> Both logs look fine to me. The "Can't read Driver Desriptor Block"
> comes from part_mac.c. Did you verify the actual IDE read/write fails
> with current HEAD?
>
> Regards,
> Bin
>

 Hello Bin,

 I have not checked block level read but used the shell commands for 
 testing.

 Before the patch I can read the directory of the drive:

 => ide info
 Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
 Type: Hard Disk
 Supports 48-bit addressing
 Capacity: 128.0 MB = 0.1 GB (262144 x 512)
 Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
 Type: Removable CD ROM
 Capacity: not available
 => fat2ls ide 0:1
 Unknown command 'fat2ls' - try 'help'
 => fatls ide 0:1
164768   snp.efi
 0   file1
 0   file2


 After the patch (including HEAD) I cannot read the directory and cannot
 load the file snp.efi either:

 => ide info
 => fatls ide 0:1
 ** Bad device ide 0 **
 =>
 => fatls mmc 0:1
 ** Bad device mmc 0 **


 In both cases I have loaded the same image with:

 export BUILD_ROM=y
 make distclean && make qemu-x86_defconfig && make -j6

 qemu-system-x86_64 -m 1G -bios u-boot.rom -nographic \
 -netdev \
 user,id=eth0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
 -device e1000,netdev=eth0 -machine pc-i440fx-2.8 -hda img

 Best regards

 Heinrich

>>>
>>> Hello Bin, hello Simon,
>>>
>>> I think the bug is in functions ide_init (drivers/block/ide.c).
>>>
>>> Platform X86 implies CONFIG_BLK=y.
>>>
>>> So we should initialize ide_dev_desc[i].bdev.
>>>
>>> We don't, so blk_dread fails after finding no read operation with ENOSYS
>>> when called from part_test_dos.
>>>
>>> The following comment in include/blk.h confirms that bdev has to be filled:
>>>
>>> #if CONFIG_IS_ENABLED(BLK)
>>> /*
>>> * For now we have a few functions which take struct blk_desc as a
>>> * parameter. This field allows them to look up the associated
>>> * device. Once these functions are removed we can drop this field.
>>> */
>>> struct udevice *bdev;
>>> #else
>>>
>>> I assume that we have the same issue in in __sata_initialize
>>> (drivers/ata/sata.c) but have not tested.
>>>
>>
>> Thanks for the testing!
>>
>> Simon, are you going to fix this?
>
> I am not going to race you to it, if you are thinking of fixing it. I
> am back from travels in a few days but have a busy week ahead and the
> release is imminent :-(
>

Or maybe Heinrich, do you plan to work on a fix? If not, I will put it
on my todo list.

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

Re: [U-Boot] [PATCH 05/23] efi_loader: rework efi_search_obj

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> EFI_HANDLEs are used both in boottime and in runtime services.
> efi_search_obj is a function that can be used to validate
> handles. So let's make it accessible via efi_loader.h.
>
> We can simplify the coding using list_for_each_entry.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  | 2 ++
>  lib/efi_loader/efi_boottime.c | 8 +++-
>  2 files changed, 5 insertions(+), 5 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 14/23] efi_loader: pass GUIDs as const efi_guid_t *

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> We need to call some boottime services internally.
> Our GUIDs are stored as const efi_guid_t *.
>
> The boottime services never change GUIDs.
> So we can define the parameters as const efi_guid_t *.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h | 44 
> +--
>  include/efi_loader.h  |  4 ++--
>  lib/efi_loader/efi_boottime.c | 37 ++--
>  3 files changed, 43 insertions(+), 42 deletions(-)

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 01/23] efi_loader: allow return value in EFI_CALL

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> Macro EFI_CALL was introduced to call an UEFI function.

Should this be 'an EFI'. Or 'a UEFI'?

> Unfortunately it does not support return values.
> Most UEFI functions have a return value.
>
> So let's rename EFI_CALL to EFI_CALL_VOID and introduce a
> new EFI_CALL macro that supports return values.
>
> Cc: Rob Clark 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  | 17 +++--
>  lib/efi_loader/efi_boottime.c |  3 ++-
>  2 files changed, 17 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] [PATCH 11/23] efi_loader: open_info in CloseProtocol

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> efi_open_protocol and efi_close_protocol have to keep track of
> opened protocols.
>
> efi_close_protocol has to mark the appropriate entry as
> empty.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Again I wonder if you can use a utility function to find the slot.

>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 294bc1f138..c9aec597a2 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -944,9 +944,40 @@ static efi_status_t EFIAPI efi_close_protocol(void 
> *handle,
>   void *agent_handle,
>   void *controller_handle)
>  {
> +   struct efi_handler *handler;
> +   size_t i;
> +   struct efi_open_protocol_info_entry *open_info;
> +   efi_status_t r;
> +
> EFI_ENTRY("%p, %p, %p, %p", handle, protocol, agent_handle,
>   controller_handle);
> -   return EFI_EXIT(EFI_NOT_FOUND);
> +
> +   if (!agent_handle) {
> +   r = EFI_INVALID_PARAMETER;
> +   goto out;
> +   }
> +
> +   r = efi_search_protocol(handle, protocol, );
> +   if (r != EFI_SUCCESS)
> +   goto out;
> +
> +   for (i = 0; i < ARRAY_SIZE(handler->open_info); ++i) {
> +   open_info = >open_info[i];
> +
> +   if (!open_info->open_count)
> +   continue;
> +
> +   if (open_info->agent_handle == agent_handle &&
> +   open_info->controller_handle ==
> +   controller_handle) {
> +   open_info->open_count--;
> +   r = EFI_SUCCESS;
> +   goto out;
> +   }
> +   }
> +   r = EFI_NOT_FOUND;
> +out:
> +   return EFI_EXIT(r);
>  }
>
>  static efi_status_t EFIAPI efi_open_protocol_information(efi_handle_t handle,
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 03/23] efi_loader: support 16 protocols per efi_object

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> 8 protocols per efi_object is insufficient for iPXE.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 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/23] efi_loader: new function efi_search_protocol

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> In multiple functions we are searching for the protocol of a handle.
> This patch provides a new function efi_search_protocol that we can
> use to avoid duplicating code.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 25 +
>  1 file changed, 25 insertions(+)

Reviewed-by: Simon Glass 

>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index b643d299b9..9dae02daca 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -453,6 +453,31 @@ static efi_status_t EFIAPI efi_check_event(struct 
> efi_event *event)
> return EFI_EXIT(EFI_INVALID_PARAMETER);
>  }
>
> +static efi_status_t efi_search_protocol(void *handle, efi_guid_t 
> *protocol_guid,
> +   struct efi_handler **handler)

Needs a function comment

> +{
> +   struct efi_object *efiobj;
> +   size_t i;
> +   struct efi_handler *protocol;
> +
> +   if (!handle || !protocol_guid)
> +   return EFI_INVALID_PARAMETER;
> +   efiobj = efi_search_obj(handle);
> +   if (!efiobj)
> +   return EFI_INVALID_PARAMETER;
> +   for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
> +   protocol = >protocols[i];
> +   if (!protocol->guid)
> +   continue;
> +   if (!guidcmp(protocol->guid, protocol_guid)) {
> +   if (handler)
> +   *handler = protocol;
> +   return EFI_SUCCESS;
> +   }
> +   }
> +   return EFI_NOT_FOUND;
> +}
> +
>  static efi_status_t EFIAPI efi_install_protocol_interface(void **handle,
> efi_guid_t *protocol, int protocol_interface_type,
> void *protocol_interface)
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 15/23] efi_loader: implement ConnectController

[Simon Glass]

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h |  22 
>  include/efi_loader.h  |   1 +
>  lib/efi_loader/efi_boottime.c | 119 
> +-
>  3 files changed, 141 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

Please see below.

> diff --git a/include/efi_api.h b/include/efi_api.h
> index 8efc8dfab8..b2838125d7 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -609,4 +609,26 @@ struct efi_pxe {
> struct efi_pxe_mode *mode;
>  };
>
> +#define EFI_DRIVER_BINDING_PROTOCOL_GUID \
> +   EFI_GUID(0x18a031ab, 0xb443, 0x4d1a,\
> +0xa5, 0xc0, 0x0c, 0x09, 0x26, 0x1e, 0x9f, 0x71)
> +struct efi_driver_binding_protocol {
> +   efi_status_t (EFIAPI * supported)(

I think the * should be up against 'supported'. Similarly below.

> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   struct efi_device_path *remaining_device_path);
> +   efi_status_t (EFIAPI * start)(
> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   struct efi_device_path *remaining_device_path);
> +   efi_status_t (EFIAPI * stop)(
> +   struct efi_driver_binding_protocol *this,
> +   efi_handle_t controller_handle,
> +   UINTN number_of_children,
> +   efi_handle_t child_handle_buffer);

These should have function comments.

> +   u32 version;
> +   efi_handle_t image_handle;
> +   efi_handle_t driver_binding_handle;
> +};
> +
>  #endif
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9c68246c7c..f9f33e1d01 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -74,6 +74,7 @@ extern const struct efi_device_path_to_text_protocol 
> efi_device_path_to_text;
>
>  extern const efi_guid_t efi_guid_console_control;
>  extern const efi_guid_t efi_guid_device_path;
> +extern const efi_guid_t efi_guid_driver_binding_protocol;

comment for this?

>  extern const efi_guid_t efi_guid_loaded_image;
>  extern const efi_guid_t efi_guid_device_path_to_text_protocol;
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 5a73ea5cd0..1069da7d79 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -18,6 +18,14 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +static efi_status_t EFIAPI efi_locate_protocol(const efi_guid_t *protocol,
> +  void *registration,
> +  void **protocol_interface);
> +static efi_status_t EFIAPI efi_locate_handle_buffer(
> +   enum efi_locate_search_type search_type,
> +   const efi_guid_t *protocol, void *search_key,
> +   unsigned long *no_handles, efi_handle_t **buffer);
> +

Is this a forward decl? Can you reorder (in a separate patch) to avoid it?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/23] efi_loader: open_info in OpenProtocol

[Simon Glass]

Hi Heinrich,

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> efi_open_protocol and close_protocol have to keep track of
> opened protocols.
>
> So we add an array open_info to each protocol of each handle.
>
> OpenProtocol has enter the agent and controller handle
> information into this array.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  |   1 +
>  lib/efi_loader/efi_boottime.c | 130 
> +++---
>  2 files changed, 99 insertions(+), 32 deletions(-)
>

Reviewed-by: Simon Glass 

Please see below.

> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 193fca24ce..2c3360534b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -87,6 +87,7 @@ extern unsigned int __efi_runtime_rel_start, 
> __efi_runtime_rel_stop;
>  struct efi_handler {
> const efi_guid_t *guid;
> void *protocol_interface;
> +   struct efi_open_protocol_info_entry open_info[4];
>  };
>
>  /*
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index a483b827cd..294bc1f138 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1152,24 +1152,111 @@ static void EFIAPI efi_set_mem(void *buffer, 
> unsigned long size, uint8_t value)
> memset(buffer, value, size);
>  }
>
> +static efi_status_t efi_protocol_open(
> +   struct efi_handler *protocol,
> +   void **protocol_interface, void *agent_handle,
> +   void *controller_handle, uint32_t attributes)
> +{
> +   bool opened_exclusive = false;
> +   bool opened_by_driver = false;
> +   int i;
> +   struct efi_open_protocol_info_entry *open_info;
> +   struct efi_open_protocol_info_entry *match = NULL;
> +
> +   if (attributes !=
> +   EFI_OPEN_PROTOCOL_TEST_PROTOCOL) {
> +   *protocol_interface = NULL;
> +   }
> +
> +   for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) {
> +   open_info = >open_info[i];
> +
> +   if (!open_info->open_count)
> +   continue;
> +   if (open_info->agent_handle == agent_handle) {
> +   if ((attributes & EFI_OPEN_PROTOCOL_BY_DRIVER) &&
> +   (open_info->attributes == attributes))
> +   return EFI_ALREADY_STARTED;
> +   if (open_info->controller_handle == controller_handle)
> +   match = open_info;
> +   }
> +   if (open_info->attributes & EFI_OPEN_PROTOCOL_EXCLUSIVE)
> +   opened_exclusive = true;
> +   }
> +
> +   if (attributes &
> +   (EFI_OPEN_PROTOCOL_EXCLUSIVE | EFI_OPEN_PROTOCOL_BY_DRIVER) &&
> +   opened_exclusive)
> +   return EFI_ACCESS_DENIED;
> +
> +   if (attributes & EFI_OPEN_PROTOCOL_EXCLUSIVE) {
> +   for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) {

Is it possible to put this search in a utility function with suitable
parameters and call it? This function is very long.

> +   open_info = >open_info[i];
> +
> +   if (!open_info->open_count)
> +   continue;
> +   if (open_info->attributes ==
> +   EFI_OPEN_PROTOCOL_BY_DRIVER)
> +   EFI_CALL(efi_disconnect_controller(
> +   open_info->controller_handle,
> +   open_info->agent_handle,
> +   NULL));
> +   }
> +   opened_by_driver = false;
> +   for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) {
> +   open_info = >open_info[i];
> +
> +   if (!open_info->open_count)
> +   continue;
> +   if (open_info->attributes & 
> EFI_OPEN_PROTOCOL_BY_DRIVER)
> +   opened_by_driver = true;
> +   }
> +   if (opened_by_driver)
> +   return EFI_ACCESS_DENIED;
> +   if (match && !match->open_count)
> +   match = NULL;
> +   }
> +
> +   /*
> +* Find an empty slot.
> +*/
> +   if (!match) {
> +   for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) {
> +   open_info = >open_info[i];
> +
> +   if (!open_info->open_count) {
> +   match = open_info;
> +   break;
> +   }
> +   }
> +   }
> +   if (!match)
> +   return EFI_OUT_OF_RESOURCES;
> +
> +   match->agent_handle = agent_handle;
> +   

Re: [U-Boot] [PATCH 12/23] efi_loader: implement OpenProtocolInformation

[Simon Glass]

Hi Heinrich,

On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> efi_open_protocol_information provides the agent and controller
> handles as well as the attributes and open count of an protocol
> on a handle.
>
> Cc: Rob Clark 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 55 
> ++-
>  1 file changed, 54 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

I can't help wondering if this would be better as a linked list?

>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index c9aec597a2..23b8894e73 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -985,9 +985,62 @@ static efi_status_t EFIAPI 
> efi_open_protocol_information(efi_handle_t handle,
> struct efi_open_protocol_info_entry **entry_buffer,
> unsigned long *entry_count)
>  {
> +   unsigned long buffer_size;
> +   unsigned long count;
> +   struct efi_handler *handler;
> +   size_t i;
> +   efi_status_t r;
> +
> EFI_ENTRY("%p, %p, %p, %p", handle, protocol, entry_buffer,
>   entry_count);
> -   return EFI_EXIT(EFI_NOT_FOUND);
> +
> +   /* Check parameters */
> +   if (!handle || !protocol || !entry_buffer) {
> +   r = EFI_INVALID_PARAMETER;
> +   goto out;
> +   }
> +
> +   /* Find the protocol */
> +   r = efi_search_protocol(handle, protocol, );
> +   if (r != EFI_SUCCESS)
> +   goto out;
> +
> +   *entry_buffer = NULL;
> +
> +   /* Count entries */
> +   count = 0;
> +   for (i = 0; i < ARRAY_SIZE(handler->open_info); ++i) {
> +   struct efi_open_protocol_info_entry *open_info =
> +   >open_info[i];
> +
> +   if (open_info->open_count)
> +   ++count;
> +   }
> +   *entry_count = count;
> +   if (!count) {
> +   r = EFI_SUCCESS;
> +   goto out;
> +   }
> +
> +   /* Copy entries */
> +   buffer_size = count * sizeof(struct efi_open_protocol_info_entry);
> +   r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES, buffer_size,
> + (void **)entry_buffer);
> +   if (r != EFI_SUCCESS)
> +   goto out;
> +   count = 0;
> +   for (i = 0; i < ARRAY_SIZE(handler->open_info); ++i) {
> +   struct efi_open_protocol_info_entry *open_info =
> +   >open_info[i];
> +
> +   if (!open_info->open_count)
> +   continue;
> +   (*entry_buffer)[count] = *open_info;
> +   ++count;
> +   }
> +
> +out:
> +   return EFI_EXIT(r);
>  }
>
>  static efi_status_t EFIAPI efi_protocols_per_handle(void *handle,
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/23] efi_loader: notify when ExitBootServices is invoked

[Simon Glass]

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES have to be
> notified when ExitBootServices is invoked.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Simon Glass 

(I'm reviewing these in advance of the tests)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 04/23] efi_loader: rework efi_locate_handle

[Simon Glass]

Hi Heinrich,

On 27 August 2017 at 06:51, Heinrich Schuchardt  wrote:
> Check the parameters in efi_locate_handle.
>
> Use list_for_each_entry instead of list_for_each.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 42 +++---
>  1 file changed, 31 insertions(+), 11 deletions(-)
>

Reviewed-by: Simon Glass 

nits below

> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index b5538e0769..570a5ea186 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -599,6 +599,7 @@ static int efi_search(enum efi_locate_search_type 
> search_type,
> case all_handles:
> return 0;
> case by_register_notify:
> +   /* RegisterProtocolNotify is not implemented yet */
> return -1;
> case by_protocol:
> for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
> @@ -617,16 +618,38 @@ static efi_status_t efi_locate_handle(
> efi_guid_t *protocol, void *search_key,
> unsigned long *buffer_size, efi_handle_t *buffer)

function needs a comment

>  {
> -   struct list_head *lhandle;
> +   struct efi_object *efiobj;
> unsigned long size = 0;
>
> +   /* Check parameters */
> +   switch (search_type) {
> +   case all_handles:
> +   break;
> +   case by_register_notify:
> +   if (!search_key)
> +   return EFI_INVALID_PARAMETER;
> +   /* RegisterProtocolNotify is not implemented yet */
> +   return EFI_UNSUPPORTED;
> +   case by_protocol:
> +   if (!protocol)
> +   return EFI_INVALID_PARAMETER;
> +   break;
> +   default:
> +   return EFI_INVALID_PARAMETER;
> +   }
> +
> +   /*
> +* efi_locate_handle_buffer uses this function for
> +* the calculation of the necessary buffer size.
> +* So do not require a buffer for buffersize == 0.
> +*/
> +   if (!buffer_size || (*buffer_size && !buffer))
> +   return EFI_INVALID_PARAMETER;
> +
> /* Count how much space we need */
> -   list_for_each(lhandle, _obj_list) {
> -   struct efi_object *efiobj;
> -   efiobj = list_entry(lhandle, struct efi_object, link);
> -   if (!efi_search(search_type, protocol, search_key, efiobj)) {
> +   list_for_each_entry(efiobj, _obj_list, link) {
> +   if (!efi_search(search_type, protocol, search_key, efiobj))
> size += sizeof(void*);
> -   }
> }
>
> if (*buffer_size < size) {
> @@ -639,12 +662,9 @@ static efi_status_t efi_locate_handle(
> return EFI_NOT_FOUND;
>
> /* Then fill the array */
> -   list_for_each(lhandle, _obj_list) {
> -   struct efi_object *efiobj;
> -   efiobj = list_entry(lhandle, struct efi_object, link);
> -   if (!efi_search(search_type, protocol, search_key, efiobj)) {
> +   list_for_each_entry(efiobj, _obj_list, link) {
> +   if (!efi_search(search_type, protocol, search_key, efiobj))
> *(buffer++) = efiobj->handle;

*buffer++

> -   }
> }
>
> return EFI_SUCCESS;
> --
> 2.14.1
>

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

Re: [U-Boot] [PATCH v2 03/40] dm: blk: Add a generic function for block device commands

[Simon Glass]

Hi Bin,

On 1 August 2017 at 12:56, Bin Meng  wrote:
> Hi Simon,
>
> On Sun, Jul 30, 2017 at 1:34 AM, Simon Glass  wrote:
>> Most block devices provide a command (e.g. 'sata', 'scsi', 'ide') and
>> these commands generally do the same thing. This makes it harder to
>> maintain this code and keep it consistent.
>>
>> We now have a block device interface which is either implemented by driver
>> model (when CONFIG_BLK is enabled) or with a legacy interface. Therefore
>> it is possible to handle most of what these commands do with generic code.
>>
>> Add a new generic function to process block-device commands using the
>> interface type and the current device number for that type.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  cmd/Makefile |   1 +
>>  cmd/blk_common.c | 104 
>> +++
>>  include/blk.h|  12 +++
>>  3 files changed, 117 insertions(+)
>>  create mode 100644 cmd/blk_common.c
>>
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index bd231f24d8..e2b3a9cc71 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -15,6 +15,7 @@ obj-y += version.o
>>  # command
>>  obj-$(CONFIG_CMD_AES) += aes.o
>>  obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
>> +obj-y += blk_common.o
>>  obj-$(CONFIG_SOURCE) += source.o
>>  obj-$(CONFIG_CMD_SOURCE) += source.o
>>  obj-$(CONFIG_CMD_BDI) += bdinfo.o
>> diff --git a/cmd/blk_common.c b/cmd/blk_common.c
>> new file mode 100644
>> index 00..86c75e78d8
>> --- /dev/null
>> +++ b/cmd/blk_common.c
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Handling of common block commands
>> + *
>> + * Copyright (c) 2017 Google, Inc
>> + *
>> + * (C) Copyright 2000-2011
>> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +#ifdef HAVE_BLOCK_DEVICE
>> +int blk_common_cmd(int argc, char * const argv[], enum if_type if_type,
>> +  int *cur_devnump)
>> +{
>> +   const char *if_name = blk_get_if_type_name(if_type);
>> +
>> +   switch (argc) {
>> +   case 0:
>> +   case 1:
>> +   return CMD_RET_USAGE;
>> +   case 2:
>> +   if (strncmp(argv[1], "inf", 3) == 0) {
>> +   blk_list_devices(if_type);
>> +   return 0;
>> +   } else if (strncmp(argv[1], "dev", 3) == 0) {
>> +   if (blk_print_device_num(if_type, *cur_devnump)) {
>> +   printf("\nno %s devices available\n", 
>> if_name);
>> +   return CMD_RET_FAILURE;
>> +   }
>> +   return 0;
>> +   } else if (strncmp(argv[1], "part", 4) == 0) {
>> +   if (blk_list_part(if_type))
>> +   printf("\nno %s devices available\n", 
>> if_name);
>> +   return 0;
>> +   }
>> +   return CMD_RET_USAGE;
>> +   case 3:
>> +   if (strncmp(argv[1], "dev", 3) == 0) {
>> +   int dev = (int)simple_strtoul(argv[2], NULL, 10);
>> +
>> +   if (!blk_show_device(if_type, dev)) {
>> +   *cur_devnump = dev;
>> +   printf("... is now current device\n");
>> +   } else {
>> +   return CMD_RET_FAILURE;
>> +   }
>> +   return 0;
>> +   } else if (strncmp(argv[1], "part", 4) == 0) {
>> +   int dev = (int)simple_strtoul(argv[2], NULL, 10);
>> +
>> +   if (blk_print_part_devnum(if_type, dev)) {
>> +   printf("\n%s device %d not available\n",
>> +  if_name, dev);
>> +   return CMD_RET_FAILURE;
>> +   }
>> +   return 0;
>> +   }
>> +   return CMD_RET_USAGE;
>> +
>> +   default: /* at least 4 args */
>> +   if (strcmp(argv[1], "read") == 0) {
>> +   ulong addr = simple_strtoul(argv[2], NULL, 16);
>> +   lbaint_t blk = simple_strtoul(argv[3], NULL, 16);
>> +   ulong cnt = simple_strtoul(argv[4], NULL, 16);
>> +   ulong n;
>> +
>> +   printf("\n%s read: device %d block # %lld, count %ld 
>> ... ",
>> +  if_name, *cur_devnump, (unsigned long 
>> long)blk,
>> +  cnt);
>
> Please use LBAFU for parameter blk, to handle both 32-bit and 64-bit LBA.

It looks like you have kindly done a patch for that?

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

Re: [U-Boot] [PATCH] rockchip: timer: fix U_BOOT_DRIVER name

[Simon Glass]

On 25 August 2017 at 19:25, Philipp Tomsich
 wrote:
>
> When I originally added this driver, I did some careless (and in
> retrospect: mindless) copy & paste for the U_BOOT_DRIVER structure
> skeletion... unfortunately, the 'arc_timer' string was committed
> and slipped through all reviews.
>
> This fixes the U_BOOT_DRIVER name to read 'rockchip_rk3368_timer'
> (as originally intended).
>
> Signed-off-by: Philipp Tomsich 
> Reported-by: Artturi Alm 
> ---
>
>  drivers/timer/rockchip_timer.c | 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] mtd/spi: Add MT35XU512ABA1G12 NOR flash support

[Yogesh Narayan Gaur]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Tuesday, August 29, 2017 10:48 PM
> To: Yogesh Narayan Gaur 
> Cc: u-boot@lists.denx.de; York Sun 
> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
> 
> On Tue, Aug 29, 2017 at 9:42 PM, Yogesh Narayan Gaur
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Friday, August 11, 2017 4:03 PM
> >> To: Yogesh Narayan Gaur 
> >> Cc: u-boot@lists.denx.de; York Sun 
> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
> >>
> >> On Fri, Aug 11, 2017 at 3:38 PM, Yogesh Narayan Gaur
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> Sent: Friday, August 11, 2017 3:32 PM
> >> >> To: Yogesh Narayan Gaur 
> >> >> Cc: u-boot@lists.denx.de; York Sun 
> >> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash
> >> >> support
> >> >>
> >> >> On Fri, Aug 11, 2017 at 3:30 PM, Yogesh Narayan Gaur
> >> >>  wrote:
> >> >> >
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> >> Sent: Friday, August 11, 2017 3:25 PM
> >> >> >> To: Yogesh Narayan Gaur 
> >> >> >> Cc: u-boot@lists.denx.de; York Sun 
> >> >> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash
> >> >> >> support
> >> >> >>
> >> >> >> On Tue, Aug 1, 2017 at 9:43 AM, Yogesh Gaur
> >> >> >> 
> >> >> >> wrote:
> >> >> >> > Add MT35XU512ABA1G12 parameters to NOR flash parameters
> array.
> >> >> >> > Since the manufactory ID is changed to 0x2C, add it for
> >> >> >> > micron and using it for relevant settings.
> >> >> >> >
> >> >> >> > The MT35XU512ABA1G12 only supports 1 bit mode and 8 bits. It
> >> >> >> > can't support dual and quad. Supports subsector erase with
> >> >> >> > 4KB granularity, have support of FSR(flag status register)
> >> >> >> > and flash size is
> >> 64MB.
> >> >> >> > ---
> >> >> >> >  drivers/mtd/spi/sf_internal.h   | 1 +
> >> >> >> >  drivers/mtd/spi/spi_flash.c | 2 ++
> >> >> >> >  drivers/mtd/spi/spi_flash_ids.c | 1 +
> >> >> >> >  3 files changed, 4 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/drivers/mtd/spi/sf_internal.h
> >> >> >> > b/drivers/mtd/spi/sf_internal.h index 839cdbe..f46cb3a 100644
> >> >> >> > --- a/drivers/mtd/spi/sf_internal.h
> >> >> >> > +++ b/drivers/mtd/spi/sf_internal.h
> >> >> >> > @@ -33,6 +33,7 @@ enum spi_nor_option_flags {
> >> >> >> >  /* CFI Manufacture ID's */
> >> >> >> >  #define SPI_FLASH_CFI_MFR_SPANSION 0x01
> >> >> >> >  #define SPI_FLASH_CFI_MFR_STMICRO  0x20
> >> >> >> > +#define SPI_FLASH_CFI_MFR_MICRON   0x2C
> >> >> >>
> >> >> >> Does this new mfr id from micro? so 0x20 still exists?
> >> >> >>
> >> >> > On older Micron flash like MT25QU512ABB mfr id still is 0x20 but
> >> >> > in newer
> >> >> flash, MT35X, it's been changed to 0x2c.
> >> >>
> >> >> OK, so the flash features like quad ennoblements, opcodes remains same?
> >> >> except the mfr?
> >> >>
> >> > This flash support single bit and octal bit cmds no dual or quad support.
> >> > Opcode for read/write/erase and other register operation related
> >> > cmds are
> >> similar to already supported flashes like MT25QU512ABB(n25q512a in
> >> existing table).
> >> > Only mfr id has been modified.
> >>
> >> OK.
> >
> > Did this patch needs to be modified further or can be upstreamed?
> 
> Yes, ie what I commented in previous thread.
> 


Updated the patch and sent on mailing list again.

--
Thanks

> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> Maintainer Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] mtd/spi: Add MT35XU512ABA1G12 NOR flash support

[Yogesh Gaur]

Add MT35XU512ABA1G12 parameters to NOR flash parameters array.

The MT35XU512ABA1G12 only supports 1 bit mode and 8 bits. It can't support
dual and quad. Supports subsector erase with 4KB granularity, have support
of FSR(flag status register) and flash size is 64MB.

Signed-off-by: Yogesh Gaur 
---
Change in v2:
 - Incorporated Jagan's review comments. Removed macro SPI_FLASH_CFI_MFR_MICRON
---
 drivers/mtd/spi/spi_flash_ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index c4ccf48..e4f4570 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -134,6 +134,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"n25q1024a",  INFO(0x20bb21, 0x0,  64 * 1024,  2048, RD_FULL | 
WR_QPP | E_FSR | SECT_4K) },
{"mt25qu02g",  INFO(0x20bb22, 0x0,  64 * 1024,  4096, RD_FULL | 
WR_QPP | E_FSR | SECT_4K) },
{"mt25ql02g",  INFO(0x20ba22, 0x0,  64 * 1024,  4096, RD_FULL | 
WR_QPP | E_FSR | SECT_4K) },
+   {"mt35xu512g", INFO6(0x2c5b1a, 0x104100,  128 * 1024,  512, E_FSR | 
SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_SST/* SST */
{"sst25vf040b",INFO(0xbf258d, 0x0,  64 * 1024, 8, SECT_4K | 
SST_WR) },
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] dm: core: Add livetree documentation

[Simon Glass]

On 31 August 2017 at 19:59, Simon Glass  wrote:
> Add some documentation for the live device tree support in U-Boot. This
> was missing from the initial series.
>
> Signed-off-by: Simon Glass 
> Suggested-by: Lukasz Majewski 

Reviewed-by: Łukasz Majewski 

(I hope this is OK, I just fixed the typos)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] dm: core: Add livetree documentation

[Simon Glass]

Add some documentation for the live device tree support in U-Boot. This
was missing from the initial series.

Signed-off-by: Simon Glass 
Suggested-by: Lukasz Majewski 
---

Changes in v2:
- Fix several typos

 doc/driver-model/livetree.txt | 272 ++
 1 file changed, 272 insertions(+)
 create mode 100644 doc/driver-model/livetree.txt

diff --git a/doc/driver-model/livetree.txt b/doc/driver-model/livetree.txt
new file mode 100644
index 00..01d4488c60
--- /dev/null
+++ b/doc/driver-model/livetree.txt
@@ -0,0 +1,272 @@
+Driver Model with Live Device Tree
+==
+
+
+Introduction
+
+
+Traditionally U-Boot has used a 'flat' device tree. This means that it
+reads directly from the device tree binary structure. It is called a flat
+device tree because nodes are listed one after the other, with the
+hierarchy detected by tags in the format.
+
+This document describes U-Boot's support for a 'live' device tree, meaning
+that the tree is loaded into a hierarchical data structure within U-Boot.
+
+
+Motivation
+--
+
+The flat device tree has several advantages:
+
+- it is the format produced by the device tree compiler, so no translation
+is needed
+
+- it is fairly compact (e.g. there is no need for pointers)
+
+- it is accessed by the libfdt library, which is well tested and stable
+
+
+However the flat device tree does have some limitations. Adding new
+properties can involve copying large amounts of data around to make room.
+The overall tree has a fixed maximum size so sometimes the tree must be
+rebuilt in a new location to create more space. Even if not adding new
+properties or nodes, scanning the tree can be slow. For example, finding
+the parent of a node is a slow process. Reading from nodes involves a
+small amount parsing which takes a little time.
+
+Driver model scans the entire device tree sequentially on start-up which
+avoids the worst of the flat tree's limitations. But if the tree is to be
+modified at run-time, a live tree is much faster. Even if no modification
+is necessary, parsing the tree once and using a live tree from then on
+seems to save a little time.
+
+
+Implementation
+--
+
+In U-Boot a live device tree ('livetree') is currently supported only
+after relocation. Therefore we need a mechanism to specify a device
+tree node regardless of whether it is in the flat tree or livetree.
+
+The 'ofnode' type provides this. An ofnode can point to either a flat tree
+node (when the live tree node is not yet set up) or a livetree node. The
+caller of an ofnode function does not need to worry about these details.
+
+The main users of the information in a device tree are  drivers. These have
+a 'struct udevice *' which is attached to a device tree node. Therefore it
+makes sense to be able to read device tree  properties using the
+'struct udevice *', rather than having to obtain the ofnode first.
+
+The 'dev_read_...()' interface provides this. It allows properties to be
+easily read from the device tree using only a device pointer. Under the
+hood it uses ofnode so it works with both flat and live device trees.
+
+
+Enabling livetree
+-
+
+CONFIG_OF_LIVE enables livetree. When this option is enabled, the flat
+tree will be used in SPL and before relocation in U-Boot proper. Just
+before relocation a livetree is built, and this is used for U-Boot proper
+after relocation.
+
+Most checks for livetree use CONFIG_IS_ENABLED(OF_LIVE). This means that
+for SPL, the CONFIG_SPL_OF_LIVE option is checked. At present this does
+not exist, since SPL does not support livetree.
+
+
+Porting drivers
+---
+
+Many existing drivers use the fdtdec interface to read device tree
+properties. This only works with a flat device tree. The drivers should be
+converted to use the dev_read_() interface.
+
+For example, the old code may be like this:
+
+struct udevice *bus;
+const void *blob = gd->fdt_blob;
+int node = dev_of_offset(bus);
+
+i2c_bus->regs = (struct i2c_ctlr *)devfdt_get_addr(dev);
+plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency", 50);
+
+The new code is:
+
+struct udevice *bus;
+
+i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
+plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 50);
+
+The dev_read_...() interface is more convenient and works with both the
+flat and live device trees. See include/dm/read.h for a list of functions.
+
+Where properties must be read from sub-nodes or other nodes, you must fall
+back to using ofnode. For example, for old code like this:
+
+const void *blob = gd->fdt_blob;
+int subnode;
+
+fdt_for_each_subnode(subnode, blob, dev_of_offset(dev)) {
+freq = fdtdec_get_int(blob, node, "spi-max-frequency", 50);
+...
+}
+
+you should use:
+
+ofnode subnode;
+
+ofnode_for_each_subnode(subnode, 

Re: [U-Boot] [PATCH v2 1/2] armv8: mmu: remove unused macro definition

[Andy Yan]

ping


On 2017年08月17日 15:55, Andy Yan wrote:

Macro VA_BITS and PTE_BLOCK_BITS are not used
in the code, so remove them.

Signed-off-by: Andy Yan 
Reviewed-by: Philipp Tomsich 

---

Changes in v2:
- remove CONFIG_SYS_PTL2_BITS from the whitelist

  arch/arm/include/asm/armv8/mmu.h | 9 -
  scripts/config_whitelist.txt | 2 --
  2 files changed, 11 deletions(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index a349903..7752741 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -8,15 +8,6 @@
  #ifndef _ASM_ARMV8_MMU_H_
  #define _ASM_ARMV8_MMU_H_
  
-/***/

-/*
- * The following definitions are related each other, shoud be
- * calculated specifically.
- */
-
-#define VA_BITSCONFIG_SYS_VA_BITS
-#define PTE_BLOCK_BITS CONFIG_SYS_PTL2_BITS
-
  /*
   * block/section address mask and size definitions.
   */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index db28457..63b8b25 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4440,7 +4440,6 @@ CONFIG_SYS_PSDPAR
  CONFIG_SYS_PSSR_VAL
  CONFIG_SYS_PTCPAR
  CONFIG_SYS_PTDPAR
-CONFIG_SYS_PTL2_BITS
  CONFIG_SYS_PTV
  CONFIG_SYS_PUAPAR
  CONFIG_SYS_QE_FMAN_FW_IN_MMC
@@ -4815,7 +4814,6 @@ CONFIG_SYS_USE_SERIALFLASH
  CONFIG_SYS_USE_SPIFLASH
  CONFIG_SYS_USR_EXCEP
  CONFIG_SYS_U_BOOT_OFFS
-CONFIG_SYS_VA_BITS
  CONFIG_SYS_VCXK_ACKNOWLEDGE_DDR
  CONFIG_SYS_VCXK_ACKNOWLEDGE_PIN
  CONFIG_SYS_VCXK_ACKNOWLEDGE_PORT



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

Re: [U-Boot] [U-Boot,v2,2/2] armv8: mmu: add space around operator

[Andy Yan]

ping
On 2017年08月18日 21:01, Philipp Tomsich wrote:

Add space around operator "+", make it
match the coding style.

Signed-off-by: Andy Yan 
---

Changes in v2: None

  arch/arm/include/asm/armv8/mmu.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Philipp Tomsich 






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

[U-Boot] [PATCH v3 1/2] armv8: fsl-lsch3: Add SD boot support for LS1088ARDB

[Ashish Kumar]

Add SD boot support for LS1088ARDB

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
---
v3:
Depends upon
http://patchwork.ozlabs.org/patch/794217/

Rebase to top commit "8b3cec7 mtdparts: Fix uninitialized scalar usage"
Enable PPA
New memory map

 arch/arm/Kconfig |  1 +
 board/freescale/ls1088a/MAINTAINERS  |  1 +
 board/freescale/ls1088a/ddr.c|  4 
 configs/ls1088ardb_sdcard_qspi_defconfig | 33 ++
 include/configs/ls1088a_common.h | 35 
 include/configs/ls1088ardb.h | 30 +--
 6 files changed, 102 insertions(+), 2 deletions(-)
 create mode 100644 configs/ls1088ardb_sdcard_qspi_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cad0d3..6243710 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -926,6 +926,7 @@ config TARGET_LS1088ARDB
select ARMV8_MULTIENTRY
select ARCH_MISC_INIT
select BOARD_LATE_INIT
+   select SUPPORT_SPL
help
  Support for NXP LS1088ARDB platform.
  The LS1088A Reference design board (RDB) is a high-performance
diff --git a/board/freescale/ls1088a/MAINTAINERS 
b/board/freescale/ls1088a/MAINTAINERS
index e1e6d4b..68f23d6 100644
--- a/board/freescale/ls1088a/MAINTAINERS
+++ b/board/freescale/ls1088a/MAINTAINERS
@@ -5,6 +5,7 @@ S:  Maintained
 F: board/freescale/ls1088a/
 F: include/configs/ls1088ardb.h
 F: configs/ls1088ardb_qspi_defconfig
+F: configs/ls1088ardb_sdcard_qspi_defconfig
 
 LS1088AQDS BOARD
 M: Prabhakar Kushwaha 
diff --git a/board/freescale/ls1088a/ddr.c b/board/freescale/ls1088a/ddr.c
index 0ecfd65..bbab3a8 100644
--- a/board/freescale/ls1088a/ddr.c
+++ b/board/freescale/ls1088a/ddr.c
@@ -96,7 +96,11 @@ int fsl_initdram(void)
 {
puts("Initializing DDRusing SPD\n");
 
+#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
+   gd->ram_size = fsl_ddr_sdram_size();
+#else
gd->ram_size = fsl_ddr_sdram();
+#endif
 
return 0;
 }
diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig 
b/configs/ls1088ardb_sdcard_qspi_defconfig
new file mode 100644
index 000..c226bc1
--- /dev/null
+++ b/configs/ls1088ardb_sdcard_qspi_defconfig
@@ -0,0 +1,33 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1088ARDB=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1088a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="SD_BOOT_QSPI"
+CONFIG_SD_BOOT=y
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_DSPI=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x8b0
+CONFIG_FSL_LS_PPA=y
+CONFIG_SPL_BUILD=y
+CONFIG_PARTITIONS=y
+# CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index c78ba5d..b79db5a 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -20,18 +20,24 @@
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_FSL_OCRAM_BASE + 
0xfff0)
 
 /* Link Definitions */
+#ifdef CONFIG_SPL
+#define CONFIG_SYS_TEXT_BASE   0x8040
+#else
 #ifdef CONFIG_QSPI_BOOT
 #define CONFIG_SYS_TEXT_BASE0x2010
 #else
 #define CONFIG_SYS_TEXT_BASE   0x3010
 #endif
+#endif
 
 #define CONFIG_SUPPORT_RAW_INITRD
 
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
+#if !defined(CONFIG_SD_BOOT)
 #define CONFIG_FSL_DDR_INTERACTIVE /* Interactive debugging */
+#endif
 
 #define CONFIG_VERY_BIG_RAM
 #define CONFIG_SYS_DDR_SDRAM_BASE  0x8000UL
@@ -177,6 +183,11 @@ unsigned long long get_qixis_addr(void);
" fsl_mc apply dpl 0x8020 &&" \
" sf read $kernel_load $kernel_start" \
" $kernel_size && bootm $kernel_load"
+#elif defined(CONFIG_SD_BOOT)
+#define CONFIG_BOOTCOMMAND "mmcinfo;mmc read 0x8020 0x6800 0x800;"\
+   " fsl_mc apply dpl 0x8020 &&" \
+   " mmc read $kernel_load $kernel_start" \
+   " $kernel_size && bootm $kernel_load"
 #else /* NOR BOOT*/
 #define CONFIG_BOOTCOMMAND "fsl_mc apply dpl 0x580d0 &&" \
" cp.b $kernel_start $kernel_load" \
@@ -196,6 +207,30 @@ unsigned long long get_qixis_addr(void);
 
 #define CONFIG_PANIC_HANG  /* do not reset board on panic */
 
+#ifdef CONFIG_SPL
+#define CONFIG_SPL_BSS_START_ADDR  0x8010

[U-Boot] [PATCH v3 2/2] armv8: fsl-lsch3: Add SD boot support for ls1088aqds

[Ashish Kumar]

Add support for SD boot for QDS for ls1088 paltform

Signed-off-by: Ashish Kumar 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Raghav Dogra 
---
v3:
Depends upon
http://patchwork.ozlabs.org/patch/794217/

Rebase to top commit "8b3cec7 mtdparts: Fix uninitialized scalar usage"
Enable PPA
New memory map

 arch/arm/Kconfig |  1 +
 board/freescale/ls1088a/MAINTAINERS  |  1 +
 configs/ls1088aqds_sdcard_qspi_defconfig | 33 +++
 include/configs/ls1088aqds.h | 34 
 4 files changed, 65 insertions(+), 4 deletions(-)
 create mode 100644 configs/ls1088aqds_sdcard_qspi_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6243710..8bce296 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -812,6 +812,7 @@ config TARGET_LS1088AQDS
select ARMV8_MULTIENTRY
select ARCH_MISC_INIT
select BOARD_LATE_INIT
+   select SUPPORT_SPL
help
  Support for NXP LS1088AQDS platform
  The LS1088A Development System (QDS) is a high-performance
diff --git a/board/freescale/ls1088a/MAINTAINERS 
b/board/freescale/ls1088a/MAINTAINERS
index 68f23d6..b3d5c38 100644
--- a/board/freescale/ls1088a/MAINTAINERS
+++ b/board/freescale/ls1088a/MAINTAINERS
@@ -14,3 +14,4 @@ S:Maintained
 F: board/freescale/ls1088a/
 F: include/configs/ls1088aqds.h
 F: configs/ls1088aqds_qspi_defconfig
+F: configs/ls1088aqds_sdcard_qspi_defconfig
diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig 
b/configs/ls1088aqds_sdcard_qspi_defconfig
new file mode 100644
index 000..95d8627
--- /dev/null
+++ b/configs/ls1088aqds_sdcard_qspi_defconfig
@@ -0,0 +1,33 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1088AQDS=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1088a-qds"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="SD_BOOT_QSPI"
+CONFIG_SD_BOOT=y
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_DSPI=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x8b0
+CONFIG_FSL_LS_PPA=y
+CONFIG_SPL_BUILD=y
+CONFIG_PARTITIONS=y
+# CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h
index 3547b0b..72c2d3c 100644
--- a/include/configs/ls1088aqds.h
+++ b/include/configs/ls1088aqds.h
@@ -24,6 +24,11 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_ENV_SIZE0x2000  /* 8KB */
 #define CONFIG_ENV_OFFSET  0x30/* 3MB */
 #define CONFIG_ENV_SECT_SIZE   0x4
+#elif defined(CONFIG_SD_BOOT)
+#define CONFIG_ENV_OFFSET  (3 * 1024 * 1024)
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_ENV_SIZE0x2000
 #else
 #define CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
0x30)
@@ -31,10 +36,10 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_ENV_SIZE0x2
 #endif
 
-#if defined(CONFIG_QSPI_BOOT)
+#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
 #define CONFIG_QIXIS_I2C_ACCESS
 #define SYS_NO_FLASH
-
+#define CONFIG_SYS_I2C_EARLY_INIT
 #undef CONFIG_CMD_IMLS
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
@@ -192,7 +197,7 @@ unsigned long get_board_ddr_clk(void);
| CSPR_V)
 
 #define CONFIG_SYS_FPGA_AMASK  IFC_AMASK(64*1024)
-#if defined(CONFIG_QSPI_BOOT)
+#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
 #define CONFIG_SYS_FPGA_CSOR   CSOR_GPCM_ADM_SHIFT(0)
 #else
 #define CONFIG_SYS_FPGA_CSOR   CSOR_GPCM_ADM_SHIFT(12)
@@ -295,7 +300,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
 
 /* QSPI device */
-#if defined(CONFIG_QSPI_BOOT)
+#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
 #define CONFIG_FSL_QSPI
 #define CONFIG_SPI_FLASH_SPANSION
 #define FSL_QSPI_FLASH_SIZE(1 << 26)
@@ -318,7 +323,11 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_MEMTEST_START   0x8000
 #define CONFIG_SYS_MEMTEST_END 0x9fff
 
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SYS_MONITOR_BASE CONFIG_SPL_TEXT_BASE
+#else
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE
+#endif
 
 #define CONFIG_FSL_MEMAC
 
@@ -346,6 +355,23 @@ unsigned long get_board_ddr_clk(void);
"sf read 0x8010 0xE0 0x10;" \
"fsl_mc start mc 0x8000 

[U-Boot] [PATCH v3 1/2] armv8: fsl-layerscape: Support to add RGMII for ls1088aqds

[Ashish Kumar]

This patch adds support for RGMII protocol

NXP's LDPAA2 support RGMII protocol. LS1088A is the
first Soc supporting both RGMII and SGMII.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Amrita Kumari 
Signed-off-by: Ashish Kumar 
---
v3:
No change

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  | 21 +
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  4 
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  1 +
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  6 +
 board/freescale/ls1088a/eth_ls1088aqds.c   |  1 -
 drivers/net/ldpaa_eth/ldpaa_wriop.c|  9 
 drivers/net/ldpaa_eth/ls1088a.c| 27 ++
 include/fsl-mc/ldpaa_wriop.h   |  2 ++
 8 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 9290268..2af7a76 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -57,6 +57,8 @@ config ARCH_LS1088A
select SYS_FSL_DDR
select SYS_FSL_DDR_LE
select SYS_FSL_DDR_VER_50
+   select SYS_FSL_EC1
+   select SYS_FSL_EC2
select SYS_FSL_ERRATUM_A009803
select SYS_FSL_ERRATUM_A009942
select SYS_FSL_ERRATUM_A010165
@@ -64,6 +66,7 @@ config ARCH_LS1088A
select SYS_FSL_ERRATUM_A008850
select SYS_FSL_HAS_CCI400
select SYS_FSL_HAS_DDR4
+   select SYS_FSL_HAS_RGMII
select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_5
select SYS_FSL_SEC_LE
@@ -406,6 +409,18 @@ config RESV_RAM
  be at the high end of physical memory. The reserve RAM may be
  excluded from memory bank(s) passed to OS, or marked as reserved.
 
+config SYS_FSL_EC1
+   bool
+   help
+ Ethernet controller 1, this is connected to MAC3.
+ Provides DPAA2 capabilities
+
+config SYS_FSL_EC2
+   bool
+   help
+ Ethernet controller 2, this is connected to MAC4.
+ Provides DPAA2 capabilities
+
 config SYS_FSL_ERRATUM_A008336
bool
 
@@ -430,6 +445,12 @@ config SYS_FSL_ERRATUM_A009660
 config SYS_FSL_ERRATUM_A009929
bool
 
+
+config SYS_FSL_HAS_RGMII
+   bool
+   depends on SYS_FSL_EC1 || SYS_FSL_EC2
+
+
 config SYS_MC_RSV_MEM_ALIGN
hex "Management Complex reserved memory alignment"
depends on RESV_RAM
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index ec58065..3c9a5ed 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -517,6 +517,10 @@ int arch_early_init_r(void)
printf("Did not wake secondary cores\n");
}
 
+#ifdef CONFIG_SYS_FSL_HAS_RGMII
+   fsl_rgmii_init();
+#endif
+
 #ifdef CONFIG_SYS_HAS_SERDES
fsl_serdes_init();
 #endif
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index a2c7578..12fd6b8 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -159,6 +159,7 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device);
 enum srds_prtcl serdes_get_prtcl(int serdes, int cfg, int lane);
 int is_serdes_prtcl_valid(int serdes, u32 prtcl);
 int serdes_get_number(int serdes, int cfg);
+void fsl_rgmii_init(void);
 
 #ifdef CONFIG_FSL_LSCH2
 const char *serdes_clock_to_string(u32 clock);
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 99a7413..ffc5fa2 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -247,6 +247,12 @@ struct ccsr_gur {
 #define FSL_CHASSIS3_SRDS1_REGSR   29
 #define FSL_CHASSIS3_SRDS2_REGSR   29
 #elif defined(CONFIG_ARCH_LS1088A)
+#define FSL_CHASSIS3_EC1_REGSR  26
+#define FSL_CHASSIS3_EC2_REGSR  26
+#define FSL_CHASSIS3_RCWSR25_EC1_PRTCL_MASK 0x0007
+#define FSL_CHASSIS3_RCWSR25_EC1_PRTCL_SHIFT0
+#define FSL_CHASSIS3_RCWSR25_EC2_PRTCL_MASK 0x0038
+#define FSL_CHASSIS3_RCWSR25_EC2_PRTCL_SHIFT3
 #defineFSL_CHASSIS3_RCWSR29_SRDS1_PRTCL_MASK   0x
 #defineFSL_CHASSIS3_RCWSR29_SRDS1_PRTCL_SHIFT  16
 #defineFSL_CHASSIS3_RCWSR30_SRDS2_PRTCL_MASK   0x
diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c 
b/board/freescale/ls1088a/eth_ls1088aqds.c
index a912ff7..a973457 100644
--- a/board/freescale/ls1088a/eth_ls1088aqds.c
+++ b/board/freescale/ls1088a/eth_ls1088aqds.c
@@ -597,7 +597,6 @@ int board_eth_init(bd_t *bis)
 
/* Register the real MDIO1 bus */
fm_memac_mdio_init(bis, memac_mdio0_info);
-
/* Register the muxing front-ends to the MDIO buses */

[U-Boot] [PATCH v3 2/2] armv8: ls1088aqds: Add support of EC1 and EC2

[Ashish Kumar]

From: Prabhakar Kushwaha 

EC1 and EC2 are RGMII interface on ls1088aqds platform.
This patch add support of RGMII with PHY and MDIO

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Amrita Kumari 
Signed-off-by: Ashish Kumar 
---
v3:
Add missing singoff

 board/freescale/ls1088a/eth_ls1088aqds.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c 
b/board/freescale/ls1088a/eth_ls1088aqds.c
index a973457..c19f59a 100644
--- a/board/freescale/ls1088a/eth_ls1088aqds.c
+++ b/board/freescale/ls1088a/eth_ls1088aqds.c
@@ -576,6 +576,37 @@ void ls1088a_handle_phy_interface_xsgmii(int i)
break;
}
 }
+
+static void ls1088a_handle_phy_interface_rgmii(int dpmac_id)
+{
+   struct ccsr_gur __iomem *gur = (void *)CONFIG_SYS_FSL_GUTS_ADDR;
+   u32 serdes1_prtcl, cfg;
+   struct mii_dev *bus;
+
+   cfg = in_le32(>rcwsr[FSL_CHASSIS3_SRDS1_REGSR - 1]) &
+   FSL_CHASSIS3_SRDS1_PRTCL_MASK;
+   cfg >>= FSL_CHASSIS3_SRDS1_PRTCL_SHIFT;
+   serdes1_prtcl = serdes_get_number(FSL_SRDS_1, cfg);
+
+   switch (dpmac_id) {
+   case 4:
+   wriop_set_phy_address(dpmac_id, RGMII_PHY1_ADDR);
+   dpmac_info[dpmac_id].board_mux = EMI1_RGMII1;
+   bus = mii_dev_for_muxval(EMI1_RGMII1);
+   wriop_set_mdio(dpmac_id, bus);
+   break;
+   case 5:
+   wriop_set_phy_address(dpmac_id, RGMII_PHY2_ADDR);
+   dpmac_info[dpmac_id].board_mux = EMI1_RGMII2;
+   bus = mii_dev_for_muxval(EMI1_RGMII2);
+   wriop_set_mdio(dpmac_id, bus);
+   break;
+   default:
+   printf("qds: WRIOP: Unsupported RGMII SerDes Protocol 0x%02x\n",
+  serdes1_prtcl);
+   break;
+   }
+}
 #endif
 
 int board_eth_init(bd_t *bis)
@@ -604,6 +635,9 @@ int board_eth_init(bd_t *bis)
 
for (i = WRIOP1_DPMAC1; i < NUM_WRIOP_PORTS; i++) {
switch (wriop_get_enet_if(i)) {
+   case PHY_INTERFACE_MODE_RGMII:
+   ls1088a_handle_phy_interface_rgmii(i);
+   break;
case PHY_INTERFACE_MODE_QSGMII:
ls1088a_handle_phy_interface_qsgmii(i);
break;
-- 
2.7.4

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

[U-Boot] [PATCH v5 3/3] armv8: ls1088aqds: Add support of LS1088AQDS

[Ashish Kumar]

This patch add support of LS1088AQDS platform.

The LS1088A QorIQTM Development System (QDS) is a
high-performance computing, evaluation, and
development platform that supports the LS1088A QorIQ Architecture
processor.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Shaohui Xie 
Signed-off-by: Ashish Kumar 
---
v5:
 Fix checkpatch's check
 Change getenv() to env_get()
 Rebase to top commit "8b3cec7 mtdparts: Fix uninitialized scalar usage"

 arch/arm/Kconfig |  13 +
 arch/arm/cpu/armv8/Kconfig   |   2 +-
 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/fsl-ls1088a-qds.dts |  70 
 board/freescale/ls1088a/Kconfig  |  16 +
 board/freescale/ls1088a/MAINTAINERS  |   8 +
 board/freescale/ls1088a/Makefile |   1 +
 board/freescale/ls1088a/README   |  79 
 board/freescale/ls1088a/ddr.h|   5 +
 board/freescale/ls1088a/eth_ls1088aqds.c | 650 +++
 board/freescale/ls1088a/ls1088a.c|  84 +++-
 board/freescale/ls1088a/ls1088a_qixis.h  |   5 +
 configs/ls1088aqds_qspi_defconfig|  29 ++
 include/configs/ls1088aqds.h | 414 
 14 files changed, 1372 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-qds.dts
 create mode 100644 board/freescale/ls1088a/eth_ls1088aqds.c
 create mode 100644 configs/ls1088aqds_qspi_defconfig
 create mode 100644 include/configs/ls1088aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index acc6990..5cad0d3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -805,6 +805,19 @@ config TARGET_LS2080A_SIMU
  development platform that supports the QorIQ LS2080A
  Layerscape Architecture processor.
 
+config TARGET_LS1088AQDS
+   bool "Support ls1088aqds"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select ARCH_MISC_INIT
+   select BOARD_LATE_INIT
+   help
+ Support for NXP LS1088AQDS platform
+ The LS1088A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS2080AQDS
bool "Support ls2080aqds"
select ARCH_LS2080A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index aecdf81..12aba9d 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,7 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
-  !TARGET_LS1088ARDB && \
+  !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c63fb4..b070f98 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -188,7 +188,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb \
fsl-ls2081a-rdb.dtb \
fsl-ls2088a-rdb-qspi.dtb \
-   fsl-ls1088a-rdb.dtb
+   fsl-ls1088a-rdb.dtb \
+   fsl-ls1088a-qds.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
diff --git a/arch/arm/dts/fsl-ls1088a-qds.dts b/arch/arm/dts/fsl-ls1088a-qds.dts
new file mode 100644
index 000..9b7bef4
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-qds.dts
@@ -0,0 +1,70 @@
+/*
+ * NXP ls1088a QDS board device tree source
+ *
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+/ {
+   model = "NXP Layerscape 1088a QDS Board";
+   compatible = "fsl,ls1088a-qds", "fsl,ls1088a";
+   aliases {
+   spi0 = 
+   spi1 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash0: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <100>; /* input clock */
+   };
+
+   dflash1: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <350>;
+   reg = <1>;
+   };
+
+   dflash2: en25s64 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <350>;
+   reg = <2>;
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: 

[U-Boot] [PATCH v5 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform

[Ashish Kumar]

LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin
platform that supports the LS1088A family SoCs. This patch add basic
support of the platform.

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
Signed-off-by: Shaohui Xie 
---
v5:
 Fix checkpatch's check
 Change getenv() to env_get()
 Rebase to top commit "8b3cec7 mtdparts: Fix uninitialized scalar usage"

 arch/arm/Kconfig  |  14 ++
 arch/arm/cpu/armv8/Kconfig|   1 +
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |   1 +
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-ls1088a-rdb.dts  |  40 
 board/freescale/ls1088a/Kconfig   |  15 ++
 board/freescale/ls1088a/MAINTAINERS   |   7 +
 board/freescale/ls1088a/Makefile  |   9 +
 board/freescale/ls1088a/README|  66 ++
 board/freescale/ls1088a/ddr.c | 102 +
 board/freescale/ls1088a/ddr.h |  44 
 board/freescale/ls1088a/eth_ls1088ardb.c  | 102 +
 board/freescale/ls1088a/ls1088a.c | 332 ++
 board/freescale/ls1088a/ls1088a_qixis.h   |  34 +++
 configs/ls1088ardb_qspi_defconfig |  29 +++
 include/configs/ls1088a_common.h  | 201 ++
 include/configs/ls1088ardb.h  | 319 
 17 files changed, 1318 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-rdb.dts
 create mode 100644 board/freescale/ls1088a/Kconfig
 create mode 100644 board/freescale/ls1088a/MAINTAINERS
 create mode 100644 board/freescale/ls1088a/Makefile
 create mode 100644 board/freescale/ls1088a/README
 create mode 100644 board/freescale/ls1088a/ddr.c
 create mode 100644 board/freescale/ls1088a/ddr.h
 create mode 100644 board/freescale/ls1088a/eth_ls1088ardb.c
 create mode 100644 board/freescale/ls1088a/ls1088a.c
 create mode 100644 board/freescale/ls1088a/ls1088a_qixis.h
 create mode 100644 configs/ls1088ardb_qspi_defconfig
 create mode 100644 include/configs/ls1088a_common.h
 create mode 100644 include/configs/ls1088ardb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 53d0831..acc6990 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -906,6 +906,19 @@ config TARGET_LS1012AFRDM
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1088ARDB
+   bool "Support ls1088ardb"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select ARCH_MISC_INIT
+   select BOARD_LATE_INIT
+   help
+ Support for NXP LS1088ARDB platform.
+ The LS1088A Reference design board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select BOARD_LATE_INIT
@@ -1185,6 +1198,7 @@ source "board/creative/xfi3/Kconfig"
 source "board/freescale/ls2080a/Kconfig"
 source "board/freescale/ls2080aqds/Kconfig"
 source "board/freescale/ls2080ardb/Kconfig"
+source "board/freescale/ls1088a/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 8e4c3dd..aecdf81 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,6 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
+  !TARGET_LS1088ARDB && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index aa2d0d1..9290268 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -208,6 +208,7 @@ config SYS_LS_PPA_FW_ADDR
default 0x2040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A
default 0x4040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT
default 0x58040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
+   default 0x2040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
default 0x6040 if SYS_LS_PPA_FW_IN_XIP
default 0x40 if SYS_LS_PPA_FW_IN_MMC
default 0x40 if SYS_LS_PPA_FW_IN_NAND
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 762429c..9c63fb4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -187,7 +187,8 @@ 

[U-Boot] [PATCH v5 1/3] armv8: ls1088a: Add NXP LS1088A SoC support

[Ashish Kumar]

The QorIQ LS1088A processor is built on the Layerscape
architecture combining eight ARM A53 processor cores
with advanced, high-performance datapath acceleration
and networks, peripheral interfaces required for
networking, wireless infrastructure, and general-purpose
embedded applications.

LS1088A is compliant with the Layerscape Chassis Generation 3.

Features summary:
 - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
 - Cores are in 2 cluster of 4-cores each
 - Cache coherent interconnect (CCI-400)
 - One 64-bit DDR4 SDRAM memory controller with ECC
 - Data path acceleration architecture 2.0 (DPAA2)
 - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
 - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
Signed-off-by: Shaohui Xie 
---

v5:
No change

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  35 +-
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  43 ++-
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  19 
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 126 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   1 +
 arch/arm/dts/fsl-ls1088a.dtsi  |  78 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  62 +-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   3 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  11 ++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   4 +
 .../asm/arch-fsl-layerscape/stream_id_lsch3.h  |  14 +++
 drivers/ddr/fsl/util.c |   2 +-
 drivers/net/ldpaa_eth/Makefile |   1 +
 drivers/net/ldpaa_eth/ls1088a.c|  87 ++
 16 files changed, 482 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
 create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi
 create mode 100644 drivers/net/ldpaa_eth/ls1088a.c

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index eb8ccd1..aa2d0d1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -50,6 +50,29 @@ config ARCH_LS1046A
select BOARD_EARLY_INIT_F
imply SCSI
 
+config ARCH_LS1088A
+   bool
+   select ARMV8_SET_SMPEN
+   select FSL_LSCH3
+   select SYS_FSL_DDR
+   select SYS_FSL_DDR_LE
+   select SYS_FSL_DDR_VER_50
+   select SYS_FSL_ERRATUM_A009803
+   select SYS_FSL_ERRATUM_A009942
+   select SYS_FSL_ERRATUM_A010165
+   select SYS_FSL_ERRATUM_A008511
+   select SYS_FSL_ERRATUM_A008850
+   select SYS_FSL_HAS_CCI400
+   select SYS_FSL_HAS_DDR4
+   select SYS_FSL_HAS_SEC
+   select SYS_FSL_SEC_COMPAT_5
+   select SYS_FSL_SEC_LE
+   select SYS_FSL_SRDS_1
+   select SYS_FSL_SRDS_2
+   select FSL_TZASC_1
+   select ARCH_EARLY_INIT_R
+   select BOARD_EARLY_INIT_F
+
 config ARCH_LS2080A
bool
select ARMV8_SET_SMPEN
@@ -100,7 +123,7 @@ config FSL_LSCH3
 
 config FSL_MC_ENET
bool "Management Complex network"
-   depends on ARCH_LS2080A
+   depends on ARCH_LS2080A || ARCH_LS1088A
default y
select RESV_RAM
help
@@ -116,6 +139,7 @@ config FSL_PCIE_COMPAT
default "fsl,ls1043a-pcie" if ARCH_LS1043A
default "fsl,ls1046a-pcie" if ARCH_LS1046A
default "fsl,ls2080a-pcie" if ARCH_LS2080A
+   default "fsl,ls1088a-pcie" if ARCH_LS1088A
help
  This compatible is used to find pci controller node in Kernel DT
  to complete fixup.
@@ -230,6 +254,7 @@ config MAX_CPUS
default 4 if ARCH_LS1043A
default 4 if ARCH_LS1046A
default 16 if ARCH_LS2080A
+   default 8 if ARCH_LS1088A
default 1
help
  Set this number to the maximum number of possible CPUs in the SoC.
@@ -261,10 +286,10 @@ config SYS_CCI400_OFFSET
 
 config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
-   depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A
+   depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A || ARCH_LS1088A
default 4 if ARCH_LS1043A
default 4 if ARCH_LS1046A
-   default 8 if ARCH_LS2080A
+   default 8 if ARCH_LS2080A || ARCH_LS1088A
 
 config SYS_FSL_HAS_CCI400
bool
@@ -313,6 +338,7 @@ config SYS_FSL_PCLK_DIV
int "Platform clock divider"
default 1 if ARCH_LS1043A
default 1 if ARCH_LS1046A
+   default 1 if ARCH_LS1088A
default 2
help
  This is the divider that is used to derive Platform clock from
@@ 

[U-Boot] mv88e61xx autoneg doesn't work with new driver

[Clément Péron]

Hi,

I try to update my u-boot with the latest version 2017.07.

My board is an Altera SocFPGA CycloneV and I have a mv88e61xx switch.

My board is working fine except I got an issue with the new switch driver.
If autoneg is set to enable, negotation never complete and i got a timeout.
If I let the autoneg disable, I have ethernet working but with slow
speed 10mbits / half duplex.

Not sure if i'm doing something wrong or if there is a bug in the new driver.

Could you please help me to debug this issue ?

Thanks for your help,
Regards,
Clement

KConfig

--- Marvel MV88E61xx Ethernet switch PHY support.
(5)   CPU Port
(0x1F) Bitmask of PHY Ports
(0x0) Bitmask of PHYless serdes Ports


board.c

 int mv88e61xx_hw_reset(struct phy_device *phydev)
 {
 struct mii_dev *bus = phydev->bus;

 /* RGMII delay - Physical Control register bit[15:14] */
 debug("setting port%d RGMII rx/tx delay\n", CONFIG_MV88E61XX_CPU_PORT);
 /* forced 1000mbps full-duplex link */
 bus->write(bus, 0x10 + CONFIG_MV88E61XX_CPU_PORT, 0, 1, 0xc0fe);
 phydev->autoneg = AUTONEG_ENABLE;
 phydev->speed = SPEED_1000;
 phydev->duplex = DUPLEX_FULL;

 return 0;
 }

serial

U-Boot SPL 2017.07-9-g9f00f9622e-dirty (Aug 31 2017 - 10:52:53)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
Trying to boot from SPI


U-Boot 2017.07-9-g9f00f9622e-dirty (Aug 31 2017 - 10:52:53 +0200)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
BOOT:  QSPI Flash (3.0V)
   Watchdog enabled
DRAM:  512 MiB
MMC:   dwmmc0@ff704000: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: Board
Net:   setting port5 RGMII rx/tx delay

Warning: ethernet@ff702000 (eth0) using random MAC address - 2e:91:a1:21:8e:38
eth0: ethernet@ff702000
Hit any key to stop autoboot:  0
=> tftp ${rootaddr} rootfs.cpio.uboot; tftp ${dtb_loadaddr} board.dtb;
tftp ${loadaddr} uImage; bootm ${loadaddr} ${rootaddr} ${dtb_loadadd}
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000: No link.
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000: No link.
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000 Waiting for PHY auto negotiation to
complete. TIMEOUT !
ethernet@ff702000: No link.
...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: clk: rk3368: always run rkclk_init when driver probe

[Andy Yan]

Hi Philipp:


On 2017年08月28日 04:21, Dr. Philipp Tomsich wrote:

On 23 Aug 2017, at 09:26, Andy Yan  wrote:

commit 4bebf94e8544("rockchip: clk: rk3368: do not change
CPLL/GPLL before returning to BROM") limits the pll can only
be setup in SPL stage, but there are still some rk3368 based
boards have not use SPL yet, so they need run rkclk_init to
setup the pll in full u-boot stage, otherwise the clk_set_rate
function will run into wrong logic, because it assume that all
the pll have been set to the desired frequency.

If SPL is enabled, rkclk_init should not be called from the full
U-Boot, though.  I.e. we’ll need an appropriate conditional
test to check whether SPL is enabled or not...


Do you have any ideas here?





Signed-off-by: Andy Yan 
---

drivers/clk/rockchip/clk_rk3368.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 2be1f57..ee754f0 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -47,14 +47,12 @@ struct pll_div {
   (_nr * _no) == hz, #hz "Hz cannot be hit with PLL " \
   "divisors on line " __stringify(__LINE__));

-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
static const struct pll_div apll_l_init_cfg = PLL_DIVISORS(APLL_L_HZ, 12, 2);
static const struct pll_div apll_b_init_cfg = PLL_DIVISORS(APLL_B_HZ, 1, 2);
#if !defined(CONFIG_TPL_BUILD)
static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 1, 2);
static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 6);
#endif
-#endif

static ulong rk3368_clk_get_rate(struct clk *clk);

@@ -85,7 +83,6 @@ static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
}
}

-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
static int rkclk_set_pll(struct rk3368_cru *cru, enum rk3368_pll_id pll_id,
 const struct pll_div *div)
{
@@ -125,9 +122,7 @@ static int rkclk_set_pll(struct rk3368_cru *cru, enum 
rk3368_pll_id pll_id,
seamless
return 0;
}
-#endif

-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
static void rkclk_init(struct rk3368_cru *cru)
{
u32 apllb, aplll, dpll, cpll, gpll;
@@ -152,7 +147,7 @@ static void rkclk_init(struct rk3368_cru *cru)
debug("%s apllb(%d) apll(%d) dpll(%d) cpll(%d) gpll(%d)\n",
   __func__, apllb, aplll, dpll, cpll, gpll);
}
-#endif
+

#if !IS_ENABLED(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(MMC_SUPPORT)
static ulong rk3368_mmc_get_clk(struct rk3368_cru *cru, uint clk_id)
@@ -473,9 +468,8 @@ static int rk3368_clk_probe(struct udevice *dev)

priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
#endif
-#if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
+
rkclk_init(priv->cru);
-#endif

return 0;
}
--
2.7.4









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

Re: [U-Boot] tpl build error "width suffixes are invalid in ARM mode"

[Dr. Philipp Tomsich]

I just looked at the codebase and now I am also confused. ;-)
At least the usage in the Makefiles seems to not correctly support TPL at this 
point.

For what I have seen, we seem to have multiple problems:
1/  arch/arm/config.mk does test for '$(CONFIG_$(SPL_)SYS_THUMB_BUILD)’ 
instead of '$(CONFIG_$(SPL_TPL_)SYS_THUMB_BUILD)’
2/  same goes for arch/arm/lib/Makefile

And then there’s a few instances of unnecessary (and undocumented) complexity:
3/  in arch/arm/lib/cache.c, a CONFIG_IS_ENABLED(SYS_THUMB_BUILD) test 
guards whether invalidate_l2_cache(void) is present
4/  in arch/arm/include/asm/cache.h, a CONFIG_IS_ENABLED(SYS_THUMB_BUILD) 
test decides whether invalidate_l2_cache() is inline or not

Could you do a quick review all uses of ‘SYS_THUMB_BUILD’ throughout the 
code-base and and
(a) change $(CONFIG_$(SPL_)SYS_THUMB_BUILD) to 
$(CONFIG_$(SPL_TPL_)SYS_THUMB_BUILD), unless guaranteed that TPL will be 
handled in a different path
(b) make sure that .c files never test this, unless absolutely necessary (the 
compiler usually provides us with a predefined __thumb__ if we are compiling 
for Thumb)
(c) clean up the cache.h/c complexity: this seems to be there, because the 
cache-maintainance instructions are available as ARM instructions only, but the 
arch/arm/include/asm/cache.h could be included either by ARM or by Thumb code; 
an “attribute((arm))” on the inline-function might suffice to allow for a 
single, common case (if GCC is smart enough to insert an interwork transition 
for the inlined code).

Regards,
Philipp.

> On 31 Aug 2017, at 03:19, Kever Yang  wrote:
> 
> Hi Philipp,
> 
> Yes, I'm building TPL, the error message gone after I add 
> TPL_SYS_THUMB_BUILD.
> 
> I still confuse where the build option affects, eg. which Mackfile or 
> config.mk?
> 
> Thanks,
> - Kever
> On 08/30/2017 06:16 PM, Dr. Philipp Tomsich wrote:
>> I just realised that you are building TPL.
>> For this you will need a TPL_SYS_THUMB_BUILD symbol now (with the 
>> CONFIG_IS_ENABLED knowing about the difference between TPL and SPL).
>> 
>> Here’s the test output from my commandline:
>> 
>> ptomsich@android:~/rk3399-spl/u-boot$ 
>> ~/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-gcc -nostdinc -Iinclude
>> -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ 
>> -D__UBOOT__ -DCONFIG_SPL_BUILD -DCONFIG_TPL_BUILD 
>> -DCONFIG_TPL_SYS_THUMB_BUILD -D__ASSEMBLY__ -g -DCONFIG_THUMB2_KERNEL 
>> -D__ARM__ -Wa,-mimplicit-it=always -mthumb -mthumb-interwork 
>> -mabi=aapcs-linux -mno-unaligned-access -ffunction-sections -fdata-sections 
>> -fno-common -ffixed-r9 -msoft-float -pipe -march=armv7-a 
>> -D__LINUX_ARM_ARCH__=7 -I./arch/arm/mach-rockchip/include -c -o /tmp/test.o 
>> arch/arm/lib/memcpy.S && echo 'GREAT SUCCESS'
>> GREAT SUCCESS
>> 
>> Note that this is a 'gcc version 6.3.0’ built from source.
>> 
>>> On 30 Aug 2017, at 11:27, Kever Yang >> > wrote:
>>> 
>>> Philipp,
>>> 
>>> On 08/30/2017 04:59 PM, Dr. Philipp Tomsich wrote:
 Kever,
 
 I took a quick look and this seems to be an issue with CONFIG macros.
 This is failing, because the assembly (after preprocessing) requests 
 regular ARM mode and
 supplies Thumb mnemonics (e.g. nop.w).
 
 The trigger seems to be the following CONFIG_IS_ENABLED check in 
 arch/arm/lib/memcpy.S:
#if CONFIG_IS_ENABLED(SYS_THUMB_BUILD) && 
 !defined(MEMCPY_NO_THUMB_BUILD)
   .thumb
   .thumb_func
#endif
>>> 
>>> This is the first point I checked, and I'm sure .thunb and .thumb_func are 
>>> there.
>>> Both and the SPL_SYS_THUMB_BUILD and SYS_THUMB_BUILD are defined, they are 
>>> enabled
>>> by default in armv7.
>>> 
 I checked that this compiles correctly, if I supply 
 -DCONFIG_SPL_SYS_THUMB_BUILD on the
 commandline. Works as expected.
>>> 
>>> I check with command below and the error still there.
>>> arm-linux-gnueabihf-gcc -Wp,-MD,tpl/arch/arm/lib/.memcpy.o.d  -nostdinc 
>>> -isystem /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include -Iinclude
>>> -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ 
>>> -D__UBOOT__ -DCONFIG_SPL_BUILD -DCONFIG_TPL_BUILD 
>>> -DCONFIG_SPL_SYS_THUMB_BUILD -D__ASSEMBLY__ -g -DCONFIG_THUMB2_KERNEL 
>>> -D__ARM__ -Wa,-mimplicit-it=always -mthumb -mthumb-interwork 
>>> -mabi=aapcs-linux -mno-unaligned-access -ffunction-sections -fdata-sections 
>>> -fno-common -ffixed-r9 -msoft-float -pipe -march=armv7-a 
>>> -D__LINUX_ARM_ARCH__=7 -I./arch/arm/mach-rockchip/include   -c -o 
>>> tpl/arch/arm/lib/memcpy.o arch/arm/lib/memcpy.S
>>> 
>>> Thanks,
>>> - Kever
 So, you’ll just have to enable SPL_SYS_THUMB_BUILD for you configuration 
 (see also Tom’s
 commit message in commit 3a649407a49b041ceb826d55b5919dc8297f8965).
 
 Regards,
 Philipp.
 
> On 30 Aug 2017, at 10:33, Kever Yang 

Re: [U-Boot] [PATCH] sunxi: Change SUNXI_GMAC to SUN7I_GMAC in sources

[Jagan Teki]

On Wed, Aug 30, 2017 at 2:59 PM, Lionel Koenig  wrote:
> Hi,
> I found that in commit-id 4d43d065db3262f9a9918ba72457bf36dfb8e0bb was
> changing SUNXI_GMAC config to SUN7I_GMAC. However, after that change, the
> PHY was not initialized correctly on my board (Olimex
> Olinuxino-A20-Lime2-eMMC).
> This patch should correct the behavior. However, beeing my first patch to
> u-boot, I wouldn't mind few other pair of eyes.

Please use git send-email for patch submission, read here [1] for more info.

[1] https://www.denx.de/wiki/view/U-Boot/Patches#General_Patch_Submission_Rules

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] pci: layerscape: Fixup iommu-map for LS208xA

[Bharat Bhushan]

"pci: layerscape: Fixup device tree node for ls2088a" added
support for LS208xA devices but fixing iommu-map property
is missing. This patch adds support for fixing iommu-map.

Signed-off-by: Bharat Bhushan 
Signed-off-by: Ioana Ciornei 
---
 drivers/pci/pcie_layerscape_fixup.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 9e6c2f5..3dae201 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -130,19 +130,28 @@ static void fdt_pcie_set_iommu_map_entry(void *blob, 
struct ls_pcie *pcie,
u32 iommu_map[4];
int nodeoffset;
int lenp;
+   uint svr;
+   char *compat = NULL;
 
/* find pci controller node */
nodeoffset = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
   pcie->dbi_res.start);
if (nodeoffset < 0) {
 #ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   nodeoffset = fdt_node_offset_by_compat_reg(blob,
-   CONFIG_FSL_PCIE_COMPAT, pcie->dbi_res.start);
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A ||
+   svr == SVR_LS2081A || svr == SVR_LS2041A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+
+   if (compat)
+   nodeoffset = fdt_node_offset_by_compat_reg(blob,
+   compat, pcie->dbi_res.start);
+#endif
if (nodeoffset < 0)
return;
-#else
-   return;
-#endif
}
 
/* get phandle to iommu controller */
-- 
1.9.3

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

Re: [U-Boot] [PATCH] usb: dwc2: Align size of invalidating dcache before starting DMA

[Seung-Woo Kim]

Hello,

This patch was tested with Exynos4412 Odroid-U3 board for THOR usb gadget 
driver.

Best Regards,
- Seung-Woo Kim

> -Original Message-
> From: Seung-Woo Kim [mailto:sw0312@samsung.com]
> Sent: Monday, July 31, 2017 6:08 PM
> To: u-boot@lists.denx.de; lu...@denx.de; ma...@denx.de
> Cc: sw0312@samsung.com; xzy...@rock-chips.com; jh80.ch...@samsung.com
> Subject: [PATCH] usb: dwc2: Align size of invalidating dcache before starting 
> DMA
> 
> During using dwc2 usb gadget, if usb message size is too small,
> following cache misaligned warning is shown:
> 
>CACHE: Misaligned operation at range [bfdbcb00, bfdbcb04]
> 
> Align size of invalidating dcache before starting DMA to remove the
> warning.
> 
> Signed-off-by: Seung-Woo Kim 
> ---
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> index 0d6d2fb..b6164af 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> @@ -111,7 +111,8 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
> dwc2_request *req)
>   ctrl =  readl(>out_endp[ep_num].doepctl);
> 
>   invalidate_dcache_range((unsigned long) ep->dma_buf,
> - (unsigned long) ep->dma_buf + ep->len);
> + (unsigned long) ep->dma_buf +
> + ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
> 
>   writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
>   writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
> --
> 1.7.9.5


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

Re: [U-Boot] [PATCH] cmd: set filesize variable in ubi read

[Heiko Schocher]

Hello Holger,

Am 30.08.2017 um 18:38 schrieb Holger Dengler:

After a successful read of a UBI volume, the variable filesize is set
to the number of read bytes. To boot linux with a raw initramfs/initrd,
you must specify the exact size of the initramfs/initrd image in boot
command. If the initramfs/inird is read from UBI volume, $filesize is
required to access the number of read bytes.

Example:
   ubi read ${loadaddr} kernelvol
   ubi read ${fdtaddr} dtbvol
   ubi read ${initrd_addr} initrdvol
   bootz ${loadaddr} ${initrd_addr}:${filesize} ${fdt_addr}

Signed-off-by: Holger Dengler 
---
  cmd/ubi.c | 5 +
  1 file changed, 5 insertions(+)


Thanks!

Reviewed-by: Heiko Schocher 

As new release is near, I pickup this patch when the next merge window
opens.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine

[Bin Meng]

Hi Tuomas,

On Wed, Aug 30, 2017 at 4:31 PM, Tuomas Tynkkynen
 wrote:
> This board builds an U-Boot binary that is bootable with QEMU's 'virt'
> machine on ARM. The minimal QEMU command line is:
>
> qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
>
> (Note that the 'highmem=off' parameter to the 'virt' machine is required for
> PCI to work in U-Boot.) This command line enables the following:
> - u-boot.bin loaded and executing in the emulated flash at address 0x0
> - A generated device tree blob placed at the start of RAM
> - A freely configurable amount of RAM, described by the DTB
> - A PL011 serial port, discoverable via the DTB
> - An ARMv7 architected timer
> - PSCI for rebooting the system
> - A generic ECAM-based PCI host controller, discoverable via the DTB
>
> Additionally, QEMU allows plugging a bunch of useful peripherals to the PCI 
> bus.
> The following ones are supported by both U-Boot and Linux:
>
> - To enable a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.:
> -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device 
> ide-drive,drive=mydisk,bus=ahci.0
> - To enable an Intel E1000 network adapter, pass e.g.:
> -net nic,model=e1000 -net user
> - To add an EHCI-compliant USB host controller, pass e.g.:
> -device usb-ehci,id=ehci

Can we enable the NVMe driver (CONFIG_NVME) here?

>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  arch/arm/Kconfig   | 10 
>  arch/arm/mach-qemu/Kconfig |  9 +++
>  board/qemu-arm/Makefile|  5 
>  board/qemu-arm/qemu-arm.c  | 35 ++
>  configs/qemu_arm_defconfig | 27 
>  include/configs/qemu-arm.h | 63 
> ++
>  6 files changed, 149 insertions(+)
>  create mode 100644 arch/arm/mach-qemu/Kconfig
>  create mode 100644 board/qemu-arm/Makefile
>  create mode 100644 board/qemu-arm/qemu-arm.c
>  create mode 100644 configs/qemu_arm_defconfig
>  create mode 100644 include/configs/qemu-arm.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 53d0831935..0d01ba1b73 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -630,6 +630,14 @@ config ARCH_MX5
> select CPU_V7
> select BOARD_EARLY_INIT_F
>
> +config ARCH_QEMU
> +   bool "QEMU Virtual Platform"
> +   select CPU_V7
> +   select ARCH_SUPPORT_PSCI
> +   select DM
> +   select DM_SERIAL
> +   select OF_CONTROL
> +
>  config ARCH_RMOBILE
> bool "Renesas ARM SoCs"
> select DM
> @@ -1149,6 +1157,8 @@ source "arch/arm/mach-stm32/Kconfig"
>
>  source "arch/arm/mach-sunxi/Kconfig"
>
> +source "arch/arm/mach-qemu/Kconfig"
> +

Can you insert this by following alphabetical order?

>  source "arch/arm/mach-tegra/Kconfig"
>
>  source "arch/arm/mach-uniphier/Kconfig"
> diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
> new file mode 100644
> index 00..89d2a36719
> --- /dev/null
> +++ b/arch/arm/mach-qemu/Kconfig
> @@ -0,0 +1,9 @@
> +if ARCH_QEMU
> +
> +config SYS_BOARD
> +   default "qemu-arm"
> +
> +config SYS_CONFIG_NAME
> +   default "qemu-arm"
> +
> +endif
> diff --git a/board/qemu-arm/Makefile b/board/qemu-arm/Makefile
> new file mode 100644
> index 00..3e9907d983
> --- /dev/null
> +++ b/board/qemu-arm/Makefile

Can this new board be put into the board/emulation/qemu-arm directory?
Since qemu-x86 is put there.

> @@ -0,0 +1,5 @@
> +#
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +
> +obj-y  += qemu-arm.o
> diff --git a/board/qemu-arm/qemu-arm.c b/board/qemu-arm/qemu-arm.c
> new file mode 100644
> index 00..90d7badbf4
> --- /dev/null
> +++ b/board/qemu-arm/qemu-arm.c
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright (c) 2017 Tuomas Tynkkynen
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;

This is not needed as gd is not referenced in this file.

> +
> +int board_init(void)
> +{
> +   return 0;
> +}
> +
> +int dram_init(void)
> +{
> +   if (fdtdec_setup_memory_size() != 0)
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
> +int dram_init_banksize(void)
> +{
> +   fdtdec_setup_memory_banksize();
> +
> +   return 0;
> +}
> +
> +void *board_fdt_blob_setup(void)
> +{
> +   /* QEMU loads a generated DTB for us at the start of RAM. */
> +   return (void *)CONFIG_SYS_SDRAM_BASE;
> +}
> diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
> new file mode 100644
> index 00..d34512dd0d
> --- /dev/null
> +++ b/configs/qemu_arm_defconfig
> @@ -0,0 +1,27 @@
> +CONFIG_ARM=y
> +CONFIG_ARM_SMCCC=y
> +CONFIG_ARCH_QEMU=y
> +CONFIG_AHCI=y
> +CONFIG_DISTRO_DEFAULTS=y
> +# CONFIG_DISPLAY_CPUINFO is not set
> +# CONFIG_DISPLAY_BOARDINFO is not set
> +# CONFIG_CMD_IMLS is not set
> +CONFIG_CMD_PCI=y
> +CONFIG_CMD_USB=y
> +CONFIG_OF_BOARD=y
> +CONFIG_AHCI_PCI=y

Re: [U-Boot] [PATCH 1/2] PCI: Add driver for a 'pci-host-ecam-generic' host controller

[Bin Meng]

Hi Tuomas,

On Wed, Aug 30, 2017 at 4:31 PM, Tuomas Tynkkynen
 wrote:
> QEMU emulates such a device with '-machine virt,highmem=off' on ARM.
> The 'highmem=off' part is required for things to work as the PCI code
> in U-Boot doesn't seem to support 64-bit BARs.
>
> This driver is basically a copy-paste of the Xilinx PCIE driver with the
> Xilinx-specific bits removed and compatible string changed... The
> generic code should probably be extracted into some sort of library
> functions instead of duplicating them before committing this driver.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/pci/Kconfig |   8 ++
>  drivers/pci/Makefile|   1 +
>  drivers/pci/pcie_ecam_generic.c | 193 
> 
>  3 files changed, 202 insertions(+)
>  create mode 100644 drivers/pci/pcie_ecam_generic.c
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index e2a1c0a409..745161fb9f 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -33,6 +33,14 @@ config PCI_PNP
> help
>   Enable PCI memory and I/O space resource allocation and assignment.
>
> +config PCIE_ECAM_GENERIC
> +   bool "Generic PCI-E ECAM support"
> +   default n

nits: default n is not needed as it is the default value

> +   depends on DM_PCI
> +   help
> + Say Y here if you want to enable support for generic ECAM-based
> + PCIe controllers, such as the one emulated by QEMU.
> +
>  config PCIE_DW_MVEBU
> bool "Enable Armada-8K PCIe driver (DesignWare core)"
> default n
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index ad44e83996..5eb12efbf5 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_PCI) += pci.o pci_auto_old.o
>  endif
>  obj-$(CONFIG_PCI) += pci_auto_common.o pci_common.o
>
> +obj-$(CONFIG_PCIE_ECAM_GENERIC) += pcie_ecam_generic.o
>  obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
>  obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o
>  obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
> diff --git a/drivers/pci/pcie_ecam_generic.c b/drivers/pci/pcie_ecam_generic.c
> new file mode 100644
> index 00..039e378cb0
> --- /dev/null
> +++ b/drivers/pci/pcie_ecam_generic.c
> @@ -0,0 +1,193 @@
> +/*
> + * Generic PCIE host provided by e.g. QEMU
> + *
> + * Heavily based on drivers/pci/pcie_xilinx.c
> + *
> + * Copyright (C) 2016 Imagination Technologies
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/**
> + * struct generic_ecam_pcie - generic_ecam PCIe controller state
> + * @hose: The parent classes PCI controller state
> + * @cfg_base: The base address of memory mapped configuration space
> + */
> +struct generic_ecam_pcie {
> +   struct pci_controller hose;

This sounds like a non-DM PCI driver stuff. I don't see it is
referenced in this driver.

> +   void *cfg_base;
> +};
> +
> +/**
> + * pcie_generic_ecam_config_address() - Calculate the address of a config 
> access
> + * @pcie: Pointer to the PCI controller state
> + * @bdf: Identifies the PCIe device to access
> + * @offset: The offset into the device's configuration space
> + * @paddress: Pointer to the pointer to write the calculates address to
> + *
> + * Calculates the address that should be accessed to perform a PCIe
> + * configuration space access for a given device identified by the PCIe
> + * controller device @pcie and the bus, device & function numbers in @bdf. If
> + * access to the device is not valid then the function will return an error
> + * code. Otherwise the address to access will be written to the pointer 
> pointed
> + * to by @paddress.
> + *
> + * Return: 0 on success, else -ENODEV

I see this driver always return 0.

> + */
> +static int pcie_generic_ecam_config_address(struct generic_ecam_pcie *pcie, 
> pci_dev_t bdf,
> + uint offset, void **paddress)
> +{
> +   unsigned int bus = PCI_BUS(bdf);
> +   unsigned int dev = PCI_DEV(bdf);
> +   unsigned int func = PCI_FUNC(bdf);
> +   void *addr;
> +
> +   addr = pcie->cfg_base;
> +   addr += bus << 20;
> +   addr += dev << 15;
> +   addr += func << 12;
> +   addr += offset;
> +   *paddress = addr;
> +
> +   return 0;
> +}
> +
> +/**
> + * pcie_generic_ecam_read_config() - Read from configuration space
> + * @pcie: Pointer to the PCI controller state

There is no pcie parameter, instead it's bus.

> + * @bdf: Identifies the PCIe device to access
> + * @offset: The offset into the device's configuration space
> + * @valuep: A pointer at which to store the read value
> + * @size: Indicates the size of access to perform
> + *
> + * Read a value of size @size from offset @offset within the configuration
> + * space of the device identified by the bus, device & function numbers in 
> @bdf
> + * on the PCI bus @bus.
> 

Re: [U-Boot] [PATCH v2 3/3] rockchip: evb-rk3399: update document for board bring up

[Jagan Teki]

Hi Kever,

On Thu, Aug 31, 2017 at 6:37 AM, Kever Yang  wrote:
> Hi Jagan,
>
>
>
> On 08/30/2017 11:10 PM, Jagan Teki wrote:
>>
>> + Philipp
>>
>> On Mon, Aug 21, 2017 at 6:30 PM, Kever Yang 
>> wrote:
>>>
>>> Since we support ATF in SPL and add script for it, let's make the
>>> document up to date.
>>>
>>> Signed-off-by: Kever Yang 
>>> Acked-by: Philipp Tomsich 
>>> ---
>>>
>>> Changes in v2:
>>> - typo fix, evb-firefly－>firefly-rk3399
>>>
>>>   board/rockchip/evb_rk3399/README | 79
>>> 
>>>   1 file changed, 63 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/board/rockchip/evb_rk3399/README
>>> b/board/rockchip/evb_rk3399/README
>>> index fb8bb19..b5c7614 100644
>>> --- a/board/rockchip/evb_rk3399/README
>>> +++ b/board/rockchip/evb_rk3399/README
>>> @@ -18,8 +18,8 @@ evb key features:
>>>   * PMIC: rk808
>>>   * debug console: UART2
>>>
>>> -In order to support Arm Trust Firmware(ATF), we need to use the
>>> -miniloader from rockchip which:
>>> +In order to support Arm Trust Firmware(ATF), we can use either SPL or
>>> +miniloader from rockchip to do:
>>>   * do DRAM init
>>>   * load and verify ATF image
>>>   * load and verify U-Boot image
>>> @@ -32,8 +32,8 @@ Get the Source and prebuild binary
>>> > mkdir ~/evb_rk3399
>>> > cd ~/evb_rk3399
>>> > git clone https://github.com/ARM-software/arm-trusted-firmware.git
>>> -  > git clone https://github.com/rockchip-linux/rkbin
>>> -  > git clone https://github.com/rockchip-linux/rkflashtool
>>> +  > git clone https://github.com/rockchip-linux/rkbin.git
>>> +  > git clone https://github.com/rockchip-linux/rkdeveloptool.git
>>>
>>>   Compile the ATF
>>>   ===
>>> @@ -42,32 +42,79 @@ Compile the ATF
>>> > make realclean
>>> > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
>>>
>>> +  Or you can get the bl31.elf directly from Rockchip:
>>> +  cp rkbin/rk33/rk3399_bl31_v1.00.elf ../u-boot/bl31.elf
>>> +
>>> +  Get bl31.elf in this step, copy it to U-Boot root dir:
>>> +  > cp bl31.elf ../u-boot/
>>> +
>>>   Compile the U-Boot
>>>   ==
>>>
>>> > cd ../u-boot
>>> -  > make CROSS_COMPILE=aarch64-linux-gnu- evb-rk3399_defconfig all
>>> +  > export ARCH=arm64
>>> +  > export CROSS_COMPILE=aarch64-linux-gnu-
>>> +  > make evb-rk3399_defconfig
>>> +  for firefly-rk3399, use below instead:
>>> +  > make firefly-rk3399_defconfig
>>> +  > make
>>> +  > make u-boot.itb
>>>
>>> -Compile the rkflashtool
>>> -===
>>> +  Get spl/u-boot-spl.bin and u-boot.itb in this step.
>>>
>>> +Compile the rkdeveloptool
>>> +===
>>> +  Follow instructions in latest README
>>> > cd ../rkflashtool
>>> +  > autoreconf -i
>>> +  > ./configure
>>> > make
>>> +  > sudo make install
>>> +
>>> +  Get rkdeveloptool in you Host in this step.
>>> +
>>> +Both origin binaries and Tool are ready now, choose either option 1 or
>>> +option 2 to deploy U-Boot.
>>> +
>>> +Package the image
>>> +=
>>>
>>> -Package the image for miniloader
>>> -
>>> +Package the image for U-Boot SPL(option 1)
>>> +
>>> > cd ..
>>> -  > cp arm-trusted-firmware/build/rk3399/release/bl31.bin rkbin/rk33
>>> +  > tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
>>> +
>>> +  Get idbspl.img in this step.
>>> +
>>> +Package the image for Rockchip miniloader(option 2)
>>> +--
>>> +  > cd ..
>>> +  > cp arm-trusted-firmware/build/rk3399/release/bl31.elf rkbin/rk33
>>> > ./rkbin/tools/trust_merger rkbin/tools/RK3399TRUST.ini
>>> > ./rkbin/tools/loaderimage --pack --uboot u-boot/u-boot-dtb.bin
>>> uboot.img
>>> -  > mkdir image
>>> -  > mv trust.img ./image/
>>> -  > mv uboot.img ./image/rk3399evb-uboot.bin
>>>
>>> -Flash the image
>>> -===
>>> +  Get trust.img and uboot.img in this step.
>>> +
>>> +Flash the image to eMMC
>>> +===
>>> +
>>> +Flash the image with U-Boot SPL(option 1)
>>> +---
>>>   Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then:
>>> +  > rkdeveloptool db rkbin/rk33/rk3399_loader_v1.08.106.bin
>>> +  > rkdeveloptool wl 64 u-boot/idbspl.img
>>> +  > rkdeveloptool wl 512 u-boot/u-boot.itb
>>> +  > rkdeveloptool rd
>>
>> Do we still need rk3399_loader_v1.08.106.bin? if u-boot.itb has ATF,
>
>
> We need this for db command for now, if we enable rockusb in U-Boot, then we
> don't
> need db command and we don't need rk3399_loader_v1.08.106.bin
>
> rk3399_loader_v1.08.106.bin will be there for Windows flash tool like
> rkdeveloptool in Linux.

Ok, thanks for the info.

I'm trying to boot from SDMMC and written SPL and u-boot.itb
(ATF+Cortex-M0) like

# dd if=spl of=/dev/mmcblk0 seek=64
# dd if=u-boot.itb of=/dev/mmcblk0 seek=512

With