[PATCH 1/1] Update maintainer for Versatile Express.

2024-05-24 Thread Kristian Amlie 
Signed-off-by: Kristian Amlie 
---
 board/armltd/vexpress/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/armltd/vexpress/MAINTAINERS 
b/board/armltd/vexpress/MAINTAINERS
index 2b3e4916a5..7a54c6b560 100644
--- a/board/armltd/vexpress/MAINTAINERS
+++ b/board/armltd/vexpress/MAINTAINERS
@@ -1,5 +1,5 @@
 VERSATILE EXPRESS BOARDS
-M: Kristian Amlie 
+M: Josef Holzmayr 
 S: Maintained
 F: board/armltd/vexpress/
 F: include/configs/vexpress_ca9x4.h
-- 
2.34.1

Re: [PATCH v1] vexpress_ca9x4: Enable DM_SERIAL

2024-01-29 Thread Kristian Amlie 

On 29/01/2024 12:41, Ole Orhagen wrote:



On Fri, Jan 26, 2024 at 8:57 PM Linus Walleij > wrote:


On Fri, Jan 26, 2024 at 1:48 PM Ole P. Orhagen
 wrote:

 > This commit enables support for DM_SERIAL in the vexpress_ca9x4
boards.
 >
 > When running the board with the DM_SERIAL driver, the board ran
out of
 > memory in SPL when initialising the DM serial driver.
 >
 > Thus this required an increase in the pre-allocated SRAM memory.
I did
 > increase it to 0x800, and it now works graciously.
 >
 > It could probably be set lower, but I do not see any reason not
to use the
 > available SRAM at this point.
 >
 > Also adds stdout-path to the 'chosen' node in the device tree.
 >
 > Signed-off-by: Ole P. Orhagen 

Nice!
Reviewed-by: Linus Walleij mailto:linus.wall...@linaro.org>>

Are you using the actual hardware, or QEMU?


I only have QEMU available, unfortunately.


Just providing some context, since I'm listed as maintainer: This board 
was going to be removed some time ago, but was resurrected specifically 
to work with QEMU. The "virt" board, at least at that time, did not 
support some key ARM features that we need in our testing, such as SD 
cards and Flash. Hence we opted to keep this board around. So 
compatibility with hardware is not important to us at least, unless 
someone else is requesting it.


--
Kristian


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: vexpress and DM_SERIAL

2024-01-03 Thread Kristian Amlie 

On 27/12/2023 08:55, Simon Glass wrote:

Hi Kristian,

Do you think it would be possible to migrate the vexpress_ca9x4 board
to use DM_SERIAL?


Yes! This has taken the backseat for a while due to other priorities, 
but it's back near the top of our backlog now. Our goal is to have this 
solved in the first quarter.


--
*Kristian Amlie*
Software Engineer | Mender <https://mender.io>
Oslo, Norway
<https://www.linkedin.com/company/northern.tech><https://twitter.com/northerntechhq><https://northern.tech>
Northern.tech <https://northern.tech> | Securing the world's connected
devices




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ARM: vexpress_ca9x4: Add missing flash width config option

2023-09-21 Thread Kristian Amlie 

On 20/09/2023 09:41, Patryk Biel wrote:

Allow for a proper configuration of CFI flash banks avaialble on the 
vexpress_ca9x4
board. Without this option, the CFI flash incorrectly detects that the board 
has two
banks of 32MB flash devices, while in reality, the board provides
two flash banks, each with 64MB size. As a result, it becomes impossible to 
e.g. to
save u-boot env in flash. According to device tree for this board and
its implementation in QEMU, the CFI width should be set to 32 bits.

After applying this fix, CFI flash will correctly detect both flash
banks each with a size of 64MB. As as result the functionality of e.g. saving 
u-boot
env will work correctly.

Tested on QEMU 6.2.0.

Cc: Kristian Amlie 
Signed-off-by: Patryk Biel 
---
  configs/vexpress_ca9x4_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index 5cacecc7cb..ac9c0e1d71 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -55,3 +55,4 @@ CONFIG_SMC911X_32_BIT=y
  CONFIG_BAUDRATE=38400
  CONFIG_CONS_INDEX=0
  CONFIG_SYS_TIMER_COUNTS_DOWN=y
+CONFIG_SYS_FLASH_CFI_WIDTH_32BIT=y


Reviewed-by: Kristian Amlie 

I believe this should be fine.

This is probably a recent issue, since we are using the 64MB banks 
already in our test setup, and it's working. But it's based on v2022.01, 
so it's a bit older.


--
Kristian


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/2] Kconfig: Change SYS_MALLOC_F_LEN default to 0x2000

2022-04-13 Thread Kristian Amlie 

For vexpress_ca9x4_defconfig:

Reviewed-by: Kristian Amlie 

--
Kristian


On 07/04/2022 18:33, Tom Rini wrote:

The most commonly used value today is 0x2000 and not 0x400.  Rework the
Kconfig logic to use this more frequently used value as the default.

Cc: Andrew F. Davis 
Cc: Alex Nemirovsky 
Cc: Alexey Brodkin 
Cc: Alison Wang 
Cc: Anastasiia Lukianenko 
Cc: Andes 
Cc: Andre Przywara 
Cc: Bharat Gooty 
Cc: David Lechner 
Cc: Dzmitry Sankouski 
Cc: Enric Balletbo i Serra 
Cc: Eugeniy Paltsev 
Cc: Fabio Estevam 
Cc: Gerald Kerma 
Cc: Gregory CLEMENT 
Cc: Holger Brunck 
Cc: Jaehoon Chung 
Cc: Jassi Brar 
Cc: Kristian Amlie 
Cc: Krzysztof Kozlowski 
Cc: Liviu Dudau 
Cc: Luka Perkov 
Cc: Lukasz Majewski 
Cc: Marek Vasut 
Cc: Masami Hiramatsu 
Cc: Matthias Brugger 
Cc: Max Filippov 
Cc: Michael Walle 
Cc: Michal Simek 
Cc: Minkyu Kang 
Cc: Nikita Kiryanov 
Cc: Nobuhiro Iwamatsu 
Cc: Oleksandr Andrushchenko 
Cc: Otavio Salvador 
Cc: Patrice Chotard 
Cc: Paul Burton 
Cc: Paul Kocialkowski 
Cc: Priyanka Jain 
Cc: Rajesh Bhagat 
Cc: Rayagonda Kokatanur 
Cc: Sergey Temerkhanov 
Cc: Simon Glass 
Cc: Stefan Bosch 
Cc: Stephan Gerhold 
Cc: Tetsuyuki Kobayashi 
Cc: Thomas Chou 
Cc: Thomas Fitzsimmons 
Cc: Thomas Weber 
Cc: Tony Dinh 
Cc: Trevor Woerner 
Cc: Vitaly Andrianov 
Cc: Vladimir Zapolskiy 
Cc: liuhao 
Cc: lixinde 
Cc: shuyiqi 
Cc: weichangzheng 
Signed-off-by: Tom Rini 
---
To make this patch more reviewable, I've omitted the defconfigs where
the in-use value is now the default value.  I've cc'd so many
maintainers however as a frequent issue when enabling more DM migrations
is SYS_MALLOC_F_LEN being too small and 0x400 not being enough and
something like 0x2000 being more reasonable, especially on platforms
that can otherwise easily handle a little more memory usage.
---
  Kconfig   | 9 +++--
  configs/10m50_defconfig   | 1 +
  configs/3c120_defconfig   | 1 +
  configs/a3y17lte_defconfig| 1 +
  configs/a5y17lte_defconfig| 1 +
  configs/a7y17lte_defconfig| 1 +
  configs/adp-ae3xx_defconfig   | 1 +
  configs/adp-ag101p_defconfig  | 1 +
  configs/am43xx_evm_qspiboot_defconfig | 1 +
  configs/armadillo-800eva_defconfig| 1 +
  configs/arndale_defconfig | 1 +
  configs/axs101_defconfig  | 1 +
  configs/axs103_defconfig  | 1 +
  configs/bcm7260_defconfig | 1 +
  configs/bcm7445_defconfig | 1 +
  configs/bcm_ns3_defconfig | 1 +
  configs/boston32r2_defconfig  | 1 +
  configs/boston32r2el_defconfig| 1 +
  configs/boston32r6_defconfig  | 1 +
  configs/boston32r6el_defconfig| 1 +
  configs/boston64r2_defconfig  | 1 +
  configs/boston64r2el_defconfig| 1 +
  configs/boston64r6_defconfig  | 1 +
  configs/boston64r6el_defconfig| 1 +
  configs/cm_t43_defconfig  | 1 +
  configs/cortina_presidio-asic-base_defconfig  | 1 +
  configs/cortina_presidio-asic-emmc_defconfig  | 1 +
  configs/cortina_presidio-asic-pnand_defconfig | 1 +
  configs/devkit3250_defconfig  | 1 +
  configs/devkit8000_defconfig  | 1 +
  configs/durian_defconfig  | 1 +
  configs/ea-lpc3250devkitv2_defconfig  | 1 +
  configs/emsdp_defconfig   | 1 +
  configs/grpeach_defconfig | 1 +
  configs/gurnard_defconfig | 1 +
  configs/highbank_defconfig| 1 +
  configs/hsdk_4xd_defconfig| 1 +
  configs/hsdk_defconfig| 1 +
  configs/igep00x0_defconfig| 1 +
  configs/iot_devkit_defconfig  | 1 +
  configs/k2e_evm_defconfig | 1 +
  configs/k2e_hs_evm_defconfig  | 1 +
  configs/k2g_evm_defconfig | 1 +
  configs/k2g_hs_evm_defconfig  | 1 +
  configs/k2hk_evm_defconfig| 1 +
  configs/k2hk_hs_evm_defconfig | 1 +
  configs/k2l_evm_defconfig | 1 +
  configs/k2l_hs_evm_defconfig  | 1 +
  configs/km_kirkwood_128m16_defconfig  | 1 +
  configs/km_kirkwood_defconfig | 1 +
  configs/km_kirkwood_pci_defconfig | 1 +
  configs/kmcoge5un_defconfig   | 1 +
  configs/kmnusa_defconfig  | 1 +
  configs/kmsuse2_defconfig | 1 +
  configs/kzm9g_defconfig   | 1 +
  configs/legoev3_defconfig | 1 +
  configs/ls2080aqds_nand_defconfig | 1 +
  configs/ls2080aqds_qspi_defconfig | 1 +
  configs/ls2080aqds_sdcard_defconfi

Re: [PATCH] ARM: vexpress_ca9x4: Correct missing SYS_LOAD_ADDR

2021-10-07 Thread Kristian Amlie 
On 25/09/2021 16:44, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 25 Sept 2021 at 07:47, Tom Rini  wrote:
>>
>> On Sat, Sep 25, 2021 at 07:04:18AM -0600, Simon Glass wrote:
>>
>>> Add this missing option since it otherwise causes the build to fail in
>>> an infinite loop of:
>>>
>>>Address in memory to use by default (SYS_LOAD_ADDR) [] (NEW)
>>>Error in reading or end of file.
>>>
>>> Signed-off-by: Simon Glass 
>>> Fixes: 15e30106ce6 (ARM: vexpress_ca9x4: Reintroduce board in order to use 
>>> with QEMU.")
>>
>> I pushed something like this through last night, FYI.
> 
> OK ta, should have checked this morning!

Confirmed working on our side too. Thanks!

-- 
Kristian



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/1] ARM: vexpress_ca9x4: Reintroduce board in order to use with QEMU.

2021-09-09 Thread Kristian Amlie 
On 08/09/2021 15:57, Tom Rini wrote:
> On Tue, Sep 07, 2021 at 08:37:51AM +0200, Kristian Amlie wrote:
> 
>> vexpress_ca9x4 is seemingly the only board except for qemu_arm which
>> is able to run U-Boot correctly, using the `-M vexpress-a9` option to
>> QEMU. Building for qemu_arm and running qemu-system-arm with the `-M
>> virt` argument has a number of downsides, most importantly that it
>> only supports virtio storage drivers. This significantly reduces its
>> usefulness in testing memory card and Flash solutions, especially when
>> the tested images are from a third party source.
>>
>> So therefore we reintroduce the vexpress_ca9x4 board in this commit,
>> with the explicit goal of using it with QEMU.
>>
>> A number of differences to note from the original:
>>
>> * Since the board was apparently unmaintained, I have now set myself
>>   as the maintainer.
>>
>> * The board has been converted to use the driver model, which was the
>>   reason it was removed in the first place.
>>
>> * The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed
>>   in the same commit, are not necessary for the QEMU use case, and
>>   have been omitted.
>>
>> * An `mmc0` alias was introduced in the dts file. The mmc is not
>>   detected correctly without this, now that it's based on the device
>>   tree instead of the board's init function.
>>
>> * A couple of other nodes were removed because they were problematic
>>   when trying to run the UEFI bootmgr. Once again, the primary use
>>   case here is QEMU, and these nodes are not needed for that to work.
>>
>> * Unnecessary board init code has been removed, thanks to driver model
>>   and device tree.
>>
>> * `CONFIG_OF_EMBED` has been enabled. I know this goes against
>>   recommended practice, but there doesn't seem to be any other way to
>>   pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument
>>   does not work, I suppose because U-Boot doesn't use the same
>>   mechanics as the kernel when it's booting.
> 
> This is something that should get looked at and figured out, but is
> separate.  I thought this did work on Pi for example.

Yes, I tried messing with fdtaddr, but I couldn't get it to work without
OF_EMBED. I don't know the implementation details well in this area,
unfortunately.

> 
>> * Load addresses have been changed to fit QEMU use case.
>>
>> People wanting to get a more detailed, yet somewhat isolated, diff
>> between this and the original, can run this command:
>>
>>   git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \
>>   $( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD)
>>
>> (Make sure to either check out this commit first, or replace HEAD with
>> the commit ID of this commit)
>>
>> Signed-off-by: Kristian Amlie 
> 
> I'm glad to see this come back.  A request:
> 
> [snip]
>> diff --git a/include/configs/vexpress_ca9x4.h 
>> b/include/configs/vexpress_ca9x4.h
>> new file mode 100644
>> index 00..8157a5868d
>> --- /dev/null
>> +++ b/include/configs/vexpress_ca9x4.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * (C) Copyright 2011 Linaro
>> + * Ryan Harkin, 
>> + *
>> + * Configuration for Versatile Express. Parts were derived from other ARM
>> + *   configurations.
>> + */
>> +
>> +#ifndef __VEXPRESS_CA9X4_H
>> +#define __VEXPRESS_CA9X4_H
>> +
>> +#define CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
>> +#include "vexpress_common.h"
> 
> CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP looks to just be polluting the
> CONFIG namespace, it's only then used..
> 
>> +
>> +#endif /* VEXPRESS_CA9X4_H */
>> diff --git a/include/configs/vexpress_common.h 
>> b/include/configs/vexpress_common.h
>> index b131480e5b..99a5dd064a 100644
>> --- a/include/configs/vexpress_common.h
>> +++ b/include/configs/vexpress_common.h
>> @@ -169,29 +169,10 @@
>>  func(DHCP, dhcp, na)
>>  #include 
>>  
>> -#ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
>> -#define CONFIG_PLATFORM_ENV_SETTINGS \
>> -"loadaddr=0x80008000\0" \
>> -"ramdisk_addr_r=0x6100\0" \
>> -"kernel_addr=0x4410\0" \
>> -"ramdisk_addr=0x4480\0" \
>> -"maxramdisk=0x180\0" \
>> -"pxefile_addr_r=0x8800\0" \
>> -"scriptaddr

[PATCH 1/1] Avoid polluting CONFIG_ namespace with board specific define.

2021-09-09 Thread Kristian Amlie 
Signed-off-by: Kristian Amlie 
---
 include/configs/vexpress_ca9x4.h  | 2 +-
 include/configs/vexpress_common.h | 2 +-
 scripts/config_whitelist.txt  | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/configs/vexpress_ca9x4.h b/include/configs/vexpress_ca9x4.h
index 8157a5868d..ba3f9797a5 100644
--- a/include/configs/vexpress_ca9x4.h
+++ b/include/configs/vexpress_ca9x4.h
@@ -10,7 +10,7 @@
 #ifndef __VEXPRESS_CA9X4_H
 #define __VEXPRESS_CA9X4_H
 
-#define CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
+#define VEXPRESS_ORIGINAL_MEMORY_MAP
 #include "vexpress_common.h"
 
 #endif /* VEXPRESS_CA9X4_H */
diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index 99a5dd064a..f3f021f050 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -15,7 +15,7 @@
  * Definitions copied from linux kernel:
  * arch/arm/mach-vexpress/include/mach/motherboard.h
  */
-#ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
+#ifdef VEXPRESS_ORIGINAL_MEMORY_MAP
 /* CS register bases for the original memory map. */
 #define V2M_PA_CS0 0x4000
 #define V2M_PA_CS1 0x4400
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index d86f35856f..8afdee6499 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -3441,7 +3441,6 @@ CONFIG_U_BOOT_HDR_SIZE
 CONFIG_VAL
 CONFIG_VAR_SIZE_SPL
 CONFIG_VERY_BIG_RAM
-CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
 CONFIG_VIDEO_BCM2835
 CONFIG_VIDEO_BMP_LOGO
 CONFIG_VIDEO_DA8XX
-- 
2.17.1

[PATCH 1/1] ARM: vexpress_ca9x4: Reintroduce board in order to use with QEMU.

2021-09-06 Thread Kristian Amlie 
vexpress_ca9x4 is seemingly the only board except for qemu_arm which
is able to run U-Boot correctly, using the `-M vexpress-a9` option to
QEMU. Building for qemu_arm and running qemu-system-arm with the `-M
virt` argument has a number of downsides, most importantly that it
only supports virtio storage drivers. This significantly reduces its
usefulness in testing memory card and Flash solutions, especially when
the tested images are from a third party source.

So therefore we reintroduce the vexpress_ca9x4 board in this commit,
with the explicit goal of using it with QEMU.

A number of differences to note from the original:

* Since the board was apparently unmaintained, I have now set myself
  as the maintainer.

* The board has been converted to use the driver model, which was the
  reason it was removed in the first place.

* The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed
  in the same commit, are not necessary for the QEMU use case, and
  have been omitted.

* An `mmc0` alias was introduced in the dts file. The mmc is not
  detected correctly without this, now that it's based on the device
  tree instead of the board's init function.

* A couple of other nodes were removed because they were problematic
  when trying to run the UEFI bootmgr. Once again, the primary use
  case here is QEMU, and these nodes are not needed for that to work.

* Unnecessary board init code has been removed, thanks to driver model
  and device tree.

* `CONFIG_OF_EMBED` has been enabled. I know this goes against
  recommended practice, but there doesn't seem to be any other way to
  pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument
  does not work, I suppose because U-Boot doesn't use the same
  mechanics as the kernel when it's booting.

* Load addresses have been changed to fit QEMU use case.

People wanting to get a more detailed, yet somewhat isolated, diff
between this and the original, can run this command:

  git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \
  $( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD)

(Make sure to either check out this commit first, or replace HEAD with
the commit ID of this commit)

Signed-off-by: Kristian Amlie 
---
 .azure-pipelines.yml|   3 +
 .gitlab-ci.yml  |   6 +
 arch/arm/Kconfig|   6 +
 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/vexpress-v2m.dtsi  | 427 
 arch/arm/dts/vexpress-v2p-ca9.dts   | 369 
 board/armltd/vexpress/Kconfig   |  12 +
 board/armltd/vexpress/MAINTAINERS   |   6 +
 board/armltd/vexpress/Makefile  |   6 +
 board/armltd/vexpress/vexpress_common.c | 167 +
 configs/vexpress_ca9x4_defconfig|  49 +++
 include/configs/vexpress_ca9x4.h|  16 +
 include/configs/vexpress_common.h   |  25 +-
 13 files changed, 1072 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/dts/vexpress-v2m.dtsi
 create mode 100644 arch/arm/dts/vexpress-v2p-ca9.dts
 create mode 100644 board/armltd/vexpress/Kconfig
 create mode 100644 board/armltd/vexpress/MAINTAINERS
 create mode 100644 board/armltd/vexpress/Makefile
 create mode 100644 board/armltd/vexpress/vexpress_common.c
 create mode 100644 configs/vexpress_ca9x4_defconfig
 create mode 100644 include/configs/vexpress_ca9x4.h

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 15507a7357..284b32956d 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -195,6 +195,9 @@ jobs:
 evb_ast2500:
   TEST_PY_BD: "evb-ast2500"
   TEST_PY_ID: "--id qemu"
+vexpress_ca9x4:
+  TEST_PY_BD: "vexpress_ca9x4"
+  TEST_PY_ID: "--id qemu"
 integratorcp_cm926ejs:
   TEST_PY_BD: "integratorcp_cm926ejs"
   TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index ffdeaae5a8..78a55224ae 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -204,6 +204,12 @@ sandbox_flattree test.py:
 TEST_PY_BD: "sandbox_flattree"
   <<: *buildman_and_testpy_dfn
 
+vexpress_ca9x4 test.py:
+  variables:
+TEST_PY_BD: "vexpress_ca9x4"
+TEST_PY_ID: "--id qemu"
+  <<: *buildman_and_testpy_dfn
+
 integratorcp_cm926ejs test.py:
   variables:
 TEST_PY_BD: "integratorcp_cm926ejs"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d692139199..0fcfb921e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -626,6 +626,11 @@ config ARCH_BCMSTB
  This enables support for Broadcom ARM-based set-top box
  chipsets, including the 7445 family of chips.
 
+config TARGET_VEXPRESS_CA9X4
+   bool "Support vexpress_ca9x4"
+   select CPU_V7A
+   select PL011_SERIAL
+
 config TARGET_BCMCYGNUS
bool "Support bcmcygnus"
select CPU

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2021-09-02 Thread Kristian Amlie 
On 02/09/2021 10:47, Ard Biesheuvel wrote:
> On Thu, 2 Sept 2021 at 10:43, Kristian Amlie
>  wrote:
>>
>> On 31/08/2021 13:12, Kristian Amlie wrote:
>>> On 31/08/2021 12:46, Heinrich Schuchardt wrote:
>>>>
>>>>
>>>> 
>>>> *Von:* Ard Biesheuvel 
>>>> *Gesendet:* 31. August 2021 12:33:56 MESZ
>>>> *An:* Heinrich Schuchardt 
>>>> *CC:* Kristian Amlie 
>>>> *Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
>>>> returning memory map.
>>>>
>>>> On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  
>>>> wrote:
>>>>
>>>>
>>>> On 8/27/21 9:55 AM, Kristian Amlie wrote:
>>>>
>>>> You can use scripts/get_maintainer.pl to find the right addressees for
>>>> your patches.
>>>>
>>>> efi_reserve_memory() states that memory marked with "no-map"
>>>> shall not
>>>> be accessed by the UEFI payload. Make sure efi_get_memory_map()
>>>> honors
>>>> this.
>>>>
>>>>
>>>> Accessing memory and describing memory are two different things.
>>>> Describing reserved memory in the memory map is important, because it
>>>> helps us distinguish it from MMIO regions.
>>>
>>> Ok, my mistake, I thought the kernel would deduce this separately
>>> through the DTB.
>>>
>>>>
>>>> This helps the case when booting vexpress_ca9x4 under QEMU. Because
>>>> the kernel wants to use an address in the lowest 128MiB of the
>>>> range,
>>>> but this range is reserved with "no-map", the kernel complains
>>>> that it
>>>> can not allocate the low memory it needs. In reality the actual
>>>> usable
>>>> memory starts much higher, which is reflected correctly in the
>>>> memory
>>>> map after this fix.
>>>>
>>>>
>>>>
>>>> This is a u-boot patch right? (I cannot tell from the context, as
>>>> there are no mailing lists on cc)
>>>>
>>>> It is u-boot's job to describe all the memory, no matter how it is
>>>> used. Even if the kernel itself may not use it as system memory, there
>>>> are cases where kernel infrastructure is used to map these regions:
>>>> for instance, the ACPI core may need to map a SystemMemory OpRegion,
>>>> and we need the EFI memory map to tell us whether to use memory or I/O
>>>> semantics.
>>>>
>>>> As for the 128 MB issue: can you reproduce this with a recent kernel?
>>>> We made some changes recently to the EFI stub as well as the
>>>> decompressor code to prevent the decompressor code from relocating
>>>> itself to the base of DRAM, and to allow the decompressed kernel to
>>>> reside at any 2 MB aligned offset in memory.
>>>
>>> I'll try this and get back to you!
>>
>> The result have been a bit inconclusive. I *think* it works, but the
>> system later crashes because init is killed. Which may be a problem with
>> that kernel in general, I don't know. I would require more time to
>> figure out exactly what's causing it. The early boot and all the memory
>> initialization seems to work just fine though.
>>
>> I have pasted the log below if you want to look at it, but to me the
>> error looks unrelated.
>>
> 
> Agreed. systemd-init crashes for some reason, but this is highly
> unlikely to be caused by the EFI memory map containing reserved memory
> regions.

Thanks for checking! Then from my perspective you can consider this
issue resolved, and drop the patch.

-- 
Kristian



OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2021-09-02 Thread Kristian Amlie 
On 31/08/2021 13:12, Kristian Amlie wrote:
> On 31/08/2021 12:46, Heinrich Schuchardt wrote:
>>
>>
>> 
>> *Von:* Ard Biesheuvel 
>> *Gesendet:* 31. August 2021 12:33:56 MESZ
>> *An:* Heinrich Schuchardt 
>> *CC:* Kristian Amlie 
>> *Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
>> returning memory map.
>>
>> On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  wrote:
>>
>>
>> On 8/27/21 9:55 AM, Kristian Amlie wrote:
>>
>> You can use scripts/get_maintainer.pl to find the right addressees for
>> your patches.
>>
>> efi_reserve_memory() states that memory marked with "no-map"
>> shall not
>> be accessed by the UEFI payload. Make sure efi_get_memory_map()
>> honors
>> this.
>>
>>
>> Accessing memory and describing memory are two different things.
>> Describing reserved memory in the memory map is important, because it
>> helps us distinguish it from MMIO regions.
> 
> Ok, my mistake, I thought the kernel would deduce this separately
> through the DTB.
> 
>>
>> This helps the case when booting vexpress_ca9x4 under QEMU. Because
>> the kernel wants to use an address in the lowest 128MiB of the
>> range,
>> but this range is reserved with "no-map", the kernel complains
>> that it
>> can not allocate the low memory it needs. In reality the actual
>> usable
>> memory starts much higher, which is reflected correctly in the
>> memory
>> map after this fix.
>>
>>
>>
>> This is a u-boot patch right? (I cannot tell from the context, as
>> there are no mailing lists on cc)
>>
>> It is u-boot's job to describe all the memory, no matter how it is
>> used. Even if the kernel itself may not use it as system memory, there
>> are cases where kernel infrastructure is used to map these regions:
>> for instance, the ACPI core may need to map a SystemMemory OpRegion,
>> and we need the EFI memory map to tell us whether to use memory or I/O
>> semantics.
>>
>> As for the 128 MB issue: can you reproduce this with a recent kernel?
>> We made some changes recently to the EFI stub as well as the
>> decompressor code to prevent the decompressor code from relocating
>> itself to the base of DRAM, and to allow the decompressed kernel to
>> reside at any 2 MB aligned offset in memory.
> 
> I'll try this and get back to you!

The result have been a bit inconclusive. I *think* it works, but the
system later crashes because init is killed. Which may be a problem with
that kernel in general, I don't know. I would require more time to
figure out exactly what's causing it. The early boot and all the memory
initialization seems to work just fine though.

I have pasted the log below if you want to look at it, but to me the
error looks unrelated.

--- BOOT LOG ---

U-Boot 2021.07 (Jul 05 2021 - 15:11:28 +)

DRAM:  256 MiB
WARNING: Caches not enabled
Flash: 64 MiB
MMC:   sysctl@1000 - probe failed: -19
aaci@4000 - probe failed: -19
uart@9000 - probe failed: -19
uart@a000 - probe failed: -19
uart@b000 - probe failed: -19
uart@c000 - probe failed: -19
timer@11000 - probe failed: -19
timer@12000 - probe failed: -19
rtc@17000 - probe failed: -19
clcd@1f000 - probe failed: -19
clcd@1002 - probe failed: -19
memory-controller@100e - probe failed: -19
memory-controller@100e1000 - probe failed: -19
watchdog@100e5000 - probe failed: -19

Loading Environment from Flash... *** Warning - bad CRC, using default
environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@3,0200
Hit any key to stop autoboot:  0
no mmc device at slot 1
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
14163 bytes read in 16 ms (864.3 KiB/s)
Scanning disk sys...@1000.blk...
Disk sys...@1000.blk not ready
Scanning disk a...@4000.blk...
Disk a...@4000.blk not ready
Scanning disk m...@5000.blk...
Scanning disk u...@9000.blk...
Disk u...@9000.blk not ready
Scanning disk u...@a000.blk...
Disk u...@a000.blk not ready
Scanning disk u...@b000.blk...
Disk u...@b000.blk not ready
Scanning disk u...@c000.blk...
Disk u...@c000.blk not ready
Scanning disk ti...@11000.blk...
Disk ti...@11000.blk not ready
Scanning disk ti...@12000.blk...
Disk ti...@12000.blk not ready
Scanning disk r...@17000.blk...
Disk r...@17000.blk not ready
Scanning disk c...@1f000.blk...
Disk c...@1f000.blk not ready
Scanning disk c...@1002.blk...
Disk c...@1002.blk not ready
Scanning disk memory-control...@100e.bl...
Disk memory-con

Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2021-08-31 Thread Kristian Amlie 
On 31/08/2021 12:46, Heinrich Schuchardt wrote:
> 
> 
> 
> *Von:* Ard Biesheuvel 
> *Gesendet:* 31. August 2021 12:33:56 MESZ
> *An:* Heinrich Schuchardt 
> *CC:* Kristian Amlie 
> *Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
> returning memory map.
> 
> On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt  wrote:
> 
> 
> On 8/27/21 9:55 AM, Kristian Amlie wrote:
> 
> You can use scripts/get_maintainer.pl to find the right addressees for
> your patches.
> 
> efi_reserve_memory() states that memory marked with "no-map"
> shall not
> be accessed by the UEFI payload. Make sure efi_get_memory_map()
> honors
> this.
> 
> 
> Accessing memory and describing memory are two different things.
> Describing reserved memory in the memory map is important, because it
> helps us distinguish it from MMIO regions.

Ok, my mistake, I thought the kernel would deduce this separately
through the DTB.

> 
> This helps the case when booting vexpress_ca9x4 under QEMU. Because
> the kernel wants to use an address in the lowest 128MiB of the
> range,
> but this range is reserved with "no-map", the kernel complains
> that it
> can not allocate the low memory it needs. In reality the actual
> usable
> memory starts much higher, which is reflected correctly in the
> memory
> map after this fix.
> 
> 
> 
> This is a u-boot patch right? (I cannot tell from the context, as
> there are no mailing lists on cc)
> 
> It is u-boot's job to describe all the memory, no matter how it is
> used. Even if the kernel itself may not use it as system memory, there
> are cases where kernel infrastructure is used to map these regions:
> for instance, the ACPI core may need to map a SystemMemory OpRegion,
> and we need the EFI memory map to tell us whether to use memory or I/O
> semantics.
> 
> As for the 128 MB issue: can you reproduce this with a recent kernel?
> We made some changes recently to the EFI stub as well as the
> decompressor code to prevent the decompressor code from relocating
> itself to the base of DRAM, and to allow the decompressed kernel to
> reside at any 2 MB aligned offset in memory.

I'll try this and get back to you!

--
Kristian

> 
> 
> The 'no-map' requirement needs to be fulfilled by the kernel.
> 
> The GetMemoryMap() boot time service must comply to the UEFI
> specification.
> 
> The Devicetree Specification has this clarification:
> 
> "Reserved regions with the no-map property must be listed in the memory
> map with type EfiReservedMemoryType. All other reserved regions must be
> listed with type EfiBootServicesData."
> 
> https://devicetree-specification.readthedocs.io/en/latest/chapter3-devicenodes.html
> 
> <https://devicetree-specification.readthedocs.io/en/latest/chapter3-devicenodes.html>
> 
> Should the kernel calculate its internal 128 MiB requirement incorrectly
> this needs be fixed in the kernel EFI stub. Does the problem exist with
> kernel 5.14?
> 
> I wonder if the 128 MiB requirement of the kernel can be lifted for
> 32bit ARM as we already did for RISC-V. Cf.
> 
> 
> As mentioned above, this should already be fixed, in v5.11 or later
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.14&id=c79e89ecaa246c880292ba68cbe08c9c30db77e3
> 
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.14&id=c79e89ecaa246c880292ba68cbe08c9c30db77e3>
> 
> Cc Ard, maintainer of the kernel EFI stub.
> 
> Best regards
> 
> Heinrich
> 
> 
> Signed-off-by: Kristian Amlie 
> 
> 
> lib/efi_loader/efi_memory.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/efi_memory.c
> b/lib/efi_loader/efi_memory.c
> index f4acbee4f9..7f8543143a 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -646,8 +646,16 @@ efi_status_t efi_get_memory_map(efi_uintn_t
> *memory_map_size,
> 
> provided_map_size = *memory_map_size;
> 
> - list_for_each(lhandle, &efi_mem)
> + list_for_each(lhandle, &efi_mem) {
> + struct efi_mem_list *lmem;
> +
> + lmem = list_entry(lhandle, stru

[PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2021-08-27 Thread Kristian Amlie 
efi_reserve_memory() states that memory marked with "no-map" shall not
be accessed by the UEFI payload. Make sure efi_get_memory_map() honors
this.

This helps the case when booting vexpress_ca9x4 under QEMU. Because
the kernel wants to use an address in the lowest 128MiB of the range,
but this range is reserved with "no-map", the kernel complains that it
can not allocate the low memory it needs. In reality the actual usable
memory starts much higher, which is reflected correctly in the memory
map after this fix.

Signed-off-by: Kristian Amlie 
---
 lib/efi_loader/efi_memory.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index f4acbee4f9..7f8543143a 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -646,8 +646,16 @@ efi_status_t efi_get_memory_map(efi_uintn_t 
*memory_map_size,
 
provided_map_size = *memory_map_size;
 
-   list_for_each(lhandle, &efi_mem)
+   list_for_each(lhandle, &efi_mem) {
+   struct efi_mem_list *lmem;
+
+   lmem = list_entry(lhandle, struct efi_mem_list, link);
+
+   if (lmem->desc.type == EFI_RESERVED_MEMORY_TYPE)
+   continue;
+
map_entries++;
+   }
 
map_size = map_entries * sizeof(struct efi_mem_desc);
 
@@ -672,6 +680,10 @@ efi_status_t efi_get_memory_map(efi_uintn_t 
*memory_map_size,
struct efi_mem_list *lmem;
 
lmem = list_entry(lhandle, struct efi_mem_list, link);
+
+   if (lmem->desc.type == EFI_RESERVED_MEMORY_TYPE)
+   continue;
+
*memory_map = lmem->desc;
memory_map--;
}
-- 
2.17.1

efi_loader: Omit memory with "no-map" when returning memory

2021-08-27 Thread Kristian Amlie 


Since I'm not very experienced with EFI internals, this is part patch
submission, part question. Does it seem correct? At least according to
comments I could find in the code, it should work like this. See patch.

-- 
Kristian

Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-03-30 Thread Kristian Amlie 

On 28/03/2020 11:12, Heinrich Schuchardt wrote:

On 3/28/20 10:36 AM, Heinrich Schuchardt wrote:

On 3/27/20 8:18 AM, Kristian Amlie wrote:

On 27/03/2020 06:44, Heinrich Schuchardt wrote:

On 3/27/20 2:39 AM, Tom Rini wrote:

On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:


EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
and indeed, the DTB file is required to load recent versions of GRUB
(2.04) correctly.

Signed-off-by: Kristian Amlie 


Applied to u-boot/master, thanks!



Since this patch is merged I get errors on Gitlab for vexpress_ca9x4:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/69269

Filename 'lib/efi_loader/helloworld.efi'.
Load address: 0x6000
Loading: *#
  1.8 MiB/s
done
Bytes transferred = 1840 (730 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 6000 $filesize
CRC32 for 6000 ... 672f ==> f5c77855
=> => bootefi 6000
78Scanning disks on mmc...
Card did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
ERROR: need device tree


Is the "bootefi 6000" command correct? Doesn't "bootefi" need to be
called with both an EFI binary address and a device tree address?



bootefi uses $fdtcontroladdr as fallback for the device tree. But this
variable is only available if CONFIG_OF_CONTROL is set. We should adjust
the python test to check this.

CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
This line is incorrect. We never use a .dtb extension here.


I got that wrong. There are two variables which are somewhat related:

CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"

One uses the extension, the other doesn't.

So your patch seems to be correct. The error is in the Python test that
does not check if OF_CONTROL is set.


Thanks for figuring that out!

--
Kristian



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-03-27 Thread Kristian Amlie 

On 27/03/2020 06:44, Heinrich Schuchardt wrote:

On 3/27/20 2:39 AM, Tom Rini wrote:

On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:


EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
and indeed, the DTB file is required to load recent versions of GRUB
(2.04) correctly.

Signed-off-by: Kristian Amlie 


Applied to u-boot/master, thanks!



Since this patch is merged I get errors on Gitlab for vexpress_ca9x4:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/69269

Filename 'lib/efi_loader/helloworld.efi'.
Load address: 0x6000
Loading: *#
  1.8 MiB/s
done
Bytes transferred = 1840 (730 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 6000 $filesize
CRC32 for 6000 ... 672f ==> f5c77855
=> => bootefi 6000
78Scanning disks on mmc...
Card did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
ERROR: need device tree


Is the "bootefi 6000" command correct? Doesn't "bootefi" need to be 
called with both an EFI binary address and a device tree address?


--
Kristian



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-03-20 Thread Kristian Amlie 

On 02/03/2020 14:15, Kristian Amlie wrote:

On 02/03/2020 14:01, Tom Rini wrote:

On Mon, Mar 02, 2020 at 11:22:27AM +0100, Kristian Amlie wrote:

On 28/02/2020 16:32, Tom Rini wrote:

On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:


EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
and indeed, the DTB file is required to load recent versions of GRUB
(2.04) correctly.

Signed-off-by: Kristian Amlie 
---
  configs/vexpress_ca9x4_defconfig  | 2 +-
  include/configs/vexpress_common.h | 3 ++-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index 2119df6b10..6bd1f253b6 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -34,4 +34,4 @@ CONFIG_SMC911X_32_BIT=y
  CONFIG_BAUDRATE=38400
  CONFIG_CONS_INDEX=0
  CONFIG_OF_LIBFDT=y
-# CONFIG_EFI_LOADER is not set
+CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index 7f215a6707..e73658a9e6 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -207,7 +207,8 @@
"devtmpfs.mount=0  vmalloc=256M\0" \
"bootflash=run flashargs; " \
"cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
-   "bootm ${kernel_addr} ${ramdisk_addr_r}\0"
+   "bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
+   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0"
  
  /* FLASH and environment organization */

  #define PHYS_FLASH_SIZE   0x0400  /* 64MB */


Did you test build all of the vexpress platforms?  There's a common file
for the 5 different ones.  Thanks!


The two boards vexpress_aemv8a_juno_defconfig and
vexpress_aemv8a_semi_defconfig don't compile at all, even without the
patch. The other three compile just fine both with and without the patch.


Don't compile where / how?  All 5 compile with their defconfigs today.
Thanks!


Oh, those are 64-bit boards, sorry I missed that part. All five are
compiling fine then, both with and without the patch!


Anything I can do to help this along?

--
Kristian




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-03-02 Thread Kristian Amlie 
On 02/03/2020 14:01, Tom Rini wrote:
> On Mon, Mar 02, 2020 at 11:22:27AM +0100, Kristian Amlie wrote:
>> On 28/02/2020 16:32, Tom Rini wrote:
>>> On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:
>>>
>>>> EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
>>>> and indeed, the DTB file is required to load recent versions of GRUB
>>>> (2.04) correctly.
>>>>
>>>> Signed-off-by: Kristian Amlie 
>>>> ---
>>>>  configs/vexpress_ca9x4_defconfig  | 2 +-
>>>>  include/configs/vexpress_common.h | 3 ++-
>>>>  2 files changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/configs/vexpress_ca9x4_defconfig 
>>>> b/configs/vexpress_ca9x4_defconfig
>>>> index 2119df6b10..6bd1f253b6 100644
>>>> --- a/configs/vexpress_ca9x4_defconfig
>>>> +++ b/configs/vexpress_ca9x4_defconfig
>>>> @@ -34,4 +34,4 @@ CONFIG_SMC911X_32_BIT=y
>>>>  CONFIG_BAUDRATE=38400
>>>>  CONFIG_CONS_INDEX=0
>>>>  CONFIG_OF_LIBFDT=y
>>>> -# CONFIG_EFI_LOADER is not set
>>>> +CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
>>>> diff --git a/include/configs/vexpress_common.h 
>>>> b/include/configs/vexpress_common.h
>>>> index 7f215a6707..e73658a9e6 100644
>>>> --- a/include/configs/vexpress_common.h
>>>> +++ b/include/configs/vexpress_common.h
>>>> @@ -207,7 +207,8 @@
>>>>"devtmpfs.mount=0  vmalloc=256M\0" \
>>>>"bootflash=run flashargs; " \
>>>>"cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
>>>> -  "bootm ${kernel_addr} ${ramdisk_addr_r}\0"
>>>> +  "bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
>>>> +  "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0"
>>>>  
>>>>  /* FLASH and environment organization */
>>>>  #define PHYS_FLASH_SIZE   0x0400  /* 64MB */
>>>
>>> Did you test build all of the vexpress platforms?  There's a common file
>>> for the 5 different ones.  Thanks!
>>
>> The two boards vexpress_aemv8a_juno_defconfig and
>> vexpress_aemv8a_semi_defconfig don't compile at all, even without the
>> patch. The other three compile just fine both with and without the patch.
> 
> Don't compile where / how?  All 5 compile with their defconfigs today.
> Thanks!

Oh, those are 64-bit boards, sorry I missed that part. All five are
compiling fine then, both with and without the patch!

-- 
Kristian




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-03-02 Thread Kristian Amlie 
On 28/02/2020 16:32, Tom Rini wrote:
> On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:
> 
>> EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
>> and indeed, the DTB file is required to load recent versions of GRUB
>> (2.04) correctly.
>>
>> Signed-off-by: Kristian Amlie 
>> ---
>>  configs/vexpress_ca9x4_defconfig  | 2 +-
>>  include/configs/vexpress_common.h | 3 ++-
>>  2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/configs/vexpress_ca9x4_defconfig 
>> b/configs/vexpress_ca9x4_defconfig
>> index 2119df6b10..6bd1f253b6 100644
>> --- a/configs/vexpress_ca9x4_defconfig
>> +++ b/configs/vexpress_ca9x4_defconfig
>> @@ -34,4 +34,4 @@ CONFIG_SMC911X_32_BIT=y
>>  CONFIG_BAUDRATE=38400
>>  CONFIG_CONS_INDEX=0
>>  CONFIG_OF_LIBFDT=y
>> -# CONFIG_EFI_LOADER is not set
>> +CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
>> diff --git a/include/configs/vexpress_common.h 
>> b/include/configs/vexpress_common.h
>> index 7f215a6707..e73658a9e6 100644
>> --- a/include/configs/vexpress_common.h
>> +++ b/include/configs/vexpress_common.h
>> @@ -207,7 +207,8 @@
>>  "devtmpfs.mount=0  vmalloc=256M\0" \
>>  "bootflash=run flashargs; " \
>>  "cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
>> -"bootm ${kernel_addr} ${ramdisk_addr_r}\0"
>> +"bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
>> +"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0"
>>  
>>  /* FLASH and environment organization */
>>  #define PHYS_FLASH_SIZE 0x0400  /* 64MB */
> 
> Did you test build all of the vexpress platforms?  There's a common file
> for the 5 different ones.  Thanks!

The two boards vexpress_aemv8a_juno_defconfig and
vexpress_aemv8a_semi_defconfig don't compile at all, even without the
patch. The other three compile just fine both with and without the patch.

-- 
Kristian



signature.asc
Description: OpenPGP digital signature

[PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.

2020-02-25 Thread Kristian Amlie 
EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
and indeed, the DTB file is required to load recent versions of GRUB
(2.04) correctly.

Signed-off-by: Kristian Amlie 
---
 configs/vexpress_ca9x4_defconfig  | 2 +-
 include/configs/vexpress_common.h | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index 2119df6b10..6bd1f253b6 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -34,4 +34,4 @@ CONFIG_SMC911X_32_BIT=y
 CONFIG_BAUDRATE=38400
 CONFIG_CONS_INDEX=0
 CONFIG_OF_LIBFDT=y
-# CONFIG_EFI_LOADER is not set
+CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index 7f215a6707..e73658a9e6 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -207,7 +207,8 @@
"devtmpfs.mount=0  vmalloc=256M\0" \
"bootflash=run flashargs; " \
"cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
-   "bootm ${kernel_addr} ${ramdisk_addr_r}\0"
+   "bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
+   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0"
 
 /* FLASH and environment organization */
 #define PHYS_FLASH_SIZE0x0400  /* 64MB */
-- 
2.17.1

Re: [U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-08-09 Thread Kristian Amlie 
On 08/08/18 01:10, Alexander Graf wrote:
> On 07.08.18 09:26, Kristian Amlie wrote:
>> What I want out of this exercise is to make sure that the EFI path in
>> distro_bootcmd will be able to boot an EFI app on any board, regardless
>> of whether it uses kernel_addr_r or loadaddr. Sounds reasonable, right?
> 
> If you enable distro boot for a board, one of the requirement is that
> kernel_addr_r is set to a reasonable value:
> 
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;h=f8e9752a0fa4244ef0a6f7ee530b0aa218080cac;hb=HEAD#l236

Aha! This link clears up the confusion.

>> There are several things I could do from here on:
>>
>>
>> 1. Keep the current patch, but add "loadaddr" to pxe and extlinux
>> variants as well to get consistent behavior.
>>
>> 2. Reverse order of attempts, and try to use kernel_addr_r first, then
>> loadaddr. Possibly this could also include a patch to pxe and extlinux
>> to make them behave the same.
>>
>> 3. Do nothing, and keep kernel_addr_r as the one and only. IMHO this
>> implicitly means that loadaddr should be deprecated and removed, given
>> their overlapping meaning, and boards converted to using kernel_addr_r.
> 
> I think this is the best option. Just convert boards you care about
> slowly over to distro boot (which implicitly means they also use
> kernel_addr_r). For other boards you can not rely on any EFI boot path
> enumeration anyway, because the boot command doesn't search for EFI
> binaries ;).

You're right, I had not thought of that. It makes a lot of sense, we
will make this part of our recommendation for board porting then.

Thanks!

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

Re: [U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-08-07 Thread Kristian Amlie 
On 07/08/18 00:06, Alexander Graf wrote:
> On 06.08.18 13:00, Kristian Amlie wrote:
>> Ping. Any objections to this change?
> 
> I definitely don't want to have the bootefi path behave any different
> from the other distro boot targets. That would just cause confusion down
> the road.
> 
> Do they (pxe boot, extlinux, etc) make use of loadaddr?

No, you're right, apparently they use kernel_addr_r AFAICS [1].

So maybe it is better to stay with kernel_addr_r. The problem is that
not all boards follow this, and there are various "bootm ${loadaddr}"
and "bootz ${loadaddr}" sprinkled across the various board headers,
indicating that they use this.

What I want out of this exercise is to make sure that the EFI path in
distro_bootcmd will be able to boot an EFI app on any board, regardless
of whether it uses kernel_addr_r or loadaddr. Sounds reasonable, right?

Following that it seems natural to standardize on one of the two, but it
is not entirely clear from the source code which one it should be. I
picked loadaddr because it has a CONFIG_LOADADDR define, unlike
kernel_addr_r which is just hardcoded in a lot of places, and thus
seemed less "proper". But I'm fine with staying with kernel_addr_r as well.

There are several things I could do from here on:


1. Keep the current patch, but add "loadaddr" to pxe and extlinux
variants as well to get consistent behavior.

2. Reverse order of attempts, and try to use kernel_addr_r first, then
loadaddr. Possibly this could also include a patch to pxe and extlinux
to make them behave the same.

3. Do nothing, and keep kernel_addr_r as the one and only. IMHO this
implicitly means that loadaddr should be deprecated and removed, given
their overlapping meaning, and boards converted to using kernel_addr_r.

4. Opposite of 3, make loadaddr into the one and only, and convert all
boards to that.


Personally I think either option 1 or option 2 is the best, both quite
smooth transition paths. Option 3 or 4 are perhaps cleaner solutions in
the long term, but are *a lot* more work, and much more likely to cause
breakage as well.

What do you think?


[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=cmd/pxe.c;h=5609545de575d090b27f48fd0d2d2ee61b8bdc73;hb=HEAD#l701

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

Re: [U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-08-06 Thread Kristian Amlie 
Ping. Any objections to this change?

-- 
Kristian

On 10/07/18 15:29, Kristian Amlie wrote:
> loadaddr is configurable in Kconfig using CONFIG_LOADADDR, while
> kernel_addr_r is not. Hence, loadaddr is the future. Provide the
> existing kernel_addr_r as a fallback if loadaddr is not set.
> 
> Signed-off-by: Kristian Amlie 
> ---
>  include/config_distro_bootcmd.h | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index d672e8e..839afcc 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -129,12 +129,15 @@
>   "else "   \
>   "bootefi bootmgr ${fdtcontroladdr};"  \
>   "fi;" \
> + "if test -z \"${loadaddr}\"; then "   \
> + "setenv loadaddr ${kernel_addr_r};"   \
> + "fi;" \
>   "load ${devtype} ${devnum}:${distro_bootpart} "   \
> - "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
> + "${loadaddr} efi/boot/"BOOTEFI_NAME"; "   \
>   "if fdt addr ${fdt_addr_r}; then "\
> - "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
> + "bootefi ${loadaddr} ${fdt_addr_r};"  \
>   "else "   \
> - "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
> + "bootefi ${loadaddr} ${fdtcontroladdr};"  \
>   "fi\0"\
>   \
>   "load_efi_dtb="   \
> @@ -277,12 +280,15 @@
>   "setenv efi_old_arch ${bootp_arch};"  \
>   "setenv bootp_vci " BOOTENV_EFI_PXE_VCI ";"   \
>   "setenv bootp_arch " BOOTENV_EFI_PXE_ARCH ";" \
> - "if dhcp ${kernel_addr_r}; then " \
> + "if test -z \"${loadaddr}\"; then "   \
> + "setenv loadaddr ${kernel_addr_r};"   \
> + "fi;" \
> + "if dhcp ${loadaddr}; then "  \
>   "tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};"  \
>   "if fdt addr ${fdt_addr_r}; then "\
> - "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
> + "bootefi ${loadaddr} ${fdt_addr_r}; " \
>   "else "   \
> - "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
> + "bootefi ${loadaddr} ${fdtcontroladdr};"  \
>   "fi;" \
>   "fi;" \
>   "setenv bootp_vci ${efi_old_vci};"\
> 

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

[U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-07-10 Thread Kristian Amlie 
loadaddr is configurable in Kconfig using CONFIG_LOADADDR, while
kernel_addr_r is not. Hence, loadaddr is the future. Provide the
existing kernel_addr_r as a fallback if loadaddr is not set.

Signed-off-by: Kristian Amlie 
---
 include/config_distro_bootcmd.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8e..839afcc 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -129,12 +129,15 @@
"else "   \
"bootefi bootmgr ${fdtcontroladdr};"  \
"fi;" \
+   "if test -z \"${loadaddr}\"; then "   \
+   "setenv loadaddr ${kernel_addr_r};"   \
+   "fi;" \
"load ${devtype} ${devnum}:${distro_bootpart} "   \
-   "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
+   "${loadaddr} efi/boot/"BOOTEFI_NAME"; "   \
"if fdt addr ${fdt_addr_r}; then "\
-   "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
+   "bootefi ${loadaddr} ${fdt_addr_r};"  \
"else "   \
-   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "bootefi ${loadaddr} ${fdtcontroladdr};"  \
"fi\0"\
\
"load_efi_dtb="   \
@@ -277,12 +280,15 @@
"setenv efi_old_arch ${bootp_arch};"  \
"setenv bootp_vci " BOOTENV_EFI_PXE_VCI ";"   \
"setenv bootp_arch " BOOTENV_EFI_PXE_ARCH ";" \
-   "if dhcp ${kernel_addr_r}; then " \
+   "if test -z \"${loadaddr}\"; then "   \
+   "setenv loadaddr ${kernel_addr_r};"   \
+   "fi;" \
+   "if dhcp ${loadaddr}; then "  \
"tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};"  \
"if fdt addr ${fdt_addr_r}; then "\
-   "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
+   "bootefi ${loadaddr} ${fdt_addr_r}; " \
"else "   \
-   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "bootefi ${loadaddr} ${fdtcontroladdr};"  \
"fi;" \
"fi;" \
"setenv bootp_vci ${efi_old_vci};"\
-- 
2.7.4

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

[U-Boot] [PATCH 0/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-07-10 Thread Kristian Amlie 
This patch fixes the issue that CONFIG_LOADADDR is not respected when
booting via distro_bootcmd and bootefi, and follows from the thread
"Thoughts on EFI, CONFIG_LOADADDR and kernel_addr_r". Since there was no
reply, I opted for altering the behavior and providing a fallback.

Kristian Amlie (1):
  distro_bootcmd: Switch bootefi to use loadaddr by default.

 include/config_distro_bootcmd.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.7.4

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

[U-Boot] Thoughts on EFI, CONFIG_LOADADDR and kernel_addr_r

2018-06-26 Thread Kristian Amlie 
I have a question about CONFIG_LOADADDR: Given that several
configuration settings have moved to Kconfig files recently, is it
expected that the same thing will happen to CONFIG_LOADADDR?

And following that: Does it mean that we should start retiring other
environment variable names that are named differently but have similar
roles, such as "kernel_addr_r"? It is aliased to CONFIG_LOADADDR for
some boards, but not in general. The only globally available one is
"loadaddr", which mirrors CONFIG_LOADADDR as expected.

I'm asking this in the context of EFI, since "boot_efi_binary", which is
used by "distro_bootcmd" tries to load the kernel into "kernel_addr_r",
which doesn't seem to be in line with what env_defaults.h defines
("loadaddr").

Either name is fine with me, but I'd like to standardize on one, and I
don't know which one. Any preferences on the list?

-- 
Kristian



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

Re: [U-Boot] [RFC] Exporting defaul environment

2018-05-06 Thread Kristian Amlie 
On 03/05/18 18:00, Stefano Babic wrote:
> On 03/05/2018 14:57, Kristian Amlie wrote:
>> I've been having another idea in the back of my head for while, using a
>> very different approach: Instead of requiring that the tool be able to
>> fall back to a default environment, require that U-Boot write the
>> environment to storage if the CRC check fails when it boots, and remove
>> the ability to write to an uninitialized environment from the tools.
> 
> From my experience, this is often not desired by customers that do not
> like that flash is touched at first start. It does not work in case of
> CONFIG_ENV_IS_EMBEDDED, where we should skip the save. Anyway, I agree
> that this helps in User Space because it is guaranteed that a suitable
> environment is always present.

As long as it's possible to opt out, I think resiliency and ease of use
should take priority over such needs. Making the common case easy, and
the hard case possible. Also, with the patch you mentioned from Łukasz
below, if the proper environment is already in storage, no writing
should be necessary.

>> This would guarantee that the environment is available in its expected
>> storage location when entering userspace, and would also have the
>> benefit of exposing dangerous situations where a newly flashed root
>> filesystem has a /etc/fw_env.config which is wrong.
> 
> Well, if /etc/fw_env.config is broken, we cannot do a lot. But this is
> like a bug and should be solved during the test phase.

Of course. This is just a bonus, and not an argument for choosing this
approach.

> Łukasz told me yesterday that he has already sent some patches to
> OE-Core to extract the default environment, even if this is not suitable
> for an "updater" (our use case).
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150194.html
> 
> The patch is useful to generate a ready-to-flash image, but the exported
> default environment could be used as input by the env tools in user
> space when no environment is found.

-- 
Kristian



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

Re: [U-Boot] [RFC] Exporting defaul environment

2018-05-03 Thread Kristian Amlie 
On 02/05/18 21:32, Simon Glass wrote:
> Hi Stefano,
> 
> On 2 May 2018 at 02:48, Stefano Babic  wrote:
>>
>> Hi,
>>
>> I am thinking about how it is possible to export in a clean way the
>> default environment from u-boot. The general use case happens when the
>> environment must be changed from user space (via fw_setenv or whatever)
>> and no environment was still stored - board boots with default environment.
>>
>> Up now, the trick is to compile the environment tools (u-boot-fw-utils
>> in Yocto) with exactly the same U-Boot sources. This works, but it is
>> error prone when a new Yocto version is delivered (and maybe with a
>> different u-boot-fw-utils) or even if the bootloader is updated. I am
>> searching for an alterntive method.
>>
>> The code in tools/env is really generic, but it becomes board specific
>> just for the default environment. If the default environment can read in
>> a reliable way from u-boot itslef (its binary), the tool can search for
>> the default environment instead of linking again, and tools/env becomes
>> "distro capable" - one binary that works on all boards.
>>
>> I have some thoughts and I would like to share, maybe some of you has
>> better ideas. So what I would like to get directly from the binary is
>> the offset of "default_environment" (default_environment)
>> CONFIG_SYS_TEXT_BASE:
>>
>> - put this offset in the .img header. Yes, it works just for SPL /
>> u-boot.img (drawback).
> 
> How about putting the default environment in a FIT? That is typically
> easy to find using the magic word.
> 
>>
>> - surround default environment with some easy to recognize magic number.
>> Offset is not known, but user space can find it, like
>>
>> magic (long string)
>> ...
>> default_environment
>> end default environment (long string)
>>
> 
> Seems like FIT would take care of this for you.
> 
>> - adding a section in the linker. I think we tried something in the
>> past, see __UBOOT_ENV_SECTION__ (it replaced __PPCENV__ from the old
>> good mpc8xx times..) that is currently unused. I do not like this
>> approach, it can increase (due to alignment) footprint in SPL, where I
>> am starting to have issues for smaller i.MX.
> 
> Also I wonder if compression might be useful? FIT supports that fairly easily.

I like the FIT idea, but in all proposals so far, you still have the
problem of locating either the U-Boot binary or the FIT image. It's not
always clear where they can be found.

I've been having another idea in the back of my head for while, using a
very different approach: Instead of requiring that the tool be able to
fall back to a default environment, require that U-Boot write the
environment to storage if the CRC check fails when it boots, and remove
the ability to write to an uninitialized environment from the tools.
This would guarantee that the environment is available in its expected
storage location when entering userspace, and would also have the
benefit of exposing dangerous situations where a newly flashed root
filesystem has a /etc/fw_env.config which is wrong.

The downside is that if the environment somehow gets messed up from
userspace, you have to reboot to fix the problem. This could be
somewhat, but not completely remedied by requiring a redundant environment.

-- 
Kristian



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

[U-Boot] [PATCH 1/1] env/Kconfig: Add descriptions so environment options can be modified.

2018-04-23 Thread Kristian Amlie 
Without a description they always revert to their defaults regardless
of what is in the defconfig file.

Signed-off-by: Kristian Amlie 
---
 env/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/env/Kconfig b/env/Kconfig
index bef6e89..f8d5ddb 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -430,7 +430,7 @@ endif
 if ARCH_ROCKCHIP
 
 config ENV_OFFSET
-   hex
+   hex "Environment offset"
depends on !ENV_IS_IN_UBI
depends on !ENV_IS_NOWHERE
default 0x3f8000
@@ -438,7 +438,7 @@ config ENV_OFFSET
  Offset from the start of the device (or partition)
 
 config ENV_SIZE
-   hex
+   hex "Environment size"
default 0x8000
help
  Size of the environment storage area
-- 
2.7.4

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

[U-Boot] [PATCH 1/1] fw_printenv: Fix crash due to incorrect size for malloc'ed string.

2018-04-04 Thread Kristian Amlie 
Using sizeof gives the size of the pointer only, not the string. This
could easily lead to crashes when using -l argument.

Signed-off-by: Kristian Amlie 
---
 tools/env/fw_env_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
index d93a915..fb4afa5 100644
--- a/tools/env/fw_env_main.c
+++ b/tools/env/fw_env_main.c
@@ -239,7 +239,7 @@ int main(int argc, char *argv[])
argv += optind;
 
if (env_opts.lockname) {
-   lockname = malloc(sizeof(env_opts.lockname) +
+   lockname = malloc(strlen(env_opts.lockname) +
sizeof(CMD_PRINTENV) + 10);
if (!lockname) {
fprintf(stderr, "Unable allocate memory");
-- 
2.7.4

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

[U-Boot] Raspberry Pi USB storage broken after 64 byte device descriptor patch

2018-01-30 Thread Kristian Amlie 
I have a recent problem with USB storage on the Raspberry Pi 3 with
U-Boot. Take a look at the output from v2017.01:

--
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
--

which is the correct output. And compare to v2018.01:

--
USB0:   Core Release: 2.80a
scanning bus 0 for devices... unable to get device descriptor(error=-110)
3 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
--

I'm unable to use USB storage afterwards, such as "ls usb 0".

I have bisected the commits and found that the problem was introduced in
the commit below. I am not familiar enough with USB internals to comment
on the correctness of the commit, but apparently it's not working
entirely as expected. Maybe the original author can comment?

--
commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2
Author: Bin Meng 
Date:   Mon Sep 18 15:40:42 2017

usb: Only get 64 bytes device descriptor for full speed devices

Full speed device endpoint 0 can have 8/16/32/64 bMaxPacketSize0.
Other speed devices report fixed value per USB spec. So it only
makes sense if we send a get device descriptor with 64 bytes to
full speed devices.

While we are here, update the comment block to be within 80 cols.

Signed-off-by: Bin Meng 
--

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

Re: [U-Boot] Targets for BeagleBones

2016-12-27 Thread Kristian Amlie 
On 27/12/16 09:22, Peter Robinson wrote:
> On Tue, Dec 27, 2016 at 8:00 AM, Kristian Amlie
>  wrote:
>> Nobody knows?
>>
>> To put it differently: If you were building for Beaglebone White, which
>> target would you use?
> 
> In Fedora we use am335x_boneblack for all BBones. I've tested on
> black/white/green, have a BBone Air too but not had time to test it
> yet. So it should likely be renamed to something more generic but it
> should work for you on any.

Thanks, that's very helpful!

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

Re: [U-Boot] Targets for BeagleBones

2016-12-27 Thread Kristian Amlie 
Nobody knows?

To put it differently: If you were building for Beaglebone White, which
target would you use?

-- 
Kristian

On 20/12/16 09:09, Kristian Amlie wrote:
> I assume that the most appropriate configuration target for BeagleBone
> Black is am335x_boneblack_config. But what about BeagleBone White? Up
> until now we've been using am335x_evm_config, but are considering
> switching to the former.
> 
> This discussion started after the commit 80b24fcd3 in U-Boot broke some
> MMC compatibility on the BeagleBone Black (specifically, accessing the
> internal MMC when holding the button to boot from external MMC). This
> was due to the addition of the CONFIG_DM_MMC option. Since this still
> works with the am335_boneblack_config target, we're considering the
> switch for both boards.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Targets for BeagleBones

2016-12-20 Thread Kristian Amlie 
I assume that the most appropriate configuration target for BeagleBone
Black is am335x_boneblack_config. But what about BeagleBone White? Up
until now we've been using am335x_evm_config, but are considering
switching to the former.

This discussion started after the commit 80b24fcd3 in U-Boot broke some
MMC compatibility on the BeagleBone Black (specifically, accessing the
internal MMC when holding the button to boot from external MMC). This
was due to the addition of the CONFIG_DM_MMC option. Since this still
works with the am335_boneblack_config target, we're considering the
switch for both boards.

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

Re: [U-Boot] Environment storage format stability

2016-12-15 Thread Kristian Amlie 
On 15/12/16 17:21, Wolfgang Denk wrote:
> Dear Kristian,
> 
> In message <7f7560f1-5b05-1f0c-8bf0-fd0458f9d...@mender.io> you wrote:
>> I have a question about the format of the environment when stored on
>> persistent storage: Is this format considered stable?
> 
> Yes, it is.  It has never been changed since it has been invented in
> the first days of this project, when it was still sailing under the
> name PPCboot, and there are no plans or discussions to change it,
> either.
> 
>> The reason I'm asking is whether it is a reasonable assumption that
>> upgraded user space tools (fw_setenv and fw_printenv) will agree on the
>> format with an older boot loader. The user space tools may be upgraded
>> as part of a rootfs update, but the boot loader typically will not.
> 
> As of now, you can still read the environment of a 16 year old PPCBoot
> :-)

Perfect, thanks! :-)

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

[U-Boot] Environment storage format stability

2016-12-15 Thread Kristian Amlie 
I have a question about the format of the environment when stored on
persistent storage: Is this format considered stable?

The reason I'm asking is whether it is a reasonable assumption that
upgraded user space tools (fw_setenv and fw_printenv) will agree on the
format with an older boot loader. The user space tools may be upgraded
as part of a rootfs update, but the boot loader typically will not.

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