[U-Boot] [PATCH v3] tegra: nyan-big: Update CONFIG_SYS_TEXT to the default in README.chromium

2018-06-09 Thread Peter Robinson
To build U-Boot on a Nyan Big Chromebook the docs outline adjusting the Tegra124
defined CONFIG_SYS_TEXT_BASE but this has since been moved to individual config
files. We should have the default required for U-Boot chain loading on the
chromebook as the default CONFIG_SYS_TEXT_BASE and update the docs to remove
this now non required step.

Signed-off-by: Peter Robinson 
---

v3: Update commit message
v2: Update to 2018.07 RC1

 configs/nyan-big_defconfig |  2 +-
 doc/README.chromium| 27 +++
 2 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/configs/nyan-big_defconfig b/configs/nyan-big_defconfig
index 8868d1f9e10..3b64c643716 100644
--- a/configs/nyan-big_defconfig
+++ b/configs/nyan-big_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TEGRA=y
-CONFIG_SYS_TEXT_BASE=0x8011
+CONFIG_SYS_TEXT_BASE=0x81000100
 CONFIG_DEBUG_UART_BASE=0x70006000
 CONFIG_DEBUG_UART_CLOCK=40800
 CONFIG_TEGRA124=y
diff --git a/doc/README.chromium b/doc/README.chromium
index 7bf4d874474..45eaeced2da 100644
--- a/doc/README.chromium
+++ b/doc/README.chromium
@@ -43,26 +43,13 @@ 
https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big
 https://lists.denx.de/pipermail/u-boot/2017-May/289491.html
 
https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card
 
-1. Patch U-Boot
-
-Open include/configs/tegra124-common.h
-
-Change:
-
-#define CONFIG_SYS_TEXT_BASE   0x8011
-
-to:
-
-#define CONFIG_SYS_TEXT_BASE   0x81000100
-
-
-2. Build U-Boot
+1. Build U-Boot
 
mkdir b
make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig 
all
 
 
-3. Select a .its file
+2. Select a .its file
 
 Select something from doc/chromium which matches your board, or create your
 own.
@@ -72,7 +59,7 @@ used by U-Boot. This is because the Chromebook expects to 
pass it to the
 kernel, and crashes if it is not present.
 
 
-4. Build and sign an image
+3. Build and sign an image
 
./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit
echo test >dummy.txt
@@ -82,7 +69,7 @@ kernel, and crashes if it is not present.
--bootloader dummy.txt --pack u-boot.kpart
 
 
-5. Prepare an SD card
+4. Prepare an SD card
 
DISK=/dev/sdc   # Replace with your actual SD card device
sudo cgpt create $DISK
@@ -91,12 +78,12 @@ kernel, and crashes if it is not present.
sudo gdisk $DISK   # Enter command 'w' to write a protective MBR to the disk
 
 
-6. Write U-Boot to the SD card
+5. Write U-Boot to the SD card
 
sudo dd if=u-boot.kpart of=/dev/sdc1; sync
 
 
-7. Start it up
+6. Start it up
 
 Reboot the device in dev mode. Make sure that you have USB booting enabled. To
 do this, login as root (via Ctrl-Alt-forward_arrow) and type
@@ -115,7 +102,7 @@ mode screen. It should show something like the following on 
the display:
Tegra124 (Nyan-big) #
 
 
-8. Known problems
+7. Known problems
 
 On the serial console the word MMC is chopped at the start of the line:
 
-- 
2.17.1

___
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

2018-06-09 Thread Mian Yousaf Kaukab

On 06/08/2018 08:09 PM, Dr. Philipp Tomsich wrote:

Mian,

Did you change anything or is this just a resend with the same content?

Its a resend with the same content. Just sending both patches together.


I didn’t have a chance to review this yet, so wanted to make sure I work off
the latest version...

Thanks,
Philipp.


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


[U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

2018-06-09 Thread Adam Ford
When enabling BLOCK_CACHE on devices with limited RAM during SPL,
some devices may not boot.  This creates an option to enable
block caching in SPL by defaults off.  It is dependent on BLOCK_CACHE
and SPL_BLK

Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")

Signed-off-by: Adam Ford 
--

V2: Clean up macros and ifdefs

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 0792373cfc..8ef363b3d4 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -37,6 +37,13 @@ config BLOCK_CACHE
  it will prevent repeated reads from directory structures and other
  filesystem data structures.
 
+config SPL_BLOCK_CACHE
+   bool "Use block device cache in SPL"
+   depends on BLOCK_CACHE && SPL_BLK
+   default n
+   help
+ This option enables the disk-block cache in SPL
+
 config IDE
bool "Support IDE controllers"
select HAVE_BLOCK_DEVICE
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 5fcafb193e..0e80ce9405 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -11,4 +11,4 @@ endif
 
 obj-$(CONFIG_IDE) += ide.o
 obj-$(CONFIG_SANDBOX) += sandbox.o
-obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
+obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
diff --git a/include/blk.h b/include/blk.h
index fc0c239e46..bd90e39932 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -111,7 +111,8 @@ struct blk_desc {
 #define PAD_TO_BLOCKSIZE(size, blk_desc) \
(PAD_SIZE(size, blk_desc->blksz))
 
-#ifdef CONFIG_BLOCK_CACHE
+#if (CONFIG_IS_ENABLED(BLOCK_CACHE) && !CONFIG_IS_ENABLED(SPL_BUILD)) || \
+(CONFIG_IS_ENABLED(SPL_BLOCK_CACHE) && CONFIG_IS_ENABLED(SPL_BUILD))
 /**
  * blkcache_read() - attempt to read a set of blocks from cache
  *
-- 
2.17.1

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


Re: [U-Boot] Logo for U-Boot

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 07:34 PM, Simon Glass wrote:
> Hi,
> 
> On 6 May 2018 at 12:31, Tom Rini  wrote:
>> On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote:
>>
>>> On 06.05.18 18:02, Heinrich Schuchardt wrote:
 On 05/04/2018 11:18 AM, Marek Vasut wrote:
> On 05/04/2018 08:46 AM, Alexander Graf wrote:
>> On 05/04/2018 01:04 AM, Marek Vasut wrote:
>>> On 05/03/2018 11:57 PM, Alexander Graf wrote:

 On 01.05.18 04:09, Marek Vasut wrote:
> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
>> U-Boot has currently no logo that we can use in presentations.
>>
>> On the U-Boot IRC channel the following propositions where made:
>>
>> Source:
>> https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
>> License: GPL2+
>> (Alex used this in some presentations.)
> Yellow submarine, nice.
>
> Maybe we should make it a bit more toward teal and orange to improve
> the
> contrast ? Although, maybe just replacing the depressive gray
> background
> with a light blue one would do.
 How about this?

http://csgraf.de/tmp2/uboot.svg
>>> Lacks the teal.
>>
>>
>> I don't want teal :)
>
> Without teal, the contrast of the image isn't good enough.
>
> And I think you might want to check with more people, since clearly it's
> just the two of us discussing it now :)
 Find Marek's darling appended
>>
>> It's a little hard to quote things inline like this.  But, did you
>> create your own image inspired by the wikimedia one?  I ask because the
>> wikimedia one is GPLv2 or later, but an original one that we could dual
>> license (for both a new framebuffer logo, and for printed materials,
>> etc, where a CC license works better) would be good.
>>
>>> I tend to agree that it looks nice :).
>>>
>>> It may mean we need a new web design too though, as the colors in the
>>> logo probably don't work terribly well with the current blue.
>>
>> We can worry about that later.
> 
> I think the logo as here is fine:
> 
> https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg

This logo was GPLv2+. Tom, didn't you say we needed something with
creative commons license?

> 
> What do you think about putting the word U-Boot inside it? Something like 
> this:
> 
> https://drive.google.com/open?id=1HsiXbZhtn8URhbdAeiW802t5Y0Tyqnuv

I have collected all suggestions here:

https://www.xypron.de/projects/u-boot/logo.html

Best regards

Heinrich

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


Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

2018-06-09 Thread Alex Kiernan
On Sat, Jun 9, 2018 at 3:04 PM Adam Ford  wrote:
>
> On Sat, Jun 9, 2018 at 8:26 AM Alex Kiernan  wrote:
> >
> > On Fri, Jun 8, 2018 at 9:48 PM Adam Ford  wrote:
> > >
> > > When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> > > some devices may not boot.  This creates an option to enable
> > > block caching in SPL by defaults off.  It is dependant on BLOCK_CACHE
> > > and SPL_BLK
> > >
> > > Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
> > >
> > > Signed-off-by: Adam Ford 
> > >
> > > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> > > index 0792373cfc..8ef363b3d4 100644
> > > --- a/drivers/block/Kconfig
> > > +++ b/drivers/block/Kconfig
> > > @@ -37,6 +37,13 @@ config BLOCK_CACHE
> > >   it will prevent repeated reads from directory structures and 
> > > other
> > >   filesystem data structures.
> > >
> > > +config SPL_BLOCK_CACHE
> > > +   bool "Use block device cache in SPL"
> > > +   depends on BLOCK_CACHE && SPL_BLK
> > > +   default n
> > > +   help
> > > + This option enables the disk-block cache in SPL
> > > +
> > >  config IDE
> > > bool "Support IDE controllers"
> > > select HAVE_BLOCK_DEVICE
> > > diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> > > index 5fcafb193e..a9af28a552 100644
> > > --- a/drivers/block/Makefile
> > > +++ b/drivers/block/Makefile
> > > @@ -11,4 +11,9 @@ endif
> > >
> > >  obj-$(CONFIG_IDE) += ide.o
> > >  obj-$(CONFIG_SANDBOX) += sandbox.o
> > > +ifdef CONFIG_SPL_BUILD
> > > +obj-$(SPL_BLOCK_CACHE) += blkcache.o
> >
> > CONFIG_SPL_BLOCK_CACHE?
> >
> > > +endif
> > > +ifndef CONFIG_SPL_BUILD
> > >  obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> > > +endif
> >
> > Could this all get replaced by:
> >
> > obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
> >
> Nicely done.  I am not that familiar with Makefiles and how to clean
> that up, but it seems to work work this way at least for the AM3517
> EVM.
>
> > > diff --git a/include/blk.h b/include/blk.h
> > > index fc0c239e46..c17c5eb047 100644
> > > --- a/include/blk.h
> > > +++ b/include/blk.h
> > > @@ -111,7 +111,8 @@ struct blk_desc {
> > >  #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> > > (PAD_SIZE(size, blk_desc->blksz))
> > >
> > > -#ifdef CONFIG_BLOCK_CACHE
> > > +#if (defined(CONFIG_BLOCK_CACHE) && !defined(CONFIG_SPL_BUILD)) || \
> > > +(defined(CONFIG_SPL_BLOCK_CACHE) && defined(CONFIG_SPL_BUILD))
> > >  /**
> >
> > Replace with CONFIG_IS_ENABLED?
>
> I tried replacing 'defined(x)' with 'CONFIG_IS_ENABLED(x)' and I got a
> bunch of build errors.
> The only way I could get it to work was using 'defined(x)'
>

You need to drop the CONFIG_ off the front of the symbol, something like:

#if CONFIG_IS_ENABLED(BLK_CACHE)

> adam
> >
> > >   * blkcache_read() - attempt to read a set of blocks from cache
> > >   *
> > > --
> > > 2.17.1
> > >
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> >
> >
> >
> > --
> > Alex Kiernan



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


Re: [U-Boot] Logo for U-Boot

2018-06-09 Thread Marek Vasut
On 06/09/2018 07:34 PM, Simon Glass wrote:
> Hi,
> 
> On 6 May 2018 at 12:31, Tom Rini  wrote:
>> On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote:
>>
>>> On 06.05.18 18:02, Heinrich Schuchardt wrote:
 On 05/04/2018 11:18 AM, Marek Vasut wrote:
> On 05/04/2018 08:46 AM, Alexander Graf wrote:
>> On 05/04/2018 01:04 AM, Marek Vasut wrote:
>>> On 05/03/2018 11:57 PM, Alexander Graf wrote:

 On 01.05.18 04:09, Marek Vasut wrote:
> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
>> U-Boot has currently no logo that we can use in presentations.
>>
>> On the U-Boot IRC channel the following propositions where made:
>>
>> Source:
>> https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
>> License: GPL2+
>> (Alex used this in some presentations.)
> Yellow submarine, nice.
>
> Maybe we should make it a bit more toward teal and orange to improve
> the
> contrast ? Although, maybe just replacing the depressive gray
> background
> with a light blue one would do.
 How about this?

http://csgraf.de/tmp2/uboot.svg
>>> Lacks the teal.
>>
>>
>> I don't want teal :)
>
> Without teal, the contrast of the image isn't good enough.
>
> And I think you might want to check with more people, since clearly it's
> just the two of us discussing it now :)
 Find Marek's darling appended
>>
>> It's a little hard to quote things inline like this.  But, did you
>> create your own image inspired by the wikimedia one?  I ask because the
>> wikimedia one is GPLv2 or later, but an original one that we could dual
>> license (for both a new framebuffer logo, and for printed materials,
>> etc, where a CC license works better) would be good.
>>
>>> I tend to agree that it looks nice :).
>>>
>>> It may mean we need a new web design too though, as the colors in the
>>> logo probably don't work terribly well with the current blue.
>>
>> We can worry about that later.
> 
> I think the logo as here is fine:
> 
> https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg

Yes, his one is nice. The one at osfc website is not.

> What do you think about putting the word U-Boot inside it? Something like 
> this:
> 
> https://drive.google.com/open?id=1HsiXbZhtn8URhbdAeiW802t5Y0Tyqnuv

I think the rendering fell apart, make a PNG or something please.

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


Re: [U-Boot] [PATCH 8/8] sandbox: swap_case: Increase number of base address regs

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> At present the code overruns the bar[] array. Fix this.
> 
> Reported-by: Coverity (CID: 131199)
> 
> Signed-off-by: Simon Glass 

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


Re: [U-Boot] [PATCH 7/8] spi: sandbox: Fix memory leak in sandbox_sf_bind_emul()

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> Move the strdup() call so that it is only done when we know we will bind
> the device.
> 
> Reported-by: Coverity (CID: 131216)
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/mtd/spi/sandbox.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
> index 7893efee12..ae29c034b9 100644
> --- a/drivers/mtd/spi/sandbox.c
> +++ b/drivers/mtd/spi/sandbox.c
> @@ -567,14 +567,14 @@ int sandbox_sf_bind_emul(struct sandbox_state *state, 
> int busnum, int cs,
>   strncpy(name, spec, sizeof(name) - 6);
>   name[sizeof(name) - 6] = '\0';
>   strcat(name, "-emul");
> - str = strdup(name);
> - if (!str)
> - return -ENOMEM;
>   drv = lists_driver_lookup_name("sandbox_sf_emul");
>   if (!drv) {
>   puts("Cannot find sandbox_sf_emul driver\n");
>   return -ENOENT;
>   }
> + str = strdup(name);
> + if (!str)
> + return -ENOMEM;
>   ret = device_bind(bus, drv, str, NULL, of_offset, );
>   if (ret) {
>   printf("Cannot create emul device for spec '%s' (err=%d)\n",

Aren't you leaking str's memory here? I would have expected free(str).

Best regards

Heinrich

> 

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


Re: [U-Boot] [PATCH 6/8] rsa: Fix missing memory leak on error in fdt_add_bignum()

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> Thsi function can fail without freeing all its memory. Fix it.
> 
> Reported-by: Coverity (CID: 131217)
> Signed-off-by: Simon Glass 
> ---
> 
>  lib/rsa/rsa-sign.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index d2788bf79a..2a09d2b19e 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -667,15 +667,13 @@ static int fdt_add_bignum(void *blob, int noffset, 
> const char *prop_name,
>* might fail several times

Please, fix the memory leaks above this line too.

Best regards

Heinrich

>*/
>   ret = fdt_setprop(blob, noffset, prop_name, buf, size);
> - if (ret)
> - return -FDT_ERR_NOSPACE;
>   free(buf);
>   BN_free(tmp);
>   BN_free(big2);
>   BN_free(big32);
>   BN_free(big2_32);
>  
> - return ret;
> + return ret ? -FDT_ERR_NOSPACE : 0;
>  }
>  
>  int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
> 

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


Re: [U-Boot] [PATCH 5/8] fdtgrep: Separate out checking of two allocations

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> The current code might succeed on the first allocation and fail on the
> second. Separate the checks to avoid this problem.
> 
> Of course, free() will never fail and the chances that (when allocating
> two small areas) one will succeed and one will fail are just as remote.
> But this keeps coverity happy.
> 
> Reported-by: Coverity (CID: 131226)
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  tools/fdtgrep.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
> index c4563e2289..5593b42203 100644
> --- a/tools/fdtgrep.c
> +++ b/tools/fdtgrep.c
> @@ -133,11 +133,11 @@ static int value_add(struct display_info *disp, struct 
> value_node **headp,
>   }
>  
>   str = strdup(str);
> + if (!str)
> + goto err_mem;
>   node = malloc(sizeof(*node));
> - if (!str || !node) {
> - fprintf(stderr, "Out of memory\n");
> - return -1;
> - }
> + if (!node)
> + goto err_mem;
>   node->next = *headp;
>   node->type = type;
>   node->include = include;
> @@ -145,6 +145,9 @@ static int value_add(struct display_info *disp, struct 
> value_node **headp,
>   *headp = node;
>

free(str) is missing here.


>   return 0;
> +err_mem:

free(str) is missing here.

Best regards

Heinrich

> + fprintf(stderr, "Out of memory\n");
> + return -1;
>  }
>  
>  static bool util_is_printable_string(const void *data, int len)
> 

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


Re: [U-Boot] [PATCH 4/8] fdtgrep: Fix logic of free() in do_fdtgrep()

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> This loop never actually exits, but the way the code is written this is
> not obvious. Add an explicit error check.
> 
> Reported-by: Coverity (CID: 131280)
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  tools/fdtgrep.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
> index f2b8b71ed7..c4563e2289 100644
> --- a/tools/fdtgrep.c
> +++ b/tools/fdtgrep.c
> @@ -801,7 +801,7 @@ static int do_fdtgrep(struct display_info *disp, const 
> char *filename)
>* The first pass will count the regions, but if it is too many,
>* we do another pass to actually record them.
>*/
> - for (i = 0; i < 3; i++) {
> + for (i = 0; i < 2; i++) {
>   region = malloc(count * sizeof(struct fdt_region));
>   if (!region) {
>   fprintf(stderr, "Out of memory for %d regions\n",

Can't we call fdtgrep_find_regions() with max_regions = 0 and region =
NULL to do the counting and get rid of the loop? That may be a bit
slower but the code will be much easier to read.

> @@ -820,6 +820,8 @@ static int do_fdtgrep(struct display_info *disp, const 
> char *filename)

Have a look at the lines in between:

if (count < 0) {
report_error("fdt_find_regions", count);
return -1;
}

Here a free(region) is missing.

Best regards

Heinrich

>   if (count <= max_regions)
>   break;
>   free(region);
> + fprintf(stderr, "Internal error with fdtgrep_find_region)(\n");
> + return -1;
>   }
>  
>   /* Optionally print a list of regions */
> 

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


Re: [U-Boot] [PATCH 2/8] console: Fix handling of NULL global_data

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> Both putc() and puts() can be called before global_data is set up. Some of
> the code paths don't handle this correctly. Add an explicit test before
> any member is accessed.
> 
> Reported-by: Coverity (CID: 169030)
> Signed-off-by: Simon Glass 

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


Re: [U-Boot] [PATCH 1/8] log: Fix incorect range check in log_get_cat_name()

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> This allows access to an element after the end of the array. Fix it.
> 
> Reported-by: Coverity (CID: 173279)
> Signed-off-by: Simon Glass 
> ---
> 
>  common/log.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/log.c b/common/log.c
> index 3b5588ebe7..4e488eca5b 100644
> --- a/common/log.c
> +++ b/common/log.c
> @@ -38,7 +38,7 @@ static const char *log_level_name[LOGL_COUNT] = {
>  
>  const char *log_get_cat_name(enum log_category_t cat)
>  {
> - if (cat > LOGC_COUNT)
> + if (cat >= LOGC_COUNT)
>   return "invalid";
>   if (cat >= LOGC_NONE)
>   return log_cat_name[cat - LOGC_NONE];
> 

Please, consider all possible values of cat:

enums can take negative values or be an invalid uclass id. The function
terminates with

return uclass_get_name((enum uclass_id)cat);

This statement will return NULL if cat does not refer to an installed
uclass driver but above you decided that in case of an error you want to
return "invalid". This looks inconsistent to me.

Best regards

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


Re: [U-Boot] [PATCH 3/8] sandbox: Use memcpy() to move overlapping regions

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 08:22 PM, Simon Glass wrote:
> The use of strcpy() to remove characters at the start of a string is safe
> in U-Boot, since we know the implementation. But in os.c we are using the
> C library's strcpy() function, where this behaviour is not permitted.
> 
> Update the code to use memcpy() instead.
> 
> Reported-by: Coverity (CID: 173279)
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/sandbox/cpu/os.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
> index 5839932b00..496a8f9bd8 100644
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
> @@ -587,7 +587,8 @@ int os_find_u_boot(char *fname, int maxlen)
>   /* Look for 'u-boot' in the parent directory of spl/ */
>   p = strstr(fname, "/spl/");

I have built sandbox_spl_defconfig.

First observation: any parallel build fails. But that is to be handled
in a seperate patch.

The logic to find u-boot here is broken. From the top directory of the
git repository I executed:

$ spl/u-boot-spl

U-Boot SPL 2018.07-rc1-00063-g277daa5c0f (Jun 09 2018 - 20:40:23 +0200)
Trying to boot from sandbox
(spl/u-boot not found, error -2)
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Why would you expect fname to start with /spl/?

In my case fname = 'spl/u-boot'. Why do you test for '/spl/' (only)?

Just for the record if I execute
$ ./spl/u-boot-spl
everything works fine. But who would precede a directory name with './'?

Should we not concatenate the spl executable and the u-boot executable
during the build process so that spl/u-boot knows where to find u-boot?
That would be much safer than any assumption about relative paths.

Best regards

Heinrich

>   if (p) {
> - strcpy(p, p + 4);
> + /* Remove the "/spl" characters */
> + memmove(p, p + 4, strlen(p + 4) + 1);
>   fd = os_open(fname, O_RDONLY);
>   if (fd >= 0) {
>   close(fd);
> 

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


[U-Boot] [PATCH 5/8] fdtgrep: Separate out checking of two allocations

2018-06-09 Thread Simon Glass
The current code might succeed on the first allocation and fail on the
second. Separate the checks to avoid this problem.

Of course, free() will never fail and the chances that (when allocating
two small areas) one will succeed and one will fail are just as remote.
But this keeps coverity happy.

Reported-by: Coverity (CID: 131226)

Signed-off-by: Simon Glass 
---

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

diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
index c4563e2289..5593b42203 100644
--- a/tools/fdtgrep.c
+++ b/tools/fdtgrep.c
@@ -133,11 +133,11 @@ static int value_add(struct display_info *disp, struct 
value_node **headp,
}
 
str = strdup(str);
+   if (!str)
+   goto err_mem;
node = malloc(sizeof(*node));
-   if (!str || !node) {
-   fprintf(stderr, "Out of memory\n");
-   return -1;
-   }
+   if (!node)
+   goto err_mem;
node->next = *headp;
node->type = type;
node->include = include;
@@ -145,6 +145,9 @@ static int value_add(struct display_info *disp, struct 
value_node **headp,
*headp = node;
 
return 0;
+err_mem:
+   fprintf(stderr, "Out of memory\n");
+   return -1;
 }
 
 static bool util_is_printable_string(const void *data, int len)
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 8/8] sandbox: swap_case: Increase number of base address regs

2018-06-09 Thread Simon Glass
At present the code overruns the bar[] array. Fix this.

Reported-by: Coverity (CID: 131199)

Signed-off-by: Simon Glass 
---

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

diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c
index 56cd0700fa..b777404c09 100644
--- a/drivers/misc/swap_case.c
+++ b/drivers/misc/swap_case.c
@@ -21,7 +21,7 @@
  */
 struct swap_case_platdata {
u16 command;
-   u32 bar[2];
+   u32 bar[6];
 };
 
 #define offset_to_barnum(offset)   \
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 4/8] fdtgrep: Fix logic of free() in do_fdtgrep()

2018-06-09 Thread Simon Glass
This loop never actually exits, but the way the code is written this is
not obvious. Add an explicit error check.

Reported-by: Coverity (CID: 131280)

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
index f2b8b71ed7..c4563e2289 100644
--- a/tools/fdtgrep.c
+++ b/tools/fdtgrep.c
@@ -801,7 +801,7 @@ static int do_fdtgrep(struct display_info *disp, const char 
*filename)
 * The first pass will count the regions, but if it is too many,
 * we do another pass to actually record them.
 */
-   for (i = 0; i < 3; i++) {
+   for (i = 0; i < 2; i++) {
region = malloc(count * sizeof(struct fdt_region));
if (!region) {
fprintf(stderr, "Out of memory for %d regions\n",
@@ -820,6 +820,8 @@ static int do_fdtgrep(struct display_info *disp, const char 
*filename)
if (count <= max_regions)
break;
free(region);
+   fprintf(stderr, "Internal error with fdtgrep_find_region)(\n");
+   return -1;
}
 
/* Optionally print a list of regions */
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 6/8] rsa: Fix missing memory leak on error in fdt_add_bignum()

2018-06-09 Thread Simon Glass
Thsi function can fail without freeing all its memory. Fix it.

Reported-by: Coverity (CID: 131217)
Signed-off-by: Simon Glass 
---

 lib/rsa/rsa-sign.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index d2788bf79a..2a09d2b19e 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -667,15 +667,13 @@ static int fdt_add_bignum(void *blob, int noffset, const 
char *prop_name,
 * might fail several times
 */
ret = fdt_setprop(blob, noffset, prop_name, buf, size);
-   if (ret)
-   return -FDT_ERR_NOSPACE;
free(buf);
BN_free(tmp);
BN_free(big2);
BN_free(big32);
BN_free(big2_32);
 
-   return ret;
+   return ret ? -FDT_ERR_NOSPACE : 0;
 }
 
 int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 7/8] spi: sandbox: Fix memory leak in sandbox_sf_bind_emul()

2018-06-09 Thread Simon Glass
Move the strdup() call so that it is only done when we know we will bind
the device.

Reported-by: Coverity (CID: 131216)

Signed-off-by: Simon Glass 
---

 drivers/mtd/spi/sandbox.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
index 7893efee12..ae29c034b9 100644
--- a/drivers/mtd/spi/sandbox.c
+++ b/drivers/mtd/spi/sandbox.c
@@ -567,14 +567,14 @@ int sandbox_sf_bind_emul(struct sandbox_state *state, int 
busnum, int cs,
strncpy(name, spec, sizeof(name) - 6);
name[sizeof(name) - 6] = '\0';
strcat(name, "-emul");
-   str = strdup(name);
-   if (!str)
-   return -ENOMEM;
drv = lists_driver_lookup_name("sandbox_sf_emul");
if (!drv) {
puts("Cannot find sandbox_sf_emul driver\n");
return -ENOENT;
}
+   str = strdup(name);
+   if (!str)
+   return -ENOMEM;
ret = device_bind(bus, drv, str, NULL, of_offset, );
if (ret) {
printf("Cannot create emul device for spec '%s' (err=%d)\n",
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 3/8] sandbox: Use memcpy() to move overlapping regions

2018-06-09 Thread Simon Glass
The use of strcpy() to remove characters at the start of a string is safe
in U-Boot, since we know the implementation. But in os.c we are using the
C library's strcpy() function, where this behaviour is not permitted.

Update the code to use memcpy() instead.

Reported-by: Coverity (CID: 173279)

Signed-off-by: Simon Glass 
---

 arch/sandbox/cpu/os.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 5839932b00..496a8f9bd8 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -587,7 +587,8 @@ int os_find_u_boot(char *fname, int maxlen)
/* Look for 'u-boot' in the parent directory of spl/ */
p = strstr(fname, "/spl/");
if (p) {
-   strcpy(p, p + 4);
+   /* Remove the "/spl" characters */
+   memmove(p, p + 4, strlen(p + 4) + 1);
fd = os_open(fname, O_RDONLY);
if (fd >= 0) {
close(fd);
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 2/8] console: Fix handling of NULL global_data

2018-06-09 Thread Simon Glass
Both putc() and puts() can be called before global_data is set up. Some of
the code paths don't handle this correctly. Add an explicit test before
any member is accessed.

Reported-by: Coverity (CID: 169030)
Signed-off-by: Simon Glass 
---

 common/console.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/common/console.c b/common/console.c
index 2688af56e1..2ba33dc574 100644
--- a/common/console.c
+++ b/common/console.c
@@ -502,8 +502,10 @@ void putc(const char c)
return;
}
 #endif
+   if (!gd)
+   return;
 #ifdef CONFIG_CONSOLE_RECORD
-   if (gd && (gd->flags & GD_FLG_RECORD) && gd->console_out.start)
+   if ((gd->flags & GD_FLG_RECORD) && gd->console_out.start)
membuff_putbyte(>console_out, c);
 #endif
 #ifdef CONFIG_SILENT_CONSOLE
@@ -541,8 +543,10 @@ void puts(const char *s)
return;
}
 #endif
+   if (!gd)
+   return;
 #ifdef CONFIG_CONSOLE_RECORD
-   if (gd && (gd->flags & GD_FLG_RECORD) && gd->console_out.start)
+   if ((gd->flags & GD_FLG_RECORD) && gd->console_out.start)
membuff_put(>console_out, s, strlen(s));
 #endif
 #ifdef CONFIG_SILENT_CONSOLE
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 1/8] log: Fix incorect range check in log_get_cat_name()

2018-06-09 Thread Simon Glass
This allows access to an element after the end of the array. Fix it.

Reported-by: Coverity (CID: 173279)
Signed-off-by: Simon Glass 
---

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

diff --git a/common/log.c b/common/log.c
index 3b5588ebe7..4e488eca5b 100644
--- a/common/log.c
+++ b/common/log.c
@@ -38,7 +38,7 @@ static const char *log_level_name[LOGL_COUNT] = {
 
 const char *log_get_cat_name(enum log_category_t cat)
 {
-   if (cat > LOGC_COUNT)
+   if (cat >= LOGC_COUNT)
return "invalid";
if (cat >= LOGC_NONE)
return log_cat_name[cat - LOGC_NONE];
-- 
2.18.0.rc1.242.g61856ae69a-goog

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


[U-Boot] [PATCH 0/8] Fix some coverity warnings

2018-06-09 Thread Simon Glass
This series attempts to fix various problems reported by Coverity, in
subsystems where I have some knowledge.


Simon Glass (8):
  log: Fix incorect range check in log_get_cat_name()
  console: Fix handling of NULL global_data
  sandbox: Use memcpy() to move overlapping regions
  fdtgrep: Fix logic of free() in do_fdtgrep()
  fdtgrep: Separate out checking of two allocations
  rsa: Fix missing memory leak on error in fdt_add_bignum()
  spi: sandbox: Fix memory leak in sandbox_sf_bind_emul()
  sandbox: swap_case: Increase number of base address regs

 arch/sandbox/cpu/os.c |  3 ++-
 common/console.c  |  8 ++--
 common/log.c  |  2 +-
 drivers/misc/swap_case.c  |  2 +-
 drivers/mtd/spi/sandbox.c |  6 +++---
 lib/rsa/rsa-sign.c|  4 +---
 tools/fdtgrep.c   | 15 ++-
 7 files changed, 24 insertions(+), 16 deletions(-)

-- 
2.18.0.rc1.242.g61856ae69a-goog

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


Re: [U-Boot] [ANN] U-Boot v2018.05 released

2018-06-09 Thread Simon Glass
Hi Tom,

On 7 May 2018 at 07:34, Tom Rini  wrote:
> Hey all,
>
> It's release day, and here we are doing the release.  It's live on git
> and FTP and ACD (along with the PGP sig file).
>
> A few things I want to call out here.  First, a bunch more NXP PowerPC
> boards have just been marked as Orphaned due to lack of valid maintainer
> email.  So the one year until removal clock has started for them.  This
> also marks the point where another batch of boards will hit the 1 year
> mark with the _next_ release and I'm inclined to say that what that
> means is that _this_ is the final release they will be in.

Sounds good.

Also this is the deadline for CONFIG_BLK support. I am thinking of
doing a patch to remove boards which don't support it, starting with
ARM. I have not looked recently but there are definitely quite a few
stragglers. I am thinking of enabling CONFIG_BLK by default as a first
step, to see what breaks.

What do you think?

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


Re: [U-Boot] Logo for U-Boot

2018-06-09 Thread Simon Glass
Hi,

On 6 May 2018 at 12:31, Tom Rini  wrote:
> On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote:
>
>> On 06.05.18 18:02, Heinrich Schuchardt wrote:
>> > On 05/04/2018 11:18 AM, Marek Vasut wrote:
>> >> On 05/04/2018 08:46 AM, Alexander Graf wrote:
>> >>> On 05/04/2018 01:04 AM, Marek Vasut wrote:
>>  On 05/03/2018 11:57 PM, Alexander Graf wrote:
>> >
>> > On 01.05.18 04:09, Marek Vasut wrote:
>> >> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
>> >>> U-Boot has currently no logo that we can use in presentations.
>> >>>
>> >>> On the U-Boot IRC channel the following propositions where made:
>> >>>
>> >>> Source:
>> >>> https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
>> >>> License: GPL2+
>> >>> (Alex used this in some presentations.)
>> >> Yellow submarine, nice.
>> >>
>> >> Maybe we should make it a bit more toward teal and orange to improve
>> >> the
>> >> contrast ? Although, maybe just replacing the depressive gray
>> >> background
>> >> with a light blue one would do.
>> > How about this?
>> >
>> >http://csgraf.de/tmp2/uboot.svg
>>  Lacks the teal.
>> >>>
>> >>>
>> >>> I don't want teal :)
>> >>
>> >> Without teal, the contrast of the image isn't good enough.
>> >>
>> >> And I think you might want to check with more people, since clearly it's
>> >> just the two of us discussing it now :)
>> > Find Marek's darling appended
>
> It's a little hard to quote things inline like this.  But, did you
> create your own image inspired by the wikimedia one?  I ask because the
> wikimedia one is GPLv2 or later, but an original one that we could dual
> license (for both a new framebuffer logo, and for printed materials,
> etc, where a CC license works better) would be good.
>
>> I tend to agree that it looks nice :).
>>
>> It may mean we need a new web design too though, as the colors in the
>> logo probably don't work terribly well with the current blue.
>
> We can worry about that later.

I think the logo as here is fine:

https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg

What do you think about putting the word U-Boot inside it? Something like this:

https://drive.google.com/open?id=1HsiXbZhtn8URhbdAeiW802t5Y0Tyqnuv

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


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

2018-06-09 Thread Hauke Mehrtens
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 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts | 145 ++
 board/sunxi/MAINTAINERS   |   5 +
 configs/orangepi_zero_plus_defconfig  |  16 +++
 4 files changed, 167 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts
 create mode 100644 configs/orangepi_zero_plus_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e81a580692..3fff4c94e7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -379,6 +379,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-libretech-all-h3-cc.dtb \
sun50i-h5-nanopi-neo2.dtb \
sun50i-h5-nanopi-neo-plus2.dtb \
+   sun50i-h5-orangepi-zero-plus.dtb \
sun50i-h5-orangepi-pc2.dtb \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
diff --git a/arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts 
b/arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts
new file mode 100644
index 00..e79cf3baf4
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * Copyright (C) 2018 Hauke Mehrtens 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR X11)
+ */
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Xunlong Orange Pi Zero Plus";
+   compatible = "xunlong,orangepi-zero-plus", "allwinner,sun50i-h5";
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pwr {
+   label = "orangepi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
+   default-state = "on";
+   };
+
+   status {
+   label = "orangepi:red:status";
+   gpios = < 0 17 GPIO_ACTIVE_HIGH>; /* PA17 */
+   };
+   };
+
+   reg_gmac_3v3: gmac-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "gmac-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <10>;
+   enable-active-high;
+   gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-supply = <_gmac_3v3>;
+   phy-handle = <_rgmii_phy>;
+   phy-mode = "rgmii";
+   status = "okay";
+};
+
+_mdio {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   non-removable;
+   status = "okay";
+
+   /*
+* Explicitly define the sdio device, so that we can add an ethernet
+* alias for it (which e.g. makes u-boot set a mac-address).
+*/
+   rtl8189ftv: sdio_wifi@1 {
+   reg = <1>;
+   };
+};
+
+/*
+  {
+   status = "okay";
+
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mxicy,mx25l1606e", "winbond,w25q128";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+   };
+};
+*/
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+_otg {
+   dr_mode = "peripheral";
+   status = "okay";
+};
+
+ {
+   /* USB Type-A ports' VBUS is always on */
+   usb0_id_det-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 6ebf612db3..db51f48ab6 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -340,6 +340,11 @@ M: Icenowy Zheng 
 S: Maintained
 F: 

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

2018-06-09 Thread Hauke Mehrtens
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 
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts | 101 +
 board/sunxi/MAINTAINERS|   5 ++
 configs/orangepi_r1_defconfig  |  16 +
 4 files changed, 123 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts
 create mode 100644 configs/orangepi_r1_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 790571b773..e81a580692 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -355,6 +355,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-tbs-a711.dts
 dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h2-plus-libretech-all-h3-cc.dtb \
+   sun8i-h2-plus-orangepi-r1.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-libretech-all-h3-cc.dtb \
diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts 
b/arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts
new file mode 100644
index 00..c652ac3b71
--- /dev/null
+++ b/arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/* Orange Pi R1 is based on Orange Pi Zero design */
+#include "sun8i-h2-plus-orangepi-zero.dts"
+
+/ {
+   model = "Xunlong Orange Pi R1";
+   compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
+
+   /delete-node/ reg_vcc_wifi;
+
+   /*
+* Ths pin of this regulator is the same with the Wi-Fi extra
+* regulator on the original Zero. However it's used for USB
+* Ethernet rather than the Wi-Fi now.
+*/
+   reg_vcc_usb_eth: reg-vcc-usb-ethernet {
+   compatible = "regulator-fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-usb-ethernet";
+   enable-active-high;
+   gpio = < 0 20 GPIO_ACTIVE_HIGH>;
+   };
+
+   aliases {
+   ethernet1 = 
+   };
+};
+
+/*
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "mxicy,mx25l12805d", "jedec,spi-nor";
+   };
+};
+*/
+
+ {
+   /*
+* RTL8152B USB-Ethernet adapter is connected to USB1,
+* and it's a USB 2.0 device. So the OHCI1 controller
+* can be left disabled.
+*/
+   status = "disabled";
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   vqmmc-supply = <_vcc3v3>;
+
+   rtl8189etv: sdio_wifi@1 {
+   reg = <1>;
+   };
+};
+
+ {
+   

[U-Boot] [PATCH 1/1] efi_loader: avoid initializer element is not constant

2018-06-09 Thread Heinrich Schuchardt
When building with -pedantic the current definition of EFI_GUID() causes
an error 'initializer element is not constant'.

Currently EFI_GUID() is used both as an anonymous constant and as an
intializer. A conversion to efi_guid_t is not allowable when using
EFI_GUID() as an initializer. But it is needed when using it as an
anonymous constant.

We should not use EFI_GUID() for anything but an initializer. So let's
introduce a variable where needed and remove the conversion.

Signed-off-by: Heinrich Schuchardt 
---
 disk/part_efi.c | 9 +++--
 include/efi.h   | 3 +--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 5c1039f0130..2945892a24d 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -23,6 +23,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * GUID for basic data partions.
+ */
+static const efi_guid_t partition_basic_data_guid = PARTITION_BASIC_DATA_GUID;
+
 #ifdef CONFIG_HAVE_BLOCK_DEVICE
 /**
  * efi_crc32() - EFI version of crc32 function
@@ -502,12 +507,12 @@ int gpt_fill_pte(struct blk_desc *dev_desc,
} else {
/* default partition type GUID */
memcpy(bin_type_guid,
-  _BASIC_DATA_GUID, 16);
+  _basic_data_guid, 16);
}
 #else
/* partition type GUID */
memcpy(gpt_e[i].partition_type_guid.b,
-   _BASIC_DATA_GUID, 16);
+   _basic_data_guid, 16);
 #endif
 
 #if CONFIG_IS_ENABLED(PARTITION_UUIDS)
diff --git a/include/efi.h b/include/efi.h
index 98bddbac1ad..e30a3c51c67 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -89,12 +89,11 @@ typedef u64 efi_virtual_addr_t;
 typedef void *efi_handle_t;
 
 #define EFI_GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
-   ((efi_guid_t) \
{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, \
((a) >> 24) & 0xff, \
(b) & 0xff, ((b) >> 8) & 0xff, \
(c) & 0xff, ((c) >> 8) & 0xff, \
-   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) } })
+   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) } }
 
 /* Generic EFI table header */
 struct efi_table_hdr {
-- 
2.17.1

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


[U-Boot] [PATCH v2] vboot: Do not use hashed-strings offset

2018-06-09 Thread Teddy Reed
The hashed-strings signature property includes two uint32_t values.
The first is unneeded as there should never be a start offset into the
strings region. The second, the size, is needed because the added
signature node appends to this region.

See tools/image-host.c, where a static 0 value is used for the offset.

Signed-off-by: Teddy Reed 
---
 common/image-sig.c | 7 +--
 tools/image-host.c | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/common/image-sig.c b/common/image-sig.c
index f65d883..ad571f9 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -372,8 +372,11 @@ int fit_config_check_sig(const void *fit, int noffset, int 
required_keynode,
/* Add the strings */
strings = fdt_getprop(fit, noffset, "hashed-strings", NULL);
if (strings) {
-   fdt_regions[count].offset = fdt_off_dt_strings(fit) +
-   fdt32_to_cpu(strings[0]);
+   /*
+* The strings region offset must be a static 0x0.
+* This is set in tool/image-host.c
+*/
+   fdt_regions[count].offset = fdt_off_dt_strings(fit);
fdt_regions[count].size = fdt32_to_cpu(strings[1]);
count++;
}
diff --git a/tools/image-host.c b/tools/image-host.c
index 8e43671..be2d59b 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -135,6 +135,7 @@ static int fit_image_write_sig(void *fit, int noffset, 
uint8_t *value,
 
ret = fdt_setprop(fit, noffset, "hashed-nodes",
   region_prop, region_proplen);
+   /* This is a legacy offset, it is unused, and must remain 0. */
strdata[0] = 0;
strdata[1] = cpu_to_fdt32(string_size);
if (!ret) {
-- 
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] vboot: Add FIT_SIGNATURE_MAX_SIZE protection

2018-06-09 Thread Teddy Reed
This adds a new config value FIT_SIGNATURE_MAX_SIZE, which controls the
max size of a FIT header's totalsize field. The field is checked before
signature checks are applied to protect from reading past the intended
FIT regions.

This field is not part of the vboot signature so it should be sanity
checked. If the field is corrupted then the structure or string region
reads may have unintended behavior, such as reading from device memory.
A default value of 256MB is set and intended to support most max storage
sizes.

Suggested-by: Simon Glass 
Signed-off-by: Teddy Reed 
Reviewed-by: Simon Glass 
---
 Kconfig | 10 ++
 common/image-sig.c  |  5 +
 test/py/tests/test_vboot.py | 33 +
 tools/Makefile  |  1 +
 4 files changed, 49 insertions(+)

diff --git a/Kconfig b/Kconfig
index 5a82c95..c8b86cd 100644
--- a/Kconfig
+++ b/Kconfig
@@ -267,6 +267,16 @@ config FIT_SIGNATURE
  format support in this case, enable it using
  CONFIG_IMAGE_FORMAT_LEGACY.
 
+config FIT_SIGNATURE_MAX_SIZE
+   hex "Max size of signed FIT structures"
+   depends on FIT_SIGNATURE
+   default 0x1000
+   help
+ This option sets a max size in bytes for verified FIT uImages.
+ A sane value of 256MB protects corrupted DTB structures from 
overlapping
+ device memory. Assure this size does not extend past expected storage
+ space.
+
 config FIT_VERBOSE
bool "Show verbose messages when FIT images fail"
help
diff --git a/common/image-sig.c b/common/image-sig.c
index f65d883..8d2fd10 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -156,6 +156,11 @@ static int fit_image_setup_verify(struct image_sign_info 
*info,
 {
char *algo_name;
 
+   if (fdt_totalsize(fit) > CONFIG_FIT_SIGNATURE_MAX_SIZE) {
+   *err_msgp = "Total size too large";
+   return 1;
+   }
+
if (fit_image_hash_get_algo(fit, noffset, _name)) {
*err_msgp = "Can't get hash algo property";
return -1;
diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index ee939f2..3d25ec3 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -26,6 +26,7 @@ Tests run with both SHA1 and SHA256 hashing.
 
 import pytest
 import sys
+import struct
 import u_boot_utils as util
 
 @pytest.mark.boardspec('sandbox')
@@ -105,6 +106,26 @@ def test_vboot(u_boot_console):
 util.run_and_log(cons, [mkimage, '-F', '-k', tmpdir, '-K', dtb,
 '-r', fit])
 
+def replace_fit_totalsize(size):
+"""Replace FIT header's totalsize with something greater.
+
+The totalsize must be less than or equal to FIT_SIGNATURE_MAX_SIZE.
+If the size is greater, the signature verification should return false.
+
+Args:
+size: The new totalsize of the header
+
+Returns:
+prev_size: The previous totalsize read from the header
+"""
+total_size = 0
+with open(fit, 'r+b') as handle:
+handle.seek(4)
+total_size = handle.read(4)
+handle.seek(4)
+handle.write(struct.pack(">I", size))
+return struct.unpack(">I", total_size)[0]
+
 def test_with_algo(sha_algo):
 """Test verified boot with the given hash algorithm.
 
@@ -146,6 +167,18 @@ def test_vboot(u_boot_console):
 util.run_and_log(cons, [fit_check_sign, '-f', fit, '-k', tmpdir,
 '-k', dtb])
 
+# Replace header bytes
+bcfg = u_boot_console.config.buildconfig
+max_size = int(bcfg.get('config_fit_signature_max_size', 0x1000), 
0)
+existing_size = replace_fit_totalsize(max_size + 1)
+run_bootm(sha_algo, 'Signed config with bad hash', 'Bad Data Hash', 
False)
+cons.log.action('%s: Check overflowed FIT header totalsize' % sha_algo)
+
+# Replace with existing header bytes
+replace_fit_totalsize(existing_size)
+run_bootm(sha_algo, 'signed config', 'dev+', True)
+cons.log.action('%s: Check default FIT header totalsize' % sha_algo)
+
 # Increment the first byte of the signature, which should cause failure
 sig = util.run_and_log(cons, 'fdtget -t bx %s %s value' %
(fit, sig_node))
diff --git a/tools/Makefile b/tools/Makefile
index 5dd33ed..0c3341e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -133,6 +133,7 @@ ifdef CONFIG_FIT_SIGNATURE
 # This affects include/image.h, but including the board config file
 # is tricky, so manually define this options here.
 HOST_EXTRACFLAGS   += -DCONFIG_FIT_SIGNATURE
+HOST_EXTRACFLAGS   += 
-DCONFIG_FIT_SIGNATURE_MAX_SIZE=$(CONFIG_FIT_SIGNATURE_MAX_SIZE)
 endif
 
 ifdef CONFIG_SYS_U_BOOT_OFFS
-- 
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

2018-06-09 Thread Adam Ford
On Sat, Jun 9, 2018 at 8:26 AM Alex Kiernan  wrote:
>
> On Fri, Jun 8, 2018 at 9:48 PM Adam Ford  wrote:
> >
> > When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> > some devices may not boot.  This creates an option to enable
> > block caching in SPL by defaults off.  It is dependant on BLOCK_CACHE
> > and SPL_BLK
> >
> > Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
> >
> > Signed-off-by: Adam Ford 
> >
> > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> > index 0792373cfc..8ef363b3d4 100644
> > --- a/drivers/block/Kconfig
> > +++ b/drivers/block/Kconfig
> > @@ -37,6 +37,13 @@ config BLOCK_CACHE
> >   it will prevent repeated reads from directory structures and other
> >   filesystem data structures.
> >
> > +config SPL_BLOCK_CACHE
> > +   bool "Use block device cache in SPL"
> > +   depends on BLOCK_CACHE && SPL_BLK
> > +   default n
> > +   help
> > + This option enables the disk-block cache in SPL
> > +
> >  config IDE
> > bool "Support IDE controllers"
> > select HAVE_BLOCK_DEVICE
> > diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> > index 5fcafb193e..a9af28a552 100644
> > --- a/drivers/block/Makefile
> > +++ b/drivers/block/Makefile
> > @@ -11,4 +11,9 @@ endif
> >
> >  obj-$(CONFIG_IDE) += ide.o
> >  obj-$(CONFIG_SANDBOX) += sandbox.o
> > +ifdef CONFIG_SPL_BUILD
> > +obj-$(SPL_BLOCK_CACHE) += blkcache.o
>
> CONFIG_SPL_BLOCK_CACHE?
>
> > +endif
> > +ifndef CONFIG_SPL_BUILD
> >  obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> > +endif
>
> Could this all get replaced by:
>
> obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o
>
Nicely done.  I am not that familiar with Makefiles and how to clean
that up, but it seems to work work this way at least for the AM3517
EVM.

> > diff --git a/include/blk.h b/include/blk.h
> > index fc0c239e46..c17c5eb047 100644
> > --- a/include/blk.h
> > +++ b/include/blk.h
> > @@ -111,7 +111,8 @@ struct blk_desc {
> >  #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> > (PAD_SIZE(size, blk_desc->blksz))
> >
> > -#ifdef CONFIG_BLOCK_CACHE
> > +#if (defined(CONFIG_BLOCK_CACHE) && !defined(CONFIG_SPL_BUILD)) || \
> > +(defined(CONFIG_SPL_BLOCK_CACHE) && defined(CONFIG_SPL_BUILD))
> >  /**
>
> Replace with CONFIG_IS_ENABLED?

I tried replacing 'defined(x)' with 'CONFIG_IS_ENABLED(x)' and I got a
bunch of build errors.
The only way I could get it to work was using 'defined(x)'

adam
>
> >   * blkcache_read() - attempt to read a set of blocks from cache
> >   *
> > --
> > 2.17.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
> --
> Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] sandbox_flattree: Switch to TPMv2 support

2018-06-09 Thread Miquel Raynal
Hi Simon,

On Fri, 8 Jun 2018 13:59:07 -0800, Simon Glass  wrote:

> Hi Miquel,
> 
> On 7 June 2018 at 23:36, Miquel Raynal  wrote:
> > Hi Simon,
> >
> > On Thu, 7 Jun 2018 16:25:28 -0800, Simon Glass  wrote:
> >  
> >> Hi Miquel,
> >>
> >> On 6 June 2018 at 23:38, Miquel Raynal  wrote:  
> >> > Hello,
> >> >
> >> > Sorry for the delay.
> >> >
> >> > On Sat, 2 Jun 2018 10:15:17 -0600, Simon Glass  wrote:
> >> >  
> >> >> Hi Tom,
> >> >>
> >> >> On 1 June 2018 at 11:55, Tom Rini  wrote:  
> >> >> >
> >> >> > On Fri, Jun 01, 2018 at 09:25:19AM -0600, Simon Glass wrote:  
> >> >> > > +Miquel due to sandbox TPM issue
> >> >> > >
> >> >> > > Hi Tom,
> >> >> > >
> >> >> > > On 25 May 2018 at 06:27, Tom Rini  wrote:  
> >> >> > > > In order to have the test.py tests for TPMv2 run automatically we 
> >> >> > > > need
> >> >> > > > to have one of our sandbox builds use TPMv2 rather than TPMv1.  
> >> >> > > > Switch
> >> >> > > > sandbox_flattree over to this style of TPM.  
> >> >> > >
> >> >> > > The problem seems to be that the sandbox driver is only built with
> >> >> > > either TPMv1 or TPMv2. It needs to be able to build with both, so we
> >> >> > > can run tests with both.  
> >> >> >
> >> >> > Right.  But we don't have any run-time automatic tests for TPMv1 as 
> >> >> > the
> >> >> > 'tpm test' command needs to be done manually, at least today (unless 
> >> >> > I'm
> >> >> > missing something under test/py/tests/).  And we can't (functionally 
> >> >> > in
> >> >> > real uses) have both TPM types available.  Perhaps we should make 
> >> >> > TPMv2
> >> >> > the default for sandbox?  All of the TPMv1 code will still be getting
> >> >> > build-time exercised due to platforms with TPMv1 on them.  
> >> >>
> >> >> I'll take a look at this. It should actually be quite easy to have two
> >> >> TPMs in sandbox, one v1 and one v2. At least I don't know of any
> >> >> impediment.
> >> >>  
> >> >> >  
> >> >> > > It really doesn't make any sense to have build-time branches for 
> >> >> > > sandbox.
> >> >> > >
> >> >> > > We currently have:
> >> >> > >
> >> >> > > sandbox - should be used for most tests
> >> >> > > sandbox64 - special build that forces a 64-bit host
> >> >> > > sandbox_flattree - builds with dev_read_...() functions defined as
> >> >> > > inline. We need this build so that we can test those inline 
> >> >> > > functions,
> >> >> > > and we cannot build with both the inline functions and the 
> >> >> > > non-inline
> >> >> > > functions since they are named the same
> >> >> > > sandbox_noblk - builds without CONFIG_BLK, which means the legacy
> >> >> > > block drivers are used. We cannot use both the legacy and 
> >> >> > > driver-model
> >> >> > > block drivers since they implement the same functions
> >> >> > > sandbox_spl - builds sandbox with SPL support, so you can run
> >> >> > > spl/u-boot-spl and it will start up and then load ./u-boot. We could
> >> >> > > probably remove this and add SPL support to the vanilla sandbox 
> >> >> > > build,
> >> >> > > since people can still run ./u-boot directly
> >> >> > >
> >> >> > > At present there are unnecessary config differences between these
> >> >> > > builds. This is explained by the fact that it is a pain for people 
> >> >> > > to
> >> >> > > have to add configs separately to each defconfig. But we should
> >> >> > > probably make them more common. I will take a look.  
> >> >> >
> >> >> > OK.
> >> >> >  
> >> >> > > What do you think about dropping sandbox_spl and make sandbox build
> >> >> > > SPL? It does take slightly longer to build, perhaps 25%.  
> >> >> >
> >> >> > That's fine with me.
> >> >> >  
> >> >> > > > Cc: Simon Glass 
> >> >> > > > Signed-off-by: Tom Rini 
> >> >> > > > ---
> >> >> > > > I'm tempted to switch the main sandbox target over instead as I 
> >> >> > > > don't
> >> >> > > > quite see where we're running the tpm1.x tests automatically.  
> >> >> > > > Would
> >> >> > > > that be a better idea?
> >> >> > > > ---  
> >> >> > >
> >> >> > > Miquel, can we adjust the code to build both TPMv1 and v2 for 
> >> >> > > sandbox,
> >> >> > > and select at run-time?  
> >> >> >
> >> >> > I thought we had talked about that before and couldn't easily?  One
> >> >> > thing I am a bit wary of is adding indirection for build coverage 
> >> >> > sake.  
> >> >>
> >> >> Yes, I am hoping that it is just different drivers with the same API
> >> >> but perhaps I am going to be disappointed.  
> >> >
> >> > Indeed, both versions share the same 'architecture' but quite a few
> >> > structures/functions are defined differently for each TPM flavour in
> >> > different files. What makes the magic are the
> >> > #ifdef TPM_V1
> >> > #else
> >> > #endif
> >> > blocks around includes, making them mutually exclusive.
> >> >
> >> > Choice has been made not to use both flavours at the same time in the
> >> > second series, when I clearly made a separation between v1 code and v2
> >> > code. Trying to compile them both with just some Kconfig hacks 

Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

2018-06-09 Thread Alex Kiernan
On Fri, Jun 8, 2018 at 9:48 PM Adam Ford  wrote:
>
> When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> some devices may not boot.  This creates an option to enable
> block caching in SPL by defaults off.  It is dependant on BLOCK_CACHE
> and SPL_BLK
>
> Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
>
> Signed-off-by: Adam Ford 
>
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 0792373cfc..8ef363b3d4 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -37,6 +37,13 @@ config BLOCK_CACHE
>   it will prevent repeated reads from directory structures and other
>   filesystem data structures.
>
> +config SPL_BLOCK_CACHE
> +   bool "Use block device cache in SPL"
> +   depends on BLOCK_CACHE && SPL_BLK
> +   default n
> +   help
> + This option enables the disk-block cache in SPL
> +
>  config IDE
> bool "Support IDE controllers"
> select HAVE_BLOCK_DEVICE
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index 5fcafb193e..a9af28a552 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -11,4 +11,9 @@ endif
>
>  obj-$(CONFIG_IDE) += ide.o
>  obj-$(CONFIG_SANDBOX) += sandbox.o
> +ifdef CONFIG_SPL_BUILD
> +obj-$(SPL_BLOCK_CACHE) += blkcache.o

CONFIG_SPL_BLOCK_CACHE?

> +endif
> +ifndef CONFIG_SPL_BUILD
>  obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
> +endif

Could this all get replaced by:

obj-$(CONFIG_$(SPL_)BLOCK_CACHE) += blkcache.o

> diff --git a/include/blk.h b/include/blk.h
> index fc0c239e46..c17c5eb047 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -111,7 +111,8 @@ struct blk_desc {
>  #define PAD_TO_BLOCKSIZE(size, blk_desc) \
> (PAD_SIZE(size, blk_desc->blksz))
>
> -#ifdef CONFIG_BLOCK_CACHE
> +#if (defined(CONFIG_BLOCK_CACHE) && !defined(CONFIG_SPL_BUILD)) || \
> +(defined(CONFIG_SPL_BLOCK_CACHE) && defined(CONFIG_SPL_BUILD))
>  /**

Replace with CONFIG_IS_ENABLED?

>   * blkcache_read() - attempt to read a set of blocks from cache
>   *
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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


Re: [U-Boot] [PATCH v2] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE

2018-06-09 Thread Emmanuel Vadot
On Fri, 8 Jun 2018 08:28:02 +0200
Michal Simek  wrote:

> On 4.6.2018 12:21, Luca Ceresoli wrote:
> > The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus
> > forcing it to be a relative path inside the U-Boot source tree. Since
> > the PMUFW is a binary file generated outside of U-Boot, the PMUFW
> > binary must be copied inside the U-Boot source tree before the
> > build.
> > 
> > This generates a few problems:
> > 
> >  * if the source tree is shared among different out-of-tree builds,
> >they will pollute (and potentially corrupt) each other
> >  * the source tree cannot be read-only
> >  * any buildsystem must add a command to copy the PMUFW binary
> >  * putting an externally-generated binary in the source tree is ugly
> >as hell
> > 
> > Avoid these problems by accepting an absolute path for
> > PMUFW_INIT_FILE. This would be as simple as removing the "$(srctree)/"
> > prefix, but in order to keep backward compatibility we rather use the
> > shell and readlink to get the absolute path even when starting from a
> > relative path.
> > 
> > Since 'readlink -f' produces an empty string if the file does not
> > exist, we also add a check to ensure the file configured in
> > PMUFW_INIT_FILE exists. Otherwise the build would exit successfully,
> > but produce a boot.bin without PMUFW as if PMUFW_INIT_FILE were empty.
> > 
> > Tested in the 12 possible combinations of:
> >  - PMUFW_INIT_FILE empty, relative, absolute, non-existing
> >  - building in-tree, in subdir, in other directory
> > 
> > Signed-off-by: Luca Ceresoli 
> > Cc: Michal Simek 
> > Cc: Simon Glass 
> > Cc: Emmanuel Vadot 
> > 
> > ---
> > 
> > Changes v1 -> v2:
> >  - avoid non-portable 'readlink -m' by adding an explicit check to
> >ensure the file exists
> >  - test also the case where PMUFW_INIT_FILE points to a non-existing
> >file
> > ---
> >  scripts/Makefile.spl | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> > index 057389997de6..08660878b49e 100644
> > --- a/scripts/Makefile.spl
> > +++ b/scripts/Makefile.spl
> > @@ -167,8 +167,14 @@ ifdef CONFIG_ARCH_ZYNQ
> >  MKIMAGEFLAGS_boot.bin = -T zynqimage -R $(srctree)/$(CONFIG_BOOT_INIT_FILE)
> >  endif
> >  ifdef CONFIG_ARCH_ZYNQMP
> > +ifneq ($(CONFIG_PMUFW_INIT_FILE),"")
> > +spl/boot.bin: zynqmp-check-pmufw
> > +zynqmp-check-pmufw: FORCE
> > +   ( cd $(srctree) && test -r $(CONFIG_PMUFW_INIT_FILE) ) \
> > +   || ( echo "Cannot read $(CONFIG_PMUFW_INIT_FILE)" && false )
> > +endif
> >  MKIMAGEFLAGS_boot.bin = -T zynqmpimage -R 
> > $(srctree)/$(CONFIG_BOOT_INIT_FILE) \
> > -   -n $(srctree)/$(CONFIG_PMUFW_INIT_FILE)
> > +   -n "$(shell cd $(srctree); readlink -f $(CONFIG_PMUFW_INIT_FILE))"
> >  endif
> >  
> >  spl/boot.bin: $(obj)/u-boot-spl.bin FORCE
> > 
> 
> Emmanuel: Can you please try it and let me know if this works on BSD?
> 
> Thanks,
> Michal

 Yes no problem for readlink -f on BSD, I already answered to Luca.
 I don't know if you need a acked-by or something (and how to properly
send it) since I'm in CC.

 Cheers,

-- 
Emmanuel Vadot  
___
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

2018-06-09 Thread Heinrich Schuchardt
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.

As Mateusz will be the maintainer he should decide.

Best regards

Heinrich


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


Re: [U-Boot] [BUG] arch/x86/dts/cherryhill.dtb - unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

2018-06-09 Thread Bin Meng
Hi Heinrich,

On Sat, Jun 9, 2018 at 6:02 PM, Heinrich Schuchardt  wrote:
> Hello Bin,
>
> tools/buildman/buildman fails with
>
> arch/x86/dts/cherryhill.dtb: Warning (avoid_unnecessary_addr_size):
> /pci/pch@1f,0: unnecessary #address-cells/#size-cells without "ranges"
> or child "reg" property
>
> Would you know how to fix this?
>

I cannot reproduce this using buildman. What instructions are you using?

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

2018-06-09 Thread Ramon Fried
On Sat, Jun 9, 2018 at 1:24 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)
>>
>> 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 
>> ---
>>
>
> 
>
>> +/* Pointer to the one and only smem handle */
>> +static struct qcom_smem *__smem;
>> +
>> +static int qcom_smem_alloc_private(struct qcom_smem *smem,
>> +struct smem_partition_header *phdr,
>> +unsigned item,
>> +size_t size)
>> +{
>
> 
>
>> +  */
>> + dmb();
>> + le32_add_cpu(>offset_free_uncached, alloc_size);
>
>
> drivers/soc/qualcomm/smem.c: In function ‘qcom_smem_alloc_private’:
> drivers/soc/qualcomm/smem.c:391:2: warning: implicit declaration of
> function ‘le32_add_cpu’ [-Wimplicit-function-declaration]
>   le32_add_cpu(>offset_free_uncached, alloc_size);
>
> Please, add the missing definition to
> ./include/linux/byteorder/generic.h
> or reference the prerequisite patch in the commit message.
Hi Heinrich, the prerequisite patch was mentioned in the cover letter.
I thought it's good enough, I can add it also to the commit message if
necessary.
Nevertheless, here it is:
https://patchwork.ozlabs.org/patch/924769/
Thanks,
Ramon.
>
> Best regards
>
> Heinrich
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] dm: SOC (System on chip) uclass

2018-06-09 Thread Heinrich Schuchardt
On 06/09/2018 01:06 PM, Ramon Fried wrote:
> This is a simple uclass for SOC drivers.
> It is intend to serve as uclass for SOC specific drivers
> that don't fall into any other uclass catagories.
> Currently, it doesn't define any special ops.
> 
> Signed-off-by: Ramon Fried 

Reviewed-by: Heinrich Schuchardt 
___
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

2018-06-09 Thread Ramon Fried
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 ?

>
> WARNING: line over 80 characters
> #1064: FILE: drivers/soc/qualcomm/smem.c:846:
> +   smem->regions[i].virt_base = devm_ioremap(dev, r.start,
> fdt_resource_size());
>
> CHECK: Alignment should match open parenthesis
> #1098: FILE: drivers/soc/qualcomm/smem.c:880:
> +   if (num_regions > 1 && (ret = qcom_smem_map_memory(smem, dev,
> +   "qcom,rpm-msg-ram", 1)))
>
> Do not use DOS line endings.
Sure. Thanks.
>
> Best regards
>
> Heinrich Schuchardt
___
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

2018-06-09 Thread Heinrich Schuchardt
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)
> 
> 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 
> ---
> 



> +/* Pointer to the one and only smem handle */
> +static struct qcom_smem *__smem;
> +
> +static int qcom_smem_alloc_private(struct qcom_smem *smem,
> +struct smem_partition_header *phdr,
> +unsigned item,
> +size_t size)
> +{



> +  */
> + dmb();
> + le32_add_cpu(>offset_free_uncached, alloc_size);


drivers/soc/qualcomm/smem.c: In function ‘qcom_smem_alloc_private’:
drivers/soc/qualcomm/smem.c:391:2: warning: implicit declaration of
function ‘le32_add_cpu’ [-Wimplicit-function-declaration]
  le32_add_cpu(>offset_free_uncached, alloc_size);

Please, add the missing definition to
./include/linux/byteorder/generic.h
or reference the prerequisite patch in the commit message.

Best regards

Heinrich

___
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

2018-06-09 Thread Heinrich Schuchardt
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.

WARNING: line over 80 characters
#1064: FILE: drivers/soc/qualcomm/smem.c:846:
+   smem->regions[i].virt_base = devm_ioremap(dev, r.start,
fdt_resource_size());

CHECK: Alignment should match open parenthesis
#1098: FILE: drivers/soc/qualcomm/smem.c:880:
+   if (num_regions > 1 && (ret = qcom_smem_map_memory(smem, dev,
+   "qcom,rpm-msg-ram", 1)))

Do not use DOS line endings.

Best regards

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


[U-Boot] [BUG] arch/x86/dts/cherryhill.dtb - unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

2018-06-09 Thread Heinrich Schuchardt
Hello Bin,

tools/buildman/buildman fails with

arch/x86/dts/cherryhill.dtb: Warning (avoid_unnecessary_addr_size):
/pci/pch@1f,0: unnecessary #address-cells/#size-cells without "ranges"
or child "reg" property

Would you know how to fix this?

Best regards

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


Re: [U-Boot] [PATCH] env: Add !ENV_IS_IN_EXT4 dependency to ENV_IS_NOWHERE

2018-06-09 Thread Petr Vorel
Hi Alex,

> If ENV_IS_IN_EXT4 is set you shouldn't be able to select ENV_IS_NOWHERE.

> Signed-off-by: Alex Kiernan 
Tested-by: Petr Vorel 

Nice fix, thanks :)

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


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

2018-06-09 Thread Chris Packham
Combine repeated code from smi_reg_read/smi_reg_write into a common
function smi_wait_ready.

Reviewed-by: Stefan Roese 
Signed-off-by: Chris Packham 
---

Changes in v2:
- collect review from Stefan
- use wait_for_bit_le32()

 drivers/net/mvgbe.c | 47 ++---
 drivers/net/mvgbe.h |  1 +
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 4e1aff6e3a86..e6585ef8b3e7 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,10 +41,24 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi)
 
 #if defined(CONFIG_PHYLIB) || defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+static int smi_wait_ready(struct mvgbe_device *dmvgbe)
+{
+   int ret;
+
+   ret = wait_for_bit_le32(_SMI_REG, MVGBE_PHY_SMI_BUSY_MASK, false,
+   MVGBE_PHY_SMI_TIMEOUT_MS, false);
+   if (ret) {
+   printf("Error: SMI busy timeout\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * smi_reg_read - miiphy_read callback function.
  *
- * Returns 16bit phy register value, or 0x on error
+ * Returns 16bit phy register value, or -EFAULT on error
  */
 static int smi_reg_read(struct mii_dev *bus, int phy_adr, int devad,
int reg_ofs)
@@ -74,16 +89,9 @@ static int smi_reg_read(struct mii_dev *bus, int phy_adr, 
int devad,
return -EFAULT;
}
 
-   timeout = MVGBE_PHY_SMI_TIMEOUT;
/* wait till the SMI is not busy */
-   do {
-   /* read smi register */
-   smi_reg = MVGBE_REG_RD(MVGBE_SMI_REG);
-   if (timeout-- == 0) {
-   printf("Err..(%s) SMI busy timeout\n", __func__);
-   return -EFAULT;
-   }
-   } while (smi_reg & MVGBE_PHY_SMI_BUSY_MASK);
+   if (smi_wait_ready(dmvgbe) < 0)
+   return -EFAULT;
 
/* fill the phy address and regiser offset and read opcode */
smi_reg = (phy_adr << MVGBE_PHY_SMI_DEV_ADDR_OFFS)
@@ -119,10 +127,9 @@ static int smi_reg_read(struct mii_dev *bus, int phy_adr, 
int devad,
 }
 
 /*
- * smi_reg_write - imiiphy_write callback function.
+ * smi_reg_write - miiphy_write callback function.
  *
- * Returns 0 if write succeed, -EINVAL on bad parameters
- * -ETIME on timeout
+ * Returns 0 if write succeed, -EFAULT on error
  */
 static int smi_reg_write(struct mii_dev *bus, int phy_adr, int devad,
 int reg_ofs, u16 data)
@@ -131,7 +138,6 @@ static int smi_reg_write(struct mii_dev *bus, int phy_adr, 
int devad,
struct mvgbe_device *dmvgbe = to_mvgbe(dev);
struct mvgbe_registers *regs = dmvgbe->regs;
u32 smi_reg;
-   u32 timeout;
 
/* Phyadr write request*/
if (phy_adr == MV_PHY_ADR_REQUEST &&
@@ -147,19 +153,12 @@ static int smi_reg_write(struct mii_dev *bus, int 
phy_adr, int devad,
}
if (reg_ofs > PHYREG_MASK) {
printf("Err..(%s) Invalid register offset\n", __func__);
-   return -EINVAL;
+   return -EFAULT;
}
 
/* wait till the SMI is not busy */
-   timeout = MVGBE_PHY_SMI_TIMEOUT;
-   do {
-   /* read smi register */
-   smi_reg = MVGBE_REG_RD(MVGBE_SMI_REG);
-   if (timeout-- == 0) {
-   printf("Err..(%s) SMI busy timeout\n", __func__);
-   return -ETIME;
-   }
-   } while (smi_reg & MVGBE_PHY_SMI_BUSY_MASK);
+   if (smi_wait_ready(dmvgbe) < 0)
+   return -EFAULT;
 
/* fill the phy addr and reg offset and write opcode and data */
smi_reg = (data << MVGBE_PHY_SMI_DATA_OFFS);
diff --git a/drivers/net/mvgbe.h b/drivers/net/mvgbe.h
index c20d1d7edf7b..1dc9bbea2f42 100644
--- a/drivers/net/mvgbe.h
+++ b/drivers/net/mvgbe.h
@@ -216,6 +216,7 @@
 
 /* SMI register fields */
 #define MVGBE_PHY_SMI_TIMEOUT  1
+#define MVGBE_PHY_SMI_TIMEOUT_MS   1000
 #define MVGBE_PHY_SMI_DATA_OFFS0   /* Data */
 #define MVGBE_PHY_SMI_DATA_MASK(0x << 
MVGBE_PHY_SMI_DATA_OFFS)
 #define MVGBE_PHY_SMI_DEV_ADDR_OFFS16  /* PHY device address */
-- 
2.17.1

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


Re: [U-Boot] Generic uclass ID

2018-06-09 Thread Ramon Fried
On Fri, Jun 8, 2018 at 2:17 AM, Simon Glass  wrote:
> Hi Ramon,
>
> On 7 June 2018 at 13:41, Ramon Fried  wrote:
>> On Thu, Jun 7, 2018 at 11:28 PM, Simon Glass  wrote:
>>> Hi Ramon,
>>>
>>> On 3 June 2018 at 14:32, Ramon Fried  wrote:
 On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried  wrote:
> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt  
> wrote:
>> On 06/02/2018 06:25 PM, Ramon Fried wrote:
>>> Hi Simon, all.
>>>
>>> I want to port a specific driver from Linux Kernel (Qualcomm smem)
>>> which is declared in Linux as platform device.
>>> The implementation is very specific and It doesn't fall into any
>>> defined uclass id.
>>> I still want to use the dm framework, what's the approach taken on
>>> these kind of things ?
>>> Is it possible to create a generic uclass id ?
>>
>> Hello Ramon,
>>
>> a major benefit of the driver model is that drivers are selected via the
>> device tree.
>>
>> In Linux the driver is in drivers/soc. Wouldn't it make sense to create
>> a minimal uclass for platform devices in drivers/soc on U-Boot?
>>
>> drivers/ram/ram-uclass.c shows what a minimal uclass looks like.
>> The identifier has to be added in include/dm/uclass-id.h.
>>
>> Best regards
>>
>> Heinrich
> Thanks for the comment Heinrich.
> My initial intention was to place the driver under drivers/soc and I
> do thing that
> creating a UCLASS_PLATFORM make sense, acutally, it's exaclt what I'm 
> suggesting
> in a different name.
> The thing is that there's no apperent ops that I think will suit all
> the platform drivers as they're different in nature.
> So, I don't see any requirement to create a platform_uclass.c file.
>
> Thanks,
> Ramon.

 Added some initial contributors to uclass for comments.
>>>
>>> It's OK to create a uclass if you need to. What does your driver do?
>> Hi Simon, thanks for replying.
>> The driver purpose is to provide a way to access Qualcomm's shared
>> memory region and
>> to read and write properties to it accessed by other cores (Trustzone
>> for instance).
>> The Linux kernel driver I use as a reference
>> (https://elixir.bootlin.com/linux/latest/source/drivers/soc/qcom/smem.c)
>> relies heavily on device-tree bindings, and I wanted to keep as much
>> of the driver intact.
>>
>> As this is very specific to Qualcomm, I don't think that it fits any
>> other UCLASS_ definition and thus I
>> suggested adding UCLASS_PLATFORM which is intended for platform
>> specific drivers/devices.
>>
>> In such a case, the .ops will be empty as there isn't any shared
>> functionailty that can be generalized.
>>
>> Does this make sense ? should I ditch the driver-module idea and just
>> implement it as piece of code under arch/arm/mach-snapdragon ?
>
> I don't see why this is specific to Qualcomm. What is specific about
> it? The driver certainly may be specific, but the idea of wanting to
> maintain shared memory and control access to it from different CPUs
> seems pretty general to me, and I think it would be useful as a
> uclass.
>
> Here are some ideas:
>
> mailbox - has multiple channels but is stream-based
> misc - single channel read/write but does have ioctl() and call()
> remoteproc - more about executing code remotely
>
> If none of these suits or can be enhanced, how about creating a new one?
>
> BTW it would be great if you could send a patch to fix the first line
> of the description of that module in the link you provided:
>
> "The Qualcomm shared memory system is a allocate only heap structure that"
Fixed that in the U-boot case. I'm not sure that a change from a -> an
will be accepted.

>
> Should be: "...an allocate-only heap..."
I didn't manage to find any common functionality I can declare in ops.
just check out the EXPORT
functions in smem.c.
In Addition, I'm not familiar with others specific soc shared memory managers.
I ended up declaring a new class UCLASS_SOC. just sent the patchset.
please tell me what you
think.

Thanks !

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


[U-Boot] [PATCH 4/4] dts: db820c: added smem nodes

2018-06-09 Thread Ramon Fried
Added necessary nodes for Qualcomm smem driver.

Signed-off-by: Ramon Fried 
---

 arch/arm/dts/dragonboard820c-uboot.dtsi |  4 
 arch/arm/dts/dragonboard820c.dts| 16 
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi 
b/arch/arm/dts/dragonboard820c-uboot.dtsi
index 97394cc5b0..d60aa04494 100644
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
@@ -6,6 +6,10 @@
  */
 
 / {
+   smem {
+   u-boot,dm-pre-reloc;
+   };
+
soc {
u-boot,dm-pre-reloc;
 
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 7457d7b7e3..ffad8e0e0a 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -28,11 +28,27 @@
reg = <0 0x8000 0 0xc000>;
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   smem_mem: smem_region@8630 {
+   reg = <0x0 0x8630 0x0 0x20>;
+   no-map;
+   };
+   };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
};
 
+   smem {
+   compatible = "qcom,smem";
+   memory-region = <_mem>;
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
2.17.1

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


[U-Boot] [PATCH 3/4] dts: db410c: added smem nodes

2018-06-09 Thread Ramon Fried
Added necessary nodes for Qualcomm smem driver.

Signed-off-by: Ramon Fried 
---

 arch/arm/dts/dragonboard410c-uboot.dtsi |  4 
 arch/arm/dts/dragonboard410c.dts| 16 
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index 3b87639519..4e202d0008 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -10,6 +10,10 @@
u-boot,mmc-env-partition = "boot";
};
 
+   smem {
+   u-boot,dm-pre-reloc;
+   };
+
soc {
u-boot,dm-pre-reloc;
 
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 182a865b0a..f4f7c350ec 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -27,18 +27,34 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+
+   smem_mem: smem_region@8630 {
+   reg = <0x0 0x8630 0x0 0x10>;
+   no-map;
+   };
};
 
chosen {
stdout-path = "/soc/serial@78b";
};
 
+   smem {
+   compatible = "qcom,smem";
+   memory-region = <_mem>;
+   qcom,rpm-msg-ram = <_msg_ram>;
+   };
+
soc {
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges = <0x0 0x0 0x0 0x>;
compatible = "simple-bus";
 
+   rpm_msg_ram: memory@6 {
+   compatible = "qcom,rpm-msg-ram";
+   reg = <0x6 0x8000>;
+   };
+
pinctrl: qcom,tlmm@100 {
compatible = "qcom,tlmm-apq8016";
reg = <0x100 0x40>;
-- 
2.17.1

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


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

2018-06-09 Thread Ramon Fried
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

diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448093..e57c5137d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -187,6 +187,7 @@ ARM SNAPDRAGON
 M: Mateusz Kulikowski 
 S: Maintained
 F: arch/arm/mach-snapdragon/
+F: drivers/soc/qualcomm/
 
 ARM STI
 M: Patrice Chotard 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d..5af9aa78fc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -728,6 +728,7 @@ config ARCH_SNAPDRAGON
select SPMI
select OF_CONTROL
select OF_SEPARATE
+   select MSM_SMEM
 
 config ARCH_SOCFPGA
bool "Altera SOCFPGA family"
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9e21b28750..d1167a3a4a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -104,6 +104,8 @@ source "drivers/video/Kconfig"
 
 source "drivers/watchdog/Kconfig"
 
+source "drivers/soc/Kconfig"
+
 config PHYS_TO_BUS
bool "Custom physical to bus address mapping"
help
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
new file mode 100644
index 00..79b88812ba
--- /dev/null
+++ b/drivers/soc/Kconfig
@@ -0,0 +1,5 @@
+menu "SOC (System On Chip) specific Drivers"
+
+source "drivers/soc/qualcomm/Kconfig"
+
+endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index d17f6ecaa0..781a6b73b2 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,4 +3,5 @@
 # Makefile for the U-Boot SOC specific device drivers.
 
 obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
+obj-$(CONFIG_ARCH_SNAPDRAGON)  += qualcomm/
 obj-y += soc-uclass.o
diff --git a/drivers/soc/qualcomm/Kconfig b/drivers/soc/qualcomm/Kconfig
new file mode 100644
index 00..aeeaf2bb10
--- /dev/null
+++ b/drivers/soc/qualcomm/Kconfig
@@ -0,0 +1,11 @@
+menu "Qualcomm SoC drivers"
+
+config MSM_SMEM
+   bool "Qualcomm Shared Memory Manager (SMEM)"
+   depends on ARCH_SNAPDRAGON
+   help
+ Say y here to enable support for the Qualcomm Shared Memory Manager.
+ The driver provides an interface to items in a heap shared among all
+ processors in a Qualcomm platform.
+
+endmenu
diff --git a/drivers/soc/qualcomm/Makefile b/drivers/soc/qualcomm/Makefile
new file mode 100644
index 00..833944a315
--- /dev/null
+++ b/drivers/soc/qualcomm/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_MSM_SMEM) += smem.o
diff --git a/drivers/soc/qualcomm/smem.c b/drivers/soc/qualcomm/smem.c
new file mode 100644
index 00..416538ba3b
--- /dev/null
+++ b/drivers/soc/qualcomm/smem.c
@@ -0,0 +1,934 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, Ramon Fried 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The Qualcomm shared memory system is an allocate only heap structure that
+ * consists of one of more memory areas that can be accessed by the processors
+ * in the SoC.
+ *
+ * All systems contains a global heap, accessible by all processors in the SoC,
+ * with a table of contents data structure (@smem_header) at the beginning of
+ * the main shared memory block.
+ *
+ * The global header contains meta data for allocations as well as a fixed list
+ * of 512 entries (@smem_global_entry) that can be initialized to reference
+ * parts of the shared memory space.
+ *
+ *
+ * In addition 

[U-Boot] [PATCH 1/4] dm: SOC (System on chip) uclass

2018-06-09 Thread Ramon Fried
This is a simple uclass for SOC drivers.
It is intend to serve as uclass for SOC specific drivers
that don't fall into any other uclass catagories.
Currently, it doesn't define any special ops.

Signed-off-by: Ramon Fried 

---

 drivers/soc/Makefile | 1 +
 drivers/soc/soc-uclass.c | 8 
 include/dm/uclass-id.h   | 1 +
 3 files changed, 10 insertions(+)
 create mode 100644 drivers/soc/soc-uclass.c

diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 42037f99d5..d17f6ecaa0 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,3 +3,4 @@
 # Makefile for the U-Boot SOC specific device drivers.
 
 obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
+obj-y += soc-uclass.o
diff --git a/drivers/soc/soc-uclass.c b/drivers/soc/soc-uclass.c
new file mode 100644
index 00..858f30649f
--- /dev/null
+++ b/drivers/soc/soc-uclass.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include 
+#include 
+
+UCLASS_DRIVER(soc) = {
+   .id = UCLASS_SOC,
+   .name   = "soc",
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index d7f9df3583..a79cc9aa6d 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -74,6 +74,7 @@ enum uclass_id {
UCLASS_RTC, /* Real time clock device */
UCLASS_SCSI,/* SCSI device */
UCLASS_SERIAL,  /* Serial UART */
+   UCLASS_SOC, /* SOC (System on chip) specific device */
UCLASS_SPI, /* SPI bus */
UCLASS_SPMI,/* System Power Management Interface bus */
UCLASS_SPI_FLASH,   /* SPI flash */
-- 
2.17.1

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


[U-Boot] [PATCH 0/4] Qualcomm SMEM driver

2018-06-09 Thread Ramon Fried
This patchset introduces Qualcomm's shared memory manager.
In U-boot context, it will allow reading board specific information
(IE. RAM address, RAM size) that was prepopulated by the SBL.

As part of the patchset a new uclass id is introduced, UCLASS_SOC.
The UCLASS_SOC is a class intended for SOC specific drivers that
don't fall into any other uclass catagories.

Tom: Please make sure that this only get merged after:
https://patchwork.ozlabs.org/patch/924769/ as the smem driver needs some
Linux definitions that needs update in U-boot.


Ramon Fried (4):
  dm: SOC (System on chip) uclass
  soc: qualcomm: Add Shared Memory Manager driver
  dts: db410c: added smem nodes
  dts: db820c: added smem nodes

 MAINTAINERS |   1 +
 arch/arm/Kconfig|   1 +
 arch/arm/dts/dragonboard410c-uboot.dtsi |   4 +
 arch/arm/dts/dragonboard410c.dts|  16 +
 arch/arm/dts/dragonboard820c-uboot.dtsi |   4 +
 arch/arm/dts/dragonboard820c.dts|  16 +
 drivers/Kconfig |   2 +
 drivers/soc/Kconfig |   5 +
 drivers/soc/Makefile|   2 +
 drivers/soc/qualcomm/Kconfig|  11 +
 drivers/soc/qualcomm/Makefile   |   3 +
 drivers/soc/qualcomm/smem.c | 934 
 drivers/soc/soc-uclass.c|   8 +
 include/dm/uclass-id.h  |   1 +
 14 files changed, 1008 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
 create mode 100644 drivers/soc/soc-uclass.c

-- 
2.17.1

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