[U-Boot] [PATCH] ARM: kirkwood: add spi0 alias for dreamplug

2019-02-27 Thread Chris Packham
The conversion to DM_SPI managed to break accessing the environment on
dreamplug. This is because the environment code relies on being to able
to select the SPI device based on the sequence number. Add an alias so
that the spi0 bus gets sequence number 0.

Reported-by: Leigh Brown 
Signed-off-by: Chris Packham 
---
Leigh,

Could you test this on your system for me. I'm only able to compile test
this myself.

 arch/arm/dts/kirkwood-dreamplug.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/kirkwood-dreamplug.dts 
b/arch/arm/dts/kirkwood-dreamplug.dts
index a647a65c20a0..ccd74dd7fb33 100644
--- a/arch/arm/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/dts/kirkwood-dreamplug.dts
@@ -18,6 +18,10 @@
stdout-path = 
};
 
+   aliases {
+   spi0 = 
+   };
+
ocp@f100 {
pinctrl: pin-controller@1 {
pmx_led_bluetooth: pmx-led-bluetooth {
-- 
2.21.0

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


Re: [U-Boot] Commit "arm: kirkwood: configs: dreamplug: Convert to DM_SPI" breaks u-boot on Dreamplug

2019-02-27 Thread Chris Packham
Hi Leigh,

On Thu, Feb 28, 2019 at 7:24 AM Leigh Brown  wrote:
>
> Hello,
>
> Vagrant Cascadian asked for people to test the version of u-boot
> packaged
> for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
> working correctly.  I raised a bug for Debian[1] but I have also tested
> with the mainline version of u-boot and found the same issues.

Thanks for testing. We've been needing more people interested in
keeping Kirkwood going.

>
> This is the second issue that I found, and it causes u-boot to not
> detect
> the SPI flash on the system.  I bisected the issue to the following
> commit:
>
> commit 6aaf76beb131c2ff2b7184c2d63c2c63e5ab339c
> Author: Chris Packham 
> Date:   Wed Nov 21 22:22:23 2018 +1300
>
>  arm: kirkwood: configs: dreamplug: Convert to DM_SPI
>
>  Enable CONFIG_DM_SPI=y and CONFIG_DM_SPI_FLASH=y in the defconfig.
>
>  Signed-off-by: Chris Packham 
>  Reviewed-by: Stefan Roese 
>  Signed-off-by: Stefan Roese 
>
> The error manifests itself as follows:
>
> U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
> Marvell-DreamPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
>

I think this may be solved with a simple change to the DTS. I'll
include you on the CC list for a patch shortly. Could you please test
it on your hardware.

> A successful boot looks more like this:
>
> U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +)
> Marvell-DreamPlug
>
> SoC:   Kirkwood 88F6281_A1
> SPI:   ready
> DRAM:  512 MiB
> WARNING: Caches not enabled
> SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB,
> total 2 MiB
>
> Unfortunately, I don't know where to start to diagnose the issue.  Could
> anyone provide any pointers?  Happy to test any suggestions.
>
> Regards,
>
> Leigh.
>
> --
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] cmd: set CONFIG_SYS_HELP_CMD_WIDTH = 10

2019-02-27 Thread Heinrich Schuchardt
CONFIG_SYS_HELP_CMD_WIDTH is used to format the output of help without any
arguments.

CONFIG_SYS_HELP_CMD_WIDTH = 8 is too narrow to fit all our commands.

Signed-off-by: Heinrich Schuchardt 
---
Tested on Travis CI
https://travis-ci.org/xypron2/u-boot/builds/498902822
---
 include/command.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/command.h b/include/command.h
index 2e24e8ad3ee..be74f6ac92f 100644
--- a/include/command.h
+++ b/include/command.h
@@ -18,7 +18,7 @@
 
 /* Default to a width of 8 characters for help message command width */
 #ifndef CONFIG_SYS_HELP_CMD_WIDTH
-#define CONFIG_SYS_HELP_CMD_WIDTH  8
+#define CONFIG_SYS_HELP_CMD_WIDTH  10
 #endif
 
 #ifndef__ASSEMBLY__
-- 
2.20.1

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


Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

2019-02-27 Thread Heinrich Schuchardt
On 2/28/19 6:06 AM, AKASHI Takahiro wrote:
> On Thu, Feb 28, 2019 at 05:53:17AM +0100, Heinrich Schuchardt wrote:
>> On 2/28/19 5:45 AM, AKASHI Takahiro wrote:
>>> On Wed, Feb 27, 2019 at 08:10:36AM +0100, Heinrich Schuchardt wrote:
 On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
 On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e" allows for executing EFI application with a specific 
> "Boot"
> variable. If no "Boot" is specified or "BootOrder" is specified,
> it tries to run an EFI application specified in the order of 
> "bootOrder."
>

 If we cannot specify the device tree what would be the use of this for
 ARM processors?
>>>
>>> I don't get your point. What's the matter with device tree?
>>
>> To boot an ARM board on Linux or BSD you need a device tree.
>
> When I discussed with Alex about Boot Manager (and distro_bootcmd?),
> he suggested that we should not allow users to specify fdt at a command 
> line.
> I believe that it would apply to my case above.
>
> IMO, we should always provide system's fdt to EFI applications.

 With current Linux development practice this unfortunately does not
 work. Linux device trees sometimes see incompatible changes between
 versions. Booting may fail with a device tree that is either too old or
 too new for your Linux version.

 E.g. for the Odroid C2 some reserved memory regions were removed from
 the device tree and replaced by a logic that determines them on the fly
 due to changes in ARM trusted firmware location.

 The Wandboard rev B1 device tree was moved to a new file when a new
 board revision appeared and the new revision changed the old file (sic).

 U-Boot is also not perfect at keeping its device tree in sync with the
 newest Linux device tree.
>>>
>>> Why don't you use "fdt" command in that case?
>>> IMO, we don't need  argument at bootefi (and run -e).
>>> Obviously, I have one assumption that we need change the code
>>> to utilize "fdtaddr" variable in do_bootefi().
>>
>> Such a change would mean that after an upgrade of U-Boot all boards
>> running on Suse and Fedora suddenly will not boot again.
> 
> Why do you think so?
> Unless people intentionally run "fdt" command before bootefi,
> the system will behave in the exact same way.
> 
> How many people really expect that, in the case below,
>   => load ...  
>   => fdt addr 
>   => bootefi bootmgr
> bootefi will start EFI application *without* fdt?
> 
> -Takahiro Akashi

Your previous mail sounded to me as if you wanted to drop the
possibility to specify an FDT address in the bootefi command. But maybe
I got you wrong.

If your idea is that we should use the address specified in command fdt
and $fdtcontroladdr as fallbacks if no FDT address is specified, that is
another story.

Best regards

Heinrich

> 
>> We should not change existing commands in an incompatible way.
>>
>>>
>>> Under the current implementation, a similar behavior is achieved
>>> only via distro_bootcmd. IMO, this should be corrected.
>>> If you agree, I will add another patch to my current patchset
>>> for this purpose.
>>
>> I suggest to drop patch 5/5 from your series.
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>
>> So run -e Boot0001 will not allow you to boot into Linux because it does
>> not specify a device tree.
>>
>>>
>>>
 Why do you add the option to run and not to bootefi?

 You already introduced the capability to set BootNext. Why isn't that
 enough?
>>>
>>> Simple.
>>>
>>> => run -e Boot00>
>>> versus
>>>
>>> => efidebug boot next 1
>>> => bootefi bootmgr
>>
>> In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
>>
>> So there is no need to go through efidebug.
>>
>> I think we should avoid alternative commands.
>
> As I said, I already removed this feature from bootefi.
>
>>>
>>> First of all, efidebug is only recognized as a *debugging* tool.
>>> I believe that the former syntax is more intuitive, and it looks
>>> a natural extension to "run" command semantics akin to "env -e".
>>>
>>> As a result, we don't have to know about bootefi for normal operations.
>>
>> But you have to know about 'run' which you might not need otherwise.
>
> "run" is much better known to U-Boot users than bootefi.

 Do you have a statistic ;)

 Up to now booting always required a command starting on boot...
>>>
>>> What I meant is that people need not learn more commands.
>>>
>>> # Relating to secure boot, I'm now thinking of pulling bootmgr out of
>>> # 

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

2019-02-27 Thread AKASHI Takahiro
On Thu, Feb 28, 2019 at 05:53:17AM +0100, Heinrich Schuchardt wrote:
> On 2/28/19 5:45 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 08:10:36AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> >>> On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
>  On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> "run -e" allows for executing EFI application with a specific 
> >>> "Boot"
> >>> variable. If no "Boot" is specified or "BootOrder" is specified,
> >>> it tries to run an EFI application specified in the order of 
> >>> "bootOrder."
> >>>
> >>
> >> If we cannot specify the device tree what would be the use of this for
> >> ARM processors?
> >
> > I don't get your point. What's the matter with device tree?
> 
>  To boot an ARM board on Linux or BSD you need a device tree.
> >>>
> >>> When I discussed with Alex about Boot Manager (and distro_bootcmd?),
> >>> he suggested that we should not allow users to specify fdt at a command 
> >>> line.
> >>> I believe that it would apply to my case above.
> >>>
> >>> IMO, we should always provide system's fdt to EFI applications.
> >>
> >> With current Linux development practice this unfortunately does not
> >> work. Linux device trees sometimes see incompatible changes between
> >> versions. Booting may fail with a device tree that is either too old or
> >> too new for your Linux version.
> >>
> >> E.g. for the Odroid C2 some reserved memory regions were removed from
> >> the device tree and replaced by a logic that determines them on the fly
> >> due to changes in ARM trusted firmware location.
> >>
> >> The Wandboard rev B1 device tree was moved to a new file when a new
> >> board revision appeared and the new revision changed the old file (sic).
> >>
> >> U-Boot is also not perfect at keeping its device tree in sync with the
> >> newest Linux device tree.
> > 
> > Why don't you use "fdt" command in that case?
> > IMO, we don't need  argument at bootefi (and run -e).
> > Obviously, I have one assumption that we need change the code
> > to utilize "fdtaddr" variable in do_bootefi().
> 
> Such a change would mean that after an upgrade of U-Boot all boards
> running on Suse and Fedora suddenly will not boot again.

Why do you think so?
Unless people intentionally run "fdt" command before bootefi,
the system will behave in the exact same way.

How many people really expect that, in the case below,
  => load ...  
  => fdt addr 
  => bootefi bootmgr
bootefi will start EFI application *without* fdt?

-Takahiro Akashi

> We should not change existing commands in an incompatible way.
> 
> > 
> > Under the current implementation, a similar behavior is achieved
> > only via distro_bootcmd. IMO, this should be corrected.
> > If you agree, I will add another patch to my current patchset
> > for this purpose.
> 
> I suggest to drop patch 5/5 from your series.
> 
> Best regards
> 
> Heinrich
> 
> > 
> >>>
>  So run -e Boot0001 will not allow you to boot into Linux because it does
>  not specify a device tree.
> 
> >
> >
> >> Why do you add the option to run and not to bootefi?
> >>
> >> You already introduced the capability to set BootNext. Why isn't that
> >> enough?
> >
> > Simple.
> >
> > => run -e Boot00>
> > versus
> >
> > => efidebug boot next 1
> > => bootefi bootmgr
> 
>  In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
> 
>  So there is no need to go through efidebug.
> 
>  I think we should avoid alternative commands.
> >>>
> >>> As I said, I already removed this feature from bootefi.
> >>>
> >
> > First of all, efidebug is only recognized as a *debugging* tool.
> > I believe that the former syntax is more intuitive, and it looks
> > a natural extension to "run" command semantics akin to "env -e".
> >
> > As a result, we don't have to know about bootefi for normal operations.
> 
>  But you have to know about 'run' which you might not need otherwise.
> >>>
> >>> "run" is much better known to U-Boot users than bootefi.
> >>
> >> Do you have a statistic ;)
> >>
> >> Up to now booting always required a command starting on boot...
> > 
> > What I meant is that people need not learn more commands.
> > 
> > # Relating to secure boot, I'm now thinking of pulling bootmgr out of
> > # bootefi and making it as a single command. In that case,
> > # bootefi does exist only for hello and selftest.
> > 
> > -Takahiro Akashi
> > 
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >>> Thanks,
> >>> -Takahiro Akashi
> >>>
>  Best regards
> 
>  Heinrich
> 
> >
> > Thanks,
> > -Takahiro Akashi
> >
> >
> >> Best regards
> >>
> >> Heinrich
> >>
> 

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

2019-02-27 Thread Heinrich Schuchardt
On 2/28/19 5:45 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 08:10:36AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
>>> On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
 On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> "run -e" allows for executing EFI application with a specific "Boot"
>>> variable. If no "Boot" is specified or "BootOrder" is specified,
>>> it tries to run an EFI application specified in the order of 
>>> "bootOrder."
>>>
>>
>> If we cannot specify the device tree what would be the use of this for
>> ARM processors?
>
> I don't get your point. What's the matter with device tree?

 To boot an ARM board on Linux or BSD you need a device tree.
>>>
>>> When I discussed with Alex about Boot Manager (and distro_bootcmd?),
>>> he suggested that we should not allow users to specify fdt at a command 
>>> line.
>>> I believe that it would apply to my case above.
>>>
>>> IMO, we should always provide system's fdt to EFI applications.
>>
>> With current Linux development practice this unfortunately does not
>> work. Linux device trees sometimes see incompatible changes between
>> versions. Booting may fail with a device tree that is either too old or
>> too new for your Linux version.
>>
>> E.g. for the Odroid C2 some reserved memory regions were removed from
>> the device tree and replaced by a logic that determines them on the fly
>> due to changes in ARM trusted firmware location.
>>
>> The Wandboard rev B1 device tree was moved to a new file when a new
>> board revision appeared and the new revision changed the old file (sic).
>>
>> U-Boot is also not perfect at keeping its device tree in sync with the
>> newest Linux device tree.
> 
> Why don't you use "fdt" command in that case?
> IMO, we don't need  argument at bootefi (and run -e).
> Obviously, I have one assumption that we need change the code
> to utilize "fdtaddr" variable in do_bootefi().

Such a change would mean that after an upgrade of U-Boot all boards
running on Suse and Fedora suddenly will not boot again.

We should not change existing commands in an incompatible way.

> 
> Under the current implementation, a similar behavior is achieved
> only via distro_bootcmd. IMO, this should be corrected.
> If you agree, I will add another patch to my current patchset
> for this purpose.

I suggest to drop patch 5/5 from your series.

Best regards

Heinrich

> 
>>>
 So run -e Boot0001 will not allow you to boot into Linux because it does
 not specify a device tree.

>
>
>> Why do you add the option to run and not to bootefi?
>>
>> You already introduced the capability to set BootNext. Why isn't that
>> enough?
>
> Simple.
>
> => run -e Boot00>
> versus
>
> => efidebug boot next 1
> => bootefi bootmgr

 In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'

 So there is no need to go through efidebug.

 I think we should avoid alternative commands.
>>>
>>> As I said, I already removed this feature from bootefi.
>>>
>
> First of all, efidebug is only recognized as a *debugging* tool.
> I believe that the former syntax is more intuitive, and it looks
> a natural extension to "run" command semantics akin to "env -e".
>
> As a result, we don't have to know about bootefi for normal operations.

 But you have to know about 'run' which you might not need otherwise.
>>>
>>> "run" is much better known to U-Boot users than bootefi.
>>
>> Do you have a statistic ;)
>>
>> Up to now booting always required a command starting on boot...
> 
> What I meant is that people need not learn more commands.
> 
> # Relating to secure boot, I'm now thinking of pulling bootmgr out of
> # bootefi and making it as a single command. In that case,
> # bootefi does exist only for hello and selftest.
> 
> -Takahiro Akashi
> 
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Thanks,
>>> -Takahiro Akashi
>>>
 Best regards

 Heinrich

>
> Thanks,
> -Takahiro Akashi
>
>
>> Best regards
>>
>> Heinrich
>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  cmd/bootefi.c | 31 +++
>>>  cmd/nvedit.c  |  9 -
>>>  common/cli.c  | 10 ++
>>>  include/command.h |  3 +++
>>>  4 files changed, 52 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 241fd0f987ab..ebe149dffa1f 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
>>> return CMD_RET_SUCCESS;
>>>  }
>>>  
>>> +/* Called by "run" command */
>>> +int 

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

2019-02-27 Thread Heinrich Schuchardt
On 2/28/19 5:28 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 08:33:17PM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 7:47 AM, AKASHI Takahiro wrote:
>>> On Wed, Feb 27, 2019 at 07:31:06AM +0100, Heinrich Schuchardt wrote:
 On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> With this patch applied, we will be able to selectively execute
>>> an EFI application by specifying a load option, say "1" for Boot0001,
>>> "2" for Boot0002 and so on.
>>>
>>>   => bootefi bootmgr  1, or
>>>  bootefi bootmgr - 1
>>
>> You already introduced the support for BootNext. So is there a real 
>> benefit?
>
> This is a convenient way of running EFI application directly,
> but I already removed this feature from the next version.

 Please, remove 'run -e' instead because it cannot specify the device
 tree needed for booting ARM boards.
>>>
>>> See my comment for patch#5 first.
>>>
>
>>>
>>> Please note that Boot need not be included in "BootOrder".
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  cmd/bootefi.c | 39 ---
>>>  1 file changed, 28 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 3be01b49b589..241fd0f987ab 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
>>>  
>>>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>>>  
>>> -static int do_bootefi_bootmgr_exec(void)
>>> +static int do_bootefi_bootmgr_exec(int boot_id)
>>>  {
>>> struct efi_device_path *device_path, *file_path;
>>> void *addr;
>>> efi_status_t r;
>>>  
>>> -   addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
>>> -   _path, _path);
>>> +   addr = efi_bootmgr_load(boot_id, _path, _path);
>>> if (!addr)
>>> -   return 1;
>>> +   return CMD_RET_FAILURE;
>>>  
>>> printf("## Starting EFI application at %p ...\n", addr);
>>> r = do_bootefi_exec(addr, device_path, file_path);
>>> @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
>>>r & ~EFI_ERROR_MASK);
>>>  
>>> if (r != EFI_SUCCESS)
>>> -   return 1;
>>> +   return CMD_RET_FAILURE;
>>>  
>>> -   return 0;
>>> +   return CMD_RET_SUCCESS;
>>>  }
>>>  
>>>  /* Interpreter command to boot an arbitrary EFI image from memory */
>>> @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, 
>>> int argc, char * const argv[])
>>> } else
>>>  #endif
>>> if (!strcmp(argv[1], "bootmgr")) {
>>> -   if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
>>> -   return CMD_RET_FAILURE;
>>> +   char *fdtstr, *endp;
>>> +   int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
>>> +
>>> +   if (argc > 2) {
>>> +   fdtstr = argv[2];
>>> +/* Special address "-" means no device tree */
>>> +   if (fdtstr[0] == '-')
>>> +   fdtstr = NULL;
>>> +
>>> +   r = efi_handle_fdt(fdtstr);
>>> +   if (r)
>>> +   return CMD_RET_FAILURE;
>>> +   }
>>> +
>>> +   if (argc > 3) {
>>> +   boot_id = (int)simple_strtoul(argv[3], , 
>>> 0);
>>> +   if ((argv[3] + strlen(argv[3]) != endp) ||
>>> +   boot_id > 0x)
>>> +   return CMD_RET_USAGE;
>>> +   }
>>>  
>>> -   return do_bootefi_bootmgr_exec();
>>> +   return do_bootefi_bootmgr_exec(boot_id);
>>
>> Why not communicate via the BootNext variable?
>
> I don't get your point.
> BootNext and BootOrder are both defined by UEFI specification.

 Instead of changing the interface of do_bootefi_bootmgr_exec()
>>>
>>> Who care changing an *internal* function?
> 
> So do you agree?

What is wrong about calling efi_set_variable(L"BootNext", ) instead?
Wouldn't that result in less code?

> 
>>>
 you could
 simply set BootNext. Then the boot manager would pick up the option from
 the variable and finally delete the variable. This would result in less
 code.
>>>
>>> No. Even with "run -e," BootNext will disappear after execution.
>>> This is a requirement by UEFI spec.
>>
>> Shouldn't BootNext always be reset when executing bootefi no matter
>> whether the boot 

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

2019-02-27 Thread AKASHI Takahiro
On Wed, Feb 27, 2019 at 08:10:36AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> >>> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
>  On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > "run -e" allows for executing EFI application with a specific "Boot"
> > variable. If no "Boot" is specified or "BootOrder" is specified,
> > it tries to run an EFI application specified in the order of 
> > "bootOrder."
> >
> 
>  If we cannot specify the device tree what would be the use of this for
>  ARM processors?
> >>>
> >>> I don't get your point. What's the matter with device tree?
> >>
> >> To boot an ARM board on Linux or BSD you need a device tree.
> > 
> > When I discussed with Alex about Boot Manager (and distro_bootcmd?),
> > he suggested that we should not allow users to specify fdt at a command 
> > line.
> > I believe that it would apply to my case above.
> > 
> > IMO, we should always provide system's fdt to EFI applications.
> 
> With current Linux development practice this unfortunately does not
> work. Linux device trees sometimes see incompatible changes between
> versions. Booting may fail with a device tree that is either too old or
> too new for your Linux version.
> 
> E.g. for the Odroid C2 some reserved memory regions were removed from
> the device tree and replaced by a logic that determines them on the fly
> due to changes in ARM trusted firmware location.
> 
> The Wandboard rev B1 device tree was moved to a new file when a new
> board revision appeared and the new revision changed the old file (sic).
> 
> U-Boot is also not perfect at keeping its device tree in sync with the
> newest Linux device tree.

Why don't you use "fdt" command in that case?
IMO, we don't need  argument at bootefi (and run -e).
Obviously, I have one assumption that we need change the code
to utilize "fdtaddr" variable in do_bootefi().

Under the current implementation, a similar behavior is achieved
only via distro_bootcmd. IMO, this should be corrected.
If you agree, I will add another patch to my current patchset
for this purpose.

> > 
> >> So run -e Boot0001 will not allow you to boot into Linux because it does
> >> not specify a device tree.
> >>
> >>>
> >>>
>  Why do you add the option to run and not to bootefi?
> 
>  You already introduced the capability to set BootNext. Why isn't that
>  enough?
> >>>
> >>> Simple.
> >>>
> >>> => run -e Boot00>
> >>> versus
> >>>
> >>> => efidebug boot next 1
> >>> => bootefi bootmgr
> >>
> >> In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
> >>
> >> So there is no need to go through efidebug.
> >>
> >> I think we should avoid alternative commands.
> > 
> > As I said, I already removed this feature from bootefi.
> > 
> >>>
> >>> First of all, efidebug is only recognized as a *debugging* tool.
> >>> I believe that the former syntax is more intuitive, and it looks
> >>> a natural extension to "run" command semantics akin to "env -e".
> >>>
> >>> As a result, we don't have to know about bootefi for normal operations.
> >>
> >> But you have to know about 'run' which you might not need otherwise.
> > 
> > "run" is much better known to U-Boot users than bootefi.
> 
> Do you have a statistic ;)
> 
> Up to now booting always required a command starting on boot...

What I meant is that people need not learn more commands.

# Relating to secure boot, I'm now thinking of pulling bootmgr out of
# bootefi and making it as a single command. In that case,
# bootefi does exist only for hello and selftest.

-Takahiro Akashi

> 
> Best regards
> 
> Heinrich
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> > 
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >>> Thanks,
> >>> -Takahiro Akashi
> >>>
> >>>
>  Best regards
> 
>  Heinrich
> 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 31 +++
> >  cmd/nvedit.c  |  9 -
> >  common/cli.c  | 10 ++
> >  include/command.h |  3 +++
> >  4 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 241fd0f987ab..ebe149dffa1f 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
> > return CMD_RET_SUCCESS;
> >  }
> >  
> > +/* Called by "run" command */
> > +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> > +{
> > +   int boot_id = -1;
> > +   char *endp;
> > +
> > +   if (argc > 2)
> > +   return CMD_RET_USAGE;
> > +
> > +   if (argc == 2) {
> > +   if (!strcmp(argv[1], "BootOrder")) {
> > +  

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

2019-02-27 Thread AKASHI Takahiro
On Wed, Feb 27, 2019 at 08:33:17PM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:47 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 07:31:06AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> >>> On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
>  On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > With this patch applied, we will be able to selectively execute
> > an EFI application by specifying a load option, say "1" for Boot0001,
> > "2" for Boot0002 and so on.
> >
> >   => bootefi bootmgr  1, or
> >  bootefi bootmgr - 1
> 
>  You already introduced the support for BootNext. So is there a real 
>  benefit?
> >>>
> >>> This is a convenient way of running EFI application directly,
> >>> but I already removed this feature from the next version.
> >>
> >> Please, remove 'run -e' instead because it cannot specify the device
> >> tree needed for booting ARM boards.
> > 
> > See my comment for patch#5 first.
> > 
> >>>
> >
> > Please note that Boot need not be included in "BootOrder".
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 39 ---
> >  1 file changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3be01b49b589..241fd0f987ab 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
> >  
> >  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> >  
> > -static int do_bootefi_bootmgr_exec(void)
> > +static int do_bootefi_bootmgr_exec(int boot_id)
> >  {
> > struct efi_device_path *device_path, *file_path;
> > void *addr;
> > efi_status_t r;
> >  
> > -   addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
> > -   _path, _path);
> > +   addr = efi_bootmgr_load(boot_id, _path, _path);
> > if (!addr)
> > -   return 1;
> > +   return CMD_RET_FAILURE;
> >  
> > printf("## Starting EFI application at %p ...\n", addr);
> > r = do_bootefi_exec(addr, device_path, file_path);
> > @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
> >r & ~EFI_ERROR_MASK);
> >  
> > if (r != EFI_SUCCESS)
> > -   return 1;
> > +   return CMD_RET_FAILURE;
> >  
> > -   return 0;
> > +   return CMD_RET_SUCCESS;
> >  }
> >  
> >  /* Interpreter command to boot an arbitrary EFI image from memory */
> > @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, 
> > int argc, char * const argv[])
> > } else
> >  #endif
> > if (!strcmp(argv[1], "bootmgr")) {
> > -   if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
> > -   return CMD_RET_FAILURE;
> > +   char *fdtstr, *endp;
> > +   int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
> > +
> > +   if (argc > 2) {
> > +   fdtstr = argv[2];
> > +/* Special address "-" means no device tree */
> > +   if (fdtstr[0] == '-')
> > +   fdtstr = NULL;
> > +
> > +   r = efi_handle_fdt(fdtstr);
> > +   if (r)
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > +   if (argc > 3) {
> > +   boot_id = (int)simple_strtoul(argv[3], , 
> > 0);
> > +   if ((argv[3] + strlen(argv[3]) != endp) ||
> > +   boot_id > 0x)
> > +   return CMD_RET_USAGE;
> > +   }
> >  
> > -   return do_bootefi_bootmgr_exec();
> > +   return do_bootefi_bootmgr_exec(boot_id);
> 
>  Why not communicate via the BootNext variable?
> >>>
> >>> I don't get your point.
> >>> BootNext and BootOrder are both defined by UEFI specification.
> >>
> >> Instead of changing the interface of do_bootefi_bootmgr_exec()
> > 
> > Who care changing an *internal* function?

So do you agree?

> > 
> >> you could
> >> simply set BootNext. Then the boot manager would pick up the option from
> >> the variable and finally delete the variable. This would result in less
> >> code.
> > 
> > No. Even with "run -e," BootNext will disappear after execution.
> > This is a requirement by UEFI spec.
> 
> Shouldn't BootNext always be reset when executing bootefi no matter
> whether the boot manager is used or not?

Didn't I say the same thing?
Or do you expect that BootNext remain after "run -e"?

-Takahiro Akashi

> Regards
> 
> Heinrich
> 
> 

Re: [U-Boot] [PATCH 2/2] imx8mq_evk/README: add missing firmware extract step

2019-02-27 Thread Baruch Siach
Hi Fabio, Stefano,

On Thu, Feb 28 2019, Fabio Estevam wrote:
> On Sun, Feb 24, 2019 at 3:21 PM Baruch Siach  wrote:
>> Signed-off-by: Baruch Siach 
>> ---
>>  board/freescale/imx8mq_evk/README | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/board/freescale/imx8mq_evk/README 
>> b/board/freescale/imx8mq_evk/README
>> index e1335293a08f..2529f7da3d98 100644
>> --- a/board/freescale/imx8mq_evk/README
>> +++ b/board/freescale/imx8mq_evk/README
>> @@ -18,6 +18,7 @@ Get the ddr and hdmi firmware
>>  Note: srctree is U-Boot source directory
>>  $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
>>  $ chmod +x firmware-imx-7.9.bin
>> +$ ./firmware-imx-7.9.bin
>
> I would suggest making this one the first patch of this series.

Should I post v2 with that change?

> Tested-by: Fabio Estevam 

Thanks,
baruch

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


Re: [U-Boot] [PATCH 1/2] tools/imx8m_image.sh: remove bashism

2019-02-27 Thread Baruch Siach
Hi Fabio,

On Thu, Feb 28 2019, Fabio Estevam wrote:
> On Wed, Jan 2, 2019 at 4:59 AM Baruch Siach  wrote:
>>
>> Use a single '=' to test string equality for compatibility with non-bash
>> shells. Otherwise, if /bin/sh is dash, build fails:
>>
>> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
>> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
>> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
>> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
>> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is 
>> not-functional
>>
>> Signed-off-by: Baruch Siach 
>
> I don't see this patch applied yet.
>
> Do we have other solution?

Stefano suggested an alternative in reply to the other patch:

  https://lists.denx.de/pipermail/u-boot/2019-January/356941.html

baruch

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


Re: [U-Boot] [PATCH v9 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

2019-02-27 Thread Chee, Tien Fong
On Wed, 2019-02-27 at 10:13 +0100, Michal Simek wrote:
> On 27. 02. 19 7:37, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-02-26 at 07:58 -0800, Dalon L Westergreen wrote:
> > > 
> > > On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
> > > > 
> > > > 
> > > > On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> > > > > > 
> > > > > > 
> > > > > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > From: Tien Fong Chee 
> > > > > > > 
> > > > > > > This patch adds description on properties about file name
> > > > > > > used for
> > > > > > > both
> > > > > > > peripheral bitstream and core bitstream.
> > > > > > > 
> > > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > changes for v8
> > > > > > > - Removed explanation about support for altr,bitstream-
> > > > > > > core
> > > > > > > 
> > > > > > > changes for v7
> > > > > > > - Provided example of setting FPGA FIT image for both
> > > > > > > early
> > > > > > > IO
> > > > > > > release
> > > > > > >   and full release FPGA configuration.
> > > > > > > ---
> > > > > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
> > > > > > > +-
> > > > > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-
> > > > > > > socfpga-
> > > > > > > a10-fpga-
> > > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > > > a10-
> > > > > > > fpga-
> > > > > > > mgr.txt
> > > > > > > index 2fd8e7a..da210bf 100644
> > > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > fpga-
> > > > > > > mgr.txt
> > > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > fpga-
> > > > > > > mgr.txt
> > > > > > > @@ -7,8 +7,31 @@ Required properties:
> > > > > > > - The second index is for writing FPGA
> > > > > > > configuration data.
> > > > > > >  - resets : Phandle and reset specifier for the
> > > > > > > device's
> > > > > > > reset.
> > > > > > >  - clocks : Clocks used by the device.
> > > > > > > +- altr,bitstream : Fit image file name for both FPGA
> > > > > > > peripheral
> > > > > > > bitstream,
> > > > > > > +    FPGA core bitstream and full
> > > > > > > bitstream.
> > > > > > >  
> > > > > > By adding new required property you are automatically
> > > > > > saying
> > > > > > that you
> > > > > > want to break all current users.
> > > > > This is company's product specific property, that's why with
> > > > > prefix
> > > > > "altr". DT allows that ,right?
> > > > no issue with altr prefix. Issue is that you add a required
> > > > property and
> > > > breaking all current users.
> > > > It should be optional.
> > > This parameter is only for Arria10, which at this point is not
> > > fully
> > > supported
> > > in mainline uboot.  So this doesnt affect any existing designs,
> > > no?
> > Yeah, how this breaking all current users? This property in only
> > used
> > for the A10 fpga driver with fit implementation.
> That you use latest u-boot with previous DT(or our of tree DT which
> doesn't have this property).
Sorry, i'm still not getting you. My understanding "breaking" means the
existing driver would stop working after A10 DT is applied.
May be you can tell us breaking what driver?

What you means with previous DT? Which DT you means? This series of
patches are the 1st one fully support A10 SDMMC in mainline.

How this related to your DT?

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


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

2019-02-27 Thread Tom Rini
On Wed, Feb 27, 2019 at 01:39:44PM +0800, ub...@andestech.com wrote:

> Hi Tom,
> 
> Please pull some riscv updates:
> 
> SiFive FU540 Support
> 
> https://travis-ci.org/rickchen36/u-boot-riscv/builds/499037971
> 
> Thanks
> Rick
> 
> 
> The following changes since commit b3820ba997f004a376efc5446683101ff42b05af:
> 
>   Merge tag 'efi-2019-04-rc3' of https://github.com/xypron2/u-boot 
> (2019-02-26 08:45:08 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-riscv.git
> 
> for you to fetch changes up to 98a66ffa3aafd20d38f357d624e470e20fbb1839:
> 
>   riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd (2019-02-27 
> 09:12:34 +0800)
> 

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 v1 2/2] x86: acpi: Add DMA descriptors for I2C1 on Intel Tangier

2019-02-27 Thread Bin Meng
On Tue, Feb 26, 2019 at 7:43 PM Andy Shevchenko
 wrote:
>
> Intel Tangier SoC has a general purpose DMA which can serve to speed up
> communications on SPI and I2C serial buses.
>
> Provide DMA descriptors to utilize this capability in the future.
>
> Note, I2C6, which is available to user, has no DMA request lines connected.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../include/asm/arch-tangier/acpi/southcluster.asl| 11 +++
>  1 file changed, 11 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 v1 1/2] x86: acpi: Add DMA descriptors for SPI5 on Intel Tangier

2019-02-27 Thread Bin Meng
On Tue, Feb 26, 2019 at 7:43 PM Andy Shevchenko
 wrote:
>
> Intel Tangier SoC has a general purpose DMA which can serve to speed up
> communications on SPI and I2C serial buses.
>
> Provide DMA descriptors to utilize this capability in the future.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 3 +++
>  1 file changed, 3 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 v1 2/2] x86: edison: Add the rest of UARTs present on board

2019-02-27 Thread Bin Meng
Hi Andy,

On Tue, Feb 26, 2019 at 7:21 PM Andy Shevchenko
 wrote:
>
> Intel Edison has three UART ports, i.e.
>  port 0 - Bluetooth
>  port 1 - auxiliary, available for general purpose use
>  port 2 - debugging, usually console output is here
>
> Enable all of them for future use.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/dts/edison.dts | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
> index b59171cb50..8629f7bcf2 100644
> --- a/arch/x86/dts/edison.dts
> +++ b/arch/x86/dts/edison.dts
> @@ -17,6 +17,8 @@
> compatible = "intel,edison";
>
> aliases {
> +   serial0 = 
> +   serial1 = 
> serial2 = 
> };
>
> @@ -53,6 +55,22 @@
>   0x0100 0x0 0x2000 0x2000 0 0xe000>;
> };
>
> +   serial0: serial@ff010180 {

The reg base is wrong here, should be @ff010080

> +   compatible = "intel,mid-uart";
> +   reg = <0xff010080 0x100>;
> +   reg-shift = <0>;
> +   clock-frequency = <29491200>;
> +   current-speed = <115200>;
> +   };
> +
> +   serial1: serial@ff010180 {

ditto

> +   compatible = "intel,mid-uart";
> +   reg = <0xff010100 0x100>;
> +   reg-shift = <0>;
> +   clock-frequency = <29491200>;
> +   current-speed = <115200>;
> +   };
> +
> serial2: serial@ff010180 {
> compatible = "intel,mid-uart";
> reg = <0xff010180 0x100>;
> --

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


Re: [U-Boot] [PATCH v1 1/2] x86: edison: Use proper number of serial interface

2019-02-27 Thread Bin Meng
On Tue, Feb 26, 2019 at 7:21 PM Andy Shevchenko
 wrote:
>
> The console is actually serial #2. When we would like to enable other ports,
> this would be not okay to mess up with the ordering.
>
> Thus, fix the number of default console interface to be 2.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/dts/edison.dts | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq

2019-02-27 Thread Bin Meng
Christian, I got some time to look at this old patch, and I see my
last question remained unanswered.

+Andy,

Hi Andy,

On Thu, May 24, 2018 at 12:00 PM Bin Meng  wrote:
>
> Hi Christian,
>
> On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner
>  wrote:
> > Fixes performance related issue when running vxWorks 5/7 images.
>
> nits: vxWorks -> VxWorks
>
> > The overall memory performance (L1, L2 cache and ram) was measured
> > with Bandwidth [0].
> >
> > Without this patch we get following numbers:
> >  - sequential 128-bit reads:  ~5.2 GB/s
> >  - sequential 128-bit copy:   ~2.1 GB/s
> >  - random 32-bit writes:  ~1.2 GB/s
> >
> > With this patch patch we get the following numbers:
> >  - sequential 128-bit reads: ~18.0 GB/s
> >  - sequential 128-bit copy:   ~9.5 GB/s
> >  - random 32-bit writes:  ~5.0 GB/s
> >
> > [0] https://zsmith.co/bandwidth.html
> >
> > v1 -> v2:
> >  - incorporate feedback from Bin Meng
>
> This should not show in the commit message.
>
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  arch/x86/cpu/queensbay/Makefile |  2 +-
> >  arch/x86/cpu/queensbay/cpu.c| 58 
> > +
> >  2 files changed, 59 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/x86/cpu/queensbay/cpu.c
> >
> > diff --git a/arch/x86/cpu/queensbay/Makefile 
> > b/arch/x86/cpu/queensbay/Makefile
> > index c0681995bd..3dd23465d4 100644
> > --- a/arch/x86/cpu/queensbay/Makefile
> > +++ b/arch/x86/cpu/queensbay/Makefile
> > @@ -5,4 +5,4 @@
> >  #
> >
> >  obj-y += fsp_configs.o irq.o
> > -obj-y += tnc.o
> > +obj-y += tnc.o cpu.o
> > diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
> > new file mode 100644
> > index 00..805a94cc27
> > --- /dev/null
> > +++ b/arch/x86/cpu/queensbay/cpu.c
> > @@ -0,0 +1,58 @@
> > +/*
> > + * Copyright (C) 2018, Bachmann electronic GmbH
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static void set_max_freq(void)
> > +{
> > +   msr_t msr;
> > +
> > +   /* Enable enhanced speed step */
> > +   msr = msr_read(MSR_IA32_MISC_ENABLES);
> > +   msr.lo |= (1 << 16);
> > +   msr_write(MSR_IA32_MISC_ENABLES, msr);
> > +
> > +   /* Set new performance state */
> > +   msr = msr_read(MSR_IA32_PERF_CTL);
> > +   msr.lo = 0x101f;
> > +   msr_write(MSR_IA32_PERF_CTL, msr);
> > +}
>
> I tried to find any documentation that describes the performance state
> values of the TunnelCreek processor, but in vain. However when I read
> the doc, I do have a question here:
>
> The enhanced speedstep technology is set to disabled by the processor
> after power-on, that means we don't need set the performance state
> (P-state) via the MSR_IA32_PERF_CTL and the processor itself should
> work under its maximum base frequency. So I believe this whole
> set_max_freq() is not needed. Can you clarify this?
>

I hope you can give some clarification about Enhanced Intel Speedstep
(EIST) technology. I read Intel 64 and IA-32 Architectures SDM volume
3: chapter 14 "POWER AND THERMAL MANAGEMENT" and it does not say much
about this EIST. Especially I want to know whether the process is
running at the highest frequency if EIST is disabled which is the case
after power-on (MSR_IA32_MISC_ENABLES bit[16] is 0).

A related discussion after Googling is:
https://forums.anandtech.com/threads/actual-difference-between-speedstep-and-turbo-boost.2226820/
It says: "The base frequency is the highest P-state called P0, and
every step below that using EIST goes P1, P2, etc. Turbo Mode only
activates when the CPU is at P0 state, then every speed above the base
clock is decided by the CPU."

So to me this seems to match my understanding about EIST. If this is
true, then I can't explain why Christian's patch is needed since the
EIST is disabled on TunnelCreek by default and the processor should
already run at the highest performance.

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


Re: [U-Boot] [PATCH 1/2] tools/imx8m_image.sh: remove bashism

2019-02-27 Thread Fabio Estevam
Hi Baruch and Stefano,

On Wed, Jan 2, 2019 at 4:59 AM Baruch Siach  wrote:
>
> Use a single '=' to test string equality for compatibility with non-bash
> shells. Otherwise, if /bin/sh is dash, build fails:
>
> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is 
> not-functional
>
> Signed-off-by: Baruch Siach 

I don't see this patch applied yet.

Do we have other solution?

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


Re: [U-Boot] [PATCH 2/2] imx8mq_evk/README: add missing firmware extract step

2019-02-27 Thread Fabio Estevam
Hi Baruch,

On Sun, Feb 24, 2019 at 3:21 PM Baruch Siach  wrote:
>
> Signed-off-by: Baruch Siach 
> ---
>  board/freescale/imx8mq_evk/README | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/board/freescale/imx8mq_evk/README 
> b/board/freescale/imx8mq_evk/README
> index e1335293a08f..2529f7da3d98 100644
> --- a/board/freescale/imx8mq_evk/README
> +++ b/board/freescale/imx8mq_evk/README
> @@ -18,6 +18,7 @@ Get the ddr and hdmi firmware
>  Note: srctree is U-Boot source directory
>  $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
>  $ chmod +x firmware-imx-7.9.bin
> +$ ./firmware-imx-7.9.bin

I would suggest making this one the first patch of this series.

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


Re: [U-Boot] [PATCH 1/2] imx8mq_evk/README: fix DDR training firmware path

2019-02-27 Thread Fabio Estevam
On Sun, Feb 24, 2019 at 3:22 PM Baruch Siach  wrote:
>
> Remove a redundant directory level.
>
> Reported-by: Ofer Heifetz 
> Signed-off-by: Baruch Siach 

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


Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

2019-02-27 Thread Oleksandr Tyshchenko
Hi, Marek

sorry for possible format issue.


ср, 27 февр. 2019 г., 23:02 Marek Vasut :

> On 2/26/19 8:37 PM, Oleksandr wrote:
> >
> > Hi, Marek
>
> Hi,
>
>  +}
>  +
>  +/*
>  + * Reset vector for secondary CPUs.
>  + * This will be mapped at address 0 by SBAR register.
>  + * We need _long_ jump to the physical address.
>  + */
>  +asm(".arm\n"
>  +".align 12\n"
>  +".globl shmobile_boot_vector\n"
>  +"shmobile_boot_vector:\n"
>  +"ldr r1, 1f\n"
>  +"bxr1\n"
>  +".type shmobile_boot_vector, %function\n"
>  +".size shmobile_boot_vector, .-shmobile_boot_vector\n"
>  +".align2\n"
>  +".globlshmobile_boot_fn\n"
>  +"shmobile_boot_fn:\n"
>  +"1:.space4\n"
>  +".globlshmobile_boot_size\n"
>  +"shmobile_boot_size:\n"
>  +".long.-shmobile_boot_vector\n");
> >>> Why can't this be implemented in C ?
> >> This "reset vector" code was ported from Linux:
> >>
> >>
> https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/headsmp.S#L21
> >>
> >>
> >>
> >>
> >> Really don't know whether it can be implemented in C.
> >>
> >> I was thinking of moving this code to a separate ASM file in order
> >> not
> >> to mix C and ASM. What do you think about it?
> > U-Boot already has a reset vector code, can't that be reused ?
>  I don't think. Being honest, I couldn't find an obvious way how to
>  reuse
>  (I assume you meant arch/arm/cpu/armv7/start.S).
> >>> Maybe it needs some additional work first ?
> >>> It seems Altera socfpga somehow uses the U-Boot reset vectors for PSCI,
> >>> so it should at least be possible.
> >>
> >> Could you, please, point me in code? Unfortunately, I wasn't able to
> >> find.
> >>
> >>
> >>>
>  The newly turned on secondary CPU entry should be common
>  "psci_cpu_entry", which does proper things.
> 
>  And this reset vector is just "a small piece of code" to be located in
>  on-chip RAM (with limited size) and used for the jump stub...
> >>> We already have the SPL reset vectors in SRAM, maybe that can be
> >>> recycled somehow ?
> >>
> >>
> >> The only idea I have, how it may be recycled (not sure whether it will
> >> work...)
> >>
> >>
> >> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> >> index 0cb6dd39cc..69acf4677b 100644
> >> --- a/arch/arm/cpu/armv7/start.S
> >> +++ b/arch/arm/cpu/armv7/start.S
> >> @@ -36,6 +36,12 @@
> >>  #endif
> >>
> >>  reset:
> >> +
> >> +#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
> >> +   b psci_cpu_entry_jump
> >> +   /* return only if this is not "a newly turned on CPU" using
> >> PSCI) */
> >> +#endif
> >> +
> >> /* Allow the board to save important registers */
> >> b   save_boot_params
> >>  save_boot_params_ret:
> >> @@ -128,6 +134,21 @@ ENDPROC(switch_to_hypervisor)
> >> .weak   switch_to_hypervisor
> >>  #endif
> >>
> >> +/*
> >> + * Each platform which implements psci_cpu_entry_jump function should
> >> perform
> >> + * in the following way:
> >> + *
> >> + * If the executing this call CPU is exactly that CPU we are
> >> expecting to be
> >> + * powered on, then jump to psci_cpu_entry and never return.
> >> + * Otherwise return to the caller.
> >> + */
> >> +#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
> >> +ENTRY(psci_cpu_entry_jump)
> >> +   movspc, lr
> >> +ENDPROC(psci_cpu_entry_jump)
> >> +.weak psci_cpu_entry_jump
> >> +#endif
> >> +
> >>
>  /*
> >>
> >>   *
> >>   * cpu_init_cp15
> >>
> >>
> >> What do you think?
> >>
> >>
> >> It would be much appreciated, if you could provide some hints.
> >
> >
> > Don't want to be annoying, but it would be really nice to get my
> > questions answered...
>
> I am sorry, I am too busy right now. I will answer that once I can
> properly study the problem and give you a useful answer.
>

No problem, I will wait.

Thank you.


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


Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

2019-02-27 Thread Marek Vasut
On 2/26/19 7:37 PM, Oleksandr wrote:
> 
> Hi, Marek

Hi,

>>>
 2. It should be new pm-r8a7791.c file which will don't have any CA7
 related stuff (CPU cores, SCU, etc).
>>> I'd like to have a generic pm-gen2.c file , which parses the DT and
>>> figures the configuration out that way. We are trying to get rid of all
>>> the ad-hoc hardcoded configuration stuff in favor of DT.
>>>
 Or it should be the single pm-r8a779x.c which must distinguish what SoC
 is being used and do proper things.
>>> Right
>>
>>
>> I agree to have a single generic pm-gen2.c file which covers all Gen2
>> SoCs.
>>
>> But, unfortunately, I only have Stout boards (H2), and therefore can
>> check only on them. This is why the current patch series adds support
>> for H2 SoC only.
>>
>> Theoretically, I could add support for M2 as well, but, I wouldn't
>> have possibility to check.
>>
>>
>> I would focus on the r8a7790 for now, as the Stout board is our
>> nearest target which we want to support in Xen and the PSCI feature is
>> a mandatory option.
>>
>> What do you think?
> 
> Could you, please, answer that question...

I am sorry, I am too busy right now. I will answer that once I can
properly study the problem and give you a useful answer.

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


Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

2019-02-27 Thread Marek Vasut
On 2/26/19 8:37 PM, Oleksandr wrote:
> 
> Hi, Marek

Hi,

 +}
 +
 +/*
 + * Reset vector for secondary CPUs.
 + * This will be mapped at address 0 by SBAR register.
 + * We need _long_ jump to the physical address.
 + */
 +asm("    .arm\n"
 +    "    .align 12\n"
 +    "    .globl shmobile_boot_vector\n"
 +    "shmobile_boot_vector:\n"
 +    "    ldr r1, 1f\n"
 +    "    bx    r1\n"
 +    "    .type shmobile_boot_vector, %function\n"
 +    "    .size shmobile_boot_vector, .-shmobile_boot_vector\n"
 +    "    .align    2\n"
 +    "    .globl    shmobile_boot_fn\n"
 +    "shmobile_boot_fn:\n"
 +    "1:    .space    4\n"
 +    "    .globl    shmobile_boot_size\n"
 +    "shmobile_boot_size:\n"
 +    "    .long    .-shmobile_boot_vector\n");
>>> Why can't this be implemented in C ?
>> This "reset vector" code was ported from Linux:
>>
>> https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/headsmp.S#L21
>>
>>
>>
>>
>> Really don't know whether it can be implemented in C.
>>
>> I was thinking of moving this code to a separate ASM file in order
>> not
>> to mix C and ASM. What do you think about it?
> U-Boot already has a reset vector code, can't that be reused ?
 I don't think. Being honest, I couldn't find an obvious way how to
 reuse
 (I assume you meant arch/arm/cpu/armv7/start.S).
>>> Maybe it needs some additional work first ?
>>> It seems Altera socfpga somehow uses the U-Boot reset vectors for PSCI,
>>> so it should at least be possible.
>>
>> Could you, please, point me in code? Unfortunately, I wasn't able to
>> find.
>>
>>
>>>
 The newly turned on secondary CPU entry should be common
 "psci_cpu_entry", which does proper things.

 And this reset vector is just "a small piece of code" to be located in
 on-chip RAM (with limited size) and used for the jump stub...
>>> We already have the SPL reset vectors in SRAM, maybe that can be
>>> recycled somehow ?
>>
>>
>> The only idea I have, how it may be recycled (not sure whether it will
>> work...)
>>
>>
>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>> index 0cb6dd39cc..69acf4677b 100644
>> --- a/arch/arm/cpu/armv7/start.S
>> +++ b/arch/arm/cpu/armv7/start.S
>> @@ -36,6 +36,12 @@
>>  #endif
>>
>>  reset:
>> +
>> +#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
>> +   b psci_cpu_entry_jump
>> +   /* return only if this is not "a newly turned on CPU" using
>> PSCI) */
>> +#endif
>> +
>>     /* Allow the board to save important registers */
>>     b   save_boot_params
>>  save_boot_params_ret:
>> @@ -128,6 +134,21 @@ ENDPROC(switch_to_hypervisor)
>>     .weak   switch_to_hypervisor
>>  #endif
>>
>> +/*
>> + * Each platform which implements psci_cpu_entry_jump function should
>> perform
>> + * in the following way:
>> + *
>> + * If the executing this call CPU is exactly that CPU we are
>> expecting to be
>> + * powered on, then jump to psci_cpu_entry and never return.
>> + * Otherwise return to the caller.
>> + */
>> +#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
>> +ENTRY(psci_cpu_entry_jump)
>> +   movs    pc, lr
>> +ENDPROC(psci_cpu_entry_jump)
>> +.weak psci_cpu_entry_jump
>> +#endif
>> +
>>  /*
>>
>>   *
>>   * cpu_init_cp15
>>
>>
>> What do you think?
>>
>>
>> It would be much appreciated, if you could provide some hints.
> 
> 
> Don't want to be annoying, but it would be really nice to get my
> questions answered...

I am sorry, I am too busy right now. I will answer that once I can
properly study the problem and give you a useful answer.

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


Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

2019-02-27 Thread Heinrich Schuchardt
On 2/27/19 7:47 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:31:06AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
 On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> With this patch applied, we will be able to selectively execute
> an EFI application by specifying a load option, say "1" for Boot0001,
> "2" for Boot0002 and so on.
>
>   => bootefi bootmgr  1, or
>  bootefi bootmgr - 1

 You already introduced the support for BootNext. So is there a real 
 benefit?
>>>
>>> This is a convenient way of running EFI application directly,
>>> but I already removed this feature from the next version.
>>
>> Please, remove 'run -e' instead because it cannot specify the device
>> tree needed for booting ARM boards.
> 
> See my comment for patch#5 first.
> 
>>>
>
> Please note that Boot need not be included in "BootOrder".
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 39 ---
>  1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 3be01b49b589..241fd0f987ab 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
>  
>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>  
> -static int do_bootefi_bootmgr_exec(void)
> +static int do_bootefi_bootmgr_exec(int boot_id)
>  {
>   struct efi_device_path *device_path, *file_path;
>   void *addr;
>   efi_status_t r;
>  
> - addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
> - _path, _path);
> + addr = efi_bootmgr_load(boot_id, _path, _path);
>   if (!addr)
> - return 1;
> + return CMD_RET_FAILURE;
>  
>   printf("## Starting EFI application at %p ...\n", addr);
>   r = do_bootefi_exec(addr, device_path, file_path);
> @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
>  r & ~EFI_ERROR_MASK);
>  
>   if (r != EFI_SUCCESS)
> - return 1;
> + return CMD_RET_FAILURE;
>  
> - return 0;
> + return CMD_RET_SUCCESS;
>  }
>  
>  /* Interpreter command to boot an arbitrary EFI image from memory */
> @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, 
> int argc, char * const argv[])
>   } else
>  #endif
>   if (!strcmp(argv[1], "bootmgr")) {
> - if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
> - return CMD_RET_FAILURE;
> + char *fdtstr, *endp;
> + int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
> +
> + if (argc > 2) {
> + fdtstr = argv[2];
> +  /* Special address "-" means no device tree */
> + if (fdtstr[0] == '-')
> + fdtstr = NULL;
> +
> + r = efi_handle_fdt(fdtstr);
> + if (r)
> + return CMD_RET_FAILURE;
> + }
> +
> + if (argc > 3) {
> + boot_id = (int)simple_strtoul(argv[3], , 0);
> + if ((argv[3] + strlen(argv[3]) != endp) ||
> + boot_id > 0x)
> + return CMD_RET_USAGE;
> + }
>  
> - return do_bootefi_bootmgr_exec();
> + return do_bootefi_bootmgr_exec(boot_id);

 Why not communicate via the BootNext variable?
>>>
>>> I don't get your point.
>>> BootNext and BootOrder are both defined by UEFI specification.
>>
>> Instead of changing the interface of do_bootefi_bootmgr_exec()
> 
> Who care changing an *internal* function?
> 
>> you could
>> simply set BootNext. Then the boot manager would pick up the option from
>> the variable and finally delete the variable. This would result in less
>> code.
> 
> No. Even with "run -e," BootNext will disappear after execution.
> This is a requirement by UEFI spec.

Shouldn't BootNext always be reset when executing bootefi no matter
whether the boot manager is used or not?

Regards

Heinrich

> 
> Thanks,
> -Takahiro Akashi
> 
>> Best regards
>>
>> Heinrich
>>
>>>
>   } else {
>   saddr = argv[1];
>  
> @@ -590,7 +607,7 @@ static char bootefi_help_text[] =
>   "Use environment variable efi_selftest to select a single test.\n"
>   "Use 'setenv efi_selftest list' to enumerate all tests.\n"
>  #endif
> - "bootefi bootmgr [fdt addr]\n"
> + "bootefi bootmgr [|'-' []]\n"
>   "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
>   "\n"
>   "If specified, the device tree located at  gets\n"
> @@ -598,7 +615,7 @@ static char bootefi_help_text[] =
>  #endif
>  
>  

Re: [U-Boot] [PATCH] efi_loader: Fix serial console size detection

2019-02-27 Thread Heinrich Schuchardt
On 2/27/19 10:55 AM, Matthias Brugger wrote:
> 
> 
> On 26/02/2019 17:58, Heinrich Schuchardt wrote:
>> On 2/26/19 12:46 PM, matthias@kernel.org wrote:
>>> From: Matthias Brugger 
>>>
>>> Function term_read_reply tries to read from the serial console until
>>> the end_char was read. This can hang forever if we are, for some reason,
>>> not be able to read the full response (e.g. serial buffer too small,
>>> frame error). This patch moves the timeout detection into
>>> term_read_reply to assure we will make progress.
>>>
>>> Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
>>> Signed-off-by: Matthias Brugger 
>>
>> Thanks Matthias for the patch.
>>
>> The general direction is right. Yet I would prefer if you could move the
>> waiting loop as described below.
>>
>>> ---
>>>  lib/efi_loader/efi_console.c | 63 +---
>>>  1 file changed, 37 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>> index 66c33a551d..817220455f 100644
>>> --- a/lib/efi_loader/efi_console.c
>>> +++ b/lib/efi_loader/efi_console.c
>>> @@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode = {
>>> .cursor_visible = 1,
>>>  };
>>>  
>>> +static int term_get_char(char *c)
>>> +{
>>> +   if (tstc()) {
>>> +   *c = getc();
>>> +   return 0;
>>> +   }
>>> +
>>> +   return 1;
>>
>> The function signals an error if the character to read is not yet in the
>> UART buffer. I think it would be preferable to put the waiting time (100
>> ms is sufficient at 110 baud and above) into this function instead. This
>> has the following advantages:
>>
>> - We would need only one waiting loop.
>> - We could reuse the function in function efi_cin_read_key() where we
>>   have another chance to hang waiting for a character.
>>
> 
> Ok, I'll do that in v2.
> 
>>> +}
>>> +
>>>  /*
>>>   * Receive and parse a reply from the terminal.
>>>   *
>>> @@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char 
>>> end_char)
>>>  {
>>> char c;
>>> int i = 0;
>>> +   u64 timeout;
>>>  
>>> -   c = getc();
>>> -   if (c != cESC)
>>> +   /* Allow up to one second for the response */
>>> +   timeout = timer_get_us() + 100;
>>
>> Even at 110 baud a waiting time of 100 ms is sufficient.
>>
> 
> So we don't have to wait up to one second for the first character to arrive as
> we did in query_console_serial() before this patch?

Teterminal will respond immediately when we query the size. Even at 110
baud it should be sufficient to wait for a maximum of 100 ms for the
first character.

> 
>>> +   while (!tstc())
>>> +   if (timer_get_us() > timeout)
>>> +   return -1;
>>
>> This loop could be moved to term_get_char().
>>
>>> +
>>> +   if (term_get_char() || c != cESC)
>>> return -1;
>>> -   c = getc();
>>> -   if (c != '[')
>>> +
>>> +   if (term_get_char() || c != '[')
>>
>> We should allow time for this character to arrive.
>>
>>> return -1;
>>>  
>>> n[0] = 0;
>>> while (1) {
>>> -   c = getc();
>>> -   if (c == ';') {
>>> -   i++;
>>> -   if (i >= num)> +if (!term_get_char()) 
>>> {
>>
>> On loop entry there is no wait before this term_get_char().
> 
> I don't understand, if the character is not yet present, we will loop in the
> while until it arrives or we hit the timeout.

We should not loop forever. If the next character is not received within
100 ms we should error out.

Best regards

Heinrich

> 
> Regards,
> Matthias
> 
>>
>> Best regards
>>
>> Heinrich
>>
>>> +   if (c == ';') {
>>> +   i++;
>>> +   if (i >= num)
>>> +   return -1;
>>> +   n[i] = 0;
>>> +   continue;
>>> +   } else if (c == end_char) {
>>> +   break;
>>> +   } else if (c > '9' || c < '0') {
>>> return -1;
>>> -   n[i] = 0;
>>> -   continue;
>>> -   } else if (c == end_char) {
>>> -   break;
>>> -   } else if (c > '9' || c < '0') {
>>> -   return -1;
>>> +   }
>>> +
>>> +   /* Read one more decimal position */
>>> +   n[i] *= 10;
>>> +   n[i] += c - '0';
>>> }
>>>  
>>> -   /* Read one more decimal position */
>>> -   n[i] *= 10;
>>> -   n[i] += c - '0';
>>> +   if (timer_get_us() > timeout)
>>> +   return -1;
>>> }
>>> if (i != num - 1)
>>> return -1;
>>> @@ -196,7 +216,6 @@ static int query_console_serial(int *rows, int *cols)
>>>  {
>>> int ret = 0;
>>> int n[2];
>>> -   u64 timeout;
>>>  
>>> /* Empty input buffer */
>>> while (tstc())
>>> @@ -216,14 

[U-Boot] [PATCH 1/1] configs: tinker-rk3288 disable CONFIG_SPL_I2C_SUPPORT

2019-02-27 Thread Heinrich Schuchardt
The SPL for the Tinker Board has to fit into 32 KiB. Currently this limit
is exceeded.

CONFIG_SPL_I2C_SUPPORT is not needed to move to main U-Boot. So let's
disable it.

Suggested-by: David Wu 
Signed-off-by: Heinrich Schuchardt 
---
This solves only one of the problems with the boards in v2019.04.
The next problem is that reading the environment from MMC fails.

The patch
[PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
https://lists.denx.de/pipermail/u-boot/2019-February/358883.html
makes the problem visibe.
---
 configs/tinker-rk3288_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/tinker-rk3288_defconfig b/configs/tinker-rk3288_defconfig
index 68adf7635bf..03a7f81d63d 100644
--- a/configs/tinker-rk3288_defconfig
+++ b/configs/tinker-rk3288_defconfig
@@ -18,7 +18,6 @@ CONFIG_DEFAULT_FDT_FILE="rk3288-tinker.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
-CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
-- 
2.20.1

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


[U-Boot] [PATCH v3 06/13] test/dm: clk: Add clk_get_by_index[_nodev] test

2019-02-27 Thread Jagan Teki
Add sample dm clk test for clk_get_by_index and
clk_get_by_index_nodev functionality code.

Cc: Stephen Warren 
Signed-off-by: Jagan Teki 
Reviewed-by: Simon Glass 
---
 test/dm/clk.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/test/dm/clk.c b/test/dm/clk.c
index 898c034e27..29ef6ef41b 100644
--- a/test/dm/clk.c
+++ b/test/dm/clk.c
@@ -4,12 +4,33 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
+/* Base test of the clk uclass */
+static int dm_test_clk_base(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   struct clk clk_method1;
+   struct clk clk_method2;
+
+   /* Get the device using the clk device */
+   ut_assertok(uclass_get_device_by_name(UCLASS_MISC, "clk-test", ));
+
+   /* Get the same clk port in 2 different ways and compare */
+   ut_assertok(clk_get_by_index(dev, 1, _method1));
+   ut_assertok(clk_get_by_index_nodev(dev_ofnode(dev), 1, _method2));
+   ut_asserteq(clk_method1.id, clk_method2.id);
+
+   return 0;
+}
+
+DM_TEST(dm_test_clk_base, DM_TESTF_SCAN_FDT);
+
 static int dm_test_clk(struct unit_test_state *uts)
 {
struct udevice *dev_fixed, *dev_clk, *dev_test;
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 13/13] board: sunxi: gmac: Remove Ethernet clock and reset

2019-02-27 Thread Jagan Teki
Since Ethernet clock and reset is now handling via
CLK and RESET frameworks via driver API's remove
explicit ccm writes.

Signed-off-by: Jagan Teki 
---
 board/sunxi/gmac.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index 826650c89b..d8fdf7728e 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -12,14 +12,6 @@ void eth_init_board(void)
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
-   /* Set up clock gating */
-#ifdef CONFIG_SUNXI_GEN_SUN6I
-   setbits_le32(>ahb_reset0_cfg, 0x1 << AHB_RESET_OFFSET_GMAC);
-   setbits_le32(>ahb_gate0, 0x1 << AHB_GATE_OFFSET_GMAC);
-#else
-   setbits_le32(>ahb_gate1, 0x1 << AHB_GATE_OFFSET_GMAC);
-#endif
-
/* Set MII clock */
 #ifdef CONFIG_RGMII
setbits_le32(>gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 03/13] net: sun8i_emac: Retrieve GMAC clock via 'syscon' phandle

2019-02-27 Thread Jagan Teki
Unlike other Allwinner SoC's R40 GMAC clock control register
is locate in CCU, but rest located via syscon itself. Since
the phandle property for current code look for 'syscon' and
it will grab the respective ccu or syscon base address based
on DT property defined in respective SoC dtsi.

So, use the existing 'syscon' code even for R40 for retrieving
GMAC clock via CCU and update the register directly in
sun8i_emac_set_syscon instead of writing it separately using
ccm base.

Cc: Joe Hershberger 
Cc: Lothar Felten 
Signed-off-by: Jagan Teki 
---
 drivers/net/sun8i_emac.c | 55 
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index c9798445c7..a7fb7ac405 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -285,10 +285,18 @@ static int sun8i_emac_set_syscon(struct sun8i_eth_pdata 
*pdata,
int ret;
u32 reg;
 
-   reg = readl(priv->sysctl_reg + 0x30);
+   if (priv->variant == R40_GMAC) {
+   /* Select RGMII for R40 */
+   reg = readl(priv->sysctl_reg + 0x164);
+   reg |= CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
+  CCM_GMAC_CTRL_GPIT_RGMII |
+  CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY);
 
-   if (priv->variant == R40_GMAC)
+   writel(reg, priv->sysctl_reg + 0x164);
return 0;
+   }
+
+   reg = readl(priv->sysctl_reg + 0x30);
 
if (priv->variant == H3_EMAC) {
ret = sun8i_emac_set_syscon_ephy(priv, );
@@ -662,13 +670,6 @@ static void sun8i_emac_board_setup(struct emac_eth_dev 
*priv)
 
/* De-assert EMAC */
setbits_le32(>ahb_gate1, BIT(AHB_GATE_OFFSET_GMAC));
-
-   /* Select RGMII for R40 */
-   setbits_le32(>gmac_clk_cfg,
-CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
-CCM_GMAC_CTRL_GPIT_RGMII);
-   setbits_le32(>gmac_clk_cfg,
-CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY));
} else {
/* Set clock gating for emac */
setbits_le32(>ahb_gate0, BIT(AHB_GATE_OFFSET_GMAC));
@@ -850,25 +851,23 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
return -EINVAL;
}
 
-   if (priv->variant != R40_GMAC) {
-   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
-   if (offset < 0) {
-   debug("%s: cannot find syscon node\n", __func__);
-   return -EINVAL;
-   }
-   reg = fdt_getprop(gd->fdt_blob, offset, "reg", NULL);
-   if (!reg) {
-   debug("%s: cannot find reg property in syscon node\n",
- __func__);
-   return -EINVAL;
-   }
-   priv->sysctl_reg = fdt_translate_address((void *)gd->fdt_blob,
-offset, reg);
-   if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
-   debug("%s: Cannot find syscon base address\n",
- __func__);
-   return -EINVAL;
-   }
+   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
+   if (offset < 0) {
+   debug("%s: cannot find syscon node\n", __func__);
+   return -EINVAL;
+   }
+
+   reg = fdt_getprop(gd->fdt_blob, offset, "reg", NULL);
+   if (!reg) {
+   debug("%s: cannot find reg property in syscon node\n",
+ __func__);
+   return -EINVAL;
+   }
+   priv->sysctl_reg = fdt_translate_address((void *)gd->fdt_blob,
+offset, reg);
+   if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
+   debug("%s: Cannot find syscon base address\n", __func__);
+   return -EINVAL;
}
 
pdata->phy_interface = -1;
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 12/13] net: sun8i_emac: Add EPHY CLK and RESET support

2019-02-27 Thread Jagan Teki
Add EPHY CLK and RESET support for sun8i_emac driver to
enable EPHY TX clock and EPHY reset pins via CLK and RESET
framework.

Cc: Joe Hershberger 
Cc: Lothar Felten 
Signed-off-by: Jagan Teki 
---
 drivers/net/sun8i_emac.c | 74 +++-
 1 file changed, 57 insertions(+), 17 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 98bd7a5823..c0a440886e 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -138,7 +138,9 @@ struct emac_eth_dev {
struct phy_device *phydev;
struct mii_dev *bus;
struct clk tx_clk;
+   struct clk ephy_clk;
struct reset_ctl tx_rst;
+   struct reset_ctl ephy_rst;
 #ifdef CONFIG_DM_GPIO
struct gpio_desc reset_gpio;
 #endif
@@ -653,7 +655,6 @@ static int sun8i_eth_write_hwaddr(struct udevice *dev)
 
 static int sun8i_emac_board_setup(struct emac_eth_dev *priv)
 {
-   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
int ret;
 
ret = clk_enable(>tx_clk);
@@ -670,16 +671,20 @@ static int sun8i_emac_board_setup(struct emac_eth_dev 
*priv)
}
}
 
-   if (priv->variant == H3_EMAC) {
-   /* Only H3/H5 have clock controls for internal EPHY */
-   if (priv->use_internal_phy) {
-   /* Set clock gating for ephy */
-   setbits_le32(>bus_gate4,
-BIT(AHB_GATE_OFFSET_EPHY));
-
-   /* Deassert EPHY */
-   setbits_le32(>ahb_reset2_cfg,
-BIT(AHB_RESET_OFFSET_EPHY));
+   /* Only H3/H5 have clock controls for internal EPHY */
+   if (clk_valid(>ephy_clk)) {
+   ret = clk_enable(>ephy_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable EPHY TX clock\n");
+   return ret;
+   }
+   }
+
+   if (reset_valid(>ephy_rst)) {
+   ret = reset_deassert(>ephy_rst);
+   if (ret) {
+   dev_err(dev, "failed to deassert EPHY TX clock\n");
+   return ret;
}
}
 
@@ -839,6 +844,44 @@ static const struct eth_ops sun8i_emac_eth_ops = {
.stop   = sun8i_emac_eth_stop,
 };
 
+static int sun8i_get_ephy_nodes(struct emac_eth_dev *priv)
+{
+   int node, ret;
+
+   /* look for mdio-mux node for internal PHY node */
+   node = fdt_path_offset(gd->fdt_blob,
+   "/soc/ethernet@1c3/mdio-mux/mdio@1/ethernet-phy@1");
+   if (node < 0) {
+   debug("failed to get mdio-mux with internal PHY\n");
+   return node;
+   }
+
+   ret = fdt_node_check_compatible(gd->fdt_blob, node,
+   "allwinner,sun8i-h3-mdio-internal");
+   if (ret < 0) {
+   debug("failed to find mdio-internal node\n");
+   return ret;
+   }
+
+   ret = clk_get_by_index_nodev(offset_to_ofnode(node), 0,
+>ephy_clk);
+   if (ret) {
+   dev_err(dev, "failed to get EPHY TX clock\n");
+   return ret;
+   }
+
+   ret = reset_get_by_index_nodev(offset_to_ofnode(node), 0,
+  >ephy_rst);
+   if (ret) {
+   dev_err(dev, "failed to get EPHY TX reset\n");
+   return ret;
+   }
+
+   priv->use_internal_phy = true;
+
+   return 0;
+}
+
 static int sun8i_emac_eth_ofdata_to_platdata(struct udevice *dev)
 {
struct sun8i_eth_pdata *sun8i_pdata = dev_get_platdata(dev);
@@ -920,12 +963,9 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
}
 
if (priv->variant == H3_EMAC) {
-   int parent = fdt_parent_offset(gd->fdt_blob, offset);
-
-   if (parent >= 0 &&
-   !fdt_node_check_compatible(gd->fdt_blob, parent,
-   "allwinner,sun8i-h3-mdio-internal"))
-   priv->use_internal_phy = true;
+   ret = sun8i_get_ephy_nodes(priv);
+   if (ret)
+   return ret;
}
 
priv->interface = pdata->phy_interface;
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 11/13] clk: sunxi: h3: Implement EPHY CLK and RESET

2019-02-27 Thread Jagan Teki
EPHY CLK and RESET is available in Allwinner H3 EMAC
via mdio-mux node of internal PHY. Add the respetive
clock and reset reg and bits.

Cc: Joe Hershberger 
Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/clk_h3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
index f5ae1e9555..6111a13f1c 100644
--- a/drivers/clk/sunxi/clk_h3.c
+++ b/drivers/clk/sunxi/clk_h3.c
@@ -34,6 +34,8 @@ static struct ccu_clk_gate h3_gates[] = {
[CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
[CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
 
+   [CLK_BUS_EPHY]  = GATE(0x070, BIT(0)),
+
[CLK_SPI0]  = GATE(0x0a0, BIT(31)),
[CLK_SPI1]  = GATE(0x0a4, BIT(31)),
 
@@ -69,6 +71,8 @@ static struct ccu_reset h3_resets[] = {
[RST_BUS_OHCI2] = RESET(0x2c0, BIT(30)),
[RST_BUS_OHCI3] = RESET(0x2c0, BIT(31)),
 
+   [RST_BUS_EPHY]  = RESET(0x2c8, BIT(2)),
+
[RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
[RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
[RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 09/13] clk: sunxi: Implement EMAC, GMAC clocks, resets

2019-02-27 Thread Jagan Teki
- Implement EMAC, GMAC clocks via ccu_clk_gate for
  all supported Allwinner SoCs.
- Implement EMAC, GMAC resets via ccu_reset for all
  supported Allwinner SoCs.

Cc: Joe Hershberger 
Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/clk_a31.c  | 2 ++
 drivers/clk/sunxi/clk_a64.c  | 2 ++
 drivers/clk/sunxi/clk_a83t.c | 2 ++
 drivers/clk/sunxi/clk_h3.c   | 2 ++
 drivers/clk/sunxi/clk_h6.c   | 4 
 drivers/clk/sunxi/clk_r40.c  | 3 +++
 6 files changed, 15 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index fa6e3eeef0..4ec3c2ae89 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -17,6 +17,7 @@ static struct ccu_clk_gate a31_gates[] = {
[CLK_AHB1_MMC1] = GATE(0x060, BIT(9)),
[CLK_AHB1_MMC2] = GATE(0x060, BIT(10)),
[CLK_AHB1_MMC3] = GATE(0x060, BIT(11)),
+   [CLK_AHB1_EMAC] = GATE(0x060, BIT(17)),
[CLK_AHB1_SPI0] = GATE(0x060, BIT(20)),
[CLK_AHB1_SPI1] = GATE(0x060, BIT(21)),
[CLK_AHB1_SPI2] = GATE(0x060, BIT(22)),
@@ -57,6 +58,7 @@ static struct ccu_reset a31_resets[] = {
[RST_AHB1_MMC1] = RESET(0x2c0, BIT(9)),
[RST_AHB1_MMC2] = RESET(0x2c0, BIT(10)),
[RST_AHB1_MMC3] = RESET(0x2c0, BIT(11)),
+   [RST_AHB1_EMAC] = RESET(0x2c0, BIT(17)),
[RST_AHB1_SPI0] = RESET(0x2c0, BIT(20)),
[RST_AHB1_SPI1] = RESET(0x2c0, BIT(21)),
[RST_AHB1_SPI2] = RESET(0x2c0, BIT(22)),
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index 322d6cd557..f94e8aa754 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -16,6 +16,7 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_EMAC]  = GATE(0x060, BIT(17)),
[CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
[CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
@@ -49,6 +50,7 @@ static const struct ccu_reset a64_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_EMAC]  = RESET(0x2c0, BIT(17)),
[RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
[RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(23)),
diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
index 36f7e14c45..2be87a31fd 100644
--- a/drivers/clk/sunxi/clk_a83t.c
+++ b/drivers/clk/sunxi/clk_a83t.c
@@ -16,6 +16,7 @@ static struct ccu_clk_gate a83t_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_EMAC]  = GATE(0x060, BIT(17)),
[CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
[CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
@@ -47,6 +48,7 @@ static struct ccu_reset a83t_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_EMAC]  = RESET(0x2c0, BIT(17)),
[RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
[RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
index 5f99ef7342..f5ae1e9555 100644
--- a/drivers/clk/sunxi/clk_h3.c
+++ b/drivers/clk/sunxi/clk_h3.c
@@ -16,6 +16,7 @@ static struct ccu_clk_gate h3_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_EMAC]  = GATE(0x060, BIT(17)),
[CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
[CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
@@ -55,6 +56,7 @@ static struct ccu_reset h3_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_EMAC]  = RESET(0x2c0, BIT(17)),
[RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
[RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(23)),
diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
index 71f0c78656..0bb00f449a 100644
--- a/drivers/clk/sunxi/clk_h6.c
+++ b/drivers/clk/sunxi/clk_h6.c
@@ -26,6 

[U-Boot] [PATCH v3 10/13] net: sun8i_emac: Add CLK and RESET support

2019-02-27 Thread Jagan Teki
Add CLK and RESET support for sun8i_emac driver to
enable TX clock and reset pins via CLK and RESET
framework.

Cc: Joe Hershberger 
Cc: Lothar Felten 
Signed-off-by: Jagan Teki 
---
 drivers/net/sun8i_emac.c | 57 +---
 1 file changed, 42 insertions(+), 15 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index a7fb7ac405..98bd7a5823 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_DM_GPIO
 #include 
@@ -135,6 +137,8 @@ struct emac_eth_dev {
phys_addr_t sysctl_reg;
struct phy_device *phydev;
struct mii_dev *bus;
+   struct clk tx_clk;
+   struct reset_ctl tx_rst;
 #ifdef CONFIG_DM_GPIO
struct gpio_desc reset_gpio;
 #endif
@@ -647,9 +651,24 @@ static int sun8i_eth_write_hwaddr(struct udevice *dev)
return _sun8i_write_hwaddr(priv, pdata->enetaddr);
 }
 
-static void sun8i_emac_board_setup(struct emac_eth_dev *priv)
+static int sun8i_emac_board_setup(struct emac_eth_dev *priv)
 {
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   int ret;
+
+   ret = clk_enable(>tx_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable TX clock\n");
+   return ret;
+   }
+
+   if (reset_valid(>tx_rst)) {
+   ret = reset_deassert(>tx_rst);
+   if (ret) {
+   dev_err(dev, "failed to deassert TX reset\n");
+   goto err_tx_clk;
+   }
+   }
 
if (priv->variant == H3_EMAC) {
/* Only H3/H5 have clock controls for internal EPHY */
@@ -664,19 +683,11 @@ static void sun8i_emac_board_setup(struct emac_eth_dev 
*priv)
}
}
 
-   if (priv->variant == R40_GMAC) {
-   /* Set clock gating for emac */
-   setbits_le32(>ahb_reset1_cfg, BIT(AHB_RESET_OFFSET_GMAC));
-
-   /* De-assert EMAC */
-   setbits_le32(>ahb_gate1, BIT(AHB_GATE_OFFSET_GMAC));
-   } else {
-   /* Set clock gating for emac */
-   setbits_le32(>ahb_gate0, BIT(AHB_GATE_OFFSET_GMAC));
+   return 0;
 
-   /* De-assert EMAC */
-   setbits_le32(>ahb_reset0_cfg, BIT(AHB_RESET_OFFSET_GMAC));
-   }
+err_tx_clk:
+   clk_disable(>tx_clk);
+   return ret;
 }
 
 #if defined(CONFIG_DM_GPIO)
@@ -803,10 +814,14 @@ static int sun8i_emac_eth_probe(struct udevice *dev)
struct sun8i_eth_pdata *sun8i_pdata = dev_get_platdata(dev);
struct eth_pdata *pdata = _pdata->eth_pdata;
struct emac_eth_dev *priv = dev_get_priv(dev);
+   int ret;
 
priv->mac_reg = (void *)pdata->iobase;
 
-   sun8i_emac_board_setup(priv);
+   ret = sun8i_emac_board_setup(priv);
+   if (ret)
+   return ret;
+
sun8i_emac_set_syscon(sun8i_pdata, priv);
 
sun8i_mdio_init(dev->name, dev);
@@ -835,8 +850,8 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct udevice 
*dev)
int offset = 0;
 #ifdef CONFIG_DM_GPIO
int reset_flags = GPIOD_IS_OUT;
-   int ret = 0;
 #endif
+   int ret;
 
pdata->iobase = devfdt_get_addr(dev);
if (pdata->iobase == FDT_ADDR_T_NONE) {
@@ -851,6 +866,18 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
return -EINVAL;
}
 
+   ret = clk_get_by_name(dev, "stmmaceth", >tx_clk);
+   if (ret) {
+   dev_err(dev, "failed to get TX clock\n");
+   return ret;
+   }
+
+   ret = reset_get_by_name(dev, "stmmaceth", >tx_rst);
+   if (ret && ret != -ENOENT) {
+   dev_err(dev, "failed to get TX reset\n");
+   return ret;
+   }
+
offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
if (offset < 0) {
debug("%s: cannot find syscon node\n", __func__);
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 07/13] reset: Get the RESET by index without device

2019-02-27 Thread Jagan Teki
Getting a RESET by index with device is not straight forward
for some use-cases like handling clock operations for child
node in parent driver. So we need to process the child node
in parent probe via ofnode and process RESET operation for child
without udevice but with ofnode.

So add reset_get_by_index_nodev() and move the common code
in reset_get_by_index_tail() to use for reset_get_by_index()

Cc: Stephen Warren 
Signed-off-by: Jagan Teki 
Reviewed-by: Simon Glass 
---
 drivers/reset/reset-uclass.c | 53 
 include/reset.h  | 16 +++
 2 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index 89e39c6b5a..ee1a423ffb 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -29,41 +29,34 @@ static int reset_of_xlate_default(struct reset_ctl 
*reset_ctl,
return 0;
 }
 
-int reset_get_by_index(struct udevice *dev, int index,
-  struct reset_ctl *reset_ctl)
+static int reset_get_by_index_tail(int ret, ofnode node,
+  struct ofnode_phandle_args *args,
+  const char *list_name, int index,
+  struct reset_ctl *reset_ctl)
 {
-   struct ofnode_phandle_args args;
-   int ret;
struct udevice *dev_reset;
struct reset_ops *ops;
 
-   debug("%s(dev=%p, index=%d, reset_ctl=%p)\n", __func__, dev, index,
- reset_ctl);
+   assert(reset_ctl);
reset_ctl->dev = NULL;
-
-   ret = dev_read_phandle_with_args(dev, "resets", "#reset-cells", 0,
- index, );
-   if (ret) {
-   debug("%s: fdtdec_parse_phandle_with_args() failed: %d\n",
- __func__, ret);
+   if (ret)
return ret;
-   }
 
-   ret = uclass_get_device_by_ofnode(UCLASS_RESET, args.node,
+   ret = uclass_get_device_by_ofnode(UCLASS_RESET, args->node,
  _reset);
if (ret) {
debug("%s: uclass_get_device_by_ofnode() failed: %d\n",
  __func__, ret);
-   debug("%s %d\n", ofnode_get_name(args.node), args.args[0]);
+   debug("%s %d\n", ofnode_get_name(args->node), args->args[0]);
return ret;
}
ops = reset_dev_ops(dev_reset);
 
reset_ctl->dev = dev_reset;
if (ops->of_xlate)
-   ret = ops->of_xlate(reset_ctl, );
+   ret = ops->of_xlate(reset_ctl, args);
else
-   ret = reset_of_xlate_default(reset_ctl, );
+   ret = reset_of_xlate_default(reset_ctl, args);
if (ret) {
debug("of_xlate() failed: %d\n", ret);
return ret;
@@ -78,6 +71,32 @@ int reset_get_by_index(struct udevice *dev, int index,
return 0;
 }
 
+int reset_get_by_index(struct udevice *dev, int index,
+  struct reset_ctl *reset_ctl)
+{
+   struct ofnode_phandle_args args;
+   int ret;
+
+   ret = dev_read_phandle_with_args(dev, "resets", "#reset-cells", 0,
+index, );
+
+   return reset_get_by_index_tail(ret, dev_ofnode(dev), , "resets",
+  index > 0, reset_ctl);
+}
+
+int reset_get_by_index_nodev(ofnode node, int index,
+struct reset_ctl *reset_ctl)
+{
+   struct ofnode_phandle_args args;
+   int ret;
+
+   ret = ofnode_parse_phandle_with_args(node, "resets", "#reset-cells", 0,
+index > 0, );
+
+   return reset_get_by_index_tail(ret, node, , "resets",
+  index > 0, reset_ctl);
+}
+
 int reset_get_bulk(struct udevice *dev, struct reset_ctl_bulk *bulk)
 {
int i, ret, err, count;
diff --git a/include/reset.h b/include/reset.h
index 65aa7a4ce5..57bbc0b49d 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -6,6 +6,7 @@
 #ifndef _RESET_H
 #define _RESET_H
 
+#include 
 #include 
 
 /**
@@ -99,6 +100,21 @@ struct reset_ctl_bulk {
 int reset_get_by_index(struct udevice *dev, int index,
   struct reset_ctl *reset_ctl);
 
+/**
+ * reset_get_by_index_nodev - Get/request a reset signal by integer index
+ * without a device.
+ *
+ * This is a version of reset_get_by_index() that does not use a device.
+ *
+ * @node:  The client ofnode.
+ * @index: The index of the reset signal to request, within the client's
+ * list of reset signals.
+ * @reset_ctl  A pointer to a reset control struct to initialize.
+ * @return 0 if OK, or a negative error code.
+ */
+int reset_get_by_index_nodev(ofnode node, int index,
+struct reset_ctl *reset_ctl);
+
 /**
  * reset_get_bulk - Get/request all reset signals of a device.
  *
-- 
2.18.0.321.gffc6fa0e3


[U-Boot] [PATCH v3 08/13] test/dm: reset: Add reset_get_by_index[_nodev] test

2019-02-27 Thread Jagan Teki
Add sample dm reset test for reset_get_by_index and
reset_get_by_index_nodev functionality code.

Cc: Stephen Warren 
Signed-off-by: Jagan Teki 
Reviewed-by: Simon Glass 
---
 test/dm/reset.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/test/dm/reset.c b/test/dm/reset.c
index c02866a2f0..c61daed490 100644
--- a/test/dm/reset.c
+++ b/test/dm/reset.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,28 @@
 /* This is the other reset phandle specifier handled by bulk */
 #define OTHER_RESET_ID 2
 
+/* Base test of the reset uclass */
+static int dm_test_reset_base(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   struct reset_ctl reset_method1;
+   struct reset_ctl reset_method2;
+
+   /* Get the device using the reset device */
+   ut_assertok(uclass_get_device_by_name(UCLASS_MISC, "reset-ctl-test",
+ ));
+
+   /* Get the same reset port in 2 different ways and compare */
+   ut_assertok(reset_get_by_index(dev, 1, _method1));
+   ut_assertok(reset_get_by_index_nodev(dev_ofnode(dev), 1,
+_method2));
+   ut_asserteq(reset_method1.id, reset_method2.id);
+
+   return 0;
+}
+
+DM_TEST(dm_test_reset_base, DM_TESTF_SCAN_FDT);
+
 static int dm_test_reset(struct unit_test_state *uts)
 {
struct udevice *dev_reset;
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 05/13] clk: Use clk_get_by_index_tail()

2019-02-27 Thread Jagan Teki
clk_get_by_index_tail() now handle common clk get by index
code so use it from clk_get_by_indexed_prop().

Cc: Stephen Warren 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- use clk_get_by_index_tail() from clk_get_by_indexed_prop()

 drivers/clk/clk-uclass.c | 24 ++--
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index d9236c5b51..79b3b0494c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -99,8 +99,6 @@ static int clk_get_by_indexed_prop(struct udevice *dev, const 
char *prop_name,
 {
int ret;
struct ofnode_phandle_args args;
-   struct udevice *dev_clk;
-   const struct clk_ops *ops;
 
debug("%s(dev=%p, index=%d, clk=%p)\n", __func__, dev, index, clk);
 
@@ -115,27 +113,9 @@ static int clk_get_by_indexed_prop(struct udevice *dev, 
const char *prop_name,
return ret;
}
 
-   ret = uclass_get_device_by_ofnode(UCLASS_CLK, args.node, _clk);
-   if (ret) {
-   debug("%s: uclass_get_device_by_of_offset failed: err=%d\n",
- __func__, ret);
-   return ret;
-   }
-
-   clk->dev = dev_clk;
-
-   ops = clk_dev_ops(dev_clk);
 
-   if (ops->of_xlate)
-   ret = ops->of_xlate(clk, );
-   else
-   ret = clk_of_xlate_default(clk, );
-   if (ret) {
-   debug("of_xlate() failed: %d\n", ret);
-   return ret;
-   }
-
-   return clk_request(dev_clk, clk);
+   return clk_get_by_index_tail(ret, dev_ofnode(dev), , "clocks",
+index > 0, clk);
 }
 
 int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 04/13] clk: Get the CLK by index without device

2019-02-27 Thread Jagan Teki
Getting a CLK by index with device is not straight forward
for some use-cases like handling clock operations for child
node in parent driver. So we need to process the child node
in parent probe via ofnode and process CLK operation for child
without udevice but with ofnode.

So add clk_get_by_index_nodev() and move the common code
in clk_get_by_index_tail() to use for clk_get_by_index()

Cc: Stephen Warren 
Signed-off-by: Jagan Teki 
Reviewed-by: Simon Glass 
---
 drivers/clk/clk-uclass.c | 61 +++-
 include/clk.h| 15 ++
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 844b87cc33..d9236c5b51 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -54,6 +54,46 @@ static int clk_of_xlate_default(struct clk *clk,
return 0;
 }
 
+static int clk_get_by_index_tail(int ret, ofnode node,
+struct ofnode_phandle_args *args,
+const char *list_name, int index,
+struct clk *clk)
+{
+   struct udevice *dev_clk;
+   const struct clk_ops *ops;
+
+   assert(clk);
+   clk->dev = NULL;
+   if (ret)
+   goto err;
+
+   ret = uclass_get_device_by_ofnode(UCLASS_CLK, args->node, _clk);
+   if (ret) {
+   debug("%s: uclass_get_device_by_of_offset failed: err=%d\n",
+ __func__, ret);
+   return ret;
+   }
+
+   clk->dev = dev_clk;
+
+   ops = clk_dev_ops(dev_clk);
+
+   if (ops->of_xlate)
+   ret = ops->of_xlate(clk, args);
+   else
+   ret = clk_of_xlate_default(clk, args);
+   if (ret) {
+   debug("of_xlate() failed: %d\n", ret);
+   return ret;
+   }
+
+   return clk_request(dev_clk, clk);
+err:
+   debug("%s: Node '%s', property '%s', failed to request CLK index %d: 
%d\n",
+ __func__, ofnode_get_name(node), list_name, index, ret);
+   return ret;
+}
+
 static int clk_get_by_indexed_prop(struct udevice *dev, const char *prop_name,
   int index, struct clk *clk)
 {
@@ -100,7 +140,26 @@ static int clk_get_by_indexed_prop(struct udevice *dev, 
const char *prop_name,
 
 int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
 {
-   return clk_get_by_indexed_prop(dev, "clocks", index, clk);
+   struct ofnode_phandle_args args;
+   int ret;
+
+   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+index, );
+
+   return clk_get_by_index_tail(ret, dev_ofnode(dev), , "clocks",
+index > 0, clk);
+}
+
+int clk_get_by_index_nodev(ofnode node, int index, struct clk *clk)
+{
+   struct ofnode_phandle_args args;
+   int ret;
+
+   ret = ofnode_parse_phandle_with_args(node, "clocks", "#clock-cells", 0,
+index > 0, );
+
+   return clk_get_by_index_tail(ret, node, , "clocks",
+index > 0, clk);
 }
 
 int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
diff --git a/include/clk.h b/include/clk.h
index 8e366163f9..d24e99713a 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -8,6 +8,7 @@
 #ifndef _CLK_H_
 #define _CLK_H_
 
+#include 
 #include 
 #include 
 
@@ -100,6 +101,20 @@ int clk_get_by_index_platdata(struct udevice *dev, int 
index,
  */
 int clk_get_by_index(struct udevice *dev, int index, struct clk *clk);
 
+/**
+ * clock_get_by_index_nodev - Get/request a clock by integer index
+ * without a device.
+ *
+ * This is a version of clk_get_by_index() that does not use a device.
+ *
+ * @node:  The client ofnode.
+ * @index: The index of the clock to request, within the client's list of
+ * clocks.
+ * @clock  A pointer to a clock struct to initialize.
+ * @return 0 if OK, or a negative error code.
+ */
+int clk_get_by_index_nodev(ofnode node, int index, struct clk *clk);
+
 /**
  * clock_get_bulk - Get/request all clocks of a device.
  *
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 02/13] net: sunxi_emac: Add CLK support

2019-02-27 Thread Jagan Teki
Add CLk support for sunxi_emac to enable AHB_EMAC clock
via CLK framework.

Cc: Joe Hershberger 
Signed-off-by: Jagan Teki 
---
 drivers/net/sunxi_emac.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index 8dbd3c50c1..9a5f7fd3c7 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -157,6 +158,7 @@ struct sunxi_sramc_regs {
 
 struct emac_eth_dev {
struct emac_regs *regs;
+   struct clk clk;
struct mii_dev *bus;
struct phy_device *phydev;
int link_printed;
@@ -500,14 +502,12 @@ static int _sunxi_emac_eth_send(struct emac_eth_dev 
*priv, void *packet,
return 0;
 }
 
-static void sunxi_emac_board_setup(struct emac_eth_dev *priv)
+static int sunxi_emac_board_setup(struct emac_eth_dev *priv)
 {
-   struct sunxi_ccm_reg *const ccm =
-   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
struct sunxi_sramc_regs *sram =
(struct sunxi_sramc_regs *)SUNXI_SRAMC_BASE;
struct emac_regs *regs = priv->regs;
-   int pin;
+   int pin, ret;
 
/* Map SRAM to EMAC */
setbits_le32(>ctrl1, 0x5 << 2);
@@ -517,10 +517,16 @@ static void sunxi_emac_board_setup(struct emac_eth_dev 
*priv)
sunxi_gpio_set_cfgpin(pin, SUNXI_GPA_EMAC);
 
/* Set up clock gating */
-   setbits_le32(>ahb_gate0, 0x1 << AHB_GATE_OFFSET_EMAC);
+   ret = clk_enable(>clk);
+   if (ret) {
+   dev_err(dev, "failed to enable emac clock\n");
+   return ret;
+   }
 
/* Set MII clock */
clrsetbits_le32(>mac_mcfg, 0xf << 2, 0xd << 2);
+
+   return 0;
 }
 
 static int sunxi_emac_eth_start(struct udevice *dev)
@@ -557,9 +563,19 @@ static int sunxi_emac_eth_probe(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct emac_eth_dev *priv = dev_get_priv(dev);
+   int ret;
 
priv->regs = (struct emac_regs *)pdata->iobase;
-   sunxi_emac_board_setup(priv);
+
+   ret = clk_get_by_index(dev, 0, >clk);
+   if (ret) {
+   dev_err(dev, "failed to get emac clock\n");
+   return ret;
+   }
+
+   ret = sunxi_emac_board_setup(priv);
+   if (ret)
+   return ret;
 
return sunxi_emac_init_phy(priv, dev);
 }
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 01/13] clk: sunxi: Implement A10 EMAC clocks

2019-02-27 Thread Jagan Teki
Implement EMAC clocks via ccu_clk_gate for Allwinner A10 SoC.

Which would eventually used in sunxi_emac.c driver.

Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/clk_a10.c  | 1 +
 drivers/clk/sunxi/clk_a10s.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index b8b57e2b31..15ffe5ecb3 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -22,6 +22,7 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
[CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
+   [CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
[CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
[CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
[CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index c6fcede822..33d41d47b0 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -19,6 +19,7 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
[CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
[CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
[CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 00/13] net: Add Allwinner EMAC CLK, RESET support

2019-02-27 Thread Jagan Teki
This is v2 version for Allwinner EMAC CLK, RESET support, which
was initially be a part of previous series[1].

Changes for v3:
- rebase on master
- collecet review tags from Simon
- fixed the comment by Simon, keep clk_get_by_indexed_prop()
  and call clk_get_by_index_tail
Changes for v2:
- rebase on master
- add dm tests for new clk and reset functions.

Any inputs?
Jagan.

[1] https://patchwork.ozlabs.org/cover/1039666/

Jagan Teki (13):
  clk: sunxi: Implement A10 EMAC clocks
  net: sunxi_emac: Add CLK support
  net: sun8i_emac: Retrieve GMAC clock via 'syscon' phandle
  clk: Get the CLK by index without device
  clk: Use clk_get_by_index_tail()
  test/dm: clk: Add clk_get_by_index[_nodev] test
  reset: Get the RESET by index without device
  test/dm: reset: Add reset_get_by_index[_nodev] test
  clk: sunxi: Implement EMAC, GMAC clocks, resets
  net: sun8i_emac: Add CLK and RESET support
  clk: sunxi: h3: Implement EPHY CLK and RESET
  net: sun8i_emac: Add EPHY CLK and RESET support
  board: sunxi: gmac: Remove Ethernet clock and reset

 board/sunxi/gmac.c   |   8 --
 drivers/clk/clk-uclass.c |  75 ++
 drivers/clk/sunxi/clk_a10.c  |   1 +
 drivers/clk/sunxi/clk_a10s.c |   1 +
 drivers/clk/sunxi/clk_a31.c  |   2 +
 drivers/clk/sunxi/clk_a64.c  |   2 +
 drivers/clk/sunxi/clk_a83t.c |   2 +
 drivers/clk/sunxi/clk_h3.c   |   6 ++
 drivers/clk/sunxi/clk_h6.c   |   4 +
 drivers/clk/sunxi/clk_r40.c  |   3 +
 drivers/net/sun8i_emac.c | 184 ---
 drivers/net/sunxi_emac.c |  28 --
 drivers/reset/reset-uclass.c |  53 ++
 include/clk.h|  15 +++
 include/reset.h  |  16 +++
 test/dm/clk.c|  21 
 test/dm/reset.c  |  23 +
 17 files changed, 336 insertions(+), 108 deletions(-)

-- 
2.18.0.321.gffc6fa0e3

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


Re: [U-Boot] [PATCH v2] configs: dra7xx_evm: Remove ENV_IS_IN_FAT

2019-02-27 Thread Tom Rini
On Tue, Feb 26, 2019 at 10:45:44PM +0530, Faiz Abbas wrote:

> With U-boot supporting environment in multiple places, enable only
> ENV_IS_IN_EMMC
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
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 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB

2019-02-27 Thread Tom Rini
On Wed, Feb 27, 2019 at 11:15:23AM +0100, Simon Goldschmidt wrote:
> Tom,
> 
> On Thu, Feb 14, 2019 at 10:20 AM Simon Goldschmidt
>  wrote:
> >
> > On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt  
> > wrote:
> > >
> > > The SPL image for the Tinker Board has to fit into 32 KiB. This includes
> > > up to 2 KiB for the file header.
> > >
> > > A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is introduced
> > > to define the board specific limit.
> > >
> > > Signed-off-by: Heinrich Schuchardt 
> >
> > Reviewed-by: Simon Goldschmidt 
> 
> Is this planned for v2019.04? I know we're in rc phase, but this patch
> adds a new config
> option so shouldn't interfere with boards not using it.
> 
> Plus if we have this SPL size check in v2019.04, it would probably
> enable more board
> maintainers testing/fixing the SPL size check after the release.

I really want to get the generic version of this in, yes.

-- 
Tom


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


Re: [U-Boot] [PATCH v2 4/4] configs: ti_omap5_common: Add NAND environment settings

2019-02-27 Thread Tom Rini
On Wed, Feb 27, 2019 at 01:29:38PM +0530, Faiz Abbas wrote:

> Now that NAND is supported on DRA71x include various NAND environment
> settings
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


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


[U-Boot] Commit "arm: kirkwood: configs: dreamplug: Convert to DM_SPI" breaks u-boot on Dreamplug

2019-02-27 Thread Leigh Brown

Hello,

Vagrant Cascadian asked for people to test the version of u-boot 
packaged

for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
working correctly.  I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.

This is the second issue that I found, and it causes u-boot to not 
detect
the SPI flash on the system.  I bisected the issue to the following 
commit:


commit 6aaf76beb131c2ff2b7184c2d63c2c63e5ab339c
Author: Chris Packham 
Date:   Wed Nov 21 22:22:23 2018 +1300

arm: kirkwood: configs: dreamplug: Convert to DM_SPI

Enable CONFIG_DM_SPI=y and CONFIG_DM_SPI_FLASH=y in the defconfig.

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

The error manifests itself as follows:

U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
Marvell-DreamPlug

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

A successful boot looks more like this:

U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +)
Marvell-DreamPlug

SoC:   Kirkwood 88F6281_A1
SPI:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB, 
total 2 MiB


Unfortunately, I don't know where to start to diagnose the issue.  Could
anyone provide any pointers?  Happy to test any suggestions.

Regards,

Leigh.

--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

2019-02-27 Thread Stephen Warren

On 2/26/19 7:36 PM, Masahiro Yamada wrote:

On Wed, Feb 27, 2019 at 11:17 AM Masahiro Yamada
 wrote:


On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren  wrote:


From: Stephen Warren 

Without this, the arch-dtbs target only gets evaluated when building
U-Boot the first time, not when re-building (incrementally building)
U-Boot. Thus incremental builds ignore changes to DTB files.



Really?

I tested "touch DT, then incremental build",
and it correctly re-compiled device tree.


I attached the log of the following build sequence:

[1] make jetson-tk1_defconfig
[2] make CROSS_COMPILE=arm-linux-gnueabihf-
[3] touch  arch/arm/dts/tegra124-jetson-tk1.dts
[4] make CROSS_COMPILE=arm-linux-gnueabihf-


Hmm, OK. Understood.

The jetson DT was recompiled,
but the other tegra DT files were not.


Yes, perhaps I should have mentioned that I found this issue when 
building sandbox. Sandbox's default DTB of sandbox.dtb does get 
recompiled as expected, but test.dtb (used by the test/py/ test system) 
does not, for incremental builds.

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


[U-Boot] [PATCH] arm: arm64 32bit address relocation

2019-02-27 Thread Ibai Erkiaga
Current relocation code is limited to 21bit PC-relative addressing
which might not be enough for bigger code sizes. The following patch
increases the addressing to 32bit PC-relative. This feature is
specially interesting if U-Boot is build without optimiation (-O0) as
the text section is increased significativelly.

Signed-off-by: Ibai Erkiaga 
---

 arch/arm/lib/relocate_64.S | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
index 7603f52..6e9658b 100644
--- a/arch/arm/lib/relocate_64.S
+++ b/arch/arm/lib/relocate_64.S
@@ -26,9 +26,10 @@ ENTRY(relocate_code)
/*
 * Copy u-boot from flash to RAM
 */
-   adr x1, __image_copy_start  /* x1 <- Run &__image_copy_start */
-   subsx9, x0, x1  /* x8 <- Run to copy offset */
-   b.eqrelocate_done   /* skip relocation */
+   adrpx1, __image_copy_start  /* x1 <- address bits [31:12] */
+   add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] */
+   subsx9, x0, x1  /* x8 <- Run to copy offset */
+   b.eqrelocate_done   /* skip relocation */
/*
 * Don't ldr x1, __image_copy_start here, since if the code is already
 * running at an address other than it was linked to, that instruction
@@ -42,8 +43,10 @@ ENTRY(relocate_code)
ldr x1, _TEXT_BASE  /* x1 <- Linked &__image_copy_start */
subsx9, x0, x1  /* x9 <- Link to copy offset */
 
-   adr x1, __image_copy_start  /* x1 <- Run &__image_copy_start */
-   adr x2, __image_copy_end/* x2 <- Run &__image_copy_end */
+   adrpx1, __image_copy_start  /* x1 <- address bits [31:12] */
+   add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] */
+   adrpx2, __image_copy_end/* x2 <- address bits [31:12] */
+   add x2, x2, :lo12:__image_copy_end  /* x2 <- address bits [11:00] */
 copy_loop:
ldp x10, x11, [x1], #16 /* copy from source address [x1] */
stp x10, x11, [x0], #16 /* copy to   target address [x0] */
@@ -54,8 +57,10 @@ copy_loop:
/*
 * Fix .rela.dyn relocations
 */
-   adr x2, __rel_dyn_start /* x2 <- Run &__rel_dyn_start */
-   adr x3, __rel_dyn_end   /* x3 <- Run &__rel_dyn_end */
+   adrpx2, __rel_dyn_start /* x2 <- address bits [31:12] */
+   add x2, x2, :lo12:__rel_dyn_start   /* x2 <- address bits [11:00] */
+   adrpx3, __rel_dyn_end   /* x3 <- address bits [31:12] */
+   add x3, x3, :lo12:__rel_dyn_end /* x3 <- address bits [11:00] */
 fixloop:
ldp x0, x1, [x2], #16   /* (x0,x1) <- (SRC location, fixup) */
ldr x4, [x2], #8/* x4 <- addend */
-- 
1.8.3.1

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


[U-Boot] [PATCH 16/19] stm32mp1: basic boot: SPL enable access to GPIOZ bank

2019-02-27 Thread Patrick Delaunay
SPL need to set GPIOZ_SECCFGR = 0 to enable access to GPIOZ bank
(open security).

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cpu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 5d79bde..f39941e 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -18,6 +18,7 @@
 #define RCC_DBGCFGR(STM32_RCC_BASE + 0x080C)
 #define RCC_BDCR   (STM32_RCC_BASE + 0x0140)
 #define RCC_MP_APB5ENSETR  (STM32_RCC_BASE + 0x0208)
+#define RCC_MP_AHB5ENSETR  (STM32_RCC_BASE + 0x0210)
 #define RCC_BDCR_VSWRSTBIT(31)
 #define RCC_BDCR_RTCSRCGENMASK(17, 16)
 #define RCC_DBGCFGR_DBGCKENBIT(8)
@@ -44,6 +45,9 @@
 #define DBGMCU_IDC_REV_ID_MASK GENMASK(31, 16)
 #define DBGMCU_IDC_REV_ID_SHIFT16
 
+/* GPIOZ registers */
+#define GPIOZ_SECCFGR  0x54004030
+
 /* boot interface from Bootrom
  * - boot instance = bit 31:16
  * - boot device = bit 15:0
@@ -135,6 +139,10 @@ static void security_init(void)
 * Bit 16 ITAMP1E: RTC power domain supply monitoring
 */
writel(0x0, TAMP_CR1);
+
+   /* GPIOZ: deactivate the security */
+   writel(BIT(0), RCC_MP_AHB5ENSETR);
+   writel(0x0, GPIOZ_SECCFGR);
 }
 #endif /* CONFIG_STM32MP1_TRUSTED */
 
-- 
2.7.4

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


[U-Boot] [PATCH 08/19] stm32mp1: update bootcmd

2019-02-27 Thread Patrick Delaunay
Clearly separate bootcmd for stm32mp1 board
(bootcmd_stm32mp) and preboot management.
That solve issue for fastboot continue command.

Signed-off-by: Patrick Delaunay 
---

 board/st/stm32mp1/stm32mp1.c|  1 +
 configs/stm32mp15_basic_defconfig   |  1 +
 configs/stm32mp15_trusted_defconfig |  1 +
 include/configs/stm32mp1.h  | 37 +++--
 4 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 48da459..0d963c2 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index b1d09fb..4ab29ee 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
 CONFIG_SPL_I2C_SUPPORT=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 9be7319..1bb3d0d 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_STM32MP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_PROMPT="STM32MP> "
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_ELF is not set
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 4722672..48da1e3 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -10,8 +10,6 @@
 #include 
 #include 
 
-#define CONFIG_PREBOOT
-
 /*
  * Number of clock ticks in 1 sec
  */
@@ -75,20 +73,38 @@
 #define CONFIG_SYS_MMC_MAX_DEVICE  3
 #define CONFIG_SUPPORT_EMMC_BOOT
 
-#if !defined(CONFIG_SPL) || !defined(CONFIG_SPL_BUILD)
+/*/
+#ifdef CONFIG_DISTRO_DEFAULTS
+/*/
+
+#if !defined(CONFIG_SPL_BUILD)
 
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 1) \
func(MMC, mmc, 0) \
func(MMC, mmc, 2)
+/*
+ * bootcmd for stm32mp1:
+ * for serial/usb: execute the stm32prog command
+ * for mmc boot (eMMC, SD card), boot only on the same device
+ * for nand boot, boot with on ubifs partition on nand
+ * for nor boot, use the default order
+ */
+#define CONFIG_PREBOOT
 
-#include 
+#define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
+   "echo \"Boot over ${boot_device}${boot_instance}!\";" \
+   "if test ${boot_device} = serial || test ${boot_device} = usb;" \
+   "then stm32prog ${boot_device} ${boot_instance}; " \
+   "else " \
+   "if test ${boot_device} = mmc;" \
+   "then env set boot_targets \"mmc${boot_instance}\"; fi;" \
+   "if test ${boot_device} = nand;" \
+   "then env set boot_targets ubifs0; fi;" \
+   "run distro_bootcmd;" \
+   "fi;\0"
 
-#define STM32MP_PREBOOT\
-   "echo \"Boot over ${boot_device}${boot_instance}!\"; " \
-   "if test \"${boot_device}\" = \"mmc\"; then " \
-   "env set boot_targets \"mmc${boot_instance}\"; "\
-   "fi;"
+#include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"scriptaddr=0xC000\0" \
@@ -98,9 +114,10 @@
"ramdisk_addr_r=0xC410\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "preboot=" STM32MP_PREBOOT "\0" \
+   STM32MP_BOOTCMD \
BOOTENV
 
 #endif /* ifndef CONFIG_SPL_BUILD */
+#endif /* ifdef CONFIG_DISTRO_DEFAULTS*/
 
 #endif /* __CONFIG_H */
-- 
2.7.4

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


[U-Boot] [PATCH 15/19] stm32mp1: align serial number on bootrom

2019-02-27 Thread Patrick Delaunay
Always use upper case for serial number.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 305ea6d..5d79bde 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -507,7 +507,7 @@ static int setup_serial_number(void)
if (ret < 0)
return ret;
 
-   sprintf(serial_string, "%08x%08x%08x", otp[0], otp[1], otp[2]);
+   sprintf(serial_string, "%08X%08X%08X", otp[0], otp[1], otp[2]);
env_set("serial#", serial_string);
 
return 0;
-- 
2.7.4

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


[U-Boot] [PATCH 18/19] stm32mp1: bsec: shadow all the upper OTP (no secure) during boot

2019-02-27 Thread Patrick Delaunay
Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/bsec.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index 8c5a299..9ed8d8c 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -171,7 +171,7 @@ static int bsec_shadow_register(u32 base, u32 otp)
ret = bsec_power_safmem(base, true);
if (ret)
return ret;
-   power_up = 1;
+   power_up = true;
}
/* set BSEC_OTP_CTRL_OFF with the otp value*/
writel(otp | BSEC_READ, base + BSEC_OTP_CTRL_OFF);
@@ -433,6 +433,21 @@ static int stm32mp_bsec_ofdata_to_platdata(struct udevice 
*dev)
return 0;
 }
 
+#ifndef CONFIG_STM32MP1_TRUSTED
+static int stm32mp_bsec_probe(struct udevice *dev)
+{
+   int otp;
+   struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
+
+   /* update unlocked shadow for OTP cleared by the rom code */
+   for (otp = 57; otp <= BSEC_OTP_MAX_VALUE; otp++)
+   if (!bsec_read_SR_lock(plat->base, otp))
+   bsec_shadow_register(plat->base, otp);
+
+   return 0;
+}
+#endif
+
 static const struct udevice_id stm32mp_bsec_ids[] = {
{ .compatible = "st,stm32mp15-bsec" },
{}
@@ -445,4 +460,7 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
.ofdata_to_platdata = stm32mp_bsec_ofdata_to_platdata,
.platdata_auto_alloc_size = sizeof(struct stm32mp_bsec_platdata),
.ops = _bsec_ops,
+#ifndef CONFIG_STM32MP1_TRUSTED
+   .probe = stm32mp_bsec_probe,
+#endif
 };
-- 
2.7.4

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


[U-Boot] [PATCH 17/19] stm32mp1: bsec: use device tree new compatible

2019-02-27 Thread Patrick Delaunay
Update bsec driver to use the device tree provided by Kernel.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157-u-boot.dtsi|  4 
 arch/arm/dts/stm32mp157c.dtsi  |  7 +++
 arch/arm/mach-stm32mp/bsec.c   | 12 +---
 arch/arm/mach-stm32mp/include/mach/stm32.h |  1 -
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi 
b/arch/arm/dts/stm32mp157-u-boot.dtsi
index 90d13f3..2594702 100644
--- a/arch/arm/dts/stm32mp157-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
@@ -39,6 +39,10 @@
};
 };
 
+ {
+   u-boot,dm-pre-reloc;
+};
+
 _hsi {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index d1d0f90..50978ef 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -996,6 +996,13 @@
status = "disabled";
};
 
+   bsec: nvmem@5c005000 {
+   compatible = "st,stm32mp15-bsec";
+   reg = <0x5c005000 0x400>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
i2c6: i2c@5c009000 {
compatible = "st,stm32f7-i2c";
reg = <0x5c009000 0x400>;
diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index 920a6c9..8c5a299 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -434,7 +434,7 @@ static int stm32mp_bsec_ofdata_to_platdata(struct udevice 
*dev)
 }
 
 static const struct udevice_id stm32mp_bsec_ids[] = {
-   { .compatible = "st,stm32mp-bsec" },
+   { .compatible = "st,stm32mp15-bsec" },
{}
 };
 
@@ -446,13 +446,3 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
.platdata_auto_alloc_size = sizeof(struct stm32mp_bsec_platdata),
.ops = _bsec_ops,
 };
-
-/* bsec IP is not present in device tee, manage IP address by platdata */
-static struct stm32mp_bsec_platdata stm32_bsec_platdata = {
-   .base = STM32_BSEC_BASE,
-};
-
-U_BOOT_DEVICE(stm32mp_bsec) = {
-   .name = "stm32mp_bsec",
-   .platdata = _bsec_platdata,
-};
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index d153ac8..c526c88 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -13,7 +13,6 @@
 #define STM32_RCC_BASE 0x5000
 #define STM32_PWR_BASE 0x50001000
 #define STM32_DBGMCU_BASE  0x50081000
-#define STM32_BSEC_BASE0x5C005000
 #define STM32_TZC_BASE 0x5C006000
 #define STM32_ETZPC_BASE   0x5C007000
 #define STM32_TAMP_BASE0x5C00A000
-- 
2.7.4

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


[U-Boot] [PATCH 19/19] stm32mp1: Replace OTP read by SHADOW read

2019-02-27 Thread Patrick Delaunay
Replace STM32_BSEC_OTP() by STM32_BSEC_SHADOW() to
increase read performance.


Signed-off-by: Patrice Chotard 
Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index f39941e..7b4431c 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -472,7 +472,7 @@ static int setup_mac_address(void)
if (ret)
return ret;
 
-   ret = misc_read(dev, BSEC_OTP_MAC * 4 + STM32_BSEC_OTP_OFFSET,
+   ret = misc_read(dev, STM32_BSEC_SHADOW(BSEC_OTP_MAC),
otp, sizeof(otp));
if (ret < 0)
return ret;
@@ -510,7 +510,7 @@ static int setup_serial_number(void)
if (ret)
return ret;
 
-   ret = misc_read(dev, BSEC_OTP_SERIAL * 4 + STM32_BSEC_OTP_OFFSET,
+   ret = misc_read(dev, STM32_BSEC_SHADOW(BSEC_OTP_SERIAL),
otp, sizeof(otp));
if (ret < 0)
return ret;
-- 
2.7.4

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


[U-Boot] [PATCH 12/19] stm32mp1: activated some configuration

2019-02-27 Thread Patrick Delaunay
Add configuration useful for test
- FIT support
- MEMTEST
- DFU
- CACHE
- TIME
- TIMER

Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   | 6 ++
 configs/stm32mp15_trusted_defconfig | 6 ++
 include/configs/stm32mp1.h  | 4 
 3 files changed, 16 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 2d6a164..fa27cad 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
 CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
@@ -18,8 +19,10 @@ CONFIG_SYS_PROMPT="STM32MP> "
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
 CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
+CONFIG_CMD_DFU=y
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
@@ -27,6 +30,9 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 7945e9f..447c1d9 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_STM32MP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
 CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_PROMPT="STM32MP> "
 # CONFIG_CMD_BOOTD is not set
@@ -12,8 +13,10 @@ CONFIG_SYS_PROMPT="STM32MP> "
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
 CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
+CONFIG_CMD_DFU=y
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
@@ -21,6 +24,9 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index f2508f7..737dfd6 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -72,6 +72,10 @@
 STM32_SYSRAM_SIZE)
 #endif /* #ifdef CONFIG_SPL */
 
+#define CONFIG_SYS_MEMTEST_START   STM32_DDR_BASE
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + SZ_64M)
+#define CONFIG_SYS_MEMTEST_SCRATCH (CONFIG_SYS_MEMTEST_END + 4)
+
 /*MMC SD*/
 #define CONFIG_SYS_MMC_MAX_DEVICE  3
 #define CONFIG_SUPPORT_EMMC_BOOT
-- 
2.7.4

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


[U-Boot] [PATCH 10/19] stm32mp1: support forced boot mode

2019-02-27 Thread Patrick Delaunay
The boot mode can be forced by key press
or by TAMP register, requested in kernel by syscon-reboot-mode

tamp: tamp@5c00a000 {
compatible = "simple-bus", "syscon", "simple-mfd";
reg = <0x5c00a000 0x400>;

reboot-mode {
compatible = "syscon-reboot-mode";
offset = <0x150>; /* reg20 */
mask = <0xff>;
mode-normal = <0>;
mode-fastboot = <0x1>;
mode-recovery = <0x2>;
mode-stm32cubeprogrammer = <0x3>;
mode-ums_mmc0 = <0x10>;
mode-ums_mmc1 = <0x11>;
mode-ums_mmc2 = <0x12>;
};
};

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   |  5 +++
 arch/arm/mach-stm32mp/cpu.c| 36 +++--
 arch/arm/mach-stm32mp/include/mach/stm32.h | 11 +++
 board/st/stm32mp1/stm32mp1.c   | 51 ++
 4 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 70bbf66..d22401c 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -14,6 +14,11 @@
i2c3 = 
};
 
+   config {
+   st,fastboot-gpios = < 13 GPIO_ACTIVE_LOW>;
+   st,stm32prog-gpios = < 14 GPIO_ACTIVE_LOW>;
+   };
+
led {
compatible = "gpio-leds";
 
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 206b82e..305ea6d 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -359,12 +359,12 @@ static void setup_boot_mode(void)
u32 boot_mode =
(boot_ctx & TAMP_BOOT_MODE_MASK) >> TAMP_BOOT_MODE_SHIFT;
int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1;
+   u32 forced_mode = (boot_ctx & TAMP_BOOT_FORCED_MASK);
struct udevice *dev;
int alias;
 
-   pr_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d\n",
-__func__, boot_ctx, boot_mode, instance);
-
+   pr_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d forced=%x\n",
+__func__, boot_ctx, boot_mode, instance, forced_mode);
switch (boot_mode & TAMP_BOOT_DEVICE_MASK) {
case BOOT_SERIAL_UART:
if (instance > ARRAY_SIZE(serial_addr))
@@ -409,6 +409,36 @@ static void setup_boot_mode(void)
pr_debug("unexpected boot mode = %x\n", boot_mode);
break;
}
+
+   switch (forced_mode) {
+   case BOOT_FASTBOOT:
+   printf("Enter fastboot!\n");
+   env_set("preboot", "env set preboot; fastboot 0");
+   break;
+   case BOOT_STM32PROG:
+   env_set("boot_device", "usb");
+   env_set("boot_instance", "0");
+   break;
+   case BOOT_UMS_MMC0:
+   case BOOT_UMS_MMC1:
+   case BOOT_UMS_MMC2:
+   printf("Enter UMS!\n");
+   instance = forced_mode - BOOT_UMS_MMC0;
+   sprintf(cmd, "env set preboot; ums 0 mmc %d", instance);
+   env_set("preboot", cmd);
+   break;
+   case BOOT_RECOVERY:
+   env_set("preboot", "env set preboot; run altbootcmd");
+   break;
+   case BOOT_NORMAL:
+   break;
+   default:
+   pr_debug("unexpected forced boot mode = %x\n", forced_mode);
+   break;
+   }
+
+   /* clear TAMP for next reboot */
+   clrsetbits_le32(TAMP_BOOT_CONTEXT, TAMP_BOOT_FORCED_MASK, BOOT_NORMAL);
 }
 
 /*
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index f2ab026..da23af0 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -92,6 +92,17 @@ enum boot_device {
 #define TAMP_BOOT_MODE_SHIFT   8
 #define TAMP_BOOT_DEVICE_MASK  GENMASK(7, 4)
 #define TAMP_BOOT_INSTANCE_MASKGENMASK(3, 0)
+#define TAMP_BOOT_FORCED_MASK  GENMASK(7, 0)
+
+enum forced_boot_mode {
+   BOOT_NORMAL = 0x00,
+   BOOT_FASTBOOT = 0x01,
+   BOOT_RECOVERY = 0x02,
+   BOOT_STM32PROG = 0x03,
+   BOOT_UMS_MMC0 = 0x10,
+   BOOT_UMS_MMC1 = 0x11,
+   BOOT_UMS_MMC2 = 0x12,
+};
 
 /* offset used for BSEC driver: misc_read and misc_write */
 #define STM32_BSEC_SHADOW_OFFSET   0x0
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 0d963c2..d13793e 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -67,6 +67,55 @@ int checkboard(void)
return 0;
 }
 
+static void board_key_check(void)
+{
+#if defined(CONFIG_FASTBOOT) || defined(CONFIG_CMD_STM32PROG)
+   ofnode node;
+   struct gpio_desc gpio;
+   enum forced_boot_mode boot_mode = BOOT_NORMAL;
+
+   node = ofnode_path("/config");
+   if 

[U-Boot] [PATCH 11/19] stm32mp1: update memory layout

2019-02-27 Thread Patrick Delaunay
Update the memory layout to be aligned with other platform and avoid
overlap with 32MB Linux kernel (multiv7 image).
+ Kernel => 32MiB offset = 0xC200
and increase the bootm size to 32MiB
+ FDT => 64MiB offset = 0xc400
+ SCRIPT => 65Mib offset = 0xc410
+ PXESCRIPT => 66Mib offset = 0xc420
+ SPLASHIMAGE => 67Mib offset = 0xc430
+ RAMDISK => 68Mib offset = 0xc440
 (not limited size)

In sources/boot/u-boot/doc/README.distro

+ kernel_addr_r: A size of 16MB for the kernel is likely adequate.
+ pxefile_addr_r: A size of 1MB for extlinux.conf is more than adequate.
+ fdt_addr_r: A size of 1MB for the FDT/DTB seems reasonable.
+ ramdisk_addr_r: It is recommended that this location be highest in RAM
  out of fdt_addr_, kernel_addr_r, and ramdisk_addr_r,
  so that the RAM disk can vary in size and use any
 available RAM.
+ pxefile_addr_r: A size of 1MB for extlinux.conf is more than adequate.
+ scriptaddr: A size of 1MB for extlinux.conf is more than adequate.

For suggestions on memory locations for ARM systems, you must follow
the guidelines specified in Documentation/arm/Booting
in the Linux kernel tree.

And in sources/linux-stm32mp/Documentation/arm/Booting

The zImage may also be placed in system RAM and called there.  The
kernel should be placed in the first 128MiB of RAM.  It is recommended
that it is loaded above 32MiB in order to avoid the need to relocate
prior to decompression, which will make the boot process slightly
faster.

Signed-off-by: Patrick Delaunay 
---

 include/configs/stm32mp1.h | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 48da1e3..f2508f7 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -53,6 +53,9 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
 
+/* Extend size of kernel image for uncompression */
+#define CONFIG_SYS_BOOTM_LEN   SZ_32M
+
 /* SPL support */
 #ifdef CONFIG_SPL
 /* BOOTROM load address */
@@ -106,12 +109,18 @@
 
 #include 
 
+/*
+ * memory layout for 32M uncompressed/compressed kernel,
+ * 1M fdt, 1M script, 1M pxe and 1M for splashimage
+ * and the ramdisk at the end.
+ */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "scriptaddr=0xC000\0" \
-   "pxefile_addr_r=0xC000\0" \
-   "kernel_addr_r=0xC100\0" \
-   "fdt_addr_r=0xC400\0" \
-   "ramdisk_addr_r=0xC410\0" \
+   "kernel_addr_r=0xc200\0" \
+   "fdt_addr_r=0xc400\0" \
+   "scriptaddr=0xc410\0" \
+   "pxefile_addr_r=0xc420\0" \
+   "splashimage=0xc430\0"  \
+   "ramdisk_addr_r=0xc440\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
STM32MP_BOOTCMD \
-- 
2.7.4

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


[U-Boot] [PATCH 14/19] stm32mp1: add syscfg initialization

2019-02-27 Thread Patrick Delaunay
Initialize the system configuration for basic boot
- update interconnect setting
- disable pull-down for boot pin
- enable High Speed Low Voltage Pad mode for SPI, SDMMC, ETH, QSPI
- activate I/O compensation

Done by SSBL = TF-A for trusted boot

Signed-off-by: Patrick Delaunay 
---

 board/st/stm32mp1/stm32mp1.c | 130 ++-
 1 file changed, 129 insertions(+), 1 deletion(-)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index d13793e..2829180 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -11,13 +11,47 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+/* SYSCFG registers */
+#define SYSCFG_BOOTR   0x00
+#define SYSCFG_PMCSETR 0x04
+#define SYSCFG_IOCTRLSETR  0x18
+#define SYSCFG_ICNR0x1C
+#define SYSCFG_CMPCR   0x20
+#define SYSCFG_CMPENSETR   0x24
+#define SYSCFG_PMCCLRR 0x44
+
+#define SYSCFG_BOOTR_BOOT_MASK GENMASK(2, 0)
+#define SYSCFG_BOOTR_BOOTPD_SHIFT  4
+
+#define SYSCFG_IOCTRLSETR_HSLVEN_TRACE BIT(0)
+#define SYSCFG_IOCTRLSETR_HSLVEN_QUADSPI   BIT(1)
+#define SYSCFG_IOCTRLSETR_HSLVEN_ETH   BIT(2)
+#define SYSCFG_IOCTRLSETR_HSLVEN_SDMMC BIT(3)
+#define SYSCFG_IOCTRLSETR_HSLVEN_SPI   BIT(4)
+
+#define SYSCFG_CMPCR_SW_CTRL   BIT(1)
+#define SYSCFG_CMPCR_READY BIT(8)
+
+#define SYSCFG_CMPENSETR_MPU_ENBIT(0)
+
+#define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
+#define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
+
+#define SYSCFG_PMCSETR_ETH_SELMII  BIT(20)
+
+#define SYSCFG_PMCSETR_ETH_SEL_MASKGENMASK(23, 21)
+#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII(0 << 21)
+#define SYSCFG_PMCSETR_ETH_SEL_RGMII   (1 << 21)
+#define SYSCFG_PMCSETR_ETH_SEL_RMII(4 << 21)
+
 /*
  * Get a global data pointer
  */
@@ -270,6 +304,98 @@ int board_usb_cleanup(int index, enum usb_init_type init)
return 0;
 }
 
+static void sysconf_init(void)
+{
+#ifndef CONFIG_STM32MP1_TRUSTED
+   u8 *syscfg;
+#ifdef CONFIG_DM_REGULATOR
+   struct udevice *pwr_dev;
+   struct udevice *pwr_reg;
+   struct udevice *dev;
+   int ret;
+   u32 otp = 0;
+#endif
+   u32 bootr;
+
+   syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
+
+   /* interconnect update : select master using the port 1 */
+   /* LTDC = AXI_M9 */
+   /* GPU  = AXI_M8 */
+   /* today information is hardcoded in U-Boot */
+   writel(BIT(9), syscfg + SYSCFG_ICNR);
+
+   /* disable Pull-Down for boot pin connected to VDD */
+   bootr = readl(syscfg + SYSCFG_BOOTR);
+   bootr &= ~(SYSCFG_BOOTR_BOOT_MASK << SYSCFG_BOOTR_BOOTPD_SHIFT);
+   bootr |= (bootr & SYSCFG_BOOTR_BOOT_MASK) << SYSCFG_BOOTR_BOOTPD_SHIFT;
+   writel(bootr, syscfg + SYSCFG_BOOTR);
+
+#ifdef CONFIG_DM_REGULATOR
+   /* High Speed Low Voltage Pad mode Enable for SPI, SDMMC, ETH, QSPI
+* and TRACE. Needed above ~50MHz and conditioned by AFMUX selection.
+* The customer will have to disable this for low frequencies
+* or if AFMUX is selected but the function not used, typically for
+* TRACE. Otherwise, impact on power consumption.
+*
+* WARNING:
+*   enabling High Speed mode while VDD>2.7V
+*   with the OTP product_below_2v5 (OTP 18, BIT 13)
+*   erroneously set to 1 can damage the IC!
+*   => U-Boot set the register only if VDD < 2.7V (in DT)
+*  but this value need to be consistent with board design
+*/
+   ret = syscon_get_by_driver_data(STM32MP_SYSCON_PWR, _dev);
+   if (!ret) {
+   ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_GET_DRIVER(stm32mp_bsec),
+ );
+   if (ret) {
+   pr_err("Can't find stm32mp_bsec driver\n");
+   return;
+   }
+
+   ret = misc_read(dev, STM32_BSEC_SHADOW(18), , 4);
+   if (!ret)
+   otp = otp & BIT(13);
+
+   /* get VDD = pwr-supply */
+   ret = device_get_supply_regulator(pwr_dev, "pwr-supply",
+ _reg);
+
+   /* check if VDD is Low Voltage */
+   if (!ret) {
+   if (regulator_get_value(pwr_reg) < 270) {
+   writel(SYSCFG_IOCTRLSETR_HSLVEN_TRACE |
+  SYSCFG_IOCTRLSETR_HSLVEN_QUADSPI |
+  SYSCFG_IOCTRLSETR_HSLVEN_ETH |
+  SYSCFG_IOCTRLSETR_HSLVEN_SDMMC |
+  SYSCFG_IOCTRLSETR_HSLVEN_SPI,
+  syscfg + SYSCFG_IOCTRLSETR);
+
+  

[U-Boot] [PATCH 09/19] stm32mp1: activate FASTBOOT on eMMC

2019-02-27 Thread Patrick Delaunay
activate Fastboot for eMMC on EV1 board (mmc1)

$> sudo apt-get install android-tools-adb android-tools-fastboot
$> fastboot -i 0x0483 getvar bootloader-version

Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   | 7 ++-
 configs/stm32mp15_trusted_defconfig | 7 ++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 4ab29ee..2d6a164 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -33,6 +33,12 @@ CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
 CONFIG_STM32_ADC=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0xC000
+CONFIG_FASTBOOT_BUF_SIZE=0x0200
+CONFIG_FASTBOOT_USB_DEV=1
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
 CONFIG_DM_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_STM32=y
 CONFIG_DM_I2C=y
@@ -64,4 +70,3 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
-CONFIG_USB_GADGET_DOWNLOAD=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 1bb3d0d..7945e9f 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -26,6 +26,12 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
 CONFIG_STM32_ADC=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0xC000
+CONFIG_FASTBOOT_BUF_SIZE=0x0200
+CONFIG_FASTBOOT_USB_DEV=1
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
 CONFIG_DM_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_STM32=y
 CONFIG_DM_I2C=y
@@ -55,4 +61,3 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
-CONFIG_USB_GADGET_DOWNLOAD=y
-- 
2.7.4

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


[U-Boot] [PATCH 06/19] stm32mp1: cosmetic: add comment on psci_migrate_info_type return value

2019-02-27 Thread Patrick Delaunay
Add explaination for the return value of psci_migrate_info_type:
  2 = Trusted OS.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/psci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c
index 6ed2482..c2dff38 100644
--- a/arch/arm/mach-stm32mp/psci.c
+++ b/arch/arm/mach-stm32mp/psci.c
@@ -103,7 +103,13 @@ int __secure psci_affinity_info(u32 function_id, u32 
target_affinity,
 
 int __secure psci_migrate_info_type(u32 function_id)
 {
-   /* Trusted OS is either not present or does not require migration */
+   /*
+* in Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
+* return 2 = Trusted OS is either not present or does not require
+* migration, system of this type does not require the caller
+* to use the MIGRATE function.
+* MIGRATE function calls return NOT_SUPPORTED.
+*/
return 2;
 }
 
-- 
2.7.4

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


[U-Boot] [PATCH 13/19] stm32mp1: add some syscon drivers for syscfg and etpzc

2019-02-27 Thread Patrick Delaunay
Add SYSCON driver for syscfg and etpzc and reorder in alphabetics order

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157c.dtsi  | 2 +-
 arch/arm/mach-stm32mp/include/mach/stm32.h | 4 +++-
 arch/arm/mach-stm32mp/syscon.c | 9 +
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 37cadfa..d1d0f90 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -754,7 +754,7 @@
};
 
syscfg: system-config@5002 {
-   compatible = "st,stm32-syscfg", "syscon";
+   compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x5002 0x400>;
};
 
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index da23af0..d153ac8 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -37,8 +37,10 @@
 /* enumerated used to identify the SYSCON driver instance */
 enum {
STM32MP_SYSCON_UNKNOWN,
-   STM32MP_SYSCON_STGEN,
+   STM32MP_SYSCON_ETZPC,
STM32MP_SYSCON_PWR,
+   STM32MP_SYSCON_STGEN,
+   STM32MP_SYSCON_SYSCFG,
 };
 
 /*
diff --git a/arch/arm/mach-stm32mp/syscon.c b/arch/arm/mach-stm32mp/syscon.c
index eb7f435..242f834 100644
--- a/arch/arm/mach-stm32mp/syscon.c
+++ b/arch/arm/mach-stm32mp/syscon.c
@@ -9,10 +9,11 @@
 #include 
 
 static const struct udevice_id stm32mp_syscon_ids[] = {
-   { .compatible = "st,stm32-stgen",
- .data = STM32MP_SYSCON_STGEN },
-   { .compatible = "st,stm32mp1-pwr",
- .data = STM32MP_SYSCON_PWR },
+   { .compatible = "st,stm32mp1-etzpc", .data = STM32MP_SYSCON_ETZPC },
+   { .compatible = "st,stm32mp1-pwr", .data = STM32MP_SYSCON_PWR },
+   { .compatible = "st,stm32-stgen", .data = STM32MP_SYSCON_STGEN },
+   { .compatible = "st,stm32mp157-syscfg",
+ .data = STM32MP_SYSCON_SYSCFG },
{ }
 };
 
-- 
2.7.4

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


[U-Boot] [PATCH 04/19] stm32mp1: spl: add spl_display_print

2019-02-27 Thread Patrick Delaunay
SPL displays the board model from device tree.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/Kconfig |  1 +
 arch/arm/mach-stm32mp/spl.c   | 17 +
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 3101d80..d70658a 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -18,6 +18,7 @@ config SPL
select SPL_SERIAL_SUPPORT
select SPL_SYSCON
select SPL_DRIVERS_MISC_SUPPORT
+   imply SPL_DISPLAY_PRINT
imply SPL_LIBDISK_SUPPORT
 
 config SYS_SOC
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index c6ae73d..501e077 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -7,6 +7,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 u32 spl_boot_device(void)
 {
@@ -58,6 +60,21 @@ int spl_boot_partition(const u32 boot_device)
}
 }
 
+#ifdef CONFIG_SPL_DISPLAY_PRINT
+void spl_display_print(void)
+{
+   DECLARE_GLOBAL_DATA_PTR;
+   const char *model;
+
+   /* same code than show_board_info() but not compiled for SPL
+* see CONFIG_DISPLAY_BOARDINFO & common/board_info.c
+*/
+   model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+   if (model)
+   printf("Model: %s\n", model);
+}
+#endif
+
 void board_init_f(ulong dummy)
 {
struct udevice *dev;
-- 
2.7.4

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


[U-Boot] [PATCH 07/19] stm32mp1: spl: hang with trace when DDR init failed

2019-02-27 Thread Patrick Delaunay
When DDR initialization failed, print error message
and stop the SPL execution.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/spl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index 501e077..a3b0d6f 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -111,7 +111,7 @@ void board_init_f(ulong dummy)
 
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret) {
-   debug("DRAM init failed: %d\n", ret);
-   return;
+   printf("DRAM init failed: %d\n", ret);
+   hang();
}
 }
-- 
2.7.4

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


[U-Boot] [PATCH 05/19] stm32mp1: cosmetic cleanup Kconfig

2019-02-27 Thread Patrick Delaunay
Cosmetic cleanup in mach-stm32mp Kconfig
- remove duplicated SPL_DRIVERS_MISC_SUPPORT
- update help for TARGET_STM32MP1
- set value for NR_DRAM_BANKS
- remove one comment as DEBUG_UART is deactivated by default
- include board Kconfig at the end of the file

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/Kconfig   | 11 +++
 configs/stm32mp15_basic_defconfig   |  1 -
 configs/stm32mp15_trusted_defconfig |  1 -
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index d70658a..73aa382 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -17,7 +17,6 @@ config SPL
select SPL_DM_RESET
select SPL_SERIAL_SUPPORT
select SPL_SYSCON
-   select SPL_DRIVERS_MISC_SUPPORT
imply SPL_DISPLAY_PRINT
imply SPL_LIBDISK_SUPPORT
 
@@ -38,7 +37,9 @@ config TARGET_STM32MP1
imply SYSRESET_SYSCON if !STM32MP1_TRUSTED
help
target STMicroelectronics SOC STM32MP1 family
+   STM32MP157, STM32MP153 or STM32MP151
STMicroelectronics MPU with core ARMv7
+   dual core A7 for STM32MP157/3, monocore for STM32MP151
 
 config STM32MP1_TRUSTED
bool "Support trusted boot with TF-A"
@@ -58,6 +59,9 @@ config SYS_TEXT_BASE
when DDR driver is used:
  DDR + 1MB (0xC010)
 
+config NR_DRAM_BANKS
+   default 1
+
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_MMC2
hex "Partition on MMC2 to use to load U-Boot from"
depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
@@ -66,9 +70,6 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_MMC2
  Partition on the second MMC to load U-Boot from when the MMC is being
  used in raw mode
 
-source "board/st/stm32mp1/Kconfig"
-
-# currently activated for debug / should be deactivated for real product
 if DEBUG_UART
 
 config DEBUG_UART_BOARD_INIT
@@ -83,4 +84,6 @@ config DEBUG_UART_CLOCK
default 6400
 endif
 
+source "board/st/stm32mp1/Kconfig"
+
 endif
diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index d20b2ab..b1d09fb 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -5,7 +5,6 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
 CONFIG_SPL_I2C_SUPPORT=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 62ab010..9be7319 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_STM32MP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_PROMPT="STM32MP> "
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_ELF is not set
-- 
2.7.4

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


[U-Boot] [PATCH 00/19] stm32mp1: update of stm32mp arch and stm32mp1 board

2019-02-27 Thread Patrick Delaunay

Need to be apply after the previous serie:
  stm32mp1: add trusted boot with TF-A
  http://patchwork.ozlabs.org/project/uboot/list/?series=91422

It is a first alignment on the delivery v2018.11-stm32mp-r2
available on GITHUB https://github.com/STMicroelectronics/u-boot



Patrick Delaunay (19):
  stm32mp1: add runtime information in environment
  stm32mp1: update boot mode management
  stm32mp1: update print_cpuinfo()
  stm32mp1: spl: add spl_display_print
  stm32mp1: cosmetic cleanup Kconfig
  stm32mp1: cosmetic: add comment on psci_migrate_info_type return value
  stm32mp1: spl: hang with trace when DDR init failed
  stm32mp1: update bootcmd
  stm32mp1: activate FASTBOOT on eMMC
  stm32mp1: support forced boot mode
  stm32mp1: update memory layout
  stm32mp1: activated some configuration
  stm32mp1: add some syscon drivers for syscfg and etpzc
  stm32mp1: add syscfg initialization
  stm32mp1: align serial number on bootrom
  stm32mp1: basic boot: SPL enable access to GPIOZ bank
  stm32mp1: bsec: use device tree new compatible
  stm32mp1: bsec: shadow all the upper OTP (no secure) during boot
  stm32mp1: Replace OTP read by SHADOW read

 arch/arm/Kconfig   |   1 +
 arch/arm/dts/stm32mp157-u-boot.dtsi|   4 +
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   |   5 +
 arch/arm/dts/stm32mp157c.dtsi  |   9 +-
 arch/arm/mach-stm32mp/Kconfig  |  12 +-
 arch/arm/mach-stm32mp/bsec.c   |  32 ++--
 arch/arm/mach-stm32mp/cpu.c| 209 ++---
 arch/arm/mach-stm32mp/include/mach/stm32.h |  19 ++-
 arch/arm/mach-stm32mp/include/mach/sys_proto.h |  12 +-
 arch/arm/mach-stm32mp/psci.c   |   8 +-
 arch/arm/mach-stm32mp/spl.c|  39 -
 arch/arm/mach-stm32mp/syscon.c |   9 +-
 board/st/stm32mp1/stm32mp1.c   | 200 ++-
 configs/stm32mp15_basic_defconfig  |  15 +-
 configs/stm32mp15_trusted_defconfig|  15 +-
 include/configs/stm32mp1.h |  60 +--
 16 files changed, 571 insertions(+), 78 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 03/19] stm32mp1: update print_cpuinfo()

2019-02-27 Thread Patrick Delaunay
Display CPU part number and package information.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cpu.c| 102 +++--
 arch/arm/mach-stm32mp/include/mach/sys_proto.h |  10 ++-
 2 files changed, 104 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 753ff3e..206b82e 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -55,9 +55,30 @@
 #define BOOTROM_INSTANCE_SHIFT 16
 
 /* BSEC OTP index */
+#define BSEC_OTP_RPN   1
 #define BSEC_OTP_SERIAL13
+#define BSEC_OTP_PKG   16
 #define BSEC_OTP_MAC   57
 
+/* Device Part Number (RPN) = OTP_DATA1 lower 8 bits */
+#define RPN_SHIFT  0
+#define RPN_MASK   GENMASK(7, 0)
+
+/* Package = bit 27:29 of OTP16
+ * - 100: LBGA448 (FFI) => AA = LFBGA 18x18mm 448 balls p. 0.8mm
+ * - 011: LBGA354 (LCI) => AB = LFBGA 16x16mm 359 balls p. 0.8mm
+ * - 010: TFBGA361 (FFC) => AC = TFBGA 12x12mm 361 balls p. 0.5mm
+ * - 001: TFBGA257 (LCC) => AD = TFBGA 10x10mm 257 balls p. 0.5mm
+ * - others: Reserved
+ */
+#define PKG_SHIFT  27
+#define PKG_MASK   GENMASK(2, 0)
+
+#define PKG_AA_LBGA448 4
+#define PKG_AB_LBGA354 3
+#define PKG_AC_TFBGA3612
+#define PKG_AD_TFBGA2571
+
 #if !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)
 #ifndef CONFIG_STM32MP1_TRUSTED
 static void security_init(void)
@@ -215,25 +236,94 @@ u32 get_cpu_rev(void)
return (read_idc() & DBGMCU_IDC_REV_ID_MASK) >> DBGMCU_IDC_REV_ID_SHIFT;
 }
 
+static u32 get_otp(int index, int shift, int mask)
+{
+   int ret;
+   struct udevice *dev;
+   u32 otp = 0;
+
+   ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_GET_DRIVER(stm32mp_bsec),
+ );
+
+   if (!ret)
+   ret = misc_read(dev, STM32_BSEC_SHADOW(index),
+   , sizeof(otp));
+
+   return (otp >> shift) & mask;
+}
+
+/* Get Device Part Number (RPN) from OTP */
+static u32 get_cpu_rpn(void)
+{
+   return get_otp(BSEC_OTP_RPN, RPN_SHIFT, RPN_MASK);
+}
+
 u32 get_cpu_type(void)
 {
-   return (read_idc() & DBGMCU_IDC_DEV_ID_MASK) >> DBGMCU_IDC_DEV_ID_SHIFT;
+   u32 id;
+
+   id = (read_idc() & DBGMCU_IDC_DEV_ID_MASK) >> DBGMCU_IDC_DEV_ID_SHIFT;
+
+   return (id << 16) | get_cpu_rpn();
+}
+
+/* Get Package options from OTP */
+static u32 get_cpu_package(void)
+{
+   return get_otp(BSEC_OTP_PKG, PKG_SHIFT, PKG_MASK);
 }
 
 #if defined(CONFIG_DISPLAY_CPUINFO)
 int print_cpuinfo(void)
 {
-   char *cpu_s, *cpu_r;
+   char *cpu_s, *cpu_r, *pkg;
 
+   /* MPUs Part Numbers */
switch (get_cpu_type()) {
-   case CPU_STMP32MP15x:
-   cpu_s = "15x";
+   case CPU_STM32MP157Cxx:
+   cpu_s = "157C";
+   break;
+   case CPU_STM32MP157Axx:
+   cpu_s = "157A";
+   break;
+   case CPU_STM32MP153Cxx:
+   cpu_s = "153C";
+   break;
+   case CPU_STM32MP153Axx:
+   cpu_s = "153A";
+   break;
+   case CPU_STM32MP151Cxx:
+   cpu_s = "151C";
+   break;
+   case CPU_STM32MP151Axx:
+   cpu_s = "151A";
+   break;
+   default:
+   cpu_s = "";
+   break;
+   }
+
+   /* Package */
+   switch (get_cpu_package()) {
+   case PKG_AA_LBGA448:
+   pkg = "AA";
+   break;
+   case PKG_AB_LBGA354:
+   pkg = "AB";
+   break;
+   case PKG_AC_TFBGA361:
+   pkg = "AC";
+   break;
+   case PKG_AD_TFBGA257:
+   pkg = "AD";
break;
default:
-   cpu_s = "?";
+   pkg = "??";
break;
}
 
+   /* REVISION */
switch (get_cpu_rev()) {
case CPU_REVA:
cpu_r = "A";
@@ -246,7 +336,7 @@ int print_cpuinfo(void)
break;
}
 
-   printf("CPU: STM32MP%s.%s\n", cpu_s, cpu_r);
+   printf("CPU: STM32MP%s%s Rev.%s\n", cpu_s, pkg, cpu_r);
 
return 0;
 }
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h 
b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
index 8b426c0..71a3ba7 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -3,9 +3,15 @@
  * Copyright (C) 2015-2017, STMicroelectronics - All Rights Reserved
  */
 
-#define CPU_STMP32MP15x0x500
+/* ID = Device Version (bit31:16) + Device Part Number (RPN) (bit15:0)*/
+#define CPU_STM32MP157Cxx  0x0500
+#define CPU_STM32MP157Axx  0x0501
+#define CPU_STM32MP153Cxx  0x0524
+#define CPU_STM32MP153Axx  0x0525
+#define CPU_STM32MP151Cxx  0x052E
+#define CPU_STM32MP151Axx  0x052F
 
-/* return CPU_STMP32MPxx constants */
+/* return 

[U-Boot] [PATCH 02/19] stm32mp1: update boot mode management

2019-02-27 Thread Patrick Delaunay
- export the function get_bootmode() and reused it in spl code
- manage uart instance by alias (prepare v4.19 binding)
- solve issue on nand instance
- restore console for uart boot

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cpu.c| 57 +-
 arch/arm/mach-stm32mp/include/mach/stm32.h |  3 --
 arch/arm/mach-stm32mp/include/mach/sys_proto.h |  2 +
 arch/arm/mach-stm32mp/spl.c| 18 +++-
 4 files changed, 64 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index b96720f..753ff3e 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -129,14 +129,19 @@ static void dbgmcu_init(void)
 }
 #endif /* !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD) */
 
-static u32 get_bootmode(void)
-{
-   u32 boot_mode;
 #if !defined(CONFIG_STM32MP1_TRUSTED) && \
(!defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD))
+/* get bootmode from ROM code boot context: saved in TAMP register */
+static void update_bootmode(void)
+{
+   u32 boot_mode;
u32 bootrom_itf = readl(BOOTROM_PARAM_ADDR);
u32 bootrom_device, bootrom_instance;
 
+   /* enable TAMP clock = RTCAPBEN */
+   writel(BIT(8), RCC_MP_APB5ENSETR);
+
+   /* read bootrom context */
bootrom_device =
(bootrom_itf & BOOTROM_MODE_MASK) >> BOOTROM_MODE_SHIFT;
bootrom_instance =
@@ -150,12 +155,14 @@ static u32 get_bootmode(void)
clrsetbits_le32(TAMP_BOOT_CONTEXT,
TAMP_BOOT_MODE_MASK,
boot_mode << TAMP_BOOT_MODE_SHIFT);
-#else
-   /* read TAMP backup register */
-   boot_mode = (readl(TAMP_BOOT_CONTEXT) & TAMP_BOOT_MODE_MASK) >>
-   TAMP_BOOT_MODE_SHIFT;
+}
 #endif
-   return boot_mode;
+
+u32 get_bootmode(void)
+{
+   /* read bootmode from TAMP backup register */
+   return (readl(TAMP_BOOT_CONTEXT) & TAMP_BOOT_MODE_MASK) >>
+   TAMP_BOOT_MODE_SHIFT;
 }
 
 /*
@@ -172,10 +179,10 @@ int arch_cpu_init(void)
dbgmcu_init();
 #ifndef CONFIG_STM32MP1_TRUSTED
security_init();
+   update_bootmode();
 #endif
 #endif
 
-   /* get bootmode from BootRom context: saved in TAMP register */
boot_mode = get_bootmode();
 
if ((boot_mode & TAMP_BOOT_DEVICE_MASK) == BOOT_SERIAL_UART)
@@ -247,20 +254,48 @@ int print_cpuinfo(void)
 
 static void setup_boot_mode(void)
 {
+   const u32 serial_addr[] = {
+   STM32_USART1_BASE,
+   STM32_USART2_BASE,
+   STM32_USART3_BASE,
+   STM32_UART4_BASE,
+   STM32_UART5_BASE,
+   STM32_USART6_BASE,
+   STM32_UART7_BASE,
+   STM32_UART8_BASE
+   };
char cmd[60];
u32 boot_ctx = readl(TAMP_BOOT_CONTEXT);
u32 boot_mode =
(boot_ctx & TAMP_BOOT_MODE_MASK) >> TAMP_BOOT_MODE_SHIFT;
int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1;
+   struct udevice *dev;
+   int alias;
 
pr_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d\n",
 __func__, boot_ctx, boot_mode, instance);
 
switch (boot_mode & TAMP_BOOT_DEVICE_MASK) {
case BOOT_SERIAL_UART:
-   sprintf(cmd, "%d", instance);
-   env_set("boot_device", "uart");
+   if (instance > ARRAY_SIZE(serial_addr))
+   break;
+   /* serial : search associated alias in devicetree */
+   sprintf(cmd, "serial@%x", serial_addr[instance]);
+   if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, ))
+   break;
+   if (fdtdec_get_alias_seq(gd->fdt_blob, "serial",
+dev_of_offset(dev), ))
+   break;
+   sprintf(cmd, "%d", alias);
+   env_set("boot_device", "serial");
env_set("boot_instance", cmd);
+
+   /* restore console on uart when not used */
+   if (gd->cur_serial_dev != dev) {
+   gd->flags &= ~(GD_FLG_SILENT |
+  GD_FLG_DISABLE_CONSOLE);
+   printf("serial boot with console enabled!\n");
+   }
break;
case BOOT_SERIAL_USB:
env_set("boot_device", "usb");
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 85d783c..f2ab026 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -18,8 +18,6 @@
 #define STM32_ETZPC_BASE   0x5C007000
 #define STM32_TAMP_BASE0x5C00A000
 
-#ifdef CONFIG_DEBUG_UART_BASE
-/* hardcoded value can be only used for DEBUG UART */
 #define STM32_USART1_BASE  0x5C00
 #define STM32_USART2_BASE  0x4000E000

[U-Boot] [PATCH 01/19] stm32mp1: add runtime information in environment

2019-02-27 Thread Patrick Delaunay
Set board name with the first dts compatible found in DT
code under CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

The result with DEVICE_TREE=stm32mp157c-ev1 is:
STM32MP> env print
board=stm32mp1
board_name=stm32mp157c-ev1

Signed-off-by: Patrick Delaunay 
---

 arch/arm/Kconfig |  1 +
 board/st/stm32mp1/stm32mp1.c | 24 +++-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e861c2..ec524f4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1364,6 +1364,7 @@ config ARCH_STM32MP
select SYSRESET
select SYS_THUMB_BUILD
imply CMD_DM
+   imply ENV_VARS_UBOOT_RUNTIME_CONFIG
help
  Support for STM32MP SoC family developed by STMicroelectronics,
  MPUs based on ARM cortex A core
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 07d1add..48da459 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -220,11 +220,6 @@ int board_usb_cleanup(int index, enum usb_init_type init)
return 0;
 }
 
-int board_late_init(void)
-{
-   return 0;
-}
-
 /* board dependent setup after realloc */
 int board_init(void)
 {
@@ -236,3 +231,22 @@ int board_init(void)
 
return 0;
 }
+
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   const void *fdt_compat;
+   int fdt_compat_len;
+
+   fdt_compat = fdt_getprop(gd->fdt_blob, 0, "compatible",
+_compat_len);
+   if (fdt_compat && fdt_compat_len) {
+   if (strncmp(fdt_compat, "st,", 3) != 0)
+   env_set("board_name", fdt_compat);
+   else
+   env_set("board_name", fdt_compat + 3);
+   }
+#endif
+
+   return 0;
+}
-- 
2.7.4

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


Re: [U-Boot] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

2019-02-27 Thread Adam Ford
On Wed, Feb 27, 2019 at 8:52 AM Leigh Brown  wrote:
>
> Hi Adam,
>
> Thanks very much for your response.
>
> On 2019-02-27 12:50, Adam Ford wrote:
> > On Wed, Feb 27, 2019 at 5:32 AM Leigh Brown 
> > wrote:
> >>
> >> Hello,
> >>
> >> Vagrant Cascadian asked for people to test the version of u-boot
> >> packaged
> >> for Debian Buster.  I tested u-boot on my Dreamplug and found it was
> >> not
> >> working correctly.  I raised a bug for Debian[1] but I have also
> >> tested
> >> with the mainline version of u-boot and found the same issues.
> >>
> >> The first issue is that the following commit caused u-boot to no
> >> longer
> >> be able to access usb storage on the Dreamplug:
> >>
> >> commit 93b283d49f933f95f3a6f40762936f454ac655a8
> >> Author: Adam Ford 
> >> Date:   Thu Aug 16 13:23:11 2018 -0500
> >>
> >
> > Sorry about that.
> >
> >>  ARM: CPU: arm926ejs: Consolidate cache routines to common file
> >>
> >>  Four different boards had different options for enabling cache
> >>  that were virtually all the same.  This consolidates these
> >>  common functions into arch/arm/cpu/arm926ejs/cache.c
> >>
> >>  This also has the positive side-effect of enabling cache on
> >>  the Davinci (da850) boards.
> >>
> >>  Signed-off-by: Adam Ford 
> >>  [trini: Add mach-at91 to the list of consolidations]
> >>  Signed-off-by: Tom Rini 
> >>
> >> I don't have much knowledge of ARM caching, but the following patch
> >> makes
> >> it work again on my Dreamplug.
> >
> > I am not that familiar with the ARM caching either, I was just hoping
> > to enable it on the da850 board and compared the various code chunks
> > between ARM 926 boards and noticed a common thread.  Tom took it and
> > added some more.
>
> Okay.  Hopefully Tom can comment on my proposed fixes.
>
> >
> >>
> >> diff --git a/arch/arm/mach-kirkwood/cpu.c
> >> b/arch/arm/mach-kirkwood/cpu.c
> >> index d54de53f31..8a065d73ae 100644
> >> --- a/arch/arm/mach-kirkwood/cpu.c
> >> +++ b/arch/arm/mach-kirkwood/cpu.c
> >> @@ -291,7 +291,6 @@ int arch_misc_init(void)
> >> temp |= (1 << 22);
> >> writefr_extra_feature_reg(temp);
> >>
> > #ifndef CONFIG_SYS_ICACHE_OFF
> >> -   icache_enable();
> > #endif
> >
> > Instead of commenting out that line, try defining
> > CONFIG_SYS_ICACHE_OFF in your header like you did for the
> > CONFIG_SYS_DCACHE_OFF and encapsulate the function call with ifdef's
> > so any other kirkwood processors can enable/disable it independently.
>
> The reason I removed that line is because icache_enable() is called from
> enable_caches() which is called from initr_caches() which is in the list
> of functions in init_sequence_r[] prior to arch_misc_init().  In other
> words, it will already have been called by then if CONFIG_SYS_ICACHE_OFF
> is not set.  Does that make sense?

That makes a lot of sense to me.

>
> >> /* Change reset vector to address 0x0 */
> >> temp = get_cr();
> >> set_cr(temp & ~CR_V);
> >> diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
> >> index f4d717213c..6348935c68 100644
> >> --- a/include/configs/dreamplug.h
> >> +++ b/include/configs/dreamplug.h
> >> @@ -79,4 +79,6 @@
> >>   #define CONFIG_SYS_ATA_IDE0_OFFSETMV_SATA_PORT0_OFFSET
> >>   #endif /*CONFIG_MVSATA_IDE*/
> >>
> >> +#define CONFIG_SYS_DCACHE_OFF
> > #define CONFIG_SYS_ICACHE_OFF
>
> The reason I have not done this is because the Kirkwood arch_misc_init()
> function was already unconditionally enabling the instruction cache, so
> we want to retain that behaviour - I think.  I hope that makes sense.

That makes a lot of sense too.

adam

>
> >> +
> >>   #endif /* _CONFIG_DREAMPLUG_H */
> >>
> >> I'd be grateful if someone could take a look.  If you need me to do
> >> any
> >> testing  or provide any more information, please let me know.
> >>
> >> I found another issue (documented in the same bug).  I'll send a
> >> separate
> >> email about that.
> >>
> >> Regards,
> >>
> >> Leigh.
> >>
> >> --
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379
>
> Regards,
>
> Leigh.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

2019-02-27 Thread Patrick DELAUNAY
Hi Jagan,


> From: Patrick DELAUNAY
> Sent: mardi 19 février 2019 13:28
> Subject: RE: [PATCH v3] dm: spi: Read default speed and mode values from DT
> 
> Hi Jagan,
> 
> > From: Jagan Teki 
> > Sent: jeudi 14 février 2019 18:05
> >
> > On Tue, Feb 12, 2019 at 7:14 PM Patrick DELAUNAY
> > 
> > wrote:
> > >
> > > Hi Jagan
> > >
> > > > From: Jagan Teki 
> > > > Sent: samedi 9 février 2019 17:22
> > > > Subject: Re: [PATCH v3] dm: spi: Read default speed and mode
> > > > values from DT
> > > >
> > > > On Mon, Jan 28, 2019 at 2:37 PM Patrick Delaunay
> > > > 
> > > > wrote:
> > > > >
> > > > > This patch update the behavior introduced by commit 96907c0fe50a ("dm:
> > > > > spi: Read default speed and mode values from DT")
> > > > >
> > > > > In case of DT boot, don't read default speed and mode for SPI
> > > > > from
> > > > > CONFIG_* but instead read from DT node. This will make sure that
> > > > > boards with multiple SPI/QSPI controllers can be probed at
> > > > > different bus frequencies and SPI modes.
> > > > >
> > > > > DT values will be always used when available (full DM support of
> > > > > SPI slave with available DT node) even if speed and mode are
> > > > > requested; for example in splash screen support (in
> > > > > splash_sf_read_raw) or in SPL boot (in spl_spi_load_image).
> > > > > The caller of spi_get_bus_and_cs() no more need to force speed=0.
> > > > >
> > > > > But the current behavior don't change if the SPI slave is not
> > > > > present (device with generic driver is created automatically) or
> > > > > if platdata is used (CONFIG_OF_PLATDATA).
> > > > >
> > > > >
> > > > > Signed-off-by: Patrick Delaunay 
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > - complete rework of the patch-set to avoid regression
> > > > >
> > > > > Changes in v2:
> > > > > - use variables to avoid duplicated code
> > > > >
> > > > >  README   | 3 +++
> > > > >  cmd/sf.c | 3 +--
> > > > >  common/spl/spl_spi.c | 2 ++
> > > > >  drivers/spi/spi-uclass.c | 4 +++-
> > > > >  include/spi.h| 9 +
> > > > >  5 files changed, 14 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/README b/README
> > > > > index 17d56b8..f7fe74f 100644
> > > > > --- a/README
> > > > > +++ b/README
> > > > > @@ -2184,6 +2184,9 @@ The following options need to be configured:
> > > > > CONFIG_SF_DEFAULT_MODE  (see include/spi.h)
> > > > > CONFIG_SF_DEFAULT_SPEED in Hz
> > > > >
> > > > > +   In case of DT boot, SPI don't read default speed and 
> > > > > mode
> > > > > +   from CONFIG_*, but from platdata values computed
> > > > > + from
> > available
> > > > > +   DT node
> > > >
> > > > This has to update in Kconfig help info.
> > >
> > > Ok but witch Kconfig ? whitch config ?
> > >
> > > drivers/mtd/spi/Kconfig
> > > config DM_SPI_FLASH
> > >
> > > PS: In master branch, these define are not in yet managed in
> > > Kconfig, but they
> > are still managed by defines:
> > >scripts/config_whitelist.txt:1713:CONFIG_SF_DEFAULT_MODE
> > >   And so documentation is done in README not in Kconfig
> > >
> > > some migration in Kconfig is pending (moveconfig) ?
> >
> > Yes, moving them and make changes on top would really nice to go. thanks!
> 
> In fact it was a question...
> But I have my answer, no migration are pending on your side.
> 
> So I try yesterday and this morning to start migration in Kconfig but it is 
> more
> difficult than expected initially (make defconfig freeze my PC for some board 
> after
> my modificaitons).
> 
> So I don't expect to make the change on the top of the moving serie at a short
> term, but I will continue to work on that.
> 
> It is possible to inverse the proposed order...
> this patch first and after the Kconfig migration ?

Finally I found and solve the issue, So I push the 2 series :

SPI migration in Kconfig = 
http://patchwork.ozlabs.org/project/uboot/list/?series=94485
V4 = http://patchwork.ozlabs.org/project/uboot/list/?series=94490

Regards

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


Re: [U-Boot] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

2019-02-27 Thread Leigh Brown

Hi Adam,

Thanks very much for your response.

On 2019-02-27 12:50, Adam Ford wrote:
On Wed, Feb 27, 2019 at 5:32 AM Leigh Brown  
wrote:


Hello,

Vagrant Cascadian asked for people to test the version of u-boot
packaged
for Debian Buster.  I tested u-boot on my Dreamplug and found it was 
not
working correctly.  I raised a bug for Debian[1] but I have also 
tested

with the mainline version of u-boot and found the same issues.

The first issue is that the following commit caused u-boot to no 
longer

be able to access usb storage on the Dreamplug:

commit 93b283d49f933f95f3a6f40762936f454ac655a8
Author: Adam Ford 
Date:   Thu Aug 16 13:23:11 2018 -0500



Sorry about that.


 ARM: CPU: arm926ejs: Consolidate cache routines to common file

 Four different boards had different options for enabling cache
 that were virtually all the same.  This consolidates these
 common functions into arch/arm/cpu/arm926ejs/cache.c

 This also has the positive side-effect of enabling cache on
 the Davinci (da850) boards.

 Signed-off-by: Adam Ford 
 [trini: Add mach-at91 to the list of consolidations]
 Signed-off-by: Tom Rini 

I don't have much knowledge of ARM caching, but the following patch
makes
it work again on my Dreamplug.


I am not that familiar with the ARM caching either, I was just hoping
to enable it on the da850 board and compared the various code chunks
between ARM 926 boards and noticed a common thread.  Tom took it and
added some more.


Okay.  Hopefully Tom can comment on my proposed fixes.





diff --git a/arch/arm/mach-kirkwood/cpu.c 
b/arch/arm/mach-kirkwood/cpu.c

index d54de53f31..8a065d73ae 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -291,7 +291,6 @@ int arch_misc_init(void)
temp |= (1 << 22);
writefr_extra_feature_reg(temp);


#ifndef CONFIG_SYS_ICACHE_OFF

-   icache_enable();

#endif

Instead of commenting out that line, try defining
CONFIG_SYS_ICACHE_OFF in your header like you did for the
CONFIG_SYS_DCACHE_OFF and encapsulate the function call with ifdef's
so any other kirkwood processors can enable/disable it independently.


The reason I removed that line is because icache_enable() is called from
enable_caches() which is called from initr_caches() which is in the list
of functions in init_sequence_r[] prior to arch_misc_init().  In other
words, it will already have been called by then if CONFIG_SYS_ICACHE_OFF
is not set.  Does that make sense?


/* Change reset vector to address 0x0 */
temp = get_cr();
set_cr(temp & ~CR_V);
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index f4d717213c..6348935c68 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -79,4 +79,6 @@
  #define CONFIG_SYS_ATA_IDE0_OFFSETMV_SATA_PORT0_OFFSET
  #endif /*CONFIG_MVSATA_IDE*/

+#define CONFIG_SYS_DCACHE_OFF

#define CONFIG_SYS_ICACHE_OFF


The reason I have not done this is because the Kirkwood arch_misc_init()
function was already unconditionally enabling the instruction cache, so
we want to retain that behaviour - I think.  I hope that makes sense.


+
  #endif /* _CONFIG_DREAMPLUG_H */

I'd be grateful if someone could take a look.  If you need me to do 
any

testing  or provide any more information, please let me know.

I found another issue (documented in the same bug).  I'll send a
separate
email about that.

Regards,

Leigh.

--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379


Regards,

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


Re: [U-Boot] [PATCH 5/7] Convert CONFIG_SF_DEFAULT_* to Kconfig

2019-02-27 Thread Simon Goldschmidt

[reducing the CC list as gmail won't let me send otherwise]

On 27.02.2019 15:20, Patrick Delaunay wrote:

This converts the following to Kconfig:
   CONFIG_SF_DEFAULT_BUS
   CONFIG_SF_DEFAULT_CS
   CONFIG_SF_DEFAULT_MODE
   CONFIG_SF_DEFAULT_SPEED

I use moveconfig script and then manual check on generated u-boot.cfg
to solve the remaining issue.

Signed-off-by: Patrick Delaunay 


I admit I haven't followed the patches regarding these defines 
completely, but isn't moving these to Kconfig the opposite of what we want?


I always thought the goal would be to move U-Boot to DM and devicetree 
completely sooner or later (where these defines aren't used). Adding 
them to Kconfig does not make them optional but makes them *always* 
present (but probably with default values if not used).


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


[U-Boot] [PATCH v4] dm: spi: Read default speed and mode values from DT

2019-02-27 Thread Patrick Delaunay
This patch update the behavior introduced by
commit 96907c0fe50a ("dm: spi: Read default speed and mode values from DT")

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_* but instead read from DT node. This will make sure that boards
with multiple SPI/QSPI controllers can be probed at different
bus frequencies and SPI modes.

Remove also use in boards of the value speed=0 (no more supported)
for ENV in SPI by using CONFIG_ENV_SPI_MAX_HZ=0.

DT values will be always used when available (full DM support of
SPI slave with available DT node) even if speed and mode are requested;
for example in splash screen support (in splash_sf_read_raw)
or in SPL boot (in spl_spi_load_image).
The caller of spi_get_bus_and_cs() no more need to force speed=0.

But the current behavior don't change if the SPI slave is not
present (device with generic driver is created automatically)
or if platdata is used (CONFIG_OF_PLATDATA).

Signed-off-by: Patrick Delaunay 
---

Changes in v4:
- rebase on v2019.04-rc2
- after Jagan review depends on Migrate SPI defines to Kconfig
  http://patchwork.ozlabs.org/project/uboot/list/?series=94485
- remove no more supported configuration:
  CONFIG_ENV_SPI_MAX_HZ=0 or CONFIG_ENV_SPI_MODE=0

Changes in v3:
- complete rework of the patch-set to avoid regression

Changes in v2:
- use variables to avoid duplicated code

 cmd/sf.c  | 3 +--
 common/spl/spl_spi.c  | 2 ++
 configs/da850_am18xxevm_defconfig | 4 
 configs/da850evm_defconfig| 4 
 configs/mscc_jr2_defconfig| 4 
 configs/mscc_luton_defconfig  | 4 
 configs/mscc_ocelot_defconfig | 4 
 configs/mscc_serval_defconfig | 4 
 configs/mscc_servalt_defconfig| 4 
 drivers/mtd/spi/Kconfig   | 6 ++
 drivers/spi/spi-uclass.c  | 4 +++-
 include/spi.h | 9 +
 12 files changed, 17 insertions(+), 35 deletions(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index 738ef0e..6ccf98a 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -81,14 +81,13 @@ static int do_spi_flash_probe(int argc, char * const argv[])
 {
unsigned int bus = CONFIG_SF_DEFAULT_BUS;
unsigned int cs = CONFIG_SF_DEFAULT_CS;
+   /* In DM mode, defaults speed and mode will be taken from DT */
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
 #ifdef CONFIG_DM_SPI_FLASH
struct udevice *new, *bus_dev;
int ret;
-   /* In DM mode defaults will be taken from DT */
-   speed = 0, mode = 0;
 #else
struct spi_flash *new;
 #endif
diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
index 8cd4830..9b74473 100644
--- a/common/spl/spl_spi.c
+++ b/common/spl/spl_spi.c
@@ -77,6 +77,8 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
 
/*
 * Load U-Boot image from SPI flash into RAM
+* In DM mode: defaults speed and mode will be
+* taken from DT when available
 */
 
flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
diff --git a/configs/da850_am18xxevm_defconfig 
b/configs/da850_am18xxevm_defconfig
index b1cf9bd..58745fe 100644
--- a/configs/da850_am18xxevm_defconfig
+++ b/configs/da850_am18xxevm_defconfig
@@ -38,10 +38,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
 CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=0
-CONFIG_USE_ENV_SPI_MODE=y
-CONFIG_ENV_SPI_MODE=0
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_DA8XX_GPIO=y
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index e6031b4..5100ee7 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -40,10 +40,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
 CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=0
-CONFIG_USE_ENV_SPI_MODE=y
-CONFIG_ENV_SPI_MODE=0
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mscc_jr2_defconfig b/configs/mscc_jr2_defconfig
index 95562b7..9276df2 100644
--- a/configs/mscc_jr2_defconfig
+++ b/configs/mscc_jr2_defconfig
@@ -38,10 +38,6 @@ CONFIG_OF_LIST="jr2_pcb110 jr2_pcb111 serval2_pcb112"
 CONFIG_DTB_RESELECT=y
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=0
-CONFIG_USE_ENV_SPI_MODE=y
-CONFIG_ENV_SPI_MODE=0
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mscc_luton_defconfig b/configs/mscc_luton_defconfig
index 162a514..0fdd9b8 100644
--- a/configs/mscc_luton_defconfig
+++ b/configs/mscc_luton_defconfig
@@ -44,10 +44,6 @@ CONFIG_OF_LIST="luton_pcb090 luton_pcb091"
 CONFIG_DTB_RESELECT=y
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=0
-CONFIG_USE_ENV_SPI_MODE=y
-CONFIG_ENV_SPI_MODE=0
 CONFIG_NET_RANDOM_ETHADDR=y
 

[U-Boot] [PATCH v4 0/1] Read default speed and mode values from DT

2019-02-27 Thread Patrick Delaunay

This patch-set finish the previous serie:
http://patchwork.ozlabs.org/project/uboot/list/?series=76834

and also replace the serie:
"Remove defines for SPI default speed and mode "
http://patchwork.ozlabs.org/project/uboot/list/?series=80769=*

This new version is a complete rework after several remarks
and regression for these 2 patchset, mainly when SPI node
configuration is not in DT, when platdata is used.

I take some time to check the code and this proposal is a rework
of commit 96907c0fe50a ("dm: spi: Read default speed and mode values from DT")

This patch avoid spi_get_bus_and_cs() callers to force value of
parameter speed to 0 for some board (without DT node)
and regression for other board (as i was the case in my previous
Series V2).

I see this kind of problem in file env/sf.c with first commit
96907c0fe50a ("dm: spi: Read default speed and mode values from DT")
and come-back to the previous behavior with CONFIG_ in the commit
25a17652c9c2 ("fix: env: Fix the SPI flash device setup for DM mode")

So I decide to don't remove the defines used for default value
of speed and mode but they are no more used when platdata
is available.

That avoid regression when spi_get_bus_and_cs is directly called.

NB: I don't sure that the behavior of 'compatibility' function
spi_setup_slave() will be still is still the correct on
(in some case speed and mode will parameter will be not used).

Tested on my board only for the boot from SPI NOR
so when spl_spi_load_image() is called in SPL.


Changes in v4:
- rebase on v2019.04-rc2
- after Jagan review depends on Migrate SPI defines to Kconfig
  http://patchwork.ozlabs.org/project/uboot/list/?series=94485
- remove no more supported configuration:
  CONFIG_ENV_SPI_MAX_HZ=0 or CONFIG_ENV_SPI_MODE=0

Changes in v3:
- complete rework of the patch-set to avoid regression

Changes in v2:
- use variables to avoid duplicated code

Patrick Delaunay (1):
  dm: spi: Read default speed and mode values from DT

 cmd/sf.c  | 3 +--
 common/spl/spl_spi.c  | 2 ++
 configs/da850_am18xxevm_defconfig | 4 
 configs/da850evm_defconfig| 4 
 configs/mscc_jr2_defconfig| 4 
 configs/mscc_luton_defconfig  | 4 
 configs/mscc_ocelot_defconfig | 4 
 configs/mscc_serval_defconfig | 4 
 configs/mscc_servalt_defconfig| 4 
 drivers/mtd/spi/Kconfig   | 6 ++
 drivers/spi/spi-uclass.c  | 4 +++-
 include/spi.h | 9 +
 12 files changed, 17 insertions(+), 35 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 7/7] Convert CONFIG_ENV_SPI_* to Kconfig

2019-02-27 Thread Patrick Delaunay
This converts the following to Kconfig:
  CONFIG_ENV_SPI_BUS
  CONFIG_ENV_SPI_CS
  CONFIG_ENV_SPI_MAX_HZ
  CONFIG_ENV_SPI_MODE

Most of time these value are not needed, CONFIG_SF_DEFAULT
with same value is used, so I introduced CONFIG_USE_ENV_SPI_*
to force the associated value for the environment.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-kirkwood/include/mach/config.h  | 15 
 arch/arm/mach-mvebu/include/mach/config.h | 15 
 configs/M52277EVB_stmicro_defconfig   |  2 +
 configs/M54418TWR_defconfig   |  2 +
 configs/M54418TWR_serial_mii_defconfig|  2 +
 configs/M54418TWR_serial_rmii_defconfig   |  2 +
 configs/M54451EVB_stmicro_defconfig   |  2 +
 configs/M54455EVB_stm33_defconfig |  2 +
 configs/SBx81LIFKW_defconfig  |  2 +
 configs/SBx81LIFXCAT_defconfig|  2 +
 configs/ap121_defconfig   |  2 +
 configs/ap143_defconfig   |  2 +
 configs/at91sam9260ek_dataflash_cs0_defconfig |  2 +
 configs/at91sam9260ek_dataflash_cs1_defconfig |  2 +
 configs/at91sam9261ek_dataflash_cs0_defconfig |  2 +
 configs/at91sam9261ek_dataflash_cs3_defconfig |  2 +
 configs/at91sam9263ek_dataflash_cs0_defconfig |  2 +
 configs/at91sam9263ek_dataflash_defconfig |  2 +
 configs/at91sam9g10ek_dataflash_cs0_defconfig |  2 +
 configs/at91sam9g10ek_dataflash_cs3_defconfig |  2 +
 configs/at91sam9g20ek_dataflash_cs0_defconfig |  2 +
 configs/at91sam9g20ek_dataflash_cs1_defconfig |  2 +
 configs/at91sam9rlek_dataflash_defconfig  |  2 +
 configs/at91sam9xeek_dataflash_cs0_defconfig  |  2 +
 configs/at91sam9xeek_dataflash_cs1_defconfig  |  2 +
 configs/controlcenterdc_defconfig |  2 +
 configs/d2net_v2_defconfig|  2 +
 configs/da850_am18xxevm_defconfig |  4 ++
 configs/da850evm_defconfig|  4 ++
 configs/db-88f6720_defconfig  |  2 +
 configs/db-88f6820-amc_defconfig  |  2 +
 configs/db-88f6820-gp_defconfig   |  2 +
 configs/db-mv784mp-gp_defconfig   |  2 +
 configs/dreamplug_defconfig   |  2 +
 configs/ds109_defconfig   |  2 +
 configs/ds414_defconfig   |  2 +
 configs/ethernut5_defconfig   |  2 +
 configs/inetspace_v2_defconfig|  2 +
 configs/ls1012aqds_qspi_defconfig |  7 +++-
 configs/ls1012aqds_tfa_defconfig  |  6 +++
 configs/ls1043aqds_tfa_defconfig  |  2 +
 configs/ls1046aqds_tfa_defconfig  |  2 +
 configs/maxbcm_defconfig  |  2 +
 configs/meesc_dataflash_defconfig |  2 +
 configs/mscc_jr2_defconfig|  4 ++
 configs/mscc_luton_defconfig  |  4 ++
 configs/mscc_ocelot_defconfig |  4 ++
 configs/mscc_serval_defconfig |  4 ++
 configs/mscc_servalt_defconfig|  4 ++
 configs/net2big_v2_defconfig  |  2 +
 configs/netspace_lite_v2_defconfig|  2 +
 configs/netspace_max_v2_defconfig |  2 +
 configs/netspace_mini_v2_defconfig|  2 +
 configs/netspace_v2_defconfig |  2 +
 configs/peach-pi_defconfig|  2 +
 configs/peach-pit_defconfig   |  2 +
 configs/smdk5250_defconfig|  2 +
 configs/smdk5420_defconfig|  2 +
 configs/snow_defconfig|  2 +
 configs/spring_defconfig  |  2 +
 configs/stmark2_defconfig |  2 +
 configs/theadorable_debug_defconfig   |  2 +
 configs/trimslice_defconfig   |  2 +
 configs/turris_omnia_defconfig|  2 +
 configs/usb_a9263_dataflash_defconfig |  2 +
 env/Kconfig   | 53 +++
 env/sf.c  | 13 ---
 include/configs/B4860QDS.h|  4 --
 include/configs/BSC9131RDB.h  |  4 --
 include/configs/BSC9132QDS.h  |  4 --
 include/configs/C29XPCIE.h|  4 --
 include/configs/M52277EVB.h   |  3 --
 include/configs/M54418TWR.h   |  1 -
 include/configs/M54451EVB.h   |  1 -
 include/configs/M54455EVB.h   |  3 --
 include/configs/MPC8536DS.h   |  4 --
 include/configs/P1010RDB.h|  4 --
 include/configs/P1022DS.h |  4 --
 include/configs/P2041RDB.h|  4 --
 include/configs/SBx81LIFKW.h  |  4 --
 include/configs/SBx81LIFXCAT.h|  4 --
 include/configs/T102xQDS.h|  4 --
 include/configs/T102xRDB.h|  4 --
 include/configs/T1040QDS.h|  4 --
 include/configs/T104xRDB.h|  

Re: [U-Boot] U-Boot Digest, Vol 129, Issue 63

2019-02-27 Thread Terrance Chiang
Currently switch is unable to boot pass Nintendo logo, will revert a nand
backup to the first uboot error which includes  and the files created from
Uboot. The rest of the error after that are (after running different files
like kip files are results of me trying to retrieve inital setup.

Is it because of the firmware update 6.20 that messes everything. Some
payloads returns with tesc key and tes root key. All payloads can't
retrieve biskeys. Red QR code or only 3 keys, Tesc keys, SBW and Aes key
which is only two amd it indicate Aes0 and a AES test key.

However, i did not remember what i did, and i got the crypto amd tweats for
biskeys Unable to do clean nand backup with any cfw. Restore from any
firmware will give error and can't boot normal or cfw. But can enter cfw
mainmenu to launch payload. Will let you all know  what are the results
when done

Thanks and best regards
Terrance  Chiang

On Wed, 27 Feb 2019, 20:00 ,  wrote:

> Send U-Boot mailing list submissions to
> u-boot@lists.denx.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.denx.de/listinfo/u-boot
> or, via email, send a message with subject or body 'help' to
> u-boot-requ...@lists.denx.de
>
> You can reach the person managing the list at
> u-boot-ow...@lists.denx.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of U-Boot digest..."
>
>
> Today's Topics:
>
>1. Re: [PATCH] efi_loader: Fix serial console size detection
>   (Matthias Brugger)
>2. Re: [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file
>   must fit into 32 KiB (Simon Goldschmidt)
>3. SDCRARD boot on Intel Arria10 SOCDK (Marcel Gielen [Celestia-STS])
>4. [PATCH v2] fs: fat: fix reading non-cluster-aligned root
>   directory (Anssi Hannula)
>
>
> --
>
> Message: 1
> Date: Wed, 27 Feb 2019 10:55:00 +0100
> From: Matthias Brugger 
> To: Heinrich Schuchardt , matthias@kernel.org,
> ag...@csgraf.de
> Cc: u-boot@lists.denx.de, Matthias Brugger 
> Subject: Re: [U-Boot] [PATCH] efi_loader: Fix serial console size
> detection
> Message-ID: <0d3f133f-ec80-bfdd-7b6b-3b35e493a...@suse.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 26/02/2019 17:58, Heinrich Schuchardt wrote:
> > On 2/26/19 12:46 PM, matthias@kernel.org wrote:
> >> From: Matthias Brugger 
> >>
> >> Function term_read_reply tries to read from the serial console until
> >> the end_char was read. This can hang forever if we are, for some reason,
> >> not be able to read the full response (e.g. serial buffer too small,
> >> frame error). This patch moves the timeout detection into
> >> term_read_reply to assure we will make progress.
> >>
> >> Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
> >> Signed-off-by: Matthias Brugger 
> >
> > Thanks Matthias for the patch.
> >
> > The general direction is right. Yet I would prefer if you could move the
> > waiting loop as described below.
> >
> >> ---
> >>  lib/efi_loader/efi_console.c | 63 +---
> >>  1 file changed, 37 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> >> index 66c33a551d..817220455f 100644
> >> --- a/lib/efi_loader/efi_console.c
> >> +++ b/lib/efi_loader/efi_console.c
> >> @@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode =
> {
> >>  .cursor_visible = 1,
> >>  };
> >>
> >> +static int term_get_char(char *c)
> >> +{
> >> +if (tstc()) {
> >> +*c = getc();
> >> +return 0;
> >> +}
> >> +
> >> +return 1;
> >
> > The function signals an error if the character to read is not yet in the
> > UART buffer. I think it would be preferable to put the waiting time (100
> > ms is sufficient at 110 baud and above) into this function instead. This
> > has the following advantages:
> >
> > - We would need only one waiting loop.
> > - We could reuse the function in function efi_cin_read_key() where we
> >   have another chance to hang waiting for a character.
> >
>
> Ok, I'll do that in v2.
>
> >> +}
> >> +
> >>  /*
> >>   * Receive and parse a reply from the terminal.
> >>   *
> >> @@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char
> end_char)
> >>  {
> >>  char c;
> >>  int i = 0;
> >> +u64 timeout;
> >>
> >> -c = getc();
> >> -if (c != cESC)
> >> +/* Allow up to one second for the response */
> >> +timeout = timer_get_us() + 100;
> >
> > Even at 110 baud a waiting time of 100 ms is sufficient.
> >
>
> So we don't have to wait up to one second for the first character to
> arrive as
> we did in query_console_serial() before this patch?
>
> >> +while (!tstc())
> >> +if (timer_get_us() > timeout)
> >> +return -1;
> >
> > This loop could be moved to term_get_char().
> >
> >> +
> >> +if 

[U-Boot] [PATCH 0/7] Migrate SPI defines to Kconfig

2019-02-27 Thread Patrick Delaunay

This serie is a proposal to convert all SPI configuration settings
in Kconfig :
+ parameters for SF command
  - CONFIG_SF_DEFAULT_BUS
  - CONFIG_SF_DEFAULT_CS
  - CONFIG_SF_DEFAULT_MODE
  - CONFIG_SF_DEFAULT_SPEED
+ parameters for SSPI command
  - CONFIG_DEFAULT_SPI_BUS
  - CONFIG_DEFAULT_SPI_MODE
+ parameters for ENV in SPI
  - CONFIG_ENV_SPI_BUS
  - CONFIG_ENV_SPI_CS
  - CONFIG_ENV_SPI_MAX_HZ
  - CONFIG_ENV_SPI_MODE

I make this work after the remarks of Jagan Teki.
on http://patchwork.ozlabs.org/patch/1031768/
[U-Boot,v3] dm: spi: Read default speed and mode values from DT

So it is a preliminary for v4 on this patch.

This commit includes a full migration using moveconfig.py to ensure
that each commit compiles.

To allow compilation, I also move CMD in Kconfig for some board.

I introduce CONFIG_USE_ENV_SPI* to handle absent value
(CONFIG_SF_DEFAULT_* is used) and use some post-processing to solve
the remaining issue and remove the unnecessary configuration in defconfig
(when default value can be used).
I make manual check at the end.

Compilation is OK on Travis:
https://travis-ci.org/patrickdelaunay/u-boot/builds/498044826

This v1 can be see as a starting point based on v2019.04-rc2.
Any feedback or test is welcome.



Patrick Delaunay (7):
  bcm7445: move some configuration in defconfig file
  controlcenterdc: move some configuration in defconfig file
  exynos: replace CONFIG_ENV_SPI_BASE by CONFIG_SYS_SPI_BASE
  tqma6s_wru4_mmc: manage board_spi_cs_gpio correctly
  Convert CONFIG_SF_DEFAULT_* to Kconfig
  Convert CONFIG_DEFAULT_SPI_* to Kconfig
  Convert CONFIG_ENV_SPI_* to Kconfig

 README | 15 --
 arch/arm/mach-exynos/spl_boot.c|  2 +-
 arch/arm/mach-kirkwood/include/mach/config.h   | 15 --
 arch/arm/mach-mvebu/include/mach/config.h  | 15 --
 board/Arcturus/ucp1020/cmd_arc.c   | 13 --
 board/tqc/tqma6/tqma6.c|  2 +
 cmd/Kconfig| 12 -
 cmd/spi.c  |  7 ---
 configs/B4420QDS_NAND_defconfig|  2 +
 configs/B4420QDS_SPIFLASH_defconfig|  2 +
 configs/B4420QDS_defconfig |  2 +
 configs/B4860QDS_NAND_defconfig|  2 +
 configs/B4860QDS_SECURE_BOOT_defconfig |  2 +
 configs/B4860QDS_SPIFLASH_defconfig|  2 +
 configs/B4860QDS_SRIO_PCIE_BOOT_defconfig  |  2 +
 configs/B4860QDS_defconfig |  2 +
 configs/BSC9131RDB_NAND_SYSCLK100_defconfig|  2 +
 configs/BSC9131RDB_NAND_defconfig  |  2 +
 configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig|  2 +
 configs/BSC9131RDB_SPIFLASH_defconfig  |  2 +
 configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig |  2 +
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig|  2 +
 configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig |  2 +
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig|  2 +
 configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig  |  2 +
 configs/BSC9132QDS_NOR_DDRCLK100_defconfig |  2 +
 configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig  |  2 +
 configs/BSC9132QDS_NOR_DDRCLK133_defconfig |  2 +
 .../BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig   |  2 +
 configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig  |  2 +
 .../BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig   |  2 +
 configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig  |  2 +
 .../BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig |  2 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK100_defconfig|  2 +
 .../BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig |  2 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK133_defconfig|  2 +
 configs/C29XPCIE_NAND_defconfig|  2 +
 configs/C29XPCIE_NOR_SECBOOT_defconfig |  2 +
 configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig|  2 +
 configs/C29XPCIE_SPIFLASH_defconfig|  2 +
 configs/C29XPCIE_defconfig |  2 +
 configs/M52277EVB_stmicro_defconfig|  2 +
 configs/M54418TWR_defconfig|  2 +
 configs/M54418TWR_serial_mii_defconfig |  2 +
 configs/M54418TWR_serial_rmii_defconfig|  2 +
 configs/M54451EVB_stmicro_defconfig|  2 +
 configs/M54455EVB_stm33_defconfig  |  2 +
 configs/MPC8536DS_36BIT_defconfig  |  2 +
 configs/MPC8536DS_SDCARD_defconfig |  2 +
 configs/MPC8536DS_SPIFLASH_defconfig   |  2 +
 configs/MPC8536DS_defconfig|  2 +
 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig   |  2 +
 configs/P1010RDB-PA_36BIT_NAND_defconfig   |  2 +
 configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig|  2 +
 configs/P1010RDB-PA_36BIT_NOR_defconfig|  2 +
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig |  2 +
 

[U-Boot] [PATCH v3 8/9] spi: sun4i: Driver cleanup

2019-02-27 Thread Jagan Teki
- drop unused macros.
- use base instead of base_addr, for better code readability
- move .probe and .ofdata_to_platdata functions in required
  places to add platdata support in future.
- use sentinel sun4i_spi_ids.

Signed-off-by: Jagan Teki 
---
 drivers/spi/sun4i_spi.c | 190 +---
 1 file changed, 80 insertions(+), 110 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index da9984c004..dbfeac77ee 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -33,57 +33,16 @@
 
 #include 
 
-#define SUN4I_RXDATA_REG   0x00
-
-#define SUN4I_TXDATA_REG   0x04
-
-#define SUN4I_CTL_REG  0x08
-#define SUN4I_CTL_ENABLE   BIT(0)
-#define SUN4I_CTL_MASTER   BIT(1)
-#define SUN4I_CTL_CPHA BIT(2)
-#define SUN4I_CTL_CPOL BIT(3)
-#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
-#define SUN4I_CTL_LMTF BIT(6)
-#define SUN4I_CTL_TF_RST   BIT(8)
-#define SUN4I_CTL_RF_RST   BIT(9)
-#define SUN4I_CTL_XCH  BIT(10)
-#define SUN4I_CTL_CS_MASK  0x3000
-#define SUN4I_CTL_CS(cs)   (((cs) << 12) & SUN4I_CTL_CS_MASK)
-#define SUN4I_CTL_DHB  BIT(15)
-#define SUN4I_CTL_CS_MANUALBIT(16)
-#define SUN4I_CTL_CS_LEVEL BIT(17)
-#define SUN4I_CTL_TP   BIT(18)
-
-#define SUN4I_INT_CTL_REG  0x0c
-#define SUN4I_INT_CTL_RF_F34   BIT(4)
-#define SUN4I_INT_CTL_TF_E34   BIT(12)
-#define SUN4I_INT_CTL_TC   BIT(16)
-
-#define SUN4I_INT_STA_REG  0x10
-
-#define SUN4I_DMA_CTL_REG  0x14
-
-#define SUN4I_WAIT_REG 0x18
-
-#define SUN4I_CLK_CTL_REG  0x1c
-#define SUN4I_CLK_CTL_CDR2_MASK0xff
-#define SUN4I_CLK_CTL_CDR2(div)((div) & 
SUN4I_CLK_CTL_CDR2_MASK)
-#define SUN4I_CLK_CTL_CDR1_MASK0xf
-#define SUN4I_CLK_CTL_CDR1(div)(((div) & 
SUN4I_CLK_CTL_CDR1_MASK) << 8)
-#define SUN4I_CLK_CTL_DRS  BIT(12)
-
-#define SUN4I_MAX_XFER_SIZE0xff
-
-#define SUN4I_BURST_CNT_REG0x20
-#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)
-
-#define SUN4I_XMIT_CNT_REG 0x24
-#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+DECLARE_GLOBAL_DATA_PTR;
 
-#define SUN4I_FIFO_STA_REG 0x28
-#define SUN4I_FIFO_STA_RF_CNT_BITS 0
-#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
-#define SUN4I_FIFO_STA_TF_CNT_BITS 16
+/* sun4i spi registers */
+#define SUN4I_RXDATA_REG   0x00
+#define SUN4I_TXDATA_REG   0x04
+#define SUN4I_CTL_REG  0x08
+#define SUN4I_CLK_CTL_REG  0x1c
+#define SUN4I_BURST_CNT_REG0x20
+#define SUN4I_XMIT_CNT_REG 0x24
+#define SUN4I_FIFO_STA_REG 0x28
 
 /* sun6i spi registers */
 #define SUN6I_GBL_CTL_REG  0x04
@@ -97,12 +56,25 @@
 #define SUN6I_TXDATA_REG   0x200
 #define SUN6I_RXDATA_REG   0x300
 
-#define SUN4I_SPI_MAX_RATE 2400
-#define SUN4I_SPI_MIN_RATE 3000
-#define SUN4I_SPI_DEFAULT_RATE 100
-#define SUN4I_SPI_TIMEOUT_US   100
+/* sun spi bits */
+#define SUN4I_CTL_ENABLE   BIT(0)
+#define SUN4I_CTL_MASTER   BIT(1)
+#define SUN4I_CLK_CTL_CDR2_MASK0xff
+#define SUN4I_CLK_CTL_CDR2(div)((div) & 
SUN4I_CLK_CTL_CDR2_MASK)
+#define SUN4I_CLK_CTL_CDR1_MASK0xf
+#define SUN4I_CLK_CTL_CDR1(div)(((div) & 
SUN4I_CLK_CTL_CDR1_MASK) << 8)
+#define SUN4I_CLK_CTL_DRS  BIT(12)
+#define SUN4I_MAX_XFER_SIZE0xff
+#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)
+#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+#define SUN4I_FIFO_STA_RF_CNT_BITS 0
+
+#define SUN4I_SPI_MAX_RATE 2400
+#define SUN4I_SPI_MIN_RATE 3000
+#define SUN4I_SPI_DEFAULT_RATE 100
+#define SUN4I_SPI_TIMEOUT_US   100
 
-#define SPI_REG(priv, reg) ((priv)->base_addr + \
+#define SPI_REG(priv, reg) ((priv)->base + \
(priv)->variant->regs[reg])
 #define SPI_BIT(priv, bit) ((priv)->variant->bits[bit])
 #define SPI_CS(priv, cs)   (((cs) << SPI_BIT(priv, 
SPI_TCR_CS_SEL)) & \
@@ -149,7 +121,7 @@ struct sun4i_spi_variant {
 
 struct sun4i_spi_platdata {
struct sun4i_spi_variant *variant;
-   u32 base_addr;
+   u32 base;
u32 max_hz;
 };
 
@@ -157,7 +129,7 @@ struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
struct clk clk_ahb, clk_mod;
struct reset_ctl reset;
-   u32 base_addr;
+   u32 base;
u32 freq;
u32 mode;
 
@@ -165,8 +137,6 @@ struct sun4i_spi_priv {
u8 *rx_buf;
 };
 
-DECLARE_GLOBAL_DATA_PTR;
-
 static inline void 

[U-Boot] [PATCH v3 9/9] spi: Rename sun4i_spi.c into spi-sunxi.c

2019-02-27 Thread Jagan Teki
Now the same SPI controller driver is reusable in all Allwinner
SoC variants, so rename the existing sun4i_spi.c into spi-sunxi.c
which eventually look like a common sunxi driver.

Also update the function, variable, structure names in driver from
sun4i into sunxi.

Signed-off-by: Jagan Teki 
---
 drivers/spi/Kconfig  | 12 +++-
 drivers/spi/Makefile |  2 +-
 drivers/spi/{sun4i_spi.c => spi-sunxi.c} |  0
 3 files changed, 8 insertions(+), 6 deletions(-)
 rename drivers/spi/{sun4i_spi.c => spi-sunxi.c} (100%)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 15207d23c1..098372e093 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -213,6 +213,13 @@ config SANDBOX_SPI
};
  };
 
+config SPI_SUNXI
+   bool "Allwinner SoC SPI controllers"
+   help
+ Enable the Allwinner SoC SPi controller driver.
+
+ Same controller driver can reuse in all Allwinner SoC variants.
+
 config STM32_QSPI
bool "STM32F7 QSPI driver"
depends on STM32F7
@@ -222,11 +229,6 @@ config STM32_QSPI
  used to access the SPI NOR flash chips on platforms embedding
  this ST IP core.
 
-config SUN4I_SPI
-   bool "Allwinner A10/A31 SoCs SPI controller"
-   help
- This enables using the SPI controller on the Allwinner A10/A31 SoCs.
-
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3902671293..01907bef79 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -48,10 +48,10 @@ obj-$(CONFIG_PL022_SPI) += pl022_spi.o
 obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
 obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
+obj-$(CONFIG_SPI_SUNXI) += spi-sunxi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
 obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
-obj-$(CONFIG_SUN4I_SPI) += sun4i_spi.o
 obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
 obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
 obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/spi-sunxi.c
similarity index 100%
rename from drivers/spi/sun4i_spi.c
rename to drivers/spi/spi-sunxi.c
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 6/9] spi: sun4i: Add CLK support

2019-02-27 Thread Jagan Teki
Add CLK support to enable AHB and MOD SPI clocks on sun4i_spi driver.

Clock disablement could be done while releasing the bus transfer, but
the existing code doesn't disable the clocks it only taken care of clock
enablement globally in probe.

So to make a proper clock handling, the clocks should enable it in claim
and disable it in release.

This patch would also do that change, by enable and disable clock in
proper order.

Signed-off-by: Jagan Teki 
Reviewed-by: Andre Przywara 
---
 drivers/spi/sun4i_spi.c | 56 +++--
 1 file changed, 48 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 82e69a6b6a..4324d686eb 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -19,6 +19,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 #include 
 
 #define SUN4I_RXDATA_REG   0x00
@@ -140,6 +139,7 @@ struct sun4i_spi_platdata {
 
 struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
+   struct clk clk_ahb, clk_mod;
u32 base_addr;
u32 freq;
u32 mode;
@@ -266,13 +266,34 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
return 0;
 }
 
-static inline void sun4i_spi_enable_clock(void)
+static inline int sun4i_spi_set_clock(struct udevice *dev, bool enable)
 {
-   struct sunxi_ccm_reg *const ccm =
-   (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE;
+   struct sun4i_spi_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   if (!enable) {
+   clk_disable(>clk_ahb);
+   clk_disable(>clk_mod);
+   return 0;
+   }
 
-   setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0));
-   writel((1 << 31), >spi0_clk_cfg);
+   ret = clk_enable(>clk_ahb);
+   if (ret) {
+   dev_err(dev, "failed to enable ahb clock (ret=%d)\n", ret);
+   return ret;
+   }
+
+   ret = clk_enable(>clk_mod);
+   if (ret) {
+   dev_err(dev, "failed to enable mod clock (ret=%d)\n", ret);
+   goto err_ahb;
+   }
+
+   return 0;
+
+err_ahb:
+   clk_disable(>clk_ahb);
+   return ret;
 }
 
 static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
@@ -296,8 +317,20 @@ static int sun4i_spi_probe(struct udevice *bus)
 {
struct sun4i_spi_platdata *plat = dev_get_platdata(bus);
struct sun4i_spi_priv *priv = dev_get_priv(bus);
+   int ret;
+
+   ret = clk_get_by_name(bus, "ahb", >clk_ahb);
+   if (ret) {
+   dev_err(dev, "failed to get ahb clock\n");
+   return ret;
+   }
+
+   ret = clk_get_by_name(bus, "mod", >clk_mod);
+   if (ret) {
+   dev_err(dev, "failed to get mod clock\n");
+   return ret;
+   }
 
-   sun4i_spi_enable_clock();
sun4i_spi_parse_pins(bus);
 
priv->variant = plat->variant;
@@ -310,6 +343,11 @@ static int sun4i_spi_probe(struct udevice *bus)
 static int sun4i_spi_claim_bus(struct udevice *dev)
 {
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
+   int ret;
+
+   ret = sun4i_spi_set_clock(dev->parent, true);
+   if (ret)
+   return ret;
 
setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
 SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
@@ -326,6 +364,8 @@ static int sun4i_spi_release_bus(struct udevice *dev)
 
clrbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE);
 
+   sun4i_spi_set_clock(dev->parent, false);
+
return 0;
 }
 
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 3/9] spi: sun4i: Simplify reg writes using set/clrbits_le32

2019-02-27 Thread Jagan Teki
Update the existing register writes using setbits_le32 and
clrbits_le32 in required places.

Signed-off-by: Jagan Teki 
---
 drivers/spi/sun4i_spi.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index f5f2d5635a..0b1663038c 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -283,20 +283,18 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
 {
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
 
-   writel(SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP |
-  SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW,
-  >regs->ctl);
+   setbits_le32(>regs->ctl, SUN4I_CTL_ENABLE |
+SUN4I_CTL_MASTER | SUN4I_CTL_TP |
+SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW);
+
return 0;
 }
 
 static int sun4i_spi_release_bus(struct udevice *dev)
 {
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
-   u32 reg;
 
-   reg = readl(>regs->ctl);
-   reg &= ~SUN4I_CTL_ENABLE;
-   writel(reg, >regs->ctl);
+   clrbits_le32(>regs->ctl, SUN4I_CTL_ENABLE);
 
return 0;
 }
@@ -309,7 +307,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
 
u32 len = bitlen / 8;
-   u32 reg, rx_fifocnt;
+   u32 rx_fifocnt;
u8 nbytes;
int ret;
 
@@ -324,10 +322,8 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
if (flags & SPI_XFER_BEGIN)
sun4i_spi_set_cs(bus, slave_plat->cs, true);
 
-   reg = readl(>regs->ctl);
-
/* Reset FIFOs */
-   writel(reg | SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST, >regs->ctl);
+   setbits_le32(>regs->ctl, SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST);
 
while (len) {
/* Setup the transfer now... */
@@ -341,8 +337,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
sun4i_spi_fill_fifo(priv, nbytes);
 
/* Start the transfer */
-   reg = readl(>regs->ctl);
-   writel(reg | SUN4I_CTL_XCH, >regs->ctl);
+   setbits_le32(>regs->ctl, SUN4I_CTL_XCH);
 
/* Wait till RX FIFO to be empty */
ret = readl_poll_timeout(>regs->fifo_sta, rx_fifocnt,
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 7/9] spi: sun4: Add A31 spi controller support

2019-02-27 Thread Jagan Teki
The usual SPI transmission protocol in Allwinner A10 and A31
controllers share similar context with minimal changes in register
offsets along with few additional register bits on A31.

So, add A31 spi controller support in existing sun4i_spi with A31
specific register offsets and bits.

Signed-off-by: Jagan Teki 
---
 drivers/spi/Kconfig |   4 +-
 drivers/spi/sun4i_spi.c | 101 +++-
 2 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ac7fbab841..15207d23c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -223,9 +223,9 @@ config STM32_QSPI
  this ST IP core.
 
 config SUN4I_SPI
-   bool "Allwinner A10 SoCs SPI controller"
+   bool "Allwinner A10/A31 SoCs SPI controller"
help
- SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
+ This enables using the SPI controller on the Allwinner A10/A31 SoCs.
 
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 4324d686eb..da9984c004 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -84,6 +85,18 @@
 #define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
 #define SUN4I_FIFO_STA_TF_CNT_BITS 16
 
+/* sun6i spi registers */
+#define SUN6I_GBL_CTL_REG  0x04
+#define SUN6I_TFR_CTL_REG  0x08
+#define SUN6I_FIFO_CTL_REG 0x18
+#define SUN6I_FIFO_STA_REG 0x1c
+#define SUN6I_CLK_CTL_REG  0x24
+#define SUN6I_BURST_CNT_REG0x30
+#define SUN6I_XMIT_CNT_REG 0x34
+#define SUN6I_BURST_CTL_REG0x38
+#define SUN6I_TXDATA_REG   0x200
+#define SUN6I_RXDATA_REG   0x300
+
 #define SUN4I_SPI_MAX_RATE 2400
 #define SUN4I_SPI_MIN_RATE 3000
 #define SUN4I_SPI_DEFAULT_RATE 100
@@ -112,6 +125,7 @@ enum sun4i_spi_regs {
 /* sun spi register bits */
 enum sun4i_spi_bits {
SPI_GCR_TP,
+   SPI_GCR_SRST,
SPI_TCR_CPHA,
SPI_TCR_CPOL,
SPI_TCR_CS_ACTIVE_LOW,
@@ -129,6 +143,8 @@ struct sun4i_spi_variant {
const unsigned long *regs;
const u32 *bits;
u32 fifo_depth;
+   bool has_soft_reset;
+   bool has_burst_ctl;
 };
 
 struct sun4i_spi_platdata {
@@ -140,6 +156,7 @@ struct sun4i_spi_platdata {
 struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
struct clk clk_ahb, clk_mod;
+   struct reset_ctl reset;
u32 base_addr;
u32 freq;
u32 mode;
@@ -258,7 +275,10 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
if (pin < 0)
break;
 
-   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
+   if (IS_ENABLED(CONFIG_MACH_SUN50I))
+   sunxi_gpio_set_cfgpin(pin, SUN50I_GPC_SPI0);
+   else
+   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
sunxi_gpio_set_drv(pin, drive);
sunxi_gpio_set_pull(pin, pull);
}
@@ -274,6 +294,8 @@ static inline int sun4i_spi_set_clock(struct udevice *dev, 
bool enable)
if (!enable) {
clk_disable(>clk_ahb);
clk_disable(>clk_mod);
+   if (reset_valid(>reset))
+   reset_assert(>reset);
return 0;
}
 
@@ -289,8 +311,18 @@ static inline int sun4i_spi_set_clock(struct udevice *dev, 
bool enable)
goto err_ahb;
}
 
+   if (reset_valid(>reset)) {
+   ret = reset_deassert(>reset);
+   if (ret) {
+   dev_err(dev, "failed to deassert reset\n");
+   goto err_mod;
+   }
+   }
+
return 0;
 
+err_mod:
+   clk_disable(>clk_mod);
 err_ahb:
clk_disable(>clk_ahb);
return ret;
@@ -331,6 +363,12 @@ static int sun4i_spi_probe(struct udevice *bus)
return ret;
}
 
+   ret = reset_get_by_index(bus, 0, >reset);
+   if (ret && ret != -ENOENT) {
+   dev_err(dev, "failed to get reset\n");
+   return ret;
+   }
+
sun4i_spi_parse_pins(bus);
 
priv->variant = plat->variant;
@@ -352,6 +390,10 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
 SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
 
+   if (priv->variant->has_soft_reset)
+   setbits_le32(SPI_REG(priv, SPI_GCR),
+SPI_BIT(priv, SPI_GCR_SRST));
+
setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
 SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW));
 
@@ -404,6 +446,10 @@ static int sun4i_spi_xfer(struct 

[U-Boot] [PATCH v3 5/9] spi: sun4i: Support fifo_depth via drvdata

2019-02-27 Thread Jagan Teki
Support fifo_depth via drvdata instead of macro definition, this would
eventually reduce another macro definition for new SPI controller fifo
depth support addition.

Signed-off-by: Jagan Teki 
Reviewed-by: Andre Przywara 
---
 drivers/spi/sun4i_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index be026e6554..82e69a6b6a 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -33,8 +33,6 @@
 
 #include 
 
-#define SUN4I_FIFO_DEPTH   64
-
 #define SUN4I_RXDATA_REG   0x00
 
 #define SUN4I_TXDATA_REG   0x04
@@ -131,6 +129,7 @@ enum sun4i_spi_bits {
 struct sun4i_spi_variant {
const unsigned long *regs;
const u32 *bits;
+   u32 fifo_depth;
 };
 
 struct sun4i_spi_platdata {
@@ -359,7 +358,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
 
while (len) {
/* Setup the transfer now... */
-   nbytes = min(len, (u32)(SUN4I_FIFO_DEPTH - 1));
+   nbytes = min(len, (priv->variant->fifo_depth - 1));
 
/* Setup the counters */
writel(SUN4I_BURST_CNT(nbytes), SPI_REG(priv, SPI_BC));
@@ -503,6 +502,7 @@ static const u32 sun4i_spi_bits[] = {
 static const struct sun4i_spi_variant sun4i_a10_spi_variant = {
.regs   = sun4i_spi_regs,
.bits   = sun4i_spi_bits,
+   .fifo_depth = 64,
 };
 
 static const struct udevice_id sun4i_spi_ids[] = {
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 4/9] spi: sun4i: Access registers and bits via enum offsets

2019-02-27 Thread Jagan Teki
Allwinner support two different SPI controllers one for A10 and
another for A31 with minimal changes in register offsets and
respective register bits, but the logic for accessing the SPI
master via SPI slave remains nearly similar.

Add enum offsets for register set and register bits, so-that
it can access both classes of SPI controllers.

Assign same control register for global, transfer and fifo control
registers to make the same code compatible with A31 SPI controller.

Signed-off-by: Jagan Teki 
Tested-by: Stefan Mavrodiev  # A20-SOM204
---
 drivers/spi/sun4i_spi.c | 154 +---
 1 file changed, 112 insertions(+), 42 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 0b1663038c..be026e6554 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -83,7 +83,6 @@
 #define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
 
 #define SUN4I_FIFO_STA_REG 0x28
-#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
 #define SUN4I_FIFO_STA_RF_CNT_BITS 0
 #define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
 #define SUN4I_FIFO_STA_TF_CNT_BITS 16
@@ -93,28 +92,56 @@
 #define SUN4I_SPI_DEFAULT_RATE 100
 #define SUN4I_SPI_TIMEOUT_US   100
 
-/* sun4i spi register set */
-struct sun4i_spi_regs {
-   u32 rxdata;
-   u32 txdata;
-   u32 ctl;
-   u32 intctl;
-   u32 st;
-   u32 dmactl;
-   u32 wait;
-   u32 cctl;
-   u32 bc;
-   u32 tc;
-   u32 fifo_sta;
+#define SPI_REG(priv, reg) ((priv)->base_addr + \
+   (priv)->variant->regs[reg])
+#define SPI_BIT(priv, bit) ((priv)->variant->bits[bit])
+#define SPI_CS(priv, cs)   (((cs) << SPI_BIT(priv, 
SPI_TCR_CS_SEL)) & \
+   SPI_BIT(priv, SPI_TCR_CS_MASK))
+
+/* sun spi register set */
+enum sun4i_spi_regs {
+   SPI_GCR,
+   SPI_TCR,
+   SPI_FCR,
+   SPI_FSR,
+   SPI_CCR,
+   SPI_BC,
+   SPI_TC,
+   SPI_BCTL,
+   SPI_TXD,
+   SPI_RXD,
+};
+
+/* sun spi register bits */
+enum sun4i_spi_bits {
+   SPI_GCR_TP,
+   SPI_TCR_CPHA,
+   SPI_TCR_CPOL,
+   SPI_TCR_CS_ACTIVE_LOW,
+   SPI_TCR_CS_SEL,
+   SPI_TCR_CS_MASK,
+   SPI_TCR_XCH,
+   SPI_TCR_CS_MANUAL,
+   SPI_TCR_CS_LEVEL,
+   SPI_FCR_TF_RST,
+   SPI_FCR_RF_RST,
+   SPI_FSR_RF_CNT_MASK,
+};
+
+struct sun4i_spi_variant {
+   const unsigned long *regs;
+   const u32 *bits;
 };
 
 struct sun4i_spi_platdata {
+   struct sun4i_spi_variant *variant;
u32 base_addr;
u32 max_hz;
 };
 
 struct sun4i_spi_priv {
-   struct sun4i_spi_regs *regs;
+   struct sun4i_spi_variant *variant;
+   u32 base_addr;
u32 freq;
u32 mode;
 
@@ -129,7 +156,7 @@ static inline void sun4i_spi_drain_fifo(struct 
sun4i_spi_priv *priv, int len)
u8 byte;
 
while (len--) {
-   byte = readb(>regs->rxdata);
+   byte = readb(SPI_REG(priv, SPI_RXD));
if (priv->rx_buf)
*priv->rx_buf++ = byte;
}
@@ -141,7 +168,7 @@ static inline void sun4i_spi_fill_fifo(struct 
sun4i_spi_priv *priv, int len)
 
while (len--) {
byte = priv->tx_buf ? *priv->tx_buf++ : 0;
-   writeb(byte, >regs->txdata);
+   writeb(byte, SPI_REG(priv, SPI_TXD));
}
 }
 
@@ -150,17 +177,17 @@ static void sun4i_spi_set_cs(struct udevice *bus, u8 cs, 
bool enable)
struct sun4i_spi_priv *priv = dev_get_priv(bus);
u32 reg;
 
-   reg = readl(>regs->ctl);
+   reg = readl(SPI_REG(priv, SPI_TCR));
 
-   reg &= ~SUN4I_CTL_CS_MASK;
-   reg |= SUN4I_CTL_CS(cs);
+   reg &= ~SPI_BIT(priv, SPI_TCR_CS_MASK);
+   reg |= SPI_CS(priv, cs);
 
if (enable)
-   reg &= ~SUN4I_CTL_CS_LEVEL;
+   reg &= ~SPI_BIT(priv, SPI_TCR_CS_LEVEL);
else
-   reg |= SUN4I_CTL_CS_LEVEL;
+   reg |= SPI_BIT(priv, SPI_TCR_CS_LEVEL);
 
-   writel(reg, >regs->ctl);
+   writel(reg, SPI_REG(priv, SPI_TCR));
 }
 
 static int sun4i_spi_parse_pins(struct udevice *dev)
@@ -255,6 +282,7 @@ static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
int node = dev_of_offset(bus);
 
plat->base_addr = devfdt_get_addr(bus);
+   plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
  "spi-max-frequency",
  SUN4I_SPI_DEFAULT_RATE);
@@ -273,7 +301,8 @@ static int sun4i_spi_probe(struct udevice *bus)
sun4i_spi_enable_clock();
sun4i_spi_parse_pins(bus);
 
-   priv->regs = (struct sun4i_spi_regs *)(uintptr_t)plat->base_addr;
+   priv->variant = plat->variant;
+   priv->base_addr = plat->base_addr;
priv->freq = plat->max_hz;
 
return 0;

[U-Boot] [PATCH v3 2/9] clk: sunxi: Implement SPI clocks, resets

2019-02-27 Thread Jagan Teki
- Implement SPI AHB, MOD clocks via ccu_clk_gate for all
  supported Allwinner SoCs
- Implement SPI resets via ccu_reset for all supported
  Allwinner SoCs.

Signed-off-by: Jagan Teki 
Reviewed-by: Andre Przywara 
---
 drivers/clk/sunxi/clk_a10.c  | 10 ++
 drivers/clk/sunxi/clk_a10s.c |  7 +++
 drivers/clk/sunxi/clk_a23.c  |  7 +++
 drivers/clk/sunxi/clk_a31.c  | 13 +
 drivers/clk/sunxi/clk_a64.c  |  7 +++
 drivers/clk/sunxi/clk_a80.c  | 13 +
 drivers/clk/sunxi/clk_a83t.c |  7 +++
 drivers/clk/sunxi/clk_h3.c   |  7 +++
 drivers/clk/sunxi/clk_h6.c   |  9 +
 drivers/clk/sunxi/clk_r40.c  | 13 +
 drivers/clk/sunxi/clk_v3s.c  |  4 
 11 files changed, 97 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index 2aa41efe17..b8b57e2b31 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -22,6 +22,10 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
[CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
+   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
+   [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
+   [CLK_AHB_SPI3]  = GATE(0x060, BIT(23)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
@@ -32,9 +36,15 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
[CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
 
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
+
[CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
[CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
+
+   [CLK_SPI3]  = GATE(0x0d4, BIT(31)),
 };
 
 static struct ccu_reset a10_resets[] = {
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index 87b74e52dc..c6fcede822 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -19,12 +19,19 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
+   [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
[CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
[CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
 
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
+
[CLK_USB_OHCI]  = GATE(0x0cc, BIT(6)),
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 1ef2359286..c16019215e 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -16,6 +16,8 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
[CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
[CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
@@ -26,6 +28,9 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
[CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
 
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
[CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
@@ -41,6 +46,8 @@ static struct ccu_reset a23_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
+   [RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
[RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
[RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 5bd8b7dccc..fa6e3eeef0 

[U-Boot] [PATCH v3 1/9] spi: sun4i: Poll for rxfifo to be filled up

2019-02-27 Thread Jagan Teki
To drain rx fifo the fifo need to poll for how much data has
been filled up in rx fifo.

To achieve this, the current code is using wait_for_bit logic
on control register with exchange burst mode mask, which is not
a proper way of waiting for fifo filled up.

So, add code for polling rxfifo to be filled up using fifo
status register.

Signed-off-by: Jagan Teki 
Reviewed-by: Andre Przywara 
---
 drivers/spi/sun4i_spi.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 38cc743c61..f5f2d5635a 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -31,6 +31,8 @@
 
 #include 
 
+#include 
+
 #define SUN4I_FIFO_DEPTH   64
 
 #define SUN4I_RXDATA_REG   0x00
@@ -46,7 +48,6 @@
 #define SUN4I_CTL_LMTF BIT(6)
 #define SUN4I_CTL_TF_RST   BIT(8)
 #define SUN4I_CTL_RF_RST   BIT(9)
-#define SUN4I_CTL_XCH_MASK 0x0400
 #define SUN4I_CTL_XCH  BIT(10)
 #define SUN4I_CTL_CS_MASK  0x3000
 #define SUN4I_CTL_CS(cs)   (((cs) << 12) & SUN4I_CTL_CS_MASK)
@@ -308,7 +309,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
 
u32 len = bitlen / 8;
-   u32 reg;
+   u32 reg, rx_fifocnt;
u8 nbytes;
int ret;
 
@@ -343,10 +344,12 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
reg = readl(>regs->ctl);
writel(reg | SUN4I_CTL_XCH, >regs->ctl);
 
-   /* Wait transfer to complete */
-   ret = wait_for_bit_le32(>regs->ctl, SUN4I_CTL_XCH_MASK,
-   false, SUN4I_SPI_TIMEOUT_US, false);
-   if (ret) {
+   /* Wait till RX FIFO to be empty */
+   ret = readl_poll_timeout(>regs->fifo_sta, rx_fifocnt,
+(((rx_fifocnt & 
SUN4I_FIFO_STA_RF_CNT_MASK) >>
+SUN4I_FIFO_STA_RF_CNT_BITS) >= nbytes),
+SUN4I_SPI_TIMEOUT_US);
+   if (ret < 0) {
printf("ERROR: sun4i_spi: Timeout transferring data\n");
sun4i_spi_set_cs(bus, slave_plat->cs, false);
return ret;
-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH v3 0/9] spi: Add Allwinner A31 SPI driver

2019-02-27 Thread Jagan Teki
This series add support for Allwinner A31 SPI controller driver.

Fixed and improved conde when compared to previous series[1]

Changes for v3:
- update commit message for "poll rxfifo" patch
- change SPI_CS argument as SPI_CS(priv, cs)
- keep 'unsigned long' for register set, since using u16 encounter 
  type-casting issues with writel and readl calls
- change 'unsigned long' to u32 for register bits
- add detailed commit message for 'spi: sun4i: Add CLK support'
- use has_soft_reset and has_burst_ctl driver variant flags for 
  A31 specific changes
- add allwinner,sun6i-a31-spi compatible support
- add fifo_depth support for A31
- rename sun4i_spi to spi-sunxi.c
- update spi-sunxi.c Kconfig entry
Changes for v2:
- use fifo_sta instead ctl reg in readl_poll
- use ">=" instead of negotiation in readl_poll condition
- use SPI_REG, SPI_BIT, SPI_CS macro for code improvement
- use compatible check for A31 register enablement
- add allwinner,sun6i-a31-spi compatible
- exclude driver enable patches, since it has SPI kconfig dependencies.

[1] https://patchwork.ozlabs.org/cover/1041901/

Jagan Teki (9):
  spi: sun4i: Poll for rxfifo to be filled up
  clk: sunxi: Implement SPI clocks, resets
  spi: sun4i: Simplify reg writes using set/clrbits_le32
  spi: sun4i: Access registers and bits via enum offsets
  spi: sun4i: Support fifo_depth via drvdata
  spi: sun4i: Add CLK support
  spi: sun4: Add A31 spi controller support
  spi: sun4i: Driver cleanup
  spi: Rename sun4i_spi.c into spi-sunxi.c

 drivers/clk/sunxi/clk_a10.c  |  10 +
 drivers/clk/sunxi/clk_a10s.c |   7 +
 drivers/clk/sunxi/clk_a23.c  |   7 +
 drivers/clk/sunxi/clk_a31.c  |  13 +
 drivers/clk/sunxi/clk_a64.c  |   7 +
 drivers/clk/sunxi/clk_a80.c  |  13 +
 drivers/clk/sunxi/clk_a83t.c |   7 +
 drivers/clk/sunxi/clk_h3.c   |   7 +
 drivers/clk/sunxi/clk_h6.c   |   9 +
 drivers/clk/sunxi/clk_r40.c  |  13 +
 drivers/clk/sunxi/clk_v3s.c  |   4 +
 drivers/spi/Kconfig  |  12 +-
 drivers/spi/Makefile |   2 +-
 drivers/spi/{sun4i_spi.c => spi-sunxi.c} | 445 ---
 14 files changed, 416 insertions(+), 140 deletions(-)
 rename drivers/spi/{sun4i_spi.c => spi-sunxi.c} (50%)

-- 
2.18.0.321.gffc6fa0e3

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


[U-Boot] [PATCH 6/7] Convert CONFIG_DEFAULT_SPI_* to Kconfig

2019-02-27 Thread Patrick Delaunay
This converts the following to Kconfig:
   CONFIG_DEFAULT_SPI_BUS
   CONFIG_DEFAULT_SPI_MODE

Signed-off-by: Patrick Delaunay 
---

 cmd/Kconfig  | 12 +++-
 cmd/spi.c|  7 ---
 configs/bg0900_defconfig |  1 +
 configs/ls1012aqds_qspi_defconfig|  3 +++
 configs/ls1012aqds_tfa_SECURE_BOOT_defconfig |  2 ++
 configs/ls1012aqds_tfa_defconfig |  2 ++
 configs/mx28evk_auart_console_defconfig  |  1 +
 configs/mx28evk_defconfig|  1 +
 configs/mx28evk_nand_defconfig   |  1 +
 configs/mx28evk_spi_defconfig|  1 +
 configs/mx31pdk_defconfig|  2 ++
 include/configs/bg0900.h |  7 ---
 include/configs/cl-som-am57x.h   |  1 -
 include/configs/ls1012aqds.h |  2 --
 include/configs/mx28evk.h|  6 --
 include/configs/mx31pdk.h|  3 ---
 scripts/config_whitelist.txt |  2 --
 17 files changed, 25 insertions(+), 29 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3ea42e4..fbc1b6f 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1030,10 +1030,20 @@ config CMD_SF_TEST
  everything is working properly.
 
 config CMD_SPI
-   bool "sspi"
+   bool "sspi - Command to access spi device"
help
  SPI utility command.
 
+config DEFAULT_SPI_BUS
+   int "default spi bus used by sspi command"
+   depends on CMD_SPI
+   default 0
+
+config DEFAULT_SPI_MODE
+   hex "default spi mode used by sspi command (see include/spi.h)"
+   depends on CMD_SPI
+   default 0
+
 config CMD_TSI148
bool "tsi148 - Command to access tsi148 device"
help
diff --git a/cmd/spi.c b/cmd/spi.c
index 9a2edcf..75226fd 100644
--- a/cmd/spi.c
+++ b/cmd/spi.c
@@ -22,13 +22,6 @@
 #   define MAX_SPI_BYTES 32/* Maximum number of bytes we can handle */
 #endif
 
-#ifndef CONFIG_DEFAULT_SPI_BUS
-#   define CONFIG_DEFAULT_SPI_BUS  0
-#endif
-#ifndef CONFIG_DEFAULT_SPI_MODE
-#   define CONFIG_DEFAULT_SPI_MODE SPI_MODE_0
-#endif
-
 /*
  * Values from last command.
  */
diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
index a8b5f86..2c4d3e3 100644
--- a/configs/bg0900_defconfig
+++ b/configs/bg0900_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=2
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
diff --git a/configs/ls1012aqds_qspi_defconfig 
b/configs/ls1012aqds_qspi_defconfig
index 1bf9343..d2c3eea 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -27,7 +27,10 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=1
 CONFIG_CMD_USB=y
+CONFIG_DEFAULT_SPI_BUS=1
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
diff --git a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
index 747fa3d..9a6139e 100644
--- a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
@@ -27,6 +27,8 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=1
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_CACHE=y
diff --git a/configs/ls1012aqds_tfa_defconfig b/configs/ls1012aqds_tfa_defconfig
index a41757d..d18d40a 100644
--- a/configs/ls1012aqds_tfa_defconfig
+++ b/configs/ls1012aqds_tfa_defconfig
@@ -27,6 +27,8 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=1
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_CACHE=y
diff --git a/configs/mx28evk_auart_console_defconfig 
b/configs/mx28evk_auart_console_defconfig
index beb10c4..c54b933 100644
--- a/configs/mx28evk_auart_console_defconfig
+++ b/configs/mx28evk_auart_console_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=2
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index be1feb3..187467d 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=2
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
diff --git a/configs/mx28evk_nand_defconfig b/configs/mx28evk_nand_defconfig
index 61e3586..7d891e7 100644
--- a/configs/mx28evk_nand_defconfig
+++ b/configs/mx28evk_nand_defconfig
@@ -22,6 +22,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
+CONFIG_DEFAULT_SPI_BUS=2
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
diff --git a/configs/mx28evk_spi_defconfig 

[U-Boot] [PATCH 1/7] bcm7445: move some configuration in defconfig file

2019-02-27 Thread Patrick Delaunay
Move some configurations in defconfig file
- CONFIG_DM_SPI (removed by syncing defconfigs )
- CONFIG_CMD_SF
- CONFIG_CMD_SPI
- CONFIG_CMD_SF_TEST

This allow correct dependency handling in Kconfig.

Signed-off-by: Patrick Delaunay 
---

 configs/bcm7445_defconfig | 3 +++
 include/configs/bcm7445.h | 4 
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig
index a09ac5c..97098bf 100644
--- a/configs/bcm7445_defconfig
+++ b/configs/bcm7445_defconfig
@@ -8,6 +8,9 @@ CONFIG_FIT_SIGNATURE=y
 CONFIG_BOOTDELAY=1
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot>"
+CONFIG_CMD_SF=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
 CONFIG_OF_PRIOR_STAGE=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_MMC_SDHCI=y
diff --git a/include/configs/bcm7445.h b/include/configs/bcm7445.h
index 8c675f7..6984edd 100644
--- a/include/configs/bcm7445.h
+++ b/include/configs/bcm7445.h
@@ -34,10 +34,6 @@
 #define CONFIG_ENV_OFFSET  0x1e
 #define CONFIG_ENV_SECT_SIZE   CONFIG_ENV_SIZE
 
-#define CONFIG_DM_SPI  1
 #define CONFIG_SYS_MAX_FLASH_BANKS 1
-#define CONFIG_CMD_SF
-#define CONFIG_CMD_SPI
-#define CONFIG_CMD_SF_TEST
 
 #endif /* __CONFIG_H */
-- 
2.7.4

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


[U-Boot] [PATCH 2/7] controlcenterdc: move some configuration in defconfig file

2019-02-27 Thread Patrick Delaunay
Move some configurations in defconfig file
- CONFIG_CMD_I2C
- CONFIG_CMD_SPI

This allow correct dependency handling in Kconfig.

Signed-off-by: Patrick Delaunay 
---

 configs/controlcenterdc_defconfig | 2 ++
 include/configs/controlcenterdc.h | 6 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/configs/controlcenterdc_defconfig 
b/configs/controlcenterdc_defconfig
index f22a3ab..b4b5732 100644
--- a/configs/controlcenterdc_defconfig
+++ b/configs/controlcenterdc_defconfig
@@ -26,9 +26,11 @@ CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_GO is not set
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
diff --git a/include/configs/controlcenterdc.h 
b/include/configs/controlcenterdc.h
index 06c93c3..2433815 100644
--- a/include/configs/controlcenterdc.h
+++ b/include/configs/controlcenterdc.h
@@ -25,12 +25,6 @@
 
 #define CONFIG_LOADADDR100
 
-/*
- * Commands configuration
- */
-#define CONFIG_CMD_I2C
-#define CONFIG_CMD_SPI
-
 /* SPI NOR flash default params, used by sf commands */
 #define CONFIG_SF_DEFAULT_BUS  1
 #define CONFIG_SF_DEFAULT_SPEED100
-- 
2.7.4

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


[U-Boot] [PATCH 3/7] exynos: replace CONFIG_ENV_SPI_BASE by CONFIG_SYS_SPI_BASE

2019-02-27 Thread Patrick Delaunay
Replace CONFIG_ENV_SPI_BASE by the better CONFIG_SYS_SPI_BASE
(it is not the location for environment but the location for U-Boot)
and, as it is the only platform with use this define, remove
it from whitelist.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-exynos/spl_boot.c | 2 +-
 include/configs/exynos5-dt-common.h | 2 +-
 scripts/config_whitelist.txt| 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/spl_boot.c b/arch/arm/mach-exynos/spl_boot.c
index b4945bd..103bb38 100644
--- a/arch/arm/mach-exynos/spl_boot.c
+++ b/arch/arm/mach-exynos/spl_boot.c
@@ -107,7 +107,7 @@ static void exynos_spi_copy(unsigned int uboot_size, 
unsigned int uboot_addr)
 {
int upto, todo;
int i, timeout = 100;
-   struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+   struct exynos_spi *regs = (struct exynos_spi *)CONFIG_SYS_SPI_BASE;
 
set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
/* set the spi1 GPIO */
diff --git a/include/configs/exynos5-dt-common.h 
b/include/configs/exynos5-dt-common.h
index 696f009..a87182a 100644
--- a/include/configs/exynos5-dt-common.h
+++ b/include/configs/exynos5-dt-common.h
@@ -17,7 +17,7 @@
 
 #define CONFIG_EXYNOS5_DT
 
-#define CONFIG_ENV_SPI_BASE0x12D3
+#define CONFIG_SYS_SPI_BASE0x12D3
 #define FLASH_SIZE (4 << 20)
 #define CONFIG_ENV_OFFSET  (FLASH_SIZE - CONFIG_ENV_SECT_SIZE)
 #define CONFIG_SPI_BOOTING
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 2b35725..3e01f84 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -498,7 +498,6 @@ CONFIG_ENV_SETTINGS_V1
 CONFIG_ENV_SETTINGS_V2
 CONFIG_ENV_SIZE_FLEX
 CONFIG_ENV_SIZE_REDUND
-CONFIG_ENV_SPI_BASE
 CONFIG_ENV_SPI_BUS
 CONFIG_ENV_SPI_CS
 CONFIG_ENV_SPI_MAX_HZ
-- 
2.7.4

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


[U-Boot] [PATCH 4/7] tqma6s_wru4_mmc: manage board_spi_cs_gpio correctly

2019-02-27 Thread Patrick Delaunay
Define the function board_spi_cs_gpio only when needed,
only called in drivers/spi/mxc_spi.c.
That avoid compilation issue for tqma6s_wru4_mmc_defconfig
when CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS are not
defined (CMD_SF not defined) after migration in KConfig.

Signed-off-by: Patrick Delaunay 
---

 board/tqc/tqma6/tqma6.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index 816672e..372a17c 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -155,11 +155,13 @@ __weak void tqma6_iomuxc_spi(void)
 ARRAY_SIZE(tqma6_ecspi1_pads));
 }
 
+#if defined(CONFIG_SF_DEFAULT_BUS) && defined(CONFIG_SF_DEFAULT_CS)
 int board_spi_cs_gpio(unsigned bus, unsigned cs)
 {
return ((bus == CONFIG_SF_DEFAULT_BUS) &&
(cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1;
 }
+#endif
 
 static struct i2c_pads_info tqma6_i2c3_pads = {
/* I2C3: on board LM75, M24C64,  */
-- 
2.7.4

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


Re: [U-Boot] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

2019-02-27 Thread Adam Ford
On Wed, Feb 27, 2019 at 5:32 AM Leigh Brown  wrote:
>
> Hello,
>
> Vagrant Cascadian asked for people to test the version of u-boot
> packaged
> for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
> working correctly.  I raised a bug for Debian[1] but I have also tested
> with the mainline version of u-boot and found the same issues.
>
> The first issue is that the following commit caused u-boot to no longer
> be able to access usb storage on the Dreamplug:
>
> commit 93b283d49f933f95f3a6f40762936f454ac655a8
> Author: Adam Ford 
> Date:   Thu Aug 16 13:23:11 2018 -0500
>

Sorry about that.

>  ARM: CPU: arm926ejs: Consolidate cache routines to common file
>
>  Four different boards had different options for enabling cache
>  that were virtually all the same.  This consolidates these
>  common functions into arch/arm/cpu/arm926ejs/cache.c
>
>  This also has the positive side-effect of enabling cache on
>  the Davinci (da850) boards.
>
>  Signed-off-by: Adam Ford 
>  [trini: Add mach-at91 to the list of consolidations]
>  Signed-off-by: Tom Rini 
>
> I don't have much knowledge of ARM caching, but the following patch
> makes
> it work again on my Dreamplug.

I am not that familiar with the ARM caching either, I was just hoping
to enable it on the da850 board and compared the various code chunks
between ARM 926 boards and noticed a common thread.  Tom took it and
added some more.


>
> diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
> index d54de53f31..8a065d73ae 100644
> --- a/arch/arm/mach-kirkwood/cpu.c
> +++ b/arch/arm/mach-kirkwood/cpu.c
> @@ -291,7 +291,6 @@ int arch_misc_init(void)
> temp |= (1 << 22);
> writefr_extra_feature_reg(temp);
>
#ifndef CONFIG_SYS_ICACHE_OFF
> -   icache_enable();
#endif

Instead of commenting out that line, try defining
CONFIG_SYS_ICACHE_OFF in your header like you did for the
CONFIG_SYS_DCACHE_OFF and encapsulate the function call with ifdef's
so any other kirkwood processors can enable/disable it independently.

> /* Change reset vector to address 0x0 */
> temp = get_cr();
> set_cr(temp & ~CR_V);
> diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
> index f4d717213c..6348935c68 100644
> --- a/include/configs/dreamplug.h
> +++ b/include/configs/dreamplug.h
> @@ -79,4 +79,6 @@
>   #define CONFIG_SYS_ATA_IDE0_OFFSETMV_SATA_PORT0_OFFSET
>   #endif /*CONFIG_MVSATA_IDE*/
>
> +#define CONFIG_SYS_DCACHE_OFF
#define CONFIG_SYS_ICACHE_OFF

> +
>   #endif /* _CONFIG_DREAMPLUG_H */
>
> I'd be grateful if someone could take a look.  If you need me to do any
> testing  or provide any more information, please let me know.
>
> I found another issue (documented in the same bug).  I'll send a
> separate
> email about that.
>
> Regards,
>
> Leigh.
>
> --
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

2019-02-27 Thread Leigh Brown

Hello,

Vagrant Cascadian asked for people to test the version of u-boot 
packaged

for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
working correctly.  I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.

The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:

commit 93b283d49f933f95f3a6f40762936f454ac655a8
Author: Adam Ford 
Date:   Thu Aug 16 13:23:11 2018 -0500

ARM: CPU: arm926ejs: Consolidate cache routines to common file

Four different boards had different options for enabling cache
that were virtually all the same.  This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c

This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.

Signed-off-by: Adam Ford 
[trini: Add mach-at91 to the list of consolidations]
Signed-off-by: Tom Rini 

I don't have much knowledge of ARM caching, but the following patch 
makes

it work again on my Dreamplug.

diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index d54de53f31..8a065d73ae 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -291,7 +291,6 @@ int arch_misc_init(void)
temp |= (1 << 22);
writefr_extra_feature_reg(temp);

-   icache_enable();
/* Change reset vector to address 0x0 */
temp = get_cr();
set_cr(temp & ~CR_V);
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index f4d717213c..6348935c68 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -79,4 +79,6 @@
 #define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET
 #endif /*CONFIG_MVSATA_IDE*/

+#define CONFIG_SYS_DCACHE_OFF
+
 #endif /* _CONFIG_DREAMPLUG_H */

I'd be grateful if someone could take a look.  If you need me to do any
testing  or provide any more information, please let me know.

I found another issue (documented in the same bug).  I'll send a 
separate

email about that.

Regards,

Leigh.

--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index d54de53f31..8a065d73ae 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -291,7 +291,6 @@ int arch_misc_init(void)
 	temp |= (1 << 22);
 	writefr_extra_feature_reg(temp);
 
-	icache_enable();
 	/* Change reset vector to address 0x0 */
 	temp = get_cr();
 	set_cr(temp & ~CR_V);
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index f4d717213c..6348935c68 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -79,4 +79,6 @@
 #define CONFIG_SYS_ATA_IDE0_OFFSET	MV_SATA_PORT0_OFFSET
 #endif /*CONFIG_MVSATA_IDE*/
 
+#define CONFIG_SYS_DCACHE_OFF
+
 #endif /* _CONFIG_DREAMPLUG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] fs: fat: fix reading non-cluster-aligned root directory

2019-02-27 Thread Anssi Hannula
A FAT12/FAT16 root directory location is specified by a sector offset and
it might not start at a cluster boundary. It also resides before the
data area (before cluster 2).

However, the current code assumes that the root directory is located at
a beginning of a cluster, causing no files to be found if that is not
the case.

Since the FAT12/FAT16 root directory is located before the data area
and is not aligned to clusters, using unsigned cluster numbers to refer
to the root directory does not work well (the "cluster number" may be
negative, and even allowing it be signed would not make it properly
aligned).

Modify the code to not use the normal cluster numbering when referring to
the root directory of FAT12/FAT16 and instead use a cluster-sized
offsets counted from the root directory start sector.

This is a relatively common case as at least the filesystem formatter on
Win7 seems to create such filesystems by default on 2GB USB sticks when
"FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors,
rootdir starts at half a cluster before cluster 2).

dosfstools mkfs.vfat does not seem to create affected filesystems.

Signed-off-by: Anssi Hannula 
---

v2: Rewrite to avoid negative "cluster numbers".


Hi,

I'm sorry about not responding in a timely manner.

Bernhard Messerklinger wrote:
> clust_size = 2
> rootdir_sect = 113
> dara_begin = 132
> 
> sect_to_clust: 0xfff1 = (0x113 - 132) / 2
> sect_to_clust: 114 = 132 + 0xfff1 * 2
> 
> Now my root_cluster is above the root dir but it should be below it (112).

You are right, root_cluster going negative is not being handled properly.

However, I'd rather avoid that in the first place, as the code generally
assumes that cluster numbers are unsigned - which is the reality as well,
it is just that the FAT12/16 rootdir is located before the clusters.

So here is a different take on the original patch that instead avoids
using the "cluster numbers" to refer to the root directory on FAT12/16
altogether.


 fs/fat/fat.c | 47 ++-
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 6ade4ea54e..c5997c2173 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -602,8 +602,13 @@ static int get_fs_info(fsdata *mydata)
mydata->data_begin = mydata->rootdir_sect +
mydata->rootdir_size -
(mydata->clust_size * 2);
-   mydata->root_cluster =
-   sect_to_clust(mydata, mydata->rootdir_sect);
+
+   /*
+* The root directory is not cluster-aligned and may be on a
+* "negative" cluster, this will be handled specially in
+* next_cluster().
+*/
+   mydata->root_cluster = 0;
}
 
mydata->fatbufnum = -1;
@@ -733,20 +738,38 @@ static void fat_itr_child(fat_itr *itr, fat_itr *parent)
itr->last_cluster = 0;
 }
 
-static void *next_cluster(fat_itr *itr)
+static void *next_cluster(fat_itr *itr, unsigned *nbytes)
 {
fsdata *mydata = itr->fsdata;  /* for silly macros */
int ret;
u32 sect;
+   u32 read_size;
 
/* have we reached the end? */
if (itr->last_cluster)
return NULL;
 
-   sect = clust_to_sect(itr->fsdata, itr->next_clust);
+   if (itr->is_root && itr->fsdata->fatsize != 32) {
+   /*
+* The root directory is located before the data area and
+* cannot be indexed using the regular unsigned cluster
+* numbers (it may start at a "negative" cluster or not at a
+* cluster boundary at all), so consider itr->next_clust to be
+* a offset in cluster-sized units from the start of rootdir.
+*/
+   unsigned sect_offset = itr->next_clust * 
itr->fsdata->clust_size;
+   unsigned remaining_sects = itr->fsdata->rootdir_size - 
sect_offset;
+   sect = itr->fsdata->rootdir_sect + sect_offset;
+   /* do not read past the end of rootdir */
+   read_size = min_t(u32, itr->fsdata->clust_size,
+ remaining_sects);
+   } else {
+   sect = clust_to_sect(itr->fsdata, itr->next_clust);
+   read_size = itr->fsdata->clust_size;
+   }
 
-   debug("FAT read(sect=%d), clust_size=%d, DIRENTSPERBLOCK=%zd\n",
- sect, itr->fsdata->clust_size, DIRENTSPERBLOCK);
+   debug("FAT read(sect=%d), clust_size=%d, read_size=%u, 
DIRENTSPERBLOCK=%zd\n",
+ sect, itr->fsdata->clust_size, read_size, DIRENTSPERBLOCK);
 
/*
 * NOTE: do_fat_read_at() had complicated logic to deal w/
@@ -757,18 +780,17 @@ static void *next_cluster(fat_itr *itr)
 * dent at a time and iteratively constructing the vfat long
 * name.
 */
-   ret = 

[U-Boot] SDCRARD boot on Intel Arria10 SOCDK

2019-02-27 Thread Marcel Gielen [Celestia-STS]

We are trying to setup the Arria10 SOCDK  (DK-SOC-10AS066S-A)  to boot form 
SDCARD in RAW mode.  We are under the impression this
has never been used before.

Kconfig sets SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x200 for ARCH_SOCFPGA, which 
is correct for the Cyclone-V, but not anymore for Arria-10.
The SPL image size handled in the A10 bootROM is increased from 64KiB to 
256KiB, which would result in an offset 0x800.

The boot process, however ends up in an MMC timeout when trying to boot  ( 
v2019.01  ). Didn't peform any further checks yet, but it looks like card is 
not responding
after this  stage.  The board boots with an Intel branched u-boot, we like to 
avoid this branch and stick to mainline.

Default arria10 config:
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices

With CONFIG_MMC_DW enabled:
Trying to boot from MMC1
spl: partition error

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR:
mmc_load_image_raw_sector: mmc block read error

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800:
mmc_load_image_raw_sector: mmc block read error

CONFIG_SD_BOOT:
mmc_load_image_raw_sector: mmc block read error


Any suggestion how to setup RAW mode for A10 ?  (with a C5 we have no issues 
using the same options)
A10 does not requires SPL, but using SPL would allow more options in the u-boot 
image.
What is the preferred bootmode to use for A10 ( No SPL, SPL with RAW mode, SPL 
with u-boot on FAT partition (We prefer to avoid FAT), SPL with u-boot on ext 
partition )


Regards,
   Marcej










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


Re: [U-Boot] [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB

2019-02-27 Thread Simon Goldschmidt
Tom,

On Thu, Feb 14, 2019 at 10:20 AM Simon Goldschmidt
 wrote:
>
> On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt  
> wrote:
> >
> > The SPL image for the Tinker Board has to fit into 32 KiB. This includes
> > up to 2 KiB for the file header.
> >
> > A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is introduced
> > to define the board specific limit.
> >
> > Signed-off-by: Heinrich Schuchardt 
>
> Reviewed-by: Simon Goldschmidt 

Is this planned for v2019.04? I know we're in rc phase, but this patch
adds a new config
option so shouldn't interfere with boards not using it.

Plus if we have this SPL size check in v2019.04, it would probably
enable more board
maintainers testing/fixing the SPL size check after the release.

Regards,
Simon

>
> > ---
> > v3
> > The maximum size should of the image should be 30 KiB. Allowing
> > 2 KiB for the header. This is 30720 and not 32700 bytes.
> > v2
> > Instead of using CONFIG_SPL_MAX_SIZE with an estimate of the FDT
> > size introduce a new test in scripts/Makefile.spl.
> > ---
> >  Kconfig |  8 
> >  configs/tinker-rk3288_defconfig |  1 +
> >  scripts/Makefile.spl| 16 
> >  3 files changed, 25 insertions(+)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 512c7beb89..7cce53da74 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -172,6 +172,14 @@ config TPL_SYS_MALLOC_F_LEN
> >   particular needs this to operate, so that it can allocate the
> >   initial serial device and any others that are needed.
> >
> > +config SPL_WITH_DTB_SIZE_LIMIT
> > +   int "Maximum size of SPL image including device tree"
> > +   depends on SPL
> > +   default 0
> > +   help
> > + Specifies the maximum length of the U-Boot SPL image including the
> > + device tree. If this value is zero, it is ignored.
> > +
> >  menuconfig EXPERT
> > bool "Configure standard U-Boot features (expert users)"
> > default y
> > diff --git a/configs/tinker-rk3288_defconfig 
> > b/configs/tinker-rk3288_defconfig
> > index fdcab28185..cc5e59bcf1 100644
> > --- a/configs/tinker-rk3288_defconfig
> > +++ b/configs/tinker-rk3288_defconfig
> > @@ -3,6 +3,7 @@ CONFIG_ARCH_ROCKCHIP=y
> >  CONFIG_SYS_TEXT_BASE=0x
> >  CONFIG_SYS_MALLOC_F_LEN=0x2000
> >  CONFIG_ROCKCHIP_RK3288=y
> > +CONFIG_SPL_WITH_DTB_SIZE_LIMIT=30720
> >  CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
> >  CONFIG_TARGET_TINKER_RK3288=y
> >  CONFIG_DEBUG_UART_BASE=0xff69
> > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> > index 9d5921606e..afc329a410 100644
> > --- a/scripts/Makefile.spl
> > +++ b/scripts/Makefile.spl
> > @@ -254,11 +254,27 @@ FINAL_DTB_CONTAINER = $(obj)/$(SPL_BIN).multidtb.fit
> >  endif
> >
> >
> > +ifneq ($(CONFIG_SPL_WITH_DTB_SIZE_LIMIT),0)
> > +SPL_WITH_DTB_SIZE_CHECK = \
> > +   @actual=`wc -c $@ | awk '{print $$1}'`; \
> > +   limit=`printf "%d" $(CONFIG_SPL_WITH_DTB_SIZE_LIMIT)`; \
> > +   if test $$actual -gt $$limit; then \
> > +   echo "$@ exceeds file size limit:" >&2 ; \
> > +   echo "  limit:  $$limit bytes" >&2 ; \
> > +   echo "  actual: $$actual bytes" >&2 ; \
> > +   echo "  excess: $$((actual - limit)) bytes" >&2; \
> > +   exit 1; \
> > +   fi
> > +else
> > +SPL_WITH_DTB_SIZE_CHECK =
> > +endif
> > +
> >  ifeq 
> > ($(CONFIG_$(SPL_TPL_)OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
> >  $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
> > $(if $(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) 
> > \
> > $(FINAL_DTB_CONTAINER)  FORCE
> > $(call if_changed,cat)
> > +   $(SPL_WITH_DTB_SIZE_CHECK)
> >
> >  $(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-dtb.bin FORCE
> > $(call if_changed,copy)
> > --
> > 2.20.1
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] efi_loader: Fix serial console size detection

2019-02-27 Thread Matthias Brugger


On 26/02/2019 17:58, Heinrich Schuchardt wrote:
> On 2/26/19 12:46 PM, matthias@kernel.org wrote:
>> From: Matthias Brugger 
>>
>> Function term_read_reply tries to read from the serial console until
>> the end_char was read. This can hang forever if we are, for some reason,
>> not be able to read the full response (e.g. serial buffer too small,
>> frame error). This patch moves the timeout detection into
>> term_read_reply to assure we will make progress.
>>
>> Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
>> Signed-off-by: Matthias Brugger 
> 
> Thanks Matthias for the patch.
> 
> The general direction is right. Yet I would prefer if you could move the
> waiting loop as described below.
> 
>> ---
>>  lib/efi_loader/efi_console.c | 63 +---
>>  1 file changed, 37 insertions(+), 26 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 66c33a551d..817220455f 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode = {
>>  .cursor_visible = 1,
>>  };
>>  
>> +static int term_get_char(char *c)
>> +{
>> +if (tstc()) {
>> +*c = getc();
>> +return 0;
>> +}
>> +
>> +return 1;
> 
> The function signals an error if the character to read is not yet in the
> UART buffer. I think it would be preferable to put the waiting time (100
> ms is sufficient at 110 baud and above) into this function instead. This
> has the following advantages:
> 
> - We would need only one waiting loop.
> - We could reuse the function in function efi_cin_read_key() where we
>   have another chance to hang waiting for a character.
> 

Ok, I'll do that in v2.

>> +}
>> +
>>  /*
>>   * Receive and parse a reply from the terminal.
>>   *
>> @@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char 
>> end_char)
>>  {
>>  char c;
>>  int i = 0;
>> +u64 timeout;
>>  
>> -c = getc();
>> -if (c != cESC)
>> +/* Allow up to one second for the response */
>> +timeout = timer_get_us() + 100;
> 
> Even at 110 baud a waiting time of 100 ms is sufficient.
> 

So we don't have to wait up to one second for the first character to arrive as
we did in query_console_serial() before this patch?

>> +while (!tstc())
>> +if (timer_get_us() > timeout)
>> +return -1;
> 
> This loop could be moved to term_get_char().
> 
>> +
>> +if (term_get_char() || c != cESC)
>>  return -1;
>> -c = getc();
>> -if (c != '[')
>> +
>> +if (term_get_char() || c != '[')
> 
> We should allow time for this character to arrive.
> 
>>  return -1;
>>  
>>  n[0] = 0;
>>  while (1) {
>> -c = getc();
>> -if (c == ';') {
>> -i++;
>> -if (i >= num)> +if (!term_get_char()) 
>> {
> 
> On loop entry there is no wait before this term_get_char().

I don't understand, if the character is not yet present, we will loop in the
while until it arrives or we hit the timeout.

Regards,
Matthias

> 
> Best regards
> 
> Heinrich
> 
>> +if (c == ';') {
>> +i++;
>> +if (i >= num)
>> +return -1;
>> +n[i] = 0;
>> +continue;
>> +} else if (c == end_char) {
>> +break;
>> +} else if (c > '9' || c < '0') {
>>  return -1;
>> -n[i] = 0;
>> -continue;
>> -} else if (c == end_char) {
>> -break;
>> -} else if (c > '9' || c < '0') {
>> -return -1;
>> +}
>> +
>> +/* Read one more decimal position */
>> +n[i] *= 10;
>> +n[i] += c - '0';
>>  }
>>  
>> -/* Read one more decimal position */
>> -n[i] *= 10;
>> -n[i] += c - '0';
>> +if (timer_get_us() > timeout)
>> +return -1;
>>  }
>>  if (i != num - 1)
>>  return -1;
>> @@ -196,7 +216,6 @@ static int query_console_serial(int *rows, int *cols)
>>  {
>>  int ret = 0;
>>  int n[2];
>> -u64 timeout;
>>  
>>  /* Empty input buffer */
>>  while (tstc())
>> @@ -216,14 +235,6 @@ static int query_console_serial(int *rows, int *cols)
>> ESC "[999;999H"  /* Move to bottom right corner */
>> ESC "[6n");  /* Query cursor position */
>>  
>> -/* Allow up to one second for a response */
>> -timeout = timer_get_us() + 100;
>> -while (!tstc())
>> -if (timer_get_us() > timeout) {
>> -ret = -1;
>> -goto 

Re: [U-Boot] [PATCH v9 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

2019-02-27 Thread Michal Simek
On 27. 02. 19 7:37, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 07:58 -0800, Dalon L Westergreen wrote:
>> On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
>>>
>>> On 26. 02. 19 15:28, Chee, Tien Fong wrote:

 On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
>
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>
>> From: Tien Fong Chee 
>>
>> This patch adds description on properties about file name
>> used for
>> both
>> peripheral bitstream and core bitstream.
>>
>> Signed-off-by: Tien Fong Chee 
>>
>> ---
>>
>> changes for v8
>> - Removed explanation about support for altr,bitstream-core
>>
>> changes for v7
>> - Provided example of setting FPGA FIT image for both early
>> IO
>> release
>>   and full release FPGA configuration.
>> ---
>>  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
>> +-
>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
>> a10-fpga-
>> mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>> fpga-
>> mgr.txt
>> index 2fd8e7a..da210bf 100644
>> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
>> mgr.txt
>> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
>> mgr.txt
>> @@ -7,8 +7,31 @@ Required properties:
>> - The second index is for writing FPGA
>> configuration data.
>>  - resets : Phandle and reset specifier for the device's
>> reset.
>>  - clocks : Clocks used by the device.
>> +- altr,bitstream : Fit image file name for both FPGA
>> peripheral
>> bitstream,
>> +   FPGA core bitstream and full bitstream.
>>  
> By adding new required property you are automatically saying
> that you
> want to break all current users.
 This is company's product specific property, that's why with
 prefix
 "altr". DT allows that ,right?
>>> no issue with altr prefix. Issue is that you add a required
>>> property and
>>> breaking all current users.
>>> It should be optional.
>> This parameter is only for Arria10, which at this point is not fully
>> supported
>> in mainline uboot.  So this doesnt affect any existing designs, no?
> 
> Yeah, how this breaking all current users? This property in only used
> for the A10 fpga driver with fit implementation.

That you use latest u-boot with previous DT(or our of tree DT which
doesn't have this property).

M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




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


Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

2019-02-27 Thread Michal Simek
On 27. 02. 19 7:10, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 16:43 +0100, Michal Simek wrote:
>> On 26. 02. 19 15:30, Chee, Tien Fong wrote:
>>>
>>> On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:

 On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee 
>
> Add default fitImage file bundling FPGA bitstreams for Arria10.
>
> Signed-off-by: Tien Fong Chee 
>
> ---
>
> changes for v8
> - Reordered the images and fpga configurations.
> - Removed the load property at core image.
>
> changes for v8
> - Changed the FPGA node name to fpga-core and fpga-periph for
> both
> core and
>   periph bitstreams respectively.
> ---
>  board/altera/arria10-socdk/fit_spl_fpga.its | 38
> +
>  1 file changed, 38 insertions(+)
>  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
>
> diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
> b/board/altera/arria10-socdk/fit_spl_fpga.its
> new file mode 100644
> index 000..df84562
> --- /dev/null
> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> + /*
> + * Copyright (C) 2019 Intel Corporation 
> + *
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + description = "FIT image with FPGA bistream";
> + #address-cells = <1>;
> +
> + images {
> + fpga-periph@1 {
 Still this is DT and using @1 without reg property below is
 wrong.
>>> Sorry, i'm not getting you.
>>> Mind to explain more?
>> it should be just fpga-periph {
>> because you don't have reg properly below.
> So this rule also apply for ITS image node name?

yep.

> How about fpga-periph-1?

Not a problem with it.

M
-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




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