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

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

Re: [PATCH v1] vexpress_ca9x4: Enable DM_SERIAL

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

Re: vexpress and DM_SERIAL

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

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

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

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

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

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

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

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

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 q

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

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

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

) (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

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

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

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

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:*

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

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.

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_load

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

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.

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

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

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

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

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

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

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 f95b8a

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

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. >&

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

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

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

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 loadad

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

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 &

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

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 i

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

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

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

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. Kristia

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

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

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

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, requ

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

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

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

Without a description they always revert to their defaults regardless of what is in the defconfig file. Signed-off-by: Kristian Amlie <kristian.am...@northern.tech> --- env/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/env/Kconfig b/env/Kconfig index b

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

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 <kristian.am...@northern.tech> --- tools/env/fw_env_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/too

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

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

Re: [U-Boot] Targets for BeagleBones

On 27/12/16 09:22, Peter Robinson wrote: > On Tue, Dec 27, 2016 at 8:00 AM, Kristian Amlie > <kristian.am...@mender.io> wrote: >> Nobody knows? >> >> To put it differently: If you were building for Beaglebone White, which >> target would you use? > >

Re: [U-Boot] Targets for BeagleBones

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

[U-Boot] Targets for BeagleBones

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

Re: [U-Boot] Environment storage format stability

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

[U-Boot] Environment storage format stability

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.