Re: [U-Boot] [PATCH v2 1/2] drivers; add DM_NO_OF Kconfig option

[Simon Glass]

+Tom

Hi Angelo,

On 27 May 2018 at 01:22, Angelo Dureghello  wrote:
> Hi Simon,
>
> On Sat, May 26, 2018 at 04:18:57PM -0600, Simon Glass wrote:
>> Hi Angelo,
>>
>> On 3 May 2018 at 16:01, Angelo Dureghello  wrote:
>> > To be able to build spi driver with DM support, a new config
>> > option has been introduced (DM_NO_OF) since m68k architecture
>> > does not support fdt.
>> >
>> > ---
>> > Changes from v1:
>> > - split into 2 patches
>> >
>> > Signed-off-by: Angelo Dureghello 
>> > ---
>> >  arch/Kconfig |  1 +
>> >  drivers/core/Kconfig |  4 
>> >  drivers/spi/spi-uclass.c | 12 +++-
>> >  3 files changed, 12 insertions(+), 5 deletions(-)
>> >
>>
>> Is it possible to use SPL_OF_PLATDATA instead?
>>
> I have seen that setting, but my understanding is that
> SPL_OF_PLATDATA ws made for a different purpose, and also, i
> tried to use it, but cannot select it from menuconfig.
>
>> How come m68k cannot use device tree?
>>
> There was never any devicetree implementation, probably becouse it
> is missing on Linux too.

It is a real shame that we can't do better than that.

I've added Tom in for comment as I'm not sure what is best here.

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

Re: [U-Boot] [PATCH 6/6] common: iotrace: fix behaviour when buffer is full

[Simon Glass]

Hi Ramon,

On 27 May 2018 at 02:35, Ramon Fried  wrote:
> On Sun, May 27, 2018 at 1:18 AM, Simon Glass  wrote:
>> Hi Ramon,
>>
>> On 26 May 2018 at 00:05, Ramon Fried  wrote:
>>> On Sat, May 26, 2018 at 5:07 AM, Simon Glass  wrote:
 Hi Ramon,

 On 25 May 2018 at 04:41, Ramon Fried  wrote:
> When the buffer is full, there supposed to be no more
> writes, the code however misses the else statement and
> subsequently writes to arbitrary pointer location and increases
> the offset.

 I don't think so. It writes to a local variable in this case. The
 point of this is to detect how much space would be needed to hold the
 I/O trace. Unless the pointer is incremented, there is no way to know.
>>> You're right. I missed the initial assignment to rec.
>>>

 Perhaps instead, iotrace_get_buffer() should be updated to also return
 the number of valid records, as well as the pointer value?

>>> It's a valid option, another one I have in mind is that
>>> we can return immediately like I suggested but add one time warning
>>> that states that the
>>> buffer is full ?
>>
>> The problem is that people want to be able to resize the buffer so
>> that they can try again, so they need to know the correct size.
>>
>> Can you make it report that it overflowed, and print the correct size?
> The correct size can only be printed in the end of the tracing.
> Maybe we can use WARN_ONCE when it first occurs and later when the user
> type "iotrace stats" it will state the required buffer size to
> accommodate all of the
> entries.
> What do you think ?

Sounds good to me.

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

Re: [U-Boot] [PATCH v2] patman: add option for limiting the Cc list

[Simon Glass]

On 27 May 2018 at 03:52, Chris Packham  wrote:
> Many mailing-lists consider a long Cc list a sign of spam and will
> either drop the message or mark it for moderation. Because patman
> automatically invokes get_maintainer.pl the Cc list can expand
> unexpectedly. Allow the user to specify a limit for the Cc list.
>
> This limit is applied after removing any known bouncing addresses. By
> default no limit is applied.
>
> Signed-off-by: Chris Packham 
> ---
> I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not
> sure what the actual limit is so I've left patman's default behaviour
> unlimited.
>
> Changes in v2:
> - make default None to allow limit 0 to suppress the list completely
>
>  tools/patman/patman.py | 4 +++-
>  tools/patman/series.py | 5 -
>  2 files changed, 7 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 1/1] efi_loader: efi_allocate_pages is too restrictive

[Heinrich Schuchardt]

On 03/12/2018 11:48 AM, Alexander Graf wrote:
> On 03/09/2018 05:35 PM, Heinrich Schuchardt wrote:
>> On 03/09/2018 05:19 PM, Alexander Graf wrote:
>>> On 03/09/2018 04:58 PM, Heinrich Schuchardt wrote:
 On 03/09/2018 01:48 PM, Alexander Graf wrote:
> On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
>> When running on the sandbox the stack is not necessarily at a higher
>> memory
>> address than the highest free memory.
>>
>> There is no reason why the checking of the highest memory address
>> should be
>> more restrictive for EFI_ALLOCATE_ANY_PAGES than for
>> EFI_ALLOCATE_MAX_ADDRESS.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>     lib/efi_loader/efi_memory.c | 2 +-
>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/efi_memory.c
>> b/lib/efi_loader/efi_memory.c
>> index cc271e0709d..0efbb973231 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -294,7 +294,7 @@ efi_status_t efi_allocate_pages(int type, int
>> memory_type,
>>     switch (type) {
>>     case EFI_ALLOCATE_ANY_PAGES:
>>     /* Any page */
>> -    addr = efi_find_free_memory(len, gd->start_addr_sp);
>> +    addr = efi_find_free_memory(len, (uint64_t)-1);
> This will break on systems that do not map high address space into the
> linear map (IIRC nvidia systems had that issue).
>
 The memory map is also passed on to the operating system when booting.
 If a memory reservation is missing for any board it has to be fixed in
 the board or driver files, cf.

 sunxi: video: mark framebuffer as EFI reserved memory
 https://lists.denx.de/pipermail/u-boot/2018-March/321820.htm

 For type = EFI_ALLOCATE_MAX_ADDRESS we don't care about
 gd->start_addr_sp. So if the memory map is incomplete the current code
 may fail. Keeping things as they are is not a viable option.

 Could you, please, identify for which Nvidia system a problem was
 reported? Then we can add a call to efi_add_memory_map() for the board.
>>> Git blame points to this commit. I guess -1 should do the same thing
>>> then, true.
>>>
>>> Andreas, would you see any reason -1 will not work?
>> Are we talking about this line:
>>
>> arch/arm/mach-tegra/board2.c:317:
>> gd->pci_ram_top = gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size;
> 
> pci_ram_top != ram_top, no? :)
> 
> I'd rather assume it's this one:
> 
> /*
>  * Most hardware on 64-bit Tegra is still restricted to DMA to the lower
>  * 32-bits of the physical address space. Cap the maximum usable RAM area
>  * at 4 GiB to avoid DMA buffers from being allocated beyond the 32-bit
>  * boundary that most devices can address. Also, don't let U-Boot use any
>  * carve-out, as mentioned above.
>  *
>  * This function is called before dram_init_banksize(), so we can't simply
>  * return gd->bd->bi_dram[1].start + gd->bd->bi_dram[1].size.
>  */
> ulong board_get_usable_ram_top(ulong total_size)
> {
>     return CONFIG_SYS_SDRAM_BASE + usable_ram_size_below_4g();
> }
> 
> But the real problem is that ram_top of 0 is perfectly valid for 32bit
> systems.

But where is the problem? If ram_top == 0 on a 32bit system
efi_memory_init() will create a memory map for the high memory reaching
from start_addr_sp - uboot_stack_size to 0x
marked as EFI_LOADER_DATA.

So efi_allocate_pages will never touch that memory even if we start our
search at 0x.

And on a 32 bit system we will not have any memory map beyond 0x.

So essentially in this case the patch does not lead to a different
outcome of the search for free pages.

Best regards

Heinrich

> 
> Also ram_top may be used by platforms (like tegra again) to ensure that
> we don't use addresses >32bit for DMA. I guess the real solution to that
> would be to enable bounce buffers for tegra though. But we should make
> sure we don't regress tegra support, so we need to enable bounce buffers
> first for tegra and then allow the allocation to walk the full address
> space.
> 
> 
> Alex
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

Re: [U-Boot] [U-Boot, v4, 09/32] tpm: prepare introduction of TPMv2.x support in Kconfig

[Miquel Raynal]

Hi Tom,

On Sat, 26 May 2018 11:54:29 -0400, Tom Rini  wrote:

> On Tue, May 15, 2018 at 11:57:05AM +0200, Miquel Raynal wrote:
> 
> > Because both major revisions are not compatible at all, let's make them
> > mutually exclusive in Kconfig. This way we will be sure, when using a
> > command or a library function that it is supported by the right
> > revision.
> > 
> > Current drivers are currently prefixed by "tpm_", we will prefix TPMv2.x
> > files by "tpm2_" to make the distinction without moving everything.
> > 
> > The Kconfig menu about TPM drivers is now divided into two sections, one
> > for each specification. Compliant drivers with one specification will
> > only show up if this specification _only_ has been selected, otherwise a
> > comment is displayed.
> > 
> > Once a driver is selected by the user, it selects automatically a
> > boolean value, that is needed in order to activate the TPM commands.
> > Selecting the TPM commands will automatically select the right
> > command/library files.
> > 
> > Signed-off-by: Miquel Raynal 
> > Reviewed-by: Simon Glass 
> > Reviewed-by: Tom Rini   
> 
> There was a thinko in here that I noticed when building for everything,
> that I have fixed.  Both TPM_V1 and TPM_V2 need to depend on TPM (which
> comes from lib/Kconfig) otherwise we would start building TPMv1 support
> for all platforms.  I also ended up dropping out TPM_DRIVER_SELECTED and
> instead making CMD_TPM depend on TPM_V1 || TPM_V2 as that ended up being
> a cleaner way to deal with the gdsys boards with TPM but without a
> dedicated driver exactly.  With that fixed:
> 
> Applied to u-boot/master, thanks!
> 

Ok, thanks for the update.

Nice to see all that series merged!

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

Re: [U-Boot] env: mmc: Fix misaligned buffer address when saving envvars to FAT

[Tom Rini]

On Thu, May 17, 2018 at 01:19:41PM +0530, Vipul Kumar wrote:

> From: Gary Mussar 
> 
> When doing a u-boot saveenv with the environment in FAT we see the
> following warning:
> 
> ZynqMP> saveenv
> Saving Environment to FAT...
> writing uboot.env
> FAT: Misaligned buffer address (7deb9b60)
> done
> 
> This can be eliminated by aligning the environment to an appropriate
> boundary.
> 
> Signed-off-by: Gary Mussar 
> Signed-off-by: Vipul Kumar 
> ---
>  include/environment.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> --
> 2.7.4
> 
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> 
> diff --git a/include/environment.h b/include/environment.h
> index 50c62c5..d6c530d 100644
> --- a/include/environment.h
> +++ b/include/environment.h
> @@ -150,7 +150,11 @@ typedef struct environment_s {
> unsigned char   flags;  /* active/obsolete flags*/
>  #endif
> unsigned char   data[ENV_SIZE]; /* Environment data */
> -} env_t;
> +} env_t
> +#ifdef ARCH_DMA_MINALIGN
> +__aligned(ARCH_DMA_MINALIGN)
> +#endif
> +;
> 
>  #ifdef ENV_IS_EMBEDDED
>  extern env_t environment;

This needs some more work.  The first problem is that ARCH_DMA_MINALIGN
is defined for all platforms.  But it might not be defined in all uses,
for example M5485BFE and other cases of embedded in the binary
environment.  And if we drop the check for ARCH_DMA_MINALIGN existing we
run into problems with needing to add __align to include/compiler.h.

My guess is that what we should do here is that we have another case in
env/fat.c (there's already one) where a variable needs to be __aligned
properly instead.  Can you look down that path?  Thanks!

-- 
Tom


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

[U-Boot] [PATCH 1/1] efi_loader: avoid make race condition

[Heinrich Schuchardt]

When building .efi targets a race condition was observed:

If %_efi.so is not yet built before trying to build %.efi and error
*** No rule to make target '%.efi'
occurs. By explicitly adding %_efi.so to the targets this is avoided.

Reported-by: Tuomas Tynkkynen 
Signed-off-by: Heinrich Schuchardt 
---
Hello Tuomas,

please, test if this resolves your problem.

Best regards

Heinrich
---
 lib/efi_loader/Makefile   | 4 +++-
 lib/efi_selftest/Makefile | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e36d26..d31393c7a28 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -10,7 +10,9 @@ CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI) -Os
 
 ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
-always += helloworld.efi
+always-y += \
+helloworld_efi.so \
+helloworld.efi
 endif
 
 obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 4fe404d88d8..2aeaa2e0f66 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -52,6 +52,8 @@ efi_selftest_startimage_return.o
 targets += \
 efi_miniapp_file_image_exit.h \
 efi_miniapp_file_image_return.h \
+efi_selftest_miniapp_exit_efi.so \
+efi_selftest_miniapp_return_efi.so \
 efi_selftest_miniapp_exit.efi \
 efi_selftest_miniapp_return.efi
 
-- 
2.17.0

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

Re: [U-Boot] [PATCH v1] rockchip: utilize CONFIG_DEFAULT_FDT_FILE

[klaus . goger]

> On 27.05.2018, at 21:16, Vagrant Cascadian  wrote:
> 
> On 2018-05-25, Klaus Goger wrote:
>> Currently the fdtfile environment variable is set to
>> CONFIG_DEFAULT_DEVICE_TREE which is іnternally used as U-Boot devicetree
>> source. The OS can use a different filename and Kconfig gives us the
>> ability to select a default devicetree via CONFIG_DEFAULT_FDT_FILE.
>> This also gives user configuring U-Boot via menuconfig the behaviour
>> someone would expect.
> 
> I did wonder, given that many of these boards the value for
> CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE is *nearly*
> identical, if it wouldn't make sense to derive CONFIG_DEFAULT_FDT_FILE
> From the value of CONFIG_DEFAULT_DEVICE_TREE by default, only overriding
> it in the unusual cases.
> 
> Though there is a lot to be said about being explicit and not mixing the
> two similar but not identical values.

Would love to to that, but couldn’t find a proper way to do it.
CONFIG_DEFAULT_FDT_FILE is a Kconfig string and therefore always present in the 
.config.
If not set by the user or a defconfig it’s just a empty string (“”). So we 
can’t do a #ifdef and we can’t
do string compares with C macros. An option would be to have DEFAULT_FDT_FILE 
be hidden
behind a Kconfig bool (i.e CONFIG_DEFAULT_FDT_FILE depends on CONFIG_FDT_FILE)
But that change looked a bit to invasive for me.

> Tested on puma-rk3399.
> 
> Tested-By: Vagrant Cascadian 
> 
> Was hoping to also test on firefly-rk3399, but having difficulty getting
> u-boot installed unreleated to this patch. Also having troubles with
> firefly-rk3288 due to mmc hanging the board: https://bugs.debian.org/898520.
> 
> 
> live well,
>  vagrant
> 
>> configs/puma-rk3399_defconfig   | 1 +
>> include/configs/rk3399_common.h | 2 +-
> 
>> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
>> index e6539a7da8..e5753b4f20 100644
>> --- a/configs/puma-rk3399_defconfig
>> +++ b/configs/puma-rk3399_defconfig
>> @@ -16,6 +16,7 @@ CONFIG_DEBUG_UART=y
>> CONFIG_FIT=y
>> CONFIG_SPL_LOAD_FIT=y
>> CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
>> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
>> # CONFIG_DISPLAY_CPUINFO is not set
>> CONFIG_DISPLAY_BOARDINFO_LATE=y
>> CONFIG_SPL_BOARD_INIT=y
> 
>> diff --git a/include/configs/rk3399_common.h 
>> b/include/configs/rk3399_common.h
>> index a61e74bc03..ee38107ea5 100644
>> --- a/include/configs/rk3399_common.h
>> +++ b/include/configs/rk3399_common.h
>> @@ -55,7 +55,7 @@
>> #include 
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>>  ENV_MEM_LAYOUT_SETTINGS \
>> -"fdtfile=rockchip/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>> +"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
>>  "partitions=" PARTS_DEFAULT \
>>  BOOTENV
>> 
>> --
>> 2.11.0



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

Re: [U-Boot] [PATCH v1] rockchip: utilize CONFIG_DEFAULT_FDT_FILE

[Vagrant Cascadian]

On 2018-05-25, Klaus Goger wrote:
> Currently the fdtfile environment variable is set to
> CONFIG_DEFAULT_DEVICE_TREE which is іnternally used as U-Boot devicetree
> source. The OS can use a different filename and Kconfig gives us the
> ability to select a default devicetree via CONFIG_DEFAULT_FDT_FILE.
> This also gives user configuring U-Boot via menuconfig the behaviour
> someone would expect.

I did wonder, given that many of these boards the value for
CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE is *nearly*
identical, if it wouldn't make sense to derive CONFIG_DEFAULT_FDT_FILE
From the value of CONFIG_DEFAULT_DEVICE_TREE by default, only overriding
it in the unusual cases.

Though there is a lot to be said about being explicit and not mixing the
two similar but not identical values.

Tested on puma-rk3399.

Tested-By: Vagrant Cascadian 

Was hoping to also test on firefly-rk3399, but having difficulty getting
u-boot installed unreleated to this patch. Also having troubles with
firefly-rk3288 due to mmc hanging the board: https://bugs.debian.org/898520.


live well,
  vagrant

>  configs/puma-rk3399_defconfig   | 1 +
>  include/configs/rk3399_common.h | 2 +-

> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
> index e6539a7da8..e5753b4f20 100644
> --- a/configs/puma-rk3399_defconfig
> +++ b/configs/puma-rk3399_defconfig
> @@ -16,6 +16,7 @@ CONFIG_DEBUG_UART=y
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_BOARD_INIT=y

> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index a61e74bc03..ee38107ea5 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -55,7 +55,7 @@
>  #include 
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   ENV_MEM_LAYOUT_SETTINGS \
> - "fdtfile=rockchip/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
>   "partitions=" PARTS_DEFAULT \
>   BOOTENV
>  
> -- 
> 2.11.0


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

Re: [U-Boot] [PATCH v2 1/2] sunxi-mmc: use new mode on A64

[Jagan Teki]

On Mon, May 14, 2018 at 8:57 PM, Vasily Khoruzhick  wrote:
> That is necessary for using automatic calibration on A64 eMMC.
>
> Signed-off-by: Vasily khoruzhick 
> ---
>  arch/arm/mach-sunxi/Kconfig | 1 +
>  drivers/mmc/sunxi_mmc.c | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index f0c9d1b058..376380e977 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -256,6 +256,7 @@ config MACH_SUN50I
> select SUNXI_DE2
> select SUNXI_GEN_SUN6I
> select SUNXI_HIGH_SRAM
> +   select MMC_SUNXI_HAS_NEW_MODE
> select SUPPORT_SPL
> select SUNXI_DRAM_DW
> select SUNXI_DRAM_DW_32BIT
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index fe6d82c7b4..65d88ee921 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -165,7 +165,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
> }
>
> if (new_mode) {
> -#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
> +#if defined(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && !defined(CONFIG_MACH_SUN50I)
> val = CCM_MMC_CTRL_MODE_SEL_NEW;

This is breaking eMMC boot on A64

U-Boot SPL 2018.05-00431-gf4fcaa5f15 (May 27 2018 - 23:59:42 +0530)
DRAM: 1024 MiB
Trying to boot from MMC2
unable to select a mode
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Initialization of TI AM335x MII connected to Marvell's 88e6341 switch

[Avner Flesch]

Hi,


I have costume board based on Beagle Bone Black board except the networking -

instead of Ethernet PHY, we put a Marvell switch 88e6341 (The CPU port 
connected with MII).

So, I need the u-boot source modification for it

If someone can point me to a reference or send me the files, I will really 
appreciate it


Thanks


Avner

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

Re: [U-Boot] Parallel make issue with helloworld.efi

[Tuomas Tynkkynen]

Hi Heinrich,

Thanks for taking a look.

On 05/27/2018 08:11 PM, Heinrich Schuchardt wrote:

On 11/07/2017 04:57 PM, Tuomas Tynkkynen wrote:

Hi,

Every now and then I see parallel builds failing, e.g. with
Linksprite_pcDuino3_Nano_defconfig:

   CC  lib/efi_loader/efi_bootmgr.o
   CC  lib/efi_loader/efi_disk.o
   CC  lib/efi_loader/efi_net.o
make[2]: *** No rule to make target 'lib/efi_loader/helloworld.efi',
needed by '__build'.  Stop.
make[2]: *** Waiting for unfinished jobs
   CC  lib/efi_loader/efi_smbios.o
make[1]: *** [scripts/Makefile.build:425: lib/efi_loader] Error 2
make: *** [Makefile:1279: lib] Error 2

This has been going for a while now (since ~2017.03 or so).
Anybody have ideas on how to express the dependency properly?


Hello Tuomas,

the build dependencies for *.efi files are described in
./scripts/Makefile.lib:

EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)

cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
 -Bsymbolic $^ -o $@

$(obj)/%_efi.so: $(obj)/%.o arch/$(ARCH)/lib/$(EFI_CRT0) \
 arch/$(ARCH)/lib/$(EFI_RELOC)
 $(call cmd,efi_ld)

$(obj)/%.efi: $(obj)/%_efi.so
 $(call cmd,efi_objcopy)


Right, but...


The target is selected in lib/efi_loader/Makefile:

ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
always += helloworld.efi
endif



... as I've described in

https://lists.denx.de/pipermail/u-boot/2018-March/323624.html

, the problem is that when recursive make is building lib/efi_loader,
arch/$(ARCH)/lib/$(EFI_CRT0) might not exist yet and the rule for building
it is only known by the recursive make responsible for building
arch/arm/lib.


obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtim

Does the problem ever occur if you run mrproper beforehand?



It doesn't matter if it's a clean or incremental build. By increasing
the race window with this hacky patch (the ':=' -> '=' change is important):

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 655727f431..fb569f57f2 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -99,10 +99,10 @@ endif
 endif

 # For building EFI apps
-CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
+CFLAGS_$(EFI_CRT0) = $(CFLAGS_EFI) $(shell echo sleeping >&2 && sleep 60)
 CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI)

-CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI)
+CFLAGS_$(EFI_RELOC) = $(CFLAGS_EFI) $(shell echo sleeping >&2 && sleep 60)
 CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI)

 extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC)


and running:

export CROSS_COMPILE=arm-linux-gnueabihf-
rm -rf build-qemu_arm
make O=build-qemu_arm qemu_arm_defconfig
make O=build-qemu_arm all -j4

... I can reproduce the problem 100% of the time, even in incremental builds.
For example:

$ make O=build-qemu_arm all -j4 V=1

make -C /home/tmtynkky/opt/u-boot/build-qemu_arm 
KBUILD_SRC=/home/tmtynkky/opt/u-boot \
-f /home/tmtynkky/opt/u-boot/Makefile all
make[1]: Entering directory '/home/tmtynkky/opt/u-boot/build-qemu_arm'
set -e; : '  CHK include/config/uboot.release'; mkdir -p include/config/;   echo 
"2018.05$(/bin/sh ../scripts/setlocalversion ..)" < include/config/auto.conf > 
include/config/uboot.release.tmp; if [ -r include/config/uboot.release ] && cmp -s 
include/config/uboot.release include/config/uboot.release.tmp; then rm -f 
include/config/uboot.release.tmp; else : '  UPD include/config/uboot.release'; mv -f 
include/config/uboot.release.tmp include/config/uboot.release; fi
ln -fsn .. source
set -e; : '  CHK include/generated/timestamp_autogenerated.h'; mkdir -p include/generated/; (if test -n "${SOURCE_DATE_EPOCH}"; then SOURCE_DATE="@${SOURCE_DATE_EPOCH}"; DATE=""; for date in gdate date.gnu date; do ${date} -u -d "${SOURCE_DATE}" 
>/dev/null 2>&1 && DATE="${date}"; done; if test -n "${DATE}"; then LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; LC_ALL=C 
${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; else return 42; fi; else LC_ALL=C 
date +'#define U_BOOT_DATE "%b %d %C%y"'; LC_ALL=C date +'#define U_BOOT_TIME "%T"'; LC_ALL=C date +'#define U_BOOT_TZ "%z"'; LC_ALL=C date +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; LC_ALL=C date +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; fi) < ../Makefile > 
include/generated/timestamp_autogenerated.h.tmp; if [ -r include/generated/timestamp_autogenerated.h ] && cmp -s include/generated/timestamp_autogenerated.h include/generated/timestamp_autogenerated.h.tmp; then rm -f include/generated/timestamp_autogenerated.h.tmp; else : '  UPD 
include/generated/timestamp_autogenerated.h'; mv -f include/generated/timestamp_autogenerated.h.tmp 

[U-Boot] [PATCH 1/1] Remove snapshot.commit

[Heinrich Schuchardt]

The file is not referenced anywhere.
To display a change log we have the 'git log' command.

Signed-off-by: Heinrich Schuchardt 
---
 snapshot.commit | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 snapshot.commit

diff --git a/snapshot.commit b/snapshot.commit
deleted file mode 100644
index 8d263096dd0..000
--- a/snapshot.commit
+++ /dev/null
@@ -1 +0,0 @@
-$Format:%H  %cD$
-- 
2.17.0

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

Re: [U-Boot] Parallel make issue with helloworld.efi

[Heinrich Schuchardt]

On 11/07/2017 04:57 PM, Tuomas Tynkkynen wrote:
> Hi,
> 
> Every now and then I see parallel builds failing, e.g. with
> Linksprite_pcDuino3_Nano_defconfig:
> 
>   CC  lib/efi_loader/efi_bootmgr.o
>   CC  lib/efi_loader/efi_disk.o
>   CC  lib/efi_loader/efi_net.o
> make[2]: *** No rule to make target 'lib/efi_loader/helloworld.efi',
> needed by '__build'.  Stop.
> make[2]: *** Waiting for unfinished jobs
>   CC  lib/efi_loader/efi_smbios.o
> make[1]: *** [scripts/Makefile.build:425: lib/efi_loader] Error 2
> make: *** [Makefile:1279: lib] Error 2
> 
> This has been going for a while now (since ~2017.03 or so).
> Anybody have ideas on how to express the dependency properly?

Hello Tuomas,

the build dependencies for *.efi files are described in
./scripts/Makefile.lib:

EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)

cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
-Bsymbolic $^ -o $@

$(obj)/%_efi.so: $(obj)/%.o arch/$(ARCH)/lib/$(EFI_CRT0) \
arch/$(ARCH)/lib/$(EFI_RELOC)
$(call cmd,efi_ld)

$(obj)/%.efi: $(obj)/%_efi.so
$(call cmd,efi_objcopy)

The target is selected in lib/efi_loader/Makefile:

ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
always += helloworld.efi
endif

obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtim

Does the problem ever occur if you run mrproper beforehand?

To allow analyzing your problem, please, run make with parameter V=1,
provide the command line you used, the value of $CROSS_COMPILE, the
.config file, and the complete output of make.

Further provide the output of
find . -exec ls {} -la --time-style=full-iso \;

Best regards

Heinrich

> 
> Thanks!
> - Tuomas
> 

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

[U-Boot] [PATCH v2 3/3] efi_selftest: test writing to file

[Heinrich Schuchardt]

Provide a unit test for writing to a FAT file system.
Add some additional comments in block device unit test.

Signed-off-by: Heinrich Schuchardt 
---
v2
Avoid use after free due to calling root->close(root) too often.
---
 lib/efi_selftest/efi_selftest_block_device.c | 66 
 1 file changed, 66 insertions(+)

diff --git a/lib/efi_selftest/efi_selftest_block_device.c 
b/lib/efi_selftest/efi_selftest_block_device.c
index 4af8bd8cb28..6c655a94647 100644
--- a/lib/efi_selftest/efi_selftest_block_device.c
+++ b/lib/efi_selftest/efi_selftest_block_device.c
@@ -309,11 +309,14 @@ static int execute(void)
efi_uintn_t buf_size;
char buf[16] __aligned(ARCH_DMA_MINALIGN);
 
+   /* Connect controller to virtual disk */
ret = boottime->connect_controller(disk_handle, NULL, NULL, 1);
if (ret != EFI_SUCCESS) {
efi_st_error("Failed to connect controller\n");
return EFI_ST_FAILURE;
}
+
+   /* Get the handle for the partition */
ret = boottime->locate_handle_buffer(
BY_PROTOCOL, _device_path, NULL,
_handles, );
@@ -347,6 +350,8 @@ static int execute(void)
efi_st_error("Partition handle not found\n");
return EFI_ST_FAILURE;
}
+
+   /* Open the simple file system protocol */
ret = boottime->open_protocol(handle_partition,
  _simple_file_system_protocol,
  (void **)_system, NULL, NULL,
@@ -355,6 +360,8 @@ static int execute(void)
efi_st_error("Failed to open simple file system protocol\n");
return EFI_ST_FAILURE;
}
+
+   /* Open volume */
ret = file_system->open_volume(file_system, );
if (ret != EFI_SUCCESS) {
efi_st_error("Failed to open volume\n");
@@ -377,6 +384,8 @@ static int execute(void)
"Wrong volume label '%ps', expected 'U-BOOT TEST'\n",
system_info.info.volume_label);
}
+
+   /* Read file */
ret = root->open(root, , (s16 *)L"hello.txt", EFI_FILE_MODE_READ,
 0);
if (ret != EFI_SUCCESS) {
@@ -389,6 +398,11 @@ static int execute(void)
efi_st_error("Failed to read file\n");
return EFI_ST_FAILURE;
}
+   if (buf_size != 13) {
+   efi_st_error("Wrong number of bytes read: %u\n",
+(unsigned int)buf_size);
+   return EFI_ST_FAILURE;
+   }
if (efi_st_memcmp(buf, "Hello world!", 12)) {
efi_st_error("Unexpected file content\n");
return EFI_ST_FAILURE;
@@ -398,6 +412,58 @@ static int execute(void)
efi_st_error("Failed to close file\n");
return EFI_ST_FAILURE;
}
+
+   /* Write file */
+   ret = root->open(root, , (s16 *)L"u-boot.txt",
+EFI_FILE_MODE_WRITE | EFI_FILE_MODE_CREATE, 0);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to open file\n");
+   return EFI_ST_FAILURE;
+   }
+   buf_size = 7;
+   boottime->set_mem(buf, sizeof(buf), 0);
+   boottime->copy_mem(buf, "U-Boot", buf_size);
+   ret = file->write(file, _size, buf);
+   if (ret != EFI_SUCCESS || buf_size != 7) {
+   efi_st_error("Failed to write file\n");
+   return EFI_ST_FAILURE;
+   }
+   ret = file->close(file);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to close file\n");
+   return EFI_ST_FAILURE;
+   }
+
+   /* Verify file */
+   boottime->set_mem(buf, sizeof(buf), 0);
+   ret = root->open(root, , (s16 *)L"u-boot.txt", EFI_FILE_MODE_READ,
+0);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to open file\n");
+   return EFI_ST_FAILURE;
+   }
+   buf_size = sizeof(buf) - 1;
+   ret = file->read(file, _size, buf);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to read file\n");
+   return EFI_ST_FAILURE;
+   }
+   if (buf_size != 7) {
+   efi_st_error("Wrong number of bytes read: %u\n",
+(unsigned int)buf_size);
+   return EFI_ST_FAILURE;
+   }
+   if (efi_st_memcmp(buf, "U-Boot", 7)) {
+   efi_st_error("Unexpected file content %s\n", buf);
+   return EFI_ST_FAILURE;
+   }
+   ret = file->close(file);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to close file\n");
+   return EFI_ST_FAILURE;
+   }
+
+   /* Close volume */
ret = root->close(root);
if (ret != EFI_SUCCESS) {
efi_st_error("Failed to close volume\n");
-- 
2.17.0

[U-Boot] [PATCH v2 1/3] fs: fat: cannot write to subdirectories

[Heinrich Schuchardt]

fs_fat_write() is not able to write to subdirectories.

Currently if a filepath with a leading slash is passed, the slash is
treated as part of the filename to be created in the root directory.

Strip leading (back-)slashes.

Check that the remaining filename does not contain any illegal characters
(<>:"/\|?*). This way we will throw an error when trying to write to a
subdirectory.

Signed-off-by: Heinrich Schuchardt 
---
v2:
use ISDIRDELIM() to identify (back-)slashes
---
 fs/fat/fat_write.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 5ca8fcda73c..c5aee519b79 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -908,9 +908,11 @@ static int do_fat_write(const char *filename, void 
*buffer, loff_t size,
volume_info volinfo;
fsdata datablock;
fsdata *mydata = 
-   int cursect;
+   int cursect, i;
int ret = -1, name_len;
char l_filename[VFAT_MAXLEN_BYTES];
+   char bad[2] = " ";
+   const char illegal[] = "<>:\"/\\|?*";
 
*actwrite = size;
dir_curclust = 0;
@@ -970,6 +972,18 @@ static int do_fat_write(const char *filename, void 
*buffer, loff_t size,
}
dentptr = (dir_entry *) do_fat_read_at_block;
 
+   /* Strip leading (back-)slashes */
+   while ISDIRDELIM(*filename)
+   ++filename;
+   /* Check that the filename is valid */
+   for (i = 0; i < strlen(illegal); ++i) {
+   *bad = illegal[i];
+   if (strstr(filename, bad)) {
+   printf("FAT: illegal filename (%s)\n", filename);
+   return -1;
+   }
+   }
+
name_len = strlen(filename);
if (name_len >= VFAT_MAXLEN_BYTES)
name_len = VFAT_MAXLEN_BYTES - 1;
-- 
2.17.0

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

[U-Boot] [PATCH v2 2/3] efi_selftest: imply FAT, FAT_WRITE

[Heinrich Schuchardt]

efi_selftest_block_device accesses a FAT file system.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/efi_selftest/Kconfig b/lib/efi_selftest/Kconfig
index 3b5f3a1230b..59f9f36801c 100644
--- a/lib/efi_selftest/Kconfig
+++ b/lib/efi_selftest/Kconfig
@@ -1,6 +1,8 @@
 config CMD_BOOTEFI_SELFTEST
bool "Allow booting an EFI efi_selftest"
depends on CMD_BOOTEFI
+   imply FAT
+   imply FAT_WRITE
help
  This adds an EFI test application to U-Boot that can be executed
  with the 'bootefi selftest' command. It provides extended tests of
-- 
2.17.0

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

[U-Boot] [PATCH v2 0/3] efi_loader: allow writing to FAT

[Heinrich Schuchardt]

Running the UEFI Self-Certifcation Test (SCT) will require to support
writing to a FAT file system.

Writing to the FAT root directory from EFI fails because the leading
slash of the file path is interpreted as part of the filename.

With the 1st patch we can write to the root directory.

A unit test for writing a new file to the FAT root directory is supplied.

v2
Avoid use after free due to calline root->close(root) too often.
Use ISDIRDELIM() to identify (back-)slashes.

Heinrich Schuchardt (3):
  fs: fat: cannot write to subdirectories
  efi_selftest: imply FAT, FAT_WRITE
  efi_selftest: test writing to file

 fs/fat/fat_write.c   | 16 -
 lib/efi_selftest/Kconfig |  2 +
 lib/efi_selftest/efi_selftest_block_device.c | 66 
 3 files changed, 83 insertions(+), 1 deletion(-)

-- 
2.17.0

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

[U-Boot] [PATCH] mvebu: a38x: Force receiver detected on PCIe lanes

[Baruch Siach]

From: Rabeeh Khoury 

Some QCA988x based modules presence is not detected by the SERDES lanes,
so force this detection which will trigger the LTSSM state machine to
negotiate link.

An example of such a card is WLE900VX.

Signed-off-by: Rabeeh Khoury 
Signed-off-by: Baruch Siach 
---
 arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 2 ++
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 13553cf96008..33e70569bc48 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -597,6 +597,8 @@ struct op_params pex_electrical_config_serdes_rev2_params[] 
= {
{LANE_CFG4_REG, 0x800, 0x8, {0x8}, 0, 0},
/* tximpcal_th and rximpcal_th */
{VTHIMPCAL_CTRL_REG, 0x800, 0xff00, {0x3000}, 0, 0},
+   /* Force receiver detected */
+   {LANE_CFG0_REG, 0x800, 0x8000, {0x8000}, 0, 0},
 };
 
 /* PEX - configuration seq for REF_CLOCK_25MHz */
diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
index 953445b7d7ae..50b235826659 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
@@ -71,6 +71,7 @@
 #define RX_REG30xa0188
 #define PCIE_REG1  0xa0288
 #define PCIE_REG3  0xa0290
+#define LANE_CFG0_REG  0xa0600
 #define LANE_CFG1_REG  0xa0604
 #define LANE_CFG4_REG  0xa0620
 #define LANE_CFG5_REG  0xa0624
-- 
2.17.0

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

[U-Boot] [PATCH] arm: mvebu: move i2c slave disable to generic SPL code

[Baruch Siach]

The hidden i2c slave that interferes the i2c bus is not board specific.
All Armada 38x SoCs are affected. Move the code disabling this slave to
generic code to make it work on all affected hardware.

Cc: Marek Behún 
Cc: Rabeeh Khoury 
Signed-off-by: Baruch Siach 
---
 arch/arm/mach-mvebu/spl.c| 16 
 board/CZ.NIC/turris_omnia/turris_omnia.c |  9 -
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 50b24f5760b7..cbd900fee5d1 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -8,10 +8,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#define MVTWSI_ARMADA_DEBUG_REG0x8c
+
 static u32 get_boot_device(void)
 {
u32 val;
@@ -69,10 +72,23 @@ u32 spl_boot_device(void)
return get_boot_device();
 }
 
+static void disable_i2c_slave(void)
+{
+   u32 i2c_debug_reg;
+
+   /* Disable I2C debug mode blocking 0x64 I2C address */
+   i2c_debug_reg = readl(MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
+   i2c_debug_reg &= ~BIT(18);
+   writel(i2c_debug_reg, MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
+}
+
 void board_init_f(ulong dummy)
 {
int ret;
 
+   if (IS_ENABLED(CONFIG_ARMADA_38X))
+   disable_i2c_slave();
+
/*
 * Pin muxing needs to be done before UART output, since
 * on A38x the UART pins need some re-muxing for output
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index da663cf1bb0c..044c959d1b13 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -50,8 +50,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define OMNIA_ATSHA204_OTP_MAC03
 #define OMNIA_ATSHA204_OTP_MAC14
 
-#define MVTWSI_ARMADA_DEBUG_REG0x8c
-
 /*
  * Those values and defines are taken from the Marvell U-Boot version
  * "u-boot-2013.01-2014_T3.0"
@@ -297,8 +295,6 @@ static int set_regdomain(void)
 
 int board_early_init_f(void)
 {
-   u32 i2c_debug_reg;
-
/* Configure MPP */
writel(0x, MVEBU_MPP_BASE + 0x00);
writel(0x, MVEBU_MPP_BASE + 0x04);
@@ -321,11 +317,6 @@ int board_early_init_f(void)
writel(OMNIA_GPP_OUT_ENA_LOW, MVEBU_GPIO0_BASE + 0x04);
writel(OMNIA_GPP_OUT_ENA_MID, MVEBU_GPIO1_BASE + 0x04);
 
-   /* Disable I2C debug mode blocking 0x64 I2C address */
-   i2c_debug_reg = readl(MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
-   i2c_debug_reg &= ~(1<<18);
-   writel(i2c_debug_reg, MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
-
return 0;
 }
 
-- 
2.17.0

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

[U-Boot] [PATCH 1/1] efi_loader: create handles from normal memory

[Heinrich Schuchardt]

Handles are not used at runtime. They are freed by the firmware when the
last protocol interface is uninstalled. So there is no reason to use EFI
memory when creating handles.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index b7ab2e8208e..50d311548e2 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -431,16 +431,15 @@ void efi_add_handle(struct efi_object *obj)
 efi_status_t efi_create_handle(efi_handle_t *handle)
 {
struct efi_object *obj;
-   efi_status_t r;
 
-   r = efi_allocate_pool(EFI_ALLOCATE_ANY_PAGES,
- sizeof(struct efi_object),
- (void **));
-   if (r != EFI_SUCCESS)
-   return r;
+   obj = calloc(1, sizeof(struct efi_object));
+   if (!obj)
+   return EFI_OUT_OF_RESOURCES;
+
efi_add_handle(obj);
*handle = obj->handle;
-   return r;
+
+   return EFI_SUCCESS;
 }
 
 /**
-- 
2.17.0

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

[U-Boot] [PATCH 1/1] efi_loader: efi_mem_carve_out should return s64

[Heinrich Schuchardt]

efi_mem_carve_out() is used to remove memory pages from a mapping.
As the number of pages to be removed is a 64bit type the return type
should be 64bit too.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_memory.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 4ea25c03053..d5b5fc16070 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -68,23 +68,27 @@ static void efi_mem_sort(void)
list_sort(NULL, _mem, efi_mem_cmp);
 }
 
-/*
- * Unmaps all memory occupied by the carve_desc region from the
- * list entry pointed to by map.
+/** efi_mem_carve_out - unmap memory region
+ *
+ * @map:   memory map
+ * @carve_desc:memory region to unmap
+ * @overlap_only_ram:  the carved out region may only overlap RAM
+ * Return Value:   the number of overlapping pages which have been
+ * removed from the map,
+ * EFI_CARVE_NO_OVERLAP, if the regions don't overlap,
+ * EFI_CARVE_OVERLAPS_NONRAM, if the carve and map overlap,
+ * and the map contains anything but free ram
+ * (only when overlap_only_ram is true),
+ * EFI_CARVE_LOOP_AGAIN, if the mapping list should be
+ * traversed again, as it has been altered.
  *
- * Returns EFI_CARVE_NO_OVERLAP if the regions don't overlap.
- * Returns EFI_CARVE_OVERLAPS_NONRAM if the carve and map overlap,
- *and the map contains anything but free ram.
- *(only when overlap_only_ram is true)
- * Returns EFI_CARVE_LOOP_AGAIN if the mapping list should be traversed
- *again, as it has been altered
- * Returns the number of overlapping pages. The pages are removed from
- * the mapping list.
+ * Unmaps all memory occupied by the carve_desc region from the list entry
+ * pointed to by map.
  *
  * In case of EFI_CARVE_OVERLAPS_NONRAM it is the callers responsibility
- * to readd the already carved out pages to the mapping.
+ * to re-add the already carved out pages to the mapping.
  */
-static int efi_mem_carve_out(struct efi_mem_list *map,
+static s64 efi_mem_carve_out(struct efi_mem_list *map,
 struct efi_mem_desc *carve_desc,
 bool overlap_only_ram)
 {
@@ -183,7 +187,7 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages, 
int memory_type,
carve_again = false;
list_for_each(lhandle, _mem) {
struct efi_mem_list *lmem;
-   int r;
+   s64 r;
 
lmem = list_entry(lhandle, struct efi_mem_list, link);
r = efi_mem_carve_out(lmem, >desc,
-- 
2.17.0

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

Re: [U-Boot] RFC: Alternative boot_jump_linux() function

[Nicolas Dechesne]

Ramon, Tom,

On Sat, May 26, 2018 at 7:58 AM, Ramon Fried  wrote:

> On Sat, May 26, 2018 at 5:18 AM, Tom Rini  wrote:
> > On Fri, May 25, 2018 at 05:41:31PM +0300, Ramon Fried wrote:
> >> On Fri, May 25, 2018 at 3:11 PM, Tom Rini  wrote:
> >> > On Thu, May 17, 2018 at 07:48:45PM +0300, Ramon Fried wrote:
> >> >> On Thu, May 17, 2018 at 5:22 PM, Tom Rini 
> wrote:
> >> >> > On Thu, May 17, 2018 at 02:01:55PM +0300, Ramon Fried wrote:
> >> >> >
> >> >> >> Hi.
> >> >> >> I'm currently working on snapdragon bootloader support and in the
> >> >> >> particular case where U-boot is running in Aarch32 and the kernel
> is
> >> >> >> Aarch64 the specific implementation is to jump to Linux through
> SCM
> >> >> >> call.
> >> >> >>
> >> >> >> I try to find the best possible way to provide an alternative
> boot function.
> >> >> >> Adding #ifdef ARCH_SNAPDRAGON will just be too specific in
> >> >> >> arm/lib/bootm.c in my opinion and I'm thinking of introducing
> kind of
> >> >> >> a callback function in gd. that if exists will jump there instead
> of
> >> >> >> executing boot_jump_linux().
> >> >> >>
> >> >> >> What do you think ?
> >> >> >
> >> >> > So, to be clear, we're on an aarch64 SoC, but U-Boot has been
> entered in
> >> >> > 32bit mode.  And we need to boot a 64bit Linux Kernel.  What else,
> if
> >> >> > anything, is also loaded/still in residence/etc?  Can you explain
> the
> >> >> > overall usecase a bit more and why we're in 32bit mode?  Thanks!
> >> >> >
> >> >> OK.
> >> >> Basically, Qualcomm has the following boot flow:
> >> >>
> >> >> PBL -> SBL -> LK -> Linux Kernel
> >> >>
> >> >> PBL - 32bit Primary boot loader(ROM) loads the SBL from eMMC.
> >> >>
> >> >> SBL - 32bit Secondary boot loader(eMMC/UFS), proprietary closed
> source,
> >> >> Initializes the DDR, starts the trustzone and can load either a 32bit
> >> >> or a 64bit (1)
> >> >> ELF bootloader, given that it's signed.
> >> >>
> >> >> LK - Little kernel, 32bit. Qualcomm maintains a downstream version,
> open source.
> >> >> Loads 64bit Android boot image from eMMC and jumps to it using SMC
> >> >> call made to Trustzone.
> >> >>
> >> >> This was used primarily for Android, but when Dragonboards boards
> came
> >> >> out, Qualcomm and Linaro started
> >> >> distributing 64bit Linux OE & Debian builds that were booted by LK.
> >> >> Because U-boot is much more useful than LK, the first U-boot
> >> >> contribution was made by Mateusz Kulikowski.
> >> >>
> >> >> Basically, Mateusz port is wrapping U-boot to appear as a kernel so
> LK
> >> >> boots it, then it boots Linux.
> >> >> So basically, LK did the 32 -> 64 transition.
> >> >>
> >> >> Now, here where I appear in the story... :)
> >> >
> >> > Thanks for the detailed background.
> >> >
> >> >> I'm trying to get rid of LK and use U-boot as the real bootloader
> for Linux.
> >> >> I succeeded in that, and I have all the patches ready for submission,
> >> >> I just need to add a dedicated boot function
> >> >> that does the SMC call, hence this discussion.
> >> >>
> >> >> (1) - It implies that we can in practice just use 64bit U-boot for
> Snapdragon.
> >> >> The only problem I have right now is that there's isn't any
> >> >> open-source tool to sign the Bootloader that supports ELF64
> >> >> executable.
> >> >
> >> > Is it possible to just write that tool, or update an existing tool to
> do
> >> > that signature?
> >> Yes. It should be possible.
> >>
> >> Actually, when I did have access to qcom internal tool for doing so I
> >> was able to run U-boot
> >> on 64bit mode. I had problems booting the kernel, as after the boot
> >> weird things were happening,
> >> like other cpu weren't responding, eMMC driver wasn't working etc.
> >> I suspect it's related to low level initialization that was lacking,
> >> or something similar.
> >>
> >> I ended up working on the 32bit mode because I no longer have access
> >> to the internal tool.
> >> I believe that in the end we will end up with a working 64bit version.
> >> I'm just thinking that meanwhile It maybe worthwhile to also have the
> >> 32bit version.
> >>
> >> What do you think ?
> >
> > How long might we be in this interim odd spot?  It sounds like we need
> > some odd hoops to go and be able to boot a 64bit Linux when we're in
> > 32bit mode.  If this is just for a short period of time, maybe we just
> > accept that the Linaro tree will have to hold a patch or two for now
> > until we can just be a good and clean 64bit binary?
>
> I added Nicolas from Linaro to the thread so he can comment regarding
> the signing tool.
>

thanks Ramon, for the very good and information data above!


>
> I agree with you that the jump through SCM call is very specific.
> I didn't send any of the 32bit patches yet, I was waiting to see if
> the required supported
> changes will get accepted.
> It's up to you to decide if you're willing to accept that as in
> intermediate solution 

[U-Boot] [PATCH v2] patman: add option for limiting the Cc list

[Chris Packham]

Many mailing-lists consider a long Cc list a sign of spam and will
either drop the message or mark it for moderation. Because patman
automatically invokes get_maintainer.pl the Cc list can expand
unexpectedly. Allow the user to specify a limit for the Cc list.

This limit is applied after removing any known bouncing addresses. By
default no limit is applied.

Signed-off-by: Chris Packham 
---
I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not
sure what the actual limit is so I've left patman's default behaviour
unlimited.

Changes in v2:
- make default None to allow limit 0 to suppress the list completely

 tools/patman/patman.py | 4 +++-
 tools/patman/series.py | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 8d2c78235a7e..e01510df9c0f 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -38,6 +38,8 @@ parser.add_option('-i', '--ignore-errors', 
action='store_true',
 parser.add_option('-m', '--no-maintainers', action='store_false',
dest='add_maintainers', default=True,
help="Don't cc the file maintainers automatically")
+parser.add_option('-l', '--limit-cc', dest='limit', type='int',
+   default=None, help='Limit the cc list to LIMIT entries [default: 
%default]')
 parser.add_option('-n', '--dry-run', action='store_true', dest='dry_run',
default=False, help="Do a dry run (create but don't email patches)")
 parser.add_option('-p', '--project', default=project.DetectProject(),
@@ -157,7 +159,7 @@ else:
 
 cc_file = series.MakeCcFile(options.process_tags, cover_fname,
 not options.ignore_bad_tags,
-options.add_maintainers)
+options.add_maintainers, options.limit)
 
 # Email the patches out (giving the user time to check / cancel)
 cmd = ''
diff --git a/tools/patman/series.py b/tools/patman/series.py
index d526d4ee91d3..2735afaf88fe 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -202,7 +202,7 @@ class Series(dict):
 print(col.Color(col.RED, str))
 
 def MakeCcFile(self, process_tags, cover_fname, raise_on_error,
-   add_maintainers):
+   add_maintainers, limit):
 """Make a cc file for us to use for per-commit Cc automation
 
 Also stores in self._generated_cc to make ShowActions() faster.
@@ -215,6 +215,7 @@ class Series(dict):
 add_maintainers: Either:
 True/False to call the get_maintainers to CC maintainers
 List of maintainers to include (for testing)
+limit: Limit the length of the Cc list
 Return:
 Filename of temp file created
 """
@@ -238,6 +239,8 @@ class Series(dict):
 print(col.Color(col.YELLOW, 'Skipping "%s"' % x))
 cc = set(cc) - set(settings.bounces)
 cc = [m.encode('utf-8') if type(m) != str else m for m in cc]
+if limit is not None:
+cc = cc[:limit]
 all_ccs += cc
 print(commit.patch, ', '.join(set(cc)), file=fd)
 self._generated_cc[commit.patch] = cc
-- 
2.17.0

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

Re: [U-Boot] [PATCH] patman: add option for limiting the Cc list

[Chris Packham]

On Sun, 27 May 2018, 12:53 PM Simon Glass,  wrote:

> Hi Chris,
>
> On 26 May 2018 at 17:10, Chris Packham  wrote:
> > Many mailing-lists consider a long Cc list a sign of spam and will
> > either drop the message or mark it for moderation. Because patman
> > automatically invokes get_maintainer.pl the Cc list can expand
> > unexpectedly. Allow the user to specify a limit for the Cc list.
> >
> > This limit is applied after removing any known bouncing addresses. By
> > default no limit is applied.
> >
> > Signed-off-by: Chris Packham 
> > ---
> > I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not
> > sure what the actual limit is so I've left patman's default behaviour
> > unlimited.
> >
> >  tools/patman/patman.py | 4 +++-
> >  tools/patman/series.py | 4 +++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/patman/patman.py b/tools/patman/patman.py
> > index 8d2c78235a7e..7dd7a1c7b61a 100755
> > --- a/tools/patman/patman.py
> > +++ b/tools/patman/patman.py
> > @@ -38,6 +38,8 @@ parser.add_option('-i', '--ignore-errors',
> action='store_true',
> >  parser.add_option('-m', '--no-maintainers', action='store_false',
> > dest='add_maintainers', default=True,
> > help="Don't cc the file maintainers automatically")
> > +parser.add_option('-l', '--limit-cc', dest='limit', type='int',
> > +   default=0, help='Limit the cc list to LIMIT entries [default:
> %default]')
>
> Could we have a default of None? If that works then I think it would
> be preferable, so that 0 means no CC.
>

That would make -m the same as -l 0. But regardless None is a better fit
for unset.


> >  parser.add_option('-n', '--dry-run', action='store_true',
> dest='dry_run',
> > default=False, help="Do a dry run (create but don't email
> patches)")
> >  parser.add_option('-p', '--project', default=project.DetectProject(),
> > @@ -157,7 +159,7 @@ else:
> >
> >  cc_file = series.MakeCcFile(options.process_tags, cover_fname,
> >  not options.ignore_bad_tags,
> > -options.add_maintainers)
> > +options.add_maintainers, options.limit)
> >
> >  # Email the patches out (giving the user time to check / cancel)
> >  cmd = ''
> > diff --git a/tools/patman/series.py b/tools/patman/series.py
> > index d526d4ee91d3..2066b97e73ff 100644
> > --- a/tools/patman/series.py
> > +++ b/tools/patman/series.py
> > @@ -202,7 +202,7 @@ class Series(dict):
> >  print(col.Color(col.RED, str))
> >
> >  def MakeCcFile(self, process_tags, cover_fname, raise_on_error,
> > -   add_maintainers):
> > +   add_maintainers, limit=0):
>
> Please add an arg comment for limit
>

Will do. Also since there is only one caller of this which passes limit
should I make this non-optional.


> >  """Make a cc file for us to use for per-commit Cc automation
> >
> >  Also stores in self._generated_cc to make ShowActions() faster.
> > @@ -238,6 +238,8 @@ class Series(dict):
> >  print(col.Color(col.YELLOW, 'Skipping "%s"' % x))
> >  cc = set(cc) - set(settings.bounces)
> >  cc = [m.encode('utf-8') if type(m) != str else m for m in
> cc]
> > +if limit > 0:
> > +cc = cc[:limit]
> >  all_ccs += cc
> >  print(commit.patch, ', '.join(set(cc)), file=fd)
> >  self._generated_cc[commit.patch] = cc
> > --
> > 2.17.0
> >
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] common: iotrace: fix behaviour when buffer is full

[Ramon Fried]

On Sun, May 27, 2018 at 1:18 AM, Simon Glass  wrote:
> Hi Ramon,
>
> On 26 May 2018 at 00:05, Ramon Fried  wrote:
>> On Sat, May 26, 2018 at 5:07 AM, Simon Glass  wrote:
>>> Hi Ramon,
>>>
>>> On 25 May 2018 at 04:41, Ramon Fried  wrote:
 When the buffer is full, there supposed to be no more
 writes, the code however misses the else statement and
 subsequently writes to arbitrary pointer location and increases
 the offset.
>>>
>>> I don't think so. It writes to a local variable in this case. The
>>> point of this is to detect how much space would be needed to hold the
>>> I/O trace. Unless the pointer is incremented, there is no way to know.
>> You're right. I missed the initial assignment to rec.
>>
>>>
>>> Perhaps instead, iotrace_get_buffer() should be updated to also return
>>> the number of valid records, as well as the pointer value?
>>>
>> It's a valid option, another one I have in mind is that
>> we can return immediately like I suggested but add one time warning
>> that states that the
>> buffer is full ?
>
> The problem is that people want to be able to resize the buffer so
> that they can try again, so they need to know the correct size.
>
> Can you make it report that it overflowed, and print the correct size?
The correct size can only be printed in the end of the tracing.
Maybe we can use WARN_ONCE when it first occurs and later when the user
type "iotrace stats" it will state the required buffer size to
accommodate all of the
entries.
What do you think ?
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] drivers; add DM_NO_OF Kconfig option

[Angelo Dureghello]

Hi Simon,

On Sat, May 26, 2018 at 04:18:57PM -0600, Simon Glass wrote:
> Hi Angelo,
> 
> On 3 May 2018 at 16:01, Angelo Dureghello  wrote:
> > To be able to build spi driver with DM support, a new config
> > option has been introduced (DM_NO_OF) since m68k architecture
> > does not support fdt.
> >
> > ---
> > Changes from v1:
> > - split into 2 patches
> >
> > Signed-off-by: Angelo Dureghello 
> > ---
> >  arch/Kconfig |  1 +
> >  drivers/core/Kconfig |  4 
> >  drivers/spi/spi-uclass.c | 12 +++-
> >  3 files changed, 12 insertions(+), 5 deletions(-)
> >
> 
> Is it possible to use SPL_OF_PLATDATA instead?
>
I have seen that setting, but my understanding is that
SPL_OF_PLATDATA ws made for a different purpose, and also, i
tried to use it, but cannot select it from menuconfig.
 
> How come m68k cannot use device tree?
> 
There was never any devicetree implementation, probably becouse it
is missing on Linux too. 

> Regards,
> Simon

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