Re: [U-Boot] [RFC 4/8] cmd: bootefi: move do_bootefi_bootmgr_exec() forward

2019-03-21 Thread AKASHI Takahiro
On Thu, Mar 21, 2019 at 12:48:53PM +0100, Heinrich Schuchardt wrote:
> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch.
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 42 +-
> >  1 file changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3619a20e6433..1d90e7b4b575 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -314,6 +314,27 @@ err_add_protocol:
> > return ret;
> >  }
> >
> > +static int do_bootefi_bootmgr_exec(void)
> > +{
> > +   struct efi_device_path *device_path, *file_path;
> > +   void *addr;
> > +   efi_status_t r;
> > +
> > +   addr = efi_bootmgr_load(_path, _path);
> > +   if (!addr)
> > +   return 1;
> > +
> > +   printf("## Starting EFI application at %p ...\n", addr);
> > +   r = do_bootefi_exec(addr, device_path, file_path);
> > +   printf("## Application terminated, r = %lu\n",
> > +  r & ~EFI_ERROR_MASK);
> > +   if (r != EFI_SUCCESS)
> > +   return 1;
> 
> return CMD_RET_FAILURE ?
> 
> > +
> > +   return 0;
> 
> return CMD_RET_SUCCESS ?
> 
> The lines following efi_bootmgr_load() are duplicating code from
> do_bootefi().

do_bootefi() -> do_boot_efi()?

> The patch itself is ok. But in the patch series we should get rid of the
> duplication.

We only share:
> > +   printf("## Starting EFI application at %p ...\n", addr);
> > +   r = do_bootefi_exec(addr, device_path, file_path);
> > +   printf("## Application terminated, r = %lu\n",
> > +  r & ~EFI_ERROR_MASK);
> > +   if (r != EFI_SUCCESS)
> > +   return 1;

Can we call it a duplication?
# I don't like the print messages here anyway.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > +}
> > +
> >  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> >  /**
> >   * bootefi_test_prepare() - prepare to run an EFI test
> > @@ -362,27 +383,6 @@ failure:
> >
> >  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> >
> > -static int do_bootefi_bootmgr_exec(void)
> > -{
> > -   struct efi_device_path *device_path, *file_path;
> > -   void *addr;
> > -   efi_status_t r;
> > -
> > -   addr = efi_bootmgr_load(_path, _path);
> > -   if (!addr)
> > -   return 1;
> > -
> > -   printf("## Starting EFI application at %p ...\n", addr);
> > -   r = do_bootefi_exec(addr, device_path, file_path);
> > -   printf("## Application terminated, r = %lu\n",
> > -  r & ~EFI_ERROR_MASK);
> > -
> > -   if (r != EFI_SUCCESS)
> > -   return 1;
> > -
> > -   return 0;
> > -}
> > -
> >  /* Interpreter command to boot an arbitrary EFI image from memory */
> >  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> >  {
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] CONFIG_OF_EMBED

2019-03-21 Thread Simon Glass
Hi,

On Fri, 22 Mar 2019 at 05:37, Marek Vasut  wrote:
>
> On 3/21/19 5:37 PM, Dalon L Westergreen wrote:
> > On Thu, 2019-03-21 at 16:48 +0100, Marek Vasut wrote:
> >> On 3/21/19 3:33 PM, Dalon L Westergreen wrote:
> >>> On Thu, 2019-03-21 at 03:30 +0100, Marek Vasut wrote:
>  On 3/20/19 9:24 PM, Dalon L Westergreen wrote:
> > On Wed, 2019-03-20 at 19:37 +0100, Marek Vasut wrote:
> >> On 3/20/19 6:28 PM, Dalon L Westergreen wrote:
> >>> Hey Marek,
> >>
> >> Hi,
> >>
> >>> A while ago, when adding the hex output required for stratix10, I
> >>> enabled
> >>> CONFIG_OF_EMBED so that the spl elf included the dtb.  This avoided
> >>> the
> >>> --
> >>> change-address option when using objcopy to convert the u-boot-spl-
> >>> dtb.bin
> >>> into
> >>> a hex file with the correct address as required by the quartus
> >>> tools.
> >>>
> >>> In any case, there is now a warning that CONFIG_OF_EMBED should only
> >>> be
> >>> used
> >>> for
> >>> development and debug.  I am wondering how best to resolve this
> >>> issue,
> >>> should i
> >>> revert back to using objcopy with the u-boot-spl-dtb.bin, is there a
> >>> way
> >>> to
> >>> have
> >>> CONFIG_OF_EMBED only apply to SPL?
> >>
> >> CONFIG_OF_SEPARATE is what you want.
> >
> > I dont think this is what i want exactly.  I was thinking of this.
> > From 82c1d1bc6092ce40f33a04f2bc7713b0143e30a5 Mon Sep 17 00:00:00 2001
> > From: Dalon Westergreen 
> > Date: Wed, 20 Mar 2019 11:21:20 -0700
> > Subject: [PATCH 1/2] Makefile: Add target to generate hex output for
> > combined
> >  spl and dtb
> >
> > Some architectures, Stratix10, require a hex formatted spl that combines
> > the spl image and dtb.  This adds a target to create said hex file with
> > and offset of SPL_TEXT_BASE.

I don't really follow this thread, but you should not use
CONFIG_OF_EMBED. If there is a problem with setting up the image with
CONFIG_OF_SEPARATE, we should discuss it.

- Simon

> 
>  The CONFIG_OF_SEPARATE doesn't generate a combined image anymore ? Seems
>  like it does at least on the renesas platforms (cfr e.g.
>  stout_defconfig, where I use exactly that).
> >>>
> >>> It generates a combined binary, u-boot-spl-dtb.bin, as far as i know.
> >>> The elf is not combined, so using objcopy on the elf results in a hex
> >>> file without the dtb.  Stratix 10 needs a combined hex file that starts
> >>> at CONFIG_SPL_TEXT_BASE.  This file is then combined by quartus with
> >>> the fpga image.  The SDM loads the spl image into the cpu's onchip ram
> >>> and releases it from reset.
> >>>
> >>> So what i am trying to do is get a hex file generated that is appriopriate
> >>> for the quartus tools.  With CONFIG_OF_EMBED, this was easy, as you just
> >>> run objcopy on the elf to create the hex output.  With CONFIG_OF_SEPARATE
> >>> you need the combined binary to do the same.  hence,
> >>>
> >>> +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex --change-
> > address=$(CONFIG_SPL_TEXT_BASE)
> > +
> > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl-dtb.bin FORCE
> > +   $(call if_changed,objcopy)
> >> Aha, right. CCing Simon, maybe he has some better idea.
> >>
> >> Otherwise, let's add the custom target. Maybe we can add it to
> >> arch/arm/mach-socfpga instead though.
> >
> > After a quick test to add the target to mach-socfpga instead of the root
> > Makefile, it seems i would still need to modify the root Makefile to call
> > the mach-socfpga makefile for the target in any case.  If acceptable, i
> > think it cleaner to just add the target to the root Makefile.
>
> I think that's fine. The root Makefile is growing like dough. that needs
> to stop.
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 3/8] efi_loader: bootmgr: return pointer and size of buffer in loading

2019-03-21 Thread AKASHI Takahiro
On Thu, Mar 21, 2019 at 12:41:06PM +0100, Heinrich Schuchardt wrote:
> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> > We need to know the size of image loaded so as to be able to use
> > load_image() API at do_bootefi_exec() in a later patch.
> >
> > So change the interface of efi_bootmgr_load().
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/efi_loader.h |  5 +++--
> >  lib/efi_loader/efi_bootmgr.c | 41 +---
> >  2 files changed, 27 insertions(+), 19 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 47a51ddc9406..3f51116155ad 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -564,8 +564,9 @@ struct efi_load_option {
> >
> >  void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
> >  unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 
> > **data);
> > -void *efi_bootmgr_load(struct efi_device_path **device_path,
> > -  struct efi_device_path **file_path);
> > +efi_status_t efi_bootmgr_load(struct efi_device_path **device_path,
> > + struct efi_device_path **file_path,
> > + void **image, efi_uintn_t *size);
> >
> >  #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index 1575c5c09e46..38f3fa15f6ef 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -120,14 +120,17 @@ static void *get_var(u16 *name, const efi_guid_t 
> > *vendor,
> >   * if successful.  This checks that the EFI_LOAD_OPTION is active (enabled)
> >   * and that the specified file to boot exists.
> >   */
> > -static void *try_load_entry(uint16_t n, struct efi_device_path 
> > **device_path,
> > -   struct efi_device_path **file_path)
> > +static efi_status_t try_load_entry(u16 n,
> > +  struct efi_device_path **device_path,
> > +  struct efi_device_path **file_path,
> > +  void **image, efi_uintn_t *image_size)
> >  {
> > struct efi_load_option lo;
> > u16 varname[] = L"Boot";
> > u16 hexmap[] = L"0123456789ABCDEF";
> > -   void *load_option, *image = NULL;
> > +   void *load_option;
> > efi_uintn_t size;
> > +   efi_status_t ret;
> >
> > varname[4] = hexmap[(n & 0xf000) >> 12];
> > varname[5] = hexmap[(n & 0x0f00) >> 8];
> > @@ -136,18 +139,17 @@ static void *try_load_entry(uint16_t n, struct 
> > efi_device_path **device_path,
> >
> > load_option = get_var(varname, _global_variable_guid, );
> > if (!load_option)
> > -   return NULL;
> > +   return EFI_LOAD_ERROR;
> >
> > efi_deserialize_load_option(, load_option);
> >
> > if (lo.attributes & LOAD_OPTION_ACTIVE) {
> > u32 attributes;
> > -   efi_status_t ret;
> >
> > debug("%s: trying to load \"%ls\" from %pD\n",
> >   __func__, lo.label, lo.file_path);
> >
> > -   ret = efi_load_image_from_path(lo.file_path, , );
> > +   ret = efi_load_image_from_path(lo.file_path, image, image_size);
> >
> 
> This call to efi_load_image_from_path() leads to duplication of logic.
> 
> Why don't we simply call EFI_CALL(efi_load_image())) here and if it
> succeeds return from efi_bootmgr_load()?

Make sense. It will make do_bootefi_exec() simpler.
This will also give us a reason why we have do_efibootmgr() apart
from do_boot_efi().

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > if (ret != EFI_SUCCESS)
> > goto error;
> > @@ -164,12 +166,14 @@ static void *try_load_entry(uint16_t n, struct 
> > efi_device_path **device_path,
> >
> > printf("Booting: %ls\n", lo.label);
> > efi_dp_split_file_path(lo.file_path, device_path, file_path);
> > +   } else {
> > +   ret = EFI_LOAD_ERROR;
> > }
> >
> >  error:
> > free(load_option);
> >
> > -   return image;
> > +   return ret;
> >  }
> >
> >  /*
> > @@ -177,12 +181,12 @@ error:
> >   * EFI variable, the available load-options, finding and returning
> >   * the first one that can be loaded successfully.
> >   */
> > -void *efi_bootmgr_load(struct efi_device_path **device_path,
> > -  struct efi_device_path **file_path)
> > +efi_status_t efi_bootmgr_load(struct efi_device_path **device_path,
> > + struct efi_device_path **file_path,
> > + void **image, efi_uintn_t *image_size)
> >  {
> > u16 bootnext, *bootorder;
> > efi_uintn_t size;
> > -   void *image = NULL;
> > int i, num;
> > efi_status_t ret;
> >
> > @@ -201,9 +205,9 @@ void *efi_bootmgr_load(struct efi_device_path 
> > **device_path,
> > (efi_guid_t *)_global_variable_guid,
> > 0, 0, ));
> > if (ret == 

Re: [U-Boot] [PATCH] lib: tiny-printf: Add "%ll" modifier support

2019-03-21 Thread Tom Rini
On Fri, Mar 22, 2019 at 09:28:21AM +0800, Ley Foon Tan wrote:
> On Thu, Mar 21, 2019 at 7:22 PM Tom Rini  wrote:
> >
> > On Fri, Mar 22, 2019 at 01:12:14AM +0800, Ley Foon Tan wrote:
> >
> > > Add "%ll" modifier support for tiny printf.
> > >
> > > - Tested on ARM32 and ARM64 systems.
> > > - Tested "%lld", "%llu", "%llx" and "%p" format with
> > >   minimum and maximum ranges. Compared tiny printf
> > >   output with full printf.
> > >
> > > Signed-off-by: Ley Foon Tan 
> > > ---
> > >  lib/tiny-printf.c | 42 +-
> > >  1 file changed, 29 insertions(+), 13 deletions(-)
> >
> > What's the use case for this, how much does it grow the size, and can
> > the code in question be changed to use a different format modifier or be
> > debug() instead?  Tiny printf isn't intended to cover all formats but
> > rather still allow some amount of printf on constrained systems.
> > Thanks!
> >
> > --
> > Tom
> This is to support printf %lld, %llu and %llx and 64-bit %p when
> CONFIG_USE_TINY_PRINTF=y is enabled.
> In 64-bit system, phys_size_t and phys_addr_t are unsigned long long.
> Printf these variables will see rubbish in existing tiny printf.
> 
> Example %ll printf;
> printf("9223372036854775807 ==> %lld \n",  (long long)9223372036854775807);
> printf("0x ==> 0x%llx \n", (unsigned long
> long)0x);
> 
> There are few issues I've noticed with original tiny printf:
> - Some common codes use %ll format
> - %p in tiny printf only support 32-bit, it can't support 64-bit address.
> 
> If DEBUG is defined and with tiny printf. You can see all rubbish x
> for %llx printf. The most serious issue is it cause system hang at
> line below (printf from common code).
> addr=x level=0
> idx=x PTE  at level 16384: x
> Creating table for virt 0xx
> Setting 4000 to addr=5000
> addr=x level=0
> idx=x PTE  at level 16384: x
> idx=x PTE  at level 20480: x
> Checking if pte fits for virt=x size=x blocksize=x
> Setting PTE 5000 to block virt=x
> addr=x level=1073741824
> idx=x PTE  at level 16384: x
> addr=x level=1073741824
> idx=x PTE  at level 16384: x
> idx=x PTE 1 at level 20488: x
> Checking if pte fits for virt=x size=x blocksize=x
> Setting PTE 5008 to block virt=x
> addr=x level=
> 
> Example output after apply this patch:
> idx=0 PTE 8000 at level 0: 9003
> idx=3 PTE 9018 at level 1: a003
> Checking if pte fits for virt=c060 size=1fa0 blocksize=4000
> addr=c060 level=2
> idx=0 PTE 8000 at level 0: 9003
> idx=3 PTE 9018 at level 1: a003
> 
> 
> ARM64:
> --
> It increase 200 bytes.
> 
> Before:
>text   databssdechexfilename
>   69618   5296232  75146  1258aspl/u-boot-spl
> 
> After:
>text   databssdechexfilename
>   69818   5296232  75346  12652spl/u-boot-spl
> 
> 
> ARM32:
> --
> It increase 644 bytes.
> 
> Before:
>text   databssdechexfilename
>   31825   2968132  34925   886dspl/u-boot-spl
> 
> After:
>textdata bss dec hex filename
>   324692968 132   355698af1 spl/u-boot-spl

That's a lot, especially since we have tiny printf platforms that are
really on the edge.  Can you just not use TINY_PRINTF when using DEBUG?
Maybe we need a Kconfig symbol for some debug stuff.  But I don't think
we can just add this.

-- 
Tom


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


Re: [U-Boot] [PATCH] lib: tiny-printf: Add "%ll" modifier support

2019-03-21 Thread Ley Foon Tan
On Thu, Mar 21, 2019 at 7:22 PM Tom Rini  wrote:
>
> On Fri, Mar 22, 2019 at 01:12:14AM +0800, Ley Foon Tan wrote:
>
> > Add "%ll" modifier support for tiny printf.
> >
> > - Tested on ARM32 and ARM64 systems.
> > - Tested "%lld", "%llu", "%llx" and "%p" format with
> >   minimum and maximum ranges. Compared tiny printf
> >   output with full printf.
> >
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  lib/tiny-printf.c | 42 +-
> >  1 file changed, 29 insertions(+), 13 deletions(-)
>
> What's the use case for this, how much does it grow the size, and can
> the code in question be changed to use a different format modifier or be
> debug() instead?  Tiny printf isn't intended to cover all formats but
> rather still allow some amount of printf on constrained systems.
> Thanks!
>
> --
> Tom
This is to support printf %lld, %llu and %llx and 64-bit %p when
CONFIG_USE_TINY_PRINTF=y is enabled.
In 64-bit system, phys_size_t and phys_addr_t are unsigned long long.
Printf these variables will see rubbish in existing tiny printf.

Example %ll printf;
printf("9223372036854775807 ==> %lld \n",  (long long)9223372036854775807);
printf("0x ==> 0x%llx \n", (unsigned long
long)0x);

There are few issues I've noticed with original tiny printf:
- Some common codes use %ll format
- %p in tiny printf only support 32-bit, it can't support 64-bit address.

If DEBUG is defined and with tiny printf. You can see all rubbish x
for %llx printf. The most serious issue is it cause system hang at
line below (printf from common code).
addr=x level=0
idx=x PTE  at level 16384: x
Creating table for virt 0xx
Setting 4000 to addr=5000
addr=x level=0
idx=x PTE  at level 16384: x
idx=x PTE  at level 20480: x
Checking if pte fits for virt=x size=x blocksize=x
Setting PTE 5000 to block virt=x
addr=x level=1073741824
idx=x PTE  at level 16384: x
addr=x level=1073741824
idx=x PTE  at level 16384: x
idx=x PTE 1 at level 20488: x
Checking if pte fits for virt=x size=x blocksize=x
Setting PTE 5008 to block virt=x
addr=x level=

Example output after apply this patch:
idx=0 PTE 8000 at level 0: 9003
idx=3 PTE 9018 at level 1: a003
Checking if pte fits for virt=c060 size=1fa0 blocksize=4000
addr=c060 level=2
idx=0 PTE 8000 at level 0: 9003
idx=3 PTE 9018 at level 1: a003


ARM64:
--
It increase 200 bytes.

Before:
   text   databssdechexfilename
  69618   5296232  75146  1258aspl/u-boot-spl

After:
   text   databssdechexfilename
  69818   5296232  75346  12652spl/u-boot-spl


ARM32:
--
It increase 644 bytes.

Before:
   text   databssdechexfilename
  31825   2968132  34925   886dspl/u-boot-spl

After:
   textdata bss dec hex filename
  324692968 132   355698af1 spl/u-boot-spl

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


Re: [U-Boot] [PATCH v2] efi_loader: set image_base and image_size to correct values

2019-03-21 Thread AKASHI Takahiro
On Thu, Mar 21, 2019 at 09:24:46PM +0100, Heinrich Schuchardt wrote:
> On 10/11/18 1:11 PM, AKASHI Takahiro wrote:
> > Currently, image's image_base points to an address where the image was
> > temporarily uploaded for further loading. Since efi_loader relocates
> > the image to final destination, image_base and image_size should reflect
> > that.
> >
> > This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
> > which shows that 'Unload' function doesn't fit into a range suggested by
> > image_base and image_size.
> > TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
> > LoadedImageBBTestMain.c:1002
> >
> > Changes in this patch also includes:
> > * reverts a patch, "efi_loader: save image relocation address
> >   and size" since newly added fields are no longer needed.
> > * copy PE headers as well since those information will be needed
> >   for module loading, in particular, at gurb.
> >   (This bug was reported by Heinrich.)
> >
> > Signed-off-by: AKASHI Takahiro 
> > Reported-by: Heinrich Schuchardt 
> > ---
> >  lib/efi_loader/efi_image_loader.c | 22 +++---
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_image_loader.c 
> > b/lib/efi_loader/efi_image_loader.c
> > index a18ce0a5705e..d1b6c0d3cdf2 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct 
> > efi_loaded_image_obj *obj,
> >  {
> > printf("UEFI image");
> > printf(" [0x%p:0x%p]",
> > -  obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
> > -   if (pc && pc >= obj->reloc_base &&
> > -   pc < obj->reloc_base + obj->reloc_size)
> > -   printf(" pc=0x%zx", pc - obj->reloc_base);
> > +  image->image_base, image->image_base + image->image_size - 1);
> > +   if (pc && pc >= image->image_base &&
> > +   pc < image->image_base + image->image_size)
> > +   printf(" pc=0x%zx", pc - image->image_base);
> > if (image->file_path)
> > printf(" '%pD'", image->file_path);
> > printf("\n");
> > @@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> > void *efi,
> > int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
> > void *entry;
> > uint64_t image_base;
> > -   uint64_t image_size;
> > unsigned long virt_size = 0;
> > int supported = 0;
> >
> > @@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> > void *efi,
> > IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
> > IMAGE_OPTIONAL_HEADER64 *opt = >OptionalHeader;
> > image_base = opt->ImageBase;
> > -   image_size = opt->SizeOfImage;
> > efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> > efi_reloc = efi_alloc(virt_size,
> >   loaded_image_info->image_code_type);
> > @@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> > void *efi,
> > } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
> > IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
> > image_base = opt->ImageBase;
> > -   image_size = opt->SizeOfImage;
> > efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> > efi_reloc = efi_alloc(virt_size,
> >   loaded_image_info->image_code_type);
> > @@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> > void *efi,
> > return NULL;
> > }
> >
> > +   /* Copy PE headers */
> > +   memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
> > +   + nt->FileHeader.SizeOfOptionalHeader
> > +   + num_sections * sizeof(IMAGE_SECTION_HEADER));
> > +
> 
> Why is it needed to copy the header? Did you experience any error
> related to this header not copied?

You made the same question before, and I answered already.
https://lists.denx.de/pipermail/u-boot/2018-October/344165.html

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> 
> > /* Load sections into RAM */
> > for (i = num_sections - 1; i >= 0; i--) {
> > IMAGE_SECTION_HEADER *sec = [i];
> > @@ -315,10 +317,8 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> > void *efi,
> > invalidate_icache_all();
> >
> > /* Populate the loaded image interface bits */
> > -   loaded_image_info->image_base = efi;
> > -   loaded_image_info->image_size = image_size;
> > -   handle->reloc_base = efi_reloc;
> > -   handle->reloc_size = virt_size;
> > +   loaded_image_info->image_base = efi_reloc;
> > +   loaded_image_info->image_size = virt_size;
> >
> > return entry;
> >  }
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 00/11] SMP support for RISC-V

2019-03-21 Thread Atish Patra

On 3/21/19 4:06 PM, Bin Meng wrote:

On Thu, Mar 21, 2019 at 11:39 PM Troy Benjegerdes  wrote:


On Sun, Mar 17, 2019 at 07:28:31PM +0100, Lukas Auer wrote:

This patch series adds SMP support for RISC-V to U-Boot. It allows
U-Boot to run on multi-hart systems (hart is the RISC-V terminology for
hardware thread). Images passed to bootm will be started on all harts.
The bootm command is currently the only one that will boot images on all
harts, bootefi is not yet supported.

The patches have been successfully tested on both QEMU (machine and
supervisor mode) and the HiFive Unleashed board (supervisor mode), using
BBL and OpenSBI.


Can you describe the test configuration and boot flow a little more, or post an
SDcard image that boots with the switches as shown in the readme at [1]

I don't see any board-specific memory initialization code anywhere, so I assume
you are still using the original SiFive FSBL, and not the u-boot version that
includes the memory init code [2]



Correct. Mainline U-Boot on the FU540 board runs on S-mode currently.
You can refer to documentation doc/README.sifive-fu540



To add Bin's comment, the boot flow described in README.sifive-fu540 is

ZSBL->FSBL->OpenSBI/BBL->U-Boot(S Mode)->Linux

FYI: For BBL, you need to hack U-Boot to add serial console in DT.

IMHO, we should avoid forks and use upstream code as much as possible.

The memory initialization patches in [2] were never upstreamed. It would 
be great if that can upstream them so that we can replace FSBL as well. 
U-Boot SPL support for RISC-V would even be better.


Regards,
Atish

[1] https://github.com/sifive/freedom-u-sdk
[2] https://github.com/sifive/HiFive_U-Boot



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



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


Re: [U-Boot] [PATCH v3 00/11] SMP support for RISC-V

2019-03-21 Thread Bin Meng
On Thu, Mar 21, 2019 at 11:39 PM Troy Benjegerdes  wrote:
>
> On Sun, Mar 17, 2019 at 07:28:31PM +0100, Lukas Auer wrote:
> > This patch series adds SMP support for RISC-V to U-Boot. It allows
> > U-Boot to run on multi-hart systems (hart is the RISC-V terminology for
> > hardware thread). Images passed to bootm will be started on all harts.
> > The bootm command is currently the only one that will boot images on all
> > harts, bootefi is not yet supported.
> >
> > The patches have been successfully tested on both QEMU (machine and
> > supervisor mode) and the HiFive Unleashed board (supervisor mode), using
> > BBL and OpenSBI.
>
> Can you describe the test configuration and boot flow a little more, or post 
> an
> SDcard image that boots with the switches as shown in the readme at [1]
>
> I don't see any board-specific memory initialization code anywhere, so I 
> assume
> you are still using the original SiFive FSBL, and not the u-boot version that
> includes the memory init code [2]
>

Correct. Mainline U-Boot on the FU540 board runs on S-mode currently.
You can refer to documentation doc/README.sifive-fu540

> [1] https://github.com/sifive/freedom-u-sdk
> [2] https://github.com/sifive/HiFive_U-Boot
>

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


Re: [U-Boot] [PATCH] mtd: spi: Add Macronix MX66U2G45F device

2019-03-21 Thread Marek Vasut
On 3/21/19 5:57 PM, Jagan Teki wrote:
> On Fri, Mar 8, 2019 at 3:57 AM Marek Vasut  wrote:
>>
>> Add Macronix MX66U2G45F flash device description.
>> This is a 256 MiB part.
> 
> Couldn't find the datasheet on web, do you have a link?

Try this, the F seems compatible to the G .
http://www.macronix.com/Lists/Datasheet/Attachments/7481/MX66U2G45G,%201.8V,%202Gb,%20v1.0.pdf

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


Re: [U-Boot] [linux-sunxi] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels

2019-03-21 Thread Jonathan Liu
Hi Jagan,

On Fri., 22 Mar. 2019 at 4:05 am, Jagan Teki 
wrote:

> On Tue, Mar 19, 2019 at 11:09 AM Jonathan Liu  wrote:
> >
> > Old sunxi kernels fail to boot with ARMV7_LPAE enabled.
>
> Any idea why? I don't have relevant stuff with to test this.
>
I don't know why. It failed to boot linux-sunxi 3.4.104 kernel on A20
OLinuXino-MICRO after updating from 2018.07 to 2018.09-rc1 and would hang
at "Starting kernel...".

I bisected the issue to:
https://git.denx.de/?p=u-boot.git;a=commit;h=d32e86bde8a31a49cf4a9b233ad91ecdfc96ba2a

No problems booting mainline kernel.

Thanks.

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


[U-Boot] [PATCH 1/1] efi_selftest: check image_base, image_size

2019-03-21 Thread Heinrich Schuchardt
In efi_selftest_start_image_exit.c test the image_base and image_size are
correctly set in the loaded image protocol.

Signed-off-by: Heinrich Schuchardt 
---
Hello Takahiro,

this relates to your patch

efi_loader: set image_base and image_size to correct values
https://lists.denx.de/pipermail/u-boot/2018-October/344048.html

Could you, please, review this patch.

Best regards

Heinrich
---
 lib/efi_selftest/efi_selftest_miniapp_exit.c | 58 ++--
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_miniapp_exit.c 
b/lib/efi_selftest/efi_selftest_miniapp_exit.c
index 2ffdd65b759..baead834294 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exit.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exit.c
@@ -11,22 +11,70 @@
 #include 
 #include 

-/*
+static efi_guid_t loaded_image_protocol_guid = LOADED_IMAGE_GUID;
+
+/**
+ * check_loaded_image_protocol() - check image_base/image_size
+ *
+ * Try to open the loaded image protocol. Check that this function is located
+ * between image_base and image_base + image_size.
+ *
+ * @image_handle:  handle of the loaded image
+ * @systable:  system table
+ * @return:status code
+ */
+static efi_status_t EFIAPI check_loaded_image_protocol
+   (efi_handle_t image_handle, struct efi_system_table *systable)
+{
+   struct efi_simple_text_output_protocol *cout = systable->con_out;
+   struct efi_boot_services *boottime = systable->boottime;
+   struct efi_loaded_image *loaded_image_protocol;
+   efi_status_t ret;
+
+   /*
+* Open the loaded image protocol.
+*/
+   ret = boottime->open_protocol
+   (image_handle, _image_protocol_guid,
+(void **)_image_protocol, NULL,
+ NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+   if (ret != EFI_SUCCESS) {
+   cout->output_string(cout,
+   L"Could not open loaded image protocol");
+   return ret;
+   }
+   if ((void *)check_loaded_image_protocol <
+   loaded_image_protocol->image_base ||
+   (void *)check_loaded_image_protocol >=
+   loaded_image_protocol->image_base +
+   loaded_image_protocol->image_size) {
+   cout->output_string(cout,
+   L"Incorrect image_base or image_size\n");
+   return EFI_NOT_FOUND;
+   }
+   return EFI_SUCCESS;
+}
+
+/**
  * Entry point of the EFI application.
  *
- * @handle handle of the loaded image
- * @systable   system table
- * @return status code
+ * @handle:handle of the loaded image
+ * @systable:  system table
+ * @return:status code
  */
 efi_status_t EFIAPI efi_main(efi_handle_t handle,
 struct efi_system_table *systable)
 {
struct efi_simple_text_output_protocol *con_out = systable->con_out;
+   efi_status_t ret = EFI_UNSUPPORTED;

con_out->output_string(con_out, L"EFI application calling Exit\n");

+   if (check_loaded_image_protocol(handle, systable) != EFI_SUCCESS)
+   ret = EFI_NOT_FOUND;
+
/* The return value is checked by the calling test */
-   systable->boottime->exit(handle, EFI_UNSUPPORTED, 0, NULL);
+   systable->boottime->exit(handle, ret, 0, NULL);

/*
 * This statement should not be reached.
--
2.19.0

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


Re: [U-Boot] [PATCH] arm: timer: sunxi: fix a64 spurious timeout issues

2019-03-21 Thread Oskari Lemmelä

On 3/17/19 11:14 PM, André Przywara wrote:

On 17/03/2019 18:41, Oskari Lemmelä wrote:

On 3/17/19 6:04 PM, Peter Robinson wrote:

On Sun, Mar 17, 2019 at 2:56 PM Oskari Lemmela 
wrote:

Fixes spurious timeouts which have been seen during testing
SPI_SUNXI driver. The false timeouts disappear when number of
bits reduced to 10 in workaround.

So in general I am fine with this patch, if it fixes things for you, but
still scratching my head about this.
AFAIK Samuel has never seen less than 11 identical bits in his testing,
and I am using the new SPI driver for some weeks now (without the patch)
and never had any issues. I am on the Pine64 LTS (with that "R18" SoC).

So Oskari, can you share how exactly you triggered this problem?
I'd rather know what's going on before papering over the issue,
especially if that leaves the much more important Linux kernel still at
risk.


Actually now when I'm trying to retrigger it seems to be hard to catch.
I was running following loop couple of days without any issues

setenv read_loop 'setenv i 0; while sf read ${kernel_addr_r} 0; do 
setexpr i ${i} + 1; echo run ${i}; done'


Then I changed wait loop code in spi driver to original one.

diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
index dbfeac77ee..6aaa79ddd9 100644
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -377,14 +377,11 @@ static int sun4i_spi_xfer(struct udevice *dev, 
unsigned int bitlen,

    setbits_le32(SPI_REG(priv, SPI_TCR),
 SPI_BIT(priv, SPI_TCR_XCH));

-   /* Wait till RX FIFO to be empty */
-   ret = readl_poll_timeout(SPI_REG(priv, SPI_FSR),
-    rx_fifocnt,
-    (((rx_fifocnt &
-    SPI_BIT(priv, 
SPI_FSR_RF_CNT_MASK)) >>

- SUN4I_FIFO_STA_RF_CNT_BITS) >= nbytes),
- SUN4I_SPI_TIMEOUT_US);
-   if (ret < 0) {
+   /* Wait transfer to complete */
+   u32 *tcr = SPI_REG(priv, SPI_TCR);
+   ret = wait_for_bit_le32(tcr, 0x8000,
+   false, SUN4I_SPI_TIMEOUT_US, false);
+   if (ret) {
    printf("ERROR: sun4i_spi: Timeout transferring 
data\n");

    sun4i_spi_set_cs(bus, slave_plat->cs, false);
    return ret;

Don't know it that was difference but then only one of my boards trigger 
it two times in row.


=> setenv read_loop 'setenv i 0; while sf read ${kernel_addr_r} 0; do 
setexpr i ${i} + 1; echo run ${i}; done'

=> sf probe
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 
16 MiB

=> run read_loop
device 0 whole chip
ERROR: sun4i_spi: Timeout transferring data
SF: 16777216 bytes @ 0x0 Read: ERROR -110
=> run read_loop
device 0 whole chip
ERROR: sun4i_spi: Timeout transferring data
SF: 16777216 bytes @ 0x0 Read: ERROR -110
=>

And after that also couple of times.
I'll leave all those three Pine64-LTS boards to run same code to see if 
only one of them

have this issue.

Thanks,
Oskari


Cheers,
Andre.


The false timeouts are caused by timer backward jumps.

Wouldn't it be best to apply the same fix as the kernel uses here [1]
as a more permanent fix?

[1] https://www.spinics.net/lists/arm-kernel/msg699622.html

Sure. Difference is that retry counter was added to while loop in kernel
side.

Only CNTPCT is used in u-boot.
So CNTVCT part of kernel patch is currently not needed?


Signed-off-by: Oskari Lemmela 
---
   arch/arm/cpu/armv8/generic_timer.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/generic_timer.c
b/arch/arm/cpu/armv8/generic_timer.c
index c1706dcec1..2e06ee4ed2 100644
--- a/arch/arm/cpu/armv8/generic_timer.c
+++ b/arch/arm/cpu/armv8/generic_timer.c
@@ -66,7 +66,7 @@ unsigned long timer_read_counter(void)
  isb();
  do {
  asm volatile("mrs %0, cntpct_el0" : "=r" (cntpct));
-   } while (((cntpct + 1) & GENMASK(10, 0)) <= 1);
+   } while (((cntpct + 1) & GENMASK(9, 0)) <= 1);

  return cntpct;
   }
--
2.17.1

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

Oskari


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


Re: [U-Boot] [PATCH v2] efi_loader: set image_base and image_size to correct values

2019-03-21 Thread Heinrich Schuchardt
On 10/11/18 1:11 PM, AKASHI Takahiro wrote:
> Currently, image's image_base points to an address where the image was
> temporarily uploaded for further loading. Since efi_loader relocates
> the image to final destination, image_base and image_size should reflect
> that.
>
> This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
> which shows that 'Unload' function doesn't fit into a range suggested by
> image_base and image_size.
>   TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
>   LoadedImageBBTestMain.c:1002
>
> Changes in this patch also includes:
> * reverts a patch, "efi_loader: save image relocation address
>   and size" since newly added fields are no longer needed.
> * copy PE headers as well since those information will be needed
>   for module loading, in particular, at gurb.
>   (This bug was reported by Heinrich.)
>
> Signed-off-by: AKASHI Takahiro 
> Reported-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_image_loader.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/lib/efi_loader/efi_image_loader.c 
> b/lib/efi_loader/efi_image_loader.c
> index a18ce0a5705e..d1b6c0d3cdf2 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct 
> efi_loaded_image_obj *obj,
>  {
>   printf("UEFI image");
>   printf(" [0x%p:0x%p]",
> -obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
> - if (pc && pc >= obj->reloc_base &&
> - pc < obj->reloc_base + obj->reloc_size)
> - printf(" pc=0x%zx", pc - obj->reloc_base);
> +image->image_base, image->image_base + image->image_size - 1);
> + if (pc && pc >= image->image_base &&
> + pc < image->image_base + image->image_size)
> + printf(" pc=0x%zx", pc - image->image_base);
>   if (image->file_path)
>   printf(" '%pD'", image->file_path);
>   printf("\n");
> @@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> void *efi,
>   int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
>   void *entry;
>   uint64_t image_base;
> - uint64_t image_size;
>   unsigned long virt_size = 0;
>   int supported = 0;
>
> @@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> void *efi,
>   IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
>   IMAGE_OPTIONAL_HEADER64 *opt = >OptionalHeader;
>   image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
>   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
>   efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> void *efi,
>   } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
>   IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
>   image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
>   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
>   efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> void *efi,
>   return NULL;
>   }
>
> + /* Copy PE headers */
> + memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
> + + nt->FileHeader.SizeOfOptionalHeader
> + + num_sections * sizeof(IMAGE_SECTION_HEADER));
> +

Why is it needed to copy the header? Did you experience any error
related to this header not copied?

Best regards

Heinrich


>   /* Load sections into RAM */
>   for (i = num_sections - 1; i >= 0; i--) {
>   IMAGE_SECTION_HEADER *sec = [i];
> @@ -315,10 +317,8 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, 
> void *efi,
>   invalidate_icache_all();
>
>   /* Populate the loaded image interface bits */
> - loaded_image_info->image_base = efi;
> - loaded_image_info->image_size = image_size;
> - handle->reloc_base = efi_reloc;
> - handle->reloc_size = virt_size;
> + loaded_image_info->image_base = efi_reloc;
> + loaded_image_info->image_size = virt_size;
>
>   return entry;
>  }
>

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


Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"

2019-03-21 Thread Simon Goldschmidt

Tom,

Am 21.03.2019 um 20:21 schrieb Simon Goldschmidt:

Hi Lukasz,

Am 18.03.2019 um 08:23 schrieb Lukasz Majewski:

On Fri, 15 Mar 2019 20:02:25 +0100
Simon Goldschmidt  wrote:


Tom,

(adding Lukasz as he authored the DM fix 0c07a9b4078d)

Am 14.03.2019 um 21:57 schrieb Simon Goldschmidt:

This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.

The 'eeprom' command has been converted to work with DM_I2C in a
patch submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to
eeprom command")

Signed-off-by: Simon Goldschmidt 


I know it's late in the release cycle, but is there a chance to get
this in for v2019.04?

That would allow me to convert I2C and EEPROM access for socfpga in
the socfpga-next tree...

Also, I guess adding this now shouldn't be a great risk since it is
default off and removing the dependency shouldn't harm.


If it doesn't cause build breaks - I don't mind.


I don't see why this should cause build breaks. It's default off and not
selected anywhere: although 101 defconfig files have CONFIG_CMD_EEPROM
enabled, none of them has CONFIG_DM_I2C enabled.

Your patch from Nov/Dec 2018 should allow those boards to move to DM_I2C
(if the i2c driver supports it) but the commit I want to revert here
prevents it soemwhat by depending on legacy code: even DM_I2C_COMPAT is
not needed any more after your patch.


Could this please go in to v2019.04? I'd like to base my patches for 
socfpga-next on this...


Or should Heiko get this via the i2c tree?

Regards,
Simon



Regards,
Simon





Thanks,
Simon


---

cmd/Kconfig | 1 -
1 file changed, 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4bcc5c4557..74c5a1a6ed 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -455,7 +455,6 @@ config CRC32_VERIFY

config CMD_EEPROM

bool "eeprom - EEPROM subsystem"
-   depends on !DM_I2C || DM_I2C_COMPAT
help
  (deprecated, needs conversion to driver model)
  Provides commands to read and write EEPROM
(Electrically Erasable







Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de





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


Re: [U-Boot] [PATCHv2 2/2] configs: move CONFIG_SPL_TEXT_BASE to Kconfig

2019-03-21 Thread Simon Goldschmidt

Hi Tom,

Am 19.03.2019 um 12:14 schrieb Tom Rini:

From: Simon Goldschmidt 

Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing
values.

Signed-off-by: Simon Goldschmidt 
[trini: Re-run migration]
Signed-off-by: Tom Rini 


Unfortunately, this clashes with Marek's last pull-request, where 
socfpga_common.h has changed in this exact area.


However, after manually fixing this merge conflict, everything works 
fine (tested on socfpga_socrates).


Regards,
Simon

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


Re: [U-Boot] [PATCH 1/2] Add domain mapping for Pepperl+Fuchs

2019-03-21 Thread Simon Goldschmidt

Hi Wolfgang,

Am 24.01.2019 um 13:22 schrieb Tom Rini:

On Thu, Jan 24, 2019 at 12:40:14PM +0100, Simon Goldschmidt wrote:

On Mon, Aug 13, 2018 at 12:07 PM Simon Goldschmidt
 wrote:


Signed-off-by: Simon Goldschmidt 


Gentle ping for:
https://patchwork.ozlabs.org/patch/956901/
https://patchwork.ozlabs.org/patch/956902/

Who is responsible for the gitdm repo?


That would be Wolfgang.


Would you consider merging this series into the gitdm repo?

https://patchwork.ozlabs.org/project/uboot/list/?series=60515

Thanks,
Simon





Thanks,
Simon


---
  u-boot-config/domain-map | 1 +
  1 file changed, 1 insertion(+)

diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map
index f2abba9..74c1538 100644
--- a/u-boot-config/domain-map
+++ b/u-boot-config/domain-map
@@ -262,6 +262,7 @@ parallels.com   Parallels
  pasemi.com PA Semi Corporation
  pcs.de PCS Systemtechnik
  pengutronix.de Pengutronix
+pepperl-fuchs.com  Pepperl+Fuchs
  pheonix.comPhoeonix
  philosys.dePhilosys Software
  phytec.de  Phytec
--
2.17.1





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


Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"

2019-03-21 Thread Simon Goldschmidt

Hi Lukasz,

Am 18.03.2019 um 08:23 schrieb Lukasz Majewski:

On Fri, 15 Mar 2019 20:02:25 +0100
Simon Goldschmidt  wrote:


Tom,

(adding Lukasz as he authored the DM fix 0c07a9b4078d)

Am 14.03.2019 um 21:57 schrieb Simon Goldschmidt:

This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.

The 'eeprom' command has been converted to work with DM_I2C in a
patch submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to
eeprom command")

Signed-off-by: Simon Goldschmidt 


I know it's late in the release cycle, but is there a chance to get
this in for v2019.04?

That would allow me to convert I2C and EEPROM access for socfpga in
the socfpga-next tree...

Also, I guess adding this now shouldn't be a great risk since it is
default off and removing the dependency shouldn't harm.


If it doesn't cause build breaks - I don't mind.


I don't see why this should cause build breaks. It's default off and not 
selected anywhere: although 101 defconfig files have CONFIG_CMD_EEPROM 
enabled, none of them has CONFIG_DM_I2C enabled.


Your patch from Nov/Dec 2018 should allow those boards to move to DM_I2C 
(if the i2c driver supports it) but the commit I want to revert here 
prevents it soemwhat by depending on legacy code: even DM_I2C_COMPAT is 
not needed any more after your patch.


Regards,
Simon





Thanks,
Simon


---

   cmd/Kconfig | 1 -
   1 file changed, 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4bcc5c4557..74c5a1a6ed 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -455,7 +455,6 @@ config CRC32_VERIFY
   
   config CMD_EEPROM

bool "eeprom - EEPROM subsystem"
-   depends on !DM_I2C || DM_I2C_COMPAT
help
  (deprecated, needs conversion to driver model)
  Provides commands to read and write EEPROM
(Electrically Erasable







Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de



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


[U-Boot] [PATCH v3 12/13] p2371-2180: Add support for framebuffer carveouts

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.

This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.

Signed-off-by: Thierry Reding 
---
 board/nvidia/p2371-2180/p2371-2180.c | 47 
 1 file changed, 47 insertions(+)

diff --git a/board/nvidia/p2371-2180/p2371-2180.c 
b/board/nvidia/p2371-2180/p2371-2180.c
index a444d692d7ea..4985302d6bc2 100644
--- a/board/nvidia/p2371-2180/p2371-2180.c
+++ b/board/nvidia/p2371-2180/p2371-2180.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,9 +139,55 @@ static void ft_mac_address_setup(void *fdt)
}
 }
 
+static int ft_copy_carveout(void *dst, const void *src, const char *node)
+{
+   struct fdt_memory fb;
+   int err;
+
+   err = fdtdec_get_carveout(src, node, "memory-region", 0, );
+   if (err < 0) {
+   if (err != -FDT_ERR_NOTFOUND)
+   printf("failed to get carveout for %s: %d\n", node,
+  err);
+
+   return err;
+   }
+
+   err = fdtdec_set_carveout(dst, node, "memory-region", 0, "framebuffer",
+ );
+   if (err < 0) {
+   printf("failed to set carveout for %s: %d\n", node, err);
+   return err;
+   }
+
+   return 0;
+}
+
+static void ft_carveout_setup(void *fdt)
+{
+   const void *cboot_fdt = (const void *)cboot_boot_x0;
+   static const char * const nodes[] = {
+   "/host1x@5000/dc@5420",
+   "/host1x@5000/dc@5424",
+   };
+   unsigned int i;
+   int err;
+
+   for (i = 0; i < ARRAY_SIZE(nodes); i++) {
+   err = ft_copy_carveout(fdt, cboot_fdt, nodes[i]);
+   if (err < 0) {
+   if (err != -FDT_ERR_NOTFOUND)
+   printf("failed to copy carveout for %s: %d\n",
+  nodes[i], err);
+   continue;
+   }
+   }
+}
+
 int ft_board_setup(void *fdt, bd_t *bd)
 {
ft_mac_address_setup(fdt);
+   ft_carveout_setup(fdt);
 
return 0;
 }
-- 
2.21.0

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


[U-Boot] [PATCH v3 10/13] fdtdec: test: Add carveout tests

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Implement carveout tests for 32-bit and 64-bit builds.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 lib/fdtdec_test.c | 152 ++
 1 file changed, 152 insertions(+)

diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
index 928950918413..f6defe16c5a6 100644
--- a/lib/fdtdec_test.c
+++ b/lib/fdtdec_test.c
@@ -141,6 +141,156 @@ static int run_test(const char *aliases, const char 
*nodes, const char *expect)
return 0;
 }
 
+static int make_fdt_carveout_device(void *fdt, uint32_t na, uint32_t ns)
+{
+   const char *basename = "/display";
+   struct fdt_memory carveout = {
+#ifdef CONFIG_PHYS_64BIT
+   .start = 0x18000,
+   .end = 0x18fff,
+#else
+   .start = 0x8000,
+   .end = 0x8fff,
+#endif
+   };
+   fdt32_t cells[4], *ptr = cells;
+   uint32_t upper, lower;
+   char name[32];
+   int offset;
+
+   /* store one or two address cells */
+   lower = fdt_addr_unpack(carveout.start, );
+
+   if (na > 1 && upper > 0)
+   snprintf(name, sizeof(name), "%s@%x,%x", basename, upper,
+lower);
+   else
+   snprintf(name, sizeof(name), "%s@%x", basename, lower);
+
+   if (na > 1)
+   *ptr++ = cpu_to_fdt32(upper);
+
+   *ptr++ = cpu_to_fdt32(lower);
+
+   /* store one or two size cells */
+   lower = fdt_size_unpack(carveout.end - carveout.start + 1, );
+
+   if (ns > 1)
+   *ptr++ = cpu_to_fdt32(upper);
+
+   *ptr++ = cpu_to_fdt32(lower);
+
+   offset = CHECK(fdt_add_subnode(fdt, 0, name + 1));
+   CHECK(fdt_setprop(fdt, offset, "reg", cells, (na + ns) * 
sizeof(*cells)));
+
+   return fdtdec_set_carveout(fdt, name, "memory-region", 0,
+  "framebuffer", );
+}
+
+static int check_fdt_carveout(void *fdt, uint32_t address_cells,
+ uint32_t size_cells)
+{
+#ifdef CONFIG_PHYS_64BIT
+   const char *name = "/display@1,8000";
+   const struct fdt_memory expected = {
+   .start = 0x18000,
+   .end = 0x18fff,
+   };
+#else
+   const char *name = "/display@8000";
+   const struct fdt_memory expected = {
+   .start = 0x8000,
+   .end = 0x8fff,
+   };
+#endif
+   struct fdt_memory carveout;
+
+   printf("carveout: %pap-%pap na=%u ns=%u: ", ,
+  , address_cells, size_cells);
+
+   CHECK(fdtdec_get_carveout(fdt, name, "memory-region", 0, ));
+
+   if ((carveout.start != expected.start) ||
+   (carveout.end != expected.end)) {
+   printf("carveout: %pap-%pap, expected %pap-%pap\n",
+  , ,
+  , );
+   return 1;
+   }
+
+   printf("pass\n");
+   return 0;
+}
+
+static int make_fdt_carveout(void *fdt, int size, uint32_t address_cells,
+uint32_t size_cells)
+{
+   fdt32_t na = cpu_to_fdt32(address_cells);
+   fdt32_t ns = cpu_to_fdt32(size_cells);
+#if defined(DEBUG) && defined(CONFIG_SANDBOX)
+   char filename[512];
+   int fd;
+#endif
+   int err;
+
+   CHECK(fdt_create(fdt, size));
+   CHECK(fdt_finish_reservemap(fdt));
+   CHECK(fdt_begin_node(fdt, ""));
+   CHECK(fdt_property(fdt, "#address-cells", , sizeof(na)));
+   CHECK(fdt_property(fdt, "#size-cells", , sizeof(ns)));
+   CHECK(fdt_end_node(fdt));
+   CHECK(fdt_finish(fdt));
+   CHECK(fdt_pack(fdt));
+
+   CHECK(fdt_open_into(fdt, fdt, FDT_SIZE));
+
+   err = make_fdt_carveout_device(fdt, address_cells, size_cells);
+
+#if defined(DEBUG) && defined(CONFIG_SANDBOX)
+   snprintf(filename, sizeof(filename), "/tmp/fdtdec-carveout-%u-%u.dtb",
+address_cells, size_cells);
+
+   fd = os_open(filename, OS_O_CREAT | OS_O_WRONLY);
+   if (fd < 0) {
+   printf("could not open .dtb file to write\n");
+   goto out;
+   }
+
+   os_write(fd, fdt, size);
+   os_close(fd);
+
+out:
+#endif
+   return err;
+}
+
+static int check_carveout(void)
+{
+   void *fdt;
+
+   fdt = malloc(FDT_SIZE);
+   if (!fdt) {
+   printf("%s: out of memory\n", __func__);
+   return 1;
+   }
+
+#ifndef CONFIG_PHYS_64BIT
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 1, 1), 0);
+   CHECKOK(check_fdt_carveout(fdt, 1, 1));
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 1, 2), 0);
+   CHECKOK(check_fdt_carveout(fdt, 1, 2));
+#else
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 1, 1), -FDT_ERR_BADVALUE);
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 1, 2), -FDT_ERR_BADVALUE);
+#endif
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 2, 1), 0);
+   CHECKOK(check_fdt_carveout(fdt, 2, 1));
+   CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 2, 2), 

[U-Boot] [PATCH v3 04/13] fdtdec: Implement fdtdec_set_phandle()

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

This function can be used to set a phandle for a given node.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- don't emit deprecated linux,phandle property

 include/fdtdec.h | 11 +++
 lib/fdtdec.c |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index a0ba57c6318b..55600026c488 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -981,6 +981,17 @@ int fdtdec_setup_mem_size_base(void);
  */
 int fdtdec_setup_memory_banksize(void);
 
+/**
+ * fdtdec_set_phandle() - sets the phandle of a given node
+ *
+ * @param blob FDT blob
+ * @param node offset in the FDT blob of the node whose phandle is to
+ * be set
+ * @param phandle  phandle to set for the given node
+ * @return 0 on success or a negative error code on failure
+ */
+int fdtdec_set_phandle(void *blob, int node, uint32_t phandle);
+
 /**
  * Set up the device tree ready for use
  */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 09a7e133a539..00db90e3cdfd 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1243,6 +1243,13 @@ __weak void *board_fdt_blob_setup(void)
 }
 #endif
 
+int fdtdec_set_phandle(void *blob, int node, uint32_t phandle)
+{
+   fdt32_t value = cpu_to_fdt32(phandle);
+
+   return fdt_setprop(blob, node, "phandle", , sizeof(value));
+}
+
 int fdtdec_setup(void)
 {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-- 
2.21.0

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


[U-Boot] [PATCH v3 05/13] fdtdec: Implement fdtdec_add_reserved_memory()

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

This function can be used to add subnodes in the /reserved-memory node.

Reviewed-by: Simon Glass 
Signed-off-by: Thierry Reding 
---
Changes in v3:
- use fdt_generate_phandle() instead of fdtdec_generate_phandle()
- add device tree bindings for /reserved-memory
- add examples to code comments

Changes in v2:
- split fdt_{addr,size}_unpack() helpers into separate patch
- use name@x,y notation only if the upper cell is > 0
- use debug() instead of printf() to save code size
- properly compute number of cells in reg property
- fix carveout size computations, was off by one
- use #size-cells where appropriate

 .../reserved-memory/reserved-memory.txt   | 136 ++
 include/fdtdec.h  |  48 +++
 lib/fdtdec.c  | 131 +
 3 files changed, 315 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
new file mode 100644
index ..bac4afa3b197
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -0,0 +1,136 @@
+*** Reserved memory regions ***
+
+Reserved memory is specified as a node under the /reserved-memory node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions. Such memory regions are usually designed for
+the special usage by various device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory node
+-
+#address-cells, #size-cells (required) - standard definition
+- Should use the same values as the root node
+ranges (required) - standard definition
+- Should be empty
+
+/reserved-memory/ child nodes
+-
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a 'reg' property to
+specify a specific range of reserved memory, or a 'size' property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+address (@) should be appended to the name if the node is a
+static allocation.
+
+Properties:
+Requires either a) or b) below.
+a) static allocation
+   reg (required) - standard definition
+b) dynamic allocation
+   size (required) - length based on parent's #size-cells
+   - Size in bytes of memory to reserve.
+   alignment (optional) - length based on parent's #size-cells
+- Address boundary for alignment of allocation.
+   alloc-ranges (optional) - prop-encoded-array (address, length pairs).
+   - Specifies regions of memory that are
+ acceptable to allocate from.
+
+If both reg and size are present, then the reg property takes precedence
+and size is ignored.
+
+Additional properties:
+compatible (optional) - standard definition
+- may contain the following strings:
+- shared-dma-pool: This indicates a region of memory meant to be
+  used as a shared pool of DMA buffers for a set of devices. It can
+  be used by an operating system to instantiate the necessary pool
+  management subsystem if necessary.
+- vendor specific string in the form ,[-]
+no-map (optional) - empty property
+- Indicates the operating system must not create a virtual mapping
+  of the region as part of its standard mapping of system memory,
+  nor permit speculative access to it under any circumstances other
+  than under the control of the device driver using the region.
+reusable (optional) - empty property
+- The operating system can use the memory in this region with the
+  limitation that the device driver(s) owning the region need to be
+  able to reclaim it back. Typically that means that the operating
+  system can use that region to store volatile or cached data that
+  can be otherwise regenerated or migrated elsewhere.
+
+Linux implementation note:
+- If a "linux,cma-default" property is present, then Linux will use the
+  region for the default pool of the contiguous memory allocator.
+
+- If a "linux,dma-default" property is present, then Linux will use the
+  region for the default pool of the consistent DMA allocator.
+
+Device node references to reserved memory
+-
+Regions in the /reserved-memory node may be referenced by other device
+nodes by adding a memory-region property to the device node.
+
+memory-region (optional) - phandle, specifier pairs to children of 

[U-Boot] [PATCH v3 06/13] fdtdec: Implement carveout support functions

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The fdtdec_get_carveout() and fdtdec_set_carveout() function can be used
to read a carveout from a given node or add a carveout to a given node
using the standard device tree bindings (involving reserved-memory nodes
and the memory-region property).

Reviewed-by: Simon Glass 
Signed-off-by: Thierry Reding 
---
Changes in v3:
- add examples to code comments

Changes in v2:
- use debug() instead of printf() to save code size
- fix carveout size computations, was off by one
- use fdtdec_get_addr_size_auto_noparent()

 include/fdtdec.h | 81 
 lib/fdtdec.c | 87 
 2 files changed, 168 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index b54ed38fb362..13b743f59ab1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -1030,6 +1030,8 @@ int fdtdec_set_phandle(void *blob, int node, uint32_t 
phandle);
  * The phandle returned from the function call can be used to reference this
  * reserved memory region from other nodes.
  *
+ * See fdtdec_set_carveout() for a more elaborate example.
+ *
  * @param blob FDT blob
  * @param basename base name of the node to create
  * @param carveout information about the carveout region
@@ -1040,6 +1042,85 @@ int fdtdec_add_reserved_memory(void *blob, const char 
*basename,
   const struct fdt_memory *carveout,
   uint32_t *phandlep);
 
+/**
+ * fdtdec_get_carveout() - reads a carveout from an FDT
+ *
+ * Reads information about a carveout region from an FDT. The carveout is a
+ * referenced by its phandle that is read from a given property in a given
+ * node.
+ *
+ * @param blob FDT blob
+ * @param node name of a node
+ * @param name name of the property in the given node that contains
+ * the phandle for the carveout
+ * @param indexindex of the phandle for which to read the 
carveout
+ * @param carveout return location for the carveout information
+ * @return 0 on success or a negative error code on failure
+ */
+int fdtdec_get_carveout(const void *blob, const char *node, const char *name,
+   unsigned int index, struct fdt_memory *carveout);
+
+/**
+ * fdtdec_set_carveout() - sets a carveout region for a given node
+ *
+ * Sets a carveout region for a given node. If a reserved-memory node already
+ * exists for the carveout, the phandle for that node will be reused. If no
+ * such node exists, a new one will be created and a phandle to it stored in
+ * a specified property of the given node.
+ *
+ * As an example, consider the following code snippet:
+ *
+ * const char *node = "/host1x@5000/dc@5424";
+ * struct fdt_memory fb = {
+ * .start = 0x92cb3000,
+ * .end = 0x934b2fff,
+ * };
+ *
+ * fdtdec_set_carveout(fdt, node, "memory-region", 0, "framebuffer", );
+ *
+ * dc@5420 is a display controller and was set up by the bootloader to
+ * scan out the framebuffer specified by "fb". This would cause the following
+ * reserved memory region to be added:
+ *
+ * reserved-memory {
+ * #address-cells = <0x0002>;
+ * #size-cells = <0x0002>;
+ * ranges;
+ *
+ * framebuffer@92cb3000 {
+ * reg = <0x 0x92cb3000 0x 0x0080>;
+ * phandle = <0x004d>;
+ * };
+ * };
+ *
+ * A "memory-region" property will also be added to the node referenced by the
+ * offset parameter.
+ *
+ * host1x@5000 {
+ * ...
+ *
+ * dc@5424 {
+ * ...
+ * memory-region = <0x004d>;
+ * ...
+ * };
+ *
+ * ...
+ * };
+ *
+ * @param blob FDT blob
+ * @param node name of the node to add the carveout to
+ * @param prop_namename of the property in which to store the phandle of
+ * the carveout
+ * @param indexindex of the phandle to store
+ * @param name base name of the reserved-memory node to create
+ * @param carveout information about the carveout to add
+ * @return 0 on success or a negative error code on failure
+ */
+int fdtdec_set_carveout(void *blob, const char *node, const char *prop_name,
+   unsigned int index, const char *name,
+   const struct fdt_memory *carveout);
+
 /**
  * Set up the device tree ready for use
  */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index be54ad5bd092..bd05ab90fce1 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1381,6 +1381,93 @@ int fdtdec_add_reserved_memory(void *blob, const char 
*basename,
return 0;
 }
 
+int fdtdec_get_carveout(const void *blob, const char *node, const char *name,
+   unsigned int index, struct fdt_memory *carveout)
+{
+   const fdt32_t *prop;
+   uint32_t phandle;
+   int offset, len;
+   

[U-Boot] [PATCH v3 02/13] fdtdec: Add cpu_to_fdt_{addr, size}() macros

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

These macros are useful for converting the endianness of variables of
type fdt_addr_t and fdt_size_t.

Reviewed-by: Simon Glass 
Signed-off-by: Thierry Reding 
---
Changes in v2:
- add Reviewed-by from Simon

 include/fdtdec.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index b7e35cd87c55..a965c33157c9 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -27,11 +27,15 @@ typedef phys_size_t fdt_size_t;
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be64_to_cpu(reg)
+#define cpu_to_fdt_addr(reg) cpu_to_be64(reg)
+#define cpu_to_fdt_size(reg) cpu_to_be64(reg)
 typedef fdt64_t fdt_val_t;
 #else
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be32_to_cpu(reg)
+#define cpu_to_fdt_addr(reg) cpu_to_be32(reg)
+#define cpu_to_fdt_size(reg) cpu_to_be32(reg)
 typedef fdt32_t fdt_val_t;
 #endif
 
-- 
2.21.0

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


[U-Boot] [PATCH v3 07/13] fdtdec: Add Kconfig symbol for tests

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Runtime tests are provided as a test_fdtdec command implementation. Add
a Kconfig symbol that allows this command to be built so that the tests
can be used.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 lib/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 366d164cd760..b1fccf7e8dff 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -423,4 +423,8 @@ source lib/efi/Kconfig
 source lib/efi_loader/Kconfig
 source lib/optee/Kconfig
 
+config TEST_FDTDEC
+   bool "enable fdtdec test"
+   depends on OF_LIBFDT
+
 endmenu
-- 
2.21.0

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


[U-Boot] [PATCH v3 09/13] fdtdec: test: Use compound statement macros

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

This eliminates the need for intermediate helper functions and allow the
macros to return a value so that it can be used subsequently.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 lib/fdtdec_test.c | 64 ---
 1 file changed, 22 insertions(+), 42 deletions(-)

diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
index 065fed278cf3..928950918413 100644
--- a/lib/fdtdec_test.c
+++ b/lib/fdtdec_test.c
@@ -15,48 +15,28 @@
 /* The size of our test fdt blob */
 #define FDT_SIZE   (16 * 1024)
 
-/**
- * Check if an operation failed, and if so, print an error
- *
- * @param oper_nameName of operation
- * @param err  Error code to check
- *
- * @return 0 if ok, -1 if there was an error
- */
-static int fdt_checkerr(const char *oper_name, int err)
-{
-   if (err) {
-   printf("%s: %s: %s\n", __func__, oper_name, fdt_strerror(err));
-   return -1;
-   }
-
-   return 0;
-}
-
-/**
- * Check the result of an operation and if incorrect, print an error
- *
- * @param oper_nameName of operation
- * @param expected Expected value
- * @param valueActual value
- *
- * @return 0 if ok, -1 if there was an error
- */
-static int checkval(const char *oper_name, int expected, int value)
-{
-   if (expected != value) {
-   printf("%s: %s: expected %d, but returned %d\n", __func__,
-  oper_name, expected, value);
-   return -1;
-   }
-
-   return 0;
-}
+#define CHECK(op) ({   \
+   int err = op;   \
+   if (err < 0) {  \
+   printf("%s: %s: %s\n", __func__, #op,   \
+  fdt_strerror(err));  \
+   return err; \
+   }   \
+   \
+   err;\
+   })
+
+#define CHECKVAL(op, expected) ({  \
+   int err = op;   \
+   if (err != expected) {  \
+   printf("%s: %s: expected %d, but returned %d\n",\
+  __func__, #op, expected, err);   \
+   return err; \
+   }   \
+   \
+   err;\
+   })
 
-#define CHECK(op)  if (fdt_checkerr(#op, op)) return -1
-#define CHECKVAL(op, expected) \
-   if (checkval(#op, expected, op)) \
-   return -1
 #define CHECKOK(op)CHECKVAL(op, 0)
 
 /* maximum number of nodes / aliases to generate */
@@ -138,7 +118,7 @@ static int run_test(const char *aliases, const char *nodes, 
const char *expect)
CHECKVAL(make_fdt(blob, FDT_SIZE, aliases, nodes), 0);
CHECKVAL(fdtdec_find_aliases_for_id(blob, "i2c",
COMPAT_UNKNOWN,
-   list, ARRAY_SIZE(list)), strlen(expect));
+   list, ARRAY_SIZE(list)), (int)strlen(expect));
 
/* Check we got the right ones */
for (i = 0, s = expect; *s; s++, i++) {
-- 
2.21.0

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


[U-Boot] [PATCH v3 01/13] libfdt: Add phandle generation helper

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The new fdt_generate_phandle() function can be used to generate a new,
unused phandle given a specific device tree blob. The implementation is
somewhat naive in that it simply walks the entire device tree to find
the highest phandle value and then returns a phandle value one higher
than that. A more clever implementation might try to find holes in the
current set of phandle values and fill them. But this implementation is
relatively simple and works reliably.

Also add a test that validates that phandles generated by this new API
are indeed unique.

Signed-off-by: Thierry Reding 
---
Changes in v3:
- update to latest upstream commit

 lib/libfdt/fdt_ro.c | 31 +++
 scripts/dtc/libfdt/fdt_ro.c | 31 +++
 scripts/dtc/libfdt/libfdt.h | 19 +++
 scripts/dtc/libfdt/libfdt_env.h |  1 +
 4 files changed, 82 insertions(+)

diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
index b6ca4e0b0c30..693de9aa5ad8 100644
--- a/lib/libfdt/fdt_ro.c
+++ b/lib/libfdt/fdt_ro.c
@@ -73,6 +73,37 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return 0;
 }
 
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
+{
+   uint32_t max = 0;
+   int offset = -1;
+
+   while (true) {
+   uint32_t value;
+
+   offset = fdt_next_node(fdt, offset, NULL);
+   if (offset < 0) {
+   if (offset == -FDT_ERR_NOTFOUND)
+   break;
+
+   return offset;
+   }
+
+   value = fdt_get_phandle(fdt, offset);
+
+   if (value > max)
+   max = value;
+   }
+
+   if (max == FDT_MAX_PHANDLE)
+   return -FDT_ERR_NOPHANDLES;
+
+   if (phandle)
+   *phandle = max + 1;
+
+   return 0;
+}
+
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
FDT_CHECK_HEADER(fdt);
diff --git a/scripts/dtc/libfdt/fdt_ro.c b/scripts/dtc/libfdt/fdt_ro.c
index dfb3236da388..dc499884e4d1 100644
--- a/scripts/dtc/libfdt/fdt_ro.c
+++ b/scripts/dtc/libfdt/fdt_ro.c
@@ -115,6 +115,37 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return 0;
 }
 
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
+{
+   uint32_t max = 0;
+   int offset = -1;
+
+   while (true) {
+   uint32_t value;
+
+   offset = fdt_next_node(fdt, offset, NULL);
+   if (offset < 0) {
+   if (offset == -FDT_ERR_NOTFOUND)
+   break;
+
+   return offset;
+   }
+
+   value = fdt_get_phandle(fdt, offset);
+
+   if (value > max)
+   max = value;
+   }
+
+   if (max == FDT_MAX_PHANDLE)
+   return -FDT_ERR_NOPHANDLES;
+
+   if (phandle)
+   *phandle = max + 1;
+
+   return 0;
+}
+
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
FDT_CHECK_HEADER(fdt);
diff --git a/scripts/dtc/libfdt/libfdt.h b/scripts/dtc/libfdt/libfdt.h
index fd73688f9e9f..cf86ddba8811 100644
--- a/scripts/dtc/libfdt/libfdt.h
+++ b/scripts/dtc/libfdt/libfdt.h
@@ -139,6 +139,10 @@
 
 #define FDT_ERR_MAX17
 
+/* constants */
+#define FDT_MAX_PHANDLE 0xfffe
+   /* Valid values for phandles range from 1 to 2^32-2. */
+
 /**/
 /* Low-level functions (you probably don't need these)*/
 /**/
@@ -313,6 +317,21 @@ const char *fdt_string(const void *fdt, int stroffset);
  */
 uint32_t fdt_get_max_phandle(const void *fdt);
 
+/**
+ * fdt_generate_phandle - return a new, unused phandle for a device tree blob
+ * @fdt: pointer to the device tree blob
+ * @phandle: return location for the new phandle
+ *
+ * Walks the device tree blob and looks for the highest phandle value. On
+ * success, the new, unused phandle value (one higher than the previously
+ * highest phandle value in the device tree blob) will be returned in the
+ * @phandle parameter.
+ *
+ * Returns:
+ *   0 on success or a negative error-code on failure
+ */
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle);
+
 /**
  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
  * @fdt: pointer to the device tree blob
diff --git a/scripts/dtc/libfdt/libfdt_env.h b/scripts/dtc/libfdt/libfdt_env.h
index bd2474628775..3ff9e2863075 100644
--- a/scripts/dtc/libfdt/libfdt_env.h
+++ b/scripts/dtc/libfdt/libfdt_env.h
@@ -52,6 +52,7 @@
  * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.21.0

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


[U-Boot] [PATCH v3 13/13] p2771-0000: Add support for framebuffer carveouts

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.

This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.

Signed-off-by: Thierry Reding 
---
 board/nvidia/p2771-/p2771-.c | 66 ++--
 1 file changed, 62 insertions(+), 4 deletions(-)

diff --git a/board/nvidia/p2771-/p2771-.c 
b/board/nvidia/p2771-/p2771-.c
index fe22067f6571..d294c7ae0136 100644
--- a/board/nvidia/p2771-/p2771-.c
+++ b/board/nvidia/p2771-/p2771-.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,7 +57,7 @@ int tegra_pcie_board_init(void)
 }
 #endif
 
-int ft_board_setup(void *fdt, bd_t *bd)
+static void ft_mac_address_setup(void *fdt)
 {
const void *cboot_fdt = (const void *)cboot_boot_x0;
uint8_t mac[ETH_ALEN], local_mac[ETH_ALEN];
@@ -69,13 +70,15 @@ int ft_board_setup(void *fdt, bd_t *bd)
 
path = fdt_get_alias(fdt, "ethernet");
if (!path)
-   return 0;
+   return;
 
debug("ethernet alias found: %s\n", path);
 
offset = fdt_path_offset(fdt, path);
-   if (offset < 0)
-   return 0;
+   if (offset < 0) {
+   printf("ethernet alias points to absent node %s\n", path);
+   return;
+   }
 
if (is_valid_ethaddr(local_mac)) {
err = fdt_setprop(fdt, offset, "local-mac-address", local_mac,
@@ -92,6 +95,61 @@ int ft_board_setup(void *fdt, bd_t *bd)
debug("MAC address set: %pM\n", mac);
}
}
+}
+
+static int ft_copy_carveout(void *dst, const void *src, const char *node)
+{
+   struct fdt_memory fb;
+   int err;
+
+   err = fdtdec_get_carveout(src, node, "memory-region", 0, );
+   if (err < 0) {
+   if (err != -FDT_ERR_NOTFOUND)
+   printf("failed to get carveout for %s: %d\n", node,
+  err);
+
+   return err;
+   }
+
+   err = fdtdec_set_carveout(dst, node, "memory-region", 0, "framebuffer",
+ );
+   if (err < 0) {
+   printf("failed to set carveout for %s: %d\n", node, err);
+   return err;
+   }
+
+   return 0;
+}
+
+static void ft_carveout_setup(void *fdt)
+{
+   const void *cboot_fdt = (const void *)cboot_boot_x0;
+   static const char * const nodes[] = {
+   "/host1x@13e0/display-hub@1520/display@1520",
+   "/host1x@13e0/display-hub@1520/display@1521",
+   "/host1x@13e0/display-hub@1520/display@1522",
+   };
+   unsigned int i;
+   int err;
+
+   for (i = 0; i < ARRAY_SIZE(nodes); i++) {
+   printf("copying carveout for %s...\n", nodes[i]);
+
+   err = ft_copy_carveout(fdt, cboot_fdt, nodes[i]);
+   if (err < 0) {
+   if (err != -FDT_ERR_NOTFOUND)
+   printf("failed to copy carveout for %s: %d\n",
+  nodes[i], err);
+
+   continue;
+   }
+   }
+}
+
+int ft_board_setup(void *fdt, bd_t *bd)
+{
+   ft_mac_address_setup(fdt);
+   ft_carveout_setup(fdt);
 
return 0;
 }
-- 
2.21.0

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


[U-Boot] [PATCH v3 08/13] fdtdec: test: Fix build warning

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Hide the declaration of the "fd" variable When not building a DEBUG
configuration, to avoid the variable being unused.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 lib/fdtdec_test.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
index a82e27de942f..065fed278cf3 100644
--- a/lib/fdtdec_test.c
+++ b/lib/fdtdec_test.c
@@ -79,7 +79,9 @@ static int make_fdt(void *fdt, int size, const char *aliases,
 {
char name[20], value[20];
const char *s;
+#if defined(DEBUG) && defined(CONFIG_SANDBOX)
int fd;
+#endif
 
CHECK(fdt_create(fdt, size));
CHECK(fdt_finish_reservemap(fdt));
-- 
2.21.0

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


[U-Boot] [PATCH v3 11/13] sandbox: Enable fdtdec tests

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Enable fdtdec tests on sandbox configurations so that they can be run to
validate the fdtdec implementation.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 configs/sandbox64_defconfig | 1 +
 configs/sandbox_defconfig   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index da4bdced3105..c04ecd915ae7 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -194,6 +194,7 @@ CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 CONFIG_LZ4=y
 CONFIG_ERRNO_STR=y
+CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 193e41896cb7..bb508a8d02e2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -215,6 +215,7 @@ CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 CONFIG_LZ4=y
 CONFIG_ERRNO_STR=y
+CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
-- 
2.21.0

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


[U-Boot] [PATCH v3 03/13] fdtdec: Add fdt_{addr, size}_unpack() helpers

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

These helpers can be used to unpack variables of type fdt_addr_t and
fdt_size_t into a pair of 32-bit variables. This is useful in cases
where such variables need to be written to properties (such as "reg")
of a device tree node where they need to be split into cells.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 include/fdtdec.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index a965c33157c9..a0ba57c6318b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -23,6 +23,31 @@
  */
 typedef phys_addr_t fdt_addr_t;
 typedef phys_size_t fdt_size_t;
+
+static inline fdt32_t fdt_addr_unpack(fdt_addr_t addr, fdt32_t *upper)
+{
+   if (upper)
+#ifdef CONFIG_PHYS_64BIT
+   *upper = addr >> 32;
+#else
+   *upper = 0;
+#endif
+
+   return addr;
+}
+
+static inline fdt32_t fdt_size_unpack(fdt_size_t size, fdt32_t *upper)
+{
+   if (upper)
+#ifdef CONFIG_PHYS_64BIT
+   *upper = size >> 32;
+#else
+   *upper = 0;
+#endif
+
+   return size;
+}
+
 #ifdef CONFIG_PHYS_64BIT
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
-- 
2.21.0

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


[U-Boot] [PATCH v3 00/13] ARM: tegra: Add support for framebuffer carveouts

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The series adds a couple of helpers that allow passing framebuffer
carveouts to the kernel on boot. This is required in order to reserve
the memory region that the framebuffer resides in and that the display
controller is scanning out from, so that it is not reused by the kernel
for the buddy allocator. At the same time, this information can be used
to set up a 1:1 mapping for the IOMMU during boot in order to allow the
display controller to keep scanning out from the same address without
causing IOMMU faults.

Note that the last two patches depend on this series:

http://patchwork.ozlabs.org/project/uboot/list/?series=98501

I've included them here to give an example for how they are used. Tom
would need to apply these on top of that series once the remainder of
the patches here have been merged.

Given the build time dependencies it might be best for Tom to pick up
the fdtdec pieces as well, with Simon's ack. Or alternatively Simon
could merge these through his tree and Tom can apply once the
dependencies have gone into master.

Tom, Simon, any preferences?

Thierry

Thierry Reding (13):
  libfdt: Add phandle generation helper
  fdtdec: Add cpu_to_fdt_{addr,size}() macros
  fdtdec: Add fdt_{addr,size}_unpack() helpers
  fdtdec: Implement fdtdec_set_phandle()
  fdtdec: Implement fdtdec_add_reserved_memory()
  fdtdec: Implement carveout support functions
  fdtdec: Add Kconfig symbol for tests
  fdtdec: test: Fix build warning
  fdtdec: test: Use compound statement macros
  fdtdec: test: Add carveout tests
  sandbox: Enable fdtdec tests
  p2371-2180: Add support for framebuffer carveouts
  p2771-: Add support for framebuffer carveouts

 .../reserved-memory/reserved-memory.txt   | 136 +++
 board/nvidia/p2371-2180/p2371-2180.c  |  47 
 board/nvidia/p2771-/p2771-.c  |  66 -
 configs/sandbox64_defconfig   |   1 +
 configs/sandbox_defconfig |   1 +
 include/fdtdec.h  | 169 +
 lib/Kconfig   |   4 +
 lib/fdtdec.c  | 225 ++
 lib/fdtdec_test.c | 216 +
 lib/libfdt/fdt_ro.c   |  31 +++
 scripts/dtc/libfdt/fdt_ro.c   |  31 +++
 scripts/dtc/libfdt/libfdt.h   |  19 ++
 scripts/dtc/libfdt/libfdt_env.h   |   1 +
 13 files changed, 902 insertions(+), 45 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

-- 
2.21.0

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


[U-Boot] [PATCH v3 19/19] ARM: tegra: Import cbootargs value from cboot DTB

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Read the boot arguments passed by cboot via the /chosen/bootargs
property and store it in the cbootargs environment variable.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/cboot.c | 47 +
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index 9735380bda59..8bfcbcdc6e6d 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 
 #include 
@@ -536,10 +538,49 @@ out:
return err;
 }
 
+static char *strip(const char *ptr)
+{
+   const char *end;
+
+   while (*ptr && isblank(*ptr))
+   ptr++;
+
+   /* empty string */
+   if (*ptr == '\0')
+   return strdup(ptr);
+
+   end = ptr;
+
+   while (end[1])
+   end++;
+
+   while (isblank(*end))
+   end--;
+
+   return strndup(ptr, end - ptr + 1);
+}
+
+static char *cboot_get_bootargs(const void *fdt)
+{
+   const char *args;
+   int offset, len;
+
+   offset = fdt_path_offset(fdt, "/chosen");
+   if (offset < 0)
+   return NULL;
+
+   args = fdt_getprop(fdt, offset, "bootargs", );
+   if (!args)
+   return NULL;
+
+   return strip(args);
+}
+
 int cboot_late_init(void)
 {
const void *fdt = (const void *)cboot_boot_x0;
uint8_t mac[ETH_ALEN];
+   char *bootargs;
int err;
 
set_calculated_env_vars();
@@ -554,5 +595,11 @@ int cboot_late_init(void)
if (!err)
eth_env_set_enetaddr("ethaddr", mac);
 
+   bootargs = cboot_get_bootargs(fdt);
+   if (bootargs) {
+   env_set("cbootargs", bootargs);
+   free(bootargs);
+   }
+
return 0;
 }
-- 
2.21.0

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


[U-Boot] [PATCH v3 18/19] lib: Implement strndup()

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Signed-off-by: Thierry Reding 
---
 include/linux/string.h |  1 +
 lib/string.c   | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/string.h b/include/linux/string.h
index 36066207392e..5d63be4ce5b0 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -94,6 +94,7 @@ size_t strcspn(const char *s, const char *reject);
 #ifndef __HAVE_ARCH_STRDUP
 extern char * strdup(const char *);
 #endif
+extern char * strndup(const char *, size_t);
 #ifndef __HAVE_ARCH_STRSWAB
 extern char * strswab(const char *);
 #endif
diff --git a/lib/string.c b/lib/string.c
index af17c16f616d..9b779ddc3bbe 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -326,6 +326,29 @@ char * strdup(const char *s)
 }
 #endif
 
+char * strndup(const char *s, size_t n)
+{
+   size_t len;
+   char *new;
+
+   if (s == NULL)
+   return NULL;
+
+   len = strlen(s);
+
+   if (n < len)
+   len = n;
+
+   new = malloc(len + 1);
+   if (new == NULL)
+   return NULL;
+
+   strncpy(new, s, len);
+   new[len] = '\0';
+
+   return new;
+}
+
 #ifndef __HAVE_ARCH_STRSPN
 /**
  * strspn - Calculate the length of the initial substring of @s which only
-- 
2.21.0

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


[U-Boot] [PATCH v3 06/19] ARM: tegra: Guard powergate code with a Kconfig symbol

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Powergate code is not relevant on all Tegra SoC generations, so guard it
with a Kconfig symbol that can be selected by the generations that need
it.

This is in preparation for unifying Tegra186 code with the code used on
older generations.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig  | 5 +
 arch/arm/mach-tegra/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index be20ac2e804e..db9198348d3f 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -32,6 +32,9 @@ config TEGRA_MC
 config TEGRA_PINCTRL
bool
 
+config TEGRA_PMC
+   bool
+
 config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -74,6 +77,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_MC
select TEGRA_NO_BPMP
select TEGRA_PINCTRL
+   select TEGRA_PMC
 
 config TEGRA_ARMV8_COMMON
bool "Tegra 64-bit common options"
@@ -122,6 +126,7 @@ config TEGRA210
select TEGRA_MC
select TEGRA_NO_BPMP
select TEGRA_PINCTRL
+   select TEGRA_PMC
 
 config TEGRA186
bool "Tegra186 family"
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 395e0191a458..517be21ee5f5 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -18,7 +18,7 @@ obj-y += board.o board2.o
 obj-y += cache.o
 obj-$(CONFIG_TEGRA_CLKRST) += clock.o
 obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
-obj-y += powergate.o
+obj-$(CONFIG_TEGRA_PMC) += powergate.o
 obj-y += xusb-padctl-dummy.o
 endif
 
-- 
2.21.0

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


[U-Boot] [PATCH v3 14/19] ARM: tegra: Implement cboot_get_ethaddr()

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

This function will attempt to look up an ethernet address in the DTB
that was passed in from cboot. It does so by first trying to locate the
primary ethernet device for the board (identified by the "ethernet"
alias) and if found, reads the "local-mac-address" property. If the
"ethernet" alias does not exist, or if it points to a device tree node
that doesn't exist, or if the device tree node that it points to does
not have a "local-mac-address" property or if the value is invalid, it
will fall back to the legacy mechanism of looking for the MAC address
stored in the "nvidia,ethernet-mac" property of the "/chosen" node.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- make dummy static inline to avoid duplicate definitions

 arch/arm/include/asm/arch-tegra/cboot.h |  6 ++
 arch/arm/mach-tegra/cboot.c | 78 -
 2 files changed, 69 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/arch-tegra/cboot.h 
b/arch/arm/include/asm/arch-tegra/cboot.h
index b3441ec178b3..021c24617575 100644
--- a/arch/arm/include/asm/arch-tegra/cboot.h
+++ b/arch/arm/include/asm/arch-tegra/cboot.h
@@ -14,6 +14,7 @@ void cboot_save_boot_params(unsigned long x0, unsigned long 
x1,
 int cboot_dram_init(void);
 int cboot_dram_init_banksize(void);
 ulong cboot_get_usable_ram_top(ulong total_size);
+int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN]);
 #else
 static inline void cboot_save_boot_params(unsigned long x0, unsigned long x1,
  unsigned long x2, unsigned long x3)
@@ -34,6 +35,11 @@ static inline ulong cboot_get_usable_ram_top(ulong 
total_size)
 {
return 0;
 }
+
+static inline int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN])
+{
+   return -ENOSYS;
+}
 #endif
 
 #endif
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index acf33b4c4e0c..9735380bda59 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -465,46 +466,93 @@ static int set_fdt_addr(void)
  * Attempt to use /chosen/nvidia,ethernet-mac in the cboot DTB to U-Boot's
  * ethaddr environment variable if possible.
  */
-static int set_ethaddr_from_cboot(void)
+static int cboot_get_ethaddr_legacy(const void *fdt, uint8_t mac[ETH_ALEN])
 {
-   const void *cboot_blob = (void *)cboot_boot_x0;
-   int ret, node, len;
-   const u32 *prop;
-
-   /* Already a valid address in the environment? If so, keep it */
-   if (env_get("ethaddr"))
-   return 0;
+   const char *prop;
+   int node, len;
 
-   node = fdt_path_offset(cboot_blob, "/chosen");
+   node = fdt_path_offset(fdt, "/chosen");
if (node < 0) {
printf("Can't find /chosen node in cboot DTB\n");
return node;
}
-   prop = fdt_getprop(cboot_blob, node, "nvidia,ethernet-mac", );
+
+   prop = fdt_getprop(fdt, node, "nvidia,ethernet-mac", );
if (!prop) {
printf("Can't find nvidia,ether-mac property in cboot DTB\n");
return -ENOENT;
}
 
-   ret = env_set("ethaddr", (void *)prop);
-   if (ret) {
-   printf("Failed to set ethaddr from cboot DTB: %d\n", ret);
-   return ret;
+   eth_parse_enetaddr(prop, mac);
+
+   if (!is_valid_ethaddr(mac)) {
+   printf("Invalid MAC address: %s\n", prop);
+   return -EINVAL;
}
 
+   debug("Legacy MAC address: %pM\n", mac);
+
return 0;
 }
 
+int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN])
+{
+   int node, len, err = 0;
+   const uchar *prop;
+   const char *path;
+
+   path = fdt_get_alias(fdt, "ethernet");
+   if (!path) {
+   err = -ENOENT;
+   goto out;
+   }
+
+   debug("ethernet alias found: %s\n", path);
+
+   node = fdt_path_offset(fdt, path);
+   if (node < 0) {
+   err = -ENOENT;
+   goto out;
+   }
+
+   prop = fdt_getprop(fdt, node, "local-mac-address", );
+   if (!prop) {
+   err = -ENOENT;
+   goto out;
+   }
+
+   if (len != ETH_ALEN) {
+   err = -EINVAL;
+   goto out;
+   }
+
+   debug("MAC address: %pM\n", prop);
+   memcpy(mac, prop, ETH_ALEN);
+
+out:
+   if (err < 0)
+   err = cboot_get_ethaddr_legacy(fdt, mac);
+
+   return err;
+}
+
 int cboot_late_init(void)
 {
+   const void *fdt = (const void *)cboot_boot_x0;
+   uint8_t mac[ETH_ALEN];
+   int err;
+
set_calculated_env_vars();
/*
 * Ignore errors here; the value may not be used depending on
 * extlinux.conf or boot script content.
 */
set_fdt_addr();
+
/* Ignore errors here; not all cases care about Ethernet addresses */
-   set_ethaddr_from_cboot();
+   err 

[U-Boot] [PATCH v3 05/19] ARM: tegra: Guard pin controller code with a Kconfig symbol

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Pin controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.

This is in preparation for unifying Tegra186 code with the code used on
older generations.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig  | 5 +
 arch/arm/mach-tegra/Makefile | 2 +-
 arch/arm/mach-tegra/board.c  | 6 ++
 arch/arm/mach-tegra/board2.c | 2 ++
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 5763c4ae3cd1..be20ac2e804e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -29,6 +29,9 @@ config TEGRA_IVC
 config TEGRA_MC
bool
 
+config TEGRA_PINCTRL
+   bool
+
 config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -70,6 +73,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
+   select TEGRA_PINCTRL
 
 config TEGRA_ARMV8_COMMON
bool "Tegra 64-bit common options"
@@ -117,6 +121,7 @@ config TEGRA210
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
+   select TEGRA_PINCTRL
 
 config TEGRA186
bool "Tegra186 family"
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 69f802c01b45..395e0191a458 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_TEGRA_GP_PADCTRL) += ap.o
 obj-y += board.o board2.o
 obj-y += cache.o
 obj-$(CONFIG_TEGRA_CLKRST) += clock.o
-obj-y += pinmux-common.o
+obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
 obj-y += powergate.o
 obj-y += xusb-padctl-dummy.o
 endif
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 7ef5a67edd1f..b65bdde5a78d 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -12,7 +12,9 @@
 #if IS_ENABLED(CONFIG_TEGRA_CLKRST)
 #include 
 #endif
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
 #include 
+#endif
 #if IS_ENABLED(CONFIG_TEGRA_MC)
 #include 
 #endif
@@ -132,6 +134,7 @@ int dram_init(void)
return 0;
 }
 
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
 static int uart_configs[] = {
 #if defined(CONFIG_TEGRA20)
  #if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
@@ -199,9 +202,11 @@ static void setup_uarts(int uart_ids)
}
}
 }
+#endif
 
 void board_init_uart_f(void)
 {
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
int uart_ids = 0;   /* bit mask of which UART ids to enable */
 
 #ifdef CONFIG_TEGRA_ENABLE_UARTA
@@ -220,6 +225,7 @@ void board_init_uart_f(void)
uart_ids |= UARTE;
 #endif
setup_uarts(uart_ids);
+#endif
 }
 
 #if !CONFIG_IS_ENABLED(OF_CONTROL)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index b94077221f77..ce1c9346959d 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -25,8 +25,10 @@
 #if IS_ENABLED(CONFIG_TEGRA_CLKRST)
 #include 
 #endif
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
 #include 
 #include 
+#endif
 #include 
 #ifdef CONFIG_TEGRA_CLOCK_SCALING
 #include 
-- 
2.21.0

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


[U-Boot] [PATCH v3 12/19] ARM: tegra: Unify Tegra186 builds

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Tegra186 build are currently dealt with in very special ways, which is
because Tegra186 is fundamentally different in many respects. It is no
longer necessary to do many of the low-level programming because early
boot firmware will already have taken care of it.

Unfortunately, separating Tegra186 builds from the rest in this way
makes it difficult to share code with prior generations of Tegra. With
all of the low-level programming code behind Kconfig guards, the build
for Tegra186 can again be unified.

As a side-effect, and partial reason for this change, other Tegra SoC
generations can now make use of the code that deals with taking over a
boot from earlier bootloaders. This used to be nvtboot, but has been
replaced by cboot nowadays. Rename the files and functions related to
this to avoid confusion. The implemented protocols are unchanged.

Signed-off-by: Thierry Reding 
---
Changes in v3:
- load cboot DTB address to fdt_addr instead of fdtaddr

 arch/arm/include/asm/arch-tegra/cboot.h   |  39 
 arch/arm/mach-tegra/Makefile  |   4 +-
 arch/arm/mach-tegra/board.c   |  23 ++
 arch/arm/mach-tegra/board186.c|  32 ---
 arch/arm/mach-tegra/board2.c  |  21 ++
 .../{tegra186/nvtboot_board.c => cboot.c} | 200 --
 .../{tegra186/nvtboot_ll.S => cboot_ll.S} |  12 +-
 arch/arm/mach-tegra/tegra186/Makefile |   4 -
 arch/arm/mach-tegra/tegra186/nvtboot_mem.c| 172 ---
 board/nvidia/p2771-/p2771-.c  |  10 +-
 10 files changed, 278 insertions(+), 239 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra/cboot.h
 delete mode 100644 arch/arm/mach-tegra/board186.c
 rename arch/arm/mach-tegra/{tegra186/nvtboot_board.c => cboot.c} (56%)
 rename arch/arm/mach-tegra/{tegra186/nvtboot_ll.S => cboot_ll.S} (57%)
 delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_mem.c

diff --git a/arch/arm/include/asm/arch-tegra/cboot.h 
b/arch/arm/include/asm/arch-tegra/cboot.h
new file mode 100644
index ..b3441ec178b3
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/cboot.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 NVIDIA Corporation. All rights reserved.
+ */
+
+#ifndef _TEGRA_CBOOT_H_
+#define _TEGRA_CBOOT_H_
+
+#ifdef CONFIG_ARM64
+extern unsigned long cboot_boot_x0;
+
+void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+   unsigned long x2, unsigned long x3);
+int cboot_dram_init(void);
+int cboot_dram_init_banksize(void);
+ulong cboot_get_usable_ram_top(ulong total_size);
+#else
+static inline void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+ unsigned long x2, unsigned long x3)
+{
+}
+
+static inline int cboot_dram_init(void)
+{
+   return -ENOSYS;
+}
+
+static inline int cboot_dram_init_banksize(void)
+{
+   return -ENOSYS;
+}
+
+static inline ulong cboot_get_usable_ram_top(ulong total_size)
+{
+   return 0;
+}
+#endif
+
+#endif
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f8bc65aa8b18..41ba674edff4 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -5,7 +5,6 @@
 # (C) Copyright 2000-2008
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
-ifndef CONFIG_TEGRA186
 ifdef CONFIG_SPL_BUILD
 obj-y += spl.o
 obj-y += cpu.o
@@ -20,9 +19,8 @@ obj-$(CONFIG_TEGRA_CLKRST) += clock.o
 obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
 obj-$(CONFIG_TEGRA_PMC) += powergate.o
 obj-y += xusb-padctl-dummy.o
-endif
 
-obj-$(CONFIG_ARM64) += arm64-mmu.o
+obj-$(CONFIG_ARM64) += arm64-mmu.o cboot_ll.o cboot.o
 obj-y += dt-setup.o
 obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
 obj-$(CONFIG_TEGRA_GPU) += gpu.o
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 59d2f347485d..c3ba00811e83 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,21 @@ void save_boot_params(unsigned long r0, unsigned long r1, 
unsigned long r2,
  unsigned long r3)
 {
from_spl = r0 != UBOOT_NOT_LOADED_FROM_SPL;
+
+   /*
+* The logic for this is somewhat indirect. The purpose of the marker
+* (UBOOT_NOT_LOADED_FROM_SPL) is in fact used to determine if U-Boot
+* was loaded from a read-only instance of itself, which is something
+* that can happen in secure boot setups. So basically the presence
+* of the marker is an indication that U-Boot was loaded by one such
+* special variant of U-Boot. Conversely, the absence of the marker
+* indicates that this instance of U-Boot was loaded by something
+* other than a special U-Boot. This could be SPL, but it could just
+* as well be one of any number of other first stage bootloaders.
+  

[U-Boot] [PATCH v3 16/19] p2371-2180: Pass Ethernet MAC to the kernel

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.

Signed-off-by: Thierry Reding 
---
 board/nvidia/p2371-2180/p2371-2180.c | 50 
 configs/p2371-2180_defconfig |  1 +
 2 files changed, 51 insertions(+)

diff --git a/board/nvidia/p2371-2180/p2371-2180.c 
b/board/nvidia/p2371-2180/p2371-2180.c
index 212037da5ac0..a444d692d7ea 100644
--- a/board/nvidia/p2371-2180/p2371-2180.c
+++ b/board/nvidia/p2371-2180/p2371-2180.c
@@ -5,9 +5,12 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include "../p2571/max77620_init.h"
 #include "pinmux-config-p2371-2180.h"
 
@@ -94,3 +97,50 @@ int tegra_pcie_board_init(void)
return 0;
 }
 #endif /* PCI */
+
+static void ft_mac_address_setup(void *fdt)
+{
+   const void *cboot_fdt = (const void *)cboot_boot_x0;
+   uint8_t mac[ETH_ALEN], local_mac[ETH_ALEN];
+   const char *path;
+   int offset, err;
+
+   err = cboot_get_ethaddr(cboot_fdt, local_mac);
+   if (err < 0)
+   memset(local_mac, 0, ETH_ALEN);
+
+   path = fdt_get_alias(fdt, "ethernet");
+   if (!path)
+   return;
+
+   debug("ethernet alias found: %s\n", path);
+
+   offset = fdt_path_offset(fdt, path);
+   if (offset < 0) {
+   printf("ethernet alias points to absent node %s\n", path);
+   return;
+   }
+
+   if (is_valid_ethaddr(local_mac)) {
+   err = fdt_setprop(fdt, offset, "local-mac-address", local_mac,
+ ETH_ALEN);
+   if (!err)
+   debug("Local MAC address set: %pM\n", local_mac);
+   }
+
+   if (eth_env_get_enetaddr("ethaddr", mac)) {
+   if (memcmp(local_mac, mac, ETH_ALEN) != 0) {
+   err = fdt_setprop(fdt, offset, "mac-address", mac,
+ ETH_ALEN);
+   if (!err)
+   debug("MAC address set: %pM\n", mac);
+   }
+   }
+}
+
+int ft_board_setup(void *fdt, bd_t *bd)
+{
+   ft_mac_address_setup(fdt);
+
+   return 0;
+}
diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig
index 2fac69917a92..16afbba68ae7 100644
--- a/configs/p2371-2180_defconfig
+++ b/configs/p2371-2180_defconfig
@@ -5,6 +5,7 @@ CONFIG_TEGRA210=y
 CONFIG_TARGET_P2371_2180=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
 CONFIG_SYS_PROMPT="Tegra210 (P2371-2180) # "
-- 
2.21.0

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


[U-Boot] [PATCH v3 15/19] ARM: tegra: Enable position independent build for 64-bit

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Note that U-Boot is always chainloaded from cboot starting with L4T
release 28. cboot always loads U-Boot to a fixed address, so making
the builds position independent isn't strictly necessary. However,
position independent builds can be convenient because if U-Boot is
ever loaded to an address different from its link address, it will
still be able to boot.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig  | 1 +
 configs/e2220-1170_defconfig | 2 +-
 configs/p2371-_defconfig | 2 +-
 configs/p2371-2180_defconfig | 2 +-
 configs/p2571_defconfig  | 2 +-
 5 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index faa73559fd42..97e22ead5985 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -87,6 +87,7 @@ config TEGRA_ARMV8_COMMON
bool "Tegra 64-bit common options"
select ARM64
select LINUX_KERNEL_IMAGE_HEADER
+   select POSITION_INDEPENDENT
select TEGRA_COMMON
 
 if TEGRA_ARMV8_COMMON
diff --git a/configs/e2220-1170_defconfig b/configs/e2220-1170_defconfig
index fbca72ace6ed..87668f8e517f 100644
--- a/configs/e2220-1170_defconfig
+++ b/configs/e2220-1170_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TEGRA=y
-CONFIG_SYS_TEXT_BASE=0x8011
+CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA210=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/p2371-_defconfig b/configs/p2371-_defconfig
index c25872128e07..979cb8ec0a25 100644
--- a/configs/p2371-_defconfig
+++ b/configs/p2371-_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TEGRA=y
-CONFIG_SYS_TEXT_BASE=0x8011
+CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA210=y
 CONFIG_TARGET_P2371_=y
 CONFIG_NR_DRAM_BANKS=2
diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig
index b662ef143141..2fac69917a92 100644
--- a/configs/p2371-2180_defconfig
+++ b/configs/p2371-2180_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TEGRA=y
-CONFIG_SYS_TEXT_BASE=0x8011
+CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA210=y
 CONFIG_TARGET_P2371_2180=y
 CONFIG_NR_DRAM_BANKS=2
diff --git a/configs/p2571_defconfig b/configs/p2571_defconfig
index 5f0f8c519b4c..ff4654cea9b4 100644
--- a/configs/p2571_defconfig
+++ b/configs/p2571_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TEGRA=y
-CONFIG_SYS_TEXT_BASE=0x8011
+CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA210=y
 CONFIG_TARGET_P2571=y
 CONFIG_NR_DRAM_BANKS=2
-- 
2.21.0

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


[U-Boot] [PATCH v3 17/19] p2771-0000: Pass Ethernet MAC to the kernel

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.

Signed-off-by: Thierry Reding 
---
 board/nvidia/p2771-/p2771-.c | 43 
 configs/p2771--000_defconfig |  1 +
 configs/p2771--500_defconfig |  1 +
 3 files changed, 45 insertions(+)

diff --git a/board/nvidia/p2771-/p2771-.c 
b/board/nvidia/p2771-/p2771-.c
index 6f88010c18c3..fe22067f6571 100644
--- a/board/nvidia/p2771-/p2771-.c
+++ b/board/nvidia/p2771-/p2771-.c
@@ -4,7 +4,10 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include "../p2571/max77620_init.h"
 
 void pin_mux_mmc(void)
@@ -52,3 +55,43 @@ int tegra_pcie_board_init(void)
return 0;
 }
 #endif
+
+int ft_board_setup(void *fdt, bd_t *bd)
+{
+   const void *cboot_fdt = (const void *)cboot_boot_x0;
+   uint8_t mac[ETH_ALEN], local_mac[ETH_ALEN];
+   const char *path;
+   int offset, err;
+
+   err = cboot_get_ethaddr(cboot_fdt, local_mac);
+   if (err < 0)
+   memset(local_mac, 0, ETH_ALEN);
+
+   path = fdt_get_alias(fdt, "ethernet");
+   if (!path)
+   return 0;
+
+   debug("ethernet alias found: %s\n", path);
+
+   offset = fdt_path_offset(fdt, path);
+   if (offset < 0)
+   return 0;
+
+   if (is_valid_ethaddr(local_mac)) {
+   err = fdt_setprop(fdt, offset, "local-mac-address", local_mac,
+ ETH_ALEN);
+   if (!err)
+   debug("Local MAC address set: %pM\n", local_mac);
+   }
+
+   if (eth_env_get_enetaddr("ethaddr", mac)) {
+   if (memcmp(local_mac, mac, ETH_ALEN) != 0) {
+   err = fdt_setprop(fdt, offset, "mac-address", mac,
+ ETH_ALEN);
+   if (!err)
+   debug("MAC address set: %pM\n", mac);
+   }
+   }
+
+   return 0;
+}
diff --git a/configs/p2771--000_defconfig b/configs/p2771--000_defconfig
index ad0802067e73..91896e39a10f 100644
--- a/configs/p2771--000_defconfig
+++ b/configs/p2771--000_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA186=y
 CONFIG_NR_DRAM_BANKS=1026
 CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
 CONFIG_SYS_PROMPT="Tegra186 (P2771--000) # "
diff --git a/configs/p2771--500_defconfig b/configs/p2771--500_defconfig
index 459b67fd195f..20d4393838d6 100644
--- a/configs/p2771--500_defconfig
+++ b/configs/p2771--500_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA186=y
 CONFIG_NR_DRAM_BANKS=1026
 CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
 CONFIG_SYS_PROMPT="Tegra186 (P2771--500) # "
-- 
2.21.0

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


[U-Boot] [PATCH v3 13/19] ARM: tegra: Implement cboot_save_boot_params() in C

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

This is easier to deal with and works just as well for this simple
function.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Makefile   |  2 +-
 arch/arm/mach-tegra/cboot.c| 12 
 arch/arm/mach-tegra/cboot_ll.S | 20 
 3 files changed, 13 insertions(+), 21 deletions(-)
 delete mode 100644 arch/arm/mach-tegra/cboot_ll.S

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 41ba674edff4..7165d70a60da 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
 obj-$(CONFIG_TEGRA_PMC) += powergate.o
 obj-y += xusb-padctl-dummy.o
 
-obj-$(CONFIG_ARM64) += arm64-mmu.o cboot_ll.o cboot.o
+obj-$(CONFIG_ARM64) += arm64-mmu.o cboot.o
 obj-y += dt-setup.o
 obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
 obj-$(CONFIG_TEGRA_GPU) += gpu.o
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index 95a097584ac6..acf33b4c4e0c 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -52,6 +52,18 @@ static u64 ram_top __attribute__((section(".data")));
 /* The base address of the region of RAM that ends at ram_top */
 static u64 region_base __attribute__((section(".data")));
 
+/*
+ * Explicitly put this in the .data section because it is written before the
+ * .bss section is zeroed out but it needs to persist.
+ */
+unsigned long cboot_boot_x0 __attribute__((section(".data")));
+
+void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+   unsigned long x2, unsigned long x3)
+{
+   cboot_boot_x0 = x0;
+}
+
 int cboot_dram_init(void)
 {
unsigned int na, ns;
diff --git a/arch/arm/mach-tegra/cboot_ll.S b/arch/arm/mach-tegra/cboot_ll.S
deleted file mode 100644
index 4c9ddacc2b39..
--- a/arch/arm/mach-tegra/cboot_ll.S
+++ /dev/null
@@ -1,20 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Save cboot-related boot-time CPU state
- *
- * (C) Copyright 2015-2016 NVIDIA Corporation 
- */
-
-#include 
-#include 
-
-.align 8
-.globl cboot_boot_x0
-cboot_boot_x0:
-   .dword 0
-
-ENTRY(cboot_save_boot_params)
-   adr x8, cboot_boot_x0
-   str x0, [x8]
-   b   save_boot_params_ret
-ENDPROC(cboot_save_boot_params)
-- 
2.21.0

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


[U-Boot] [PATCH v3 02/19] ARM: tegra: Guard clock code with a Kconfig symbol

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Clock code is not relevant on all Tegra SoC generations, so guard it
with a Kconfig symbol that can be selected by the generations that need
it.

This is in preparation for unifying Tegra186 code with the code used on
older generations.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig  |  5 +
 arch/arm/mach-tegra/Makefile |  2 +-
 arch/arm/mach-tegra/board.c  |  2 ++
 arch/arm/mach-tegra/board2.c | 12 ++--
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 86b1cd11f752..ee078fec9adc 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -12,6 +12,9 @@ config SPL_LIBGENERIC_SUPPORT
 config SPL_SERIAL_SUPPORT
default y
 
+config TEGRA_CLKRST
+   bool
+
 config TEGRA_IVC
bool "Tegra IVC protocol"
help
@@ -55,6 +58,7 @@ config TEGRA_ARMV7_COMMON
select SPL
select SPL_BOARD_INIT if SPL
select SUPPORT_SPL
+   select TEGRA_CLKRST
select TEGRA_COMMON
select TEGRA_GPIO
select TEGRA_NO_BPMP
@@ -100,6 +104,7 @@ config TEGRA124
 config TEGRA210
bool "Tegra210 family"
select TEGRA_ARMV8_COMMON
+   select TEGRA_CLKRST
select TEGRA_GPIO
select TEGRA_NO_BPMP
 
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index d4b4666fb1e2..0e812818d7a2 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -16,7 +16,7 @@ endif
 obj-y += ap.o
 obj-y += board.o board2.o
 obj-y += cache.o
-obj-y += clock.o
+obj-$(CONFIG_TEGRA_CLKRST) += clock.o
 obj-y += pinmux-common.o
 obj-y += powergate.o
 obj-y += xusb-padctl-dummy.o
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index f8fc042a1dcc..ecd5001de4c5 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -9,7 +9,9 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
 #include 
+#endif
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index b8d5ef0322cb..b94077221f77 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -22,7 +22,9 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -109,8 +111,10 @@ int board_init(void)
__maybe_unused int board_id;
 
/* Do clocks and UART first so that printf() works */
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
clock_init();
clock_verify();
+#endif
 
tegra_gpu_config();
 
@@ -181,8 +185,10 @@ void gpio_early_init(void) __attribute__((weak, 
alias("__gpio_early_init")));
 
 int board_early_init_f(void)
 {
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
if (!clock_early_init_done())
clock_early_init();
+#endif
 
 #if defined(CONFIG_TEGRA_DISCONNECT_UDC_ON_BOOT)
 #define USBCMD_FS2 (1 << 15)
@@ -193,10 +199,12 @@ int board_early_init_f(void)
 #endif
 
/* Do any special system timer/TSC setup */
-#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
+#  if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
if (!tegra_cpu_is_non_secure())
-#endif
+#  endif
arch_timer_init();
+#endif
 
pinmux_init();
board_init_uart_f();
-- 
2.21.0

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


[U-Boot] [PATCH v3 09/19] ARM: tegra: Support TZ-only access to PMC

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Some devices may restrict access to the PMC to TrustZone software only.
Non-TZ software can detect this and use SMC calls to the firmware that
runs in the TrustZone to perform accesses to PMC registers.

Note that this also fixes reset_cpu() and the enterrcm command on
Tegra186 where they were previously trying to access the PMC at a wrong
physical address.

Based on work by Kalyani Chidambaram  and Tom
Warren .

Signed-off-by: Thierry Reding 
---
 arch/arm/include/asm/arch-tegra/pmc.h   | 20 +-
 arch/arm/include/asm/arch-tegra/tegra.h |  6 ++
 arch/arm/mach-tegra/Kconfig |  5 ++
 arch/arm/mach-tegra/Makefile|  4 +-
 arch/arm/mach-tegra/clock.c | 13 ++--
 arch/arm/mach-tegra/cmd_enterrcm.c  |  6 +-
 arch/arm/mach-tegra/cpu.c   | 20 +++---
 arch/arm/mach-tegra/lowlevel_init.S | 39 ---
 arch/arm/mach-tegra/pmc.c   | 92 +
 arch/arm/mach-tegra/powergate.c | 11 +--
 10 files changed, 151 insertions(+), 65 deletions(-)
 delete mode 100644 arch/arm/mach-tegra/lowlevel_init.S
 create mode 100644 arch/arm/mach-tegra/pmc.c

diff --git a/arch/arm/include/asm/arch-tegra/pmc.h 
b/arch/arm/include/asm/arch-tegra/pmc.h
index 34bbe75d5fdb..1524bf291164 100644
--- a/arch/arm/include/asm/arch-tegra/pmc.h
+++ b/arch/arm/include/asm/arch-tegra/pmc.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- *  (C) Copyright 2010-2015
+ *  (C) Copyright 2010-2019
  *  NVIDIA Corporation 
  */
 
@@ -388,4 +388,22 @@ struct pmc_ctlr {
 /* APBDEV_PMC_CNTRL2_0 0x440 */
 #define HOLD_CKE_LOW_EN(1 << 12)
 
+/* PMC read/write functions */
+u32 tegra_pmc_readl(unsigned long offset);
+void tegra_pmc_writel(u32 value, unsigned long offset);
+
+#define PMC_CNTRL  0x0
+#define  PMC_CNTRL_MAIN_RSTBIT(4)
+
+#if IS_ENABLED(CONFIG_TEGRA186)
+#  define PMC_SCRATCH0 0x32000
+#else
+#  define PMC_SCRATCH0 0x00050
+#endif
+
+/* for secure PMC */
+#define TEGRA_SMC_PMC  0xc2fffe00
+#define  TEGRA_SMC_PMC_READ0xaa
+#define  TEGRA_SMC_PMC_WRITE   0xbb
+
 #endif /* PMC_H */
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h 
b/arch/arm/include/asm/arch-tegra/tegra.h
index 7ae0129e2db3..7a4e0972fb76 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -30,7 +30,13 @@
 #define NV_PA_SLINK5_BASE  (NV_PA_APB_MISC_BASE + 0xDC00)
 #define NV_PA_SLINK6_BASE  (NV_PA_APB_MISC_BASE + 0xDE00)
 #define TEGRA_DVC_BASE (NV_PA_APB_MISC_BASE + 0xD000)
+#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30) || \
+   defined(CONFIG_TEGRA114) || defined(CONFIG_TEGRA124) || \
+   defined(CONFIG_TEGRA132) || defined(CONFIG_TEGRA210)
 #define NV_PA_PMC_BASE (NV_PA_APB_MISC_BASE + 0xE400)
+#else
+#define NV_PA_PMC_BASE 0xc36
+#endif
 #define NV_PA_EMC_BASE (NV_PA_APB_MISC_BASE + 0xF400)
 #define NV_PA_FUSE_BASE(NV_PA_APB_MISC_BASE + 0xF800)
 #if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30) || \
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index db9198348d3f..28914a34a1b5 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -35,6 +35,10 @@ config TEGRA_PINCTRL
 config TEGRA_PMC
bool
 
+config TEGRA_PMC_SECURE
+   bool
+   depends on TEGRA_PMC
+
 config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -127,6 +131,7 @@ config TEGRA210
select TEGRA_NO_BPMP
select TEGRA_PINCTRL
select TEGRA_PMC
+   select TEGRA_PMC_SECURE
 
 config TEGRA186
bool "Tegra186 family"
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 517be21ee5f5..f8bc65aa8b18 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
-# (C) Copyright 2010-2015 Nvidia Corporation.
+# (C) Copyright 2010-2019 Nvidia Corporation.
 #
 # (C) Copyright 2000-2008
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
@@ -27,11 +27,11 @@ obj-y += dt-setup.o
 obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
 obj-$(CONFIG_TEGRA_GPU) += gpu.o
 obj-$(CONFIG_TEGRA_IVC) += ivc.o
-obj-y += lowlevel_init.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_ARMV7_PSCI) += psci.o
 endif
 obj-$(CONFIG_DISPLAY_CPUINFO) += sys_info.o
+obj-y += pmc.o
 
 obj-$(CONFIG_TEGRA20) += tegra20/
 obj-$(CONFIG_TEGRA30) += tegra30/
diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
index 096330748f2b..c9cd4e6aaeb7 100644
--- a/arch/arm/mach-tegra/clock.c
+++ b/arch/arm/mach-tegra/clock.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) 2010-2015, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (c) 2010-2019, NVIDIA CORPORATION.  All rights reserved.
  */
 
 /* Tegra SoC common clock control functions */
@@ -814,11 +814,16 @@ void tegra30_set_up_pllp(void)
 
 int 

[U-Boot] [PATCH v3 07/19] ARM: tegra: Fix save_boot_params() prototype

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The save_boot_params() function takes as its first four arguments the
first four registers. On 32-bit ARM these are r0, r1, r2 and r3, all of
which are 32 bits wide. However, on 64-bit ARM thene registers are x0,
x1, x2 and x3, all of which are 64 bits wide. In order to allow reusing
the save_boot_params() implementation on 64-bit ARM, change it to take
unsigned long parameters rather than the fixed size 32-bit integers.
This ensures that the correct values are passed.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/board.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index b65bdde5a78d..59d2f347485d 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -42,7 +42,8 @@ enum {
 static bool from_spl __attribute__ ((section(".data")));
 
 #ifndef CONFIG_SPL_BUILD
-void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
+ unsigned long r3)
 {
from_spl = r0 != UBOOT_NOT_LOADED_FROM_SPL;
save_boot_params_ret();
-- 
2.21.0

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


[U-Boot] [PATCH v3 10/19] ARM: tegra: Workaround UDC boot issues only if necessary

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Resetting the USB device controller on boot is only necessary if the SoC
actually has a UDC controller and U-Boot enables support for it. All the
Tegra boards support UDC via the ChipIdea UDC driver, so make the UDC on
boot workaround depend on the ChipIdea UDC driver.

This prevents a crash on Tegra186 which does not have the ChipIdea UDC.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 28914a34a1b5..faa73559fd42 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -148,6 +148,7 @@ endchoice
 
 config TEGRA_DISCONNECT_UDC_ON_BOOT
bool "Disconnect USB device mode controller on boot"
+   depends on CI_UDC
default y
help
  When loading U-Boot into RAM over USB protocols using tools such as
-- 
2.21.0

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


[U-Boot] [PATCH v3 08/19] ARM: tegra: Allow boards to override boot target devices

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Boards may not support all the boot target devices in the default list
for Tegra devices. Allow a board to override the list and default to the
standard list only if the board hasn't specified one itself.

Signed-off-by: Thierry Reding 
---
 include/configs/tegra-common-post.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/tegra-common-post.h 
b/include/configs/tegra-common-post.h
index e54428ba43e2..9685ee5059ab 100644
--- a/include/configs/tegra-common-post.h
+++ b/include/configs/tegra-common-post.h
@@ -21,12 +21,14 @@
 #define CONFIG_SYS_NONCACHED_MEMORY(1 << 20)   /* 1 MiB */
 
 #ifndef CONFIG_SPL_BUILD
+#ifndef BOOT_TARGET_DEVICES
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 1) \
func(MMC, mmc, 0) \
func(USB, usb, 0) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
+#endif
 #include 
 #else
 #define BOOTENV
-- 
2.21.0

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


[U-Boot] [PATCH v3 03/19] ARM: tegra: Guard GP pad control code with a Kconfig symbol

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The GP pad control code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.

This is in preparation for unifying Tegra186 code with the code used on
older generations.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig  | 5 +
 arch/arm/mach-tegra/Makefile | 2 +-
 arch/arm/mach-tegra/cache.c  | 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index ee078fec9adc..265051b18aaf 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -15,6 +15,9 @@ config SPL_SERIAL_SUPPORT
 config TEGRA_CLKRST
bool
 
+config TEGRA_GP_PADCTRL
+   bool
+
 config TEGRA_IVC
bool "Tegra IVC protocol"
help
@@ -61,6 +64,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_CLKRST
select TEGRA_COMMON
select TEGRA_GPIO
+   select TEGRA_GP_PADCTRL
select TEGRA_NO_BPMP
 
 config TEGRA_ARMV8_COMMON
@@ -106,6 +110,7 @@ config TEGRA210
select TEGRA_ARMV8_COMMON
select TEGRA_CLKRST
select TEGRA_GPIO
+   select TEGRA_GP_PADCTRL
select TEGRA_NO_BPMP
 
 config TEGRA186
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 0e812818d7a2..69f802c01b45 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -13,7 +13,7 @@ else
 obj-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o
 endif
 
-obj-y += ap.o
+obj-$(CONFIG_TEGRA_GP_PADCTRL) += ap.o
 obj-y += board.o board2.o
 obj-y += cache.o
 obj-$(CONFIG_TEGRA_CLKRST) += clock.o
diff --git a/arch/arm/mach-tegra/cache.c b/arch/arm/mach-tegra/cache.c
index be414e4e4aca..d7063490e222 100644
--- a/arch/arm/mach-tegra/cache.c
+++ b/arch/arm/mach-tegra/cache.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_TEGRA_GP_PADCTRL)
 #include 
+#endif
 
 #ifndef CONFIG_ARM64
 void config_cache(void)
-- 
2.21.0

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


[U-Boot] [PATCH v3 11/19] ARM: tegra: Restore DRAM bank count

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") reduced
the number of DRAM banks supported by U-Boot from 1026 to 8 on P2771-000
boards.

However, as explained in commit a9819b9e33bd ("ARM: tegra: p2771-000:
increase max DRAM bank count"), the platform can have a large number of
unusable chunks of memory (up to 1024), so a total of 1026 DRAM banks
are needed to describe the worst-case situation.

In practice the number of DRAM banks needed will typically be much
lower, but we should be prepared to properly deal with the worst case.

Signed-off-by: Thierry Reding 
---
 configs/p2771--000_defconfig | 2 +-
 configs/p2771--500_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/p2771--000_defconfig b/configs/p2771--000_defconfig
index ac85efa37b3b..ad0802067e73 100644
--- a/configs/p2771--000_defconfig
+++ b/configs/p2771--000_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TEGRA=y
 CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA186=y
-CONFIG_NR_DRAM_BANKS=8
+CONFIG_NR_DRAM_BANKS=1026
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
diff --git a/configs/p2771--500_defconfig b/configs/p2771--500_defconfig
index df4d914d85cf..459b67fd195f 100644
--- a/configs/p2771--500_defconfig
+++ b/configs/p2771--500_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TEGRA=y
 CONFIG_SYS_TEXT_BASE=0x8008
 CONFIG_TEGRA186=y
-CONFIG_NR_DRAM_BANKS=8
+CONFIG_NR_DRAM_BANKS=1026
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
-- 
2.21.0

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


[U-Boot] [PATCH v3 04/19] ARM: tegra: Guard memory controller code with a Kconfig symbol

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

Memory controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.

This is in preparation for unifying Tegra186 code with the code used on
older generations.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/Kconfig | 5 +
 arch/arm/mach-tegra/board.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 265051b18aaf..5763c4ae3cd1 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -26,6 +26,9 @@ config TEGRA_IVC
  U-Boot, it is typically used for communication between the main CPU
  and various auxiliary processors.
 
+config TEGRA_MC
+   bool
+
 config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -65,6 +68,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_COMMON
select TEGRA_GPIO
select TEGRA_GP_PADCTRL
+   select TEGRA_MC
select TEGRA_NO_BPMP
 
 config TEGRA_ARMV8_COMMON
@@ -111,6 +115,7 @@ config TEGRA210
select TEGRA_CLKRST
select TEGRA_GPIO
select TEGRA_GP_PADCTRL
+   select TEGRA_MC
select TEGRA_NO_BPMP
 
 config TEGRA186
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index ecd5001de4c5..7ef5a67edd1f 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -13,7 +13,9 @@
 #include 
 #endif
 #include 
+#if IS_ENABLED(CONFIG_TEGRA_MC)
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -68,6 +70,7 @@ bool tegra_cpu_is_non_secure(void)
 }
 #endif
 
+#if IS_ENABLED(CONFIG_TEGRA_MC)
 /* Read the RAM size directly from the memory controller */
 static phys_size_t query_sdram_size(void)
 {
@@ -117,11 +120,15 @@ static phys_size_t query_sdram_size(void)
 
return size_bytes;
 }
+#endif
 
 int dram_init(void)
 {
+#if IS_ENABLED(CONFIG_TEGRA_MC)
/* We do not initialise DRAM here. We just query the size */
gd->ram_size = query_sdram_size();
+#endif
+
return 0;
 }
 
-- 
2.21.0

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


[U-Boot] [PATCH v3 01/19] ARM: tegra: Use common header for PMU declarations

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

There's no need to replicate the pmu.h header file for every Tegra SoC
generation. Use a single header that is shared across generations.

Signed-off-by: Thierry Reding 
---
 .../include/asm/{arch-tegra20 => arch-tegra}/pmu.h  |  6 +++---
 arch/arm/include/asm/arch-tegra114/pmu.h| 12 
 arch/arm/include/asm/arch-tegra124/pmu.h| 13 -
 arch/arm/include/asm/arch-tegra210/pmu.h| 13 -
 arch/arm/include/asm/arch-tegra30/pmu.h | 12 
 arch/arm/mach-tegra/board2.c|  2 +-
 arch/arm/mach-tegra/emc.c   |  2 +-
 7 files changed, 5 insertions(+), 55 deletions(-)
 rename arch/arm/include/asm/{arch-tegra20 => arch-tegra}/pmu.h (73%)
 delete mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra124/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra210/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra30/pmu.h

diff --git a/arch/arm/include/asm/arch-tegra20/pmu.h 
b/arch/arm/include/asm/arch-tegra/pmu.h
similarity index 73%
rename from arch/arm/include/asm/arch-tegra20/pmu.h
rename to arch/arm/include/asm/arch-tegra/pmu.h
index 18766dfed2bb..e850875d3166 100644
--- a/arch/arm/include/asm/arch-tegra20/pmu.h
+++ b/arch/arm/include/asm/arch-tegra/pmu.h
@@ -4,10 +4,10 @@
  *  NVIDIA Corporation 
  */
 
-#ifndef _ARCH_PMU_H_
-#define _ARCH_PMU_H_
+#ifndef _TEGRA_PMU_H_
+#define _TEGRA_PMU_H_
 
 /* Set core and CPU voltages to nominal levels */
 int pmu_set_nominal(void);
 
-#endif /* _ARCH_PMU_H_ */
+#endif /* _TEGRA_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra114/pmu.h 
b/arch/arm/include/asm/arch-tegra114/pmu.h
deleted file mode 100644
index 1e571ee7b317..
--- a/arch/arm/include/asm/arch-tegra114/pmu.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2010-2013, NVIDIA CORPORATION.  All rights reserved.
- */
-
-#ifndef _TEGRA114_PMU_H_
-#define _TEGRA114_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA114_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra124/pmu.h 
b/arch/arm/include/asm/arch-tegra124/pmu.h
deleted file mode 100644
index c38393edefda..
--- a/arch/arm/include/asm/arch-tegra124/pmu.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2010-2013
- * NVIDIA Corporation 
- */
-
-#ifndef _TEGRA124_PMU_H_
-#define _TEGRA124_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA124_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra210/pmu.h 
b/arch/arm/include/asm/arch-tegra210/pmu.h
deleted file mode 100644
index 6ea36aa41876..
--- a/arch/arm/include/asm/arch-tegra210/pmu.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2010-2015
- * NVIDIA Corporation 
- */
-
-#ifndef _TEGRA210_PMU_H_
-#define _TEGRA210_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA210_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra30/pmu.h 
b/arch/arm/include/asm/arch-tegra30/pmu.h
deleted file mode 100644
index a823f0fbfc61..
--- a/arch/arm/include/asm/arch-tegra30/pmu.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
- */
-
-#ifndef _TEGRA30_PMU_H_
-#define _TEGRA30_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA30_PMU_H_ */
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index 12257a42b51b..b8d5ef0322cb 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #ifdef CONFIG_TEGRA_CLOCK_SCALING
 #include 
diff --git a/arch/arm/mach-tegra/emc.c b/arch/arm/mach-tegra/emc.c
index 6697909d9a3e..66628933b653 100644
--- a/arch/arm/mach-tegra/emc.c
+++ b/arch/arm/mach-tegra/emc.c
@@ -8,10 +8,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
-- 
2.21.0

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


[U-Boot] [PATCH v3 00/19] ARM: tegra: Miscellaneous improvements

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

The bulk of these changes are an effort to unify Tegra186 builds with
builds of prior 64-bit Tegra generations. On top of that there are
various improvements that allow data (such as the MAC address and boot
arguments) to be passed through from early firmware to the kernel on
boot.

The last two patches can be applied at a later time if the strndup()
addition can't be merged along with the rest of the patches through
the Tegra tree.

Thierry

Thierry Reding (19):
  ARM: tegra: Use common header for PMU declarations
  ARM: tegra: Guard clock code with a Kconfig symbol
  ARM: tegra: Guard GP pad control code with a Kconfig symbol
  ARM: tegra: Guard memory controller code with a Kconfig symbol
  ARM: tegra: Guard pin controller code with a Kconfig symbol
  ARM: tegra: Guard powergate code with a Kconfig symbol
  ARM: tegra: Fix save_boot_params() prototype
  ARM: tegra: Allow boards to override boot target devices
  ARM: tegra: Support TZ-only access to PMC
  ARM: tegra: Workaround UDC boot issues only if necessary
  ARM: tegra: Restore DRAM bank count
  ARM: tegra: Unify Tegra186 builds
  ARM: tegra: Implement cboot_save_boot_params() in C
  ARM: tegra: Implement cboot_get_ethaddr()
  ARM: tegra: Enable position independent build for 64-bit
  p2371-2180: Pass Ethernet MAC to the kernel
  p2771-: Pass Ethernet MAC to the kernel
  lib: Implement strndup()
  ARM: tegra: Import cbootargs value from cboot DTB

 arch/arm/include/asm/arch-tegra/cboot.h   |  45 ++
 arch/arm/include/asm/arch-tegra/pmc.h |  20 +-
 .../asm/{arch-tegra20 => arch-tegra}/pmu.h|   6 +-
 arch/arm/include/asm/arch-tegra/tegra.h   |   6 +
 arch/arm/include/asm/arch-tegra114/pmu.h  |  12 -
 arch/arm/include/asm/arch-tegra124/pmu.h  |  13 -
 arch/arm/include/asm/arch-tegra210/pmu.h  |  13 -
 arch/arm/include/asm/arch-tegra30/pmu.h   |  12 -
 arch/arm/mach-tegra/Kconfig   |  32 +
 arch/arm/mach-tegra/Makefile  |  16 +-
 arch/arm/mach-tegra/board.c   |  41 +-
 arch/arm/mach-tegra/board186.c|  32 -
 arch/arm/mach-tegra/board2.c  |  37 +-
 arch/arm/mach-tegra/cache.c   |   2 +
 arch/arm/mach-tegra/cboot.c   | 605 ++
 arch/arm/mach-tegra/clock.c   |  13 +-
 arch/arm/mach-tegra/cmd_enterrcm.c|   6 +-
 arch/arm/mach-tegra/cpu.c |  20 +-
 arch/arm/mach-tegra/emc.c |   2 +-
 arch/arm/mach-tegra/lowlevel_init.S   |  39 --
 arch/arm/mach-tegra/pmc.c |  92 +++
 arch/arm/mach-tegra/powergate.c   |  11 +-
 arch/arm/mach-tegra/tegra186/Makefile |   4 -
 arch/arm/mach-tegra/tegra186/nvtboot_board.c  | 332 --
 arch/arm/mach-tegra/tegra186/nvtboot_ll.S |  20 -
 arch/arm/mach-tegra/tegra186/nvtboot_mem.c| 172 -
 board/nvidia/p2371-2180/p2371-2180.c  |  50 ++
 board/nvidia/p2771-/p2771-.c  |  53 +-
 configs/e2220-1170_defconfig  |   2 +-
 configs/p2371-_defconfig  |   2 +-
 configs/p2371-2180_defconfig  |   3 +-
 configs/p2571_defconfig   |   2 +-
 configs/p2771--000_defconfig  |   3 +-
 configs/p2771--500_defconfig  |   3 +-
 include/configs/tegra-common-post.h   |   2 +
 include/linux/string.h|   1 +
 lib/string.c  |  23 +
 37 files changed, 1046 insertions(+), 701 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra/cboot.h
 rename arch/arm/include/asm/{arch-tegra20 => arch-tegra}/pmu.h (73%)
 delete mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra124/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra210/pmu.h
 delete mode 100644 arch/arm/include/asm/arch-tegra30/pmu.h
 delete mode 100644 arch/arm/mach-tegra/board186.c
 create mode 100644 arch/arm/mach-tegra/cboot.c
 delete mode 100644 arch/arm/mach-tegra/lowlevel_init.S
 create mode 100644 arch/arm/mach-tegra/pmc.c
 delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_board.c
 delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_ll.S
 delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_mem.c

-- 
2.21.0

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


[U-Boot] [PATCH 2/2] ARM: tegra: Remove disp1 clock initialization on Tegra210

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

pll_c is not a valid parent for the disp1 clock, so trying to set it
will fail. Given that display is not used in U-Boot, remove the init
table entry so that disp1 will keep its default parent (clk_m).

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/tegra210/clock.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-tegra/tegra210/clock.c 
b/arch/arm/mach-tegra/tegra210/clock.c
index 0d7cafea2017..b240860f08cf 100644
--- a/arch/arm/mach-tegra/tegra210/clock.c
+++ b/arch/arm/mach-tegra/tegra210/clock.c
@@ -1265,7 +1265,6 @@ struct periph_clk_init periph_clk_init_table[] = {
{ PERIPH_ID_SBC5, CLOCK_ID_PERIPH },
{ PERIPH_ID_SBC6, CLOCK_ID_PERIPH },
{ PERIPH_ID_HOST1X, CLOCK_ID_PERIPH },
-   { PERIPH_ID_DISP1, CLOCK_ID_CGENERAL },
{ PERIPH_ID_SDMMC1, CLOCK_ID_PERIPH },
{ PERIPH_ID_SDMMC2, CLOCK_ID_PERIPH },
{ PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH },
-- 
2.21.0

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


[U-Boot] [PATCH 1/2] ARM: tegra: Fix mux type for disp1 and disp2 clocks on Tegra210

2019-03-21 Thread Thierry Reding
From: Thierry Reding 

On Tegra210 the parents for the disp1 and disp2 clocks are slightly
different from earlier chips. Only pll_p, pll_d_out0, pll_d2_out0 and
clk_m are valid parents (technically pll_d_out is as well, but U-Boot
doesn't know anything about it). Fix up the type name and the mux
definition.

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-tegra/tegra210/clock.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-tegra/tegra210/clock.c 
b/arch/arm/mach-tegra/tegra210/clock.c
index 06068c4b7b8d..0d7cafea2017 100644
--- a/arch/arm/mach-tegra/tegra210/clock.c
+++ b/arch/arm/mach-tegra/tegra210/clock.c
@@ -40,7 +40,7 @@ enum clock_type_id {
CLOCK_TYPE_PDCT,
CLOCK_TYPE_ACPT,
CLOCK_TYPE_ASPTE,
-   CLOCK_TYPE_PMDACD2T,
+   CLOCK_TYPE_PDD2T,
CLOCK_TYPE_PCST,
CLOCK_TYPE_DP,
 
@@ -97,8 +97,8 @@ static enum clock_id 
clock_source[CLOCK_TYPE_COUNT][CLOCK_MAX_MUX+1] = {
{ CLK(AUDIO),   CLK(SFROM32KHZ),CLK(PERIPH),CLK(OSC),
CLK(EPCI),  CLK(NONE),  CLK(NONE),  CLK(NONE),
MASK_BITS_31_29},
-   { CLK(PERIPH),  CLK(MEMORY),CLK(DISPLAY),   CLK(AUDIO),
-   CLK(CGENERAL),  CLK(DISPLAY2),  CLK(OSC),   CLK(NONE),
+   { CLK(PERIPH),  CLK(NONE),  CLK(DISPLAY),   CLK(NONE),
+   CLK(NONE),  CLK(DISPLAY2),  CLK(OSC),   CLK(NONE),
MASK_BITS_31_29},
{ CLK(PERIPH),  CLK(CGENERAL),  CLK(SFROM32KHZ),CLK(OSC),
CLK(NONE),  CLK(NONE),  CLK(NONE),  CLK(NONE),
@@ -174,8 +174,8 @@ static enum clock_type_id clock_periph_type[PERIPHC_COUNT] 
= {
TYPE(PERIPHC_0bh,   CLOCK_TYPE_NONE),
TYPE(PERIPHC_0ch,   CLOCK_TYPE_NONE),
TYPE(PERIPHC_SBC1,  CLOCK_TYPE_PC2CC3M_T),
-   TYPE(PERIPHC_DISP1, CLOCK_TYPE_PMDACD2T),
-   TYPE(PERIPHC_DISP2, CLOCK_TYPE_PMDACD2T),
+   TYPE(PERIPHC_DISP1, CLOCK_TYPE_PDD2T),
+   TYPE(PERIPHC_DISP2, CLOCK_TYPE_PDD2T),
 
/* 0x10 */
TYPE(PERIPHC_10h,   CLOCK_TYPE_NONE),
-- 
2.21.0

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


Re: [U-Boot] [PATCHv2 1/2] ti: keystone2: Move CONFIG_ISW_ENTRY_ADDR to a common place

2019-03-21 Thread Tom Rini
On Thu, Mar 21, 2019 at 11:02:37AM +0530, Lokesh Vutla wrote:
> Hi Tom,
> 
> On 20/03/19 8:09 PM, Tom Rini wrote:
> > On Wed, Mar 20, 2019 at 07:03:52PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >> On 19/03/19 4:44 PM, Tom Rini wrote:
> >>> The ISW_ENTRY_ADDR Kconfig option under mach-omap2 isn't a SoC specific
> >>> notion but rather "where is our previous stage loaded in memory?"
> >>> option.  Make use of this on ARCH_KEYSTONE rather than SPL_TEXT_BASE for
> >>> our HS builds that are not using SPL anyhow.
> >>>
> >>> Cc: Vitaly Andrianov 
> >>> Cc: Andrew F. Davis 
> >>> Cc: Lokesh Vutla 
> >>> Signed-off-by: Tom Rini 
> >>
> >> Reviewed-by: Lokesh Vutla  > 
> > Thanks.
> > 
> >>> ---
> >>> On a related note, can we please move SRAM_SCRATCH_SPACE_ADDR to a more
> >>> fixed location?  The build logic here is going to break again when more
> >>
> >> I guess you are talking about keystone2 devices. All omap platforms has 
> >> sram
> >> scratch space as last 1K.  Something similar can be done for keystone2 
> >> platforms
> >> as well.
> > 
> > Well, as came up in another thread, that's not quite true for OMAP
> > platforms.  Today we shove it in such a location that stack could grow
> 
> I see what you are talking about. Then CONFIG_SYS_INIT_SP_ADDR should be 
> updated
> to SRAM_SCRATCH_SPACE_ADDR instead of NON_SECURE_SRAM_END. I am surprised we
> never faced an issue.

Keystone2 is "huge" and we got a bit lucky on AM335x/etc/etc until
recently.

> > into it, and IFF what the am437x TRM says is true, we've been violating
> > rules wrt stack placement since forever (that "public stack" is for ROM
> 
> That public stack is used by ROM only while downloading the image. Once ROM
> completes the download it is available for use by any bootloader.

Ah, OK.  I'll not worry too much that the TRM claims it's for the ROM
only then and that'll save us some headroom on these otherwise
constrained platforms.

-- 
Tom


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


Re: [U-Boot] [linux-sunxi] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels

2019-03-21 Thread Jagan Teki
On Tue, Mar 19, 2019 at 11:09 AM Jonathan Liu  wrote:
>
> Old sunxi kernels fail to boot with ARMV7_LPAE enabled.

Any idea why? I don't have relevant stuff with to test this.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] mtd: spi: Add Macronix MX66U2G45F device

2019-03-21 Thread Jagan Teki
On Fri, Mar 8, 2019 at 3:57 AM Marek Vasut  wrote:
>
> Add Macronix MX66U2G45F flash device description.
> This is a 256 MiB part.

Couldn't find the datasheet on web, do you have a link?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/9] riscv: Add a SYSCON driver for Andestech's PLIC

2019-03-21 Thread Troy Benjegerdes
> > > >
> > > > Probably it makes more sense to put this to arch/riscv/cpu/ax25/Kconfig?
> > >
> > > I just refer to SIFIVE_CLINT. It also not make sense to place here, right 
> > > ?
> >
> > Maybe, but since the cpu directory is renamed to 'generic', I am not
> > sure moving to that directory is a good idea.
> 
> Maybe I will still put it in /arch/riscv/Kconfig.
> And we can move them to the place they belong individually together if
> there have better place to accommodate to SIFIVE_CLINT.
> How do you think ?
> 



> > > > > +++ b/arch/riscv/lib/Makefile
> > > > > @@ -11,6 +11,7 @@ obj-$(CONFIG_CMD_GO) += boot.o
> > > > >  obj-y  += cache.o
> > > > >  obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
> > > > >  obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
> > > > > +obj-$(CONFIG_NDS_PLIC) += nds_plic.o
> > > > >  obj-y  += interrupts.o
> > > > >  obj-y  += reset.o
> > > > >  obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
> > > > > diff --git a/arch/riscv/lib/nds_plic.c b/arch/riscv/lib/nds_plic.c
> > > >
> > > > And move this driver to arch/riscv/cpu/ax25 since it's only available
> > > > in AX25 CPUs?
> > >
> > > Same as sifive_clint.c . Shall it also move away from /lib ?
> > >
> >
> > I agree, but see comments above :)


It seems to me there might be a usefull distinction between potentially 
generic things like the Sifive/Berkely/Rocket-chip clint [1] and other
vendor implementations which do not have necessarily have publicly 
reviewable hardware implementations.

[1] 
https://github.com/sifive/rocket-chip/blob/master/src/main/scala/devices/tilelink/CLINT.scala
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [RFC v2 0/2] arm64: zynqmp: pass a PMUFW config object

2019-03-21 Thread Luca Ceresoli
Hi,

a long-standing issue in the ZynqMP users community is the management on
the PMU firmware configuration object when U-Boot SPL is used.

The Platform Management Unit (PMU) needs a configuration object (cfg obj)
to know how to operate the SoC. When using the "Xilinx workflow", the
Xilinx FSBL (First Stage Bootloader) has the SPL role. FSBL has a built-in
cfg obj and passes it to the PMUFW at runtime before jumping to U-Boot
proper.

This is just not implemented in the U-Boot code. The best workaround for
U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg obj
built-in and self-load it. This approach has some drawbacks: among others,
it forces to use a different PMUFW binary for each hardware and hardware
configuation. It also makes it impossible to change the configuration after
boot.

This patchset is a first attempt at filling the gap by allowing U-Boot SPL
to load the cfg obj firmware at runtime. It adds a Kconfig string option to
point to the cfg obj in the form of a C file as produced by Xilinx tools
(usually called pm_cfg_obj.c). If the option is non-empty, code is enabled
to compile that file in U-Boot SPL and send the configuration to PMUFW.

The next development target will be to load the cfg obj from a binary blob
instead of compiling it from a .c file. With that in place, patch 1 will be
removed and patch 2 cleaned up.

These patches are tested on the UltraZed EV board.

Since RFC v1 [1] the loading has been reimplemented in SPL (it was in
U-Boot proper). Now it does not rely on ARM Trusted Firmware but instead
talks directly with the PMU via IPI mailboxes.

[0] 
https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch
[1] https://lists.denx.de/pipermail/u-boot/2019-February/360450.html

Luca


Luca Ceresoli (2):
  zynqmp: add minimal include files to build a pm_cfg_obj.c
  arm64: zynqmp: spl: install a PMU firmware config object at runtime

 board/xilinx/zynqmp/Kconfig  |  26 
 board/xilinx/zynqmp/Makefile |   5 +
 board/xilinx/zynqmp/pm_defs.h| 254 +++
 board/xilinx/zynqmp/pmu_global.h |   0
 board/xilinx/zynqmp/pmu_ipc.c| 116 ++
 board/xilinx/zynqmp/pmu_ipc.h|  14 ++
 board/xilinx/zynqmp/xil_types.h  |   1 +
 board/xilinx/zynqmp/zynqmp.c |  11 ++
 8 files changed, 427 insertions(+)
 create mode 100644 board/xilinx/zynqmp/pm_defs.h
 create mode 100644 board/xilinx/zynqmp/pmu_global.h
 create mode 100644 board/xilinx/zynqmp/pmu_ipc.c
 create mode 100644 board/xilinx/zynqmp/pmu_ipc.h
 create mode 100644 board/xilinx/zynqmp/xil_types.h

-- 
2.17.1

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


[U-Boot] [RFC v2 1/2] zynqmp: add minimal include files to build a pm_cfg_obj.c

2019-03-21 Thread Luca Ceresoli
A following commit will allow U-Boot to pass a configuration object to
the ZynqMP PMU firmware. This configuration object is generated by
Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a
few headers with constants definitions.

In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal
version of those headers files:

 - pm_defs: a copy of [0], reduced to remove unneeded values
 - pmu_global.h: empty file, it is included but not really needed
 - xil_types.h: just includes common.h which has all the needed types

[0] 
https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h

Signed-off-by: Luca Ceresoli 
---
 board/xilinx/zynqmp/pm_defs.h| 254 +++
 board/xilinx/zynqmp/pmu_global.h |   0
 board/xilinx/zynqmp/xil_types.h  |   1 +
 3 files changed, 255 insertions(+)
 create mode 100644 board/xilinx/zynqmp/pm_defs.h
 create mode 100644 board/xilinx/zynqmp/pmu_global.h
 create mode 100644 board/xilinx/zynqmp/xil_types.h

diff --git a/board/xilinx/zynqmp/pm_defs.h b/board/xilinx/zynqmp/pm_defs.h
new file mode 100644
index ..a339d5ef4fd1
--- /dev/null
+++ b/board/xilinx/zynqmp/pm_defs.h
@@ -0,0 +1,254 @@
+/**
+*
+* Copyright (C) 2015-2018 Xilinx, Inc.  All rights reserved.
+*
+* 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
+* XILINX  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.
+*
+* Except as contained in this notice, the name of the Xilinx shall not be used
+* in advertising or otherwise to promote the sale, use or other dealings in
+* this Software without prior written authorization from Xilinx.
+*
+**/
+
+/*/
+/**
+ * @file pm_defs.h
+ *
+ * PM Definitions implementation
+ * @addtogroup xpm_apis XilPM APIs
+ * @{
+ */
+
+#ifndef PM_DEFS_H_
+#define PM_DEFS_H_
+
+/** @name Capabilities for RAM
+ *
+ * @{
+ */
+#define PM_CAP_ACCESS  0x1U
+#define PM_CAP_CONTEXT 0x2U
+#define PM_CAP_WAKEUP  0x4U
+/**@}*/
+
+/**
+ * PM Node ID Enum
+ */
+enum XPmNodeId {
+   NODE_UNKNOWN,
+   NODE_APU,
+   NODE_APU_0,
+   NODE_APU_1,
+   NODE_APU_2,
+   NODE_APU_3,
+   NODE_RPU,
+   NODE_RPU_0,
+   NODE_RPU_1,
+   NODE_PLD,
+   NODE_FPD,
+   NODE_OCM_BANK_0,
+   NODE_OCM_BANK_1,
+   NODE_OCM_BANK_2,
+   NODE_OCM_BANK_3,
+   NODE_TCM_0_A,
+   NODE_TCM_0_B,
+   NODE_TCM_1_A,
+   NODE_TCM_1_B,
+   NODE_L2,
+   NODE_GPU_PP_0,
+   NODE_GPU_PP_1,
+   NODE_USB_0,
+   NODE_USB_1,
+   NODE_TTC_0,
+   NODE_TTC_1,
+   NODE_TTC_2,
+   NODE_TTC_3,
+   NODE_SATA,
+   NODE_ETH_0,
+   NODE_ETH_1,
+   NODE_ETH_2,
+   NODE_ETH_3,
+   NODE_UART_0,
+   NODE_UART_1,
+   NODE_SPI_0,
+   NODE_SPI_1,
+   NODE_I2C_0,
+   NODE_I2C_1,
+   NODE_SD_0,
+   NODE_SD_1,
+   NODE_DP,
+   NODE_GDMA,
+   NODE_ADMA,
+   NODE_NAND,
+   NODE_QSPI,
+   NODE_GPIO,
+   NODE_CAN_0,
+   NODE_CAN_1,
+   NODE_EXTERN,
+   NODE_APLL,
+   NODE_VPLL,
+   NODE_DPLL,
+   NODE_RPLL,
+   NODE_IOPLL,
+   NODE_DDR,
+   NODE_IPI_APU,
+   NODE_IPI_RPU_0,
+   NODE_GPU,
+   NODE_PCIE,
+   NODE_PCAP,
+   NODE_RTC,
+   NODE_LPD,
+   NODE_VCU,
+   NODE_IPI_RPU_1,
+   NODE_IPI_PL_0,
+   NODE_IPI_PL_1,
+   NODE_IPI_PL_2,
+   NODE_IPI_PL_3,
+   NODE_PL,
+   NODE_ID_MAX
+};
+
+/**
+ *  PM Reset Line IDs
+ */
+enum XPmReset {
+   XILPM_RESET_PCIE_CFG = 1000,
+   XILPM_RESET_PCIE_BRIDGE,
+   XILPM_RESET_PCIE_CTRL,
+   XILPM_RESET_DP,
+   XILPM_RESET_SWDT_CRF,
+   XILPM_RESET_AFI_FM5,
+   XILPM_RESET_AFI_FM4,
+   XILPM_RESET_AFI_FM3,
+   

[U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime

2019-03-21 Thread Luca Ceresoli
Optionally allow U-Boot to load at the PMU firmware configuration object
into the Power Management Unit (PMU) on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

 * 
https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
 * 
https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

The load is logged on the console during boot:

  U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
  Loading PMUFW cfg obj (2008 bytes)
  EL Level: EL3
  ...

Signed-off-by: Luca Ceresoli 

---

Changes RFC v1 -> RFC v2:
 - Load the cfg_obj in SPL, not U-Boot proper: this required a complete
   reimplementation since we cannot rely on ATF now
 - Update and refine the Kconfig option help

Todo:
 - don't compile pm_cfg_obj.c from source, load it from a binary file
---
 board/xilinx/zynqmp/Kconfig   |  26 
 board/xilinx/zynqmp/Makefile  |   5 ++
 board/xilinx/zynqmp/pmu_ipc.c | 116 ++
 board/xilinx/zynqmp/pmu_ipc.h |  14 
 board/xilinx/zynqmp/zynqmp.c  |  11 
 5 files changed, 172 insertions(+)
 create mode 100644 board/xilinx/zynqmp/pmu_ipc.c
 create mode 100644 board/xilinx/zynqmp/pmu_ipc.h

diff --git a/board/xilinx/zynqmp/Kconfig b/board/xilinx/zynqmp/Kconfig
index 7d1f7398c3e9..4201e38571e7 100644
--- a/board/xilinx/zynqmp/Kconfig
+++ b/board/xilinx/zynqmp/Kconfig
@@ -15,4 +15,30 @@ config CMD_ZYNQMP
  and authentication feature enabled while generating
  BOOT.BIN using Xilinx bootgen tool.
 
+config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+   string "PMU firmware configuration object to load at runtime"
+   help
+ Path to a PMU firmware configuration object to be built into
+ U-Boot and loaded at runtime by SPL into the PMU firmware.
+
+ The ZynqMP Power Management Unit (PMU) needs a configuration
+ object for most SoC peripherals to work. It can be either
+ hard-coded in the PMUFW or passed at runtime.
+
+ If the configuration object is not hard-coded in the PMU
+ firmware, U-Boot SPL can load it at runtime. To enable this
+ feature set here the file name (absolute path or relative to
+ board/xilinx/zynqmp/). It will be loaded into the PMU firmware by
+ U-Boot SPL during board initialization.
+
+ Note: if your pm_cfg_obj.c is generated by the Xilinx tools,
+ you must remove any linking directives from the
+ XPm_ConfigObject declaration! E.g.:
+
+   -const u32 XPm_ConfigObject[] __attribute__((used, 
section(".sys_cfg_data"))) = {
+   +const u32 XPm_ConfigObject[] = {
+
+ Leave this option empty if your PMU firmware has a hard-coded
+ configuration object or you are loading it by any other means.
+
 endif
diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
index 80f8ca7e1e4b..0d8f52ecd631 100644
--- a/board/xilinx/zynqmp/Makefile
+++ b/board/xilinx/zynqmp/Makefile
@@ -33,6 +33,11 @@ ifneq ($(call ifdef_any_of, CONFIG_ZYNQMP_PSU_INIT_ENABLED 
CONFIG_SPL_BUILD),)
 obj-y += $(init-objs)
 endif
 
+ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
+CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ -I$(srctree)/$(src)
+obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o
+endif
+
 obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
 
 ifndef CONFIG_SPL_BUILD
diff --git a/board/xilinx/zynqmp/pmu_ipc.c b/board/xilinx/zynqmp/pmu_ipc.c
new file mode 100644
index ..6306d33d6f17
--- /dev/null
+++ b/board/xilinx/zynqmp/pmu_ipc.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Inter-Processor Communication with the Platform Management Unit (PMU)
+ * firmware.
+ *
+ * (C) Copyright 2019 Luca Ceresoli
+ * Luca Ceresoli 
+ */
+
+#include "pmu_ipc.h"
+#include 
+#include 
+
+/* IPI bitmasks, register base and register offsets */
+#define IPI_BIT_MASK_APU  0x1
+#define IPI_BIT_MASK_PMU0 0x1
+#define IPI_REG_BASE_APU  0xFF30
+#define IPI_REG_BASE_PMU0 0xFF33
+#define IPI_REG_OFFSET_TRIG   0x00
+#define IPI_REG_OFFSET_OBR0x04
+
+/* IPI mailbox buffer offsets */
+#define IPI_BUF_BASE_APU   0xFF990400
+#define IPI_BUF_OFFSET_TARGET_PMU  0x1C0
+#define IPI_BUF_OFFSET_REQ 0x00
+#define IPI_BUF_OFFSET_RESP0x20
+
+/* Xilinx FSBL sets 8, ATF sets 6. Which one is correct? */
+#define 

[U-Boot] [PULL] u-boot-socfpga/master

2019-03-21 Thread Marek Vasut
The following changes since commit a00d15757d7a513e410f15f2f910cb5261a3:

  Merge git://git.denx.de/u-boot-marvell (2019-03-19 19:58:48 -0400)

are available in the Git repository at:

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

for you to fetch changes up to e3ada91e49848ddcd3293a737cf08e48b2d72e42:

  ARM: socfpga: Build sfp image only for Gen5 and Arria10 devices
(2019-03-21 03:31:01 +0100)


Dalon Westergreen (1):
  ARM: socfpga: Build sfp image only for Gen5 and Arria10 devices

 Kconfig  | 3 ++-
 scripts/Makefile.spl | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 00/11] SMP support for RISC-V

2019-03-21 Thread Troy Benjegerdes
On Sun, Mar 17, 2019 at 07:28:31PM +0100, Lukas Auer wrote:
> This patch series adds SMP support for RISC-V to U-Boot. It allows
> U-Boot to run on multi-hart systems (hart is the RISC-V terminology for
> hardware thread). Images passed to bootm will be started on all harts.
> The bootm command is currently the only one that will boot images on all
> harts, bootefi is not yet supported.
> 
> The patches have been successfully tested on both QEMU (machine and
> supervisor mode) and the HiFive Unleashed board (supervisor mode), using
> BBL and OpenSBI.

Can you describe the test configuration and boot flow a little more, or post an
SDcard image that boots with the switches as shown in the readme at [1]

I don't see any board-specific memory initialization code anywhere, so I assume
you are still using the original SiFive FSBL, and not the u-boot version that
includes the memory init code [2]

[1] https://github.com/sifive/freedom-u-sdk
[2] https://github.com/sifive/HiFive_U-Boot 

> Mainline QEMU requires two patches [1, 2] to run in this configuration.
> Patch [1] has been dropped and will be replaced with a U-Boot patch.
> 
> [1]: https://patchwork.ozlabs.org/patch/1039493/
> [2]: https://patchwork.ozlabs.org/patch/1039082/
> 
> Changes in v3:
> - Print error if riscv_send_ipi() fails
> - Adjust error message for failures of riscv_clear_ipi() to match error
> message for failures of riscv_send_ipi()
> - New patch to save the hart ID in register tp instead of s0
> - Adjust patch to use the new location of the hart ID (register tp)
> - New patch to hang if relocation of secondary harts fails
> 
> Changes in v2:
> - Remove unneeded quotes from NR_CPUS Kconfig entry
> - Move memory barrier from send_ipi_many() to handle_ipi()
> - Add check in send_ipi_many so that IPIs are only sent to available
> harts as indicated by the available_harts mask
> - Implement hart lottery to pick main hart to run U-Boot
> - Remove CONFIG_MAIN_HART as it is not required anymore
> - Register available harts in the available_harts mask
> - New patch to populate register a0 with the hart ID from the mhartid
> CSR in machine-mode
> - New patch to enable SMP on the SiFive FU540, which was previously sent
> independently
> 
> Lukas Auer (11):
>   riscv: add infrastructure for calling functions on other harts
>   riscv: import the supervisor binary interface header file
>   riscv: implement IPI platform functions using SBI
>   riscv: delay initialization of caches and debug UART
>   riscv: save hart ID in register tp instead of s0
>   riscv: add support for multi-hart systems
>   riscv: boot images passed to bootm on all harts
>   riscv: do not rely on hart ID passed by previous boot stage
>   riscv: hang if relocation of secondary harts fails
>   riscv: fu540: enable SMP
>   riscv: qemu: enable SMP
> 
>  arch/riscv/Kconfig   |  28 +
>  arch/riscv/cpu/cpu.c |   9 +-
>  arch/riscv/cpu/start.S   | 167 +--
>  arch/riscv/include/asm/csr.h |   1 +
>  arch/riscv/include/asm/global_data.h |   6 +
>  arch/riscv/include/asm/sbi.h |  94 +++
>  arch/riscv/include/asm/smp.h |  53 +
>  arch/riscv/lib/Makefile  |   2 +
>  arch/riscv/lib/asm-offsets.c |   1 +
>  arch/riscv/lib/bootm.c   |  13 ++-
>  arch/riscv/lib/sbi_ipi.c |  25 
>  arch/riscv/lib/smp.c | 118 +++
>  board/emulation/qemu-riscv/Kconfig   |   1 +
>  board/sifive/fu540/Kconfig   |   1 +
>  14 files changed, 507 insertions(+), 12 deletions(-)
>  create mode 100644 arch/riscv/include/asm/sbi.h
>  create mode 100644 arch/riscv/include/asm/smp.h
>  create mode 100644 arch/riscv/lib/sbi_ipi.c
>  create mode 100644 arch/riscv/lib/smp.c
> 
> -- 
> 2.20.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Laurentiu Tudor

On 21.03.2019 17:10, Horia Geanta wrote:
> On 3/21/2019 2:42 PM, Tudor Laurentiu-B10716 wrote:
>> Hi Horia,
>>
>> On 21.03.2019 12:36, Horia Geanta wrote:
>>> On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
#define SET_SEC_QI_ICID(streamid) \
 -  SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
 +  SET_ICID_ENTRY("fsl,sec-v4.0", SEC_ICID_REG_VAL(streamid), \
>>> Is this a fix for LS104x? Then it should be a separate patch.
>>
>> Not really. I added an intermediate macro, SEC_ICID_REG_VAL(streamid)
>> that forms the correct register value starting from ICID, depending on
>> the chip version (the register layouts are different between the two).
>>
> This is the define
> #define SEC_ICID_REG_VAL(streamid) (((streamid) << 16) | (streamid))
> 
> Thus the QI ICID for LS104x changes.

Ah, alright. Good point. I checked in the manuals and this unintended 
change does indeed fix this register setup. I'm leaning towards 
mentioning this collateral fix in the commit message.

 +#else /* CONFIG_FSL_LSCH2 */
>>> [...]
 +#define SEC_ICID_REG_VAL(streamid) ((streamid) << 24)
>>> ICID is in lower 6:0 bits, not in 31:24.
>>
>> That was also my initial impression but it didn't work (smmu global
>> faults with icid 0). Probably there's an ambiguity related to endianness
>> in the documentation.
>>
> Note that on DPAA 2.x both the core and device (CAAM) are little endian.
> Probably the problem is with the I/O accessors writing the CAAM registers.
> 
> Instead of out_be32() use either sec_out32() (but this means splitting
> CAAM-specific code) or out_le32().
> 
> CAAM endianness can be detected using CONFIG_SYS_FSL_SEC_LE / 
> CONFIG_SYS_FSL_SEC_BE.
> 

Thanks for the explanation. I think I can change the macros to take into 
consideration the CONFIG_*s you pointed.

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


Re: [U-Boot] [PATCH 00/11] Fix Ethernet boot in am335x

2019-03-21 Thread Andrew F. Davis
On 3/21/19 10:22 AM, Andrew F. Davis wrote:
> On 3/18/19 3:24 AM, Faiz Abbas wrote:
>> The following patches fix ethernet boot in am335x.
>>
>> Enabling OF_CONTROL in SPL makes it overflow the sram size. To avoid
> 
> If you are overflowing SRAM on the non-HS devices you are even more
> constrained on HS, you don't need an HS to test, just build for
> am335x_hs_evm_defconfig and it should break build if you out of space.
> 

Oh, and if build complains about not having SECDEV tools use this:
https://github.com/glneo/dummy-secdev

Andrew

> Thanks,
> Andrew
> 
>> this, I am using static platdata in the am335x board file instead of
>> the fdtdec_*() calls used in ofdata_to_platdata().
>>
>> Patches 1-5 isolate the two operations of getting platform data (all of
>> which should happen in _ofdata_to_platdata()) and initial configurations
>> (all of which should happen in _probe()).
>>
>> Patch 6 makes sure the cpsw driver gets probed in SPL.
>> Patch 7 adds static platdata to the am335 board file.
>> Patches 8-10 makes changes in the config to make space for and enable
>> ETH_SUPPORT in SPL.
>> Patch 11 removes non-DM_ETH code from the am335x board file.
>>
>> Tested ethernet boot and tftp in am335x-evm. Regression tested on dra71x-evm.
>>
>> Faiz Abbas (11):
>>   net: Add priv_pdata to eth_pdata
>>   net: ti: cpsw: Move cpsw_phy_sel() to _probe()
>>   net: ti: cpsw: Convert cpsw_platform_data to a pointer in cpsw_priv
>>   net: ti: cpsw-common: Isolate getting syscon address from assigning
>> macid
>>   net: ti: cpsw: Block off ofdata_to_platdata with OF_CONTROL
>>   net: ti: cpsw: Enable DM_FLAG_PRE_RELOC
>>   board: ti: am335x: Add platdata for cpsw in SPL
>>   configs: am335x_evm: Reduce size of SPL
>>   configs: am335x_evm: Add Support for SPL_ETH
>>   configs: am335x_evm: Update VCI String
>>   board: ti: am335x: Remove non DM_ETH code
>>
>>  board/ti/am335x/board.c  | 170 ++---
>>  configs/am335x_evm_defconfig |   8 +-
>>  drivers/net/ti/cpsw-common.c | 127 ++
>>  drivers/net/ti/cpsw.c| 202 ---
>>  include/cpsw.h   |  25 -
>>  include/net.h|   2 +
>>  6 files changed, 217 insertions(+), 317 deletions(-)
>>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 00/11] Fix Ethernet boot in am335x

2019-03-21 Thread Andrew F. Davis
On 3/18/19 3:24 AM, Faiz Abbas wrote:
> The following patches fix ethernet boot in am335x.
> 
> Enabling OF_CONTROL in SPL makes it overflow the sram size. To avoid

If you are overflowing SRAM on the non-HS devices you are even more
constrained on HS, you don't need an HS to test, just build for
am335x_hs_evm_defconfig and it should break build if you out of space.

Thanks,
Andrew

> this, I am using static platdata in the am335x board file instead of
> the fdtdec_*() calls used in ofdata_to_platdata().
> 
> Patches 1-5 isolate the two operations of getting platform data (all of
> which should happen in _ofdata_to_platdata()) and initial configurations
> (all of which should happen in _probe()).
> 
> Patch 6 makes sure the cpsw driver gets probed in SPL.
> Patch 7 adds static platdata to the am335 board file.
> Patches 8-10 makes changes in the config to make space for and enable
> ETH_SUPPORT in SPL.
> Patch 11 removes non-DM_ETH code from the am335x board file.
> 
> Tested ethernet boot and tftp in am335x-evm. Regression tested on dra71x-evm.
> 
> Faiz Abbas (11):
>   net: Add priv_pdata to eth_pdata
>   net: ti: cpsw: Move cpsw_phy_sel() to _probe()
>   net: ti: cpsw: Convert cpsw_platform_data to a pointer in cpsw_priv
>   net: ti: cpsw-common: Isolate getting syscon address from assigning
> macid
>   net: ti: cpsw: Block off ofdata_to_platdata with OF_CONTROL
>   net: ti: cpsw: Enable DM_FLAG_PRE_RELOC
>   board: ti: am335x: Add platdata for cpsw in SPL
>   configs: am335x_evm: Reduce size of SPL
>   configs: am335x_evm: Add Support for SPL_ETH
>   configs: am335x_evm: Update VCI String
>   board: ti: am335x: Remove non DM_ETH code
> 
>  board/ti/am335x/board.c  | 170 ++---
>  configs/am335x_evm_defconfig |   8 +-
>  drivers/net/ti/cpsw-common.c | 127 ++
>  drivers/net/ti/cpsw.c| 202 ---
>  include/cpsw.h   |  25 -
>  include/net.h|   2 +
>  6 files changed, 217 insertions(+), 317 deletions(-)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Horia Geanta
On 3/21/2019 2:42 PM, Tudor Laurentiu-B10716 wrote:
> Hi Horia,
> 
> On 21.03.2019 12:36, Horia Geanta wrote:
>> On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
>>>   #define SET_SEC_QI_ICID(streamid) \
>>> -   SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
>>> +   SET_ICID_ENTRY("fsl,sec-v4.0", SEC_ICID_REG_VAL(streamid), \
>> Is this a fix for LS104x? Then it should be a separate patch.
> 
> Not really. I added an intermediate macro, SEC_ICID_REG_VAL(streamid) 
> that forms the correct register value starting from ICID, depending on 
> the chip version (the register layouts are different between the two).
> 
This is the define
#define SEC_ICID_REG_VAL(streamid) (((streamid) << 16) | (streamid))

Thus the QI ICID for LS104x changes.

>>> +#else /* CONFIG_FSL_LSCH2 */
>> [...]
>>> +#define SEC_ICID_REG_VAL(streamid) ((streamid) << 24)
>> ICID is in lower 6:0 bits, not in 31:24.
> 
> That was also my initial impression but it didn't work (smmu global 
> faults with icid 0). Probably there's an ambiguity related to endianness 
> in the documentation.
> 
Note that on DPAA 2.x both the core and device (CAAM) are little endian.
Probably the problem is with the I/O accessors writing the CAAM registers.

Instead of out_be32() use either sec_out32() (but this means splitting
CAAM-specific code) or out_le32().

CAAM endianness can be detected using CONFIG_SYS_FSL_SEC_LE / 
CONFIG_SYS_FSL_SEC_BE.

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


[U-Boot] [PATCH] pico-imx6ul: Fix eMMC boot after DM_MMC conversion

2019-03-21 Thread Fabio Estevam
After the DM_MMC conversion the following eMMC boot error is observed:

U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 18:53:28 +)
Trying to boot from MMC1
MMC Device 0 not found
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

This happens because the SPL code does not initialize the SDHC pins
and clock.

Fix it by moving the original eMMC initialization from U-Boot proper
to SPL.

Reported-by: Otavio Salvador 
Signed-off-by: Fabio Estevam 
Tested-by: Fabio Berton 
Reviewed-by: Otavio Salvador 
---
 board/technexion/pico-imx6ul/spl.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/board/technexion/pico-imx6ul/spl.c 
b/board/technexion/pico-imx6ul/spl.c
index 6464a32d3b..f972cc9eaf 100644
--- a/board/technexion/pico-imx6ul/spl.c
+++ b/board/technexion/pico-imx6ul/spl.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -141,4 +142,37 @@ void board_init_f(ulong dummy)
 void reset_cpu(ulong addr)
 {
 }
+
+#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
+   PAD_CTL_PUS_22K_UP  | PAD_CTL_SPEED_LOW |   \
+   PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
+
+static iomux_v3_cfg_t const usdhc1_pads[] = {
+   MX6_PAD_SD1_CLK__USDHC1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD1_CMD__USDHC1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD1_DATA0__USDHC1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD1_DATA1__USDHC1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD1_DATA2__USDHC1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_SD1_DATA3__USDHC1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_NAND_READY_B__USDHC1_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_NAND_CE0_B__USDHC1_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_NAND_CE1_B__USDHC1_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX6_PAD_NAND_CLE__USDHC1_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
+static struct fsl_esdhc_cfg usdhc_cfg[1] = {
+   {USDHC1_BASE_ADDR},
+};
+
+int board_mmc_getcd(struct mmc *mmc)
+{
+   return 1;
+}
+
+int board_mmc_init(bd_t *bis)
+{
+   imx_iomux_v3_setup_multiple_pads(usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
+   usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+   return fsl_esdhc_initialize(bis, _cfg[0]);
+}
 #endif
-- 
2.17.1

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


[U-Boot] [PATCH 8/8] bcm963158: enable led support

2019-03-21 Thread Philippe Reynes
Enable the led support in the configuration
of the board bcm963158.

Signed-off-by: Philippe Reynes 
---
 configs/bcm963158_ram_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig
index fc55e98..c93a8f6 100644
--- a/configs/bcm963158_ram_defconfig
+++ b/configs/bcm963158_ram_defconfig
@@ -28,6 +28,9 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm963158"
 # CONFIG_NET is not set
 CONFIG_BLK=y
 CONFIG_CLK=y
+CONFIG_LED=y
+CONFIG_LED_BCM6858=y
+CONFIG_LED_BLINK=y
 # CONFIG_MMC is not set
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 # CONFIG_SPL_SERIAL_PRESENT is not set
-- 
2.7.4

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


[U-Boot] [PATCH 5/8] led: bcm6858: allow to use this driver on ARCH_963158

2019-03-21 Thread Philippe Reynes
Allow the led bcm6858 driver to be used on bcm63158.
They have the same led controller.

Signed-off-by: Philippe Reynes 
---
 drivers/led/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 4c8582d..5643939 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -30,7 +30,7 @@ config LED_BCM6358
 
 config LED_BCM6858
bool "LED Support for BCM6858"
-   depends on LED && ARCH_BCM6858
+   depends on LED && (ARCH_BCM6858 || ARCH_BCM63158)
help
  This option enables support for LEDs connected to the BCM6858
  HW has blinking capabilities and up to 32 LEDs can be controlled.
-- 
2.7.4

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


[U-Boot] [PATCH 3/8] dt: bcm968580xref: enable led controller

2019-03-21 Thread Philippe Reynes
Enable the led controller in the device tree
of the board bcm968580xref.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm968580xref.dts | 48 ++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/dts/bcm968580xref.dts b/arch/arm/dts/bcm968580xref.dts
index 0c59f94..c11246a 100644
--- a/arch/arm/dts/bcm968580xref.dts
+++ b/arch/arm/dts/bcm968580xref.dts
@@ -29,3 +29,51 @@
u-boot,dm-pre-reloc;
status = "okay";
 };
+
+ {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,serial-led-en-pol;
+   brcm,serial-led-data-ppol;
+
+   led@2 {
+   reg = <2>;
+   label = "green:inet";
+   };
+
+   led@5 {
+   reg = <5>;
+   label = "red:alarm";
+   };
+
+   led@8 {
+   reg = <8>;
+   label = "green:wlan_link";
+   };
+
+   led@11 {
+   reg = <11>;
+   label = "green:fxs1";
+   };
+
+   led@14 {
+   reg = <14>;
+   label = "green:fxs2";
+   };
+
+   led@15 {
+   reg = <15>;
+   label = "green:usb0";
+   };
+
+   led@16 {
+   reg = <16>;
+   label = "green:usb1";
+   };
+
+   led@17 {
+   reg = <17>;
+   label = "green:wps";
+   };
+};
-- 
2.7.4

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


[U-Boot] [PATCH 6/8] dt: bcm63158: add led controller

2019-03-21 Thread Philippe Reynes
Add the led controller in the bcm63158 device tree.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm63158.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/bcm63158.dtsi b/arch/arm/dts/bcm63158.dtsi
index 6a3fbc9..0967a3d 100644
--- a/arch/arm/dts/bcm63158.dtsi
+++ b/arch/arm/dts/bcm63158.dtsi
@@ -82,6 +82,13 @@
status = "disabled";
};
 
+   leds: led-controller@ff800800 {
+   compatible = "brcm,bcm6858-leds";
+   reg = <0x0 0xff800800 0x0 0xe4>;
+
+   status = "disabled";
+   };
+
wdt1: watchdog@ff800480 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff800480 0x0 0x14>;
-- 
2.7.4

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


[U-Boot] [PATCH 4/8] bcm968580xref: enable led support

2019-03-21 Thread Philippe Reynes
Enable the led support in the configuration
of the board bcm968580xref.

Signed-off-by: Philippe Reynes 
---
 configs/bcm968580xref_ram_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/bcm968580xref_ram_defconfig 
b/configs/bcm968580xref_ram_defconfig
index e8cb3a0..887ccb8 100644
--- a/configs/bcm968580xref_ram_defconfig
+++ b/configs/bcm968580xref_ram_defconfig
@@ -22,6 +22,9 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm968580xref"
 # CONFIG_NET is not set
 CONFIG_BLK=y
 CONFIG_CLK=y
+CONFIG_LED=y
+CONFIG_LED_BCM6858=y
+CONFIG_LED_BLINK=y
 # CONFIG_MMC is not set
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 # CONFIG_SPL_SERIAL_PRESENT is not set
-- 
2.7.4

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


[U-Boot] [PATCH 7/8] dt: bcm963158: enable led controller

2019-03-21 Thread Philippe Reynes
Enable the led controller in the device tree
of the board bcm963158.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm963158.dts | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/dts/bcm963158.dts b/arch/arm/dts/bcm963158.dts
index dc5afb5..15e87de 100644
--- a/arch/arm/dts/bcm963158.dts
+++ b/arch/arm/dts/bcm963158.dts
@@ -29,3 +29,52 @@
u-boot,dm-pre-reloc;
status = "okay";
 };
+
+ {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,serial-led-en-pol;
+   brcm,serial-led-data-ppol;
+
+   led@16 {
+   reg = <16>;
+   label = "red:dsl2";
+   };
+
+   led@17 {
+   reg = <17>;
+   label = "green:dsl1";
+   };
+
+   led@18 {
+   reg = <18>;
+   label = "green:fxs2";
+   };
+
+   led@19 {
+   reg = <19>;
+   label = "green:fxs1";
+   };
+
+   led@26 {
+   reg = <26>;
+   label = "green:wan1_act";
+   };
+
+   led@27 {
+   reg = <27>;
+   label = "green:wps";
+   };
+
+   led@28 {
+   reg = <28>;
+   active-low;
+   label = "green:aggregate_act";
+   };
+
+   led@29 {
+   reg = <29>;
+   label = "green:aggregate_link";
+   };
+};
-- 
2.7.4

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


[U-Boot] [PATCH 1/8] led: add initial support for bcm6858

2019-03-21 Thread Philippe Reynes
The driver add the support of the led IP on bcm6858.
This led IP can drive up to 32 leds, and can handle
blinking.

Signed-off-by: Philippe Reynes 
---
 doc/device-tree-bindings/leds/leds-bcm6858.txt |  51 +
 drivers/led/Kconfig|   7 +
 drivers/led/Makefile   |   1 +
 drivers/led/led_bcm6858.c  | 248 +
 4 files changed, 307 insertions(+)
 create mode 100644 doc/device-tree-bindings/leds/leds-bcm6858.txt
 create mode 100644 drivers/led/led_bcm6858.c

diff --git a/doc/device-tree-bindings/leds/leds-bcm6858.txt 
b/doc/device-tree-bindings/leds/leds-bcm6858.txt
new file mode 100644
index 000..ea2fe23
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-bcm6858.txt
@@ -0,0 +1,51 @@
+LEDs connected to Broadcom BCM6858 controller
+
+This controller is present on BCM6858, BCM6328, BCM6362 and BCM63268.
+In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
+
+Required properties:
+  - compatible : should be "brcm,bcm6858-leds".
+  - #address-cells : must be 1.
+  - #size-cells : must be 0.
+  - reg : BCM6858 LED controller address and size.
+
+Optional properties:
+  - brcm,serial-led-msb-first : Boolean, msb data come out first on serial 
data pin
+Default : false
+  - brcm,serial-led-en-pol : Boolean, serial led polarity (true => active high)
+Default : false
+  - brcm,serial-led-clk-pol : Boolean, serial clock polarity (true => active 
high)
+Default : false
+  - brcm,serial-led-data-ppol : Boolean, serial data polarity (true => active 
high)
+Default : false
+  - brcm,serial-shift-inv : Boolean, led test mode
+Default : false
+
+Each LED is represented as a sub-node of the brcm,bcm6858-leds device.
+
+LED sub-node required properties:
+  - reg : LED pin number (only LEDs 0 to 32 are valid).
+
+LED sub-node optional properties:
+  - label : see Documentation/devicetree/bindings/leds/common.txt
+  - active-low : Boolean, makes LED active low.
+Default : false
+
+Examples:
+BCM6328 with 2 GPIO LEDs
+   leds0: led-controller@ff800800 {
+   compatible = "brcm,bcm6858-leds";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0xff800800 0x0 0xe4>;
+
+   led@2 {
+   reg = <2>;
+   label = "green:inet";
+   };
+
+   led@5 {
+   reg = <5>;
+   label = "red:alarm";
+   };
+   };
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 5da5c4a..4c8582d 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -28,6 +28,13 @@ config LED_BCM6358
  LED HW controller accessed via MMIO registers.
  HW has no blinking capabilities and up to 32 LEDs can be controlled.
 
+config LED_BCM6858
+   bool "LED Support for BCM6858"
+   depends on LED && ARCH_BCM6858
+   help
+ This option enables support for LEDs connected to the BCM6858
+ HW has blinking capabilities and up to 32 LEDs can be controlled.
+
 config LED_BLINK
bool "Support LED blinking"
depends on LED
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 160a8f3..3654dd3 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -6,4 +6,5 @@
 obj-y += led-uclass.o
 obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
 obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
+obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
 obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
diff --git a/drivers/led/led_bcm6858.c b/drivers/led/led_bcm6858.c
new file mode 100644
index 000..c0f9b90
--- /dev/null
+++ b/drivers/led/led_bcm6858.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Philippe Reynes 
+ *
+ * based on:
+ * drivers/led/led_bcm6328.c
+ * drivers/led/led_bcm6358.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LEDS_MAX   32
+#define LEDS_WAIT  100
+
+/* LED Mode register */
+#define LED_MODE_REG   0x0
+#define LED_MODE_OFF   0
+#define LED_MODE_ON1
+#define LED_MODE_MASK  1
+
+/* LED Controller Global settings register */
+#define LED_CTRL_REG   0x00
+#define LED_CTRL_MASK  0x1f
+#define LED_CTRL_LED_TEST_MODE BIT(0)
+#define LED_CTRL_SERIAL_LED_DATA_PPOL  BIT(1)
+#define LED_CTRL_SERIAL_LED_CLK_POLBIT(2)
+#define LED_CTRL_SERIAL_LED_EN_POL BIT(3)
+#define LED_CTRL_SERIAL_LED_MSB_FIRST  BIT(4)
+
+/* LED Controller IP LED source select register */
+#define LED_HW_LED_EN_REG  0x08
+/* LED Flash control register0 */
+#define LED_FLASH_RATE_CONTROL_REG00x10
+/* Soft LED input register */
+#define LED_SW_LED_IP_REG  0xb8
+/* Soft LED input polarity register */
+#define LED_SW_LED_IP_PPOL_REG 0xbc
+
+struct bcm6858_led_priv {
+   void __iomem *regs;
+   u8 pin;
+};
+

[U-Boot] [PATCH 2/8] dt: bcm6858: add led controller

2019-03-21 Thread Philippe Reynes
Add the led controller in the bcm6858 device tree.

Signed-off-by: Philippe Reynes 
---
 arch/arm/dts/bcm6858.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
index 23b80c6..0359417 100644
--- a/arch/arm/dts/bcm6858.dtsi
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -82,6 +82,13 @@
status = "disabled";
};
 
+   leds: led-controller@ff800800 {
+   compatible = "brcm,bcm6858-leds";
+   reg = <0x0 0xff800800 0x0 0xe4>;
+
+   status = "disabled";
+   };
+
wdt1: watchdog@ff802780 {
compatible = "brcm,bcm6345-wdt";
reg = <0x0 0xff802780 0x0 0x14>;
-- 
2.7.4

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


[U-Boot] Please pull from u-boot-i2c

2019-03-21 Thread Heiko Schocher

Hello Tom,

please pull from u-boot-i2c.git master

The following changes since commit 2e8092d94f40a5692baf3ec768ce3216a7bf032a:

  Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 15:48:57 
-0400)

are available in the Git repository at:

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

for you to fetch changes up to 9d59d6fff67da170873aaff66ff1a75514e54d29:

  i2c: i2c_cdns: Fix below warnings with checker tool (2019-03-21 08:21:43 
+0100)


Siva Durga Prasad Paladugu (1):
  i2c: i2c_cdns: Fix below warnings with checker tool

 drivers/i2c/i2c-cdns.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

Travis builds fine:

https://travis-ci.org/hsdenx/u-boot-i2c/builds/509299647

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


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Laurentiu Tudor
Hi Horia,

On 21.03.2019 12:36, Horia Geanta wrote:
> On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
>> +struct icid_id_table icid_tbl[] = {
>> +SET_SDHC_ICID(FSL_SDMMC_STREAM_ID),
>> +SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
>> +SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
>> +SET_SATA_ICID(1, "fsl,ls1088a-ahci", FSL_SATA1_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +};
> A single ICID is allocated to all SEC sub-blocks able to initiate 
> transactions.
> I think at least the job rings should have different ICIDs, while the rest 
> could
> share another ICID.

Actually let me take back my statement on the scarcity of the ICIDs. I 
just noticed that in the allocation of the ICIDs we actually use just 64 
[1] out of the total 128 available. I don't know why we do that, perhaps 
it a legacy left over but anyway I've tested SEC with ICIDs > 63 and 
tests passed.
In conclusion I'll update the ICID allocation for SEC in the following spin.

[1] 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h;h=e017d8b55895ba79328dd9281458e35a99b5900a;hb=HEAD#l99

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


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Laurentiu Tudor
Hi Horia,

On 21.03.2019 12:36, Horia Geanta wrote:
> On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
>> +struct icid_id_table icid_tbl[] = {
>> +SET_SDHC_ICID(FSL_SDMMC_STREAM_ID),
>> +SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
>> +SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
>> +SET_SATA_ICID(1, "fsl,ls1088a-ahci", FSL_SATA1_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +};
> A single ICID is allocated to all SEC sub-blocks able to initiate 
> transactions.
> I think at least the job rings should have different ICIDs, while the rest 
> could
> share another ICID.

I agree here, problem is that on these chips ICIDs are scarce resource 
because DPAA2 gets a big chunk of them. I'd suggest to leave them like 
that and, if a user needs distinct, per JR ICIDs (s)he can easily tune them.

>>   #define SET_SEC_QI_ICID(streamid) \
>> -SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
>> +SET_ICID_ENTRY("fsl,sec-v4.0", SEC_ICID_REG_VAL(streamid), \
> Is this a fix for LS104x? Then it should be a separate patch.

Not really. I added an intermediate macro, SEC_ICID_REG_VAL(streamid) 
that forms the correct register value starting from ICID, depending on 
the chip version (the register layouts are different between the two).

>> +#else /* CONFIG_FSL_LSCH2 */
> [...]
>> +#define SEC_ICID_REG_VAL(streamid) ((streamid) << 24)
> ICID is in lower 6:0 bits, not in 31:24.

That was also my initial impression but it didn't work (smmu global 
faults with icid 0). Probably there's an ambiguity related to endianness 
in the documentation.

>> +#endif /* !CONFIG_FSL_LSCH2 */
> Nitpick: comment for #endif should match #if condition, which is 
> CONFIG_FSL_LSCH2.
> 

Ok.

Thanks for the review!

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


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Laurentiu Tudor
Hi Horia,

On 21.03.2019 12:36, Horia Geanta wrote:
> On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
>> +struct icid_id_table icid_tbl[] = {
>> +SET_SDHC_ICID(FSL_SDMMC_STREAM_ID),
>> +SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
>> +SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
>> +SET_SATA_ICID(1, "fsl,ls1088a-ahci", FSL_SATA1_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
>> +SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
>> +};
> A single ICID is allocated to all SEC sub-blocks able to initiate 
> transactions.
> I think at least the job rings should have different ICIDs, while the rest 
> could
> share another ICID.

I agree here, problem is that on these chips ICIDs are scarce resource 
because DPAA2 gets a big chunk of them. I'd suggest to leave them like 
that and, if a user needs distinct, per JR ICIDs (s)he can easily tune them.

>>   #define SET_SEC_QI_ICID(streamid) \
>> -SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
>> +SET_ICID_ENTRY("fsl,sec-v4.0", SEC_ICID_REG_VAL(streamid), \
> Is this a fix for LS104x? Then it should be a separate patch.

Not really. I added an intermediate macro, SEC_ICID_REG_VAL(streamid) 
that forms the correct register value starting from ICID, depending on 
the chip version (the register layouts are different between the two).

>> +#else /* CONFIG_FSL_LSCH2 */
> [...]
>> +#define SEC_ICID_REG_VAL(streamid) ((streamid) << 24)
> ICID is in lower 6:0 bits, not in 31:24.

That was also my initial impression but it didn't work (smmu global 
faults with icid 0). Probably there's an ambiguity related to endianness 
in the documentation.

>> +#endif /* !CONFIG_FSL_LSCH2 */
> Nitpick: comment for #endif should match #if condition, which is 
> CONFIG_FSL_LSCH2.
> 

Ok.

Thanks for the review!

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


Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: imply/default common config options

2019-03-21 Thread Simon Goldschmidt
Hi,

On Thu, Mar 21, 2019 at 5:29 AM Masahiro Yamada
 wrote:
>
> Hi Simon,
>
> Sorry, I completely missed this thread.

No problem, this is not a too pressing issue, yet, since it's for the
next merge window :-)

>
> On Wed, Mar 20, 2019 at 7:40 PM Simon Goldschmidt
>  wrote:
> >
> > Hi Mrek,
> >
> > Am 15.03.2019 um 21:34 schrieb Simon Goldschmidt:
> > > Am 05.03.2019 um 21:58 schrieb Marek Vasut:
> > >> On 3/5/19 9:28 PM, Simon Goldschmidt wrote:
> > >>> Am 04.03.2019 um 22:34 schrieb Marek Vasut:
> >  On 3/4/19 10:23 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 4.
> > > März 2019, 22:19:
> > >
> > >On 3/4/19 9:53 PM, Simon Goldschmidt wrote:
> > >> This commit moves common config options used in all socfpga
> > > boards
> > >> to select/imply in Kconfig. This both cleans up the defconfig
> > > files
> > >> as well as makes future changes easier.
> > >>
> > >> Options implied/defaulted for all sub-arches:
> > >> - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS
> > >>
> > >> Options implied/defaulted for implied for A10 & gen5:
> > >> - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE
> > >>
> > >> Options implied/defaulted for A10:
> > >> - SPL_SYS_MALLOC_F_LEN
> > >>
> > >> Options implied/defaulted for gen5:
> > >> - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR
> > >>
> > >> Signed-off-by: Simon Goldschmidt 
> > >  > >>
> > >> ---
> > >>
> > >> Changes in v2:
> > >> - added patch to imply/default common config options
> > >>
> > >>  arch/arm/Kconfig   |  3 +++
> > >>  arch/arm/mach-socfpga/Kconfig  | 21
> > > +
> > >>  configs/socfpga_arria10_defconfig  |  8 
> > >>  configs/socfpga_arria5_defconfig   | 10 --
> > >>  configs/socfpga_cyclone5_defconfig | 10 --
> > >>  configs/socfpga_dbm_soc1_defconfig | 10 --
> > >>  configs/socfpga_de0_nano_soc_defconfig | 10 --
> > >>  configs/socfpga_de10_nano_defconfig| 10 --
> > >>  configs/socfpga_de1_soc_defconfig  | 10 --
> > >>  configs/socfpga_is1_defconfig  |  8 
> > >>  configs/socfpga_sockit_defconfig   | 10 --
> > >>  configs/socfpga_socrates_defconfig | 10 --
> > >>  configs/socfpga_sr1500_defconfig   | 10 --
> > >>  configs/socfpga_stratix10_defconfig|  4 
> > >>  configs/socfpga_vining_fpga_defconfig  | 10 --
> > >>  15 files changed, 24 insertions(+), 120 deletions(-)
> > >>
> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >> index ded7c11a4c..71bb14acce 100644
> > >> --- a/arch/arm/Kconfig
> > >> +++ b/arch/arm/Kconfig
> > >> @@ -839,12 +839,15 @@ config ARCH_SOCFPGA
> > >>   imply DM_SPI
> > >>   imply DM_SPI_FLASH
> > >>   imply FAT_WRITE
> > >> + imply SPL
> > >> + imply SPL_DM
> > >>   imply SPL_LIBDISK_SUPPORT
> > >>   imply SPL_MMC_SUPPORT
> > >>   imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> > >>   imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> > >>   imply SPL_SPI_FLASH_SUPPORT
> > >>   imply SPL_SPI_SUPPORT
> > >> + imply USE_TINY_PRINTF
> > >>
> > >>  config ARCH_SUNXI
> > >>   bool "Support sunxi (Allwinner) SoCs"
> > >> diff --git a/arch/arm/mach-socfpga/Kconfig
> > >b/arch/arm/mach-socfpga/Kconfig
> > >> index 5e87371f8c..da801eb660 100644
> > >> --- a/arch/arm/mach-socfpga/Kconfig
> > >> +++ b/arch/arm/mach-socfpga/Kconfig
> > >> @@ -1,8 +1,25 @@
> > >>  if ARCH_SOCFPGA
> > >>
> > >> +config NR_DRAM_BANKS
> > >> + default 1
> > >> +
> > >> +config SPL_STACK_R_ADDR
> > >> + default 0x0080 if TARGET_SOCFPGA_GEN5
> > >> +
> > >> +config SPL_SYS_MALLOC_F_LEN
> > >> + default 0x1 if TARGET_SOCFPGA_ARRIA10
> > >> +
> > >
> > >This is already defined in /Kconfig, won't you end up with
> > >duplicate/redefined symbols this way ?
> > >
> > >
> > > I did not get errors. I 

Re: [U-Boot] [PATCH v2 0/6] Update Stratix 10 SDRAM driver

2019-03-21 Thread Marek Vasut
On 3/21/19 6:23 PM, Ley Foon Tan wrote:
> This patchset update Stratix 10 SDRAM driver to support:
> - Multi-banks memory
>   - Stratix 10 support up to 2 memory banks:
>   Bank 0: Address 0, size 2GB
>   Bank 1: Address 0x1, size 124GB
> - Add warm reset boot checking function (Patch[5])
> - Add ECC memory scrubbing support (Patch [6])
>   - Use cache enabled + "DC ZVA" instruction to clear memory to zeros
> 
> v1 -> v2:
> -
> - Decode memory bank configuration from device tree
> - Use asm volatile() and "memory" clobber
> 
> History:
> 
> v1: https://patchwork.ozlabs.org/cover/1055134/
> 
> Ley Foon Tan (6):
>   ddr: altera: stratix10: Move SDRAM size check to SDRAM driver
>   ddr: altera: Stratix10: Add multi-banks DRAM size check
>   configs: stratix10: Change CONFIG_NR_DRAM_BANKS to 2
>   arm: dts: Stratix10: Modify stratix10 socdk memory node
>   arm: socfpga: stratix10: Add cpu_has_been_warmreset()
>   ddr: altera: Stratix10: Add ECC memory scrubbing
> 
>  arch/arm/dts/socfpga_stratix10_socdk.dts  |   4 +-
>  .../include/mach/reset_manager_s10.h  |   3 +
>  .../arm/mach-socfpga/include/mach/sdram_s10.h |   9 ++
>  arch/arm/mach-socfpga/reset_manager_s10.c |   9 ++
>  arch/arm/mach-socfpga/spl_s10.c   |  11 --
>  configs/socfpga_stratix10_defconfig   |   2 +-
>  drivers/ddr/altera/sdram_s10.c| 136 +-
>  7 files changed, 159 insertions(+), 15 deletions(-)
> 
Applied all to socfpga/next, thanks

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


Re: [U-Boot] [PATCH 06/11] arm: at91: Enable watchdog support

2019-03-21 Thread Eugen.Hristev


On 21.03.2019 14:00, Stefan Roese wrote:
> External E-Mail
> 
> 
> On 21.03.19 11:23, eugen.hris...@microchip.com wrote:
>>
>>
>> On 19.03.2019 17:56, Stefan Roese wrote:
>>> External E-Mail
>>>
>>>
>>> This patch enables and starts the watchdog on the AT91 platform if
>>> configured. Currently the WD timeout is configured to 16 seconds,
>>> which is the longest value for this timer.
>>>
>>> Signed-off-by: Stefan Roese 
>>> Cc: Heiko Schocher 
>>> Cc: Andreas Bießmann 
>>> Cc: Eugen Hristev 
>>> ---
>>>    arch/arm/mach-at91/clock.c | 41 
>>> ++
>>>    1 file changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
>>> index 64cbc3d1ed..2d442d0092 100644
>>> --- a/arch/arm/mach-at91/clock.c
>>> +++ b/arch/arm/mach-at91/clock.c
>>> @@ -5,6 +5,8 @@
>>>     */
>>>    #include 
>>> +#include 
>>> +#include 
>>>    #include 
>>>    #include 
>>>    #include 
>>> @@ -118,3 +120,42 @@ void at91_pllicpr_init(u32 icpr)
>>>    writel(icpr, >pllicpr);
>>>    }
>>> +
>>> +#if defined(CONFIG_WATCHDOG) && !defined(CONFIG_SPL_BUILD)
>>
>> Hi Stefan,
>>
>> Does this mean that for CONFIG_SPL_BUILD, this functions won't exist,
>> thus the SPL cannot use the watchdog ?
>>
>> For example, configuring CONFIG_SPL_WATCHDOG_SUPPORT=y
>> makes SPL build fail :
>>
>> drivers/built-in.o: In function `atmel_nand_pmecc_write_page':
>> /home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:592: undefined
>> reference to `watchdog_reset'
>> drivers/built-in.o: In function `atmel_nand_pmecc_read_page':
>> /home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:552: undefined
>> reference to `watchdog_reset'
>> drivers/built-in.o: In function `pmecc_err_location':
>> /home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:416: undefined
>> reference to `watchdog_reset'
>> scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed
> 
> Let me see, if I can change this so that this code is
> available if selected in SPL as well. Even though arch_misc_init()
> will not be called, so the watchdog will not be started.

It should at least build :)

> 
> But the code looks cleaner without this #ifdef and if you agree, I
> will send v2 soon with this change.

I did not have time to review all the patch series yet. So more reviews 
will follow

> 
>>
>>> +static struct udevice *watchdog_dev;
>>> +
>>> +/* Called by macro WATCHDOG_RESET */
>>> +void watchdog_reset(void)
>>> +{
>>> +    static ulong next_reset;
>>> +    ulong now;
>>> +
>>> +    if (!watchdog_dev)
>>> +    return;
>>> +
>>> +    now = get_timer(0);
>>> +
>>> +    /* Do not reset the watchdog too often */
>>> +    if (now > next_reset) {
>>> +    next_reset = now + 1000;    /* reset every 1000ms */
>>> +    wdt_reset(watchdog_dev);
>>> +    }
>>> +}
>>> +
>>> +int arch_misc_init(void)
>>> +{
>>> +    /* Init watchdog */
>>> +    if (uclass_get_device_by_seq(UCLASS_WDT, 0, _dev)) {
>>> +    debug("Watchdog: Not found by seq!\n");
>>> +    if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
>>> +    puts("Watchdog: Not found!\n");
>>> +    return 0;
>>> +    }
>>> +    }
>>> +
>>> +    wdt_start(watchdog_dev, 16000, 0);    /* 16 seconds is max */
>>> +    printf("Watchdog: Started\n");
>>> +
>>
>> Any reason why you use printf and puts and debug in the same function ?
>> Would expect to see debug everywhere except some fatal error that should
>> be printed all the time.
> 
> Good catch. This is copy-pasted from other very similar implementations.
> I personally find this last status message "Watchdog: Started" quite
> useful and would like to keep it. All others might be changed to debug().

I do not mind if you keep it

Eugen

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


Re: [U-Boot] [PATCH 06/11] arm: at91: Enable watchdog support

2019-03-21 Thread Stefan Roese

On 21.03.19 11:23, eugen.hris...@microchip.com wrote:



On 19.03.2019 17:56, Stefan Roese wrote:

External E-Mail


This patch enables and starts the watchdog on the AT91 platform if
configured. Currently the WD timeout is configured to 16 seconds,
which is the longest value for this timer.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
Cc: Andreas Bießmann 
Cc: Eugen Hristev 
---
   arch/arm/mach-at91/clock.c | 41 ++
   1 file changed, 41 insertions(+)

diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index 64cbc3d1ed..2d442d0092 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -5,6 +5,8 @@
*/
   
   #include 

+#include 
+#include 
   #include 
   #include 
   #include 
@@ -118,3 +120,42 @@ void at91_pllicpr_init(u32 icpr)
   
   	writel(icpr, >pllicpr);

   }
+
+#if defined(CONFIG_WATCHDOG) && !defined(CONFIG_SPL_BUILD)


Hi Stefan,

Does this mean that for CONFIG_SPL_BUILD, this functions won't exist,
thus the SPL cannot use the watchdog ?

For example, configuring CONFIG_SPL_WATCHDOG_SUPPORT=y
makes SPL build fail :

drivers/built-in.o: In function `atmel_nand_pmecc_write_page':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:592: undefined
reference to `watchdog_reset'
drivers/built-in.o: In function `atmel_nand_pmecc_read_page':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:552: undefined
reference to `watchdog_reset'
drivers/built-in.o: In function `pmecc_err_location':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:416: undefined
reference to `watchdog_reset'
scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed


Let me see, if I can change this so that this code is
available if selected in SPL as well. Even though arch_misc_init()
will not be called, so the watchdog will not be started.

But the code looks cleaner without this #ifdef and if you agree, I
will send v2 soon with this change.
 



+static struct udevice *watchdog_dev;
+
+/* Called by macro WATCHDOG_RESET */
+void watchdog_reset(void)
+{
+   static ulong next_reset;
+   ulong now;
+
+   if (!watchdog_dev)
+   return;
+
+   now = get_timer(0);
+
+   /* Do not reset the watchdog too often */
+   if (now > next_reset) {
+   next_reset = now + 1000;/* reset every 1000ms */
+   wdt_reset(watchdog_dev);
+   }
+}
+
+int arch_misc_init(void)
+{
+   /* Init watchdog */
+   if (uclass_get_device_by_seq(UCLASS_WDT, 0, _dev)) {
+   debug("Watchdog: Not found by seq!\n");
+   if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
+   puts("Watchdog: Not found!\n");
+   return 0;
+   }
+   }
+
+   wdt_start(watchdog_dev, 16000, 0);  /* 16 seconds is max */
+   printf("Watchdog: Started\n");
+


Any reason why you use printf and puts and debug in the same function ?
Would expect to see debug everywhere except some fatal error that should
be printed all the time.


Good catch. This is copy-pasted from other very similar implementations.
I personally find this last status message "Watchdog: Started" quite
useful and would like to keep it. All others might be changed to debug().

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


Re: [U-Boot] [RFC 4/8] cmd: bootefi: move do_bootefi_bootmgr_exec() forward

2019-03-21 Thread Heinrich Schuchardt
On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> This is a preparatory patch.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 3619a20e6433..1d90e7b4b575 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -314,6 +314,27 @@ err_add_protocol:
>   return ret;
>  }
>
> +static int do_bootefi_bootmgr_exec(void)
> +{
> + struct efi_device_path *device_path, *file_path;
> + void *addr;
> + efi_status_t r;
> +
> + addr = efi_bootmgr_load(_path, _path);
> + if (!addr)
> + return 1;
> +
> + printf("## Starting EFI application at %p ...\n", addr);
> + r = do_bootefi_exec(addr, device_path, file_path);
> + printf("## Application terminated, r = %lu\n",
> +r & ~EFI_ERROR_MASK);
> + if (r != EFI_SUCCESS)
> + return 1;

return CMD_RET_FAILURE ?

> +
> + return 0;

return CMD_RET_SUCCESS ?

The lines following efi_bootmgr_load() are duplicating code from
do_bootefi().

The patch itself is ok. But in the patch series we should get rid of the
duplication.

Best regards

Heinrich

> +}
> +
>  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
>  /**
>   * bootefi_test_prepare() - prepare to run an EFI test
> @@ -362,27 +383,6 @@ failure:
>
>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>
> -static int do_bootefi_bootmgr_exec(void)
> -{
> - struct efi_device_path *device_path, *file_path;
> - void *addr;
> - efi_status_t r;
> -
> - addr = efi_bootmgr_load(_path, _path);
> - if (!addr)
> - return 1;
> -
> - printf("## Starting EFI application at %p ...\n", addr);
> - r = do_bootefi_exec(addr, device_path, file_path);
> - printf("## Application terminated, r = %lu\n",
> -r & ~EFI_ERROR_MASK);
> -
> - if (r != EFI_SUCCESS)
> - return 1;
> -
> - return 0;
> -}
> -
>  /* Interpreter command to boot an arbitrary EFI image from memory */
>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
>

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


Re: [U-Boot] [RFC 3/8] efi_loader: bootmgr: return pointer and size of buffer in loading

2019-03-21 Thread Heinrich Schuchardt
On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> We need to know the size of image loaded so as to be able to use
> load_image() API at do_bootefi_exec() in a later patch.
>
> So change the interface of efi_bootmgr_load().
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/efi_loader.h |  5 +++--
>  lib/efi_loader/efi_bootmgr.c | 41 +---
>  2 files changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 47a51ddc9406..3f51116155ad 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -564,8 +564,9 @@ struct efi_load_option {
>
>  void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
>  unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 
> **data);
> -void *efi_bootmgr_load(struct efi_device_path **device_path,
> -struct efi_device_path **file_path);
> +efi_status_t efi_bootmgr_load(struct efi_device_path **device_path,
> +   struct efi_device_path **file_path,
> +   void **image, efi_uintn_t *size);
>
>  #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
>
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index 1575c5c09e46..38f3fa15f6ef 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -120,14 +120,17 @@ static void *get_var(u16 *name, const efi_guid_t 
> *vendor,
>   * if successful.  This checks that the EFI_LOAD_OPTION is active (enabled)
>   * and that the specified file to boot exists.
>   */
> -static void *try_load_entry(uint16_t n, struct efi_device_path **device_path,
> - struct efi_device_path **file_path)
> +static efi_status_t try_load_entry(u16 n,
> +struct efi_device_path **device_path,
> +struct efi_device_path **file_path,
> +void **image, efi_uintn_t *image_size)
>  {
>   struct efi_load_option lo;
>   u16 varname[] = L"Boot";
>   u16 hexmap[] = L"0123456789ABCDEF";
> - void *load_option, *image = NULL;
> + void *load_option;
>   efi_uintn_t size;
> + efi_status_t ret;
>
>   varname[4] = hexmap[(n & 0xf000) >> 12];
>   varname[5] = hexmap[(n & 0x0f00) >> 8];
> @@ -136,18 +139,17 @@ static void *try_load_entry(uint16_t n, struct 
> efi_device_path **device_path,
>
>   load_option = get_var(varname, _global_variable_guid, );
>   if (!load_option)
> - return NULL;
> + return EFI_LOAD_ERROR;
>
>   efi_deserialize_load_option(, load_option);
>
>   if (lo.attributes & LOAD_OPTION_ACTIVE) {
>   u32 attributes;
> - efi_status_t ret;
>
>   debug("%s: trying to load \"%ls\" from %pD\n",
> __func__, lo.label, lo.file_path);
>
> - ret = efi_load_image_from_path(lo.file_path, , );
> + ret = efi_load_image_from_path(lo.file_path, image, image_size);
>

This call to efi_load_image_from_path() leads to duplication of logic.

Why don't we simply call EFI_CALL(efi_load_image())) here and if it
succeeds return from efi_bootmgr_load()?

Best regards

Heinrich

>   if (ret != EFI_SUCCESS)
>   goto error;
> @@ -164,12 +166,14 @@ static void *try_load_entry(uint16_t n, struct 
> efi_device_path **device_path,
>
>   printf("Booting: %ls\n", lo.label);
>   efi_dp_split_file_path(lo.file_path, device_path, file_path);
> + } else {
> + ret = EFI_LOAD_ERROR;
>   }
>
>  error:
>   free(load_option);
>
> - return image;
> + return ret;
>  }
>
>  /*
> @@ -177,12 +181,12 @@ error:
>   * EFI variable, the available load-options, finding and returning
>   * the first one that can be loaded successfully.
>   */
> -void *efi_bootmgr_load(struct efi_device_path **device_path,
> -struct efi_device_path **file_path)
> +efi_status_t efi_bootmgr_load(struct efi_device_path **device_path,
> +   struct efi_device_path **file_path,
> +   void **image, efi_uintn_t *image_size)
>  {
>   u16 bootnext, *bootorder;
>   efi_uintn_t size;
> - void *image = NULL;
>   int i, num;
>   efi_status_t ret;
>
> @@ -201,9 +205,9 @@ void *efi_bootmgr_load(struct efi_device_path 
> **device_path,
>   (efi_guid_t *)_global_variable_guid,
>   0, 0, ));
>   if (ret == EFI_SUCCESS) {
> - image = try_load_entry(bootnext,
> -device_path, file_path);
> - if (image)
> + ret = try_load_entry(bootnext, device_path, file_path,
> +  image, image_size);
> + if (ret == EFI_SUCCESS)
>   

Re: [U-Boot] [PATCH] hikey: Take peripherals out of reset during board init

2019-03-21 Thread Daniel Thompson
On Wed, Mar 20, 2019 at 11:56:58AM +0530, Manivannan Sadhasivam wrote:
> Hi Peter,
> 
> On Tue, Mar 19, 2019 at 11:29:01AM +, Peter Griffin wrote:
> > Hi Mani,
> > 
> > This looks like a bug in the Linux kernel. The kernel driver should be
> > correctly
> > handling the reset lines of the I2C or SPI peripheral rather than replying
> > on
> > the bootloader to have already taken it out of reset.
> > 
> 
> Correct. After sending this patch out, I sent a patchset to LKML [1] for 
> fixing
> the issue in Linux kernel (thanks to Daniel for suggesting the change). But,
> we might need this hack in u-boot to make the old kernel/dts to work properly.
> And that's the reason I didn't abandon this patch.

Hacks like this develop a lot of legacy.

To be honest I don't really have much skin in the game here but even so
I'd prefer to see kernel patches back ported to keep any old kernels
running.


Daniel.

> 
> Thanks,
> Mani
> 
> [1] https://lkml.org/lkml/2019/3/8/878
> 
> > Peter.
> > 
> > On Fri, 8 Mar 2019 at 08:57, Manivannan Sadhasivam <
> > manivannan.sadhasi...@linaro.org> wrote:
> > 
> > > Peripherals like I2C and SPI needs to be taken out of reset during
> > > board init for functioning properly. Hence, add `hi6220_periph_reset`
> > > function for doing the same. For instance without this function, I2C
> > > will fail like below while booting linux:
> > >
> > > [0.608033] i2c_designware f710.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > > [0.621378] i2c_designware f7101000.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > > [0.633818] i2c_designware f7102000.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > >
> > > Signed-off-by: Manivannan Sadhasivam 
> > > ---
> > >  board/hisilicon/hikey/hikey.c | 16 
> > >  1 file changed, 16 insertions(+)
> > >
> > > diff --git a/board/hisilicon/hikey/hikey.c b/board/hisilicon/hikey/hikey.c
> > > index 940ae82c45b..f8b8c372bfd 100644
> > > --- a/board/hisilicon/hikey/hikey.c
> > > +++ b/board/hisilicon/hikey/hikey.c
> > > @@ -364,6 +364,20 @@ static void hi6220_pmussi_init(void)
> > > gpio_direction_output(0, 1);
> > >  }
> > >
> > > +static void hi6220_periph_reset(void)
> > > +{
> > > +   u32 data, bits;
> > > +
> > > +   /* Bring I2C0/I2C1/I2C2/SPI0 out of reset */
> > > +   bits = PERI_RST3_I2C0 | PERI_RST3_I2C1 | PERI_RST3_I2C2 |
> > > PERI_RST3_SSP;
> > > +   writel(bits, _sc->rst3_dis);
> > > +
> > > +   /* Wait until the peripherals are out of reset */
> > > +   do {
> > > +   data = readl(_sc->rst3_dis);
> > > +   } while (data & bits);
> > > +}
> > > +
> > >  int misc_init_r(void)
> > >  {
> > > return 0;
> > > @@ -371,6 +385,8 @@ int misc_init_r(void)
> > >
> > >  int board_init(void)
> > >  {
> > > +   hi6220_periph_reset();
> > > +
> > > return 0;
> > >  }
> > >
> > > --
> > > 2.17.1
> > >
> > >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] lib: tiny-printf: Add "%ll" modifier support

2019-03-21 Thread Tom Rini
On Fri, Mar 22, 2019 at 01:12:14AM +0800, Ley Foon Tan wrote:

> Add "%ll" modifier support for tiny printf.
> 
> - Tested on ARM32 and ARM64 systems.
> - Tested "%lld", "%llu", "%llx" and "%p" format with
>   minimum and maximum ranges. Compared tiny printf
>   output with full printf.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  lib/tiny-printf.c | 42 +-
>  1 file changed, 29 insertions(+), 13 deletions(-)

What's the use case for this, how much does it grow the size, and can
the code in question be changed to use a different format modifier or be
debug() instead?  Tiny printf isn't intended to cover all formats but
rather still allow some amount of printf on constrained systems.
Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 1/2] distro_bootcmd: add spi flash boot command

2019-03-21 Thread Jagan Teki
On Tue, Feb 19, 2019 at 9:57 PM Oskari Lemmelä  wrote:
>
> Hi,
>
> On 9.2.2019 17.50, Jagan Teki wrote:
> > On Thu, Jan 31, 2019 at 12:51 AM Oskari Lemmela  wrote:
> >> Add a boot command to distro boot to support load FIT image
> >> from SPI flash.
> > Add some info about why default offsets being used below.
>
> Or is it just better not to define default values?

Adding offsets fine, for verification. please add comments on offsets
along with which platform it's been tested.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] armv8: fsl-layerscape: add missing sec jr base address defines

2019-03-21 Thread Horia Geanta
On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> Add defines for all the SEC job rings base addresses.
> 
> Signed-off-by: Laurentiu Tudor 
Reviewed-by: Horia Geantă 

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


Re: [U-Boot] [PATCH 2/2] armv8: ls1088a: add icid setup for platform devices

2019-03-21 Thread Horia Geanta
On 3/20/2019 4:31 PM, laurentiu.tu...@nxp.com wrote:
> +struct icid_id_table icid_tbl[] = {
> + SET_SDHC_ICID(FSL_SDMMC_STREAM_ID),
> + SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
> + SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
> + SET_SATA_ICID(1, "fsl,ls1088a-ahci", FSL_SATA1_STREAM_ID),
> + SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
> + SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
> + SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
> + SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
> + SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
> + SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
> + SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
> + SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
> + SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
> + SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
> + SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
> + SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
> +};
A single ICID is allocated to all SEC sub-blocks able to initiate transactions.
I think at least the job rings should have different ICIDs, while the rest could
share another ICID.

>  #define SET_SEC_QI_ICID(streamid) \
> - SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
> + SET_ICID_ENTRY("fsl,sec-v4.0", SEC_ICID_REG_VAL(streamid), \
Is this a fix for LS104x? Then it should be a separate patch.

> +#else /* CONFIG_FSL_LSCH2 */
[...]
> +#define SEC_ICID_REG_VAL(streamid) ((streamid) << 24)
ICID is in lower 6:0 bits, not in 31:24.

> +#endif /* !CONFIG_FSL_LSCH2 */
Nitpick: comment for #endif should match #if condition, which is 
CONFIG_FSL_LSCH2.

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


Re: [U-Boot] [PATCH 06/11] arm: at91: Enable watchdog support

2019-03-21 Thread Eugen.Hristev


On 19.03.2019 17:56, Stefan Roese wrote:
> External E-Mail
> 
> 
> This patch enables and starts the watchdog on the AT91 platform if
> configured. Currently the WD timeout is configured to 16 seconds,
> which is the longest value for this timer.
> 
> Signed-off-by: Stefan Roese 
> Cc: Heiko Schocher 
> Cc: Andreas Bießmann 
> Cc: Eugen Hristev 
> ---
>   arch/arm/mach-at91/clock.c | 41 ++
>   1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 64cbc3d1ed..2d442d0092 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -5,6 +5,8 @@
>*/
>   
>   #include 
> +#include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -118,3 +120,42 @@ void at91_pllicpr_init(u32 icpr)
>   
>   writel(icpr, >pllicpr);
>   }
> +
> +#if defined(CONFIG_WATCHDOG) && !defined(CONFIG_SPL_BUILD)

Hi Stefan,

Does this mean that for CONFIG_SPL_BUILD, this functions won't exist, 
thus the SPL cannot use the watchdog ?

For example, configuring CONFIG_SPL_WATCHDOG_SUPPORT=y
makes SPL build fail :

drivers/built-in.o: In function `atmel_nand_pmecc_write_page':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:592: undefined 
reference to `watchdog_reset'
drivers/built-in.o: In function `atmel_nand_pmecc_read_page':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:552: undefined 
reference to `watchdog_reset'
drivers/built-in.o: In function `pmecc_err_location':
/home/eugen/u-boot-denx/drivers/mtd/nand/raw/atmel_nand.c:416: undefined 
reference to `watchdog_reset'
scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed


> +static struct udevice *watchdog_dev;
> +
> +/* Called by macro WATCHDOG_RESET */
> +void watchdog_reset(void)
> +{
> + static ulong next_reset;
> + ulong now;
> +
> + if (!watchdog_dev)
> + return;
> +
> + now = get_timer(0);
> +
> + /* Do not reset the watchdog too often */
> + if (now > next_reset) {
> + next_reset = now + 1000;/* reset every 1000ms */
> + wdt_reset(watchdog_dev);
> + }
> +}
> +
> +int arch_misc_init(void)
> +{
> + /* Init watchdog */
> + if (uclass_get_device_by_seq(UCLASS_WDT, 0, _dev)) {
> + debug("Watchdog: Not found by seq!\n");
> + if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
> + puts("Watchdog: Not found!\n");
> + return 0;
> + }
> + }
> +
> + wdt_start(watchdog_dev, 16000, 0);  /* 16 seconds is max */
> + printf("Watchdog: Started\n");
> +

Any reason why you use printf and puts and debug in the same function ? 
Would expect to see debug everywhere except some fatal error that should 
be printed all the time.

Eugen

> + return 0;
> +}
> +#endif
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 8/9] riscv: dts: ae350 support SMP.

2019-03-21 Thread Rick Chen
Bin Meng  於 2019年3月21日 週四 下午6:12寫道:
>
> Hi Rick,
>
> On Thu, Mar 21, 2019 at 5:37 PM Rick Chen  wrote:
> >
> > Bin Meng  於 2019年3月21日 週四 下午5:15寫道:
> > >
> > > Hi Rick,
> > >
> > > On Thu, Mar 21, 2019 at 4:51 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > Bin Meng  於 2019年3月20日 週三 下午3:22寫道:
> > > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Tue, Mar 19, 2019 at 5:13 PM Andes  wrote:
> > > > > >
> > > > > > From: Rick Chen 
> > > > > >
> > > > >
> > > > > nits: remove the ending period in the commit title.
> > > >
> > > > OK.
> > > > I will remove it.
> > > >
> > > > >
> > > > > > Signed-off-by: Rick Chen 
> > > > > > Cc: Greentime Hu 
> > > > > > ---
> > > > > >  arch/riscv/dts/ae350_32.dts | 81 
> > > > > > +
> > > > > >  arch/riscv/dts/ae350_64.dts | 47 +++---
> > > > > >  2 files changed, 101 insertions(+), 27 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/dts/ae350_32.dts 
> > > > > > b/arch/riscv/dts/ae350_32.dts
> > > > > > index 0679827..0b4d966 100644
> > > > > > --- a/arch/riscv/dts/ae350_32.dts
> > > > > > +++ b/arch/riscv/dts/ae350_32.dts
> > > > > > @@ -25,17 +25,50 @@
> > > > > > reg = <0>;
> > > > > > status = "okay";
> > > > > > compatible = "riscv";
> > > > > > -   riscv,isa = "rv32imafdc";
> > > > > > +   riscv,isa = 
> > > > > > "rv32i2p0m2p0a2p0f2p0d2p0c2p0xv5-0p0";
> > > > >
> > > > > I am not sure what is this. Is this something approved?
> > > >
> > > > It is about elf checking (attribute) and seem has been upstream to GCC.
> > > > https://patchwork.ozlabs.org/cover/1040998/
> > > >
> > >
> > > So that patch affects GCC's "-march" string? But why do we need adjust
> > > the "riscv,isa" string in DT?
> > >
> >
> > We will use this to check user program (binutils will assign this
> > string) when it run in kernel at run time.
>
> Do you have details about this binutils checks? Is this new string
> approved by the DT upstream? At least I see latest QEMU still
> generates the old string.

The string is NOT approved by the DT upstream.
We use it internally .

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


Re: [U-Boot] [PATCH 8/9] riscv: dts: ae350 support SMP.

2019-03-21 Thread Bin Meng
Hi Rick,

On Thu, Mar 21, 2019 at 5:37 PM Rick Chen  wrote:
>
> Bin Meng  於 2019年3月21日 週四 下午5:15寫道:
> >
> > Hi Rick,
> >
> > On Thu, Mar 21, 2019 at 4:51 PM Rick Chen  wrote:
> > >
> > > Hi Bin
> > >
> > > Bin Meng  於 2019年3月20日 週三 下午3:22寫道:
> > > >
> > > > Hi Rick,
> > > >
> > > > On Tue, Mar 19, 2019 at 5:13 PM Andes  wrote:
> > > > >
> > > > > From: Rick Chen 
> > > > >
> > > >
> > > > nits: remove the ending period in the commit title.
> > >
> > > OK.
> > > I will remove it.
> > >
> > > >
> > > > > Signed-off-by: Rick Chen 
> > > > > Cc: Greentime Hu 
> > > > > ---
> > > > >  arch/riscv/dts/ae350_32.dts | 81 
> > > > > +
> > > > >  arch/riscv/dts/ae350_64.dts | 47 +++---
> > > > >  2 files changed, 101 insertions(+), 27 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> > > > > index 0679827..0b4d966 100644
> > > > > --- a/arch/riscv/dts/ae350_32.dts
> > > > > +++ b/arch/riscv/dts/ae350_32.dts
> > > > > @@ -25,17 +25,50 @@
> > > > > reg = <0>;
> > > > > status = "okay";
> > > > > compatible = "riscv";
> > > > > -   riscv,isa = "rv32imafdc";
> > > > > +   riscv,isa = 
> > > > > "rv32i2p0m2p0a2p0f2p0d2p0c2p0xv5-0p0";
> > > >
> > > > I am not sure what is this. Is this something approved?
> > >
> > > It is about elf checking (attribute) and seem has been upstream to GCC.
> > > https://patchwork.ozlabs.org/cover/1040998/
> > >
> >
> > So that patch affects GCC's "-march" string? But why do we need adjust
> > the "riscv,isa" string in DT?
> >
>
> We will use this to check user program (binutils will assign this
> string) when it run in kernel at run time.

Do you have details about this binutils checks? Is this new string
approved by the DT upstream? At least I see latest QEMU still
generates the old string.

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


[U-Boot] [PATCH] ARM: socfpga: Build sfp image only for Gen5 and Arria10 devices

2019-03-21 Thread Dalon Westergreen
From: Dalon Westergreen 

The sfp file is only valid for Gen5 (Cyclone5 & Arria5) and Arria10
devices.  The file should only be built for these devices.

Signed-off-by: Dalon Westergreen 
---
 Kconfig  | 3 ++-
 scripts/Makefile.spl | 6 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index 512c7beb89..305b265ed7 100644
--- a/Kconfig
+++ b/Kconfig
@@ -226,7 +226,8 @@ config BUILD_ROM
 
 config BUILD_TARGET
string "Build target special images"
-   default "u-boot-with-spl.sfp" if ARCH_SOCFPGA
+   default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_ARRIA10
+   default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_GEN5
default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
default "u-boot-elf.srec" if RCAR_GEN3
default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 9d5921606e..592c5dfe57 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -212,7 +212,11 @@ ifdef CONFIG_SAMSUNG
 ALL-y  += $(obj)/$(BOARD)-spl.bin
 endif
 
-ifdef CONFIG_ARCH_SOCFPGA
+ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
+ALL-y  += $(obj)/$(SPL_BIN).sfp
+endif
+
+ifdef CONFIG_TARGET_SOCFPGA_GEN5
 ALL-y  += $(obj)/$(SPL_BIN).sfp
 endif
 
-- 
2.20.1

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


Re: [U-Boot] [PATCH] configs: icorem6: Use imx6 cratch register for bootcount

2019-03-21 Thread Shyam Saini
Hi Stefano,

Thanks a lot for reviewing this

> nitpick: cratch ==> scratch
>
> On 21/03/19 09:35, Jagan Teki wrote:
> > SRAM address used for bootcount on exiting code is erasing
> > previous count value when system reset from Linux. So use
> > the dedicated imx6 scratch register, GPR2 to preserve the
> > contents even if the system reset from Linux.
> >
> > Fixes: 4eb9aa39350e ("configs: imx6qdl_icore_mmc: Enable watchdog and 
> > bootcounter")
> > Signed-off-by: Michael Trimarchi 
> > Signed-off-by: Jagan Teki 
> > ---
> >  configs/imx6qdl_icore_mmc_defconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/configs/imx6qdl_icore_mmc_defconfig 
> > b/configs/imx6qdl_icore_mmc_defconfig
> > index 68ad1c6d20..24e99718e6 100644
> > --- a/configs/imx6qdl_icore_mmc_defconfig
> > +++ b/configs/imx6qdl_icore_mmc_defconfig
> > @@ -16,7 +16,7 @@ CONFIG_CMD_BOOTCOUNT=y
> >  CONFIG_BOOTCOUNT_LIMIT=y
> >  CONFIG_BOOTCOUNT_BOOTLIMIT=3
> >  CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
> > -CONFIG_SYS_BOOTCOUNT_ADDR=0x0090
> > +CONFIG_SYS_BOOTCOUNT_ADDR=0x020D8024
> >  CONFIG_SYS_BOOTCOUNT_MAGIC=0x0B01C041
> >  CONFIG_IMX_WATCHDOG=y
> >  CONFIG_DEBUG_UART=y
> >
>
> Just as info: I confirm that using start address of SRAM does not work.
> Rather even the GPRx registers are not a common solution. I have already
> seen that even the GPRx registers are touched and cannot be used on some
> i.MX6 variant. Anyway, if this works on your board, fine.

Since GPRx registers are common to i.MX6, I think it can work
irrespective of boards, please correct me
if I am missing something here.

Did you come across any generic and robust solution for this ?
It would be great if we can use more generic or better solution.
Please let us know.

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


Re: [U-Boot] [PATCH 8/9] riscv: dts: ae350 support SMP.

2019-03-21 Thread Rick Chen
Bin Meng  於 2019年3月21日 週四 下午5:15寫道:
>
> Hi Rick,
>
> On Thu, Mar 21, 2019 at 4:51 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > Bin Meng  於 2019年3月20日 週三 下午3:22寫道:
> > >
> > > Hi Rick,
> > >
> > > On Tue, Mar 19, 2019 at 5:13 PM Andes  wrote:
> > > >
> > > > From: Rick Chen 
> > > >
> > >
> > > nits: remove the ending period in the commit title.
> >
> > OK.
> > I will remove it.
> >
> > >
> > > > Signed-off-by: Rick Chen 
> > > > Cc: Greentime Hu 
> > > > ---
> > > >  arch/riscv/dts/ae350_32.dts | 81 
> > > > +
> > > >  arch/riscv/dts/ae350_64.dts | 47 +++---
> > > >  2 files changed, 101 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> > > > index 0679827..0b4d966 100644
> > > > --- a/arch/riscv/dts/ae350_32.dts
> > > > +++ b/arch/riscv/dts/ae350_32.dts
> > > > @@ -25,17 +25,50 @@
> > > > reg = <0>;
> > > > status = "okay";
> > > > compatible = "riscv";
> > > > -   riscv,isa = "rv32imafdc";
> > > > +   riscv,isa = 
> > > > "rv32i2p0m2p0a2p0f2p0d2p0c2p0xv5-0p0";
> > >
> > > I am not sure what is this. Is this something approved?
> >
> > It is about elf checking (attribute) and seem has been upstream to GCC.
> > https://patchwork.ozlabs.org/cover/1040998/
> >
>
> So that patch affects GCC's "-march" string? But why do we need adjust
> the "riscv,isa" string in DT?
>

We will use this to check user program (binutils will assign this
string) when it run in kernel at run time.

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


[U-Boot] [PATCH v2 4/6] arm: dts: Stratix10: Modify stratix10 socdk memory node

2019-03-21 Thread Ley Foon Tan
The stratix10 socdk ships with 4GB of memory.  Modify the
device tree to represent this.  Note that to access 4GB of
memory in Stratix 10, due to the IO space from 2GB to 4GB,
we use the fact that the DDR controller ignores upper address
bits outside of the configured DRAM's size.  This means that
, the 4GB DRAM is mapped to memory every 4GB.

For an 8GB memory, you can either live with the 2GB IO space,
and loose access to that memory from the processor, or use
the same trick:

Loose 2GB of memory:
memory {
device_type = "memory";
/* 8GB */
/* first 2GB */
reg = <0 0x 0 0x8000>,
/* last 4GB */
  <1 0x 1 0x>;
u-boot,dm-pre-reloc;
};


or to map it all:
memory {
device_type = "memory";
/* 8GB */
/* first 2GB */
reg = <0 0x 0 0x8000>,
/* next 6GB */
  <2 0x8000 1 0x8000>;
u-boot,dm-pre-reloc;
};

Signed-off-by: Dalon Westergreen 
Signed-off-by: Ley Foon Tan 
---
 arch/arm/dts/socfpga_stratix10_socdk.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index 6e8ddcd9f4..c59b77d829 100644
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -36,7 +36,9 @@
 
memory {
device_type = "memory";
-   reg = <0 0 0 0x8000>; /* 2GB */
+   /* 4GB */
+   reg = <0 0x 0 0x8000>,
+ <1 0x8000 0 0x8000>;
u-boot,dm-pre-reloc;
};
 };
-- 
2.19.0

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


[U-Boot] [PATCH v2 6/6] ddr: altera: Stratix10: Add ECC memory scrubbing

2019-03-21 Thread Ley Foon Tan
Scrub memory content if ECC is enabled and it is not
from warm reset boot.

Enable icache and dcache before scrub memory
and use "DC ZVA" instruction to clear memory
to zeros. This instruction writes a cache line
at a time and it can prevent false ECC error
trigger if write cache line partially.

Signed-off-by: Ley Foon Tan 
---
 .../arm/mach-socfpga/include/mach/sdram_s10.h |  9 +++
 drivers/ddr/altera/sdram_s10.c| 81 +++
 2 files changed, 90 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/sdram_s10.h 
b/arch/arm/mach-socfpga/include/mach/sdram_s10.h
index ca68594445..f39206ca1e 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram_s10.h
@@ -22,6 +22,7 @@ int sdram_calibration_full(void);
 #define ECCCTRL1   0x100
 #define ECCCTRL2   0x104
 #define ERRINTEN   0x110
+#define ERRINTENS  0x114
 #define INTMODE0x11c
 #define INTSTAT0x120
 #define AUTOWB_CORRADDR0x138
@@ -52,6 +53,10 @@ int sdram_calibration_full(void);
 #define DDR_HMC_SEQ2CORE_INT_RESP_MASK BIT(3)
 #define DDR_HMC_HPSINTFCSEL_ENABLE_MASK0x001f1f1f
 
+#defineDDR_HMC_ERRINTEN_INTMASK\
+   (DDR_HMC_ERRINTEN_SERRINTEN_EN_SET_MSK |\
+DDR_HMC_ERRINTEN_DERRINTEN_EN_SET_MSK)
+
 /* NOC DDR scheduler */
 #define DDR_SCH_ID_COREID  0
 #define DDR_SCH_ID_REVID   0x4
@@ -180,4 +185,8 @@ int sdram_calibration_full(void);
 #define CALTIMING9_CFG_4_ACT_TO_ACT(x) \
(((x) >> 0) & 0xFF)
 
+/* Firewall DDR scheduler MPFE */
+#define FW_HMC_ADAPTOR_REG_ADDR0xf8020004
+#define FW_HMC_ADAPTOR_MPU_MASKBIT(0)
+
 #endif /* _SDRAM_S10_H_ */
diff --git a/drivers/ddr/altera/sdram_s10.c b/drivers/ddr/altera/sdram_s10.c
index 462c8feaef..e4d4a02ca2 100644
--- a/drivers/ddr/altera/sdram_s10.c
+++ b/drivers/ddr/altera/sdram_s10.c
@@ -23,6 +23,8 @@ static const struct socfpga_system_manager *sysmgr_regs =
 
 #define DDR_CONFIG(A, B, C, R) (((A) << 24) | ((B) << 16) | ((C) << 8) | (R))
 
+#define PGTABLE_OFF0x4000
+
 /* The followring are the supported configurations */
 u32 ddr_config[] = {
/* DDR_CONFIG(Address order,Bank,Column,Row) */
@@ -136,6 +138,76 @@ static int poll_hmc_clock_status(void)
 SYSMGR_HMC_CLK_STATUS_MSK, true, 1000, false);
 }
 
+static void sdram_clear_mem(phys_addr_t addr, phys_size_t size)
+{
+   phys_size_t i;
+
+   if (addr % CONFIG_SYS_CACHELINE_SIZE) {
+   printf("DDR: address 0x%llx is not cacheline size aligned.\n",
+  addr);
+   hang();
+   }
+
+   if (size % CONFIG_SYS_CACHELINE_SIZE) {
+   printf("DDR: size 0x%llx is not multiple of cacheline size\n",
+  size);
+   hang();
+   }
+
+   /* Use DC ZVA instruction to clear memory to zeros by a cache line */
+   for (i = 0; i < size; i = i + CONFIG_SYS_CACHELINE_SIZE) {
+   asm volatile("dc zva, %0"
+:
+: "r"(addr)
+: "memory");
+   addr += CONFIG_SYS_CACHELINE_SIZE;
+   }
+}
+
+static void sdram_init_ecc_bits(bd_t *bd)
+{
+   phys_size_t size, size_init;
+   phys_addr_t start_addr;
+   int bank = 0;
+   unsigned int start = get_timer(0);
+
+   icache_enable();
+
+   start_addr = bd->bi_dram[0].start;
+   size = bd->bi_dram[0].size;
+
+   /* Initialize small block for page table */
+   memset((void *)start_addr, 0, PGTABLE_SIZE + PGTABLE_OFF);
+   gd->arch.tlb_addr = start_addr + PGTABLE_OFF;
+   gd->arch.tlb_size = PGTABLE_SIZE;
+   start_addr += PGTABLE_SIZE + PGTABLE_OFF;
+   size -= (PGTABLE_OFF + PGTABLE_SIZE);
+   dcache_enable();
+
+   while (1) {
+   while (size) {
+   size_init = min((phys_addr_t)SZ_1G, (phys_addr_t)size);
+   sdram_clear_mem(start_addr, size_init);
+   size -= size_init;
+   start_addr += size_init;
+   WATCHDOG_RESET();
+   }
+
+   bank++;
+   if (bank >= CONFIG_NR_DRAM_BANKS)
+   break;
+
+   start_addr = bd->bi_dram[bank].start;
+   size = bd->bi_dram[bank].size;
+   }
+
+   dcache_disable();
+   icache_disable();
+
+   printf("SDRAM-ECC: Initialized success with %d ms\n",
+  (unsigned int)get_timer(start));
+}
+
 static void sdram_size_check(bd_t *bd)
 {
phys_size_t total_ram_check = 0;
@@ -400,6 +472,15 @@ int sdram_mmr_init_full(unsigned int unused)

[U-Boot] [PATCH v2 5/6] arm: socfpga: stratix10: Add cpu_has_been_warmreset()

2019-03-21 Thread Ley Foon Tan
Add helper function cpu_has_been_warmreset() to check
if CPU is from warm reset boot.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 3 +++
 arch/arm/mach-socfpga/reset_manager_s10.c  | 9 +
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
index 31b73edabe..e186296791 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
@@ -9,6 +9,7 @@
 
 void reset_cpu(ulong addr);
 void reset_deassert_peripherals_handoff(void);
+int cpu_has_been_warmreset(void);
 
 void socfpga_bridges_reset(int enable);
 
@@ -47,6 +48,8 @@ struct socfpga_reset_manager {
 #define RSTMGR_MPUMODRST_CORE0 0
 #define RSTMGR_PER0MODRST_OCP_MASK 0x0020bf00
 #define RSTMGR_BRGMODRST_DDRSCH_MASK   0X0040
+/* Watchdogs and MPU warm reset mask */
+#define RSTMGR_L4WD_MPU_WARMRESET_MASK 0x000F0F00
 
 /*
  * Define a reset identifier, from which a permodrst bank ID
diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c 
b/arch/arm/mach-socfpga/reset_manager_s10.c
index f176c38495..f8dd787cc6 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -103,3 +103,12 @@ void reset_deassert_peripherals_handoff(void)
writel(~RSTMGR_PER0MODRST_OCP_MASK, _manager_base->per0modrst);
writel(0, _manager_base->per0modrst);
 }
+
+/*
+ * Return non-zero if the CPU has been warm reset
+ */
+int cpu_has_been_warmreset(void)
+{
+   return readl(_manager_base->status) &
+   RSTMGR_L4WD_MPU_WARMRESET_MASK;
+}
-- 
2.19.0

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


[U-Boot] [PATCH v2 2/6] ddr: altera: Stratix10: Add multi-banks DRAM size check

2019-03-21 Thread Ley Foon Tan
Stratix 10 maps dram from 0 to 128GB.  There is a 2GB hole
in the memory for peripherals and other IO from 2GB to 4GB.
However the dram controller ignores upper address bits for
smaller dram configurations.  Example: a 4GB dram
maps to multiple locations, every 4GB on the address.

Signed-off-by: Dalon Westergreen 
Signed-off-by: Ley Foon Tan 
---
 drivers/ddr/altera/sdram_s10.c | 46 ++
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/ddr/altera/sdram_s10.c b/drivers/ddr/altera/sdram_s10.c
index 033ccca437..462c8feaef 100644
--- a/drivers/ddr/altera/sdram_s10.c
+++ b/drivers/ddr/altera/sdram_s10.c
@@ -7,12 +7,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -134,14 +136,35 @@ static int poll_hmc_clock_status(void)
 SYSMGR_HMC_CLK_STATUS_MSK, true, 1000, false);
 }
 
-static void sdram_size_check(void)
+static void sdram_size_check(bd_t *bd)
 {
+   phys_size_t total_ram_check = 0;
+   phys_size_t ram_check = 0;
+   phys_addr_t start = 0;
+   int bank;
+
/* Sanity check ensure correct SDRAM size specified */
debug("DDR: Running SDRAM size sanity check\n");
-   if (get_ram_size(0, gd->ram_size) != gd->ram_size) {
+
+   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+   start = bd->bi_dram[bank].start;
+   while (ram_check < bd->bi_dram[bank].size) {
+   ram_check += get_ram_size((void *)(start + ram_check),
+(phys_size_t)SZ_1G);
+   }
+   total_ram_check += ram_check;
+   ram_check = 0;
+   }
+
+   /* If the ram_size is 2GB smaller, we can assume the IO space is
+* not mapped in.  gd->ram_size is the actual size of the dram
+* not the accessible size.
+*/
+   if (total_ram_check != gd->ram_size) {
puts("DDR: SDRAM size check failed!\n");
hang();
}
+
debug("DDR: SDRAM size check passed!\n");
 }
 
@@ -155,6 +178,8 @@ int sdram_mmr_init_full(unsigned int unused)
u32 update_value, io48_value, ddrioctl;
u32 i;
int ret;
+   phys_size_t hw_size;
+   bd_t bd = {0};
 
/* Enable access to DDR from CPU master */
clrbits_le32(CCU_REG_ADDR(CCU_CPU0_MPRT_ADBASE_DDRREG),
@@ -346,9 +371,20 @@ int sdram_mmr_init_full(unsigned int unused)
unsigned long long size = sdram_calculate_size();
/* If the size is invalid, use default Config size */
if (size <= 0)
-   gd->ram_size = PHYS_SDRAM_1_SIZE;
+   hw_size = PHYS_SDRAM_1_SIZE;
else
-   gd->ram_size = size;
+   hw_size = size;
+
+   /* Get bank configuration from devicetree */
+   ret = fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
+(phys_size_t *)>ram_size, );
+   if (ret) {
+   puts("DDR: Failed to decode memory node\n");
+   return -1;
+   }
+
+   if (gd->ram_size != hw_size)
+   printf("DDR: Warning: DRAM size from device tree mismatch with 
hardware.\n");
 
printf("DDR: %lld MiB\n", gd->ram_size >> 20);
 
@@ -374,7 +410,7 @@ int sdram_mmr_init_full(unsigned int unused)
  DDR_HMC_ECCCTL2_AWB_EN_SET_MSK));
}
 
-   sdram_size_check();
+   sdram_size_check();
 
debug("DDR: HMC init success\n");
return 0;
-- 
2.19.0

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


  1   2   >