Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

[Simon Goldschmidt]

On 23.01.2018 07:28, Chee, Tien Fong wrote:

On Mon, 2018-01-22 at 12:41 +0100, Simon Goldschmidt wrote:

On 22.01.2018 09:08, Chee, Tien Fong wrote:

On Thu, 2018-01-18 at 06:57 +0100, Simon Goldschmidt wrote:

On 27.12.2017 06:04, tien.fong.c...@intel.com wrote:

From: Tien Fong Chee 

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program
whatever,
ie. the FPGA device.

Signed-off-by: Tien Fong Chee 
---
    common/Makefile|   1 +
    common/fs_loader.c | 309
+
    doc/README.firmware_loader |  76 +++
    include/fs_loader.h|  28 
    4 files changed, 414 insertions(+)
    create mode 100644 common/fs_loader.c
    create mode 100644 doc/README.firmware_loader
    create mode 100644 include/fs_loader.h




+#if defined(CONFIG_SPL_MMC_SUPPORT) &&
defined(CONFIG_SPL_BUILD)
+static int init_mmc(void)
+{
+   /* Just for the case MMC is not yet initialized */
+   struct mmc *mmc = NULL;
+   int err;
+
+   spl_mmc_find_device(, spl_boot_device());
+
+   err = mmc_init(mmc);
+   if (err) {
+   printf("spl: mmc init failed with error:
%d\n",
err);
+   return err;
+   }
+
+   return err;
+}

I see two problems here: First, you're ignoring the return value
of
spl_mmc_find_device() and initialize 'mmc' to NULL instead.
Wouldn't
it
be better to let 'mmc' be uninitialized and return the error code
returned by spl_mmc_find_device() if there is one?


Yeah, you are right, i should add the check on the return value. I
think that would better to initialize NULL to mmc, because there is
no
checking on the mmc in spl_mmc_find_device(), so that is possible
memory access violation/abort can be happended if unknown value in
mmc
pointer.


Second, using spl_boot_device() would prevent making the loader
work
on
mach-socfpga when spl is not loaded from mmc, right?

E.g. for the case I'm currently trying to fix (boot from qspi),
this
loader would not work although there's technically no reason
since
the
platform only has one mmc. The call to spl_boot_device() could be
replaced by the exact value here for platforms that only have one
mmc. I
don't know how to fix that, though.


The main purpose here is to initialize the mmc driver. So which
storage
user wants to load the file is totally depend what storage such as
mmc
user defines in location->name. Loader would init the storage based
on
the storage defined in location->name before accessing it. Since
the
loader only support file system at this moment, i would suggest FAT
fs
for mmc and ubi fs for qspi.

What I meant to say is this: at least on mach-socfpga, from reading
the
code, I cannot load a file from mmc when booting from qspi, as
'spl_boot_device' returns 'BOOT_DEVICE_SPI' in that case, although I
need to pass 'BOOT_DEVICE_MMC1' to 'spl_mmc_find_device'. Or am I
wrong
here?


Okay, i got you.

Yeah, you are right for use case if you need to load the file from mmc
during SPL boot and SPL is not loaded from mmc.

Since the spl_boot_device is platform dependent, you may try to add
some state machine so that this function can return correct device
type.

Secondly, you can use this function in U-Boot instead of SPL.


You're right on that. Thinking about it, I would probably use it from 
U-Boot, not from SPL...



Lastly, i can declare __Weak to init_mmc, so that user can define their
own implementation.


At least somehow allowing to override which device is passed to 
'spl_mmc_find_device' might be good, instead of hardcoding it to 
'spl_boot_device'...


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

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Mon, 2018-01-22 at 12:41 +0100, Simon Goldschmidt wrote:
> On 22.01.2018 09:08, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-01-18 at 06:57 +0100, Simon Goldschmidt wrote:
> > > 
> > > On 27.12.2017 06:04, tien.fong.c...@intel.com wrote:
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >    common/Makefile|   1 +
> > > >    common/fs_loader.c | 309
> > > > +
> > > >    doc/README.firmware_loader |  76 +++
> > > >    include/fs_loader.h|  28 
> > > >    4 files changed, 414 insertions(+)
> > > >    create mode 100644 common/fs_loader.c
> > > >    create mode 100644 doc/README.firmware_loader
> > > >    create mode 100644 include/fs_loader.h
> > > 
> > > 
> > > > 
> > > > +#if defined(CONFIG_SPL_MMC_SUPPORT) &&
> > > > defined(CONFIG_SPL_BUILD)
> > > > +static int init_mmc(void)
> > > > +{
> > > > +   /* Just for the case MMC is not yet initialized */
> > > > +   struct mmc *mmc = NULL;
> > > > +   int err;
> > > > +
> > > > +   spl_mmc_find_device(, spl_boot_device());
> > > > +
> > > > +   err = mmc_init(mmc);
> > > > +   if (err) {
> > > > +   printf("spl: mmc init failed with error:
> > > > %d\n",
> > > > err);
> > > > +   return err;
> > > > +   }
> > > > +
> > > > +   return err;
> > > > +}
> > > I see two problems here: First, you're ignoring the return value
> > > of
> > > spl_mmc_find_device() and initialize 'mmc' to NULL instead.
> > > Wouldn't
> > > it
> > > be better to let 'mmc' be uninitialized and return the error code
> > > returned by spl_mmc_find_device() if there is one?
> > > 
> > Yeah, you are right, i should add the check on the return value. I
> > think that would better to initialize NULL to mmc, because there is
> > no
> > checking on the mmc in spl_mmc_find_device(), so that is possible
> > memory access violation/abort can be happended if unknown value in
> > mmc
> > pointer.
> > 
> > > 
> > > Second, using spl_boot_device() would prevent making the loader
> > > work
> > > on
> > > mach-socfpga when spl is not loaded from mmc, right?
> > > 
> > > E.g. for the case I'm currently trying to fix (boot from qspi),
> > > this
> > > loader would not work although there's technically no reason
> > > since
> > > the
> > > platform only has one mmc. The call to spl_boot_device() could be
> > > replaced by the exact value here for platforms that only have one
> > > mmc. I
> > > don't know how to fix that, though.
> > > 
> > The main purpose here is to initialize the mmc driver. So which
> > storage
> > user wants to load the file is totally depend what storage such as
> > mmc
> > user defines in location->name. Loader would init the storage based
> > on
> > the storage defined in location->name before accessing it. Since
> > the
> > loader only support file system at this moment, i would suggest FAT
> > fs
> > for mmc and ubi fs for qspi.
> What I meant to say is this: at least on mach-socfpga, from reading
> the 
> code, I cannot load a file from mmc when booting from qspi, as 
> 'spl_boot_device' returns 'BOOT_DEVICE_SPI' in that case, although I 
> need to pass 'BOOT_DEVICE_MMC1' to 'spl_mmc_find_device'. Or am I
> wrong 
> here?
> 
Okay, i got you.

Yeah, you are right for use case if you need to load the file from mmc
during SPL boot and SPL is not loaded from mmc.

Since the spl_boot_device is platform dependent, you may try to add
some state machine so that this function can return correct device
type.

Secondly, you can use this function in U-Boot instead of SPL.

Lastly, i can declare __Weak to init_mmc, so that user can define their
own implementation.

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

Re: [U-Boot] u-boot-mmc fails on almost every Tegra board

[Jaehoon Chung]

On 01/23/2018 01:24 PM, Jaehoon Chung wrote:
> Hi Stephen,
> 
> On 01/23/2018 10:39 AM, Jaehoon Chung wrote:
>> Hi Stephen,
>>
>> On 01/23/2018 02:02 AM, Stephen Warren wrote:
>>> Jaehoon,
>>>
>>> The latest commit in u-boot-mmc.git master branch fails on almost every 
>>> Tegra board. The MMC device experiences an error during initialization and 
>>> hence isn't available:
>>
>> Thanks for reporting this. I'm not sure but it seems that relevant to my 
>> fixing patch.
>>
>> commit 9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
>> Author: Jaehoon Chung 
>> Date:   Wed Jan 17 19:36:58 2018 +0900
>>
>> mmc: fix the wrong disabling clock
>> 
>> When power is off, clock is not disabling.
>> Because it's passed to 1, mmc->clock should be set to f_min value.
>> Some drivers can't initialize the eMMC/SD card with current status.
>> 
>> This patch is to fix the disabling clock value to 0.
>> 
>> Fixes: 2e7410d76ad1 ("mmc: disable the mmc clock during power off")
>> 
>> Signed-off-by: Jaehoon Chung 
>> Reviewed-by: Jean-Jacques Hiblot 
>> Tested-by: Guillaume GARDET 
>> Tested-by: Anand Moon 
>>
>> Will check on today. And share the result. Thanks!
> 
> I reproduced this issue. i will send the patch for fixing. Thanks!

I sent the patch..refer to the below URL. If it's ok, let me know.

http://patchwork.ozlabs.org/patch/864607/

Best Regards,
Jaehoon Chung

> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> U-Boot 2018.01-05974-gb9b4f146c9 (Jan 22 2018 - 09:18:42 -0700), Build: 
>>> jenkins-u-boot-denx_uboot_mmc-master-build-U_BOOT_BOARD=p2371-2180-151
>>>
>>> TEGRA210
>>> Model: NVIDIA P2371-2180
>>> Board: NVIDIA P2371-2180
>>> DRAM:  3.5 GiB
>>> MMC:   sdhci@700b: 1, sdhci@700b0600: 0
>>> tegra_mmc_send_cmd_bounced: waiting for status update
>>> mmc_init: -110, time 1068
>>> *** Warning - No block device, using default environment
>>>
>>>
>>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

[U-Boot] [PATCH] mmc: fix to assign to corret clock value when clock is enabling

[Jaehoon Chung]

When clock is enabling, it's assigned to 0 as mmc->clock.
Then it can't initialize any card.
Fix to assign to correct clock value as mmc->cfg->f_min or f_max.

Fixes: 9546eb92cb6 ("mmc: fix the wrong disabling clock")

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 311f51f237..2d0e7bb3a2 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1501,7 +1501,7 @@ static int mmc_set_ios(struct mmc *mmc)
 
 int mmc_set_clock(struct mmc *mmc, uint clock, bool disable)
 {
-   if (!disable && clock != 0) {
+   if (!disable) {
if (clock > mmc->cfg->f_max)
clock = mmc->cfg->f_max;
 
-- 
2.15.1

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

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Mon, 2018-01-22 at 09:44 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Mon, 22 Jan 2018 07:11:37 + Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-01-18 at 12:12 +0100, Marek Vasut wrote:
> > > 
> > > On 01/18/2018 05:33 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Tue, 2018-01-16 at 15:41 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 12/27/2017 06:04 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > Whoa, this improved substantially since last time I checked.
> > > > > Minor
> > > > > nitpicks below.
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > +/* USB build is not supported yet in SPL */
> > > > > > +#ifndef CONFIG_SPL_BUILD
> > > > > > +#ifdef CONFIG_USB_STORAGE
> > > > > > +static int init_usb(void)
> > > > > > +{
> > > > > > +   int err;
> > > > > > +
> > > > > > +   err = usb_init();
> > > > > > +   if (err)
> > > > > > +   return err;
> > > > > > +
> > > > > > +#ifndef CONFIG_DM_USB
> > > > > > +   err = usb_stor_scan(1) < 0 ? -ENODEV : 0;
> > > > > if (err)
> > > > >   return err;
> > > > > ?
> > > > > 
> > > > This is last line code of the function, so it's always return
> > > > the
> > > > result regardless error or not.
> > > You are rewriting the true error code with -ENODEV instead of
> > > propagating it.
> > > 
> > Ohhare you saying to change the codes as shown in below:
> > 
> > err = usb_stor_scan(1);
> > if (err)
> > return err;
> > 
> usb_stor_scan() does not return a sensible error code, but '-1' if no
> device was found. This should be changed to -ENODEV then!
> 
Okay, so this should be fixed in usb_stor_scan() function.
> 
> Lothar Waßmann
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot-mmc fails on almost every Tegra board

[Jaehoon Chung]

Hi Stephen,

On 01/23/2018 10:39 AM, Jaehoon Chung wrote:
> Hi Stephen,
> 
> On 01/23/2018 02:02 AM, Stephen Warren wrote:
>> Jaehoon,
>>
>> The latest commit in u-boot-mmc.git master branch fails on almost every 
>> Tegra board. The MMC device experiences an error during initialization and 
>> hence isn't available:
> 
> Thanks for reporting this. I'm not sure but it seems that relevant to my 
> fixing patch.
> 
> commit 9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
> Author: Jaehoon Chung 
> Date:   Wed Jan 17 19:36:58 2018 +0900
> 
> mmc: fix the wrong disabling clock
> 
> When power is off, clock is not disabling.
> Because it's passed to 1, mmc->clock should be set to f_min value.
> Some drivers can't initialize the eMMC/SD card with current status.
> 
> This patch is to fix the disabling clock value to 0.
> 
> Fixes: 2e7410d76ad1 ("mmc: disable the mmc clock during power off")
> 
> Signed-off-by: Jaehoon Chung 
> Reviewed-by: Jean-Jacques Hiblot 
> Tested-by: Guillaume GARDET 
> Tested-by: Anand Moon 
> 
> Will check on today. And share the result. Thanks!

I reproduced this issue. i will send the patch for fixing. Thanks!

Best Regards,
Jaehoon Chung

> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> U-Boot 2018.01-05974-gb9b4f146c9 (Jan 22 2018 - 09:18:42 -0700), Build: 
>> jenkins-u-boot-denx_uboot_mmc-master-build-U_BOOT_BOARD=p2371-2180-151
>>
>> TEGRA210
>> Model: NVIDIA P2371-2180
>> Board: NVIDIA P2371-2180
>> DRAM:  3.5 GiB
>> MMC:   sdhci@700b: 1, sdhci@700b0600: 0
>> tegra_mmc_send_cmd_bounced: waiting for status update
>> mmc_init: -110, time 1068
>> *** Warning - No block device, using default environment
>>
>>
>>
> 
> ___
> 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] travis-ci: Add qemu-x86_64 target

[Tom Rini]

On Mon, Jan 22, 2018 at 08:11:54PM -0500, Tom Rini wrote:
> On Sat, Feb 11, 2017 at 10:44:05AM -0500, Tom Rini wrote:
> 
> > Add qemu-x86_64 to the list of targets we use for test.py runs.
> > 
> > Signed-off-by: Tom Rini 
> 
> Applied to u-boot/master, thanks!


But, sigh, breaks on the EFI network test, so reverted.

-- 
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] mmc: Poll for broken card detection case

[Jaehoon Chung]

On 01/23/2018 12:10 PM, Jun Nie wrote:
> 2018-01-23 10:00 GMT+08:00 Jaehoon Chung :
>> On 01/22/2018 09:21 PM, Jun Nie wrote:
>>> 2018-01-22 13:03 GMT+08:00 Jaehoon Chung :
 Hi,

 On 01/02/2018 01:25 PM, Jun Nie wrote:
> Poll for broken card detection case instead of return
> no card detected.

 Sorry for late. i didn't see this patch in my mailbox.

 Does it need to add the new config?
>>>
>>> Yes, a new config, CONFIG_MMC_BROKEN_CD is needed for board that does
>>> not support card detection pin. Not sure whether you mean this.
>>> Without this config, the logic is not changed so no board is impacted
>>> by this config.
>>
>> Right, there is no impacted by this config.
>> In Kernel, there is "broken-cd" property. So how about using 'broken-cd' 
>> property instead of adding config?
>>
>> Best Regards,
>> Jaehoon Chung
>>
> Some platforms, if not all, do not support DTB in SPL. So a config is
> better than dt node property.

Ok. It make sense...Will apply this patch to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Jun
>>>
>>> Jun
>>>

 Best Regards,
 Jaehoon Chung

>
> Signed-off-by: Jun Nie 
> ---
>  drivers/mmc/Kconfig | 5 +
>  drivers/mmc/mmc.c   | 4 
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 8fbeaa7..ed194a3 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -10,6 +10,11 @@ config MMC
> If you want MMC/SD/SDIO support, you should say Y here and
> also to your specific host controller driver.
>
> +config MMC_BROKEN_CD
> + bool "Poll for broken card detection case"
> + help
> +   If card  detection feature is broken, just poll to detect.
> +
>  config DM_MMC
>   bool "Enable MMC controllers using Driver Model"
>   depends on DM
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 38d2e07..13c5bf5 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1650,8 +1650,12 @@ int mmc_start_init(struct mmc *mmc)
>   bool no_card;
>   int err;
>
> +#if !defined(CONFIG_MMC_BROKEN_CD)
>   /* we pretend there's no card when init is NULL */
>   no_card = mmc_getcd(mmc) == 0;
> +#else
> + no_card = 0;
> +#endif
>  #if !CONFIG_IS_ENABLED(DM_MMC)
>   no_card = no_card || (mmc->cfg->ops->init == NULL);
>  #endif
>

>>>
>>>
>>>
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH] mmc: Poll for broken card detection case

[Jun Nie]

2018-01-23 10:00 GMT+08:00 Jaehoon Chung :
> On 01/22/2018 09:21 PM, Jun Nie wrote:
>> 2018-01-22 13:03 GMT+08:00 Jaehoon Chung :
>>> Hi,
>>>
>>> On 01/02/2018 01:25 PM, Jun Nie wrote:
 Poll for broken card detection case instead of return
 no card detected.
>>>
>>> Sorry for late. i didn't see this patch in my mailbox.
>>>
>>> Does it need to add the new config?
>>
>> Yes, a new config, CONFIG_MMC_BROKEN_CD is needed for board that does
>> not support card detection pin. Not sure whether you mean this.
>> Without this config, the logic is not changed so no board is impacted
>> by this config.
>
> Right, there is no impacted by this config.
> In Kernel, there is "broken-cd" property. So how about using 'broken-cd' 
> property instead of adding config?
>
> Best Regards,
> Jaehoon Chung
>
Some platforms, if not all, do not support DTB in SPL. So a config is
better than dt node property.

Jun
>>
>> Jun
>>
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>

 Signed-off-by: Jun Nie 
 ---
  drivers/mmc/Kconfig | 5 +
  drivers/mmc/mmc.c   | 4 
  2 files changed, 9 insertions(+)

 diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
 index 8fbeaa7..ed194a3 100644
 --- a/drivers/mmc/Kconfig
 +++ b/drivers/mmc/Kconfig
 @@ -10,6 +10,11 @@ config MMC
 If you want MMC/SD/SDIO support, you should say Y here and
 also to your specific host controller driver.

 +config MMC_BROKEN_CD
 + bool "Poll for broken card detection case"
 + help
 +   If card  detection feature is broken, just poll to detect.
 +
  config DM_MMC
   bool "Enable MMC controllers using Driver Model"
   depends on DM
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index 38d2e07..13c5bf5 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -1650,8 +1650,12 @@ int mmc_start_init(struct mmc *mmc)
   bool no_card;
   int err;

 +#if !defined(CONFIG_MMC_BROKEN_CD)
   /* we pretend there's no card when init is NULL */
   no_card = mmc_getcd(mmc) == 0;
 +#else
 + no_card = 0;
 +#endif
  #if !CONFIG_IS_ENABLED(DM_MMC)
   no_card = no_card || (mmc->cfg->ops->init == NULL);
  #endif

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

[U-Boot] [PATCH] arm64 :show_regs: show the real hardware register even after relocation

[Peng Fan]

Not only show the calculated value after relocation, also show
the real hardware register value.

Signed-off-by: Peng Fan 
Reported-by: Karl Beldan 
---
 arch/arm/lib/interrupts_64.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
index cbcfeec2b0..843d9fcd54 100644
--- a/arch/arm/lib/interrupts_64.c
+++ b/arch/arm/lib/interrupts_64.c
@@ -30,13 +30,14 @@ void show_regs(struct pt_regs *regs)
 {
int i;
 
+   printf("ELR: %lx\n", regs->elr);
+   printf("LR:  %lx\n", regs->regs[30]);
if (gd->flags & GD_FLG_RELOC) {
-   printf("ELR: %lx\n", regs->elr - gd->reloc_off);
-   printf("LR:  %lx\n", regs->regs[30] - gd->reloc_off);
-   } else {
-   printf("ELR: %lx\n", regs->elr);
-   printf("LR:  %lx\n", regs->regs[30]);
+   printf("reloc ELR: %lxlr: %lx\n",
+  regs->elr - gd->reloc_off,
+  regs->regs[30] - gd->reloc_off);
}
+
for (i = 0; i < 29; i += 2)
printf("x%-2d: %016lx x%-2d: %016lx\n",
   i, regs->regs[i], i+1, regs->regs[i+1]);
-- 
2.14.1

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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

On Mon, Jan 22, 2018 at 03:00:36PM +0100, Stefano Babic wrote:
>Hi Peng,
>
>On 10/01/2018 06:20, Peng Fan wrote:
>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>> DRAM.
>> 
>> The boot log with Arm trusted firmware console enabled:
>> "
>> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
>> PMIC:  PFUZE100 ID=0x10
>> Normal Boot
>> Trying to boot from MMC2
>> NOTICE:  Configureing TZASC380
>> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
>> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
>> NOTICE:  sip svc init
>> 
>> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
>> 
>> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
>> Reset cause: POR
>> Model: Freescale i.MX8MQ EVK
>> DRAM:  3 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> Using default environment
>> 
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> u-boot=>
>> "
>
>If I see the output here, I am expecting the setup forthe working
>peripherals. Without ethernet working, why do we activate FEC and set
>the PHY ?
>
>I would suggest to start with the minimal (=that is, all that is
>working), adding later when peripherals will be successfully added and
>tested.
>
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Fabio Estevam 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/dts/Makefile|2 +
>>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>>  board/freescale/mx8mq_evk/Kconfig|   12 +
>>  board/freescale/mx8mq_evk/Makefile   |   12 +
>>  board/freescale/mx8mq_evk/README |   47 +
>>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
>> ++
>>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>>  board/freescale/mx8mq_evk/spl.c  |  230 +
>>  configs/mx8mq_evk_defconfig  |   27 +
>>  include/configs/mx8mq_evk.h  |  269 ++
>>  14 files changed, 2819 insertions(+)
>>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>>  create mode 100644 board/freescale/mx8mq_evk/README
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>>  create mode 100644 configs/mx8mq_evk_defconfig
>>  create mode 100644 include/configs/mx8mq_evk.h
>> 
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index a895c70284..299107977f 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>>  
>>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>>  
>> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
>> +
>>  dtb-$(CONFIG_RCAR_GEN3) += \
>>  r8a7795-h3ulcb.dtb \
>>  r8a7795-salvator-x.dtb \
>> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts 
>> b/arch/arm/dts/fsl-imx8mq-evk.dts
>> new file mode 100644
>> index 00..f0aa3485e6
>> --- /dev/null
>> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
>> @@ -0,0 +1,424 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>> + * Copyright 2017 NXP
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/* First 128KB is for PSCI ATF. */
>> +/memreserve/ 0x4000 0x0002;
>> +
>> +#include "fsl-imx8mq.dtsi"
>> +
>> +/ {
>> +model = "Freescale i.MX8MQ EVK";
>> +compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
>> +
>> +chosen {
>> +bootargs = "console=ttymxc0,115200 
>> earlycon=ec_imx6q,0x3086,115200";
>> +};
>> +
>> +regulators {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +reg_usdhc2_vmmc: usdhc2_vmmc {
>> +compatible = "regulator-fixed";
>> +regulator-name = 

Re: [U-Boot] [PATCH 1/2] sunxi: fix i2c support for sunxi H3/H5

[Nuno Gonçalves]

I have tried for a while to make it work with DM_I2C but so far nothing.

=> i2c bus
Bus -1: i2c@01c2ac00
Bus -1: i2c@01c2b000
=> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  `-- soc
 usb[ + ]   ehci_sunxi  |-- usb@01c1b000
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 usb[ + ]   ohci_sunxi  |-- usb@01c1b400
 gpio   [ + ]   gpio_sunxi  |-- pinctrl@01c20800
 gpio   [ + ]   gpio_sunxi  |   |-- PA
 gpio   [ + ]   gpio_sunxi  |   |-- PB
 gpio   [ + ]   gpio_sunxi  |   |-- PC
 gpio   [ + ]   gpio_sunxi  |   |-- PD
 gpio   [ + ]   gpio_sunxi  |   |-- PE
 gpio   [ + ]   gpio_sunxi  |   |-- PF
 gpio   [ + ]   gpio_sunxi  |   |-- PG
 gpio   [ + ]   gpio_sunxi  |   |-- PH
 gpio   [ + ]   gpio_sunxi  |   `-- PI
 serial [ + ]   ns16550_se  |-- serial@01c28000
 i2c[   ]   i2c_mvtwsi  |-- i2c@01c2ac00
 i2c[   ]   i2c_mvtwsi  |-- i2c@01c2b000
 eth[ + ]   eth_sun8i_  |-- ethernet@1c3
 gpio   [ + ]   gpio_sunxi  `-- pinctrl@01f02c00
 gpio   [ + ]   gpio_sunxi  `-- PL

Is there any typical cause for this driver not to be probed?

Thanks

On Mon, Jan 22, 2018 at 10:18 AM, Nuno Gonçalves  wrote:
> On Fri, Jan 19, 2018 at 9:35 PM, Jernej Škrabec  
> wrote:
>> Hi,
>>
>> Dne petek, 19. januar 2018 ob 19:38:52 CET je Nuno Gonçalves napisal(a):
>>> Sorry, there is only 1 patch in this series.
>>>
>>> I would like comments regarding removing DM_I2C for MACH_SUNXI_H3_H5,
>>> as I didn't found a reason for it to be defined.
>>
>> there is good reason to be there. When H3/H5 board has DE2/HDMI enabled,
>> warning is shown when configuring, if DM_I2C is not selected. Since there
>> should be no warning, DM_I2C has to stay.
>>
>> This means that whatever you want to have attached to I2C, you have to have 
>> an
>> entry in DT for it. Since there is no DM pinctrl driver, you have to put code
>> somewhere, like you already done.
>>
>> Besides, U-Boot wants to migrate towards DM drivers, no other way around. 
>> Last
>> time I checked, DM I2C driver for H3/H5 should work, although it wasn't
>> thoroughly tested from my side. So if there are issues with DM I2C driver, 
>> you
>> have to fix it.
>>
>> Best regards,
>> Jernej
>>
>
> Thanks Jernej. In fact I didn't manage to get it working with DM_I2C,
> even after adding the devices to the DT.
>
> Maybe you can give me some hints to bring it to work, as I am a uboot ousider.
>
> Is DM_I2C_COMPAT supposed to be defined?
>
> The i2c device should be in the DT but since there is no pinctrl
> driver I must also include the  "sunxi_gpio_set_cfgpin()" already in
> my patch?
>
> Thanks,
> Nuno
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: Poll for broken card detection case

[Jaehoon Chung]

On 01/22/2018 09:21 PM, Jun Nie wrote:
> 2018-01-22 13:03 GMT+08:00 Jaehoon Chung :
>> Hi,
>>
>> On 01/02/2018 01:25 PM, Jun Nie wrote:
>>> Poll for broken card detection case instead of return
>>> no card detected.
>>
>> Sorry for late. i didn't see this patch in my mailbox.
>>
>> Does it need to add the new config?
> 
> Yes, a new config, CONFIG_MMC_BROKEN_CD is needed for board that does
> not support card detection pin. Not sure whether you mean this.
> Without this config, the logic is not changed so no board is impacted
> by this config.

Right, there is no impacted by this config.
In Kernel, there is "broken-cd" property. So how about using 'broken-cd' 
property instead of adding config?

Best Regards,
Jaehoon Chung

> 
> Jun
> 
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Signed-off-by: Jun Nie 
>>> ---
>>>  drivers/mmc/Kconfig | 5 +
>>>  drivers/mmc/mmc.c   | 4 
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index 8fbeaa7..ed194a3 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -10,6 +10,11 @@ config MMC
>>> If you want MMC/SD/SDIO support, you should say Y here and
>>> also to your specific host controller driver.
>>>
>>> +config MMC_BROKEN_CD
>>> + bool "Poll for broken card detection case"
>>> + help
>>> +   If card  detection feature is broken, just poll to detect.
>>> +
>>>  config DM_MMC
>>>   bool "Enable MMC controllers using Driver Model"
>>>   depends on DM
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 38d2e07..13c5bf5 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -1650,8 +1650,12 @@ int mmc_start_init(struct mmc *mmc)
>>>   bool no_card;
>>>   int err;
>>>
>>> +#if !defined(CONFIG_MMC_BROKEN_CD)
>>>   /* we pretend there's no card when init is NULL */
>>>   no_card = mmc_getcd(mmc) == 0;
>>> +#else
>>> + no_card = 0;
>>> +#endif
>>>  #if !CONFIG_IS_ENABLED(DM_MMC)
>>>   no_card = no_card || (mmc->cfg->ops->init == NULL);
>>>  #endif
>>>
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Hi Stefano,
On Mon, Jan 22, 2018 at 01:13:17PM +0100, Stefano Babic wrote:
>Hi Peng,
>
>On 10/01/2018 06:20, Peng Fan wrote:
>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>> DRAM.
>> 
>> The boot log with Arm trusted firmware console enabled:
>> "
>> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
>> PMIC:  PFUZE100 ID=0x10
>> Normal Boot
>> Trying to boot from MMC2
>> NOTICE:  Configureing TZASC380
>> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
>> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
>> NOTICE:  sip svc init
>> 
>> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
>> 
>> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
>> Reset cause: POR
>> Model: Freescale i.MX8MQ EVK
>> DRAM:  3 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> Using default environment
>> 
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> u-boot=>
>> "
>
>If I see the output here, I am expecting the setup forthe working
>peripherals. Without ethernet working, why do we activate FEC and set
>the PHY ?
>
>I would suggest to start with the minimal (=that is, all that is
>working), adding later when peripherals will be successfully added and
>tested.

ok. I'll minimize the changes.

>
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Fabio Estevam 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/dts/Makefile|2 +
>>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>>  board/freescale/mx8mq_evk/Kconfig|   12 +
>>  board/freescale/mx8mq_evk/Makefile   |   12 +
>>  board/freescale/mx8mq_evk/README |   47 +
>>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
>> ++
>>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>>  board/freescale/mx8mq_evk/spl.c  |  230 +
>>  configs/mx8mq_evk_defconfig  |   27 +
>>  include/configs/mx8mq_evk.h  |  269 ++
>>  14 files changed, 2819 insertions(+)
>>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>>  create mode 100644 board/freescale/mx8mq_evk/README
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>>  create mode 100644 configs/mx8mq_evk_defconfig
>>  create mode 100644 include/configs/mx8mq_evk.h
>> 
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index a895c70284..299107977f 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>>  
>>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>>  
>> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
>> +
>>  dtb-$(CONFIG_RCAR_GEN3) += \
>>  r8a7795-h3ulcb.dtb \
>>  r8a7795-salvator-x.dtb \
>> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts 
>> b/arch/arm/dts/fsl-imx8mq-evk.dts
>> new file mode 100644
>> index 00..f0aa3485e6
>> --- /dev/null
>> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
>> @@ -0,0 +1,424 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>> + * Copyright 2017 NXP
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/* First 128KB is for PSCI ATF. */
>> +/memreserve/ 0x4000 0x0002;
>> +
>> +#include "fsl-imx8mq.dtsi"
>> +
>> +/ {
>> +model = "Freescale i.MX8MQ EVK";
>> +compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
>> +
>> +chosen {
>> +bootargs = "console=ttymxc0,115200 
>> earlycon=ec_imx6q,0x3086,115200";
>> +};
>> +
>> +regulators {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +reg_usdhc2_vmmc: usdhc2_vmmc {
>> +compatible = "regulator-fixed";
>> 

Re: [U-Boot] [RFC PATCH] mmc: Skipping the MMC initialization at the boot time

[Jaehoon Chung]

Hi Siva,

On 01/22/2018 08:03 PM, Siva Durga Prasad Paladugu wrote:
> Hi Jaehoon,
> 
>> -Original Message-
>> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>> Sent: Thursday, January 18, 2018 1:46 PM
>> To: Siva Durga Prasad Paladugu ; u-
>> b...@lists.denx.de
>> Cc: Vipul Kumar ; Vipul Kumar ;
>> Siva Durga Prasad Paladugu 
>> Subject: Re: [RFC PATCH] mmc: Skipping the MMC initialization at the boot
>> time
>>
>> On 01/18/2018 02:40 PM, Siva Durga Prasad Paladugu wrote:
>>> From: Vipul Kumar 
>>>
>>> By enabling CONFIG_SKIP_EARLY_MMC_INIT config, user can skip the
>> MMC
>>> initialization at the boot time. After getting the u-boot console,
>>> user can select the device using mmc dev and can communicate with that.
>>> This is useful where user don't want to perform mmc initialization
>>> while booting and can do explicitly later as per choice.
>>
>> Is there any use-case? What benefit can user have with this config?
>> According to commit-msg, user will choose the mmc device later.
>> Is it same with initializing at booting time?
> Yes, there may be case, where we have both controllers enabled but user would 
> like to
> Communicate with only one at u-boot and this selection also depends on 
> environment
> Or something which will be updated from external world then in this case, 
> user will initialize
> Later as per his wish. This may save bootime as it initializes only the 
> required one and choice of 
> which one to initialize

Then did you check how much time can save? 
If user want to save the booting time, will not enter to uboot console?
Well..I didn't agree about saving the booting time.

If you need to add this config, could you explain in more detail.
And how many board do enable this config in ./configs/ ?

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Siva
> 
>>
>>>
>>> Signed-off-by: Vipul Kumar 
>>> Signed-off-by: Siva Durga Prasad Paladugu 
>>> ---
>>>  common/board_r.c| 4 ++--
>>>  drivers/mmc/Kconfig | 7 +++
>>>  2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/common/board_r.c b/common/board_r.c index
>>> 2a9df6b..8727b93 100644
>>> --- a/common/board_r.c
>>> +++ b/common/board_r.c
>>> @@ -421,7 +421,7 @@ static int initr_onenand(void)  }  #endif
>>>
>>> -#ifdef CONFIG_MMC
>>> +#if defined(CONFIG_MMC) &&
>> !defined(CONFIG_SKIP_EARLY_MMC_INIT)
>>>  static int initr_mmc(void)
>>>  {
>>> puts("MMC:   ");
>>> @@ -768,7 +768,7 @@ static init_fnc_t init_sequence_r[] = {  #ifdef
>>> CONFIG_CMD_ONENAND
>>> initr_onenand,
>>>  #endif
>>> -#ifdef CONFIG_MMC
>>> +#if defined(CONFIG_MMC) &&
>> !defined(CONFIG_SKIP_EARLY_MMC_INIT)
>>> initr_mmc,
>>>  #endif
>>> initr_env,
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
>>> ab0627a..05b1503 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -40,6 +40,13 @@ config SPL_DM_MMC
>>>
>>>  if MMC
>>>
>>> +config SKIP_EARLY_MMC_INIT
>>> +   bool "Skip the MMC initialization at boot time"
>>> +   help
>>> + Skip the MMC initialization at the boot time. After getting the u-
>> boot
>>> + console, user need to set mmc device and after setting the mmc
>> dev, user
>>> + can communicate with that device.
>>> +
>>>  config ARM_PL180_MMCI
>>> bool "ARM AMBA Multimedia Card Interface and compatible
>> support"
>>> depends on DM_MMC && OF_CONTROL
>>> --
>>> 2.7.4
>>>
>>> This email and any attachments are intended for the sole use of the
>> named recipient(s) and contain(s) confidential information that may be
>> proprietary, privileged or copyrighted under applicable law. If you are not
>> the intended recipient, do not read, copy, or forward this email message or
>> any attachments. Delete this email message and any attachments
>> immediately.
>>>
>>>
>>>
> 

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

Re: [U-Boot] mmc: disable UHS modes if Vcc cannot be switched on and off

[Jaehoon Chung]

On 01/23/2018 03:38 AM, Eugeniy Paltsev wrote:
> Hi Jean-Jacques,
> 
> after commit "mmc: disable UHS modes if Vcc cannot be switched on and off" 
> (04a2ea248f)
> we got MMC broken on several (at least two) platforms with DesignWare MMC 
> controller.
> 
> The error log (with debug enabled in drivers/mmc/mmc.c and 
> drivers/mmc/dw_mmc.c) is next:
> --->8-
> MMC:   Synopsys Mobile storage: 0
> Buswidth = 0, clock: 40
> selecting mode MMC legacy (freq : 0 MHz)
> Buswidth = 1, clock: 40
> Buswidth = 1, clock: 40
> Sending CMD0
> dwmci_send_cmd: Timeout.
> mmc_init: -110, time 19
> ** Bad device mmc 0 **
> --->8-
> 
> Any ideas how to fix this?

Could you share which git repository you use? 

Best Regards,
Jaehoon Chung

> 
> Thanks.
> 

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

Re: [U-Boot] u-boot-mmc fails on almost every Tegra board

[Jaehoon Chung]

Hi Stephen,

On 01/23/2018 02:02 AM, Stephen Warren wrote:
> Jaehoon,
> 
> The latest commit in u-boot-mmc.git master branch fails on almost every Tegra 
> board. The MMC device experiences an error during initialization and hence 
> isn't available:

Thanks for reporting this. I'm not sure but it seems that relevant to my fixing 
patch.

commit 9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
Author: Jaehoon Chung 
Date:   Wed Jan 17 19:36:58 2018 +0900

mmc: fix the wrong disabling clock

When power is off, clock is not disabling.
Because it's passed to 1, mmc->clock should be set to f_min value.
Some drivers can't initialize the eMMC/SD card with current status.

This patch is to fix the disabling clock value to 0.

Fixes: 2e7410d76ad1 ("mmc: disable the mmc clock during power off")

Signed-off-by: Jaehoon Chung 
Reviewed-by: Jean-Jacques Hiblot 
Tested-by: Guillaume GARDET 
Tested-by: Anand Moon 

Will check on today. And share the result. Thanks!

Best Regards,
Jaehoon Chung

> 
> U-Boot 2018.01-05974-gb9b4f146c9 (Jan 22 2018 - 09:18:42 -0700), Build: 
> jenkins-u-boot-denx_uboot_mmc-master-build-U_BOOT_BOARD=p2371-2180-151
> 
> TEGRA210
> Model: NVIDIA P2371-2180
> Board: NVIDIA P2371-2180
> DRAM:  3.5 GiB
> MMC:   sdhci@700b: 1, sdhci@700b0600: 0
> tegra_mmc_send_cmd_bounced: waiting for status update
> mmc_init: -110, time 1068
> *** Warning - No block device, using default environment
> 
> 
> 

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

Re: [U-Boot] travis-ci: Add qemu-x86_64 target

[Tom Rini]

On Sat, Feb 11, 2017 at 10:44:05AM -0500, Tom Rini wrote:

> Add qemu-x86_64 to the list of targets we use for test.py runs.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,5/5] fs: fat: Drop CONFIG_SUPPORT_VFAT

[Tom Rini]

On Fri, Jan 05, 2018 at 02:45:21AM +0200, Tuomas Tynkkynen wrote:

> fat.h unconditionally defines CONFIG_SUPPORT_VFAT (and has done since
> 2003), so as a result VFAT support is always enabled regardless of
> whether a board config defines it or not. Drop this unnecessary option.
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,3/5] env: ENV_IS_IN_FAT improvements

[Tom Rini]

On Fri, Jan 05, 2018 at 02:45:19AM +0200, Tuomas Tynkkynen wrote:

> Make it select FS_FAT as well, because if it's not selected, enabling
> ENV_IS_IN_FAT causes a Kconfig warning:
> 
> warning: (ENV_IS_IN_FAT) selects FAT_WRITE which has unmet direct 
> dependencies (FS_FAT)
> 
> This also allows dropping some code from config_fallbacks.
> 
> Also drop the unnecessary help text about having to enable
> CONFIG_FAT_WRITE - Kconfig automatically handles that.
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/3] Convert CONFIG_TWL4030_USB to Kconfig

[Tom Rini]

On Tue, Jan 02, 2018 at 10:38:36AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_TWL4030_USB
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 3/3] Convert CONFIG_ROCKCHIP_USB2_PHY to Kconfig

[Tom Rini]

On Tue, Jan 02, 2018 at 10:39:52AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_ROCKCHIP_USB2_PHY
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/5] fs: Migrate ext4 to Kconfig

[Tom Rini]

On Fri, Jan 05, 2018 at 02:45:17AM +0200, Tuomas Tynkkynen wrote:

> Migrate the following symbols to Kconfig:
> 
> CONFIG_FS_EXT4
> CONFIG_EXT4_WRITE
> 
> The definitions in config_fallbacks.h can now be expressed in Kconfig.
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 4/5] fs: FAT: Fix typo in FS_FAT_MAX_CLUSTSIZE description

[Tom Rini]

On Fri, Jan 05, 2018 at 02:45:20AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,2/3] Convert CONFIG_OMAP_USB_PHY to Kconfig

[Tom Rini]

On Tue, Jan 02, 2018 at 10:39:21AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_OMAP_USB_PHY
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 2/5] ARM: poplar: Use Kconfig to enable CONFIG_FAT_WRITE

[Tom Rini]

On Fri, Jan 05, 2018 at 02:45:18AM +0200, Tuomas Tynkkynen wrote:

> The symbol's been converted to Kconfig for a while, poplar is the only
> one #defining it.
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,V5] Convert CONFIG_SOC_DA8XX et al to Kconfig

[Tom Rini]

On Thu, Jan 11, 2018 at 08:20:27AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_SOC_DA8XX
>CONFIG_SOC_DA850
>CONFIG_DA850_LOWLEVEL
>CONFIG_MACH_DAVINCI_DA850_EVM
>CONFIG_SYS_DA850_PLL_INIT
>CONFIG_SYS_DA850_DDR_INIT
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: David Lechner

With the README text left in, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Convert CONFIG_USB_MUSB_HCD et al to Kconfig

[Tom Rini]

On Fri, Dec 29, 2017 at 09:15:41AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_USB_MUSB_HCD
>CONFIG_USB_MUSB_UDC
>CONFIG_USB_DAVINCI
>CONFIG_USB_OMAP3
>CONFIG_USB_DA8XX
>CONFIG_USB_AM35X
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Convert CONFIG_DAVINCI_SPI to Kconfig

[Tom Rini]

On Sat, Dec 30, 2017 at 07:33:42AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_DAVINCI_SPI
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, V2] Convert CONFIG_USB_MUSB_OMAP2PLUS et al to Kconfig

[Tom Rini]

On Fri, Dec 29, 2017 at 08:16:05AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_USB_MUSB_OMAP2PLUS
>CONFIG_USB_MUSB_AM35X
>CONFIG_USB_MUSB_DSPS
>CONFIG_USB_MUSB_PIO_ONLY
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] ARM: omap3_logic: Enable SPL_OF_CONTROL and SPL_OF_PLATDATA

[Tom Rini]

On Wed, Dec 27, 2017 at 01:39:56PM -0600, Adam Ford wrote:

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

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] UDP packet sender

[Joe Hershberger]

On Mon, Jan 22, 2018 at 5:28 PM, Gaëtan Carlier  wrote:
> Hi Joe,
>
> On 01/22/2018 11:46 PM, Joe Hershberger wrote:
>> Hi Gaëtan,
>>
>> On Thu, Jan 18, 2018 at 4:56 AM, Gaëtan Carlier  wrote:
>>> Hi,
>>> I would like to implement a new command and submit it to the mailing list.
>>> The command will have the following format:
>>> udpsend>> to send>
>>>
>>> udpsend 255.255.255.255 4040 0 hello world
>>>
>>> If source port is 0, a random port will be used (11000 + (get_timer(0) % 
>>> 4096))
>>
>> I'd like to understand the purpose / use-case for this command? Maybe
>> there is a more appropriate way to solve the problem you have instead.
>>
>
> I want to send the current progression of an update script. As the board has 
> no display/leds, the only way to get update progression is to broadcast UDP 
> packet that a PC software will monitor. U-Boot will load/source a script from 
> an ext4 partition. This script will load a rootfs image from update partition 
> of an eMMC splitted into 10M chunks that will be written to an other 
> partition of the eMMC.
> This is for update on site (by customer).
>
> This UDP command will also be used in a closed production LAN to send Unique 
> ID of the CPU (secret) and the MAC address to the monitoring production 
> (burning) software that will feed a database to be able to generate license 
> keys linked to hardware and print a label with the product name and the MAC 
> address.
>
> Maybe there is already existing command that I can use from a U-Boot script ?

I think this is commonly done by enabling netconsole and controlling /
monitoring progress based on console output sent over UDP.

Cheers,
-Joe

>>> Where do I have to place my code : cmd or net directory ?
>>> For me cmd will be the better directory to keep it away from all more 
>>> complex stuff like DHCP, TFTP, ...
>>
>> That's probably true. cmd/ would be the appropriate place.
>>
>> -Joe
>>
>
> Regards,
> Gaëtan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UDP packet sender

[Gaëtan Carlier]

Hi Joe,

On 01/22/2018 11:46 PM, Joe Hershberger wrote:
> Hi Gaëtan,
> 
> On Thu, Jan 18, 2018 at 4:56 AM, Gaëtan Carlier  wrote:
>> Hi,
>> I would like to implement a new command and submit it to the mailing list.
>> The command will have the following format:
>> udpsend> send>
>>
>> udpsend 255.255.255.255 4040 0 hello world
>>
>> If source port is 0, a random port will be used (11000 + (get_timer(0) % 
>> 4096))
> 
> I'd like to understand the purpose / use-case for this command? Maybe
> there is a more appropriate way to solve the problem you have instead.
> 

I want to send the current progression of an update script. As the board has no 
display/leds, the only way to get update progression is to broadcast UDP packet 
that a PC software will monitor. U-Boot will load/source a script from an ext4 
partition. This script will load a rootfs image from update partition of an 
eMMC splitted into 10M chunks that will be written to an other partition of the 
eMMC.
This is for update on site (by customer).

This UDP command will also be used in a closed production LAN to send Unique ID 
of the CPU (secret) and the MAC address to the monitoring production (burning) 
software that will feed a database to be able to generate license keys linked 
to hardware and print a label with the product name and the MAC address.

Maybe there is already existing command that I can use from a U-Boot script ?

>> Where do I have to place my code : cmd or net directory ?
>> For me cmd will be the better directory to keep it away from all more 
>> complex stuff like DHCP, TFTP, ...
> 
> That's probably true. cmd/ would be the appropriate place.
> 
> -Joe
> 

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

[U-Boot] [PATCH v2] Convert CONFIG_SYS_BOOT_GET_{CMDLINE, KBD} to Kconfig

[Derald D. Woods]

This converts the following to Kconfig:
CONFIG_SYS_BOOT_GET_CMDLINE
CONFIG_SYS_BOOT_GET_KBD

Signed-off-by: Derald D. Woods 
---
v2:
- Drop selection for ARM

---
 Kconfig   | 12 
 arch/Kconfig  |  4 
 arch/m68k/include/asm/config.h|  2 --
 arch/powerpc/include/asm/config.h |  2 --
 scripts/config_whitelist.txt  |  2 --
 5 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index 9b8a807799..f713c6a9b1 100644
--- a/Kconfig
+++ b/Kconfig
@@ -83,6 +83,18 @@ config DISTRO_DEFAULTS
  Select this to enable various options and commands which are suitable
  for building u-boot for booting general purpose Linux distributions.
 
+config SYS_BOOT_GET_CMDLINE
+   bool "Enable kernel command line setup"
+   help
+ Enables allocating and saving kernel cmdline in space between
+ "bootm_low" and "bootm_low" + BOOTMAPSZ.
+
+config SYS_BOOT_GET_KBD
+   bool "Enable kernel board information setup"
+   help
+ Enables allocating and saving a kernel copy of the bd_info in
+ space between "bootm_low" and "bootm_low" + BOOTMAPSZ.
+
 config SYS_MALLOC_F
bool "Enable malloc() pool before relocation"
default y if DM
diff --git a/arch/Kconfig b/arch/Kconfig
index 762230cd56..5d57d6da2c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -26,6 +26,8 @@ config ARM
 config M68K
bool "M68000 architecture"
select HAVE_PRIVATE_LIBGCC
+   select SYS_BOOT_GET_CMDLINE
+   select SYS_BOOT_GET_KBD
 
 config MICROBLAZE
bool "MicroBlaze architecture"
@@ -53,6 +55,8 @@ config PPC
bool "PowerPC architecture"
select HAVE_PRIVATE_LIBGCC
select SUPPORT_OF_CONTROL
+   select SYS_BOOT_GET_CMDLINE
+   select SYS_BOOT_GET_KBD
 
 config RISCV
bool "riscv architecture"
diff --git a/arch/m68k/include/asm/config.h b/arch/m68k/include/asm/config.h
index 9c4d3fb8fd..fd0b5513ee 100644
--- a/arch/m68k/include/asm/config.h
+++ b/arch/m68k/include/asm/config.h
@@ -11,7 +11,5 @@
 
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
-#define CONFIG_SYS_BOOT_GET_CMDLINE
-#define CONFIG_SYS_BOOT_GET_KBD
 
 #endif
diff --git a/arch/powerpc/include/asm/config.h 
b/arch/powerpc/include/asm/config.h
index 6aec815c71..67e4b48a96 100644
--- a/arch/powerpc/include/asm/config.h
+++ b/arch/powerpc/include/asm/config.h
@@ -31,8 +31,6 @@
 
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
-#define CONFIG_SYS_BOOT_GET_CMDLINE
-#define CONFIG_SYS_BOOT_GET_KBD
 
 #ifndef CONFIG_MAX_MEM_MAPPED
 #ifdefined(CONFIG_E500)|| \
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index c98f262079..6e9750eb16 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -2273,8 +2273,6 @@ CONFIG_SYS_BOOTM_LEN
 CONFIG_SYS_BOOTPARAMS_LEN
 CONFIG_SYS_BOOTSZ
 CONFIG_SYS_BOOT_BLOCK
-CONFIG_SYS_BOOT_GET_CMDLINE
-CONFIG_SYS_BOOT_GET_KBD
 CONFIG_SYS_BOOT_RAMDISK_HIGH
 CONFIG_SYS_BR0_64M
 CONFIG_SYS_BR0_8M
-- 
2.16.0

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

Re: [U-Boot] UDP packet sender

[Joe Hershberger]

Hi Gaëtan,

On Thu, Jan 18, 2018 at 4:56 AM, Gaëtan Carlier  wrote:
> Hi,
> I would like to implement a new command and submit it to the mailing list.
> The command will have the following format:
> udpsend send>
>
> udpsend 255.255.255.255 4040 0 hello world
>
> If source port is 0, a random port will be used (11000 + (get_timer(0) % 
> 4096))

I'd like to understand the purpose / use-case for this command? Maybe
there is a more appropriate way to solve the problem you have instead.

> Where do I have to place my code : cmd or net directory ?
> For me cmd will be the better directory to keep it away from all more complex 
> stuff like DHCP, TFTP, ...

That's probably true. cmd/ would be the appropriate place.

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

Re: [U-Boot] [U-Boot, V3] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

[Tom Rini]

On Mon, Jan 22, 2018 at 04:27:32PM -0600, Adam Ford wrote:
> On Mon, Jan 22, 2018 at 4:12 PM, Tom Rini  wrote:
> > On Mon, Jan 22, 2018 at 04:07:44PM -0600, Adam Ford wrote:
> >> On Mon, Jan 22, 2018 at 3:30 PM, Tom Rini  wrote:
> >> > On Fri, Jan 12, 2018 at 07:26:06AM -0600, Adam Ford wrote:
> >> >
> >> >> This converts the following to Kconfig:
> >> >>CONFIG_SYS_DV_CLKMODE
> >> >>CONFIG_SYS_DA850_PLL0_POSTDIV
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV1
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV2
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV3
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV4
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV5
> >> >>CONFIG_SYS_DA850_PLL0_PLLDIV7
> >> >>CONFIG_SYS_DA850_PLL1_POSTDIV
> >> >>CONFIG_SYS_DA850_PLL1_PLLDIV1
> >> >>CONFIG_SYS_DA850_PLL1_PLLDIV2
> >> >>CONFIG_SYS_DA850_PLL1_PLLDIV3
> >> >>
> >> >> Signed-off-by: Adam Ford 
> >> >> Reviewed-by: David Lechner 
> >> >> ---
> >> >> Changes in V3:
> >> >>   Using the L138 Technical Reference manual, I changed the names to 
> >> >> match
> >> >> the descriptions of the registers as listed in Table 8-2 and 
> >> >> 8-3 of the
> >> >> PLL Control 0 and PLL Control 1 Registers.
> >> >> V2:
> >> >> Expand Kconfig help definitions to give a small explanation of 
> >> >> options
> >> >> V1:
> >> >> This patch is a continuation of Convert CONFIG_SOC_DA8XX et al
> >> >> This also showed warnings when used with the legoev3_defconfig, however
> >> >> it seems like the ev3 board was defining things in the header it didn't 
> >> >> need
> >> >> since it doesn't seem to be building da850_lowlevel.c.  I don't have the
> >> >> hardware to test that board.
> >> >>
> >> >>  arch/arm/mach-davinci/Kconfig   | 85 
> >> >> -
> >> >>  configs/omapl138_lcdk_defconfig |  1 +
> >> >>  include/configs/calimain.h  | 13 ---
> >> >>  include/configs/da850evm.h  | 13 ---
> >> >>  include/configs/ipam390.h   | 13 ---
> >> >>  include/configs/legoev3.h   | 13 ---
> >> >>  include/configs/omapl138_lcdk.h | 13 ---
> >> >>  scripts/config_whitelist.txt| 12 --
> >> >>  8 files changed, 85 insertions(+), 78 deletions(-)
> >> >
> >> > [patchwork link is https://patchwork.ozlabs.org/patch/859919/]
> >> >
> >> > First, this should also cover CONFIG_SYS_DA850_PLL0_PLLM which shouldn't
> >> > be too bad.
> >> >
> >> > Second, this needs to deal with calimain, which has both
> >> > CONFIG_SYS_DA850_PLL1_PLLM and CONFIG_SYS_DA850_PLL0_PLLM as dynamic.
> >> > Ideas?  Thanks!
> >> >
> >> Can we push the low-hanging fruit and come back and revisit the rest
> >> at a later date?   My goal was just try and clean up a bunch of config
> >> files.
> >
> > Yeah, please respin a v4 that drops out CONFIG_SYS_DA850_PLL1_PLLM for
> > now, thanks!
> 
> Since it was a continuation of Convert CONFIG_SOC_DA8XX et al have you
> had a chance to review that patch?   If not, I'd like to wait until
> it's ready so I can rebuild this off any changes from the Convert
> CONFIG_SOC_DA8XX et al  patch.

In build-tests now, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, V3] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

[Adam Ford]

On Mon, Jan 22, 2018 at 4:12 PM, Tom Rini  wrote:
> On Mon, Jan 22, 2018 at 04:07:44PM -0600, Adam Ford wrote:
>> On Mon, Jan 22, 2018 at 3:30 PM, Tom Rini  wrote:
>> > On Fri, Jan 12, 2018 at 07:26:06AM -0600, Adam Ford wrote:
>> >
>> >> This converts the following to Kconfig:
>> >>CONFIG_SYS_DV_CLKMODE
>> >>CONFIG_SYS_DA850_PLL0_POSTDIV
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV1
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV2
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV3
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV4
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV5
>> >>CONFIG_SYS_DA850_PLL0_PLLDIV7
>> >>CONFIG_SYS_DA850_PLL1_POSTDIV
>> >>CONFIG_SYS_DA850_PLL1_PLLDIV1
>> >>CONFIG_SYS_DA850_PLL1_PLLDIV2
>> >>CONFIG_SYS_DA850_PLL1_PLLDIV3
>> >>
>> >> Signed-off-by: Adam Ford 
>> >> Reviewed-by: David Lechner 
>> >> ---
>> >> Changes in V3:
>> >>   Using the L138 Technical Reference manual, I changed the names to 
>> >> match
>> >> the descriptions of the registers as listed in Table 8-2 and 8-3 
>> >> of the
>> >> PLL Control 0 and PLL Control 1 Registers.
>> >> V2:
>> >> Expand Kconfig help definitions to give a small explanation of 
>> >> options
>> >> V1:
>> >> This patch is a continuation of Convert CONFIG_SOC_DA8XX et al
>> >> This also showed warnings when used with the legoev3_defconfig, however
>> >> it seems like the ev3 board was defining things in the header it didn't 
>> >> need
>> >> since it doesn't seem to be building da850_lowlevel.c.  I don't have the
>> >> hardware to test that board.
>> >>
>> >>  arch/arm/mach-davinci/Kconfig   | 85 
>> >> -
>> >>  configs/omapl138_lcdk_defconfig |  1 +
>> >>  include/configs/calimain.h  | 13 ---
>> >>  include/configs/da850evm.h  | 13 ---
>> >>  include/configs/ipam390.h   | 13 ---
>> >>  include/configs/legoev3.h   | 13 ---
>> >>  include/configs/omapl138_lcdk.h | 13 ---
>> >>  scripts/config_whitelist.txt| 12 --
>> >>  8 files changed, 85 insertions(+), 78 deletions(-)
>> >
>> > [patchwork link is https://patchwork.ozlabs.org/patch/859919/]
>> >
>> > First, this should also cover CONFIG_SYS_DA850_PLL0_PLLM which shouldn't
>> > be too bad.
>> >
>> > Second, this needs to deal with calimain, which has both
>> > CONFIG_SYS_DA850_PLL1_PLLM and CONFIG_SYS_DA850_PLL0_PLLM as dynamic.
>> > Ideas?  Thanks!
>> >
>> Can we push the low-hanging fruit and come back and revisit the rest
>> at a later date?   My goal was just try and clean up a bunch of config
>> files.
>
> Yeah, please respin a v4 that drops out CONFIG_SYS_DA850_PLL1_PLLM for
> now, thanks!

Since it was a continuation of Convert CONFIG_SOC_DA8XX et al have you
had a chance to review that patch?   If not, I'd like to wait until
it's ready so I can rebuild this off any changes from the Convert
CONFIG_SOC_DA8XX et al  patch.

thanks

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

Re: [U-Boot] [U-Boot, V3] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

[Tom Rini]

On Mon, Jan 22, 2018 at 04:07:44PM -0600, Adam Ford wrote:
> On Mon, Jan 22, 2018 at 3:30 PM, Tom Rini  wrote:
> > On Fri, Jan 12, 2018 at 07:26:06AM -0600, Adam Ford wrote:
> >
> >> This converts the following to Kconfig:
> >>CONFIG_SYS_DV_CLKMODE
> >>CONFIG_SYS_DA850_PLL0_POSTDIV
> >>CONFIG_SYS_DA850_PLL0_PLLDIV1
> >>CONFIG_SYS_DA850_PLL0_PLLDIV2
> >>CONFIG_SYS_DA850_PLL0_PLLDIV3
> >>CONFIG_SYS_DA850_PLL0_PLLDIV4
> >>CONFIG_SYS_DA850_PLL0_PLLDIV5
> >>CONFIG_SYS_DA850_PLL0_PLLDIV7
> >>CONFIG_SYS_DA850_PLL1_POSTDIV
> >>CONFIG_SYS_DA850_PLL1_PLLDIV1
> >>CONFIG_SYS_DA850_PLL1_PLLDIV2
> >>CONFIG_SYS_DA850_PLL1_PLLDIV3
> >>
> >> Signed-off-by: Adam Ford 
> >> Reviewed-by: David Lechner 
> >> ---
> >> Changes in V3:
> >>   Using the L138 Technical Reference manual, I changed the names to 
> >> match
> >> the descriptions of the registers as listed in Table 8-2 and 8-3 
> >> of the
> >> PLL Control 0 and PLL Control 1 Registers.
> >> V2:
> >> Expand Kconfig help definitions to give a small explanation of 
> >> options
> >> V1:
> >> This patch is a continuation of Convert CONFIG_SOC_DA8XX et al
> >> This also showed warnings when used with the legoev3_defconfig, however
> >> it seems like the ev3 board was defining things in the header it didn't 
> >> need
> >> since it doesn't seem to be building da850_lowlevel.c.  I don't have the
> >> hardware to test that board.
> >>
> >>  arch/arm/mach-davinci/Kconfig   | 85 
> >> -
> >>  configs/omapl138_lcdk_defconfig |  1 +
> >>  include/configs/calimain.h  | 13 ---
> >>  include/configs/da850evm.h  | 13 ---
> >>  include/configs/ipam390.h   | 13 ---
> >>  include/configs/legoev3.h   | 13 ---
> >>  include/configs/omapl138_lcdk.h | 13 ---
> >>  scripts/config_whitelist.txt| 12 --
> >>  8 files changed, 85 insertions(+), 78 deletions(-)
> >
> > [patchwork link is https://patchwork.ozlabs.org/patch/859919/]
> >
> > First, this should also cover CONFIG_SYS_DA850_PLL0_PLLM which shouldn't
> > be too bad.
> >
> > Second, this needs to deal with calimain, which has both
> > CONFIG_SYS_DA850_PLL1_PLLM and CONFIG_SYS_DA850_PLL0_PLLM as dynamic.
> > Ideas?  Thanks!
> >
> Can we push the low-hanging fruit and come back and revisit the rest
> at a later date?   My goal was just try and clean up a bunch of config
> files.

Yeah, please respin a v4 that drops out CONFIG_SYS_DA850_PLL1_PLLM for
now, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, V3] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

[Adam Ford]

On Mon, Jan 22, 2018 at 3:30 PM, Tom Rini  wrote:
> On Fri, Jan 12, 2018 at 07:26:06AM -0600, Adam Ford wrote:
>
>> This converts the following to Kconfig:
>>CONFIG_SYS_DV_CLKMODE
>>CONFIG_SYS_DA850_PLL0_POSTDIV
>>CONFIG_SYS_DA850_PLL0_PLLDIV1
>>CONFIG_SYS_DA850_PLL0_PLLDIV2
>>CONFIG_SYS_DA850_PLL0_PLLDIV3
>>CONFIG_SYS_DA850_PLL0_PLLDIV4
>>CONFIG_SYS_DA850_PLL0_PLLDIV5
>>CONFIG_SYS_DA850_PLL0_PLLDIV7
>>CONFIG_SYS_DA850_PLL1_POSTDIV
>>CONFIG_SYS_DA850_PLL1_PLLDIV1
>>CONFIG_SYS_DA850_PLL1_PLLDIV2
>>CONFIG_SYS_DA850_PLL1_PLLDIV3
>>
>> Signed-off-by: Adam Ford 
>> Reviewed-by: David Lechner 
>> ---
>> Changes in V3:
>>   Using the L138 Technical Reference manual, I changed the names to match
>> the descriptions of the registers as listed in Table 8-2 and 8-3 of 
>> the
>> PLL Control 0 and PLL Control 1 Registers.
>> V2:
>> Expand Kconfig help definitions to give a small explanation of 
>> options
>> V1:
>> This patch is a continuation of Convert CONFIG_SOC_DA8XX et al
>> This also showed warnings when used with the legoev3_defconfig, however
>> it seems like the ev3 board was defining things in the header it didn't need
>> since it doesn't seem to be building da850_lowlevel.c.  I don't have the
>> hardware to test that board.
>>
>>  arch/arm/mach-davinci/Kconfig   | 85 
>> -
>>  configs/omapl138_lcdk_defconfig |  1 +
>>  include/configs/calimain.h  | 13 ---
>>  include/configs/da850evm.h  | 13 ---
>>  include/configs/ipam390.h   | 13 ---
>>  include/configs/legoev3.h   | 13 ---
>>  include/configs/omapl138_lcdk.h | 13 ---
>>  scripts/config_whitelist.txt| 12 --
>>  8 files changed, 85 insertions(+), 78 deletions(-)
>
> [patchwork link is https://patchwork.ozlabs.org/patch/859919/]
>
> First, this should also cover CONFIG_SYS_DA850_PLL0_PLLM which shouldn't
> be too bad.
>
> Second, this needs to deal with calimain, which has both
> CONFIG_SYS_DA850_PLL1_PLLM and CONFIG_SYS_DA850_PLL0_PLLM as dynamic.
> Ideas?  Thanks!
>
Can we push the low-hanging fruit and come back and revisit the rest
at a later date?   My goal was just try and clean up a bunch of config
files.

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

Re: [U-Boot] Convert CONFIG_SYS_BOOT_GET_{CMDLINE, KBD} to Kconfig

[Tom Rini]

On Thu, Dec 28, 2017 at 01:25:13AM -0600, Derald D. Woods wrote:

> This converts the following to Kconfig:
>   CONFIG_SYS_BOOT_GET_CMDLINE
>   CONFIG_SYS_BOOT_GET_KBD
> 
> Additionally, ARM now selects CONFIG_SYS_BOOT_GET_CMDLINE. This enables
> the 'boot_get_cmdline' call to be reached from 'image_setup_linux' in
> "common/image.c".
> 
> Signed-off-by: Derald D. Woods 
> ---
>  Kconfig   | 12 
>  arch/Kconfig  |  5 +
>  arch/m68k/include/asm/config.h|  2 --
>  arch/powerpc/include/asm/config.h |  2 --
>  scripts/config_whitelist.txt  |  2 --
>  5 files changed, 17 insertions(+), 6 deletions(-)

Why are you enabling this on ARM as well here?  It causes a size grow
(of course, we're adding in a function) on all ARM boards and I don't
quite see why we need to put a copy of the bootargs in that location.

Off the top of my head it seems like it only makes sense on pre-DTB
PowerPC where the cmdline needed to be in a good location.  On pre-DTB
ARM that's done via ATAGS instead, so already covered.  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] [RFC] SPDX License text updates

[Lukasz Majewski]

On Mon, 22 Jan 2018 12:06:07 -0500
Tom Rini  wrote:

> Hey all,
> 
> In another thread Felix Brack brought up that as of version 3.0 of
> SPDX, there's a number of deprecated tags (see
> https://spdx.org/licenses/) and that we're using at least one of them.
> 
> Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".
> 
> Now, we have a few options here:
> - Deprecated isn't removed.  SPDX specifically says the old links
> shall remain valid, etc, etc.  We could continue to use "GPL-2.0+",
> etc and not have to change (literally) 8000 files.  This will also
> keep us in line with what the Linux kernel currently does.  I also
> have no idea, nor have I looked to see if that's going to change.
> - Allow both old and new.  Both are valid, the newer form allows for
>   easier tooling and more precise management of options that I'm not
>   sure apply to our use cases.
> - Switch to the new tags.  A few hour I imagine of playing around with
>   sed and then manual fixups and I can probably convert all the
> existing cases to the new syntax (we have some DTS files for example
> with (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).
> But then we need some tooling to make checkpatch.pl at least noisy
> about unconverted and to get everyone into the habit of changing and
> so forth.
> 
> At this point in time I'm leaning towards the first, and as is often
> the case, watching what the kernel does.

+1

>  Thoughts / comments?
> Thanks!
> 



Best regards,

Lukasz Majewski

--

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


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

Re: [U-Boot] [U-Boot, V3] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

[Tom Rini]

On Fri, Jan 12, 2018 at 07:26:06AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_DV_CLKMODE
>CONFIG_SYS_DA850_PLL0_POSTDIV
>CONFIG_SYS_DA850_PLL0_PLLDIV1
>CONFIG_SYS_DA850_PLL0_PLLDIV2
>CONFIG_SYS_DA850_PLL0_PLLDIV3
>CONFIG_SYS_DA850_PLL0_PLLDIV4
>CONFIG_SYS_DA850_PLL0_PLLDIV5
>CONFIG_SYS_DA850_PLL0_PLLDIV7
>CONFIG_SYS_DA850_PLL1_POSTDIV
>CONFIG_SYS_DA850_PLL1_PLLDIV1
>CONFIG_SYS_DA850_PLL1_PLLDIV2
>CONFIG_SYS_DA850_PLL1_PLLDIV3
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: David Lechner 
> ---
> Changes in V3:
>   Using the L138 Technical Reference manual, I changed the names to match
> the descriptions of the registers as listed in Table 8-2 and 8-3 of 
> the
> PLL Control 0 and PLL Control 1 Registers.
> V2:
> Expand Kconfig help definitions to give a small explanation of options
> V1:
> This patch is a continuation of Convert CONFIG_SOC_DA8XX et al
> This also showed warnings when used with the legoev3_defconfig, however
> it seems like the ev3 board was defining things in the header it didn't need
> since it doesn't seem to be building da850_lowlevel.c.  I don't have the
> hardware to test that board.
> 
>  arch/arm/mach-davinci/Kconfig   | 85 
> -
>  configs/omapl138_lcdk_defconfig |  1 +
>  include/configs/calimain.h  | 13 ---
>  include/configs/da850evm.h  | 13 ---
>  include/configs/ipam390.h   | 13 ---
>  include/configs/legoev3.h   | 13 ---
>  include/configs/omapl138_lcdk.h | 13 ---
>  scripts/config_whitelist.txt| 12 --
>  8 files changed, 85 insertions(+), 78 deletions(-)

[patchwork link is https://patchwork.ozlabs.org/patch/859919/]

First, this should also cover CONFIG_SYS_DA850_PLL0_PLLM which shouldn't
be too bad.

Second, this needs to deal with calimain, which has both
CONFIG_SYS_DA850_PLL1_PLLM and CONFIG_SYS_DA850_PLL0_PLLM as dynamic.
Ideas?  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] UDP packet sender

[Lukasz Majewski]

Hi.

> Hi,
> On 01/18/2018 11:56 AM, Gaëtan Carlier wrote:
> > Hi,
> > I would like to implement a new command and submit it to the
> > mailing list. The command will have the following format:
> > udpsend   
> > 
> > 
> > udpsend 255.255.255.255 4040 0 hello world
> > 
> > If source port is 0, a random port will be used (11000 +
> > (get_timer(0) % 4096))
> > 
> > Where do I have to place my code : cmd or net directory ?
> > For me cmd will be the better directory to keep it away from all
> > more complex stuff like DHCP, TFTP, ...
> > 
> > Thank you for these informations.
> > Regards,
> > Gaëtan.
> >   
> 
> Ping ?

You should write directly to network u-boot maintainer and add list to
CC.

Joe Hershberger 

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



Best regards,

Lukasz Majewski

--

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


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

Re: [U-Boot] [PATCH 1/1] efi_loader: use built-in device tree in bootefi command

[Alexander Graf]

On 22.01.18 19:43, Heinrich Schuchardt wrote:
> 
> 
> On 01/22/2018 02:59 PM, Alexander Graf wrote:
>> On 01/20/2018 01:56 PM, Heinrich Schuchardt wrote:
>>> The bootefi command has two parameters: the address of the executable
>>> and
>>> the address of the flattened device tree.
>>>
>>> When executing the devicetree command in grub this command can only
>>> replace an existing device tree. So we always want to pass a device
>>> tree.
>>>
>>> With the patch the device tree defaults to the internal one. But of
>>> cause
>>> the user still can supply his one via the second parameter.
>>>
>>> One use case is booting via iPXE from an iSCSI drive. As we may be able
>>> to choose between different operating systems in the iPXE menu we cannot
>>> know the correct device tree when invoking bootefi. The dtb might not
>>> even
>>> be installed on a local device.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>
>> All of this logic is already implemented in the distro boot script, so
>> if you load your iPXE EFI binary via dhcp boot, from a block device or
>> something similar, it will by default already get $fdtcontroladdr
>> passed in. I'm not sure I'm terribly happy to have additional magic in
>> the bootefi command. If you want to spawn an EFI binary without device
>> tree table, you should be able to do so IMHO.
> 
> Booting via DHCP is most insecure. Neither the client nor the server are
> authenticated.
> 
> My understanding is that ftd address is not set by:
> 
> load mmc 0:1 0x1300 snp.efi
> bootefi 0x1300
> 
> Where would an fdtadress be determined without loading a dtb?

If you instead just use

bootefi 0x1300 $fdtcontroladdr

you should be all set :)


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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jan 22, 2018 at 09:55:43PM +0100, Álvaro Fernández Rojas wrote:
> Hi Daniel,
> 
> 
> El 22/01/2018 a las 21:26, Daniel Schwierzeck escribió:
> >
> >On 22.01.2018 18:14, Tom Rini wrote:
> >>On Mon, Jan 22, 2018 at 05:49:39PM +0100, Daniel Schwierzeck wrote:
> >>>
> >>>On 22.01.2018 13:58, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> 
> >Hi Tom,
> >
> >Please pull this PR.
> >
> >thanks!
> >Jagan.
> >
> >The following changes since commit 
> >98691a60abffb44303d7dae6e9e699d0daded930:
> >
> >   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
> >
> >are available in the git repository at:
> >
> >   git://git.denx.de/u-boot-spi.git master
> >
> >for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
> >
> >   mips: bmips: enable the SPI flash on the Comtrend AR-5387un 
> > (2018-01-22 10:39:13 +0530)
> >
> NAK:
> 
> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> Author: Álvaro Fernández Rojas 
> Date:   Sat Jan 20 02:11:34 2018 +0100
> 
>  wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> 
>  Add 8/16/32 bits and BE/LE versions of wait_for_bit.
>  This is needed for reading registers that are not aligned to 32 
>  bits, and for
>  Big Endian platforms.
> 
>  Signed-off-by: Álvaro Fernández Rojas 
>  Reviewed-by: Daniel Schwierzeck 
>  Reviewed-by: Jagan Teki 
> 
> Adds warnings on almost all platforms:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be16?:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> implicit declaration of function ?readw_be? 
> [-Wimplicit-function-declaration]
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> ?readl_be? [-Wimplicit-function-declaration]
> 
> 
> >>>Tom, would this change to the patch be acceptable?
> >>>
> >>>--- a/include/wait_bit.h
> >>>+++ b/include/wait_bit.h
> >>>@@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void *reg,   
> >>>\
> >>>
> >>>  BUILD_WAIT_FOR_BIT(8, u8, readb)
> >>>  BUILD_WAIT_FOR_BIT(le16, u16, readw)
> >>>+#ifdef readw_be
> >>>  BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
> >>>+#endif
> >>>  BUILD_WAIT_FOR_BIT(le32, u32, readl)
> >>>+#ifdef readl_be
> >>>  BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
> >>>+#endif
> >>>
> >>>  #endif
> >>>
> >>>This wouldn't define wait_bit_be*() on archs which doesn't implement
> >>>readw_be or readl_be.
> >>>
> >>>A build with the updated patch is scheduled at
> >>>https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381
> >>That seems reasonable, thanks!
> >>
> >Álvaro, could you send a v10 where the patch "wait_bit: add 8/16/32
> >BE/LE versions of wait_for_bit" is fixed like above? Thanks.
> Sure, but I think this alternative would be much cleaner:
> https://gist.github.com/Noltari/3e6ed4648b87484c73ca22e2f533f9b0
> 
> What do you think?

That is a bit cleaner, 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] Pull request: u-boot-spi/master

[Álvaro Fernández Rojas]

Hi Daniel,


El 22/01/2018 a las 21:26, Daniel Schwierzeck escribió:


On 22.01.2018 18:14, Tom Rini wrote:

On Mon, Jan 22, 2018 at 05:49:39PM +0100, Daniel Schwierzeck wrote:


On 22.01.2018 13:58, Tom Rini wrote:

On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:


Hi Tom,

Please pull this PR.

thanks!
Jagan.

The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930:

   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)

are available in the git repository at:

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

for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:

   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
10:39:13 +0530)


NAK:

commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
Author: Álvaro Fernández Rojas 
Date:   Sat Jan 20 02:11:34 2018 +0100

 wait_bit: add 8/16/32 BE/LE versions of wait_for_bit

 Add 8/16/32 bits and BE/LE versions of wait_for_bit.
 This is needed for reading registers that are not aligned to 32 bits, and 
for
 Big Endian platforms.

 Signed-off-by: Álvaro Fernández Rojas 
 Reviewed-by: Daniel Schwierzeck 
 Reviewed-by: Jagan Teki 

Adds warnings on almost all platforms:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
?wait_for_bit_be16?:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: implicit 
declaration of function ?readw_be? [-Wimplicit-function-declaration]
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
../include/wait_bit.h:78:31: warning: implicit declaration of function 
?readl_be? [-Wimplicit-function-declaration]



Tom, would this change to the patch be acceptable?

--- a/include/wait_bit.h
+++ b/include/wait_bit.h
@@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void *reg,
\

  BUILD_WAIT_FOR_BIT(8, u8, readb)
  BUILD_WAIT_FOR_BIT(le16, u16, readw)
+#ifdef readw_be
  BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
+#endif
  BUILD_WAIT_FOR_BIT(le32, u32, readl)
+#ifdef readl_be
  BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
+#endif

  #endif

This wouldn't define wait_bit_be*() on archs which doesn't implement
readw_be or readl_be.

A build with the updated patch is scheduled at
https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381

That seems reasonable, thanks!


Álvaro, could you send a v10 where the patch "wait_bit: add 8/16/32
BE/LE versions of wait_for_bit" is fixed like above? Thanks.

Sure, but I think this alternative would be much cleaner:
https://gist.github.com/Noltari/3e6ed4648b87484c73ca22e2f533f9b0

What do you think?

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Daniel Schwierzeck]

On 22.01.2018 18:14, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 05:49:39PM +0100, Daniel Schwierzeck wrote:
>>
>>
>> On 22.01.2018 13:58, Tom Rini wrote:
>>> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
>>>
 Hi Tom,

 Please pull this PR.

 thanks!
 Jagan.

 The following changes since commit 
 98691a60abffb44303d7dae6e9e699d0daded930:

   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)

 are available in the git repository at:

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

 for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:

   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
 10:39:13 +0530)

>>>
>>> NAK:
>>>
>>> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
>>> Author: Álvaro Fernández Rojas 
>>> Date:   Sat Jan 20 02:11:34 2018 +0100
>>>
>>> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
>>>
>>> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
>>> This is needed for reading registers that are not aligned to 32 bits, 
>>> and for
>>> Big Endian platforms.
>>>
>>> Signed-off-by: Álvaro Fernández Rojas 
>>> Reviewed-by: Daniel Schwierzeck 
>>> Reviewed-by: Jagan Teki 
>>>
>>> Adds warnings on almost all platforms:
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
>>> ?wait_for_bit_be16?:
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
>>> implicit declaration of function ?readw_be? 
>>> [-Wimplicit-function-declaration]
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
>>> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
>>> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
>>> ?readl_be? [-Wimplicit-function-declaration]
>>>
>>>
>>
>> Tom, would this change to the patch be acceptable?
>>
>> --- a/include/wait_bit.h
>> +++ b/include/wait_bit.h
>> @@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void *reg, 
>> \
>>
>>  BUILD_WAIT_FOR_BIT(8, u8, readb)
>>  BUILD_WAIT_FOR_BIT(le16, u16, readw)
>> +#ifdef readw_be
>>  BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
>> +#endif
>>  BUILD_WAIT_FOR_BIT(le32, u32, readl)
>> +#ifdef readl_be
>>  BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
>> +#endif
>>
>>  #endif
>>
>> This wouldn't define wait_bit_be*() on archs which doesn't implement
>> readw_be or readl_be.
>>
>> A build with the updated patch is scheduled at
>> https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381
> 
> That seems reasonable, thanks!
> 

Álvaro, could you send a v10 where the patch "wait_bit: add 8/16/32
BE/LE versions of wait_for_bit" is fixed like above? Thanks.

-- 
- Daniel



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

Re: [U-Boot] [PATCH] boston: Ensure DDR address calcuations don't overflow

[Daniel Schwierzeck]

On 22.01.2018 19:54, Daniel Schwierzeck wrote:
> 
> 
> On 22.01.2018 19:01, Paul Burton wrote:
>> Hi Daniel,
>>
>> On Fri, Jan 19, 2018 at 12:31:25PM +0100, Daniel Schwierzeck wrote:
>>> On 18.01.2018 22:19, Paul Burton wrote:
 When constraining the highest DDR address that U-Boot will use for its
 data & relocated self, we need to handle the common case in which a 32
 bit system with 2GB DDR will have a zero gd->ram_top, due to the
 addition of 2GB (0x8000) to the base address of kseg0 (also
 0x8000) which overflows & wraps to 0.

 We originally had a check for this case, but it was lost in commit
 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing
 problems for the affected 32 bit systems.
>>>
>>> I think I did a wrong conflict resolution because the patch didn't apply
>>> anymore. I folded this patch into "boston: Provide physical
>>> CONFIG_SYS_SDRAM_BASE" to fix this. Actually I wanted to resend the
>>> updated patches. But if you are okay with the current state in
>>> u-boot-mips/next branch, I'll take them as they are.
>>>
>>> BTW: could you resend your series "boston: Ethernet support for MIPS
>>> Boston board"? I still have no Acks or Reviews on the generic DM parts.
>>> Thanks.
>>
>> When I last fetched from u-boot-mips.git I saw patches up to
>> 564cc3a11c45 ("mips: Remove virt_to_phys call on bi_memstart") in the
>> next branch, which I have then rebased my ethernet patches atop with the
>> result working fine on a real Boston board.
>>
>> I see that next now contains only 2 patches up to d2a4e3664150 ("mips:
>> bmips: increment SYS_MALLOC_F_LEN") and has dropped the patches
>> switching to a physical CONFIG_SYS_SDRAM_BASE. Would you like me to
>> rebase those plus the Boston ethernet support atop the current next
>> branch?
>>
> 
> I had to remove the patches because there is a failing test case in qemu
> pytest [1] which needs to be fixed. The test case fetches the RAM base
> address from the "bdinfo" output which is 0x0 due to
> CONFIG_SYS_SDRAM_BASE = 0. I'm not sure if we need to add a phys_to_virt
> mapping to the "md" command or if "bdinfo" should show the virtual
> address. What do you think? Actually other tools like "cp" are also
> affected.
> 

I think we need to implement "include/mapmem.h" for MIPS. But this won't work 
with the current phys_to_virt() implementation because there a lot of places 
using map_sysmem() and therefore expecting a physical address.

One hack would be:

diff --git a/arch/mips/config.mk b/arch/mips/config.mk
index cefdbe65e1..82fcd55f8c 100644
--- a/arch/mips/config.mk
+++ b/arch/mips/config.mk
@@ -39,6 +39,9 @@ PLATFORM_CPPFLAGS += -D__MIPS__
 PLATFORM_ELFENTRY = "__start"
 PLATFORM_ELFFLAGS += -B mips $(OBJCOPYFLAGS)
 
+# Force this until converted to a Kconfig symbol
+PLATFORM_CPPFLAGS += -DCONFIG_ARCH_MAP_SYSMEM
+
 #
 # From Linux arch/mips/Makefile
 #
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 45d7ca0cc6..9173beda0b 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -559,6 +559,20 @@ BUILD_CLRSETBITS(q, le64, le64, u64)
 BUILD_CLRSETBITS(q, be64, be64, u64)
 BUILD_CLRSETBITS(q, 64, _, u64)
 
+static inline void *map_sysmem(phys_addr_t paddr, unsigned long len)
+{
+   return (void *)CKSEG0ADDR(paddr);
+}
+
+static inline void unmap_sysmem(const void *vaddr)
+{
+}
+
+static inline phys_addr_t map_to_sysmem(const void *ptr)
+{
+   return CKSEG0ADDR((uintptr_t)ptr);
+}
+
 #include 
 
 #endif /* _ASM_IO_H */


Test with qemu_mips:

qemu-mips # bdinfo 
boot_params = 0x87F488E8
memstart= 0x
memsize = 0x0800
flashstart  = 0xBFC0
flashsize   = 0x0040
flashoffset = 0x00030508
ethaddr = 52:54:00:12:34:56
IP addr = 
baudrate= 115200 bps
relocaddr   = 0x87F9
reloc off   = 0xC839
qemu-mips # md 0
:    
0010:    
0020:    


There is another issue. If "struct bd_info" is supposed to hold physical 
addresses, 
we would need to fix bi_flashstart and CONFIG_SYS_FLASH_BASE too ;)

-- 
- Daniel



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

Re: [U-Boot] [RFC] SPDX License text updates

[Tom Rini]

On Mon, Jan 22, 2018 at 08:44:27PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180122170607.GL32220@bill-the-cat> you wrote:
> > 
> > In another thread Felix Brack brought up that as of version 3.0 of SPDX,
> > there's a number of deprecated tags (see https://spdx.org/licenses/) and
> > that we're using at least one of them.
> > 
> > Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".
> 
> OK...
> 
> > Now, we have a few options here:
> > - Deprecated isn't removed.  SPDX specifically says the old links shall
> >   remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
> >   not have to change (literally) 8000 files.  This will also keep us in
> >   line with what the Linux kernel currently does.  I also have no idea,
> >   nor have I looked to see if that's going to change.
> > - Allow both old and new.  Both are valid, the newer form allows for
> >   easier tooling and more precise management of options that I'm not
> >   sure apply to our use cases.
> 
> Both sound not really attractive to me.
> 
> > - Switch to the new tags.  A few hour I imagine of playing around with
> >   sed and then manual fixups and I can probably convert all the existing
> 
> Umm... where do you expect problems?  Running for example
> 
>   fgrep -hR GPL-2.0+ * | sort -u | less
> 
> gives a realtively short list which looks harmless to me.

Note we also need go convert "GPL-2.0" (and LGPL-...), but yes, that's
only going to add a tiny bit more work.

> >   cases to the new syntax (we have some DTS files for example with
> >   (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But
> 
> Yes, and why do you think this would be a problem?
> 
> We have a few other places that don't match current SPDX
> spcification, like all these
> 
>   GPL-2.0+BSD-2-Clause
>   GPL-2.0+BSD-3-Clause
>   GPL-2.0+ or X11
>   GPL-2.0+X11
>   |GPL-2.0+
> 
> but these cases are few and easy to spot.  I currentlse see neither
> the need for "few hour of playing around with sed" nor the need for
> manual fxes - a plain string substitution should work just fine, and
> we could even clean up the other inconsistencies whil we are at it.

This is the second time today I've not spoken clearly enough, sorry.
Yes, the sed side of correcting "GPL-2.0+", "GPL-2.0" and the LGPL
instances as well to take a minute, and perhaps another hour, hopefully
no more than 2 to correct the multi-license things to follow the license
expression format and update Licenses/README.  I don't think that the
above effort is a problem.

What I do see as at least a minor burden moving forward is catching new
files with an SPDX tag of the old variety.  Whacking checkpatch.pl to
catch that will make sure I don't miss them (since I am running
checkpatch.pl every time now).  I see
https://patchwork.kernel.org/patch/10053699/ exists, and it's easy
enough to extend that to catch old-style GPL-2.0/GPL2.0+/LGPL-2.0+/..
and warn about that.

> I vote for 3 plus additional cleanup.

Noted, 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] [RFC] SPDX License text updates

[Wolfgang Denk]

Dear Tom,

In message <20180122170607.GL32220@bill-the-cat> you wrote:
> 
> In another thread Felix Brack brought up that as of version 3.0 of SPDX,
> there's a number of deprecated tags (see https://spdx.org/licenses/) and
> that we're using at least one of them.
> 
> Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".

OK...

> Now, we have a few options here:
> - Deprecated isn't removed.  SPDX specifically says the old links shall
>   remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
>   not have to change (literally) 8000 files.  This will also keep us in
>   line with what the Linux kernel currently does.  I also have no idea,
>   nor have I looked to see if that's going to change.
> - Allow both old and new.  Both are valid, the newer form allows for
>   easier tooling and more precise management of options that I'm not
>   sure apply to our use cases.

Both sound not really attractive to me.

> - Switch to the new tags.  A few hour I imagine of playing around with
>   sed and then manual fixups and I can probably convert all the existing

Umm... where do you expect problems?  Running for example

fgrep -hR GPL-2.0+ * | sort -u | less

gives a realtively short list which looks harmless to me.

>   cases to the new syntax (we have some DTS files for example with
>   (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But

Yes, and why do you think this would be a problem?

We have a few other places that don't match current SPDX
spcification, like all these

GPL-2.0+BSD-2-Clause
GPL-2.0+BSD-3-Clause
GPL-2.0+ or X11
GPL-2.0+X11
|GPL-2.0+

but these cases are few and easy to spot.  I currentlse see neither
the need for "few hour of playing around with sed" nor the need for
manual fxes - a plain string substitution should work just fine, and
we could even clean up the other inconsistencies whil we are at it.

I vote for 3 plus additional cleanup.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The scientists of today think deeply instead of clearly. One must  be
sane  to think clearly, but one can think deeply and be quite insane.
   - Nikola Tesla
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/1] log: add category LOGC_EFI

[Heinrich Schuchardt]

The EFI implementation does not fit into any of the existing categories.

Provide LOGC_EFI so that EFI related message can be filtered.

Signed-off-by: Heinrich Schuchardt 
---
v2
rebase on git://git.denx.de/u-boot-dm.git, branch log-working
add category name
---
 common/log.c   | 1 +
 doc/README.log | 1 +
 include/log.h  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/common/log.c b/common/log.c
index 7559d74e90..02a98685d0 100644
--- a/common/log.c
+++ b/common/log.c
@@ -21,6 +21,7 @@ static const char *log_cat_name[LOGC_COUNT - LOGC_NONE] = {
"core",
"driver-model",
"device-tree",
+   "efi",
 };
 
 static const char *log_level_name[LOGL_COUNT] = {
diff --git a/doc/README.log b/doc/README.log
index 2abaee0c10..dc9e2deec5 100644
--- a/doc/README.log
+++ b/doc/README.log
@@ -51,6 +51,7 @@ The following main categories are defined:
LOGC_BOARD  - Related to board-specific code
LOGC_CORE   - Related to core driver-model support
LOGC_DT - Related to device tree control
+   LOGC_EFI- Related to EFI implementation
 
 
 Enabling logging
diff --git a/include/log.h b/include/log.h
index 68368d5cf1..20dc5289c7 100644
--- a/include/log.h
+++ b/include/log.h
@@ -46,6 +46,7 @@ enum log_category_t {
LOGC_CORE,
LOGC_DM,/* Core driver-model */
LOGC_DT,/* Device-tree */
+   LOGL_EFI,   /* EFI implementation */
 
LOGC_COUNT,
LOGC_END,
-- 
2.11.0

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

Re: [U-Boot] [PATCH] arm64 :show_regs: show the address before relocation

[Karl Beldan]

On Tue, Nov 28, 2017 at 10:08:08AM +0800, Peng Fan wrote:
> After relocation, when error happends, it is hard to track
> ELR and LR with asm file objdumped from elf file.
> 
> So subtract the gd->reloc_off the reflect the compliation address.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/lib/interrupts_64.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
> index 7c9cfce69f..cbcfeec2b0 100644
> --- a/arch/arm/lib/interrupts_64.c
> +++ b/arch/arm/lib/interrupts_64.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  
> +DECLARE_GLOBAL_DATA_PTR;
>  
>  int interrupt_init(void)
>  {
> @@ -29,8 +30,13 @@ void show_regs(struct pt_regs *regs)
>  {
>   int i;
>  
> - printf("ELR: %lx\n", regs->elr);
> - printf("LR:  %lx\n", regs->regs[30]);
> + if (gd->flags & GD_FLG_RELOC) {
> + printf("ELR: %lx\n", regs->elr - gd->reloc_off);
> + printf("LR:  %lx\n", regs->regs[30] - gd->reloc_off);
> + } else {
> + printf("ELR: %lx\n", regs->elr);
> + printf("LR:  %lx\n", regs->regs[30]);
> + }
>   for (i = 0; i < 29; i += 2)
>   printf("x%-2d: %016lx x%-2d: %016lx\n",
>  i, regs->regs[i], i+1, regs->regs[i+1]);

Hi,

It is useful to show the relocated address, the kind of local mods I too
have had for a while.
But here you dropped the hw register values altogether, instead of
displaying both, which I guess I am not the only one to not be happy
about.

Regards,
Karl

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

Re: [U-Boot] [PATCH] boston: Ensure DDR address calcuations don't overflow

[Daniel Schwierzeck]

On 22.01.2018 19:01, Paul Burton wrote:
> Hi Daniel,
> 
> On Fri, Jan 19, 2018 at 12:31:25PM +0100, Daniel Schwierzeck wrote:
>> On 18.01.2018 22:19, Paul Burton wrote:
>>> When constraining the highest DDR address that U-Boot will use for its
>>> data & relocated self, we need to handle the common case in which a 32
>>> bit system with 2GB DDR will have a zero gd->ram_top, due to the
>>> addition of 2GB (0x8000) to the base address of kseg0 (also
>>> 0x8000) which overflows & wraps to 0.
>>>
>>> We originally had a check for this case, but it was lost in commit
>>> 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing
>>> problems for the affected 32 bit systems.
>>
>> I think I did a wrong conflict resolution because the patch didn't apply
>> anymore. I folded this patch into "boston: Provide physical
>> CONFIG_SYS_SDRAM_BASE" to fix this. Actually I wanted to resend the
>> updated patches. But if you are okay with the current state in
>> u-boot-mips/next branch, I'll take them as they are.
>>
>> BTW: could you resend your series "boston: Ethernet support for MIPS
>> Boston board"? I still have no Acks or Reviews on the generic DM parts.
>> Thanks.
> 
> When I last fetched from u-boot-mips.git I saw patches up to
> 564cc3a11c45 ("mips: Remove virt_to_phys call on bi_memstart") in the
> next branch, which I have then rebased my ethernet patches atop with the
> result working fine on a real Boston board.
> 
> I see that next now contains only 2 patches up to d2a4e3664150 ("mips:
> bmips: increment SYS_MALLOC_F_LEN") and has dropped the patches
> switching to a physical CONFIG_SYS_SDRAM_BASE. Would you like me to
> rebase those plus the Boston ethernet support atop the current next
> branch?
> 

I had to remove the patches because there is a failing test case in qemu
pytest [1] which needs to be fixed. The test case fetches the RAM base
address from the "bdinfo" output which is 0x0 due to
CONFIG_SYS_SDRAM_BASE = 0. I'm not sure if we need to add a phys_to_virt
mapping to the "md" command or if "bdinfo" should show the virtual
address. What do you think? Actually other tools like "cp" are also
affected.

Also we now need a new patch for CONFIG_SYS_SDRAM_BASE in various
"include/configs/bmips_*.h" files.

[1] https://travis-ci.org/danielschwierzeck/u-boot/jobs/330776664

-- 
- Daniel



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

Re: [U-Boot] [PATCH 1/1] efi_loader: use built-in device tree in bootefi command

[Heinrich Schuchardt]

On 01/22/2018 02:59 PM, Alexander Graf wrote:

On 01/20/2018 01:56 PM, Heinrich Schuchardt wrote:

The bootefi command has two parameters: the address of the executable and
the address of the flattened device tree.

When executing the devicetree command in grub this command can only
replace an existing device tree. So we always want to pass a device tree.

With the patch the device tree defaults to the internal one. But of cause
the user still can supply his one via the second parameter.

One use case is booting via iPXE from an iSCSI drive. As we may be able
to choose between different operating systems in the iPXE menu we cannot
know the correct device tree when invoking bootefi. The dtb might not 
even

be installed on a local device.

Signed-off-by: Heinrich Schuchardt 


All of this logic is already implemented in the distro boot script, so 
if you load your iPXE EFI binary via dhcp boot, from a block device or 
something similar, it will by default already get $fdtcontroladdr passed 
in. I'm not sure I'm terribly happy to have additional magic in the 
bootefi command. If you want to spawn an EFI binary without device tree 
table, you should be able to do so IMHO.


Booting via DHCP is most insecure. Neither the client nor the server are 
authenticated.


My understanding is that ftd address is not set by:

load mmc 0:1 0x1300 snp.efi
bootefi 0x1300

Where would an fdtadress be determined without loading a dtb?

But giving it a further thought I have to better analyze why Grub fails 
to correctly execute 'devicetable' if no fdt has been passed to bootefi. 
Let's keep back the patch until the problem is properly understood.


Regards

Heinrich



How do you invoke iPXE?


Alex



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

Re: [U-Boot] mmc: disable UHS modes if Vcc cannot be switched on and off

[Eugeniy Paltsev]

Hi Jean-Jacques,

after commit "mmc: disable UHS modes if Vcc cannot be switched on and off" 
(04a2ea248f)
we got MMC broken on several (at least two) platforms with DesignWare MMC 
controller.

The error log (with debug enabled in drivers/mmc/mmc.c and 
drivers/mmc/dw_mmc.c) is next:
--->8-
MMC:   Synopsys Mobile storage: 0
Buswidth = 0, clock: 40
selecting mode MMC legacy (freq : 0 MHz)
Buswidth = 1, clock: 40
Buswidth = 1, clock: 40
Sending CMD0
dwmci_send_cmd: Timeout.
mmc_init: -110, time 19
** Bad device mmc 0 **
--->8-

Any ideas how to fix this?

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

[U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Heinrich Schuchardt]

The appended README explains how U-Boot and iPXE can be used
to boot a diskless system from an iSCSI SAN.

The maintainer for README.efi and README.iscsi is set.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS  |   2 +
 doc/README.iscsi | 178 +++
 2 files changed, 180 insertions(+)
 create mode 100644 doc/README.iscsi

diff --git a/MAINTAINERS b/MAINTAINERS
index d459153503..6e94cee5d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -286,6 +286,8 @@ EFI PAYLOAD
 M: Alexander Graf 
 S: Maintained
 T: git git://github.com/agraf/u-boot.git
+F: doc/README.efi
+F: doc/README.iscsi
 F: include/efi*
 F: lib/efi*/
 F: test/py/tests/test_efi*
diff --git a/doc/README.iscsi b/doc/README.iscsi
new file mode 100644
index 00..f095ad1ddf
--- /dev/null
+++ b/doc/README.iscsi
@@ -0,0 +1,178 @@
+# iSCSI booting with U-Boot and iPXE
+
+## Motivation
+
+U-Boot has only a reduced set of supported network protocols. A major gap is
+the lack of a TCP stack.
+
+For booting a diskless computer this leaves us with BOOTP or DHCP to get the
+address of a boot script. TFTP can be used to load the boot script and the
+operating system kernel and initial file system (initrd).
+
+These protocols are insecure. The client cannot validate the authenticity
+of the contacted servers. And the server cannot verify the identity of the
+client.
+
+Furthermore the services providing the operating system loader or kernel are
+not the ones that the operating system will use. Especially in a SAN 
environment
+this makes updating the operating system a hassle. After installing a new
+kernel version the boot files have to be copied to the TFTP server directory.
+
+The HTTPS protocol provides certificate based validation of servers. Sensitive
+data like passwords can be securely transmitted.
+
+The iSCSI protocol is used for connecting storage attached networks. It
+provides mutual authentication using the CHAP protocol. It typically runs on
+a TCP transport.
+
+Thus a better solution than DHCP/TFTP boot would be to load a boot script via
+HTTPS and to download any other files needed for booting via iSCSI.
+
+An alternative to implementing these protocols in U-Boot is to use an existing
+software that can run on top of U-Boot. iPXE is the "swiss army knife" of
+network booting. It supports both HTTPS and iSCSI. It has a script engine for
+fine grained control of the boot process and can provide a command shell.
+
+iPXE can be built as an EFI application (named snp.efi) which can be loaded and
+run by U-Boot.
+
+## Boot sequence
+
+U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
+application has network access via the simple network protocol offered by
+U-Boot.
+
+iPXE executes its internal script. This script may optionally chain load a
+secondary boot script via HTTPS or open a shell.
+
+For the further boot process iPXE connects to the iSCSI server. This includes
+the mutual authentication using the CHAP protocol. After the authentication 
iPXE
+has access to the iSCSI targets.
+
+For a selected iSCSI target iPXE sets up a handle with the block IO protocol. 
It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect 
a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and install the simple file
+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
+the block IO protocol offered by iPXE to fulfill the request.
+
+Once Grub is started it uses the same simple file protocol to load Linux. Via
+the EFI stub Linux is called as an EFI application.
+
+```
+   ++  ++
+   || Runs ||
+   | U-Boot |=>| iPXE   |
+   | EFI|  | snp.efi|
+++ || DHCP ||
+||<||<=||
+| DHCP   | || Request  ||
+| Server | ||  ||
+||>||=>||
+++ || Response ||
+   ||  ||
+   ||  ||
+++ || HTTPS||
+||<||<=||
+| HTTPS  | || Request  ||
+| Server | ||  ||
+||>||=>||
+++ || Response ||
+   ||  ||
+   ||  ||
+++ || iSCSI||
+||<||<=||
+| iSCSI  | || Auth ||
+| Server |>||=>||
+|| ||  ||
+|| || Loads||
+|

Re: [U-Boot] [PATCH] boston: Ensure DDR address calcuations don't overflow

[Paul Burton]

Hi Daniel,

On Fri, Jan 19, 2018 at 12:31:25PM +0100, Daniel Schwierzeck wrote:
> On 18.01.2018 22:19, Paul Burton wrote:
> > When constraining the highest DDR address that U-Boot will use for its
> > data & relocated self, we need to handle the common case in which a 32
> > bit system with 2GB DDR will have a zero gd->ram_top, due to the
> > addition of 2GB (0x8000) to the base address of kseg0 (also
> > 0x8000) which overflows & wraps to 0.
> > 
> > We originally had a check for this case, but it was lost in commit
> > 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing
> > problems for the affected 32 bit systems.
> 
> I think I did a wrong conflict resolution because the patch didn't apply
> anymore. I folded this patch into "boston: Provide physical
> CONFIG_SYS_SDRAM_BASE" to fix this. Actually I wanted to resend the
> updated patches. But if you are okay with the current state in
> u-boot-mips/next branch, I'll take them as they are.
> 
> BTW: could you resend your series "boston: Ethernet support for MIPS
> Boston board"? I still have no Acks or Reviews on the generic DM parts.
> Thanks.

When I last fetched from u-boot-mips.git I saw patches up to
564cc3a11c45 ("mips: Remove virt_to_phys call on bi_memstart") in the
next branch, which I have then rebased my ethernet patches atop with the
result working fine on a real Boston board.

I see that next now contains only 2 patches up to d2a4e3664150 ("mips:
bmips: increment SYS_MALLOC_F_LEN") and has dropped the patches
switching to a physical CONFIG_SYS_SDRAM_BASE. Would you like me to
rebase those plus the Boston ethernet support atop the current next
branch?

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

Re: [U-Boot] STM32F746 Discovery - No serial output?

[Francois Dugast]

Thanks for the infos and the patches.

1. Non SPL
After disabling SPL in the U-Boot configuration and enabling USART6 in the
DTS with the patches you provided, there is still no output on this serial
interface after flashing U-Boot v2018.01 (stm32f746-disco_defconfig) with:
$ openocd -f board/stm32f7discovery.cfg -c "program images/u-boot.bin
0x0800" -c "reset run" -c shutdown
Serial output is coming on USART6 with U-Boot from
https://github.com/EmcraftSystems/u-boot so it is unlikely to be a hardware
issue.

2. SPL
I am not familiar with this mode on the stm32f746 disco. I have tried
copying the u-boot.bin generated with SPL enabled to the "DIS_F746NG" MBED
volume exposed by the card and the LED blinks in red and green for a few
seconds. Still, no output is coming through the /dev/ttyACM* device. Could
you give some hints about the steps to get it running?

Francois

On Tue, Jul 25, 2017 at 3:39 PM, Patrice CHOTARD 
wrote:

> Another update you need to do, is to change the default uart in device
> tree. By default uart1 is used, using the STLink usb port.
>
> To use the UART6 output on arduino UNO connector, applied the attached
> patch.
>
> Patrice
>
> On 07/25/2017 02:20 PM, Patrice CHOTARD wrote:
> > Hi Francois
> >
> > By default, stm32f746-disco is configured in SPL mode, that's what
> > explain you don't get any output in the console
> >
> > To come back in non SPL mode, you can use the attached patch.
> >
> > Patrice
> >
> > On 07/21/2017 10:40 PM, Francois Dugast wrote:
> >> Hi,
> >>
> >> I am trying to run the master on a STM32F746 Discovery board [1] by
> using
> >> stm32f746-disco_defconfig. It was built with
> gcc-arm-none-eabi-5_4-2016q3
> >> [2] and flashed with OpenOCD [3]. A USB-serial adapter is connected to
> >> USART6_RX and USART6_TX (pins D0 and D1 of the Arduino connector) and
> >> configured for 115200 8N1. No output coming out through the serial
> >> interface. It is unlikely to be a hardware issue as output is coming out
> >> normally this way when using the U-Boot repository from Emcraft.
> >>
> >> I do not know what I am doing wrong, can you help me out?
> >>
> >> Cheers,
> >> Francois
> >>
> >> [1] http://www.st.com/en/evaluation-tools/32f746gdiscovery.html
> >> [2] https://launchpad.net/gcc-arm-embedded
> >> [3] http://openocd.org
> >> [4] https://github.com/EmcraftSystems/u-boot
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
> >>
> >>
> >>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jan 22, 2018 at 05:49:39PM +0100, Daniel Schwierzeck wrote:
> 
> 
> On 22.01.2018 13:58, Tom Rini wrote:
> > On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> > 
> >> Hi Tom,
> >>
> >> Please pull this PR.
> >>
> >> thanks!
> >> Jagan.
> >>
> >> The following changes since commit 
> >> 98691a60abffb44303d7dae6e9e699d0daded930:
> >>
> >>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.denx.de/u-boot-spi.git master
> >>
> >> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
> >>
> >>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
> >> 10:39:13 +0530)
> >>
> > 
> > NAK:
> > 
> > commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> > Author: Álvaro Fernández Rojas 
> > Date:   Sat Jan 20 02:11:34 2018 +0100
> > 
> > wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> > 
> > Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> > This is needed for reading registers that are not aligned to 32 bits, 
> > and for
> > Big Endian platforms.
> > 
> > Signed-off-by: Álvaro Fernández Rojas 
> > Reviewed-by: Daniel Schwierzeck 
> > Reviewed-by: Jagan Teki 
> > 
> > Adds warnings on almost all platforms:
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> > ?wait_for_bit_be16?:
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> > implicit declaration of function ?readw_be? 
> > [-Wimplicit-function-declaration]
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> > ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> > ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> > ?readl_be? [-Wimplicit-function-declaration]
> > 
> > 
> 
> Tom, would this change to the patch be acceptable?
> 
> --- a/include/wait_bit.h
> +++ b/include/wait_bit.h
> @@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void *reg,  
> \
> 
>  BUILD_WAIT_FOR_BIT(8, u8, readb)
>  BUILD_WAIT_FOR_BIT(le16, u16, readw)
> +#ifdef readw_be
>  BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
> +#endif
>  BUILD_WAIT_FOR_BIT(le32, u32, readl)
> +#ifdef readl_be
>  BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
> +#endif
> 
>  #endif
> 
> This wouldn't define wait_bit_be*() on archs which doesn't implement
> readw_be or readl_be.
> 
> A build with the updated patch is scheduled at
> https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381

That seems reasonable, 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 13/15] env: Mark env_get_location as weak

[Tom Rini]

On Mon, Jan 22, 2018 at 09:48:26AM -0700, Simon Glass wrote:
> Hi,
> 
> On 22 January 2018 at 09:36, Tom Rini  wrote:
> > On Mon, Jan 22, 2018 at 04:57:41PM +0100, Maxime Ripard wrote:
> >> On Mon, Jan 22, 2018 at 07:49:41AM -0500, Tom Rini wrote:
> >> > On Mon, Jan 22, 2018 at 01:46:46PM +0100, Maxime Ripard wrote:
> >> > > Hi,
> >> > >
> >> > > On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
> >> > > > > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
> >> > > > >> On 16 January 2018 at 01:16, Maxime Ripard
> >> > > > >>  wrote:
> >> > > > >> > Allow boards and architectures to override the default 
> >> > > > >> > environment lookup
> >> > > > >> > code by overriding env_get_location.
> >> > > > >> >
> >> > > > >> > Reviewed-by: Andre Przywara 
> >> > > > >> > Reviewed-by: Lukasz Majewski 
> >> > > > >> > Signed-off-by: Maxime Ripard 
> >> > > > >> > ---
> >> > > > >> >  env/env.c | 20 +++-
> >> > > > >> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >> > > > >> >
> >> > > > >>
> >> > > > >> I still don't really understand why this needs to be a weak 
> >> > > > >> function.
> >> > > > >> If the board knows the priority order, can it not put it into
> >> > > > >> global_data? We could have a little u8 array of 4 items with a
> >> > > > >> terminator?
> >> > > > >
> >> > > > > Sure that would be simpler, but that would also prevent us from 
> >> > > > > doing
> >> > > > > "smart" things based on data other than just whether the previous
> >> > > > > environment is usable. Things based for example on a GPIO state, 
> >> > > > > or a
> >> > > > > custom algorithm to transition (or duplicate) the environment.
> >> > > >
> >> > > > In that case the board could read the GPIO state, or the algorithm,
> >> > > > and then set up the value.
> >> > > >
> >> > > > Basically I am saying it could set up the priority order in advance 
> >> > > > of
> >> > > > it being needed, rather than having a callback.
> >> > >
> >> > > Aren't we kind of stuck here?
> >> > >
> >> > > On the previous iterations, we already discussed this and Tom
> >> > > eventually told he was in favour of __weak functions, and the
> >> > > discussion stopped there. I assumed you were ok with it.
> >> > >
> >> > > I'd really want to move forward on that. This is something that is
> >> > > really biting us *now* and I'd hate to miss yet another merge window
> >> > > because of debates like this.
> >> >
> >> > Yes, I think this is where we want things to be weak, with a reasonable
> >> > default.  If we start to see that "everyone" does the same thing by and
> >> > large we can re-evaluate.
> >>
> >> Ok.
> >>
> >> I've fixed the bug I mentionned the other day on IRC, should I send a PR?
> >
> > Lets give Simon a chance to provide any other feedback here, or another
> > argument to convince me that no, we don't want to have this abstracted
> > by a weak function but instead ..., thanks!
> 
> I suspect there is a reason why this is better than what I propose.
> Perhaps when I try it out it will become apparent.
> 
> So let's go ahead and revisit later if we have new information.
> 
> Reviewed-by: Simon Glass 

Thanks!  Maxime, please re-spin with the bugfix (or wait another day or
two for other feedback), repost and I'll take it in Thurs/Fri or so.

-- 
Tom


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

[U-Boot] [RFC] SPDX License text updates

[Tom Rini]

Hey all,

In another thread Felix Brack brought up that as of version 3.0 of SPDX,
there's a number of deprecated tags (see https://spdx.org/licenses/) and
that we're using at least one of them.

Specifically, "GPL-2.0+" should be "GPL-2.0-or-later".

Now, we have a few options here:
- Deprecated isn't removed.  SPDX specifically says the old links shall
  remain valid, etc, etc.  We could continue to use "GPL-2.0+", etc and
  not have to change (literally) 8000 files.  This will also keep us in
  line with what the Linux kernel currently does.  I also have no idea,
  nor have I looked to see if that's going to change.
- Allow both old and new.  Both are valid, the newer form allows for
  easier tooling and more precise management of options that I'm not
  sure apply to our use cases.
- Switch to the new tags.  A few hour I imagine of playing around with
  sed and then manual fixups and I can probably convert all the existing
  cases to the new syntax (we have some DTS files for example with
  (GPL-2.0+ OR MIT) which would become (GPL-2.0-or-later OR MIT).  But
  then we need some tooling to make checkpatch.pl at least noisy about
  unconverted and to get everyone into the habit of changing and so
  forth.

At this point in time I'm leaning towards the first, and as is often the
case, watching what the kernel does.  Thoughts / comments?  Thanks!

-- 
Tom


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

[U-Boot] u-boot-mmc fails on almost every Tegra board

[Stephen Warren]

Jaehoon,

The latest commit in u-boot-mmc.git master branch fails on almost every 
Tegra board. The MMC device experiences an error during initialization 
and hence isn't available:


U-Boot 2018.01-05974-gb9b4f146c9 (Jan 22 2018 - 09:18:42 -0700), Build: 
jenkins-u-boot-denx_uboot_mmc-master-build-U_BOOT_BOARD=p2371-2180-151


TEGRA210
Model: NVIDIA P2371-2180
Board: NVIDIA P2371-2180
DRAM:  3.5 GiB
MMC:   sdhci@700b: 1, sdhci@700b0600: 0
tegra_mmc_send_cmd_bounced: waiting for status update
mmc_init: -110, time 1068
*** Warning - No block device, using default environment
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] net: sh-eth: Add to Kconfig and convert

[Joe Hershberger]

Hi Nobuhiro,

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

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

Re: [U-Boot] net: dhcp: Allow "MAY_FAIL" to still try each adapter

[Joe Hershberger]

Hi Wilson,

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

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

Re: [U-Boot] net: sh-eth: Fix coding style checked by checkpatch.pl

[Joe Hershberger]

Hi Nobuhiro,

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

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

Re: [U-Boot] net: sh-eth: Change read/write() param to struct sh_eth_info

[Joe Hershberger]

Hi Nobuhiro,

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

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

Re: [U-Boot] net: sh-eth: Remove bd_t from sh_eth_config()

[Joe Hershberger]

Hi Nobuhiro,

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

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

Re: [U-Boot] phy: atheros: set auto-negotiation for AR8021

[Joe Hershberger]

Hi Qiang,

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

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

Re: [U-Boot] net: sh-eth: Fix misaligned cache operation warning

[Joe Hershberger]

Hi Nobuhiro,

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

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

Re: [U-Boot] configs: Update Lamobo_R1 with B53 switch options

[Joe Hershberger]

Hi Florian,

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

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

Re: [U-Boot] net: phy: b53: Add b53_reg read/write commands

[Joe Hershberger]

Hi Florian,

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

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

Re: [U-Boot] net: mvneta - Fixed recv() when multiple packets have arrived.

[Joe Hershberger]

Hi Jason,

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

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

Re: [U-Boot] net: designware: Pad small packets

[Joe Hershberger]

Hi Florian,

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

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

Re: [U-Boot] dm: core: add missing dev_count_phandle_with_args()

[Joe Hershberger]

Hi Patrice,

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

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

Re: [U-Boot] net: Remove nfs.h include from bootp.c

[Joe Hershberger]

Hi Joe,

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

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

Re: [U-Boot] net: designware: add clock support

[Joe Hershberger]

Hi Patrice,

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

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

Re: [U-Boot] net: miiphybb: fix casting error

[Joe Hershberger]

Hi Chris,

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

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

Re: [U-Boot] net: phy: Add Broadcom BCM53xx switch driver

[Joe Hershberger]

Hi Florian,

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

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

Re: [U-Boot] net: sh-eth: remove sh_eth_offset_rz table

[Joe Hershberger]

Hi Chris,

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

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

Re: [U-Boot] net: sh-eth: fix inl and outl definitions

[Joe Hershberger]

Hi Chris,

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

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

Re: [U-Boot] net: phy: marvell: Add functions to read PHY's extended registers

[Joe Hershberger]

Hi Lukasz,

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

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

Re: [U-Boot] net: Fix buffer overrun error in netconsole

[Joe Hershberger]

Hi Joe,

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

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

Re: [U-Boot] net: macb: Add support for Xilinx Zynq SoC

[Joe Hershberger]

Hi Wilson,

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

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Daniel Schwierzeck]

On 22.01.2018 13:58, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> 
>> Hi Tom,
>>
>> Please pull this PR.
>>
>> thanks!
>> Jagan.
>>
>> The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930:
>>
>>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-spi.git master
>>
>> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
>>
>>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
>> 10:39:13 +0530)
>>
> 
> NAK:
> 
> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> Author: Álvaro Fernández Rojas 
> Date:   Sat Jan 20 02:11:34 2018 +0100
> 
> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> 
> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> This is needed for reading registers that are not aligned to 32 bits, and 
> for
> Big Endian platforms.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> Reviewed-by: Jagan Teki 
> 
> Adds warnings on almost all platforms:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be16?:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> implicit declaration of function ?readw_be? [-Wimplicit-function-declaration]
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> ?readl_be? [-Wimplicit-function-declaration]
> 
> 

Tom, would this change to the patch be acceptable?

--- a/include/wait_bit.h
+++ b/include/wait_bit.h
@@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void *reg,
\

 BUILD_WAIT_FOR_BIT(8, u8, readb)
 BUILD_WAIT_FOR_BIT(le16, u16, readw)
+#ifdef readw_be
 BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
+#endif
 BUILD_WAIT_FOR_BIT(le32, u32, readl)
+#ifdef readl_be
 BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
+#endif

 #endif

This wouldn't define wait_bit_be*() on archs which doesn't implement
readw_be or readl_be.

A build with the updated patch is scheduled at
https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381

-- 
- Daniel



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

Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak

[Simon Glass]

Hi,

On 22 January 2018 at 09:36, Tom Rini  wrote:
> On Mon, Jan 22, 2018 at 04:57:41PM +0100, Maxime Ripard wrote:
>> On Mon, Jan 22, 2018 at 07:49:41AM -0500, Tom Rini wrote:
>> > On Mon, Jan 22, 2018 at 01:46:46PM +0100, Maxime Ripard wrote:
>> > > Hi,
>> > >
>> > > On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
>> > > > > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
>> > > > >> On 16 January 2018 at 01:16, Maxime Ripard
>> > > > >>  wrote:
>> > > > >> > Allow boards and architectures to override the default 
>> > > > >> > environment lookup
>> > > > >> > code by overriding env_get_location.
>> > > > >> >
>> > > > >> > Reviewed-by: Andre Przywara 
>> > > > >> > Reviewed-by: Lukasz Majewski 
>> > > > >> > Signed-off-by: Maxime Ripard 
>> > > > >> > ---
>> > > > >> >  env/env.c | 20 +++-
>> > > > >> >  1 file changed, 19 insertions(+), 1 deletion(-)
>> > > > >> >
>> > > > >>
>> > > > >> I still don't really understand why this needs to be a weak 
>> > > > >> function.
>> > > > >> If the board knows the priority order, can it not put it into
>> > > > >> global_data? We could have a little u8 array of 4 items with a
>> > > > >> terminator?
>> > > > >
>> > > > > Sure that would be simpler, but that would also prevent us from doing
>> > > > > "smart" things based on data other than just whether the previous
>> > > > > environment is usable. Things based for example on a GPIO state, or a
>> > > > > custom algorithm to transition (or duplicate) the environment.
>> > > >
>> > > > In that case the board could read the GPIO state, or the algorithm,
>> > > > and then set up the value.
>> > > >
>> > > > Basically I am saying it could set up the priority order in advance of
>> > > > it being needed, rather than having a callback.
>> > >
>> > > Aren't we kind of stuck here?
>> > >
>> > > On the previous iterations, we already discussed this and Tom
>> > > eventually told he was in favour of __weak functions, and the
>> > > discussion stopped there. I assumed you were ok with it.
>> > >
>> > > I'd really want to move forward on that. This is something that is
>> > > really biting us *now* and I'd hate to miss yet another merge window
>> > > because of debates like this.
>> >
>> > Yes, I think this is where we want things to be weak, with a reasonable
>> > default.  If we start to see that "everyone" does the same thing by and
>> > large we can re-evaluate.
>>
>> Ok.
>>
>> I've fixed the bug I mentionned the other day on IRC, should I send a PR?
>
> Lets give Simon a chance to provide any other feedback here, or another
> argument to convince me that no, we don't want to have this abstracted
> by a weak function but instead ..., thanks!

I suspect there is a reason why this is better than what I propose.
Perhaps when I try it out it will become apparent.

So let's go ahead and revisit later if we have new information.

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2] arm: add support for PDU001

[Tom Rini]

On Mon, Jan 22, 2018 at 05:33:59PM +0100, Felix Brack wrote:
> Hi Tom,
> 
> On 22.01.2018 16:15, Tom Rini wrote:
> > On Mon, Jan 22, 2018 at 12:07:49PM +0100, Felix Brack wrote:
> > 
> >> This patch adds support for the PDU001 board.
> >>
> >> Signed-off-by: Felix Brack 
> > [snip]
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index f6d57f5..15349b3 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -1339,6 +1339,7 @@ source "board/vscom/baltos/Kconfig"
> >>  source "board/woodburn/Kconfig"
> >>  source "board/work-microwave/work_92105/Kconfig"
> >>  source "board/zipitz2/Kconfig"
> >> +source "board/eets/pdu001/Kconfig"
> > 
> Sorry, missed that one.
> 
> > This should stay alphabetized.
> > 
> > [snip]
> >> new file mode 100644
> >> index 000..0967e82
> >> --- /dev/null
> >> +++ b/arch/arm/dts/am335x-pdu001.dts
> >
> > So, have you pushed this platform upstream to Linux?
> > 
> Not yet. I would like to follow the same procedure for Linux as I did
> for U-Boot, i.e. first finish the work on all drivers required by the board.

OK.  Please just make sure to keep it in sync with feedback you get from
upstream there, thanks!

> >> @@ -0,0 +1,612 @@
> >> +/*
> >> + * pdu001.dts
> >> + *
> >> + * EETS GmbH PDU001 board device tree file
> >> + *
> >> + * Copyright (C) 2018 EETS GmbH - http://www.eets.ch/
> >> + *
> >> + * Copyright (C) 2011, Texas Instruments, Incorporated - 
> >> http://www.ti.com/
> >> + *
> >> + * SPDX-License-Identifier:  GPL-2.0-or-later
> > 
> > This is not a free-form tag.  Here and elsewhere you want "GPL-2.0+".
> >
> Well, I followed the advice on https://spdx.org/licenses/ when using
> this tag. According to SPDX "GPL-2.0+" is deprecated as of V2.0rc2 and
> the use of "GPL-2.0-or-later" is suggested instead. However I'm fine
> using "GPL-2.0+", just let me know.

Ugh.  For now, please do GPL-2.0+ and I'll take an action to do a
treewide update to match what's preferred as of 3.0.

-- 
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 13/15] env: Mark env_get_location as weak

[Tom Rini]

On Mon, Jan 22, 2018 at 04:57:41PM +0100, Maxime Ripard wrote:
> On Mon, Jan 22, 2018 at 07:49:41AM -0500, Tom Rini wrote:
> > On Mon, Jan 22, 2018 at 01:46:46PM +0100, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
> > > > > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
> > > > >> On 16 January 2018 at 01:16, Maxime Ripard
> > > > >>  wrote:
> > > > >> > Allow boards and architectures to override the default environment 
> > > > >> > lookup
> > > > >> > code by overriding env_get_location.
> > > > >> >
> > > > >> > Reviewed-by: Andre Przywara 
> > > > >> > Reviewed-by: Lukasz Majewski 
> > > > >> > Signed-off-by: Maxime Ripard 
> > > > >> > ---
> > > > >> >  env/env.c | 20 +++-
> > > > >> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > > > >> >
> > > > >>
> > > > >> I still don't really understand why this needs to be a weak function.
> > > > >> If the board knows the priority order, can it not put it into
> > > > >> global_data? We could have a little u8 array of 4 items with a
> > > > >> terminator?
> > > > >
> > > > > Sure that would be simpler, but that would also prevent us from doing
> > > > > "smart" things based on data other than just whether the previous
> > > > > environment is usable. Things based for example on a GPIO state, or a
> > > > > custom algorithm to transition (or duplicate) the environment.
> > > > 
> > > > In that case the board could read the GPIO state, or the algorithm,
> > > > and then set up the value.
> > > > 
> > > > Basically I am saying it could set up the priority order in advance of
> > > > it being needed, rather than having a callback.
> > > 
> > > Aren't we kind of stuck here?
> > > 
> > > On the previous iterations, we already discussed this and Tom
> > > eventually told he was in favour of __weak functions, and the
> > > discussion stopped there. I assumed you were ok with it.
> > > 
> > > I'd really want to move forward on that. This is something that is
> > > really biting us *now* and I'd hate to miss yet another merge window
> > > because of debates like this.
> > 
> > Yes, I think this is where we want things to be weak, with a reasonable
> > default.  If we start to see that "everyone" does the same thing by and
> > large we can re-evaluate.
> 
> Ok.
> 
> I've fixed the bug I mentionned the other day on IRC, should I send a PR?

Lets give Simon a chance to provide any other feedback here, or another
argument to convince me that no, we don't want to have this abstracted
by a weak function but instead ..., 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] arm: add support for PDU001

[Felix Brack]

Hi Tom,

On 22.01.2018 16:15, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 12:07:49PM +0100, Felix Brack wrote:
> 
>> This patch adds support for the PDU001 board.
>>
>> Signed-off-by: Felix Brack 
> [snip]
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index f6d57f5..15349b3 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1339,6 +1339,7 @@ source "board/vscom/baltos/Kconfig"
>>  source "board/woodburn/Kconfig"
>>  source "board/work-microwave/work_92105/Kconfig"
>>  source "board/zipitz2/Kconfig"
>> +source "board/eets/pdu001/Kconfig"
> 
Sorry, missed that one.

> This should stay alphabetized.
> 
> [snip]
>> new file mode 100644
>> index 000..0967e82
>> --- /dev/null
>> +++ b/arch/arm/dts/am335x-pdu001.dts
>
> So, have you pushed this platform upstream to Linux?
> 
Not yet. I would like to follow the same procedure for Linux as I did
for U-Boot, i.e. first finish the work on all drivers required by the board.

>> @@ -0,0 +1,612 @@
>> +/*
>> + * pdu001.dts
>> + *
>> + * EETS GmbH PDU001 board device tree file
>> + *
>> + * Copyright (C) 2018 EETS GmbH - http://www.eets.ch/
>> + *
>> + * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
>> + *
>> + * SPDX-License-Identifier:  GPL-2.0-or-later
> 
> This is not a free-form tag.  Here and elsewhere you want "GPL-2.0+".
>
Well, I followed the advice on https://spdx.org/licenses/ when using
this tag. According to SPDX "GPL-2.0+" is deprecated as of V2.0rc2 and
the use of "GPL-2.0-or-later" is suggested instead. However I'm fine
using "GPL-2.0+", just let me know.

> [snip]
>> +ocp {
>> +u-boot,dm-pre-reloc;
>> +};
>> +};
>> +
>> +_wkup {
>> +u-boot,dm-pre-reloc;
>> +};
>> +
>> + {
>> +u-boot,dm-pre-reloc;
>> +};
>> +
> 
> For long term maintenance you'll want to move these U-Boot specific
> parts to a am335x-pdu001-u-boot.dtsi file so that you can re-sync the
> main DTS file with Linux and not have any important U-Boot changes be
> dropped.
>
Thanks for the hint!

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

Re: [U-Boot] [PATCH] fs: btrfs: Fix unaligned memory accesses

[Robert Nelson]

On Sat, Jan 20, 2018 at 1:17 AM, Alberto Sánchez Molero
 wrote:
> Loading files stored with lzo compression from a btrfs filesystem was
> producing unaligned memory accesses, which were causing a data abort
> and a reset on an Orange Pi Zero.
>
> The change in hash.c is not triggered by any error but follows the
> same pattern. Please confirm.
>
> Fixed according to doc/README.unaligned-memory-access.txt

Awesome!

Marek, this fixes the issue i was also seeing on the Beagle's with lzo
compression.

Tested-by: Robert Nelson 


>
> Signed-off by: Alberto Sánchez Molero 
> ---
>  fs/btrfs/compression.c | 5 +++--
>  fs/btrfs/hash.c| 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index a59ff5a..4e685a0 100644
> --- a/fs/btrfs/compression.c
> +++ b/fs/btrfs/compression.c
> @@ -9,6 +9,7 @@
>  #include "btrfs.h"
>  #include 
>  #include 
> +#include 
>
>  static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8 *dbuf, u32 dlen)
>  {
> @@ -19,7 +20,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
> u8 *dbuf, u32 dlen)
>  if (clen < 4)
>  return -1;
>
> -tot_len = le32_to_cpu(*(u32 *) cbuf);
> +tot_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
>  cbuf += 4;
>  clen -= 4;
>  tot_len -= 4;
> @@ -32,7 +33,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
> u8 *dbuf, u32 dlen)
>  res = 0;
>
>  while (tot_len > 4) {
> -in_len = le32_to_cpu(*(u32 *) cbuf);
> +in_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
>  cbuf += 4;
>  clen -= 4;
>
> diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
> index f8a50e5..1c75ea8 100644
> --- a/fs/btrfs/hash.c
> +++ b/fs/btrfs/hash.c
> @@ -8,6 +8,7 @@
>
>  #include "btrfs.h"
>  #include 
> +#include 
>
>  static u32 btrfs_crc32c_table[256];
>
> @@ -34,5 +35,5 @@ u32 btrfs_csum_data(char *data, u32 seed, size_t len)
>
>  void btrfs_csum_final(u32 crc, void *result)
>  {
> -*((u32 *) result) = cpu_to_le32(~crc);
> +put_unaligned(cpu_to_le32(~crc), (u32 *) result);
>  }
> --
> 2.16.0
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Fabio,

On 22/01/2018 16:23, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic  wrote:
> 
>>> --- /dev/null
>>> +++ b/board/freescale/mx8mq_evk/README
>>> @@ -0,0 +1,47 @@
>>> +U-Boot for the NXP i.MX8MQ EVK board
>>> +
>>> +Quick Start
>>> +
>>> +- Build the ARM Trusted firmware binary
>>> +- Build U-Boot
>>> +- Get ddr fimware and tools
>>> +- Generate flash.bin using imx-mkimage
>>> +- Boot
>>> +
>>> +Get and Build the ARM Trusted firmware
>>> +
>>> +Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>>
>> This is currently not enough - master is empty, which branch should be
>> selected ?
> 
> Yes, the README from this patch does not allow us to create a bootable image.
> 
> Diego sent a patch today that puts more details so that we can really
> boot the mx8mevk board.
> 
>> Is this maintainable ?
>>
>> I am asking why this is coming from here and not from an official
>> source, like :
>>
>> https://github.com/ARM-software/arm-trusted-firmware
> 
> Agreed.
> 
>> I am just asking which is the plan here. This is a fork of U-Boot's
>> mkimage tool. I did not see attempts to push changes to imximage mainline.
>>
>> Any thoughts ? This means that it is not possible inside U-Boot to
>> produce a U-Boot image, but we need an external tool that was *based* on
>> U-Boot code
> 
> Agreed. In long term imx-mkimage should go away and we should just use
> the official mkimage tool.
> 
>> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
>> it, but it is not used in further commands.
> 
> Diego's patch clarifies this point as well.
> 
>> I guess we will not have any improvement here, at least for first
>> version. I cannot say this is optimal, because it becomes difficult to
>> add further MX8M targets.
>>
>> Just an example: dramtmgX contain timings, and they are computed from
>> the RAM chip (tRAS, and so on).
>>
>> The best way (and I hope, this will go on sometimes..) should be to add
>> a table for the chosen RAM chip and registers are then computed.
>>
>> It will be even ok if there is a tool(I guess, you or the DDR-team is
>> using such as tool) to derive registers value from chip datasheet.
>>
>> Fabio, what do you think about this ?
> 
> Yes, the current method expects too much DDR code for each board and
> does not seem to scale well.
> 
>> Im open to suggestions how to go on. The big isssues with the patchset
>> is IMHO the cryptical part with the LPDDR settings. We could start to
>> merge most of patches - they were already reviewed and they are freee of
>> comments.
>>
>> Fabio, do you have a best approach ?
> 
> Yes, I agree. Please start merging the patches of the series that were
> reviewed and are in good shape.


ok, thanks, I will merge most of them.

> 
> Then Peng can rework this current patch that adds the mx8mqevk board support.
> 
> Thanks
> 

Best regards,
Stefano


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

Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak

[Maxime Ripard]

On Mon, Jan 22, 2018 at 07:49:41AM -0500, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 01:46:46PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
> > > > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
> > > >> On 16 January 2018 at 01:16, Maxime Ripard
> > > >>  wrote:
> > > >> > Allow boards and architectures to override the default environment 
> > > >> > lookup
> > > >> > code by overriding env_get_location.
> > > >> >
> > > >> > Reviewed-by: Andre Przywara 
> > > >> > Reviewed-by: Lukasz Majewski 
> > > >> > Signed-off-by: Maxime Ripard 
> > > >> > ---
> > > >> >  env/env.c | 20 +++-
> > > >> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > > >> >
> > > >>
> > > >> I still don't really understand why this needs to be a weak function.
> > > >> If the board knows the priority order, can it not put it into
> > > >> global_data? We could have a little u8 array of 4 items with a
> > > >> terminator?
> > > >
> > > > Sure that would be simpler, but that would also prevent us from doing
> > > > "smart" things based on data other than just whether the previous
> > > > environment is usable. Things based for example on a GPIO state, or a
> > > > custom algorithm to transition (or duplicate) the environment.
> > > 
> > > In that case the board could read the GPIO state, or the algorithm,
> > > and then set up the value.
> > > 
> > > Basically I am saying it could set up the priority order in advance of
> > > it being needed, rather than having a callback.
> > 
> > Aren't we kind of stuck here?
> > 
> > On the previous iterations, we already discussed this and Tom
> > eventually told he was in favour of __weak functions, and the
> > discussion stopped there. I assumed you were ok with it.
> > 
> > I'd really want to move forward on that. This is something that is
> > really biting us *now* and I'd hate to miss yet another merge window
> > because of debates like this.
> 
> Yes, I think this is where we want things to be weak, with a reasonable
> default.  If we start to see that "everyone" does the same thing by and
> large we can re-evaluate.

Ok.

I've fixed the bug I mentionned the other day on IRC, should I send a PR?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] Pull request: u-boot-spi/master

[Daniel Schwierzeck]

On 22.01.2018 16:32, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 04:28:16PM +0100, Daniel Schwierzeck wrote:
>>
>>
>> On 22.01.2018 15:59, Tom Rini wrote:
>>> On Mon, Jan 22, 2018 at 03:56:09PM +0100, Daniel Schwierzeck wrote:
 Hi Tom,

 On 22.01.2018 13:58, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
>
>> Hi Tom,
>>
>> Please pull this PR.
>>
>> thanks!
>> Jagan.
>>
>> The following changes since commit 
>> 98691a60abffb44303d7dae6e9e699d0daded930:
>>
>>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-spi.git master
>>
>> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
>>
>>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un 
>> (2018-01-22 10:39:13 +0530)
>>
>
> NAK:
>
> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> Author: Álvaro Fernández Rojas 
> Date:   Sat Jan 20 02:11:34 2018 +0100
>
> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
>
> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> This is needed for reading registers that are not aligned to 32 bits, 
> and for
> Big Endian platforms.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> Reviewed-by: Jagan Teki 
>
> Adds warnings on almost all platforms:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be16?:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> implicit declaration of function ?readw_be? 
> [-Wimplicit-function-declaration]
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> ?readl_be? [-Wimplicit-function-declaration]
>


 did this commit alone produce those warnings? The patch series itself
 builds successfully on Travis CI [1].

 [1] https://travis-ci.org/danielschwierzeck/u-boot/builds/331506036
>>>
>>> It builds, yes.  But it adds that warning too:
>>> https://travis-ci.org/danielschwierzeck/u-boot/jobs/331506059
>>>
>>> And I bisect'd down to the above commit being what adds that warning.
>>>
>>> And yes, sigh, I need to something-something to get us back to zero
>>> warnings and make -Werror at least a CONFIG option and perhaps default
>>> in travis as this isn't the first warning to come in that wasn't noticed
>>> as travis didn't fail.
>>
>> hm, since when are gcc warnings being ignored? I thought only DTC
>> warnings were suppressed. Thus I still expected to have Travis CI builds
>> marked as yellow in case of gcc warnings ;)
> 
> ... wait, you can have Travis CI do yellow for warnings?  That'd be
> handy to get back again.  Especially if we can have it for non-DTC
> warnings only.
> 

hm, I think I saw this in the past but can't find any reference in the
documentation. Sorry for creating false hopes ;)

-- 
- Daniel



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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jan 22, 2018 at 04:28:16PM +0100, Daniel Schwierzeck wrote:
> 
> 
> On 22.01.2018 15:59, Tom Rini wrote:
> > On Mon, Jan 22, 2018 at 03:56:09PM +0100, Daniel Schwierzeck wrote:
> >> Hi Tom,
> >>
> >> On 22.01.2018 13:58, Tom Rini wrote:
> >>> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> >>>
>  Hi Tom,
> 
>  Please pull this PR.
> 
>  thanks!
>  Jagan.
> 
>  The following changes since commit 
>  98691a60abffb44303d7dae6e9e699d0daded930:
> 
>    Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
> 
>  are available in the git repository at:
> 
>    git://git.denx.de/u-boot-spi.git master
> 
>  for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
> 
>    mips: bmips: enable the SPI flash on the Comtrend AR-5387un 
>  (2018-01-22 10:39:13 +0530)
> 
> >>>
> >>> NAK:
> >>>
> >>> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> >>> Author: Álvaro Fernández Rojas 
> >>> Date:   Sat Jan 20 02:11:34 2018 +0100
> >>>
> >>> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> >>>
> >>> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> >>> This is needed for reading registers that are not aligned to 32 bits, 
> >>> and for
> >>> Big Endian platforms.
> >>>
> >>> Signed-off-by: Álvaro Fernández Rojas 
> >>> Reviewed-by: Daniel Schwierzeck 
> >>> Reviewed-by: Jagan Teki 
> >>>
> >>> Adds warnings on almost all platforms:
> >>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> >>> ?wait_for_bit_be16?:
> >>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> >>> implicit declaration of function ?readw_be? 
> >>> [-Wimplicit-function-declaration]
> >>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> >>> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> >>> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> >>> ?readl_be? [-Wimplicit-function-declaration]
> >>>
> >>
> >>
> >> did this commit alone produce those warnings? The patch series itself
> >> builds successfully on Travis CI [1].
> >>
> >> [1] https://travis-ci.org/danielschwierzeck/u-boot/builds/331506036
> > 
> > It builds, yes.  But it adds that warning too:
> > https://travis-ci.org/danielschwierzeck/u-boot/jobs/331506059
> > 
> > And I bisect'd down to the above commit being what adds that warning.
> > 
> > And yes, sigh, I need to something-something to get us back to zero
> > warnings and make -Werror at least a CONFIG option and perhaps default
> > in travis as this isn't the first warning to come in that wasn't noticed
> > as travis didn't fail.
> 
> hm, since when are gcc warnings being ignored? I thought only DTC
> warnings were suppressed. Thus I still expected to have Travis CI builds
> marked as yellow in case of gcc warnings ;)

... wait, you can have Travis CI do yellow for warnings?  That'd be
handy to get back again.  Especially if we can have it for non-DTC
warnings only.

-- 
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] Pull request: u-boot-spi/master

[Daniel Schwierzeck]

On 22.01.2018 15:59, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 03:56:09PM +0100, Daniel Schwierzeck wrote:
>> Hi Tom,
>>
>> On 22.01.2018 13:58, Tom Rini wrote:
>>> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
>>>
 Hi Tom,

 Please pull this PR.

 thanks!
 Jagan.

 The following changes since commit 
 98691a60abffb44303d7dae6e9e699d0daded930:

   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)

 are available in the git repository at:

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

 for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:

   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
 10:39:13 +0530)

>>>
>>> NAK:
>>>
>>> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
>>> Author: Álvaro Fernández Rojas 
>>> Date:   Sat Jan 20 02:11:34 2018 +0100
>>>
>>> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
>>>
>>> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
>>> This is needed for reading registers that are not aligned to 32 bits, 
>>> and for
>>> Big Endian platforms.
>>>
>>> Signed-off-by: Álvaro Fernández Rojas 
>>> Reviewed-by: Daniel Schwierzeck 
>>> Reviewed-by: Jagan Teki 
>>>
>>> Adds warnings on almost all platforms:
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
>>> ?wait_for_bit_be16?:
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
>>> implicit declaration of function ?readw_be? 
>>> [-Wimplicit-function-declaration]
>>> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
>>> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
>>> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
>>> ?readl_be? [-Wimplicit-function-declaration]
>>>
>>
>>
>> did this commit alone produce those warnings? The patch series itself
>> builds successfully on Travis CI [1].
>>
>> [1] https://travis-ci.org/danielschwierzeck/u-boot/builds/331506036
> 
> It builds, yes.  But it adds that warning too:
> https://travis-ci.org/danielschwierzeck/u-boot/jobs/331506059
> 
> And I bisect'd down to the above commit being what adds that warning.
> 
> And yes, sigh, I need to something-something to get us back to zero
> warnings and make -Werror at least a CONFIG option and perhaps default
> in travis as this isn't the first warning to come in that wasn't noticed
> as travis didn't fail.
> 

hm, since when are gcc warnings being ignored? I thought only DTC
warnings were suppressed. Thus I still expected to have Travis CI builds
marked as yellow in case of gcc warnings ;)

-- 
- Daniel



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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Stefano,

On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic  wrote:

>> --- /dev/null
>> +++ b/board/freescale/mx8mq_evk/README
>> @@ -0,0 +1,47 @@
>> +U-Boot for the NXP i.MX8MQ EVK board
>> +
>> +Quick Start
>> +
>> +- Build the ARM Trusted firmware binary
>> +- Build U-Boot
>> +- Get ddr fimware and tools
>> +- Generate flash.bin using imx-mkimage
>> +- Boot
>> +
>> +Get and Build the ARM Trusted firmware
>> +
>> +Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>
> This is currently not enough - master is empty, which branch should be
> selected ?

Yes, the README from this patch does not allow us to create a bootable image.

Diego sent a patch today that puts more details so that we can really
boot the mx8mevk board.

> Is this maintainable ?
>
> I am asking why this is coming from here and not from an official
> source, like :
>
> https://github.com/ARM-software/arm-trusted-firmware

Agreed.

> I am just asking which is the plan here. This is a fork of U-Boot's
> mkimage tool. I did not see attempts to push changes to imximage mainline.
>
> Any thoughts ? This means that it is not possible inside U-Boot to
> produce a U-Boot image, but we need an external tool that was *based* on
> U-Boot code

Agreed. In long term imx-mkimage should go away and we should just use
the official mkimage tool.

> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
> it, but it is not used in further commands.

Diego's patch clarifies this point as well.

> I guess we will not have any improvement here, at least for first
> version. I cannot say this is optimal, because it becomes difficult to
> add further MX8M targets.
>
> Just an example: dramtmgX contain timings, and they are computed from
> the RAM chip (tRAS, and so on).
>
> The best way (and I hope, this will go on sometimes..) should be to add
> a table for the chosen RAM chip and registers are then computed.
>
> It will be even ok if there is a tool(I guess, you or the DDR-team is
> using such as tool) to derive registers value from chip datasheet.
>
> Fabio, what do you think about this ?

Yes, the current method expects too much DDR code for each board and
does not seem to scale well.

> Im open to suggestions how to go on. The big isssues with the patchset
> is IMHO the cryptical part with the LPDDR settings. We could start to
> merge most of patches - they were already reviewed and they are freee of
> comments.
>
> Fabio, do you have a best approach ?

Yes, I agree. Please start merging the patches of the series that were
reviewed and are in good shape.

Then Peng can rework this current patch that adds the mx8mqevk board support.

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

Re: [U-Boot] [PATCH v2] arm: add support for PDU001

[Tom Rini]

On Mon, Jan 22, 2018 at 12:07:49PM +0100, Felix Brack wrote:

> This patch adds support for the PDU001 board.
> 
> Signed-off-by: Felix Brack 
[snip]
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f6d57f5..15349b3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1339,6 +1339,7 @@ source "board/vscom/baltos/Kconfig"
>  source "board/woodburn/Kconfig"
>  source "board/work-microwave/work_92105/Kconfig"
>  source "board/zipitz2/Kconfig"
> +source "board/eets/pdu001/Kconfig"

This should stay alphabetized.

[snip]
> new file mode 100644
> index 000..0967e82
> --- /dev/null
> +++ b/arch/arm/dts/am335x-pdu001.dts

So, have you pushed this platform upstream to Linux?

> @@ -0,0 +1,612 @@
> +/*
> + * pdu001.dts
> + *
> + * EETS GmbH PDU001 board device tree file
> + *
> + * Copyright (C) 2018 EETS GmbH - http://www.eets.ch/
> + *
> + * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
> + *
> + * SPDX-License-Identifier:  GPL-2.0-or-later

This is not a free-form tag.  Here and elsewhere you want "GPL-2.0+".

[snip]
> + ocp {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +_wkup {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +

For long term maintenance you'll want to move these U-Boot specific
parts to a am335x-pdu001-u-boot.dtsi file so that you can re-sync the
main DTS file with Linux and not have any important U-Boot changes be
dropped.

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] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jan 22, 2018 at 03:56:09PM +0100, Daniel Schwierzeck wrote:
> Hi Tom,
> 
> On 22.01.2018 13:58, Tom Rini wrote:
> > On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> > 
> >> Hi Tom,
> >>
> >> Please pull this PR.
> >>
> >> thanks!
> >> Jagan.
> >>
> >> The following changes since commit 
> >> 98691a60abffb44303d7dae6e9e699d0daded930:
> >>
> >>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.denx.de/u-boot-spi.git master
> >>
> >> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
> >>
> >>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
> >> 10:39:13 +0530)
> >>
> > 
> > NAK:
> > 
> > commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> > Author: Álvaro Fernández Rojas 
> > Date:   Sat Jan 20 02:11:34 2018 +0100
> > 
> > wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> > 
> > Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> > This is needed for reading registers that are not aligned to 32 bits, 
> > and for
> > Big Endian platforms.
> > 
> > Signed-off-by: Álvaro Fernández Rojas 
> > Reviewed-by: Daniel Schwierzeck 
> > Reviewed-by: Jagan Teki 
> > 
> > Adds warnings on almost all platforms:
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> > ?wait_for_bit_be16?:
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> > implicit declaration of function ?readw_be? 
> > [-Wimplicit-function-declaration]
> > w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> > ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> > ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> > ?readl_be? [-Wimplicit-function-declaration]
> > 
> 
> 
> did this commit alone produce those warnings? The patch series itself
> builds successfully on Travis CI [1].
> 
> [1] https://travis-ci.org/danielschwierzeck/u-boot/builds/331506036

It builds, yes.  But it adds that warning too:
https://travis-ci.org/danielschwierzeck/u-boot/jobs/331506059

And I bisect'd down to the above commit being what adds that warning.

And yes, sigh, I need to something-something to get us back to zero
warnings and make -Werror at least a CONFIG option and perhaps default
in travis as this isn't the first warning to come in that wasn't noticed
as travis didn't fail.

-- 
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] Pull request: u-boot-spi/master

[Daniel Schwierzeck]

Hi Tom,

On 22.01.2018 13:58, Tom Rini wrote:
> On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:
> 
>> Hi Tom,
>>
>> Please pull this PR.
>>
>> thanks!
>> Jagan.
>>
>> The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930:
>>
>>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-spi.git master
>>
>> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
>>
>>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
>> 10:39:13 +0530)
>>
> 
> NAK:
> 
> commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
> Author: Álvaro Fernández Rojas 
> Date:   Sat Jan 20 02:11:34 2018 +0100
> 
> wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
> 
> Add 8/16/32 bits and BE/LE versions of wait_for_bit.
> This is needed for reading registers that are not aligned to 32 bits, and 
> for
> Big Endian platforms.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> Reviewed-by: Daniel Schwierzeck 
> Reviewed-by: Jagan Teki 
> 
> Adds warnings on almost all platforms:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be16?:
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: 
> implicit declaration of function ?readw_be? [-Wimplicit-function-declaration]
> w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
> ?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
> ../include/wait_bit.h:78:31: warning: implicit declaration of function 
> ?readl_be? [-Wimplicit-function-declaration]
> 


did this commit alone produce those warnings? The patch series itself
builds successfully on Travis CI [1].

[1] https://travis-ci.org/danielschwierzeck/u-boot/builds/331506036

-- 
- Daniel



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

Re: [U-Boot] [PATCH v2 6/9] tools: mkimage: add optee image type

[Andrew F. Davis]

On 01/19/2018 05:59 PM, Bryan O'Donoghue wrote:
> 
> 
> On 19/01/18 20:14, Andrew F. Davis wrote:
>> On 01/19/2018 01:43 PM, Bryan O'Donoghue wrote:
>>> This patch adds support for bootable OPTEE images to mkimage. Currently
>>> there is a (Trusted Execution Environment) TEE image type, the TEE image
>>> type is installed to a memory location with u-boot continuing to own the
>>> boot process whereas the OPTEE image type defined here is a bootable
>>> image,
>>> which typically wants to live at a defined location in memory.
>>> Defining a
>>> new image type allows us to pull out the load address and entry point
>>> defined in the OPTEE header and having a separate image type lays the
>>> foundation for a subsequent patch to validate the OPTEE memory
>>> defined in a
>>> board-port matches the link location specified in the OPTEE bootable
>>> image.
>>>
>>> example usage:
>>>
> 
>>> uTee.optee
>>>
>>> making a separate image type means you don't need to specify things like
>>> entry point and load address as you would if you were defining the OPTEE
>>> image as a linux image.
>>>
>>
>> I'm still not getting the reasoning for this all, you can have the load
>> address checks and relocation stuff inside your loadable handler:
>>
>> U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process
> Hi Andrew,
> 
> As I understand it, that's a board-specific method, which wants to
> install a TEE (jump into a TEE and return to u-boot), whereas the aim
> with this patch-set is to chain-load and boot via TEE - OPTEE in this case.
> 

This is not board-specific, this is the flow all ARM boards I know of
use (except i.MX 6).

It is certainly possible to use the same flow on TI boards if we wanted,
we just don't as in my mind OP-TEE logically should jump back to the
non-secure side were it was called from so non-secure boot can continue.
Not act as another boot loader stage.

Is there some technical reason I am missing as to why you want to use
this alternate flow?

> I should make that clearer in the patch text description.
> 

That would be great.

> The example from Peng Fang
> 
>>> mkimage -A arm -O linux -C none -a 0x9c0fffe4 -e 0x9c10 -d
>>> ./out/arm-plat-imx/core/tee.bin uTee
> 

I haven't used mkimage in a while, but how is this any different than
what we do with the kernel image? Why do we need to pull this info out
of the header when we don't do the same for Linux?

> is then simplified down to this
> 
>>> mkimage -A arm -T optee -C none -d ./out/arm-plat-imx/core/tee.bin
> > and remove the requirement to pass load and entry point on the command
> line.
> 

To me the save in this command (which should be handled automatically
during the build process), doesn't justify the additional complexity in
the boot flow.

> The boot-flow looks like this
> 
> BootROM -> u-boot {load kernel, dtb, optee} -> OPTEE -> Kernel
> 
> Whereas - as I understand it the flow on the TI examples you have is
> 
> BootROM -> u-boot {load kernel, dtb, TEE} -> TEE -> u-boot -> Kernel
> 


This is correct, we also on some platforms load additional firmware, so
returning to u-boot after each image is deployed is a must.

BootROM -> (u-boot  u-boot   u-boot  u-boot) -> kernel
 |  |  | |   |  |
 v  |  v |   v  |
 TEE ->PMMC ->   Something else, etc..

You seem to be locking yourself in with your flow, as now TEE *must* be
the last item you load. What happens when you want to make secure calls
into OP-TEE from U-Boot? You won't be able to move it back in the
stages. (We are now doing this to handle some new Android secure-boot
requirements, so it is not that far-fetched)


> Note: I do believe IH_TYPE_TEE is the right type to use for Kever's
> patch with the SPL - because again as I understand it - the model is
> 
> BootROM -> SPL -> Install TEE -> u-boot -> etc
> 
> ---
> bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Peng,

On 10/01/2018 06:20, Peng Fan wrote:
> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> DRAM.
> 
> The boot log with Arm trusted firmware console enabled:
> "
> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> PMIC:  PFUZE100 ID=0x10
> Normal Boot
> Trying to boot from MMC2
> NOTICE:  Configureing TZASC380
> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
> NOTICE:  sip svc init
> 
> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
> 
> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
> Reset cause: POR
> Model: Freescale i.MX8MQ EVK
> DRAM:  3 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> u-boot=>
> "

If I see the output here, I am expecting the setup forthe working
peripherals. Without ethernet working, why do we activate FEC and set
the PHY ?

I would suggest to start with the minimal (=that is, all that is
working), adding later when peripherals will be successfully added and
tested.

> 
> Signed-off-by: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile|2 +
>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>  board/freescale/mx8mq_evk/Kconfig|   12 +
>  board/freescale/mx8mq_evk/Makefile   |   12 +
>  board/freescale/mx8mq_evk/README |   47 +
>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
> ++
>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>  board/freescale/mx8mq_evk/spl.c  |  230 +
>  configs/mx8mq_evk_defconfig  |   27 +
>  include/configs/mx8mq_evk.h  |  269 ++
>  14 files changed, 2819 insertions(+)
>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>  create mode 100644 board/freescale/mx8mq_evk/README
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>  create mode 100644 configs/mx8mq_evk_defconfig
>  create mode 100644 include/configs/mx8mq_evk.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a895c70284..299107977f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>  
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  
> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
> +
>  dtb-$(CONFIG_RCAR_GEN3) += \
>   r8a7795-h3ulcb.dtb \
>   r8a7795-salvator-x.dtb \
> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts b/arch/arm/dts/fsl-imx8mq-evk.dts
> new file mode 100644
> index 00..f0aa3485e6
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
> @@ -0,0 +1,424 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +
> +/* First 128KB is for PSCI ATF. */
> +/memreserve/ 0x4000 0x0002;
> +
> +#include "fsl-imx8mq.dtsi"
> +
> +/ {
> + model = "Freescale i.MX8MQ EVK";
> + compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
> +
> + chosen {
> + bootargs = "console=ttymxc0,115200 
> earlycon=ec_imx6q,0x3086,115200";
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_usdhc2_vmmc: usdhc2_vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> +