uires when modifying page tables that the MMU is using and
> the question therefore was: can setup_pgtables() be called on such live PTs?
>
> For most AArch64 U-Boot ports (including the i.MX family), the answer is
> trivial
> because they use the arch code i.e. setup_all_pgtables(). However, as
> fsl-layerscape re-implements mmu_setup(), it had to be looked at separately,
> hence my question, which you answered above.
Thanks for the details.
With that,
Reviewed-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
On Mon, 18 Mar 2024 19:35:49 +,
Pierre-Clément Tosi wrote:
>
> The implementation of map_range() creates the requested mapping by
> walking the page tables, iterating over multiple PTEs and/or descending
> into existing table mappings as needed. When doing so, it assumes any
> pre-existing va
On Sat, 09 Mar 2024 12:29:10 +,
Fabio Estevam wrote:
>
> Hi Marc,
>
> On Sat, Mar 9, 2024 at 6:53 AM Marc Zyngier wrote:
>
> > It would be good to narrow down which access is generating this. It is
> > an asynchronous error, so the code above won't help.
&
On Fri, 08 Mar 2024 20:22:53 +,
Fabio Estevam wrote:
>
> Hi Paul and Tom,
>
> On Tue, Feb 14, 2023 at 10:38 AM Ying-Chun Liu (PaulLiu)
> wrote:
> >
> > From: Marc Zyngier
> >
> > In the add_map() function, for each level it populates, it iterates f
[Fixing Ard's email address for something more current.]
On Sat, 10 Feb 2024 12:07:09 +,
Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto
> Extensions. The CPU should support ARMv8.2 instruction set and implement
> SHA
On 2023-12-22 12:33, Ivan T. Ivanov wrote:
On 12-22 12:19, Marc Zyngier wrote:
Hi Ivan,
On 2023-12-18 21:03, Ivan T. Ivanov wrote:
> Hi,
>
> These patches are adding basic support for RPi5.
> They are based on v2 series from Dmitry Malkin[1].
>
> With them I am able
Hi Ivan,
On 2023-12-18 21:03, Ivan T. Ivanov wrote:
Hi,
These patches are adding basic support for RPi5.
They are based on v2 series from Dmitry Malkin[1].
With them I am able to _start_ current openSUSE
Tumbleweed without modification. They are still
a lot of things to be added to the upstrea
Hi Pierre-Clément,
On Fri, 27 Oct 2023 10:49:47 +0100,
Pierre-Clément Tosi wrote:
>
> Hi Chris,
>
> On Fri, Oct 27, 2023 at 01:23:51PM +1300, Chris Packham wrote:
> > As discussed this series reverts the HAFDBS changes that caused an issue
> > on AC5/AC5X. I think there are some improvements th
On 2023-10-18 21:53, Chris Packham wrote:
Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
when available") the default get_page_table_size() sets some flags for
more efficient handling of dirty page table entries. This causes
problems on the AC5/AC5X SoC (specifically a lo
On Mon, 16 Oct 2023 02:42:08 +0100,
Chris Packham wrote:
>
> On Sun, Oct 15, 2023 at 10:29 AM Chris Packham
> wrote:
> >
> >
> >
> > On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote:
> >>
> >> On 2023-10-13 03:40, Chris Packham wrote:
>
On 2023-10-13 03:40, Chris Packham wrote:
Hi Marc, Paul,
On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu)
wrote:
From: Marc Zyngier
Some recent arm64 cores have a facility that allows the page
table walker to track the dirty state of a page. This makes it
really efficient to perform
On Fri, 25 Aug 2023 19:05:32 +0100,
Sam Edwards wrote:
>
> On 8/25/23 00:20, Chen-Yu Tsai wrote:
>
> Hi Chen-Yu,
>
> > IIRC the GIC manual says that the secure bit is set or cleared to select
> > which bank of registers is accessed.
>
> Which secure bit are we talking about here? Do we mean th
On Mon, 14 Aug 2023 21:39:10 +0100,
Andre Przywara wrote:
>
> On Wed, 31 May 2023 14:15:20 -0600
> Sam Edwards wrote:
>
> Hi,
>
> (CC:ing Marc and Chen-Yu as the original authors)
>
> sorry for the delay, found that mouldering in my Drafts folder.
>
> > The nonsec code overrides/handles thes
On Tue, 01 Aug 2023 09:53:52 +0100,
Oliver Graute wrote:
>
> On 14/02/23, Ying-Chun Liu (PaulLiu) wrote:
> > From: Marc Zyngier
> >
> > In the add_map() function, for each level it populates, it iterates from
> > the root of the PT tree, making it ineficie
On Mon, 26 Jun 2023 10:00:09 +0100,
"Lim, Jit Loon" wrote:
>
>
>
> > -Original Message-
> > From: Marek Vasut
> > Sent: Wednesday, 21 June, 2023 10:20 PM
> > To: Marc Zyngier ; Lim, Jit Loon
> > Cc: u-boot@lists.denx.de; Jagan Teki ;
On Wed, 21 Jun 2023 15:06:51 +0100,
Jit Loon Lim wrote:
>
> From: Kah Jing Lee
>
> Dcache feature is not enabled in SPL and enable it will cause ISR
> exception. Since the Dcache is not supported in SPL, new
> CONFIG_SPL_SYS_DISABLE_DCACHE_OPS is added to Kconfig to disable Dcache
> in SPL.
>
On Tue, 07 Feb 2023 17:18:27 +,
Paul Liu wrote:
>
> Hi Marc,
>
> I think you are the author. I'm just making some minor fixes and
> then upstreaming to the mailing list. What is the correct way to
> make the Signed-off-by list?
In general, and unless you have completely rewritten the patch
On Tue, 07 Feb 2023 16:40:05 +,
Tom Rini wrote:
>
> On Tue, Feb 07, 2023 at 04:35:25PM +, Marc Zyngier wrote:
> > On 2023-02-07 16:20, Ying-Chun Liu (PaulLiu) wrote:
> > > Exposing set/way cache maintenance to a virtual machine is unsafe, not
> > > least be
can select
this option and perform by-VA cache maintenance instead of using the
set/way instructions.
Signed-off-by: Ying-Chun Liu (PaulLiu)
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Cc: Tom Rini
The sign-off chain looks pretty odd. Either you are the author
of this patch, and I
On Fri, 25 Feb 2022 13:41:06 +,
Zhiqiang Hou wrote:
>
> From: Hou Zhiqiang
>
> The current implementation needs the caller provides the memory region
> for the property and pending tables and the number of re-distibutor,
> and it doesn't handle the address alignment of the tables and doesn'
On Mon, 21 Feb 2022 10:24:36 +,
Michael Walle wrote:
>
> Hi,
>
> Am 2022-02-21 11:16, schrieb Wasim Khan:
> > From: Wasim Khan
> >
> > Memory after gd->arch.resv_ram is reserved for MC block.
> > Use ALIGN_DOWN to avoid updating MC block for unaligned
> > address.
>
> I cannot really tell
On Sun, 31 Oct 2021 16:45:41 +,
"Z.Q. Hou" wrote:
>
>
>
> > -Original Message-----
> > From: Marc Zyngier [mailto:m...@kernel.org]
> > Sent: 2021年10月29日 5:09
> > To: Michael Walle
> > Cc: u-boot@lists.denx.de; Vladimir Oltean ;
l28
> can do kexec also with booti (and not just bootefi). Anyway, I
> still have some remarks.
>
> Am 2021-10-28 23:09, schrieb Marc Zyngier:
> > On Wed, 27 Oct 2021 17:54:54 +0100,
> > Michael Walle wrote:
> >>
> >> Stop using the device tree a
a.dtsi | 6 --
> arch/arm/dts/fsl-ls1088a.dtsi | 6 --
> arch/arm/dts/fsl-ls2080a.dtsi | 6 --
> arch/arm/dts/fsl-lx2160a.dtsi | 6 --
> 5 files changed, 1 insertion(+), 41 deletions(-)
Acked-by: Marc Zyngier
I have a number of com
On Wed, 27 Oct 2021 17:54:54 +0100,
Michael Walle wrote:
>
> Stop using the device tree as a source for ad-hoc information.
>
> This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
>
> Signed-off-by: Michael Walle
> ---
> arch/arm/Kconfig| 2 -
> arch/arm/cpu
On Thu, 28 Oct 2021 12:21:59 +0100,
Michael Walle wrote:
>
> Am 2021-10-28 11:20, schrieb Bharat Gooty:
> > On Thu, Oct 28, 2021 at 2:33 PM Marc Zyngier wrote:
>
> > For GIC V3, once the LPI tables are programmed, we can not update it,
> > unless we do a reset.
>
On Thu, 28 Oct 2021 11:27:44 +0100,
Bharat Gooty wrote:
>
> [1 ]
> On Thu, Oct 28, 2021 at 3:19 PM Marc Zyngier wrote:
>
> > On Thu, 28 Oct 2021 10:20:53 +0100,
> > Bharat Gooty wrote:
> > >
> > > For GIC V3, once the LPI tables are programmed,
On Thu, 28 Oct 2021 13:31:13 +0100,
Tom Rini wrote:
>
> On Thu, Oct 28, 2021 at 10:01:34AM +0100, Marc Zyngier wrote:
> > On Wed, 27 Oct 2021 17:54:52 +0100,
> > Michael Walle wrote:
> > >
> > > Please stop throwing every ad-hoc information in the device t
On Thu, 28 Oct 2021 10:20:53 +0100,
Bharat Gooty wrote:
>
> For GIC V3, once the LPI tables are programmed, we can not update it,
> unless we do a reset.
Please tell me something I don't know...
> For the kexec kernel, where the reboot does not happen, in this case,
> during the new kernel boot
On Wed, 27 Oct 2021 17:54:52 +0100,
Michael Walle wrote:
>
> Please stop throwing every ad-hoc information in the device tree. Use the
> official bindings (or maybe some bindings which will get approved soon).
>
> On the quest of syncing the device tree used in u-boot with the one used in
> linu
Hi Mark,
On 2021-02-11 10:22, Mark Kettenis wrote:
Date: Thu, 11 Feb 2021 09:58:49 +
From: Marc Zyngier
On 2021-02-10 19:14, Mark Kettenis wrote:
> On implementations that support VHE, the layout of the CPTR_EL2
> register depends on whether HCR_EL2.E2H is set. If the bit is
EL1 code to enable access to the FP/SIMD registers. This allows
U-Boot to run on systems that pass control to U-Boot in EL2 with
EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis
---
v4: use EL1 codepath when HCR_EL2.E2H is set
suggested by Marc Zy
On 2020-12-07 07:14, Priyanka Jain wrote:
From: Nikhil Gupta
Add programming of GIC LPI configuration table:
1. Program Redistributor PROCBASER configuration table
The register name is GICR_PROPBASER.
which is common for all redistributors.
2. Program Redistributor pending table (PENDBAS
(host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE))
> >> - ctrl &= ~SDHCI_CTRL_HISPD;
> >> + if (!(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
> >
> > Should that be "&&" rather than "||"? Otherwise this will always
> > evaluate to true unless *both* quirks are set, which isn't
> > equivalent to the check being removed above.
>
>
> You're right.
It'd be great if you could respin this patch quickly and get it merged,
as it just helped me getting my NanoPC-T4 up and running.
FWIW:
Tested-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
On 15/06/18 13:51, Mark Kettenis wrote:
>> From: Marc Zyngier
>> Date: Fri, 15 Jun 2018 08:59:59 +0100
>>
>> On 14/06/18 21:55, Mark Kettenis wrote:
>>>> From: Marc Zyngier
>>>> Date: Thu, 14 Jun 2018 12:54:53 +0100
>>>>
>>>>
On 14/06/18 21:55, Mark Kettenis wrote:
>> From: Marc Zyngier
>> Date: Thu, 14 Jun 2018 12:54:53 +0100
>>
>> On 13/06/18 23:41, Mark Kettenis wrote:
>>> If desired (and possible) switch into HYP mode or non-secure SVC mode
>>> before calling the entry
On 13/06/18 23:41, Mark Kettenis wrote:
> If desired (and possible) switch into HYP mode or non-secure SVC mode
> before calling the entry point of an EFI application. This allows
> U-Boot to provide a usable PSCI implementation and makes it possible
> to boot kernels into hypervisor mode using an
e
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Tony Lindgren
> Cc: Robin Murphy
> Cc: Florian Fainelli
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Christoffer Dall
> Cc:
On Sat, 20 Jan 2018 12:29:22 +
Russell King wrote:
> On Sat, Jan 20, 2018 at 11:31:19AM +0000, Marc Zyngier wrote:
> > Define enough. These patches allow these CPUs to cope with variant-2,
> > and only variant-2. Variant-1 is still work in progress across all
> > arc
On Sat, 20 Jan 2018 11:45:08 +0100
Michael Nazzareno Trimarchi wrote:
> Hi Marc
>
> On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier wrote:
> > On Fri, 19 Jan 2018 16:56:14 -0500
> > Tom Rini wrote:
> >
> >> Hey all,
> >>
> >> So, now t
On Fri, 19 Jan 2018 23:21:44 +0100
Mark Kettenis wrote:
> > Date: Fri, 19 Jan 2018 16:56:14 -0500
> > From: Tom Rini
> >
> > Hey all,
> >
> > So, now that things have quieted down a little bit in this area, I've
> > been wondering about something. Over on the U-Boot side of things, are
> > th
On Fri, 19 Jan 2018 17:10:04 -0600
Nishanth Menon wrote:
> On 01/19/2018 04:21 PM, Mark Kettenis wrote:
> >> Date: Fri, 19 Jan 2018 16:56:14 -0500
> >> From: Tom Rini
> >>
> >> Hey all,
> >>
> >> So, now that things have quieted down a little bit in this area, I've
> >> been wondering about some
On Fri, 19 Jan 2018 16:56:14 -0500
Tom Rini wrote:
> Hey all,
>
> So, now that things have quieted down a little bit in this area, I've
> been wondering about something. Over on the U-Boot side of things, are
> there changes we need to make in order to support the kernel side of the
> various m
On 13/10/17 09:37, Michal Simek wrote:
> On 13.10.2017 10:33, Marc Zyngier wrote:
>> On 13/10/17 08:26, Michal Simek wrote:
>>> On 13.10.2017 09:19, Alexander Graf wrote:
>>>>
>>>>
>>>> On 13.10.17 09:08, Michal Simek wrote:
>>>>
On 13/10/17 08:26, Michal Simek wrote:
> On 13.10.2017 09:19, Alexander Graf wrote:
>>
>>
>> On 13.10.17 09:08, Michal Simek wrote:
>>> AArch32 Linux should start in EL1 instead of EL2.
>>
>> Why? There is KVM on AArch32 as well.
>
> Is AArch32 without KVM able to start from EL2?
> At least based
On Sun, 2 Jul 2017 20:36:04 +0800
wrote:
> 在 2017-07-02 19:22，Marc Zyngier 写道：
> > On Sun, 2 Jul 2017 15:08:12 +0800
> > wrote:
> >
> >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> >> > On Fri, Jun 23, 2017 at 9:39 PM, wrote:
&
:
> >>>>
> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
> >>>> > >
> >>>> > >
> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
&
On 07/06/17 14:04, Maxime Ripard wrote:
> On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote:
>> On 07/06/17 13:12, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier 写到:
>>>> On 07/06/17 08:00, Chen-Yu Tsai wro
On 07/06/17 13:12, Icenowy Zheng wrote:
>
>
> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier 写到:
>> On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>> wrote:
>>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Che
On 07/06/17 08:00, Chen-Yu Tsai wrote:
> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> wrote:
>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng wrote:
于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai 写到:
> On We
On 07/06/17 07:59, Icenowy Zheng wrote:
>
>
> 于 2017年6月7日 GMT+08:00 下午2:48:55, Maxime Ripard
> 写到:
>> Hi,
>>
>> On Wed, Jun 07, 2017 at 08:47:20AM +0800, Icenowy Zheng wrote:
>>> From: Chen-Yu Tsai
>>>
>>> Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
>>> contains 4 cores.
p Holla
Ah, that'd be a great reason for me to update the 2.5 year old u-boot
that lives on my TC2!
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Wed, 15 Jun 2016 15:16:08 +0800
Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Jun 14, 2016 at 3:01 PM, wrote:
> > From: Hongbo Zhang
> >
> > v5 changes:
> > - Give up fixing the potential bug of PSCI stack overlap with secure text
> > end
> > when there is more CPUs in system. Because I just want
is based on sunxi/next. Parts of it will likely conflict with
> the effort to support PSCI 1.0 on the Freescale LS102xA.
[...]
Thanks a lot for doing this and for following up on the review
comments; I'm quite pleased with how it ended-up, so please put my
Acked-by: Marc Zyngier
on a
On 27/05/16 05:22, Chen-Yu Tsai wrote:
> On Fri, May 27, 2016 at 1:19 AM, Marc Zyngier wrote:
>> On 26/05/16 15:01, Chen-Yu Tsai wrote:
>>> To make the PSCI backend more maintainable and easier to port to newer
>>> SoCs, rewrite the current PSCI implementation in C.
&
pu/armv7/sunxi/psci.c
> @@ -0,0 +1,269 @@
> +/*
> + * Copyright (C) 2016
> + * Author: Chen-Yu Tsai
> + *
> + * Based on assembly code by Marc Zyngier ,
> + * which was based on code by Carl van Schaik .
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
On 26/05/16 15:01, Chen-Yu Tsai wrote:
> The PSCI implementation expects at most 2 pages worth of space reserved
> at the end of the secure section for its stacks. If PSCI is relocated to
> secure SRAM, then everything is fine. If no secure SRAM is available,
> and PSCI remains in main memory, the
On 26/05/16 15:01, Chen-Yu Tsai wrote:
> Some common PSCI functions are written in assembly, but it should be
> possible to use them from C code.
>
> Add function declarations for C code to consume.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm/include/asm/psci.h | 8
> 1 file chang
On 25/05/16 03:14, Chen-Yu Tsai wrote:
> On Tue, May 24, 2016 at 4:41 PM, Marc Zyngier wrote:
>> On 23/05/16 13:41, Chen-Yu Tsai wrote:
>>> To make the PSCI backend more maintainable and easier to port to newer
>>> SoCs, rewrite the current PSCI implementation in C.
&
On 24/05/16 17:06, Chen-Yu Tsai wrote:
> On Tue, May 24, 2016 at 4:15 PM, Marc Zyngier wrote:
>> On 23/05/16 13:41, Chen-Yu Tsai wrote:
>>> Instead of listing individual registers for controls to each processor
>>> core, list them as an array of registers. This make
On 24/05/16 16:49, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, May 24, 2016 at 9:58 PM, Marc Zyngier wrote:
>> On 24/05/16 11:21, Marc Zyngier wrote:
>>> On 23/05/16 13:41, Chen-Yu Tsai wrote:
>>>> The PSCI implementation expects at most 2 pages worth of space re
On 24/05/16 11:21, Marc Zyngier wrote:
> On 23/05/16 13:41, Chen-Yu Tsai wrote:
>> The PSCI implementation expects at most 2 pages worth of space reserved
>> at the end of the secure section for its stacks. This was not properly
>> marked and taken into consideration when rese
On 23/05/16 13:41, Chen-Yu Tsai wrote:
> The PSCI implementation expects at most 2 pages worth of space reserved
> at the end of the secure section for its stacks. This was not properly
> marked and taken into consideration when reserving memory from the
> kernel.
>
> If one accesses PSCI after Li
On 23/05/16 13:41, Chen-Yu Tsai wrote:
> Some common PSCI functions are written in assembly, but it should be
> possible to use them from C code.
>
> Add function declarations for C code to consume.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm/include/asm/psci.h | 8
> 1 file chang
n();
> +
> + /* Ask CPU0 via SGI15 to pull the rug... */
> + writel(BIT(16) | 15, GICD_BASE + GICD_SGIR);
> + DSB;
> +
> + /* Wait to be turned off */
> + while (1)
> + wfi();
> +}
> +
> +void __secure sunxi_gic_init(void)
> +{
> + u3
On 23/05/16 13:41, Chen-Yu Tsai wrote:
> Instead of listing individual registers for controls to each processor
> core, list them as an array of registers. This makes accessing controls
> by core index easier.
>
> Also rename "cpucfg_sun6i.h" (which was unused anyway) to the more generic
> "cpucfg
Hi Tim,
[just spotted this by pure luck...]
I recently ported U-Boot over to the RK3288-based Veyron Speedy 4GB
Chromebook in an attempt to gain KVM (hypervisor) support [1].
However,
in addition to the GIC being completely masked off in non-secure mode
by
the AXI bus, the machine hangs imm
On 23/02/16 15:01, Stuart Yoder wrote:
>
>
>> -Original Message-
>> From: Minghuan Lian
>> Sent: Tuesday, February 23, 2016 3:57 AM
>> To: Stuart Yoder ; u-boot@lists.denx.de
>> Cc: york sun ; Prabhakar Kushwaha
>> ;
>> Mingkai Hu ; Yang-Leo Li ;
>> marc.zyng...@arm.com;
>> Stuart Yoder
On 25/08/15 08:40, Chen-Yu Tsai wrote:
> On Tue, Aug 25, 2015 at 3:34 PM, Marc Zyngier wrote:
>> On Tue, 25 Aug 2015 10:49:19 +0800
>> Chen-Yu Tsai wrote:
>>
>> Hi,
>>
>> Thanks for putting this patch together. A few comments below:
>>
>>>
On Tue, 25 Aug 2015 10:49:19 +0800
Chen-Yu Tsai wrote:
Hi,
Thanks for putting this patch together. A few comments below:
> On the A31s the RTC is by default secured. Thus when u-boot
> loads the kernel in non-secure world, the RTC is unavailable. The
> SoC has a TrustZone Protection Controller,
Alison,
On 17/07/15 11:01, Huan Wang wrote:
> Hi, Mark,
>
>>> On Wed, Jul 15, 2015 at 08:13:05AM +0100, Alison Wang wrote:
This patch addresses a problem mentioned recently on this mailing
>>> list:
[1].
In that posting a LS1021 based system was locking up at about 5
minu
Hi Albert,
On 02/07/15 22:06, Albert ARIBAUD wrote:
> Hello Marc,
>
> On Fri, 20 Mar 2015 18:13:26 +0000, Marc Zyngier
> wrote:
>> On 20/03/15 11:47, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Use the inner shareable attribute for memory
On 20/03/15 11:47, Thierry Reding wrote:
> From: Thierry Reding
>
> Some SoCs come with a custom timer interface, so allow them to use that
> instead.
>
> Cc: Albert Aribaud
> Cc: Marc Zyngier
> Signed-off-by: Thierry Reding
> ---
> arch/arm/cpu/armv8/ge
On 20/03/15 11:47, Thierry Reding wrote:
> From: Thierry Reding
>
> For EL3 and EL2, the documentation says that bits 31 and 23 are reserved
> but should be written as 1.
>
> For EL1, only bit 23 is not reserved, so only write bit 31 as 1.
>
> Cc: Albert Aribaud
>
eld to
> match the documentation.
>
> Cc: Albert Aribaud
> Cc: Marc Zyngier
> Signed-off-by: Thierry Reding
> ---
> arch/arm/include/asm/armv8/mmu.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/armv8/mmu
-Boot
> to hang once the MMU is enabled.
>
> Fix this by making the index a 64-bit unsigned integer and so avoid the
> overflow.
>
> Cc: Albert Aribaud
> Cc: Marc Zyngier
> Signed-off-by: Thierry Reding
Acked-by: Marc Zyngier
> ---
> arch/arm/cpu/armv8/cache_
Hi Thierry,
On 20/03/15 11:47, Thierry Reding wrote:
> From: Thierry Reding
>
> Initialize all GICD_IGROUPRn registers and set up GICC_CTLR to enable
> interrupts to the primary CPU. This fixes issues seen after booting a
> Linux kernel from U-Boot.
>
> Suggested-by: Marc
On 02/03/15 09:40, Jan Kiszka wrote:
> On 2015-02-28 14:56, Marc Zyngier wrote:
>> On Fri, 27 Feb 2015 13:28:01 +
>> Jan Kiszka wrote:
>>
>>> Handy for obtaining the ID of the current CPU. We will have more use
>>> cases.
>>>
>
On Fri, 27 Feb 2015 13:28:01 +
Jan Kiszka wrote:
> Handy for obtaining the ID of the current CPU. We will have more use
> cases.
>
> CC: Marc Zyngier
> Signed-off-by: Jan Kiszka
> ---
> arch/arm/cpu/armv7/sunxi/psci.S | 4 ++--
> arch/arm/include/asm/macro.h
Tegra124 support.
>
> CC: Marc Zyngier
> Signed-off-by: Jan Kiszka
> ---
> arch/arm/cpu/armv7/psci.S | 71
> +
> arch/arm/cpu/armv7/sunxi/psci.S | 63
> +--- 2 files changed, 72
> insertions(+)
On Fri, 27 Feb 2015 13:28:03 +
Jan Kiszka wrote:
> _sunxi_cpu_entry can be converted completely into a reusable
> psci_cpu_entry. Tegra124 will use it as well.
>
> CC: Marc Zyngier
> Signed-off-by: Jan Kiszka
> ---
> arch/arm/cpu/armv7/psci.S | 18 +
On 18/02/15 17:42, surya.satyav...@sirabtech.com wrote:
> I am trying to bring up xen suing u-boot that has this patch.
> Unfortunately as soon as the code tries to call _nonsec_init through
> secure_ram_addr in arm7_init_nonsec function in virt-v7.c I get an
> undefined instruction exception. I su
IG_ARMV7_PSCI
> smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
> smp_kick_all_cpus();
> #endif
>
> /* call the non-sec switching code on this CPU also */
> - relocate_secure_section();
> secure_ram_addr(_nonsec_init)()
On 28/11/14 08:52, Jan Kiszka wrote:
> On 2014-11-10 14:36, Marc Zyngier wrote:
>> On 10/11/14 13:25, Jan Kiszka wrote:
>>> On 2014-11-10 14:08, Marc Zyngier wrote:
>>>> On 10/11/14 12:51, Jan Kiszka wrote:
>>>>> Hi Marc,
>>>>>
>>&
p15, 0, r4, c0, c0, 5 @ MPIDR
> and r4, r4, #3 @ cpu number in cluster
> - mov r5, #400@ 1kB of stack per CPU
> + mov r5, #0x400 @ 1kB of stack per CPU
> mul r4, r4, r5
>
> adr r5, text_end
On 26/11/14 08:44, Jan Kiszka wrote:
> On 2014-11-17 07:47, Jan Kiszka wrote:
>> On 2014-11-10 14:10, Marc Zyngier wrote:
>>> On 10/11/14 12:57, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> I'm trying to get Marc's CPU hotplug-anab
On 25/11/14 10:27, Jan Kiszka wrote:
> On 2014-11-17 07:47, Jan Kiszka wrote:
>> On 2014-11-10 14:10, Marc Zyngier wrote:
>>> On 10/11/14 12:57, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> I'm trying to get Marc's CPU hotplug-anab
On Sun, Nov 16 2014 at 11:19:02 AM, Ian Campbell wrote:
> On Fri, 2014-10-24 at 20:28 +0200, Hans de Goede wrote:
>> It is not used anywhere.
>
> Might this be an oversight because sunxi is the only SoC with psci
> support so far? Marc, was this added intentionally with a usecase in
> mind or just
On 10/11/14 13:25, Jan Kiszka wrote:
> On 2014-11-10 14:08, Marc Zyngier wrote:
>> On 10/11/14 12:51, Jan Kiszka wrote:
>>> Hi Marc,
>>>
>>> what is the motivation to expose a PSCI 0.1 interface in U-boot, instead
>>> of 0.2? Support for preexisting u
On 10/11/14 12:57, Jan Kiszka wrote:
> Hi all,
>
> I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi
> working on a B-Pi. After the first discussion it became clear that we
> need something like flush_dcache_all in the PSCI monitor (I don't think
> we need an icache flush, do we?).
On 10/11/14 12:51, Jan Kiszka wrote:
> Hi Marc,
>
> what is the motivation to expose a PSCI 0.1 interface in U-boot, instead
> of 0.2? Support for preexisting users of 0.1? The kernel seems to be
> happy with both, and I'm now wondering if we should actually add the
> legacy version to Jailhouse a
On Wed, Oct 15 2014 at 03:05:24 PM, Siarhei Siamashka
wrote:
> On Wed, 15 Oct 2014 13:42:33 +0100
> Marc Zyngier wrote:
>
>> On Wed, Oct 15 2014 at 11:40:24 AM, Siarhei Siamashka
>> wrote:
>> > On Wed, 15 Oct 2014 11:31:44 +0100
>> > Marc Zyngier wrote:
On Wed, Oct 15 2014 at 11:40:24 AM, Siarhei Siamashka
wrote:
> On Wed, 15 Oct 2014 11:31:44 +0100
> Marc Zyngier wrote:
>
>> On Wed, Oct 15 2014 at 11:25:10 AM, Siarhei Siamashka
>> wrote:
>> > On Wed, 15 Oct 2014 12:13:05 +0200
>> > Hans de Goede wro
On Wed, Oct 15 2014 at 11:25:43 AM, Albert ARIBAUD
wrote:
> Hi Marc, Hans,
>
> On Wed, 15 Oct 2014 11:18:28 +0100, Marc Zyngier
> wrote:
>
>> On Wed, Oct 15 2014 at 11:13:05 AM, Hans de Goede
>> wrote:
>> > Older Linux kernels will not properly
On Wed, Oct 15 2014 at 11:25:10 AM, Siarhei Siamashka
wrote:
> On Wed, 15 Oct 2014 12:13:05 +0200
> Hans de Goede wrote:
>
>> Older Linux kernels will not properly boot in hype mode, add support for a
>> bootm_boot_mode environment variable, which when set to "sec" will cause
>> u-boot to boot i
c (and hyp) support.
>
> Signed-off-by: Hans de Goede
Looks good to me.
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 2014-10-11 12:27, Albert ARIBAUD wrote:
Hi Albert,
On Fri, 19 Sep 2014 18:04:14 +0200, Albert ARIBAUD
wrote:
Hi Marc,
On Thu, 18 Sep 2014 16:28:52 +0100, Marc Zyngier
wrote:
> On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD
wrote:
> > Hi Arnab,
> >
> > On T
ifically for the
>> purpose.
>>
>> So far no one is using this section.
>>
>> Signed-off-by: Arnab Basu
>> Reviewed-by: Bhupesh Sharma
>> Cc: Marc Zyngier
>> ---
>> arch/arm/config.mk|2 +-
>> arch/arm/cpu/armv8/u-boot.lds |
On 07/08/14 02:54, Xiubo Li wrote:
> The memory where loaded the smp_waitloop code section probablly
> be corrupted by Linux Kernel, then the secondary cores will be
> running the random code, leading booting the secondary cores
> failed.
There is now similar reservation code in virt-dt.c. Probabl
On 06/08/14 10:49, Mark Rutland wrote:
> On Wed, Aug 06, 2014 at 08:38:13AM +0100, Ian Campbell wrote:
>> On Mon, 2014-08-04 at 16:14 +0100, Marc Zyngier wrote:
>>
>>> My personal feeling is that booting in secure mode is always the wrong
>>> thing to do.
>>
1 - 100 of 187 matches
Mail list logo
