Re: [U-Boot] [PATCH 1/1] x86: #define CONFIG_LOADADDR 0x1100000

[Alexander Graf]

> Am 31.01.2019 um 08:50 schrieb Bin Meng :
> 
> Hi Heinrich,
> 
>> On Fri, Jan 25, 2019 at 4:18 AM Heinrich Schuchardt  
>> wrote:
>> 
>> arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x100.
> 
> I think you misread the codes. 0x100 means PCI I/O space, not the
> actual address here. See FDT_PCI_SPACE_IO in fdtdec.h.

It still crashes. Can you explain why? :)

Alex

> 
>> Loading via the `dhcp` command to this address leads to a crash on
>> qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x110.
>> 
>> Reported-by: Alexander Graf 
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> compatible='pci-x86' is a U-Boot specific device tree binding.
>> Unfortunately it is not documented. Simon, it would be helpful
>> if you could provide some README.
>> ---
>> include/configs/x86-common.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
> 
> Regards,
> Bin

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

Re: [U-Boot] [PATCH 1/1] x86: #define CONFIG_LOADADDR 0x1100000

[Bin Meng]

Hi Heinrich,

On Fri, Jan 25, 2019 at 4:18 AM Heinrich Schuchardt  wrote:
>
> arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x100.

I think you misread the codes. 0x100 means PCI I/O space, not the
actual address here. See FDT_PCI_SPACE_IO in fdtdec.h.

> Loading via the `dhcp` command to this address leads to a crash on
> qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x110.
>
> Reported-by: Alexander Graf 
> Signed-off-by: Heinrich Schuchardt 
> ---
> compatible='pci-x86' is a U-Boot specific device tree binding.
> Unfortunately it is not documented. Simon, it would be helpful
> if you could provide some README.
> ---
>  include/configs/x86-common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

Re: [U-Boot] U-Boot and USB 3.0

[Bin Meng]

On Thu, Jan 31, 2019 at 2:29 AM DJM-Avalesta  wrote:
>
> Hi Bin
>
> Further to previous, I have built the latest u-boot source from git.denx.de 
> but, when I flash this version, it fails to boot the kernel. Here are the 
> debug traces.
>

+Tom who is the maintainer of Tegra to check.

[snip]

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

Re: [U-Boot] [PATCH v1 2/2] x86: edison: Switch to CONFIG_OF_SEPARATE

[Bin Meng]

On Fri, Jan 11, 2019 at 5:48 AM Ferry Toth  wrote:
>
> Op 08-01-19 om 15:17 schreef Andy Shevchenko:
> > There is no need for Intel Edison to have CONFIG_OF_EMBED to be enabled.
> > Replace it with CONFIG_OF_SEPARATE.
> >
> > There is no functional change since u-boot.bin always contains DTB
> > either embedded or attached.
> >
> > Signed-off-by: Andy Shevchenko 
> Tested-by: Ferry Toth 
> > ---
> >   configs/edison_defconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/2] doc: Fix CONFIG_OF_SEPARATE description

[Bin Meng]

On Thu, Jan 31, 2019 at 3:54 AM Andy Shevchenko
 wrote:
>
> On Tue, Jan 08, 2019 at 04:17:42PM +0200, Andy Shevchenko wrote:
> > CONFIG_OF_SEPARATE description is not in align with actual code in Makefile 
> > and
> > thus has misleading instructions and explanation.
> >
> > Make it aligned with the actual code.
>
> Bin, is it possible to see this for the next release?
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Nand boot on imx6q board is broken

[Shyam Saini]

Hi Everyone,

I'm trying to boot imx6q board from nand but it seems like mainline
u-boot nand boot support for imx6q board is broken.

It is working till v2017.05 with this fix [1].

I'm using this as my stub:
https://github.com/openedev/u-boot-amarula/tree/icore-nand



When I git bisect between v2017.05 and v2017.07, found this commit
which is further breaking  the nand boot support:
--
ommit bc1fe9006dfaacc5103b5c7057a62215844957b7
Author: Jagan Teki 
Date:   Sun May 7 02:43:05 2017 +0530

icorem6: Make SPL to pick suitable fdt

SPL FIT is able to pick the suitable fdt file for u-boot,
so add that function through board_fit_config_name_match.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
-
And It is fixed with this [2].

In mainline u-boot we already  have fix [1] and [2] available but nand
boot is still broken. It seems like problem is some where else, fix
[1] and [2] are just making the bug appear less frequently.

logs:
[3] nand boot working
[4] Nand boot not working

Has anyone else faced or fixed the same issue on imx6 board.
Please let me know.


[1] https://paste.ubuntu.com/p/nKq7SNWDrn/
[2] https://paste.ubuntu.com/p/tXqbx5dVPJ/
[3] https://paste.ubuntu.com/p/DcBQ4gcSCM/
[4] https://paste.ubuntu.com/p/WVtrqfdVQT/


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

Re: [U-Boot] [PATCH v3] x86: tsc: Add support for native calibration of TSC freq

[Bin Meng]

On Mon, Jan 7, 2019 at 7:14 PM Bernhard Messerklinger
 wrote:
>
> Add native tsc calibration function. Calibrate the tsc timer the same
> way as linux does in arch/x86/kernel/tsc.c.
> Fixes booting for Apollo Lake processors.
>
> Signed-off-by: Bernhard Messerklinger 
> 
> ---
> I hope this patch won't break other x86 board.
> I only can test it with APL board.
>
> Changes in v4:
> - Fix commit message
> - Update macro names
> - Order macro numbers
> - Check cpuid eax and ebx return value
>
>  drivers/timer/tsc_timer.c | 55 +++
>  1 file changed, 55 insertions(+)
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] x86: tsc: Add support for native calibration of TSC freq

[Bin Meng]

On Fri, Dec 21, 2018 at 3:31 PM Bernhard Messerklinger
 wrote:
>
> Add native tsc calibration function. Calibrate the tsc timer the same
> way as linux does arch/x86/kernel/tsc.c.
> Fixes booting for Apollo Lake processors.
>
> Signed-off-by: Bernhard Messerklinger 
> 
> ---
> I hope this patch won't break other x86 board.
> I only can test it with APL board.
>
> Changes in v1:
> - Update to linux way of dealing with TSC calibration
>
>  drivers/timer/tsc_timer.c | 52 +++
>  1 file changed, 52 insertions(+)
>

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

Re: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset

[Bin Meng]

On Thu, Jan 31, 2019 at 3:30 PM Bin Meng  wrote:
>
> On Thu, Jan 31, 2019 at 9:24 AM Simon Glass  wrote:
> >
> > Hi,
> >
> > On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt  
> > wrote:
> > >
> > > On 1/30/19 11:46 AM, Alexander Graf wrote:
> > > > Our selftest will soon test the actual runtime reset function rather 
> > > > than
> > > > the boot time one. For this, we need to ensure that the runtime version
> > > > actually succeeds on x86 to keep our travis tests work.
> > > >
> > > > So this patch implements an x86 runtime reset function. It is missing
> > > > shutdown functionality today, but OSs usually implement that via ACPI
> > > > and this function does more than the stub from before, so it's at least
> > > > an improvement.
> > > >
> > > > Eventually we will want to have full DM functionality in runtime 
> > > > services.
> > > > But this fixes a travis failure and doesn't clutter the code too 
> > > > heavily, so
> > > > we should pull it in without the amazing new RTS DM framework.
> > > >
> > > > Signed-off-by: Alexander Graf 
> > > >
> > > > ---
> > > >
> > > > v2 -> v3:
> > > >
> > > >   - support EFI_RESET_PLATFORM_SPECIFIC
> > > >   - reuse existing x86_sysreset_request() function
> > >
> > > The v2->v3 update does not answer the question if the reset is correctly
> > > implemented. We would not want to call a function we do not trust.
> > >
> > > @Simon, Bin:
> > > x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in
> > > native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
> > > which is tried before using the keyboard controller as last resort.
> > >
> > > u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
> > > u8 cf9 = inb(0xcf9) & ~reboot_code;
> > > outb(cf9|2, 0xcf9); /* Request hard reset */
> > > udelay(50);
> > > /* Actually do the reset */
> > > outb(cf9|reboot_code, 0xcf9);
> > > udelay(50);
> > >
> > > So the Kernel first switches bit 2 off and bit 1 on, waits, and then
> > > switches bit 2 on, cf.
> > > http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html
> > >
> > > Shouldn't we do it the same way as the Kernel does it?
> >
> > I suspect so, but Bin is the expert.
> >
>
> What U-Boot does is essentially the same as Linux but a simplified
> version, because bit 2 is 0 any way. If it were 0, the system should

Sorry, a typo: If it were "1"

> have been reset already then there is no chance to execute the reset
> sequence at all.
>
> > As to this patch, it perpetuates the current EFI run-time approach in
> > U-Boot so I'm not sure this is the right path.
> >
>

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

Re: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset

[Bin Meng]

On Thu, Jan 31, 2019 at 9:24 AM Simon Glass  wrote:
>
> Hi,
>
> On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt  wrote:
> >
> > On 1/30/19 11:46 AM, Alexander Graf wrote:
> > > Our selftest will soon test the actual runtime reset function rather than
> > > the boot time one. For this, we need to ensure that the runtime version
> > > actually succeeds on x86 to keep our travis tests work.
> > >
> > > So this patch implements an x86 runtime reset function. It is missing
> > > shutdown functionality today, but OSs usually implement that via ACPI
> > > and this function does more than the stub from before, so it's at least
> > > an improvement.
> > >
> > > Eventually we will want to have full DM functionality in runtime services.
> > > But this fixes a travis failure and doesn't clutter the code too heavily, 
> > > so
> > > we should pull it in without the amazing new RTS DM framework.
> > >
> > > Signed-off-by: Alexander Graf 
> > >
> > > ---
> > >
> > > v2 -> v3:
> > >
> > >   - support EFI_RESET_PLATFORM_SPECIFIC
> > >   - reuse existing x86_sysreset_request() function
> >
> > The v2->v3 update does not answer the question if the reset is correctly
> > implemented. We would not want to call a function we do not trust.
> >
> > @Simon, Bin:
> > x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in
> > native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
> > which is tried before using the keyboard controller as last resort.
> >
> > u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
> > u8 cf9 = inb(0xcf9) & ~reboot_code;
> > outb(cf9|2, 0xcf9); /* Request hard reset */
> > udelay(50);
> > /* Actually do the reset */
> > outb(cf9|reboot_code, 0xcf9);
> > udelay(50);
> >
> > So the Kernel first switches bit 2 off and bit 1 on, waits, and then
> > switches bit 2 on, cf.
> > http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html
> >
> > Shouldn't we do it the same way as the Kernel does it?
>
> I suspect so, but Bin is the expert.
>

What U-Boot does is essentially the same as Linux but a simplified
version, because bit 2 is 0 any way. If it were 0, the system should
have been reset already then there is no chance to execute the reset
sequence at all.

> As to this patch, it perpetuates the current EFI run-time approach in
> U-Boot so I'm not sure this is the right path.
>

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

[U-Boot] [PATCH] arm: dts: am33xx: add u-boot, dm-spl to ocp bus

[Hannes Schmelzer]

commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
introduced with
commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")

Due to this the brppt1_spi board is broken because it cannot
bind/probe the spi-interface during SPL stage.

This commit adds this flag again.

This flag is needed for having access to the devices below this bus,
most important is uart and boot-device (spi, mmc, ...) in SPL stage.

Signed-off-by: Hannes Schmelzer 

---

 arch/arm/dts/am33xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
index d3dd6a1..0a6b177 100644
--- a/arch/arm/dts/am33xx.dtsi
+++ b/arch/arm/dts/am33xx.dtsi
@@ -160,6 +160,7 @@
 * the whole bus hierarchy.
 */
ocp {
+   u-boot,dm-spl;
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
-- 
2.7.4


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

Re: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset

[Alexander Graf]

> Am 31.01.2019 um 02:24 schrieb Simon Glass :
> 
> Hi,
> 
>> On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt  wrote:
>> 
>>> On 1/30/19 11:46 AM, Alexander Graf wrote:
>>> Our selftest will soon test the actual runtime reset function rather than
>>> the boot time one. For this, we need to ensure that the runtime version
>>> actually succeeds on x86 to keep our travis tests work.
>>> 
>>> So this patch implements an x86 runtime reset function. It is missing
>>> shutdown functionality today, but OSs usually implement that via ACPI
>>> and this function does more than the stub from before, so it's at least
>>> an improvement.
>>> 
>>> Eventually we will want to have full DM functionality in runtime services.
>>> But this fixes a travis failure and doesn't clutter the code too heavily, so
>>> we should pull it in without the amazing new RTS DM framework.
>>> 
>>> Signed-off-by: Alexander Graf 
>>> 
>>> ---
>>> 
>>> v2 -> v3:
>>> 
>>>  - support EFI_RESET_PLATFORM_SPECIFIC
>>>  - reuse existing x86_sysreset_request() function
>> 
>> The v2->v3 update does not answer the question if the reset is correctly
>> implemented. We would not want to call a function we do not trust.
>> 
>> @Simon, Bin:
>> x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in
>> native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
>> which is tried before using the keyboard controller as last resort.
>> 
>> u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
>> u8 cf9 = inb(0xcf9) & ~reboot_code;
>> outb(cf9|2, 0xcf9); /* Request hard reset */
>> udelay(50);
>> /* Actually do the reset */
>> outb(cf9|reboot_code, 0xcf9);
>> udelay(50);
>> 
>> So the Kernel first switches bit 2 off and bit 1 on, waits, and then
>> switches bit 2 on, cf.
>> http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html
>> 
>> Shouldn't we do it the same way as the Kernel does it?
> 
> I suspect so, but Bin is the expert.
> 
> As to this patch, it perpetuates the current EFI run-time approach in
> U-Boot so I'm not sure this is the right path.

It is the right short- to mid-term plan. I rather have a shed I can live in 
today than a palace in 5 years :). Well, not true, I probably want both :).


Alex


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

Re: [U-Boot] [PATCH v3] moveconfig: add a second pass for empty #if/#endif blocks

[Masahiro Yamada]

On Wed, Jan 30, 2019 at 5:55 PM Masahiro Yamada
 wrote:
>
> On Wed, Jan 30, 2019 at 4:23 PM Chris Packham  wrote:
> >
> > Moveconfig already attempts to remove empty #if/#endif blocks when there
> > is a matching CONFIG_ being moved. Add a second pass which covers files
> > without a match.
> >
> > Signed-off-by: Chris Packham 
> > ---
> > This was previously submitted as
> > http://patchwork.ozlabs.org/patch/924901/ there still seems to be cases
> > of #if/#endif left over from Kconfig migrations so perhaps this is still
> > needed/wanted.
> >
> > I've plumbed this in as a second pass because ultimately we may want to
> > make this a separate option. Also I couldn't figure out how to implement
> > this without using re.M so I couldn't make it work in with the line by
> > line parsing of cleanup_one_header().
>
>
> This seems useful to find leftover code
> regardless of the CONFIG options you are moving.
>
> One drawback is, it may fold unrelated cleanups.
>
> Maybe, it would be useful to add a separate option to turn on this feature,
> or make it into a separate tool.
>
>
>


I tested this patch.
It detected one empty block.


diff --git a/include/configs/omap3_cairo.h b/include/configs/omap3_cairo.h
index 04bce2f..ac1a6cb 100644
--- a/include/configs/omap3_cairo.h
+++ b/include/configs/omap3_cairo.h
@@ -197,8 +197,6 @@
  * are needed and peripheral clocks for UART2 must be enabled in
  * function per_clocks_enable().
  */
-#ifdef CONFIG_SPL_BUILD
-#endif

 /* Provide the MACH_TYPE value the vendor kernel requires */
 #define CONFIG_MACH_TYPE   3063







This seems a leftover of 9baa2bce.


$ git show 9baa2bce -- include/configs/omap3_cairo.h
commit 9baa2bce28901321d6f62399b5ebeb3fcb8e8a57
Author: Adam Ford 
Date:   Tue Aug 7 07:08:32 2018 -0500

Removed unused references to CONFIG_SERIALx

After creating CONS_INDEX and migrating a bunch of boards to it,
there are a bunch of defined references to CONFIG_SERIALx which
are not referenced in any C code or #ifdef, so they can now be
removed

Signed-off-by: Adam Ford 

diff --git a/include/configs/omap3_cairo.h b/include/configs/omap3_cairo.h
index 0133416..04bce2f 100644
--- a/include/configs/omap3_cairo.h
+++ b/include/configs/omap3_cairo.h
@@ -198,8 +198,6 @@
  * function per_clocks_enable().
  */
 #ifdef CONFIG_SPL_BUILD
-#undef CONFIG_SERIAL3
-#define CONFIG_SERIAL2
 #endif

 /* Provide the MACH_TYPE value the vendor kernel requires */





However, I doubt it used the moveconfig tool.


I re-ran the tool against the previous commit.


$ git checkout 9baa2bce2890^
$ tools/moveconfig.py -H SERIAL0 SERIAL1 SERIAL2 SERIAL3
Clean up headers? [y/n]: y
y
...
$ git diff -- include/configs/omap3_cairo.h
diff --git a/include/configs/omap3_cairo.h b/include/configs/omap3_cairo.h
index 0133416..ac1a6cb 100644
--- a/include/configs/omap3_cairo.h
+++ b/include/configs/omap3_cairo.h
@@ -197,10 +197,6 @@
  * are needed and peripheral clocks for UART2 must be enabled in
  * function per_clocks_enable().
  */
-#ifdef CONFIG_SPL_BUILD
-#undef CONFIG_SERIAL3
-#define CONFIG_SERIAL2
-#endif

 /* Provide the MACH_TYPE value the vendor kernel requires */
 #define CONFIG_MACH_TYPE   3063





cleanup_one_header() did a good job.

Is there a particular case that the second path is needed?



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

[U-Boot] [PATCH] mips: mt76xx: Use correct timer frequency

[Stefan Roese]

Testing has shown that the timer on the MT7688 platforms does not run
correctly (too fast timeout). This patch changes
CONFIG_SYS_MIPS_TIMER_FREQ from 200MHz to 290MHz which is the correct
value, as its also used in Linux.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
 include/configs/gardena-smart-gateway-mt7688.h | 2 +-
 include/configs/linkit-smart-7688.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/gardena-smart-gateway-mt7688.h 
b/include/configs/gardena-smart-gateway-mt7688.h
index b10857a757..b3b89d2ab9 100644
--- a/include/configs/gardena-smart-gateway-mt7688.h
+++ b/include/configs/gardena-smart-gateway-mt7688.h
@@ -7,7 +7,7 @@
 #define __CONFIG_GARDENA_SMART_GATEWAY_H
 
 /* CPU */
-#define CONFIG_SYS_MIPS_TIMER_FREQ 2
+#define CONFIG_SYS_MIPS_TIMER_FREQ 29000
 
 /* RAM */
 #define CONFIG_SYS_SDRAM_BASE  0x8000
diff --git a/include/configs/linkit-smart-7688.h 
b/include/configs/linkit-smart-7688.h
index 3bae92d0ee..2adf38545a 100644
--- a/include/configs/linkit-smart-7688.h
+++ b/include/configs/linkit-smart-7688.h
@@ -7,7 +7,7 @@
 #define __CONFIG_LINKIT_SMART_7688_H
 
 /* CPU */
-#define CONFIG_SYS_MIPS_TIMER_FREQ 2
+#define CONFIG_SYS_MIPS_TIMER_FREQ 29000
 
 /* RAM */
 #define CONFIG_SYS_SDRAM_BASE  0x8000
-- 
2.20.1

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

[U-Boot] [PATCH 5/5] configs: am65x_evm_a53: enable networking

[Keerthy]

From: Grygorii Strashko 

Enable TI K3 AM65x CPSW NUSS driver.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 configs/am65x_evm_a53_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 9ce22157c9..bf26fb4838 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -42,6 +42,7 @@ CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_IS_IN_FAT=y
 CONFIG_ENV_FAT_INTERFACE="mmc"
 CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
@@ -56,6 +57,11 @@ CONFIG_K3_SEC_PROXY=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PHY_TI=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
@@ -71,3 +77,4 @@ CONFIG_DM_SERIAL=y
 CONFIG_SOC_TI=y
 CONFIG_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
+CONFIG_HEXDUMP=y
-- 
2.17.1

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

[U-Boot] [PATCH 3/5] arm64: dts: ti: k3-am65: add mcu cpsw node

[Keerthy]

From: Grygorii Strashko 

Add mcu cpsw and its components along with scm_conf node
to have ethernet functional.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 arch/arm/dts/k3-am65.dtsi|   2 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 111 +++
 2 files changed, 113 insertions(+)

diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3d4bf369d0..9d1ed49753 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -64,6 +64,7 @@
 /* MCUSS Range */
 <0x00 0x2838 0x00 0x2838 0x00 0x0388>,
 <0x00 0x4020 0x00 0x4020 0x00 0x00900100>,
+<0x00 0x40f0 0x00 0x40f0 0x00 0x0002>,
 <0x00 0x4204 0x00 0x4204 0x00 0x03ac2400>,
 <0x00 0x4510 0x00 0x4510 0x00 0x00c24000>,
 <0x00 0x4600 0x00 0x4600 0x00 0x0020>,
@@ -75,6 +76,7 @@
#size-cells = <2>;
ranges = <0x00 0x2838 0x00 0x2838 0x00 
0x0388>, /* MCU NAVSS*/
 <0x00 0x4020 0x00 0x4020 0x00 
0x00900100>, /* First peripheral window */
+<0x00 0x40f0 0x00 0x40f0 0x00 
0x0002>, /* CTRL_MMR0 */
 <0x00 0x4204 0x00 0x4204 0x00 
0x03ac2400>, /* WKUP */
 <0x00 0x4510 0x00 0x4510 0x00 
0x00c24000>, /* MMRs, remaining NAVSS */
 <0x00 0x4600 0x00 0x4600 0x00 
0x0020>, /* CPSW */
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 5a934b106d..27685c5a22 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -13,6 +13,7 @@
 
aliases {
serial2 = _uart0;
+   ethernet0 = _port1;
};
 };
 
@@ -109,6 +110,116 @@
ti,sci-rm-range-rflow = <0x5>; /* GP RFLOW */
};
};
+
+   mcu_conf: scm_conf@40f0 {
+   compatible = "syscon";
+   reg = <0x0 0x40f0 0x0 0x2>;
+   };
+
+   mcu_cpsw: cpsw_nuss@04600 {
+   compatible = "ti,am654-cpsw-nuss";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x4600 0x0 0x20>;
+   reg-names = "cpsw_nuss";
+   ranges;
+   dma-coherent;
+   clocks = <_clks 5 10>;
+   clock-names = "fck";
+   power-domains = <_pds 5>;
+   ti,psil-base = <0x7000>;
+
+   dmas = <_udmap _cpsw 0 UDMA_DIR_TX>,
+  <_udmap _cpsw 1 UDMA_DIR_TX>,
+  <_udmap _cpsw 2 UDMA_DIR_TX>,
+  <_udmap _cpsw 3 UDMA_DIR_TX>,
+  <_udmap _cpsw 4 UDMA_DIR_TX>,
+  <_udmap _cpsw 5 UDMA_DIR_TX>,
+  <_udmap _cpsw 6 UDMA_DIR_TX>,
+  <_udmap _cpsw 7 UDMA_DIR_TX>,
+  <_udmap _cpsw 0 UDMA_DIR_RX>;
+   dma-names = "tx0", "tx1", "tx2", "tx3",
+   "tx4", "tx5", "tx6", "tx7",
+   "rx";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   host: host@0 {
+   reg = <0>;
+   ti,label = "host";
+   };
+
+   cpsw_port1: port@1 {
+   reg = <1>;
+   ti,mac-only;
+   ti,label = "port1";
+   ti,syscon-efuse = <_conf 0x200>;
+   };
+   };
+
+   davinci_mdio: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   bus_freq = <100>;
+   };
+
+   ti,psil-config0 {
+   linux,udma-mode = ;
+   statictr-type = ;
+   ti,needs-epib;
+   ti,psd-size = <16>;
+   };
+
+   ti,psil-config1 {
+   linux,udma-mode = ;
+   statictr-type = ;
+   ti,needs-epib;
+   ti,psd-size = <16>;
+   };
+
+   ti,psil-config2 {
+   linux,udma-mode = ;
+   statictr-type = ;
+   ti,needs-epib;
+   ti,psd-size = <16>;
+   };
+
+   ti,psil-config3 {
+   linux,udma-mode = ;
+   statictr-type = ;
+   

[U-Boot] [PATCH 4/5] arm64: dts: k3-am654-base-board: add mcu cpsw nuss pinmux and phy defs

[Keerthy]

From: Grygorii Strashko 

Add mcu cpsw nuss pinmux and phy defs required by cpsw.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 59 
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 27685c5a22..404df4ed36 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 / {
chosen {
@@ -299,6 +300,32 @@
u-boot,dm-spl;
 };
 
+_pmx0 {
+   mcu_cpsw_pins_default: mcu_cpsw_pins_default {
+   pinctrl-single,pins = <
+   AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT | MUX_MODE0) /* 
(N4) MCU_RGMII1_TX_CTL */
+   AM65X_WKUP_IOPAD(0x005c, PIN_INPUT | MUX_MODE0) /* (N5) 
MCU_RGMII1_RX_CTL */
+   AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT | MUX_MODE0) /* 
(M2) MCU_RGMII1_TD3 */
+   AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT | MUX_MODE0) /* 
(M3) MCU_RGMII1_TD2 */
+   AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT | MUX_MODE0) /* 
(M4) MCU_RGMII1_TD1 */
+   AM65X_WKUP_IOPAD(0x006c, PIN_OUTPUT | MUX_MODE0) /* 
(M5) MCU_RGMII1_TD0 */
+   AM65X_WKUP_IOPAD(0x0078, PIN_INPUT | MUX_MODE0) /* (L2) 
MCU_RGMII1_RD3 */
+   AM65X_WKUP_IOPAD(0x007c, PIN_INPUT | MUX_MODE0) /* (L5) 
MCU_RGMII1_RD2 */
+   AM65X_WKUP_IOPAD(0x0080, PIN_INPUT | MUX_MODE0) /* (M6) 
MCU_RGMII1_RD1 */
+   AM65X_WKUP_IOPAD(0x0084, PIN_INPUT | MUX_MODE0) /* (L6) 
MCU_RGMII1_RD0 */
+   AM65X_WKUP_IOPAD(0x0070, PIN_INPUT | MUX_MODE0) /* (N1) 
MCU_RGMII1_TXC */
+   AM65X_WKUP_IOPAD(0x0074, PIN_INPUT | MUX_MODE0) /* (M1) 
MCU_RGMII1_RXC */
+   >;
+   };
+
+   mcu_mdio_pins_default: mcu_mdio1_pins_default {
+   pinctrl-single,pins = <
+   AM65X_WKUP_IOPAD(0x008c, PIN_OUTPUT | MUX_MODE0) /* 
(L1) MCU_MDIO0_MDC */
+   AM65X_WKUP_IOPAD(0x0088, PIN_INPUT | MUX_MODE0) /* (L4) 
MCU_MDIO0_MDIO */
+   >;
+   };
+};
+
 _uart0 {
u-boot,dm-spl;
pinctrl-names = "default";
@@ -322,3 +349,35 @@
pinctrl-0 = <_mmc1_pins_default>;
sdhci-caps-mask = <0x7 0x0>;
 };
+
+_cpsw {
+   pinctrl-names = "default";
+   pinctrl-0 = <_cpsw_pins_default _mdio_pins_default>;
+};
+
+_mdio {
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   /* TODO: phy reset: 
TCA9555RTWR(i2c:0x21)[p04].GPIO_MCU_RGMII_RSTN */
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+};
+
+_port1 {
+   phy-mode = "rgmii-id";
+   phy-handle = <>;
+};
+
+_cpsw {
+   reg = <0x0 0x4600 0x0 0x20>,
+ <0x0 0x40f00200 0x0 0x2>;
+   reg-names = "cpsw_nuss", "mac_efuse";
+
+   cpsw-phy-sel@40f04040 {
+   compatible = "ti,am654-cpsw-phy-sel";
+   reg= <0x0 0x40f04040 0x0 0x4>;
+   reg-names = "gmii-sel";
+   };
+};
-- 
2.17.1

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

[U-Boot] [PATCH 2/5] net: ethernet: ti: Introduce am654 gigabit eth switch subsystem driver

[Keerthy]

From: Grygorii Strashko 

Add new driver for the TI AM65x SoC Gigabit Ethernet Switch subsystem (CPSW
NUSS). It has two ports and provides Ethernet packet communication for the
device and can be configured as an Ethernet switch. CPSW NUSS features: the
Reduced Gigabit Media Independent Interface (RGMII), Reduced Media
Independent Interface (RMII), and the Management Data Input/Output (MDIO)
interface for physical layer device (PHY) management. The TI AM65x SoC has
integrated two-port Gigabit Ethernet Switch subsystem into device MCU
domain named MCU_CPSW0. One Ethernet port (port 1) with selectable RGMII
and RMII interfaces and an internal Communications Port Programming
Interface (CPPI) port (Host port 0).

Host Port 0 CPPI Packet Streaming Interface interface supports 8 TX
channels and on RX channels operating by TI am654 NAVSS Unified DMA
Peripheral Root Complex (UDMA-P) controller.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 drivers/net/ti/Kconfig  |   8 +
 drivers/net/ti/Makefile |   1 +
 drivers/net/ti/am65-cpsw-nuss.c | 834 
 3 files changed, 843 insertions(+)
 create mode 100644 drivers/net/ti/am65-cpsw-nuss.c

diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index 82bc9f5d03..ecf642de10 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -18,3 +18,11 @@ config DRIVER_TI_KEYSTONE_NET
bool "TI Keystone 2 Ethernet"
help
   This driver supports the TI Keystone 2 Ethernet subsystem
+
+config TI_AM65_CPSW_NUSS
+   bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
+   depends on ARCH_K3
+   select PHYLIB
+   help
+ This driver supports TI K3 MCU CPSW Nuss Ethernet controller
+ in Texas Instruments K3 AM65x SoCs.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index ee3e4eb5d6..8d3808bb4b 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
 obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
+obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
new file mode 100644
index 00..4793c99bd2
--- /dev/null
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -0,0 +1,834 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments K3 AM65 Ethernet Switch SubSystem Driver
+ *
+ * Copyright (C) 2019, Texas Instruments, Incorporated
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cpsw_mdio.h"
+
+#define AM65_CPSW_CPSWNU_MAX_PORTS 2
+
+#define AM65_CPSW_SS_BASE  0x0
+#define AM65_CPSW_SGMII_BASE   0x100
+#define AM65_CPSW_MDIO_BASE0xf00
+#define AM65_CPSW_XGMII_BASE   0x2100
+#define AM65_CPSW_CPSW_NU_BASE 0x2
+#define AM65_CPSW_CPSW_NU_ALE_BASE 0x1e000
+
+#define AM65_CPSW_CPSW_NU_PORTS_OFFSET 0x1000
+#define AM65_CPSW_CPSW_NU_PORT_MACSL_OFFSET0x330
+
+#define AM65_CPSW_MDIO_BUS_FREQ_DEF 100
+
+#define AM65_CPSW_CTL_REG  0x4
+#define AM65_CPSW_STAT_PORT_EN_REG 0x14
+#define AM65_CPSW_PTYPE_REG0x18
+
+#define AM65_CPSW_CTL_REG_P0_ENABLEBIT(2)
+#define AM65_CPSW_CTL_REG_P0_TX_CRC_REMOVE BIT(13)
+#define AM65_CPSW_CTL_REG_P0_RX_PADBIT(14)
+
+#define AM65_CPSW_P0_FLOW_ID_REG   0x8
+#define AM65_CPSW_PN_RX_MAXLEN_REG 0x24
+#define AM65_CPSW_PN_REG_SA_L  0x308
+#define AM65_CPSW_PN_REG_SA_H  0x30c
+
+#define AM65_CPSW_ALE_CTL_REG  0x8
+#define AM65_CPSW_ALE_CTL_REG_ENABLE   BIT(31)
+#define AM65_CPSW_ALE_CTL_REG_RESET_TBLBIT(30)
+#define AM65_CPSW_ALE_CTL_REG_BYPASS   BIT(4)
+#define AM65_CPSW_ALE_PN_CTL_REG(x)(0x40 + (x) * 4)
+#define AM65_CPSW_ALE_PN_CTL_REG_MODE_FORWARD  0x3
+#define AM65_CPSW_ALE_PN_CTL_REG_MAC_ONLY  BIT(11)
+
+#define AM65_CPSW_MACSL_CTL_REG0x0
+#define AM65_CPSW_MACSL_CTL_REG_IFCTL_ABIT(15)
+#define AM65_CPSW_MACSL_CTL_REG_GIGBIT(7)
+#define AM65_CPSW_MACSL_CTL_REG_GMII_ENBIT(5)
+#define AM65_CPSW_MACSL_CTL_REG_LOOPBACK   BIT(1)
+#define AM65_CPSW_MACSL_CTL_REG_FULL_DUPLEXBIT(0)
+#define AM65_CPSW_MACSL_RESET_REG  0x8
+#define AM65_CPSW_MACSL_RESET_REG_RESETBIT(0)
+#define AM65_CPSW_MACSL_STATUS_REG 0x4
+#define AM65_CPSW_MACSL_RESET_REG_PN_IDLE  BIT(31)
+#define AM65_CPSW_MACSL_RESET_REG_PN_E_IDLEBIT(30)
+#define AM65_CPSW_MACSL_RESET_REG_PN_P_IDLEBIT(29)
+#define AM65_CPSW_MACSL_RESET_REG_PN_TX_IDLE   BIT(28)
+#define AM65_CPSW_MACSL_RESET_REG_IDLE_MASK \
+   

[U-Boot] [PATCH 0/5] net: ethernet: ti: Introduce am654 gigabit eth switch subsystem driver

[Keerthy]

Add new driver for the TI AM65x SoC Gigabit Ethernet Switch subsystem (CPSW
NUSS). It has two ports and provides Ethernet packet communication for the
device and can be configured as an Ethernet switch. CPSW NUSS features: the
Reduced Gigabit Media Independent Interface (RGMII), Reduced Media
Independent Interface (RMII), and the Management Data Input/Output (MDIO)
interface for physical layer device (PHY) management. The TI AM65x SoC has
integrated two-port Gigabit Ethernet Switch subsystem into device MCU
domain named MCU_CPSW0. One Ethernet port (port 1) with selectable RGMII
and RMII interfaces and an internal Communications Port Programming
Interface (CPPI) port (Host port 0).

Host Port 0 CPPI Packet Streaming Interface interface supports 8 TX
channels and on RX channels operating by TI am654 NAVSS Unified DMA
Peripheral Root Complex (UDMA-P) controller. 

The series is based on top of Vignesh's v3:

https://patchwork.ozlabs.org/patch/1032504/

Tested for tftp and booting to kernel on am654-evm.

Grygorii Strashko (5):
  driver: net: ti: cpsw-mdio: use phys_addr_t for mdio_base addr
  net: ethernet: ti: Introduce am654 gigabit eth switch subsystem driver
  arm64: dts: ti: k3-am65: add mcu cpsw node
  arm64: dts: k3-am654-base-board: add mcu cpsw nuss pinmux and phy defs
  configs: am65x_evm_a53: enable networking

 arch/arm/dts/k3-am65.dtsi|   2 +
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 170 
 configs/am65x_evm_a53_defconfig  |   7 +
 drivers/net/ti/Kconfig   |   8 +
 drivers/net/ti/Makefile  |   1 +
 drivers/net/ti/am65-cpsw-nuss.c  | 834 +++
 drivers/net/ti/cpsw_mdio.c   |   2 +-
 drivers/net/ti/cpsw_mdio.h   |   2 +-
 8 files changed, 1024 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ti/am65-cpsw-nuss.c

-- 
2.17.1

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

[U-Boot] [PATCH 1/5] driver: net: ti: cpsw-mdio: use phys_addr_t for mdio_base addr

[Keerthy]

From: Grygorii Strashko 

Use phys_addr_t for mdio_base address to avoid build warnings on arm64.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 drivers/net/ti/cpsw_mdio.c | 2 +-
 drivers/net/ti/cpsw_mdio.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
index 70f547e6d7..86980612dd 100644
--- a/drivers/net/ti/cpsw_mdio.c
+++ b/drivers/net/ti/cpsw_mdio.c
@@ -125,7 +125,7 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
return val & GENMASK(15, 0);
 }
 
-struct mii_dev *cpsw_mdio_init(const char *name, u32 mdio_base,
+struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,
   u32 bus_freq, int fck_freq)
 {
struct cpsw_mdio *cpsw_mdio;
diff --git a/drivers/net/ti/cpsw_mdio.h b/drivers/net/ti/cpsw_mdio.h
index 4a76d4e5c5..dbf4a2dcac 100644
--- a/drivers/net/ti/cpsw_mdio.h
+++ b/drivers/net/ti/cpsw_mdio.h
@@ -10,7 +10,7 @@
 
 struct cpsw_mdio;
 
-struct mii_dev *cpsw_mdio_init(const char *name, u32 mdio_base,
+struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,
   u32 bus_freq, int fck_freq);
 void cpsw_mdio_free(struct mii_dev *bus);
 u32 cpsw_mdio_get_alive(struct mii_dev *bus);
-- 
2.17.1

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

Re: [U-Boot] [RFC 1/9] Arm: dts: imx7d-pico: Import Linux pico-pi dts

[Offouga Joris]

Hi Fabio

> Le 31 janv. 2019 à 02:16, Fabio Estevam  a écrit :
> 
> Hi Bryan and Joris,
> 
> On Wed, Jan 23, 2019 at 7:53 AM Bryan O'Donoghue
>  wrote:
> 
>> Hi Joris,
>> 
>> I've been told that this board exhibits this same problem even without
>> the DM conversion.
>> 
>> "PMIC:  PFUZE3000 DEV_ID=0x0 REV_ID=0xfffb
>> read error from device: 9df65458 register: 0x69!
>> write error to device: 9df65458 register: 0x23!
>> write error to device: 9df65458 register: 0x31!"
> 
> I cannot reproduce the error here on U-Boot master:
> 
> U-Boot SPL 2019.01-00410-g748ad078ee (Jan 30 2019 - 23:02:31 -0200)
> Trying to boot from MMC1
> 
> 
> U-Boot 2019.01-00410-g748ad078ee (Jan 30 2019 - 23:02:31 -0200)
> 
> CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 47C
> Reset cause: POR
> Board: i.MX7D PICOSOM
> I2C:   ready
> DRAM:  512 MiB
> PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 0
> Loading Environment from MMC... OK
> Video: 800x480x24
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC0
> Hit any key to stop autoboot:  0
> 
> Are you sure the PMIC problem happens prior to the DM conversion?
The PMIC problem occurs after the dm conversion 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] cros: Expand the Chromium OS documentation

[Simon Glass]

The current documentation only covers how to chain-load U-Boot on a
Chromebook. Add more information about the other ways to use U-Boot on
Chromebooks.

In particular it is again possible to build it with Chromium OS
verified boot.

Signed-off-by: Simon Glass 
---

 doc/README.chromium   | 296 ++
 doc/README.chromium-chainload | 239 +++
 2 files changed, 356 insertions(+), 179 deletions(-)
 create mode 100644 doc/README.chromium-chainload

diff --git a/doc/README.chromium b/doc/README.chromium
index 45eaeced2d..096bc4f1f7 100644
--- a/doc/README.chromium
+++ b/doc/README.chromium
@@ -1,239 +1,177 @@
-Running U-Boot from coreboot on Chromebooks
-===
+Chromium OS Support in U-Boot
+=
 
-U-Boot can be used as a secondary boot loader in a few situations such as from
-UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on
-ARM platforms to start up the machine.
+Introduction
+
 
-This document aims to provide a guide to booting U-Boot on a Chromebook. It
-is only a starting point, and there are many guides on the interwebs. But
-placing this information in the U-Boot tree should make it easier to find for
-those who use U-Boot habitually.
+This describes how to use U-Boot with Chromium OS. Several options are
+available:
 
-Most of these platforms are supported by U-Boot natively, but it is risky to
-replace the ROM unless you have a servo board and cable to restore it with.
+   - Running U-Boot from the 'altfw' feature, which is available on selected
+Chromebooks from 2019 onwards (initially Grunt). Press '1' from the
+developer-mode screen to get into U-Boot. See here for details:
+
https://sites.google.com/a/chromium.org/dev/chromium-os/poking-around-your-chrome-os-device?pli=1
 
+   - Running U-Boot from the disk partition. This involves signing U-Boot and
+placing it on the disk, for booting as a 'kernel'. See
+README.chromium-chainload for information on this. This is the only
+option on non-U-Boot Chromebooks from 2013 to 2018 and is somewhat
+more involved.
 
-For all of these the standard U-Boot build instructions apply. For example on
-ARM:
+   - Running U-Boot with Chromium OS verified boot. This allows U-Boot to be
+used instead of either or both of depthcharge (a bootloader which 
forked
+from U-Boot in 2013) and coreboot. See below for more information on
+this.
 
-   sudo apt install gcc-arm-linux-gnueabi
-   mkdir b
-   make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all
 
-You can obtain the vbutil_kernel utility here:
+U-Boot with Chromium OS verified boot
+-
 
-   https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U
+To obtain:
 
+   git clone https://github.com/sglass68/u-boot.git
+   cd u-boot
+   git checkout cros-master
 
-Snow (Samsung ARM Chromebook)
--
+To build for sandbox:
 
-See here:
+   UB=/tmp/b/chromeos_sandbox# U-Boot build directory
+   CROS=/home/sglass/cosarm  # Chromium OS directory
+   make O=$UB/chromeos_sandbox_defconfig
+   make O=$UB -j20 -s VBOOT_SOURCE=$CROS/src/platform/vboot_reference \
+   MAKEFLAGS_VBOOT=DEBUG=1 QUIET=1
 
-https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook
+Replace sandbox with another supported target.
 
+This produces $UB/image.bin which contains the firmware binaries in a SPI
+flash image.
 
-Nyan-big
-
-
-Compiled based on information here:
-https://lists.denx.de/pipermail/u-boot/2015-March/209530.html
-https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big
-https://lists.denx.de/pipermail/u-boot/2017-May/289491.html
-https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card
-
-1. Build U-Boot
-
-   mkdir b
-   make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig 
all
-
-
-2. Select a .its file
-
-Select something from doc/chromium which matches your board, or create your
-own.
-
-Note that the device tree node is required, even though it is not actually
-used by U-Boot. This is because the Chromebook expects to pass it to the
-kernel, and crashes if it is not present.
-
-
-3. Build and sign an image
-
-   ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit
-   echo test >dummy.txt
-   vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \
-   --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \
-   --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \
-   --bootloader dummy.txt --pack u-boot.kpart
-
-
-4. Prepare an SD card
-
-   DISK=/dev/sdc   # Replace with your actual SD card device
-   sudo cgpt create $DISK
-   sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK
-   sudo 

Re: [U-Boot] [PATCH v2 02/10] spl: misc: Allow misc drivers in SPL and TPL

[Simon Glass]

Hi Jean-Jacques,

On Tue, 20 Nov 2018 at 06:49, Jean-Jacques Hiblot  wrote:
>
> Hi Simon,
>
> On 18/11/2018 16:14, Simon Glass wrote:
> > In some cases it is necessary to read the keyboard in early phases of
> > U-Boot. The cros_ec keyboard is kept in the misc directory. Update the
> > config to allow this.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Leave the misc uclass alone since it stops sandbox_spl working
> >
> >   drivers/misc/Kconfig  | 72 +++
> >   drivers/misc/Makefile |  8 +++--
> >   2 files changed, 77 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 48febc47d26..802046cf966 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -13,6 +13,24 @@ config MISC
> > set of generic read, write and ioctl methods may be used to
> > access the device.
> >
> > +config SPL_MISC
> > + bool "Enable Driver Model for Misc drivers in SPL"
> > + depends on SPL_DM
> > + help
> > +   Enable driver model for miscellaneous devices. This class is
> > +   used only for those do not fit other more general classes. A
> > +   set of generic read, write and ioctl methods may be used to
> > +   access the device.
>
> Platforms currently use CONFIG_SPL_DRIVERS_MISC_SUPPORT and CONFIG_MISC
> to enable the MISC drivers in the SPL.

This is a bit confusing but that is not my understanding of the situation.

CONFIG_MISC enables UCLASS_MISC devices. The 'misc' drivers directory
is included always in U-Boot proper. Yes the
CONFIG_SPL_DRIVERS_MISC_SUPPORT option is for SPL only.

But in my case I want an option to enable driver-model MISC devices in
SPL/TPL. Oddly this is orthogonal to whether the drivers/misc
directory itself is included in the build.

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

Re: [U-Boot] dfu: mmc: call fs functions instead of run_command

[Tom Rini]

On Fri, Jan 25, 2019 at 07:58:01PM +0100, Simon Goldschmidt wrote:

> This unbreaks dfu mmc_file_op which is currently broken since using the
> load cmd on a buffer from heap is not allowed - added with
> commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> 
> Fixes: commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> Reported-by: Stephen Warren 
> Signed-off-by: Simon Goldschmidt 
> Tested-by: Stephen Warren 
> Acked-by: Lukasz Majewski 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Makefile: remove generated font files

[Tom Rini]

On Tue, Jan 29, 2019 at 09:15:21PM +0100, Heinrich Schuchardt wrote:

> If `make mrproper` does not delete the generated drivers/video/fonts/*.S
> files a following `make tests` fails.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Anatolij Gustschin 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,u-boot] MAINTAINERS: Add Amlogic entry

[Tom Rini]

On Wed, Jan 30, 2019 at 10:53:10AM +0100, Neil Armstrong wrote:

> Add entry for Amlogic SoC maintained files and the freshly
> created mailing-list.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Wed, Jan 30, 2019 at 09:56:22PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> We are 2 days late to send this DM_MMC changes, hope you understand
> and apply this PR asap.

That's OK, I'm 2 days late on -rc1 so far.  Can I assume a SPI PR is
coming my way soon as well?

> 
> thanks,
> Jagan.
> 
> The following changes since commit 2f41ade79e5969ebea03a7dcadbeae8e03787d7e:
> 
>   linker: Modify linker scripts to be more generic (2019-01-26 22:55:53 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to a7cca5793774ee139b75a704d6efaa4d29f09f93:
> 
>   arm: sunxi: Enable DM_MMC (2019-01-30 18:22:18 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] U-Boot and USB 3.0

[DJM-Avalesta]

Hi Bin 

Further to previous, I have built the latest u-boot source from
git.denx.de but, when I flash this version, it fails to boot the kernel.
Here are the debug traces. 

The working u-Boot:- 

U-Boot 2019.01-dirty (Jan 29 2019 - 08:17:16 -0800)

TEGRA186
Model: NVIDIA P2771--500
DRAM:  7.8 GiB
MC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@249
Hit any key to stop autoboot:  0
Tegra186 (P2771--500) # boot
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
213 bytes read in 90 ms (2 KiB/s)
p2771- eMMC boot options
1:  primary kernel
Enter choice: 1:primary kernel
Retrieving file: /boot/Image
20727600 bytes read in 546 ms (36.2 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8
console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb
no_console_suspend=1 earlycon=uart8250,mmio32,0x0310
nvdumper_reserved=0x2772e gpt tegra_fbmem2=0x14@0x969ee000
lut_mem2=0x2008@0x969eb000 tegraid=18.1.2.0.0 tegra_keep_boot_clocks
maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2.1
androidboot.serialno=0422518026482 bl_prof_dataptr=0x1@0x27704
sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait
rootfstype=ext4
## Flattened Device Tree blob at 9200
   Booting using the fdt blob at 0x9200
   reserving fdt memory region: addr=8000 size=1
   Using Device Tree in place at 9200, end 92049273

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x100
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.38-tegra (buildbrain@mobile-u64-773)
(gcc version 4.8.5 (GCC) ) #1 SMP PREEMPT Thu May 17 00:15:19 PDT 2018

and the non-working u-boot:- 

U-Boot 2019.01 (Jan 30 2019 - 17:38:42 +)

TEGRA186
Model: NVIDIA P2771--500
DRAM:  7.8 GiB
MMC:   sdhci@340: 1, sdhci@346: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@249
Hit any key to stop autoboot:  0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
213 bytes read in 2 ms (103.5 KiB/s)
p2771- eMMC boot options
1:  primary kernel
Enter choice: 1:primary kernel
Retrieving file: /boot/Image
20727600 bytes read in 509 ms (38.8 MiB/s)
append:  root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
## Flattened Device Tree blob at 9200
   Booting using the fdt blob at 0x9200
   Using Device Tree in place at 9200, end 92049273

Starting kernel ... 

Any ideas? 

- David 

On 2019-01-29 13:46, DJM-Avalesta wrote:

> Hi Bin. 
> 
> I am trying to build and load u-boot at the moment (just the same version as 
> I already have) but I keep breaking the system. When I can build and 
> overwrite u-boot, I will try a more recent version of the u-boot source, but 
> I worry that there may be NVidia-Jetson-specific code in the current version 
> of u-boot.
> 
> Many thanks 
> David 
> 
> On 2019-01-29 02:49, Bin Meng wrote: 
> Hi,
> 
> On Tue, Jan 29, 2019 at 1:32 AM DJM-Avalesta  
> wrote: 
> Dear Bin Meng,
> 
> I have a version of U-Boot, on my Jetson TX2 hardware, which does not support 
> USB 3.0.
> 
> U-Boot 2016.07-g9c3b9a4
> 
> (May 17 2018 - 00:08:48 -0700)
> 
> Can you please use latest U-Boot instead? That will be much easier.
> 
> Is it possible to apply one or more of your patches to this version to 
> implement support for USB 3.0?
> 
> Technically it's doable.
> 
> Many thanks for your help.
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset

[Simon Glass]

Hi,

On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt  wrote:
>
> On 1/30/19 11:46 AM, Alexander Graf wrote:
> > Our selftest will soon test the actual runtime reset function rather than
> > the boot time one. For this, we need to ensure that the runtime version
> > actually succeeds on x86 to keep our travis tests work.
> >
> > So this patch implements an x86 runtime reset function. It is missing
> > shutdown functionality today, but OSs usually implement that via ACPI
> > and this function does more than the stub from before, so it's at least
> > an improvement.
> >
> > Eventually we will want to have full DM functionality in runtime services.
> > But this fixes a travis failure and doesn't clutter the code too heavily, so
> > we should pull it in without the amazing new RTS DM framework.
> >
> > Signed-off-by: Alexander Graf 
> >
> > ---
> >
> > v2 -> v3:
> >
> >   - support EFI_RESET_PLATFORM_SPECIFIC
> >   - reuse existing x86_sysreset_request() function
>
> The v2->v3 update does not answer the question if the reset is correctly
> implemented. We would not want to call a function we do not trust.
>
> @Simon, Bin:
> x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in
> native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
> which is tried before using the keyboard controller as last resort.
>
> u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
> u8 cf9 = inb(0xcf9) & ~reboot_code;
> outb(cf9|2, 0xcf9); /* Request hard reset */
> udelay(50);
> /* Actually do the reset */
> outb(cf9|reboot_code, 0xcf9);
> udelay(50);
>
> So the Kernel first switches bit 2 off and bit 1 on, waits, and then
> switches bit 2 on, cf.
> http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html
>
> Shouldn't we do it the same way as the Kernel does it?

I suspect so, but Bin is the expert.

As to this patch, it perpetuates the current EFI run-time approach in
U-Boot so I'm not sure this is the right path.

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

Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

[Simon Glass]

Hi AKASHI,

On Mon, 28 Jan 2019 at 19:59, AKASHI Takahiro
 wrote:
>
> efi_disk_create() will initialize efi_disk attributes for each device,
> either UCLASS_BLK or UCLASS_PARTITION.
>
> Currently (temporarily), efi_disk_obj structure is embedded into
> blk_desc to hold efi-specific attributes.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  drivers/block/blk-uclass.c |   9 ++
>  drivers/core/device.c  |   3 +
>  include/blk.h  |  24 +
>  include/dm/device.h|   4 +
>  lib/efi_loader/efi_disk.c  | 192 ++---
>  5 files changed, 174 insertions(+), 58 deletions(-)
>

I think the objective should be to drop the EFI data structures.

So your approach of just including them in DM structures seems about
right to me, as a short-term migration measure. Given the large amount
of code that has built up I don't think it is possible to do it any
other way.

It is very unfortunate though.

So basically migration could be something like this:

1. Move each of the EFI structs into the DM structs one by one
2. Drop struct members that are not needed and can be calculated from DM members
3. Update DM to have 1:1 uclasses for each EFI protocol
4. Move all the protocol structs into the DM uclasses
5. Whittle these down until they are just shells used by the API, with
everything going through normal DM calls

Or would it be better to just start again and rewrite it with the
existing code as a base?

Looking at it, efi_object is not very useful in DM. It contains two members:

1. link - linked list link, which devices already have, although we
don't have a single list of all them. Instead they are linked into
separate lists for each uclass

2. protocols - list of protocols. But DM devices support only one
protocol. Multiple protocols are handled using child devices. E.g a
UCLASS_PMIC device that supports UCLASS_GPIO, UCLASS_REGULATOR and
UCLASS_AUDIO_CODEC would have three children, one for each uclass. So
perhaps with EFI we should create a separate child for each protocol
in a similar way?

Which comes back to the idea of creating an EFI child device for every
DM device. Perhaps instead we create one EFI child for each protocol
supported by the parent device?

Another point is that the operations supported by EFI should be in DM
operations structs. For example I think struct
efi_simple_text_output_protocol should have methods which call into
the corresponding uclass operations.

It is confusing that an EFI disk is in fact a partition. Or do I have
that wrong?

Anyway that's all the thoughts I have at present. Thanks for your
efforts on this.

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

Re: [U-Boot] [RFC 1/9] Arm: dts: imx7d-pico: Import Linux pico-pi dts

[Fabio Estevam]

Hi Bryan and Joris,

On Wed, Jan 23, 2019 at 7:53 AM Bryan O'Donoghue
 wrote:

> Hi Joris,
>
> I've been told that this board exhibits this same problem even without
> the DM conversion.
>
> "PMIC:  PFUZE3000 DEV_ID=0x0 REV_ID=0xfffb
> read error from device: 9df65458 register: 0x69!
> write error to device: 9df65458 register: 0x23!
> write error to device: 9df65458 register: 0x31!"

I cannot reproduce the error here on U-Boot master:

U-Boot SPL 2019.01-00410-g748ad078ee (Jan 30 2019 - 23:02:31 -0200)
Trying to boot from MMC1


U-Boot 2019.01-00410-g748ad078ee (Jan 30 2019 - 23:02:31 -0200)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 47C
Reset cause: POR
Board: i.MX7D PICOSOM
I2C:   ready
DRAM:  512 MiB
PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 0
Loading Environment from MMC... OK
Video: 800x480x24
In:serial
Out:   serial
Err:   serial
Net:   FEC0
Hit any key to stop autoboot:  0

Are you sure the PMIC problem happens prior to the DM conversion?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION

[Simon Glass]

Hi Takahiro,

On Mon, 28 Jan 2019 at 19:59, AKASHI Takahiro
 wrote:
>
> UCLASS_PARTITION device will be created as a child node of
> UCLASS_BLK device.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  drivers/block/blk-uclass.c | 52 ++
>  include/dm/uclass-id.h |  1 +
>  2 files changed, 53 insertions(+)
>
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index baaf431e5e0c..d4ca30f23fc1 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  static const char *if_typename_str[IF_TYPE_COUNT] = {
> [IF_TYPE_IDE]   = "ide",
> @@ -654,3 +656,53 @@ UCLASS_DRIVER(blk) = {
> .post_probe = blk_post_probe,
> .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
>  };
> +
> +U_BOOT_DRIVER(blk_partition) = {
> +   .name   = "blk_partition",
> +   .id = UCLASS_PARTITION,
> +   .platdata_auto_alloc_size = sizeof(struct disk_part),
> +};
> +
> +UCLASS_DRIVER(partition) = {
> +   .id = UCLASS_PARTITION,
> +   .name   = "partition",
> +};
> +
> +#if defined(CONFIG_PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
> +int blk_create_partitions(struct udevice *parent)
> +{
> +   int part;
> +   struct blk_desc *desc = dev_get_uclass_platdata(parent);
> +   disk_partition_t info;
> +   struct disk_part *part_data;
> +   char devname[32];
> +   struct udevice *dev;
> +   int disks = 0, ret;
> +
> +   /* Add devices for each partition */
> +   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> +   if (part_get_info(desc, part, ))
> +   continue;
> +   snprintf(devname, sizeof(devname), "%s:%d", parent->name,
> +part);
> +
> +   ret = device_bind_driver(parent, "blk_partition",
> +strdup(devname), );
> +   if (ret)
> +   return ret;
> +
> +   part_data = dev_get_uclass_platdata(dev);
> +   part_data->partnum = part;
> +   part_data->gpt_part_info = info;
> +
> +   disks++;
> +   }
> +
> +   return disks;
> +}
> +#else
> +int blk_create_partitions(struct udevice *dev)
> +{
> +   return 0;
> +}
> +#endif
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index f3bafb3c6353..e02b5f8fda42 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -65,6 +65,7 @@ enum uclass_id {
> UCLASS_NVME,/* NVM Express device */
> UCLASS_PANEL,   /* Display panel, such as an LCD */
> UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */
> +   UCLASS_PARTITION,   /* Logical disk partition device */
> UCLASS_PCH, /* x86 platform controller hub */
> UCLASS_PCI, /* PCI bus */
> UCLASS_PCI_GENERIC, /* Generic PCI bus device */
> --
> 2.19.1
>

This looks OK to me. It does need a test in test/dm/partition.c for
the new uclass.

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

Re: [U-Boot] [PATCH v3 02/20] bitops: Fix GENMASK definition for Sandbox

[Simon Glass]

On Mon, 28 Jan 2019 at 22:49, Vignesh R  wrote:
>
> In arch/sandbox/include/asm/types.h we have
> Therefore for 32 bit Sandbox build BITS_PER_LONG turns out to be 32 as
> CONFIG_PHYS64 is not set
>
> This messes up the current logic of GENMASK macro due to mismatch b/w
> size of unsigned long (64 bit) and that of BITS_PER_LONG.
> Fix this by using CONFIG_SANDBOX_BITS_PER_LONG which is set to 64/32
> based on the host machine on which its being compiled.
>
> Without this patch:
> GENMASK(14,0) => 0x7fff
> After this patch:
> GENMASK(14,0) => 0x7fff
>
> Signed-off-by: Vignesh R 
> ---
>  include/linux/bitops.h | 5 +
>  1 file changed, 5 insertions(+)

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

[U-Boot] [PATCH v2] rpi: add Compute Module 3+

[Jonathan Gray]

Add Raspberry Pi Compute Module 3+ to list of models, the revision code
is 0x10 according to the list on raspberrypi.org.

v2: Use the same dtb name as CM3 as CM3+ is a drop in replacement
for CM3.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..617c892dde 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
false,
},
+   [0x10] = {
+   "Compute Module 3+",
+   DTB_DIR "bcm2837-rpi-cm3.dtb",
+   false,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.20.1

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

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

On Wed, Jan 30, 2019 at 10:56:37PM +0100, Alexander Graf wrote:
> 
> 
> > Am 30.01.2019 um 22:38 schrieb Jonathan Gray :
> > 
> >> On Wed, Jan 30, 2019 at 04:13:44PM +0100, Alexander Graf wrote:
> >> Hi Jonathan,
> >> 
> >>> On 30.01.19 15:17, Jonathan Gray wrote:
> >>> Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> >>> is 0x10 according to the list on raspberrypi.org.
> >>> 
> >>> Signed-off-by: Jonathan Gray 
> >>> ---
> >>> board/raspberrypi/rpi/rpi.c | 5 +
> >>> 1 file changed, 5 insertions(+)
> >>> 
> >>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> >>> index 153a1fdcb7..c118250740 100644
> >>> --- a/board/raspberrypi/rpi/rpi.c
> >>> +++ b/board/raspberrypi/rpi/rpi.c
> >>> @@ -143,6 +143,11 @@ static const struct rpi_model 
> >>> rpi_models_new_scheme[] = {
> >>>DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
> >>>false,
> >>>},
> >>> +[0x10] = {
> >>> +"Compute Module 3+",
> >>> +DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
> >> 
> >> Is the dtb name already committed to? I haven't seen patches on the rpi
> >> kernel ML.
> > 
> > I didn't see an existing name in various linux trees.
> > 
> > There is currently no new dtb provided with the firmware either, though
> > https://raw.githubusercontent.com/raspberrypi/documentation/master/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf
> > states
> > 
> > "CM3+ modules require a software/firmware image dated November 2018 or
> > newer to function correctly."
> > 
> > So the firmware likely patches bcm2710-rpi-cm3.dtb before passing it on.
> 
> Or maybe it's identical to the CM3? It's supposed to be a drop in replacement 
> after all - and the other differences (wifi chip, usb hub) of the 3+ should 
> not apply to a CM.
> 
> So I guess either you send a patch to Linux that adds the cm3plus and only 
> changes the compatible/model properties over cm3 or we make the dtb name in 
> this patch the cm3 one.
> 
> Alex

Ok, I'll send a v2 with "bcm2837-rpi-cm3.dtb".
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Alexander Graf]

> Am 30.01.2019 um 22:38 schrieb Jonathan Gray :
> 
>> On Wed, Jan 30, 2019 at 04:13:44PM +0100, Alexander Graf wrote:
>> Hi Jonathan,
>> 
>>> On 30.01.19 15:17, Jonathan Gray wrote:
>>> Add Raspberry Pi Compute Module 3+ to list of models, the revision code
>>> is 0x10 according to the list on raspberrypi.org.
>>> 
>>> Signed-off-by: Jonathan Gray 
>>> ---
>>> board/raspberrypi/rpi/rpi.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>> 
>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>> index 153a1fdcb7..c118250740 100644
>>> --- a/board/raspberrypi/rpi/rpi.c
>>> +++ b/board/raspberrypi/rpi/rpi.c
>>> @@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] 
>>> = {
>>>DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
>>>false,
>>>},
>>> +[0x10] = {
>>> +"Compute Module 3+",
>>> +DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
>> 
>> Is the dtb name already committed to? I haven't seen patches on the rpi
>> kernel ML.
> 
> I didn't see an existing name in various linux trees.
> 
> There is currently no new dtb provided with the firmware either, though
> https://raw.githubusercontent.com/raspberrypi/documentation/master/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf
> states
> 
> "CM3+ modules require a software/firmware image dated November 2018 or
> newer to function correctly."
> 
> So the firmware likely patches bcm2710-rpi-cm3.dtb before passing it on.

Or maybe it's identical to the CM3? It's supposed to be a drop in replacement 
after all - and the other differences (wifi chip, usb hub) of the 3+ should not 
apply to a CM.

So I guess either you send a patch to Linux that adds the cm3plus and only 
changes the compatible/model properties over cm3 or we make the dtb name in 
this patch the cm3 one.

Alex


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

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

On Wed, Jan 30, 2019 at 04:13:44PM +0100, Alexander Graf wrote:
> Hi Jonathan,
> 
> On 30.01.19 15:17, Jonathan Gray wrote:
> > Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> > is 0x10 according to the list on raspberrypi.org.
> > 
> > Signed-off-by: Jonathan Gray 
> > ---
> >  board/raspberrypi/rpi/rpi.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > index 153a1fdcb7..c118250740 100644
> > --- a/board/raspberrypi/rpi/rpi.c
> > +++ b/board/raspberrypi/rpi/rpi.c
> > @@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] 
> > = {
> > DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
> > false,
> > },
> > +   [0x10] = {
> > +   "Compute Module 3+",
> > +   DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
> 
> Is the dtb name already committed to? I haven't seen patches on the rpi
> kernel ML.

I didn't see an existing name in various linux trees.

There is currently no new dtb provided with the firmware either, though
https://raw.githubusercontent.com/raspberrypi/documentation/master/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf
states

"CM3+ modules require a software/firmware image dated November 2018 or
newer to function correctly."

So the firmware likely patches bcm2710-rpi-cm3.dtb before passing it on.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dfu: mmc: call fs functions instead of run_command

[Lukasz Majewski]

Hi Stephen, Tom,

> On 1/25/19 11:58 AM, Simon Goldschmidt wrote:
> > This unbreaks dfu mmc_file_op which is currently broken since using
> > the load cmd on a buffer from heap is not allowed - added with
> > commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> > 
> > Fixes: commit aa3c609e2be5 ("fs: prevent overwriting reserved
> > memory") Reported-by: Stephen Warren 
> > Signed-off-by: Simon Goldschmidt 
> > Tested-by: Stephen Warren   
> 
> Any chance we could get this applied (directly to u-boot/master) to
> fix the rampant test failures? Thanks.

Tom, I've acked this patch (in other mail). Please feel free to apply
it to -master branch.

Thanks for fixing it :-) (the code was really old and I'm glad that it
was updated to fs_* functions).

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


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

Re: [U-Boot] [PATCH] dfu: mmc: call fs functions instead of run_command

[Lukasz Majewski]

Hi,

> This unbreaks dfu mmc_file_op which is currently broken since using
> the load cmd on a buffer from heap is not allowed - added with
> commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> 
> Fixes: commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
> Reported-by: Stephen Warren 
> Signed-off-by: Simon Goldschmidt 
> Tested-by: Stephen Warren 
> ---

Acked-by: Lukasz Majewski 

> 
> Changes since RFC:
> - decreased size of 'dev_part_str' to hold 'xxx:yyy' string
> - removed now unused define 'DFU_CMD_BUF_SIZE'
> 
> ---
>  drivers/dfu/dfu_mmc.c | 67
> --- include/dfu.h |
> 1 - 2 files changed, 31 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
> index b45e6dc54c..403fd5351d 100644
> --- a/drivers/dfu/dfu_mmc.c
> +++ b/drivers/dfu/dfu_mmc.c
> @@ -108,17 +108,17 @@ static int mmc_file_buffer(struct dfu_entity
> *dfu, void *buf, long *len) static int mmc_file_op(enum dfu_op op,
> struct dfu_entity *dfu, void *buf, u64 *len)
>  {
> - const char *fsname, *opname;
> - char cmd_buf[DFU_CMD_BUF_SIZE];
> - char *str_env;
> + char dev_part_str[8];
>   int ret;
> + int fstype;
> + loff_t size = 0;
>  
>   switch (dfu->layout) {
>   case DFU_FS_FAT:
> - fsname = "fat";
> + fstype = FS_TYPE_FAT;
>   break;
>   case DFU_FS_EXT4:
> - fsname = "ext4";
> + fstype = FS_TYPE_EXT;
>   break;
>   default:
>   printf("%s: Layout (%s) not (yet) supported!\n",
> __func__, @@ -126,48 +126,43 @@ static int mmc_file_op(enum dfu_op
> op, struct dfu_entity *dfu, return -1;
>   }
>  
> + snprintf(dev_part_str, sizeof(dev_part_str), "%d:%d",
> +  dfu->data.mmc.dev, dfu->data.mmc.part);
> +
> + ret = fs_set_blk_dev("mmc", dev_part_str, fstype);
> + if (ret) {
> + puts("dfu: fs_set_blk_dev error!\n");
> + return ret;
> + }
> +
>   switch (op) {
>   case DFU_OP_READ:
> - opname = "load";
> + ret = fs_read(dfu->name, (size_t)buf, 0, 0, );
> + if (ret) {
> + puts("dfu: fs_read error!\n");
> + return ret;
> + }
> + *len = size;
>   break;
>   case DFU_OP_WRITE:
> - opname = "write";
> + ret = fs_write(dfu->name, (size_t)buf, 0, *len,
> );
> + if (ret) {
> + puts("dfu: fs_write error!\n");
> + return ret;
> + }
>   break;
>   case DFU_OP_SIZE:
> - opname = "size";
> + ret = fs_size(dfu->name, );
> + if (ret) {
> + puts("dfu: fs_size error!\n");
> + return ret;
> + }
> + *len = size;
>   break;
>   default:
>   return -1;
>   }
>  
> - sprintf(cmd_buf, "%s%s mmc %d:%d", fsname, opname,
> - dfu->data.mmc.dev, dfu->data.mmc.part);
> -
> - if (op != DFU_OP_SIZE)
> - sprintf(cmd_buf + strlen(cmd_buf), " %p", buf);
> -
> - sprintf(cmd_buf + strlen(cmd_buf), " %s", dfu->name);
> -
> - if (op == DFU_OP_WRITE)
> - sprintf(cmd_buf + strlen(cmd_buf), " %llx", *len);
> -
> - debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf);
> -
> - ret = run_command(cmd_buf, 0);
> - if (ret) {
> - puts("dfu: Read error!\n");
> - return ret;
> - }
> -
> - if (op != DFU_OP_WRITE) {
> - str_env = env_get("filesize");
> - if (str_env == NULL) {
> - puts("dfu: Wrong file size!\n");
> - return -1;
> - }
> - *len = simple_strtoul(str_env, NULL, 16);
> - }
> -
>   return ret;
>  }
>  
> diff --git a/include/dfu.h b/include/dfu.h
> index fbe978abdc..c671d8b04d 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -80,7 +80,6 @@ struct sf_internal_data {
>  };
>  
>  #define DFU_NAME_SIZE32
> -#define DFU_CMD_BUF_SIZE 128
>  #ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
>  #define CONFIG_SYS_DFU_DATA_BUF_SIZE
> (1024*1024*8) /* 8 MiB */ #endif




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


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

[U-Boot] [PATCH v2 1/1] configs: qemu: enable CONFIG_UT

[Heinrich Schuchardt]

Some library functions are implemented in a architecture dependent way,
e.g. the memory functions memset(), memcopy(), memmove.

So let's enable unit tests for QEMU targets. Later we should ensure they
are actually called on Travis CI.

Signed-off-by: Heinrich Schuchardt 
---
v2
use the correct CONFIG option
---
 configs/qemu-ppce500_defconfig   | 1 +
 configs/qemu-riscv32_defconfig   | 1 +
 configs/qemu-riscv32_smode_defconfig | 1 +
 configs/qemu-riscv64_defconfig   | 1 +
 configs/qemu-riscv64_smode_defconfig | 1 +
 configs/qemu-x86_64_defconfig| 1 +
 configs/qemu-x86_defconfig   | 1 +
 configs/qemu_arm64_defconfig | 1 +
 configs/qemu_arm_defconfig   | 1 +
 configs/qemu_mips64_defconfig| 1 +
 configs/qemu_mips64el_defconfig  | 1 +
 configs/qemu_mips_defconfig  | 1 +
 configs/qemu_mipsel_defconfig| 1 +
 13 files changed, 13 insertions(+)

diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index fd276f2d04..40629a2a5d 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -28,3 +28,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_PANIC_HANG=y
 CONFIG_OF_LIBFDT=y
+CONFIG_UT=y
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index 6334d8c0fc..ce247bd44a 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -7,3 +7,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT=y
diff --git a/configs/qemu-riscv32_smode_defconfig 
b/configs/qemu-riscv32_smode_defconfig
index 0a84ec1874..fb581504ea 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 2d9ead93a2..ee0b7e9c23 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT=y
diff --git a/configs/qemu-riscv64_smode_defconfig 
b/configs/qemu-riscv64_smode_defconfig
index b012443370..3b255afaa7 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT=y
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 8d43acd480..0ecfa3129f 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -72,3 +72,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
 CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_UT=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 12ea72f562..e58d48575f 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -51,3 +51,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
 CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_UT=y
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index f2e759cee9..74fa6bfc65 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -35,3 +35,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+CONFIG_UT=y
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 27c427dd82..0843c57690 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -36,3 +36,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+CONFIG_UT=y
diff --git a/configs/qemu_mips64_defconfig b/configs/qemu_mips64_defconfig
index aff109512e..c305d43b7b 100644
--- a/configs/qemu_mips64_defconfig
+++ b/configs/qemu_mips64_defconfig
@@ -23,3 +23,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT=y
diff --git a/configs/qemu_mips64el_defconfig b/configs/qemu_mips64el_defconfig
index 63cbd44c0d..59729e7719 100644
--- a/configs/qemu_mips64el_defconfig
+++ b/configs/qemu_mips64el_defconfig
@@ -24,3 +24,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT=y
diff --git a/configs/qemu_mips_defconfig b/configs/qemu_mips_defconfig
index 37bf69f9e8..92007e9fe5 100644
--- a/configs/qemu_mips_defconfig
+++ b/configs/qemu_mips_defconfig
@@ -21,3 +21,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT=y
diff --git a/configs/qemu_mipsel_defconfig b/configs/qemu_mipsel_defconfig
index 82091b97df..96532058de 100644
--- a/configs/qemu_mipsel_defconfig
+++ b/configs/qemu_mipsel_defconfig
@@ -22,3 +22,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 

[U-Boot] [PATCH] fs: ext4: cache extent data

[Stephen Warren]

From: Stephen Warren 

When a file contains extents, U-Boot currently reads extent-related data
for each block in the file, even if that data is located in the same
block each time. This significantly slows down loading of files that use
extents. Implement a very dumb cache to prevent repeatedly reading the
same block. Files with extents now load as fast as files without.

Note: There are many cases where read_allocated_block() is called. This
patch only addresses one of those places; all others still read redundant
data in any case they did before. This is a minimal patch to fix the
load command; other cases aren't fixed.

Signed-off-by: Stephen Warren 
---
 fs/ext4/ext4_common.c  | 45 ++---
 fs/ext4/ext4_journal.c | 22 +-
 fs/ext4/ext4_write.c   |  6 ++---
 fs/ext4/ext4fs.c   | 51 +-
 include/ext4fs.h   | 12 +-
 5 files changed, 99 insertions(+), 37 deletions(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 67e2471bd388..29308e3b4474 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -510,7 +510,8 @@ restart:
 
 restart_read:
/* read the block no allocated to a file */
-   first_block_no_of_root = read_allocated_block(g_parent_inode, blk_idx);
+   first_block_no_of_root = read_allocated_block(g_parent_inode, blk_idx,
+ NULL);
if (first_block_no_of_root <= 0)
goto fail;
 
@@ -646,7 +647,7 @@ static int search_dir(struct ext2_inode *parent_inode, char 
*dirname)
 
/* get the block no allocated to a file */
for (blk_idx = 0; blk_idx < directory_blocks; blk_idx++) {
-   blknr = read_allocated_block(parent_inode, blk_idx);
+   blknr = read_allocated_block(parent_inode, blk_idx, NULL);
if (blknr <= 0)
goto fail;
 
@@ -943,7 +944,7 @@ int ext4fs_filename_unlink(char *filename)
 
/* read the block no allocated to a file */
for (blk_idx = 0; blk_idx < directory_blocks; blk_idx++) {
-   blknr = read_allocated_block(g_parent_inode, blk_idx);
+   blknr = read_allocated_block(g_parent_inode, blk_idx, NULL);
if (blknr <= 0)
break;
inodeno = unlink_filename(filename, blknr);
@@ -1522,7 +1523,7 @@ void ext4fs_allocate_blocks(struct ext2_inode *file_inode,
 #endif
 
 static struct ext4_extent_header *ext4fs_get_extent_block
-   (struct ext2_data *data, char *buf,
+   (struct ext2_data *data, struct ext_block_cache *cache,
struct ext4_extent_header *ext_block,
uint32_t fileblock, int log2_blksz)
 {
@@ -1551,12 +1552,10 @@ static struct ext4_extent_header 
*ext4fs_get_extent_block
 
block = le16_to_cpu(index[i].ei_leaf_hi);
block = (block << 32) + le32_to_cpu(index[i].ei_leaf_lo);
-
-   if (ext4fs_devread((lbaint_t)block << log2_blksz, 0, blksz,
-  buf))
-   ext_block = (struct ext4_extent_header *)buf;
-   else
+   block <<= log2_blksz;
+   if (!ext_cache_read(cache, (lbaint_t)block, blksz))
return NULL;
+   ext_block = (struct ext4_extent_header *)cache->buf;
}
 }
 
@@ -1613,7 +1612,8 @@ int ext4fs_read_inode(struct ext2_data *data, int ino, 
struct ext2_inode *inode)
return 1;
 }
 
-long int read_allocated_block(struct ext2_inode *inode, int fileblock)
+long int read_allocated_block(struct ext2_inode *inode, int fileblock,
+ struct ext_block_cache *cache)
 {
long int blknr;
int blksz;
@@ -1630,20 +1630,26 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
 
if (le32_to_cpu(inode->flags) & EXT4_EXTENTS_FL) {
long int startblock, endblock;
-   char *buf = zalloc(blksz);
-   if (!buf)
-   return -ENOMEM;
+   struct ext_block_cache *c, cd;
struct ext4_extent_header *ext_block;
struct ext4_extent *extent;
int i;
+
+   if (cache) {
+   c = cache;
+   } else {
+   c = 
+   ext_cache_init(c);
+   }
ext_block =
-   ext4fs_get_extent_block(ext4fs_root, buf,
+   ext4fs_get_extent_block(ext4fs_root, c,
(struct ext4_extent_header *)
inode->b.blocks.dir_blocks,
fileblock, log2_blksz);
if (!ext_block) {
printf("invalid extent block\n");
-   free(buf);
+  

Re: [U-Boot] [PATCH v1 1/2] doc: Fix CONFIG_OF_SEPARATE description

[Andy Shevchenko]

On Tue, Jan 08, 2019 at 04:17:42PM +0200, Andy Shevchenko wrote:
> CONFIG_OF_SEPARATE description is not in align with actual code in Makefile 
> and
> thus has misleading instructions and explanation.
> 
> Make it aligned with the actual code.

Bin, is it possible to see this for the next release?

> 
> Signed-off-by: Andy Shevchenko 
> ---
>  doc/README.fdt-control | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/README.fdt-control b/doc/README.fdt-control
> index 446401c9e9..e53cf51875 100644
> --- a/doc/README.fdt-control
> +++ b/doc/README.fdt-control
> @@ -122,13 +122,14 @@ the U-Boot image (including u-boot.bin). This is 
> suitable for debugging
>  and development only and is not recommended for production devices.
>  
>  If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
> -a u-boot.dtb file alongside u-boot.bin. A common approach is then to
> +a u-boot.dtb file alongside u-boot-nodtb.bin. A common approach is then to
>  join the two:
>  
> - cat u-boot.bin u-boot.dtb >image.bin
> + cat u-boot-nodtb.bin u-boot.dtb >image.bin
>  
>  and then flash image.bin onto your board. Note that U-Boot creates
> -u-boot-dtb.bin which does the above step for you also. If you are using
> +u-boot-dtb.bin which does the above step for you also. Resulting
> +u-boot.bin is a copy of u-boot-dtb.bin in this case. If you are using
>  CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
>  tree binary.
>  
> -- 
> 2.19.2
> 

-- 
With Best Regards,
Andy Shevchenko


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

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

[Oskari Lemmela]

Add a boot command to distro boot to support load FIT image
from SPI flash.

Signed-off-by: Oskari Lemmela 
---
 Kconfig | 29 +
 include/config_distro_bootcmd.h | 16 
 2 files changed, 45 insertions(+)

diff --git a/Kconfig b/Kconfig
index a078f7b1b6..f28fbf4fc0 100644
--- a/Kconfig
+++ b/Kconfig
@@ -342,6 +342,35 @@ config FIT_IMAGE_POST_PROCESS
  injected into the FIT creation (i.e. the blobs would have been pre-
  processed before being added to the FIT image).
 
+config FIT_SPI_FLASH_BOOT
+   bool "Distro bootcmd from SPI Flash"
+   depends on DM_SPI_FLASH
+   imply CMD_SF
+   help
+ Enable SPI bootcmd to load FIT image from SPI flash. Command
+ probes for the SPI flash device. If device is found command
+ will try to load FIT image to memory and boot it.
+
+config FIT_FLASH_IMAGE_ADDR
+   hex "FIT image memory address"
+   depends on FIT_SPI_FLASH_BOOT
+   help
+ Memory address where to load FIT image.
+
+config FIT_FLASH_IMAGE_OFFSET
+   hex "FIT image flash offset"
+   depends on FIT_SPI_FLASH_BOOT
+   default 0x10
+   help
+ Flash offset of FIT image.
+
+config FIT_FLASH_IMAGE_SIZE
+   hex "FIT image size"
+   depends on FIT_SPI_FLASH_BOOT
+   default 0x70
+   help
+ Max size of the FIT image.
+
 if SPL
 
 config SPL_FIT
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 555efb7433..75bc76c139 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -242,6 +242,22 @@
BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
 #endif
 
+#ifdef CONFIG_FIT_SPI_FLASH_BOOT
+#define BOOT_TARGET_DEVICES_SPI(func) func(SPI, spi, 0)
+#define BOOTENV_DEV_SPI(devtypeu, devtypel, instance) \
+   "image_addr_r=" __stringify(CONFIG_FIT_FLASH_IMAGE_ADDR) "\0" \
+   "image_addr=" __stringify(CONFIG_FIT_FLASH_IMAGE_OFFSET) "\0" \
+   "image_size=" __stringify(CONFIG_FIT_FLASH_IMAGE_SIZE) "\0" \
+   "bootcmd_" #devtypel #instance "=" \
+   "if sf probe " #instance "; then " \
+   "sf read ${image_addr_r} ${image_addr} ${image_size}; " 
\
+   "bootm ${image_addr_r}; " \
+   "fi\0"
+#define BOOTENV_DEV_NAME_SPI   BOOTENV_DEV_NAME_BLKDEV
+#else
+#define BOOT_TARGET_DEVICES_SPI(func)
+#endif
+
 #ifdef CONFIG_CMD_VIRTIO
 #define BOOTENV_SHARED_VIRTIO  BOOTENV_SHARED_BLKDEV(virtio)
 #define BOOTENV_DEV_VIRTIO BOOTENV_DEV_BLKDEV
-- 
2.17.1

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

[U-Boot] [PATCH v2 2/2] sunxi: enable distro spi boot command

[Oskari Lemmela]

Signed-off-by: Oskari Lemmela 
---
 include/configs/sunxi-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index ed0cfc24f5..967f3e1f08 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -415,6 +415,7 @@ extern int soft_i2c_gpio_scl;
BOOT_TARGET_DEVICES_MMC(func) \
BOOT_TARGET_DEVICES_SCSI(func) \
BOOT_TARGET_DEVICES_USB(func) \
+   BOOT_TARGET_DEVICES_SPI(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
-- 
2.17.1

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

[U-Boot] [PATCH v2 0/2] sunxi: add spi flash bootcmd

[Oskari Lemmela]

Patches enable booting FIT image from SPI flash device.

Changes since v1:
 - Move bootcmd to config_distro_bootcmd
 - Add Kconfig options to enable and configure it

Oskari Lemmela (2):
  distro_bootcmd: add spi flash boot command
  sunxi: enable distro spi boot command

 Kconfig | 29 +
 include/config_distro_bootcmd.h | 16 
 include/configs/sunxi-common.h  |  1 +
 3 files changed, 46 insertions(+)

-- 
2.17.1

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

[U-Boot] [PATCH 1/1] configs: qemu: enable CONFIG_UT

[Heinrich Schuchardt]

Some library functions are implemented in a architecture dependent way,
e.g. the memory functions memset(), memcopy(), memmove.

So let's enable unit tests for QEMU targets. Later we should ensure they
are actually called on Travis CI.

Signed-off-by: Heinrich Schuchardt 
---
 configs/qemu-ppce500_defconfig   | 1 +
 configs/qemu-riscv32_defconfig   | 1 +
 configs/qemu-riscv32_smode_defconfig | 1 +
 configs/qemu-riscv64_defconfig   | 1 +
 configs/qemu-riscv64_smode_defconfig | 1 +
 configs/qemu-x86_64_defconfig| 1 +
 configs/qemu-x86_defconfig   | 1 +
 configs/qemu_arm64_defconfig | 1 +
 configs/qemu_arm_defconfig   | 1 +
 configs/qemu_mips64_defconfig| 1 +
 configs/qemu_mips64el_defconfig  | 1 +
 configs/qemu_mips_defconfig  | 1 +
 configs/qemu_mipsel_defconfig| 1 +
 13 files changed, 13 insertions(+)

diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index fd276f2d04..40629a2a5d 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -28,3 +28,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_PANIC_HANG=y
 CONFIG_OF_LIBFDT=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index 6334d8c0fc..ce247bd44a 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -7,3 +7,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-riscv32_smode_defconfig 
b/configs/qemu-riscv32_smode_defconfig
index 0a84ec1874..fb581504ea 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 2d9ead93a2..ee0b7e9c23 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-riscv64_smode_defconfig 
b/configs/qemu-riscv64_smode_defconfig
index b012443370..3b255afaa7 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 # CONFIG_CMD_MII is not set
 CONFIG_OF_PRIOR_STAGE=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 8d43acd480..0ecfa3129f 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -72,3 +72,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
 CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_UT_LIB=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 12ea72f562..e58d48575f 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -51,3 +51,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
 CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index f2e759cee9..74fa6bfc65 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -35,3 +35,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 27c427dd82..0843c57690 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -36,3 +36,4 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_mips64_defconfig b/configs/qemu_mips64_defconfig
index aff109512e..c305d43b7b 100644
--- a/configs/qemu_mips64_defconfig
+++ b/configs/qemu_mips64_defconfig
@@ -23,3 +23,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_mips64el_defconfig b/configs/qemu_mips64el_defconfig
index 63cbd44c0d..59729e7719 100644
--- a/configs/qemu_mips64el_defconfig
+++ b/configs/qemu_mips64el_defconfig
@@ -24,3 +24,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_mips_defconfig b/configs/qemu_mips_defconfig
index 37bf69f9e8..92007e9fe5 100644
--- a/configs/qemu_mips_defconfig
+++ b/configs/qemu_mips_defconfig
@@ -21,3 +21,4 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZMA=y
+CONFIG_UT_LIB=y
diff --git a/configs/qemu_mipsel_defconfig b/configs/qemu_mipsel_defconfig
index 82091b97df..96532058de 100644
--- a/configs/qemu_mipsel_defconfig
+++ b/configs/qemu_mipsel_defconfig
@@ -22,3 +22,4 @@ 

Re: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset

[Heinrich Schuchardt]

On 1/30/19 11:46 AM, Alexander Graf wrote:
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
> 
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at least
> an improvement.
> 
> Eventually we will want to have full DM functionality in runtime services.
> But this fixes a travis failure and doesn't clutter the code too heavily, so
> we should pull it in without the amazing new RTS DM framework.
> 
> Signed-off-by: Alexander Graf 
> 
> ---
> 
> v2 -> v3:
> 
>   - support EFI_RESET_PLATFORM_SPECIFIC
>   - reuse existing x86_sysreset_request() function

The v2->v3 update does not answer the question if the reset is correctly
implemented. We would not want to call a function we do not trust.

@Simon, Bin:
x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in
native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
which is tried before using the keyboard controller as last resort.

u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
u8 cf9 = inb(0xcf9) & ~reboot_code;
outb(cf9|2, 0xcf9); /* Request hard reset */
udelay(50);
/* Actually do the reset */
outb(cf9|reboot_code, 0xcf9);
udelay(50);

So the Kernel first switches bit 2 off and bit 1 on, waits, and then
switches bit 2 on, cf.
http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html

Shouldn't we do it the same way as the Kernel does it?

Best regards

Heinrich

> ---
>  drivers/sysreset/sysreset_x86.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..009f376602 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,8 +10,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
> +static __efi_runtime int x86_sysreset_request(struct udevice *dev,
> +   enum sysreset_t type)
>  {
>   int value;
>  
> @@ -31,6 +33,25 @@ static int x86_sysreset_request(struct udevice *dev, enum 
> sysreset_t type)
>   return -EINPROGRESS;
>  }
>  
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + if (reset_type == EFI_RESET_COLD ||
> +  reset_type == EFI_RESET_PLATFORM_SPECIFIC)
> + x86_sysreset_request(NULL, SYSRESET_COLD);
> + else if (reset_type == EFI_RESET_WARM)
> + x86_sysreset_request(NULL, SYSRESET_WARM);
> +
> + /* TODO EFI_RESET_SHUTDOWN */
> +
> + while (1) { }
> +}
> +#endif
> +
> +
>  static const struct udevice_id x86_sysreset_ids[] = {
>   { .compatible = "x86,reset" },
>   { }
> 

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

Re: [U-Boot] [PATCH v3 00/22] mx6sabre: Add DM and SPL FIT support

[Tom Rini]

On Wed, Jan 30, 2019 at 01:39:50PM +, Abel Vesa wrote:

> The second version is here:
> https://lists.denx.de/pipermail/u-boot/2019-January/356557.html
> 
> Changes since v2:
>  * Removed the unecessary SYS_MALLOC_F_LEN from both defocnfig
>  * Fixed the copyright for all the *u-boot.dtsi files

OK, but you didn't answer why you need to specify your own its file when
the TI examples show how to have mkimage generate this for you, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 2/2] efi_loader: Patch non-runtime code out at ExitBootServices already

[Heinrich Schuchardt]

On 1/30/19 11:46 AM, Alexander Graf wrote:
> While discussing something compeltely different, Ard pointed out
> that it might be legal to omit calling SetVirtualAddressMap altogether.
> 
> There is even a patch on the Linux Kernel Mailing List that implements
> such behavior by now:
> 
>   https://patchwork.kernel.org/patch/10782393/
> 
> While that sounds great, we currently rely on the SetVirtualAddressMap
> call to remove all references to code that would not workoutside of
> boot services.
> 
> So let's patch out those bits already on the call to ExitBootServices,
> so that we can successfully run even when an OS chooses to omit
> any call to SetVirtualAddressMap.
> 
> Reported-by: Ard Biesheuvel 
> Signed-off-by: Alexander Graf 
> 
> ---
> 

This patch series leads to a Python test error on qemu_arm64_defconfig:

if m != 0:
>   raise Exception('Reset failed during the EFI selftest')
E Exception: Reset failed during the EFI selftest

test/py/tests/test_efi_selftest.py:25: Exception



The output looks like:

Preparing for reset. Press any key...




U-Boot 2019.01-00458-gada5205aef (Jan 30 2019 - 19:47:02 +0100)



DRAM:



Please, adjust test_efi_selftest().

Best regards

Heinrich

> v1 -> v2:
> 
>   - Add missing icache invalidation
> 
> v2 -> v3:
> 
>   - Add link to upstream Linux patch
> ---
>  include/efi_loader.h  |  2 ++
>  lib/efi_loader/efi_boottime.c |  1 +
>  lib/efi_loader/efi_runtime.c  | 29 -
>  3 files changed, 23 insertions(+), 9 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9dd933dae7..2a40b09693 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -310,6 +310,8 @@ void efi_save_gd(void);
>  void efi_restore_gd(void);
>  /* Call this to relocate the runtime section to an address space */
>  void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
> +/* Call this when we start to live in a runtime only world */
> +void efi_runtime_detach(ulong offset);
>  /* Call this to set the current device name */
>  void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
>  /* Add a new object to the object list. */
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index fc26d6adc1..8cb2979bab 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1917,6 +1917,7 @@ static efi_status_t EFIAPI 
> efi_exit_boot_services(efi_handle_t image_handle,
>   bootm_disable_interrupts();
>  
>   /* Disable boot time services */
> + efi_runtime_detach((ulong)gd->relocaddr);
>   systab.con_in_handle = NULL;
>   systab.con_in = NULL;
>   systab.con_out_handle = NULL;
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 636dfdab39..17d22d429e 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -276,16 +276,12 @@ struct efi_runtime_detach_list_struct {
>   void *patchto;
>  };
>  
> -static const struct efi_runtime_detach_list_struct efi_runtime_detach_list[] 
> = {
> +static struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = {
>   {
>   /* do_reset is gone */
>   .ptr = _runtime_services.reset_system,
>   .patchto = efi_reset_system,
>   }, {
> - /* invalidate_*cache_all are gone */
> - .ptr = _runtime_services.set_virtual_address_map,
> - .patchto = _unimplemented,
> - }, {
>   /* RTC accessors are gone */
>   .ptr = _runtime_services.get_time,
>   .patchto = _get_time,
> @@ -328,7 +324,15 @@ static bool efi_runtime_tobedetached(void *p)
>   return false;
>  }
>  
> -static void efi_runtime_detach(ulong offset)
> +/**
> + * efi_runtime_detach() - Remove any dependency on non-runtime sections
> + *
> + * This function patches all remaining code to be self-sufficient inside
> + * runtime sections. Any calls to non-runtime will be removed after this.
> + *
> + * @offset:  relocaddr for pre-set_v_a_space, offset to VA after
> + */
> +__efi_runtime void efi_runtime_detach(ulong offset)
>  {
>   int i;
>   ulong patchoff = offset - (ulong)gd->relocaddr;
> @@ -344,6 +348,8 @@ static void efi_runtime_detach(ulong offset)
>  
>   /* Update CRC32 */
>   efi_update_table_header_crc32(_runtime_services.hdr);
> +
> +invalidate_icache_all();
>  }
>  
>  /* Relocate EFI runtime to uboot_reloc_base = offset */
> @@ -430,19 +436,25 @@ void efi_runtime_relocate(ulong offset, struct 
> efi_mem_desc *map)
>   * @virtmap: virtual address mapping information
>   * Return:   status code
>   */
> -static efi_status_t EFIAPI efi_set_virtual_address_map(
> +static __efi_runtime efi_status_t EFIAPI efi_set_virtual_address_map(
>   unsigned long memory_map_size,
>   unsigned long descriptor_size,
>   

Re: [U-Boot] [PATCH] dfu: mmc: call fs functions instead of run_command

[Stephen Warren]

On 1/25/19 11:58 AM, Simon Goldschmidt wrote:

This unbreaks dfu mmc_file_op which is currently broken since using the
load cmd on a buffer from heap is not allowed - added with
commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")

Fixes: commit aa3c609e2be5 ("fs: prevent overwriting reserved memory")
Reported-by: Stephen Warren 
Signed-off-by: Simon Goldschmidt 
Tested-by: Stephen Warren 


Any chance we could get this applied (directly to u-boot/master) to fix 
the rampant test failures? Thanks.

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

Re: [U-Boot] [PATCH 2/3] ARM: zynq: Convert Syzygy and Topic Miami to DM_I2C

[Michal Simek]

On 30. 01. 19 18:54, Michal Simek wrote:
> On 29. 01. 19 20:03, Tom McLeod wrote:
>> Sorry for the late reply here, the syzygy hub board has a Microchip
>> 24AA025E48 EEPROM on the I2C.
>>
>> Please let me know if there's any other information you need.
> 
> Are you wiring it in Linux? What compatible string are you using it?

Will be good if you can try this branch and let me know if this still
works for you.
https://github.com/michalsimek/u-boot/commits/20190130-mainline-v2

Thanks,
Michal

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

[U-Boot] [RFC PATCH 1/1] spi: Kconfig: change dependency order

[Oskari Lemmela]

SPI Kconfig logic is changed to reverse dependencies.
Dependencies are not needed to be defined in the defconfig.

Signed-off-by: Oskari Lemmela 
---
 drivers/mtd/spi/Kconfig | 28 --
 drivers/spi/Kconfig | 63 -
 2 files changed, 75 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 76d5a1d115..19ec3a9c9b 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -17,7 +17,8 @@ config DM_SPI_FLASH
 
 config SPI_FLASH_SANDBOX
bool "Support sandbox SPI flash device"
-   depends on SANDBOX && DM_SPI_FLASH
+   depends on SANDBOX
+   select DM_SPI_FLASH
help
  Since sandbox cannot access real devices, an emulation mechanism is
  provided instead. Drivers can be connected up to the sandbox SPI
@@ -27,6 +28,8 @@ config SPI_FLASH_SANDBOX
 
 config SPI_FLASH
bool "Legacy SPI Flash Interface support"
+   imply CMD_SF
+   select SPI
help
  Enable the legacy SPI flash support. This will include basic
  standard support for things like probing, read / write, and
@@ -36,7 +39,7 @@ config SPI_FLASH
 
 config SPI_FLASH_BAR
bool "SPI flash Bank/Extended address register support"
-   depends on SPI_FLASH
+   select SPI_FLASH
help
  Enable the SPI flash Bank/Extended address register support.
  Bank/Extended address registers are used to access the flash
@@ -44,66 +47,72 @@ config SPI_FLASH_BAR
 
 config SF_DUAL_FLASH
bool "SPI DUAL flash memory support"
-   depends on SPI_FLASH
+   select SPI_FLASH
help
  Enable this option to support two flash memories connected to a single
  controller. Currently Xilinx Zynq qspi supports this.
 
-if SPI_FLASH
-
 config SPI_FLASH_ATMEL
bool "Atmel SPI flash support"
+   select SPI_FLASH
help
  Add support for various Atmel SPI flash chips (AT45xxx and AT25xxx)
 
 config SPI_FLASH_EON
bool "EON SPI flash support"
+   select SPI_FLASH
help
  Add support for various EON SPI flash chips (EN25xxx)
 
 config SPI_FLASH_GIGADEVICE
bool "GigaDevice SPI flash support"
+   select SPI_FLASH
help
  Add support for various GigaDevice SPI flash chips (GD25xxx)
 
 config SPI_FLASH_ISSI
bool "ISSI SPI flash support"
+   select SPI_FLASH
help
  Add support for various ISSI SPI flash chips (ISxxx)
 
 config SPI_FLASH_MACRONIX
bool "Macronix SPI flash support"
+   select SPI_FLASH
help
  Add support for various Macronix SPI flash chips (MX25Lxxx)
 
 config SPI_FLASH_SPANSION
bool "Spansion SPI flash support"
+   select SPI_FLASH
help
  Add support for various Spansion SPI flash chips (S25FLxxx)
 
 config SPI_FLASH_STMICRO
bool "STMicro SPI flash support"
+   select SPI_FLASH
help
  Add support for various STMicro SPI flash chips (M25Pxxx and N25Qxxx)
 
 config SPI_FLASH_SST
bool "SST SPI flash support"
+   select SPI_FLASH
help
  Add support for various SST SPI flash chips (SST25xxx)
 
 config SPI_FLASH_WINBOND
bool "Winbond SPI flash support"
+   select SPI_FLASH
help
  Add support for various Winbond SPI flash chips (W25xxx)
 
 config SPI_FLASH_XMC
bool "XMC SPI flash support"
+   select SPI_FLASH
help
  Add support for various XMC (Wuhan Xinxin Semiconductor
  Manufacturing Corp.) SPI flash chips (XM25xxx)
 
-endif
-
 config SPI_FLASH_USE_4K_SECTORS
bool "Use small 4096 B erase sectors"
depends on SPI_FLASH
@@ -121,7 +130,8 @@ config SPI_FLASH_USE_4K_SECTORS
 
 config SPI_FLASH_DATAFLASH
bool "AT45xxx DataFlash support"
-   depends on SPI_FLASH && DM_SPI_FLASH
+   select SPI_FLASH
+   select DM_SPI_FLASH
help
  Enable the access for SPI-flash-based AT45xxx DataFlash chips.
  DataFlash is a kind of SPI flash. Most AT45 chips have two buffers
@@ -136,7 +146,7 @@ config SPI_FLASH_DATAFLASH
 
 config SPI_FLASH_MTD
bool "SPI Flash MTD support"
-   depends on SPI_FLASH
+   select SPI_FLASH
help
   Enable the MTD support for spi flash layer, this adapter is for
  translating mtd_read/mtd_write commands into spi_flash_read/write
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index fa76d8c3c0..c825384edf 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -1,7 +1,7 @@
-menuconfig SPI
-   bool "SPI Support"
+menu "SPI Support"
 
-if SPI
+config SPI
+   bool "SPI Support"
 
 config DM_SPI
bool "Enable Driver Model for SPI drivers"
@@ -16,10 +16,12 @@ config DM_SPI
  typically use driver-private data instead of extending the
  spi_slave structure.
 
-if DM_SPI
+menu "DM SPI Drivers"
+   visible if DM
 
 

[U-Boot] [RFC PATCH 0/1] SPI flash dependency rework

[Oskari Lemmela]

Currently TARGET_* and ARCH_* selects multiple spi related
CONFIG options. If dependency order of spi related CONFIG options
is reverse, they are selected as dependencies when needed.

Oskari Lemmela (1):
  spi: Kconfig: change dependency order

 drivers/mtd/spi/Kconfig | 28 --
 drivers/spi/Kconfig | 63 -
 2 files changed, 75 insertions(+), 16 deletions(-)

-- 
2.17.1

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

Re: [U-Boot] [PATCH 2/3] ARM: zynq: Convert Syzygy and Topic Miami to DM_I2C

[Michal Simek]

On 29. 01. 19 20:03, Tom McLeod wrote:
> Sorry for the late reply here, the syzygy hub board has a Microchip
> 24AA025E48 EEPROM on the I2C.
> 
> Please let me know if there's any other information you need.

Are you wiring it in Linux? What compatible string are you using it?

M

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

Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx u -boot-imx-20190129

[Tom Rini]

On Wed, Jan 30, 2019 at 10:10:23AM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> Tag: u -boot-imx-20190110
> Travis: https://travis-ci.org/sbabic/u-boot-imx

Thanks for doing a tag.  Can you please summarize things a little more
in the tag message next time?  It really helps with changelog summaries.

> 
> The following changes since commit d01806a8fcbdaedcc67cead56ece572021d97ab7:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-01-24
> 15:30:48 -0500)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190129
> 
> for you to fetch changes up to 6d69e535116ba9d6d3b8e4dc57cf3543301b59df:
> 
>   ARM: imx6q_logic: Enable Falcon Mode and fatwrite (2019-01-28 21:11:14
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] Makefile: remove generated font files

[Simon Glass]

On Tue, 29 Jan 2019 at 13:15, Heinrich Schuchardt  wrote:
>
> If `make mrproper` does not delete the generated drivers/video/fonts/*.S
> files a following `make tests` fails.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Jagan Teki]

On Wed, Jan 30, 2019 at 9:43 PM Andre Przywara  wrote:
>
> On Wed, 30 Jan 2019 20:17:56 +0530
> Jagan Teki  wrote:
>
> > On Wed, Jan 30, 2019 at 8:02 PM Andre Przywara
> >  wrote:
> > >
> > > On Wed, 30 Jan 2019 19:49:23 +0530
> > > Jagan Teki  wrote:
> > >
> > > > On Wed, Jan 30, 2019 at 7:13 PM Andre Przywara
> > > >  wrote:
> > > > >
> > > > > On Wed, 30 Jan 2019 18:16:44 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > > On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Wed, 30 Jan 2019 16:08:14 +0530
> > > > > > > Jagan Teki  wrote:
> > > > > > >
> > > > > > > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > > > > > > Jagan Teki  wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > > > > > > Jagan Teki  wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Some Allwinner clock devices have parent clocks
> > > > > > > > > > > > > and reset gates itself, which need to be
> > > > > > > > > > > > > activated for them to work.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Add some code to just assert all resets and
> > > > > > > > > > > > > enable all clocks given. This should enable the
> > > > > > > > > > > > > A80 MMC config clock, which requires both to be
> > > > > > > > > > > > > activated. The full CCU devices typically don't
> > > > > > > > > > > > > require resets, and have just fixed clocks as
> > > > > > > > > > > > > their parents. Since we treat both as optional
> > > > > > > > > > > > > and enabling fixed clocks is a NOP, this works
> > > > > > > > > > > > > for all cases, without the need to
> > > > > > > > > > > > > differentiate between those clock types.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Andre Przywara
> > > > > > > > > > > > >  ---
> > > > > > > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > > +#include 
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > >  #include 
> > > > > > > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops
> > > > > > > > > > > > > = { int sunxi_clk_probe(struct udevice *dev)
> > > > > > > > > > > > >  {
> > > > > > > > > > > > > struct ccu_priv *priv =
> > > > > > > > > > > > > dev_get_priv(dev);
> > > > > > > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > > > > > > +   int ret;
> > > > > > > > > > > > >
> > > > > > > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > > > > > > if (!priv->base)
> > > > > > > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct
> > > > > > > > > > > > > udevice *dev) if (!priv->desc)
> > > > > > > > > > > > > return -EINVAL;
> > > > > > > > > > > > >
> > > > > > > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > > > > > > +
> > > > > > > > > > > >
> > > > > > > > > > > > Can't we do this locally to clk_a80 probe?
> > > > > > > > > > >
> > > > > > > > > > > That's the point: there is no such thing. For all
> > > > > > > > > > > SoCs we use the shared sunxi_clk_probe() function.
> > > > > > > > > > > Doing this only for the A80 would mean to split
> > > > > > > > > > > this up, which is duplicating a lot of code for
> > > > > > > > > > > very little effect. The code here just enables
> > > > > > > > > > > every clock and reset given, which is generic and
> > > > > > > > > > > should always be the right thing.
> > > > > > > > > >
> > > > > > > > > > But enable and dessert of clock and reset is job
> > > > > > > > > > respective IP driver isn't it?
> > > > > > > > >
> > > > > > > > > Which IP driver are you thinking about? This is "the 

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

[Jagan Teki]

Hi Tom,

We are 2 days late to send this DM_MMC changes, hope you understand
and apply this PR asap.

thanks,
Jagan.

The following changes since commit 2f41ade79e5969ebea03a7dcadbeae8e03787d7e:

  linker: Modify linker scripts to be more generic (2019-01-26 22:55:53 -0500)

are available in the Git repository at:

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

for you to fetch changes up to a7cca5793774ee139b75a704d6efaa4d29f09f93:

  arm: sunxi: Enable DM_MMC (2019-01-30 18:22:18 +0530)


Andre Przywara (6):
  sunxi: clk: add MMC gates/resets
  sunxi: clk: A80: add MMC clock support
  mmc: sunxi: Add DM clk and reset support
  sunxi: board: do MMC pinmux setup for DM_MMC builds
  mmc: sunxi: Honour non-removable property in DT
  sunxi: clk: enable clk and reset for CCU devices

Jagan Teki (7):
  sunxi: amarula_a64_relic: Enable USB host
  mmc: sunxi: Add remaining compatible strings
  mmc: sunxi: Add DM_MMC support for H6
  mmc: sunxi: Add DM_MMC support for A80
  arm: dts: sunxi: Alter mmc2 auto-numbering to mmc1
  sunxi: A64: pinebook-u-boot: Include sunxi-u-boot.dtsi
  arm: sunxi: Enable DM_MMC

 arch/arm/Kconfig |  1 +
 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi |  2 ++
 arch/arm/dts/sunxi-u-boot.dtsi   |  4 +++
 arch/arm/mach-sunxi/Kconfig  |  1 -
 board/sunxi/board.c  | 15 
 configs/Linksprite_pcDuino3_defconfig|  1 -
 configs/amarula_a64_relic_defconfig  |  2 ++
 drivers/clk/sunxi/clk_a10.c  |  4 +++
 drivers/clk/sunxi/clk_a10s.c |  3 ++
 drivers/clk/sunxi/clk_a23.c  |  6 
 drivers/clk/sunxi/clk_a31.c  |  8 +
 drivers/clk/sunxi/clk_a64.c  |  6 
 drivers/clk/sunxi/clk_a80.c  | 32 -
 drivers/clk/sunxi/clk_a83t.c |  6 
 drivers/clk/sunxi/clk_h3.c   |  6 
 drivers/clk/sunxi/clk_h6.c   |  6 
 drivers/clk/sunxi/clk_r40.c  |  8 +
 drivers/clk/sunxi/clk_sunxi.c| 12 +++
 drivers/clk/sunxi/clk_v3s.c  |  6 
 drivers/mmc/sunxi_mmc.c  | 53 
 20 files changed, 173 insertions(+), 9 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/8] net: Add MSCC Luton networkd driver.

[Daniel Schwierzeck]

Am 30.01.19 um 13:29 schrieb Horatiu Vultur:
> Add network driver for Microsemi Ethernet switch, it is
> present on Luton SoCs.

the series looks good so far, only some nits below

> 
> Signed-off-by: Horatiu Vultur 
> ---
>  drivers/net/Kconfig |   7 +
>  drivers/net/Makefile|   2 +-
>  drivers/net/mscc_eswitch/Makefile   |   1 +
>  drivers/net/mscc_eswitch/luton_switch.c | 736 
> 
>  4 files changed, 745 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/net/mscc_eswitch/luton_switch.c
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 39ce4e8..d82037d 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -439,6 +439,13 @@ config MSCC_OCELOT_SWITCH
>   help
> This driver supports the Ocelot network switch device.
>  
> +config MSCC_LUTON_SWITCH
> + bool "Luton switch driver"
> + depends on DM_ETH && ARCH_MSCC
> + select PHYLIB
> + help
> +   This driver supports the Luton network switch device.
> +

maybe it makes sense to move the MSCC_*_SWITCH options to
driver/net/mscc_eswitch/Kconfig especially when you want to support more
SoCs in the future

>  config ETHER_ON_FEC1
>   bool "FEC1"
>   depends on MPC8XX_FEC
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 3ab7f26..51be72b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -75,4 +75,4 @@ obj-$(CONFIG_FSL_PFE) += pfe_eth/
>  obj-$(CONFIG_SNI_AVE) += sni_ave.o
>  obj-y += ti/
>  obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
> -obj-$(CONFIG_MSCC_OCELOT_SWITCH) += mscc_eswitch/
> +obj-y += mscc_eswitch/

this change would fit better to patch 1/8

> diff --git a/drivers/net/mscc_eswitch/Makefile 
> b/drivers/net/mscc_eswitch/Makefile
> index 704f854..751a839 100644
> --- a/drivers/net/mscc_eswitch/Makefile
> +++ b/drivers/net/mscc_eswitch/Makefile
> @@ -1,2 +1,3 @@
>  
>  obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o 
> mscc_mac_table.o
> +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o 
> mscc_mac_table.o
> diff --git a/drivers/net/mscc_eswitch/luton_switch.c 
> b/drivers/net/mscc_eswitch/luton_switch.c
> new file mode 100644
> index 000..dee6f15
> --- /dev/null
> +++ b/drivers/net/mscc_eswitch/luton_switch.c
> @@ -0,0 +1,736 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Microsemi Corporation
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mscc_miim.h"
> +#include "mscc_xfer.h"
> +#include "mscc_mac_table.h"
> +
> +#define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x))
> +#define  ANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
> +#define  ANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
> +#define ANA_PORT_CPU_FWD_CFG(x)  (0x50 + 0x80 * (x))
> +#define  ANA_PORT_CPU_FWD_CFG_SRC_COPY_ENA   BIT(1)
> +#define ANA_PORT_PORT_CFG(x) (0x60 + 0x80 * (x))
> +#define  ANA_PORT_PORT_CFG_RECV_ENA  BIT(5)
> +#define ANA_PGID(x)  (0x1000 + 4 * (x))
> +
> +#define SYS_FRM_AGING0x8300
> +
> +#define SYS_SYSTEM_RST_CFG   0x81b0
> +#define  SYS_SYSTEM_RST_MEM_INIT BIT(0)
> +#define  SYS_SYSTEM_RST_MEM_ENA  BIT(1)
> +#define  SYS_SYSTEM_RST_CORE_ENA BIT(2)
> +#define SYS_PORT_MODE(x) (0x81bc + 0x4 * (x))
> +#define  SYS_PORT_MODE_INCL_INJ_HDR  BIT(0)
> +#define SYS_SWITCH_PORT_MODE(x)  (0x8294 + 0x4 * (x))
> +#define  SYS_SWITCH_PORT_MODE_PORT_ENA   BIT(3)
> +#define SYS_EGR_NO_SHARING   0x8378
> +#define SYS_SCH_CPU  0x85a0
> +
> +#define REW_PORT_CFG(x)  (0x8 + 0x80 * (x))
> +#define  REW_PORT_CFG_IFH_INSERT_ENA BIT(7)
> +
> +#define GCB_DEVCPU_RST_SOFT_CHIP_RST 0x90
> +#define  GCB_DEVCPU_RST_SOFT_CHIP_RST_SOFT_PHY   BIT(1)
> +#define GCB_MISC_STAT0x11c
> +#define  GCB_MISC_STAT_PHY_READY BIT(3)
> +
> +#define  QS_XTR_MAP(x)   (0x10 + 4 * (x))
> +#define  QS_XTR_MAP_GRP  BIT(4)
> +#define  QS_XTR_MAP_ENA  BIT(0)
> +
> +#define HSIO_PLL5G_CFG_PLL5G_CFG20x8
> +
> +#define HSIO_RCOMP_CFG_CFG0  0x20
> +#define  HSIO_RCOMP_CFG_CFG0_MODE_SEL(x) ((x) << 
> 8)
> +#define  HSIO_RCOMP_CFG_CFG0_RUN_CAL BIT(12)
> +#define HSIO_RCOMP_STATUS0x24
> +#define  HSIO_RCOMP_STATUS_BUSY  BIT(12)
> +#define  HSIO_RCOMP_STATUS_RCOMP_M   
> GENMASK(3, 0)
> +#define HSIO_SERDES6G_ANA_CFG_DES_CFG0x64
> +#define  

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Andre Przywara]

On Wed, 30 Jan 2019 20:17:56 +0530
Jagan Teki  wrote:

> On Wed, Jan 30, 2019 at 8:02 PM Andre Przywara
>  wrote:
> >
> > On Wed, 30 Jan 2019 19:49:23 +0530
> > Jagan Teki  wrote:
> >  
> > > On Wed, Jan 30, 2019 at 7:13 PM Andre Przywara
> > >  wrote:  
> > > >
> > > > On Wed, 30 Jan 2019 18:16:44 +0530
> > > > Jagan Teki  wrote:
> > > >  
> > > > > On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
> > > > >  wrote:  
> > > > > >
> > > > > > On Wed, 30 Jan 2019 16:08:14 +0530
> > > > > > Jagan Teki  wrote:
> > > > > >  
> > > > > > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > > > > > >  wrote:  
> > > > > > > >
> > > > > > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > > > > > Jagan Teki  wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >  
> > > > > > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > > > > > >  wrote:  
> > > > > > > > > >
> > > > > > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > > > > > Jagan Teki  wrote:
> > > > > > > > > >  
> > > > > > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > > > > > >  wrote:  
> > > > > > > > > > > >
> > > > > > > > > > > > Some Allwinner clock devices have parent clocks
> > > > > > > > > > > > and reset gates itself, which need to be
> > > > > > > > > > > > activated for them to work.
> > > > > > > > > > > >
> > > > > > > > > > > > Add some code to just assert all resets and
> > > > > > > > > > > > enable all clocks given. This should enable the
> > > > > > > > > > > > A80 MMC config clock, which requires both to be
> > > > > > > > > > > > activated. The full CCU devices typically don't
> > > > > > > > > > > > require resets, and have just fixed clocks as
> > > > > > > > > > > > their parents. Since we treat both as optional
> > > > > > > > > > > > and enabling fixed clocks is a NOP, this works
> > > > > > > > > > > > for all cases, without the need to
> > > > > > > > > > > > differentiate between those clock types.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Andre Przywara
> > > > > > > > > > > >  ---
> > > > > > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > > > > > >  #include 
> > > > > > > > > > > >  #include 
> > > > > > > > > > > >  #include 
> > > > > > > > > > > > +#include 
> > > > > > > > > > > >  #include 
> > > > > > > > > > > >  #include 
> > > > > > > > > > > >  #include 
> > > > > > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops
> > > > > > > > > > > > = { int sunxi_clk_probe(struct udevice *dev)
> > > > > > > > > > > >  {
> > > > > > > > > > > > struct ccu_priv *priv =
> > > > > > > > > > > > dev_get_priv(dev);
> > > > > > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > > > > > +   int ret;
> > > > > > > > > > > >
> > > > > > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > > > > > if (!priv->base)
> > > > > > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct
> > > > > > > > > > > > udevice *dev) if (!priv->desc)
> > > > > > > > > > > > return -EINVAL;
> > > > > > > > > > > >
> > > > > > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > > > > > +
> > > > > > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > > > > > +  
> > > > > > > > > > >
> > > > > > > > > > > Can't we do this locally to clk_a80 probe?  
> > > > > > > > > >
> > > > > > > > > > That's the point: there is no such thing. For all
> > > > > > > > > > SoCs we use the shared sunxi_clk_probe() function.
> > > > > > > > > > Doing this only for the A80 would mean to split
> > > > > > > > > > this up, which is duplicating a lot of code for
> > > > > > > > > > very little effect. The code here just enables
> > > > > > > > > > every clock and reset given, which is generic and
> > > > > > > > > > should always be the right thing.  
> > > > > > > > >
> > > > > > > > > But enable and dessert of clock and reset is job
> > > > > > > > > respective IP driver isn't it?  
> > > > > > > >
> > > > > > > > Which IP driver are you thinking about? This is "the IP
> > > > > > > > driver" for those clock, isn't it?  
> > > > > > >
> > > > > > > IP can be any peripheral like USB, MMC, UART and it those
> > > > > > > drivers job to get and enable the clock isn't it?  
> > > > > >
> > > > > > Yes, using 

Re: [U-Boot] [U-Boot, 2/2] imx8mq_evk/README: remove ARCH environment variable

[Stefano Babic]

On 30/01/19 16:13, Baruch Siach wrote:
> Hi Stefano,
> 
> On Wed, Jan 30, 2019 at 03:33:21PM +0100, Stefano Babic wrote:
>> On 30/01/19 10:48, Baruch Siach wrote:
>>> On Wed, Jan 30, 2019 at 10:40:19AM +0200, sba...@denx.de wrote:
> There is no need to set the ARCH variable when building U-Boot. In fact,
> the ARCH name in U-Boot is 'arm'.
> Signed-off-by: Baruch Siach 

 Applied to u-boot-imx, master, thanks !
>>>
>>> Thanks.
>>>
>>> What about patch #1 in this series? It fixes build failure when /bin/sh is 
>>> not 
>>> bash.
>>
>> I suffer from the prejudice that a single "=" is always bad in a
>> comparison.I am surely influenced from bugs in C/C++ due to a
>> missing "=" in my experience as developer.
>>
>> I searched for such as comparison in other parts of build to justify
>> this patch : I have just found it in "test/fs" (ok, this is not really
>> part of build) and in ./lib/lzma/import_lzmasdk.sh. I fully agree that
>> this could be just a problem of mine, and I confess I was already merged
>> your patch and then removed again..
>>
>> Apart of this,  it looks like that a single "=" was already avoided in
>> U-Boot scripts like the pest. Apart of the single entry I found above,
>> it was avoided..
>>
>> What about to substitute "=" with an explicit "-eq" ? Like :
>>
>>  [ $f -eq "spl/u-boot-spl-ddr.bin" ]
> 
> The '-eq' operator only accept integers:
> 
> $ [ f -eq "spl/u-boot-spl-ddr.bin" ]
> bash: test: f: integer expression expected
> 
> The alternative is to set the script shebang to /bin/bash. I don't like this 
> solution. What do you think?

Is not possible to change the behavior of the script filtering the
$blobs variable before evaluating ? The check is just for skipping these
two files.

Something like :

 blobs=`awk '/^SIGNED_HDMI/ {print $2} /^LOADER/ {print $2}
/^SECOND_LOADER/ {print $2} /^DDR_FW/ {print $2}' $file` | grep -v
""spl/u-boot-spl-ddr.bin" | ..

It look to me better to put in $blobs just the values that must be
evaluated instead of checking them later. $blobs is not evaluated anymore.

Best regards,
Stefano

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

Re: [U-Boot] [PATCH] rpi: add Compute Module 3+

[Alexander Graf]

Hi Jonathan,

On 30.01.19 15:17, Jonathan Gray wrote:
> Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> is 0x10 according to the list on raspberrypi.org.
> 
> Signed-off-by: Jonathan Gray 
> ---
>  board/raspberrypi/rpi/rpi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 153a1fdcb7..c118250740 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
>   DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
>   false,
>   },
> + [0x10] = {
> + "Compute Module 3+",
> + DTB_DIR "bcm2837-rpi-cm3-plus.dtb",

Is the dtb name already committed to? I haven't seen patches on the rpi
kernel ML.


Alex

> + false,
> + },
>  };
>  
>  static const struct rpi_model rpi_models_old_scheme[] = {
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] imx8mq_evk/README: remove ARCH environment variable

[Baruch Siach]

Hi Stefano,

On Wed, Jan 30, 2019 at 03:33:21PM +0100, Stefano Babic wrote:
> On 30/01/19 10:48, Baruch Siach wrote:
> > On Wed, Jan 30, 2019 at 10:40:19AM +0200, sba...@denx.de wrote:
> >>> There is no need to set the ARCH variable when building U-Boot. In fact,
> >>> the ARCH name in U-Boot is 'arm'.
> >>> Signed-off-by: Baruch Siach 
> >>
> >> Applied to u-boot-imx, master, thanks !
> > 
> > Thanks.
> > 
> > What about patch #1 in this series? It fixes build failure when /bin/sh is 
> > not 
> > bash.
> 
> I suffer from the prejudice that a single "=" is always bad in a
> comparison.I am surely influenced from bugs in C/C++ due to a
> missing "=" in my experience as developer.
> 
> I searched for such as comparison in other parts of build to justify
> this patch : I have just found it in "test/fs" (ok, this is not really
> part of build) and in ./lib/lzma/import_lzmasdk.sh. I fully agree that
> this could be just a problem of mine, and I confess I was already merged
> your patch and then removed again..
> 
> Apart of this,  it looks like that a single "=" was already avoided in
> U-Boot scripts like the pest. Apart of the single entry I found above,
> it was avoided..
> 
> What about to substitute "=" with an explicit "-eq" ? Like :
> 
>   [ $f -eq "spl/u-boot-spl-ddr.bin" ]

The '-eq' operator only accept integers:

$ [ f -eq "spl/u-boot-spl-ddr.bin" ]
bash: test: f: integer expression expected

The alternative is to set the script shebang to /bin/bash. I don't like this 
solution. What do you think?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [upstream-release] [PATCH 3/3] armv8: fsl-layerscape: avoid DT fixup warning

[Bharat Bhushan]

> -Original Message-
> From: upstream-release-boun...@linux.nxdi.nxp.com  boun...@linux.nxdi.nxp.com> On Behalf Of laurentiu.tu...@nxp.com
> Sent: Wednesday, January 30, 2019 5:31 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> ; York Sun 
> Cc: Laurentiu Tudor 
> Subject: [upstream-release] [PATCH 3/3] armv8: fsl-layerscape: avoid DT
> fixup warning
> 
> From: Laurentiu Tudor 
> 
> sec_firmware reserves JR3 for it's own usage and deletes the JR3 node from
> the device tree. This causes this warning to be issued when doing the device
> tree fixup:

Do you think it is fair to assume that firmware will always reserve JR3? 

Thanks
-Bharat

> 
> WARNING could not find node fsl,sec-v4.0-job-ring: FDT_ERR_NOTFOUND.
> 
> Fix it by excluding the device tree fixup for the JR reserved by sec_firmware.
> 
> Signed-off-by: Laurentiu Tudor 
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> index e7a8801262..f971af8d26 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  struct icid_id_table {
>   const char *compat;
> @@ -98,7 +99,13 @@ void fdt_fixup_icid(void *blob);
>   CONFIG_SYS_FSL_SEC_ADDR)
> 
>  #define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
> - SET_ICID_ENTRY("fsl,sec-v4.0-job-ring", streamid, \
> + SET_ICID_ENTRY( \
> + (CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT && \
> + (FSL_SEC_JR##jr_num##_OFFSET ==  \
> + SEC_JR3_OFFSET + CONFIG_SYS_FSL_SEC_OFFSET) \
> + ? NULL \
> + : "fsl,sec-v4.0-job-ring"), \
> + streamid, \
>   (((streamid) << 16) | (streamid)), \
>   offsetof(ccsr_sec_t, jrliodnr[jr_num].ls) + \
>   CONFIG_SYS_FSL_SEC_ADDR, \
> --
> 2.17.1
> 
> ___
> upstream-release mailing list
> upstream-rele...@linux.nxdi.nxp.com
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flin
> ux.nxdi.nxp.com%2Fmailman%2Flistinfo%2Fupstream-
> releasedata=02%7C01%7Cbharat.bhushan%40nxp.com%7C13292681c
> 0d54b7bf07e08d686aaa051%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C636844464719708439sdata=XaF8UOqcTBaARb3wQuQjE%2BY7u
> 4VspHD2qodYvvrXXw8%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Jagan Teki]

On Wed, Jan 30, 2019 at 8:02 PM Andre Przywara  wrote:
>
> On Wed, 30 Jan 2019 19:49:23 +0530
> Jagan Teki  wrote:
>
> > On Wed, Jan 30, 2019 at 7:13 PM Andre Przywara
> >  wrote:
> > >
> > > On Wed, 30 Jan 2019 18:16:44 +0530
> > > Jagan Teki  wrote:
> > >
> > > > On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
> > > >  wrote:
> > > > >
> > > > > On Wed, 30 Jan 2019 16:08:14 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > > > > Jagan Teki  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > > > > Jagan Teki  wrote:
> > > > > > > > >
> > > > > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Some Allwinner clock devices have parent clocks and
> > > > > > > > > > > reset gates itself, which need to be activated for
> > > > > > > > > > > them to work.
> > > > > > > > > > >
> > > > > > > > > > > Add some code to just assert all resets and enable
> > > > > > > > > > > all clocks given. This should enable the A80 MMC
> > > > > > > > > > > config clock, which requires both to be activated.
> > > > > > > > > > > The full CCU devices typically don't require
> > > > > > > > > > > resets, and have just fixed clocks as their
> > > > > > > > > > > parents. Since we treat both as optional and
> > > > > > > > > > > enabling fixed clocks is a NOP, this works for all
> > > > > > > > > > > cases, without the need to differentiate between
> > > > > > > > > > > those clock types.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Andre Przywara
> > > > > > > > > > >  ---
> > > > > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > > > > >  #include 
> > > > > > > > > > >  #include 
> > > > > > > > > > >  #include 
> > > > > > > > > > > +#include 
> > > > > > > > > > >  #include 
> > > > > > > > > > >  #include 
> > > > > > > > > > >  #include 
> > > > > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops = {
> > > > > > > > > > >  int sunxi_clk_probe(struct udevice *dev)
> > > > > > > > > > >  {
> > > > > > > > > > > struct ccu_priv *priv = dev_get_priv(dev);
> > > > > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > > > > +   int ret;
> > > > > > > > > > >
> > > > > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > > > > if (!priv->base)
> > > > > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct
> > > > > > > > > > > udevice *dev) if (!priv->desc)
> > > > > > > > > > > return -EINVAL;
> > > > > > > > > > >
> > > > > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > > > > +
> > > > > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > > > > +   if (!ret)
> > > > > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > > > > +
> > > > > > > > > >
> > > > > > > > > > Can't we do this locally to clk_a80 probe?
> > > > > > > > >
> > > > > > > > > That's the point: there is no such thing. For all SoCs
> > > > > > > > > we use the shared sunxi_clk_probe() function. Doing
> > > > > > > > > this only for the A80 would mean to split this up,
> > > > > > > > > which is duplicating a lot of code for very little
> > > > > > > > > effect. The code here just enables every clock and
> > > > > > > > > reset given, which is generic and should always be the
> > > > > > > > > right thing.
> > > > > > > >
> > > > > > > > But enable and dessert of clock and reset is job
> > > > > > > > respective IP driver isn't it?
> > > > > > >
> > > > > > > Which IP driver are you thinking about? This is "the IP
> > > > > > > driver" for those clock, isn't it?
> > > > > >
> > > > > > IP can be any peripheral like USB, MMC, UART and it those
> > > > > > drivers job to get and enable the clock isn't it?
> > > > >
> > > > > Yes, using the DM_CLK framework. This is what we do: the A80
> > > > > MMC DT node refers to the MMC config clock (instead of the
> > > > > generic CCU), and the MMC driver doesn't care about any
> > > > > requirement this clock has *itself*.
> > > > > This is the responsibility of the *A80 MMC config clock driver*,
> > > > > which we 

Re: [U-Boot] [upstream-release] [PATCH 1/3] fsl_sec: fix register layout on Layerscape architectures

[Bharat Bhushan]

> -Original Message-
> From: upstream-release-boun...@linux.nxdi.nxp.com  boun...@linux.nxdi.nxp.com> On Behalf Of laurentiu.tu...@nxp.com
> Sent: Wednesday, January 30, 2019 5:31 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> ; York Sun 
> Cc: Laurentiu Tudor 
> Subject: [upstream-release] [PATCH 1/3] fsl_sec: fix register layout on
> Layerscape architectures
> 
> From: Laurentiu Tudor 
> 
> On Layerscape architectures the SEC memory map is 1MB and the register
> blocks contained in it are 64KB aligned, not 4KB as the ccsr_sec structure
> currently assumes. Fix the layout of the structure for these architectures.
> 
> Signed-off-by: Laurentiu Tudor 

Reviewed-by: Bharat Bhushan 


> ---
>  include/fsl_sec.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/fsl_sec.h b/include/fsl_sec.h index
> 16e3fcb5a1..be08a2b88b 100644
> --- a/include/fsl_sec.h
> +++ b/include/fsl_sec.h
> @@ -121,10 +121,18 @@ typedef struct ccsr_sec {
>   u32 chanum_ls;  /* CHA Number Register, LS */
>   u32 secvid_ms;  /* SEC Version ID Register, MS */
>   u32 secvid_ls;  /* SEC Version ID Register, LS */
> +#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3)
> + u8  res9[0x6f020];
> +#else
>   u8  res9[0x6020];
> +#endif
>   u32 qilcr_ms;   /* Queue Interface LIODN CFG Register, MS
> */
>   u32 qilcr_ls;   /* Queue Interface LIODN CFG Register, LS */
> +#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3)
> + u8  res10[0x8ffd8];
> +#else
>   u8  res10[0x8fd8];
> +#endif
>  } ccsr_sec_t;
> 
>  #define SEC_CTPR_MS_AXI_LIODN0x0800
> --
> 2.17.1
> 
> ___
> upstream-release mailing list
> upstream-rele...@linux.nxdi.nxp.com
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flin
> ux.nxdi.nxp.com%2Fmailman%2Flistinfo%2Fupstream-
> releasedata=02%7C01%7Cbharat.bhushan%40nxp.com%7C4ce1e3290
> 6cf486d062508d686aa9f4f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636844464713844776sdata=siuiBHEwywauPP22fsYTU98mMJP2dS3
> %2BDAAGIl0MPfM%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCH] common: fdt_support: Remove fdt_add_mem_rsv in fdt_shrink_to_minimum

[Keerthy]

With introduction of commit:

a156c47e39ad: tftp: prevent overwriting reserved memory

tftp with loadaddr is failing for Images of the size bigger than SPL.
The issue is that SPL image is located at bootaddr
and dtb is allocated at bootaddr + spl_size.

The region where dtb is present is marked reserved.

So when the tftp tries to load the Image it tries to find
a location from loadaddr to the first reserved memory region
which is the dtb base address. The max_size obtained is pretty
less and hence tftp fails with the below error:

TFTP error: trying to overwrite reserved memory...

Signed-off-by: Keerthy 
---

I am sure there are better solutions so just wanted to know
if there is one.

 common/fdt_support.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 42583e3ed8..2bb101e56e 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -633,11 +633,6 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
/* Change the fdt header to reflect the correct size */
fdt_set_totalsize(blob, actualsize);
 
-   /* Add the new reservation */
-   ret = fdt_add_mem_rsv(blob, map_to_sysmem(blob), actualsize);
-   if (ret < 0)
-   return ret;
-
return actualsize;
 }
 
-- 
2.17.1

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

Re: [U-Boot] [upstream-release] [PATCH] pci: layerscape: add option to statically allocate PCI StreamIDs

[Bharat Bhushan]

> -Original Message-
> From: upstream-release-boun...@linux.nxdi.nxp.com  boun...@linux.nxdi.nxp.com> On Behalf Of laurentiu.tu...@nxp.com
> Sent: Wednesday, January 30, 2019 5:31 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> ; York Sun 
> Cc: Laurentiu Tudor 
> Subject: [upstream-release] [PATCH] pci: layerscape: add option to statically
> allocate PCI StreamIDs
> 
> From: Laurentiu Tudor 
> 
> Certain PCI scenarios have more dynamic requirements, e.g. endpoints are
> "hot-plugged" later in the system lifetime. Add a Kconfig option that allows
> specifying a maximum number of end-points, per PCI controller and allocate
> a StreamID for each one.
> 
> Signed-off-by: Laurentiu Tudor 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 28 +
>  drivers/pci/pcie_layerscape_fixup.c   | 38 +++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 2b086da79b..1d633d71a8 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -571,3 +571,31 @@ config TFABOOT
> help
>   Enabling this will make a U-Boot binary that is capable of being
>   booted via TFA.
> +
> +menuconfig FSL_PCIE_STATIC_STREAM_IDS
> + bool "Allocate PCI streamIDs statically"
> + default n
> + depends on PCIE_LAYERSCAPE
> + help
> +   Statically allocate a certain number of StreamIDs for each PCI
> +   controller, instead of enumerating the connected endpoints and
> +   allocate a StreamID for each one. This allocation method can
> +   be used in more dynamic PCI scenarios, e.g. where endpoints are
> +   "hot-plugged" later in the system bringup, by statically specifying
> +   a maximum number of StreamIDs expected for each PCI controller.
> +
> +if FSL_PCIE_STATIC_STREAM_IDS
> +
> +config FSL_PCIE1_STREAM_IDS_COUNT
> + default 3
> + int "Maximum number of streamIDs to allocate for PCI1 controller"
> +
> +config FSL_PCIE2_STREAM_IDS_COUNT
> + default 3
> + int "Maximum number of streamIDs to allocate for PCI2 controller"
> +
> +config FSL_PCIE3_STREAM_IDS_COUNT
> + default 3
> + int "Maximum number of streamIDs to allocate for PCI3 controller"
> +
> +endif
> diff --git a/drivers/pci/pcie_layerscape_fixup.c
> b/drivers/pci/pcie_layerscape_fixup.c
> index 1a17bd98aa..32355cbf2e 100644
> --- a/drivers/pci/pcie_layerscape_fixup.c
> +++ b/drivers/pci/pcie_layerscape_fixup.c
> @@ -177,6 +177,7 @@ static void fdt_pcie_set_iommu_map_entry(void
> *blob, struct ls_pcie *pcie,
> 
>  static void fdt_fixup_pcie(void *blob)
>  {
> +#if !CONFIG_FSL_PCIE_STATIC_STREAM_IDS
>   struct udevice *dev, *bus;
>   struct ls_pcie *pcie;
>   int streamid;
> @@ -215,6 +216,43 @@ static void fdt_fixup_pcie(void *blob)
>   fdt_pcie_set_iommu_map_entry(blob, pcie, bdf >> 8,
>streamid);
>   }
> +#else
> + static const int streamid_cnt[] = {
> + CONFIG_FSL_PCIE1_STREAM_IDS_COUNT,
> + CONFIG_FSL_PCIE2_STREAM_IDS_COUNT,
> + CONFIG_FSL_PCIE3_STREAM_IDS_COUNT

Why 3 controllers?

> + };
> + struct ls_pcie *pcie;
> + int i, streamid, index;
> + pci_dev_t bdf;
> +
> + list_for_each_entry(pcie, _pcie_list, list) {
> + for (i = 0; i < streamid_cnt[pcie->idx]; i++) {
> + streamid = ls_pcie_next_streamid();
> + if (streamid < 0) {
> + debug("ERROR: no stream ids free\n");
> + continue;

Why to continue if we are out of stream-ids?

> + }
> +
> + index = ls_pcie_next_lut_index(pcie);
> + if (index < 0) {
> + debug("ERROR: no LUT indexes free\n");
> + continue;

We can error out when out of LUT entry

> + }
> +
> + bdf = PCI_BDF(i, 0, 0);
> + /* map PCI b.d.f to streamID in LUT */
> + ls_pcie_lut_set_mapping(pcie, index, bdf >> 8,
> + streamid);
> + /* update msi-map in device tree */
> + fdt_pcie_set_msi_map_entry(blob, pcie, bdf >> 8,
> +streamid);
> + /* update iommu-map in device tree */
> + fdt_pcie_set_iommu_map_entry(blob, pcie, bdf >>
> 8,
> +  streamid);
> + }
> + }
> +#endif /* !CONFIG_FSL_PCIE_STATIC_STREAM_IDS */
>  }
>  #endif
> 
> --
> 2.17.1
> 
> ___
> upstream-release mailing list
> upstream-rele...@linux.nxdi.nxp.com
> 

Re: [U-Boot] [U-Boot, 2/2] imx8mq_evk/README: remove ARCH environment variable

[Stefano Babic]

Hi Baruch,

On 30/01/19 10:48, Baruch Siach wrote:
> Hi Stefano,
> 
> On Wed, Jan 30, 2019 at 10:40:19AM +0200, sba...@denx.de wrote:
>>> There is no need to set the ARCH variable when building U-Boot. In fact,
>>> the ARCH name in U-Boot is 'arm'.
>>> Signed-off-by: Baruch Siach 
>>
>> Applied to u-boot-imx, master, thanks !
> 
> Thanks.
> 
> What about patch #1 in this series? It fixes build failure when /bin/sh is 
> not 
> bash.
> 

I suffer from the prejudice that a single "=" is always bad in a
comparison.I am surely influenced from bugs in C/C++ due to a
missing "=" in my experience as developer.

I searched for such as comparison in other parts of build to justify
this patch : I have just found it in "test/fs" (ok, this is not really
part of build) and in ./lib/lzma/import_lzmasdk.sh. I fully agree that
this could be just a problem of mine, and I confess I was already merged
your patch and then removed again..

Apart of this,  it looks like that a single "=" was already avoided in
U-Boot scripts like the pest. Apart of the single entry I found above,
it was avoided..

What about to substitute "=" with an explicit "-eq" ? Like :

[ $f -eq "spl/u-boot-spl-ddr.bin" ]

Best regards,
Stefano

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

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Andre Przywara]

On Wed, 30 Jan 2019 19:49:23 +0530
Jagan Teki  wrote:

> On Wed, Jan 30, 2019 at 7:13 PM Andre Przywara
>  wrote:
> >
> > On Wed, 30 Jan 2019 18:16:44 +0530
> > Jagan Teki  wrote:
> >  
> > > On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
> > >  wrote:  
> > > >
> > > > On Wed, 30 Jan 2019 16:08:14 +0530
> > > > Jagan Teki  wrote:
> > > >  
> > > > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > > > >  wrote:  
> > > > > >
> > > > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > > > Jagan Teki  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >  
> > > > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > > > >  wrote:  
> > > > > > > >
> > > > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > > > Jagan Teki  wrote:
> > > > > > > >  
> > > > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > > > >  wrote:  
> > > > > > > > > >
> > > > > > > > > > Some Allwinner clock devices have parent clocks and
> > > > > > > > > > reset gates itself, which need to be activated for
> > > > > > > > > > them to work.
> > > > > > > > > >
> > > > > > > > > > Add some code to just assert all resets and enable
> > > > > > > > > > all clocks given. This should enable the A80 MMC
> > > > > > > > > > config clock, which requires both to be activated.
> > > > > > > > > > The full CCU devices typically don't require
> > > > > > > > > > resets, and have just fixed clocks as their
> > > > > > > > > > parents. Since we treat both as optional and
> > > > > > > > > > enabling fixed clocks is a NOP, this works for all
> > > > > > > > > > cases, without the need to differentiate between
> > > > > > > > > > those clock types.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Andre Przywara
> > > > > > > > > >  ---
> > > > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > > > >  #include 
> > > > > > > > > >  #include 
> > > > > > > > > >  #include 
> > > > > > > > > > +#include 
> > > > > > > > > >  #include 
> > > > > > > > > >  #include 
> > > > > > > > > >  #include 
> > > > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops = {
> > > > > > > > > >  int sunxi_clk_probe(struct udevice *dev)
> > > > > > > > > >  {
> > > > > > > > > > struct ccu_priv *priv = dev_get_priv(dev);
> > > > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > > > +   int ret;
> > > > > > > > > >
> > > > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > > > if (!priv->base)
> > > > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct
> > > > > > > > > > udevice *dev) if (!priv->desc)
> > > > > > > > > > return -EINVAL;
> > > > > > > > > >
> > > > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > > > +   if (!ret)
> > > > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > > > +
> > > > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > > > +   if (!ret)
> > > > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > > > +  
> > > > > > > > >
> > > > > > > > > Can't we do this locally to clk_a80 probe?  
> > > > > > > >
> > > > > > > > That's the point: there is no such thing. For all SoCs
> > > > > > > > we use the shared sunxi_clk_probe() function. Doing
> > > > > > > > this only for the A80 would mean to split this up,
> > > > > > > > which is duplicating a lot of code for very little
> > > > > > > > effect. The code here just enables every clock and
> > > > > > > > reset given, which is generic and should always be the
> > > > > > > > right thing.  
> > > > > > >
> > > > > > > But enable and dessert of clock and reset is job
> > > > > > > respective IP driver isn't it?  
> > > > > >
> > > > > > Which IP driver are you thinking about? This is "the IP
> > > > > > driver" for those clock, isn't it?  
> > > > >
> > > > > IP can be any peripheral like USB, MMC, UART and it those
> > > > > drivers job to get and enable the clock isn't it?  
> > > >
> > > > Yes, using the DM_CLK framework. This is what we do: the A80
> > > > MMC DT node refers to the MMC config clock (instead of the
> > > > generic CCU), and the MMC driver doesn't care about any
> > > > requirement this clock has *itself*.
> > > > This is the responsibility of the *A80 MMC config clock driver*,
> > > > which we introduce in patch 3/9. So in *this* driver's probe
> > > > function you would need to enable the parent clocks, which is
> > > > exactly what we do. Just by re-using the existing
> > > > sunxi_clk_probe() function.  
> > > > > I assume this code would 

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Jagan Teki]

On Wed, Jan 30, 2019 at 7:13 PM Andre Przywara  wrote:
>
> On Wed, 30 Jan 2019 18:16:44 +0530
> Jagan Teki  wrote:
>
> > On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
> >  wrote:
> > >
> > > On Wed, 30 Jan 2019 16:08:14 +0530
> > > Jagan Teki  wrote:
> > >
> > > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > > >  wrote:
> > > > >
> > > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > > Jagan Teki  wrote:
> > > > > > >
> > > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Some Allwinner clock devices have parent clocks and
> > > > > > > > > reset gates itself, which need to be activated for them
> > > > > > > > > to work.
> > > > > > > > >
> > > > > > > > > Add some code to just assert all resets and enable all
> > > > > > > > > clocks given. This should enable the A80 MMC config
> > > > > > > > > clock, which requires both to be activated. The full
> > > > > > > > > CCU devices typically don't require resets, and have
> > > > > > > > > just fixed clocks as their parents. Since we treat both
> > > > > > > > > as optional and enabling fixed clocks is a NOP, this
> > > > > > > > > works for all cases, without the need to differentiate
> > > > > > > > > between those clock types.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Andre Przywara 
> > > > > > > > > ---
> > > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > > +#include 
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops = {
> > > > > > > > >  int sunxi_clk_probe(struct udevice *dev)
> > > > > > > > >  {
> > > > > > > > > struct ccu_priv *priv = dev_get_priv(dev);
> > > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > > +   int ret;
> > > > > > > > >
> > > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > > if (!priv->base)
> > > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct udevice
> > > > > > > > > *dev) if (!priv->desc)
> > > > > > > > > return -EINVAL;
> > > > > > > > >
> > > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > > +   if (!ret)
> > > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > > +
> > > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > > +   if (!ret)
> > > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > > +
> > > > > > > >
> > > > > > > > Can't we do this locally to clk_a80 probe?
> > > > > > >
> > > > > > > That's the point: there is no such thing. For all SoCs we
> > > > > > > use the shared sunxi_clk_probe() function. Doing this only
> > > > > > > for the A80 would mean to split this up, which is
> > > > > > > duplicating a lot of code for very little effect. The code
> > > > > > > here just enables every clock and reset given, which is
> > > > > > > generic and should always be the right thing.
> > > > > >
> > > > > > But enable and dessert of clock and reset is job respective IP
> > > > > > driver isn't it?
> > > > >
> > > > > Which IP driver are you thinking about? This is "the IP driver"
> > > > > for those clock, isn't it?
> > > >
> > > > IP can be any peripheral like USB, MMC, UART and it those drivers
> > > > job to get and enable the clock isn't it?
> > >
> > > Yes, using the DM_CLK framework. This is what we do: the A80 MMC DT
> > > node refers to the MMC config clock (instead of the generic CCU),
> > > and the MMC driver doesn't care about any requirement this clock has
> > > *itself*.
> > > This is the responsibility of the *A80 MMC config clock driver*,
> > > which we introduce in patch 3/9. So in *this* driver's probe
> > > function you would need to enable the parent clocks, which is
> > > exactly what we do. Just by re-using the existing sunxi_clk_probe()
> > > function.
> > > > I assume this code would do the same thing what these peripheral
> > > > driver do?
> > >
> > > It does, it's just one layer in between.
> > > ---
> > > A64 MMC driver   A64 CCU driver   fixed clock driver
> > >  sunxi_clk_probe()
> > >  clk_enable()->   (NULL)
> >
> > Ahh.. It didn't effect 

[U-Boot] [PATCH] rpi: add Compute Module 3+

[Jonathan Gray]

Add Raspberry Pi Compute Module 3+ to list of models, the revision code
is 0x10 according to the list on raspberrypi.org.

Signed-off-by: Jonathan Gray 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..c118250740 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
false,
},
+   [0x10] = {
+   "Compute Module 3+",
+   DTB_DIR "bcm2837-rpi-cm3-plus.dtb",
+   false,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.20.1

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

Re: [U-Boot] RK3399/RK3288 same-as-spl Option

[Philipp Tomsich]

> On 30.01.2019, at 15:06, Wadim Egorov  wrote:
> 
> Hi Philipp,
> Am 30.01.19 um 13:56 schrieb Philipp Tomsich:
>> Wadim,
>> 
>>> On 30.01.2019, at 13:50, Wadim Egorov >> > wrote:
>>> I want to know if there is a reason why the same-as-spl boot order option 
>>> [1] was not added for the RK3288. Do the chromebooks or other RK3288 based 
>>> boards don't want/need this option?
>> For starters I don’t have a RK3288-based board or a Chromebook.
>> The code was designed to be generic enough to easily retarget to new boards.
>> 
>> It’s good to see that it’s not just our modules that face the challenge of 
>> requiring a configurable boot-order ;-) 
> Yes, this popped up again for me after the "eMMC/sd index distro boot order" 
> discussion.
> 
>>> It seems the RK3288 has the same Register that marks the boot source device:
>>>   RK3399_BROM_BOOTSOURCE_ID_ADDR: 0xff8c0010
>>>   For RK3288 it is 0xff700010. I know it is not documented in the TRM. But 
>>> it works.
>> I had asked Kever for the address (back in the day), as it was not 
>> documented neither for the RK3368 nor for the RK3399.
>>> Any opinions in reworking the RK3288 code to use this Register for 
>>> "same-as-spl" boot?
>> There’s a task in my to-do list to move most of the configuration in the GRF 
>> (e.g. selecting RGMII vs. GMII) to an ioctl-based scheme.
>> This resulted as the “best available choice” from a prior discussion between 
>> me an Simon.
>> 
>> If you want to tackle this, I would advise a DM-based solution for 
>> interfacing with our BootROM.
> Thanks, I will keep this in mind. Right know it is not that important for us. 
> And I just wanted to know why nobody else had the idea to use the same-as-spl 
> process before. Maybe because this Register was not known for a long time.
For us it was a critical issue, as we have to support the Qseven form-factor on 
top of the
Rockchip BootROM: i.e. BIOS_DISABLE should force an external boot.  The hardware
does this by keeping the eMMC and SPI-NOR in reset (or powered-off, as we model 
it
as a regulator) and early-on in SPL during the regulator set-up, we re-enable 
these two
devices.

As we probe for a bootable FIT payload, we thus need to know what order to 
probe in.
Yet, the same bootloader should work from eMMC and SD-card … so we needed to 
have
some token to say “same device the SPL stage was booted from” that we could 
insert
early on in the search sequence (and yes: the SRAM location—this is not even a 
register—
is not publicly documented, but it took only one mail to Kever to get the info…)

That’s the complete historical record on this feature, now documented for 
eternity on the
mailing list archive. ;-)
I hope this provides the needed context…

Cheers,
Phil.

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

Re: [U-Boot] RK3399/RK3288 same-as-spl Option

[Wadim Egorov]

Hi Philipp,

Am 30.01.19 um 13:56 schrieb Philipp Tomsich:
> Wadim,
>
>> On 30.01.2019, at 13:50, Wadim Egorov > > wrote:
>>
>> I want to know if there is a reason why the same-as-spl boot order
>> option [1] was not added for the RK3288. Do the chromebooks or other
>> RK3288 based boards don't want/need this option?
>>
> For starters I don’t have a RK3288-based board or a Chromebook.
> The code was designed to be generic enough to easily retarget to new
> boards.
>
> It’s good to see that it’s not just our modules that face the
> challenge of requiring a configurable boot-order ;-)

Yes, this popped up again for me after the "eMMC/sd index distro boot
order" discussion.


>> It seems the RK3288 has the same Register that marks the boot source
>> device:
>>   RK3399_BROM_BOOTSOURCE_ID_ADDR: 0xff8c0010
>>   For RK3288 it is 0xff700010. I know it is not documented in the
>> TRM. But it works.
>>
> I had asked Kever for the address (back in the day), as it was not
> documented neither for the RK3368 nor for the RK3399.
>>
>> Any opinions in reworking the RK3288 code to use this Register for
>> "same-as-spl" boot?
>>
> There’s a task in my to-do list to move most of the configuration in
> the GRF (e.g. selecting RGMII vs. GMII) to an ioctl-based scheme.
> This resulted as the “best available choice” from a prior discussion
> between me an Simon.
>
> If you want to tackle this, I would advise a DM-based solution for
> interfacing with our BootROM.

Thanks, I will keep this in mind. Right know it is not that important
for us. And I just wanted to know why nobody else had the idea to use
the same-as-spl process before. Maybe because this Register was not
known for a long time.

Regards,
Wadim

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

Re: [U-Boot] [PATCH v4 0/9] mmc: sunxi: Enable DM_MMC

[Andre Przywara]

On Wed, 30 Jan 2019 18:20:31 +0530
Jagan Teki  wrote:

> On Wed, Jan 30, 2019 at 5:17 PM Andre Przywara
>  wrote:
> >
> > On Wed, 30 Jan 2019 11:16:07 +0100
> > Tomas Novotny  wrote:
> >
> > Hi,
> >  
> > > On Tue, 29 Jan 2019 15:54:07 +, Andre Przywara
> > >  wrote:  
> > > > This series gathers all remaining patches we need to enable
> > > > DM_MMC for Allwinner boards. It relies on the clock gates
> > > > framework already merged, and adds the respective gates and
> > > > resets for each SoC. It then teaches the sunxi MMC driver to
> > > > use the clock framework for those reset and gates clocks. The
> > > > "mod clock", responsible for setting the actual interface
> > > > speed, is still handled in the MMC driver, as the DM_CLK part
> > > > of that is not ready yet (and is not trivial). This allows to
> > > > turn on DM_MMC, and gets rid of the doomsday warning message
> > > > every Allwinner board was blessed with for a while.
> > > >
> > > > This series is available at:
> > > > https://github.com/apritzel/u-boot/commits/sunxi-dm-gates  
> > >
> > > I've briefly tested that branch on A83t mainlined tablet (TBS
> > > A711). I was able to boot from SD card and eMMC.
> > >
> > > Just noticed that message:
> > > MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1'
> > > mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
> > > I guess that this is the mmc1/2 renaming stuff?  
> >
> > I think so. So is this just a warning, and it continues anyway and
> > works?
> >
> > TBH, I don't like this patch 9/9 very much, I actually believe
> > relying on this numbering scheme in /aliases is something odd and
> > fragile. Especially since Linux (and other OSes) seem to get away
> > without it.
> >
> > For MMC, can't we just enumerate them dynamically? AFAIU the MMC
> > driver would not probe a block device successfully on an SDIO
> > device, would it?
> >
> > But for the sake of having something working, I am fine with the
> > patch, at least on a for-now basis.  
> 
> It's not a simple think that 9/9 fix is for,It's something big like
> w/o that we can't get the default env and fastboot devices because we
> always assign mmc1 for these purposes and indeed mmc1 is SDIO for DT
> enumeration.

Yeah, but why is it enumerating mmc1 in the first place? It doesn't
seem to be usable? The MMC layer should know that there is no block
device behind this SDIO thing, so it shouldn't even bother with
creating a device for it. Certainly Linux works this way.

I understand that it fixes the issue, but it's some sort of hack,
especially as it's applied to all DTs.

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

[U-Boot] [PATCH v3 21/22] board: mx6sabreauto: Update README with the SPL DM FIT info

[Abel Vesa]

There is a new step now. The need to build the u-boot.itb.
And instead of flashing the .img file, now the .itb file needs
to be flashed.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabreauto/README | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mx6sabreauto/README 
b/board/freescale/mx6sabreauto/README
index e8c589b..960a7d7 100644
--- a/board/freescale/mx6sabreauto/README
+++ b/board/freescale/mx6sabreauto/README
@@ -8,6 +8,7 @@ In order to build it:
 $ make mx6sabreauto_defconfig
 
 $ make
+$ make u-boot.itb
 
 This will generate the SPL and u-boot.img binaries.
 
@@ -17,7 +18,7 @@ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
 
 - Flash the u-boot.img binary into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot.itb of=/dev/sdX bs=1K seek=69 && sync
 
 Booting via Falcon mode
 ---
@@ -31,6 +32,7 @@ In order to build it:
 $ make mx6sabreauto_defconfig
 
 $ make
+$ make u-boot.itb
 
 This will generate the SPL image called SPL and the u-boot.img.
 
@@ -40,7 +42,7 @@ $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
 
 - Flash the u-boot.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 && sync
+$ sudo dd if=u-boot.itb of=/dev/sdb bs=1K seek=69 && sync
 
 Create a FAT16 boot partition to store uImage and the dtb file, then copy the 
files there:
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

[Andre Przywara]

On Wed, 30 Jan 2019 18:16:44 +0530
Jagan Teki  wrote:

> On Wed, Jan 30, 2019 at 4:26 PM Andre Przywara
>  wrote:
> >
> > On Wed, 30 Jan 2019 16:08:14 +0530
> > Jagan Teki  wrote:
> >  
> > > On Wed, Jan 30, 2019 at 4:04 PM Andre Przywara
> > >  wrote:  
> > > >
> > > > On Tue, 29 Jan 2019 23:56:44 +0530
> > > > Jagan Teki  wrote:
> > > >
> > > > Hi,
> > > >  
> > > > > On Tue, Jan 29, 2019 at 11:47 PM Andre Przywara
> > > > >  wrote:  
> > > > > >
> > > > > > On Tue, 29 Jan 2019 23:40:26 +0530
> > > > > > Jagan Teki  wrote:
> > > > > >  
> > > > > > > On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
> > > > > > >  wrote:  
> > > > > > > >
> > > > > > > > Some Allwinner clock devices have parent clocks and
> > > > > > > > reset gates itself, which need to be activated for them
> > > > > > > > to work.
> > > > > > > >
> > > > > > > > Add some code to just assert all resets and enable all
> > > > > > > > clocks given. This should enable the A80 MMC config
> > > > > > > > clock, which requires both to be activated. The full
> > > > > > > > CCU devices typically don't require resets, and have
> > > > > > > > just fixed clocks as their parents. Since we treat both
> > > > > > > > as optional and enabling fixed clocks is a NOP, this
> > > > > > > > works for all cases, without the need to differentiate
> > > > > > > > between those clock types.
> > > > > > > >
> > > > > > > > Signed-off-by: Andre Przywara 
> > > > > > > > ---
> > > > > > > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > > > > > > >  1 file changed, 12 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c index
> > > > > > > > 62ce2994e4..6d4aeb5315 100644 ---
> > > > > > > > a/drivers/clk/sunxi/clk_sunxi.c +++
> > > > > > > > b/drivers/clk/sunxi/clk_sunxi.c @@ -8,6 +8,7 @@
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > > +#include 
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops = {
> > > > > > > >  int sunxi_clk_probe(struct udevice *dev)
> > > > > > > >  {
> > > > > > > > struct ccu_priv *priv = dev_get_priv(dev);
> > > > > > > > +   struct clk_bulk clk_bulk;
> > > > > > > > +   struct reset_ctl_bulk rst_bulk;
> > > > > > > > +   int ret;
> > > > > > > >
> > > > > > > > priv->base = dev_read_addr_ptr(dev);
> > > > > > > > if (!priv->base)
> > > > > > > > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct udevice
> > > > > > > > *dev) if (!priv->desc)
> > > > > > > > return -EINVAL;
> > > > > > > >
> > > > > > > > +   ret = clk_get_bulk(dev, _bulk);
> > > > > > > > +   if (!ret)
> > > > > > > > +   clk_enable_bulk(_bulk);
> > > > > > > > +
> > > > > > > > +   ret = reset_get_bulk(dev, _bulk);
> > > > > > > > +   if (!ret)
> > > > > > > > +   reset_deassert_bulk(_bulk);
> > > > > > > > +  
> > > > > > >
> > > > > > > Can't we do this locally to clk_a80 probe?  
> > > > > >
> > > > > > That's the point: there is no such thing. For all SoCs we
> > > > > > use the shared sunxi_clk_probe() function. Doing this only
> > > > > > for the A80 would mean to split this up, which is
> > > > > > duplicating a lot of code for very little effect. The code
> > > > > > here just enables every clock and reset given, which is
> > > > > > generic and should always be the right thing.  
> > > > >
> > > > > But enable and dessert of clock and reset is job respective IP
> > > > > driver isn't it?  
> > > >
> > > > Which IP driver are you thinking about? This is "the IP driver"
> > > > for those clock, isn't it?  
> > >
> > > IP can be any peripheral like USB, MMC, UART and it those drivers
> > > job to get and enable the clock isn't it?  
> >
> > Yes, using the DM_CLK framework. This is what we do: the A80 MMC DT
> > node refers to the MMC config clock (instead of the generic CCU),
> > and the MMC driver doesn't care about any requirement this clock has
> > *itself*.
> > This is the responsibility of the *A80 MMC config clock driver*,
> > which we introduce in patch 3/9. So in *this* driver's probe
> > function you would need to enable the parent clocks, which is
> > exactly what we do. Just by re-using the existing sunxi_clk_probe()
> > function. 
> > > I assume this code would do the same thing what these peripheral
> > > driver do?  
> >
> > It does, it's just one layer in between.
> > ---
> > A64 MMC driver   A64 CCU driver   fixed clock driver
> >  sunxi_clk_probe()
> >  clk_enable()->   (NULL)  
> 
> Ahh.. It didn't effect other clk drivers except A80?

It affects every CCU device, but most (all?) of them just don't
specify any resets in the DT and the only clocks most of them have
there are fixed clocks.
And even if they would, enabling clocks and de-asserting resets sounds
like 

[U-Boot] [PATCH v3 13/22] mx6sabreauto: Add DM_GPIO support

[Abel Vesa]

Add the DM_GPIO related config for mx6sabreauto.
Also add the gpio request calls.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabreauto/mx6sabreauto.c | 3 +++
 configs/mx6sabreauto_defconfig  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index c8f1263..c7e3e67 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -501,6 +501,7 @@ iomux_v3_cfg_t const backlight_pads[] = {
 
 static void setup_iomux_backlight(void)
 {
+   gpio_request(IMX_GPIO_NR(2, 9), "backlight");
gpio_direction_output(IMX_GPIO_NR(2, 9), 1);
SETUP_IOMUX_PADS(backlight_pads);
 }
@@ -594,6 +595,7 @@ int board_init(void)
else
setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
/* I2C 3 Steer */
+   gpio_request(IMX_GPIO_NR(5, 4), "steer logic");
gpio_direction_output(IMX_GPIO_NR(5, 4), 1);
SETUP_IOMUX_PADS(i2c3_pads);
 #ifndef CONFIG_SYS_FLASH_CFI
@@ -602,6 +604,7 @@ int board_init(void)
else
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
 #endif
+   gpio_request(IMX_GPIO_NR(1, 15), "expander en");
gpio_direction_output(IMX_GPIO_NR(1, 15), 1);
SETUP_IOMUX_PADS(port_exp);
 
diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 6a4d3a4..31e8153 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -58,6 +58,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_SF=y
+CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 19/22] board: mx6sabresd: Remove the enet reset gpio handling

[Abel Vesa]

Rely on the phy-reset-gpios which is set in imx6qdl-sabresd dtsi
and get rid of the enet reset gpio handling from the board file.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 0824a05..385a18e 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -94,13 +94,6 @@ static iomux_v3_cfg_t const enet_pads[] = {
 static void setup_iomux_enet(void)
 {
SETUP_IOMUX_PADS(enet_pads);
-
-   /* Reset AR8031 PHY */
-   gpio_request(IMX_GPIO_NR(1, 25), "ENET PHY Reset");
-   gpio_direction_output(IMX_GPIO_NR(1, 25) , 0);
-   mdelay(10);
-   gpio_set_value(IMX_GPIO_NR(1, 25), 1);
-   udelay(100);
 }
 
 static iomux_v3_cfg_t const usdhc2_pads[] = {
-- 
2.7.4

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

[U-Boot] [PATCH v3 20/22] configs: mx6sabresd: Reduce size for SPL by disabling SPL_DOS and SPL_EFI

[Abel Vesa]

With DM and FIT enabled in SPL, there is an sram overflow.
By disabling CONFIG_SPL_DOS_PARTITION and CONFIG_SPL_EFI_PARTITION,
we get to keep the 'one binary to fit all' for imx6[q|qp|dl]
on sabresd since the final SPL image is now under 64KB.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabresd_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index b26e764..84840fe 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -54,6 +54,8 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_EFI_PARTITION=y
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
-- 
2.7.4

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

[U-Boot] [PATCH v3 18/22] board: mx6sabresd: Remove non-DM code

[Abel Vesa]

Since the mx6sabreauto has DM support, remove the unused non-DM code
from mx6sabresd board file.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 50 -
 1 file changed, 50 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 99002bd..0824a05 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -563,63 +563,13 @@ int board_eth_init(bd_t *bis)
 }
 
 #ifdef CONFIG_USB_EHCI_MX6
-#define USB_OTHERREGS_OFFSET   0x800
-#define UCTRL_PWR_POL  (1 << 9)
-
-static iomux_v3_cfg_t const usb_otg_pads[] = {
-   IOMUX_PADS(PAD_EIM_D22__USB_OTG_PWR | MUX_PAD_CTRL(NO_PAD_CTRL)),
-   IOMUX_PADS(PAD_ENET_RX_ER__USB_OTG_ID | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
-static iomux_v3_cfg_t const usb_hc1_pads[] = {
-   IOMUX_PADS(PAD_ENET_TXD1__GPIO1_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
 static void setup_usb(void)
 {
-   SETUP_IOMUX_PADS(usb_otg_pads);
-
/*
 * set daisy chain for otg_pin_id on 6q.
 * for 6dl, this bit is reserved
 */
imx_iomux_set_gpr_register(1, 13, 1, 0);
-
-   SETUP_IOMUX_PADS(usb_hc1_pads);
-}
-
-int board_ehci_hcd_init(int port)
-{
-   u32 *usbnc_usb_ctrl;
-
-   if (port > 1)
-   return -EINVAL;
-
-   usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + USB_OTHERREGS_OFFSET +
-port * 4);
-
-   setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
-
-   return 0;
-}
-
-int board_ehci_power(int port, int on)
-{
-   switch (port) {
-   case 0:
-   break;
-   case 1:
-   if (on)
-   gpio_direction_output(IMX_GPIO_NR(1, 29), 1);
-   else
-   gpio_direction_output(IMX_GPIO_NR(1, 29), 0);
-   break;
-   default:
-   printf("MXC USB port %d not yet supported\n", port);
-   return -EINVAL;
-   }
-
-   return 0;
 }
 #endif
 
-- 
2.7.4

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

[U-Boot] [PATCH v3 14/22] mx6sabresd: Add DM_GPIO support

[Abel Vesa]

Add the DM_GPIO related config for mx6sabresd.
Also add the gpio request calls.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 5 +
 configs/mx6sabresd_defconfig| 1 +
 2 files changed, 6 insertions(+)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 4688095..99002bd 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -96,6 +96,7 @@ static void setup_iomux_enet(void)
SETUP_IOMUX_PADS(enet_pads);
 
/* Reset AR8031 PHY */
+   gpio_request(IMX_GPIO_NR(1, 25), "ENET PHY Reset");
gpio_direction_output(IMX_GPIO_NR(1, 25) , 0);
mdelay(10);
gpio_set_value(IMX_GPIO_NR(1, 25), 1);
@@ -189,6 +190,7 @@ static iomux_v3_cfg_t const bl_pads[] = {
 static void enable_backlight(void)
 {
SETUP_IOMUX_PADS(bl_pads);
+   gpio_request(DISP0_PWR_EN, "Display Power Enable");
gpio_direction_output(DISP0_PWR_EN, 1);
 }
 
@@ -307,11 +309,13 @@ int board_mmc_init(bd_t *bis)
switch (i) {
case 0:
SETUP_IOMUX_PADS(usdhc2_pads);
+   gpio_request(USDHC2_CD_GPIO, "USDHC2 CD");
gpio_direction_input(USDHC2_CD_GPIO);
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
break;
case 1:
SETUP_IOMUX_PADS(usdhc3_pads);
+   gpio_request(USDHC3_CD_GPIO, "USDHC3 CD");
gpio_direction_input(USDHC3_CD_GPIO);
usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
break;
@@ -729,6 +733,7 @@ int checkboard(void)
 #ifdef CONFIG_SPL_OS_BOOT
 int spl_start_uboot(void)
 {
+   gpio_request(KEY_VOL_UP, "KEY Volume UP");
gpio_direction_input(KEY_VOL_UP);
 
/* Only enter in Falcon mode if KEY_VOL_UP is pressed */
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index d5a4365..1f4c5c5 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -69,6 +69,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
 CONFIG_FASTBOOT_BUF_SIZE=0x1000
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=2
+CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 22/22] board: mx6sabresd: Update README with the SPL DM FIT info

[Abel Vesa]

There is a new step now. The need to build the u-boot.itb.
And instead of flashing the .img file, now the .itb file needs
to be flashed.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabresd/README | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/freescale/mx6sabresd/README 
b/board/freescale/mx6sabresd/README
index 4b4df06..9b7f7cd 100644
--- a/board/freescale/mx6sabresd/README
+++ b/board/freescale/mx6sabresd/README
@@ -20,6 +20,7 @@ In order to build it:
 $ make mx6sabresd_defconfig
 
 $ make
+$ make u-boot.itb
 
 This will generate the SPL and u-boot.img binaries.
 
@@ -29,7 +30,7 @@ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
 
 - Flash the u-boot.img binary into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot.itb of=/dev/sdX bs=1K seek=69 && sync
 
 
 2. Booting from eMMC
@@ -38,6 +39,7 @@ $ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
 $ make mx6sabresd_defconfig
 
 $ make
+$ make u-boot.itb
 
 This will generate the SPL and u-boot.img binaries.
 
@@ -54,7 +56,7 @@ Mount the eMMC in the host PC:
 - Flash SPL and u-boot.img binaries into the eMMC:
 
 $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot.itb of=/dev/sdX bs=1K seek=69 && sync
 
 Set SW6 to eMMC 8-bit boot: 11010110
 
@@ -64,6 +66,7 @@ Set SW6 to eMMC 8-bit boot: 11010110
 
 $ make mx6sabresd_defconfig
 $ make
+$ make u-boot.itb
 
 This will generate the SPL image called SPL and the u-boot.img.
 
@@ -73,7 +76,7 @@ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 oflag=sync 
status=none && sync
 
 - Flash the u-boot.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 oflag=sync status=none && 
sync
+$ sudo dd if=u-boot.itb of=/dev/sdX bs=1K seek=69 oflag=sync status=none && 
sync
 
 Create a partition for root file system and extract it there:
 
-- 
2.7.4

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

[U-Boot] [PATCH v3 10/22] arm: imx: Add FIT SPL its

[Abel Vesa]

Add simple its in order to allow SPL to boot u-boot proper
via FIT table.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 arch/arm/mach-imx/mx6/fit_spl.its | 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 arch/arm/mach-imx/mx6/fit_spl.its

diff --git a/arch/arm/mach-imx/mx6/fit_spl.its 
b/arch/arm/mach-imx/mx6/fit_spl.its
new file mode 100644
index 000..bf3ffee
--- /dev/null
+++ b/arch/arm/mach-imx/mx6/fit_spl.its
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2018 NXP
+ *
+ * Simple U-boot fit source file containing U-Boot (with dtb appended)
+ */
+
+/dts-v1/;
+
+/ {
+   description = "Image for u-boot proper (with dtb appended)";
+   #address-cells = <1>;
+
+   images {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   uboot@1 {
+   reg = <0>;
+   description = "U-Boot";
+   data = /incbin/("../../../../u-boot-fit-dtb.bin");
+   type = "standalone";
+   os = "U-Boot";
+   compression = "none";
+   arch = "arm";
+   load = <0x1780>;
+   };
+   };
+
+   configurations {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   default = "conf@1";
+
+   conf@1 {
+   reg = <0>;
+   description = "i.MX armv7";
+   loadables = "uboot@1";
+   };
+   };
+};
-- 
2.7.4

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

[U-Boot] [PATCH v3 08/22] arm: dts: Add all the imx6[q|qp|dl] sabre[auto|sd] u-boot dts[i] files

[Abel Vesa]

This allows us to keep the basic dts[i] files up-to-date with
the ones in kernel, but at the same time allowing the u-boot
to add its own properties to the existing nodes.

Signed-off-by: Abel Vesa 
---
 arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi  |  6 ++
 arch/arm/dts/imx6dl-sabresd-u-boot.dtsi|  6 ++
 arch/arm/dts/imx6q-sabreauto-u-boot.dtsi   |  6 ++
 arch/arm/dts/imx6q-sabresd-u-boot.dtsi |  6 ++
 arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi | 21 +
 arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi   | 14 ++
 arch/arm/dts/imx6qdl-u-boot.dtsi   |  4 ++--
 arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi  |  6 ++
 arch/arm/dts/imx6qp-sabresd-u-boot.dtsi|  6 ++
 9 files changed, 73 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6q-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabresd-u-boot.dtsi

diff --git a/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
new file mode 100644
index 000..d75fcc1
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabreauto-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi 
b/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
new file mode 100644
index 000..e4d7d28
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabresd-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi 
b/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
new file mode 100644
index 000..d75fcc1
--- /dev/null
+++ b/arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabreauto-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6q-sabresd-u-boot.dtsi 
b/arch/arm/dts/imx6q-sabresd-u-boot.dtsi
new file mode 100644
index 000..e4d7d28
--- /dev/null
+++ b/arch/arm/dts/imx6q-sabresd-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabresd-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
new file mode 100644
index 000..ea90f40
--- /dev/null
+++ b/arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   aliases {
+   mmc0 = 
+   };
+};
+
+ {
+   no-1-8-v;
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi 
b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
new file mode 100644
index 000..45f02b1
--- /dev/null
+++ b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+ {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi b/arch/arm/dts/imx6qdl-u-boot.dtsi
index dffc21b..45ae2fa 100644
--- a/arch/arm/dts/imx6qdl-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
@@ -7,11 +7,11 @@
soc {
u-boot,dm-spl;
 
-   aips-bus@0200 {
+   aips-bus@200 {
u-boot,dm-spl;
};
 
-   aips-bus@0210 {
+   aips-bus@210 {
u-boot,dm-spl;
};
};
diff --git a/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi 
b/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
new file mode 100644
index 000..d75fcc1
--- /dev/null
+++ b/arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabreauto-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi 
b/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
new file mode 100644
index 000..e4d7d28
--- /dev/null
+++ b/arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 NXP
+ */
+
+#include "imx6qdl-sabresd-u-boot.dtsi"
-- 
2.7.4

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

[U-Boot] [PATCH v3 11/22] configs: mx6sabreauto: Add SPL FIT and DM support

[Abel Vesa]

Enable all the necessary configs for SPL DM and FIT support for
mx6sabreauto.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabreauto_defconfig | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 4bdcbb1..6a4d3a4 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -11,12 +11,19 @@ CONFIG_SPL=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_NXP_BOARD_REVISION=y
 CONFIG_NR_DRAM_BANKS=1
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_FIT=y
+CONFIG_SPL_FIT_PRINT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="arch/arm/mach-imx/mx6/fit_spl.its"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOUNCE_BUFFER=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_EXT_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
@@ -40,8 +47,15 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabreauto"
+CONFIG_OF_LIST="imx6dl-sabreauto imx6q-sabreauto imx6qp-sabreauto"
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_SF=y
 CONFIG_DM_MMC=y
@@ -68,4 +82,3 @@ CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
-CONFIG_OF_LIBFDT=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 09/22] arm: dts: Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd]

[Abel Vesa]

Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd] to the ones
from kernel v4.20 (commit 8fe28cb58bcb2).

Signed-off-by: Abel Vesa 
Acked-by: Peng Fan 
---
 arch/arm/dts/Makefile   |   8 +-
 arch/arm/dts/imx6dl-sabreauto.dts   |  13 +
 arch/arm/dts/imx6dl-sabresd.dts |  18 +
 arch/arm/dts/imx6dl.dtsi| 306 --
 arch/arm/dts/imx6q-sabreauto.dts|  18 +
 arch/arm/dts/imx6q-sabresd.dts  |  23 +
 arch/arm/dts/imx6q.dtsi | 310 --
 arch/arm/dts/imx6qdl-sabreauto.dtsi | 810 
 arch/arm/dts/imx6qdl-sabresd.dtsi   | 741 +
 arch/arm/dts/imx6qdl.dtsi   | 455 +++-
 arch/arm/dts/imx6qp-sabreauto.dts   |  55 +++
 arch/arm/dts/imx6qp-sabresd.dts |  55 +++
 arch/arm/dts/imx6qp.dtsi| 115 +
 13 files changed, 2669 insertions(+), 258 deletions(-)
 create mode 100644 arch/arm/dts/imx6dl-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6dl-sabresd.dts
 create mode 100644 arch/arm/dts/imx6q-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6q-sabresd.dts
 create mode 100644 arch/arm/dts/imx6qdl-sabreauto.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabresd.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6qp-sabresd.dts
 create mode 100644 arch/arm/dts/imx6qp.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5c3225b..c18da3d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -443,7 +443,13 @@ dtb-$(CONFIG_MX6QDL) += \
imx6q-icore.dtb \
imx6q-icore-mipi.dtb \
imx6q-icore-rqs.dtb \
-   imx6q-logicpd.dtb
+   imx6q-logicpd.dtb \
+   imx6q-sabreauto.dtb \
+   imx6q-sabresd.dtb \
+   imx6dl-sabreauto.dtb \
+   imx6dl-sabresd.dtb \
+   imx6qp-sabreauto.dtb \
+   imx6qp-sabresd.dtb
 
 dtb-$(CONFIG_MX6SL) += imx6sl-evk.dtb
 
diff --git a/arch/arm/dts/imx6dl-sabreauto.dts 
b/arch/arm/dts/imx6dl-sabreauto.dts
new file mode 100644
index 000..660d52a
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabreauto.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2013 Freescale Semiconductor, Inc.
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabreauto.dtsi"
+
+/ {
+   model = "Freescale i.MX6 DualLite/Solo SABRE Automotive Board";
+   compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
+};
diff --git a/arch/arm/dts/imx6dl-sabresd.dts b/arch/arm/dts/imx6dl-sabresd.dts
new file mode 100644
index 000..cd6bbf2
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sabresd.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2013 Freescale Semiconductor, Inc.
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabresd.dtsi"
+
+/ {
+   model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
+   compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
+};
+
+_csi1_from_ipu1_csi1_mux {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+};
diff --git a/arch/arm/dts/imx6dl.dtsi b/arch/arm/dts/imx6dl.dtsi
index 9a4c22c..f0607eb 100644
--- a/arch/arm/dts/imx6dl.dtsi
+++ b/arch/arm/dts/imx6dl.dtsi
@@ -1,12 +1,6 @@
-
-/*
- * Copyright 2013 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright 2013 Freescale Semiconductor, Inc.
 
 #include 
 #include "imx6dl-pinfunc.h"
@@ -39,6 +33,7 @@
396000  1175000
>;
clock-latency = <61036>; /* two CLK32 periods */
+   #cooling-cells = <2>;
clocks = < IMX6QDL_CLK_ARM>,
 < IMX6QDL_CLK_PLL2_PFD2_396M>,
 < IMX6QDL_CLK_STEP>,
@@ -56,39 +51,57 @@
device_type = "cpu";
reg = <1>;
next-level-cache = <>;
+   operating-points = <
+   /* kHzuV */
+   996000  125
+   792000  1175000
+   396000  115
+   >;
+   fsl,soc-operating-points = <
+   /* ARM kHz  SOC-PU uV */
+   996000  1175000
+   792000  1175000
+   396000  1175000
+   >;
+   clock-latency = <61036>; /* two CLK32 periods */
+   clocks = < IMX6QDL_CLK_ARM>,
+< IMX6QDL_CLK_PLL2_PFD2_396M>,
+< IMX6QDL_CLK_STEP>,
+< IMX6QDL_CLK_PLL1_SW>,
+ 

[U-Boot] [PATCH v3 12/22] configs: mx6sabresd: Add SPL FIT and DM support

[Abel Vesa]

Enable all the necessary configs for SPL DM and FIT support for
mx6sabresd.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabresd_defconfig | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 3babfd5..d5a4365 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -10,12 +10,19 @@ CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_FIT=y
+CONFIG_SPL_FIT_PRINT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="arch/arm/mach-imx/mx6/fit_spl.its"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOUNCE_BUFFER=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_EXT_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
@@ -47,23 +54,34 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_EFI_PARTITION=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
+CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_SPL_DM=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
 CONFIG_FASTBOOT_BUF_SIZE=0x1000
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=2
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_MII=y
 CONFIG_PCI=y
+CONFIG_DM_REGULATOR=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_USB=y
-CONFIG_USB_STORAGE=y
+CONFIG_DM_USB=y
+# CONFIG_SPL_DM_USB is not set
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
@@ -73,4 +91,3 @@ CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
-CONFIG_OF_LIBFDT=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 17/22] board: mx6sabreauto: Remove the non-DM code

[Abel Vesa]

Since the mx6sabreauto has DM support, remove the unused non-DM code
from mx6sabreauto board file.

Signed-off-by: Abel Vesa 
---
 board/freescale/mx6sabreauto/mx6sabreauto.c | 70 -
 1 file changed, 70 deletions(-)

diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index c7e3e67..dd72de9 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -159,44 +159,6 @@ static iomux_v3_cfg_t const port_exp[] = {
IOMUX_PADS(PAD_SD2_DAT0__GPIO1_IO15 | MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
 
-/*Define for building port exp gpio, pin starts from 0*/
-#define PORTEXP_IO_NR(chip, pin) \
-   ((chip << 5) + pin)
-
-/*Get the chip addr from a ioexp gpio*/
-#define PORTEXP_IO_TO_CHIP(gpio_nr) \
-   (gpio_nr >> 5)
-
-/*Get the pin number from a ioexp gpio*/
-#define PORTEXP_IO_TO_PIN(gpio_nr) \
-   (gpio_nr & 0x1f)
-
-static int port_exp_direction_output(unsigned gpio, int value)
-{
-   int ret;
-
-   i2c_set_bus_num(2);
-   ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio));
-   if (ret)
-   return ret;
-
-   ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio),
-   (1 << PORTEXP_IO_TO_PIN(gpio)),
-   (PCA953X_DIR_OUT << PORTEXP_IO_TO_PIN(gpio)));
-
-   if (ret)
-   return ret;
-
-   ret = pca953x_set_val(PORTEXP_IO_TO_CHIP(gpio),
-   (1 << PORTEXP_IO_TO_PIN(gpio)),
-   (value << PORTEXP_IO_TO_PIN(gpio)));
-
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 #ifdef CONFIG_MTD_NOR_FLASH
 static iomux_v3_cfg_t const eimnor_pads[] = {
IOMUX_PADS(PAD_EIM_D16__EIM_DATA16  | 
MUX_PAD_CTRL(WEIM_NOR_PAD_CTRL)),
@@ -681,19 +643,10 @@ int checkboard(void)
 }
 
 #ifdef CONFIG_USB_EHCI_MX6
-#define USB_HOST1_PWR PORTEXP_IO_NR(0x32, 7)
-#define USB_OTG_PWR   PORTEXP_IO_NR(0x34, 1)
-
-iomux_v3_cfg_t const usb_otg_pads[] = {
-   IOMUX_PADS(PAD_ENET_RX_ER__USB_OTG_ID | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
 int board_ehci_hcd_init(int port)
 {
switch (port) {
case 0:
-   SETUP_IOMUX_PADS(usb_otg_pads);
-
/*
  * Set daisy chain for otg_pin_id on 6q.
 *  For 6dl, this bit is reserved.
@@ -708,29 +661,6 @@ int board_ehci_hcd_init(int port)
}
return 0;
 }
-
-int board_ehci_power(int port, int on)
-{
-   switch (port) {
-   case 0:
-   if (on)
-   port_exp_direction_output(USB_OTG_PWR, 1);
-   else
-   port_exp_direction_output(USB_OTG_PWR, 0);
-   break;
-   case 1:
-   if (on)
-   port_exp_direction_output(USB_HOST1_PWR, 1);
-   else
-   port_exp_direction_output(USB_HOST1_PWR, 0);
-   break;
-   default:
-   printf("MXC USB port %d not yet supported\n", port);
-   return -EINVAL;
-   }
-
-   return 0;
-}
 #endif
 
 #ifdef CONFIG_SPL_BUILD
-- 
2.7.4

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

[U-Boot] [PATCH v3 15/22] configs: mx6sabreauto: Add DM_SPI_FLASH necessary configs

[Abel Vesa]

Enable all neceassary configs to support DM_SPI_FLASH on mx6sabreauto.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 configs/mx6sabreauto_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 31e8153..34fb9d04 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -63,12 +63,14 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_MII=y
 CONFIG_DM_REGULATOR=y
 CONFIG_SPI=y
+CONFIG_DM_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 16/22] configs: mx6sabresd: Add DM_SPI_FLASH necessary configs

[Abel Vesa]

Enable all neceassary configs to support DM_SPI_FLASH on mx6sabresd.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 configs/mx6sabresd_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 1f4c5c5..b26e764 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -72,6 +72,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=2
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
@@ -79,6 +80,7 @@ CONFIG_MII=y
 CONFIG_PCI=y
 CONFIG_DM_REGULATOR=y
 CONFIG_SPI=y
+CONFIG_DM_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 04/22] configs: imx6sabreauto: Add DM_USB support

[Abel Vesa]

Add the DM support for USB. For that, DM_REGULATOR is needed.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabreauto_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index a3d63a2..4bdcbb1 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -52,9 +52,11 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_MII=y
+CONFIG_DM_REGULATOR=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="FSL"
-- 
2.7.4

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

[U-Boot] [PATCH v3 05/22] mmc: fsl_esdhc: Fix DM_REGULATOR ifdefs for SPL builds

[Abel Vesa]

Since the fsl_esdhc will also be used by SPL, make the
preprocessor switches more generic to allow any kind of build.

Signed-off-by: Abel Vesa 
---
 drivers/mmc/fsl_esdhc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index b8171ba..47f2a8f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -804,7 +804,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
case MMC_SIGNAL_VOLTAGE_330:
if (priv->vs18_enable)
return -EIO;
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (!IS_ERR_OR_NULL(priv->vqmmc_dev)) {
ret = regulator_set_value(priv->vqmmc_dev, 330);
if (ret) {
@@ -823,7 +823,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (!IS_ERR_OR_NULL(priv->vqmmc_dev)) {
ret = regulator_set_value(priv->vqmmc_dev, 180);
if (ret) {
@@ -1442,7 +1442,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
int node = dev_of_offset(dev);
struct esdhc_soc_data *data =
(struct esdhc_soc_data *)dev_get_driver_data(dev);
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
struct udevice *vqmmc_dev;
 #endif
fdt_addr_t addr;
@@ -1500,7 +1500,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
 
priv->vs18_enable = 0;
 
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
/*
 * If emmc I/O has a fixed voltage at 1.8V, this must be provided,
 * otherwise, emmc will work abnormally.
-- 
2.7.4

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

[U-Boot] [PATCH v3 07/22] board: mx6sabreauto: Add board_fit_config_name_match to support FIT in SPL

[Abel Vesa]

This matches one of the following three boards (or fails):
 - imx6q-sabreauto
 - imx6qp-sabreauto
 - imx6dl-sabreauto

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabreauto/mx6sabreauto.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index c1bef85..c8f1263 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -1097,3 +1097,21 @@ void board_init_f(ulong dummy)
board_init_r(NULL, 0);
 }
 #endif
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   if (is_mx6dq()) {
+   if (!strcmp(name, "imx6q-sabreauto"))
+   return 0;
+   } else if (is_mx6dqp()) {
+   if (!strcmp(name, "imx6qp-sabreauto"))
+   return 0;
+   } else if (is_mx6dl()) {
+   if (!strcmp(name, "imx6dl-sabreauto"))
+   return 0;
+   }
+
+   return -1;
+}
+#endif
-- 
2.7.4

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

[U-Boot] [PATCH v3 06/22] board: mx6sabresd: Add board_fit_config_name_match to support FIT in SPL

[Abel Vesa]

This matches one of the following three boards (or fails):
 - imx6q-sabresd
 - imx6qp-sabresd
 - imx6dl-sabresd

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 0183ede..4688095 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -1062,3 +1062,21 @@ void board_init_f(ulong dummy)
board_init_r(NULL, 0);
 }
 #endif
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   if (is_mx6dq()) {
+   if (!strcmp(name, "imx6q-sabresd"))
+   return 0;
+   } else if (is_mx6dqp()) {
+   if (!strcmp(name, "imx6qp-sabresd"))
+   return 0;
+   } else if (is_mx6dl()) {
+   if (!strcmp(name, "imx6dl-sabresd"))
+   return 0;
+   }
+
+   return -1;
+}
+#endif
-- 
2.7.4

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

[U-Boot] [PATCH v3 01/22] usb: Rename SPL_USB_SUPPORT to SPL_USB_STORAGE

[Abel Vesa]

Since there is the SPL_USB_HOST_SUPPORT for enabling USB support in SPL,
makes more sense to rename the SPL_USB_SUPPORT as SPL_USB_STORAGE.
Everything that is not part of the usb storage support in SPL is now
build under SPL_USB_HOST_SUPPORT.

Signed-off-by: Abel Vesa 
Reviewed-by: Tom Rini 
---
 arch/arm/include/asm/arch-am33xx/spl.h| 2 +-
 arch/arm/mach-omap2/boot-common.c | 2 +-
 common/Makefile   | 5 +++--
 common/spl/Kconfig| 4 ++--
 common/spl/Makefile   | 2 +-
 common/spl/spl_usb.c  | 4 
 configs/am43xx_evm_usbhost_boot_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig   | 2 +-
 8 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/arch-am33xx/spl.h 
b/arch/arm/include/asm/arch-am33xx/spl.h
index 0bf8c17..f3910c2 100644
--- a/arch/arm/include/asm/arch-am33xx/spl.h
+++ b/arch/arm/include/asm/arch-am33xx/spl.h
@@ -62,7 +62,7 @@
 #define BOOT_DEVICE_CPGMAC 0x47
 
 #define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
-#ifdef CONFIG_SPL_USB_SUPPORT
+#ifdef CONFIG_SPL_USB_STORAGE
 #define MMC_BOOT_DEVICES_END   BOOT_DEVICE_USB
 #else
 #define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2
diff --git a/arch/arm/mach-omap2/boot-common.c 
b/arch/arm/mach-omap2/boot-common.c
index 2db1922..c8b8ac6 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -93,7 +93,7 @@ void save_omap_boot_params(void)
sys_boot_device = 1;
break;
 #endif
-#if defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)
+#if defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_STORAGE)
case BOOT_DEVICE_USB:
sys_boot_device = 1;
break;
diff --git a/common/Makefile b/common/Makefile
index ad390d0..8c92feb 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -75,8 +75,9 @@ obj-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
 obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
 
 ifdef CONFIG_SPL_USB_HOST_SUPPORT
-obj-$(CONFIG_SPL_USB_SUPPORT) += usb.o usb_hub.o
-obj-$(CONFIG_USB_STORAGE) += usb_storage.o
+obj-y += usb.o
+obj-y += usb_hub.o
+obj-$(CONFIG_SPL_USB_STORAGE) += usb_storage.o
 else
 obj-$(CONFIG_USB_MUSB_HOST) += usb.o
 endif
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 54b0dc3..8b0627e 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -766,9 +766,9 @@ config SPL_USB_HOST_SUPPORT
  device can be attached. This option enables the drivers in
  drivers/usb/host as part of an SPL build.
 
-config SPL_USB_SUPPORT
+config SPL_USB_STORAGE
bool "Support loading from USB"
-   depends on SPL_USB_HOST_SUPPORT
+   depends on SPL_USB_HOST_SUPPORT && !(BLK && !DM_USB)
help
  Enable support for USB devices in SPL. This allows use of USB
  devices such as hard drives and flash drivers for loading U-Boot.
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 6f8d759..a3980ce 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
 obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
 obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o
 obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o
-obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
+obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
 obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o
 obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o
 obj-$(CONFIG_$(SPL_TPL_)SATA_SUPPORT) += spl_sata.o
diff --git a/common/spl/spl_usb.c b/common/spl/spl_usb.c
index c8d8231..e29d579 100644
--- a/common/spl/spl_usb.c
+++ b/common/spl/spl_usb.c
@@ -15,9 +15,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_USB_STORAGE
 static int usb_stor_curr_dev = -1; /* current device */
-#endif
 
 static int spl_usb_load_image(struct spl_image_info *spl_image,
  struct spl_boot_device *bootdev)
@@ -34,13 +32,11 @@ static int spl_usb_load_image(struct spl_image_info 
*spl_image,
return err;
}
 
-#ifdef CONFIG_USB_STORAGE
/* try to recognize storage devices immediately */
usb_stor_curr_dev = usb_stor_scan(1);
stor_dev = blk_get_devnum_by_type(IF_TYPE_USB, usb_stor_curr_dev);
if (!stor_dev)
return -ENODEV;
-#endif
 
debug("boot mode - FAT\n");
 
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 5131f19..5bd919b 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -14,7 +14,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_USB_HOST_SUPPORT=y
-CONFIG_SPL_USB_SUPPORT=y
+CONFIG_SPL_USB_STORAGE=y
 CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_NAND_OFS=0x0010
 CONFIG_CMD_SPL_WRITE_SIZE=0x4
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 

[U-Boot] [PATCH v3 02/22] usb: ehci-mx6: Make regulator DM_REGULATOR dependent

[Abel Vesa]

Do the regulator related work only if the build has the DM_REGULATOR.

Signed-off-by: Abel Vesa 
Reviewed-by: Peng Fan 
---
 drivers/usb/host/ehci-mx6.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 1acf08d..9483947 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -404,6 +404,7 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
if (ret)
return ret;
 
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
ret = regulator_set_enable(priv->vbus_supply,
   (type == USB_INIT_DEVICE) ?
@@ -413,6 +414,7 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
return ret;
}
}
+#endif
 
if (type == USB_INIT_DEVICE)
return 0;
@@ -514,15 +516,17 @@ static int ehci_usb_probe(struct udevice *dev)
priv->portnr = dev->seq;
priv->init_type = type;
 
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
ret = device_get_supply_regulator(dev, "vbus-supply",
  >vbus_supply);
if (ret)
debug("%s: No vbus supply\n", dev->name);
-
+#endif
ret = ehci_mx6_common_init(ehci, priv->portnr);
if (ret)
return ret;
 
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
ret = regulator_set_enable(priv->vbus_supply,
   (type == USB_INIT_DEVICE) ?
@@ -532,6 +536,7 @@ static int ehci_usb_probe(struct udevice *dev)
return ret;
}
}
+#endif
 
if (priv->init_type == USB_INIT_HOST) {
setbits_le32(>usbmode, CM_HOST);
-- 
2.7.4

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

[U-Boot] [PATCH v3 03/22] configs: imx6sabreauto: Add DM_MMC support

[Abel Vesa]

Add DM_MMC config to imx6sabreauto defconfig.

Signed-off-by: Abel Vesa 
---
 configs/mx6sabreauto_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 40386c2..a3d63a2 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -44,6 +44,7 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_SF=y
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
-- 
2.7.4

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

[U-Boot] [PATCH v3 00/22] mx6sabre: Add DM and SPL FIT support

[Abel Vesa]

The second version is here:
https://lists.denx.de/pipermail/u-boot/2019-January/356557.html

Changes since v2:
 * Removed the unecessary SYS_MALLOC_F_LEN from both defocnfig
 * Fixed the copyright for all the *u-boot.dtsi files

Abel Vesa (22):
  usb: Rename SPL_USB_SUPPORT to SPL_USB_STORAGE
  usb: ehci-mx6: Make regulator DM_REGULATOR dependent
  configs: imx6sabreauto: Add DM_MMC support
  configs: imx6sabreauto: Add DM_USB support
  mmc: fsl_esdhc: Fix DM_REGULATOR ifdefs for SPL builds
  board: mx6sabresd: Add board_fit_config_name_match to support FIT in
SPL
  board: mx6sabreauto: Add board_fit_config_name_match to support FIT in
SPL
  arm: dts: Add all the imx6[q|qp|dl] sabre[auto|sd] u-boot dts[i] files
  arm: dts: Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd]
  arm: imx: Add FIT SPL its
  configs: mx6sabreauto: Add SPL FIT and DM support
  configs: mx6sabresd: Add SPL FIT and DM support
  mx6sabreauto: Add DM_GPIO support
  mx6sabresd: Add DM_GPIO support
  configs: mx6sabreauto: Add DM_SPI_FLASH necessary configs
  configs: mx6sabresd: Add DM_SPI_FLASH necessary configs
  board: mx6sabreauto: Remove the non-DM code
  board: mx6sabresd: Remove non-DM code
  board: mx6sabresd: Remove the enet reset gpio handling
  configs: mx6sabresd: Reduce size for SPL by disabling SPL_DOS and
SPL_EFI
  board: mx6sabreauto: Update README with the SPL DM FIT info
  board: mx6sabresd: Update README with the SPL DM FIT info

 arch/arm/dts/Makefile   |   8 +-
 arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi   |   6 +
 arch/arm/dts/imx6dl-sabreauto.dts   |  13 +
 arch/arm/dts/imx6dl-sabresd-u-boot.dtsi |   6 +
 arch/arm/dts/imx6dl-sabresd.dts |  18 +
 arch/arm/dts/imx6dl.dtsi| 306 ++-
 arch/arm/dts/imx6q-sabreauto-u-boot.dtsi|   6 +
 arch/arm/dts/imx6q-sabreauto.dts|  18 +
 arch/arm/dts/imx6q-sabresd-u-boot.dtsi  |   6 +
 arch/arm/dts/imx6q-sabresd.dts  |  23 +
 arch/arm/dts/imx6q.dtsi | 310 +--
 arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi  |  21 +
 arch/arm/dts/imx6qdl-sabreauto.dtsi | 810 
 arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi|  14 +
 arch/arm/dts/imx6qdl-sabresd.dtsi   | 741 +
 arch/arm/dts/imx6qdl-u-boot.dtsi|   4 +-
 arch/arm/dts/imx6qdl.dtsi   | 455 +---
 arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi   |   6 +
 arch/arm/dts/imx6qp-sabreauto.dts   |  55 ++
 arch/arm/dts/imx6qp-sabresd-u-boot.dtsi |   6 +
 arch/arm/dts/imx6qp-sabresd.dts |  55 ++
 arch/arm/dts/imx6qp.dtsi| 115 
 arch/arm/include/asm/arch-am33xx/spl.h  |   2 +-
 arch/arm/mach-imx/mx6/fit_spl.its   |  41 ++
 arch/arm/mach-omap2/boot-common.c   |   2 +-
 board/freescale/mx6sabreauto/README |   6 +-
 board/freescale/mx6sabreauto/mx6sabreauto.c |  91 +---
 board/freescale/mx6sabresd/README   |   9 +-
 board/freescale/mx6sabresd/mx6sabresd.c |  78 +--
 common/Makefile |   5 +-
 common/spl/Kconfig  |   4 +-
 common/spl/Makefile |   2 +-
 common/spl/spl_usb.c|   4 -
 configs/am43xx_evm_usbhost_boot_defconfig   |   2 +-
 configs/am43xx_hs_evm_defconfig |   2 +-
 configs/mx6sabreauto_defconfig  |  21 +-
 configs/mx6sabresd_defconfig|  26 +-
 drivers/mmc/fsl_esdhc.c |   8 +-
 drivers/usb/host/ehci-mx6.c |   7 +-
 39 files changed, 2900 insertions(+), 412 deletions(-)
 create mode 100644 arch/arm/dts/imx6dl-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6dl-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6dl-sabresd.dts
 create mode 100644 arch/arm/dts/imx6q-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6q-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6q-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6q-sabresd.dts
 create mode 100644 arch/arm/dts/imx6qdl-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabreauto.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qdl-sabresd.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabreauto-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabreauto.dts
 create mode 100644 arch/arm/dts/imx6qp-sabresd-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6qp-sabresd.dts
 create mode 100644 arch/arm/dts/imx6qp.dtsi
 create mode 100644 arch/arm/mach-imx/mx6/fit_spl.its

-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 0/9] mmc: sunxi: Enable DM_MMC

[Tomas Novotny]

Hi,

On Wed, 30 Jan 2019 11:46:55 +, Andre Przywara 
wrote:
> On Wed, 30 Jan 2019 11:16:07 +0100
> Tomas Novotny  wrote:
> 
> Hi,
> 
> > On Tue, 29 Jan 2019 15:54:07 +, Andre Przywara
> >  wrote:  
> > > This series gathers all remaining patches we need to enable DM_MMC
> > > for Allwinner boards. It relies on the clock gates framework
> > > already merged, and adds the respective gates and resets for each
> > > SoC. It then teaches the sunxi MMC driver to use the clock
> > > framework for those reset and gates clocks. The "mod clock",
> > > responsible for setting the actual interface speed, is still
> > > handled in the MMC driver, as the DM_CLK part of that is not ready
> > > yet (and is not trivial). This allows to turn on DM_MMC, and gets
> > > rid of the doomsday warning message every Allwinner board was
> > > blessed with for a while.
> > > 
> > > This series is available at:
> > > https://github.com/apritzel/u-boot/commits/sunxi-dm-gates
> > 
> > I've briefly tested that branch on A83t mainlined tablet (TBS A711).
> > I was able to boot from SD card and eMMC.
> > 
> > Just noticed that message:
> > MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1'
> > mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
> > I guess that this is the mmc1/2 renaming stuff?  
> 
> I think so. So is this just a warning, and it continues anyway and
> works?

yes. Just a warning and it successfully boots then.

Tomas

> TBH, I don't like this patch 9/9 very much, I actually believe relying
> on this numbering scheme in /aliases is something odd and fragile.
> Especially since Linux (and other OSes) seem to get away without it.
> 
> For MMC, can't we just enumerate them dynamically? AFAIU the MMC driver
> would not probe a block device successfully on an SDIO device, would it?
> 
> But for the sake of having something working, I am fine with the patch,
> at least on a for-now basis.
> 
> Cheers,
> Andre.
>  
> > With 2019.01 I got:
> > MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
> > 
> > Tomas
> >   
> > > ---
> > > 
> > > Jagan, can you please have a look whether this is fine? If you are
> > > not sure about patch 7, you can leave this one out for now.
> > > If you are good with it, can you merge it to sunxi/master and send
> > > the PR, so that it still goes into the release?
> > > We can then fix all the remaining issues until the release.
> > > 
> > > Cheers,
> > > Andre.
> > > 
> > > Changes in v4:
> > > - Add proper A80 support (special MMC config clock)
> > > - Add V3s support (gates and resets)
> > > - Fix pinmux problem when not booting via SD or eMMC
> > > - smaller fixes per ML discussion
> > > Changes for v3:
> > > - Handle clock via CLK framework.
> > > Changes for v2:
> > > - update the 'reset enablement' logic to do
> > >   required SoC's
> > > 
> > > Andre Przywara (5):
> > >   sunxi: clk: enable clk and reset for CCU devices
> > >   sunxi: clk: add MMC gates/resets
> > >   sunxi: clk: A80: add MMC clock support
> > >   mmc: sunxi: Add DM clk and reset support
> > >   sunxi: board: do MMC pinmux setup for DM_MMC builds
> > > 
> > > Jagan Teki (4):
> > >   mmc: sunxi: Add remaining compatible strings
> > >   mmc: sunxi: Add DM_MMC support for H6
> > >   arm: sunxi: Enable DM_MMC
> > >   arm: dts: sunxi: Enumerate MMC2 as MMC1
> > > 
> > >  arch/arm/Kconfig  |  1 +
> > >  arch/arm/dts/sunxi-u-boot.dtsi|  4 +++
> > >  arch/arm/mach-sunxi/Kconfig   |  1 -
> > >  board/sunxi/board.c   | 15 ++
> > >  configs/Linksprite_pcDuino3_defconfig |  1 -
> > >  drivers/clk/sunxi/clk_a10.c   |  4 +++
> > >  drivers/clk/sunxi/clk_a10s.c  |  3 ++
> > >  drivers/clk/sunxi/clk_a23.c   |  6 
> > >  drivers/clk/sunxi/clk_a31.c   |  8 +
> > >  drivers/clk/sunxi/clk_a64.c   |  6 
> > >  drivers/clk/sunxi/clk_a80.c   | 32 +++-
> > >  drivers/clk/sunxi/clk_a83t.c  |  6 
> > >  drivers/clk/sunxi/clk_h3.c|  6 
> > >  drivers/clk/sunxi/clk_h6.c|  6 
> > >  drivers/clk/sunxi/clk_r40.c   |  8 +
> > >  drivers/clk/sunxi/clk_sunxi.c | 12 
> > >  drivers/clk/sunxi/clk_v3s.c   |  6 
> > >  drivers/mmc/sunxi_mmc.c   | 42
> > > +++ 18 files changed, 159 insertions(+), 8
> > > deletions(-)   
> > 
> >   
> 


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