t; The implementation is based on original implementation from Ard Biesheuvel in
> Linux kernel [2]
>
> [1]
> https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0
> [2]
> https://git.kernel.org/pub/scm
On Thu, 4 Jan 2024 at 18:53, Chiu, Chasel wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel
> > Sent: Thursday, January 4, 2024 12:43 AM
> > To: Chiu, Chasel
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > Rutland
&
On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel
> > Sent: Wednesday, January 3, 2024 7:22 AM
> > To: Chiu, Chasel
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > Rutland
&
On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel wrote:
>
>
> Please see my reply below inline.
>
> Thanks,
> Chasel
>
...
> > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > defaults, and the actual memory type information is kept in a
> > > > non-volatile EFI variable,
On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel wrote:
>
>
> Hi Ard,
>
> Please see my reply below inline and let me know your thoughts.
>
> Thanks,
> Chasel
>
>
> > -----Original Message-
> > From: Ard Biesheuvel
> > Sent: Thursday, December 21,
On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel wrote:
>
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel
> > Sent: Tuesday, November 28, 2023 10:08 AM
> > To: Chiu, Chasel
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > Rutlan
e regions in
a way where the operating system might be expected to interpret this
information and act upon it.
>
> > -Original Message-
> > From: Chiu, Chasel
> > Sent: Tuesday, November 21, 2023 10:34 AM
> > To: Ard Biesheuvel ; Simon Glass
> > Cc: devic
On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:
>
> Hi,
>
> On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:
> >
> >
> > Hi Ard,
> >
> > Please see my reply below inline.
> >
> > Thanks,
> > Chasel
> >
> >
> >
l > ker...@vger.kernel.org>; Dhaval Sharma ; Brune,
> > Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; Chiu, Chasel ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List ; Ard
> > Biesheuvel ; Simon Glass
> >
On Wed, 8 Nov 2023 at 14:57, Rob Herring wrote:
>
> On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel wrote:
> >
> > On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:
> > >
> > >
> > > All of this:
> > >
> &
On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:
>
>
> All of this:
>
> > On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:
> > >
> > > It is not specific to EDK2. Imagine this boot sequence:
> > >
> > > - Platform Init (U-Boot) starts up
> > > - U-Boot uses its platform knowledge to sets some
On Sat, 7 Oct 2023 at 02:03, Simon Glass wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard
On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:
> >
> > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, 26 Sept 2023 at 13:4
On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:
> >
> > It is common to split firmware into 'Platform Init', which does the
> > initial hardware setup and a "Payload" which selects the OS to be booted.
> > Thus an handover
On Thu, 7 Sept 2023 at 17:57, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 09:07, Ard Biesheuvel wrote:
> >
> > On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 7 Sept 2023 at 08:12
On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel wrote:
> >
> > On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 7 Sept 2023 at 07:31
On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel wrote:
> >
> > On Wed, 6 Sept 2023 at 18:50, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Wed, Sep 6, 2023, 10:09 Ar
On Wed, 6 Sept 2023 at 18:50, Simon Glass wrote:
>
> Hi Ard,
>
> On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel wrote:
>>
>> On Wed, 6 Sept 2023 at 16:54, Simon Glass wrote:
>> >
>> > Hi Rob, Ard,
>> >
>> > On Wed, 6 Sept 2023 at 08:34, R
On Wed, 6 Sept 2023 at 16:54, Simon Glass wrote:
>
> Hi Rob, Ard,
>
> On Wed, 6 Sept 2023 at 08:34, Rob Herring wrote:
> >
> > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel wrote:
> > >
> > > On Thu, 31 Aug 2023 at 01:18, Simon Glass wrote:
> >
On Thu, 31 Aug 2023 at 01:18, Simon Glass wrote:
>
> The Devicetree specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
>
> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload"
On Fri, 1 Sept 2023 at 03:12, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 16:39, Ard Biesheuvel wrote:
> >
> > On Fri, 1 Sept 2023 at 00:17, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 31 Aug 2023 at 15:48
On Fri, 1 Sept 2023 at 00:17, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 15:48, Ard Biesheuvel wrote:
> >
> > On Thu, 31 Aug 2023 at 21:03, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 31 Aug 2023 at 06:28
On Thu, 31 Aug 2023 at 21:03, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 31 Aug 2023 at 06:28, Ard Biesheuvel wrote:
> >
> > On Wed, 30 Aug 2023 at 23:11, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Tue, 29 Aug 2023 at 15:32
On Wed, 30 Aug 2023 at 23:11, Simon Glass wrote:
>
> Hi Ard,
>
> On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel wrote:
> >
> > On Tue, 29 Aug 2023 at 21:18, Simon Glass wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, 24 Aug 2023 at 03:10
On Tue, 29 Aug 2023 at 21:18, Simon Glass wrote:
>
> Hi Ard,
>
> On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel wrote:
> >
> > On Wed, 23 Aug 2023 at 22:04, Simon Glass wrote:
> > >
> > > Hi,
> > >
> > > On Wed, 23 Aug 2023 at 08:24
On Wed, 23 Aug 2023 at 22:04, Simon Glass wrote:
>
> Hi,
>
> On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel wrote:
> >
> > On Wed, 23 Aug 2023 at 10:59, Mark Rutland wrote:
> > >
> > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
>
On Wed, 23 Aug 2023 at 10:59, Mark Rutland wrote:
>
> On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
> > The Devicetree specification skips over handling of a logical view of
> > the memory map, pointing users to the UEFI specification.
> >
> > It is common to split firmware into
On Thu, 9 Feb 2023 at 19:05, Simon Glass wrote:
>
> Hi Jan,
>
> On Wed, 8 Feb 2023 at 01:15, Jan Lübbe wrote:
> >
> > On Tue, 2023-02-07 at 11:39 -0700, Simon Glass wrote:
> > > Hi Jan,
> > >
> > > On Tue, 7 Feb 2023 at 08:39, Jan Lübbe wrote:
> > > >
> > > > On Tue, 2023-02-07 at 06:38 -0700,
On Thu, 16 Dec 2021 at 18:55, Mark Kettenis wrote:
>
> > From: Ard Biesheuvel
> > Date: Thu, 16 Dec 2021 18:12:02 +0100
> >
> > On Thu, 16 Dec 2021 at 17:56, Mark Kettenis wrote:
> > >
> > > > From: Ard Biesheuvel
> > > > Dat
On Thu, 16 Dec 2021 at 17:56, Mark Kettenis wrote:
>
> > From: Ard Biesheuvel
> > Date: Thu, 16 Dec 2021 15:54:55 +0100
>
> Hi Ard, Ilias,
>
> > On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
> > wrote:
> > >
> > > Right now we unco
On Thu, 16 Dec 2021 at 16:25, Mark Kettenis wrote:
>
> > From: Ilias Apalodimas
> > Date: Thu, 16 Dec 2021 16:52:08 +0200
> >
> > Right now we unconditionally pass a 'kaslr-seed' property to the kernel
> > if the DTB we ended up in EFI includes the entry. However the kernel
> > EFI stub
o let's get rid of it unconditionally since it would mess up the
> (upcoming) DTB TPM measuring as well.
>
> Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
Note that the EFI stub itself does not consume the DTB /chosen entry
for its own randomness needs (i.e., the randomization o
ever used. Please, remove the assignment.
> >
> > > + u64 aligned_mem;
> > > + efi_status_t r;
> > > + u64 mem;
> > > +
> >
> > Please add a comment:
> >
> > /* Align must be a power of two */
> >
> > I can apply these changes when merging.
>
> Ok the changes seem fine to me. Wait a few days in case Ard sees
> this, so he can verify the changes are what the kernel expects.
>
Should be fine if it results in the correct alignment, and makes the
error message go away.
Acked-by: Ard Biesheuvel
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:
> >>
> >>
> >> --------
> >> *V
On Tue, 31 Aug 2021 at 18:59, Heinrich Schuchardt wrote:
>
>
>
> On 8/31/21 1:12 PM, Kristian Amlie wrote:
> > On 31/08/2021 12:46, Heinrich Schuchardt wrote:
> >>
> >>
> >> --------
&g
On Thu, 29 Apr 2021 at 18:11, Simon Glass wrote:
>
> Hi Patrick,
>
> On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay
> wrote:
> >
> > Save the no-map information present in 'reserved-memory' node to allow
> > correct handling when the MMU is configured in board to avoid
> > speculative access.
>
On Thu, 11 Feb 2021 at 16:34, Heinrich Schuchardt wrote:
>
> On 11.02.21 15:56, Ard Biesheuvel wrote:
> > On Thu, 11 Feb 2021 at 15:18, Heinrich Schuchardt
> > wrote:
> >>
> >> On 11.02.21 13:04, Igor Opaniuk wrote:
> >>> From: Igor Opaniu
On Thu, 11 Feb 2021 at 15:18, Heinrich Schuchardt wrote:
>
> On 11.02.21 13:04, Igor Opaniuk wrote:
> > From: Igor Opaniuk
> >
> > When LPAE is enabled, 1:1 mapping is created using 2 MB blocks.
> > In case amount of memory provided to QEMU is not multiple
> > of 2 MB, round down the amount of
On Fri, 5 Feb 2021 at 18:38, Igor Opaniuk wrote:
>
> Hi,
>
> With this commit 3fa914af82("arm: qemu: implement enable_caches()")
> introduced,
> which enables instruction/data caches for qemu-arm target,
> U-Boot sometimes hangs during MMU init procedure :
>
> DRAM: 1 GiB
> initcall: 60011df8
>
On Thu, 29 Oct 2020 at 17:06, Etienne Carriere
wrote:
>
> On Thu, 29 Oct 2020 at 12:26, Ard Biesheuvel wrote:
> >
> > On Thu, 29 Oct 2020 at 11:40, Etienne Carriere
> > wrote:
> > >
> > > Dear all,
> > >
> > > CC some
On Thu, 29 Oct 2020 at 11:40, Etienne Carriere
wrote:
>
> Dear all,
>
> CC some fellow OP-TEE guys for this secure memory description topic.
>
>
> On Wed, 28 Oct 2020 at 11:33, Patrick DELAUNAY
> wrote:
> >
> > Hi,
> >
> > > From: Ard
On Tue, 27 Oct 2020 at 18:25, Tom Rini wrote:
>
> On Fri, Oct 09, 2020 at 05:00:44PM +, Patrick DELAUNAY wrote:
> > Hi Ard,
> >
> > > From: Ard Biesheuvel
> > > Sent: mercredi 7 octobre 2020 15:16
> > >
> > > On Wed, 7 Oct 202
On Mon, 12 Oct 2020 at 11:51, Etienne Carriere
wrote:
>
> On Mon, 12 Oct 2020 at 11:20, Ard Biesheuvel wrote:
> >
> > On Mon, 12 Oct 2020 at 11:09, Etienne Carriere
> > wrote:
> > >
> > > On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum wrote:
> > >
On Mon, 12 Oct 2020 at 11:09, Etienne Carriere
wrote:
>
> On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum wrote:
> >
> > Hello Patrick,
> >
> > On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > > I checked DACR behavior and CheckDomain / CheckPermission
> > >
> > > In my case the cortex A7 try to
On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum wrote:
>
> Hello Patrick,
>
> On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > I checked DACR behavior and CheckDomain / CheckPermission
> >
> > In my case the cortex A7 try to access to part of DDR / mapped cacheable
> > and bufferable, protected by
On Fri, 9 Oct 2020 at 13:19, Patrick DELAUNAY wrote:
>
> Hi Ard,
>
> > From: Ard Biesheuvel
> > Sent: mercredi 7 octobre 2020 12:27
> >
> > On Tue, 6 Oct 2020 at 18:36, Patrick Delaunay
> > wrote:
> > >
> > >
> > > Hi,
&
On Wed, 7 Oct 2020 at 16:55, Etienne Carriere
wrote:
>
> Hello all,
>
> On Wed, 7 Oct 2020 at 15:16, Ard Biesheuvel wrote:
> >
> > On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum wrote:
> > >
> > > Hello,
> > >
> > > On 10/7/20 1:23 PM, Ahma
On Wed, 7 Oct 2020 at 13:53, Ahmad Fatoum wrote:
>
> Hello,
>
> On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> > My findings[1] back then were that U-Boot did set the eXecute Never bit
> > only on
> > OMAP, but not for other platforms. So I could imagine this being the root
> > cause
> > of
On Tue, 6 Oct 2020 at 18:36, Patrick Delaunay wrote:
>
>
> Hi,
>
> On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
> protected by a firewall. This region is reserved in device with "no-map"
> property.
>
> But sometime the platform boot failed in U-boot on a Cortex A7 access
On Tue, 6 Oct 2020 at 17:09, François Ozog wrote:
>
>
> On Tue, 6 Oct 2020 at 16:46, Ard Biesheuvel wrote:
>
>>
>>
>> On Tue, 6 Oct 2020 at 16:22, François Ozog
>> wrote:
>>
>>> Ard, there is a question for you in the below thread ;-)
>&
On Tue, 6 Oct 2020 at 16:22, François Ozog wrote:
> Ard, there is a question for you in the below thread ;-)
>
> On Tue, 6 Oct 2020 at 15:02, Grant Likely wrote:
>
>>
>>
>> On 06/10/2020 13:52, Heinrich Schuchardt wrote:
>> > On 06.10.20 14:43, Grant Likely wrote:
>> >
>> >>
>> >> Current
On Tue, 6 Oct 2020 at 12:13, François Ozog wrote:
>
>
> On Tue, 6 Oct 2020 at 10:06, Ard Biesheuvel wrote:
>
>>
>>
>> On Tue, 6 Oct 2020 at 10:00, François Ozog
>> wrote:
>>
>>>
>>>
>>> Le mar. 6 oct. 2020 à 09:21, Ard
On Tue, 6 Oct 2020 at 10:00, François Ozog wrote:
>
>
> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel a écrit :
>
>> On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt
>> wrote:
>> >
>> > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
>>
On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt wrote:
>
> Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely :
> >
> >
> >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
> >> Hello Ilias, hello Christian,
> >>
> >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
> >initramfs
>
On Sat, 3 Oct 2020 at 18:35, Heinrich Schuchardt wrote:
>
> On 10/3/20 3:12 PM, Ard Biesheuvel wrote:
> >
> >
> > On Sat, 3 Oct 2020 at 13:16, François Ozog > <mailto:francois.o...@linaro.org>> wrote:
> >
> >
> >
> > Le sam.
On Sat, 3 Oct 2020 at 13:16, François Ozog wrote:
>
>
> Le sam. 3 oct. 2020 à 13:14, François Ozog a
> écrit :
>
>>
>>
>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt a
>> écrit :
>>
>>> Hello Ilias, hello Christian,
>>>
>>>
>>>
>>> with commit ec80b4735a59 ("efi_loader: Implement
On Thu, 24 Sep 2020 at 16:45, André Przywara wrote:
>
> On 24/09/2020 01:17, Andre Przywara wrote:
> > When the actual offset between link and runtime address is zero, there
> > is no need for patching up U-Boot early when running with
> > CONFIG_POSITION_INDEPENDENT.
>
> That turns out to be not
On Thu, 24 Sep 2020 at 09:58, Amit Tomar wrote:
>
> Hi,
>
> Andre Przywara (5):
>>
>> arm64: PIE: Skip fixups if distance is zero
>> arm64: PIE: Allow fixed stack pointer
>> qemu-arm: Remove need to specify flash banks
>> qemu: Drop ARCH_SUPPORT_TFABOOT
>> qemu/arm64: Enable
On Fri, 4 Sep 2020 at 13:51, Patrick Delaunay wrote:
>
> arm: cache: cp15: don't map reserved region with no-map property
>
> Hi,
>
> On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region protected
> by a firewall. This region is reserved in device with "no-map" property.
>
> But
accessors that we need to (patch #5)
- add Heinrich's ack to #2 and #4
Cc: Tom Rini
Cc: Andre Przywara
Cc: Heinrich Schuchardt
Cc: Tuomas Tynkkynen
Ard Biesheuvel (5):
arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH
arm: qemu: enable LPAE on 32-bit
arm: qemu
-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs
for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.
Signed-off-by: Ard Biesheuvel
Acked-by: Heinrich Schuchardt
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs
. Note that the the 64-bit wide read and write accessors have
been omitted: they are never used when running under QEMU given that it
does not emulate CFI flash that supports it.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 45
include/configs/qemu
Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 7 +++
1 file changed, 7 insertions
-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/system.h | 23
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include
On Thu, 11 Jun 2020 at 10:17, Ard Biesheuvel wrote:
>
> Some instructions in the ARM ISA have multiple output registers, such
> as ldrd/ldp (load pair), where two registers are loaded from memory,
> but also ldr with indexing, where the memory base register is incremented
> as well
. Note that the the 64-bit wide read accessors and all the write
accessors have been omitted: they are either never used to begin with, or
don't suffer from the MMIO emulation issue (as str instructions don't have
multiple output registers)
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu
Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 7 +++
1 file changed, 7 insertions
-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs
for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.
Signed-off-by: Ard Biesheuvel
Acked-by: Heinrich Schuchardt
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs
-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/system.h | 23
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include
Cc: Andre Przywara
Cc: Heinrich Schuchardt
Cc: Tuomas Tynkkynen
Ard Biesheuvel (5):
arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH
arm: qemu: enable LPAE on 32-bit
arm: qemu: implement enable_caches()
arm: qemu: disable the EFI workaround for older GRUB
arm
On Sun, 7 Jun 2020 at 13:03, Heinrich Schuchardt wrote:
>
> Am June 7, 2020 8:59:00 AM UTC schrieb Ard Biesheuvel :
> >On Sat, 6 Jun 2020 at 22:49, Heinrich Schuchardt
> >wrote:
> >>
> >> On 6/6/20 10:32 PM, Heinrich Schuchardt wrote:
> >&
On Sat, 6 Jun 2020 at 22:49, Heinrich Schuchardt wrote:
>
> On 6/6/20 10:32 PM, Heinrich Schuchardt wrote:
> > On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> >> QEMU's mach-virt machine only supports selecting CPU models that
> >> implement the virtualization extensions
On Sat, 6 Jun 2020 at 22:14, Heinrich Schuchardt wrote:
>
> On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> > The LPAE version of DCACHE_WRITEBACK is currently defined as no-allocate
> > for both reads and writes, which deviates from the non-LPAE definition,
> > and mo
On Sat, 6 Jun 2020 at 23:08, Heinrich Schuchardt wrote:
>
> On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> > Some instructions in the ARM ISA have multiple output registers, such
> > as ldrd/ldp (load pair), where two registers are loaded from memory,
> > but also ldr with in
-off-by: Ard Biesheuvel
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 75bdce7708c7..1d2b4437cb07 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB=y
accessors are included for completeness, but the
read accessors are the ones that need this special care.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 55
include/configs/qemu-arm.h | 1 +
2 files changed, 56 insertions(+)
diff --git a/board
Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 7 +++
1 file changed, 7 insertions
The LPAE version of DCACHE_WRITEBACK is currently defined as no-allocate
for both reads and writes, which deviates from the non-LPAE definition,
and mostly defeats the purpose of enabling the caches in the first place.
So align LPAE with !LPAE, and enable allocate-on-read.
Signed-off-by: Ard
for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.
Signed-off-by: Ard Biesheuvel
---
configs/qemu_arm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index
can boot Linux in EFI mode under
KVM.
Cc: Tom Rini
Cc: Sughosh Ganu
Cc: Heinrich Schuchardt
Ard Biesheuvel (5):
arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK
arm: qemu: enable LPAE on 32-bit
arm: qemu: implement enable_caches()
arm: qemu: disable the EFI workaround for older
On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt wrote:
>
> On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > On Mon, 6 Apr 2020 at 22:45, Atish Patra wrote:
> >>
> >> This series adds few DT related fixes required for Linux EFI stub to work
> >> o
On Mon, 6 Apr 2020 at 22:45, Atish Patra wrote:
>
> This series adds few DT related fixes required for Linux EFI stub to work
> on RISC-V.
>
I'm not sure how this is supposed to work, since DT reserved memory
regions are not used by EFI. If you want to reserve memory on a UEFI
system, you have
On Thu, 5 Mar 2020 at 04:28, Schaefer, Daniel (DualStudy)
wrote:
>
> Hi,
>
> I have started to implement the corresponding changes in EDK2:
> https://github.com/changab/edk2-staging-riscv/compare/5f63e9249751ccb9302514455b9a1a7038f34547...RISC-V-DT-fixup
> What happens is: The DTB is embedded in
On Tue, 25 Feb 2020 at 09:59, Chang, Abner (HPS SW/FW Technologist)
wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Tuesday, February 25, 2020 4:48 PM
> > To: Chang, Abner (HPS SW/FW Technologist
On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist)
wrote:
>
>
>
> > -Original Message-
> > From: Atish Patra [mailto:ati...@atishpatra.org]
> >
> > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel
> > wrote:
> > >
> &g
On Mon, 24 Feb 2020 at 23:20, Atish Patra wrote:
>
> Linux booting protocol mandates that register "a0" contains the hartid.
> However, U-boot can not pass the hartid via a0 during EFI boot without
> breaking the UEFI specification.
>
It is not about breaking or violating the UEFI specification.
On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt wrote:
>
> On 2/24/20 11:19 PM, Atish Patra wrote:
> > The RISC-V booting protocol requires the hart id to be present in "a0"
> > register. This is not a problem for bootm/booti commands as they directly
> > jump to Linux kernel. However, bootefi
On Wed, 19 Feb 2020 at 21:00, Heinrich Schuchardt wrote:
>
> UEFI spec 2.8 errata A replaces the RuntimeServicesSupported variable
> defined in UEFI spec 2.8 by the configuration table
> EFI_RT_PROPERTIES_TABLE. So let's follow suit.
>
> Cc: Ard Biesheuvel
> Signed-off-by
On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist)
wrote:
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, February 14, 2020 7:33 PM
> > To: Chang, Abner (HPS SW/FW Technologist
On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist)
wrote:
>
>
>
> > -Original Message-
> > From: Alexander Graf [mailto:ag...@csgraf.de]
> > Sent: Friday, February 14, 2020 4:07 PM
> > To: Chang, Abner (HPS SW/FW Technologist)
>
On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote:
>
> On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel
> wrote:
> >
> > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist)
> > wrote:
> > >
> > >
> > >
> > >
On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist)
wrote:
>
>
>
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Wednesday, February 12, 2020 2:26 AM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
On Thu, 6 Feb 2020 at 21:06, Atish Patra wrote:
>
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf wrote:
> >
> >
> > On 06.02.20 19:28, Atish Patra wrote:
> > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > > wrote:
> > >> On Wed, 5
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt wrote:
>
> RISC-V booting currently is based on a per boot stage lottery to determine
> the active CPU. The Hart State Management (HSM) SBI extension replaces
> this lottery by using a dedicated primary CPU.
>
> Cf. Hart State Management Extension,
On Sun, 23 Jun 2019 at 23:47, Alexander Graf wrote:
>
>
>
> > Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt :
> >
> > Hello Alex,
> >
> > on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least
> > since U-Boot v2019.01. See below.
> >
> > In the code for
On Fri, 21 Jun 2019 at 09:37, Alexander Graf wrote:
>
>
> On 20.06.19 23:59, Heinrich Schuchardt wrote:
> > Hello Alex,
> >
> > currently we have two code sections in U-Boot:
> >
> > * __efi_runtime/__efi_runtime_data (mapped to EFI_RUNTIME_SERVICES_CODE)
> > * all other code (mapped to
e
> >> services implementation.
> >> Let's change the type to EFI_BOOT_SERVICES_DATA
> >>
> >> This also fixes booting of armv7 using efi and fdtcontroladdr
> >>
> >> Suggested-by: Ard Biesheuvel
> >> Signed-off-by: Ilias Apalodimas
On Fri, 12 Apr 2019 at 10:44, Heinrich Schuchardt wrote:
>
> On 4/12/19 7:24 PM, Ard Biesheuvel wrote:
> > On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt
> > wrote:
> >>
> >> On 4/11/19 10:50 PM, Ard Biesheuvel wrote:
> >>> On Thu, 11 Apr
1 - 100 of 115 matches
Mail list logo
