from:"Guillaume GARDET"

RE: U-Boot 2023.10 does not boot from uSD on RPi4

2023-10-13 Thread Guillaume Gardet

Hi,

Indeed, your patch [2] fixes my boot problem.

Thanks,
Guillaume


From: Simon Glass 
Sent: Tuesday, October 10, 2023 4:58 PM
To: Guillaume Gardet 
Cc: Peter Robinson ; Matthias Brugger 
; Ivan Ivanov ; U-Boot Mailing List 

Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4

Hi,

On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet 
mailto:guillaume.gar...@arm.com>> wrote:
>
>
>
> > -Original Message-
> > From: Peter Robinson mailto:pbrobin...@gmail.com>>
> > Sent: Tuesday, October 10, 2023 12:22 PM
> > To: Guillaume Gardet 
> > mailto:guillaume.gar...@arm.com>>
> > Cc: mbrug...@suse.com<mailto:mbrug...@suse.com>; Ivan Ivanov 
> > mailto:ivan.iva...@suse.com>>; Simon Glass
> > mailto:s...@chromium.org>>; 
> > u-boot@lists.denx.de<mailto:u-boot@lists.denx.de>
> > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> >
> > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > mailto:guillaume.gar...@arm.com>> wrote:
> > >
> > > Hi,
> > >
> > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > This has been found on openSUSE Tumbleweed. The only diff we need is:
> > >   -CONFIG_OF_EMBED=y
> > >   +CONFIG_OF_BOARD=y
> > > To use firmware provided Device Tree. But that should not affect the mmc
> > behavior too much, I think.
> >
> > I've been booting Fedora fine on a RPi4 BUT there's issues with the display
> > turning off [1] when the accelerated display modules load
> > (vc4) as a result of this patch set. Can you confirm if that's the same 
> > problem
> > you're seeing?
>
> No, that's not my problem. My issue is grub was not loaded by u-boot from uSD.
> It seems more like Simon's problem: 
> https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
>
> @Simon, can you check if the patch below fixes your boot problem on RPi4, 
> please?

This has been reported at least twice before. There is a fix [2] which is in my 
queue to apply.

Regarding the display problem, I got my rpi4 running again and Fedora 
installed, but I won't get back to it until the end of the week as I'm at osfc.

Regards,
Simon

>
> Thanks,
> Guillaume
>

[2] 
https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/

> >
> > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html
> >
> > > 'git bisect' points to:
> > > **
> > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9
> > > Author: Simon Glass mailto:s...@chromium.org>>
> > > Date:   Thu Jul 27 15:54:28 2023 -0600
> > >
> > > arm: rpi: Switch to standard boot
> > >
> > > Drop use of the distro scripts and use standard boot instead.
> > >
> > > We don't need to specify the mmc devices individually, since they are
> > > used in order from 0 to 2, and standard boot uses that order anyway.
> > >
> > > Signed-off-by: Simon Glass 
> > > mailto:s...@chromium.org>>
> > > **
> > >
> > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 
> > > nor RPi
> > Zero 2 W):
> > > **
> > > diff --git a/board/raspberrypi/rpi/rpi.env
> > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644
> > > --- a/board/raspberrypi/rpi/rpi.env
> > > +++ b/board/raspberrypi/rpi/rpi.env
> > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> > >  fdt_addr_r=0x0260
> > >  ramdisk_addr_r=0x0270
> > >
> > > -boot_targets=mmc usb pxe dhcp
> > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> > > **
> > >
> > > So, the comment from Simon " We don't need to specify the mmc devices
> > individually, since they are used in order from 0 to 2, and standard boot 
> > uses that
> > order anyway" seems wrong for the RPi4 case.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended 
> > recipient,
> > please notify the sender immediately and do not disclose the contents to any
> > other person, use it for any purpose, or store or copy the information in 
> > any
> > medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

RE: U-Boot 2023.10 does not boot from uSD on RPi4

2023-10-10 Thread Guillaume Gardet



> -Original Message-
> From: Peter Robinson 
> Sent: Tuesday, October 10, 2023 12:22 PM
> To: Guillaume Gardet 
> Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass
> ; u-boot@lists.denx.de
> Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
>
> On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
>  wrote:
> >
> > Hi,
> >
> > U-Boot 2023.10 does not boot from uSD on RPi4.
> > This has been found on openSUSE Tumbleweed. The only diff we need is:
> >   -CONFIG_OF_EMBED=y
> >   +CONFIG_OF_BOARD=y
> > To use firmware provided Device Tree. But that should not affect the mmc
> behavior too much, I think.
>
> I've been booting Fedora fine on a RPi4 BUT there's issues with the display
> turning off [1] when the accelerated display modules load
> (vc4) as a result of this patch set. Can you confirm if that's the same 
> problem
> you're seeing?

No, that's not my problem. My issue is grub was not loaded by u-boot from uSD.
It seems more like Simon's problem: 
https://lists.denx.de/pipermail/u-boot/2023-October/533162.html

@Simon, can you check if the patch below fixes your boot problem on RPi4, 
please?

Thanks,
Guillaume

>
> [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html
>
> > 'git bisect' points to:
> > **
> > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9
> > Author: Simon Glass 
> > Date:   Thu Jul 27 15:54:28 2023 -0600
> >
> > arm: rpi: Switch to standard boot
> >
> > Drop use of the distro scripts and use standard boot instead.
> >
> > We don't need to specify the mmc devices individually, since they are
> > used in order from 0 to 2, and standard boot uses that order anyway.
> >
> > Signed-off-by: Simon Glass 
> > **
> >
> > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor 
> > RPi
> Zero 2 W):
> > **
> > diff --git a/board/raspberrypi/rpi/rpi.env
> > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644
> > --- a/board/raspberrypi/rpi/rpi.env
> > +++ b/board/raspberrypi/rpi/rpi.env
> > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> >  fdt_addr_r=0x0260
> >  ramdisk_addr_r=0x0270
> >
> > -boot_targets=mmc usb pxe dhcp
> > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> > **
> >
> > So, the comment from Simon " We don't need to specify the mmc devices
> individually, since they are used in order from 0 to 2, and standard boot 
> uses that
> order anyway" seems wrong for the RPi4 case.
> >
> > Cheers,
> > Guillaume
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

U-Boot 2023.10 does not boot from uSD on RPi4

2023-10-10 Thread Guillaume Gardet

Hi,

U-Boot 2023.10 does not boot from uSD on RPi4.
This has been found on openSUSE Tumbleweed. The only diff we need is:
  -CONFIG_OF_EMBED=y
  +CONFIG_OF_BOARD=y
To use firmware provided Device Tree. But that should not affect the mmc 
behavior too much, I think.

'git bisect' points to:
**
commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9
Author: Simon Glass 
Date:   Thu Jul 27 15:54:28 2023 -0600

arm: rpi: Switch to standard boot

Drop use of the distro scripts and use standard boot instead.

We don't need to specify the mmc devices individually, since they are
used in order from 0 to 2, and standard boot uses that order anyway.

Signed-off-by: Simon Glass 
**

The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor RPi 
Zero 2 W):
**
diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
index 30228285ed..02210b97b5 100644
--- a/board/raspberrypi/rpi/rpi.env
+++ b/board/raspberrypi/rpi/rpi.env
@@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
 fdt_addr_r=0x0260
 ramdisk_addr_r=0x0270

-boot_targets=mmc usb pxe dhcp
+boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
**

So, the comment from Simon " We don't need to specify the mmc devices 
individually, since they are used in order from 0 to 2, and standard boot uses 
that order anyway" seems wrong for the RPi4 case.

Cheers,
Guillaume

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re : Re: Commit 76c2ff3e broke backlight on Chromebook snow

2021-10-22 Thread Guillaume GARDET



Hi Dario,

- Dario Binacchi  a écrit :
> Hi Guillaume,
> 
> > Il 21/10/2021 16:47 Guillaume GARDET  ha scritto:
> > 
> >  
> > Hi,
> > 
> > Commit 76c2ff3e [0] broke backlight on Chromebook snow.
> > A revert on top of 2021.10 restores the backlight.
> > Not sure why it breaks on Chromebook snow yet. Dario, any idea how to fix 
> > this?
> 
> Is it possible that max_level is equal to min_level and therefore division 
> by zero is done?

I do not think so, because u-boot does not crash and the DTS file has multiple 
levels:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-snow.dts#L243

I think the problem occurs when 'cur_level == max_level', which is also the 
default value in the DTS.
If I change the default-brightness-level to 6 (instead of 7), then the 
backlight works again, which would confirm the assumption above.
pwm_backlight_set_brightness seems to set cur_level to max value by default. 
Maybe the driver thinks there is nothing to do, since current level is also the 
desired level?


Cheers,
Guillaume


> 
> Thanks and regards,
> Dario
> > 
> > Cheers,
> > Guillaume

Commit 76c2ff3e broke backlight on Chromebook snow

2021-10-21 Thread Guillaume GARDET



Hi,

Commit 76c2ff3e [0] broke backlight on Chromebook snow.
A revert on top of 2021.10 restores the backlight.
Not sure why it breaks on Chromebook snow yet. Dario, any idea how to fix this?

Cheers,
Guillaume

EHCI timeout on Beagleboard xM with u-boot 2020.01

2020-01-15 Thread Guillaume Gardet

Hi,

Booting u-boot 2020.01 on a Beagleboard xM, I get the following EHCI timeouts:
**
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
2 USB Device(s) found
   scanning usb for ethernet devices... 0 Ethernet Device(s) found
**

Cheers,
Guillaume

RE: SPL too large for firefly-rk3288 and tinker-rk3288 since 2020.01

2020-01-10 Thread Guillaume Gardet



> -Original Message-
> From: Jagan Teki 
> Sent: 10 January 2020 11:37
> To: Guillaume Gardet 
> Cc: Simon Glass ; Lin Huang ; u-
> b...@lists.denx.de; nd 
> Subject: Re: SPL too large for firefly-rk3288 and tinker-rk3288 since 2020.01
> 
> On Fri, Jan 10, 2020 at 4:02 PM Guillaume Gardet 
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Jagan Teki 
> > > Sent: 10 January 2020 11:13
> > > To: Guillaume Gardet 
> > > Cc: Simon Glass ; Lin Huang ;
> > > u- b...@lists.denx.de
> > > Subject: Re: SPL too large for firefly-rk3288 and tinker-rk3288
> > > since 2020.01
> > >
> > > On Fri, Jan 10, 2020 at 3:12 PM Guillaume Gardet
> > > 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > since 2020.01, SPL image is too large for rk3288 boards (at least
> > > > firefly-rk3288
> > > and tinker-rk3288), because I get respectively:
> > > >   [  356s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T
> > > > rksd u-boot-
> > > spl.rksd
> > > >   [  356s] Error: SPL image is too large (size 0x9800 than 0x8000)
> > > > And:
> > > >   [  305s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T
> > > > rksd u-boot-
> > > spl.rksd
> > > >   [  305s] Error: SPL image is too large (size 0xb800 than 0x8000)
> > >
> > > Both the board now TPL-enabled, so create boot image with TPL then
> > > concatenate SPL.
> >
> > What do you mean by "then concatenate SPL"?
> 
> ₹ ./tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin out
> Image Type:   Rockchip RK32 (SD/MMC) boot image
> Init Data Size: 20480 bytes
> ₹ cat spl/u-boot-spl-dtb.bin >> out

Ok, thanks!

Guillaume

RE: SPL too large for firefly-rk3288 and tinker-rk3288 since 2020.01

2020-01-10 Thread Guillaume Gardet



> -Original Message-
> From: Jagan Teki 
> Sent: 10 January 2020 11:13
> To: Guillaume Gardet 
> Cc: Simon Glass ; Lin Huang ; u-
> b...@lists.denx.de
> Subject: Re: SPL too large for firefly-rk3288 and tinker-rk3288 since 2020.01
> 
> On Fri, Jan 10, 2020 at 3:12 PM Guillaume Gardet 
> wrote:
> >
> > Hi,
> >
> > since 2020.01, SPL image is too large for rk3288 boards (at least 
> > firefly-rk3288
> and tinker-rk3288), because I get respectively:
> >   [  356s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T rksd u-boot-
> spl.rksd
> >   [  356s] Error: SPL image is too large (size 0x9800 than 0x8000)
> > And:
> >   [  305s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T rksd u-boot-
> spl.rksd
> >   [  305s] Error: SPL image is too large (size 0xb800 than 0x8000)
> 
> Both the board now TPL-enabled, so create boot image with TPL then
> concatenate SPL.

What do you mean by "then concatenate SPL"?

SPL too large for firefly-rk3288 and tinker-rk3288 since 2020.01

2020-01-10 Thread Guillaume Gardet

Hi,

since 2020.01, SPL image is too large for rk3288 boards (at least 
firefly-rk3288 and tinker-rk3288), because I get respectively:
  [  356s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T rksd 
u-boot-spl.rksd
  [  356s] Error: SPL image is too large (size 0x9800 than 0x8000)
And:
  [  305s] + ./tools/mkimage -n rk3288 -d spl/u-boot-spl.bin -T rksd 
u-boot-spl.rksd
  [  305s] Error: SPL image is too large (size 0xb800 than 0x8000)

This is with gcc 9.2.1

Cheers,
Guillaume

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before mmc0/1

2019-08-30 Thread Guillaume Gardet

Hi,

I got no feedback on this patch. Is there anything blocking it?

Guillaume


> -Original Message-
> From: Guillaume GARDET 
> Sent: 24 July 2019 09:10
> To: u-boot@lists.denx.de
> Cc: Guillaume Gardet ; Lukasz Majewski
> ; Anand Moon ; Simon Glass
> ; Minkyu Kang 
> Subject: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before
> mmc0/1
> 
> As stated in commit a61a4a1db009e3e600258551a01b54c4f50ec103 with
> DM_MMC, exynos boards now enumarates external SD/MMC slot as mmc2,
> instead of mmc1 with legacy mode. Moving mmc2 before mmc1/0 restore
> the previous behavior of trying external SD/MMC before internal slot.
> 
> Signed-off-by: Guillaume GARDET 
> 
> Cc: Lukasz Majewski 
> Cc: Anand Moon 
> Cc: Simon Glass 
> Cc: Minkyu Kang 
> 
> ---
>  include/configs/exynos5-common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-
> common.h
> index 397bbf6d9d..e0a4d76d53 100644
> --- a/include/configs/exynos5-common.h
> +++ b/include/configs/exynos5-common.h
> @@ -128,9 +128,9 @@
>  #define EXYNOS_IRAM_SECONDARY_BASE   0x02020018
> 
>  #define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 2) \
>   func(MMC, mmc, 1) \
>   func(MMC, mmc, 0) \
> - func(MMC, mmc, 2) \
>   func(PXE, pxe, na) \
>   func(DHCP, dhcp, na)
> 
> --
> 2.22.0

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

[U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before mmc0/1

2019-07-24 Thread Guillaume GARDET

As stated in commit a61a4a1db009e3e600258551a01b54c4f50ec103 with DM_MMC,
exynos boards now enumarates external SD/MMC slot as mmc2, instead of mmc1
with legacy mode. Moving mmc2 before mmc1/0 restore the previous behavior 
of trying external SD/MMC before internal slot.

Signed-off-by: Guillaume GARDET 

Cc: Lukasz Majewski 
Cc: Anand Moon 
Cc: Simon Glass 
Cc: Minkyu Kang 

---
 include/configs/exynos5-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h
index 397bbf6d9d..e0a4d76d53 100644
--- a/include/configs/exynos5-common.h
+++ b/include/configs/exynos5-common.h
@@ -128,9 +128,9 @@
 #define EXYNOS_IRAM_SECONDARY_BASE 0x02020018
 
 #define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 2) \
func(MMC, mmc, 1) \
func(MMC, mmc, 0) \
-   func(MMC, mmc, 2) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
-- 
2.22.0

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

[U-Boot] X850 V1.3 hat for Raspberry Pi 3 is not working with u-boot

2019-03-27 Thread Guillaume GARDET


Hi,

I am trying to use a X850 V1.3 hat (USB/mSATA) for Raspberry Pi 3: 
http://www.raspberrypiwiki.com/index.php/X850#Installation_Guide_For_X850_V1.3_Old_Version

It works to load firmware (most of the time), but it fails in u-boot with:
  starting USB...
  USB0:   scanning bus 0 for devices... usb_new_device: Cannot read 
configuration, skipping device 152d:0578

or just fails to find it (after a long timeout):
  USB0:   scanning bus 0 for devices... 4 USB Device(s) found
 scanning usb for storage devices... 0 Storage Device(s) found

Only once I got it detected:
  starting USB...
  USB0:   scanning bus 0 for devices... 4 USB Device(s) found
 scanning usb for storage devices... 1 Storage Device(s) found
  Hit any key to stop autoboot:  0 
  (snip)
  Device 0: Vendor: JMicron  Rev: 0204 Prod: Generic 
  Type: Hard Disk
  Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
  ... is now current device

But then, the loaded EFI payload seems to be corrupted (bad read?).


Please note it is working fine when connected to a Linux PC host, without 
external 5V.


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

[U-Boot] Re : Re: [PATCH] exynos: allow SPL to build in thumb mode

2019-01-04 Thread Guillaume GARDET


Hi,

- Siarhei Siamashka  a écrit :
> On Wed,  2 Jan 2019 14:31:41 +0100
> Guillaume GARDET  wrote:
> 
> > Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
> > ends-up in the following error:
> > 
> > Error: Thumb encoding does not support an immediate here -- `msr 
> > cpsr_c,#0x13|0xC0'
> > 
> > Use an intermediate register to be able to use thumb for exynos5 SPL.
> > 
> > 
> > Signed-off-by: Guillaume GARDET 
> > 
> > Cc: Albert Aribaud 
> > Cc: Minkyu Kang 
> > Cc: Tom Rini 
> > 
> > ---
> >  arch/arm/mach-exynos/include/mach/system.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-exynos/include/mach/system.h 
> > b/arch/arm/mach-exynos/include/mach/system.h
> > index 4837781957..81fa9800b4 100644
> > --- a/arch/arm/mach-exynos/include/mach/system.h
> > +++ b/arch/arm/mach-exynos/include/mach/system.h
> > @@ -58,7 +58,8 @@ struct exynos5_sysreg {
> >  /* Move 0xd3 value to CPSR register to enable SVC mode */
> >  #define svc32_mode_en() __asm__ __volatile__   
> > \
> > ("@ I disable, Mode: 0x13 - SVC\n\t"  \
> > -"msr cpsr_c, #0x13|0xC0\n\t" : : )
> > +"mov r0, #0x13|0xC0\n\t"   \
> > +"msr cpsr_c, r0\n\t" : : )
> 
> This line needs "r0" to be also added to the clobber list. If you
> don't do this, then you may encounter sporadic r0 corruption
> problem depending on the compiler version or optimization settings.
> 
> This would be:
> 
> "msr cpsr_c, r0\n\t" : : : "r0")
> 
> See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html for more
> details.
> 
> An even better option is to just use something like this and give
> the compiler freedom to pick any register:
> 
> "msr cpsr_c, %0\n\t" : : "r"(0x13|0xC0))

Thanks for the report Siarhei.

Minkyu, please merge also this patch: 
https://lists.denx.de/pipermail/u-boot/2019-January/353533.html

Thanks,
Guillaume


> 
> -- 
> Best regards,
> Siarhei Siamashka

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

[U-Boot] [PATCH] exynos: Leave the compiler to choose the register to avoid possible r0 corruption

2019-01-04 Thread Guillaume GARDET

Reported-by: Siarhei Siamashka 
Signed-off-by: Guillaume GARDET 

Cc: Albert Aribaud 
Cc: Minkyu Kang 
Cc: Tom Rini 
---
 arch/arm/mach-exynos/include/mach/system.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/system.h 
b/arch/arm/mach-exynos/include/mach/system.h
index 81fa9800b4..48f13c7648 100644
--- a/arch/arm/mach-exynos/include/mach/system.h
+++ b/arch/arm/mach-exynos/include/mach/system.h
@@ -58,8 +58,7 @@ struct exynos5_sysreg {
 /* Move 0xd3 value to CPSR register to enable SVC mode */
 #define svc32_mode_en() __asm__ __volatile__   \
("@ I disable, Mode: 0x13 - SVC\n\t"  \
-"mov r0, #0x13|0xC0\n\t"   \
-"msr cpsr_c, r0\n\t" : : )
+"msr cpsr_c, %0\n\t" : : "r"(0x13|0xC0))
 
 /* Set program counter with the given value */
 #define set_pc(x) __asm__ __volatile__ ("mov pc, %0\n\t" : : "r"(x))
-- 
2.20.1


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

[U-Boot] Re : Re : Re: please pull u-boot-samsung master

2019-01-02 Thread Guillaume GARDET


Hi,


- Guillaume GARDET  a écrit :
> 
> Hi,
> 
> - Minkyu Kang  a écrit :
> > Dear Guillaume GARDET,
> > 
> > On 28/12/18 00:41, Tom Rini wrote:
> > > On Thu, Dec 27, 2018 at 12:49:53PM +0900, Minkyu Kang wrote:
> > > 
> > >> Dear Tom,
> > >>
> > >> The following changes since commit 
> > >> 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
> > >>
> > >>   Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
> > >>
> > >> are available in the git repository at:
> > >>
> > >>   git://git.denx.de/u-boot-samsung master
> > >>
> > >> for you to fetch changes up to c96d90367a6a229210b8b16681cfe9e5c8aeced1:
> > >>
> > >>   exynos: imply SYS_THUMB_BUILD (2018-12-26 11:57:48 +0900)
> > >>
> > >> --------
> > >> Anand Moon (2):
> > >>   exynos5-dt-types: add missing dtb file for Odroid HC1/HC2
> > >>   odroid: Update README.odroid for support of Odroid HC1
> > >>
> > >> Guillaume GARDET (1):
> > >>   exynos: imply SYS_THUMB_BUILD
> > >>
> > >> Seung-Woo Kim (1):
> > >>   Revert "arm: config: fix default console only to specify the 
> > >> device"
> > >>
> > >>  arch/arm/Kconfig| 1 +
> > >>  doc/README.odroid   | 7 +--
> > >>  include/configs/odroid.h| 4 ++--
> > >>  include/configs/odroid_xu3.h| 5 +++--
> > >>  include/configs/s5p_goni.h  | 4 ++--
> > >>  include/configs/s5pc210_universal.h | 4 ++--
> > >>  include/configs/trats.h | 4 ++--
> > >>  include/configs/trats2.h| 4 ++--
> > >>  8 files changed, 19 insertions(+), 14 deletions(-)
> > > 
> > > NAK:
> > > 18: Merge branch 'master' of git://git.denx.de/u-boot-samsung
> > >arm:  +   peach-pi smdk5420 peach-pit
> > > +(peach-pi,smdk5420,peach-pit) {standard input}: Assembler messages:
> > > +(peach-pi,smdk5420,peach-pit) {standard input}:117: Error: Thumb 
> > > encoding does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > > +(peach-pi,smdk5420,peach-pit) {standard input}:325: Error: Thumb 
> > > encoding does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > > +(peach-pi,smdk5420,peach-pit) make[3]: *** 
> > > [../scripts/Makefile.build:279: spl/arch/arm/mach-exynos/lowlevel_init.o] 
> > > Error 1
> > > +(peach-pi,smdk5420,peach-pit) make[2]: *** [../scripts/Makefile.spl:383: 
> > > spl/arch/arm/mach-exynos] Error 2
> > > +(peach-pi,smdk5420,peach-pit) make[1]: *** [Makefile:1597: 
> > > spl/u-boot-spl] Error 2
> > > +(peach-pi,smdk5420,peach-pit) make: *** [Makefile:148: sub-make] Error 2
> > > 
> > 
> > Because of this, thumb build feature cannot applied.
> > Do you have an idea?
> 
> We should disable thumb explicitly for this board.
> 
> I will not be in front of a computer for the next days, so please wait until 
> 2nd of January, or you can do it, if you want.

Instead of disabling thumb for SPL in 3 default configs, I sent a patch to get 
it built in thumb mode: 
  https://lists.denx.de/pipermail/u-boot/2019-January/353347.html

Build tested on peach-pi peach-pit and smdk5420 configs.

Thanks,
Guillaume


> 
> Thanks,
> Guillaume
>  
> > 
> > Thanks,
> > Minkyu Kang.
> 

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

[U-Boot] [PATCH] exynos: allow SPL to build in thumb mode

2019-01-02 Thread Guillaume GARDET

Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
ends-up in the following error:

Error: Thumb encoding does not support an immediate here -- `msr 
cpsr_c,#0x13|0xC0'

Use an intermediate register to be able to use thumb for exynos5 SPL.


Signed-off-by: Guillaume GARDET 

Cc: Albert Aribaud 
Cc: Minkyu Kang 
Cc: Tom Rini 

---
 arch/arm/mach-exynos/include/mach/system.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/include/mach/system.h 
b/arch/arm/mach-exynos/include/mach/system.h
index 4837781957..81fa9800b4 100644
--- a/arch/arm/mach-exynos/include/mach/system.h
+++ b/arch/arm/mach-exynos/include/mach/system.h
@@ -58,7 +58,8 @@ struct exynos5_sysreg {
 /* Move 0xd3 value to CPSR register to enable SVC mode */
 #define svc32_mode_en() __asm__ __volatile__   \
("@ I disable, Mode: 0x13 - SVC\n\t"  \
-"msr cpsr_c, #0x13|0xC0\n\t" : : )
+"mov r0, #0x13|0xC0\n\t"   \
+"msr cpsr_c, r0\n\t" : : )
 
 /* Set program counter with the given value */
 #define set_pc(x) __asm__ __volatile__ ("mov pc, %0\n\t" : : "r"(x))
-- 
2.20.1


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

[U-Boot] Re : Re: please pull u-boot-samsung master

2018-12-29 Thread Guillaume GARDET


Hi,

- Minkyu Kang  a écrit :
> Dear Guillaume GARDET,
> 
> On 28/12/18 00:41, Tom Rini wrote:
> > On Thu, Dec 27, 2018 at 12:49:53PM +0900, Minkyu Kang wrote:
> > 
> >> Dear Tom,
> >>
> >> The following changes since commit 
> >> 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
> >>
> >>   Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.denx.de/u-boot-samsung master
> >>
> >> for you to fetch changes up to c96d90367a6a229210b8b16681cfe9e5c8aeced1:
> >>
> >>   exynos: imply SYS_THUMB_BUILD (2018-12-26 11:57:48 +0900)
> >>
> >> 
> >> Anand Moon (2):
> >>   exynos5-dt-types: add missing dtb file for Odroid HC1/HC2
> >>   odroid: Update README.odroid for support of Odroid HC1
> >>
> >> Guillaume GARDET (1):
> >>   exynos: imply SYS_THUMB_BUILD
> >>
> >> Seung-Woo Kim (1):
> >>   Revert "arm: config: fix default console only to specify the device"
> >>
> >>  arch/arm/Kconfig| 1 +
> >>  doc/README.odroid   | 7 +--
> >>  include/configs/odroid.h| 4 ++--
> >>  include/configs/odroid_xu3.h| 5 +++--
> >>  include/configs/s5p_goni.h  | 4 ++--
> >>  include/configs/s5pc210_universal.h | 4 ++--
> >>  include/configs/trats.h | 4 ++--
> >>  include/configs/trats2.h| 4 ++--
> >>  8 files changed, 19 insertions(+), 14 deletions(-)
> > 
> > NAK:
> > 18: Merge branch 'master' of git://git.denx.de/u-boot-samsung
> >arm:  +   peach-pi smdk5420 peach-pit
> > +(peach-pi,smdk5420,peach-pit) {standard input}: Assembler messages:
> > +(peach-pi,smdk5420,peach-pit) {standard input}:117: Error: Thumb encoding 
> > does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > +(peach-pi,smdk5420,peach-pit) {standard input}:325: Error: Thumb encoding 
> > does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > +(peach-pi,smdk5420,peach-pit) make[3]: *** [../scripts/Makefile.build:279: 
> > spl/arch/arm/mach-exynos/lowlevel_init.o] Error 1
> > +(peach-pi,smdk5420,peach-pit) make[2]: *** [../scripts/Makefile.spl:383: 
> > spl/arch/arm/mach-exynos] Error 2
> > +(peach-pi,smdk5420,peach-pit) make[1]: *** [Makefile:1597: spl/u-boot-spl] 
> > Error 2
> > +(peach-pi,smdk5420,peach-pit) make: *** [Makefile:148: sub-make] Error 2
> > 
> 
> Because of this, thumb build feature cannot applied.
> Do you have an idea?

We should disable thumb explicitly for this board.

I will not be in front of a computer for the next days, so please wait until 
2nd of January, or you can do it, if you want.

Thanks,
Guillaume
 
> 
> Thanks,
> Minkyu Kang.

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

Re: [U-Boot] Re : Re: [PATCH] exynos: imply SYS_THUMB_BUILD

2018-12-21 Thread Guillaume Gardet


Hi Tom,

Le 04/12/2018 à 05:47, Minkyu Kang a écrit :

Dear Tom,

On 04/12/18 05:23, Tom Rini wrote:

On Mon, Dec 03, 2018 at 08:57:21PM +0100, Guillaume GARDET wrote:


Hi,

not sure through which tree it should go and who should take care of it?

I will likely pick this up "soon" if I don't seen an overall Samsung PR,
thanks!


It's OK to take this patch by you.

Acked-by: Minkyu Kang 



It seems you missed it for -rc2. Could you take it before the release, please?

Thanks,

Guillaume




Thanks,
Minkyu Kang.


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

Re: [U-Boot] [PATCH] omap3: beagle: Enable DM_MMC and BLK for u-boot only, not SPL

2018-12-17 Thread Guillaume Gardet



Le 21/11/2018 à 18:06, Tom Rini a écrit :

On Wed, Nov 21, 2018 at 04:13:20PM +0100, Guillaume GARDET wrote:


Also disable USB_STORAGE as it is not ready for the switch.
Tested on a Beagleboard xM rev. B.

Signed-off-by: Guillaume GARDET 

Cc: Tom Rini 
Cc: Simon Glass 

In the case of USB_STORAGE we need to turn on DM_USB and then it works.



If DM_USB is enabled, no USB controller are detected, so we loose Ethernet. Did 
I miss an additional option to enable?

Guillaume


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

[U-Boot] Re : Re: [PATCH] exynos: imply SYS_THUMB_BUILD

2018-12-03 Thread Guillaume GARDET


- Lukasz Majewski  a écrit :
> Hi Guillaume,
> 
> > Hi,
> > 
> > not sure through which tree it should go and who should take care of
> > it?
> 
> Please rebase on top of u-boot/master branch.

No need, it applies just fine.

> 
> Then Minkyu will take the patch to his tree.

Tom should take it (see Minkyu e-mail).

Thanks,
Guillaume

> 
> > 
> > Guillaume
> > 
> > - Lukasz Majewski  a écrit :
> > > Hi Guillaume,
> > >   
> > > > This patch allows smaller binaries.
> > > > This is needed for and has been tested on Arndale board, as
> > > > u-boot.bin is now bigger than the 512K load limit, with GCC8,
> > > > without thumb mode.
> > > >   
> > > 
> > > Acked-by: Lukasz Majewski 
> > >   
> > > > Signed-off-by: Guillaume GARDET 
> > > > 
> > > > Cc: Albert Aribaud 
> > > > Cc: Minkyu Kang 
> > > > Cc: Tom Rini 
> > > > ---
> > > >  arch/arm/Kconfig | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > index f5d4d39683..1ccd53fd0b 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -607,6 +607,7 @@ config ARCH_EXYNOS
> > > > select DM_SPI
> > > > select DM_SPI_FLASH
> > > > select SPI
> > > > +   imply SYS_THUMB_BUILD
> > > > imply CMD_DM
> > > > imply FAT_WRITE
> > > >
> > > 
> > > 
> > > 
> > > 
> > > Best regards,
> > > 
> > > Lukasz Majewski
> > > 
> > > --
> > > 
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lu...@denx.de  
> > 
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de

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

[U-Boot] Re : Re: [PATCH] exynos: imply SYS_THUMB_BUILD

2018-12-03 Thread Guillaume GARDET


Hi,

not sure through which tree it should go and who should take care of it?

Guillaume

- Lukasz Majewski  a écrit :
> Hi Guillaume,
> 
> > This patch allows smaller binaries.
> > This is needed for and has been tested on Arndale board, as
> > u-boot.bin is now bigger than the 512K load limit, with GCC8, without
> > thumb mode.
> > 
> 
> Acked-by: Lukasz Majewski 
> 
> > Signed-off-by: Guillaume GARDET 
> > 
> > Cc: Albert Aribaud 
> > Cc: Minkyu Kang 
> > Cc: Tom Rini 
> > ---
> >  arch/arm/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f5d4d39683..1ccd53fd0b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -607,6 +607,7 @@ config ARCH_EXYNOS
> > select DM_SPI
> > select DM_SPI_FLASH
> > select SPI
> > +   imply SYS_THUMB_BUILD
> > imply CMD_DM
> > imply FAT_WRITE
> >  
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de

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

[U-Boot] [PATCH] omap3: beagle: Enable DM_MMC and BLK for u-boot only, not SPL

2018-11-21 Thread Guillaume GARDET

Also disable USB_STORAGE as it is not ready for the switch.
Tested on a Beagleboard xM rev. B.

Signed-off-by: Guillaume GARDET 

Cc: Tom Rini 
Cc: Simon Glass 
---
 configs/omap3_beagle_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
index 4fb8aec57d..b4ea714aef 100644
--- a/configs/omap3_beagle_defconfig
+++ b/configs/omap3_beagle_defconfig
@@ -37,6 +37,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
+# CONFIG_SPL_BLK is not set
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8200
 CONFIG_LED_STATUS=y
@@ -52,6 +53,8 @@ CONFIG_LED_STATUS_GREEN_ENABLE=y
 CONFIG_LED_STATUS_GREEN=2
 CONFIG_LED_STATUS_CMD=y
 CONFIG_TWL4030_LED=y
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
@@ -66,7 +69,6 @@ CONFIG_USB_OMAP3=y
 CONFIG_USB_MUSB_GADGET=y
 CONFIG_USB_MUSB_OMAP2PLUS=y
 CONFIG_TWL4030_USB=y
-CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="TI"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
-- 
2.19.1

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

[U-Boot] [PATCH] exynos: imply SYS_THUMB_BUILD

2018-11-20 Thread Guillaume GARDET

This patch allows smaller binaries.
This is needed for and has been tested on Arndale board, as u-boot.bin is
now bigger than the 512K load limit, with GCC8, without thumb mode.

Signed-off-by: Guillaume GARDET 

Cc: Albert Aribaud 
Cc: Minkyu Kang 
Cc: Tom Rini 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f5d4d39683..1ccd53fd0b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -607,6 +607,7 @@ config ARCH_EXYNOS
select DM_SPI
select DM_SPI_FLASH
select SPI
+   imply SYS_THUMB_BUILD
imply CMD_DM
imply FAT_WRITE
 
-- 
2.19.1

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

[U-Boot] [PATCH] exynos5: allow bigger BL2 (u-boot.bin)

2018-11-19 Thread Guillaume GARDET

This patch allows SPL to load a bigger BL2 (u-boot.bin).
This is needed for and has been tested on Arndale board, as u-boot.bin is 
now bigger than 512K with GCC8.

Signed-off-by: Guillaume GARDET 

Cc: Minkyu Kang 
Cc: Tom Rini 
---
 include/configs/exynos5-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h
index cd2a9046af..7da4be5ca8 100644
--- a/include/configs/exynos5-common.h
+++ b/include/configs/exynos5-common.h
@@ -89,7 +89,7 @@
 /* Configuration of BL1, BL2, ENV Blocks on mmc */
 #define CONFIG_RES_BLOCK_SIZE  (512)
 #define CONFIG_BL1_SIZE(16 << 10) /*16 K reserved for BL1*/
-#define CONFIG_BL2_SIZE(512UL << 10UL) /* 512 KB */
+#define CONFIG_BL2_SIZE(512UL << 11UL) /* 1 MB */
 #define CONFIG_ENV_SIZE(16 << 10) /* 16 KB */
 
 #define CONFIG_BL1_OFFSET  (CONFIG_RES_BLOCK_SIZE + CONFIG_SEC_FW_SIZE)
-- 
2.19.1

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

[U-Boot] Re : Re: [PATCH] exynos5: allow bigger BL2 (u-boot.bin)

2018-11-19 Thread Guillaume GARDET


- Tom Rini  a écrit :
> On Mon, Nov 19, 2018 at 05:45:03PM +0100, Guillaume GARDET wrote:
> 
> > This patch allows SPL to load a bigger BL2 (u-boot.bin).
> > This is needed for and has been tested on Arndale board, as u-boot.bin is 
> > now bigger than 512K with GCC8.
> > 
> > Signed-off-by: Guillaume GARDET 
> > 
> > Cc: Minkyu Kang 
> > Cc: Tom Rini 
> > ---
> >  include/configs/exynos5-common.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Are these platforms using thumb2 to build?  Were it not for some early
> Cortex-A platforms with thumb2 errata I'd be strongly inclined to do a
> global switch to making that option default.

No, they are not using thumb2:
# CONFIG_SYS_THUMB_BUILD is not set
# CONFIG_SPL_SYS_THUMB_BUILD is not set


Guillaume

> 
> -- 
> Tom

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

[U-Boot] Re : Re: Re : Re: [PATCH] exynos5: allow bigger BL2 (u-boot.bin)

2018-11-19 Thread Guillaume GARDET


- Tom Rini  a écrit :
> On Mon, Nov 19, 2018 at 05:56:37PM +0100, Guillaume GARDET wrote:
> > 
> > - Tom Rini  a écrit :
> > > On Mon, Nov 19, 2018 at 05:45:03PM +0100, Guillaume GARDET wrote:
> > > 
> > > > This patch allows SPL to load a bigger BL2 (u-boot.bin).
> > > > This is needed for and has been tested on Arndale board, as u-boot.bin 
> > > > is 
> > > > now bigger than 512K with GCC8.
> > > > 
> > > > Signed-off-by: Guillaume GARDET 
> > > > 
> > > > Cc: Minkyu Kang 
> > > > Cc: Tom Rini 
> > > > ---
> > > >  include/configs/exynos5-common.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > Are these platforms using thumb2 to build?  Were it not for some early
> > > Cortex-A platforms with thumb2 errata I'd be strongly inclined to do a
> > > global switch to making that option default.
> > 
> > No, they are not using thumb2:
> > # CONFIG_SYS_THUMB_BUILD is not set
> > # CONFIG_SPL_SYS_THUMB_BUILD is not set
> 
> I would suggest switching that on instead then.  I'm always wary of
> changing stuff on the flash layout.

I tested thumb2 for SPL and u-boot.bin on arndale and it does boot properly.
u-boot.bin is 397KB with thumb2, which is OK.

Should I make the switch for Arndale board only, or on a bigger range?

Guillaume

> 
> -- 
> Tom

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

[U-Boot] Re : [U-Boot,BUG] snow: mmc: SD card access broken: unable to select a mode

2018-10-23 Thread Guillaume GARDET


Hi,

- Paweł Jarosz  a écrit :
> Hi Guillaume,
> 
> 
> Could you test this patch:
> 
> https://patchwork.ozlabs.org/patch/986180/
> 
> and tell me how it goes?

Unfortunately, it does not solve the problem.
The only solution I found so far is to disable MMC_MODE_HS and 
MMC_MODE_HS_52MHz.
See: 
https://github.com/openSUSE/u-boot/commit/ab0f592165628a43d304106ce8892375543285d4

Cheers,
Guillaume



> 
> 
> Cheers
> 
> Paweł
> 
> 

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

Re: [U-Boot] [U-Boot, BUG] snow: mmc: SD card access broken: unable to select a mode

2018-10-15 Thread Guillaume Gardet


Hi,

Le 16/05/2018 à 09:22, Guillaume Gardet a écrit :

Hi Jaehoon,


Le 26/04/2018 à 15:15, Guillaume Gardet a écrit :



Le 26/04/2018 à 12:31, Jaehoon Chung a écrit :

Hi,

On 04/09/2018 09:02 PM, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:



Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?

Sorry for late. Hmm. I will check your issue. Just disable MMC_MODE_HS, then 
it's working fine?
or HS_52MHz?


I tried to disable HS_52MHz only and it did not fix the problem. Then I tried 
to disable both HS and HS_52MHz and it fixed the problem.


Any progress on this problem?



Ping again.
The problem is still there in u-boot v2018.11-rc1.


Guillaume




Guillaume




Guillaume



Best Regards,
Jaehoon Chung



Guillaume

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
       cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
   }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
   }








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

[U-Boot] Problem with v2018-09-rc2 to boot EFI on Arndale board

2018-08-16 Thread Guillaume GARDET


Hi,

While trying to boot Grub2/EFI on Arndale board, I got the following error:
**
fdt_fixup_memory_banks: num banks 8 exceeds hardcoded limit 4. Recompile with 
higher MEMORY_BANKS_MAX?
ERROR: arch-specific fdt fixup failed
 - must RESET the board to recover.

ERROR: failed to process device tree
ERROR: failed to install device tree
812544 bytes read in 77 ms (10.1 MiB/s)
fdt_fixup_memory_banks: num banks 8 exceeds hardcoded limit 4. Recompile with 
higher MEMORY_BANKS_MAX?
ERROR: arch-specific fdt fixup failed
 - must RESET the board to recover.

ERROR: failed to process device tree
ERROR: failed to install device tree
EFI LOAD FAILED: continuing...
**

If I set MEMORY_BANKS_MAX to 8 in common/fdt_support.c , then it boots fine. Is 
there any reason to stick this to 4, or could I send a patch to rise it to 8?

Would be great to get it fixed for v2018.09.


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

Re: [U-Boot] [PATCH] omap3: beagle: re-enable EFI support after the following commit removed it by mistake:

2018-07-19 Thread Guillaume Gardet


Hi Derald,


Le 19/07/2018 à 01:47, Derald D. Woods a écrit :

On Wed, Jul 18, 2018 at 09:38:44PM +0200, Guillaume GARDET wrote:

   commit d233ccb1d84b901f7e23e6d9b4f2c6a57198b23b
   ARM: omap3: beagle: Enable DM_SERIAL, update distro usage and NAND layout


I have found no compile or runtime issues, on my BeagleBoard Rev. C4
or xM, with the current default configuration. At least, for my non-EFI
boot environment.


It is related to EFI options since I use GPT partitions (and EFI/Grub2 to 
boot). That is why you did not find anything.



The following items are brought in from the EFI config additions:

+CONFIG_SMBIOS_PRODUCT_NAME="beagle"
+CONFIG_CMD_BOOTEFI=y
+CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
+CONFIG_EFI_PARTITION=y
+CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128
+CONFIG_EFI_PARTITION_ENTRIES_OFF=0
+CONFIG_SPL_EFI_PARTITION=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_GENERATE_SMBIOS_TABLE=y
+CONFIG_SMBIOS_MANUFACTURER="ti"
+CONFIG_EFI_LOADER=y

I would change the commit message though. It was not a mistake. It was
removed to provide a minimal set of configuration options for the base
BSP type of setup. Using EFI is a choice. In fact, I tested my changes
on 3 different OMAP3 boards. So there has been no period of not working
in the basic board configuration. Provably.

So if EFI is required, even though one may not use it, this is a don't
care for me. My boards boot just fine without EFI.


The thing is you introduced a regression with your commit, since EFI was 
supported previously. And you did not explicitly stated that you disabled it on 
purpose. So, it sounds like a mistake to me.
If you don't care about EFI, it is your choice, but please do not break setup 
of others. A use case is openSUSE which relies on EFI/Grub2 to boot.
Please note that EFI is now a default feature in U-Boot, so, please, let it 
enabled.

Guillaume




Derald


Signed-off-by: Guillaume GARDET 
Cc: Derald D. Woods 
Cc: Tom Rini 

---
  configs/omap3_beagle_defconfig | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
index a37a38f881..1e1a391d7f 100644
--- a/configs/omap3_beagle_defconfig
+++ b/configs/omap3_beagle_defconfig
@@ -32,8 +32,6 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
  
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(spl),1920k(u-boot),128k(u-boot-env),128k(dtb),6m(kernel),-(rootfs)"
  CONFIG_CMD_UBI=y
  # CONFIG_ISO_PARTITION is not set
-# CONFIG_EFI_PARTITION is not set
-CONFIG_SPL_PARTITION_UUIDS=y
  CONFIG_OF_CONTROL=y
  CONFIG_ENV_IS_IN_NAND=y
  CONFIG_SPL_DM=y
@@ -79,4 +77,3 @@ CONFIG_USB_ETHER_SMSC95XX=y
  CONFIG_FAT_WRITE=y
  CONFIG_BCH=y
  CONFIG_SPL_OF_LIBFDT=y
-# CONFIG_EFI_LOADER is not set
--
2.18.0



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

[U-Boot] Re : Re: Re : Commit d233ccb1d84b90 broke MMC access on BeagleBoard xM

2018-07-18 Thread Guillaume GARDET


- Derald D. Woods  a écrit :
> On Wed, Jul 18, 2018 at 05:04:45PM +0200, Guillaume GARDET wrote:
> > 
> > - Guillaume GARDET  a écrit :
> > > 
> > > Hi,
> > > 
> > > commit d233ccb1d84b901f7e23e6d9b4f2c6a57198b23b (HEAD, refs/bisect/bad)
> > > Author: Derald D. Woods 
> > > Date:   Mon Feb 26 17:52:58 2018 -0600
> > > 
> > > ARM: omap3: beagle: Enable DM_SERIAL, update distro usage and NAND 
> > > layout
> > > 
> > > broke MMC access on Beagleboard xM (rev. B). For my SD card with 2 
> > > partitions, I get the following errors:
> > > * 'ls mmc 0:1' returns: ** Unrecognized filesystem type **
> > > * 'ls mmc 0:2' returns: ** Invalid partition 2 **
> > > 
> > > 
> > > Not sure which part of this patch cause this bug.
> > 
> > I removed: 
> >   # CONFIG_EFI_PARTITION is not set
> > 
> > and MMC is working again for me! I will send a patch to fix this.
> > 
> > Note also that EFI boot does not work since this commit, even with 
> > CONFIG_EFI_PARTITION enabled.
> 
> So if you use 'make menucofig' to set the properties that you want, for
> your setup, it does not work? To my knowledge the patch series did not
> limit any known configurable functionality.

Now, I get it working with some options changed in menuconfig. See the fix 
here: https://lists.denx.de/pipermail/u-boot/2018-July/335218.html

Guillaume


> 
> Derald
> 
> > 
> > Guillaume

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

[U-Boot] [PATCH] omap3: beagle: re-enable EFI support after the following commit removed it by mistake:

2018-07-18 Thread Guillaume GARDET

  commit d233ccb1d84b901f7e23e6d9b4f2c6a57198b23b
  ARM: omap3: beagle: Enable DM_SERIAL, update distro usage and NAND layout

Signed-off-by: Guillaume GARDET 
Cc: Derald D. Woods 
Cc: Tom Rini  

---
 configs/omap3_beagle_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
index a37a38f881..1e1a391d7f 100644
--- a/configs/omap3_beagle_defconfig
+++ b/configs/omap3_beagle_defconfig
@@ -32,8 +32,6 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(spl),1920k(u-boot),128k(u-boot-env),128k(dtb),6m(kernel),-(rootfs)"
 CONFIG_CMD_UBI=y
 # CONFIG_ISO_PARTITION is not set
-# CONFIG_EFI_PARTITION is not set
-CONFIG_SPL_PARTITION_UUIDS=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
@@ -79,4 +77,3 @@ CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_FAT_WRITE=y
 CONFIG_BCH=y
 CONFIG_SPL_OF_LIBFDT=y
-# CONFIG_EFI_LOADER is not set
-- 
2.18.0

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

[U-Boot] Re : Commit d233ccb1d84b90 broke MMC access on BeagleBoard xM

2018-07-18 Thread Guillaume GARDET


- Guillaume GARDET  a écrit :
> 
> Hi,
> 
> commit d233ccb1d84b901f7e23e6d9b4f2c6a57198b23b (HEAD, refs/bisect/bad)
> Author: Derald D. Woods 
> Date:   Mon Feb 26 17:52:58 2018 -0600
> 
> ARM: omap3: beagle: Enable DM_SERIAL, update distro usage and NAND layout
> 
> broke MMC access on Beagleboard xM (rev. B). For my SD card with 2 
> partitions, I get the following errors:
> * 'ls mmc 0:1' returns: ** Unrecognized filesystem type **
> * 'ls mmc 0:2' returns: ** Invalid partition 2 **
> 
> 
> Not sure which part of this patch cause this bug.

I removed: 
  # CONFIG_EFI_PARTITION is not set

and MMC is working again for me! I will send a patch to fix this.

Note also that EFI boot does not work since this commit, even with 
CONFIG_EFI_PARTITION enabled.

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

[U-Boot] Commit d233ccb1d84b90 broke MMC access on BeagleBoard xM

2018-07-18 Thread Guillaume GARDET


Hi,

commit d233ccb1d84b901f7e23e6d9b4f2c6a57198b23b (HEAD, refs/bisect/bad)
Author: Derald D. Woods 
Date:   Mon Feb 26 17:52:58 2018 -0600

ARM: omap3: beagle: Enable DM_SERIAL, update distro usage and NAND layout

broke MMC access on Beagleboard xM (rev. B). For my SD card with 2 partitions, 
I get the following errors:
* 'ls mmc 0:1' returns: ** Unrecognized filesystem type **
* 'ls mmc 0:2' returns: ** Invalid partition 2 **


Not sure which part of this patch cause this bug.

Guillaume

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

Re: [U-Boot] [PATCH] snow: set fdtfile

2018-07-16 Thread Guillaume Gardet


Hi,


Le 13/07/2018 à 19:20, Peter Robinson a écrit :

On Thu, Jun 14, 2018 at 9:34 PM, Guillaume GARDET
 wrote:

Needed to boot with EFI distro boot.

Signed-off-by: Guillaume GARDET 

Cc: Akshay Saraswat 
Cc: Tom Rini 
---
  include/configs/snow.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/include/configs/snow.h b/include/configs/snow.h
index 3b0db32ece..c546a5a6d0 100644
--- a/include/configs/snow.h
+++ b/include/configs/snow.h
@@ -8,6 +8,9 @@
  #ifndef __CONFIG_SNOW_H
  #define __CONFIG_SNOW_H

+#define EXYNOS_FDTFILE_SETTING \
+   "fdtfile=exynos5250-snow.dtb\0"

Isn't it set in configs/snow_defconfig with
CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow"


No, CONFIG_DEFAULT_DEVICE_TREE is only used for U-Boot DT, not to set fdtfile 
var.

Guillaume




  #include 
  #include 
  #include 
--
2.17.1

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


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

Re: [U-Boot] [PATCH] snow: set fdtfile

2018-07-13 Thread Guillaume Gardet


Hi,

This is a reminder for this patch.

Guillaume



Le 14/06/2018 à 22:34, Guillaume GARDET a écrit :

Needed to boot with EFI distro boot.

Signed-off-by: Guillaume GARDET 

Cc: Akshay Saraswat 
Cc: Tom Rini 
---
  include/configs/snow.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/include/configs/snow.h b/include/configs/snow.h
index 3b0db32ece..c546a5a6d0 100644
--- a/include/configs/snow.h
+++ b/include/configs/snow.h
@@ -8,6 +8,9 @@
  #ifndef __CONFIG_SNOW_H
  #define __CONFIG_SNOW_H
  
+#define EXYNOS_FDTFILE_SETTING \

+   "fdtfile=exynos5250-snow.dtb\0"
+
  #include 
  #include 
  #include 


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

Re: [U-Boot] [PATCH 1/2] arm: timer: factor out FSL arch timer erratum workaround

2018-07-03 Thread Guillaume Gardet




Le 03/07/2018 à 01:08, Andreas Färber a écrit :

Am 02.07.2018 um 10:01 schrieb Jagan Teki:

On Wed, Jun 27, 2018 at 6:12 AM, Andre Przywara  wrote:

At the moment we have the workaround for the Freescale arch timer
erratum A-008585 merged into the generic timer_read_counter() routine.
Split those two up, so that we can add other errata workaround more
easily. Also add an explaining comment on the way.

Signed-off-by: Andre Przywara 
---

Applied both patches, to u-boot-sunxi/master

Tested both on top of v2018.07-rc2, fixes the boot for me.


Tested both on top of v2018.07-rc3, and it fixes the boot.

Thanks.

Guillaume



Thanks,
Andreas



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

[U-Boot] Pine64 problems with GPT partitions

2018-06-26 Thread guillaume . gardet


Hi Andre,

You are the maintainer of Pine64 in U-Boot, so I want to let you know that 
Pine64 has problems to access GPT partitions, whereas MBR partitions seem to be 
OK.

There is a bug report from openSUSE here with additional informations: 
https://bugzilla.opensuse.org/show_bug.cgi?id=1098550


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

[U-Boot] [PATCH] distro: add more efi dtb prefixes

2018-06-14 Thread Guillaume GARDET

As used on some distro, such as openSUSE.
Signed-off-by: Guillaume GARDET 

Cc: Tom Rini 
---
 include/config_distro_bootcmd.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8ebe6..ad4c7a78f1 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -141,7 +141,8 @@
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=/ /dtb/ /dtb/current/ " \
+   "/boot/ /boot/dtb/ /boot/dtb/current/\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-- 
2.17.1

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

[U-Boot] [PATCH] snow: set fdtfile

2018-06-14 Thread Guillaume GARDET

Needed to boot with EFI distro boot.

Signed-off-by: Guillaume GARDET 

Cc: Akshay Saraswat 
Cc: Tom Rini 
---
 include/configs/snow.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/snow.h b/include/configs/snow.h
index 3b0db32ece..c546a5a6d0 100644
--- a/include/configs/snow.h
+++ b/include/configs/snow.h
@@ -8,6 +8,9 @@
 #ifndef __CONFIG_SNOW_H
 #define __CONFIG_SNOW_H
 
+#define EXYNOS_FDTFILE_SETTING \
+   "fdtfile=exynos5250-snow.dtb\0"
+
 #include 
 #include 
 #include 
-- 
2.17.1

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

[U-Boot] Re : Re: Clearfog fails to build with U-Boot v2018.07-rc1

2018-06-14 Thread guillaume . gardet


- Stefan Roese  a écrit :
> Hi Guillaume,
> 
> On 14.06.2018 14:19, guillaume.gar...@free.fr wrote:
> > Clearfog config fails to build with U-Boot v2018.07-rc1, because SPL is too 
> > big:
> > 
> >  LD  spl/u-boot-spl
> >ld.bfd: SPL image too big
> >make[1]: *** [scripts/Makefile.spl:347: spl/u-boot-spl] Error 1
> >make: *** [Makefile:1510: spl/u-boot-spl] Error 2
> 
> This works for me just fine. I'm currently using GCC 7.2 (Linaro)
> and Travis is also not reporting any build errors here.
> 
> Which toolchain are you using? Perhaps it makes sense to switch here?

I am using GCC8 from openSUSE Tumbleweed (native build).
You can see the full log here: 
https://build.opensuse.org/package/live_build_log/hardware:boot:staging/u-boot-clearfog/openSUSE_Factory_ARM/armv7l

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

[U-Boot] Clearfog fails to build with U-Boot v2018.07-rc1

2018-06-14 Thread guillaume . gardet


Hi Stefan,

Clearfog config fails to build with U-Boot v2018.07-rc1, because SPL is too big:

LD  spl/u-boot-spl
  ld.bfd: SPL image too big
  make[1]: *** [scripts/Makefile.spl:347: spl/u-boot-spl] Error 1
  make: *** [Makefile:1510: spl/u-boot-spl] Error 2

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

Re: [U-Boot] [U-Boot, BUG] snow: mmc: SD card access broken: unable to select a mode

2018-05-16 Thread Guillaume Gardet


Hi Jaehoon,


Le 26/04/2018 à 15:15, Guillaume Gardet a écrit :



Le 26/04/2018 à 12:31, Jaehoon Chung a écrit :

Hi,

On 04/09/2018 09:02 PM, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:



Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?

Sorry for late. Hmm. I will check your issue. Just disable MMC_MODE_HS, then 
it's working fine?
or HS_52MHz?


I tried to disable HS_52MHz only and it did not fix the problem. Then I tried 
to disable both HS and HS_52MHz and it fixed the problem.


Any progress on this problem?

Guillaume




Guillaume



Best Regards,
Jaehoon Chung



Guillaume

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
       cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
   }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
   }







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

Re: [U-Boot] [PATCH V6 0/2] Update sabrelite and nitrogen6x boards to use distro boot support

2018-05-16 Thread Guillaume Gardet


Hi,

just a friendly reminder for those 2 patches.


Guillaume



Le 18/04/2018 à 17:04, Guillaume GARDET a écrit :

This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Currently, only the Sabrelite has fdtfile defined.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

Changes in V6:
   * added CONFIG_CMD_GPT to sabrelite defconfig
   * remove CONFIG_ARCH_MISC_INIT to sabrelite defconfig

Changes in V5:
   * remove obsolete code from include/configs/nitrogen6x.h
   
Changes in V4:

   * Remove imx6 soc definition
   * Change comment on not defined fdtfile (no more fallback)

Changes in V3:
   * Add imx6 soc definition
   * Also update nitrogen6x config, not only sabrelite
   * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
   * add mx6qsabrelite_defconfig update


Guillaume GARDET (2):
   imx6: Convert sabrelite and nitrogen6x boards to distro boot support
   imx6: sabrelite: update defconfig to use distro defaults

  configs/mx6qsabrelite_defconfig |  15 ++--
  include/configs/nitrogen6x.h| 179 ++--
  2 files changed, 48 insertions(+), 146 deletions(-)



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

[U-Boot] SPL too big for Turris Omnia in v2018.05

2018-05-09 Thread guillaume . gardet


Hi,

While trying to build u-boot for Turris Omnia board in v2018.05 with GCC 7.3.1, 
I get the following error:

  MKIMAGE u-boot-spl.kwb
Error: Image header (incl. SPL image) too big!
header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000!
Increase CONFIG_SYS_U_BOOT_OFFS!
Error: Image header (incl. SPL image) too big!
header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000!
Increase CONFIG_SYS_U_BOOT_OFFS!
Could not create image
make: *** [Makefile:1097: u-boot-spl.kwb] Error 1



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

Re: [U-Boot] [U-Boot, BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-26 Thread Guillaume Gardet




Le 26/04/2018 à 12:31, Jaehoon Chung a écrit :

Hi,

On 04/09/2018 09:02 PM, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:



Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?

Sorry for late. Hmm. I will check your issue. Just disable MMC_MODE_HS, then 
it's working fine?
or HS_52MHz?


I tried to disable HS_52MHz only and it did not fix the problem. Then I tried 
to disable both HS and HS_52MHz and it fixed the problem.


Guillaume



Best Regards,
Jaehoon Chung



Guillaume

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
       cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
   }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
   }





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

Re: [U-Boot] [PATCH V5 2/2] imx6: sabrelite: update defconfig to use distro defaults

2018-04-18 Thread Guillaume Gardet


Hi,


Le 18/04/2018 à 16:44, Gary Bisson a écrit :

Hi Guillaume,

On Mon, Apr 16, 2018 at 02:47:38PM +0200, Guillaume GARDET wrote:

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
  configs/mx6qsabrelite_defconfig | 15 +--
  1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..fee33cfff1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y
  CONFIG_SYS_TEXT_BASE=0x1780
  CONFIG_TARGET_NITROGEN6X=y
  CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
  
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
  CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
  CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_ARCH_MISC_INIT=y

The above config breaks the build since there's no arch_misc_init
function in the board file.


  CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
  CONFIG_FASTBOOT=y
  CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
  CONFIG_CMD_MEMTEST=y
  CONFIG_SYS_ALT_MEMTEST=y
  # CONFIG_CMD_FLASH is not set

Also, can you add CMD_GPT so that GPT parition tables are supported?

Many of our OS images now rely on it.


Ok, patch V6 sent just now.

Guillaume



Regards,
Gary



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

[U-Boot] [PATCH V6 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-18 Thread Guillaume GARDET

Boot tested on sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 include/configs/nitrogen6x.h | 179 +++
 1 file changed, 43 insertions(+), 136 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..0d0be2a955 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -80,161 +80,68 @@
 
 #define CONFIG_PREBOOT ""
 
-#ifdef CONFIG_CMD_SATA
-#define CONFIG_DRIVE_SATA "sata "
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
 #else
-#define CONFIG_DRIVE_SATA
+#define DISTRO_BOOT_DEV_MMC(func)
 #endif
 
-#ifdef CONFIG_CMD_MMC
-#define CONFIG_DRIVE_MMC "mmc "
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
 #else
-#define CONFIG_DRIVE_MMC
+#define DISTRO_BOOT_DEV_SATA(func)
 #endif
 
 #ifdef CONFIG_USB_STORAGE
-#define CONFIG_DRIVE_USB "usb "
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
 #else
-#define CONFIG_DRIVE_USB
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
 #endif
 
-#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
-#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else
+/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each 
supported config. */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   DISTRO_BOOT_DEV_MMC(func) \
+   DISTRO_BOOT_DEV_SATA(func) \
+   DISTRO_BOOT_DEV_USB(func) \
+   DISTRO_BOOT_DEV_PXE(func) \
+   DISTRO_BOOT_DEV_DHCP(func)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   FDTFILE \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-

[U-Boot] [PATCH V6 2/2] imx6: sabrelite: update defconfig to use distro defaults

2018-04-18 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 configs/mx6qsabrelite_defconfig | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..54a9fc84a1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,36 +3,31 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-- 
2.13.6

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

[U-Boot] [PATCH V6 0/2] Update sabrelite and nitrogen6x boards to use distro boot support

2018-04-18 Thread Guillaume GARDET

This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Currently, only the Sabrelite has fdtfile defined.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

Changes in V6:
  * added CONFIG_CMD_GPT to sabrelite defconfig
  * remove CONFIG_ARCH_MISC_INIT to sabrelite defconfig

Changes in V5:
  * remove obsolete code from include/configs/nitrogen6x.h
  
Changes in V4:
  * Remove imx6 soc definition
  * Change comment on not defined fdtfile (no more fallback)

Changes in V3:
  * Add imx6 soc definition
  * Also update nitrogen6x config, not only sabrelite
  * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
  * add mx6qsabrelite_defconfig update


Guillaume GARDET (2):
  imx6: Convert sabrelite and nitrogen6x boards to distro boot support
  imx6: sabrelite: update defconfig to use distro defaults

 configs/mx6qsabrelite_defconfig |  15 ++--
 include/configs/nitrogen6x.h| 179 ++--
 2 files changed, 48 insertions(+), 146 deletions(-)

-- 
2.13.6

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

[U-Boot] [PATCH V5 2/2] imx6: sabrelite: update defconfig to use distro defaults

2018-04-16 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 configs/mx6qsabrelite_defconfig | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..fee33cfff1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_ARCH_MISC_INIT=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
@@ -22,17 +22,12 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-- 
2.13.6

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

[U-Boot] [PATCH V5 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-16 Thread Guillaume GARDET

Boot tested on sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 include/configs/nitrogen6x.h | 179 +++
 1 file changed, 43 insertions(+), 136 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..0d0be2a955 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -80,161 +80,68 @@
 
 #define CONFIG_PREBOOT ""
 
-#ifdef CONFIG_CMD_SATA
-#define CONFIG_DRIVE_SATA "sata "
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
 #else
-#define CONFIG_DRIVE_SATA
+#define DISTRO_BOOT_DEV_MMC(func)
 #endif
 
-#ifdef CONFIG_CMD_MMC
-#define CONFIG_DRIVE_MMC "mmc "
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
 #else
-#define CONFIG_DRIVE_MMC
+#define DISTRO_BOOT_DEV_SATA(func)
 #endif
 
 #ifdef CONFIG_USB_STORAGE
-#define CONFIG_DRIVE_USB "usb "
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
 #else
-#define CONFIG_DRIVE_USB
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
 #endif
 
-#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
-#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else
+/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each 
supported config. */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   DISTRO_BOOT_DEV_MMC(func) \
+   DISTRO_BOOT_DEV_SATA(func) \
+   DISTRO_BOOT_DEV_USB(func) \
+   DISTRO_BOOT_DEV_PXE(func) \
+   DISTRO_BOOT_DEV_DHCP(func)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   FDTFILE \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-

[U-Boot] [PATCH V5 0/2] Update sabrelite and nitrogen6x boards to use distro boot support

2018-04-16 Thread Guillaume GARDET

This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Currently, only the Sabrelite has fdtfile defined.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

Changes in V5:
  * remove obsolete code from include/configs/nitrogen6x.h
  
Changes in V4:
  * Remove imx6 soc definition
  * Change comment on not defined fdtfile (no more fallback)

Changes in V3:
  * Add imx6 soc definition
  * Also update nitrogen6x config, not only sabrelite
  * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
  * add mx6qsabrelite_defconfig update



Guillaume GARDET (2):
  imx6: Convert sabrelite and nitrogen6x boards to distro boot support
  imx6: sabrelite: update defconfig to use distro defaults

 configs/mx6qsabrelite_defconfig |  15 ++--
 include/configs/nitrogen6x.h| 179 ++--
 2 files changed, 48 insertions(+), 146 deletions(-)

-- 
2.13.6

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

[U-Boot] [PATCH V4 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-12 Thread Guillaume GARDET

Boot tested on sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 include/configs/nitrogen6x.h | 180 +--
 1 file changed, 54 insertions(+), 126 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..f6dce6c069 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -101,140 +101,68 @@
 #define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
 #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
+#else
+#define DISTRO_BOOT_DEV_MMC(func)
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
+#else
+#define DISTRO_BOOT_DEV_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
+#else
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
+#endif
+
+
 #if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else
+/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each 
supported config. */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   DISTRO_BOOT_DEV_MMC(func) \
+   DISTRO_BOOT_DEV_SATA(func) \
+   DISTRO_BOOT_DEV_USB(func) \
+   DISTRO_BOOT_DEV_PXE(func) \
+   DISTRO_BOOT_DEV_DHCP(func)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   FDTFILE \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then &quo

[U-Boot] [PATCH V4 2/2] imx6: sabrelite: update defconfig to use distro defaults

2018-04-12 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 configs/mx6qsabrelite_defconfig | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..fee33cfff1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_ARCH_MISC_INIT=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
@@ -22,17 +22,12 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-- 
2.13.6

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

[U-Boot] [PATCH V4 0/2] Update sabrelite and nitrogen6x boards to use distro boot support

2018-04-12 Thread Guillaume GARDET

This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Currently, only the Sabrelite has fdtfile defined.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

Changes in V4:
  * Remove imx6 soc definition
  * Change comment on not defined fdtfile (no more fallback)

Changes in V3:
  * Add imx6 soc definition
  * Also update nitrogen6x config, not only sabrelite
  * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
  * add mx6qsabrelite_defconfig update


Guillaume GARDET (2):
  imx6: Convert sabrelite and nitrogen6x boards to distro boot support
  imx6: sabrelite: update defconfig to use distro defaults

 configs/mx6qsabrelite_defconfig |  15 ++--
 include/configs/nitrogen6x.h| 180 
 2 files changed, 59 insertions(+), 136 deletions(-)

-- 
2.13.6

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

Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-12 Thread Guillaume Gardet




Le 12/04/2018 à 14:58, Gary Bisson a écrit :

Hi Guillaume,

On Thu, Apr 12, 2018 at 02:48:07PM +0200, Guillaume Gardet wrote:


Le 12/04/2018 à 14:36, Gary Bisson a écrit :

Hi Fabio, Guillaume

On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:

On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
<guillaume.gar...@free.fr> wrote:
script that picks the correct dtb.

Ok. So, how would you like to proceed?
Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev'
(or maybe a static definition if one configuration match a single dtb) to
define the right dtb?

I prefer to keep the same solution as done in other boards sucn as
mx6sabresd, wandboard and cuboxi.

Ok. My suggestion was to have something generic so that it matches the
fdt name set in config_distro_bootcmd.h
(${soc}-${board}${boardver}.dtb).

I especially like the naming in that standard, don't think board_rev
should be the SOC name.

This would also avoid redundancy in each board_late_init functions since
only the board name would need to be setup (and boardver in some cases
like wandboard).

Guillaume, please forget that point for now and just set your fdtfile
name in the config file. I'll update the board file later on.

Ok.

Could you just confirm which DTB should work with the various nitrogen6x boards 
config, please?
Are the following ok?
* imx6q-nitrogen6x.dts => nitrogen6q2g_defconfig nitrogen6q_defconfig
* imx6dl-nitrogen6x.dts     =>     nitrogen6dl2g_defconfig nitrogen6dl_defconfig
* imx6sx-nitrogen6sx.dts => nitrogen6s1g_defconfig nitrogen6s_defconfig

No, imx6sx is different than imx6s. Solo is the same as imx6dl as far as
the kernl is concerned.

Maybe just leave fdt_file blank for nitrogen6x for now, it's only necessary
for PXE which isn't enabled in nitrogen6*defconfig.


Ok, I will leave it as is for now, but fdtfile must also be defined for EFI 
boot. Otherwise, you start your EFI payload without device tree.


Guillaume




Regards,
Gary



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

Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-12 Thread Guillaume Gardet




Le 12/04/2018 à 14:36, Gary Bisson a écrit :

Hi Fabio, Guillaume

On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:

On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
<guillaume.gar...@free.fr> wrote:
script that picks the correct dtb.

Ok. So, how would you like to proceed?
Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev'
(or maybe a static definition if one configuration match a single dtb) to
define the right dtb?

I prefer to keep the same solution as done in other boards sucn as
mx6sabresd, wandboard and cuboxi.

Ok. My suggestion was to have something generic so that it matches the
fdt name set in config_distro_bootcmd.h
(${soc}-${board}${boardver}.dtb).

I especially like the naming in that standard, don't think board_rev
should be the SOC name.

This would also avoid redundancy in each board_late_init functions since
only the board name would need to be setup (and boardver in some cases
like wandboard).

Guillaume, please forget that point for now and just set your fdtfile
name in the config file. I'll update the board file later on.


Ok.

Could you just confirm which DTB should work with the various nitrogen6x boards 
config, please?
Are the following ok?
* imx6q-nitrogen6x.dts => nitrogen6q2g_defconfig nitrogen6q_defconfig
* imx6dl-nitrogen6x.dts     =>     nitrogen6dl2g_defconfig nitrogen6dl_defconfig
* imx6sx-nitrogen6sx.dts => nitrogen6s1g_defconfig nitrogen6s_defconfig
* imx6q-sabrelite.dts => mx6qsabrelite_defconfig

Guillaume


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

Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-12 Thread Guillaume Gardet




Le 11/04/2018 à 18:06, Fabio Estevam a écrit :

On Wed, Apr 11, 2018 at 12:52 PM, Guillaume Gardet
<guillaume.gar...@free.fr> wrote:


So, how to handle dtb filenames? Update with wrong soc definition ? Or drop
this patch and define a FDTFILE for each flavor?

You can take a look at how we handle this for wandboard, cuboxi,
sabresd, for example.

Taking mx6sabresd as an example you can look at board_late_init() in
board/freescale/mx6sabresd/mx6sabresd.c

Then inside  include/configs/mx6sabre_common.h check for the findfdt
script that picks the correct dtb.


Ok. So, how would you like to proceed?
Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev' 
(or maybe a static definition if one configuration match a single dtb) to 
define the right dtb?

Could you tell me which DTB should work with the various nitrogen6x boards 
config?

Here are the one I could get from upstream kernel dts folder and possible 
config match:
* imx6q-nitrogen6x.dts     =>     nitrogen6q2g_defconfig nitrogen6q_defconfig
* imx6q-nitrogen6_max.dts     =>     none?
* imx6q-nitrogen6_som2.dts     =>     none?
* imx6qp-nitrogen6_max.dts     =>     none?
* imx6qp-nitrogen6_som2.dts     =>     none?
* imx6dl-nitrogen6x.dts     =>     nitrogen6dl2g_defconfig nitrogen6dl_defconfig
* imx6sx-nitrogen6sx.dts     =>     nitrogen6s1g_defconfig nitrogen6s_defconfig
* imx6q-sabrelite.dts     =>     mx6qsabrelite_defconfig
* imx6dl-sabrelite.dts     =>     none?


Guillaume

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

Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-11 Thread Guillaume Gardet




Le 11/04/2018 à 17:46, Gary Bisson a écrit :

Hi Guillaume,

On Wed, Apr 11, 2018 at 12:38:48PM +0200, Guillaume GARDET wrote:

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
  arch/arm/mach-imx/mx6/soc.c | 34 ++
  1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 9b3d8f69b2..c4cb752c76 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -446,6 +446,40 @@ int arch_cpu_init(void)
return 0;
  }
  
+ #ifdef CONFIG_ARCH_MISC_INIT

+ int arch_misc_init(void)
+ {
+ #ifdef CONFIG_ENV_VARS_UBOOT_CONFIG
+   if (is_cpu_type(MXC_CPU_MX6QP))
+   env_set("soc", "imx6qp");
+   else if (is_cpu_type(MXC_CPU_MX6Q))
+   env_set("soc", "imx6q");
+   else if (is_cpu_type(MXC_CPU_MX6DP))
+   env_set("soc", "imx6dp");

If we want that soc variable to be used for dtb names, then the above
won't work. A i.MX6DP platform has its dtb named imx6qp-board.dtb.


+   else if (is_cpu_type(MXC_CPU_MX6D))
+   env_set("soc", "imx6d");

Same here, a Dual CPU actually uses a imx6q-board.dtb.


+   else if (is_mx6dl( ))
+   env_set("soc", "imx6dl");
+   else if (is_mx6sx( ))
+   env_set("soc", "imx6sx");
+   else if (is_mx6sl( ))
+   env_set("soc", "imx6sl");
+   else if (is_mx6solo( ))
+   env_set("soc", "imx6solo");

Same here, a Solo CPU uses a imx6dl-board.dtb.


So, how to handle dtb filenames? Update with wrong soc definition ? Or drop 
this patch and define a FDTFILE for each flavor?




+   else if (is_mx6ul( ))
+   env_set("soc", "imx6ul");
+   else if (is_mx6ull( ))
+   env_set("soc", "imx6ull");
+   else if (is_mx6sll( ))
+   env_set("soc", "imx6sll");
+   else
+   env_set("soc", "imx6");

In that case we most likely miss a CPU definition, maybe "unknown" would
be more explicit?


Currently soc is defined to imx6, so I think it is a good idea to keep imx6 
definition.

Guillaume




Regards,
Gary



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

Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-11 Thread Guillaume Gardet


Hi,


Le 11/04/2018 à 16:23, Fabio Estevam a écrit :

Hi Guillaume,

On Wed, Apr 11, 2018 at 7:38 AM, Guillaume GARDET
<guillaume.gar...@free.fr> wrote:

Please explain in the commit log why this is needed. Thanks


This is for efi fdtfile fallback definition for default distro config for 
nitrogen6x board.
Is it ok for you?




Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>


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

[U-Boot] [PATCH V3 3/3] imx6: sabrelite: update defconfig to use distro defaults

2018-04-11 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 configs/mx6qsabrelite_defconfig | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..fee33cfff1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_ARCH_MISC_INIT=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
@@ -22,17 +22,12 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-- 
2.13.6

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

[U-Boot] [PATCH V3 2/3] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-11 Thread Guillaume GARDET

Boot tested on sabrelite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 include/configs/nitrogen6x.h | 180 +--
 1 file changed, 54 insertions(+), 126 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..589c5b1ae8 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -101,140 +101,68 @@
 #define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
 #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
+#else
+#define DISTRO_BOOT_DEV_MMC(func)
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
+#else
+#define DISTRO_BOOT_DEV_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
+#else
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
+#endif
+
+
 #if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else 
+/* fdtfile depends on nitrogen6x board used, so leave it to config distro 
fallback */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   DISTRO_BOOT_DEV_MMC(func) \
+   DISTRO_BOOT_DEV_SATA(func) \
+   DISTRO_BOOT_DEV_USB(func) \
+   DISTRO_BOOT_DEV_PXE(func) \
+   DISTRO_BOOT_DEV_DHCP(func)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   FDTFILE \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then &quo

[U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC

2018-04-11 Thread Guillaume GARDET

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

---
 arch/arm/mach-imx/mx6/soc.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 9b3d8f69b2..c4cb752c76 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -446,6 +446,40 @@ int arch_cpu_init(void)
return 0;
 }
 
+ #ifdef CONFIG_ARCH_MISC_INIT
+ int arch_misc_init(void)
+ {
+ #ifdef CONFIG_ENV_VARS_UBOOT_CONFIG
+   if (is_cpu_type(MXC_CPU_MX6QP))
+   env_set("soc", "imx6qp");
+   else if (is_cpu_type(MXC_CPU_MX6Q))
+   env_set("soc", "imx6q");
+   else if (is_cpu_type(MXC_CPU_MX6DP))
+   env_set("soc", "imx6dp");
+   else if (is_cpu_type(MXC_CPU_MX6D))
+   env_set("soc", "imx6d");
+   else if (is_mx6dl( ))
+   env_set("soc", "imx6dl");
+   else if (is_mx6sx( ))
+   env_set("soc", "imx6sx");
+   else if (is_mx6sl( ))
+   env_set("soc", "imx6sl");
+   else if (is_mx6solo( ))
+   env_set("soc", "imx6solo");
+   else if (is_mx6ul( ))
+   env_set("soc", "imx6ul");
+   else if (is_mx6ull( ))
+   env_set("soc", "imx6ull");
+   else if (is_mx6sll( ))
+   env_set("soc", "imx6sll");
+   else
+   env_set("soc", "imx6");
+ #endif
+
+   return 0;
+ }
+ #endif
+
 #ifdef CONFIG_ENV_IS_IN_MMC
 __weak int board_mmc_get_env_dev(int devno)
 {
-- 
2.13.6

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

[U-Boot] [PATCH V3 0/3] Update sabrelite and nitrogen6x boards to use distro boot support

2018-04-11 Thread Guillaume GARDET

This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Gary Bisson <gary.bis...@boundarydevices.com>

Changes in V3:
  * Add imx6 soc definition
  * Also update nitrogen6x config, not only sabrelite
  * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
  * add mx6qsabrelite_defconfig update

Guillaume GARDET (3):
  imx6: Define 'soc' env var for imx6 SoC
  imx6: Convert sabrelite and nitrogen6x boards to distro boot support
  imx6: sabrelite: update defconfig to use distro defaults

 arch/arm/mach-imx/mx6/soc.c |  34 
 configs/mx6qsabrelite_defconfig |  15 ++--
 include/configs/nitrogen6x.h| 180 
 3 files changed, 93 insertions(+), 136 deletions(-)

-- 
2.13.6

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

Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet




Le 09/04/2018 à 18:02, Guillaume Gardet a écrit :



Le 09/04/2018 à 17:18, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:46, Guillaume Gardet wrote:



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)

So it fails either in sd_select_bus_width() or sd_set_card_speed()
Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?


Yes, it fails too.


If I disable sd_set_card_speed, then it is working fine.

Guillaume



Guillaume




selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume








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

Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet




Le 09/04/2018 à 17:18, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:46, Guillaume Gardet wrote:



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)

So it fails either in sd_select_bus_width() or sd_set_card_speed()
Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?


Yes, it fails too.

Guillaume




selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume






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

Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Guillaume Gardet




Le 09/04/2018 à 16:40, Gary Bisson a écrit :

Hi Guillaume,

Thanks for your patch! Switching the upstream nitrogen6x configuration
to distro bootcmd has been in our todo list for some time since we also
use that in our own git repo.

On Fri, Apr 06, 2018 at 12:05:48PM +0200, Guillaume GARDET wrote:

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
  include/configs/nitrogen6x.h | 86 ++--
  1 file changed, 18 insertions(+), 68 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index c73cfb7f7e..2e2c499cb6 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
  #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
  
  #if defined(CONFIG_SABRELITE)

Please also switch nitrogen6x to it, not only sabrelite.


Should we keep all the 6x scripts stuff or not?




+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1) \
+   func(SATA, sata, 0) \
+   func(USB, usb, 0) \
+   func(PXE, pxe, na) \

That currently doesn't build because CMD_PXE isn't selected in the
sabrelite defconfig.
"include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before
‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’"

Which brings a good point, all the above should depend on the storage
command being present, like done here [1].


No, we just need to update the defconfig, see V2 of this patch sent earlier 
today.




+   func(DHCP, dhcp, na)
+
+#include 
+
  #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
+   "fdtfile=imx6q-sabrelite.dtb\0" \

I wish the default efi_fdtfile would work, Fabio is there any plan to
populate the ${soc} variable like it is done for i.MX7? [2]
Then a small patch in the nitrogen6x.c would set the proper board env
variable.

That way there would be no difference in this header between sabrelite
vs. nitrogen6x.


"fdt_addr=0x1800\0" \

Do we need to keep fdt_addr since we define fdt_addr_r below?


It was for backward compatibility, if people had some script using it.




-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   &q

Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet




Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume

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

Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet




Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Guillaume





JJ




Guillaume








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

[U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet


Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Guillaume


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

[U-Boot] [PATCH] mmc: fix check of returned value of sd_read_ssr function

2018-04-09 Thread Guillaume GARDET

sd_read_ssr returns 0 if it succeed.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>

---
 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 c930893300..92ea78b8af 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1689,7 +1689,7 @@ static int sd_select_mode_and_width(struct mmc *mmc, uint 
card_caps)
 
 #if CONFIG_IS_ENABLED(MMC_WRITE)
err = sd_read_ssr(mmc);
-   if (!err)
+   if (err)
pr_warn("unable to read ssr\n");
 #endif
if (!err)
-- 
2.13.6

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

[U-Boot] [PATCH V2] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Guillaume GARDET


Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>

---
Changes in V2:
  * add mx6qsabrelite_defconfig update

 configs/mx6qsabrelite_defconfig | 16 ++--
 include/configs/nitrogen6x.h| 86 +
 2 files changed, 22 insertions(+), 80 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..c644754929 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,17 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
-CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -22,21 +20,15 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_PHYLIB=y
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..3161b1dd79 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
 #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1) \
+   func(SATA, sata, 0) \
+   func(USB, usb, 0) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
+   "fdtfile=imx6q-sabrelite.dtb\0" \
"fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp

[U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-06 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Troy Kisky <troy.ki...@boundarydevices.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
---
 include/configs/nitrogen6x.h | 86 ++--
 1 file changed, 18 insertions(+), 68 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index c73cfb7f7e..2e2c499cb6 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
 #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1) \
+   func(SATA, sata, 0) \
+   func(USB, usb, 0) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
+   "fdtfile=imx6q-sabrelite.dtb\0" \
"fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0"
+   BOOTENV
 
-#define CONFIG_BOOTCOMMAND \
-   "for mmcdev in ${mmcdevs}; do " \
-   "mmc dev ${mmcdev}; " \
-   "if mmc rescan; then " \
-   "if run loadbootscript; then " \
-   "run bootscript; " \
-   "else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
-   "fi; " \
-   "fi; " \
-   "done; " \
-   "run netboot; "
 #else
 #define CONFIG_EXTRA_ENV_SETTINGS \
"bootdevs=" CONFIG_DRIVE_TYPES "\0" \
-- 
2.13.6

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

[U-Boot] [PATCH] mkimage: do not fail if there is no print_header function

2018-03-30 Thread Guillaume GARDET

Commit 253c60a breaks the exit value of 'mkimage -T rkimage'
and print the following  error:
  mkimage: Can't print header for Rockchip Boot Image support: Success

It is not a failure to not print headers, so just display the warning message,
and finish the function properly.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>

Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Tom Rini <tr...@konsulko.com>
---
 tools/mkimage.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 28ff35e670..4e561820e7 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -588,9 +588,8 @@ int main(int argc, char **argv)
if (tparams->print_header)
tparams->print_header (ptr);
else {
-   fprintf (stderr, "%s: Can't print header for %s: %s\n",
-   params.cmdname, tparams->name, strerror(errno));
-   exit (EXIT_FAILURE);
+   fprintf (stderr, "%s: Can't print header for %s\n",
+   params.cmdname, tparams->name);
}
 
(void) munmap((void *)ptr, sbuf.st_size);
-- 
2.13.6

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

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

2018-01-23 Thread Guillaume Gardet



Le 23/01/2018 à 06:04, Jaehoon Chung a écrit :

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")


I tested your patch on top of u-boot-mmc and SD/MMC is working fine on snow 
config (Samsung Chromebook).

Tested-by: Guillaume GARDET <guillaume.gar...@free.fr>




Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
---
  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;
  


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

[U-Boot] Wrong u-boot-mmc git URL

2018-01-23 Thread Guillaume Gardet


Hi,

The web interface of u-boot-mmc GIT repo shows wrong URLs. See: 
http://git.denx.de/?p=u-boot/u-boot-mmc.git

It is written:
    git://git.denx.de/u-boot/u-boot-mmc.git
    http://git.denx.de/u-boot/u-boot-mmc.git

Whereas, it should be:
    git://git.denx.de/u-boot-mmc.git
    http://git.denx.de/u-boot-mmc.git


Guillaume


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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

2018-01-18 Thread Guillaume Gardet


Hi,


Le 17/01/2018 à 11:05, Jaehoon Chung a écrit :

Hi Guillaume,

On 01/09/2018 11:37 PM, Guillaume Gardet wrote:

Hi,


Le 17/11/2017 à 10:48, Jaehoon Chung a écrit :

Hi,

On 2017년 11월 16일 21:29, Guillaume Gardet wrote:

I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
  cfg->host_caps |= MMC_MODE_4BIT;
  cfg->host_caps &= ~MMC_MODE_8BIT;
  }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so disbale 
it for now */
+   cfg->host_caps |= MMC_MODE_HS;

It means that card is running the lower clock frequency..it's not solution.
Timing issue and some problems should be fixed with lowest frequency.

Now, i can't test and check more detail. After back to my office or home, i 
will check what main cause.

Any progress on this topic ?

Sorry for late. It seems that is related with mmc_power_cycle().

commit 2e7410d76ad11856d09284c18d262d0bb2a3da0c
Author: Kishon Vijay Abraham I <kis...@ti.com>
Date:   Thu Sep 21 16:30:04 2017 +0200

 mmc: disable the mmc clock during power off
 
 There is no point in having the mmc clock enabled during

 power off. Disable the mmc clock. This is similar to how it's
 programmed in Linux Kernel.
 
 Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>

 Signed-off-by: Vignesh R <vigne...@ti.com>
 Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com>
 Reviewed-by: Simon Glass <s...@chromium.org>

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 664b71affd..be68d8d930 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1971,6 +1971,7 @@ static int mmc_power_on(struct mmc *mmc)
  
  static int mmc_power_off(struct mmc *mmc)

  {
+   mmc_set_clock(mmc, 1, true);
  #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_REGULATOR)
 if (mmc->vmmc_supply) {
 int ret = regulator_set_enable(mmc->vmmc_supply, false);

Current, I'm looking for fixing it.

Could you test with removing its code?


As replied to your patch which fixes this commit, it fixed the MMC problem on 
snow.

Thanks a lot!


Guillaume



Best Regards,
Jaehoon Chung


Guillaume


Best Regards,
Jaehoon Chung


  cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
   }
******


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :

Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
  mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), 
I firstly get:
  mmc_init: -5, time 39

Then, all next attempts retruns:
  mmc_init: -110, time 30


Guillaume



Any idea what could be wrong?

Guillaume



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








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

Re: [U-Boot] [PATCH] mmc: fix the wrong dislabing clock

2018-01-18 Thread Guillaume Gardet


Hi,


Le 17/01/2018 à 11:36, Jaehoon Chung a écrit :

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 fixes the MMC boot for snow (Chromebook). Thanks a lot!

Tested-by: Guillaume GARDET <guillaume.gar...@free.fr>


Guillaume




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 <jh80.ch...@samsung.com>
---
  drivers/mmc/mmc.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 53c819187e..311f51f237 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1501,11 +1501,13 @@ static int mmc_set_ios(struct mmc *mmc)
  
  int mmc_set_clock(struct mmc *mmc, uint clock, bool disable)

  {
-   if (clock > mmc->cfg->f_max)
-   clock = mmc->cfg->f_max;
+   if (!disable && clock != 0) {
+   if (clock > mmc->cfg->f_max)
+   clock = mmc->cfg->f_max;
  
-	if (clock < mmc->cfg->f_min)

-   clock = mmc->cfg->f_min;
+   if (clock < mmc->cfg->f_min)
+   clock = mmc->cfg->f_min;
+   }
  
  	mmc->clock = clock;

mmc->clk_disable = disable;
@@ -2449,7 +2451,7 @@ static int mmc_power_on(struct mmc *mmc)
  
  static int mmc_power_off(struct mmc *mmc)

  {
-   mmc_set_clock(mmc, 1, true);
+   mmc_set_clock(mmc, 0, true);
  #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_REGULATOR)
if (mmc->vmmc_supply) {
int ret = regulator_set_enable(mmc->vmmc_supply, false);


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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

2018-01-09 Thread Guillaume Gardet


Hi,


Le 17/11/2017 à 10:48, Jaehoon Chung a écrit :

Hi,

On 2017년 11월 16일 21:29, Guillaume Gardet wrote:

I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
     }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so disbale 
it for now */
+   cfg->host_caps |= MMC_MODE_HS;

It means that card is running the lower clock frequency..it's not solution.
Timing issue and some problems should be fixed with lowest frequency.

Now, i can't test and check more detail. After back to my office or home, i 
will check what main cause.


Any progress on this topic ?

Guillaume



Best Regards,
Jaehoon Chung


     cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
  }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :


Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
     mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), 
I firstly get:
     mmc_init: -5, time 39

Then, all next attempts retruns:
     mmc_init: -110, time 30


Guillaume



Any idea what could be wrong?

Guillaume



___
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] mmc1 not working on Samsung snow chromebook

2017-12-01 Thread Guillaume Gardet




Le 18/11/2017 à 17:33, Guillaume Gardet a écrit :



Le 17/11/2017 à 17:06, Jaehoon Chung a écrit :


On 2017년 11월 17일 18:38, Guillaume Gardet wrote:


Le 17/11/2017 à 10:36, Lukasz Majewski a écrit :

On Thu, 16 Nov 2017 13:29:56 +0100
Guillaume Gardet <guillaume.gar...@free.fr> wrote:


I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is
working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg,
struct dwmci_host *host, cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
       }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so
disbale it for now */
+   cfg->host_caps |= MMC_MODE_HS;

This seems like a workaround. The root cause of the problem is the
regression with HS 52MHz

Not sure it ever worked on this target.

Could you give me the debug log after enabled DEBUG?


WIth debug in mmc.c and dw_mmc.c on the broken system, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD6
Sending CMD55
dwmci_send_cmd: Response Error.
mmc_init: -5, time 78


WIth debug in mmc.c and dw_mmc.c with my workaround, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD55
Sending CMD6
Buswidth = 4, clock: 40
Sending CMD55
Sending CMD13
Buswidth = 4, clock: 2500
Sending CMD16
Sending CMD17
switch to partitions #0, OK
mmc1 is current device

The problem occurs in 'sd_change_freq' function when if we try to set high 
speed with the 2nd call to  'sd_switch' (1st call is just a check).


Any progress on this problem?

Guillaume





Guillaume




Best Regards,
Jaehoon Chung


Guillaume


       cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
    }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :

Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and
while mmc0 (internal eMMC) is working fine, mmc1 (external SD
slot) does not work. I get the following error for 'mmc dev 1'
command: mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop
auto-boot), I firstly get: mmc_init: -5, time 39

Then, all next attempts retruns:
  mmc_init: -110, time 30


Guillaume


Any idea what could be wrong?

Guillaume


___
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

___
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] mmc1 not working on Samsung snow chromebook

2017-11-18 Thread Guillaume Gardet




Le 17/11/2017 à 17:06, Jaehoon Chung a écrit :


On 2017년 11월 17일 18:38, Guillaume Gardet wrote:


Le 17/11/2017 à 10:36, Lukasz Majewski a écrit :

On Thu, 16 Nov 2017 13:29:56 +0100
Guillaume Gardet <guillaume.gar...@free.fr> wrote:


I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is
working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg,
struct dwmci_host *host, cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
       }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so
disbale it for now */
+   cfg->host_caps |= MMC_MODE_HS;

This seems like a workaround. The root cause of the problem is the
regression with HS 52MHz

Not sure it ever worked on this target.

Could you give me the debug log after enabled DEBUG?


WIth debug in mmc.c and dw_mmc.c on the broken system, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD6
Sending CMD55
dwmci_send_cmd: Response Error.
mmc_init: -5, time 78


WIth debug in mmc.c and dw_mmc.c with my workaround, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD55
Sending CMD6
Buswidth = 4, clock: 40
Sending CMD55
Sending CMD13
Buswidth = 4, clock: 2500
Sending CMD16
Sending CMD17
switch to partitions #0, OK
mmc1 is current device

The problem occurs in 'sd_change_freq' function when if we try to set high 
speed with the 2nd call to  'sd_switch' (1st call is just a check).


Guillaume




Best Regards,
Jaehoon Chung


Guillaume


       cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
    }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :

Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and
while mmc0 (internal eMMC) is working fine, mmc1 (external SD
slot) does not work. I get the following error for 'mmc dev 1'
command: mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop
auto-boot), I firstly get: mmc_init: -5, time 39

Then, all next attempts retruns:
  mmc_init: -110, time 30


Guillaume

  

Any idea what could be wrong?

Guillaume

   
   
   

___
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

___
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] mmc1 not working on Samsung snow chromebook

2017-11-17 Thread Guillaume Gardet




Le 17/11/2017 à 10:36, Lukasz Majewski a écrit :

On Thu, 16 Nov 2017 13:29:56 +0100
Guillaume Gardet <guillaume.gar...@free.fr> wrote:


I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is
working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg,
struct dwmci_host *host, cfg->host_caps |= MMC_MODE_4BIT;
      cfg->host_caps &= ~MMC_MODE_8BIT;
      }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so
disbale it for now */
+   cfg->host_caps |= MMC_MODE_HS;

This seems like a workaround. The root cause of the problem is the
regression with HS 52MHz


Not sure it ever worked on this target.

Guillaume




      cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
   }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :


Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and
while mmc0 (internal eMMC) is working fine, mmc1 (external SD
slot) does not work. I get the following error for 'mmc dev 1'
command: mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop
auto-boot), I firstly get: mmc_init: -5, time 39

Then, all next attempts retruns:
     mmc_init: -110, time 30


Guillaume

  

Any idea what could be wrong?

Guillaume

  
  
  

___
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


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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

2017-11-16 Thread Guillaume Gardet


I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
    cfg->host_caps |= MMC_MODE_4BIT;
    cfg->host_caps &= ~MMC_MODE_8BIT;
    }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so disbale 
it for now */
+   cfg->host_caps |= MMC_MODE_HS;

    cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :



Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
    mmc_init: -110, time 30


Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), 
I firstly get:
    mmc_init: -5, time 39

Then, all next attempts retruns:
    mmc_init: -110, time 30


Guillaume




Any idea what could be wrong?

Guillaume








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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

2017-11-15 Thread Guillaume Gardet




Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
    mmc_init: -110, time 30


Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), 
I firstly get:
    mmc_init: -5, time 39

Then, all next attempts retruns:
    mmc_init: -110, time 30


Guillaume




Any idea what could be wrong?

Guillaume






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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

2017-11-15 Thread Guillaume Gardet


Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
    mmc_init: -110, time 30

Any idea what could be wrong?

Guillaume




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

[U-Boot] U-Boot download link broken

2017-10-13 Thread Guillaume Gardet


Hi,

On this page: http://www.denx.de/wiki/U-Boot/SourceCode

there is a link to Amazon Cloud Drive to download U-Boot, but this link is not 
working anymore.

Another problem: on the FTP, there is no tarball for v2017.11-rc1.


Guillaume


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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

2017-10-04 Thread Guillaume Gardet




Le 04/10/2017 à 13:46, Tom Rini a écrit :

On Wed, Oct 04, 2017 at 09:39:52AM +0200, Guillaume Gardet wrote:


Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :


Le 02/10/2017 à 17:58, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:

Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis <a...@ti.com>
Date:   Fri Apr 21 10:01:28 2017 -0500

  Kconfig: Enable FIT support by default for TI platforms

  Almost all TI defconfigs enable this already, add this as a default
  and remove the explicit assignment.

  Signed-off-by: Andrew F. Davis <a...@ti.com>
  Reviewed-by: Tom Rini <tr...@konsulko.com>

broke boot on Beagleboard xM. I mean the board hangs after:
  OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
  OMAP3 Beagle board + LPDDR/NAND
  I2C:   ready
  DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!

This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

OK.  Can you test FAT booting?  Both should work, but I have an idea at
least on RAW, but I'd like to rule out anything else other than size
changes.   Thanks!

Indeed, if u-boot.img is on FAT partition, it boots properly!

So, what is the problem?
Are we limited in size for u-boot.img when raw booting is used?

Actually, I'm not sure now.  I thought it was one thing, but no, it
can't be just a size thing.  And it's proper U-Boot that fails, not SPL.
Can you add a call to image_check_dcrc() to make sure that the
u-boot.img that's being loaded is not corrupted in some dway?  Thanks!



Ok, but where should I add such a call?

Guillaume

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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

2017-10-04 Thread Guillaume Gardet




Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :



Le 02/10/2017 à 17:58, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:


Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis <a...@ti.com>
Date:   Fri Apr 21 10:01:28 2017 -0500

 Kconfig: Enable FIT support by default for TI platforms

 Almost all TI defconfigs enable this already, add this as a default
 and remove the explicit assignment.

 Signed-off-by: Andrew F. Davis <a...@ti.com>
 Reviewed-by: Tom Rini <tr...@konsulko.com>

broke boot on Beagleboard xM. I mean the board hangs after:
 OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
 OMAP3 Beagle board + LPDDR/NAND
 I2C:   ready
 DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!

This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

OK.  Can you test FAT booting?  Both should work, but I have an idea at
least on RAW, but I'd like to rule out anything else other than size
changes.   Thanks!


Indeed, if u-boot.img is on FAT partition, it boots properly!


So, what is the problem?
Are we limited in size for u-boot.img when raw booting is used?

Guillaume

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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

2017-10-02 Thread Guillaume Gardet




Le 02/10/2017 à 17:58, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:


Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis <a...@ti.com>
Date:   Fri Apr 21 10:01:28 2017 -0500

     Kconfig: Enable FIT support by default for TI platforms

     Almost all TI defconfigs enable this already, add this as a default
     and remove the explicit assignment.

     Signed-off-by: Andrew F. Davis <a...@ti.com>
     Reviewed-by: Tom Rini <tr...@konsulko.com>

broke boot on Beagleboard xM. I mean the board hangs after:
     OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
     OMAP3 Beagle board + LPDDR/NAND
     I2C:   ready
     DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!

This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

OK.  Can you test FAT booting?  Both should work, but I have an idea at
least on RAW, but I'd like to rule out anything else other than size
changes.   Thanks!


Indeed, if u-boot.img is on FAT partition, it boots properly!

Guillaume

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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

2017-10-02 Thread Guillaume Gardet




Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis <a...@ti.com>
Date:   Fri Apr 21 10:01:28 2017 -0500

     Kconfig: Enable FIT support by default for TI platforms

     Almost all TI defconfigs enable this already, add this as a default
     and remove the explicit assignment.

     Signed-off-by: Andrew F. Davis <a...@ti.com>
     Reviewed-by: Tom Rini <tr...@konsulko.com>

broke boot on Beagleboard xM. I mean the board hangs after:
     OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
     OMAP3 Beagle board + LPDDR/NAND
     I2C:   ready
     DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!


This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

Guillaume

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

[U-Boot] Beagleboard xM boot broken due to FIT enable

2017-10-02 Thread Guillaume Gardet


Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis 
Date:   Fri Apr 21 10:01:28 2017 -0500

    Kconfig: Enable FIT support by default for TI platforms

    Almost all TI defconfigs enable this already, add this as a default
    and remove the explicit assignment.

    Signed-off-by: Andrew F. Davis 
    Reviewed-by: Tom Rini 

broke boot on Beagleboard xM. I mean the board hangs after:
    OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
    OMAP3 Beagle board + LPDDR/NAND
    I2C:   ready
    DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.


Guillaume


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

Re: [U-Boot] [PATCH] Revert 'rockchip: mkimage: remove placeholder functions from rkimage'

2017-06-26 Thread Guillaume Gardet




Le 22/06/2017 à 18:19, Dr. Philipp Tomsich a écrit :

Guillaume,


On 22 Jun 2017, at 10:11, Guillaume GARDET <guillaume.gar...@free.fr> wrote:

Revert commit 253c60a557d6740f15169a1f15772d7e64928d9b as it breaks the
return value of 'mkimage -T rkimage' and print the following  error:
'./tools/mkimage: Can't print header for Rockchip Boot Image support: Success’

If you revert the underlying change, then 'dumpimage -l spl.img’ will break for 
all
Rockchip rksd/rkspi images (see the original commit message for details why it
is necessary).

E.g. with the change in question reverted:
ptomsich@android:~/rk3399/u-boot$ tools/dumpimage -l spl-3368.img
ptomsich@android:~/rk3399/u-boot$
With the change in question in place:
ptomsich@android:~/rk3399/u-boot$ tools/dumpimage -l spl-3368.img
Image Type:   Rockchip RK33 (SD/MMC) boot image
Data Size:28672 bytes
ptomsich@android:~/rk3399/u-boot$

Looks like correctly doing this is even more involved in the imagetool framework
than meets the eye, as you error is coming from:

 /* Print the image information by processing image header */
 if (tparams->print_header)
 tparams->print_header (ptr);
 else {
 fprintf (stderr, "%s: Can't print header for %s: %s\n",
 params.cmdname, tparams->name, strerror(errno));
 exit (EXIT_FAILURE);
 }


So you might want to check whether adding but just the print_header
function works for you—the verify should be a sufficient guard for the
dumpimage case.

A yet better solution would be to implement verify_header/print_header
in a useful way for the rkimage type as well …


I am not familiar with RK, so I cannot implement this.
We should find a solution quite quickly since the release is not so far. Later, 
we could implement missing functions if wanted.

Could you propose a fix to your commit which is working for you, please?

Guillaume




Regards,
Philipp.


Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>

Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Tom Rini <tr...@konsulko.com>

---
tools/rkimage.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/tools/rkimage.c b/tools/rkimage.c
index 9880b1569f..44d098c775 100644
--- a/tools/rkimage.c
+++ b/tools/rkimage.c
@@ -13,6 +13,16 @@

static uint32_t header;

+static int rkimage_verify_header(unsigned char *buf, int size,
+struct image_tool_params *params)
+{
+   return 0;
+}
+
+static void rkimage_print_header(const void *buf)
+{
+}
+
static void rkimage_set_header(void *buf, struct stat *sbuf, int ifd,
   struct image_tool_params *params)
{
@@ -23,6 +33,11 @@ static void rkimage_set_header(void *buf, struct stat *sbuf, 
int ifd,
rkcommon_rc4_encode_spl(buf, 4, params->file_size);
}

+static int rkimage_extract_subimage(void *buf, struct image_tool_params 
*params)
+{
+   return 0;
+}
+
static int rkimage_check_image_type(uint8_t type)
{
if (type == IH_TYPE_RKIMAGE)
@@ -40,10 +55,10 @@ U_BOOT_IMAGE_TYPE(
4,
,
rkcommon_check_params,
-   NULL,
-   NULL,
+   rkimage_verify_header,
+   rkimage_print_header,
rkimage_set_header,
-   NULL,
+   rkimage_extract_subimage,
rkimage_check_image_type,
NULL,
NULL
--
2.12.3





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

[U-Boot] [PATCH] Revert 'rockchip: mkimage: remove placeholder functions from rkimage'

2017-06-22 Thread Guillaume GARDET

Revert commit 253c60a557d6740f15169a1f15772d7e64928d9b as it breaks the 
return value of 'mkimage -T rkimage' and print the following  error: 
'./tools/mkimage: Can't print header for Rockchip Boot Image support: Success'

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>

Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Tom Rini <tr...@konsulko.com>

---
 tools/rkimage.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/tools/rkimage.c b/tools/rkimage.c
index 9880b1569f..44d098c775 100644
--- a/tools/rkimage.c
+++ b/tools/rkimage.c
@@ -13,6 +13,16 @@
 
 static uint32_t header;
 
+static int rkimage_verify_header(unsigned char *buf, int size,
+struct image_tool_params *params)
+{
+   return 0;
+}
+
+static void rkimage_print_header(const void *buf)
+{
+}
+
 static void rkimage_set_header(void *buf, struct stat *sbuf, int ifd,
   struct image_tool_params *params)
 {
@@ -23,6 +33,11 @@ static void rkimage_set_header(void *buf, struct stat *sbuf, 
int ifd,
rkcommon_rc4_encode_spl(buf, 4, params->file_size);
 }
 
+static int rkimage_extract_subimage(void *buf, struct image_tool_params 
*params)
+{
+   return 0;
+}
+
 static int rkimage_check_image_type(uint8_t type)
 {
if (type == IH_TYPE_RKIMAGE)
@@ -40,10 +55,10 @@ U_BOOT_IMAGE_TYPE(
4,
,
rkcommon_check_params,
-   NULL,
-   NULL,
+   rkimage_verify_header,
+   rkimage_print_header,
rkimage_set_header,
-   NULL,
+   rkimage_extract_subimage,
rkimage_check_image_type,
NULL,
NULL
-- 
2.12.3

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

[U-Boot] [PATCH] omap3_beagle: use config_distro_bootcmd

2016-10-25 Thread Guillaume GARDET

Add support for distro_bootcmd on MMC and fall back to prior 
behavior if distro_bootcmd fails.

Tested on Beagleboad xM to boot GRUB2 (and then Linux kernel) in EFI mode 
from MMC.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Tom Rini <tr...@konsulko.com>

---
 include/configs/omap3_beagle.h | 76 --
 1 file changed, 43 insertions(+), 33 deletions(-)

diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 8a69a5f..9850aa6 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -104,11 +104,52 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1   /* Max number of NAND */
/* devices */
 
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0)
+
+#define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
+   "run distro_bootcmd; " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
+   "if run userbutton; then " \
+   "setenv bootenv uEnv.txt;" \
+   "else " \
+   "setenv bootenv user.txt;" \
+   "fi;" \
+   "echo SD/MMC found on device ${mmcdev};" \
+   "if run loadbootenv; then " \
+   "echo Loaded environment from ${bootenv};" \
+   "run importbootenv;" \
+   "fi;" \
+   "if test -n $uenvcmd; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "if run loadbootscript; then " \
+   "run bootscript; " \
+   "else " \
+   "if run loadimage; then " \
+   "run mmcboot;" \
+   "fi;" \
+   "fi; " \
+   "fi;" \
+   "run nandboot;" \
+   "setenv bootfile zImage;" \
+   "if run loadimage; then " \
+   "run loadfdt;" \
+   "run mmcbootz; " \
+   "fi; " \
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
+   "kernel_addr_r=0x8020\0" \
"rdaddr=0x8100\0" \
+   "initrd_addr_r=0x8100\0" \
"fdt_high=0x\0" \
"fdtaddr=0x80f8\0" \
+   "fdt_addr_r=0x80f8\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
"ramdisk=ramdisk.gz\0" \
@@ -203,39 +244,8 @@
"userbutton=if gpio input 173; then run userbutton_xm; " \
"else run userbutton_nonxm; fi;\0" \
"userbutton_xm=gpio input 4;\0" \
-   "userbutton_nonxm=gpio input 7;\0"
-/* "run userbutton" will return 1 (false) if pressed and 0 (true) if not */
-#define CONFIG_BOOTCOMMAND \
-   "run findfdt; " \
-   "mmc dev ${mmcdev}; if mmc rescan; then " \
-   "if run userbutton; then " \
-   "setenv bootenv uEnv.txt;" \
-   "else " \
-   "setenv bootenv user.txt;" \
-   "fi;" \
-   "echo SD/MMC found on device ${mmcdev};" \
-   "if run loadbootenv; then " \
-   "echo Loaded environment from ${bootenv};" \
-   "run importbootenv;" \
-   "fi;" \
-   "if test -n $uenvcmd; then " \
-   "echo Running uenvcmd ...;" \
-   "run uenvcmd;" \
-   "fi;" \
-   "if run loadbootscript; then " \
-   "run bootscript; " \
-   "else " \
-   "if run loadimage; then " \
-   "run mmcboot;" \
-   "fi;" \
-   "fi; " \
-   "fi;" \
-   "run nandboot;" \
-   "setenv bootfile zImage;" \
-   "if run loadimage; then " \
-   "run loadfdt;" \
-   "run mmcbootz; " \
-   "fi; " \
+   "userbutton_nonxm=gpio input 7;\0" \
+   BOOTENV
 
 /*
  * OMAP3 has 12 GP timers, they can be driven by the system clock
-- 
1.8.4.5

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

Re: [U-Boot] NFS and timeouts?

2016-10-19 Thread Guillaume Gardet


Hi,


Le 14/10/2016 à 15:40, Tom Rini a écrit :

On Fri, Oct 14, 2016 at 11:13:11AM +0200, Guillaume Gardet wrote:

Hi,


Le 14/10/2016 à 01:00, Joe Hershberger a écrit :

On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass <s...@chromium.org> wrote:

Hi Tom,

On 13 October 2016 at 13:11, Tom Rini <tr...@konsulko.com> wrote:

Hey all,

I've noticed now, but not dug into a problem that goes like this.  On
every platform that I have tried NFS on now (and I wasn't a user before
the test came in) I see:
# nfs 8000 /tftpboot/1MiBtest.bin
link up on port 0, speed 1000, full duplex
#
  #
  #
  ##T T T T
done
Bytes transferred = 1048576 (10 hex)

for the same 1MiB file.  The link line will vary from board to board but
the end result is that I always see 4 T (for timeout) at the end of the
transfer.  On boards where I am doing this on gigabit the initial
transfer is fast enough that the timeout doesn't cause failure.  On the
boards where I'm at 100Mbit instead however, I fail.

I have seen this also - what type of interface are you using?

Does this happen in your testing, Guillaume?


No, I never saw those timeouts. I will try to reproduce here.
On which boards does it happen?

AM335x GP EVM, DRA72x EVM ("J6 Eco"), Beagleboard xM, RPi 3 (32 or 64bit
mode).  I suspect it's something either config or network related.
Everything is on the same 24 port gigabit switch.



I just tried 2016.11-rc2 on a Beagleboard xM with:
* nfs download from a NFSv2 server
* nfs download from a NFSv3 server
* tftpboot download from a TFTP server

And all are working fine here.


Guillaume

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

Re: [U-Boot] NFS and timeouts?

2016-10-14 Thread Guillaume Gardet


Hi,


Le 14/10/2016 à 01:00, Joe Hershberger a écrit :

On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass  wrote:

Hi Tom,

On 13 October 2016 at 13:11, Tom Rini  wrote:

Hey all,

I've noticed now, but not dug into a problem that goes like this.  On
every platform that I have tried NFS on now (and I wasn't a user before
the test came in) I see:
# nfs 8000 /tftpboot/1MiBtest.bin
link up on port 0, speed 1000, full duplex
#
  #
  #
  ##T T T T
done
Bytes transferred = 1048576 (10 hex)

for the same 1MiB file.  The link line will vary from board to board but
the end result is that I always see 4 T (for timeout) at the end of the
transfer.  On boards where I am doing this on gigabit the initial
transfer is fast enough that the timeout doesn't cause failure.  On the
boards where I'm at 100Mbit instead however, I fail.

I have seen this also - what type of interface are you using?

Does this happen in your testing, Guillaume?



No, I never saw those timeouts. I will try to reproduce here.
On which boards does it happen?

Guillaume


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

Re: [U-Boot] [PATCH] test: add NFS download test

2016-10-07 Thread Guillaume Gardet




Le 23/09/2016 à 22:52, Joe Hershberger a écrit :

On Wed, Sep 14, 2016 at 3:29 AM, Guillaume GARDET
<guillaume.gar...@free.fr> wrote:

Add a NFS download test, based on TFTP test.
Tested on i.MX6 SabreLite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>

Cc: Tom Rini <tr...@konsulko.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Simon Glass <s...@chromium.org>

Acked-by: Joe Hershberger <joe.hershber...@ni.com>

I'll take the blank line out when I apply it.



Ping.

Guillaume

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

[U-Boot] [PATCH] test: add NFS download test

2016-09-14 Thread Guillaume GARDET

Add a NFS download test, based on TFTP test.
Tested on i.MX6 SabreLite board.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>

Cc: Tom Rini <tr...@konsulko.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Simon Glass <s...@chromium.org>

---
 test/py/tests/test_net.py | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index 4ab58b4..0884051 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -47,6 +47,15 @@ env__net_tftp_readable_file = {
 "size": 5058624,
 "crc32": "c2244b26",
 }
+
+# Details regarding a file that may be read from a NFS server. This variable
+# may be omitted or set to None if NFS testing is not possible or desired.
+env__net_nfs_readable_file = {
+"fn": "ubtest-readable.bin",
+"addr": 0x1000,
+"size": 5058624,
+"crc32": "c2244b26",
+}
 """
 
 net_set_up = False
@@ -157,3 +166,43 @@ def test_net_tftpboot(u_boot_console):
 
 output = u_boot_console.run_command('crc32 %x $filesize' % addr)
 assert expected_crc in output
+
+@pytest.mark.buildconfigspec('cmd_nfs')
+def test_net_nfs(u_boot_console):
+"""Test the nfs command.
+
+A file is downloaded from the NFS server, its size and optionally its
+CRC32 are validated.
+
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip('Network not initialized')
+
+f = u_boot_console.config.env.get('env__net_nfs_readable_file', None)
+if not f:
+pytest.skip('No NFS readable file to read')
+
+addr = f.get('addr', None)
+if not addr:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+fn = f['fn']
+output = u_boot_console.run_command('nfs %x %s' % (addr, fn))
+expected_text = 'Bytes transferred = '
+sz = f.get('size', None)
+if sz:
+expected_text += '%d' % sz
+assert expected_text in output
+
+expected_crc = f.get('crc32', None)
+if not expected_crc:
+return
+
+if u_boot_console.config.buildconfig.get('config_cmd_crc32', 'n') != 'y':
+return
+
+output = u_boot_console.run_command('crc32 %x $filesize' % addr)
+assert expected_crc in output
-- 
1.8.4.5

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

Re: [U-Boot] [PATCH 8/9] net: nfs: Use the tx buffer to construct rpc msgs

2016-09-07 Thread Guillaume Gardet


Le 07/09/2016 à 09:33, Guillaume Gardet a écrit :



Le 06/09/2016 à 21:09, Joe Hershberger a écrit :

On Tue, Sep 6, 2016 at 8:09 AM, Guillaume Gardet
<guillaume.gar...@free.fr> wrote:

Hi Joe,

I tested 2016.09-rc2 on a beagleboard xM and NFS does not work anymore!
When I call the nfs command, I get a "data abort" error with a reboot of the
board!

Yikes!


A git bisect point to this patch: "net: nfs: Use the tx buffer to construct
rpc msgs"

Could you have a look and fix it for the release, please? At least revert it
for now.

In your testing does reverting just this patch fix things for you? If
so, I can send a revert of just that for the short term.


If I revert this patch only, data abort disappear but NFS is not working fine 
since when I download a boot.scr file, I get the folowing error while sourcing 
it:
## Executing script at 8020
Bad data crc

I will try to find the problem.


Found. You also need to revert: commit 6279b49e6c2fdaf8665355d1777bc90cd41fcf90: 
"net: nfs: Correct the reply data buffer size"

Reverting those 2 commits makes the NFS working again.


Guillaume




Guillaume



Thanks,
-Joe


Guillaume




Le 15/08/2016 à 22:03, Joe Hershberger a écrit :

Instead of always allocating a huge temporary buffer on the stack and
then memcpy()ing the result into the transmit buffer, simply figure out
where in the transmit buffer the bytes will belong and write them there
directly as each message is built.

Signed-off-by: Joe Hershberger <joe.hershber...@ni.com>
---

   net/nfs.c | 88
---
   1 file changed, 45 insertions(+), 43 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index 31047c2..3fb253b 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -183,41 +183,41 @@ static uint32_t *rpc_add_credentials(uint32_t *p)

/**
   RPC_LOOKUP - Lookup RPC Port numbers

**/
-static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int
datalen)
+static struct rpc_t *rpc_req_prep(void)
+{
+   return (struct rpc_t *)(net_tx_packet + net_eth_hdr_size() +
+   IP_UDP_HDR_SIZE);
+}
+
+static void rpc_req(int rpc_prog, int rpc_proc, struct rpc_t *rpc_pkt,
+   int datalen)
   {
-   struct rpc_t rpc_pkt;
 unsigned long id;
-   uint32_t *p;
 int pktlen;
 int sport;
 id = ++rpc_id;
-   rpc_pkt.u.call.id = htonl(id);
-   rpc_pkt.u.call.type = htonl(MSG_CALL);
-   rpc_pkt.u.call.rpcvers = htonl(2);  /* use RPC version 2 */
-   rpc_pkt.u.call.prog = htonl(rpc_prog);
+   rpc_pkt->u.call.id = htonl(id);
+   rpc_pkt->u.call.type = htonl(MSG_CALL);
+   rpc_pkt->u.call.rpcvers = htonl(2); /* use RPC version 2 */
+   rpc_pkt->u.call.prog = htonl(rpc_prog);
 switch (rpc_prog) {
 case PROG_NFS:
 if (supported_nfs_versions & NFSV2_FLAG)
-   rpc_pkt.u.call.vers = htonl(2); /* NFS v2 */
+   rpc_pkt->u.call.vers = htonl(2);/* NFS v2
*/
 else /* NFSV3_FLAG */
-   rpc_pkt.u.call.vers = htonl(3); /* NFS v3 */
+   rpc_pkt->u.call.vers = htonl(3);/* NFS v3
*/
 break;
 case PROG_PORTMAP:
 case PROG_MOUNT:
 default:
-   rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2
*/
+   /* portmapper is version 2 */
+   rpc_pkt->u.call.vers = htonl(2);
 }
-   rpc_pkt.u.call.proc = htonl(rpc_proc);
-   p = (uint32_t *)&(rpc_pkt.u.call.data);
-
-   if (datalen)
-   memcpy((char *)p, (char *)data, datalen*sizeof(uint32_t));
-
-   pktlen = (char *)p + datalen * sizeof(uint32_t) - (char
*)_pkt;
+   rpc_pkt->u.call.proc = htonl(rpc_proc);
   - memcpy((char *)net_tx_packet + net_eth_hdr_size() +
IP_UDP_HDR_SIZE,
-  _pkt.u.data[0], pktlen);
+   pktlen = ((char *)_pkt->u.call.data - (char *)_pkt) +
+   datalen * sizeof(uint32_t);
 if (rpc_prog == PROG_PORTMAP)
 sport = SUNRPC_PORT;
@@ -235,15 +235,17 @@ RPC_LOOKUP - Lookup RPC Port numbers

**/
   static void rpc_lookup_req(int prog, int ver)
   {
-   uint32_t data[16];
+   uint32_t *data;
+   struct rpc_t *rpc_pkt = rpc_req_prep();
   + data = rpc_pkt->u.call.data;
 data[0] = 0; data[1] = 0;   /* auth credential */
 data[2] = 0; data[3] = 0;   /* auth verifier */
 data[4] = htonl(prog);
 data[5] = htonl(ver);
 data[6] = htonl(17);/* IP_UDP */
 data[7] = 0;
-   rpc_req(PROG_PORTMAP, PORT

1 2 3 >

1 - 100 of 233 matches

Mail list logo