Re: [U-Boot] [PATCH v2] mmc: sdhci: Fix MMC HS200 tuning command failures

[Masahiro Yamada]

2018-06-13 15:20 GMT+09:00 Michal Simek :
> From: Siva Durga Prasad Paladugu 
>
> This patch fixes the mmc tuning command failures
> when tuning pattern data needs to read back for
> comparision against the expected bit pattern.
>
> Reported-by: Masahiro Yamada 
> Signed-off-by: Siva Durga Prasad Paladugu 
> Signed-off-by: Michal Simek 


This one applies and works for me.

Tested-by: Masahiro Yamada 


Thanks.


> ---
>
> Changes in v2:
> - Fixed typo and added Reported-by
>
>  drivers/mmc/sdhci.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 40e28abda67f..cdeba914f95c 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -161,8 +161,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
> mmc_cmd *cmd,
> /* We shouldn't wait for data inihibit for stop commands, even
>though they might use busy signaling */
> if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION ||
> -   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> -   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
> +   ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> + cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data))
> mask &= ~SDHCI_DATA_INHIBIT;
>
> while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
> @@ -184,8 +184,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
> mmc_cmd *cmd,
> sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
>
> mask = SDHCI_INT_RESPONSE;
> -   if (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> -   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
> +   if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> +cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data)
> mask = SDHCI_INT_DATA_AVAIL;
>
> if (!(cmd->resp_type & MMC_RSP_PRESENT))
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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

Re: [U-Boot] sun50i: h5: Add initial Orange Pi Zero Plus support

[Maxime Ripard]

On Sat, Jun 09, 2018 at 06:34:46PM +0200, Hauke Mehrtens wrote:
> Orange Pi Zero Plus is an open-source single-board computer
> using the Allwinner H5 SOC.
> 
> H5 Orangepi Zero Plus has
>  - Quad-core Cortex-A53
>  - 512MB DDR3
>  - micrSD slot
>  - 16MBit SPI Nor flash
>  - Debug TTL UART
>  - 1GBit/s Ethernet (RTL8211E)
>  - Wifi (RTL8189FTV)
>  - USB 2.0 Host
>  - USB 2.0 OTG + power supply
> 
> The device tree file is copied from the Linux kernel 4.17.
> 
> Signed-off-by: Hauke Mehrtens 

Acked-by: Maxime Ripard 

Maxime

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


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

Re: [U-Boot] sun8i: h2: Add initial Orange Pi R1 support

[Maxime Ripard]

On Sat, Jun 09, 2018 at 06:33:37PM +0200, Hauke Mehrtens wrote:
> Orange Pi R1 is an open-source single-board computer using the
> Allwinner H2+ SOC.
> 
> H2+ Orange Pi R1 has
>  - Quad-core Cortex-A7
>  - 256MB DDR3
>  - micrSD slot
>  - 128MBit SPI Nor flash
>  - Debug TTL UART
>  - 100MBit/s Ethernet (H2+)
>  - 100MBit/s Ethernet (RTL8152B)
>  - Wifi (RTL8189ETV)
>  - USB 2.0 OTG + power supply
> This board is very similar to the Orange Pi Zero.
> 
> The device tree file is copied from the Linux kernel 4.17.
> 
> Signed-off-by: Hauke Mehrtens 

Acked-by: Maxime Ripard 

Maxime

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


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

Re: [U-Boot] [PATCH v4 4/4] tools: zynqmpimage: Add bif support

[Peter Robinson]

 Michael or Alex,

Could someone add a ZynqMP README documenting the process required to
use U-Boot for the ZynqMP with the open tools? I looked in
board/xilinx/zynqmp and doc/ and a few other places but couldn't see
any docs for either that or the closed tools.

Peter

On Fri, Apr 13, 2018 at 1:18 PM, Alexander Graf  wrote:
> The officially described way to generate boot.bin files for ZynqMP is to
> describe the contents of the target binary using a file of the "bif"
> format.  This file then links to other files that all get packed into a
> bootable image.
>
> This patch adds support to read such a .bif file and generate a respective
> ZynqMP boot.bin file that can include the normal image and pmu files, but
> also supports image partitions now. This makes it a handy replacement for
> the proprietary "bootgen" utility that is currently used to generate
> boot.bin files with FSBL.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v2 -> v3:
>
>   - zero initialize header
>   - reduce default debug verbosity
>
> v3 -> v4:
>
>   - add error handling
>   - add fsbl_config support
>   - add aarch32 support
>   - allow a5x to be written as a53
>   - add offset support
>   - add support for partition_owner
>   - ensure pmufw comes before bootloader
>   - simplify fsbl_config
>   - add non-a53 boot support
>   - checkpatch fixes
> ---
>  common/image.c  |1 +
>  include/image.h |1 +
>  tools/Makefile  |1 +
>  tools/imagetool.h   |1 +
>  tools/mkimage.c |7 +
>  tools/zynqmpbif.c   | 1008 
> +++
>  tools/zynqmpimage.c |4 +-
>  tools/zynqmpimage.h |7 +
>  8 files changed, 1028 insertions(+), 2 deletions(-)
>  create mode 100644 tools/zynqmpbif.c
>
> diff --git a/common/image.c b/common/image.c
> index e1c50eb25d..f30dfa229b 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -159,6 +159,7 @@ static const table_entry_t uimage_type[] = {
> {   IH_TYPE_VYBRIDIMAGE, "vybridimage",  "Vybrid Boot Image", },
> {   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
> {   IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot 
> Image" },
> +   {   IH_TYPE_ZYNQMPBIF,  "zynqmpbif",  "Xilinx ZynqMP Boot Image 
> (bif)" },
> {   IH_TYPE_FPGA,   "fpga",   "FPGA Image" },
> {   IH_TYPE_TEE,"tee","Trusted Execution 
> Environment Image",},
> {   IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 
> IVT" },
> diff --git a/include/image.h b/include/image.h
> index a579c5f509..c5af912aeb 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -269,6 +269,7 @@ enum {
> IH_TYPE_RKSPI,  /* Rockchip SPI image   */
> IH_TYPE_ZYNQIMAGE,  /* Xilinx Zynq Boot Image */
> IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
> +   IH_TYPE_ZYNQMPBIF,  /* Xilinx ZynqMP Boot Image (bif) */
> IH_TYPE_FPGA,   /* FPGA Image */
> IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
> IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
> diff --git a/tools/Makefile b/tools/Makefile
> index 8143c25666..204685ec9e 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -113,6 +113,7 @@ dumpimage-mkimage-objs := aisimage.o \
> ublimage.o \
> zynqimage.o \
> zynqmpimage.o \
> +   zynqmpbif.o \
> $(LIBFDT_OBJS) \
> gpimage.o \
> gpimage-common.o \
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index e67de9b5ad..6a7e7386f7 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -232,6 +232,7 @@ time_t imagetool_get_source_date(
>
>
>  void pbl_load_uboot(int fd, struct image_tool_params *mparams);
> +int zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
>
>  #define ___cat(a, b) a ## b
>  #define __cat(a, b) ___cat(a, b)
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 4e561820e7..fe861f5405 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -514,6 +514,13 @@ int main(int argc, char **argv)
> } else if (params.type == IH_TYPE_PBLIMAGE) {
> /* PBL has special Image format, implements its' own 
> */
> pbl_load_uboot(ifd, );
> +   } else if (params.type == IH_TYPE_ZYNQMPBIF) {
> +   /* Image file is meta, walk through actual targets */
> +   int ret;
> +
> +   ret = zynqmpbif_copy_image(ifd, );
> +   if (ret)
> +   return ret;
> } else {
> copy_file(ifd, params.datafile, pad_len);
> }
> diff --git a/tools/zynqmpbif.c b/tools/zynqmpbif.c
> new file mode 100644
> 

Re: [U-Boot] [PATCH V4 1/2] ARM: image: Add option for ignoring ep bit 3

[Bin Chen]

On 13 June 2018 at 14:13, Marek Vasut  wrote:

> Add option to the booti_setup() which indicates to it that the caller
> requires the image to be relocated to the beginning of the RAM and
> that the information whether the image can be located anywhere in RAM
> at 2 MiB aligned boundary or not is to be ignored. This is useful ie.
> in case the Image is wrapped in another envelope, ie. fitImage and not
> relocating it but moving it would corrupt the envelope.
>
> Signed-off-by: Marek Vasut 
> Cc: Bin Chen 
> Cc: Masahiro Yamada 
> Cc: Tom Rini 
> ---
> V2: Rename ignore_ep to force_reloc
> V3: No change
> V4: - Add stdbool.h include
> - Switch force_reloc to bool
> ---
>  arch/arm/lib/image.c | 5 +++--
>  cmd/booti.c  | 2 +-
>  include/image.h  | 5 -
>  3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/lib/image.c b/arch/arm/lib/image.c
> index 1a04e2b875..699bf44e70 100644
> --- a/arch/arm/lib/image.c
> +++ b/arch/arm/lib/image.c
> @@ -26,7 +26,8 @@ struct Image_header {
> uint32_tres5;
>  };
>
> -int booti_setup(ulong image, ulong *relocated_addr, ulong *size)
> +int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
> +   bool force_reloc)
>  {
> struct Image_header *ih;
> uint64_t dst;
> @@ -63,7 +64,7 @@ int booti_setup(ulong image, ulong *relocated_addr,
> ulong *size)
>  * images->ep.  Otherwise, relocate the image to the base of RAM
>  * since memory below it is not accessible via the linear mapping.
>  */
> -   if (le64_to_cpu(ih->flags) & BIT(3))
> +   if (!force_reloc && (le64_to_cpu(ih->flags) & BIT(3)))
> dst = image - text_offset;
> else
> dst = gd->bd->bi_dram[0].start;
> diff --git a/cmd/booti.c b/cmd/booti.c
> index 45fbb99b68..04353b68ec 100644
> --- a/cmd/booti.c
> +++ b/cmd/booti.c
> @@ -37,7 +37,7 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int
> argc,
> debug("*  kernel: cmdline image address = 0x%08lx\n", ld);
> }
>
> -   ret = booti_setup(ld, _addr, _size);
> +   ret = booti_setup(ld, _addr, _size, false);
> if (ret != 0)
> return 1;
>
> diff --git a/include/image.h b/include/image.h
> index 95d5934344..420b8ff576 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -17,6 +17,7 @@
>
>  #include "compiler.h"
>  #include 
> +#include 
>
>  /* Define this to avoid #ifdefs later on */
>  struct lmb;
> @@ -881,9 +882,11 @@ int bootz_setup(ulong image, ulong *start, ulong
> *end);
>   * @image: Address of image
>   * @start: Returns start address of image
>   * @size : Returns size image
> + * @force_reloc: Ignore image->ep field, always place image to RAM start
>   * @return 0 if OK, 1 if the image was not recognised
>   */
> -int booti_setup(ulong image, ulong *relocated_addr, ulong *size);
> +int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
> +   bool force_reloc);
>
>  /***/
>  /* New uImage format specific code (prefixed with fit_) */
>

Reviewed-By: Bin Chen 


> --
> 2.17.1
>
>


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

Re: [U-Boot] [PATCH v2 1/4] core: Add functions to set properties in live-tree

[Mario Six]

Hi Simon,

On Fri, May 4, 2018 at 11:37 PM, Simon Glass  wrote:
> Hi Mario,
>
> On 4 May 2018 at 01:14, Mario Six  wrote:
>> Hi Simon,
>>
>> On Tue, May 1, 2018 at 1:13 AM, Simon Glass  wrote:
>>> Hi Mario,
>>>
>>> On 27 April 2018 at 06:51, Mario Six  wrote:

 Implement a set of functions to manipulate properties in a live device
 tree:

 * ofnode_set_property() to set generic properties of a node
 * ofnode_write_string() to set string properties of a node
 * ofnode_set_enabled() to either enable or disable a node

 Signed-off-by: Mario Six 

 ---

 v1 -> v2:
 * Fix potential NULL pointer dereference in ofnode_write_property

 ---
  drivers/core/ofnode.c | 58
> +++
  include/dm/ofnode.h   | 37 
  2 files changed, 95 insertions(+)
>>>
>>> Reviewed-by: Simon Glass 
>>>
>>> But please see below.
>>>

 diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
 index 5909a25f85..a55aa75e5b 100644
 --- a/drivers/core/ofnode.c
 +++ b/drivers/core/ofnode.c
 @@ -687,3 +687,61 @@ u64 ofnode_translate_address(ofnode node, const
> fdt32_t *in_addr)
 else
 return fdt_translate_address(gd->fdt_blob,
> ofnode_to_offset(node), in_addr);
  }
 +
 +#ifdef CONFIG_OF_LIVE
 +int ofnode_write_property(ofnode node, const char *propname, int len,
 + const void *value)
 +{
 +   const struct device_node *np = ofnode_to_np(node);
 +   struct property *pp;
 +   struct property *pp_last = NULL;
 +   struct property *new;
 +
 +   if (!np)
 +   return -EINVAL;
 +
 +   for (pp = np->properties; pp; pp = pp->next) {
 +   if (strcmp(pp->name, propname) == 0) {
 +   /* Property exists -> change value */
 +   pp->value = (void *)value;
 +   pp->length = len;
 +   return 0;
 +   }
 +   pp_last = pp;
 +   }
 +
 +   if (!pp_last)
 +   return -ENOENT;
 +
 +   /* Property does not exist -> append new property */
 +   new = malloc(sizeof(struct property));
 +
 +   new->name = strdup(propname);
 +   new->value = malloc(len);
 +   memcpy(new->value, value, len);
>>>
>>> To me it seems odd that you allocate space for the value here, but
>>> above (in the loop) you just assign it.
>>>
>>
>> Right, just the pointer in the property itself is allocated; just
> assigning the
>> pointer to the property value with the one passed in might lead to it
> being
>> deallocated.
>
> Who will ever deallocate it? To me these cases are the same and I can't see
> why an existing property should be simply assigned, but a new property must
> be allocated. At the very lease that seems like a confusing thing to
> explain in the function comment you're going to add :-)
>
>>
>> Unfortunately a "free and malloc" or "realloc" won't work, since the
> unflatten
>> procedure in lib/of_live.c allocates the memory for the whole device tree
> as
>> one chunk, which cannot be partially freed. So the only choice would
> either be
>> only a "malloc" without prior freeing (which would leak memory if the
> property
>> is set multiple times), or require that the property value passed in is
> valid
>> forever (i.e. the caller has to malloc it himself), which would make the
>> interface more complicated to use, and also pushes the responsibility of
>> freeing the value onto the caller, who probably cannot safely decide when
> to
>> free it anyway.
>>
>> Another idea would be to find out the size of the unflattened device
> tree; that
>> way one could decide whether the property value pointer points into the
>> allocated memory for the tree (in that case, just allocate a new
> property), or
>> if it points into a different memory region, which would indicate that the
>> property was changed before already (in that case, free and allocate new
>> property or reallocate). I don't know how complicated that would be,
> though.
>> I'll investigate.
>
> Hmm, I think just documenting behaviour clearly is good enough. How about
> we don't allocate the memory here. The caller can do it if necessary.
>

OK, should not be too difficult. I'll use that approach for v3.

> Regards,
> Simon
>

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

[U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB

[tien . fong . chee]

From: Tien Fong Chee 

In ARM 64-bits, memory size can be supported is more than 4GB,
hence increasing save array is needed to cope with testing larger memory.

Signed-off-by: Tien Fong Chee 
---
 common/memsize.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/memsize.c b/common/memsize.c
index 5670e95..b091203 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
 long get_ram_size(long *base, long maxsize)
 {
volatile long *addr;
-   long   save[31];
+   long   save[BITS_PER_LONG];
long   save_base;
long   cnt;
long   val;
-- 
1.7.7.4

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

[U-Boot] [PATCH] arm64: zynqmp: Check return value from calloc

[Michal Simek]

calloc() can fail and return NULL. The patch is checking return value
and return in case of error.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 3e8edb81109a..68a0964477e0 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -624,6 +624,8 @@ int board_late_init(void)
 
new_targets = calloc(1, strlen(mode) + env_targets_len + 2 +
 bootseq_len);
+   if (!new_targets)
+   return -ENOMEM;
 
if (bootseq >= 0)
sprintf(new_targets, "%s%x %s", mode, bootseq,
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 4/5] lib: Import hexdump.c from Linux

[Mario Six]

Hi Alexey,

On Mon, Jun 4, 2018 at 6:05 PM, Alexey Brodkin
 wrote:
> Hi Mario,
>
> On Wed, 2018-05-23 at 14:09 +0200, Mario Six wrote:
>> Especially for commands, it is useful to be able to turn a hexadecimal
>> string into its binary representation.
>>
>> Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the
>> Linux kernel.
>>
>> Signed-off-by: Mario Six 
>>
>> ---
>>
>> v1 -> v2:
>> New in v2
>
> Something is missing?
>
> Note there was a similar discussion some time ago here:
> https://patchwork.ozlabs.org/patch/633733/, might worth checking.
>
> If of any interest you may pick up my earlier patch and do
> fix-ups mentioned by Tom:
>  1. Move hexdump.h away from common.h
>  2. Update existing users of print_hex_dump() in U-Boot
> such that they don't use debug level (i.e. drop the first argument)
>
> Or I may do the same re-spin sometime soon.
>

Thanks for your feedback! I saw that you posted a re-spin of your patch;
Thank you, that's very helpful.

> Still read-on for a couple of comments for your patch.
>
> [snip]
>
>>  /*
>>   * min()/max()/clamp() macros that also do
>>   * strict type-checking.. See the
>> diff --git a/lib/Makefile b/lib/Makefile
>> index d531ea54b31..0f6d744579f 100644
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@ -29,6 +29,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o
>>  obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
>>  obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
>>  obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o
>> +obj-y += hexdump.o
>
> U-Boot might be used on targets with limited memory
> so having ability to include hexdump or not might be
> beneficial here. Especially in production builds why would you need hexdump?
>

Yes, it's probably better to have it deactivatable, true. But as for why
production builds need hexdump: It's not so much the hexdump function, but the
bin2hex function, which can be used in a number of U-Boot commands that read
hexadecimal data. We use one such command to initialize a TPM on one of our
boards, for example.

> [snip]
>
>> +#ifdef CONFIG_PRINTK
>
> Why PRINTK in U-Boot? It's purely kernel's thing.
>
>> +#if !defined(CONFIG_DYNAMIC_DEBUG)
>
> Ditto, CONFIG_DYNAMIC_DEBUG has nothing to do with U-Boot.
>

Those were copied verbatim from the kernel, I'm pretty sure I just got them by
mistake.

> -Alexey
>

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

Re: [U-Boot] [PATCH 1/2] net: Add option to prefer bootp/dhcp serverip

[Rick Chen]

2018-06-13 9:42 GMT+08:00 Rick Chen :
> 2018-06-13 3:59 GMT+08:00 Joe Hershberger :
>> On Wed, Jun 6, 2018 at 8:54 PM, Rick Chen  wrote:
 From: Alexander Graf [mailto:ag...@suse.de]
 Sent: Wednesday, June 06, 2018 8:32 PM
 To: u-boot@lists.denx.de
 Cc: Rick Jian-Zhi Chen(陳建志); Joe Hershberger; Simon Glass
 Subject: [PATCH 1/2] net: Add option to prefer bootp/dhcp serverip

 Currently we can choose between 2 different types of behavior for the 
 serverip
 variable:

   1) Always overwrite it with the DHCP server IP address (default)
   2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP)

 This patch adds a 3rd option:

   3) Use serverip from DHCP if no serverip is given
  (CONFIG_BOOTP_PREFER_SERVERIP)

 With this new option, we can have the default case that a boot file gets 
 loaded
 from the DHCP provided TFTP server work while allowing users to specify 
 their
 own serverip variable to explicitly use a different tftp server.

 Signed-off-by: Alexander Graf 
 ---
  README  | 5 +
  cmd/Kconfig | 9 +
  net/bootp.c | 7 ++-
  3 files changed, 20 insertions(+), 1 deletion(-)

 diff --git a/README b/README
 index fb331f910d..d8a99281ca 100644
 --- a/README
 +++ b/README
 @@ -1511,10 +1511,15 @@ The following options need to be configured:
   CONFIG_BOOTP_TIMEOFFSET
   CONFIG_BOOTP_VENDOREX
   CONFIG_BOOTP_MAY_FAIL
 + CONFIG_BOOTP_PREFER_SERVERIP

   CONFIG_BOOTP_SERVERIP - TFTP server will be the serverip
   environment variable, not the BOOTP server.

 + CONFIG_BOOTP_PREFER_SERVERIP - TFTP server will be the
 + serverip environment variable if previously unset, otherwise
 + the DHCP provided serverip is used.
 +
   CONFIG_BOOTP_MAY_FAIL - If the DHCP server is not found
   after the configured retry count, the call will fail
   instead of starting over.  This can be used to fail over 
 diff --git
 a/cmd/Kconfig b/cmd/Kconfig index e283cb9a8a..e77a4131b3 100644
 --- a/cmd/Kconfig
 +++ b/cmd/Kconfig
 @@ -1121,6 +1121,15 @@ config BOOTP_HOSTNAME
   help
 The name may or may not be qualified with the local domain name.

 +config BOOTP_PREFER_SERVERIP
 + bool "Leave serverip variable in place if existing"
 + default n
 + depends on CMD_BOOTP
 + help
 +   By default a BOOTP/DHCP reply will overwrite the tftp target ip
 +   address. With this option enabled, it will leave it alone if
 +   already specified, but populate it if no serverip is specified.
 +
  config BOOTP_SUBNETMASK
   bool "Request & store 'netmask' from BOOTP/DHCP server"
   default y
 diff --git a/net/bootp.c b/net/bootp.c
 index 9d7cb5d30c..91de4cd426 100644
 --- a/net/bootp.c
 +++ b/net/bootp.c
 @@ -147,9 +147,14 @@ static void store_net_params(struct bootp_hdr *bp)
 {  #if !defined(CONFIG_BOOTP_SERVERIP)
   struct in_addr tmp_ip;
 + bool overwrite_serverip = true;
 +
 +#if defined(CONFIG_BOOTP_PREFER_SERVERIP)
 + overwrite_serverip = false;
 +#endif

   net_copy_ip(_ip, >bp_siaddr);
 - if (tmp_ip.s_addr != 0)
 + if (tmp_ip.s_addr != 0 && (overwrite_serverip ||
 +!net_server_ip.s_addr))
   net_copy_ip(_server_ip, >bp_siaddr);
   memcpy(net_server_ethaddr,
  ((struct ethernet_hdr *)net_rx_packet)->et_src, 6);
 --
 2.12.3
>>>
>>> Hi Alex
>>>
>>> I have apply those two patchs and verify
>>> U-Boot-1-2-net-Add-option-to-prefer-bootp-dhcp-serverip.patch
>>> U-Boot-2-2-ax25-Switch-to-CONFIG_BOOTP_PREFER_SERVERIP.patch
>>>
>>> But it still fail in dhcp command as below
>>>
>>> case 1
>>> serverip is null
>>>
>>> RISC-V # set serverip
>>> RISC-V # env print
>>> baudrate=38400
>>> bootcmd=fatload mmc 0:1 0x2000 ae350_64.dtb;fatload mmc 0:1 0x0
>>> bbl-ae350.bin;go 0x0
>>> bootdelay=3
>>> bootfile=pxelinux.0
>>> ethact=mac@e010
>>> fdtcontroladdr=3fedf290
>>> fileaddr=60
>>> filesize=1bb7d34
>>> stderr=serial@f030
>>> stdin=serial@f030
>>> stdout=serial@f030
>>>
>>> Environment size: 304/8188 bytes
>>> RISC-V # dhcp 0x60 10.0.4.97:boomimage-310y-ag101p.bin
>>
>> You are explicitly setting the server IP in the DHCP command line, so
>> why would you expect the DHCP server IP to be used?
>>
>>> BOOTP broadcast 1
>>> BOOTP broadcast 2
>>> BOOTP broadcast 3
>>> BOOTP broadcast 4
>>> DHCP client bound to address 10.0.4.191 (4603 ms)
>>> Using mac@e010 device
>>> TFTP from server 255.255.255.255; our IP address is 10.0.4.191;
>>
>> This broadcast address is clearly not right. It should have been 

Re: [U-Boot] [PATCH v4 4/4] tools: zynqmpimage: Add bif support

[Alexander Graf]

Hi Peter,

I'm not sure how much documentation you want. Basically mkimage becomes
a replacement for bootgen in any official Xilinx documentation. So any
Xilinx wiki like

  http://www.wiki.xilinx.com/Prepare+boot+image

or even the official .bif documentation:


https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf

apply. The only difference is that the command line arguments are
different. But mkimage takes a .bif file as input and generates a
boot.bin file as output.


Alex

On 13.06.18 08:49, Peter Robinson wrote:
>  Michael or Alex,
> 
> Could someone add a ZynqMP README documenting the process required to
> use U-Boot for the ZynqMP with the open tools? I looked in
> board/xilinx/zynqmp and doc/ and a few other places but couldn't see
> any docs for either that or the closed tools.
> 
> Peter
> 
> On Fri, Apr 13, 2018 at 1:18 PM, Alexander Graf  wrote:
>> The officially described way to generate boot.bin files for ZynqMP is to
>> describe the contents of the target binary using a file of the "bif"
>> format.  This file then links to other files that all get packed into a
>> bootable image.
>>
>> This patch adds support to read such a .bif file and generate a respective
>> ZynqMP boot.bin file that can include the normal image and pmu files, but
>> also supports image partitions now. This makes it a handy replacement for
>> the proprietary "bootgen" utility that is currently used to generate
>> boot.bin files with FSBL.
>>
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> v2 -> v3:
>>
>>   - zero initialize header
>>   - reduce default debug verbosity
>>
>> v3 -> v4:
>>
>>   - add error handling
>>   - add fsbl_config support
>>   - add aarch32 support
>>   - allow a5x to be written as a53
>>   - add offset support
>>   - add support for partition_owner
>>   - ensure pmufw comes before bootloader
>>   - simplify fsbl_config
>>   - add non-a53 boot support
>>   - checkpatch fixes
>> ---
>>  common/image.c  |1 +
>>  include/image.h |1 +
>>  tools/Makefile  |1 +
>>  tools/imagetool.h   |1 +
>>  tools/mkimage.c |7 +
>>  tools/zynqmpbif.c   | 1008 
>> +++
>>  tools/zynqmpimage.c |4 +-
>>  tools/zynqmpimage.h |7 +
>>  8 files changed, 1028 insertions(+), 2 deletions(-)
>>  create mode 100644 tools/zynqmpbif.c
>>
>> diff --git a/common/image.c b/common/image.c
>> index e1c50eb25d..f30dfa229b 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -159,6 +159,7 @@ static const table_entry_t uimage_type[] = {
>> {   IH_TYPE_VYBRIDIMAGE, "vybridimage",  "Vybrid Boot Image", },
>> {   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
>> {   IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot 
>> Image" },
>> +   {   IH_TYPE_ZYNQMPBIF,  "zynqmpbif",  "Xilinx ZynqMP Boot Image 
>> (bif)" },
>> {   IH_TYPE_FPGA,   "fpga",   "FPGA Image" },
>> {   IH_TYPE_TEE,"tee","Trusted Execution 
>> Environment Image",},
>> {   IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 
>> IVT" },
>> diff --git a/include/image.h b/include/image.h
>> index a579c5f509..c5af912aeb 100644
>> --- a/include/image.h
>> +++ b/include/image.h
>> @@ -269,6 +269,7 @@ enum {
>> IH_TYPE_RKSPI,  /* Rockchip SPI image   */
>> IH_TYPE_ZYNQIMAGE,  /* Xilinx Zynq Boot Image */
>> IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
>> +   IH_TYPE_ZYNQMPBIF,  /* Xilinx ZynqMP Boot Image (bif) */
>> IH_TYPE_FPGA,   /* FPGA Image */
>> IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
>> IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
>> diff --git a/tools/Makefile b/tools/Makefile
>> index 8143c25666..204685ec9e 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -113,6 +113,7 @@ dumpimage-mkimage-objs := aisimage.o \
>> ublimage.o \
>> zynqimage.o \
>> zynqmpimage.o \
>> +   zynqmpbif.o \
>> $(LIBFDT_OBJS) \
>> gpimage.o \
>> gpimage-common.o \
>> diff --git a/tools/imagetool.h b/tools/imagetool.h
>> index e67de9b5ad..6a7e7386f7 100644
>> --- a/tools/imagetool.h
>> +++ b/tools/imagetool.h
>> @@ -232,6 +232,7 @@ time_t imagetool_get_source_date(
>>
>>
>>  void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>> +int zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
>>
>>  #define ___cat(a, b) a ## b
>>  #define __cat(a, b) ___cat(a, b)
>> diff --git a/tools/mkimage.c b/tools/mkimage.c
>> index 4e561820e7..fe861f5405 100644
>> --- a/tools/mkimage.c
>> +++ b/tools/mkimage.c
>> @@ -514,6 +514,13 @@ int main(int argc, char **argv)
>> } else if 

Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Russell King - ARM Linux]

On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> On 21:40-20180612, Russell King - ARM Linux wrote:
> [...]
> > > I started respinning the series, while there is definitely a use of
> > > implementing in u-boot,
> > > I am starting to wonder if we should also be doing this in kernel.
> > 
> > How does the kernel set the bit when the kernel is running in non-secure
> > mode, when the ACTLR is read-only in that mode?
> 
> For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> it:
> https://patchwork.kernel.org/patch/10461273/
> 
> This'd be similar in implementation to ARM erratum 801819 workaround
> that needs two pieces (u-boot + kernel). I am not really worried about
> OMAP5/DRA7 since they should'nt loose context in Low power modes.
> Other SoCs need to be aware of the constraints.
> 
> /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> legacy v7 SoCs have implementations that are kind of different (even
> smc calling conventions vary).

It may seem to be an easy way out (do everything in the kernel) but
have you considered that the secure world is also vulnerable?

If the IBE bit is not set in the secure world, then the secure world
is not implementing the workarounds, and therefore the non-secure
world has the possibility to use the Spectre vulnerabilities to
exploit the secure world with enough effort and knowledge.

You really need to _also_ fix these vulnerabilities in the secure
world, which includes setting the IBE bit there.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V4 2/2] bootm: Handle kernel_noload on arm64

[Bin Chen]

On 13 June 2018 at 14:13, Marek Vasut  wrote:

> The ARM64 has 2 MiB alignment requirement for the kernel. When using
> fitImage, this requirement may by violated, the kernel will thus be
> executed from unaligned address and fail to boot. Do what booti does
> and run booti_setup() for kernel_noload images on arm64 to obtain a
> suitable aligned address to which the image shall be relocated.
>
> Signed-off-by: Marek Vasut 
> Cc: Bin Chen 
> Cc: Masahiro Yamada 
> Cc: Tom Rini 
> ---
> V2: Protect the ARM64 booti bit with if IS_ENABLED(CMD_BOOTI)
> V3: Use if() instead of #ifdef
> V4: Switch force_reloc to bool
> ---
>  common/bootm.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f6818a..e517d9f118 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -202,8 +202,23 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag,
> int argc,
> }
>
> if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
> -   images.os.load = images.os.image_start;
> -   images.ep += images.os.load;
> +   if (CONFIG_IS_ENABLED(CMD_BOOTI) &&
> +   images.os.arch == IH_ARCH_ARM64) {
> +   ulong image_addr;
> +   ulong image_size;
> +
> +   ret = booti_setup(images.os.image_start,
> _addr,
> + _size, true);
>

Is it guaranteed to be conflict free (with other images) by always moving
the kernel to the start of the RAM?



> +   if (ret != 0)
> +   return 1;
>

Do you think it helps to add some debug/error message here as in other path
that returns 1?


> +
> +   images.os.type = IH_TYPE_KERNEL;
> +   images.os.load = image_addr;
> +   images.ep = image_addr;
> +   } else {
> +   images.os.load = images.os.image_start;
> +   images.ep += images.os.image_start;
>

I know this is same the orinigal code. I'm not famaliar the history/purpse
of type
IH_TYPE_KERNEL_NOLOAD (compared with IH_TYPE_KERNEL), so just for my
understanding,
why in this case we have to increment the images.ep by images.os.load, not
just set images.ep to
images.os.load.


+   }
> }
>
> images.os.start = map_to_sysmem(os_hdr);
> --
> 2.17.1
>
>


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

[U-Boot] [PATCH] net: zynq_gem: Fix return type for phy...()

[Michal Simek]

wait_for_bit_le32 returns negative value on failure. Fix phy...() to
handle these failures properly.

Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index a218c92314bc..d1436807ffb9 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -185,7 +185,7 @@ struct zynq_gem_priv {
bool int_pcs;
 };
 
-static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
+static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
u32 op, u16 *data)
 {
u32 mgtcr;
@@ -216,10 +216,10 @@ static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 
phy_addr, u32 regnum,
return 0;
 }
 
-static u32 phyread(struct zynq_gem_priv *priv, u32 phy_addr,
+static int phyread(struct zynq_gem_priv *priv, u32 phy_addr,
   u32 regnum, u16 *val)
 {
-   u32 ret;
+   int ret;
 
ret = phy_setup_op(priv, phy_addr, regnum,
   ZYNQ_GEM_PHYMNTNC_OP_R_MASK, val);
@@ -231,7 +231,7 @@ static u32 phyread(struct zynq_gem_priv *priv, u32 phy_addr,
return ret;
 }
 
-static u32 phywrite(struct zynq_gem_priv *priv, u32 phy_addr,
+static int phywrite(struct zynq_gem_priv *priv, u32 phy_addr,
u32 regnum, u16 data)
 {
debug("%s: phy_addr %d, regnum 0x%x, data 0x%x\n", __func__, phy_addr,
-- 
1.9.1

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

[U-Boot] [PATCH] arm64: zynqmp: Check return value in zynqmp_mmio_rawwrite()

[Michal Simek]

There should be return value check from zynqmp_mmio_read() in
zynqmp_mmio_rawwrite() to make sure that errors are propagated properly.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index e122be59c747..1279dc8658a1 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -212,8 +212,12 @@ static int zynqmp_mmio_rawwrite(const u32 address,
 {
u32 data;
u32 value_local = value;
+   int ret;
+
+   ret = zynqmp_mmio_read(address, );
+   if (ret)
+   return ret;
 
-   zynqmp_mmio_read(address, );
data &= ~mask;
value_local &= mask;
value_local |= data;
-- 
1.9.1

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

[U-Boot] [PATCH] gpio: zynq: Do not check unsigned type that is >= 0

[Michal Simek]

There is no reason to check that unsigned type that is >= 0.

Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index 4cb75a862780..804ddbd4983b 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -189,7 +189,7 @@ static int gpio_is_valid(unsigned gpio, struct udevice *dev)
 {
struct zynq_gpio_privdata *priv = dev_get_priv(dev);
 
-   return (gpio >= 0) && (gpio < priv->p_data->ngpio);
+   return gpio < priv->p_data->ngpio;
 }
 
 static int check_gpio(unsigned gpio, struct udevice *dev)
-- 
1.9.1

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

[U-Boot] [PATCH] mmc: zynq: Fix tuning_loop_counter type in arasan_sdhci_execute_tuning()

[Michal Simek]

Code around tuning_loop_counter variable expects to go below zero.
That's why this variable can't use unsigned type.

Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 86e478523c44..32d626793cd4 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -92,7 +92,7 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 
opcode)
u32 ctrl;
struct sdhci_host *host;
struct arasan_sdhci_priv *priv = dev_get_priv(mmc->dev);
-   u8 tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT;
+   char tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT;
u8 deviceid;
 
debug("%s\n", __func__);
-- 
1.9.1

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

[U-Boot] [PATCH v2] mmc: sdhci: Fix MMC HS200 tuning command failures

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch fixes the mmc tuning command failures
when tuning pattern data needs to read back for
comparision against the expected bit pattern.

Reported-by: Masahiro Yamada 
Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

Changes in v2:
- Fixed typo and added Reported-by

 drivers/mmc/sdhci.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 40e28abda67f..cdeba914f95c 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -161,8 +161,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
/* We shouldn't wait for data inihibit for stop commands, even
   though they might use busy signaling */
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION ||
-   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
-   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
+   ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
+ cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data))
mask &= ~SDHCI_DATA_INHIBIT;
 
while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
@@ -184,8 +184,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
 
mask = SDHCI_INT_RESPONSE;
-   if (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
-   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
+   if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
+cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data)
mask = SDHCI_INT_DATA_AVAIL;
 
if (!(cmd->resp_type & MMC_RSP_PRESENT))
-- 
1.9.1

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

[U-Boot] [PATCH] net: zynq_gem: Initialize phyreg variable

[Michal Simek]

In case of phyread()/phy_setup_op() timeout code is working with
uninitialized phyreg variable. Initialize this variable to make sure
that code it not working with random value.

Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index d1436807ffb9..14564e365e6e 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -244,7 +244,7 @@ static int phywrite(struct zynq_gem_priv *priv, u32 
phy_addr,
 static int phy_detection(struct udevice *dev)
 {
int i;
-   u16 phyreg;
+   u16 phyreg = 0;
struct zynq_gem_priv *priv = dev->priv;
 
if (priv->phyaddr != -1) {
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 1/3] misc: docs: Fix comments in misc.h

[Mario Six]

Hi Simon,

On Wed, May 30, 2018 at 9:18 PM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 May 2018 at 07:01, Mario Six  wrote:
>> Hi Simon,
>>
>> On Fri, May 25, 2018 at 4:41 AM, Simon Glass  wrote:
>>> +Marex
>>>
>>> Hi Mario,
>>>
>>> On 23 May 2018 at 08:07, Mario Six  wrote:
 The comments in misc.h are not in kernel-doc format. Correct the format.

 Signed-off-by: Mario Six 

 ---

 v2 -> v3:
 New in v3

 ---
  include/misc.h | 66 
 +++---
  1 file changed, 35 insertions(+), 31 deletions(-)

>>>
>>> Not another format?! I have been following what I thought was docbook
>>> format as proposed by Marek a few years ago.
>>>
>>
>> Well, others seem to think different. Michal pointed out in [1] that the
>> comments were very close to kerneldoc, but not quiet, and proposed to change
>> the format to make them comply. This seems reasonable, since the kerneldoc
>> utility is in the tree after all.
>>
>> As for the docbook format: That was imported from the Linux kernel, and the
>> kernel guys subsequently abandoned the docbook format in favor of 
>> Sphinx-based
>> documentation. So, you could argue that the docbook format is obsolete (also,
>> from what I see there were only ever two docbook documents written in U-Boot,
>> so the success was limited).
>>
>> But that's actually a good question: Is there a preferred or even mandatory 
>> doc
>> format in use? If that's the case, it would certainly be nice if it was
>> documented somewhere (or even if there was an automated linter akin to
>> kerneldoc, for example).
>>
>> [1] http://patchwork.ozlabs.org/patch/905733/#1902178
>
> OK how about adding it to the README then? Also the DocBook scripts
> need to be updated I think.
>

The best way to update the DocBook scripts would probably be to pull in the
sphinx-based scripts, and migrate the DocBook files to sphinx. I'll check how
complicated that would be.

> Regards,
> Simon
>

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

[U-Boot] [PATCH] common: Fix cpu nr type which is always unsigned type

[Michal Simek]

cpu_cmd() is reading cpu number via simple_strtoul() which is always
unsigned type.
Platform code implementations are not expecting that nr can be negative
and there is not checking in the code for that too.

This patch is using u32 type for cpu number to make sure that platform
code get proper value range.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/fsl-layerscape/mp.c |  8 
 arch/arm/cpu/armv8/zynqmp/mp.c |  8 
 arch/arm/mach-imx/mx6/mp.c |  8 
 arch/powerpc/cpu/mpc85xx/mp.c  | 10 +-
 arch/powerpc/cpu/mpc86xx/mp.c  |  8 
 include/common.h   |  8 
 6 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c 
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index dd89d0a83f89..7627fd13e7d8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -191,14 +191,14 @@ int is_core_online(u64 cpu_id)
return table[SPIN_TABLE_ELEM_STATUS_IDX] == 1;
 }
 
-int cpu_reset(int nr)
+int cpu_reset(u32 nr)
 {
puts("Feature is not implemented.\n");
 
return 0;
 }
 
-int cpu_disable(int nr)
+int cpu_disable(u32 nr)
 {
puts("Feature is not implemented.\n");
 
@@ -231,7 +231,7 @@ static int core_to_pos(int nr)
return i;
 }
 
-int cpu_status(int nr)
+int cpu_status(u32 nr)
 {
u64 *table;
int pos;
@@ -257,7 +257,7 @@ int cpu_status(int nr)
return 0;
 }
 
-int cpu_release(int nr, int argc, char * const argv[])
+int cpu_release(u32 nr, int argc, char * const argv[])
 {
u64 boot_addr;
u64 *table = (u64 *)get_spin_tbl_addr();
diff --git a/arch/arm/cpu/armv8/zynqmp/mp.c b/arch/arm/cpu/armv8/zynqmp/mp.c
index 7e270a7dc232..2a71870ae7bc 100644
--- a/arch/arm/cpu/armv8/zynqmp/mp.c
+++ b/arch/arm/cpu/armv8/zynqmp/mp.c
@@ -45,7 +45,7 @@ int is_core_valid(unsigned int core)
return 0;
 }
 
-int cpu_reset(int nr)
+int cpu_reset(u32 nr)
 {
puts("Feature is not implemented.\n");
return 0;
@@ -131,7 +131,7 @@ static void enable_clock_r5(void)
udelay(0x500);
 }
 
-int cpu_disable(int nr)
+int cpu_disable(u32 nr)
 {
if (nr >= ZYNQMP_CORE_APU0 && nr <= ZYNQMP_CORE_APU3) {
u32 val = readl(_base->rst_fpd_apu);
@@ -144,7 +144,7 @@ int cpu_disable(int nr)
return 0;
 }
 
-int cpu_status(int nr)
+int cpu_status(u32 nr)
 {
if (nr >= ZYNQMP_CORE_APU0 && nr <= ZYNQMP_CORE_APU3) {
u32 addr_low = readl(((u8 *)_base->rvbar_addr0_l) + nr * 8);
@@ -220,7 +220,7 @@ void initialize_tcm(bool mode)
}
 }
 
-int cpu_release(int nr, int argc, char * const argv[])
+int cpu_release(u32 nr, int argc, char * const argv[])
 {
if (nr >= ZYNQMP_CORE_APU0 && nr <= ZYNQMP_CORE_APU3) {
u64 boot_addr = simple_strtoull(argv[0], NULL, 16);
diff --git a/arch/arm/mach-imx/mx6/mp.c b/arch/arm/mach-imx/mx6/mp.c
index c3806dca3ad0..eda168d86711 100644
--- a/arch/arm/mach-imx/mx6/mp.c
+++ b/arch/arm/mach-imx/mx6/mp.c
@@ -29,20 +29,20 @@ static uint32_t cpu_ctrl_mask[MAX_CPUS] = {
SRC_SCR_CORE_3_ENABLE_MASK
 };
 
-int cpu_reset(int nr)
+int cpu_reset(u32 nr)
 {
/* Software reset of the CPU N */
src->scr |= cpu_reset_mask[nr];
return 0;
 }
 
-int cpu_status(int nr)
+int cpu_status(u32 nr)
 {
printf("core %d => %d\n", nr, !!(src->scr & cpu_ctrl_mask[nr]));
return 0;
 }
 
-int cpu_release(int nr, int argc, char *const argv[])
+int cpu_release(u32 nr, int argc, char *const argv[])
 {
uint32_t boot_addr;
 
@@ -78,7 +78,7 @@ int is_core_valid(unsigned int core)
return 1;
 }
 
-int cpu_disable(int nr)
+int cpu_disable(u32 nr)
 {
/* Disable the CPU N */
src->scr &= ~cpu_ctrl_mask[nr];
diff --git a/arch/powerpc/cpu/mpc85xx/mp.c b/arch/powerpc/cpu/mpc85xx/mp.c
index 42501ca3cec5..b0aa72ed6e02 100644
--- a/arch/powerpc/cpu/mpc85xx/mp.c
+++ b/arch/powerpc/cpu/mpc85xx/mp.c
@@ -42,7 +42,7 @@ int hold_cores_in_reset(int verbose)
return 0;
 }
 
-int cpu_reset(int nr)
+int cpu_reset(u32 nr)
 {
volatile ccsr_pic_t *pic = (void *)(CONFIG_SYS_MPC8xxx_PIC_ADDR);
out_be32(>pir, 1 << nr);
@@ -53,7 +53,7 @@ int cpu_reset(int nr)
return 0;
 }
 
-int cpu_status(int nr)
+int cpu_status(u32 nr)
 {
u32 *table, id = get_my_id();
 
@@ -79,7 +79,7 @@ int cpu_status(int nr)
 }
 
 #ifdef CONFIG_FSL_CORENET
-int cpu_disable(int nr)
+int cpu_disable(u32 nr)
 {
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 
@@ -95,7 +95,7 @@ int is_core_disabled(int nr) {
return (coredisrl & (1 << nr));
 }
 #else
-int cpu_disable(int nr)
+int cpu_disable(u32 nr)
 {
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 
@@ -137,7 +137,7 @@ static u8 boot_entry_map[4] = {
BOOT_ENTRY_R3_LOWER,
 };
 
-int cpu_release(int nr, int argc, char * const argv[])
+int 

Re: [U-Boot] [PATCH v2 2/3] mpc83xx/pci: Register IMMR region

[Mario Six]

Hi Simon,

On Fri, May 4, 2018 at 11:37 PM, Simon Glass  wrote:
> Hi Mario,
>
> On 4 May 2018 at 02:15, Mario Six  wrote:
>> Hi Simon,
>>
>> On Thu, May 3, 2018 at 9:02 PM, Simon Glass  wrote:
>>> Hi Mario,
>>>
>>> On 27 April 2018 at 06:53, Mario Six  wrote:
 Register the IMMR region as a PCI region when PCI is used on MPC83xx.

 Signed-off-by: Mario Six 
 ---

 v1 -> v2:
 No changes

 ---
  drivers/pci/pci-uclass.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
 index a2e829608a..37ca09d76b 100644
 --- a/drivers/pci/pci-uclass.c
 +++ b/drivers/pci/pci-uclass.c
 @@ -902,6 +902,11 @@ static int decode_regions(struct pci_controller
> *hose, ofnode parent_node,
 base, size, PCI_REGION_MEM |
> PCI_REGION_SYS_MEMORY);
  #endif

 +#if defined(MPC83xx) && defined(CONFIG_SYS_IMMR)
 +   pci_set_region(hose->regions + hose->region_count++,
 +  CONFIG_SYS_IMMR, CONFIG_SYS_IMMR, 0x10,
 +  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
 +#endif
>>>
>>> Please don't add device-specific code in this file. This could go in
>>> the device tree, perhaps. If not, we perhaps need to do it in your PCI
>>> driver?
>>>
>>
>> OK, I'll try to put it into the DT (I have absolutely no expertise with
> PCI, so
>> I'm still learning with this one).
>
> Here's a possible idea:
>
> decode_regions() is called from the PCI uclass' pre_probe() method. This
> means that by the time your PCI controller enters the probe() method, all
> the regions should be set up. So you should be able to add the above code
> into the probe() method of your PCI controller driver. Perhaps can check a
> compatible string etc. to decide whether to add this region, if it is no
> described in the DT itself.
>

OK, I'll do that for v3, thanks for the explanation.

> 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 v5 10/13] efi: sandbox: Add a simple 'bootefi test' command

[Alexander Graf]

On 12.06.18 23:57, Simon Glass wrote:
> Hi Alex,
> 
> On 12 June 2018 at 08:11, Alexander Graf  wrote:
>>
>>
>> On 12.06.18 15:48, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 12 June 2018 at 02:28, Alexander Graf  wrote:


 On 12.06.18 07:26, Simon Glass wrote:
> This jumps to test code which can call directly into the EFI support. It
> does not need a separate image so it is easy to write tests with it.
>
> This test can be executed without causing problems to the run-time
> environemnt (e.g. U-Boot does not need to reboot afterwards).
>
> For now the test just outputs a message. To try it:
>
> ./sandbox/u-boot -c "bootefi test"
> U-Boot 2017.09-00204-g696c9855fe (Sep 17 2017 - 16:43:53 -0600)
>
> DRAM:  128 MiB
> MMC:
> Using default environment
>
> In:serial
> Out:   serial
> Err:   serial
> SCSI:  Net:   No ethernet found.
> IDE:   Bus 0: not available
> Found 0 disks
> WARNING: booting without device tree
> Hello, world!
> Test passed
>
> Signed-off-by: Simon Glass 

 From Heinrich's comments it sounded like it wouldn't be hard to make the
 selftest work. That sounds more appealing to me to be honest :).
>>>
>>> Yes and in fact my hope was to run the tests automatically as part of
>>> 'make tests'
>>>
>>> But rather than expanding the scope of this series, can we get this in
>>> first? Having EFI support in sandbox is a substantial step forward.
>>
>> I agree that it would be amazing to have it in, I just want to make sure
>> we're walking into the right direction. And what I want to have is an
>> easy way to execute EFI binaries from user space :).
> 
> That's a different thing entirely from the purpose of my series. My
> series is designed to allow EFI applications to be *linked* with
> sandbox and run just like normal C code, with a full unified stack
> trace, etc.
> 
> I think this is a very useful feature separate from running EFI
> binaries in user space.

I understand that and I agree that it's useful. I just don't want to
drive us into a corner where it blocks the other use case.


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

Re: [U-Boot] [PATCH v5 04/13] sandbox: smbios: Update to support sandbox

[Alexander Graf]

On 12.06.18 23:56, Simon Glass wrote:
> Hi Alex,
> 
> On 12 June 2018 at 08:05, Alexander Graf  wrote:
>>
>>
>> On 12.06.18 15:48, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 12 June 2018 at 02:12, Alexander Graf  wrote:


 On 12.06.18 07:26, Simon Glass wrote:
> At present this code casts addresses to pointers so cannot be used with
> sandbox. Update it to use mapmem instead.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Drop incorrect map_sysmem() in write_smbios_table()
>
> Changes in v2: None
>
>  lib/smbios.c | 32 
>  1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index df3d26b071..fc3dabcbc1 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -6,6 +6,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start)
>
>  static int smbios_write_type0(ulong *current, int handle)

 Please change the function argument to indicate that we're no longer
 dealing with pointers, but instead with "u-boot physical addresses".

 Same for the other functions obviously :).
>>>
>>> That actually hasn't changed. We are currently passing a U-Boot
>>> address around and it is a ulong, as it normally is in U-Boot. What
>>> has changed is that sandbox does not have a direct mapping between
>>> U-Boot address and memory address, so we have to do the mapping.
>>>
>>> While it is try that the ulong can be converted to a pointer with a
>>> cast normally, this is not possible with sandbox, so things that need
>>> to convert the ulong to a pointer need to do a conversion.
>>
>> Oh, I missed the * in *current. So it already does get passed as a
>> number which then is cast back into a pointer.
>>
>> That however means that the smbios tables are now u-boot address space
>> relative. So anything that tries to read them from within EFI context
>> will explode.
> 
> Aren't these tables for the Linux kernel? If so, then this doesn't matter.
> 
> But if EFI reads them, we are in trouble. We cannot always put a
> 64-bit address into a 32-bit word.
> 
> I suppose we could support it on 32-bit sandbox, but not a lot of
> people use that.

Sorry, I must've misremembered. I can not see a single reference of a
physical address in the SMBIOS code. So your patch looks correct to me.


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

Re: [U-Boot] T1040RDB u-boot chain load u-boot

[Radu-andrei Bulie]

Hi,


The u-boot-spl.bin (written in nand) loads the u-boot.bin which was previously 
written in nand. When the board boots, this process is transparent to you. (The 
address for the u-boot.bin in nand is 0x4). The load process is done 
through the spl routines that are used by the u-boot-spl.bin image to load the 
u-boot from offset 0x4.

To summarize,  the boot process is like this: PBL > (NAND -RCW) > 
u-boot-spl --->u-boot.bin

From the booted u-boot if you try to launch u-boot.bin which was transferred in 
a memory location by you, you will for sure get a hang because the u-boot.bin 
will try to reinitialize some blocks that were already initialized. You could 
end up taking the carpet from underneath your feet.

If you want to load another u-boot instance you will have probably to make 
changes in the u-boot.bin image. 


Radu


-Original Message-
From: Chris Packham [mailto:judge.pack...@gmail.com] 
Sent: Friday, June 8, 2018 12:20 AM
To: nicolae.rosia@gmail.com
Cc: u-boot ; Priyanka Jain ; 
Radu-andrei Bulie 
Subject: Re: [U-Boot] T1040RDB u-boot chain load u-boot

On Thu, Jun 7, 2018 at 10:46 PM Nicolae Rosia  
wrote:


> Scenario 4:
> Remove RAMBOOT_PBL from defconfig:
> -CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL"
> +CONFIG_SYS_EXTRA_OPTIONS="SPL_FSL_PBL"
>
> This results in a binary that is more than 3GB (??)
>
> Scenario 4.1:
> I noticed that CONFIG_SYS_TEXT_BASE affects the size of binary so I 
> thought I can fix this by placing it near RAM end, 4 GB - 8 MB:
> -CONFIG_SYS_TEXT_BASE=0x30001000
> +CONFIG_SYS_TEXT_BASE=0xFF80
> -CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL"
> +CONFIG_SYS_EXTRA_OPTIONS="SPL_FSL_PBL"
>
> but the size of u-boot.bin is ~249 MB

That's probably because there's some other fixed address in use (probably the 
reset vector). You'll want to adjust that address to match your new location or 
maybe use something like SKIP_LOW_LEVEL_INIT assuming powerpc has such a thing.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/4] tools: zynqmpimage: Add bif support

[Michal Simek]

Hi,


>  Hi Alex
> 
> On Wed, Jun 13, 2018 at 11:07 AM, Alexander Graf  wrote:
>> Hi Peter,
>>
>> I'm not sure how much documentation you want. Basically mkimage becomes
>> a replacement for bootgen in any official Xilinx documentation. So any
>> Xilinx wiki like
>>
>>   http://www.wiki.xilinx.com/Prepare+boot+image
>>
>> or even the official .bif documentation:
>>
>>
>> https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
>>
>> apply. The only difference is that the command line arguments are
>> different. But mkimage takes a .bif file as input and generates a
>> boot.bin file as output.
> 
> Thanks, good resources, a readme like doc/README.chromium outlining
> the process for people wanting to get started would likely be a good
> thing in general with links to those sorts of other resources would be
> useful for zynqmp like most of the other device categories. I was kind
> of surprised actually that zynqmp didn't have some sort of related
> docs to deal with it already.

Xilinx has wiki.xilinx.com pages to cover xilinx differences. Definitely
feel free to compose one and I am happy to review it.

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

Re: [U-Boot] [PATCH V4 2/2] bootm: Handle kernel_noload on arm64

[Marek Vasut]

On 06/13/2018 09:51 AM, Bin Chen wrote:
> 
> 
> On 13 June 2018 at 14:13, Marek Vasut  > wrote:
> 
> The ARM64 has 2 MiB alignment requirement for the kernel. When using
> fitImage, this requirement may by violated, the kernel will thus be
> executed from unaligned address and fail to boot. Do what booti does
> and run booti_setup() for kernel_noload images on arm64 to obtain a
> suitable aligned address to which the image shall be relocated.
> 
> Signed-off-by: Marek Vasut  >
> Cc: Bin Chen mailto:bin.c...@linaro.org>>
> Cc: Masahiro Yamada  >
> Cc: Tom Rini mailto:tr...@konsulko.com>>
> ---
> V2: Protect the ARM64 booti bit with if IS_ENABLED(CMD_BOOTI)
> V3: Use if() instead of #ifdef
> V4: Switch force_reloc to bool
> ---
>  common/bootm.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f6818a..e517d9f118 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -202,8 +202,23 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int
> flag, int argc,
>         }
> 
>         if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
> -               images.os.load = images.os.image_start;
> -               images.ep += images.os.load;
> +               if (CONFIG_IS_ENABLED(CMD_BOOTI) &&
> +                   images.os.arch == IH_ARCH_ARM64) {
> +                       ulong image_addr;
> +                       ulong image_size;
> +
> +                       ret = booti_setup(images.os.image_start,
> _addr,
> +                                         _size, true);
> 
> 
> Is it guaranteed to be conflict free (with other images) by always
> moving the kernel to the start of the RAM? 

Yes

> 
> +                       if (ret != 0)
> +                               return 1;
> 
> 
> Do you think it helps to add some debug/error message here as in other
> path that returns 1?

No, what for ?

> +
> +                       images.os.type = IH_TYPE_KERNEL;
> +                       images.os.load = image_addr;
> +                       images.ep = image_addr;
> +               } else {
> +                       images.os.load = images.os.image_start;
> +                       images.ep += images.os.image_start;
> 
> 
> I know this is same the orinigal code. I'm not famaliar the
> history/purpse of type 
> IH_TYPE_KERNEL_NOLOAD (compared with IH_TYPE_KERNEL), so just for my
> understanding, 
> why in this case we have to increment the images.ep by images.os.load,
> not just set images.ep to 
> images.os.load.
The ep is incremented by the offset from the start of the image. That's
also the purpose of kernel noload -- don't copy the kernel to the load
address and just execute it in place. Problem with arm64 is that it does
not work so because the kernel needs to be at 2 MiB offset, which is
hard to achieve with fitImage. Thus we work around that by placing the
kernel at the start of RAM. It's overloading the kernel noload, but at
least it works.

[...]

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

Re: [U-Boot] [PATCH v4 4/4] tools: zynqmpimage: Add bif support

[Peter Robinson]

 Hi Alex

On Wed, Jun 13, 2018 at 11:07 AM, Alexander Graf  wrote:
> Hi Peter,
>
> I'm not sure how much documentation you want. Basically mkimage becomes
> a replacement for bootgen in any official Xilinx documentation. So any
> Xilinx wiki like
>
>   http://www.wiki.xilinx.com/Prepare+boot+image
>
> or even the official .bif documentation:
>
>
> https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
>
> apply. The only difference is that the command line arguments are
> different. But mkimage takes a .bif file as input and generates a
> boot.bin file as output.

Thanks, good resources, a readme like doc/README.chromium outlining
the process for people wanting to get started would likely be a good
thing in general with links to those sorts of other resources would be
useful for zynqmp like most of the other device categories. I was kind
of surprised actually that zynqmp didn't have some sort of related
docs to deal with it already.

Thanks

> On 13.06.18 08:49, Peter Robinson wrote:
>>  Michael or Alex,
>>
>> Could someone add a ZynqMP README documenting the process required to
>> use U-Boot for the ZynqMP with the open tools? I looked in
>> board/xilinx/zynqmp and doc/ and a few other places but couldn't see
>> any docs for either that or the closed tools.
>>
>> Peter
>>
>> On Fri, Apr 13, 2018 at 1:18 PM, Alexander Graf  wrote:
>>> The officially described way to generate boot.bin files for ZynqMP is to
>>> describe the contents of the target binary using a file of the "bif"
>>> format.  This file then links to other files that all get packed into a
>>> bootable image.
>>>
>>> This patch adds support to read such a .bif file and generate a respective
>>> ZynqMP boot.bin file that can include the normal image and pmu files, but
>>> also supports image partitions now. This makes it a handy replacement for
>>> the proprietary "bootgen" utility that is currently used to generate
>>> boot.bin files with FSBL.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v2 -> v3:
>>>
>>>   - zero initialize header
>>>   - reduce default debug verbosity
>>>
>>> v3 -> v4:
>>>
>>>   - add error handling
>>>   - add fsbl_config support
>>>   - add aarch32 support
>>>   - allow a5x to be written as a53
>>>   - add offset support
>>>   - add support for partition_owner
>>>   - ensure pmufw comes before bootloader
>>>   - simplify fsbl_config
>>>   - add non-a53 boot support
>>>   - checkpatch fixes
>>> ---
>>>  common/image.c  |1 +
>>>  include/image.h |1 +
>>>  tools/Makefile  |1 +
>>>  tools/imagetool.h   |1 +
>>>  tools/mkimage.c |7 +
>>>  tools/zynqmpbif.c   | 1008 
>>> +++
>>>  tools/zynqmpimage.c |4 +-
>>>  tools/zynqmpimage.h |7 +
>>>  8 files changed, 1028 insertions(+), 2 deletions(-)
>>>  create mode 100644 tools/zynqmpbif.c
>>>
>>> diff --git a/common/image.c b/common/image.c
>>> index e1c50eb25d..f30dfa229b 100644
>>> --- a/common/image.c
>>> +++ b/common/image.c
>>> @@ -159,6 +159,7 @@ static const table_entry_t uimage_type[] = {
>>> {   IH_TYPE_VYBRIDIMAGE, "vybridimage",  "Vybrid Boot Image", },
>>> {   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" 
>>> },
>>> {   IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot 
>>> Image" },
>>> +   {   IH_TYPE_ZYNQMPBIF,  "zynqmpbif",  "Xilinx ZynqMP Boot Image 
>>> (bif)" },
>>> {   IH_TYPE_FPGA,   "fpga",   "FPGA Image" },
>>> {   IH_TYPE_TEE,"tee","Trusted Execution 
>>> Environment Image",},
>>> {   IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 
>>> IVT" },
>>> diff --git a/include/image.h b/include/image.h
>>> index a579c5f509..c5af912aeb 100644
>>> --- a/include/image.h
>>> +++ b/include/image.h
>>> @@ -269,6 +269,7 @@ enum {
>>> IH_TYPE_RKSPI,  /* Rockchip SPI image   */
>>> IH_TYPE_ZYNQIMAGE,  /* Xilinx Zynq Boot Image */
>>> IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
>>> +   IH_TYPE_ZYNQMPBIF,  /* Xilinx ZynqMP Boot Image (bif) */
>>> IH_TYPE_FPGA,   /* FPGA Image */
>>> IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
>>> IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
>>> diff --git a/tools/Makefile b/tools/Makefile
>>> index 8143c25666..204685ec9e 100644
>>> --- a/tools/Makefile
>>> +++ b/tools/Makefile
>>> @@ -113,6 +113,7 @@ dumpimage-mkimage-objs := aisimage.o \
>>> ublimage.o \
>>> zynqimage.o \
>>> zynqmpimage.o \
>>> +   zynqmpbif.o \
>>> $(LIBFDT_OBJS) \
>>> gpimage.o \
>>> gpimage-common.o \
>>> diff --git a/tools/imagetool.h b/tools/imagetool.h
>>> index 

Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On 10:08-20180613, Russell King - ARM Linux wrote:
> On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> > On 21:40-20180612, Russell King - ARM Linux wrote:
> > [...]
> > > > I started respinning the series, while there is definitely a use of
> > > > implementing in u-boot,
> > > > I am starting to wonder if we should also be doing this in kernel.
> > > 
> > > How does the kernel set the bit when the kernel is running in non-secure
> > > mode, when the ACTLR is read-only in that mode?
> > 
> > For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> > it:
> > https://patchwork.kernel.org/patch/10461273/
> > 
> > This'd be similar in implementation to ARM erratum 801819 workaround
> > that needs two pieces (u-boot + kernel). I am not really worried about
> > OMAP5/DRA7 since they should'nt loose context in Low power modes.
> > Other SoCs need to be aware of the constraints.
> > 
> > /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> > legacy v7 SoCs have implementations that are kind of different (even
> > smc calling conventions vary).
> 
> It may seem to be an easy way out (do everything in the kernel) but
> have you considered that the secure world is also vulnerable?

Yes, we have.

> If the IBE bit is not set in the secure world, then the secure world
> is not implementing the workarounds, and therefore the non-secure
> world has the possibility to use the Spectre vulnerabilities to
> exploit the secure world with enough effort and knowledge.
> 
> You really need to _also_ fix these vulnerabilities in the secure
> world, which includes setting the IBE bit there.

Correct, but, unfortunately, this is NOT always the case / not necessary in
some cases. Example:

On General purpose (GP) devices such as in OMAP, ROM owns the secure APIs,
there is no override of secure world APIs possible. In such cases, we
have to see if there is anything that needs to be protected. in case of
GP devices, there are no secure assets to protect and any SMC calls are
just support services provided by ROM.

a) updating secure side is not possible
b) secure side updates is not necessary since there are no critical run time
   services provided by ROM.

On devices such as Keystone 2 (TI) generation, yes, we do have ability
to update secure side and must be done as well.

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

Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS

[Nishanth Menon]

On 23:06-20180612, Marek Vasut wrote:
> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> > Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> > function to setup the bits, we are able to override the settings.
> > 
> > Without this enabled, Linux kernel reports:
> > CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, 
> > system vulnerable
> > 
> > With this enabled, Linux kernel reports:
> > CPU0: Spectre v2: using ICIALLU workaround
> > 
> > NOTE: This by itself does not enable the workaround for CPU1 (on
> > OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> > 
> > Signed-off-by: Nishanth Menon 
> > ---
> >  arch/arm/mach-omap2/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 3bb1ecb58de0..77820cc8d1e4 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -53,6 +53,7 @@ config OMAP54XX
> > bool "OMAP54XX SoC"
> > select ARM_ERRATA_798870
> > select SYS_THUMB_BUILD
> > +   select ARM_CORTEX_A15_CVE_2017_5715
> > imply NAND_OMAP_ELM
> > imply NAND_OMAP_GPMC
> > imply SPL_DISPLAY_PRINT
> > 
> 
> Can this be enabled for all CA15 systems somehow ? I am sure there are
> more that are vulnerable.

I just dont know how to make smc call convention generic. This is the
reason why v7_arch_cp15_set_acr is setup as a weak function. you'd have
to implement it specific to SoC (in many newer SoCs, you might
potentially be able to make at least few implementations generic using
PSCI). NOTE: this is the same trouble with erratum 801819 implementation
as well.

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

Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

On 23:05-20180612, Marek Vasut wrote:
> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
[..]
> > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> > +   mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
> > +   orr r0, r0, #1 << 0 @ Enable invalidates of BTB
> 
> Can we use BIT() macro in the assembler code too ?

Probably, but just following convention in the rest of the file. Do we
want to change from existing code?

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

Re: [U-Boot] [PATCH] MAINTAINERS: update ARM Snapdragon

[Mateusz Kulikowski]

Hi,

On 06/10/2018 01:51 PM, Ramon Fried wrote:

Replace Mateusz as Maintainer for ARM Snapdragon arch.

Signed-off-by: Ramon Fried 
---
  MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448093..b2c9717cb7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -184,7 +184,7 @@ F:  arch/arm/mach-s5pc1xx/
  F:arch/arm/cpu/armv7/s5p-common/
  
  ARM SNAPDRAGON

-M: Mateusz Kulikowski 
+M: Ramon Fried 
  S:Maintained
  F:arch/arm/mach-snapdragon/
  



Acked-by: Mateusz Kulikowski 

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

Re: [U-Boot] [PATCH v3 2/2] mdio: add marvell MDIO driver

[Stefan Roese]

On 13.06.2018 06:37, m...@marvell.com wrote:

From: Ken Ma 

This patch adds a separate driver for the MDIO interface of the
Marvell Ethernet controllers based on driver model. There are two
reasons to have a separate driver rather than including it inside
the MAC driver itself:
   *) The MDIO interface is shared by all Ethernet ports, so a driver
  must guarantee non-concurrent accesses to this MDIO interface. The
  most logical way is to have a separate driver that handles this
  single MDIO interface, used by all Ethernet ports.
   *) The MDIO interface is the same between the existing mv643xx_eth
  driver and the new mvneta/mvpp2 driver. Even though it is for now
  only used by the mvneta/mvpp2 driver, it will in the future be
  used by the mv643xx_eth driver as well.

This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE
802.3 Clause 45.

This patch also adds device tree binding for marvell MDIO driver.

Signed-off-by: Ken Ma 
Reviewed-by: Chris Packham 
---

Changes in v3:
- Move marvell mdio driver to driver/net/mdio folder;
- Update codes according to mdio uclass implementation updates.

Changes in v2:
- Fix error printing:
   - Change some debug to pr_err;
   - mii bus has no parent member and it is not a udevice, so dev_err
 is changed to pr_err for mii bus error printings.

  MAINTAINERS   |   1 +
  arch/arm/Kconfig  |   1 +
  doc/device-tree-bindings/net/marvell-mdio.txt |  18 ++
  drivers/net/mdio/Kconfig  |  10 ++
  drivers/net/mdio/Makefile |   1 +
  drivers/net/mdio/mvmdio.c | 234 ++
  6 files changed, 265 insertions(+)
  create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt
  create mode 100644 drivers/net/mdio/mvmdio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e1fc83..d8584f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -137,6 +137,7 @@ T:  git git://git.denx.de/u-boot-marvell.git
  F:arch/arm/mach-kirkwood/
  F:arch/arm/mach-mvebu/
  F:drivers/ata/ahci_mvebu.c
+F: drivers/net/mdio/mvmdio.c
  
  ARM MARVELL PXA

  M:Marek Vasut 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422b..e52b164 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -432,6 +432,7 @@ config ARCH_MVEBU
select DM_SPI
select DM_SPI_FLASH
select SPI
+   select MDIO
  
  config TARGET_DEVKIT3250

bool "Support devkit3250"
diff --git a/doc/device-tree-bindings/net/marvell-mdio.txt 
b/doc/device-tree-bindings/net/marvell-mdio.txt
new file mode 100644
index 000..55db435
--- /dev/null
+++ b/doc/device-tree-bindings/net/marvell-mdio.txt
@@ -0,0 +1,18 @@
+* Marvell MDIO Ethernet Controller interface
+
+The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k
+have an identical unit that provides an interface with the MDIO bus.
+This driver handles this MDIO interface.
+
+Mandatory properties:
+SoC specific:
+   - #address-cells: Must be <1>.
+   - #size-cells: Must be <0>.
+   - compatible: Should be "marvell,orion-mdio" (for SMI)
+   "marvell,xmdio"(for XSMI)
+   - reg: Base address and size SMI/XMSI bus.
+
+Optional properties:
+   - mdio-name   - MDIO bus name
+
+For example, please refer to "mdio-bus.txt".
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 533cc4a..d1a31e6 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -15,4 +15,14 @@ config MDIO
  udevice or mii bus from its child phy node or
  an ethernet udevice which the phy belongs to.
  
+config MVMDIO

+   bool "Marvell MDIO interface support"
+   depends on MDIO
+   select PHYLIB
+   help
+ This driver supports the MDIO interface found in the network
+ interface units of the Marvell EBU SoCs (Kirkwood, Orion5x,
+ Dove, Armada 370, Armada XP, Armada 37xx and Armada7K/8K/8KP).
+
+ This driver is used by the MVPP2 and MVNETA drivers.
  endmenu
diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile
index 45ae502..8b2e5a4 100644
--- a/drivers/net/mdio/Makefile
+++ b/drivers/net/mdio/Makefile
@@ -4,3 +4,4 @@
  # Author: Ken Ma
  
  obj-$(CONFIG_MDIO) += mdio-uclass.o

+obj-$(CONFIG_MVMDIO) += mvmdio.o
diff --git a/drivers/net/mdio/mvmdio.c b/drivers/net/mdio/mvmdio.c
new file mode 100644
index 000..0fb45ce
--- /dev/null
+++ b/drivers/net/mdio/mvmdio.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ * Author: Ken Ma
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MVMDIO_SMI_DATA_SHIFT  0
+#define MVMDIO_SMI_PHY_ADDR_SHIFT  16
+#define MVMDIO_SMI_PHY_REG_SHIFT   21
+#define MVMDIO_SMI_READ_OPERATION  BIT(26)
+#define MVMDIO_SMI_WRITE_OPERATION 0
+#define 

Re: [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options

[Alexander Graf]

On 13.06.18 03:29, Simon Glass wrote:
> Hi Bin, Alex,
> 
> On 12 June 2018 at 09:36, Bin Meng  wrote:
>> From: Alexander Graf 
>>
>> Currently efi.h determines a few bits of its environment according to
>> config options. This falls apart with the efi stub support which may
>> result in efi.h getting pulled into the stub as well as real U-Boot
>> code. In that case, one may be 32bit while the other one is 64bit.
>>
>> This patch changes the conditionals to use compiler provided defines
>> instead. That way we always adhere to the build environment we're in
>> and the definitions adjust automatically.
>>
>> Signed-off-by: Alexander Graf 
>> Reviewed-by: Bin Meng 
>> Tested-by: Bin Meng 
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  include/efi.h| 17 -
>>  lib/efi/Makefile |  4 ++--
>>  2 files changed, 6 insertions(+), 15 deletions(-)
>>
>> diff --git a/include/efi.h b/include/efi.h
>> index 98bddba..5e1e8ac 100644
>> --- a/include/efi.h
>> +++ b/include/efi.h
>> @@ -19,12 +19,12 @@
>>  #include 
>>  #include 
>>
>> -#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && 
>> defined(__x86_64__))
>> -/* EFI uses the Microsoft ABI which is not the default for GCC */
>> +/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
>> +#ifdef __x86_64__
>>  #define EFIAPI __attribute__((ms_abi))
>>  #else
>>  #define EFIAPI asmlinkage
>> -#endif
>> +#endif /* __x86_64__ */
> 
> I made the same comment in another patch. This is becoming too ad-hoc
> where making EFI builds work is distributed and hidden in such a way
> that no one will be able to know whether a change causes problems or
> not.
> 
> I feel that build config should be deterministic given the CONFIG
> options provided by the board. Any checks of compiler predefines
> should be done in one place (efi.h?) and bugs in that stuff should
> there all be in one place too, and easier to debug and fix.

I actually think the opposite is true. We should get rid of any #ifdef
CONFIG_ARCH checks throughout the code base that are not meant to
actually check for the "target" (sandbox for example), but instead
really only want to know the architecture the code is building against.

We can easily trust the compiler to emit correct defines for the target
architecture it's building against. That's what every other piece of C
code on earth depends on. Why be different?


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

[U-Boot] [PATCH] net: gem: Check return value from mealign/malloc

[Michal Simek]

Functions can return NULL in case of error that's why checking return
value is needed.

Signed-off-by: Michal Simek 
---

Reported by: Coverity (local)

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

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 14564e365e6e..a817f2e5d69b 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -633,10 +633,16 @@ static int zynq_gem_probe(struct udevice *dev)
 
/* Align rxbuffers to ARCH_DMA_MINALIGN */
priv->rxbuffers = memalign(ARCH_DMA_MINALIGN, RX_BUF * PKTSIZE_ALIGN);
+   if (!priv->rxbuffers)
+   return -ENOMEM;
+
memset(priv->rxbuffers, 0, RX_BUF * PKTSIZE_ALIGN);
 
/* Align bd_space to MMU_SECTION_SHIFT */
bd_space = memalign(1 << MMU_SECTION_SHIFT, BD_SPACE);
+   if (!bd_space)
+   return -ENOMEM;
+
mmu_set_region_dcache_behaviour((phys_addr_t)bd_space,
BD_SPACE, DCACHE_OFF);
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

On 00:30-20180613, Florian Fainelli wrote:
> On June 12, 2018 1:24:09 PM PDT, Nishanth Menon  wrote:
> >As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
> >needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
> >be done unconditionally for Cortex-A15 processors. Provide a config
> >option for platforms to enable this option based on impact analysis
> >for products.
> >
> >NOTE: This patch in itself is NOT the final solution, this requires:
> >a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> >   provide direct access to ACR register.
> >b) Operating Systems such as Linux to provide adequate workaround in
> >the
> >   right locations.
> 
> This is the case as of 4.18 so you could probably reference 
> CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.

Did'nt want to tie the description too deep to Linux specifics.. Linux
documents itself and users are encouraged to read that documentation,
correct?

> 
> >c) This workaround applies to only the boot processor. It is important
> >   to apply workaround as necessary (context-save-restore) around low
> >   power context loss OR additional processors as necessary in either
> >   firmware support OR elsewhere in OS.
> 
> About that, I don't know enough of uboot but are there existing PSCI or
> other seemingly standard secondary core support in uboot that would make
> us go through the same initialization as the boot CPU? If not, is
> everything going to be largely implementation specific and
> scattered between uboot and the hypervisors or kernel?

in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard.
even within TI, Few of the SoCs use PSCI, others did implement custom
SMC calls (since they existed in an architecture prior to PSCI).

> 
> FWIW, this is what prompted me to submit this:
> 
> https://patchwork.kernel.org/patch/10453643/

That wont work in a generic manner for precisely the same reason I had to do
it with weak function in u-boot (some SoCs will only permit 'mcr
p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc
call to make it happen). Unfortunately, IMHO, at least at this
point, there'd be custom implementations per SoC and layers depending on
where to implement it.

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

Re: [U-Boot] [PATCH RESEND 1/2] rockchip: make_fit_atf: use elf entry point

[Mian Yousaf Kaukab]

On 06/13/2018 08:45 AM, Kever Yang wrote:

Hi Yousaf,

     You patch looks good, but I don't know why the script always work
for me,

and I don't met the abort, where do you get the BL31?

I am building it with the following command line:
make -j4 CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 DEBUG=1 all
Abort is 100% reproducible with ATF v1.4 and v1.5.




Thanks,
- Kever

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

Re: [U-Boot] [PATCH V4 2/2] bootm: Handle kernel_noload on arm64

[Tom Rini]

On Wed, Jun 13, 2018 at 12:39:25PM +0200, Marek Vasut wrote:
> On 06/13/2018 09:51 AM, Bin Chen wrote:
> > 
> > 
> > On 13 June 2018 at 14:13, Marek Vasut  > > wrote:
> > 
> > The ARM64 has 2 MiB alignment requirement for the kernel. When using
> > fitImage, this requirement may by violated, the kernel will thus be
> > executed from unaligned address and fail to boot. Do what booti does
> > and run booti_setup() for kernel_noload images on arm64 to obtain a
> > suitable aligned address to which the image shall be relocated.
> > 
> > Signed-off-by: Marek Vasut  > >
> > Cc: Bin Chen mailto:bin.c...@linaro.org>>
> > Cc: Masahiro Yamada  > >
> > Cc: Tom Rini mailto:tr...@konsulko.com>>
> > ---
> > V2: Protect the ARM64 booti bit with if IS_ENABLED(CMD_BOOTI)
> > V3: Use if() instead of #ifdef
> > V4: Switch force_reloc to bool
> > ---
> >  common/bootm.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/common/bootm.c b/common/bootm.c
> > index e789f6818a..e517d9f118 100644
> > --- a/common/bootm.c
> > +++ b/common/bootm.c
> > @@ -202,8 +202,23 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int
> > flag, int argc,
> >         }
> > 
> >         if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
> > -               images.os.load = images.os.image_start;
> > -               images.ep += images.os.load;
> > +               if (CONFIG_IS_ENABLED(CMD_BOOTI) &&
> > +                   images.os.arch == IH_ARCH_ARM64) {
> > +                       ulong image_addr;
> > +                       ulong image_size;
> > +
> > +                       ret = booti_setup(images.os.image_start,
> > _addr,
> > +                                         _size, true);
> > 
> > 
> > Is it guaranteed to be conflict free (with other images) by always
> > moving the kernel to the start of the RAM? 
> 
> Yes
> 
> > 
> > +                       if (ret != 0)
> > +                               return 1;
> > 
> > 
> > Do you think it helps to add some debug/error message here as in other
> > path that returns 1?
> 
> No, what for ?
> 
> > +
> > +                       images.os.type = IH_TYPE_KERNEL;
> > +                       images.os.load = image_addr;
> > +                       images.ep = image_addr;
> > +               } else {
> > +                       images.os.load = images.os.image_start;
> > +                       images.ep += images.os.image_start;
> > 
> > 
> > I know this is same the orinigal code. I'm not famaliar the
> > history/purpse of type 
> > IH_TYPE_KERNEL_NOLOAD (compared with IH_TYPE_KERNEL), so just for my
> > understanding, 
> > why in this case we have to increment the images.ep by images.os.load,
> > not just set images.ep to 
> > images.os.load.
> The ep is incremented by the offset from the start of the image. That's
> also the purpose of kernel noload -- don't copy the kernel to the load
> address and just execute it in place. Problem with arm64 is that it does
> not work so because the kernel needs to be at 2 MiB offset, which is
> hard to achieve with fitImage. Thus we work around that by placing the
> kernel at the start of RAM. It's overloading the kernel noload, but at
> least it works.

And, we have also overloaded the term "noload", historically.  It does
mean "execute the contents where they are".  But it also means (to
humans) "You don't need to specify a load address, it will just work".
So it is important to fix this so that a fitImage for aarch64 can work
on multiple SoCs so long as of course it has the dtbs for each of those
SoCs.

-- 
Tom


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

[U-Boot] [PATCH] cmd: gpio: Remove dead code from do_gpio

[Michal Simek]

gpio input/set/clear and toggle commands are already cover that's why
there is no any other case which should be handled.

Signed-off-by: Michal Simek 
---

Reported by: Coverity (local)
Not sure how to report this properly without CID

---
 cmd/gpio.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cmd/gpio.c b/cmd/gpio.c
index ecdc453918f4..f59cb5837187 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -208,8 +208,6 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!IS_ERR_VALUE(value))
value = !value;
break;
-   default:
-   goto show_usage;
}
gpio_direction_output(gpio, value);
}
-- 
1.9.1

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

Re: [U-Boot] [U-Boot, 3/4] configs: pcm051: Use DEFAULT_LINUX_BOOT_ENV instead of hardcoded values

[Tom Rini]

On Sat, Jun 02, 2018 at 08:22:27PM +0300, Matwey V. Kornilov wrote:

> It appears that DEFAULT_LINUX_BOOT_ENV can be used to boot pcm051 board.
> 
> Signed-off-by: Matwey V. Kornilov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 2/4] configs: pcm051: Use DEFAULT_MMC_TI_ARGS instead of hardcoded duplicates

[Tom Rini]

On Sat, Jun 02, 2018 at 08:22:26PM +0300, Matwey V. Kornilov wrote:

> Signed-off-by: Matwey V. Kornilov 

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] doc: cmd: bubt: drop duplicated text

[Tom Rini]

On Sun, Jun 03, 2018 at 04:19:31PM +0300, Baruch Siach wrote:

> This commit removes text that is exact duplicated of the text above.
> 
> Cc: Konstantin Porotchkin 
> Signed-off-by: Baruch Siach 
> Reviewed-by: Stefan Roese 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] u-boot: Fix several typos

[Tom Rini]

On Thu, Jun 07, 2018 at 07:47:19PM +0530, Shyam Saini wrote:

> 's/environemnt/environment/' and
>   's/Environemnt/Environment/'
> 
> Signed-off-by: Shyam Saini 

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] tools: env: Use getline rather than fgets when reading config/script

[Tom Rini]

On Thu, Jun 07, 2018 at 12:20:05PM +, Alex Kiernan wrote:

> When reading the config file, or a script file, use getline rather than
> fgets so line lengths aren't limited by the size of a compiled in buffer
> (128 characters for config, 1024 for scripts).
> 
> Rename 'dump' to 'line' so it's clear we're working with a line of text.
> 
> Signed-off-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v4, 2/2] test/py: add test for whitelist of variables while importing environment

[Tom Rini]

On Mon, Jun 04, 2018 at 11:47:30AM +0200, Quentin Schulz wrote:

> This tests that the importing of an environment with a specified
> whitelist works as intended.
> 
> If there are variables passed as parameter to the env import command,
>those only should be imported in the current environment.
> 
> For each variable passed as parameter, if
>  - foo is bar in current env and bar2 in exported env, after importing
>  exported env, foo shall be bar2,
>  - foo does not exist in current env and foo is bar2 in exported env,
>  after importing exported env, foo shall be bar2,
>  - foo is bar in current env and does not exist in exported env (but is
>  passed as parameter), after importing exported env, foo shall be empty,
> 
> Any variable not passed as parameter should be left untouched.
> 
> Two other tests are made to test that size cannot be '-' if the checksum
> protection is enabled.
> 
> Signed-off-by: Quentin Schulz 
> Reviewed-by: Simon Glass 
> Reviewed-by: Stephen Warren 

This seems to not be working?

https://travis-ci.org/trini/u-boot/jobs/391504525

-- 
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] env: Add !ENV_IS_IN_EXT4 dependency to ENV_IS_NOWHERE

[Tom Rini]

On Fri, Jun 08, 2018 at 07:10:27AM +, Alex Kiernan wrote:

> If ENV_IS_IN_EXT4 is set you shouldn't be able to select ENV_IS_NOWHERE.
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Simon Glass 
> Tested-by: Petr Vorel 

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] AM3517_EVM: Fix Environmental location

[Tom Rini]

On Wed, Jun 06, 2018 at 02:39:50PM -0500, Adam Ford wrote:

> The am3517-evm boards stores the environment in NAND, but after merging
> various configs, the board was trying to load environment variables from
> FAT which would ultimately fail and cause some chatter.
> 
> This patch removes the ENV_IS_IN_FAT flag to eliminate the noise.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> index 8a94fd3ce0..6643f93e33 100644

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] script: Make get_default_envs.sh script exclude tools/env

[Tom Rini]

On Tue, Jun 05, 2018 at 02:28:54PM +0900, Seung-Woo Kim wrote:

> If building envtools, there is env directory in tools directory.
> Make the get_default_envs.sh script exclude tools/env directory.
> 
> Signed-off-by: Seung-Woo Kim 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/4] configs: pcm051: Support distro bootcmds

[Tom Rini]

On Sat, Jun 02, 2018 at 08:22:25PM +0300, Matwey V. Kornilov wrote:

> Add support for distro bootcmds.
> 
> Signed-off-by: Matwey V. Kornilov 

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] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to Kconfig

[Ibai Erkiaga Elorza]

> -Original Message-
> From: Michal Simek [mailto:mon...@monstr.eu]
> Sent: 08 June 2018 06:45
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to
> Kconfig
> 
> On 7.6.2018 14:29, Ibai Erkiaga wrote:
> > Create a new KConfig entry to define FIT image position for SPL RAM
> > mode.
> >
> > Signed-off-by: Ibai Erkiaga 
> > ---
> >
> >  Kconfig  | 7 +++
> >  common/spl/spl_ram.c | 4 
> >  scripts/config_whitelist.txt | 1 -
> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 5a82c95..b619ccc 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -328,6 +328,13 @@ config SPL_LOAD_FIT
> >   particular it can handle selecting from multiple device tree
> >   and passing the correct one to U-Boot.
> >
> > +config SPL_LOAD_FIT_ADDRESS
> > +   hex "SPL FIT Load Address"
> > +   default 0x0
> > +   depends on SPL_LOAD_FIT
> > +   help
> > + Base address from where U-Boot FIT image will be loaded on
> > +SPL boot
> > +
> >  config SPL_LOAD_FIT_FULL
> > bool "Enable SPL loading U-Boot as a FIT"
> > select SPL_FIT
> > diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c index
> > e870193..561d1c0 100644
> > --- a/common/spl/spl_ram.c
> > +++ b/common/spl/spl_ram.c
> > @@ -15,10 +15,6 @@
> >  #include 
> >  #include 
> >
> > -#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
> > -# define CONFIG_SPL_LOAD_FIT_ADDRESS   0
> > -#endif
> > -
> >  static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
> >ulong count, void *buf)  { diff --git
> > a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index
> > e99ba6b..037f038 100644
> > --- a/scripts/config_whitelist.txt
> > +++ b/scripts/config_whitelist.txt
> > @@ -1926,7 +1926,6 @@
> CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER
> >  CONFIG_SPL_INIT_MINIMAL
> >  CONFIG_SPL_JR0_LIODN_NS
> >  CONFIG_SPL_JR0_LIODN_S
> > -CONFIG_SPL_LOAD_FIT_ADDRESS
> 
> Tom is syncing this file time to time that's why you don't need to do it but 
> of
> course you can.
> 
Ok, I will keep it as it will reflect more accurately until Tom clean-ups it.

> Also please convert zynqmp and dra7xx_evm defconfigs.
> 
I guess that means to add this define on each single defconfig that is 
currently using the header, isn't it?

> >  CONFIG_SPL_MAX_FOOTPRINT
> >  CONFIG_SPL_MAX_PEB_SIZE
> >  CONFIG_SPL_MAX_SIZE
> > --
> > 1.8.3.1
> >
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
> 
> you really need to get rid of this.
> 

I was not even aware that I was adding it (I guess email provider does it 
automatically), let see if I can remove it.

> Thanks,
> Michal
> 
> 
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel -
> Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx
> Microblaze/Zynq/ZynqMP SoCs
> 

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

Re: [U-Boot] [U-Boot, 4/4] configs: pcm051: Use am335x-wega-rdk.dtb as fdtfile

[Tom Rini]

On Sat, Jun 02, 2018 at 08:22:28PM +0300, Matwey V. Kornilov wrote:

> In upstream Linux kernel, the fdtfile
> for this specific board is called am335x-wega-rdk.dtb
> 
> Signed-off-by: Matwey V. Kornilov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2] include/linux/byteorder: Sync to latest Linux definitions

[Tom Rini]

On Mon, Jun 04, 2018 at 04:20:50AM +0300, Ramon Fried wrote:

> generic.h has changed in Linux and new addtionals functions were
> added.
> 
> This commit takes the latest and greatest from Linux (v4.17-rc5)
> to aid with porting drivers that utilize these functions.
> 
> Signed-off-by: Ramon Fried 

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] fs: fat: fix wrong casting to unsigned value of sect_to_cluster()

[Tom Rini]

On Mon, Jun 04, 2018 at 08:45:54PM +0900, Seung-Woo Kim wrote:

> After the commit 265edc03d5a1 ("fs/fat: Clean up open-coded sector
> <-> cluster conversions"), it is hung up writing new file to FAT16
> disk with more than 19 files in armv7. It is because result value
> of sect_to_cluster() is not proper by casting from signed value to
> unsigned value. Fix the wrong casting of sect_to_cluster().
> 
> Reported-by: Jaehoon Chung 
> Signed-off-by: Seung-Woo Kim 
> Reviewed-by: Lukasz Majewski 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v3] lib: Add hexdump

[Tom Rini]

On Tue, Jun 05, 2018 at 05:17:57PM +0300, Alexey Brodkin wrote:

> Often during debugging session it's very interesting to see
> what data we were dealing with. For example what we write or read
> to/from memory or peripherals.
> 
> This change introduces functions that allow to dump binary
> data with one simple function invocation like:

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] ARM: am3517_evm: Enable SPL_OF_CONTROL and SPL_OF_PLATDATA

[Tom Rini]

On Fri, Jun 08, 2018 at 09:22:30AM -0500, Adam Ford wrote:

> The SPL doesn't have much room, so in order to support OF_CONTROL
> in SPL, we need the extra functionality of SPL_OF_PLATDATA.
> 
> Adding these features allows us to remove a small part of code without
> losing the serial port during SPL.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/board/logicpd/am3517evm/am3517evm.c 
> b/board/logicpd/am3517evm/am3517evm.c
> index bcd3588818..da8be22085 100644

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,2/2] dra76: fix HDMI HPD pinmux

[Tom Rini]

On Fri, Jun 08, 2018 at 12:51:20PM +0300, Tomi Valkeinen wrote:

> The pin used for HDMI HPD should be set to GPIO mode on DRA76, similarly
> to all the other DRA7 and AM5 SoCs.
> 
> Signed-off-by: Tomi Valkeinen 

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 v2 4/5] lib: Import hexdump.c from Linux

[Alexey Brodkin]

On Wed, 2018-06-13 at 10:24 +0200, Mario Six wrote:
> Hi Alexey,
> 
> On Mon, Jun 4, 2018 at 6:05 PM, Alexey Brodkin
>  wrote:
> > Hi Mario,
> > 
> > On Wed, 2018-05-23 at 14:09 +0200, Mario Six wrote:
> > > Especially for commands, it is useful to be able to turn a hexadecimal
> > > string into its binary representation.
> > > 
> > > Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the
> > > Linux kernel.
> > > 
> > > Signed-off-by: Mario Six 
> > > 
> > > ---
> > > 
> > > v1 -> v2:
> > > New in v2
> > 
> > Something is missing?
> > 
> > Note there was a similar discussion some time ago here:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_633733_=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eVi
> > XO7breS55ytWkhpk5R81I=mnw00As1T_NpnFNncTURuK4YkIAYD-Dj-VTNkRqquVY=HcgjkTO1GdtGqH9sYIjizH30AC3m_Xfa1F6n_Cy_qZY=,
> >  might worth checking.
> > 
> > If of any interest you may pick up my earlier patch and do
> > fix-ups mentioned by Tom:
> >  1. Move hexdump.h away from common.h
> >  2. Update existing users of print_hex_dump() in U-Boot
> > such that they don't use debug level (i.e. drop the first argument)
> > 
> > Or I may do the same re-spin sometime soon.
> > 
> 
> Thanks for your feedback! I saw that you posted a re-spin of your patch;
> Thank you, that's very helpful.

FWIW Tom just pulled that in, see
http://git.denx.de/?p=u-boot.git;a=commit;h=f8c987f8f127f867d96ca74bcd1fcb11d8265b67

> 
> > Still read-on for a couple of comments for your patch.
> > 
> > [snip]
> > 
> > >  /*
> > >   * min()/max()/clamp() macros that also do
> > >   * strict type-checking.. See the
> > > diff --git a/lib/Makefile b/lib/Makefile
> > > index d531ea54b31..0f6d744579f 100644
> > > --- a/lib/Makefile
> > > +++ b/lib/Makefile
> > > @@ -29,6 +29,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o
> > >  obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
> > >  obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
> > >  obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o
> > > +obj-y += hexdump.o
> > 
> > U-Boot might be used on targets with limited memory
> > so having ability to include hexdump or not might be
> > beneficial here. Especially in production builds why would you need hexdump?
> > 
> 
> Yes, it's probably better to have it deactivatable, true. But as for why
> production builds need hexdump: It's not so much the hexdump function, but the
> bin2hex function, which can be used in a number of U-Boot commands that read
> hexadecimal data. We use one such command to initialize a TPM on one of our
> boards, for example.

I spoke a bit too soon as I forgot what I did before :)
We don't disable building of entire hexdump.o instead in hexdump.c we
just put some code in #ifdefs that way you may move bin2hex() outside
#ifdef.

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

Re: [U-Boot] [PATCH 1/3] ARM: HYP/non-sec: save and restore stack

[Mark Kettenis]

> From: Alexander Graf 
> Date: Tue, 12 Jun 2018 22:32:38 +0200
> 
> On 12.06.18 22:17, Mark Kettenis wrote:
> >> From: Alexander Graf 
> >> Date: Tue, 12 Jun 2018 20:46:02 +0200
> >>
> >> On 12.06.18 19:27, Mark Kettenis wrote:
> >>> The current code that switches into HYP mode doesn't bother to set
> >>> up a stack for HYP mode.  This doesn't work for EFI applications
> >>> as they expect a usable stack.  Fix this by saving the stack
> >>> pointer before switching and use it to set SP_hyp from monitor.
> >>> This restores the stack pointer when we drop into HYP mode.
> >>>
> >>> Signed-off-by: Mark Kettenis 
> >>
> >> Can we be sure that the stack in MON is usable from HYP?
> > 
> > I think so.  It is the stack that U-Boot sets up for itself in normal
> > memory.  As far as I can tell arm64 re-uses this stack when dropping
> > down into EL2 as well.
> 
> Well, the question is whether it's secure or non-secure memory. Usually
> the DRAM controller can be configured to have a window of RAM only
> available to secure and I'd certainly hope that at least the U-Boot
> parts that are preserved in EL3 live in such a secured area :)

The U-Boot PSCI implementation ends up in a special memory region and
uses a separate stack in that same region.  Whether that memory region
is marked as secure in hardware depends on board-specific code.  On
the i.MX7D board I'm playing with it ends up in on on-chip RAM but I'm
not sure the current U-Boot code actually marks that region as secure.
In principle the PSCI code is all that is preserved for MON/EL3.  My
diffs really don't change how that works.  The code is already there
and it already works (I assume) when booting Linux kernels in
non-secure mode the traditional (non-EFI) way.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,1/2] dra7/am5: remove CEC pin pull-up

[Tom Rini]

On Fri, Jun 08, 2018 at 12:51:19PM +0300, Tomi Valkeinen wrote:

> HDMI CEC pins are set to pull-up, but CEC requires no pull. Fix this.
> 
> Signed-off-by: Tomi Valkeinen 

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] fs: btrfs: Fix not all CHUNK_ITEMs being read from CHUNK_TREE

[Tom Rini]

On Tue, Jun 05, 2018 at 01:11:01PM +0300, Yevgeny Popovych wrote:

> This causes errors when translating logical addresses to physical:
>   btrfs_map_logical_to_physical: Cannot map logical address  to physical
>   btrfs_file_read: Error reading extent
> 
> The behavior of btrfs_map_logical_to_physical() is to stop traversing
> CHUNK_TREE when it encounters first non-CHUNK_ITEM, which makes
> only some portion of CHUNK_ITEMs being read.
> Change it to skip over non-chunk items.
> 
> Signed-off-by: Yevgeny Popovych 
> Cc: Marek Behun 
> Cc: Sergey Struzh 
> Reviewed-by: Marek Behun 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,u-boot] ARM64: meson: Sync DT with Linux 4.17

[Tom Rini]

On Tue, Jun 05, 2018 at 10:10:44AM +0200, Neil Armstrong wrote:

> Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 
> 4.17.0
> 
> This will enable USB on Amlogic Meson GXL Boards like Khadas VIM, P212 or
> LibreTech-CC.
> 
> Signed-off-by: Neil Armstrong 

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] ARM: DTS: resync a3517.dtsi with Linux 4.17

[Tom Rini]

On Fri, Jun 08, 2018 at 09:26:30AM -0500, Adam Ford wrote:

> Linux 4.17 was just released with some minor changes to the
> am3517.dtsi.  This patch re-syncs the file.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/am3517.dtsi b/arch/arm/dts/am3517.dtsi
> index 00da3f2c40..ca294914bb 100644

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 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Tom Rini]

On Wed, Jun 13, 2018 at 08:32:15AM -0500, Nishanth Menon wrote:
> On 23:05-20180612, Marek Vasut wrote:
> > On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> [..]
> > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> > > + mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
> > > + orr r0, r0, #1 << 0 @ Enable invalidates of BTB
> > 
> > Can we use BIT() macro in the assembler code too ?
> 
> Probably, but just following convention in the rest of the file. Do we
> want to change from existing code?

Agreed, we should follow the existing style (and I'm not 100% sure I
like using BIT() in asm files).

-- 
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] net: zynq_gem: Initialize phyreg variable

[Joe Hershberger]

On Wed, Jun 13, 2018 at 3:33 AM, Michal Simek  wrote:
> In case of phyread()/phy_setup_op() timeout code is working with
> uninitialized phyreg variable. Initialize this variable to make sure
> that code it not working with random value.
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] net: add Socionext AVE ethernet driver support

[Joe Hershberger]

Hi Kunihiko,

https://patchwork.ozlabs.org/patch/919761/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] [PATCH 2/4] soc: qualcomm: Add Shared Memory Manager driver

[Ramon Fried]

On June 13, 2018 4:29:03 AM GMT+03:00, Simon Glass  wrote:
>Hi Ramon,
>
>On 12 June 2018 at 02:50, Ramon Fried  wrote:
>> On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass
> wrote:
>>>Hi Ramon,
>>>
>>>On 11 June 2018 at 13:14, Ramon Fried  wrote:


 On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass 
>>>wrote:
>
> Hi Ramon,
>
> On 9 June 2018 at 03:06, Ramon Fried 
>wrote:
> > The Shared Memory Manager driver implements an interface for
>>>allocating
> > and accessing items in the memory area shared among all of the
> > processors in a Qualcomm platform.
> >
> > Adapted from the Linux driver (4.17)
> >
> > Changes from the original Linux driver:
> > * Removed HW spinlock mechanism, which is irrelevant
> > in U-boot particualar use case, which is just reading from the
>>>smem.
> > * adaptaion from Linux driver model to U-boot's.
> >
> > Cc: Bjorn Andersson 
> > Signed-off-by: Ramon Fried 
> > ---
> >
> >  MAINTAINERS   |   1 +
> >  arch/arm/Kconfig  |   1 +
> >  drivers/Kconfig   |   2 +
> >  drivers/soc/Kconfig   |   5 +
> >  drivers/soc/Makefile  |   1 +
> >  drivers/soc/qualcomm/Kconfig  |  11 +
> >  drivers/soc/qualcomm/Makefile |   3 +
> >  drivers/soc/qualcomm/smem.c   | 934
>>>++
> >  8 files changed, 958 insertions(+)
> >  create mode 100644 drivers/soc/Kconfig
> >  create mode 100644 drivers/soc/qualcomm/Kconfig
> >  create mode 100644 drivers/soc/qualcomm/Makefile
> >  create mode 100644 drivers/soc/qualcomm/smem.c
>
> Sorry, but NAK on this.
>
> This patch supports direct calls into a driver which is not
>allowed.
> This should be done through the driver's uclass API, not through
> direct calls.
>
 Hi Simon,
 I see your point.
 As you probably see, I was looking at the DM framework for the
>>>convenience
 it
 gives with binding device-tree nodes and drivers.
 If it's not an option I'll rewrite it as as arch-code under
>>>mach-snapdragon.
 Thanks,
 Ramon.
>>>
>>>You are correct that you should be using driver model. It's that you
>>>need to do it fully, with a proper API. There are lots of examples.
>>>
>> Doesn't it make sense to add some facility  for drivers that don't
>export common functionalities. Like Linux platform drivers?
>
>Well this is how things used to work in U-Boot before driver model.
>
>Now we are trying to move things to driver model.
>
>It does not look like you have many calls, so it should be easy enough
>to move it to a uclass.
That's what I'll do. 
Thanks. 
>
>You can also add a command to access the device. People can see the
>tree of devices with 'dm tree', etc.
>
>Regards,
>Simon


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/5] include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET)

[Joe Hershberger]

On Tue, Jun 12, 2018 at 9:23 PM, Ley Foon Tan  wrote:
> On Wed, Jun 13, 2018 at 5:02 AM, Joe Hershberger  
> wrote:
>> On Mon, Jun 4, 2018 at 2:19 AM, Ley Foon Tan  wrote:
>>> Change to use CONFIG_IS_ENABLED(DM_RESET), so this can work in SPL
>>> build (CONFIG_SPL_DM_RESET) and U-boot build (CONFIG_DM_RESET).
>>>
>>> Signed-off-by: Ley Foon Tan 
>>> ---
>>>  include/reset.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/reset.h b/include/reset.h
>>> index 201bafc..a7bbc1c 100644
>>> --- a/include/reset.h
>>> +++ b/include/reset.h
>>> @@ -77,7 +77,7 @@ struct reset_ctl_bulk {
>>> unsigned int count;
>>>  };
>>>
>>> -#ifdef CONFIG_DM_RESET
>>> +#if CONFIG_IS_ENABLED(DM_RESET)
>>
>> This seems like it would be more reasonable to squash into the first
>> patch of this series.
> We need to rename SPL_RESET_SUPPORT to SPL_DM_RESET in the first patch.
> Otherwise it will have redefinition of reset-class API compilation
> errors in SPL build if we move this patch to first patch.

I wasn't suggesting to switch the order, I was suggesting to combine
them. Squash.

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

Re: [U-Boot] [U-Boot, v4, 2/2] test/py: add test for whitelist of variables while importing environment

[Quentin Schulz]

Hi Tom,

On Wed, Jun 13, 2018 at 11:43:32AM -0400, Tom Rini wrote:
> On Mon, Jun 04, 2018 at 11:47:30AM +0200, Quentin Schulz wrote:
> 
> > This tests that the importing of an environment with a specified
> > whitelist works as intended.
> > 
> > If there are variables passed as parameter to the env import command,
> >those only should be imported in the current environment.
> > 
> > For each variable passed as parameter, if
> >  - foo is bar in current env and bar2 in exported env, after importing
> >  exported env, foo shall be bar2,
> >  - foo does not exist in current env and foo is bar2 in exported env,
> >  after importing exported env, foo shall be bar2,
> >  - foo is bar in current env and does not exist in exported env (but is
> >  passed as parameter), after importing exported env, foo shall be empty,
> > 
> > Any variable not passed as parameter should be left untouched.
> > 
> > Two other tests are made to test that size cannot be '-' if the checksum
> > protection is enabled.
> > 
> > Signed-off-by: Quentin Schulz 
> > Reviewed-by: Simon Glass 
> > Reviewed-by: Stephen Warren 
> 
> This seems to not be working?
> 
> https://travis-ci.org/trini/u-boot/jobs/391504525
> 

I just rebased on top of v2018.07-rc1, ran
make mrproper
./test/py/test.py --bd sandbox --build

and the tests run fine until one error in some tests *after* the env
test suite has passed. See log:
http://code.bulix.org/iojwnp-358559

It's dirty because I had to remove NO_SDL to make sandbox to compile
$ git diff
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 1a49d1dab5..a76fc384c2 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -74,10 +74,6 @@
 #define CONFIG_BOOTP_SERVERIP
 #define CONFIG_IP_DEFRAG
 
-#ifndef SANDBOX_NO_SDL
-#define CONFIG_SANDBOX_SDL
-#endif
-
 /* LCD and keyboard require SDL support */
 #ifdef CONFIG_SANDBOX_SDL
 #define LCD_BPPLCD_COLOR16

Can I have more info on how to reproduce this error please?

Thanks,

Quentin


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

Re: [U-Boot] net: cpsw: ti: Reap completed packets before stopping interface

[Joe Hershberger]

Hi Alex,

https://patchwork.ozlabs.org/patch/912382/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: Protect net_state from reentrant net_loop()

[Joe Hershberger]

Hi Leonid,

https://patchwork.ozlabs.org/patch/910202/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS

[Russell King - ARM Linux]

On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> > Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> > function to setup the bits, we are able to override the settings.
> > 
> > Without this enabled, Linux kernel reports:
> > CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, 
> > system vulnerable
> > 
> > With this enabled, Linux kernel reports:
> > CPU0: Spectre v2: using ICIALLU workaround
> > 
> > NOTE: This by itself does not enable the workaround for CPU1 (on
> > OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> > 
> > Signed-off-by: Nishanth Menon 
> > ---
> >  arch/arm/mach-omap2/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 3bb1ecb58de0..77820cc8d1e4 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -53,6 +53,7 @@ config OMAP54XX
> > bool "OMAP54XX SoC"
> > select ARM_ERRATA_798870
> > select SYS_THUMB_BUILD
> > +   select ARM_CORTEX_A15_CVE_2017_5715
> > imply NAND_OMAP_ELM
> > imply NAND_OMAP_GPMC
> > imply SPL_DISPLAY_PRINT
> > 
> 
> Can this be enabled for all CA15 systems somehow ? I am sure there are
> more that are vulnerable.

I think you're missing the point.

Spectre affects the _entire_ system.  Working around it in just the
kernel does not mean that the system is no longer vulnerable.

Fixing the "system" means implementing the fixes also in the secure
world, which on A15 and A8 also means setting the IBE bit there.  If
the IBE bit is set in the secure world, it will also be set in the
non-secure world.

The fact that the kernel is complaining is telling you that the
system as a whole does not have the workarounds in place to mitigate
against the vulnerability.  Merely setting the IBE bit via some
secure API doesn't "magically" fix the secure world.

So, even if you were to set the IBE bit via some magic secure API,
the fact still remains: even with these workarounds in place, as I
understand it, the _system as a whole_ remains vulnerable - you
might as well _not_ have the kernel workarounds.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] soc: qualcomm: Add Shared Memory Manager driver

[Ramon Fried]

On June 9, 2018 2:17:45 PM GMT+03:00, Heinrich Schuchardt  
wrote:
>On 06/09/2018 12:29 PM, Ramon Fried wrote:
>> On Sat, Jun 9, 2018 at 1:12 PM, Heinrich Schuchardt
> wrote:
>>> On 06/09/2018 01:06 PM, Ramon Fried wrote:
 The Shared Memory Manager driver implements an interface for
>allocating
 and accessing items in the memory area shared among all of the
 processors in a Qualcomm platform.

 Adapted from the Linux driver (4.17)
>>>
>>> Please, run scripts/checkpatch on this patch an fix all errors and
>>> warnings, e.g.
>> Hi Heinrich,
>> Actually I did run it, and I also run it in Linux and got the same
>results.
>> I thought it will be better to keep the driver aligned to Linux than
>> to fix these warnings.
>> But if can surely fix it, what do you suggest ?
>
>At least add a comment in the commit message why you diverge from our
>coding standard.
>
I just sent checkpatch fixes to the Linux kernel list. Hopefully it will be 
accepted. 
BTW. I'm replacing Mateusz as the maintainer for arch-snapdragon,
Thanks, Ramon 
>As Mateusz will be the maintainer he should decide.
>
>Best regards
>
>Heinrich


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: zynq_gem: Fix return type for phy...()

[Joe Hershberger]

On Wed, Jun 13, 2018 at 3:00 AM, Michal Simek  wrote:
> wait_for_bit_le32 returns negative value on failure. Fix phy...() to
> handle these failures properly.
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [U-Boot, v4, 2/2] test/py: add test for whitelist of variables while importing environment

[Stephen Warren]

On 06/13/2018 12:53 PM, Quentin Schulz wrote:

Hi Tom,

On Wed, Jun 13, 2018 at 11:43:32AM -0400, Tom Rini wrote:

On Mon, Jun 04, 2018 at 11:47:30AM +0200, Quentin Schulz wrote:


This tests that the importing of an environment with a specified
whitelist works as intended.

If there are variables passed as parameter to the env import command,
those only should be imported in the current environment.

For each variable passed as parameter, if
  - foo is bar in current env and bar2 in exported env, after importing
  exported env, foo shall be bar2,
  - foo does not exist in current env and foo is bar2 in exported env,
  after importing exported env, foo shall be bar2,
  - foo is bar in current env and does not exist in exported env (but is
  passed as parameter), after importing exported env, foo shall be empty,

Any variable not passed as parameter should be left untouched.

Two other tests are made to test that size cannot be '-' if the checksum
protection is enabled.

Signed-off-by: Quentin Schulz 
Reviewed-by: Simon Glass 
Reviewed-by: Stephen Warren 


This seems to not be working?

https://travis-ci.org/trini/u-boot/jobs/391504525



I just rebased on top of v2018.07-rc1, ran
make mrproper
./test/py/test.py --bd sandbox --build

and the tests run fine ...


Most likely the failure is due to the test relying on some feature that 
isn't enabled on the board being tested (emulated via qemu); you'll need 
to add something like the following to indicate which feature the test 
relies upon:


@pytest.mark.buildconfigspec('cmd_echo')

All the test commands are in .travis.yml in the top-level of the U-Boot 
source tree. You can see the exact error at the very end of the log that 
Tom linked to.

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

Re: [U-Boot] net: Express LINK_LOCAL dependency on LIB_RAND

[Joe Hershberger]

Hi Joe,

https://patchwork.ozlabs.org/patch/906803/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net/phy/cortina: Add support for CS4223 PHY

[Joe Hershberger]

Hi Vicentiu,

https://patchwork.ozlabs.org/patch/907515/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] [PATCH] net: gem: Check return value from mealign/malloc

[Joe Hershberger]

On Wed, Jun 13, 2018 at 8:20 AM, Michal Simek  wrote:
> Functions can return NULL in case of error that's why checking return
> value is needed.
>
> Signed-off-by: Michal Simek 

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

[U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

Hi Tom,

The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7:

  ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-net.git master

for you to fetch changes up to 5b2c9a6ce3ce66796e8c375133da8340c7ab2adc:

  net: gem: Check return value from memalign/malloc (2018-06-13 13:59:04 -0500)


Alex Kiernan (1):
  net: cpsw: ti: Reap completed packets before stopping interface

Chris Packham (2):
  net: phy: mv88e61xx: Force CPU port link up
  net: mvgbe: extract common code for SMI wait

Joe Hershberger (2):
  net: Express LINK_LOCAL dependency on LIB_RAND
  net: sunxi: Correct MAC address register order

Jon Nettleton (1):
  mvebu: neta: align DMA buffers

Kunihiko Hayashi (2):
  net: include/phy.h: add new mode for internal phy
  net: add Socionext AVE ethernet driver support

Leonid Iziumtsev (1):
  net: Protect net_state from reentrant net_loop()

Mario Six (3):
  net: Always align tx packets
  net: Initialize as many ethernet devices as possible
  tsec: Fix reading phy registers from DT

Michal Simek (3):
  net: zynq_gem: Fix return type for phy...()
  net: zynq_gem: Initialize phyreg variable
  net: gem: Check return value from memalign/malloc

Quentin Schulz (1):
  net: designware: set the PS bit when resetting DMA bus in MII 
configuration

Radu Bulie (1):
  drivers/net/vsc9953: Initialize action RAM in VCAP complex

Vasily Khoruzhick (1):
  net: nfs: don't fail when nfs_read_reply returns -NFS_RPC_DROP

Vicentiu Galanopulo (1):
  net/phy/cortina: Add support for CS4223 PHY

 cmd/Kconfig |   1 +
 drivers/net/Kconfig |  10 +
 drivers/net/Makefile|   1 +
 drivers/net/cpsw.c  |  24 +-
 drivers/net/designware.c|   9 +
 drivers/net/mvgbe.c |  47 +--
 drivers/net/mvgbe.h |   1 +
 drivers/net/mvneta.c|  18 +-
 drivers/net/phy/cortina.c   |  48 ++-
 drivers/net/phy/mv88e61xx.c |  51 ++-
 drivers/net/sni_ave.c   | 995 
 drivers/net/sunxi_emac.c|   4 +-
 drivers/net/tsec.c  |   5 +-
 drivers/net/vsc9953.c   | 134 ++
 drivers/net/zynq_gem.c  |  16 +-
 include/cortina.h   |   4 +
 include/phy.h   |   3 +
 include/vsc9953.h   |  70 
 net/arp.c   |   3 +-
 net/eth-uclass.c|   4 +-
 net/net.c   |   3 +
 net/nfs.c   |   2 +
 net/ping.c  |   3 +-
 23 files changed, 1383 insertions(+), 73 deletions(-)
 create mode 100644 drivers/net/sni_ave.c

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

Re: [U-Boot] net: Always align tx packets

[Joe Hershberger]

Hi Mario,

https://patchwork.ozlabs.org/patch/892179/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: Initialize as many ethernet devices as possible

[Joe Hershberger]

Hi Mario,

https://patchwork.ozlabs.org/patch/905737/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] tsec: Fix reading phy registers from DT

[Joe Hershberger]

Hi Mario,

https://patchwork.ozlabs.org/patch/905736/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] drivers/net/vsc9953: Initialize action RAM in VCAP complex

[Joe Hershberger]

Hi Kunihiko,

https://patchwork.ozlabs.org/patch/915965/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: include/phy.h: add new mode for internal phy

[Joe Hershberger]

Hi Radu,

https://patchwork.ozlabs.org/patch/917806/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: sunxi: Correct MAC address register order

[Joe Hershberger]

Hi Joe,

https://patchwork.ozlabs.org/patch/907230/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: gem: Check return value from memalign/malloc

[Joe Hershberger]

Hi Michal,

https://patchwork.ozlabs.org/patch/928884/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: nfs: don't fail when nfs_read_reply returns -NFS_RPC_DROP

[Joe Hershberger]

Hi Vasily,

https://patchwork.ozlabs.org/patch/913047/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] [PATCH] usb: sunxi: don't touch reset bits in ccm if CONFIG_SUNXI_GEN_SUN6I is not defined

[Chen-Yu Tsai]

On Thu, Jun 14, 2018 at 11:04 AM, Vasily Khoruzhick  wrote:
> CCM in sun4i and sun5i doesn't have reset.
>
> Fixes commit 1ed9c1118 ("usb: sunxi: ehci: get rid of ifdefs")
> and commit 56830cee3 ("usb: sunxi: ohci: get rid of ifdefs")
>
> Signed-off-by: Vasily Khoruzhick 
> ---
>  drivers/usb/host/ehci-sunxi.c | 10 --
>  drivers/usb/host/ohci-sunxi.c | 10 --
>  2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
> index 35fbe03331..f5b661ef12 100644
> --- a/drivers/usb/host/ehci-sunxi.c
> +++ b/drivers/usb/host/ehci-sunxi.c
> @@ -85,9 +85,12 @@ no_phy:
>
> setbits_le32(>ccm->ahb_gate0,
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
> -   if (priv->cfg->has_reset)
> +   if (priv->cfg->has_reset) {
> +#ifdef CONFIG_SUNXI_GEN_SUN6I

The "has_reset" field is supposed to deal with this. Is it not working?

ChenYu

> setbits_le32(>ccm->ahb_reset0_cfg,
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
> +#endif
> +   }
>
> hcor = (struct ehci_hcor *)((uintptr_t)hccr +
> HC_LENGTH(ehci_readl(>cr_capbase)));
> @@ -112,8 +115,11 @@ static int ehci_usb_remove(struct udevice *dev)
> if (ret)
> return ret;
>
> -   if (priv->cfg->has_reset)
> +   if (priv->cfg->has_reset) {
> +#ifdef CONFIG_SUNXI_GEN_SUN6I
> clrbits_le32(>ccm->ahb_reset0_cfg, priv->ahb_gate_mask);
> +#endif
> +   }
> clrbits_le32(>ccm->ahb_gate0, priv->ahb_gate_mask);
>
> return 0;
> diff --git a/drivers/usb/host/ohci-sunxi.c b/drivers/usb/host/ohci-sunxi.c
> index 2b99169da6..c8c9e1d2fe 100644
> --- a/drivers/usb/host/ohci-sunxi.c
> +++ b/drivers/usb/host/ohci-sunxi.c
> @@ -92,9 +92,12 @@ no_phy:
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
> setbits_le32(>ccm->usb_clk_cfg,
>  priv->usb_gate_mask | priv->cfg->extra_usb_gate_mask);
> -   if (priv->cfg->has_reset)
> +   if (priv->cfg->has_reset) {
> +#ifdef CONFIG_SUNXI_GEN_SUN6I
> setbits_le32(>ccm->ahb_reset0_cfg,
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
> +#endif
> +   }
>
> return ohci_register(dev, regs);
>  }
> @@ -116,8 +119,11 @@ static int ohci_usb_remove(struct udevice *dev)
> if (ret)
> return ret;
>
> -   if (priv->cfg->has_reset)
> +   if (priv->cfg->has_reset) {
> +#ifdef CONFIG_SUNXI_GEN_SUN6I
> clrbits_le32(>ccm->ahb_reset0_cfg, priv->ahb_gate_mask);
> +#endif
> +   }
> clrbits_le32(>ccm->usb_clk_cfg, priv->usb_gate_mask);
> clrbits_le32(>ccm->ahb_gate0, priv->ahb_gate_mask);
>
> --
> 2.17.1
>
> ___
> 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] usb: sunxi: don't touch reset bits in ccm if CONFIG_SUNXI_GEN_SUN6I is not defined

[Vasily Khoruzhick]

On Wed, Jun 13, 2018 at 8:23 PM, Chen-Yu Tsai  wrote:

>> +   if (priv->cfg->has_reset) {
>> +#ifdef CONFIG_SUNXI_GEN_SUN6I
>
> The "has_reset" field is supposed to deal with this. Is it not working?

There's no ahb_reset0_cfg in ccm on sun4i and sun5i, so compilation fails with

drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
no member named 'ahb_reset0_cfg'

(And similar error for ehci-sunxi.c)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: rmobile: Enable RPCHF on Draak

[Marek Vasut]

Enable the Renesas RPC HF driver on R8A77995 D3 Draak.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a77995_draak_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/r8a77995_draak_defconfig b/configs/r8a77995_draak_defconfig
index d3cccec8fc..f451950add 100644
--- a/configs/r8a77995_draak_defconfig
+++ b/configs/r8a77995_draak_defconfig
@@ -46,6 +46,7 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_RENESAS_RPC_HF=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
-- 
2.17.1

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

[U-Boot] [PATCH] clk: rmobile: Add R8A77995 RPC clock

[Marek Vasut]

Add missing RPC entry into the R8A77995 clock driver tables.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/clk/renesas/r8a77995-cpg-mssr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c 
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index 17592db3d3..e9c3aec960 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -41,6 +41,7 @@ enum clk_ids {
CLK_S2,
CLK_S3,
CLK_SDSRC,
+   CLK_RPCSRC,
CLK_SSPSRC,
 
/* Module Clocks */
@@ -67,6 +68,7 @@ static const struct cpg_core_clk r8a77995_core_clks[] = {
DEF_FIXED(".s2",   CLK_S2, CLK_PLL1,   4, 1),
DEF_FIXED(".s3",   CLK_S3, CLK_PLL1,   6, 1),
DEF_FIXED(".sdsrc",CLK_SDSRC,  CLK_PLL1,   2, 1),
+   DEF_FIXED(".rpcsrc",   CLK_RPCSRC, CLK_PLL1,   2, 1),
 
/* Core Clock Outputs */
DEF_FIXED("z2",R8A77995_CLK_Z2,CLK_PLL0D3, 1, 1),
@@ -89,6 +91,8 @@ static const struct cpg_core_clk r8a77995_core_clks[] = {
DEF_FIXED("osc",   R8A77995_CLK_OSC,   CLK_EXTAL,384, 1),
DEF_FIXED("r", R8A77995_CLK_R, CLK_EXTAL,   1536, 1),
 
+   DEF_GEN3_RPC("rpc",R8A77995_CLK_RPC,   CLK_RPCSRC,0x238),
+
DEF_GEN3_PE("s1d4c",   R8A77995_CLK_S1D4C, CLK_S1, 4, CLK_PE, 2),
DEF_GEN3_PE("s3d1c",   R8A77995_CLK_S3D1C, CLK_S3, 1, CLK_PE, 1),
DEF_GEN3_PE("s3d2c",   R8A77995_CLK_S3D2C, CLK_S3, 2, CLK_PE, 2),
@@ -153,6 +157,7 @@ static const struct mssr_mod_clk r8a77995_mod_clks[] = {
DEF_MOD("can-fd",914,   R8A77995_CLK_S3D2),
DEF_MOD("can-if1",   915,   R8A77995_CLK_S3D4),
DEF_MOD("can-if0",   916,   R8A77995_CLK_S3D4),
+   DEF_MOD("rpc",   917,   R8A77995_CLK_RPC),
DEF_MOD("i2c3",  928,   R8A77995_CLK_S3D2),
DEF_MOD("i2c2",  929,   R8A77995_CLK_S3D2),
DEF_MOD("i2c1",  930,   R8A77995_CLK_S3D2),
-- 
2.17.1

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

Re: [U-Boot] net: mvgbe: extract common code for SMI wait

[Joe Hershberger]

Hi Chris,

https://patchwork.ozlabs.org/patch/927112/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS

[Marek Vasut]

On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote:
> On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
>> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
>>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
>>> function to setup the bits, we are able to override the settings.
>>>
>>> Without this enabled, Linux kernel reports:
>>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, 
>>> system vulnerable
>>>
>>> With this enabled, Linux kernel reports:
>>> CPU0: Spectre v2: using ICIALLU workaround
>>>
>>> NOTE: This by itself does not enable the workaround for CPU1 (on
>>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
>>>
>>> Signed-off-by: Nishanth Menon 
>>> ---
>>>  arch/arm/mach-omap2/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>> index 3bb1ecb58de0..77820cc8d1e4 100644
>>> --- a/arch/arm/mach-omap2/Kconfig
>>> +++ b/arch/arm/mach-omap2/Kconfig
>>> @@ -53,6 +53,7 @@ config OMAP54XX
>>> bool "OMAP54XX SoC"
>>> select ARM_ERRATA_798870
>>> select SYS_THUMB_BUILD
>>> +   select ARM_CORTEX_A15_CVE_2017_5715
>>> imply NAND_OMAP_ELM
>>> imply NAND_OMAP_GPMC
>>> imply SPL_DISPLAY_PRINT
>>>
>>
>> Can this be enabled for all CA15 systems somehow ? I am sure there are
>> more that are vulnerable.
> 
> I think you're missing the point.

Please read the patch again.

This enables it only for a specific SoC. My point being, this should be
enabled for all SoCs with CA15, not just some select few.

> Spectre affects the _entire_ system.  Working around it in just the
> kernel does not mean that the system is no longer vulnerable.
> 
> Fixing the "system" means implementing the fixes also in the secure
> world, which on A15 and A8 also means setting the IBE bit there.  If
> the IBE bit is set in the secure world, it will also be set in the
> non-secure world.
> 
> The fact that the kernel is complaining is telling you that the
> system as a whole does not have the workarounds in place to mitigate
> against the vulnerability.  Merely setting the IBE bit via some
> secure API doesn't "magically" fix the secure world.
> 
> So, even if you were to set the IBE bit via some magic secure API,
> the fact still remains: even with these workarounds in place, as I
> understand it, the _system as a whole_ remains vulnerable - you
> might as well _not_ have the kernel workarounds.
> 


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

[U-Boot] [PATCH] clk: rmobile: Add R8A77990 RPC clock

[Marek Vasut]

Add missing RPC entry into the R8A77990 clock driver tables.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/clk/renesas/r8a77990-cpg-mssr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c 
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index b3614a1355..1198ec5cbf 100644
--- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -43,6 +43,7 @@ enum clk_ids {
CLK_S2,
CLK_S3,
CLK_SDSRC,
+   CLK_RPCSRC,
 
/* Module Clocks */
MOD_CLK_BASE
@@ -70,6 +71,7 @@ static const struct cpg_core_clk r8a77990_core_clks[] = {
DEF_FIXED(".s2",   CLK_S2, CLK_PLL1,   4, 1),
DEF_FIXED(".s3",   CLK_S3, CLK_PLL1,   6, 1),
DEF_FIXED(".sdsrc",CLK_SDSRC,  CLK_PLL1,   2, 1),
+   DEF_FIXED(".rpcsrc",   CLK_RPCSRC, CLK_PLL1,   2, 1),
 
/* Core Clock Outputs */
DEF_FIXED("za2",   R8A77990_CLK_ZA2,   CLK_PLL0D24,1, 1),
@@ -96,6 +98,8 @@ static const struct cpg_core_clk r8a77990_core_clks[] = {
DEF_GEN3_SD("sd1", R8A77990_CLK_SD1,   CLK_SDSRC, 0x0078),
DEF_GEN3_SD("sd3", R8A77990_CLK_SD3,   CLK_SDSRC, 0x026c),
 
+   DEF_GEN3_RPC("rpc",R8A77990_CLK_RPC,   CLK_RPCSRC,0x238),
+
DEF_FIXED("cl",R8A77990_CLK_CL,CLK_PLL1,  48, 1),
DEF_FIXED("cp",R8A77990_CLK_CP,CLK_EXTAL,  2, 1),
DEF_FIXED("cpex",  R8A77990_CLK_CPEX,  CLK_EXTAL,  4, 1),
@@ -194,6 +198,7 @@ static const struct mssr_mod_clk r8a77990_mod_clks[] = {
DEF_MOD("can-fd",914,   R8A77990_CLK_S3D2),
DEF_MOD("can-if1",   915,   R8A77990_CLK_S3D4),
DEF_MOD("can-if0",   916,   R8A77990_CLK_S3D4),
+   DEF_MOD("rpc",   917,   R8A77990_CLK_RPC),
DEF_MOD("i2c6",  918,   R8A77990_CLK_S3D2),
DEF_MOD("i2c5",  919,   R8A77990_CLK_S3D2),
DEF_MOD("i2c-dvfs",  926,   R8A77990_CLK_CP),
-- 
2.17.1

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

[U-Boot] [PATCH 3/4] ARM: dts: rmobile: Add initial SDHI nodes to R8A77990 E3

[Marek Vasut]

Add SDHI nodes to R8A77990 E3 SoC to allow SDHI operation.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77990.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/dts/r8a77990.dtsi b/arch/arm/dts/r8a77990.dtsi
index 4f77be2a60..6d2d5e1068 100644
--- a/arch/arm/dts/r8a77990.dtsi
+++ b/arch/arm/dts/r8a77990.dtsi
@@ -185,6 +185,30 @@
reg = <0 0xe616 0 0x0200>;
};
 
+   sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a77990";
+   reg = <0 0xee10 0 0x2000>;
+   clocks = < CPG_MOD 314>;
+   max-frequency = <2>;
+   status = "disabled";
+   };
+
+   sdhi1: sd@ee12 {
+   compatible = "renesas,sdhi-r8a77990";
+   reg = <0 0xee12 0 0x2000>;
+   clocks = < CPG_MOD 313>;
+   max-frequency = <2>;
+   status = "disabled";
+   };
+
+   sdhi3: sd@ee16 {
+   compatible = "renesas,sdhi-r8a77990";
+   reg = <0 0xee16 0 0x2000>;
+   clocks = < CPG_MOD 311>;
+   max-frequency = <2>;
+   status = "disabled";
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a77990-sysc";
reg = <0 0xe618 0 0x0400>;
-- 
2.17.1

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

[U-Boot] [PATCH 1/4] ARM: dts: rmobile: Add Renesas RPC HF/QSPI DT node to R8A77990

[Marek Vasut]

Add device tree nodes for the Renesas RPC HF/QSPI controller
to R8A77990 E3.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77990.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/r8a77990.dtsi b/arch/arm/dts/r8a77990.dtsi
index be4f519711..4f77be2a60 100644
--- a/arch/arm/dts/r8a77990.dtsi
+++ b/arch/arm/dts/r8a77990.dtsi
@@ -269,6 +269,14 @@
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
};
+
+   rpc: rpc@0xee20 {
+   compatible = "renesas,rpc-r8a77990", "renesas,rpc";
+   reg = <0 0xee20 0 0x100>, <0 0x0800 0 0>;
+   clocks = < CPG_MOD 917>;
+   bank-width = <2>;
+   status = "disabled";
+   };
};
 
timer {
-- 
2.17.1

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

Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

On 15:46-20180613, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 08:32:15AM -0500, Nishanth Menon wrote:
> > On 23:05-20180612, Marek Vasut wrote:
> > > On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> > [..]
> > > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> > > > +   mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
> > > > +   orr r0, r0, #1 << 0 @ Enable invalidates of BTB
> > > 
> > > Can we use BIT() macro in the assembler code too ?
> > 
> > Probably, but just following convention in the rest of the file. Do we
> > want to change from existing code?
> 
> Agreed, we should follow the existing style (and I'm not 100% sure I
> like using BIT() in asm files).

OK. Will drop this feedback about BIT() macro if I have to do a v2.

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

Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS

[Nishanth Menon]

On 20:36-20180613, Marek Vasut wrote:
> On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote:
> > On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
> >> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> >>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> >>> function to setup the bits, we are able to override the settings.
> >>>
> >>> Without this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE 
> >>> bit, system vulnerable
> >>>
> >>> With this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: using ICIALLU workaround
> >>>
> >>> NOTE: This by itself does not enable the workaround for CPU1 (on
> >>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> >>>
> >>> Signed-off-by: Nishanth Menon 
> >>> ---
> >>>  arch/arm/mach-omap2/Kconfig | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> >>> index 3bb1ecb58de0..77820cc8d1e4 100644
> >>> --- a/arch/arm/mach-omap2/Kconfig
> >>> +++ b/arch/arm/mach-omap2/Kconfig
> >>> @@ -53,6 +53,7 @@ config OMAP54XX
> >>>   bool "OMAP54XX SoC"
> >>>   select ARM_ERRATA_798870
> >>>   select SYS_THUMB_BUILD
> >>> + select ARM_CORTEX_A15_CVE_2017_5715
> >>>   imply NAND_OMAP_ELM
> >>>   imply NAND_OMAP_GPMC
> >>>   imply SPL_DISPLAY_PRINT
> >>>
> >>
> >> Can this be enabled for all CA15 systems somehow ? I am sure there are
> >> more that are vulnerable.
> > 
> > I think you're missing the point.
> 
> Please read the patch again.
> 
> This enables it only for a specific SoC. My point being, this should be
> enabled for all SoCs with CA15, not just some select few.
> 

As I had previously responded in
https://marc.info/?l=u-boot=152889727127549=2

I am not disagreeing this needs to be done for all CA15 based SoCs
(and A8s for previous patches ...), but.. I am not sure what you'd
like me to do here -> I just dont know what the SMC convention is
for all SoCs with CA15! I can help with TI SoCs for sure.. but then,
Russell has a point that this is just one part of the solution -> on
devices that provide secure services, there is definitely a need to
lock the secure entry points down as well. But, specifically to this
patch, do recommend an alternative if one exists.. will gladly follow.

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

Re: [U-Boot] net: phy: mv88e61xx: Force CPU port link up

[Joe Hershberger]

Hi Chris,

https://patchwork.ozlabs.org/patch/924667/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: zynq_gem: Initialize phyreg variable

[Joe Hershberger]

Hi Michal,

https://patchwork.ozlabs.org/patch/928754/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] mvebu: neta: align DMA buffers

[Joe Hershberger]

Hi Baruch,

https://patchwork.ozlabs.org/patch/922540/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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