Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed

2018-09-24 Thread Alex Kiernan
On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes
 wrote:
>
> In the case where one deletes an already-non-existing variable, or sets
> a variable to the value it already has, there is no point in writing the
> environment back, thus reducing wear on the underlying storage
> device.
>
> Signed-off-by: Rasmus Villemoes 

If you were running with a redundant env, and you were trying to sync
both copies, wouldn't you want a non-changing write to happen?

> ---
>  tools/env/fw_env.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
> index a5d75958e1..87aaa15198 100644
> --- a/tools/env/fw_env.c
> +++ b/tools/env/fw_env.c
> @@ -110,6 +110,7 @@ struct environment {
> unsigned char *flags;
> char *data;
> enum flag_scheme flag_scheme;
> +   int dirty;
>  };
>
>  static struct environment environment = {
> @@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts)
> if (!opts)
> opts = &default_opts;
>
> +   if (!environment.dirty)
> +   return 0;
> +
> /*
>  * Update CRC
>  */
> @@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value)
>
> deleting = (oldval && !(value && strlen(value)));
> creating = (!oldval && (value && strlen(value)));
> -   overwriting = (oldval && (value && strlen(value)));
> +   overwriting = (oldval && (value && strlen(value) &&
> + strcmp(oldval, value)));
>
> /* check for permission */
> if (deleting) {
> @@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value)
> /* Nothing to do */
> return 0;
>
> +   environment.dirty = 1;
> if (deleting || overwriting) {
> if (*++nxt == '\0') {
> *env = '\0';
> @@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default 
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> +   environment.dirty = 1;
> }
> } else {
> flag0 = *environment.flags;
> @@ -1503,6 +1510,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default 
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> +   environment.dirty = 1;
> dev_current = 0;
> } else {
> switch (environment.flag_scheme) {
> --
> 2.16.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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


Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback

2018-09-24 Thread Patrice CHOTARD
Hi Andy

On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> TBD

You forgot to add a commit message ;-)

> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/serial/ns16550.c   | 14 ++
>  drivers/serial/serial-uclass.c | 21 +
>  include/common.h   |  3 +++
>  include/serial.h   | 14 ++
>  4 files changed, 52 insertions(+)
> 
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index f9041aa626..a996446936 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev, 
> int baudrate)
>   return 0;
>  }
>  
> +static int ns16550_serial_getinfo(struct udevice *dev, struct 
> serial_device_info *info)
> +{
> + struct NS16550 *const com_port = dev_get_priv(dev);
> + struct ns16550_platdata *plat = com_port->plat;
> +
> + info->addr_space = 0;
> + info->reg_width = 8;
> + info->reg_shift = plat->reg_shift;
> + info->reg_offset = plat->reg_offset;
> + info->addr = plat->base;
> + return 0;
> +}
> +
>  int ns16550_serial_probe(struct udevice *dev)
>  {
>   struct NS16550 *const com_port = dev_get_priv(dev);
> @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
>   .pending = ns16550_serial_pending,
>   .getc = ns16550_serial_getc,
>   .setbrg = ns16550_serial_setbrg,
> + .getinfo = ns16550_serial_getinfo,
>  };
>  
>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index ffdcae0931..4778302e8f 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
>   return 0;
>  }
>  
> +int serial_getinfo(struct serial_device_info *info)
> +{
> + struct dm_serial_ops *ops;
> +
> + if (!gd->cur_serial_dev)
> + return -ENODEV;
> +
> + if (!info)
> + return -EINVAL;
> +
> + info->baudrate = gd->baudrate;
> +
> + ops = serial_get_ops(gd->cur_serial_dev);
> + if (ops->getinfo)
> + return ops->getinfo(gd->cur_serial_dev, info);
> +
> + return -EINVAL;
> +}
> +
>  void serial_stdio_init(void)
>  {
>  }
> @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
>   if (ops->loop)
>   ops->loop += gd->reloc_off
>  #endif
> + if (ops->getinfo)
> + ops->getinfo += gd->reloc_off;
>  #endif
>   /* Set the baud rate */
>   if (ops->setbrg) {
> diff --git a/include/common.h b/include/common.h
> index 83b3bdc58d..0479f3eac1 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int 
> corenr);
>  void smp_kick_all_cpus(void);
>  
>  /* $(CPU)/serial.c */
> +struct serial_device_info;
> +
>  int  serial_init   (void);
>  void serial_setbrg (void);
>  void serial_putc   (const char);
> @@ -357,6 +359,7 @@ void  serial_puts   (const char *);
>  int  serial_getc   (void);
>  int  serial_tstc   (void);
>  int  serial_setconfig(uint config);
> +int  serial_getinfo(struct serial_device_info *info);
>  
>  /* $(CPU)/speed.c */
>  int  get_clocks (void);
> diff --git a/include/serial.h b/include/serial.h
> index 020cd392e8..c73477b079 100644
> --- a/include/serial.h
> +++ b/include/serial.h
> @@ -111,6 +111,16 @@ enum serial_stop {
>   SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
>   SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
>  
> +/* REVISIT: ACPI GAS specification implied */
> +struct serial_device_info {
> + unsigned int baudrate;
> + u8  addr_space; /* 0 - MMIO, 1 - IO */
> + u8  reg_width;
> + u8  reg_offset;
> + u8  reg_shift;
> + u64 addr;
> +};
> +
>  /**
>   * struct struct dm_serial_ops - Driver model serial operations
>   *
> @@ -201,6 +211,10 @@ struct dm_serial_ops {
>* @return 0 if OK, -ve on error
>*/
>   int (*setconfig)(struct udevice *dev, uint serial_config);
> + /**
> +  * getinfo() - Get serial device information
> +  */
> + int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
>  };
>  
>  /**
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/2] WIP: x86: acpi: Generate SPCR table

2018-09-24 Thread Patrice CHOTARD


On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> TBD

Same remark as Patch 1

> 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/acpi_table.h | 25 ++
>  arch/x86/lib/acpi_table.c | 82 +++
>  2 files changed, 107 insertions(+)
> 
> diff --git a/arch/x86/include/asm/acpi_table.h 
> b/arch/x86/include/asm/acpi_table.h
> index 95fae036f6..27435871b9 100644
> --- a/arch/x86/include/asm/acpi_table.h
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -303,6 +303,31 @@ struct acpi_mcfg_mmconfig {
>  /* ACPI global NVS structure */
>  struct acpi_global_nvs;
>  
> +/* SPCR (Serial Port Console Redirection table) */
> +struct __packed acpi_spcr {
> + struct acpi_table_header header;/* Common ACPI table header */
> + u8 interface_type;  /* 0=full 16550, 1=subset of 16550 */
> + u8 reserved[3];
> + struct acpi_gen_regaddr serial_port;/* The base address of the 
> Serial Port register set */
> + u8 interrupt_type;
> + u8 pc_interrupt;
> + u32 interrupt;  /* Global system interrupt */
> + u8 baud_rate;
> + u8 parity;
> + u8 stop_bits;
> + u8 flow_control;
> + u8 terminal_type;
> + u8 reserved1;
> + u16 pci_device_id;  /* Must be 0x if not PCI device */
> + u16 pci_vendor_id;  /* Must be 0x if not PCI device */
> + u8 pci_bus;
> + u8 pci_device;
> + u8 pci_function;
> + u32 pci_flags;
> + u8 pci_segment;
> + u32 reserved2;
> +};
> +
>  /* These can be used by the target port */
>  
>  void acpi_fill_header(struct acpi_table_header *header, char *signature);
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index c6b2026613..551a78b11a 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -338,6 +339,79 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
>   header->checksum = table_compute_checksum((void *)mcfg, header->length);
>  }
>  
> +static void acpi_create_spcr(struct acpi_spcr *spcr)
> +{
> + struct acpi_table_header *header = &(spcr->header);
> + struct serial_device_info info = {0};
> + int access_size;
> + int ret;
> +
> + /* Fill out header fields */
> + acpi_fill_header(header, "SPCR");
> + header->length = sizeof(struct acpi_spcr);
> + header->revision = 2;
> +
> + ret = serial_getinfo(&info);
> + if (ret)
> + debug("Can't get information of serial device: %d\n", ret);
> +
> + /* Encode baud rate */
> + switch (info.baudrate) {
> + case 9600:
> + spcr->baud_rate = 3;
> + break;
> + case 19200:
> + spcr->baud_rate = 4;
> + break;
> + case 57600:
> + spcr->baud_rate = 6;
> + break;
> + case 115200:
> + spcr->baud_rate = 7;
> + break;
> + default:
> + spcr->baud_rate = 0;
> + break;
> + }
> +
> + /* Encode register access size */
> + switch (info.reg_shift) {
> + case 0:
> + access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS;
> + break;
> + case 1:
> + access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
> + break;
> + case 2:
> + access_size = ACPI_ACCESS_SIZE_DWORD_ACCESS;
> + break;
> + case 3:
> + access_size = ACPI_ACCESS_SIZE_QWORD_ACCESS;
> + break;
> + default:
> + access_size = ACPI_ACCESS_SIZE_UNDEFINED;
> + break;
> + }
> +
> + spcr->serial_port.space_id = ACPI_ADDRESS_SPACE_MEMORY;
> + spcr->serial_port.bit_width = info.reg_width;
> + spcr->serial_port.bit_offset = info.reg_offset;
> + spcr->serial_port.access_size = access_size;
> + spcr->serial_port.addrl = info.addr >> 0;
> + spcr->serial_port.addrh = info.addr >> 32;
> +
> + /* Hard coded values for now */
> + spcr->parity = 0;
> + spcr->stop_bits = 1;
> +
> + /* No PCI devices for now */
> + spcr->pci_device_id = 0x;
> + spcr->pci_vendor_id = 0x;
> +
> + /* Fix checksum */
> + header->checksum = table_compute_checksum((void *)spcr, header->length);
> +}
> +
>  /*
>   * QEMU's version of write_acpi_tables is defined in drivers/misc/qfw.c
>   */
> @@ -352,6 +426,7 @@ ulong write_acpi_tables(ulong start)
>   struct acpi_fadt *fadt;
>   struct acpi_mcfg *mcfg;
>   struct acpi_madt *madt;
> + struct acpi_spcr *spcr;
>   int i;
>  
>   current = start;
> @@ -440,6 +515,13 @@ ulong write_acpi_tables(ulong start)
>   acpi_add_table(rsdp, mcfg);
>   current = ALIGN(current, 16);
>  
> + debug("ACPI:* SPCR\n");
> + spcr = (struct acpi_spcr *)current;
> + acpi_create_spcr(spcr);
> + current += spcr->header.length;
> + acpi_add_table(rsdp, spcr);
> + current 

Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback

2018-09-24 Thread Andy Shevchenko
On Mon, Sep 24, 2018 at 10:44 AM Patrice CHOTARD  wrote:
>
> Hi Andy
>
> On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> > TBD
>
> You forgot to add a commit message ;-)

Yes, cover letter explains why.
It's a halfbaked stuff in case someone is interested to continue.

For your convenience:
patch 1: introduces a hook to retrieve necessary data from UART driver
(in particular ns16550)
patch 2: adds SPCR data structures and uses hook from patch  1 to
generate the table

>
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/serial/ns16550.c   | 14 ++
> >  drivers/serial/serial-uclass.c | 21 +
> >  include/common.h   |  3 +++
> >  include/serial.h   | 14 ++
> >  4 files changed, 52 insertions(+)
> >
> > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> > index f9041aa626..a996446936 100644
> > --- a/drivers/serial/ns16550.c
> > +++ b/drivers/serial/ns16550.c
> > @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev, 
> > int baudrate)
> >   return 0;
> >  }
> >
> > +static int ns16550_serial_getinfo(struct udevice *dev, struct 
> > serial_device_info *info)
> > +{
> > + struct NS16550 *const com_port = dev_get_priv(dev);
> > + struct ns16550_platdata *plat = com_port->plat;
> > +
> > + info->addr_space = 0;
> > + info->reg_width = 8;
> > + info->reg_shift = plat->reg_shift;
> > + info->reg_offset = plat->reg_offset;
> > + info->addr = plat->base;
> > + return 0;
> > +}
> > +
> >  int ns16550_serial_probe(struct udevice *dev)
> >  {
> >   struct NS16550 *const com_port = dev_get_priv(dev);
> > @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
> >   .pending = ns16550_serial_pending,
> >   .getc = ns16550_serial_getc,
> >   .setbrg = ns16550_serial_setbrg,
> > + .getinfo = ns16550_serial_getinfo,
> >  };
> >
> >  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> > diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> > index ffdcae0931..4778302e8f 100644
> > --- a/drivers/serial/serial-uclass.c
> > +++ b/drivers/serial/serial-uclass.c
> > @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
> >   return 0;
> >  }
> >
> > +int serial_getinfo(struct serial_device_info *info)
> > +{
> > + struct dm_serial_ops *ops;
> > +
> > + if (!gd->cur_serial_dev)
> > + return -ENODEV;
> > +
> > + if (!info)
> > + return -EINVAL;
> > +
> > + info->baudrate = gd->baudrate;
> > +
> > + ops = serial_get_ops(gd->cur_serial_dev);
> > + if (ops->getinfo)
> > + return ops->getinfo(gd->cur_serial_dev, info);
> > +
> > + return -EINVAL;
> > +}
> > +
> >  void serial_stdio_init(void)
> >  {
> >  }
> > @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
> >   if (ops->loop)
> >   ops->loop += gd->reloc_off
> >  #endif
> > + if (ops->getinfo)
> > + ops->getinfo += gd->reloc_off;
> >  #endif
> >   /* Set the baud rate */
> >   if (ops->setbrg) {
> > diff --git a/include/common.h b/include/common.h
> > index 83b3bdc58d..0479f3eac1 100644
> > --- a/include/common.h
> > +++ b/include/common.h
> > @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int 
> > corenr);
> >  void smp_kick_all_cpus(void);
> >
> >  /* $(CPU)/serial.c */
> > +struct serial_device_info;
> > +
> >  int  serial_init   (void);
> >  void serial_setbrg (void);
> >  void serial_putc   (const char);
> > @@ -357,6 +359,7 @@ void  serial_puts   (const char *);
> >  int  serial_getc   (void);
> >  int  serial_tstc   (void);
> >  int  serial_setconfig(uint config);
> > +int  serial_getinfo(struct serial_device_info *info);
> >
> >  /* $(CPU)/speed.c */
> >  int  get_clocks (void);
> > diff --git a/include/serial.h b/include/serial.h
> > index 020cd392e8..c73477b079 100644
> > --- a/include/serial.h
> > +++ b/include/serial.h
> > @@ -111,6 +111,16 @@ enum serial_stop {
> >   SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> >   SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
> >
> > +/* REVISIT: ACPI GAS specification implied */
> > +struct serial_device_info {
> > + unsigned int baudrate;
> > + u8  addr_space; /* 0 - MMIO, 1 - IO */
> > + u8  reg_width;
> > + u8  reg_offset;
> > + u8  reg_shift;
> > + u64 addr;
> > +};
> > +
> >  /**
> >   * struct struct dm_serial_ops - Driver model serial operations
> >   *
> > @@ -201,6 +211,10 @@ struct dm_serial_ops {
> >* @return 0 if OK, -ve on error
> >*/
> >   int (*setconfig)(struct udevice *dev, uint serial_config);
> > + /**
> > +  * getinfo() - Get serial device information
> > +  */
> > + int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
> >  };
> >
> >  /**
> >
> ___
> U-Bo

Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed

2018-09-24 Thread Joakim Tjernlund
On Mon, 2018-09-24 at 08:42 +0100, Alex Kiernan wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes
>  wrote:
> > 
> > In the case where one deletes an already-non-existing variable, or sets
> > a variable to the value it already has, there is no point in writing the
> > environment back, thus reducing wear on the underlying storage
> > device.
> > 
> > Signed-off-by: Rasmus Villemoes 
> 
> If you were running with a redundant env, and you were trying to sync
> both copies, wouldn't you want a non-changing write to happen?

That is a valid point, I have sometimes used this property to make
sure I have a valid env. in both copies.

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


Re: [U-Boot] [PATCH] armv8: lsch3: Add support of serdes3 module

2018-09-24 Thread Priyanka Jain


> -Original Message-
> From: York Sun
> Sent: Saturday, September 22, 2018 2:40 AM
> To: Priyanka Jain 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: lsch3: Add support of serdes3 module
> 
> On 08/23/2018 11:43 PM, Priyanka Jain wrote:
> > Some lsch3 based SoCs like lx2160a contains three serdes modules.
> > Add support for third serdes protocol in lsch3
> >
> > Signed-off-by: Priyanka Jain 
> > ---
> 
> 
> 
> > 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 6981076..bec35e8 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
> > @@ -1,5 +1,6 @@
> >  /* SPDX-License-Identifier: GPL-2.0+ */
> >  /*
> > + * Copyright 2018 NXP
> >   * Copyright 2015 Freescale Semiconductor, Inc.
> >   */
> >
> 
> Let's not to leave a gap in the copyright year. We have been NXP since 2016.
> 
> York
OK, I will update the copyright in next version. Thanks
Priyanka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb board.

2018-09-24 Thread Pramod Kumar


>-Original Message-
>From: York Sun
>Sent: Friday, September 21, 2018 8:20 PM
>To: Pramod Kumar 
>Cc: u-boot@lists.denx.de
>Subject: Re: [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb
>board.
>
>On 08/21/2018 02:18 AM, Pramod Kumar wrote:
>> ls1088ardb-pb is another varinat of the ls1088ardb.
>> This board support two m.2 x2 gen 3 pcie card slot.
>> There is no support of sata, pcie standard slot, miniPCIE slot and TDM
>> in this board.
>>
>> Signed-off-by: Pramod Kumar 
>> ---
>> Changes in v2:
>>  - Fix the compilation issue when building u-boot for SD boot.
>>
>>  arch/arm/Kconfig  |  14 +++
>>  arch/arm/cpu/armv8/Kconfig|   1 +
>>  board/freescale/ls1088a/Kconfig   |  43 +++
>>  board/freescale/ls1088a/MAINTAINERS   |  18 +++
>>  board/freescale/ls1088a/Makefile  |   1 +
>>  board/freescale/ls1088a/ddr.h |   6 +-
>>  board/freescale/ls1088a/ls1088a.c |  25 +++-
>>  ... ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} |   2 +-
>>  ...defconfig => ls1088ardb_pb_qspi_defconfig} |   2 +-
>>  ...ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} |   2 +-
>>  ...ig => ls1088ardb_pb_sdcard_qspi_defconfig} |   2 +-
>>  include/configs/ls1088ardb_pb.h   | 113 ++
>>  12 files changed, 219 insertions(+), 10 deletions(-)  copy
>> configs/{ls1088ardb_qspi_SECURE_BOOT_defconfig =>
>> ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} (97%)  copy
>> configs/{ls1088ardb_qspi_defconfig => ls1088ardb_pb_qspi_defconfig}
>> (97%)  copy configs/{ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig =>
>> ls1088ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} (98%)  copy
>> configs/{ls1088ardb_sdcard_qspi_defconfig =>
>> ls1088ardb_pb_sdcard_qspi_defconfig} (98%)  create mode 100644
>> include/configs/ls1088ardb_pb.h
>>
>
>Is it possible to reuse ls1088ardb and detect the board at runtime?
>>
>>For distro boot we need diffrent board variable for ls1088ardb and 
>>ls1088ardb_pb, which can only be 
>>achieved by using config tagets CONFIG_TARGET_LS1088ARDB and 
>>CONFIG_TARGET_LS1088ARDB_PB respectively 
f>> or both the boards.
>
>
>> diff --git a/board/freescale/ls1088a/ddr.h
>> b/board/freescale/ls1088a/ddr.h index b35c4ae2da..7a76f6bd50 100644
>> --- a/board/freescale/ls1088a/ddr.h
>> +++ b/board/freescale/ls1088a/ddr.h
>> @@ -1,6 +1,8 @@
>>  /* SPDX-License-Identifier: GPL-2.0+ */
>>  /*
>> - * Copyright 2017 NXP
>> + * Copyright 2017-2018 NXP
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>
>Do not add another SPDX line.
>
>> Will fix and send patch again.
>York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Stefan Agner
On 13.08.2018 09:30, Gerard Salvatella wrote:
> Some boards require specific configuration prior to booting the kernel.
> For instance, our boards require shutting down the display to avoid
> fading transitions before the drivers are reloaded by the kernel. This
> could be facilitated by adding an extra hook during the os booting
> process.
> 
> Signed-off-by: Gerard Salvatella 

Tom, any thoughts on this? I guess it would get merged directly by you?

FWIW, I suggested this approach, and Gerards implementation looks good
to me, so:
Reviewed-by: Stefan Agner 

--
Stefan

> ---
>  common/bootm_os.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
>  }
> 
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> +   /* please define board specific board_preboot_os() */
> +}
> +
>  int boot_selected_os(int argc, char * const argv[], int state,
>  bootm_headers_t *images, boot_os_fn *boot_fn)
>  {
> +   board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
> 
> --
> 2.18.0
> 
> 
> [Toradex Logo]  Global Leader in Arm®
> Embedded Computer Modules
> 
> Choose
> Us
> | Products | Developer
> Center |
> Community |
> Careers
> Meet our engineers
> at:
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
> 
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Michael Nazzareno Trimarchi
Hi



On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner,  wrote:

> On 13.08.2018 09:30, Gerard Salvatella wrote:
> > Some boards require specific configuration prior to booting the kernel.
> > For instance, our boards require shutting down the display to avoid
> > fading transitions before the drivers are reloaded by the kernel. This
> > could be facilitated by adding an extra hook during the os booting
> > process.
>
> Maybe I can extend on what we are trying to achieve here:
>
> We enable display backlight using board code.
>

You can make it works almost easily.

I enable simple fb, inject allocated display parameters in dts to reserve
area, pass the area to the graphics controller and dismiss it during probing

This is mainline in linux support.

I have couple of patches need to clean up for imx architecture (imx6ull and
imx25)

You can still scripting it using cmd interface

Michael

>
> The architecture code then shuts down the display controller just before
> booting Linux (e.g. on i.MX, by calling
> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>
> This leads to a display which has backlight enabled, but no data
> driven... Depending on display this leads to noisy/fading transitions
> between U-Boot and Linux.
>
> So we would like to disable the backlight in board code.
>
> In a first version we used a weak display_shutdown() function, but with
> that we would have to add it to every architecture.
>
> This approach uses a generic board specific preeboot_os callback which
> can be used for different purpose too.
>
> Does this sound like an approach which is acceptable upstream?
>
> --
> Stefan
>
>
> >
> > Signed-off-by: Gerard Salvatella 
> > ---
> >  common/bootm_os.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/common/bootm_os.c b/common/bootm_os.c
> > index f4bd905909..1e7af56b64 100644
> > --- a/common/bootm_os.c
> > +++ b/common/bootm_os.c
> > @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> > /* please define platform specific arch_preboot_os() */
> >  }
> >
> > +/* Allow for board specific config before we boot */
> > +__weak void board_preboot_os(void)
> > +{
> > +   /* please define board specific board_preboot_os() */
> > +}
> > +
> >  int boot_selected_os(int argc, char * const argv[], int state,
> >  bootm_headers_t *images, boot_os_fn *boot_fn)
> >  {
> > +   board_preboot_os();
> > arch_preboot_os();
> > boot_fn(state, argc, argv, images);
> >
> > --
> > 2.18.0
> >
> >
> > [Toradex Logo]  Global Leader in Arm®
> > Embedded Computer Modules
> >
> > Choose
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> > | Products | Developer
> > Center |
> > Community |
> > Careers
> > Meet our engineers
> > at:
> > - Linux Developer Conference, Brazil, Aug 25-26, 2018
> > - NXP Technology Days 2018, United States, Aug 28, 2018
> > - IoT Latin America, Brazil, Aug 29-30, 2018
> >
> >
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Stefan Agner
On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner,  wrote:
> 
>> On 13.08.2018 09:30, Gerard Salvatella wrote:
>>> Some boards require specific configuration prior to booting the
>> kernel.
>>> For instance, our boards require shutting down the display to
>> avoid
>>> fading transitions before the drivers are reloaded by the kernel.
>> This
>>> could be facilitated by adding an extra hook during the os booting
>>> process.
>>
>> Maybe I can extend on what we are trying to achieve here:
>>
>> We enable display backlight using board code.
> 
> You can make it works almost easily. 
> 
> I enable simple fb, inject allocated display parameters in dts to
> reserve area, pass the area to the graphics controller and dismiss it
> during probing
> 
> This is mainline in linux support.
> 
> I have couple of patches need to clean up for imx architecture
> (imx6ull and imx25)

Definitely interested in those patches! Of course using this approach
leads to the most seamless booting experience.

But as far as I know it also needs proper (driver specific) Linux
support, is that correct?

So, I think its anyway worth having an option to properly disable the
display and backlight for older kernels/non-Linux OS.

--
Stefan

> 
> You can still scripting it using cmd interface
> 
> Michael
> 
>> The architecture code then shuts down the display controller just
>> before
>> booting Linux (e.g. on i.MX, by calling
>> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>>
>> This leads to a display which has backlight enabled, but no data
>> driven... Depending on display this leads to noisy/fading
>> transitions
>> between U-Boot and Linux.
>>
>> So we would like to disable the backlight in board code.
>>
>> In a first version we used a weak display_shutdown() function, but
>> with
>> that we would have to add it to every architecture.
>>
>> This approach uses a generic board specific preeboot_os callback
>> which
>> can be used for different purpose too.
>>
>> Does this sound like an approach which is acceptable upstream?
>>
>> --
>> Stefan
>>
>>>
>>> Signed-off-by: Gerard Salvatella 
>>> ---
>>> common/bootm_os.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/common/bootm_os.c b/common/bootm_os.c
>>> index f4bd905909..1e7af56b64 100644
>>> --- a/common/bootm_os.c
>>> +++ b/common/bootm_os.c
>>> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
>>> /* please define platform specific arch_preboot_os() */
>>> }
>>>
>>> +/* Allow for board specific config before we boot */
>>> +__weak void board_preboot_os(void)
>>> +{
>>> +   /* please define board specific board_preboot_os() */
>>> +}
>>> +
>>> int boot_selected_os(int argc, char * const argv[], int state,
>>> bootm_headers_t *images, boot_os_fn *boot_fn)
>>> {
>>> +   board_preboot_os();
>>> arch_preboot_os();
>>> boot_fn(state, argc, argv, images);
>>>
>>> --
>>> 2.18.0
>>>
>>>
>>> [Toradex Logo]  Global Leader in Arm®
>>> Embedded Computer Modules
>>>
>>> Choose
>>>
>>
> Us
>>> | Products | Developer
>>> Center |
>>> Community |
>>> Careers
>>> Meet our engineers
>>>
>> at:
>>> - Linux Developer Conference, Brazil, Aug 25-26, 2018
>>> - NXP Technology Days 2018, United States, Aug 28, 2018
>>> - IoT Latin America, Brazil, Aug 29-30, 2018
>>>
>>>
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb board.

2018-09-24 Thread York Sun
On 09/24/2018 02:29 AM, Pramod Kumar wrote:
> 
> 
>> -Original Message-
>> From: York Sun
>> Sent: Friday, September 21, 2018 8:20 PM
>> To: Pramod Kumar 
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb
>> board.
>>
>> On 08/21/2018 02:18 AM, Pramod Kumar wrote:
>>> ls1088ardb-pb is another varinat of the ls1088ardb.
>>> This board support two m.2 x2 gen 3 pcie card slot.
>>> There is no support of sata, pcie standard slot, miniPCIE slot and TDM
>>> in this board.
>>>
>>> Signed-off-by: Pramod Kumar 
>>> ---
>>> Changes in v2:
>>>  - Fix the compilation issue when building u-boot for SD boot.
>>>
>>>  arch/arm/Kconfig  |  14 +++
>>>  arch/arm/cpu/armv8/Kconfig|   1 +
>>>  board/freescale/ls1088a/Kconfig   |  43 +++
>>>  board/freescale/ls1088a/MAINTAINERS   |  18 +++
>>>  board/freescale/ls1088a/Makefile  |   1 +
>>>  board/freescale/ls1088a/ddr.h |   6 +-
>>>  board/freescale/ls1088a/ls1088a.c |  25 +++-
>>>  ... ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} |   2 +-
>>>  ...defconfig => ls1088ardb_pb_qspi_defconfig} |   2 +-
>>>  ...ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} |   2 +-
>>>  ...ig => ls1088ardb_pb_sdcard_qspi_defconfig} |   2 +-
>>>  include/configs/ls1088ardb_pb.h   | 113 ++
>>>  12 files changed, 219 insertions(+), 10 deletions(-)  copy
>>> configs/{ls1088ardb_qspi_SECURE_BOOT_defconfig =>
>>> ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} (97%)  copy
>>> configs/{ls1088ardb_qspi_defconfig => ls1088ardb_pb_qspi_defconfig}
>>> (97%)  copy configs/{ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig =>
>>> ls1088ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} (98%)  copy
>>> configs/{ls1088ardb_sdcard_qspi_defconfig =>
>>> ls1088ardb_pb_sdcard_qspi_defconfig} (98%)  create mode 100644
>>> include/configs/ls1088ardb_pb.h
>>>
>>
>> Is it possible to reuse ls1088ardb and detect the board at runtime?
>>>
>>> For distro boot we need diffrent board variable for ls1088ardb and 
>>> ls1088ardb_pb, which can only be 
>>> achieved by using config tagets CONFIG_TARGET_LS1088ARDB and 
>>> CONFIG_TARGET_LS1088ARDB_PB respectively 
> f>> or both the boards.

First, please use proper prefix for quotation and reply. It makes
reading easier.

If your only concern is default variable for distroboot, you can update
the default variable at runtime.

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


Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Michael Nazzareno Trimarchi
Hi



On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner,  wrote:

> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner,  wrote:
> >
> >> On 13.08.2018 09:30, Gerard Salvatella wrote:
> >>> Some boards require specific configuration prior to booting the
> >> kernel.
> >>> For instance, our boards require shutting down the display to
> >> avoid
> >>> fading transitions before the drivers are reloaded by the kernel.
> >> This
> >>> could be facilitated by adding an extra hook during the os booting
> >>> process.
> >>
> >> Maybe I can extend on what we are trying to achieve here:
> >>
> >> We enable display backlight using board code.
> >
> > You can make it works almost easily.
> >
> > I enable simple fb, inject allocated display parameters in dts to
> > reserve area, pass the area to the graphics controller and dismiss it
> > during probing
> >
> > This is mainline in linux support.
> >
> > I have couple of patches need to clean up for imx architecture
> > (imx6ull and imx25)
>
> Definitely interested in those patches! Of course using this approach
> leads to the most seamless booting experience.
>

Yes but there are a lot of reason to have when you deal multi-image update
and so on.


> But as far as I know it also needs proper (driver specific) Linux
> support, is that correct?
>

No that is wrong. imx6ull need a small patches right now I have applied in
kernel in legacy driver and not in drm one.

sunxi already implement everything in their side


> So, I think its anyway worth having an option to properly disable the
> display and backlight for older kernels/non-Linux OS.
>

gpio clear gpio-6 ; bootm ?

Michael

>
> --
> Stefan
>
> >
> > You can still scripting it using cmd interface
> >
> > Michael
> >
> >> The architecture code then shuts down the display controller just
> >> before
> >> booting Linux (e.g. on i.MX, by calling
> >> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
> >>
> >> This leads to a display which has backlight enabled, but no data
> >> driven... Depending on display this leads to noisy/fading
> >> transitions
> >> between U-Boot and Linux.
> >>
> >> So we would like to disable the backlight in board code.
> >>
> >> In a first version we used a weak display_shutdown() function, but
> >> with
> >> that we would have to add it to every architecture.
> >>
> >> This approach uses a generic board specific preeboot_os callback
> >> which
> >> can be used for different purpose too.
> >>
> >> Does this sound like an approach which is acceptable upstream?
> >>
> >> --
> >> Stefan
> >>
> >>>
> >>> Signed-off-by: Gerard Salvatella 
> >>> ---
> >>> common/bootm_os.c | 7 +++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/common/bootm_os.c b/common/bootm_os.c
> >>> index f4bd905909..1e7af56b64 100644
> >>> --- a/common/bootm_os.c
> >>> +++ b/common/bootm_os.c
> >>> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> >>> /* please define platform specific arch_preboot_os() */
> >>> }
> >>>
> >>> +/* Allow for board specific config before we boot */
> >>> +__weak void board_preboot_os(void)
> >>> +{
> >>> +   /* please define board specific board_preboot_os() */
> >>> +}
> >>> +
> >>> int boot_selected_os(int argc, char * const argv[], int state,
> >>> bootm_headers_t *images, boot_os_fn *boot_fn)
> >>> {
> >>> +   board_preboot_os();
> >>> arch_preboot_os();
> >>> boot_fn(state, argc, argv, images);
> >>>
> >>> --
> >>> 2.18.0
> >>>
> >>>
> >>> [Toradex Logo]  Global Leader in Arm®
> >>> Embedded Computer Modules
> >>>
> >>> Choose
> >>>
> >>
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> >>> | Products | Developer
> >>> Center |
> >>> Community |
> >>> Careers
> >>> Meet our engineers
> >>>
> >> at:
> >>> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> >>> - NXP Technology Days 2018, United States, Aug 28, 2018
> >>> - IoT Latin America, Brazil, Aug 29-30, 2018
> >>>
> >>>
> >>>
> >>> ___
> >>> U-Boot mailing list
> >>> U-Boot@lists.denx.de
> >>> https://lists.denx.de/listinfo/u-boot
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [GIT PULL] u-boot-mips/master

2018-09-24 Thread Tom Rini
On Sun, Sep 23, 2018 at 06:58:25PM +0200, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> Travis-CI: https://travis-ci.org/danielschwierzeck/u-boot/builds/432133437
> 
> 
> The following changes since commit 9dc8d155d4e88563f572ee79aab758eb4272f3fd:
> 
>   Merge git://git.denx.de/u-boot-imx (2018-09-19 20:35:27 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mips.git master
> 
> for you to fetch changes up to fdd1a9ff781cda82696f8971e540e475fd1e9933:
> 
>   mips: mt7628a.dtsi: Add SPI clock-frequency property (2018-09-23 14:27:51 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v8 8/8] Enable CONFIG_BLK and CONFIG_DM_MMC to Kconfig

2018-09-24 Thread York Sun
On 08/27/2018 07:56 PM, Yinbo Zhu wrote:
> This enables the folowing to Kconfig:
>   CONFIG_BLK
>   CONFIG_DM_MMC
> 
> Signed-off-by: Yinbo Zhu 
> ---
>  configs/ls1021atwr_nor_SECURE_BOOT_defconfig   |2 ++
>  configs/ls1021atwr_nor_defconfig   |2 ++
>  configs/ls1021atwr_nor_lpuart_defconfig|2 ++
>  configs/ls1021atwr_qspi_defconfig  |2 ++
>  .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig|2 ++

ls1021atwr_sdcard_ifc_SECURE_BOOT has a compiling errors. I think it is
in building SPL. Please test and fix.

York

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


[U-Boot] [PATCH v2] misc: Add support for the Arm Versatile Express config bus

2018-09-24 Thread Liviu Dudau
Add support for the Arm Versatile Express config bus that is
being used for exposing various subsystems via a generic
configuration bus. This driver adds support for generating
transactions on this configuration bus and can be used by
other drivers to abstract the communication with the actual
function providers.

Signed-off-by: Liviu Dudau 
---

Changelog:
 - v2: removed #define DEBUG line leftover

 drivers/misc/Kconfig   |   8 +++
 drivers/misc/Makefile  |   1 +
 drivers/misc/vexpress_config.c | 126 +
 3 files changed, 136 insertions(+)
 create mode 100644 drivers/misc/vexpress_config.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c2b7cc15db..468a5682e3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -41,6 +41,14 @@ config ROCKCHIP_EFUSE
  extended (by porting the read function from the Linux kernel sources)
  to support other recent Rockchip devices.
 
+config VEXPRESS_CONFIG
+   bool "Enable support for Arm Versatile Express config bus"
+   depends on MISC
+   help
+ If you say Y here, you will get support for accessing the
+ configuration bus on the Arm Versatile Express boards via
+ a sysreg driver.
+
 config CMD_CROS_EC
bool "Enable crosec command"
depends on CROS_EC
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 32ef4a53c7..6d3418efc7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
 obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
 obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o
 obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress_config.o
diff --git a/drivers/misc/vexpress_config.c b/drivers/misc/vexpress_config.c
new file mode 100644
index 00..2cd433d01e
--- /dev/null
+++ b/drivers/misc/vexpress_config.c
@@ -0,1 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Arm Ltd
+ * Author: Liviu Dudau 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SYS_CFGDATA0xa0
+
+#define SYS_CFGCTRL0xa4
+#define SYS_CFGCTRL_START  BIT(31)
+#define SYS_CFGCTRL_WRITE  BIT(30)
+
+#define SYS_CFGSTAT0xa8
+#define SYS_CFGSTAT_ERRBIT(1)
+#define SYS_CFGSTAT_COMPLETE   BIT(0)
+
+struct vexpress_config_sysreg {
+   phys_addr_t addr;
+   u32 site;
+};
+
+static int vexpress_config_exec(struct vexpress_config_sysreg *syscfg,
+   bool write, void *buf, int size)
+{
+   u32 cmd, status, tries = 100;
+
+   cmd = (*(u32 *)buf) | SYS_CFGCTRL_START | (syscfg->site << 16);
+
+   if (!write) {
+   /* write a canary in the data register for reads */
+   writel(0xdeadbeef, syscfg->addr + SYS_CFGDATA);
+   } else {
+   cmd |= SYS_CFGCTRL_WRITE;
+   writel(((u32 *)buf)[1], syscfg->addr + SYS_CFGDATA);
+   }
+   writel(0, syscfg->addr + SYS_CFGSTAT);
+   writel(cmd, syscfg->addr + SYS_CFGCTRL);
+
+   /* completion of command takes ages, go to sleep (150us) */
+   do {
+   udelay(150);
+   status = readl(syscfg->addr + SYS_CFGSTAT);
+   if (status & SYS_CFGSTAT_ERR)
+   return -EFAULT;
+   } while (--tries && !(status & SYS_CFGSTAT_COMPLETE));
+
+   if (!tries)
+   return -ETIMEDOUT;
+
+   if (!write)
+   (*(u32 *)buf) = readl(syscfg->addr + SYS_CFGDATA);
+
+   return 0;
+}
+
+static int vexpress_config_read(struct udevice *dev, int offset, void *buf, 
int size)
+{
+   struct vexpress_config_sysreg *priv = dev_get_uclass_priv(dev);
+
+   if (size != sizeof(u32))
+   return -EINVAL;
+
+   return vexpress_config_exec(priv, false, buf, size);
+}
+
+static int vexpress_config_write(struct udevice *dev, int offset, const void 
*buf, int size)
+{
+   struct vexpress_config_sysreg *priv = dev_get_uclass_priv(dev);
+
+   if (size != sizeof(u32) * 2)
+   return -EINVAL;
+
+   return vexpress_config_exec(priv, true, (void *)buf, size);
+}
+
+static struct misc_ops vexpress_config_ops = {
+   .read = vexpress_config_read,
+   .write = vexpress_config_write,
+};
+
+static int vexpress_config_probe(struct udevice *dev)
+{
+   struct ofnode_phandle_args args;
+   struct vexpress_config_sysreg *priv;
+   const char *prop;
+   int err, prop_size;
+
+   err = dev_read_phandle_with_args(dev, "arm,vexpress,config-bridge",
+NULL, 0, 0, &args);
+   if (err)
+   return err;
+
+   prop = ofnode_get_property(args.node, "compatible", &prop_size);
+   if (!prop || (strncmp(prop, "arm,vexpress-sysreg", 19) != 0))
+   return -ENOENT;
+
+   priv = calloc(1, sizeof(*priv));
+   if (!priv)
+  

Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Stefan Agner
On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner,  wrote:
> 
>> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, 
>> wrote:
>>>
 On 13.08.2018 09:30, Gerard Salvatella wrote:
> Some boards require specific configuration prior to booting the
 kernel.
> For instance, our boards require shutting down the display to
 avoid
> fading transitions before the drivers are reloaded by the
>> kernel.
 This
> could be facilitated by adding an extra hook during the os
>> booting
> process.

 Maybe I can extend on what we are trying to achieve here:

 We enable display backlight using board code.
>>>
>>> You can make it works almost easily.
>>>
>>> I enable simple fb, inject allocated display parameters in dts to
>>> reserve area, pass the area to the graphics controller and dismiss
>> it
>>> during probing
>>>
>>> This is mainline in linux support.
>>>
>>> I have couple of patches need to clean up for imx architecture
>>> (imx6ull and imx25)
>>
>> Definitely interested in those patches! Of course using this
>> approach
>> leads to the most seamless booting experience.
> 
> Yes but there are a lot of reason to have when you deal multi-image
> update and so on.
> 
>> But as far as I know it also needs proper (driver specific) Linux
>> support, is that correct?
> 
> No that is wrong. imx6ull need a small patches right now I have
> applied in kernel in legacy driver and not in drm one. 
> 

In what way is that different to what I wrote above?

In the end, the OS needs support for this.

> sunxi already implement everything in their side
> 
>> So, I think its anyway worth having an option to properly disable
>> the
>> display and backlight for older kernels/non-Linux OS.
> 
> gpio clear gpio-6 ; bootm ?

That is very board specific scripting required. We enable the backlight
in code, so we should disable it, especially if we disable the
controller (which we do currently).

--
Stefan

> 
> Michael
> 
>> --
>> Stefan
>>
>>>
>>> You can still scripting it using cmd interface
>>>
>>> Michael
>>>
 The architecture code then shuts down the display controller just
 before
 booting Linux (e.g. on i.MX, by calling
 ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).

 This leads to a display which has backlight enabled, but no data
 driven... Depending on display this leads to noisy/fading
 transitions
 between U-Boot and Linux.

 So we would like to disable the backlight in board code.

 In a first version we used a weak display_shutdown() function,
>> but
 with
 that we would have to add it to every architecture.

 This approach uses a generic board specific preeboot_os callback
 which
 can be used for different purpose too.

 Does this sound like an approach which is acceptable upstream?

 --
 Stefan

>
> Signed-off-by: Gerard Salvatella 
> ---
> common/bootm_os.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
> }
>
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> +   /* please define board specific board_preboot_os() */
> +}
> +
> int boot_selected_os(int argc, char * const argv[], int state,
> bootm_headers_t *images, boot_os_fn *boot_fn)
> {
> +   board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
>
> --
> 2.18.0
>
>
> [Toradex Logo]  Global Leader in Arm®
> Embedded Computer Modules
>
> Choose
>

>>>
>>
> Us
> | Products | Developer
> Center |
> Community |
> Careers
> Meet our engineers
>

>> at:
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot

Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

2018-09-24 Thread Michael Nazzareno Trimarchi
Hi


On Mon., 24 Sep. 2018, 5:15 pm Stefan Agner,  wrote:

> On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner,  wrote:
> >
> >> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> >>> Hi
> >>>
> >>> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, 
> >> wrote:
> >>>
>  On 13.08.2018 09:30, Gerard Salvatella wrote:
> > Some boards require specific configuration prior to booting the
>  kernel.
> > For instance, our boards require shutting down the display to
>  avoid
> > fading transitions before the drivers are reloaded by the
> >> kernel.
>  This
> > could be facilitated by adding an extra hook during the os
> >> booting
> > process.
> 
>  Maybe I can extend on what we are trying to achieve here:
> 
>  We enable display backlight using board code.
> >>>
> >>> You can make it works almost easily.
> >>>
> >>> I enable simple fb, inject allocated display parameters in dts to
> >>> reserve area, pass the area to the graphics controller and dismiss
> >> it
> >>> during probing
> >>>
> >>> This is mainline in linux support.
> >>>
> >>> I have couple of patches need to clean up for imx architecture
> >>> (imx6ull and imx25)
> >>
> >> Definitely interested in those patches! Of course using this
> >> approach
> >> leads to the most seamless booting experience.
> >
> > Yes but there are a lot of reason to have when you deal multi-image
> > update and so on.
> >
> >> But as far as I know it also needs proper (driver specific) Linux
> >> support, is that correct?
> >
> > No that is wrong. imx6ull need a small patches right now I have
> > applied in kernel in legacy driver and not in drm one.
> >
>
> In what way is that different to what I wrote above?
>
> In the end, the OS needs support for this.
>

I said that Linux support but not all the specic SoC. I don't against the
proposal but on my side I think that create some label and some way to
register them and go through a list instead of continue create weak make
more sense



> > sunxi already implement everything in their side
> >
> >> So, I think its anyway worth having an option to properly disable
> >> the
> >> display and backlight for older kernels/non-Linux OS.
> >
> > gpio clear gpio-6 ; bootm ?
>
> That is very board specific scripting required. We enable the backlight
> in code, so we should disable it, especially if we disable the
> controller (which we do currently).
>

Your function is board specific anyway but ok I understand the asymmetric
situation. I suggest it before migrate to the latest solution

Michael

>
> --
> Stefan
>
> >
> > Michael
> >
> >> --
> >> Stefan
> >>
> >>>
> >>> You can still scripting it using cmd interface
> >>>
> >>> Michael
> >>>
>  The architecture code then shuts down the display controller just
>  before
>  booting Linux (e.g. on i.MX, by calling
>  ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
> 
>  This leads to a display which has backlight enabled, but no data
>  driven... Depending on display this leads to noisy/fading
>  transitions
>  between U-Boot and Linux.
> 
>  So we would like to disable the backlight in board code.
> 
>  In a first version we used a weak display_shutdown() function,
> >> but
>  with
>  that we would have to add it to every architecture.
> 
>  This approach uses a generic board specific preeboot_os callback
>  which
>  can be used for different purpose too.
> 
>  Does this sound like an approach which is acceptable upstream?
> 
>  --
>  Stefan
> 
> >
> > Signed-off-by: Gerard Salvatella 
> > ---
> > common/bootm_os.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/common/bootm_os.c b/common/bootm_os.c
> > index f4bd905909..1e7af56b64 100644
> > --- a/common/bootm_os.c
> > +++ b/common/bootm_os.c
> > @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> > /* please define platform specific arch_preboot_os() */
> > }
> >
> > +/* Allow for board specific config before we boot */
> > +__weak void board_preboot_os(void)
> > +{
> > +   /* please define board specific board_preboot_os() */
> > +}
> > +
> > int boot_selected_os(int argc, char * const argv[], int state,
> > bootm_headers_t *images, boot_os_fn *boot_fn)
> > {
> > +   board_preboot_os();
> > arch_preboot_os();
> > boot_fn(state, argc, argv, images);
> >
> > --
> > 2.18.0
> >
> >
> > [Toradex Logo]  Global Leader in Arm®
> > Embedded Computer Modules
> >
> > Choose
> >
> 
> >>>
> >>
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> > | Products | Developer
> > Center |
> > Community

Re: [U-Boot] [PATCH v2 0/7] [RESEND] Improvements for the dwc3_generic driver

2018-09-24 Thread Jean-Jacques Hiblot



On 21/09/2018 15:02, Jean-Jacques Hiblot wrote:



On 21/09/2018 12:43, Lukasz Majewski wrote:

Hi Jean-Jacques,


On 21/09/2018 11:24, Lukasz Majewski wrote:

Hi Jean-Jacques,

On 21/09/2018 10:50, Lukasz Majewski wrote:

Hi Jean-Jacques,

Hi Marek,

I haven't heard of you on this series.

It is already a resend and has been tested on 2 platforms (zcu100
and dra7/am57).

Can you please consider it for inclusion?

This is not Marek to blame for the delay - I had some non open
source tasks to finish (and I do apologise for this situation).

Thanks. I am not blaming anyone.

:-)

Could you check the build result?
https://travis-ci.org/lmajewski/u-boot-dfu/builds/431388980
I do see some issues with "Freescale ARM32/ARM64".

I can reproduce the problem.
The root cause is that I moved the phy handling operation from the
host (xhci-dwc3.c) to the core dwc3/core.c thinking that all users of
the dwc3 would have the core code. Well that is not the case.

Maybe a silly question - how those boards work as they do not
use/include the DWC3 core?
It looks like the host side of the dwc3 is  mostly self-contained and 
that the code in dwc3/core.c is mostly used by the gadget side.


It seems that the PHY code is not used by the platforms that failed to 
build, so it can be compiled out.

I'll send a v3 shortly.
JJ



They use xhci PHY handling code and what code on top?


I see 2 solutions:
* move the phy code back to xhci-dwc3
* enable the core code for dwc3 (CONFIG_USB_DWC3) for the failing
platforms

Any preference ?



I just wanted to make sure that this
wasn't lost in limbo.

Your patches are now under build testing on travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/431388980

I will send the PR after CI finish.

Thanks,

JJ



On 04/09/2018 15:42, Jean-Jacques Hiblot wrote:

Resending this series after rebasing on top of latest u-boot.

This series aims at bringing improvements to the dwc3_generic
driver so that it can be used by most of the platforms using the
dwc3 controller.

I tested this on with DRA7 and AM57x platforms for both
Peripheral and Host operations. The code to enable DM USB host
& dev support for those platforms will be submitted in a
separate series.

Michal Simek has tested this series:
" I have tested it on zcu100 with usb stick, usb to ethernet
converter and also dfu.
Tested-by: Michal Simek "

Enhancements:
- use separate Kconfig option for DM USB Periphal and DM USB
Host. This allow platforms to keep their non-DM USB peripheral
code and use the DM USB host.
- fixes the bind/probe confusion in dwc3_generic. The probe is
done when the USB device is first needed.
- handles PHYs when in the peripheral mode. The code to handle
the PHYs is shared with the host side
- handles clock and reset
- bind host controller to the more generic driver 'xhci-dwc3'


Changes in v2:
- Updated commit log
- Fixed typo in thordown.c
- select DM_USB_DEV by default for zynqmp platforms

Jean-Jacques Hiblot (7):
  usb: gadget: Do not call board_usb_xxx() directly in USB
gadget drivers
  usb: introduce a separate config option for DM USB device
  usb: udc: implement DM versions of
usb_gadget_initialize()/_release()/_handle_interrupt()
  dwc3_generic: do not probe the USB device driver when it's
bound dwc3: move phy operation to core.c
  dwc3-generic: Handle the PHYs, the clocks and the reset
lines dwc3-generic: Add select_dr_mode operation

 arch/arm/Kconfig  |   2 +
 cmd/fastboot.c    |   4 +-
 cmd/rockusb.c |   4 +-
 cmd/thordown.c    |   4 +-
 cmd/usb_gadget_sdp.c  |   4 +-
 cmd/usb_mass_storage.c    |   4 +-
 common/dfu.c  |   6 +-
 drivers/usb/Kconfig   |   6 ++
 drivers/usb/dwc3/Kconfig  |   7 +-
 drivers/usb/dwc3/core.c   |  86 +++-
 drivers/usb/dwc3/dwc3-generic.c   | 207
+-
drivers/usb/dwc3/ep0.c    |   1 -
drivers/usb/gadget/ether.c    |  38 +--
drivers/usb/gadget/udc/udc-core.c |  44 +++-
drivers/usb/host/xhci-dwc3.c  |  93 ++---
include/dwc3-uboot.h  |   7 ++
include/linux/usb/gadget.h    |  18  17 files changed,
351 insertions(+), 184 deletions(-)


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



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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-8219

Re: [U-Boot] [PATCH 03/15] test/py: Fix unicode handling for log filtering

2018-09-24 Thread Stephen Warren

On 09/23/2018 04:47 PM, Simon Glass wrote:

At present the unicode filtering seems to get confused at times with
this error:

   UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position
  32: ordinal not in range(128)

It seems to be due to self._nonprint being interpreted as UTF-8. Fix it
by using ordinals instead of characters, changing the string to set.


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


Re: [U-Boot] [PATCH 3/3] Kconfig: move CONFIG_STANDALONE_LOAD_ADDR to Kconfig

2018-09-24 Thread Max Filippov
On Sun, Sep 23, 2018 at 1:02 PM, Daniel Schwierzeck
 wrote:
> Create a new Kconfig menu called 'Standalone programs' with
> 'Program load address' as menu entry. It's possible now to build without
> the standalone example. Anyway the default value for CONFIG_STANDALONE
> is 'y' to maintain the current behavior.
>
> Signed-off-by: Daniel Schwierzeck 

[...]

> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> index 2ba7132c20..e228f15660 100644
> --- a/arch/xtensa/Kconfig
> +++ b/arch/xtensa/Kconfig
> @@ -8,6 +8,9 @@ config SYS_ARCH
>  config SYS_CPU
> string "Xtensa Core Variant"
>
> +config STANDALONE_LOAD_ADDR
> +   default 0x0080
> +

This doesn't preserve current address assignment for xtensa
XTFPGA boards:

> --- a/include/configs/xtfpga.h
> +++ b/include/configs/xtfpga.h
> @@ -74,22 +74,6 @@
>  #define CONFIG_SYS_MEMTEST_START   MEMADDR(0x0100)
>  #define CONFIG_SYS_MEMTEST_END MEMADDR(0x0200)
>
> -/* Load address for stand-alone applications.
> - * MEMADDR cannot be used here, because the definition needs to be
> - * a plain number as it's used as -Ttext argument for ld in standalone
> - * example makefile.
> - * Handle noMMU vs MMUv2 vs MMUv3 distinction here manually.
> - */
> -#if XCHAL_HAVE_PTP_MMU
> -#if XCHAL_VECBASE_RESET_VADDR == XCHAL_VECBASE_RESET_PADDR
> -#define CONFIG_STANDALONE_LOAD_ADDR0x0080
> -#else
> -#define CONFIG_STANDALONE_LOAD_ADDR0xd080
> -#endif
> -#else
> -#define CONFIG_STANDALONE_LOAD_ADDR0x6080
> -#endif

OTOH I don't see any way to express this in Kconfig.

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


[U-Boot] [PATCH 1/1] efi_loader: UninstallMultipleProtocolInterfaces error code

2018-09-24 Thread Heinrich Schuchardt
If UninstallMultipleProtocolInterfaces fails, we sometimes return the wrong
status code. The UEFI spec mandates to always return EFI_INVALID_PARAMETER.

Update unit test.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c  |  3 ++-
 .../efi_selftest_manageprotocols.c | 18 +++---
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index ac724b17fd..554997f44a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2409,7 +2409,8 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
}
efi_va_end(argptr);
 
-   return EFI_EXIT(r);
+   /* In case of an error always return EFI_INVALID_PARAMETER */
+   return EFI_EXIT(EFI_INVALID_PARAMETER);
 }
 
 /**
diff --git a/lib/efi_selftest/efi_selftest_manageprotocols.c 
b/lib/efi_selftest/efi_selftest_manageprotocols.c
index b09e4cdcfa..0ff35cec8a 100644
--- a/lib/efi_selftest/efi_selftest_manageprotocols.c
+++ b/lib/efi_selftest/efi_selftest_manageprotocols.c
@@ -189,7 +189,14 @@ static int execute(void)
/*
 * Test error handling in UninstallMultipleProtocols
 *
-* Try to uninstall more protocols than there are installed.
+* These are the installed protocol interfaces on handle 2:
+*
+*   guid1 interface4
+*   guid2 interface2
+*
+* Try to uninstall more protocols than there are installed. This
+* should return an error EFI_INVALID_PARAMETER. All deleted protocols
+* should be reinstalled.
 */
ret = boottime->uninstall_multiple_protocol_interfaces(
handle2,
@@ -197,13 +204,18 @@ static int execute(void)
&guid2, &interface2,
&guid3, &interface3,
NULL);
-   if (ret == EFI_SUCCESS) {
+   if (ret != EFI_INVALID_PARAMETER) {
+   printf("%lx", ret);
efi_st_error("UninstallMultipleProtocolInterfaces did not catch 
error\n");
return EFI_ST_FAILURE;
}
 
/*
 * Test LocateHandleBuffer with ByProtocol
+*
+* These are the handles with a guid1 protocol interface installed:
+*
+*  handle1, handle2
 */
count = buffer_size;
ret = boottime->locate_handle_buffer(BY_PROTOCOL, &guid1, NULL,
@@ -213,7 +225,7 @@ static int execute(void)
return EFI_ST_FAILURE;
}
if (count != 2) {
-   efi_st_error("LocateHandleBuffer failed to locate new 
handles\n");
+   efi_st_error("UninstallMultipleProtocolInterfaces deleted 
handle\n");
return EFI_ST_FAILURE;
}
ret = find_in_buffer(handle1, count, buffer);
-- 
2.19.0

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


Re: [U-Boot] [PATCH] efi_loader: Disable efi selftest on sandbox for now

2018-09-24 Thread Simon Glass
On 23 September 2018 at 07:24, Alexander Graf  wrote:
>
> The EFI selftest does not succeed on Sandbox yet. The network support
> seems to need some love to actually make our current tests succeed.
>
> So let's disable running the selftest on sandbox for now until "make
> tests" just works. Then we can have more amazing CI than ever.
>
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_selftest/Kconfig | 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


[U-Boot] [PATCH 2/2] efi_loader: eliminate handle member

2018-09-24 Thread Heinrich Schuchardt
A pointer to a struct efi_object is a handle. We do not need any handle
member in this structure. Let's eliminate it.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h | 26 +-
 lib/efi_loader/efi_boottime.c| 59 
 lib/efi_loader/efi_console.c | 20 +--
 lib/efi_loader/efi_device_path.c |  2 +-
 lib/efi_loader/efi_disk.c|  8 ++---
 lib/efi_loader/efi_gop.c |  2 +-
 lib/efi_loader/efi_net.c |  6 ++--
 7 files changed, 65 insertions(+), 58 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 74df070316..6846bb03f3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -173,20 +173,28 @@ struct efi_handler {
struct list_head open_infos;
 };
 
-/*
- * UEFI has a poor man's OO model where one "object" can be polymorphic and 
have
- * multiple different protocols (classes) attached to it.
+/**
+ * struct efi_object - dereferenced EFI handle
+ *
+ * @link:  pointers to put the handle into a linked list
+ * @protocols: linked list with the protocol interfaces installed on this
+ * handle
+ *
+ * UEFI offers a flexible and expandable object model. The objects in the UEFI
+ * API are devices, drivers, and loaded images. struct efi_object is our 
storage
+ * structure for these objects.
+ *
+ * When including this structure into a larger structure always put it first so
+ * that when deleting a handle the whole encompassing structure can be freed.
  *
- * This struct is the parent struct for all of our actual implementation 
objects
- * that can include it to make themselves an EFI object
+ * A pointer to this structure is referred to as a handle. Typedef efi_handle_t
+ * has been created for such pointers.
  */
 struct efi_object {
/* Every UEFI object is part of a global object list */
struct list_head link;
/* The list of protocols */
struct list_head protocols;
-   /* The object spawner can either use this for data or as identifier */
-   void *handle;
 };
 
 /**
@@ -296,11 +304,11 @@ void efi_runtime_relocate(ulong offset, struct 
efi_mem_desc *map);
 /* Call this to set the current device name */
 void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
 /* Add a new object to the object list. */
-void efi_add_handle(struct efi_object *obj);
+void efi_add_handle(efi_handle_t obj);
 /* Create handle */
 efi_status_t efi_create_handle(efi_handle_t *handle);
 /* Delete handle */
-void efi_delete_handle(struct efi_object *obj);
+void efi_delete_handle(efi_handle_t obj);
 /* Call this to validate a handle and find the EFI object for it */
 struct efi_object *efi_search_obj(const efi_handle_t handle);
 /* Find a protocol on a handle */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 20974f98f6..d1c4b26297 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -416,13 +416,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
  *
  * The protocols list is initialized. The object handle is set.
  */
-void efi_add_handle(struct efi_object *obj)
+void efi_add_handle(efi_handle_t handle)
 {
-   if (!obj)
+   if (!handle)
return;
-   INIT_LIST_HEAD(&obj->protocols);
-   obj->handle = obj;
-   list_add_tail(&obj->link, &efi_obj_list);
+   INIT_LIST_HEAD(&handle->protocols);
+   list_add_tail(&handle->link, &efi_obj_list);
 }
 
 /**
@@ -440,7 +439,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle)
return EFI_OUT_OF_RESOURCES;
 
efi_add_handle(obj);
-   *handle = obj->handle;
+   *handle = obj;
 
return EFI_SUCCESS;
 }
@@ -536,13 +535,13 @@ efi_status_t efi_remove_all_protocols(const efi_handle_t 
handle)
  *
  * @obj: handle to delete
  */
-void efi_delete_handle(struct efi_object *obj)
+void efi_delete_handle(efi_handle_t handle)
 {
-   if (!obj)
+   if (!handle)
return;
-   efi_remove_all_protocols(obj->handle);
-   list_del(&obj->link);
-   free(obj);
+   efi_remove_all_protocols(handle);
+   list_del(&handle->link);
+   free(handle);
 }
 
 /**
@@ -927,7 +926,7 @@ struct efi_object *efi_search_obj(const efi_handle_t handle)
struct efi_object *efiobj;
 
list_for_each_entry(efiobj, &efi_obj_list, link) {
-   if (efiobj->handle == handle)
+   if (efiobj == handle)
return efiobj;
}
 
@@ -1052,7 +1051,7 @@ out:
 
 /**
  * efi_get_drivers() - get all drivers associated to a controller
- * @efiobj:   handle of the controller
+ * @handle:   handle of the controller
  * @protocol: protocol GUID (optional)
  * @number_of_drivers:number of child controllers
  * @driver_handle_buffer: handles of the the drivers
@@ -1061,7 +1060,7 @@ out:
  *
  * Return: status code
  */
-static efi_status_t efi_get_d

[U-Boot] [PATCH 0/2] efi_loader: eliminate handle member

2018-09-24 Thread Heinrich Schuchardt
Up to now we have treated handles as separate objects to EFI objects. This
confusion has lead to hidden bugs like those corrected by the first patch.
By changing the efi_handle_t typedef we can avoid this problem in future.

As handles are pointers to EFI objects there is no need for a handle member
in struct efi_object. This allows to simplify our coding.

Heinrich Schuchardt (2):
  efi_loader: typedef struct efi_object *efi_handle_t
  efi_loader: eliminate handle member

 cmd/bootefi.c  |  4 +-
 include/efi.h  |  2 +-
 include/efi_api.h  |  8 +--
 include/efi_loader.h   | 26 +---
 lib/efi/efi.c  |  2 +-
 lib/efi_loader/efi_boottime.c  | 77 +++---
 lib/efi_loader/efi_console.c   | 20 +++---
 lib/efi_loader/efi_device_path.c   |  2 +-
 lib/efi_loader/efi_disk.c  |  8 +--
 lib/efi_loader/efi_gop.c   |  2 +-
 lib/efi_loader/efi_net.c   |  6 +-
 lib/efi_selftest/efi_selftest_devicepath.c |  2 +-
 12 files changed, 83 insertions(+), 76 deletions(-)

-- 
2.19.0

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


[U-Boot] [PATCH 1/2] efi_loader: typedef struct efi_object *efi_handle_t

2018-09-24 Thread Heinrich Schuchardt
All our handles point to a struct efi_object. So let's define the
efi_handle_t accordingly. This helps us to discover coding errors much
more easily. This becomes evident by the corrections to the usage of
handles in this patch.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c  |  4 ++--
 include/efi.h  |  2 +-
 include/efi_api.h  |  8 
 lib/efi/efi.c  |  2 +-
 lib/efi_loader/efi_boottime.c  | 18 +-
 lib/efi_selftest/efi_selftest_devicepath.c |  2 +-
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 9c51a2cbd1..05eb168e4a 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -447,7 +447,7 @@ static efi_status_t do_bootefi_exec(void *efi,
}
 #endif
 
-   ret = efi_do_enter(image_handle, &systab, entry);
+   ret = efi_do_enter(&image_handle->parent, &systab, entry);
 
 exit:
/* image has returned, loaded-image obj goes *poof*: */
@@ -561,7 +561,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
/* Transfer environment variable efi_selftest as load options */
set_load_options(loaded_image_info, "efi_selftest");
/* Execute the test */
-   r = efi_selftest(image_handle, &systab);
+   r = efi_selftest(&image_handle->parent, &systab);
efi_restore_gd();
free(loaded_image_info->load_options);
efi_delete_handle(&image_handle->parent);
diff --git a/include/efi.h b/include/efi.h
index b1deb609b4..b5e2c64f38 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -96,7 +96,7 @@ typedef struct {
 typedef unsigned long efi_status_t;
 typedef u64 efi_physical_addr_t;
 typedef u64 efi_virtual_addr_t;
-typedef void *efi_handle_t;
+typedef struct efi_object *efi_handle_t;
 
 #define EFI_GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, \
diff --git a/include/efi_api.h b/include/efi_api.h
index c42df6900a..e6566bb358 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -86,10 +86,10 @@ struct efi_boot_services {
efi_status_t (EFIAPI *check_event)(struct efi_event *event);
 #define EFI_NATIVE_INTERFACE   0x
efi_status_t (EFIAPI *install_protocol_interface)(
-   void **handle, const efi_guid_t *protocol,
+   efi_handle_t *handle, const efi_guid_t *protocol,
int protocol_interface_type, void *protocol_interface);
efi_status_t (EFIAPI *reinstall_protocol_interface)(
-   void *handle, const efi_guid_t *protocol,
+   efi_handle_t handle, const efi_guid_t *protocol,
void *old_interface, void *new_interface);
efi_status_t (EFIAPI *uninstall_protocol_interface)(
efi_handle_t handle, const efi_guid_t *protocol,
@@ -165,9 +165,9 @@ struct efi_boot_services {
efi_status_t (EFIAPI *locate_protocol)(const efi_guid_t *protocol,
void *registration, void **protocol_interface);
efi_status_t (EFIAPI *install_multiple_protocol_interfaces)(
-   void **handle, ...);
+   efi_handle_t *handle, ...);
efi_status_t (EFIAPI *uninstall_multiple_protocol_interfaces)(
-   void *handle, ...);
+   efi_handle_t handle, ...);
efi_status_t (EFIAPI *calculate_crc32)(const void *data,
   efi_uintn_t data_size,
   u32 *crc32);
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index c6639f96cc..2c6a50824f 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -69,7 +69,7 @@ int efi_init(struct efi_priv *priv, const char *banner, 
efi_handle_t image,
efi_putc(priv, ' ');
 
ret = boot->open_protocol(priv->parent_image, &loaded_image_guid,
- (void **)&loaded_image, &priv->parent_image,
+ (void **)&loaded_image, priv->parent_image,
  NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
if (ret) {
efi_puts(priv, "Failed to get loaded image protocol\n");
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 3bb7b70e08..20974f98f6 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1019,7 +1019,7 @@ efi_status_t efi_add_protocol(const efi_handle_t handle,
  * Return: status code
  */
 static efi_status_t EFIAPI efi_install_protocol_interface(
-   void **handle, const efi_guid_t *protocol,
+   efi_handle_t *handle, const efi_guid_t *protocol,
int protocol_interface_type, void *protocol_interface)
 {

[U-Boot] [BUG] U-Boot generates unusable x86_64 EFI binaries

2018-09-24 Thread Heinrich Schuchardt
Hello

neither the helloworld.efi of qemu-x86_64_defconfig nor the
u-boot-payload.efi of efi-x86_payload64_defconfig can be started from
the firmware of my Thinkpad 585 while grubx64.efi works fine.

Looking at the generated PE header I found the following abnormality:

coff.PointerToSymbolTable != 0
coff.NumberOfSymbols != 0

(using https://github.com/xypron/efi_analyzer)

According to the Microsoft Portable Executable and Common Object File
Format Specification - rev 11 - 2017-01-17 these fields should be 0.

The U-Boot executables have these sections which do not exist in
grubx64.efi, the EFI shell, and the Windows loader:

Section[3] .dynamic
Section[4] .dynsym

So I think we have to change something in the linking to get usable EFI
binaries.

Best regards

Heinrich


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


Re: [U-Boot] [PATCH 3/3] Kconfig: move CONFIG_STANDALONE_LOAD_ADDR to Kconfig

2018-09-24 Thread Daniel Schwierzeck


On 24.09.2018 19:55, Max Filippov wrote:
> On Sun, Sep 23, 2018 at 1:02 PM, Daniel Schwierzeck
>  wrote:
>> Create a new Kconfig menu called 'Standalone programs' with
>> 'Program load address' as menu entry. It's possible now to build without
>> the standalone example. Anyway the default value for CONFIG_STANDALONE
>> is 'y' to maintain the current behavior.
>>
>> Signed-off-by: Daniel Schwierzeck 
> 
> [...]
> 
>> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
>> index 2ba7132c20..e228f15660 100644
>> --- a/arch/xtensa/Kconfig
>> +++ b/arch/xtensa/Kconfig
>> @@ -8,6 +8,9 @@ config SYS_ARCH
>>  config SYS_CPU
>> string "Xtensa Core Variant"
>>
>> +config STANDALONE_LOAD_ADDR
>> +   default 0x0080
>> +
> 
> This doesn't preserve current address assignment for xtensa
> XTFPGA boards:
> 
>> --- a/include/configs/xtfpga.h
>> +++ b/include/configs/xtfpga.h
>> @@ -74,22 +74,6 @@
>>  #define CONFIG_SYS_MEMTEST_START   MEMADDR(0x0100)
>>  #define CONFIG_SYS_MEMTEST_END MEMADDR(0x0200)
>>
>> -/* Load address for stand-alone applications.
>> - * MEMADDR cannot be used here, because the definition needs to be
>> - * a plain number as it's used as -Ttext argument for ld in standalone
>> - * example makefile.
>> - * Handle noMMU vs MMUv2 vs MMUv3 distinction here manually.
>> - */
>> -#if XCHAL_HAVE_PTP_MMU
>> -#if XCHAL_VECBASE_RESET_VADDR == XCHAL_VECBASE_RESET_PADDR
>> -#define CONFIG_STANDALONE_LOAD_ADDR0x0080
>> -#else
>> -#define CONFIG_STANDALONE_LOAD_ADDR0xd080
>> -#endif
>> -#else
>> -#define CONFIG_STANDALONE_LOAD_ADDR0x6080
>> -#endif
> 
> OTOH I don't see any way to express this in Kconfig.
> 

I see you set the SYS_CPU string manually. I think this is error-prone
and not user-friendly. I suggest to convert this to Kconfig symbols like
this:

config SYS_CPU
default "dc232b" if CPU_DC232B
default "dc233c" if CPU_DC233C
default "de212" if CPU_DE212

choice
prompt "Xtensa Core Variant"
default CPU_DC233C

config CPU_DC232B
bool "dc232b"

config CPU_DC233C
bool "dc233c"

config CPU_DE212
bool "de212"

endchoice

Then the user can only choose between the three supported cores and
SYS_CPU will be automatically updated. The default value for
STANDALONE_LOAD_ADDR could be set like this:

config STANDALONE_LOAD_ADDR
default 0xd080 if CPU_DC232B
default 0x0080 if CPU_DC233C
default 0x6080 if CPU_DE212

Alternatively you model the MMU configuration also as Kconfig symbol
which can be selected by those CPU_* symbols. Then you set the default
value of STANDALONE_LOAD_ADDR dependent on that MMU setting. What do you
think?

-- 
- Daniel



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


[U-Boot] [PATCH 1/1] efi_selftest: use CR LF in helloworld

2018-09-24 Thread Heinrich Schuchardt
The UEFI spec defines that a line feed moves the cursor to the next line
and (only) a carriage return moves the cursor to the beginning of the line.

So we should issue CR LF when we want to get to the start of the next line.

Add some comments.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/helloworld.c | 40 +
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 3b8de5b4ea..93d4cec1f4 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -17,6 +17,16 @@ static const efi_guid_t fdt_guid = EFI_FDT_GUID;
 static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
+/**
+ * hw_memcmp() - compare memory areas
+ *
+ * @buf1:  pointer to first area
+ * @buf2:  pointer to second area
+ * @length:number of bytes to compare
+ * Result: 0 if both memory areas are the same, otherwise the sign of the
+ * result value is the same as the sign of ghe difference between
+ * the first differing pair of bytes taken as u8.
+ */
 static int hw_memcmp(const void *buf1, const void *buf2, size_t length)
 {
const u8 *pos1 = buf1;
@@ -31,12 +41,12 @@ static int hw_memcmp(const void *buf1, const void *buf2, 
size_t length)
return 0;
 }
 
-/*
- * Entry point of the EFI application.
+/**
+ * efi_main() - entry point of the EFI application.
  *
- * @handle handle of the loaded image
- * @systable   system table
- * @return status code
+ * @handle:handle of the loaded image
+ * @systable:  system table
+ * @return:status code
  */
 efi_status_t EFIAPI efi_main(efi_handle_t handle,
 struct efi_system_table *systable)
@@ -48,7 +58,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
efi_uintn_t i;
u16 rev[] = L"0.0.0";
 
-   con_out->output_string(con_out, L"Hello, world!\n");
+   /* UEFI requires CR LF */
+   con_out->output_string(con_out, L"Hello, world!\r\n");
 
/* Print the revision number */
rev[0] = (systable->hdr.revision >> 16) + '0';
@@ -65,27 +76,30 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
 
con_out->output_string(con_out, L"Running on UEFI ");
con_out->output_string(con_out, rev);
-   con_out->output_string(con_out, L"\n");
+   con_out->output_string(con_out, L"\r\n");
 
/* Get the loaded image protocol */
ret = boottime->handle_protocol(handle, &loaded_image_guid,
(void **)&loaded_image);
if (ret != EFI_SUCCESS) {
-   con_out->output_string(con_out,
-  L"Cannot open loaded image protocol\n");
+   con_out->output_string
+   (con_out, L"Cannot open loaded image protocol\r\n");
goto out;
}
/* Find configuration tables */
for (i = 0; i < systable->nr_tables; ++i) {
if (!hw_memcmp(&systable->tables[i].guid, &fdt_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have device tree\n");
+   con_out->output_string
+   (con_out, L"Have device tree\r\n");
if (!hw_memcmp(&systable->tables[i].guid, &acpi_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have ACPI 2.0 
table\n");
+   con_out->output_string
+   (con_out, L"Have ACPI 2.0 table\r\n");
if (!hw_memcmp(&systable->tables[i].guid, &smbios_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have SMBIOS table\n");
+   con_out->output_string
+   (con_out, L"Have SMBIOS table\r\n");
}
/* Output the load options */
con_out->output_string(con_out, L"Load options: ");
@@ -94,7 +108,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
   (u16 *)loaded_image->load_options);
else
con_out->output_string(con_out, L"");
-   con_out->output_string(con_out, L"\n");
+   con_out->output_string(con_out, L"\r\n");
 
 out:
boottime->exit(handle, ret, 0, NULL);
-- 
2.19.0

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


[U-Boot] [PATCH v2 1/1] efi_selftest: use CR LF in helloworld

2018-09-24 Thread Heinrich Schuchardt
The UEFI spec defines that a line feed moves the cursor to the next line
and (only) a carriage return moves the cursor to the beginning of the line.

So we should issue CR LF when we want to get to the start of the next line.

Add some comments.

Signed-off-by: Heinrich Schuchardt 
---
v2
correct Sphinx comments %s/Result/Return/
---
 lib/efi_loader/helloworld.c | 40 +
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 3b8de5b4ea..93d4cec1f4 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -17,6 +17,16 @@ static const efi_guid_t fdt_guid = EFI_FDT_GUID;
 static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
+/**
+ * hw_memcmp() - compare memory areas
+ *
+ * @buf1:  pointer to first area
+ * @buf2:  pointer to second area
+ * @length:number of bytes to compare
+ * Return: 0 if both memory areas are the same, otherwise the sign of the
+ * result value is the same as the sign of ghe difference between
+ * the first differing pair of bytes taken as u8.
+ */
 static int hw_memcmp(const void *buf1, const void *buf2, size_t length)
 {
const u8 *pos1 = buf1;
@@ -31,12 +41,12 @@ static int hw_memcmp(const void *buf1, const void *buf2, 
size_t length)
return 0;
 }
 
-/*
- * Entry point of the EFI application.
+/**
+ * efi_main() - entry point of the EFI application.
  *
- * @handle handle of the loaded image
- * @systable   system table
- * @return status code
+ * @handle:handle of the loaded image
+ * @systable:  system table
+ * @return:status code
  */
 efi_status_t EFIAPI efi_main(efi_handle_t handle,
 struct efi_system_table *systable)
@@ -48,7 +58,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
efi_uintn_t i;
u16 rev[] = L"0.0.0";
 
-   con_out->output_string(con_out, L"Hello, world!\n");
+   /* UEFI requires CR LF */
+   con_out->output_string(con_out, L"Hello, world!\r\n");
 
/* Print the revision number */
rev[0] = (systable->hdr.revision >> 16) + '0';
@@ -65,27 +76,30 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
 
con_out->output_string(con_out, L"Running on UEFI ");
con_out->output_string(con_out, rev);
-   con_out->output_string(con_out, L"\n");
+   con_out->output_string(con_out, L"\r\n");
 
/* Get the loaded image protocol */
ret = boottime->handle_protocol(handle, &loaded_image_guid,
(void **)&loaded_image);
if (ret != EFI_SUCCESS) {
-   con_out->output_string(con_out,
-  L"Cannot open loaded image protocol\n");
+   con_out->output_string
+   (con_out, L"Cannot open loaded image protocol\r\n");
goto out;
}
/* Find configuration tables */
for (i = 0; i < systable->nr_tables; ++i) {
if (!hw_memcmp(&systable->tables[i].guid, &fdt_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have device tree\n");
+   con_out->output_string
+   (con_out, L"Have device tree\r\n");
if (!hw_memcmp(&systable->tables[i].guid, &acpi_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have ACPI 2.0 
table\n");
+   con_out->output_string
+   (con_out, L"Have ACPI 2.0 table\r\n");
if (!hw_memcmp(&systable->tables[i].guid, &smbios_guid,
   sizeof(efi_guid_t)))
-   con_out->output_string(con_out, L"Have SMBIOS table\n");
+   con_out->output_string
+   (con_out, L"Have SMBIOS table\r\n");
}
/* Output the load options */
con_out->output_string(con_out, L"Load options: ");
@@ -94,7 +108,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
   (u16 *)loaded_image->load_options);
else
con_out->output_string(con_out, L"");
-   con_out->output_string(con_out, L"\n");
+   con_out->output_string(con_out, L"\r\n");
 
 out:
boottime->exit(handle, ret, 0, NULL);
-- 
2.19.0

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


Re: [U-Boot] [PATCH v2 4/4] aspeed: Activate SPI support on the ast2500 Eval Board

2018-09-24 Thread Joel Stanley
On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater  wrote:
>
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: Jagan Teki 

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


Re: [U-Boot] [PATCH v2 3/4] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level

2018-09-24 Thread Joel Stanley
On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater  wrote:
>
> This is a large update of the AST2500 Soc DTS file bringing it to the
> level of commit 927c2fc2db19 :
>
> Author:  Joel Stanley 
> Date:Sat Jun 2 01:18:53 2018 -0700
>
>  ARM: dts: aspeed: Fix hwrng register address
>
> There are some differences on the compatibility property names. scu,
> reset and clock drivers are also different.

You made the required changes in this patch? We should document those
so we know how to sync it next time.

If it's possible, we can also add compatible properties to the Linux
version of the device tree to make syncing easier.

> Signed-off-by: Cédric Le Goater 

Reviewed-by: Joel Stanley 

Cheers,

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


Re: [U-Boot] [PATCH v2 07/13] x86: Fix signed shift overflow in MSR_IA32_APICBASE_BASE

2018-09-24 Thread Bin Meng
Hi Eugeniu,

On Sun, Sep 23, 2018 at 7:10 AM Eugeniu Rosca  wrote:
>
> Hi Bin,
>
> jFYI, I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
> ("UBSAN behavior on left-shifting 1 into the sign bit is dependent on C
> standard"), to get some recommendation from GCC guys how to handle
> these warnings in U-Boot.

Thank you very much for following up with the gcc folks! Let's see how
they respond.

BTW: your bug report is elaborate. Well done on the research!

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


Re: [U-Boot] [PATCH 1/3] qe: kconfig: U QE kconfig

2018-09-24 Thread Ran Wang
Hi York,

> -Original Message-
> From: York Sun
> Sent: Saturday, September 22, 2018 02:50
> To: Ran Wang ; Alison Wang
> ; Sumit Garg 
> Cc: Qiang Zhao ; u-boot@lists.denx.de
> Subject: Re: [PATCH 1/3] qe: kconfig: U QE kconfig
> 
> On 08/09/2018 02:56 AM, Ran Wang wrote:
> > add Kconfig option for U QUICC Engine.
> >
> > Signed-off-by: Ran Wang 
> > ---
> >  drivers/Kconfig| 2 ++
> >  drivers/qe/Kconfig | 8 
> >  2 files changed, 10 insertions(+)
> >  create mode 100644 drivers/qe/Kconfig
> >
> > diff --git a/drivers/Kconfig b/drivers/Kconfig index c2e813f..da2f811
> > 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -68,6 +68,8 @@ source "drivers/power/Kconfig"
> >
> >  source "drivers/pwm/Kconfig"
> >
> > +source "drivers/qe/Kconfig"
> > +
> >  source "drivers/ram/Kconfig"
> >
> >  source "drivers/remoteproc/Kconfig"
> > diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig new file mode
> > 100644 index 000..e2dd2e7
> > --- /dev/null
> > +++ b/drivers/qe/Kconfig
> > @@ -0,0 +1,8 @@
> > +#
> > +# QUICC Engine Drivers
> > +#
> > +config  U_QE
> > +   bool "Enable support for U QUICC Engine"
> > +   default y if ARCH_LS1021A && !SD_BOOT && !NAND_BOOT
> && !QSPI_BOOT
> > +   help
> > + Choose this option to add support for U QUICC Engine.
> >
> 
> Since you add Kconfig option, you should migrate all existing #define
> CONFIG_U_QE to Kconfig/defconfig. So far only T102x, T1040, LS1021,
> LS1043 have this option defined.
 
OK, will cover this in next version.

Regards,
Ran

> York

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


Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback

2018-09-24 Thread Bin Meng
Hi Andy,

On Sat, Sep 22, 2018 at 9:05 PM Andy Shevchenko
 wrote:
>
> TBD
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/serial/ns16550.c   | 14 ++
>  drivers/serial/serial-uclass.c | 21 +
>  include/common.h   |  3 +++
>  include/serial.h   | 14 ++
>  4 files changed, 52 insertions(+)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index f9041aa626..a996446936 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev, 
> int baudrate)
> return 0;
>  }
>
> +static int ns16550_serial_getinfo(struct udevice *dev, struct 
> serial_device_info *info)
> +{
> +   struct NS16550 *const com_port = dev_get_priv(dev);
> +   struct ns16550_platdata *plat = com_port->plat;
> +
> +   info->addr_space = 0;

This one is tricky. Looks current 8250 DT binding does not have a
property to describe the address space to be MMIO or PIO. I am not
sure what's the best option here.

> +   info->reg_width = 8;

For this one, I believe we can use "reg-io-width" property from device tree.

> +   info->reg_shift = plat->reg_shift;
> +   info->reg_offset = plat->reg_offset;
> +   info->addr = plat->base;
> +   return 0;
> +}
> +
>  int ns16550_serial_probe(struct udevice *dev)
>  {
> struct NS16550 *const com_port = dev_get_priv(dev);
> @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
> .pending = ns16550_serial_pending,
> .getc = ns16550_serial_getc,
> .setbrg = ns16550_serial_setbrg,
> +   .getinfo = ns16550_serial_getinfo,
>  };
>
>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index ffdcae0931..4778302e8f 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
> return 0;
>  }
>
> +int serial_getinfo(struct serial_device_info *info)
> +{
> +   struct dm_serial_ops *ops;
> +
> +   if (!gd->cur_serial_dev)
> +   return -ENODEV;
> +
> +   if (!info)
> +   return -EINVAL;
> +
> +   info->baudrate = gd->baudrate;
> +
> +   ops = serial_get_ops(gd->cur_serial_dev);
> +   if (ops->getinfo)
> +   return ops->getinfo(gd->cur_serial_dev, info);
> +
> +   return -EINVAL;
> +}
> +
>  void serial_stdio_init(void)
>  {
>  }
> @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
> if (ops->loop)
> ops->loop += gd->reloc_off
>  #endif
> +   if (ops->getinfo)
> +   ops->getinfo += gd->reloc_off;
>  #endif
> /* Set the baud rate */
> if (ops->setbrg) {
> diff --git a/include/common.h b/include/common.h
> index 83b3bdc58d..0479f3eac1 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int 
> corenr);
>  void smp_kick_all_cpus(void);
>
>  /* $(CPU)/serial.c */
> +struct serial_device_info;
> +
>  intserial_init   (void);
>  void   serial_setbrg (void);
>  void   serial_putc   (const char);
> @@ -357,6 +359,7 @@ voidserial_puts   (const char *);
>  intserial_getc   (void);
>  intserial_tstc   (void);
>  intserial_setconfig(uint config);
> +intserial_getinfo(struct serial_device_info *info);
>
>  /* $(CPU)/speed.c */
>  intget_clocks (void);
> diff --git a/include/serial.h b/include/serial.h
> index 020cd392e8..c73477b079 100644
> --- a/include/serial.h
> +++ b/include/serial.h
> @@ -111,6 +111,16 @@ enum serial_stop {
> SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
>
> +/* REVISIT: ACPI GAS specification implied */
> +struct serial_device_info {
> +   unsigned int baudrate;
> +   u8  addr_space; /* 0 - MMIO, 1 - IO */
> +   u8  reg_width;
> +   u8  reg_offset;
> +   u8  reg_shift;
> +   u64 addr;
> +};
> +
>  /**
>   * struct struct dm_serial_ops - Driver model serial operations
>   *
> @@ -201,6 +211,10 @@ struct dm_serial_ops {
>  * @return 0 if OK, -ve on error
>  */
> int (*setconfig)(struct udevice *dev, uint serial_config);
> +   /**
> +* getinfo() - Get serial device information
> +*/
> +   int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
>  };

Generally this patch looks OK to me.

BTW: why doesn't the kernel use the 'earlycon' command line?

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


Re: [U-Boot] [PATCH v1 2/2] WIP: x86: acpi: Generate SPCR table

2018-09-24 Thread Bin Meng
Hi Andy,

On Sat, Sep 22, 2018 at 9:05 PM Andy Shevchenko
 wrote:
>
> TBD
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/acpi_table.h | 25 ++
>  arch/x86/lib/acpi_table.c | 82 +++
>  2 files changed, 107 insertions(+)
>
> diff --git a/arch/x86/include/asm/acpi_table.h 
> b/arch/x86/include/asm/acpi_table.h
> index 95fae036f6..27435871b9 100644
> --- a/arch/x86/include/asm/acpi_table.h
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -303,6 +303,31 @@ struct acpi_mcfg_mmconfig {
>  /* ACPI global NVS structure */
>  struct acpi_global_nvs;
>
> +/* SPCR (Serial Port Console Redirection table) */
> +struct __packed acpi_spcr {
> +   struct acpi_table_header header;/* Common ACPI table header */
> +   u8 interface_type;  /* 0=full 16550, 1=subset of 16550 */
> +   u8 reserved[3];
> +   struct acpi_gen_regaddr serial_port;/* The base address of the 
> Serial Port register set */
> +   u8 interrupt_type;
> +   u8 pc_interrupt;
> +   u32 interrupt;  /* Global system interrupt */
> +   u8 baud_rate;
> +   u8 parity;
> +   u8 stop_bits;
> +   u8 flow_control;
> +   u8 terminal_type;
> +   u8 reserved1;
> +   u16 pci_device_id;  /* Must be 0x if not PCI device */
> +   u16 pci_vendor_id;  /* Must be 0x if not PCI device */
> +   u8 pci_bus;
> +   u8 pci_device;
> +   u8 pci_function;
> +   u32 pci_flags;
> +   u8 pci_segment;
> +   u32 reserved2;
> +};
> +
>  /* These can be used by the target port */
>
>  void acpi_fill_header(struct acpi_table_header *header, char *signature);
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index c6b2026613..551a78b11a 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -338,6 +339,79 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
> header->checksum = table_compute_checksum((void *)mcfg, 
> header->length);
>  }
>
> +static void acpi_create_spcr(struct acpi_spcr *spcr)
> +{
> +   struct acpi_table_header *header = &(spcr->header);
> +   struct serial_device_info info = {0};
> +   int access_size;
> +   int ret;
> +
> +   /* Fill out header fields */
> +   acpi_fill_header(header, "SPCR");
> +   header->length = sizeof(struct acpi_spcr);
> +   header->revision = 2;
> +
> +   ret = serial_getinfo(&info);
> +   if (ret)
> +   debug("Can't get information of serial device: %d\n", ret);
> +
> +   /* Encode baud rate */
> +   switch (info.baudrate) {
> +   case 9600:
> +   spcr->baud_rate = 3;
> +   break;
> +   case 19200:
> +   spcr->baud_rate = 4;
> +   break;
> +   case 57600:
> +   spcr->baud_rate = 6;
> +   break;
> +   case 115200:
> +   spcr->baud_rate = 7;
> +   break;
> +   default:
> +   spcr->baud_rate = 0;
> +   break;
> +   }
> +
> +   /* Encode register access size */
> +   switch (info.reg_shift) {
> +   case 0:
> +   access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS;
> +   break;
> +   case 1:
> +   access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
> +   break;
> +   case 2:
> +   access_size = ACPI_ACCESS_SIZE_DWORD_ACCESS;
> +   break;
> +   case 3:
> +   access_size = ACPI_ACCESS_SIZE_QWORD_ACCESS;
> +   break;
> +   default:
> +   access_size = ACPI_ACCESS_SIZE_UNDEFINED;
> +   break;
> +   }
> +
> +   spcr->serial_port.space_id = ACPI_ADDRESS_SPACE_MEMORY;
> +   spcr->serial_port.bit_width = info.reg_width;
> +   spcr->serial_port.bit_offset = info.reg_offset;
> +   spcr->serial_port.access_size = access_size;
> +   spcr->serial_port.addrl = info.addr >> 0;
> +   spcr->serial_port.addrh = info.addr >> 32;
> +
> +   /* Hard coded values for now */
> +   spcr->parity = 0;
> +   spcr->stop_bits = 1;
> +
> +   /* No PCI devices for now */
> +   spcr->pci_device_id = 0x;
> +   spcr->pci_vendor_id = 0x;
> +

I see not every member of 'struct __packed acpi_spcr' is populated.
Are they not used by kernel? If kernel does not use it, it is used by
Windows?

> +   /* Fix checksum */
> +   header->checksum = table_compute_checksum((void *)spcr, 
> header->length);
> +}
> +
>  /*
>   * QEMU's version of write_acpi_tables is defined in drivers/misc/qfw.c
>   */
> @@ -352,6 +426,7 @@ ulong write_acpi_tables(ulong start)
> struct acpi_fadt *fadt;
> struct acpi_mcfg *mcfg;
> struct acpi_madt *madt;
> +   struct acpi_spcr *spcr;
> int i;
>
> current = start;
> @@ -440,6 +515,13 @@ ul

Re: [U-Boot] [PATCH] i2c: Add support for the Arm's Versatile Express I2C controller.

2018-09-24 Thread Heiko Schocher

Hello Liviu,

Am 18.09.2018 um 06:21 schrieb Heiko Schocher:

Hello Liviu,

Am 17.09.2018 um 18:51 schrieb Liviu Dudau:

The Arm Versatile Express I2C controller is a simple register-based
controller that uses a register to control the state of the SCL and
SDA lines. Add support for it.

Signed-off-by: Liviu Dudau 
---
  drivers/i2c/Kconfig |   7 +
  drivers/i2c/Makefile    |   1 +
  drivers/i2c/i2c-versatile.c | 270 
  3 files changed, 278 insertions(+)
  create mode 100644 drivers/i2c/i2c-versatile.c


Reviewed-by: Heiko Schocher 

I am unsure here, if all your patches are a patchserie, or if this
i2c patch can go seperately through i2c tree ...


I got some checkpatch errors:

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#64:
new file mode 100644

WARNING: Missing a blank line after declarations
#105: FILE: drivers/i2c/i2c-versatile.c:37:
+   int v = !!(readl(priv->base + I2C_CONTROL_REG) & SDA);
+   udelay(priv->delay);

WARNING: Missing a blank line after declarations
#118: FILE: drivers/i2c/i2c-versatile.c:50:
+   int v = !!(readl(priv->base + I2C_CONTROL_REG) & SCL);
+   udelay(priv->delay);

WARNING: line over 80 characters
#187: FILE: drivers/i2c/i2c-versatile.c:119:
+static int versatile_i2c_read_byte(struct versatile_i2c_priv *priv, u8 *byte, 
u8 ack)

WARNING: Missing a blank line after declarations
#260: FILE: drivers/i2c/i2c-versatile.c:192:
+   u8 ack = (msg->len - i - 1) == 0 ? 1 : 0;
+   ret = versatile_i2c_read_byte(priv, &msg->buf[i], ack);

WARNING: line over 80 characters
#274: FILE: drivers/i2c/i2c-versatile.c:206:
+static int versatile_i2c_xfer(struct udevice *bus, struct i2c_msg *msg, int 
nmsgs)

WARNING: line over 80 characters
#288: FILE: drivers/i2c/i2c-versatile.c:220:
+static int versatile_i2c_chip_probe(struct udevice *bus, uint chip, uint 
chip_flags)

WARNING: line over 80 characters
#291: FILE: drivers/i2c/i2c-versatile.c:223:
+   struct i2c_msg msg = { .addr = chip, .flags = chip_flags, .len = 0, 
.buf = NULL };

WARNING: line over 80 characters
#314: FILE: drivers/i2c/i2c-versatile.c:246:
+   /* U-Boot still doesn't assign automatically sequence numbers to 
devices */

Please fix them, also "git am" says:

Applying: i2c: Add support for the Arm's Versatile Express I2C controller.
error: new file drivers/i2c/i2c-versatile.c depends on old contents
error: could not build fake ancestor

Could you please rebase your patch on current mainline U-Boot ?

Thanks!

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


Re: [U-Boot] [PATCH v2 21/23] test/py: convert fs-test.sh to pytest

2018-09-24 Thread AKASHI Takahiro
Simon,

Sorry for not responding soon.

On Fri, Sep 14, 2018 at 12:54:57PM +0200, Simon Glass wrote:
> Hi Akashi,
> 
> On 4 September 2018 at 09:49, AKASHI Takahiro
>  wrote:
> > In this commit, the same set of test cases as in test/fs/fs-test.sh
> > is provided using pytest framework.
> > Actually, fs-test.sh provides three variants:"sb" (sb command), "nonfs"
> > (fatxx and etc.) and "fs" (hostfs), and this patch currently supports
> > only "nonfs" variant; So it is not a replacement of fs-test.sh for now.
> >
> > Simple usage:
> >   $ py.test test/py/tests/test_fs []
> >
> > You may also specify filesystem types to be tested:
> >   $ py.test test/py/tests/test_fs --fs-type fat32 []
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  test/py/tests/test_fs/conftest.py| 216 
> >  test/py/tests/test_fs/fstest_defs.py |  10 +
> >  test/py/tests/test_fs/test_basic.py  | 287 +++
> >  3 files changed, 513 insertions(+)
> >  create mode 100644 test/py/tests/test_fs/conftest.py
> >  create mode 100644 test/py/tests/test_fs/fstest_defs.py
> >  create mode 100644 test/py/tests/test_fs/test_basic.py
> 
> Thanks for doing this!
> 
> Can you also please delete the old shell script?

No, we can't.
As I said in the commit message, my script currently supports
only one of three test variants in fs-test.sh, "nonfs."
"sb" and "fs" are yet to be implemented (if necessary).

> Does this get automatically executed with 'make tests'?

Yes, of course.

> If not, is it possible to do that easily, if we reduce the size of files, etc?
> 
> >
> > diff --git a/test/py/tests/test_fs/conftest.py 
> > b/test/py/tests/test_fs/conftest.py
> > new file mode 100644
> > index ..9155ccf84266
> > --- /dev/null
> > +++ b/test/py/tests/test_fs/conftest.py
> > @@ -0,0 +1,216 @@
> > +# SPDX-License-Identifier:  GPL-2.0+
> > +# Copyright (c) 2018, Linaro Limited
> > +# Author: Takahiro Akashi 
> > +
> > +import os
> > +import os.path
> > +import pytest
> > +import re
> > +from subprocess import call, check_call, check_output, CalledProcessError
> > +from fstest_defs import *
> > +
> > +supported_fs_basic = ['fat16', 'fat32', 'ext4']
> > +
> > +#
> > +# Filesystem test specific setup
> > +#
> > +def pytest_addoption(parser):
> 
> Please can you add full function comments to each function? You can
> see other tests or binman for the format to use.
> [...]

OK.

-Takahiro Akashi


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


Re: [U-Boot] [PATCH v3.1 01/26] fs: fat: guard the content of include/fat.h

2018-09-24 Thread Akashi, Takahiro
On Sun, Sep 23, 2018 at 04:42:17PM +0200, Alexander Graf wrote:
> 
> 
> On 12.09.18 08:55, Akashi, Takahiro wrote:
> > From: AKASHI Takahiro 
> > 
> > The whole content of include/fat.h should be guarded with CONFIG_FS_FAT.
> > 
> > This is necessary specifically because fs/fs.c unconditionally includes
> > fat.h, which refers to a config symbol, CONFIG_FS_FAT_MAX_CLUSTSIZE.
> > So if CONFIG_FS_FAT, and thus CONFIG_FS_FAT_MAX_CLUSTSIZE, is not
> > defined, fs/fs.c will fail to compile.
> 
> I don't see that define used anywhere outside of FAT code, so I still
> don't understand why we need this patch.

Try to compile u-boot without CONFIG_FS_FAT.
You will find out what I (and originally Heinrich) meant.

Thanks,
-Takahiro Akashi

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


Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions

2018-09-24 Thread Bin Meng
On Sat, Sep 22, 2018 at 3:55 AM Simon Glass  wrote:
>
> Hi Mario,
>
> On 21 September 2018 at 01:02, Mario Six  wrote:
> >
> > Hi Simon,
> >
> > On Fri, Aug 17, 2018 at 2:52 PM Simon Glass  wrote:
> > >
> > > Hi Mario,
> > >
> > > On 13 August 2018 at 00:09, Mario Six  wrote:
> > > > The regmap functions currently assume that all register map accesses
> > > > have a data width of 32 bits, but there are maps that have different
> > > > widths.
> > > >
> > > > To rectify this, implement the regmap_raw_read and regmap_raw_write
> > > > functions from the Linux kernel API that specify the width of a desired
> > > > read or write operation on a regmap.
> > > >
> > > > Implement the regmap_read and regmap_write functions using these raw
> > > > functions in a backwards-compatible manner.
> > > >
> > > > Reviewed-by: Anatolij Gustschin 
> > > > Signed-off-by: Mario Six 
> > > >
> > > > ---
> > > >
> > > > v5 -> v6:
> > > > * Corrected format specifier
> > > > * Added support for 64-bit reads/writes
> > > >
> > > > v4 -> v5:
> > > > No changes
> > > >
> > > > v3 -> v4:
> > > > * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> > > > * Explained the difference between the raw and non-raw read/write
> > > >   functions better in the docs
> > > >
> > > > v2 -> v3:
> > > > * Implement the "raw" functions from Linux instead of adding a size
> > > >   parameter to the regmap_{read,write} functions
> > > > * Fixed style violation
> > > > * Improved error handling
> > > >
> > > > v1 -> v2:
> > > > New in v2
> > > >
> > > > ---
> > > >  drivers/core/regmap.c | 59 
> > > > +--
> > > >  include/regmap.h  | 58 
> > > > ++
> > > >  2 files changed, 110 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> > > > index 154426269d9..a2f82091af0 100644
> > > > --- a/drivers/core/regmap.c
> > > > +++ b/drivers/core/regmap.c
> > > > @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> > > > return 0;
> > > >  }
> > > >
> > > > +int regmap_raw_read(struct regmap *map, uint offset, void *valp, 
> > > > size_t val_len)
> > > > +{
> > > > +   void *ptr;
> > > > +
> > > > +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> > > > MAP_NOCACHE);
> > > > +
> > > > +   switch (val_len) {
> > > > +   case REGMAP_SIZE_8:
> > > > +   *((u8 *)valp) = in_8((u8 *)ptr);
> > > > +   break;
> > > > +   case REGMAP_SIZE_16:
> > > > +   *((u16 *)valp) = in_le16((u16 *)ptr);
> > > > +   break;
> > > > +   case REGMAP_SIZE_32:
> > > > +   *((u32 *)valp) = in_le32((u32 *)ptr);
> > > > +   break;
> > > > +#if defined(in_le64) && defined(readq)
> > > > +   case REGMAP_SIZE_64:
> > > > +   *((u32 *)valp) = in_le64((u64 *)ptr);
> > >
> > > How come this is u32? Can you please add a comment?
> > >
> >
> > That was a development version of the patch, sorry (I was in a bit of a 
> > hurry).
> >
> > I'll send a corrected version with v7.
> >
> > > Why is this using in/out rather than read/write? Does it not support
> > > memory-mapped I/O?
> > >
> >
> > It does, but I think the endianness of the read/write operations of the 
> > regmap
> > should not depend on the architecture, but only on the regmap itself (which 
> > is
> > little-endian for now; big-endian support can be introduced later on), so I
> > used in/out rather than read/write.
>

If regmap currently only supports little-endian, can we document this somewhere?

> What does endianness have to do with whether you use readl/writel or in/out?
>
> On x86 at least these are actually different things, so regmap() won't
> work on x86 with this change.
>

Looks so far x86's {in,out}_{8,16,32} are using MMIO.

> Adding Bin who may understand this better.

BTW: I was trying to understand why we need regmap here. Shouldn't the
driver directly call {in,out}{bwl}, or {read,write}{bwlq} APIs?

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


Re: [U-Boot] [PATCH v2 3/4] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level

2018-09-24 Thread Cédric Le Goater
On 09/25/2018 02:21 AM, Joel Stanley wrote:
> On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater  wrote:
>>
>> This is a large update of the AST2500 Soc DTS file bringing it to the
>> level of commit 927c2fc2db19 :
>>
>> Author:  Joel Stanley 
>> Date:Sat Jun 2 01:18:53 2018 -0700
>>
>>  ARM: dts: aspeed: Fix hwrng register address
>>
>> There are some differences on the compatibility property names. scu,
>> reset and clock drivers are also different.
> 
> You made the required changes in this patch? We should document those
> so we know how to sync it next time.

I only changed where the nodes were defined in the u-boot DTS file. As
for the sync, it is necessarily manual :/ See below for the differences.

The clocks are defined in another DTS file in u-boot. May be there is 
room for improvements on both sides tough. 

Syncing the "compatible" strings would be a good thing.  

> If it's possible, we can also add compatible properties to the Linux
> version of the device tree to make syncing easier.
> 
>> Signed-off-by: Cédric Le Goater 
> 
> Reviewed-by: Joel Stanley 

Thanks,

C.


--- linux/arch/arm/boot/dts/aspeed-g5.dtsi  2018-06-14 16:30:01.790506371 
+0200
+++ u-boot/arch/arm//dts/ast2500.dtsi   2018-09-22 17:35:14.302476829 +0200
@@ -1,5 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0+
-#include 
+/*
+ * This device tree is copied from
+ * 
https://raw.githubusercontent.com/torvalds/linux/34ea5c9d/arch/arm/boot/dts/aspeed-g5.dtsi
+ */
+#include "skeleton.dtsi"
 
 / {
model = "Aspeed BMC";
@@ -59,7 +62,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-fmc";
-   clocks = <&syscon ASPEED_CLK_AHB>;
status = "disabled";
interrupts = <19>;
flash@0 {
@@ -85,7 +87,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-spi";
-   clocks = <&syscon ASPEED_CLK_AHB>;
status = "disabled";
flash@0 {
reg = < 0 >;
@@ -105,7 +106,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-spi";
-   clocks = <&syscon ASPEED_CLK_AHB>;
status = "disabled";
flash@0 {
reg = < 0 >;
@@ -131,7 +131,6 @@
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e66 0x180>;
interrupts = <2>;
-   clocks = <&syscon ASPEED_CLK_GATE_MAC1CLK>;
status = "disabled";
};
 
@@ -139,7 +138,6 @@
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e68 0x180>;
interrupts = <3>;
-   clocks = <&syscon ASPEED_CLK_GATE_MAC2CLK>;
status = "disabled";
};
 
@@ -147,7 +145,6 @@
compatible = "aspeed,ast2500-ehci", "generic-ehci";
reg = <0x1e6a1000 0x100>;
interrupts = <5>;
-   clocks = <&syscon ASPEED_CLK_GATE_USBPORT1CLK>;
status = "disabled";
};
 
@@ -155,7 +152,6 @@
compatible = "aspeed,ast2500-ehci", "generic-ehci";
reg = <0x1e6a3000 0x100>;
interrupts = <13>;
-   clocks = <&syscon ASPEED_CLK_GATE_USBPORT2CLK>;
status = "disabled";
};
 
@@ -164,7 +160,6 @@
reg = <0x1e6b 0x100>;
interrupts = <14>;
#ports = <2>;
-   clocks = <&syscon ASPEED_CLK_GATE_USBUHCICLK>;
status = "disabled";
};
 
@@ -175,10 +170,8 @@
ranges;
 
syscon: syscon@1e6e2000 {
-   compatible = "aspeed,ast2500-scu", "syscon", 
"simple-mfd";
+   compatible = "aspeed,g5-scu", "syscon", 
"simple-mfd";
reg = <0x1e6e2000 0x1a8>;
-   #address-cells = <1>;
-   #size-cells = <0>;
#clock-cells = <1>;
#reset-cells = <1>;
 
@@ -189,6 +182,39 @@
};
};
 
+   clk_clkin: clk_clkin@1e6e2070 {
+   #clock-cells = <0>;
+   compatible = "aspeed,g5-clkin-cloc

Re: [U-Boot] [PATCH 2/2] fdt: fdtdec_setup_memory_banksize() use livetree

2018-09-24 Thread Jens Wiklander
Hi Simon,

On Tue, Sep 18, 2018 at 4:05 AM, Simon Glass  wrote:
> Hi Jen,
>
> On 17 August 2018 at 14:48, Simon Glass  wrote:
>>
>> On 10 August 2018 at 06:54, Jens Wiklander  wrote:
>> > Converts fdtdec_setup_memory_banksize() to use ofnode functions instead.
>> >
>> > Signed-off-by: Jens Wiklander 
>> > ---
>> >  lib/fdtdec.c | 46 +-
>> >  1 file changed, 21 insertions(+), 25 deletions(-)
>> >
>>
>> Reviewed-by: Simon Glass 
>
>
> Can you please rebase this on u-boot-dm/testing and resent? It seems
> to conflict with an existing patch.

I'm sorry, missed this one. It seems it's already been done by now.

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


Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions

2018-09-24 Thread Mario Six
Hi Simon,

On Fri, Sep 21, 2018 at 9:56 PM Simon Glass  wrote:
>
> Hi Mario,
>
> On 21 September 2018 at 01:02, Mario Six  wrote:
> >
> > Hi Simon,
> >
> > On Fri, Aug 17, 2018 at 2:52 PM Simon Glass  wrote:
> > >
> > > Hi Mario,
> > >
> > > On 13 August 2018 at 00:09, Mario Six  wrote:
> > > > The regmap functions currently assume that all register map accesses
> > > > have a data width of 32 bits, but there are maps that have different
> > > > widths.
> > > >
> > > > To rectify this, implement the regmap_raw_read and regmap_raw_write
> > > > functions from the Linux kernel API that specify the width of a desired
> > > > read or write operation on a regmap.
> > > >
> > > > Implement the regmap_read and regmap_write functions using these raw
> > > > functions in a backwards-compatible manner.
> > > >
> > > > Reviewed-by: Anatolij Gustschin 
> > > > Signed-off-by: Mario Six 
> > > >
> > > > ---
> > > >
> > > > v5 -> v6:
> > > > * Corrected format specifier
> > > > * Added support for 64-bit reads/writes
> > > >
> > > > v4 -> v5:
> > > > No changes
> > > >
> > > > v3 -> v4:
> > > > * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> > > > * Explained the difference between the raw and non-raw read/write
> > > >   functions better in the docs
> > > >
> > > > v2 -> v3:
> > > > * Implement the "raw" functions from Linux instead of adding a size
> > > >   parameter to the regmap_{read,write} functions
> > > > * Fixed style violation
> > > > * Improved error handling
> > > >
> > > > v1 -> v2:
> > > > New in v2
> > > >
> > > > ---
> > > >  drivers/core/regmap.c | 59 
> > > > +--
> > > >  include/regmap.h  | 58 
> > > > ++
> > > >  2 files changed, 110 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> > > > index 154426269d9..a2f82091af0 100644
> > > > --- a/drivers/core/regmap.c
> > > > +++ b/drivers/core/regmap.c
> > > > @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> > > > return 0;
> > > >  }
> > > >
> > > > +int regmap_raw_read(struct regmap *map, uint offset, void *valp, 
> > > > size_t val_len)
> > > > +{
> > > > +   void *ptr;
> > > > +
> > > > +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> > > > MAP_NOCACHE);
> > > > +
> > > > +   switch (val_len) {
> > > > +   case REGMAP_SIZE_8:
> > > > +   *((u8 *)valp) = in_8((u8 *)ptr);
> > > > +   break;
> > > > +   case REGMAP_SIZE_16:
> > > > +   *((u16 *)valp) = in_le16((u16 *)ptr);
> > > > +   break;
> > > > +   case REGMAP_SIZE_32:
> > > > +   *((u32 *)valp) = in_le32((u32 *)ptr);
> > > > +   break;
> > > > +#if defined(in_le64) && defined(readq)
> > > > +   case REGMAP_SIZE_64:
> > > > +   *((u32 *)valp) = in_le64((u64 *)ptr);
> > >
> > > How come this is u32? Can you please add a comment?
> > >
> >
> > That was a development version of the patch, sorry (I was in a bit of a 
> > hurry).
> >
> > I'll send a corrected version with v7.
> >
> > > Why is this using in/out rather than read/write? Does it not support
> > > memory-mapped I/O?
> > >
> >
> > It does, but I think the endianness of the read/write operations of the 
> > regmap
> > should not depend on the architecture, but only on the regmap itself (which 
> > is
> > little-endian for now; big-endian support can be introduced later on), so I
> > used in/out rather than read/write.
>
> What does endianness have to do with whether you use readl/writel or in/out?
>
> On x86 at least these are actually different things, so regmap() won't
> work on x86 with this change.
>

Ah, OK, I was not aware of that, because on powerpc we literally have, e.g.

#define readl(addr) in_le32((volatile u32 *)(addr))

So the only difference is really just the explicit endianness. Could you (or
Bin, for that matter), explain what the differences are? I think it would be a
good thing to document this somewhere, so others are more aware of the issue.

> Adding Bin who may understand this better.
>
> Regards,
> Simon
>

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


Re: [U-Boot] [PATCH v3 05/20] mmc: rpmb: add mmc_rpmb_route_frames()

2018-09-24 Thread Jens Wiklander
Hi Simon,

On Fri, Sep 14, 2018 at 12:53 PM, Simon Glass  wrote:
> Hi Jens,
>
> On 3 September 2018 at 16:46, Jens Wiklander  
> wrote:
>> Adds mmc_rpmb_route_frames() to route RPMB data frames from/to an
>> external entity.
>>
>> Tested-by: Igor Opaniuk 
>> Signed-off-by: Jens Wiklander 
>> ---
>>  drivers/mmc/rpmb.c | 160 +
>>  include/mmc.h  |   2 +
>>  2 files changed, 162 insertions(+)
>>
>
> [..]
>
>> diff --git a/include/mmc.h b/include/mmc.h
>> index df4255b828a7..d6e02af4edea 100644
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -748,6 +748,8 @@ int mmc_rpmb_read(struct mmc *mmc, void *addr, unsigned 
>> short blk,
>>   unsigned short cnt, unsigned char *key);
>>  int mmc_rpmb_write(struct mmc *mmc, void *addr, unsigned short blk,
>>unsigned short cnt, unsigned char *key);
>> +int mmc_rpmb_route_frames(struct mmc *mmc, void *req, unsigned long reqlen,
>> + void *rsp, unsigned long rsplen);
>
> Please can you add a full comment to this function? All header-file
> functions should be commented.

I'll fix.

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


Re: [U-Boot] [PATCH] Convert CONFIG_DISABLE_CONSOLE to Kconfig

2018-09-24 Thread Christian Gmeiner
ping..

 schrieb am Do., 20. Sep. 2018, 17:05:

> ping
>
> Am Mo., 10. Sep. 2018 um 12:43 Uhr schrieb Christian Gmeiner
> :
> >
> > This converts the following to Kconfig:
> >CONFIG_DISABLE_CONSOLE
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  common/Kconfig   | 5 +
> >  scripts/config_whitelist.txt | 1 -
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index 3030da4fc9..207cb3ae0b 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -259,6 +259,11 @@ config CONSOLE_RECORD_IN_SIZE
> >   The buffer is allocated immediately after the malloc() region
> is
> >   ready.
> >
> > +config DISABLE_CONSOLE
> > +   bool "Add functionality to disable console completely"
> > +   help
> > +   Disable console (in & out).
> > +
> >  config IDENT_STRING
> > string "Board specific string to be added to uboot version
> string"
> > help
> > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> > index fc37099cbe..27fba1e963 100644
> > --- a/scripts/config_whitelist.txt
> > +++ b/scripts/config_whitelist.txt
> > @@ -366,7 +366,6 @@ CONFIG_DHCP_MIN_EXT_LEN
> >  CONFIG_DIALOG_POWER
> >  CONFIG_DIMM_SLOTS_PER_CTLR
> >  CONFIG_DIRECT_NOR_BOOT
> > -CONFIG_DISABLE_CONSOLE
> >  CONFIG_DISCONTIGMEM
> >  CONFIG_DISCOVER_PHY
> >  CONFIG_DISPLAY_AER_
> > --
> > 2.17.1
> >
>
>
> --
> greets
> --
> Christian Gmeiner, MSc
>
> https://christian-gmeiner.info


--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Christian Gmeiner


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


Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions

2018-09-24 Thread Mario Six
Hi Bin,

On Tue, Sep 25, 2018 at 7:48 AM Bin Meng  wrote:
>
> On Sat, Sep 22, 2018 at 3:55 AM Simon Glass  wrote:
> >
> > Hi Mario,
> >
> > On 21 September 2018 at 01:02, Mario Six  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Aug 17, 2018 at 2:52 PM Simon Glass  wrote:
> > > >
> > > > Hi Mario,
> > > >
> > > > On 13 August 2018 at 00:09, Mario Six  wrote:
> > > > > The regmap functions currently assume that all register map accesses
> > > > > have a data width of 32 bits, but there are maps that have different
> > > > > widths.
> > > > >
> > > > > To rectify this, implement the regmap_raw_read and regmap_raw_write
> > > > > functions from the Linux kernel API that specify the width of a 
> > > > > desired
> > > > > read or write operation on a regmap.
> > > > >
> > > > > Implement the regmap_read and regmap_write functions using these raw
> > > > > functions in a backwards-compatible manner.
> > > > >
> > > > > Reviewed-by: Anatolij Gustschin 
> > > > > Signed-off-by: Mario Six 
> > > > >
> > > > > ---
> > > > >
> > > > > v5 -> v6:
> > > > > * Corrected format specifier
> > > > > * Added support for 64-bit reads/writes
> > > > >
> > > > > v4 -> v5:
> > > > > No changes
> > > > >
> > > > > v3 -> v4:
> > > > > * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> > > > > * Explained the difference between the raw and non-raw read/write
> > > > >   functions better in the docs
> > > > >
> > > > > v2 -> v3:
> > > > > * Implement the "raw" functions from Linux instead of adding a size
> > > > >   parameter to the regmap_{read,write} functions
> > > > > * Fixed style violation
> > > > > * Improved error handling
> > > > >
> > > > > v1 -> v2:
> > > > > New in v2
> > > > >
> > > > > ---
> > > > >  drivers/core/regmap.c | 59 
> > > > > +--
> > > > >  include/regmap.h  | 58 
> > > > > ++
> > > > >  2 files changed, 110 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> > > > > index 154426269d9..a2f82091af0 100644
> > > > > --- a/drivers/core/regmap.c
> > > > > +++ b/drivers/core/regmap.c
> > > > > @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> > > > > return 0;
> > > > >  }
> > > > >
> > > > > +int regmap_raw_read(struct regmap *map, uint offset, void *valp, 
> > > > > size_t val_len)
> > > > > +{
> > > > > +   void *ptr;
> > > > > +
> > > > > +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> > > > > MAP_NOCACHE);
> > > > > +
> > > > > +   switch (val_len) {
> > > > > +   case REGMAP_SIZE_8:
> > > > > +   *((u8 *)valp) = in_8((u8 *)ptr);
> > > > > +   break;
> > > > > +   case REGMAP_SIZE_16:
> > > > > +   *((u16 *)valp) = in_le16((u16 *)ptr);
> > > > > +   break;
> > > > > +   case REGMAP_SIZE_32:
> > > > > +   *((u32 *)valp) = in_le32((u32 *)ptr);
> > > > > +   break;
> > > > > +#if defined(in_le64) && defined(readq)
> > > > > +   case REGMAP_SIZE_64:
> > > > > +   *((u32 *)valp) = in_le64((u64 *)ptr);
> > > >
> > > > How come this is u32? Can you please add a comment?
> > > >
> > >
> > > That was a development version of the patch, sorry (I was in a bit of a 
> > > hurry).
> > >
> > > I'll send a corrected version with v7.
> > >
> > > > Why is this using in/out rather than read/write? Does it not support
> > > > memory-mapped I/O?
> > > >
> > >
> > > It does, but I think the endianness of the read/write operations of the 
> > > regmap
> > > should not depend on the architecture, but only on the regmap itself 
> > > (which is
> > > little-endian for now; big-endian support can be introduced later on), so 
> > > I
> > > used in/out rather than read/write.
> >
>
> If regmap currently only supports little-endian, can we document this 
> somewhere?
>
Yes, good idea. I'll send a v7 to address this.

> > What does endianness have to do with whether you use readl/writel or in/out?
> >
> > On x86 at least these are actually different things, so regmap() won't
> > work on x86 with this change.
> >
>
> Looks so far x86's {in,out}_{8,16,32} are using MMIO.
>
> > Adding Bin who may understand this better.
>
> BTW: I was trying to understand why we need regmap here. Shouldn't the
> driver directly call {in,out}{bwl}, or {read,write}{bwlq} APIs?
>
In this version of the FPGA driver, the regmap is not strictly needed, true.
But we also have devices that have multiple FPGAs where the "slave" FPGA's
register maps are accessed through a custom bus interface (called MCLink) on
the first "master FPGA". With the regmap, I'll be able to use the same driver
for both, all that's needed is another version of regmap for the MCLink bus. So
the regmap is really there for forward-compatibility reasons.

> Regards,
> Bin
>
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.d

Re: [U-Boot] [PATCH] net: macb: Clean 64b dma addresses if they are not detected

2018-09-24 Thread Michal Simek
On 21.9.2018 14:38, Nicolas Ferre wrote:
> Michal,
> 
> On 20/09/2018 at 08:23, Michal Simek wrote:
>> On 19.9.2018 20:08, Edgar E. Iglesias wrote:
>>> On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote:
 Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B
 is not detected on 64bit system.
 The issue was observed when bootloader(u-boot) does not check macb
 feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
 by default. Then macb driver is reading DMACFG register back and only
 adding 64bit dma configuration but not cleaning it out.

 This is also align with other features which are also cleared if
 they are not
 present.
>>>
>>> Hi Michal,
>>>

 Signed-off-by: Michal Simek 
 ---

   drivers/net/ethernet/cadence/macb_main.c | 2 ++
   1 file changed, 2 insertions(+)

 diff --git a/drivers/net/ethernet/cadence/macb_main.c
 b/drivers/net/ethernet/cadence/macb_main.c
 index 16e4ef7d7185..79707dff3f13 100644
 --- a/drivers/net/ethernet/cadence/macb_main.c
 +++ b/drivers/net/ethernet/cadence/macb_main.c
 @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp)
   #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
   if (bp->hw_dma_cap & HW_DMA_CAP_64B)
   dmacfg |= GEM_BIT(ADDR64);
 +    else
 +    dmacfg &= ~GEM_BIT(ADDR64);
   #endif
>>>
>>> I think you might want to do this clearing outside of the #ifdef.
>>> If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make
>>> sure the ADDR64 is cleared. E.g something like:
>>>
>>>   dmacfg &= ~GEM_BIT(ADDR64);
>>> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>   if (bp->hw_dma_cap & HW_DMA_CAP_64B)
>>>   dmacfg |= GEM_BIT(ADDR64);
>>> #endif
>>>
>>>
>>> Same thing for the USE_HWSTAMP/PTP flags below.
>>
>> Origin patch, which introduce this read with mask,
>> macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
>> was done in 2011 and from that time this function was extended a little
>> bit. I am even not quite sure if make sense to read this reg and apply
>> setting on the top of it.
>>
>> Nicolas: Isn't it better simply compose that reg from scratch?
> 
> I have several arguments against composing this register from scratch:
> 
> 1/ the reset value of this register is non-null for both of our
> platforms and it could be meaningful to keep some of these values.
> 
> 2/ one bitfield could use different values between Zynq and AT91: RXBMS
> (1kB to 8kB for Zynq and 512 to 4KB for AT91), with same encoding.
> 
> 3/ and well, this is the type of register with multiple bits that are
> marked as "reserved" and that experience tells that they might be
> connected to something...
> 
> So, I'm all for correcting the code like what Edgar suggests.

ok. I have sent v2.

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


[U-Boot] [PATCH v2 1/3] qe: kconfig: U QE kconfig

2018-09-24 Thread Ran Wang
add Kconfig option for U QUICC Engine.

Signed-off-by: Ran Wang 
---
Change in v2:
Add more conditional define to support more platforms.

 drivers/Kconfig|  2 ++
 drivers/qe/Kconfig | 12 
 2 files changed, 14 insertions(+)
 create mode 100644 drivers/qe/Kconfig

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 56536c4b19..884a945a19 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -74,6 +74,8 @@ source "drivers/power/Kconfig"
 
 source "drivers/pwm/Kconfig"
 
+source "drivers/qe/Kconfig"
+
 source "drivers/ram/Kconfig"
 
 source "drivers/remoteproc/Kconfig"
diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig
new file mode 100644
index 00..c47b54ab12
--- /dev/null
+++ b/drivers/qe/Kconfig
@@ -0,0 +1,12 @@
+#
+# QUICC Engine Drivers
+#
+config  U_QE
+   bool "Enable support for U QUICC Engine"
+   default y if (ARCH_LS1021A && !SD_BOOT && !NAND_BOOT && !QSPI_BOOT) \
+   || (TARGET_T1024QDS) \
+   || (TARGET_T1024RDB) \
+   || (TARGET_T1040QDS && !NOBQFMAN) \
+   || (TARGET_LS1043ARDB && !SPL_NO_QE && !NAND_BOOT && !QSPI_BOOT)
+   help
+ Choose this option to add support for U QUICC Engine.
-- 
2.17.1

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


[U-Boot] [PATCH v2 3/3] armv7: ls102xa: Disable QE before enter deep sleep

2018-09-24 Thread Ran Wang
Otherwise system will hang after executing wfi.

Signed-off-by: Ran Wang 
---
Change in v2:
None

 arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 4 
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c 
b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
index af413f8622..bb169aaaf4 100644
--- a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
+++ b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
@@ -73,6 +73,7 @@ static void __secure ls1_deepsleep_irq_cfg(void)
 * read, that is why we don't read it from register ippdexpcr1 itself.
 */
ippdexpcr1 = in_le32(&scfg->sparecr[7]);
+   out_be32(&rcpm->ippdexpcr1, ippdexpcr1);
 
if (ippdexpcr0 & RCPM_IPPDEXPCR0_ETSEC)
pmcintecr |= SCFG_PMCINTECR_ETSECRXG0 |
@@ -192,6 +193,9 @@ static void __secure ls1_deep_sleep(u32 entry_point)
setbits_be32(&scfg->dpslpcr, SCFG_DPSLPCR_WDRR_EN);
setbits_be32(&gur->crstsr, DCFG_CRSTSR_WDRFR);
 
+   /* Disable QE */
+   setbits_be32(&gur->devdisr, CCSR_DEVDISR1_QE);
+
ls1_deepsleep_irq_cfg();
 
psci_v7_flush_dcache_all();
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 13a282ffe1..a3d1171aa9 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -86,6 +86,8 @@ struct sys_info {
unsigned long freq_localbus;
 };
 
+#define CCSR_DEVDISR1_QE   0x0001
+
 /* Device Configuration and Pin Control */
 struct ccsr_gur {
u32 porsr1; /* POR status 1 */
-- 
2.17.1

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


[U-Boot] [PATCH v2 2/3] arm: layerscape: Remove CONFIG_U_QE define in head files

2018-09-24 Thread Ran Wang
Because it has been moved to drivers/qe/Kconfig instead.
Following platforms are involved:
T102xQDS, T102xRDB, T1040QDS, ls1021aqds, ls1021atwr, ls1043ardb

Signed-off-by: Ran Wang 
---
Change in v2:
Remove CONFIG_U_QE from more platforms besides ls1021a

 include/configs/T102xQDS.h   | 1 -
 include/configs/T102xRDB.h   | 1 -
 include/configs/T1040QDS.h   | 1 -
 include/configs/ls1021aqds.h | 1 -
 include/configs/ls1021atwr.h | 1 -
 include/configs/ls1043ardb.h | 7 ---
 6 files changed, 12 deletions(-)

diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index 8a38c5e19c..191616b8b0 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -659,7 +659,6 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_DPAA_FMAN
 
 #define CONFIG_QE
-#define CONFIG_U_QE
 /* Default address of microcode for the Linux FMan driver */
 #if defined(CONFIG_SPIFLASH)
 /*
diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h
index f7a54f7a97..ac5de8d164 100644
--- a/include/configs/T102xRDB.h
+++ b/include/configs/T102xRDB.h
@@ -669,7 +669,6 @@ unsigned long get_board_ddr_clk(void);
 
 #ifdef CONFIG_TARGET_T1024RDB
 #define CONFIG_QE
-#define CONFIG_U_QE
 #endif
 /* Default address of microcode for the Linux FMan driver */
 #if defined(CONFIG_SPIFLASH)
diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h
index e890860b7e..25615be40e 100644
--- a/include/configs/T1040QDS.h
+++ b/include/configs/T1040QDS.h
@@ -549,7 +549,6 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_DPAA_PME
 
 #define CONFIG_QE
-#define CONFIG_U_QE
 /* Default address of microcode for the Linux Fman driver */
 #if defined(CONFIG_SPIFLASH)
 /*
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 994e6ca362..7f7ffdede1 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -107,7 +107,6 @@ unsigned long get_board_ddr_clk(void);
 
 #if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_NAND_BOOT) && \
!defined(CONFIG_QSPI_BOOT)
-#define CONFIG_U_QE
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
 #endif
 
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 75b2e2fbbd..ddd024e8c0 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -106,7 +106,6 @@
 
 #if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_NAND_BOOT) && \
!defined(CONFIG_QSPI_BOOT)
-#define CONFIG_U_QE
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
 #endif
 
diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
index bc639e586f..ffd92dbb43 100644
--- a/include/configs/ls1043ardb.h
+++ b/include/configs/ls1043ardb.h
@@ -268,13 +268,6 @@
 #endif
 #endif
 
-/* QE */
-#ifndef SPL_NO_QE
-#if !defined(CONFIG_NAND_BOOT) && !defined(CONFIG_QSPI_BOOT)
-#define CONFIG_U_QE
-#endif
-#endif
-
 /* SATA */
 #ifndef SPL_NO_SATA
 #ifndef CONFIG_CMD_EXT2
-- 
2.17.1

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


[U-Boot] [PATCH v9 1/8] ppa/fm/qe: use block layer in ppa/fm/qe driver

2018-09-24 Thread Yinbo Zhu
At present the MMC subsystem maintains its own list
of MMC devices. This cannot work with driver model
when CONFIG_BLK is enabled, use blk_dread to
replace previous mmc read interface,
use mmc_get_blk_desc to get the mmc device property

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling 
errors 

 arch/arm/cpu/armv8/fsl-layerscape/ppa.c |7 +++
 drivers/net/fm/fm.c |2 +-
 drivers/qe/qe.c |2 +-
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
index a31c4d9..d391f93 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
@@ -99,7 +99,7 @@ int ppa_init(void)
cnt = DIV_ROUND_UP(fdt_header_len, 512);
debug("%s: MMC read PPA FIT header: dev # %u, block # %u, count %u\n",
  __func__, dev, blk, cnt);
-   ret = mmc->block_dev.block_read(&mmc->block_dev, blk, cnt, fitp);
+   ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt, fitp);
if (ret != cnt) {
free(fitp);
printf("MMC/SD read of PPA FIT header at offset 0x%x failed\n",
@@ -123,7 +123,7 @@ int ppa_init(void)
 
blk = CONFIG_SYS_LS_PPA_ESBC_ADDR >> 9;
cnt = DIV_ROUND_UP(CONFIG_LS_PPA_ESBC_HDR_SIZE, 512);
-   ret = mmc->block_dev.block_read(&mmc->block_dev, blk, cnt, ppa_hdr_ddr);
+   ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt, ppa_hdr_ddr);
if (ret != cnt) {
free(ppa_hdr_ddr);
printf("MMC/SD read of PPA header failed\n");
@@ -149,8 +149,7 @@ int ppa_init(void)
cnt = DIV_ROUND_UP(fw_length, 512);
debug("%s: MMC read PPA FIT image: dev # %u, block # %u, count %u\n",
  __func__, dev, blk, cnt);
-   ret = mmc->block_dev.block_read(&mmc->block_dev,
-   blk, cnt, ppa_fit_addr);
+   ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt, ppa_fit_addr);
if (ret != cnt) {
free(ppa_fit_addr);
printf("MMC/SD read of PPA FIT header at offset 0x%x failed\n",
diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 3327073..c5cf188 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -402,7 +402,7 @@ int fm_init_common(int index, struct ccsr_fman *reg)
printf("\nMMC read: dev # %u, block # %u, count %u ...\n",
dev, blk, cnt);
mmc_init(mmc);
-   (void)mmc->block_dev.block_read(&mmc->block_dev, blk, cnt,
+   (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
addr);
}
 #elif defined(CONFIG_SYS_QE_FMAN_FW_IN_REMOTE)
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index 7654df8..7010bbc 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -218,7 +218,7 @@ void u_qe_init(void)
printf("\nMMC read: dev # %u, block # %u, count %u ...\n",
   dev, blk, cnt);
mmc_init(mmc);
-   (void)mmc->block_dev.block_read(&mmc->block_dev, blk, cnt,
+   (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
addr);
}
 #endif
-- 
1.7.1

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


[U-Boot] [PATCH v9 2/8] armv8/ls1088a/ls2088a: esdhc: Add esdhc clock support

2018-09-24 Thread Yinbo Zhu
This patch adds esdhc clock support for ls1088a and ls2088a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling 
errors 

 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
index 653c6dd..bc268e2 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -192,6 +192,16 @@ int get_dspi_freq(ulong dummy)
return get_bus_freq(0) / CONFIG_SYS_FSL_DSPI_CLK_DIV;
 }
 
+#ifdef CONFIG_FSL_ESDHC
+int get_sdhc_freq(ulong dummy)
+{
+   if (!gd->arch.sdhc_clk)
+   get_clocks();
+
+   return gd->arch.sdhc_clk;
+}
+#endif
+
 int get_serial_clock(void)
 {
return get_bus_freq(0) / CONFIG_SYS_FSL_DUART_CLK_DIV;
@@ -202,6 +212,10 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
switch (clk) {
case MXC_I2C_CLK:
return get_i2c_freq(0);
+#if defined(CONFIG_FSL_ESDHC)
+   case MXC_ESDHC_CLK:
+   return get_sdhc_freq(0);
+#endif
case MXC_DSPI_CLK:
return get_dspi_freq(0);
default:
-- 
1.7.1

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


[U-Boot] [PATCH v9 3/8] armv8: ls2088a: add eSDHC node

2018-09-24 Thread Yinbo Zhu
This patch is to add eSDHC node for ls2088a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 arch/arm/dts/fsl-ls2080a.dtsi |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index b0f8517..2d537ae 100644
--- a/arch/arm/dts/fsl-ls2080a.dtsi
+++ b/arch/arm/dts/fsl-ls2080a.dtsi
@@ -75,6 +75,14 @@
num-cs = <4>;
};
 
+   esdhc: esdhc@0 {
+   compatible = "fsl,esdhc";
+   reg = <0x0 0x214 0x0 0x1>;
+   interrupts = <0 28 0x4>; /* Level high type */
+   little-endian;
+   bus-width = <4>;
+   };
+
usb0: usb3@310 {
compatible = "fsl,layerscape-dwc3";
reg = <0x0 0x310 0x0 0x1>;
-- 
1.7.1

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


[U-Boot] [PATCH v9 4/8] armv8: ls1088a: add eSDHC node

2018-09-24 Thread Yinbo Zhu
This patch is to add eSDHC node for ls1088a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 arch/arm/dts/fsl-ls1088a.dtsi |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 077caf3..72d755a 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -74,6 +74,15 @@
reg-names = "QuadSPI", "QuadSPI-memory";
num-cs = <4>;
};
+
+   esdhc: esdhc@214 {
+   compatible = "fsl,esdhc";
+   reg = <0x0 0x214 0x0 0x1>;
+   interrupts = <0 28 0x4>; /* Level high type */
+   little-endian;
+   bus-width = <4>;
+   };
+
ifc: ifc@153 {
compatible = "fsl,ifc", "simple-bus";
reg = <0x0 0x224 0x0 0x2>;
-- 
1.7.1

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


[U-Boot] [PATCH v9 6/8] armv8: ls1046a: add eSDHC node

2018-09-24 Thread Yinbo Zhu
This patch is to add eSDHC node for ls1046a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 arch/arm/dts/fsl-ls1046a.dtsi |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index 4acbaf7..7687d12 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -70,6 +70,14 @@
status = "disabled";
};
 
+   esdhc: esdhc@156 {
+   compatible = "fsl,esdhc";
+   reg = <0x0 0x156 0x0 0x1>;
+   interrupts = <0 62 0x4>;
+   big-endian;
+   bus-width = <4>;
+   };
+
ifc: ifc@153 {
compatible = "fsl,ifc", "simple-bus";
reg = <0x0 0x153 0x0 0x1>;
-- 
1.7.1

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


[U-Boot] [PATCH v9 5/8] armv8: ls1043a: add eSDHC node

2018-09-24 Thread Yinbo Zhu
This patch is to add eSDHC node for ls1043a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 arch/arm/dts/fsl-ls1043a.dtsi |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index ff40122..a804f51 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -70,6 +70,14 @@
status = "disabled";
};
 
+   esdhc: esdhc@156 {
+   compatible = "fsl,esdhc";
+   reg = <0x0 0x156 0x0 0x1>;
+   interrupts = <0 62 0x4>;
+   big-endian;
+   bus-width = <4>;
+   };
+
ifc: ifc@153 {
compatible = "fsl,ifc", "simple-bus";
reg = <0x0 0x153 0x0 0x1>;
-- 
1.7.1

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


[U-Boot] [PATCH v9 7/8] armv7: ls1021a: enable esdhc

2018-09-24 Thread Yinbo Zhu
This patch is to enable eSDHC for ls1021a.

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 arch/arm/dts/ls1021a.dtsi |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 5b3fc6a..59c97d5 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -96,7 +96,6 @@
sdhci,auto-cmd12;
big-endian;
bus-width = <4>;
-   status = "disabled";
};
 
scfg: scfg@157 {
-- 
1.7.1

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


[U-Boot] [PATCH v9 8/8] Enable CONFIG_BLK and CONFIG_DM_MMC to Kconfig

2018-09-24 Thread Yinbo Zhu
This enables the folowing to Kconfig:
CONFIG_BLK
CONFIG_DM_MMC

Signed-off-by: Yinbo Zhu 
---
Change in v9:
fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors

 configs/ls1021atwr_nor_SECURE_BOOT_defconfig  |2 ++
 configs/ls1021atwr_nor_defconfig  |2 ++
 configs/ls1021atwr_nor_lpuart_defconfig   |2 ++
 configs/ls1021atwr_qspi_defconfig |2 ++
 configs/ls1021atwr_sdcard_ifc_defconfig   |2 ++
 configs/ls1021atwr_sdcard_qspi_defconfig  |2 ++
 configs/ls1043aqds_defconfig  |2 ++
 configs/ls1043aqds_lpuart_defconfig   |2 ++
 configs/ls1043aqds_nand_defconfig |2 ++
 configs/ls1043aqds_nor_ddr3_defconfig |2 ++
 configs/ls1043aqds_qspi_defconfig |2 ++
 configs/ls1043aqds_sdcard_ifc_defconfig   |2 ++
 configs/ls1043aqds_sdcard_qspi_defconfig  |2 ++
 configs/ls1043ardb_SECURE_BOOT_defconfig  |2 ++
 configs/ls1043ardb_defconfig  |2 ++
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig |2 ++
 configs/ls1043ardb_nand_defconfig |2 ++
 configs/ls1043ardb_sdcard_defconfig   |2 ++
 configs/ls1046aqds_SECURE_BOOT_defconfig  |2 ++
 configs/ls1046aqds_defconfig  |2 ++
 configs/ls1046aqds_lpuart_defconfig   |2 ++
 configs/ls1046aqds_nand_defconfig |2 ++
 configs/ls1046aqds_qspi_defconfig |2 ++
 configs/ls1046aqds_sdcard_ifc_defconfig   |2 ++
 configs/ls1046aqds_sdcard_qspi_defconfig  |2 ++
 configs/ls1046ardb_emmc_defconfig |2 ++
 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig |2 ++
 configs/ls1046ardb_qspi_defconfig |2 ++
 configs/ls1046ardb_sdcard_defconfig   |2 ++
 configs/ls1088aqds_defconfig  |2 ++
 configs/ls1088aqds_qspi_SECURE_BOOT_defconfig |2 ++
 configs/ls1088aqds_qspi_defconfig |2 ++
 configs/ls1088aqds_sdcard_ifc_defconfig   |2 ++
 configs/ls1088aqds_sdcard_qspi_defconfig  |2 ++
 configs/ls1088ardb_qspi_SECURE_BOOT_defconfig |2 ++
 configs/ls1088ardb_qspi_defconfig |2 ++
 configs/ls1088ardb_sdcard_qspi_defconfig  |2 ++
 configs/ls2080a_emu_defconfig |2 ++
 configs/ls2080a_simu_defconfig|2 ++
 configs/ls2080aqds_SECURE_BOOT_defconfig  |2 ++
 configs/ls2080aqds_defconfig  |2 ++
 configs/ls2080aqds_nand_defconfig |2 ++
 configs/ls2080aqds_qspi_defconfig |2 ++
 configs/ls2080aqds_sdcard_defconfig   |2 ++
 configs/ls2080ardb_SECURE_BOOT_defconfig  |2 ++
 configs/ls2080ardb_defconfig  |2 ++
 configs/ls2080ardb_nand_defconfig |2 ++
 configs/ls2088ardb_qspi_SECURE_BOOT_defconfig |2 ++
 configs/ls2088ardb_qspi_defconfig |2 ++
 49 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig 
b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
index 17a202d..4d85983 100644
--- a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
+++ b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
@@ -48,3 +48,5 @@ CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
diff --git a/configs/ls1021atwr_nor_defconfig b/configs/ls1021atwr_nor_defconfig
index a18426e..f4f7998 100644
--- a/configs/ls1021atwr_nor_defconfig
+++ b/configs/ls1021atwr_nor_defconfig
@@ -48,3 +48,5 @@ CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
diff --git a/configs/ls1021atwr_nor_lpuart_defconfig 
b/configs/ls1021atwr_nor_lpuart_defconfig
index 83ffa19..037f56c 100644
--- a/configs/ls1021atwr_nor_lpuart_defconfig
+++ b/configs/ls1021atwr_nor_lpuart_defconfig
@@ -49,3 +49,5 @@ CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
diff --git a/configs/ls1021atwr_qspi_defconfig 
b/configs/ls1021atwr_qspi_defconfig
index 46d8dbb..084bd27 100644
--- a/configs/ls1021atwr_qspi_defconfig
+++ b/configs/ls1021atwr_qspi_defconfig
@@ -55,3 +55,5 @@ CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig 
b/configs/ls1021atwr_sdcard_ifc_defconfig
index 14044fd..bf719f4 100644
--- a/configs/ls1021atwr_sdcard_ifc_defconfig
+++ b/configs/ls1021atwr_sdcard_ifc_defconfig
@@ -59,3 +59,5 @@ CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_BLK=y
+CONFIG_DM_MMC=y
diff --git a/configs/ls1021atwr_sdcard_qspi_defconfig 
b/configs/ls1021atwr_sdcard_qspi_defconfig
index a69dd96..cf6055e 100644
--- a/configs/ls1021atwr_sdca

Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions

2018-09-24 Thread Bin Meng
Hi Mario,

On Tue, Sep 25, 2018 at 2:24 PM Mario Six  wrote:
>
> Hi Bin,
>
> On Tue, Sep 25, 2018 at 7:48 AM Bin Meng  wrote:
> >
> > On Sat, Sep 22, 2018 at 3:55 AM Simon Glass  wrote:
> > >
> > > Hi Mario,
> > >
> > > On 21 September 2018 at 01:02, Mario Six  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Aug 17, 2018 at 2:52 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Mario,
> > > > >
> > > > > On 13 August 2018 at 00:09, Mario Six  wrote:
> > > > > > The regmap functions currently assume that all register map accesses
> > > > > > have a data width of 32 bits, but there are maps that have different
> > > > > > widths.
> > > > > >
> > > > > > To rectify this, implement the regmap_raw_read and regmap_raw_write
> > > > > > functions from the Linux kernel API that specify the width of a 
> > > > > > desired
> > > > > > read or write operation on a regmap.
> > > > > >
> > > > > > Implement the regmap_read and regmap_write functions using these raw
> > > > > > functions in a backwards-compatible manner.
> > > > > >
> > > > > > Reviewed-by: Anatolij Gustschin 
> > > > > > Signed-off-by: Mario Six 
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > v5 -> v6:
> > > > > > * Corrected format specifier
> > > > > > * Added support for 64-bit reads/writes
> > > > > >
> > > > > > v4 -> v5:
> > > > > > No changes
> > > > > >
> > > > > > v3 -> v4:
> > > > > > * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> > > > > > * Explained the difference between the raw and non-raw read/write
> > > > > >   functions better in the docs
> > > > > >
> > > > > > v2 -> v3:
> > > > > > * Implement the "raw" functions from Linux instead of adding a size
> > > > > >   parameter to the regmap_{read,write} functions
> > > > > > * Fixed style violation
> > > > > > * Improved error handling
> > > > > >
> > > > > > v1 -> v2:
> > > > > > New in v2
> > > > > >
> > > > > > ---
> > > > > >  drivers/core/regmap.c | 59 
> > > > > > +--
> > > > > >  include/regmap.h  | 58 
> > > > > > ++
> > > > > >  2 files changed, 110 insertions(+), 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> > > > > > index 154426269d9..a2f82091af0 100644
> > > > > > --- a/drivers/core/regmap.c
> > > > > > +++ b/drivers/core/regmap.c
> > > > > > @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> > > > > > return 0;
> > > > > >  }
> > > > > >
> > > > > > +int regmap_raw_read(struct regmap *map, uint offset, void *valp, 
> > > > > > size_t val_len)
> > > > > > +{
> > > > > > +   void *ptr;
> > > > > > +
> > > > > > +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> > > > > > MAP_NOCACHE);
> > > > > > +
> > > > > > +   switch (val_len) {
> > > > > > +   case REGMAP_SIZE_8:
> > > > > > +   *((u8 *)valp) = in_8((u8 *)ptr);
> > > > > > +   break;
> > > > > > +   case REGMAP_SIZE_16:
> > > > > > +   *((u16 *)valp) = in_le16((u16 *)ptr);
> > > > > > +   break;
> > > > > > +   case REGMAP_SIZE_32:
> > > > > > +   *((u32 *)valp) = in_le32((u32 *)ptr);
> > > > > > +   break;
> > > > > > +#if defined(in_le64) && defined(readq)
> > > > > > +   case REGMAP_SIZE_64:
> > > > > > +   *((u32 *)valp) = in_le64((u64 *)ptr);
> > > > >
> > > > > How come this is u32? Can you please add a comment?
> > > > >
> > > >
> > > > That was a development version of the patch, sorry (I was in a bit of a 
> > > > hurry).
> > > >
> > > > I'll send a corrected version with v7.
> > > >
> > > > > Why is this using in/out rather than read/write? Does it not support
> > > > > memory-mapped I/O?
> > > > >
> > > >
> > > > It does, but I think the endianness of the read/write operations of the 
> > > > regmap
> > > > should not depend on the architecture, but only on the regmap itself 
> > > > (which is
> > > > little-endian for now; big-endian support can be introduced later on), 
> > > > so I
> > > > used in/out rather than read/write.
> > >
> >
> > If regmap currently only supports little-endian, can we document this 
> > somewhere?
> >
> Yes, good idea. I'll send a v7 to address this.
>
> > > What does endianness have to do with whether you use readl/writel or 
> > > in/out?
> > >
> > > On x86 at least these are actually different things, so regmap() won't
> > > work on x86 with this change.
> > >
> >
> > Looks so far x86's {in,out}_{8,16,32} are using MMIO.
> >
> > > Adding Bin who may understand this better.
> >
> > BTW: I was trying to understand why we need regmap here. Shouldn't the
> > driver directly call {in,out}{bwl}, or {read,write}{bwlq} APIs?
> >
> In this version of the FPGA driver, the regmap is not strictly needed, true.
> But we also have devices that have multiple FPGAs where the "slave" FPGA's
> register maps are accessed through a custom bus interface (called MCLink) on
> the