Re: [U-Boot] [PATCH 2/2] tools: moveconfig: process defconfig files in alphabetical order

[Masahiro Yamada]

2016-10-19 4:25 GMT+09:00 Tom Rini :
> On Wed, Oct 19, 2016 at 01:23:24AM +0900, Masahiro Yamada wrote:
>> Hi Tom,
>>
>> 2016-10-17 5:12 GMT+09:00 Tom Rini :
>> > On Mon, Oct 17, 2016 at 02:17:23AM +0900, Masahiro Yamada wrote:
>> >> This will make the log more readable.  The log is not deterministic
>> >> in case of parallel processing, though.
>> >>
>> >> Signed-off-by: Masahiro Yamada 
>> >
>> > I'm honestly ambivalent about this since single threaded is basically
>> > never the case, right?
>>
>>
>> Right.
>> If you want to diff two logs, you need to pass -j1 option.
>>
>> But, my main motivation is not that.
>> You will be able to find the log of boards you are interested in.
>>
>> For example, when some boards are listed in "suspicious results"
>> at the end of conversion, you may want to check the log
>> to see what happened.  If the log is sorted *almost* alphabetically,
>> it will be easier to jump there.
>
> I'm still ambivalent.  I 'less' the log and search doesn't care about
> order.  And I try and fix one broken board at a time since it's often
> the case that N boards will have the same form of thinko.

OK, fine.

Please drop this patch.

I sent v2 only for 1/2.



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

[U-Boot] [PATCH v2] tools: moveconfig: support wildcards in --defconfigs file

[Masahiro Yamada]

Supporting shell-style wildcards for the --defconfigs option will be
useful to run the moveconfig tool against a specific platform.  For
example, "uniphier*" in the file passed by --defconfigs option will
be expanded to defconfig files that start with "uniphier".  This is
easier than listing out all defconfig files you are interested in.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Warn when a pattern does not match any defconfig.
(suggested by Joe)

 tools/moveconfig.py | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 87e2bb2..228d098 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -127,7 +127,8 @@ Available options
standard commit message is used which may need to be edited.
 
  -d, --defconfigs
-  Specify a file containing a list of defconfigs to move
+  Specify a file containing a list of defconfigs to move.  The defconfig
+  files can be given with shell-style wildcards.
 
  -n, --dry-run
Perform a trial run that does not make any changes.  It is useful to
@@ -180,6 +181,7 @@ import copy
 import difflib
 import filecmp
 import fnmatch
+import glob
 import multiprocessing
 import optparse
 import os
@@ -284,6 +286,24 @@ def get_make_cmd():
 sys.exit('GNU Make not found')
 return ret[0].rstrip()
 
+def get_matched_defconfigs(defconfigs_file):
+"""Get all the defconfig files that match the patterns in a file."""
+defconfigs = []
+for i, line in enumerate(open(defconfigs_file)):
+line = line.strip()
+if not line:
+continue # skip blank lines silently
+pattern = os.path.join('configs', line)
+matched = glob.glob(pattern) + glob.glob(pattern + '_defconfig')
+if not matched:
+print >> sys.stderr, "warning: %s:%d: no defconfig matched '%s'" % 
\
+ (defconfigs_file, i + 1, line)
+
+defconfigs += matched
+
+# use set() to drop multiple matching
+return [ defconfig[len('configs') + 1:]  for defconfig in set(defconfigs) ]
+
 def get_all_defconfigs():
 """Get all the defconfig files under the configs/ directory."""
 defconfigs = []
@@ -1204,13 +1224,7 @@ def move_config(configs, options):
 reference_src_dir = None
 
 if options.defconfigs:
-defconfigs = [line.strip() for line in open(options.defconfigs)]
-for i, defconfig in enumerate(defconfigs):
-if not defconfig.endswith('_defconfig'):
-defconfigs[i] = defconfig + '_defconfig'
-if not os.path.exists(os.path.join('configs', defconfigs[i])):
-sys.exit('%s - defconfig does not exist. Stopping.' %
- defconfigs[i])
+defconfigs = get_matched_defconfigs(options.defconfigs)
 else:
 defconfigs = get_all_defconfigs()
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Improve indirect write transaction

[Vignesh R]

Hi,

On Tuesday 18 October 2016 05:15 PM, Marek Vasut wrote:
> On 10/18/2016 10:23 AM, Vignesh R wrote:
>>
>>
>> On Thursday 06 October 2016 04:49 PM, Vignesh R wrote:
>>> If the write transaction size(write_bytes) is not a multiple of word
>>> length, then issue word length writes till the we reach the dangling
>>> bytes. On the final write, issue byte by byte write to complete the
>>> transaction. This marginally improves write throughput when performing
>>> random sized writes to the flash.
>>>
>>> Signed-off-by: Vignesh R 
>>> ---
>>
>> Gentle ping... Any comments?
>>
>>>
>>> Tested on K2G GP EVM.
>>>
>>>  drivers/spi/cadence_qspi_apb.c | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
>>> index e285d3c1e761..4b891f227243 100644
>>> --- a/drivers/spi/cadence_qspi_apb.c
>>> +++ b/drivers/spi/cadence_qspi_apb.c
>>> @@ -752,10 +752,16 @@ int cadence_qspi_apb_indirect_write_execute(struct 
>>> cadence_spi_platdata *plat,
>>> while (remaining > 0) {
>>> write_bytes = remaining > page_size ? page_size : remaining;
>>> /* Handle non-4-byte aligned access to avoid data abort. */
>>> -   if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
>>> +   if ((uintptr_t)txbuf % 4) {
>>> writesb(plat->ahbbase, txbuf, write_bytes);
>>> -   else
>>> +   } else {
>>> writesl(plat->ahbbase, txbuf, write_bytes >> 2);
>>> +   if (write_bytes % 4) {
>>> +   writesb(plat->ahbbase,
>>> +   txbuf + rounddown(write_bytes, 4),
>>> +   write_bytes % 4);
>>> +   }
> 
> You can probably pull this block from the else branch.

Yeah, I guess writesb() can handle zero byte write request I believe.

With above change, can I have your Acked-by/Reviewed-by?


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

Re: [U-Boot] qemu-x86 issues

[Bin Meng]

Hi Tom,

On Tue, Oct 18, 2016 at 9:35 PM, Tom Rini  wrote:
> On Tue, Oct 18, 2016 at 09:19:59AM -0400, Tom Rini wrote:
>> On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
>> > Hi Tom,
>> >
>> > On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini  wrote:
>> > > Hey guys,
>> > >
>> > > After making Stephen's scripts work with qemu today, I've started
>> > > testing out what platforms I can test out via qemu.  I've found two
>> > > problems with qemu-x86.  First, there's a real problem with the network.
>> > > I run qemu with "-nographic -cpu qemu32 -netdev
>> > > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
>> > > tftpboot things in and I'm getting crc32 mismatches.
>> > >
>> >
>> > I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
>> > but did not see such issue.
>>
>> Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
>> and the tests default to 0x0 if you don't provide an address rather than
>> $loadaddr.  I'll see about changing the tests.
>>
>> > > Second, the sleep command is not at all accurate.  It's returning the 3
>> > > second test in less than 1 second.
>> >
>> > Typical emulation target issue :) Did you see similar issue on other
>> > QEMU platform with U-Boot?
>>
>> So this one is interesting.  I see the same failure for MIPS/PPC for the
>> qemu targets we have as well.  I don't see this under QEMU for the ARM
>> targets that I'm emulating.  I suspect there's some common problem on
>> the U-Boot side as also don't see this on the VMs I have running under
>> qemu nor when I boot the kernelci rootfs from U-Boot.
>
> Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
> slightly too long.  x86 is the only one where it's just way too fast.
> But this is not true once Linux itself is up.
>

U-Boot uses x86 TSC timer as the delay timer. Right now the timer
frequency is hard-coded in device tree. Auto-calibration does not work
on QEMU. I need have another check to see if we can do
auto-calibration.

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

Re: [U-Boot] Booting a proprietary OS

[Simon Glass]

Hi,

On 18 October 2016 at 05:47, dlbp90  wrote:
> Hello everybody!!!
> I need to port an operating system from x86 architecture to ARM
> architecture.
> In particular i'm using a Cubietruck board board with Cortex A-7 CPU.
>
> Initially i would use U-boot as bootloader for my operating system: so i
> concentrate on kernel porting!
>
> If i use mkimage command to create the image uncompressed of my operating
> system should i project some decompressing operation for the kernel or not?
> I explain batter: after loading from SD-card the kernel image and executing
> bootm command to start the kernel. at the entry point of the kernel what
> operation should i do and implement??
>
> It's very important
>
> Thanks in advance


Do you have a U-Boot question? It is not clear from your email.

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Simon Glass]

Hi Stephen,

On 18 October 2016 at 17:33, Stephen Warren  wrote:
> On 10/18/2016 05:08 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 18 October 2016 at 16:54, Stephen Warren  wrote:
>>>
>>> On 10/18/2016 01:56 PM, Simon Glass wrote:


 Hi Stephen,

 On 18 October 2016 at 13:10, Stephen Warren 
 wrote:
>
>
> On 10/18/2016 01:03 PM, Simon Glass wrote:
>>
>>
>>
>> Hi Stephen,
>>
>> On 18 October 2016 at 12:58, Stephen Warren 
>> wrote:
>>>
>>>
>>>
>>> On 10/18/2016 10:23 AM, Simon Glass wrote:




 Hi Stephen,

 On 17 October 2016 at 15:35, Stephen Warren 
 wrote:
>
>
>
>
> From: Stephen Warren 
>
> SoC-specific logic may be required for all forms of cache-wide
> operations; invalidate and flush of both dcache and icache (note
> that
> only 3 of the 4 possible combinations make sense, since the icache
> never
> contains dirty lines). This patch adds an optional hook for all
> implemented cache-wide operations, and renames the one existing
> hook
> to
> better represent exactly which operation it is implementing. A
> dummy
> no-op implementation of each hook is provided. These dummy
> implementations are moved into C code, since there's no need to
> implement them in assembly.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/cpu/armv8/cache.S   |  6 --
>  arch/arm/cpu/armv8/cache_v8.c| 23
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
>  arch/arm/include/asm/system.h|  5 -
>  arch/arm/mach-tegra/tegra186/cache.c |  2 +-
>  5 files changed, 27 insertions(+), 13 deletions(-)
>

 I think we should have a proper interface for this stuff rather than
 weak functions. Maybe we need a linker-list approach, or a cache
 uclass?
>>>
>>>
>>>
>>>
>>>
>>> What's improper about this interface? Presumably we could argue that
>>> no
>>> function in the entire of U-Boot be called by symbol name, which
>>> doesn't
>>> seem useful.
>>>
>>> I'm not sure exactly what you envisage by a linker-list approach. Can
>>> you
>>> provide some background? I understand how the linker can construct
>>> list
>>> of
>>> objects/implementations/..., but that doesn't seem useful here since
>>> there's
>>> a known-ahead-of-time single implementation of these functions in a
>>> single
>>> build of U-Boot.
>>
>>
>>
>>
>> Your own commit messages says that this is SoC-specific. I'm
>> suggesting that we define an interface (which I think you have already
>> done with your header file additions), and allow SoCs to implement it
>> via a linker list.
>>
>> IMO the cache code in U-Boot is starting to get a bit creaky.
>>
>>> A cache uclass seems like /massive/ overkill, especially since I'd
>>> expect
>>> these very low-level functions to be required well before any higher
>>> level
>>> code like DM/classes/... to be available.
>>
>>
>>
>>
>> DM is available very early. But it's not clear from your patch when
>> this code is actually called.
>
>
>
>
> I believe that weak functions are a perfectly acceptable approach here.
>
> Yes, the implementation of these functions is SoC-specific. The
> Makefiles
> will pull in the appropriate implementation for that SoC whenever
> U-Boot
> is
> built, just like every other board- or SoC-specific function in the
> entire
> of U-Boot.
>
> There's no need for linker lists since there is only ever one
> implementation.



 If there is only ever one implementation, why do you need weak
 functions?
>>>
>>>
>>>
>>> As I explicitly stated above, each SoC can have a different
>>> implementation,
>>> yet only a single implementation is ever needed for a particular U-Boot
>>> build.
>>>
 Just call them directly.
>>>
>>>
>>>
>>> The code is doing that, both before and after my patch.
>>
>>
>> I mean call them without needing weak functions.
>>
>>>
 I think in fact you mean that
 there can be no implementation (but perhaps an empty one), or one
 implementation. You are effectively using multiple weak functions to
 provide default code. I think it would be better if this were
 explicit.

 I still think that the cache functions could do with a rethink.
>>>
>>>
>>>
>>> 

Re: [U-Boot] pull request: u-boot-uniphier/master

[Tom Rini]

On Wed, Oct 19, 2016 at 01:00:52AM +0900, Masahiro Yamada wrote:

> Hi Tom.
> 
> I was a bit late for -rc2, but please pull some more for UniPhier SoCs:
> 
>  * rework clk driver to re-use corresponding clk data from Linux
>  * Re-sync DT with Linux
>  * Reset migrate from ad-hoc code to the reset driver
>  * some fixes
> 
> 
> The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> 
>   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to 12a5ce72738a34eaa11b559778039f1051425dbd:
> 
>   ARM: uniphier: update doc/README.uniphier (2016-10-18 14:30:05 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] powerpc/t2080: DDR controller erratum A-009942

[Hamish Martin]

This erratum is already implemented for other ARM based QorIQ
platforms with the Gen4 DDR controller. Port the fix to the Gen3
controller and enable it for T2080 and T2081.

Reviewed-by: Chris Packham 
Signed-off-by: Hamish Martin 
Cc: York Sun 
---
 arch/powerpc/cpu/mpc85xx/cmd_errata.c |  3 +++
 arch/powerpc/include/asm/config_mpc85xx.h |  1 +
 drivers/ddr/fsl/mpc85xx_ddr_gen3.c| 17 +
 3 files changed, 21 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c 
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3b06ae42e4bc..94b6dcca96b6 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -329,6 +329,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009663
puts("Work-around for Erratum A009663 enabled\n");
 #endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   puts("Work-around for Erratum A009942 enabled\n");
+#endif
 
return 0;
 }
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 6d845e859f4a..9e1cd80e16e0 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -910,6 +910,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_ERRATUM_A006593
 #define CONFIG_SYS_FSL_ERRATUM_A007186
 #define CONFIG_SYS_FSL_ERRATUM_A006379
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 
diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c 
b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
index 653b7f0c770c..a4377f80 100644
--- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
+++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
@@ -39,6 +39,10 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
 #ifdef CONFIG_SYS_FSL_ERRATUM_DDR_A003
u32 save1, save2;
 #endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   ulong ddr_freq;
+   u32 tmp;
+#endif
 
switch (ctrl_num) {
case 0:
@@ -183,6 +187,19 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t 
*regs,
out_be32(>debug[21], 0x2400);
 #endif /* CONFIG_SYS_FSL_ERRATUM_DDR_A003474 */
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   ddr_freq = get_ddr_freq(ctrl_num) / 100;
+   tmp = in_be32(>debug[28]);
+   if (ddr_freq <= 1333)
+   out_be32(>debug[28], tmp | 0x0080006a);
+   else if (ddr_freq <= 1600)
+   out_be32(>debug[28], tmp | 0x0070006f);
+   else if (ddr_freq <= 1867)
+   out_be32(>debug[28], tmp | 0x00700076);
+   else if (ddr_freq <= 2133)
+   out_be32(>debug[28], tmp | 0x0060007b);
+#endif
+
/*
 * For RDIMMs, JEDEC spec requires clocks to be stable before reset is
 * deasserted. Clocks start when any chip select is enabled and clock
-- 
2.10.1

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 05:08 PM, Simon Glass wrote:

Hi Stephen,

On 18 October 2016 at 16:54, Stephen Warren  wrote:

On 10/18/2016 01:56 PM, Simon Glass wrote:


Hi Stephen,

On 18 October 2016 at 13:10, Stephen Warren  wrote:


On 10/18/2016 01:03 PM, Simon Glass wrote:



Hi Stephen,

On 18 October 2016 at 12:58, Stephen Warren 
wrote:



On 10/18/2016 10:23 AM, Simon Glass wrote:




Hi Stephen,

On 17 October 2016 at 15:35, Stephen Warren 
wrote:




From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache
never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook
to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.

Signed-off-by: Stephen Warren 
---
 arch/arm/cpu/armv8/cache.S   |  6 --
 arch/arm/cpu/armv8/cache_v8.c| 23
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
 arch/arm/include/asm/system.h|  5 -
 arch/arm/mach-tegra/tegra186/cache.c |  2 +-
 5 files changed, 27 insertions(+), 13 deletions(-)



I think we should have a proper interface for this stuff rather than
weak functions. Maybe we need a linker-list approach, or a cache
uclass?





What's improper about this interface? Presumably we could argue that no
function in the entire of U-Boot be called by symbol name, which
doesn't
seem useful.

I'm not sure exactly what you envisage by a linker-list approach. Can
you
provide some background? I understand how the linker can construct list
of
objects/implementations/..., but that doesn't seem useful here since
there's
a known-ahead-of-time single implementation of these functions in a
single
build of U-Boot.




Your own commit messages says that this is SoC-specific. I'm
suggesting that we define an interface (which I think you have already
done with your header file additions), and allow SoCs to implement it
via a linker list.

IMO the cache code in U-Boot is starting to get a bit creaky.


A cache uclass seems like /massive/ overkill, especially since I'd
expect
these very low-level functions to be required well before any higher
level
code like DM/classes/... to be available.




DM is available very early. But it's not clear from your patch when
this code is actually called.




I believe that weak functions are a perfectly acceptable approach here.

Yes, the implementation of these functions is SoC-specific. The Makefiles
will pull in the appropriate implementation for that SoC whenever U-Boot
is
built, just like every other board- or SoC-specific function in the
entire
of U-Boot.

There's no need for linker lists since there is only ever one
implementation.



If there is only ever one implementation, why do you need weak
functions?



As I explicitly stated above, each SoC can have a different implementation,
yet only a single implementation is ever needed for a particular U-Boot
build.


Just call them directly.



The code is doing that, both before and after my patch.


I mean call them without needing weak functions.




I think in fact you mean that
there can be no implementation (but perhaps an empty one), or one
implementation. You are effectively using multiple weak functions to
provide default code. I think it would be better if this were
explicit.

I still think that the cache functions could do with a rethink.



In my opinion, this patch doesn't change the code structure at all. There is
already an interface between the core (L1/L2) cache management code and the
SoC-specific cache management code. That interface already uses a weak
function to provide the default no-op implementation. This patch doesn't
change any of that. All this patch does is fix that existing interface to
cover all 3 combinations of dcache_flush, dcache_invalidate, and
icache_invalidate, rather than just one of those combinations. It's more of
a bug-fix than anything else.


Yes I see that.



If you want to rework this interface sometime, be my guest. However, I don't
think it's fair to require that someone who simply wants to fix the existing
code (in a way that is orthogonal to your desired interface refactoring) do
that refactoring first, rather than doing it yourself.


I understand what you are saying, but isn't that how open source
software works? Believe me, I have done my fair share of refactoring
:-)

At least can you look at not making it any harder to fix up later? The
more we pile onto this interface, the harder it will be later. We
should aim to make ARMv8 really 

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Simon Glass]

Hi Stephen,

On 18 October 2016 at 16:54, Stephen Warren  wrote:
> On 10/18/2016 01:56 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 18 October 2016 at 13:10, Stephen Warren  wrote:
>>>
>>> On 10/18/2016 01:03 PM, Simon Glass wrote:


 Hi Stephen,

 On 18 October 2016 at 12:58, Stephen Warren 
 wrote:
>
>
> On 10/18/2016 10:23 AM, Simon Glass wrote:
>>
>>
>>
>> Hi Stephen,
>>
>> On 17 October 2016 at 15:35, Stephen Warren 
>> wrote:
>>>
>>>
>>>
>>> From: Stephen Warren 
>>>
>>> SoC-specific logic may be required for all forms of cache-wide
>>> operations; invalidate and flush of both dcache and icache (note that
>>> only 3 of the 4 possible combinations make sense, since the icache
>>> never
>>> contains dirty lines). This patch adds an optional hook for all
>>> implemented cache-wide operations, and renames the one existing hook
>>> to
>>> better represent exactly which operation it is implementing. A dummy
>>> no-op implementation of each hook is provided. These dummy
>>> implementations are moved into C code, since there's no need to
>>> implement them in assembly.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>>  arch/arm/cpu/armv8/cache.S   |  6 --
>>>  arch/arm/cpu/armv8/cache_v8.c| 23
>>> ---
>>>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
>>>  arch/arm/include/asm/system.h|  5 -
>>>  arch/arm/mach-tegra/tegra186/cache.c |  2 +-
>>>  5 files changed, 27 insertions(+), 13 deletions(-)
>>>
>>
>> I think we should have a proper interface for this stuff rather than
>> weak functions. Maybe we need a linker-list approach, or a cache
>> uclass?
>
>
>
>
> What's improper about this interface? Presumably we could argue that no
> function in the entire of U-Boot be called by symbol name, which
> doesn't
> seem useful.
>
> I'm not sure exactly what you envisage by a linker-list approach. Can
> you
> provide some background? I understand how the linker can construct list
> of
> objects/implementations/..., but that doesn't seem useful here since
> there's
> a known-ahead-of-time single implementation of these functions in a
> single
> build of U-Boot.



 Your own commit messages says that this is SoC-specific. I'm
 suggesting that we define an interface (which I think you have already
 done with your header file additions), and allow SoCs to implement it
 via a linker list.

 IMO the cache code in U-Boot is starting to get a bit creaky.

> A cache uclass seems like /massive/ overkill, especially since I'd
> expect
> these very low-level functions to be required well before any higher
> level
> code like DM/classes/... to be available.



 DM is available very early. But it's not clear from your patch when
 this code is actually called.
>>>
>>>
>>>
>>> I believe that weak functions are a perfectly acceptable approach here.
>>>
>>> Yes, the implementation of these functions is SoC-specific. The Makefiles
>>> will pull in the appropriate implementation for that SoC whenever U-Boot
>>> is
>>> built, just like every other board- or SoC-specific function in the
>>> entire
>>> of U-Boot.
>>>
>>> There's no need for linker lists since there is only ever one
>>> implementation.
>>
>>
>> If there is only ever one implementation, why do you need weak
>> functions?
>
>
> As I explicitly stated above, each SoC can have a different implementation,
> yet only a single implementation is ever needed for a particular U-Boot
> build.
>
>> Just call them directly.
>
>
> The code is doing that, both before and after my patch.

I mean call them without needing weak functions.

>
>> I think in fact you mean that
>> there can be no implementation (but perhaps an empty one), or one
>> implementation. You are effectively using multiple weak functions to
>> provide default code. I think it would be better if this were
>> explicit.
>>
>> I still think that the cache functions could do with a rethink.
>
>
> In my opinion, this patch doesn't change the code structure at all. There is
> already an interface between the core (L1/L2) cache management code and the
> SoC-specific cache management code. That interface already uses a weak
> function to provide the default no-op implementation. This patch doesn't
> change any of that. All this patch does is fix that existing interface to
> cover all 3 combinations of dcache_flush, dcache_invalidate, and
> icache_invalidate, rather than just one of those combinations. It's more of
> a bug-fix than anything else.

Yes I see that.

>
> 

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[york sun]

On 10/17/2016 04:35 PM, Stephen Warren wrote:
> From: Stephen Warren 
>
> SoC-specific logic may be required for all forms of cache-wide
> operations; invalidate and flush of both dcache and icache (note that
> only 3 of the 4 possible combinations make sense, since the icache never
> contains dirty lines). This patch adds an optional hook for all
> implemented cache-wide operations, and renames the one existing hook to
> better represent exactly which operation it is implementing. A dummy
> no-op implementation of each hook is provided. These dummy
> implementations are moved into C code, since there's no need to
> implement them in assembly.
>
Stephen,

Moving this function to C may pose an issue. I had a debug a couple of 
years ago that calling a C function put the stack into cache after 
flushing L1/L2. That's why I used asm function to flush L3.

York

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 01:56 PM, Simon Glass wrote:

Hi Stephen,

On 18 October 2016 at 13:10, Stephen Warren  wrote:

On 10/18/2016 01:03 PM, Simon Glass wrote:


Hi Stephen,

On 18 October 2016 at 12:58, Stephen Warren  wrote:


On 10/18/2016 10:23 AM, Simon Glass wrote:



Hi Stephen,

On 17 October 2016 at 15:35, Stephen Warren 
wrote:



From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache
never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.

Signed-off-by: Stephen Warren 
---
 arch/arm/cpu/armv8/cache.S   |  6 --
 arch/arm/cpu/armv8/cache_v8.c| 23
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
 arch/arm/include/asm/system.h|  5 -
 arch/arm/mach-tegra/tegra186/cache.c |  2 +-
 5 files changed, 27 insertions(+), 13 deletions(-)



I think we should have a proper interface for this stuff rather than
weak functions. Maybe we need a linker-list approach, or a cache
uclass?




What's improper about this interface? Presumably we could argue that no
function in the entire of U-Boot be called by symbol name, which doesn't
seem useful.

I'm not sure exactly what you envisage by a linker-list approach. Can you
provide some background? I understand how the linker can construct list
of
objects/implementations/..., but that doesn't seem useful here since
there's
a known-ahead-of-time single implementation of these functions in a
single
build of U-Boot.



Your own commit messages says that this is SoC-specific. I'm
suggesting that we define an interface (which I think you have already
done with your header file additions), and allow SoCs to implement it
via a linker list.

IMO the cache code in U-Boot is starting to get a bit creaky.


A cache uclass seems like /massive/ overkill, especially since I'd expect
these very low-level functions to be required well before any higher
level
code like DM/classes/... to be available.



DM is available very early. But it's not clear from your patch when
this code is actually called.



I believe that weak functions are a perfectly acceptable approach here.

Yes, the implementation of these functions is SoC-specific. The Makefiles
will pull in the appropriate implementation for that SoC whenever U-Boot is
built, just like every other board- or SoC-specific function in the entire
of U-Boot.

There's no need for linker lists since there is only ever one
implementation.


If there is only ever one implementation, why do you need weak
functions?


As I explicitly stated above, each SoC can have a different 
implementation, yet only a single implementation is ever needed for a 
particular U-Boot build.



Just call them directly.


The code is doing that, both before and after my patch.


I think in fact you mean that
there can be no implementation (but perhaps an empty one), or one
implementation. You are effectively using multiple weak functions to
provide default code. I think it would be better if this were
explicit.

I still think that the cache functions could do with a rethink.


In my opinion, this patch doesn't change the code structure at all. 
There is already an interface between the core (L1/L2) cache management 
code and the SoC-specific cache management code. That interface already 
uses a weak function to provide the default no-op implementation. This 
patch doesn't change any of that. All this patch does is fix that 
existing interface to cover all 3 combinations of dcache_flush, 
dcache_invalidate, and icache_invalidate, rather than just one of those 
combinations. It's more of a bug-fix than anything else.


If you want to rework this interface sometime, be my guest. However, I 
don't think it's fair to require that someone who simply wants to fix 
the existing code (in a way that is orthogonal to your desired interface 
refactoring) do that refactoring first, rather than doing it yourself.

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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Tue, Oct 18, 2016 at 04:03:08PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> 
>   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to f822403f0164be74a5161b65698d0f01f4556234:
> 
>   x86: Add implementations of setjmp() and longjmp() (2016-10-18 15:58:50 
> +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 03:28 PM, york sun wrote:

On 10/18/2016 02:01 PM, Stephen Warren wrote:

On 10/18/2016 12:40 PM, york sun wrote:

On 10/18/2016 11:14 AM, Stephen Warren wrote:

On 10/18/2016 09:28 AM, york sun wrote:

On 10/17/2016 04:35 PM, Stephen Warren wrote:

From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.


Stephen,

Moving this function to C may pose an issue. I had a debug a couple of
years ago that calling a C function put the stack into cache after
flushing L1/L2. That's why I used asm function to flush L3.


Assuming the stack is located in cachable memory, the CPU is free (per
the definition of the ARM architecture) to pull it into the cache at any
time the cache is enabled (and perhaps even when it isn't enabled, at
the very least for the icache on ARMv8 if not other cases too).
Implementation in C vs. assembly has absolutely no effect here. I guess
your statement assumes that C functions will write data to the stack and
assembly functions never will. There's no strict 1:1 correlation between
those two things; assembly code can touch the stack just like C code. If
there's an assumption it won't, it needs to be documented in the header
defining these hook functions.

I assume you're specifically talking about dirtying the dcache between
the point when dcache flushing starts and the point when the dcache is
disabled? If so, flush_dcache_all() itself would have to be manually
coded in assembly to avoid using the stack, as would dcache_disable()
and set_sctlr(). I think this is why dcache_disable() currently disables
the dcache first (thus preventing it acquiring new dirty data) and then
flushes the dcache afterwards (thus guaranteeing that all dirty data is
flushed with no race condition). This implies that your change to swap
the order of those two functions isn't correct. I'm pretty sure I'm


I wonder if David can shed some light on the original order of calls to
disable dcache.


correct in saying that the dcache can hit even if it's disabled, hence
disabling the dcache while it contains dirty data won't lead to issues?



My earlier debug was based on the original order of calls. I found I had
to avoid using the stack before flushing L3. Now with the changed order,
I haven't tested. But I can image the stack will be dirty and flushing
L3 may or may not push the data into main memory (depending on the L3
implementation whether inclusive or not).

You said you are sure dcache can hit even if it is disabled. Can you
explain more? My test shows as soon as the d-cache is disabled, the core
cannot get the data in dirty cache.


By "hit" here, I mean that even with the dcache disabled, when the CPU
performs a read access, if the dcache contains a copy of that data, it
can return it rather than requiring it to be fetched from DRAM.

Yes, with the dcache disabled, I would not expect any writes to allocate
new lines in the cache (although presumably writes would update any
lines already there, in a write-though sense).

At least, I'm pretty sure this is all true. It seems the only way to
allow switching from cache-on to cache-off state without losing dirty data.


I believe my test showed otherwise. As soon as the dcache is disabled,
the core cannot get the dirty cached data if the dcache was flushed by
way/set for L1 and L2 (L3 wasn't flushed). That's why I proposed to
change the order to flush first.


It looks like what I was saying is true for ARMv7 but not for ARMv8 (or 
perhaps it's not architectural but implementation-defined). For example, 
the Cortex A15 TRM says:



http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438i/BABHEJFF.html


When you disable the cache, all Write-Back Cacheable requests still look 
up the L1 cache. If there is a cache hit, the cache is read or updated 
in the same way as if the cache is enabled. This enables Cacheable 
memory to remain fully coherent while the cache is disabled.


However, the Cortex A72 TRM says:


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0488h/way1382448697827.html


When you disable the cache, all Write-Back Cacheable requests do not 
look up the L1 data cache. L1 cache still services the snoops from the 
L2 cache.


So yes, we should flush the entire cache first, then disable it.

This does indeed imply that we shouldn't write data between starting to 
flush the dcache and disabling the cache. However, that seems too 
restrictive, especially in the face of 

Re: [U-Boot] [U-Boot, v1] watchdog: Fix Watchdog Reset while in U-Boot Prompt

[Tom Rini]

On Wed, Jul 13, 2016 at 12:56:51PM +0200, Andreas J. Reichel wrote:

> Hardware: CM-FX6 Module from Compulab
> 
> This patch fixes unwanted watchdog resets while the user enters
> a command at the U-Boot prompt.
> 
> As found on the CM-FX6 board from Compulab, when having enabled the
> watchdog, a missing WATCHDOG_RESET call in common/console.c causes
> this and alike boards to reset when the watchdog's timeout has
> elapsed while waiting at the U-Boot prompt.
> 
> Despite the user could press several keys within the watchdog
> timeout limit, the while loop in cli_readline.c, line 261, does only
> call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st
> loop iteration. This leads to a watchdog timeout no matter if the
> user presses keys or not.
> 
> Although, this affects other boards as well as it touches
> common/console.c, the macro WATCHDOG_RESET expands to {} if watchdog
> support isn't configured. Hence, there's no harm caused and no need to
> surround it by #ifdef in this case.
> 
>  * Symptom:
>U-Boot resets after watchdog times out when in commandline prompt
>and watchdog is enabled.
> 
>  * Reasoning:
>When U-Boot shows the commandline prompt, the following function
>call stack is executed while waiting for a keypress:
> 
>common/main.c:
> main_loop  => common/cli.c: cli_loop() =>
>common/cli_hush.c:
> parse_file_outer   => parse_stream_outer   =>
> parse_stream   => b_getch(i)   =>
> i->get(i)  => file_get =>
> get_user_input => cmdedit_read_input   =>
> uboot_cli_readline =>
>common/cli_readline.c:
> cli_readline   => cli_readline_into_buffer =>
> cread_line => getcmd_getch (== getc)   =>
>common/console.c:
> fgetc  => console_tstc
> 
>common/console.c:
>(with CONFIG_CONSOLE_MUX is set)
> 
>- in console_tstc line 181:
>If dev->tstc(dev) returns 0, the global tstcdev variable doesn't get
>set. This is the case if no character is in the serial buffer.
> 
>- in fgetc(int file), line 297:
>Program flow keeps looping because tstcdev does not get set.
>Therefore WATCHDOG_RESET is not called, as mx_serial_tstc from
>drivers/serial/serial_mxc.c does not call it.
> 
>  * Solution:
>Add WATCHDOG_RESET into the loop of console_tstc.
> 
>Note: Macro expands to {} if not configured, so no #ifdef is needed.
> 
>  * Comment:
> 
> Signed-off-by: Christian Storm 
> Signed-off-by: Jan Kiszka 
> Signed-off-by: Andreas J. Reichel 
> Acked-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL v2] efi patch queue 2016-10-18

[Tom Rini]

On Tue, Oct 18, 2016 at 08:08:48PM +0200, Alexander Graf wrote:
> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> 
>   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-next
> 
> for you to fetch changes up to ef8b6363986e08eef1939e562c37dd142a7529a2:
> 
>   efi_loader: Revert device_handle to disk after net boot (2016-10-18 
> 20:03:41 +0200)
> 
> 
> Patch queue for efi - 2016-10-18
> 
> Highlights this time around:
> 
>   - Add run time service (power control) support for PSCI
>   - Add efi gop pointer exposure
>   - SMBIOS support for EFI (on ARM)
>   - efi pool memory unmap support (needed for 4.8)
>   - initial x86 efi payload support (fixed up in v2)
>   - various bug fixes
> 
> 
> Alexander Graf (19):
>   efi_loader: Allow boards to implement get_time and reset_system
>   arm: Disable HVC PSCI calls by default
>   arm: Add PSCI shutdown function
>   arm: Provide common PSCI based reset handler

This one here breaks odroid-c2.  Please fix and re-submit the PR,
thanks!

-- 
Tom


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

[U-Boot] Some issues with the python tests

[Stefan Bruens]

Hi,

I have started diving into the u-boot python tests. Now I have come accross 
two problems:

1. I would like to access the config, specifically the paths to e.g. 
build_dir, result_dir, ...
2. I would like to run and log system commands

Now while I can do this via the u_boot_console fixture, I would like to issue 
some of my fixture setup on the session/module level. Unfortunately, the 
u_boot_console fixture has "function" scope, and thus my fixtures are limited 
to function scope as well.

Although for the u_boot_console (i.e. the sandbox instance or the SoC 
terminal) function scope is likely correct, the runner/logger and the config 
should be accessible independent of u_boot_console.

Any ideas how to solve this issue?

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[york sun]

On 10/18/2016 02:01 PM, Stephen Warren wrote:
> On 10/18/2016 12:40 PM, york sun wrote:
>> On 10/18/2016 11:14 AM, Stephen Warren wrote:
>>> On 10/18/2016 09:28 AM, york sun wrote:
 On 10/17/2016 04:35 PM, Stephen Warren wrote:
> From: Stephen Warren 
>
> SoC-specific logic may be required for all forms of cache-wide
> operations; invalidate and flush of both dcache and icache (note that
> only 3 of the 4 possible combinations make sense, since the icache never
> contains dirty lines). This patch adds an optional hook for all
> implemented cache-wide operations, and renames the one existing hook to
> better represent exactly which operation it is implementing. A dummy
> no-op implementation of each hook is provided. These dummy
> implementations are moved into C code, since there's no need to
> implement them in assembly.
>
 Stephen,

 Moving this function to C may pose an issue. I had a debug a couple of
 years ago that calling a C function put the stack into cache after
 flushing L1/L2. That's why I used asm function to flush L3.
>>>
>>> Assuming the stack is located in cachable memory, the CPU is free (per
>>> the definition of the ARM architecture) to pull it into the cache at any
>>> time the cache is enabled (and perhaps even when it isn't enabled, at
>>> the very least for the icache on ARMv8 if not other cases too).
>>> Implementation in C vs. assembly has absolutely no effect here. I guess
>>> your statement assumes that C functions will write data to the stack and
>>> assembly functions never will. There's no strict 1:1 correlation between
>>> those two things; assembly code can touch the stack just like C code. If
>>> there's an assumption it won't, it needs to be documented in the header
>>> defining these hook functions.
>>>
>>> I assume you're specifically talking about dirtying the dcache between
>>> the point when dcache flushing starts and the point when the dcache is
>>> disabled? If so, flush_dcache_all() itself would have to be manually
>>> coded in assembly to avoid using the stack, as would dcache_disable()
>>> and set_sctlr(). I think this is why dcache_disable() currently disables
>>> the dcache first (thus preventing it acquiring new dirty data) and then
>>> flushes the dcache afterwards (thus guaranteeing that all dirty data is
>>> flushed with no race condition). This implies that your change to swap
>>> the order of those two functions isn't correct. I'm pretty sure I'm
>>
>> I wonder if David can shed some light on the original order of calls to
>> disable dcache.
>>
>>> correct in saying that the dcache can hit even if it's disabled, hence
>>> disabling the dcache while it contains dirty data won't lead to issues?
>>>
>>
>> My earlier debug was based on the original order of calls. I found I had
>> to avoid using the stack before flushing L3. Now with the changed order,
>> I haven't tested. But I can image the stack will be dirty and flushing
>> L3 may or may not push the data into main memory (depending on the L3
>> implementation whether inclusive or not).
>>
>> You said you are sure dcache can hit even if it is disabled. Can you
>> explain more? My test shows as soon as the d-cache is disabled, the core
>> cannot get the data in dirty cache.
>
> By "hit" here, I mean that even with the dcache disabled, when the CPU
> performs a read access, if the dcache contains a copy of that data, it
> can return it rather than requiring it to be fetched from DRAM.
>
> Yes, with the dcache disabled, I would not expect any writes to allocate
> new lines in the cache (although presumably writes would update any
> lines already there, in a write-though sense).
>
> At least, I'm pretty sure this is all true. It seems the only way to
> allow switching from cache-on to cache-off state without losing dirty data.
>

I believe my test showed otherwise. As soon as the dcache is disabled, 
the core cannot get the dirty cached data if the dcache was flushed by 
way/set for L1 and L2 (L3 wasn't flushed). That's why I proposed to 
change the order to flush first.

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

Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program

[Simon Glass]

Hi Alex,

On 18 October 2016 at 01:14, Alexander Graf  wrote:
> On 10/18/2016 04:29 AM, Simon Glass wrote:
>>
>> It is useful to have a basic sanity check for EFI loader support. Add a
>> 'bootefi hello' command which loads HelloWord.efi and runs it under
>> U-Boot.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3:
>> - Include a link to the program instead of adding it to the tree
>
>
> So, uh, where is the link?

I put it in the README (see the arm patch).

>
> I'm really not convinced this command buys us anything yet. I do agree that
> we want automated testing - but can't we get that using QEMU and a
> downloadable image file that we pass in as disk and have the distro boot do
> its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Here I am just making sure that EFI programs can start, print output
and exit. It is a test that we can easily run without a lot of
overhead, much less than a full distro boot.

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

Re: [U-Boot] [PATCH v2 5/8] arm: efi: Add a hello world test program

[Simon Glass]

Hi Alex,

On 4 October 2016 at 09:50, Alexander Graf  wrote:
>
>
> Am 04.10.2016 um 17:37 schrieb Simon Glass :
>
> Hi Alex,
>
> On 3 October 2016 at 21:15, Alexander Graf  wrote:
>
>
>
> Am 03.10.2016 um 23:50 schrieb Simon Glass :
>
>
> Hi,
>
>
> On 27 September 2016 at 15:28, Tom Rini  wrote:
>
>
> On Mon, Sep 26, 2016 at 09:36:19AM +0200, Alexander Graf wrote:
>
>
>
>
> On 25.09.16 23:27, Simon Glass wrote:
>
>
> It is useful to have a basic sanity check for EFI loader support. Add a
>
>
> 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
>
>
>
> Signed-off-by: Simon Glass 
>
>
> ---
>
>
>
> Changes in v2: None
>
>
>
> arch/arm/lib/HelloWorld32.efi  | Bin 0 -> 11712 bytes
>
>
>
> IIRC U-Boot as a whole is GPL licensed, which means that any binaries
>
>
> shipped inside would also need to be GPL compatibly licensed which again
>
>
> means that the source code (and build instructions?) for this .efi file
>
>
> would need to be part of the tree, no?
>
>
>
> Yeah, I'm not super comfortable with this.
>
>
>
> Do you think we should drop these binary patches? I could always put
>
> the binaries somewhere along with instructions on how to get them.
>
>
>
> I think that's the best option, yes. You can always just add a url to the
>
> readme to point people into the right direction.
>
>
> OK. One problem is that we cannot write a test for it unless we
> actually run an EFI application.
>
>
> Well, you could always provide a binary disk image that you run in qemu as
> test case. That one doesn't have to be gpl compliant thn because it's not
> derived work :).
>
>
>
>
> I do think it is useful to be able to test the platform though.
>
>
>
> I don't disagree, but I would argue that for the average u-boot user it
>
> brings no additional value ;). And people like you who know how to enable a
>
> new architecture probably also know how to get a file into their target's
>
> memory.
>
>
> I wonder if we can build our own hello world application? I think I
> did it once. But there is EFI library code that we would need to bring
> in (perhaps a small amount).
>
>
> We could. The main problem is the PE header.

What is tricky about that?

>
> Maybe we can trick around that with bincopy -O binary though. Hmm :).

Yes I think it is possible, and desirable. But for now I've gone with
using an external patch. I may come back to this another time.

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

Re: [U-Boot] [PATCH v3 2/8] efi: Use asmlinkage for EFIAPI

[Simon Glass]

Hi Alex,

On 18 October 2016 at 01:12, Alexander Graf  wrote:
> On 10/18/2016 04:29 AM, Simon Glass wrote:
>>
>> This is required for x86 and is also correct for ARM (since it is empty).
>>
>> Signed-off-by: Simon Glass 
>> Reviewed-by: Bin Meng 
>
>
> (Replying here in lack for a cover letter)
>
> Could you please rebase your patches on top of
>
>   https://github.com/agraf/u-boot.git efi-next
>
> so that all the patches that I already queued are not repeated in the patch
> set and we don't get any conflicts?

I can do that - but is this targeting -next? I was expecting these
patches to land in master.

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

Re: [U-Boot] [PATCH v5 7/7] efi_loader: Declare secure memory as reserved

[york sun]

On 10/17/2016 02:11 AM, Alexander Graf wrote:
>
>
> On 15.10.16 18:58, york sun wrote:
>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>>> reserve some memory that U-Boot is aware of as secure.
>>>
>>> For those systems, mask out that secure memory in the EFI memory map,
>>> as it's not usable from EL2 or EL1.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v4 -> v5:
>>>
>>>   - Use gd->arch.secure_ram
>>> ---
>>>  lib/efi_loader/efi_memory.c | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>> index 95aa590..4966e48 100644
>>> --- a/lib/efi_loader/efi_memory.c
>>> +++ b/lib/efi_loader/efi_memory.c
>>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>> efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>>  #endif
>>>
>>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>> +   /* Declare secure ram as reserved */
>>> +if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>>> +   uint64_t secure_start = gd->arch.secure_ram;
>>> +   uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>>> +
>>> +   secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>>> +   secure_start &= ~EFI_PAGE_MASK;
>>> +   secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>>> +
>>> +   efi_add_memory_map(secure_start, secure_pages,
>>> +  EFI_RESERVED_MEMORY_TYPE, false);
>>> +}
>>> +#endif
>>> +
>>> return 0;
>>>  }
>>>
>>
>> Alex,
>>
>> Do you see any issue without this patch? The secure memory is not
>> visible to OS. gd->ram_size is reduced to hide the secure memory.
>
> We're building the memory map out of gd->bd->bi_dram rather than
> ram_size, because it's perfectly reasonable for systems to have memory
> holes.
>
> So even if we're adjusting gd->ram_size, the OS will still see secure
> memory. In fact, doesn't bootm do that as well?
>
> arch/arm/lib/bootm-fdt.c:   ret = fdt_fixup_memory_banks(blob,
> start, size, CONFIG_NR_DRAM_BANKS);
>
> On armv7, arch_fixup_fdt() removes the secure memory region from the
> edge of a memory bank. But on armv8 I don't see anything like it?
>

Alex,

For ARMv8, our SoCs have several regions. Depends on the board 
implementation, the memory may end up in different banks. See 
board/freescale/ls2080ardb/ddr.c for example. The secure ram is already 
carved out.

York

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

[U-Boot] Help with spl: zImage support in Falcon mode

[Diego Dorta]

Hi all,

According to commit log: 

commit 431889d6ad9a39846636716478d504aa7ff976fc
Author: Ladislav Michl 
Date:   Tue Jul 12 20:28:14 2016 +0200

spl: zImage support in Falcon mode

Other payload than uImage is currently considered to be raw U-Boot
image. Check also for zImage in Falcon mode.

Signed-off-by: Ladislav Michl 
Reviewed-by: Heiko Schocher 

Already include at U-Boot 2016.09.01.

I was trying to apply Falcon mode on i.MX6 Sabre SD using zImage instead of 
uImage.
After the steps below I got an error trying to "spl export":

# dhcp ${fdt_addr} imx6q-sabresd.dtb

# dhcp ${loadaddr} zImage

# mmc write ${loadaddr} 0x1000 0x4000

# setenv bootargs 'console=ttymxc0,115200 root=/dev/mmcblk1p1 rootfstype=ext4 
rootwait quiet rw'

# spl export fdt ${loadaddr} - ${fdt_addr}

i�{���]߬�o;��]o��k5�ك�2s�C�Ǎ������x���ɾ�6�}��]�0��֮m�\�S���'��;}ۗ�Ԭ2�[��w<��O����7ە}�v�c�-�ϥ9��w`o��ߎ�ݭ�zoERROR:
 can't get kernel image!
   XIP Invalid Image ... OK
ERROR: booting os 'Invalid OS' (0) is not supported
ERROR: booting os 'Invalid OS' (0) is not supported
ERROR: booting os 'Invalid OS' (0) is not supported
ERROR prep subcommand failed!
Subcommand failed

I can't understand this error. Does anybody know how to fix it?

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Simon Glass]

Hi Stephen,

On 18 October 2016 at 13:10, Stephen Warren  wrote:
> On 10/18/2016 01:03 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 18 October 2016 at 12:58, Stephen Warren  wrote:
>>>
>>> On 10/18/2016 10:23 AM, Simon Glass wrote:


 Hi Stephen,

 On 17 October 2016 at 15:35, Stephen Warren 
 wrote:
>
>
> From: Stephen Warren 
>
> SoC-specific logic may be required for all forms of cache-wide
> operations; invalidate and flush of both dcache and icache (note that
> only 3 of the 4 possible combinations make sense, since the icache
> never
> contains dirty lines). This patch adds an optional hook for all
> implemented cache-wide operations, and renames the one existing hook to
> better represent exactly which operation it is implementing. A dummy
> no-op implementation of each hook is provided. These dummy
> implementations are moved into C code, since there's no need to
> implement them in assembly.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/cpu/armv8/cache.S   |  6 --
>  arch/arm/cpu/armv8/cache_v8.c| 23
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
>  arch/arm/include/asm/system.h|  5 -
>  arch/arm/mach-tegra/tegra186/cache.c |  2 +-
>  5 files changed, 27 insertions(+), 13 deletions(-)
>

 I think we should have a proper interface for this stuff rather than
 weak functions. Maybe we need a linker-list approach, or a cache
 uclass?
>>>
>>>
>>>
>>> What's improper about this interface? Presumably we could argue that no
>>> function in the entire of U-Boot be called by symbol name, which doesn't
>>> seem useful.
>>>
>>> I'm not sure exactly what you envisage by a linker-list approach. Can you
>>> provide some background? I understand how the linker can construct list
>>> of
>>> objects/implementations/..., but that doesn't seem useful here since
>>> there's
>>> a known-ahead-of-time single implementation of these functions in a
>>> single
>>> build of U-Boot.
>>
>>
>> Your own commit messages says that this is SoC-specific. I'm
>> suggesting that we define an interface (which I think you have already
>> done with your header file additions), and allow SoCs to implement it
>> via a linker list.
>>
>> IMO the cache code in U-Boot is starting to get a bit creaky.
>>
>>> A cache uclass seems like /massive/ overkill, especially since I'd expect
>>> these very low-level functions to be required well before any higher
>>> level
>>> code like DM/classes/... to be available.
>>
>>
>> DM is available very early. But it's not clear from your patch when
>> this code is actually called.
>
>
> I believe that weak functions are a perfectly acceptable approach here.
>
> Yes, the implementation of these functions is SoC-specific. The Makefiles
> will pull in the appropriate implementation for that SoC whenever U-Boot is
> built, just like every other board- or SoC-specific function in the entire
> of U-Boot.
>
> There's no need for linker lists since there is only ever one
> implementation.

If there is only ever one implementation, why do you need weak
functions? Just call them directly. I think in fact you mean that
there can be no implementation (but perhaps an empty one), or one
implementation. You are effectively using multiple weak functions to
provide default code. I think it would be better if this were
explicit.

I still think that the cache functions could do with a rethink.

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

Re: [U-Boot] [PATCH 1/2] tools: moveconfig: support wildcards in --defconfigs file

[Joe Hershberger]

On Tue, Oct 18, 2016 at 2:23 PM, Tom Rini  wrote:
> On Wed, Oct 19, 2016 at 01:14:58AM +0900, Masahiro Yamada wrote:
>> 2016-10-17 5:15 GMT+09:00 Tom Rini :
>> > On Mon, Oct 17, 2016 at 02:17:22AM +0900, Masahiro Yamada wrote:
>> > I don't see error handling in the case of files (and now globs) not
>> > existing now, is this just handled by other parts of the code?  Thanks!
>>
>>
>> No, it will be removed.
>>
>> With this patch, each line will be a pattern
>> that may match multiple defconfigs,
>> or that may match nothing.
>
> Ah, OK.
>
>> Is it important to check users' possible typos?
>
> Well, will a list of invalid config names say something useful, or fail
> silently or fail in unexpected ways?

It seems like it would be good to warn if a glob (or otherwise)
results in an empty set, because that it probably not what was
intended.

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

Re: [U-Boot] [PATCH 2/2] tools: moveconfig: process defconfig files in alphabetical order

[Tom Rini]

On Wed, Oct 19, 2016 at 01:23:24AM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 2016-10-17 5:12 GMT+09:00 Tom Rini :
> > On Mon, Oct 17, 2016 at 02:17:23AM +0900, Masahiro Yamada wrote:
> >> This will make the log more readable.  The log is not deterministic
> >> in case of parallel processing, though.
> >>
> >> Signed-off-by: Masahiro Yamada 
> >
> > I'm honestly ambivalent about this since single threaded is basically
> > never the case, right?
> 
> 
> Right.
> If you want to diff two logs, you need to pass -j1 option.
> 
> But, my main motivation is not that.
> You will be able to find the log of boards you are interested in.
> 
> For example, when some boards are listed in "suspicious results"
> at the end of conversion, you may want to check the log
> to see what happened.  If the log is sorted *almost* alphabetically,
> it will be easier to jump there.

I'm still ambivalent.  I 'less' the log and search doesn't care about
order.  And I try and fix one broken board at a time since it's often
the case that N boards will have the same form of thinko.

-- 
Tom


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

Re: [U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[york sun]

On 10/17/2016 04:45 AM, Alexander Graf wrote:
>
>
> On 10/17/2016 10:56 AM, Prabhakar Kushwaha wrote:
>>> -Original Message-
>>> From: Alexander Graf [mailto:ag...@suse.de]
>>> Sent: Monday, October 17, 2016 12:28 PM
>>> To: Prabhakar Kushwaha ; u-
>>> b...@lists.denx.de
>>> Cc: york sun 
>>> Subject: Re: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting 
>>> U-Boot
>>>
>>> Hi Prabhakara,
>>>
>>> On 17.10.16 05:42, Prabhakar Kushwaha wrote:
 Hi Alex,

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Saturday, October 15, 2016 3:33 PM
> To: u-boot@lists.denx.de
> Cc: york sun ; Prabhakar Kushwaha
> 
> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>
> On ls2080 we have a separate network fabric component which we need to
> shut down before we enter Linux (or any other OS). Along with that also
> comes configuration of the fabric using a description file.
>
> Today we always stop and configure the fabric in the boot script and
> (again) exit it on device tree generation. This works ok for the normal
> booti case, but with bootefi the payload we're running may still want to
> access the network.
>
> So let's add a new fsl_mc command that defers configuration and stopping
> the hardware to when we actually exit U-Boot, so that we can still use
> the fabric from an EFI payload.
>
> For existing boot scripts, nothing should change with this patch.
>
> Signed-off-by: Alexander Graf 
>
 Can we get one small modification in this patch to include env variable.
 So if a user **always** want " lazyapply", this info can be stored in env
>>> variable. This env variable will be used after reset without explicit u-boot
>>> command.
>>>
>>> I'm not sure I understand your suggestion. We use "lazyapply" because
>>> EFI payloads need to be able to use the fabric for network I/O which is
>>> impossible after a normal apply.
>>>
>>> Because we don't know in bootcmd whether we will end up in the old bootm
>>> path or in the fallback distro path (which again potentially means
>>> efi_loader), we have to play safe (lazyapply) by default.
>>>
>> If I understand correctly, this patch defines a variable mc_lazy_dpl_addr.  
>> It is set via " fsl_mc lazyapply DPL" u-boot command.
>> If this variable set
>>- Apply DPL file during bootm (no user intervention)
>> Else
>>   - Assume user to apply dpl manually by " fsl_mc apply DPL" before running 
>> bootm.
>>
>> One modification can be done to store value mc_lazy_dpl_addr in env so that 
>> " fsl_mc lazyapply DPL " will not be required to run after every reset.
>
> Ah, I see what you're getting at. I like the idea, but I'm not sure this
> is what users would expect. So imagine you do
>
># fsl_mc lazyapply ...
># 
># # saveenv
>
> then suddenly you have the lazyapply in your environment. In *most*
> parts of U-Boot environment variables are not used for state transfer
> (one function sets it, another one reads it). So having it here would be
> pretty unnatural and potentially confusing to users.
>
> I'd leave the decision up to York though, it's his command :). Changing
> it to be env based instead is trivial.
>
Prabhakar,

I believe you are trying to address another related issue for applying 
DPL. Please submit a patch on top of Alex's. You can wait a little bit 
after his set is settled.

York

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

Re: [U-Boot] [PATCH 1/2] tools: moveconfig: support wildcards in --defconfigs file

[Tom Rini]

On Wed, Oct 19, 2016 at 01:14:58AM +0900, Masahiro Yamada wrote:
> 2016-10-17 5:15 GMT+09:00 Tom Rini :
> > On Mon, Oct 17, 2016 at 02:17:22AM +0900, Masahiro Yamada wrote:
> >
> >> Supporting shell-style wildcards for the --defconfigs option will be
> >> useful to run the moveconfig tool against a specific platform.  For
> >> example, "uniphier*" in the file passed by --defconfigs option will
> >> be expanded to defconfig files that start with "uniphier".  This is
> >> easier than listing out all the UniPhier defconfig files.
> >>
> >> Signed-off-by: Masahiro Yamada 
> >> ---
> >>
> >>  tools/moveconfig.py | 23 +++
> >>  1 file changed, 15 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/tools/moveconfig.py b/tools/moveconfig.py
> >> index 87e2bb2..67cf5f0 100755
> >> --- a/tools/moveconfig.py
> >> +++ b/tools/moveconfig.py
> >> @@ -127,7 +127,8 @@ Available options
> >> standard commit message is used which may need to be edited.
> >>
> >>   -d, --defconfigs
> >> -  Specify a file containing a list of defconfigs to move
> >> +  Specify a file containing a list of defconfigs to move.  The defconfig
> >> +  files can be given with shell-style wildcards.
> >>
> >>   -n, --dry-run
> >> Perform a trial run that does not make any changes.  It is useful to
> >> @@ -180,6 +181,7 @@ import copy
> >>  import difflib
> >>  import filecmp
> >>  import fnmatch
> >> +import glob
> >>  import multiprocessing
> >>  import optparse
> >>  import os
> >> @@ -284,6 +286,17 @@ def get_make_cmd():
> >>  sys.exit('GNU Make not found')
> >>  return ret[0].rstrip()
> >>
> >> +def get_matched_defconfigs(defconfigs_file):
> >> +"""Get all the defconfig files that match the patterns in a file."""
> >> +# use a set rather than a list in order to avoid double-counting
> >> +defconfigs = set()
> >> +for line in open(defconfigs_file):
> >> +line = os.path.join('configs', line.strip())
> >> +defconfigs |= set(glob.glob(line))
> >> +defconfigs |= set(glob.glob(line + '_defconfig'))
> >> +
> >> +return [ defconfig[len('configs') + 1:]  for defconfig in defconfigs ]
> >> +
> >>  def get_all_defconfigs():
> >>  """Get all the defconfig files under the configs/ directory."""
> >>  defconfigs = []
> >> @@ -1204,13 +1217,7 @@ def move_config(configs, options):
> >>  reference_src_dir = None
> >>
> >>  if options.defconfigs:
> >> -defconfigs = [line.strip() for line in open(options.defconfigs)]
> >> -for i, defconfig in enumerate(defconfigs):
> >> -if not defconfig.endswith('_defconfig'):
> >> -defconfigs[i] = defconfig + '_defconfig'
> >> -if not os.path.exists(os.path.join('configs', defconfigs[i])):
> >> -sys.exit('%s - defconfig does not exist. Stopping.' %
> >> - defconfigs[i])
> >> +defconfigs = get_matched_defconfigs(options.defconfigs)
> >
> > I don't see error handling in the case of files (and now globs) not
> > existing now, is this just handled by other parts of the code?  Thanks!
> 
> 
> No, it will be removed.
> 
> With this patch, each line will be a pattern
> that may match multiple defconfigs,
> or that may match nothing.

Ah, OK.

> Is it important to check users' possible typos?

Well, will a list of invalid config names say something useful, or fail
silently or fail in unexpected ways?

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 01:03 PM, Simon Glass wrote:

Hi Stephen,

On 18 October 2016 at 12:58, Stephen Warren  wrote:

On 10/18/2016 10:23 AM, Simon Glass wrote:


Hi Stephen,

On 17 October 2016 at 15:35, Stephen Warren  wrote:


From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.

Signed-off-by: Stephen Warren 
---
 arch/arm/cpu/armv8/cache.S   |  6 --
 arch/arm/cpu/armv8/cache_v8.c| 23
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
 arch/arm/include/asm/system.h|  5 -
 arch/arm/mach-tegra/tegra186/cache.c |  2 +-
 5 files changed, 27 insertions(+), 13 deletions(-)



I think we should have a proper interface for this stuff rather than
weak functions. Maybe we need a linker-list approach, or a cache
uclass?



What's improper about this interface? Presumably we could argue that no
function in the entire of U-Boot be called by symbol name, which doesn't
seem useful.

I'm not sure exactly what you envisage by a linker-list approach. Can you
provide some background? I understand how the linker can construct list of
objects/implementations/..., but that doesn't seem useful here since there's
a known-ahead-of-time single implementation of these functions in a single
build of U-Boot.


Your own commit messages says that this is SoC-specific. I'm
suggesting that we define an interface (which I think you have already
done with your header file additions), and allow SoCs to implement it
via a linker list.

IMO the cache code in U-Boot is starting to get a bit creaky.


A cache uclass seems like /massive/ overkill, especially since I'd expect
these very low-level functions to be required well before any higher level
code like DM/classes/... to be available.


DM is available very early. But it's not clear from your patch when
this code is actually called.


I believe that weak functions are a perfectly acceptable approach here.

Yes, the implementation of these functions is SoC-specific. The 
Makefiles will pull in the appropriate implementation for that SoC 
whenever U-Boot is built, just like every other board- or SoC-specific 
function in the entire of U-Boot.


There's no need for linker lists since there is only ever one 
implementation.

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Simon Glass]

Hi Stephen,

On 18 October 2016 at 12:58, Stephen Warren  wrote:
> On 10/18/2016 10:23 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 17 October 2016 at 15:35, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> SoC-specific logic may be required for all forms of cache-wide
>>> operations; invalidate and flush of both dcache and icache (note that
>>> only 3 of the 4 possible combinations make sense, since the icache never
>>> contains dirty lines). This patch adds an optional hook for all
>>> implemented cache-wide operations, and renames the one existing hook to
>>> better represent exactly which operation it is implementing. A dummy
>>> no-op implementation of each hook is provided. These dummy
>>> implementations are moved into C code, since there's no need to
>>> implement them in assembly.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>>  arch/arm/cpu/armv8/cache.S   |  6 --
>>>  arch/arm/cpu/armv8/cache_v8.c| 23
>>> ---
>>>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
>>>  arch/arm/include/asm/system.h|  5 -
>>>  arch/arm/mach-tegra/tegra186/cache.c |  2 +-
>>>  5 files changed, 27 insertions(+), 13 deletions(-)
>>>
>>
>> I think we should have a proper interface for this stuff rather than
>> weak functions. Maybe we need a linker-list approach, or a cache
>> uclass?
>
>
> What's improper about this interface? Presumably we could argue that no
> function in the entire of U-Boot be called by symbol name, which doesn't
> seem useful.
>
> I'm not sure exactly what you envisage by a linker-list approach. Can you
> provide some background? I understand how the linker can construct list of
> objects/implementations/..., but that doesn't seem useful here since there's
> a known-ahead-of-time single implementation of these functions in a single
> build of U-Boot.

Your own commit messages says that this is SoC-specific. I'm
suggesting that we define an interface (which I think you have already
done with your header file additions), and allow SoCs to implement it
via a linker list.

IMO the cache code in U-Boot is starting to get a bit creaky.

>
> A cache uclass seems like /massive/ overkill, especially since I'd expect
> these very low-level functions to be required well before any higher level
> code like DM/classes/... to be available.

DM is available very early. But it's not clear from your patch when
this code is actually called.

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 12:40 PM, york sun wrote:

On 10/18/2016 11:14 AM, Stephen Warren wrote:

On 10/18/2016 09:28 AM, york sun wrote:

On 10/17/2016 04:35 PM, Stephen Warren wrote:

From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.


Stephen,

Moving this function to C may pose an issue. I had a debug a couple of
years ago that calling a C function put the stack into cache after
flushing L1/L2. That's why I used asm function to flush L3.


Assuming the stack is located in cachable memory, the CPU is free (per
the definition of the ARM architecture) to pull it into the cache at any
time the cache is enabled (and perhaps even when it isn't enabled, at
the very least for the icache on ARMv8 if not other cases too).
Implementation in C vs. assembly has absolutely no effect here. I guess
your statement assumes that C functions will write data to the stack and
assembly functions never will. There's no strict 1:1 correlation between
those two things; assembly code can touch the stack just like C code. If
there's an assumption it won't, it needs to be documented in the header
defining these hook functions.

I assume you're specifically talking about dirtying the dcache between
the point when dcache flushing starts and the point when the dcache is
disabled? If so, flush_dcache_all() itself would have to be manually
coded in assembly to avoid using the stack, as would dcache_disable()
and set_sctlr(). I think this is why dcache_disable() currently disables
the dcache first (thus preventing it acquiring new dirty data) and then
flushes the dcache afterwards (thus guaranteeing that all dirty data is
flushed with no race condition). This implies that your change to swap
the order of those two functions isn't correct. I'm pretty sure I'm


I wonder if David can shed some light on the original order of calls to
disable dcache.


correct in saying that the dcache can hit even if it's disabled, hence
disabling the dcache while it contains dirty data won't lead to issues?



My earlier debug was based on the original order of calls. I found I had
to avoid using the stack before flushing L3. Now with the changed order,
I haven't tested. But I can image the stack will be dirty and flushing
L3 may or may not push the data into main memory (depending on the L3
implementation whether inclusive or not).

You said you are sure dcache can hit even if it is disabled. Can you
explain more? My test shows as soon as the d-cache is disabled, the core
cannot get the data in dirty cache.


By "hit" here, I mean that even with the dcache disabled, when the CPU 
performs a read access, if the dcache contains a copy of that data, it 
can return it rather than requiring it to be fetched from DRAM.


Yes, with the dcache disabled, I would not expect any writes to allocate 
new lines in the cache (although presumably writes would update any 
lines already there, in a write-though sense).


At least, I'm pretty sure this is all true. It seems the only way to 
allow switching from cache-on to cache-off state without losing dirty data.

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 10:23 AM, Simon Glass wrote:

Hi Stephen,

On 17 October 2016 at 15:35, Stephen Warren  wrote:

From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.

Signed-off-by: Stephen Warren 
---
 arch/arm/cpu/armv8/cache.S   |  6 --
 arch/arm/cpu/armv8/cache_v8.c| 23 ---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
 arch/arm/include/asm/system.h|  5 -
 arch/arm/mach-tegra/tegra186/cache.c |  2 +-
 5 files changed, 27 insertions(+), 13 deletions(-)



I think we should have a proper interface for this stuff rather than
weak functions. Maybe we need a linker-list approach, or a cache
uclass?


What's improper about this interface? Presumably we could argue that no 
function in the entire of U-Boot be called by symbol name, which doesn't 
seem useful.


I'm not sure exactly what you envisage by a linker-list approach. Can 
you provide some background? I understand how the linker can construct 
list of objects/implementations/..., but that doesn't seem useful here 
since there's a known-ahead-of-time single implementation of these 
functions in a single build of U-Boot.


A cache uclass seems like /massive/ overkill, especially since I'd 
expect these very low-level functions to be required well before any 
higher level code like DM/classes/... to be available.

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[york sun]

On 10/18/2016 11:14 AM, Stephen Warren wrote:
> On 10/18/2016 09:28 AM, york sun wrote:
>> On 10/17/2016 04:35 PM, Stephen Warren wrote:
>>> From: Stephen Warren 
>>>
>>> SoC-specific logic may be required for all forms of cache-wide
>>> operations; invalidate and flush of both dcache and icache (note that
>>> only 3 of the 4 possible combinations make sense, since the icache never
>>> contains dirty lines). This patch adds an optional hook for all
>>> implemented cache-wide operations, and renames the one existing hook to
>>> better represent exactly which operation it is implementing. A dummy
>>> no-op implementation of each hook is provided. These dummy
>>> implementations are moved into C code, since there's no need to
>>> implement them in assembly.
>>>
>> Stephen,
>>
>> Moving this function to C may pose an issue. I had a debug a couple of
>> years ago that calling a C function put the stack into cache after
>> flushing L1/L2. That's why I used asm function to flush L3.
>
> Assuming the stack is located in cachable memory, the CPU is free (per
> the definition of the ARM architecture) to pull it into the cache at any
> time the cache is enabled (and perhaps even when it isn't enabled, at
> the very least for the icache on ARMv8 if not other cases too).
> Implementation in C vs. assembly has absolutely no effect here. I guess
> your statement assumes that C functions will write data to the stack and
> assembly functions never will. There's no strict 1:1 correlation between
> those two things; assembly code can touch the stack just like C code. If
> there's an assumption it won't, it needs to be documented in the header
> defining these hook functions.
>
> I assume you're specifically talking about dirtying the dcache between
> the point when dcache flushing starts and the point when the dcache is
> disabled? If so, flush_dcache_all() itself would have to be manually
> coded in assembly to avoid using the stack, as would dcache_disable()
> and set_sctlr(). I think this is why dcache_disable() currently disables
> the dcache first (thus preventing it acquiring new dirty data) and then
> flushes the dcache afterwards (thus guaranteeing that all dirty data is
> flushed with no race condition). This implies that your change to swap
> the order of those two functions isn't correct. I'm pretty sure I'm

I wonder if David can shed some light on the original order of calls to 
disable dcache.

> correct in saying that the dcache can hit even if it's disabled, hence
> disabling the dcache while it contains dirty data won't lead to issues?
>

My earlier debug was based on the original order of calls. I found I had 
to avoid using the stack before flushing L3. Now with the changed order, 
I haven't tested. But I can image the stack will be dirty and flushing 
L3 may or may not push the data into main memory (depending on the L3 
implementation whether inclusive or not).

You said you are sure dcache can hit even if it is disabled. Can you 
explain more? My test shows as soon as the d-cache is disabled, the core 
cannot get the data in dirty cache.

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

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Marek Vasut]

On 10/18/2016 05:50 PM, Dinh Nguyen wrote:
> On Sun, Oct 16, 2016 at 10:59 AM, Marek Vasut  wrote:
>> On 10/15/2016 12:10 AM, Dinh Nguyen wrote:
>>>
>>>
>>> On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
 Hi,

 This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform 
 makes
 use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.

 This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
 the following patch "a78cd8613204 ARM: Rework and correct barrier 
 definitions"
 in order for this patch set to work correctly. With the above patch 
 applied,
 after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
 device.

>>>
>>> I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
>>> barrier definitions" is causing SPL to fail after the SDRAM scrub
>>> operation. It appears that before the above mentioned patch, the dmb()
>>> operation is defined as this:
>>>
>>> #define dmb()  __asm__ __volatile__ ("" : : : "memory")
>>>
>>> after the patch, the dmb is now:
>>>
>>> #define DMBasm volatile ("dmb sy" : : : "memory")
>>>
>>> So the "dmb sy" as described in the ARM documentation is a "Full system
>>> DMB operation". For whatever reason, this change is causing the SPL
>>> error after the SDRAM scrub operation.
>>
>> Thanks for looking into this, can you poke into it some more ?
>>
> 
> Of course..

Thanks, I sense a great share of enthusiasm in that reply ;-)

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

[U-Boot] [PULL v2] efi patch queue 2016-10-18

[Alexander Graf]

Hi Tom,

This is my current patch queue for efi.  Please pull.

Alex


The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:

  Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)

are available in the git repository at:

  git://github.com/agraf/u-boot.git tags/signed-efi-next

for you to fetch changes up to ef8b6363986e08eef1939e562c37dd142a7529a2:

  efi_loader: Revert device_handle to disk after net boot (2016-10-18 20:03:41 
+0200)


Patch queue for efi - 2016-10-18

Highlights this time around:

  - Add run time service (power control) support for PSCI
  - Add efi gop pointer exposure
  - SMBIOS support for EFI (on ARM)
  - efi pool memory unmap support (needed for 4.8)
  - initial x86 efi payload support (fixed up in v2)
  - various bug fixes


Alexander Graf (19):
  efi_loader: Allow boards to implement get_time and reset_system
  arm: Disable HVC PSCI calls by default
  arm: Add PSCI shutdown function
  arm: Provide common PSCI based reset handler
  efi_loader: Add generic PSCI RTS
  efi_loader: Allow bouncing for network
  efi_loader: gop: Expose fb when 32bpp
  x86: Move table csum into separate file
  x86: Move smbios generation into arch independent directory
  efi_loader: Expose efi_install_configuration_table
  smbios: Allow compilation on 64bit systems
  cpu: Add DMTF id and family fields
  cpu: Add get_vendor callback
  smbios: Generate type 4 on non-x86 systems
  smbios: Expose in efi_loader as table
  efi_loader: Fix efi_install_configuration_table
  smbios: Provide serial number
  efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}
  efi_loader: Revert device_handle to disk after net boot

Robin Randhawa (1):
  efi_loader: Fix crash on 32-bit systems

Simon Glass (3):
  efi: Use asmlinkage for EFIAPI
  efi: Fix missing EFIAPI specifiers
  x86: efi: Add EFI loader support for x86

Stefan Brüns (7):
  efi_loader: Update description of internal efi_mem_carve_out
  efi_loader: Fix memory map size check to avoid out-of-bounds access
  efi_loader: Move efi_allocate_pool implementation to efi_memory.c
  efi_loader: Track size of pool allocations to allow freeing
  efi_loader: Readd freed pages to memory pool
  efi_loader: Keep memory mapping sorted when splitting an entry
  efi_loader: Do not leak memory when unlinking a mapping

 arch/arm/cpu/armv8/Kconfig |  18 +
 arch/arm/cpu/armv8/fwcall.c|  59 +-
 arch/arm/include/asm/system.h  |  12 +--
 arch/arm/mach-meson/board.c|   5 --
 arch/avr32/include/asm/linkage.h   |   0
 arch/m68k/include/asm/linkage.h|   0
 arch/microblaze/include/asm/linkage.h  |   0
 arch/mips/include/asm/linkage.h|   0
 arch/nios2/include/asm/linkage.h   |   0
 arch/openrisc/include/asm/linkage.h|   0
 arch/sandbox/include/asm/linkage.h |   0
 arch/sh/include/asm/linkage.h  |   0
 arch/sparc/include/asm/linkage.h   |   0
 arch/x86/Kconfig   |  27 ---
 arch/x86/cpu/baytrail/cpu.c|   1 +
 arch/x86/cpu/broadwell/cpu.c   |   1 +
 arch/x86/cpu/cpu_x86.c |  18 +
 arch/x86/cpu/ivybridge/model_206ax.c   |   1 +
 arch/x86/cpu/u-boot.lds|  36 -
 arch/x86/include/asm/cpu_x86.h |  13 +++
 arch/x86/include/asm/tables.h  |   2 +
 arch/x86/lib/Makefile  |   2 +-
 arch/x86/lib/sections.c|  12 +++
 arch/x86/lib/tables.c  |  21 ++---
 board/xilinx/zynqmp/zynqmp.c   |   5 --
 cmd/bootefi.c  |  16 +++-
 drivers/cpu/cpu-uclass.c   |  10 +++
 include/cpu.h  |  22 ++
 include/efi.h  |   3 +-
 include/efi_api.h  |   4 +
 include/efi_loader.h   |  39 +++--
 {arch/x86/include/asm => include}/smbios.h |   8 +-
 include/tables_csum.h  |  12 +++
 lib/Kconfig|  33 
 lib/Makefile   |   2 +
 lib/efi_loader/Makefile|   1 +
 lib/efi_loader/efi_boottime.c  |  57 +-
 lib/efi_loader/efi_disk.c  |  13 +--
 lib/efi_loader/efi_gop.c   |  16 
 lib/efi_loader/efi_memory.c|  88 ++---
 lib/efi_loader/efi_net.c   |  11 ++-
 lib/efi_loader/efi_runtime.c   | 122 -
 lib/efi_loader/efi_smbios.c|  32 
 {arch/x86/lib => lib}/smbios.c |  82 

Re: [U-Boot] efi_loader: Revert device_handle to disk after net boot

[Alexander Graf]

> When you boot an efi payload from network, then exit that payload
> and load another payload from disk afterwords, the disk payload will
> currently see the network device as its boot path.
> 
> This breaks grub2 for example which tries to find its modules based
> on the path it was loaded from.
> 
> This patch fixes that issue by always reverting to disk paths if we're
> not in the network boot. That way the data structures after a network
> boot look the same as before.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

[U-Boot] Blackfin serial driver

[Simon Glass]

Hi Sonic,

Do you have plans to convert the Blackfin serial driver to driver
model? I don't have a board myself, but it looks like there is fairly
recent activity with this arch in U-Boot.

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

Re: [U-Boot] [v2, 5/5] arch/arm, arch/powerpc: enable workaround for eSDHC erratum A009620

[york sun]

On 10/18/2016 02:39 AM, Y.B. Lu wrote:
> Hi York,
>
> I have a question about CONFIG option. Are we going to completely using 
> Kconfig in the future like kernel?
> I just found below compiling error.
>
> =Error log===
> ./scripts/check-config.sh u-boot.cfg \
>   ./scripts/config_whitelist.txt . 1>&2
> Error: You must add new CONFIG options using Kconfig
> The following new ad-hoc CONFIG options were detected:
> CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>
> Please add these via Kconfig instead. Find a suitable Kconfig
> file and add a 'config' or 'menuconfig' option.
> make: *** [all] Error 1
> ===
>
> As you know, all CONFIG options of the QorIQ eSDHC driver were defined in 
> .h.
> Should we convert to use Kconfig for eSDHC driver?
>


That is the direction U-Boot is taking. Please check my recent commits 
on upstream U-Boot for examples to move config macros to Kconfig. I 
converted some DDR options, and some errata macros.

York

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

[U-Boot] *preferred* place in u-boot to tweak device tree?

[Robert P. J. Day]

  a while back, i asked about the best way to have u-boot extract the
MAC address from a well-known address in flash, and add it to the
device tree to pass to the kernel; discussion was here:

 http://lists.denx.de/pipermail/u-boot/2016-May/255856.html

i notice that another option for tweaking the MAC address that is
popular is to add that code to a board's misc_init_r(). so both ways
work just fine, but i'm assuming that the *proper* place to do it is
in ft_board_setup(), since the routine image_setup_libfdt() pretty
much handles everything, and all that's left to do is extend
ft_board_setup() to set the env variable:

eth_setenv_enetaddr("ethaddr", );

is that what you'd call "best practice"?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH] libfdt: Sync overlay with upstream

[Simon Glass]

Hi Maxime,

On 18 October 2016 at 01:26, Maxime Ripard
 wrote:
> Hi Simon,
>
> On Mon, Oct 17, 2016 at 04:17:33PM -0600, Simon Glass wrote:
>> On 17 October 2016 at 14:50, Maxime Ripard
>>  wrote:
>> > Now that the overlay code has been merge upstream, update our copy to
>> > what's been merged, since a significant number of issues have been fixed
>> > during the merge process.
>> >
>> > Signed-off-by: Maxime Ripard 
>> > ---
>> >  include/libfdt.h  |  24 --
>> >  lib/libfdt/fdt_overlay.c  | 199 
>> > +-
>> >  lib/libfdt/fdt_strerror.c |   3 +
>> >  3 files changed, 147 insertions(+), 79 deletions(-)
>>
>> Acked-by: Simon Glass 
>
> Sorry for the dumb question, but shouldn't that go through your tree ?

Yes. Since we are at RC2 I was thinking of waiting until next cycle
though. Or do you think this is urgent?

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

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Simon Glass]

Hi Stephen,

On 17 October 2016 at 15:35, Stephen Warren  wrote:
> From: Stephen Warren 
>
> SoC-specific logic may be required for all forms of cache-wide
> operations; invalidate and flush of both dcache and icache (note that
> only 3 of the 4 possible combinations make sense, since the icache never
> contains dirty lines). This patch adds an optional hook for all
> implemented cache-wide operations, and renames the one existing hook to
> better represent exactly which operation it is implementing. A dummy
> no-op implementation of each hook is provided. These dummy
> implementations are moved into C code, since there's no need to
> implement them in assembly.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/cpu/armv8/cache.S   |  6 --
>  arch/arm/cpu/armv8/cache_v8.c| 23 ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S |  4 ++--
>  arch/arm/include/asm/system.h|  5 -
>  arch/arm/mach-tegra/tegra186/cache.c |  2 +-
>  5 files changed, 27 insertions(+), 13 deletions(-)
>

I think we should have a proper interface for this stuff rather than
weak functions. Maybe we need a linker-list approach, or a cache
uclass?

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

Re: [U-Boot] [PATCH 2/2] tools: moveconfig: process defconfig files in alphabetical order

[Masahiro Yamada]

Hi Tom,

2016-10-17 5:12 GMT+09:00 Tom Rini :
> On Mon, Oct 17, 2016 at 02:17:23AM +0900, Masahiro Yamada wrote:
>> This will make the log more readable.  The log is not deterministic
>> in case of parallel processing, though.
>>
>> Signed-off-by: Masahiro Yamada 
>
> I'm honestly ambivalent about this since single threaded is basically
> never the case, right?


Right.
If you want to diff two logs, you need to pass -j1 option.

But, my main motivation is not that.
You will be able to find the log of boards you are interested in.

For example, when some boards are listed in "suspicious results"
at the end of conversion, you may want to check the log
to see what happened.  If the log is sorted *almost* alphabetically,
it will be easier to jump there.



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

Re: [U-Boot] [PATCH v5 5/7] armv8: ls2080a: Declare spin tables as reserved for efi loader

[york sun]

On 10/17/2016 02:01 AM, Alexander Graf wrote:
>
>
> On 15.10.16 18:57, york sun wrote:
>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>> The efi loader code has its own memory map, so it needs to be aware where
>>> the spin tables are located, to ensure that no code writes into those
>>> regions.
>>>
>>> Signed-off-by: Alexander Graf 
>>> ---
>>>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
>>> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> index 1a8321b..facfcca 100644
>>> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
>>> @@ -5,6 +5,7 @@
>>>   */
>>>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -105,6 +106,11 @@ remove_psci_node:
>>>
>>> fdt_add_mem_rsv(blob, (uintptr_t)_boot_code,
>>> *boot_code_size);
>>> +#ifdef CONFIG_EFI_LOADER
>>> +   efi_add_memory_map((uintptr_t)_boot_code,
>>> +  ALIGN(*boot_code_size, EFI_PAGE_SIZE) >> 
>>> EFI_PAGE_SHIFT,
>>> +  EFI_RESERVED_MEMORY_TYPE, false);
>>> +#endif
>>>  }
>>>  #endif
>>>
>>>
>> Alex,
>>
>> Does it make more sense to use __spin_table instead of
>> secondary_boot_code (even they happen to have the same value here)?
>
> I'm reasonably indifferent, but I wanted to make sure we're using the
> same values as the fdt_add_mem_rsv() line above :).

OK, then.

York

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

Re: [U-Boot] [PATCH 1/2] tools: moveconfig: support wildcards in --defconfigs file

[Masahiro Yamada]

2016-10-17 5:15 GMT+09:00 Tom Rini :
> On Mon, Oct 17, 2016 at 02:17:22AM +0900, Masahiro Yamada wrote:
>
>> Supporting shell-style wildcards for the --defconfigs option will be
>> useful to run the moveconfig tool against a specific platform.  For
>> example, "uniphier*" in the file passed by --defconfigs option will
>> be expanded to defconfig files that start with "uniphier".  This is
>> easier than listing out all the UniPhier defconfig files.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  tools/moveconfig.py | 23 +++
>>  1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/moveconfig.py b/tools/moveconfig.py
>> index 87e2bb2..67cf5f0 100755
>> --- a/tools/moveconfig.py
>> +++ b/tools/moveconfig.py
>> @@ -127,7 +127,8 @@ Available options
>> standard commit message is used which may need to be edited.
>>
>>   -d, --defconfigs
>> -  Specify a file containing a list of defconfigs to move
>> +  Specify a file containing a list of defconfigs to move.  The defconfig
>> +  files can be given with shell-style wildcards.
>>
>>   -n, --dry-run
>> Perform a trial run that does not make any changes.  It is useful to
>> @@ -180,6 +181,7 @@ import copy
>>  import difflib
>>  import filecmp
>>  import fnmatch
>> +import glob
>>  import multiprocessing
>>  import optparse
>>  import os
>> @@ -284,6 +286,17 @@ def get_make_cmd():
>>  sys.exit('GNU Make not found')
>>  return ret[0].rstrip()
>>
>> +def get_matched_defconfigs(defconfigs_file):
>> +"""Get all the defconfig files that match the patterns in a file."""
>> +# use a set rather than a list in order to avoid double-counting
>> +defconfigs = set()
>> +for line in open(defconfigs_file):
>> +line = os.path.join('configs', line.strip())
>> +defconfigs |= set(glob.glob(line))
>> +defconfigs |= set(glob.glob(line + '_defconfig'))
>> +
>> +return [ defconfig[len('configs') + 1:]  for defconfig in defconfigs ]
>> +
>>  def get_all_defconfigs():
>>  """Get all the defconfig files under the configs/ directory."""
>>  defconfigs = []
>> @@ -1204,13 +1217,7 @@ def move_config(configs, options):
>>  reference_src_dir = None
>>
>>  if options.defconfigs:
>> -defconfigs = [line.strip() for line in open(options.defconfigs)]
>> -for i, defconfig in enumerate(defconfigs):
>> -if not defconfig.endswith('_defconfig'):
>> -defconfigs[i] = defconfig + '_defconfig'
>> -if not os.path.exists(os.path.join('configs', defconfigs[i])):
>> -sys.exit('%s - defconfig does not exist. Stopping.' %
>> - defconfigs[i])
>> +defconfigs = get_matched_defconfigs(options.defconfigs)
>
> I don't see error handling in the case of files (and now globs) not
> existing now, is this just handled by other parts of the code?  Thanks!


No, it will be removed.

With this patch, each line will be a pattern
that may match multiple defconfigs,
or that may match nothing.

Is it important to check users' possible typos?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] armv8: add hooks for all cache-wide operations

[Stephen Warren]

On 10/18/2016 09:28 AM, york sun wrote:

On 10/17/2016 04:35 PM, Stephen Warren wrote:

From: Stephen Warren 

SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided. These dummy
implementations are moved into C code, since there's no need to
implement them in assembly.


Stephen,

Moving this function to C may pose an issue. I had a debug a couple of
years ago that calling a C function put the stack into cache after
flushing L1/L2. That's why I used asm function to flush L3.


Assuming the stack is located in cachable memory, the CPU is free (per 
the definition of the ARM architecture) to pull it into the cache at any 
time the cache is enabled (and perhaps even when it isn't enabled, at 
the very least for the icache on ARMv8 if not other cases too). 
Implementation in C vs. assembly has absolutely no effect here. I guess 
your statement assumes that C functions will write data to the stack and 
assembly functions never will. There's no strict 1:1 correlation between 
those two things; assembly code can touch the stack just like C code. If 
there's an assumption it won't, it needs to be documented in the header 
defining these hook functions.


I assume you're specifically talking about dirtying the dcache between 
the point when dcache flushing starts and the point when the dcache is 
disabled? If so, flush_dcache_all() itself would have to be manually 
coded in assembly to avoid using the stack, as would dcache_disable() 
and set_sctlr(). I think this is why dcache_disable() currently disables 
the dcache first (thus preventing it acquiring new dirty data) and then 
flushes the dcache afterwards (thus guaranteeing that all dirty data is 
flushed with no race condition). This implies that your change to swap 
the order of those two functions isn't correct. I'm pretty sure I'm 
correct in saying that the dcache can hit even if it's disabled, hence 
disabling the dcache while it contains dirty data won't lead to issues?

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

[U-Boot] pull request: u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom.

I was a bit late for -rc2, but please pull some more for UniPhier SoCs:

 * rework clk driver to re-use corresponding clk data from Linux
 * Re-sync DT with Linux
 * Reset migrate from ad-hoc code to the reset driver
 * some fixes


The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:

  Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)

are available in the git repository at:

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

for you to fetch changes up to 12a5ce72738a34eaa11b559778039f1051425dbd:

  ARM: uniphier: update doc/README.uniphier (2016-10-18 14:30:05 +0900)


Masahiro Yamada (7):
  pinctrl: uniphier: fix unused-const-variable warnings for GCC 6.x
  ARM: uniphier: fix addresses of Cortex-A72 gear setting macros
  ARM: uniphier: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT define
  clk: uniphier: rework UniPhier clk driver
  ARM: dts: uniphier: sync DT with latest Linux
  ARM: uniphier: remove unnecessary EHCI reset deassertion
  ARM: uniphier: update doc/README.uniphier

 arch/arm/dts/Makefile |  24 ++--
 arch/arm/dts/uniphier-common32.dtsi   |   8 +-
 .../{uniphier-ph1-ld11-ref.dts => uniphier-ld11-ref.dts}  |   9 +-
 .../dts/{uniphier-ph1-ld11.dtsi => uniphier-ld11.dtsi}|  16 ++-
 .../{uniphier-ph1-ld20-ref.dts => uniphier-ld20-ref.dts}  |  11 +-
 .../dts/{uniphier-ph1-ld20.dtsi => uniphier-ld20.dtsi}|   9 +-
 .../{uniphier-ph1-ld4-ref.dts => uniphier-ld4-ref.dts}|  11 +-
 arch/arm/dts/{uniphier-ph1-ld4.dtsi => uniphier-ld4.dtsi} |  24 +++-
 .../{uniphier-ph1-ld6b-ref.dts => uniphier-ld6b-ref.dts}  |  11 +-
 arch/arm/dts/uniphier-ld6b.dtsi   |  32 +
 arch/arm/dts/uniphier-ph1-ld6b.dtsi   |  31 -
 .../{uniphier-ph1-pro4-ace.dts => uniphier-pro4-ace.dts}  |  15 +-
 .../{uniphier-ph1-pro4-ref.dts => uniphier-pro4-ref.dts}  |  11 +-
 ...niphier-ph1-pro4-sanji.dts => uniphier-pro4-sanji.dts} |  15 +-
 .../dts/{uniphier-ph1-pro4.dtsi => uniphier-pro4.dtsi}|  23 +++-
 ...niphier-ph1-pro5-4kbox.dts => uniphier-pro5-4kbox.dts} |  11 +-
 .../dts/{uniphier-ph1-pro5.dtsi => uniphier-pro5.dtsi}|  14 +-
 ...er-proxstream2-gentil.dts => uniphier-pxs2-gentil.dts} |  16 ++-
 ...hier-proxstream2-vodka.dts => uniphier-pxs2-vodka.dts} |  11 +-
 .../dts/{uniphier-proxstream2.dtsi => uniphier-pxs2.dtsi} |  16 ++-
 .../{uniphier-ph1-sld3-ref.dts => uniphier-sld3-ref.dts}  |  11 +-
 .../dts/{uniphier-ph1-sld3.dtsi => uniphier-sld3.dtsi}|  48 +--
 .../{uniphier-ph1-sld8-ref.dts => uniphier-sld8-ref.dts}  |  11 +-
 .../dts/{uniphier-ph1-sld8.dtsi => uniphier-sld8.dtsi}|  24 +++-
 arch/arm/mach-uniphier/boards.c   |  26 ++--
 arch/arm/mach-uniphier/clk/clk-ld4.c  |   7 +-
 arch/arm/mach-uniphier/clk/clk-pro4.c |   7 +-
 arch/arm/mach-uniphier/sc64-regs.h|   6 +-
 configs/uniphier_ld11_defconfig   |   2 +-
 configs/uniphier_ld20_defconfig   |   2 +-
 configs/uniphier_ld4_sld8_defconfig   |   2 +-
 configs/uniphier_pro4_defconfig   |   2 +-
 configs/uniphier_pxs2_ld6b_defconfig  |   2 +-
 configs/uniphier_sld3_defconfig   |   2 +-
 doc/README.uniphier   |  78 +--
 drivers/clk/uniphier/Kconfig  |  15 +-
 drivers/clk/uniphier/Makefile |   5 +-
 drivers/clk/uniphier/clk-uniphier-core.c  | 170
+++
 drivers/clk/uniphier/clk-uniphier-mio.c   | 183
+
 drivers/clk/uniphier/clk-uniphier.h   |  46 ---
 drivers/pinctrl/uniphier/pinctrl-uniphier.h   |   7 +-
 include/configs/uniphier.h|   1 -
 42 files changed, 511 insertions(+), 464 deletions(-)
 rename arch/arm/dts/{uniphier-ph1-ld11-ref.dts => uniphier-ld11-ref.dts} (78%)
 rename arch/arm/dts/{uniphier-ph1-ld11.dtsi => uniphier-ld11.dtsi} (93%)
 rename arch/arm/dts/{uniphier-ph1-ld20-ref.dts => uniphier-ld20-ref.dts} (70%)
 rename arch/arm/dts/{uniphier-ph1-ld20.dtsi => uniphier-ld20.dtsi} (96%)
 rename arch/arm/dts/{uniphier-ph1-ld4-ref.dts => uniphier-ld4-ref.dts} (72%)
 rename arch/arm/dts/{uniphier-ph1-ld4.dtsi => uniphier-ld4.dtsi} (89%)
 rename arch/arm/dts/{uniphier-ph1-ld6b-ref.dts => uniphier-ld6b-ref.dts} (73%)
 create mode 100644 arch/arm/dts/uniphier-ld6b.dtsi
 delete mode 100644 arch/arm/dts/uniphier-ph1-ld6b.dtsi
 rename arch/arm/dts/{uniphier-ph1-pro4-ace.dts => uniphier-pro4-ace.dts} (72%)
 rename arch/arm/dts/{uniphier-ph1-pro4-ref.dts => uniphier-pro4-ref.dts} (74%)
 rename arch/arm/dts/{uniphier-ph1-pro4-sanji.dts =>
uniphier-pro4-sanji.dts} 

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Dinh Nguyen]

On Sun, Oct 16, 2016 at 10:59 AM, Marek Vasut  wrote:
> On 10/15/2016 12:10 AM, Dinh Nguyen wrote:
>>
>>
>> On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
>>> Hi,
>>>
>>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform 
>>> makes
>>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
>>>
>>> This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
>>> the following patch "a78cd8613204 ARM: Rework and correct barrier 
>>> definitions"
>>> in order for this patch set to work correctly. With the above patch applied,
>>> after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
>>> device.
>>>
>>
>> I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
>> barrier definitions" is causing SPL to fail after the SDRAM scrub
>> operation. It appears that before the above mentioned patch, the dmb()
>> operation is defined as this:
>>
>> #define dmb()  __asm__ __volatile__ ("" : : : "memory")
>>
>> after the patch, the dmb is now:
>>
>> #define DMBasm volatile ("dmb sy" : : : "memory")
>>
>> So the "dmb sy" as described in the ARM documentation is a "Full system
>> DMB operation". For whatever reason, this change is causing the SPL
>> error after the SDRAM scrub operation.
>
> Thanks for looking into this, can you poke into it some more ?
>

Of course..

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

Re: [U-Boot] [PATCH] doc/README.uniphier: add build instruction for 64bit SoCs

[Masahiro Yamada]

2016-10-17 22:20 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 
> ---


Applied to u-boot-uniphier/master.


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

Re: [U-Boot] [PATCH] ARM: uniphier: fix addresses of Cortex-A72 gear setting macros

[Masahiro Yamada]

2016-10-12 21:14 GMT+09:00 Masahiro Yamada :
> My mistake during copy-paste work.
>
> Signed-off-by: Masahiro Yamada 
> ---


Applied to u-boot-uniphier/master.



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

Re: [U-Boot] [PATCH] pinctrl: uniphier: fix unused-const-variable warnings for GCC 6.x

[Marek Vasut]

On 10/18/2016 05:38 PM, Masahiro Yamada wrote:
> 2016-10-09 23:52 GMT+09:00 Masahiro Yamada :
>> Marek reports warnings in UniPhier pinctrl drivers when compiled by
>> GCC 6.x, like:
>>
>>   drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c:58:18: warning:
>>   'usb3_muxvals' defined but not used [-Wunused-const-variable=]
>>static const int usb3_muxvals[] = {0, 0};
>> ^~~~
>>
>> My intention here is to compile minimum set of pin data for SPL to
>> save memory footprint, but GCC these days is clever enough to notice
>> unused data arrays.
>>
>> We can fix it by sprinkling around __maybe_unused on those arrays,
>> but I did not do that because they are counterparts of the pinctrl
>> drivers in Linux.  All the pin data were just copy-pasted from Linux
>> and are kept in sync for maintainability.
>>
>> I chose a bit tricky way to fix the issue; calculate ARRAY_SIZE of
>> *_pins and *_muxvals and set their sum to an unused struct member.
>> This trick will satisfy GCC because the data arrays are used anyway,
>> but such data arrays will be dropped from the final binary because
>> the pointers to them are not used.
>>
>> Signed-off-by: Masahiro Yamada 
>> Reported-by: Marek Vasut 
> 
> 
> Applied to u-boot-uniphier/master.
> 
Thanks!

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

Re: [U-Boot] [PATCH 0/3] ARM: uniphier: some more UniPhier SoC code updates

[Masahiro Yamada]

2016-10-17 22:18 GMT+09:00 Masahiro Yamada :
>
>
> Masahiro Yamada (3):
>   clk: uniphier: rework UniPhier clk driver
>   ARM: uniphier: adjust fdt_file environment handling to latest Linux
>   ARM: uniphier: remove unnecessary EHCI reset deassertion
>
>  arch/arm/mach-uniphier/board_late_init.c |  17 +--
>  arch/arm/mach-uniphier/clk/clk-ld4.c |   3 -
>  arch/arm/mach-uniphier/clk/clk-pro4.c|   3 -
>  drivers/clk/uniphier/Kconfig |  15 +--
>  drivers/clk/uniphier/Makefile|   5 +-
>  drivers/clk/uniphier/clk-uniphier-core.c | 170 +---
>  drivers/clk/uniphier/clk-uniphier-mio.c  | 183 
> +++
>  drivers/clk/uniphier/clk-uniphier.h  |  46 +---
>  8 files changed, 185 insertions(+), 257 deletions(-)


Applied to u-boot-uniphier/master.


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

Re: [U-Boot] [PATCH] pinctrl: uniphier: fix unused-const-variable warnings for GCC 6.x

[Masahiro Yamada]

2016-10-09 23:52 GMT+09:00 Masahiro Yamada :
> Marek reports warnings in UniPhier pinctrl drivers when compiled by
> GCC 6.x, like:
>
>   drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c:58:18: warning:
>   'usb3_muxvals' defined but not used [-Wunused-const-variable=]
>static const int usb3_muxvals[] = {0, 0};
> ^~~~
>
> My intention here is to compile minimum set of pin data for SPL to
> save memory footprint, but GCC these days is clever enough to notice
> unused data arrays.
>
> We can fix it by sprinkling around __maybe_unused on those arrays,
> but I did not do that because they are counterparts of the pinctrl
> drivers in Linux.  All the pin data were just copy-pasted from Linux
> and are kept in sync for maintainability.
>
> I chose a bit tricky way to fix the issue; calculate ARRAY_SIZE of
> *_pins and *_muxvals and set their sum to an unused struct member.
> This trick will satisfy GCC because the data arrays are used anyway,
> but such data arrays will be dropped from the final binary because
> the pointers to them are not used.
>
> Signed-off-by: Masahiro Yamada 
> Reported-by: Marek Vasut 


Applied to u-boot-uniphier/master.

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

Re: [U-Boot] [PULL] efi patch queue 2016-10-18

[Tom Rini]

On Tue, Oct 18, 2016 at 02:06:37PM +0200, Alexander Graf wrote:

> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> 
>   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-next
> 
> for you to fetch changes up to c06a8f82c77d0fda8c190cb69e22116ebbef72b2:
> 
>   efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data} 
> (2016-10-18 09:10:05 +0200)
> 

NAK, this breaks x86 as 238d1f54eafcf705caa1460765aeb1ac17ab470e didn't
add arch/x86/lib/sections.c so x86 now fails to build.

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Tue, Oct 18, 2016 at 10:06:28AM -0400, Tom Rini wrote:
> On Tue, Oct 18, 2016 at 04:03:08PM +0800, Bin Meng wrote:
> 
> > Hi Tom,
> > 
> > The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> > 
> >   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> > 
> > are available in the git repository at:
> > 
> >   git://git.denx.de/u-boot-x86.git
> > 
> > for you to fetch changes up to f822403f0164be74a5161b65698d0f01f4556234:
> > 
> >   x86: Add implementations of setjmp() and longjmp() (2016-10-18 15:58:50 
> > +0800)
> > 
> 
> NAK.  In commit 238d1f54eafcf705caa1460765aeb1ac17ab470e sections.c
> isn't actually added so builds fail.  Thanks!

Sigh, that comes from the EFI tree not x86, my bad.  Sorry for the
noise, re-testing things.

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: zynq: Extend picozed board support

[Michal Simek]

Hi,

On 18.10.2016 09:28, Oscar Gomez Fuente wrote:
> Hi everyone,
> 
> In my opinion, use the picozed without a carrier board it doesn't make
>  sense. You always are going to need a carrier board. Avnet has two models
> the PicoZed FMC Carrier V2 and the PicoZed FMC Carrier V1. And the company
> I'm working, it is going to desing a custom carrier board according to our
> necessity.
> 
> So maybe, it's better to have only two .dts files. zynq-picozed-fmc-v2.dts
> and zynq-picozed-fmc-v1.dts.
> 
> If we decide to have the zynq-picozed.dtsi and zynq-picozed-fmc-v2.dts,
> we'll have to decide what hardware description is going to be in the
> zynq-picozed-fmc-v2.dts and what hardware description is going to be
> in zynq-picozed.dtsi.
> 
> for example the spi0 hw is in the picozed  board, but the SD (mmc0), eth0
> (gem0) and serial0 (uart1) the HW is in the picoZed but the connectors are
> in the PicoZed FMC Carrier V2, so It's a little bit confused if this HW
> description has to be on the zynq-picozed.dtsi file or in the
> zynq-picozed-fmc-v2.dts file. Do you know what I mean?
> 
> Please let me see you opinions about that.

I understand your concern. These SOMs are problematic and it is up2you
how you want to do it. My preference would be to add common stuff to
dtsi file and carried board stuff to dts file. If that configurations
have nothing in common then using just fmc dts is fine for me.
When ps7_init.* files are in place it should be visible how MIOs are
configured.

Thanks,
Michal


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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Tue, Oct 18, 2016 at 04:03:08PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:
> 
>   Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to f822403f0164be74a5161b65698d0f01f4556234:
> 
>   x86: Add implementations of setjmp() and longjmp() (2016-10-18 15:58:50 
> +0800)
> 

NAK.  In commit 238d1f54eafcf705caa1460765aeb1ac17ab470e sections.c
isn't actually added so builds fail.  Thanks!

-- 
Tom


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

[U-Boot] [PATCH] efi_loader: Revert device_handle to disk after net boot

[Alexander Graf]

When you boot an efi payload from network, then exit that payload
and load another payload from disk afterwords, the disk payload will
currently see the network device as its boot path.

This breaks grub2 for example which tries to find its modules based
on the path it was loaded from.

This patch fixes that issue by always reverting to disk paths if we're
not in the network boot. That way the data structures after a network
boot look the same as before.

Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 32148d7..a9910d7 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -207,6 +207,8 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
 
if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
loaded_image_info.device_handle = nethandle;
+   else
+   loaded_image_info.device_handle = bootefi_device_path;
 #endif
 #ifdef CONFIG_GENERATE_SMBIOS_TABLE
efi_smbios_register();
-- 
1.8.5.6

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

[U-Boot] Booting a proprietary OS

[dlbp90]

Hello everybody!!!
I need to port an operating system from x86 architecture to ARM
architecture. 
In particular i'm using a Cubietruck board board with Cortex A-7 CPU.

Initially i would use U-boot as bootloader for my operating system: so i
concentrate on kernel porting!

If i use mkimage command to create the image uncompressed of my operating
system should i project some decompressing operation for the kernel or not?
I explain batter: after loading from SD-card the kernel image and executing
bootm command to start the kernel. at the entry point of the kernel what
operation should i do and implement??

It's very important

Thanks in advance



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Booting-a-proprietary-OS-tp270884.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] qemu-x86 issues

[Tom Rini]

On Tue, Oct 18, 2016 at 09:19:59AM -0400, Tom Rini wrote:
> On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
> > Hi Tom,
> > 
> > On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini  wrote:
> > > Hey guys,
> > >
> > > After making Stephen's scripts work with qemu today, I've started
> > > testing out what platforms I can test out via qemu.  I've found two
> > > problems with qemu-x86.  First, there's a real problem with the network.
> > > I run qemu with "-nographic -cpu qemu32 -netdev
> > > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> > > tftpboot things in and I'm getting crc32 mismatches.
> > >
> > 
> > I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
> > but did not see such issue.
> 
> Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
> and the tests default to 0x0 if you don't provide an address rather than
> $loadaddr.  I'll see about changing the tests.
> 
> > > Second, the sleep command is not at all accurate.  It's returning the 3
> > > second test in less than 1 second.
> > 
> > Typical emulation target issue :) Did you see similar issue on other
> > QEMU platform with U-Boot?
> 
> So this one is interesting.  I see the same failure for MIPS/PPC for the
> qemu targets we have as well.  I don't see this under QEMU for the ARM
> targets that I'm emulating.  I suspect there's some common problem on
> the U-Boot side as also don't see this on the VMs I have running under
> qemu nor when I boot the kernelci rootfs from U-Boot.

Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
slightly too long.  x86 is the only one where it's just way too fast.
But this is not true once Linux itself is up.

-- 
Tom


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

Re: [U-Boot] qemu-x86 issues

[Tom Rini]

On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini  wrote:
> > Hey guys,
> >
> > After making Stephen's scripts work with qemu today, I've started
> > testing out what platforms I can test out via qemu.  I've found two
> > problems with qemu-x86.  First, there's a real problem with the network.
> > I run qemu with "-nographic -cpu qemu32 -netdev
> > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> > tftpboot things in and I'm getting crc32 mismatches.
> >
> 
> I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
> but did not see such issue.

Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
and the tests default to 0x0 if you don't provide an address rather than
$loadaddr.  I'll see about changing the tests.

> > Second, the sleep command is not at all accurate.  It's returning the 3
> > second test in less than 1 second.
> 
> Typical emulation target issue :) Did you see similar issue on other
> QEMU platform with U-Boot?

So this one is interesting.  I see the same failure for MIPS/PPC for the
qemu targets we have as well.  I don't see this under QEMU for the ARM
targets that I'm emulating.  I suspect there's some common problem on
the U-Boot side as also don't see this on the VMs I have running under
qemu nor when I boot the kernelci rootfs from U-Boot.

-- 
Tom


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

Re: [U-Boot] [PATCH v3 04/12] arm: socfpga: clkmgr: Separate the Clock Manager for Stratix 10

[Marek Vasut]

On 10/18/2016 05:34 AM, Chin Liang See wrote:
> On Sel, 2016-10-18 at 06:00 +0200, Marek Vasut wrote:
>> On 10/18/2016 05:22 AM, Chin Liang See wrote:
>>>
>>> On Sen, 2016-10-17 at 18:14 +0200, Marek Vasut wrote:

 On 10/17/2016 05:59 PM, Chin Liang See wrote:
>
>
> On Sen, 2016-10-17 at 17:39 +0200, Marek Vasut wrote:
>>
>>
>> On 10/17/2016 05:28 PM, Chin Liang See wrote:
>>>
>>>
>>>
>>> On Sen, 2016-10-17 at 17:20 +0200, Marek Vasut wrote:



 On 10/17/2016 05:07 PM, Chin Liang See wrote:
>
>
>
>
> On Sen, 2016-10-17 at 15:42 +0200, Marek Vasut wrote:
>>
>>
>>
>>
>> On 10/17/2016 03:32 PM, See, Chin Liang wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Min, 2016-10-16 at 17:33 +0200, Marek Vasut
>>> wrote:





 On 10/13/2016 10:33 AM, Chin Liang See wrote:
>
>
>
>
>
>
> Separate the Clock Manager to support both GEN5
> SoC
> and
> Stratix 10 SoC.
>
> Signed-off-by: Chin Liang See >
> Cc: Marek Vasut 
> Cc: Dinh Nguyen >
> Cc: Ley Foon Tan 
> Cc: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/clock_manager.c | 8
> 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/mach-
> socfpga/clock_manager.c
> b/arch/arm/mach-
> socfpga/clock_manager.c
> index aa71636..0d67b3c 100644
> --- a/arch/arm/mach-socfpga/clock_manager.c
> +++ b/arch/arm/mach-socfpga/clock_manager.c
> @@ -10,6 +10,7 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  static const struct socfpga_clock_manager
> *clock_manager_base
> =
>   (struct socfpga_clock_manager
> *)SOCFPGA_CLKMGR_ADDRESS;
>
> @@ -446,9 +447,11 @@ unsigned int
> cm_get_l4_sp_clk_hz(void)
>
>   return clock;
>  }
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>
>  unsigned int
> cm_get_mmc_controller_clk_hz(void)
>  {
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>   uint32_t reg, clock = 0;
>
>   /* identify the source of MMC clock */
> @@ -475,8 +478,12 @@ unsigned int
> cm_get_mmc_controller_clk_hz(void)
>   /* further divide by 4 as we have fixed
> divider
> at
> wrapper */
>   clock /= 4;
>   return clock;
> +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> + return 2500;
 Is this always gonna be the case or is this S10VP
 specific ?

>
>
>
>
>
>
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>  }
>
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  unsigned int
> cm_get_qspi_controller_clk_hz(void)
>  {
>   uint32_t reg, clock = 0;
> @@ -556,3 +563,4 @@ U_BOOT_CMD(
>   "display clocks",
>   ""
 Why does the clock display not work on S10 ? Are
 some
 functions
 missing?
>>> Not for SOCVP. But will be added in later stage
>>> when
>>> testing
>>> against
>>> emulation
>> How hard would it be to add this missing
>> functionality
>> now ?
>>
> That will take weeks as that need to be validated as
> whole
> in
> emulation
> platform.
 You mean printing a few clock information based on some
 values
 from
 registers would take weeks ? Why ?

>>> Oh actually I am referring all the managers code such as
>>> full
>>> Clock
>>> Manager, Reset Manager ... plus testing. Testing is the
>>> part
>>> take
>>> some
>>> significant time especially slow when come to emulation.
>> Just use empty functions for the clock init code (since it's
>> not
>> needed
>> on the socvp) and populate the clock reporting functions.
>> That
>> should
>> be
>> simple, right ?
> Can be done 

Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Improve indirect write transaction

[Marek Vasut]

On 10/18/2016 10:23 AM, Vignesh R wrote:
> 
> 
> On Thursday 06 October 2016 04:49 PM, Vignesh R wrote:
>> If the write transaction size(write_bytes) is not a multiple of word
>> length, then issue word length writes till the we reach the dangling
>> bytes. On the final write, issue byte by byte write to complete the
>> transaction. This marginally improves write throughput when performing
>> random sized writes to the flash.
>>
>> Signed-off-by: Vignesh R 
>> ---
> 
> Gentle ping... Any comments?
> 
>>
>> Tested on K2G GP EVM.
>>
>>  drivers/spi/cadence_qspi_apb.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
>> index e285d3c1e761..4b891f227243 100644
>> --- a/drivers/spi/cadence_qspi_apb.c
>> +++ b/drivers/spi/cadence_qspi_apb.c
>> @@ -752,10 +752,16 @@ int cadence_qspi_apb_indirect_write_execute(struct 
>> cadence_spi_platdata *plat,
>>  while (remaining > 0) {
>>  write_bytes = remaining > page_size ? page_size : remaining;
>>  /* Handle non-4-byte aligned access to avoid data abort. */
>> -if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
>> +if ((uintptr_t)txbuf % 4) {
>>  writesb(plat->ahbbase, txbuf, write_bytes);
>> -else
>> +} else {
>>  writesl(plat->ahbbase, txbuf, write_bytes >> 2);
>> +if (write_bytes % 4) {
>> +writesb(plat->ahbbase,
>> +txbuf + rounddown(write_bytes, 4),
>> +write_bytes % 4);
>> +}

You can probably pull this block from the else branch.

>> +}
>>  
>>  ret = wait_for_bit("QSPI", plat->regbase + CQSPI_REG_SDRAMLEVEL,
>> CQSPI_REG_SDRAMLEVEL_WR_MASK <<
>>
> 


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

[U-Boot] [PULL] efi patch queue 2016-10-18

[Alexander Graf]

Hi Tom,

This is my current patch queue for efi.  Please pull.

Alex


The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:

  Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)

are available in the git repository at:

  git://github.com/agraf/u-boot.git tags/signed-efi-next

for you to fetch changes up to c06a8f82c77d0fda8c190cb69e22116ebbef72b2:

  efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data} 
(2016-10-18 09:10:05 +0200)


Patch queue for efi - 2016-10-18

Highlights this time around:

  - Add run time service (power control) support for PSCI
  - Add efi gop pointer exposure
  - SMBIOS support for EFI (on ARM)
  - efi pool memory unmap support (needed for 4.8)
  - various bug fixes


Alexander Graf (18):
  efi_loader: Allow boards to implement get_time and reset_system
  arm: Disable HVC PSCI calls by default
  arm: Add PSCI shutdown function
  arm: Provide common PSCI based reset handler
  efi_loader: Add generic PSCI RTS
  efi_loader: Allow bouncing for network
  efi_loader: gop: Expose fb when 32bpp
  x86: Move table csum into separate file
  x86: Move smbios generation into arch independent directory
  efi_loader: Expose efi_install_configuration_table
  smbios: Allow compilation on 64bit systems
  cpu: Add DMTF id and family fields
  cpu: Add get_vendor callback
  smbios: Generate type 4 on non-x86 systems
  smbios: Expose in efi_loader as table
  efi_loader: Fix efi_install_configuration_table
  smbios: Provide serial number
  efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}

Robin Randhawa (1):
  efi_loader: Fix crash on 32-bit systems

Simon Glass (3):
  efi: Use asmlinkage for EFIAPI
  efi: Fix missing EFIAPI specifiers
  x86: efi: Add EFI loader support for x86

Stefan Brüns (7):
  efi_loader: Update description of internal efi_mem_carve_out
  efi_loader: Fix memory map size check to avoid out-of-bounds access
  efi_loader: Move efi_allocate_pool implementation to efi_memory.c
  efi_loader: Track size of pool allocations to allow freeing
  efi_loader: Readd freed pages to memory pool
  efi_loader: Keep memory mapping sorted when splitting an entry
  efi_loader: Do not leak memory when unlinking a mapping

 arch/arm/cpu/armv8/Kconfig |  18 +
 arch/arm/cpu/armv8/fwcall.c|  59 +-
 arch/arm/include/asm/system.h  |  12 +--
 arch/arm/mach-meson/board.c|   5 --
 arch/avr32/include/asm/linkage.h   |   0
 arch/m68k/include/asm/linkage.h|   0
 arch/microblaze/include/asm/linkage.h  |   0
 arch/mips/include/asm/linkage.h|   0
 arch/nios2/include/asm/linkage.h   |   0
 arch/openrisc/include/asm/linkage.h|   0
 arch/sandbox/include/asm/linkage.h |   0
 arch/sh/include/asm/linkage.h  |   0
 arch/sparc/include/asm/linkage.h   |   0
 arch/x86/Kconfig   |  27 ---
 arch/x86/cpu/baytrail/cpu.c|   1 +
 arch/x86/cpu/broadwell/cpu.c   |   1 +
 arch/x86/cpu/cpu_x86.c |  18 +
 arch/x86/cpu/ivybridge/model_206ax.c   |   1 +
 arch/x86/cpu/u-boot.lds|  36 -
 arch/x86/include/asm/cpu_x86.h |  13 +++
 arch/x86/include/asm/tables.h  |   2 +
 arch/x86/lib/Makefile  |   2 +-
 arch/x86/lib/tables.c  |  21 ++---
 board/xilinx/zynqmp/zynqmp.c   |   5 --
 cmd/bootefi.c  |  14 +++-
 drivers/cpu/cpu-uclass.c   |  10 +++
 include/cpu.h  |  22 ++
 include/efi.h  |   3 +-
 include/efi_api.h  |   4 +
 include/efi_loader.h   |  39 +++--
 {arch/x86/include/asm => include}/smbios.h |   8 +-
 include/tables_csum.h  |  12 +++
 lib/Kconfig|  33 
 lib/Makefile   |   2 +
 lib/efi_loader/Makefile|   1 +
 lib/efi_loader/efi_boottime.c  |  57 +-
 lib/efi_loader/efi_disk.c  |  13 +--
 lib/efi_loader/efi_gop.c   |  16 
 lib/efi_loader/efi_memory.c|  88 ++---
 lib/efi_loader/efi_net.c   |  11 ++-
 lib/efi_loader/efi_runtime.c   | 122 -
 lib/efi_loader/efi_smbios.c|  32 
 {arch/x86/lib => lib}/smbios.c |  82 +--
 lib/tables_csum.c  |  20 +
 44 files changed, 652 insertions(+), 158 deletions(-)
 create mode 100644 

Re: [U-Boot] i2c: mxc: refactor i2c driver and support dm

[Jagan Teki]

On Mon, Oct 17, 2016 at 4:47 PM, Jagan Teki  wrote:
> Hi Peng/all,
>
> Observed an issue while setting the bus on mxc_i2c driver
> addr = dev_get_addr(bus); is getting failed to get invalid address.
>
> Commit details:
> "i2c: mxc: refactor i2c driver and support dm"
> (sha1: 71204e95ce13228a0c742cce137c3238f64581d8)
>
> Log:
> icorem6qdl> i2c bus
> Bus 0:  i2c@021a
> Bus 1:  i2c@021a4000
> icorem6qdl> i2c dev 0
> Setting bus to 0
> cmd_i2c_set_bus_num: Trying bus 0
> mxc_i2c_probe
> 0. mxc_i2c_probe
> dev_get_addr_index: OF_TRANSLATE
> dev_get_addr_index: i2c@021a - 0x
> cmd_i2c_set_bus_num: No bus 0
> Failure changing bus number (-19)

Seen like some issue on my dts or fdt_get_patch (lib/libfdt/fdt_ro.c)
it is returning FDT_ERR_BADSTRUCTURE

U-Boot> dm tree
...
 simple_bus  [ + ]`-- aips-bus@0210
 eth [ + ]  |-- FEC
 mmc [ + ]|-- usdhc@0219
 i2c [   ]   |-- i2c@021a
 i2c [   ]   |-- i2c@021a4000
 i2c [   ]`-- i2c@021a8000

So when I uncomment the "phy-mode" on the dts file [1] I was able to
get the proper i2c addr.
Couldn't find why the phy-mode node as a corrupt block based on
comment from include/libfdt.h about FDT_ERR_BADSTRUCTURE.

Simon, any help?

[1] https://patchwork.ozlabs.org/patch/678825/

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 04/12] arm: socfpga: clkmgr: Separate the Clock Manager for Stratix 10

[Chin Liang See]

On Sel, 2016-10-18 at 06:00 +0200, Marek Vasut wrote:
> On 10/18/2016 05:22 AM, Chin Liang See wrote:
> > 
> > On Sen, 2016-10-17 at 18:14 +0200, Marek Vasut wrote:
> > > 
> > > On 10/17/2016 05:59 PM, Chin Liang See wrote:
> > > > 
> > > > 
> > > > On Sen, 2016-10-17 at 17:39 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 10/17/2016 05:28 PM, Chin Liang See wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sen, 2016-10-17 at 17:20 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/17/2016 05:07 PM, Chin Liang See wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sen, 2016-10-17 at 15:42 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 10/17/2016 03:32 PM, See, Chin Liang wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Min, 2016-10-16 at 17:33 +0200, Marek Vasut
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 10/13/2016 10:33 AM, Chin Liang See wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Separate the Clock Manager to support both GEN5
> > > > > > > > > > > > SoC
> > > > > > > > > > > > and
> > > > > > > > > > > > Stratix 10 SoC.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Chin Liang See  > > > > > > > > > > > >
> > > > > > > > > > > > Cc: Marek Vasut 
> > > > > > > > > > > > Cc: Dinh Nguyen  > > > > > > > > > > > >
> > > > > > > > > > > > Cc: Ley Foon Tan 
> > > > > > > > > > > > Cc: Tien Fong Chee 
> > > > > > > > > > > > ---
> > > > > > > > > > > >  arch/arm/mach-socfpga/clock_manager.c | 8
> > > > > > > > > > > > 
> > > > > > > > > > > >  1 file changed, 8 insertions(+)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/arch/arm/mach-
> > > > > > > > > > > > socfpga/clock_manager.c
> > > > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > > > socfpga/clock_manager.c
> > > > > > > > > > > > index aa71636..0d67b3c 100644
> > > > > > > > > > > > --- a/arch/arm/mach-socfpga/clock_manager.c
> > > > > > > > > > > > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > > > > > > > > > > > @@ -10,6 +10,7 @@
> > > > > > > > > > > > 
> > > > > > > > > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > > > > > 
> > > > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > > > >  static const struct socfpga_clock_manager
> > > > > > > > > > > > *clock_manager_base
> > > > > > > > > > > > =
> > > > > > > > > > > >   (struct socfpga_clock_manager
> > > > > > > > > > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > > > > > > > > > > 
> > > > > > > > > > > > @@ -446,9 +447,11 @@ unsigned int
> > > > > > > > > > > > cm_get_l4_sp_clk_hz(void)
> > > > > > > > > > > > 
> > > > > > > > > > > >   return clock;
> > > > > > > > > > > >  }
> > > > > > > > > > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > > > > > > > > > > 
> > > > > > > > > > > >  unsigned int
> > > > > > > > > > > > cm_get_mmc_controller_clk_hz(void)
> > > > > > > > > > > >  {
> > > > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > > > >   uint32_t reg, clock = 0;
> > > > > > > > > > > > 
> > > > > > > > > > > >   /* identify the source of MMC clock */
> > > > > > > > > > > > @@ -475,8 +478,12 @@ unsigned int
> > > > > > > > > > > > cm_get_mmc_controller_clk_hz(void)
> > > > > > > > > > > >   /* further divide by 4 as we have fixed
> > > > > > > > > > > > divider
> > > > > > > > > > > > at
> > > > > > > > > > > > wrapper */
> > > > > > > > > > > >   clock /= 4;
> > > > > > > > > > > >   return clock;
> > > > > > > > > > > > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > > > > > > > > > > + return 2500;
> > > > > > > > > > > Is this always gonna be the case or is this S10VP
> > > > > > > > > > > specific ?
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > > > > > > > > > >  }
> > > > > > > > > > > > 
> > > > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > > > >  unsigned int
> > > > > > > > > > > > cm_get_qspi_controller_clk_hz(void)
> > > > > > > > > > > >  {
> > > > > > > > > > > >   uint32_t reg, clock = 0;
> > > > > > > > > > > > @@ -556,3 +563,4 @@ U_BOOT_CMD(
> > > > > > > > > > > >   "display clocks",
> > > > > > > > > > > >   ""
> > > > > > > > > > > Why does the clock display not work on S10 

Re: [U-Boot] [PATCH v3 04/12] arm: socfpga: clkmgr: Separate the Clock Manager for Stratix 10

[Chin Liang See]

On Sen, 2016-10-17 at 18:14 +0200, Marek Vasut wrote:
> On 10/17/2016 05:59 PM, Chin Liang See wrote:
> > 
> > On Sen, 2016-10-17 at 17:39 +0200, Marek Vasut wrote:
> > > 
> > > On 10/17/2016 05:28 PM, Chin Liang See wrote:
> > > > 
> > > > 
> > > > On Sen, 2016-10-17 at 17:20 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 10/17/2016 05:07 PM, Chin Liang See wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sen, 2016-10-17 at 15:42 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/17/2016 03:32 PM, See, Chin Liang wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Min, 2016-10-16 at 17:33 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 10/13/2016 10:33 AM, Chin Liang See wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Separate the Clock Manager to support both GEN5 SoC
> > > > > > > > > > and
> > > > > > > > > > Stratix 10 SoC.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Chin Liang See 
> > > > > > > > > > Cc: Marek Vasut 
> > > > > > > > > > Cc: Dinh Nguyen 
> > > > > > > > > > Cc: Ley Foon Tan 
> > > > > > > > > > Cc: Tien Fong Chee 
> > > > > > > > > > ---
> > > > > > > > > >  arch/arm/mach-socfpga/clock_manager.c | 8 
> > > > > > > > > >  1 file changed, 8 insertions(+)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/arch/arm/mach-socfpga/clock_manager.c
> > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > socfpga/clock_manager.c
> > > > > > > > > > index aa71636..0d67b3c 100644
> > > > > > > > > > --- a/arch/arm/mach-socfpga/clock_manager.c
> > > > > > > > > > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > > > > > > > > > @@ -10,6 +10,7 @@
> > > > > > > > > > 
> > > > > > > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > > > 
> > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > >  static const struct socfpga_clock_manager
> > > > > > > > > > *clock_manager_base
> > > > > > > > > > =
> > > > > > > > > >   (struct socfpga_clock_manager
> > > > > > > > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > > > > > > > > 
> > > > > > > > > > @@ -446,9 +447,11 @@ unsigned int
> > > > > > > > > > cm_get_l4_sp_clk_hz(void)
> > > > > > > > > > 
> > > > > > > > > >   return clock;
> > > > > > > > > >  }
> > > > > > > > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > > > > > > > > 
> > > > > > > > > >  unsigned int cm_get_mmc_controller_clk_hz(void)
> > > > > > > > > >  {
> > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > >   uint32_t reg, clock = 0;
> > > > > > > > > > 
> > > > > > > > > >   /* identify the source of MMC clock */
> > > > > > > > > > @@ -475,8 +478,12 @@ unsigned int
> > > > > > > > > > cm_get_mmc_controller_clk_hz(void)
> > > > > > > > > >   /* further divide by 4 as we have fixed
> > > > > > > > > > divider
> > > > > > > > > > at
> > > > > > > > > > wrapper */
> > > > > > > > > >   clock /= 4;
> > > > > > > > > >   return clock;
> > > > > > > > > > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > > > > > > > > + return 2500;
> > > > > > > > > Is this always gonna be the case or is this S10VP
> > > > > > > > > specific ?
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > > > > > > > >  }
> > > > > > > > > > 
> > > > > > > > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > > > > > > >  unsigned int cm_get_qspi_controller_clk_hz(void)
> > > > > > > > > >  {
> > > > > > > > > >   uint32_t reg, clock = 0;
> > > > > > > > > > @@ -556,3 +563,4 @@ U_BOOT_CMD(
> > > > > > > > > >   "display clocks",
> > > > > > > > > >   ""
> > > > > > > > > Why does the clock display not work on S10 ? Are some
> > > > > > > > > functions
> > > > > > > > > missing?
> > > > > > > > Not for SOCVP. But will be added in later stage when
> > > > > > > > testing
> > > > > > > > against
> > > > > > > > emulation
> > > > > > > How hard would it be to add this missing functionality
> > > > > > > now ?
> > > > > > > 
> > > > > > That will take weeks as that need to be validated as whole
> > > > > > in
> > > > > > emulation
> > > > > > platform.
> > > > > You mean printing a few clock information based on some
> > > > > values
> > > > > from
> > > > > registers would take weeks ? Why ?
> > > > > 
> > > > Oh actually I am referring all the managers code such as full
> > > > Clock
> > > > Manager, Reset Manager ... plus testing. Testing is the part
> > > > take
> > > > some
> > > > significant time especially slow when come to emulation.
> > > Just use empty functions for the clock init code (since it's 

Re: [U-Boot] Booting from MMC, other partition

[Jaehoon Chung]

On 10/14/2016 03:45 AM, Robert Ianovich wrote:
> I have a iMX233 with SD as storage and I need to have first partition
> fat32, otherways windows will not open the SD card at all. Customer needs
> to get/save some data from windows.
> 
> So what I did is wrote U-Boot on 2'nd and rootfs on 3'rd.
> 
> Command (m for help): p
> Disk /dev/sdb: 7,4 GiB, 7969177600 bytes, 15564800 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x763f9f2e
> 
> Device Boot   Start  End Sectors  Size Id Type
> /dev/sdb1  2048  8390655 83886084G  c W95 FAT32 (LBA)
> /dev/sdb2  *8390656  8521727  131072   64M 53 OnTrack DM6 Aux3
> /dev/sdb3   8521728 15564799 7043072  3,4G 83 Linux
> 
> U-Boot starts just fine but cannot boot from 3'rd.
> 
> There is a solution for this, do I need to recompile U-Boot.

Do you want to use the 3rd partition as rootfs? Does it jump to kernel?

Best Regards,
Jaehoon Chung

> 
> If so, where should I modify.
> 
> Thanks very much in advance,
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
> 

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

Re: [U-Boot] [PATCH] ARM: zynq: Extend picozed board support

[Oscar Gomez Fuente]

Hi everyone,

It seems to be that the mailbox of the email address
albert.u.b...@aribaud.net is quota exceeded, and all emails are rejected.

-
Final-Recipient: rfc822; albert.u.b...@aribaud.net.rmap1.bookmyname.com
Original-Recipient: rfc822;albert.u.b...@aribaud.net
Action: failed
Status: 5.0.0
Remote-MTA: dns; 127.0.0.1
Diagnostic-Code: smtp; 552 4.2.2
: Mailbox full -- Quota
exceeded
...
-

could anyone inform about that please?

Best regards.


[image: photo] Óscar Gómez Fuente
Electronic Engineer & Degree in Physical Sciences
Mobile: 659.28.97.90
Email: oscargom...@gmail.com
Website: www.oscargomezf.com
  



On 18 October 2016 at 09:00, Michal Simek  wrote:

> On 17.10.2016 17:33, Oscar Gomez Fuente wrote:
> > Ok Michal,
> >
> > Then you're suggesting change the zynq-picozed.dts file to:
>
> dtsi.
>
> >
> > diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.
> dts
> > index 3408df8..d8ed298 100644
> > --- a/arch/arm/dts/zynq-picozed.dts
> > +++ b/arch/arm/dts/zynq-picozed.dts
> > @@ -14,6 +14,8 @@
> >
> > aliases {
> > serial0 = 
> > +   spi0 = 
> > +   ethernet0 = 
> > };
> >
> > memory {
> > @@ -26,3 +28,18 @@
> > u-boot,dm-pre-reloc;
> > status = "okay";
> >  };
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +   status = "okay";
> > +};
>
> keep node names sorted.
>
> > +
> > + {
> > +   status = "okay";
> > +   phy-mode = "rgmii-id";
> > +   phy-handle = <_phy>;
> > +
> > +   ethernet_phy: ethernet-phy@0 {
> > +   reg = <0>;
> > +   };
> > +};
> >
> > And add a new dts file with the configuration of the PizoZed FMC Carrier
> V2
> > (in this case V2. Avnet has two PicoZed FMC carriers V1 and V2). For
> > example: zynq-picozed-fmc-v2.dts
> >
> > *
> >  * Avnet PicoZed FMC carrier V2 DTS
> >  *
> >  * Copyright (C) 2015 Xilinx, Inc.
> >  *
> >  * SPDX-License-Identifier: GPL-2.0+
> >  */
> > /dts-v1/;
>
> Depends how zynq-picozed.dtsi will look but this line above can be
> already there.
>
> > #include "zynq-picozed.dts"
> >
> > / {
> > compatible = "xlnx,zynq-picozed", "xlnx,zynq-7000";
>
> here
> "xlnx,zynq-picozed-fmc-v2", "xlnx,zynq-picozed", "xlnx,zynq-7000";
>
>
> >
> > aliases {
> > mmc0 = 
> > };
> > };
> >
> >  {
> > u-boot,dm-pre-reloc;
> > status = "okay";
> > };
> >
> > Do you think the is the best way?
>
> with changes above it looks reasonable.
>
> Thanks,
> Michal
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2, 5/5] arch/arm, arch/powerpc: enable workaround for eSDHC erratum A009620

[Y.B. Lu]

Hi York,

I have a question about CONFIG option. Are we going to completely using Kconfig 
in the future like kernel?
I just found below compiling error.

=Error log===
./scripts/check-config.sh u-boot.cfg \
./scripts/config_whitelist.txt . 1>&2
Error: You must add new CONFIG options using Kconfig
The following new ad-hoc CONFIG options were detected:
CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620

Please add these via Kconfig instead. Find a suitable Kconfig
file and add a 'config' or 'menuconfig' option.
make: *** [all] Error 1
===

As you know, all CONFIG options of the QorIQ eSDHC driver were defined in 
.h.
Should we convert to use Kconfig for eSDHC driver?

Thanks.


Best regards,
Yangbo Lu

> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Tuesday, August 02, 2016 5:21 PM
> To: u-boot@lists.denx.de
> Cc: york sun; Jaehoon Chung; Yangbo Lu
> Subject: [v2, 5/5] arch/arm, arch/powerpc: enable workaround for eSDHC
> erratum A009620
> 
> This patch is to enable workaround for eSDHC erratum A009620. All the
> affected platforms include PowerPC(P1010/P2020/P5020/P5040/T1024/T1040/
> T2080/T4240) and ARM(LS1021A/LS1043A/LS2080A).
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - Added this patch
>   - Moved definition out of board files
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 ++
>  arch/arm/include/asm/arch-ls102xa/config.h| 1 +
>  arch/powerpc/include/asm/config_mpc85xx.h | 8 
>  3 files changed, 11 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index b0ad4b4..7f31fcd 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -32,6 +32,7 @@
>  #define CONFIG_NUM_DDR_CONTROLLERS   3
>  #define CONFIG_SYS_FSL_HAS_DP_DDR/* Runtime check to confirm */
>  #define CONFIG_SYS_FSL_CLUSTER_CLOCKS{ 1, 1, 4, 4 }
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define  SRDS_MAX_LANES  8
>  #define CONFIG_SYS_FSL_SRDS_1
>  #define CONFIG_SYS_FSL_SRDS_2
> @@ -175,6 +176,7 @@
>  #define CONFIG_SYS_NUM_FM1_DTSEC 7
>  #define CONFIG_SYS_NUM_FM1_10GEC 1
>  #define CONFIG_SYS_FSL_IFC_BANK_COUNT4
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_SYS_FSL_DDR_BE
>  #define CONFIG_SYS_DDR_BLOCK1_SIZE   ((phys_size_t)2 << 30)
>  #define CONFIG_MAX_MEM_MAPPED
>   CONFIG_SYS_DDR_BLOCK1_SIZE
> diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
> b/arch/arm/include/asm/arch-ls102xa/config.h
> index d408fe4..054f05d 100644
> --- a/arch/arm/include/asm/arch-ls102xa/config.h
> +++ b/arch/arm/include/asm/arch-ls102xa/config.h
> @@ -131,6 +131,7 @@
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT  1
>  #define CONFIG_SYS_FSL_ERRATUM_A008378
>  #define CONFIG_SYS_FSL_ERRATUM_A009663
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC1
>  #else
>  #error SoC not defined
> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index 505d355..b3d8fe8 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -148,6 +148,7 @@
>  #define CONFIG_TSECV2
>  #define CONFIG_SYS_FSL_SEC_COMPAT4
>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_NUM_DDR_CONTROLLERS   1
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT  1
>  #define CONFIG_SYS_FSL_IFC_BANK_COUNT4
> @@ -369,6 +370,7 @@
>  #define CONFIG_SYS_CCSRBAR_DEFAULT   0xff70
>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111  #define
> CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_SYS_FSL_SRIO_MAX_PORTS2
>  #define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM   9
>  #define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM   5
> @@ -530,6 +532,7 @@
>  #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
>  #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_SYS_FSL_ERRATUM_USB14
>  #define CONFIG_SYS_FSL_ERRATUM_DDR_A003  #define
> CONFIG_SYS_FSL_ERRATUM_DDR_A003474
> @@ -568,6 +571,7 @@
>  #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
>  #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define CONFIG_SYS_FSL_ERRATUM_USB14
>  #define CONFIG_SYS_FSL_ERRATUM_DDR_A003  #define
> CONFIG_SYS_FSL_ERRATUM_DDR_A003474
> @@ -686,6 +690,7 @@
>  #define CONFIG_SYS_FSL_ERRATUM_A007186
>  #define CONFIG_SYS_FSL_ERRATUM_A006593
>  #define CONFIG_SYS_FSL_ERRATUM_A007798
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
>  #define 

Re: [U-Boot] [ANN] U-Boot v2016.11-rc2 released

[Peter Robinson]

Hi Tom,

> It's release day and v2016.11-rc2 is out.  I've tried to clean up my
> queue a bit, but I think there's still a few things I have outstanding.
> And I know I need to get some changes from Alexander for EFI stuff that
> I've already promised can come in.  But we should also be moving towards
> release.
>
> So I will be picking up some Kconfig related changes and making sure we
> have no (unexplained) binary size changes.
>
> A perhaps less obvious change between -rc1 and -rc2 is that I've added
> test.py running for qemu-ppce500, qemu-x86, vexpress_ca15_tc2,
> vexpres_ca9x5 and integratorap_cm926ejs along with qemu-mips*.
>
> I plan on doing -rc3 on the 31st.
>
> Thanks all!

Not a regression but a heads up there's build issues with openssl 1.1
which recently (since rc1) landed in Fedora 26

  gcc -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic  -o
tools/mkenvimage tools/mkenvimage.o tools/os_support.o
tools/lib/crc32.o
In file included from tools/lib/rsa/rsa-sign.c:1:0:
../tools/../lib/rsa/rsa-sign.c: In function 'rsa_remove':
../tools/../lib/rsa/rsa-sign.c:156:2: warning:
'ERR_remove_thread_state' is deprecated [-Wdeprecated-declarations]
  ERR_remove_thread_state(NULL);
  ^~~
In file included from /usr/include/openssl/opensslconf.h:42:0,
 from /usr/include/openssl/x509_vfy.h:20,
 from /usr/include/openssl/x509.h:309,
 from /usr/include/openssl/pem.h:17,
 from ../tools/../lib/rsa/rsa-sign.c:13,
 from tools/lib/rsa/rsa-sign.c:1:
/usr/include/openssl/err.h:246:1: note: declared here
 DEPRECATEDIN_1_1_0(void ERR_remove_thread_state(void *))
 ^
In file included from tools/lib/rsa/rsa-sign.c:1:0:
../tools/../lib/rsa/rsa-sign.c: In function 'rsa_sign_with_key':
../tools/../lib/rsa/rsa-sign.c:213:2: warning: implicit declaration of
function 'EVP_MD_CTX_cleanup' [-Wimplicit-function-declaration]
  EVP_MD_CTX_cleanup(context);
  ^~
../tools/../lib/rsa/rsa-sign.c: In function 'rsa_get_exponent':
../tools/../lib/rsa/rsa-sign.c:279:21: error: dereferencing pointer to
incomplete type 'RSA {aka struct rsa_st}'
  if (BN_num_bits(key->e) > 64)
 ^~
make[2]: *** [scripts/Makefile.host:116: tools/lib/rsa/rsa-sign.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/builddir/build/BUILD/u-boot-2016.11-rc2/builds'
make[1]: *** [/builddir/build/BUILD/u-boot-2016.11-rc2/Makefile:1230:
tools] Error 2
make: *** [Makefile:150: sub-make] Error 2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Improve indirect write transaction

[Vignesh R]

On Thursday 06 October 2016 04:49 PM, Vignesh R wrote:
> If the write transaction size(write_bytes) is not a multiple of word
> length, then issue word length writes till the we reach the dangling
> bytes. On the final write, issue byte by byte write to complete the
> transaction. This marginally improves write throughput when performing
> random sized writes to the flash.
> 
> Signed-off-by: Vignesh R 
> ---

Gentle ping... Any comments?

> 
> Tested on K2G GP EVM.
> 
>  drivers/spi/cadence_qspi_apb.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index e285d3c1e761..4b891f227243 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -752,10 +752,16 @@ int cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_platdata *plat,
>   while (remaining > 0) {
>   write_bytes = remaining > page_size ? page_size : remaining;
>   /* Handle non-4-byte aligned access to avoid data abort. */
> - if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
> + if ((uintptr_t)txbuf % 4) {
>   writesb(plat->ahbbase, txbuf, write_bytes);
> - else
> + } else {
>   writesl(plat->ahbbase, txbuf, write_bytes >> 2);
> + if (write_bytes % 4) {
> + writesb(plat->ahbbase,
> + txbuf + rounddown(write_bytes, 4),
> + write_bytes % 4);
> + }
> + }
>  
>   ret = wait_for_bit("QSPI", plat->regbase + CQSPI_REG_SDRAMLEVEL,
>  CQSPI_REG_SDRAMLEVEL_WR_MASK <<
> 

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

[U-Boot] Please pull u-boot-x86

[Bin Meng]

Hi Tom,

The following changes since commit d5a815327d2c257fbba108ff46974b1c1d12fd2a:

  Prepare v2016.11-rc2 (2016-10-17 20:09:33 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to f822403f0164be74a5161b65698d0f01f4556234:

  x86: Add implementations of setjmp() and longjmp() (2016-10-18 15:58:50 +0800)


Alexander Graf (1):
  x86: Move table csum into separate header

Simon Glass (1):
  x86: Add implementations of setjmp() and longjmp()

 arch/x86/cpu/Makefile |  2 +-
 arch/x86/cpu/setjmp.S | 61
+
 arch/x86/include/asm/setjmp.h | 24 
 arch/x86/include/asm/tables.h |  2 ++
 arch/x86/lib/tables.c | 12 
 include/tables_csum.h | 22 ++
 6 files changed, 110 insertions(+), 13 deletions(-)
 create mode 100644 arch/x86/cpu/setjmp.S
 create mode 100644 arch/x86/include/asm/setjmp.h
 create mode 100644 include/tables_csum.h

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

Re: [U-Boot] [PATCH] ARM: zynq: Extend picozed board support

[Oscar Gomez Fuente]

Hi everyone,

In my opinion, use the picozed without a carrier board it doesn't make
 sense. You always are going to need a carrier board. Avnet has two models
the PicoZed FMC Carrier V2 and the PicoZed FMC Carrier V1. And the company
I'm working, it is going to desing a custom carrier board according to our
necessity.

So maybe, it's better to have only two .dts files. zynq-picozed-fmc-v2.dts
and zynq-picozed-fmc-v1.dts.

If we decide to have the zynq-picozed.dtsi and zynq-picozed-fmc-v2.dts,
we'll have to decide what hardware description is going to be in the
zynq-picozed-fmc-v2.dts and what hardware description is going to be
in zynq-picozed.dtsi.

for example the spi0 hw is in the picozed  board, but the SD (mmc0), eth0
(gem0) and serial0 (uart1) the HW is in the picoZed but the connectors are
in the PicoZed FMC Carrier V2, so It's a little bit confused if this HW
description has to be on the zynq-picozed.dtsi file or in the
zynq-picozed-fmc-v2.dts file. Do you know what I mean?

Please let me see you opinions about that.

Best regards.

[image: photo] Óscar Gómez Fuente
Electronic Engineer & Degree in Physical Sciences
Mobile: 659.28.97.90
Email: oscargom...@gmail.com
Website: www.oscargomezf.com
  



On 18 October 2016 at 09:00, Michal Simek  wrote:

> On 17.10.2016 17:33, Oscar Gomez Fuente wrote:
> > Ok Michal,
> >
> > Then you're suggesting change the zynq-picozed.dts file to:
>
> dtsi.
>
> >
> > diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.
> dts
> > index 3408df8..d8ed298 100644
> > --- a/arch/arm/dts/zynq-picozed.dts
> > +++ b/arch/arm/dts/zynq-picozed.dts
> > @@ -14,6 +14,8 @@
> >
> > aliases {
> > serial0 = 
> > +   spi0 = 
> > +   ethernet0 = 
> > };
> >
> > memory {
> > @@ -26,3 +28,18 @@
> > u-boot,dm-pre-reloc;
> > status = "okay";
> >  };
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +   status = "okay";
> > +};
>
> keep node names sorted.
>
> > +
> > + {
> > +   status = "okay";
> > +   phy-mode = "rgmii-id";
> > +   phy-handle = <_phy>;
> > +
> > +   ethernet_phy: ethernet-phy@0 {
> > +   reg = <0>;
> > +   };
> > +};
> >
> > And add a new dts file with the configuration of the PizoZed FMC Carrier
> V2
> > (in this case V2. Avnet has two PicoZed FMC carriers V1 and V2). For
> > example: zynq-picozed-fmc-v2.dts
> >
> > *
> >  * Avnet PicoZed FMC carrier V2 DTS
> >  *
> >  * Copyright (C) 2015 Xilinx, Inc.
> >  *
> >  * SPDX-License-Identifier: GPL-2.0+
> >  */
> > /dts-v1/;
>
> Depends how zynq-picozed.dtsi will look but this line above can be
> already there.
>
> > #include "zynq-picozed.dts"
> >
> > / {
> > compatible = "xlnx,zynq-picozed", "xlnx,zynq-7000";
>
> here
> "xlnx,zynq-picozed-fmc-v2", "xlnx,zynq-picozed", "xlnx,zynq-7000";
>
>
> >
> > aliases {
> > mmc0 = 
> > };
> > };
> >
> >  {
> > u-boot,dm-pre-reloc;
> > status = "okay";
> > };
> >
> > Do you think the is the best way?
>
> with changes above it looks reasonable.
>
> Thanks,
> Michal
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] libfdt: Sync overlay with upstream

[Maxime Ripard]

Hi Simon,

On Mon, Oct 17, 2016 at 04:17:33PM -0600, Simon Glass wrote:
> On 17 October 2016 at 14:50, Maxime Ripard
>  wrote:
> > Now that the overlay code has been merge upstream, update our copy to
> > what's been merged, since a significant number of issues have been fixed
> > during the merge process.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/libfdt.h  |  24 --
> >  lib/libfdt/fdt_overlay.c  | 199 
> > +-
> >  lib/libfdt/fdt_strerror.c |   3 +
> >  3 files changed, 147 insertions(+), 79 deletions(-)
> 
> Acked-by: Simon Glass 

Sorry for the dumb question, but shouldn't that go through your tree ?

Thanks,
Maxime

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


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

Re: [U-Boot] [PATCH 0/6] Add ARMv8 PSCI framework

[Hongbo Zhang]

Ping all,
Some time ago I saw several people mentioned ARMv8 PSCI, are you
interested in leaving your review comments?
I know it is not so easy for reviewing assembly language patches, but
code structures and assembly instructions in this patch set are not
complicated.
When this common framework gets merged, it will be possible for each
platform to implement their platform PSCI functions in C too.

Hi Tom,
Any further concerns? comments?

Thanks all.

On Wed, Sep 28, 2016 at 4:27 PM, Hongbo Zhang  wrote:
> I just explained why and how I tried to place newly introduced macros
> in arch/arm/cpu/armv8/Kconfig and  board/freescale/ls1043ardb/Kconfig.
>
> As to the order, is it compulsory to define such a CONFIG_* before
> using it, even there is #ifdef test when using it?
>
> If yes, I have to define all the four new CONFIG_* into
> arch/arm/cpu/armv8/Kconfig along with the adding-secure-sections
> patch, but default values have to be set which is bit hard to handle,
> for the CONFIG_ARMV8_PSCI_NR_CPUS, we can set a 4 although it isn't
> correct in most cases, but for the CONFIG_ARMV8_SECURE_BASE, we don't
> know its default value, it is really platform specific.
>
> In my implementation, I just wanted to treat CONFIG_ARMV8_PSCI_NR_CPUS
> and CONFIG_CPU_PER_CLUSTER as same as CONFIG_ARMV8_SECURE_BASE, since
> they are all platform specific.
>
> And for the CONFIG_ARMV8_PSCI_NR_CPUS, it is slightly different form
> ARMv7's, if not defined, the lds file still works:
> #ifdef CONFIG_ARMV8_PSCI_NR_CPUS
> . = . + CONFIG_ARMV8_PSCI_NR_CPUS * ARM_PSCI_STACK_SIZE;
> #else
> . = . + 4 * ARM_PSCI_STACK_SIZE;
> #endif
>
>
>
> On Wed, Sep 28, 2016 at 3:16 PM, Hongbo Zhang  wrote:
>> On Wed, Sep 28, 2016 at 1:23 AM, Tom Rini  wrote:
>>> On Tue, Sep 27, 2016 at 05:29:00PM +0800, macro.wav...@gmail.com wrote:
 From: Hongbo Zhang 

 This patch set introduces ARMv8 PSCI framework, all the PSCI functions are
 implemented a default dummy one, it is up to each platform to implement 
 their
 own specific ones.

 The first 1/6 patch is a prepare clean up for adding ARMv8 PSCI.
 Patches 2/6 to 5/6 introduce new ARMv8 framework and set it up.
 The last 6/6 adds a most simple implementation on NXP LS1043 platform, to
 verify this framework.

 This patch set mainly introduces ARMv8 PSCI framework, for easier review 
 and
 merge, further PSCI implementation on LS1043 is coming later.

 Hongbo Zhang (6):
   ARMv8: LS1043A: change macro CONFIG_ARMV8_PSCI definition
   ARMv8: Add secure sections for PSCI text and data
   ARMv8: Add basic PSCI framework
   ARMv8: Setup PSCI memory and dt
   ARMv8: Enable SMC instruction
   ARMv8: LS1043A: Enable LS1043A default PSCI support
>>>
>>> Conceptually this is good.  I have some issues around order of the
>>> patches, and where the Kconfig entries end up.  Looking over the series
>>> we introduce usage of some CONFIG symbols prior to declaring them in
>>> Kconfig.  This is more of a hard no now as it will break bisecting when
>>> the test for no new CONFIG symbols is tripped.  The other problem is
>>> that I think the symbols you're adding in
>>> board/freescale/ls1043ardb/Kconfig need to be in
>>> arch/arm/cpu/armv8/Kconfig and then use default ... if ... to give the
>>> right address for the layerscape boards.
>>
>> Thanks Tom for quick response.
>>
>> For config options introduced:
>> CONFIG_ARMV8_PSCI
>> CONFIG_ARMV8_PSCI_NR_CPUS
>> CONFIG_CPU_PER_CLUSTER
>> CONFIG_ARMV8_SECURE_BASE
>>
>> I've tested adding patch one by one, there is no problem with the
>> check-config script.
>>
>> And my idea was like this: let the CONFIG_ARMV8_PSCI to be an overall
>> switch, and if it is enabled even without the other three ones, the
>> default PSCI still works, as I've tested, this really works because
>> any of the other three macros, when used, there is a #ifdef to check
>> if it exists, if no, a default value is used or it isn't used at all.
>> The later three macros, because they are platform specific so I
>> intended to let every platform to define them.
>>
>> This is slightly different from ARMv7, plan was if this get accepted,
>> I would like to send patch to update ARMv7's.
>>
>>>
>>> --
>>> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: zynq: Extend picozed board support

[Michal Simek]

On 17.10.2016 17:33, Oscar Gomez Fuente wrote:
> Ok Michal,
> 
> Then you're suggesting change the zynq-picozed.dts file to:

dtsi.

> 
> diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.dts
> index 3408df8..d8ed298 100644
> --- a/arch/arm/dts/zynq-picozed.dts
> +++ b/arch/arm/dts/zynq-picozed.dts
> @@ -14,6 +14,8 @@
> 
> aliases {
> serial0 = 
> +   spi0 = 
> +   ethernet0 = 
> };
> 
> memory {
> @@ -26,3 +28,18 @@
> u-boot,dm-pre-reloc;
> status = "okay";
>  };
> +
> + {
> +   u-boot,dm-pre-reloc;
> +   status = "okay";
> +};

keep node names sorted.

> +
> + {
> +   status = "okay";
> +   phy-mode = "rgmii-id";
> +   phy-handle = <_phy>;
> +
> +   ethernet_phy: ethernet-phy@0 {
> +   reg = <0>;
> +   };
> +};
> 
> And add a new dts file with the configuration of the PizoZed FMC Carrier V2
> (in this case V2. Avnet has two PicoZed FMC carriers V1 and V2). For
> example: zynq-picozed-fmc-v2.dts
> 
> *
>  * Avnet PicoZed FMC carrier V2 DTS
>  *
>  * Copyright (C) 2015 Xilinx, Inc.
>  *
>  * SPDX-License-Identifier: GPL-2.0+
>  */
> /dts-v1/;

Depends how zynq-picozed.dtsi will look but this line above can be
already there.

> #include "zynq-picozed.dts"
> 
> / {
> compatible = "xlnx,zynq-picozed", "xlnx,zynq-7000";

here
"xlnx,zynq-picozed-fmc-v2", "xlnx,zynq-picozed", "xlnx,zynq-7000";


> 
> aliases {
> mmc0 = 
> };
> };
> 
>  {
> u-boot,dm-pre-reloc;
> status = "okay";
> };
> 
> Do you think the is the best way?

with changes above it looks reasonable.

Thanks,
Michal

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

Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program

[Alexander Graf]

On 10/18/2016 04:29 AM, Simon Glass wrote:

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Include a link to the program instead of adding it to the tree


So, uh, where is the link?

I'm really not convinced this command buys us anything yet. I do agree 
that we want automated testing - but can't we get that using QEMU and a 
downloadable image file that we pass in as disk and have the distro boot 
do its magic?



Alex

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

Re: [U-Boot] [PATCH v3 2/8] efi: Use asmlinkage for EFIAPI

[Alexander Graf]

On 10/18/2016 04:29 AM, Simon Glass wrote:

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 


(Replying here in lack for a cover letter)

Could you please rebase your patches on top of

  https://github.com/agraf/u-boot.git efi-next

so that all the patches that I already queued are not repeated in the 
patch set and we don't get any conflicts?



Thanks!

Alex

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

Re: [U-Boot] efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}

[Alexander Graf]

> Compiler attributes are more commonly __foo style tags rather than big
> upper case eye sores like EFI_RUNTIME_TEXT.
> 
> Simon Glass felt quite strongly about this, so this patch converts our
> existing defines over to more eye friendly ones.
> 
> Signed-off-by: Alexander Graf 
> Reviewed-by: Simon Glass 

Thanks, applied to efi-next
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] zynq: nand: Enable Nand flash controller driver a zynq board

[Michal Simek]

On 27.9.2016 07:25, Siva Durga Prasad Paladugu wrote:
> Enable zynq Nand flash controller driver for a zynq ZC770
> XM011(dc2) board.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
> Changes for v3:
> - None
> Changes for v2:
> - Corrected the from address
> ---
>  configs/zynq_zc770_xm011_defconfig | 2 ++
>  include/configs/zynq-common.h  | 7 +++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/configs/zynq_zc770_xm011_defconfig 
> b/configs/zynq_zc770_xm011_defconfig
> index b841fdc..3ce7114 100644
> --- a/configs/zynq_zc770_xm011_defconfig
> +++ b/configs/zynq_zc770_xm011_defconfig
> @@ -4,6 +4,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm011"
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_FIT_SIGNATURE=y
> +CONFIG_NAND_ZYNQ=y
>  CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011"
>  CONFIG_SYS_NO_FLASH=y
>  CONFIG_SPL=y
> @@ -18,6 +19,7 @@ CONFIG_CMD_DHCP=y
>  CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_CACHE=y
> +CONFIG_CMD_NAND=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_ZYNQ_GEM=y
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index 260df2f..27c02e5 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -76,6 +76,13 @@
>  # define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
>  #endif
>  
> +#ifdef CONFIG_NAND_ZYNQ
> +#define CONFIG_CMD_NAND_LOCK_UNLOCK
> +#define CONFIG_SYS_MAX_NAND_DEVICE   1
> +#define CONFIG_SYS_NAND_ONFI_DETECTION
> +#define CONFIG_MTD_DEVICE
> +#endif
> +
>  /* MMC */
>  #if defined(CONFIG_ZYNQ_SDHCI)
>  # define CONFIG_MMC
> 

Applied both to my tree.

Thanks,
Michal

-- 
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 SoCs





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

Re: [U-Boot] [PATCH] ARM: zynq: Extend picozed board support

[Michal Simek]

On 17.10.2016 23:28, Moritz Fischer wrote:
> Hi Oscar,
> 
> On Mon, Oct 17, 2016 at 5:33 PM, Oscar Gomez Fuente
>  wrote:
>> Ok Michal,
>>
>> Then you're suggesting change the zynq-picozed.dts file to:
> 
> If you're planning to include this into others, make it a .dtsi file.
> 
>>
>> diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.dts
>> index 3408df8..d8ed298 100644
>> --- a/arch/arm/dts/zynq-picozed.dts
>> +++ b/arch/arm/dts/zynq-picozed.dts
>> @@ -14,6 +14,8 @@
>>
>> aliases {
>> serial0 = 
>> +   spi0 = 
>> +   ethernet0 = 
>> };
>>
>> memory {
>> @@ -26,3 +28,18 @@
>> u-boot,dm-pre-reloc;
>> status = "okay";
>>  };
>> +
>> + {
>> +   u-boot,dm-pre-reloc;
>> +   status = "okay";
>> +};
>> +
>> + {
>> +   status = "okay";
>> +   phy-mode = "rgmii-id";
>> +   phy-handle = <_phy>;
>> +
>> +   ethernet_phy: ethernet-phy@0 {
>> +   reg = <0>;
>> +   };
>> +};
>>
>> And add a new dts file with the configuration of the PizoZed FMC Carrier V2
>> (in this case V2. Avnet has two PicoZed FMC carriers V1 and V2). For
>> example: zynq-picozed-fmc-v2.dts
>>
>> *
>>  * Avnet PicoZed FMC carrier V2 DTS
>>  *
>>  * Copyright (C) 2015 Xilinx, Inc.
>>  *
>>  * SPDX-License-Identifier: GPL-2.0+
>>  */
>> /dts-v1/;
>> #include "zynq-picozed.dts"
> 
> should be a .dtsi file then.


If you can't use picozed without carrier board then zynq-picozed should
be dtsi.

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