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 'Platform Init', which does the
> initial hardware setup and a "P
On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
> Hello,
>
> I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot
> when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've
> verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.M
Hi,
On Tue, Mar 20, 2018 at 01:59:03PM +0100, Patrick Delaunay wrote:
> Add minimal PSCI support for Linux.
>
> Signed-off-by: Patrick Delaunay
> +int __secure psci_features(unsigned int psci_fid)
> +{
> + switch (psci_fid) {
> + case ARM_PSCI_0_2_FN_PSCI_VERSION:
> + case ARM_PSCI_
On Wed, Mar 08, 2017 at 11:35:12AM +0900, Masahiro Yamada wrote:
> At first, the ARM64 Linux booting requirement recommended that the
> kernel image be placed text_offset bytes from 2MB aligned base near
> the start of usable system RAM because memory below that base address
> was unusable at that
On Tue, Mar 07, 2017 at 07:16:56AM -0500, Tom Rini wrote:
> On Tue, Mar 07, 2017 at 11:43:52AM +0000, Mark Rutland wrote:
> > On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote:
> > > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote:
> > > > 2017
On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote:
> On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote:
> > 2017-02-27 7:41 GMT+09:00 Tom Rini :
> > > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote:
> > > c) I'm not convinced your math above is correct. images->ep i
Hi,
On Fri, Feb 03, 2017 at 02:22:48PM -0800, York Sun wrote:
> We don't have to completely turn off MMU and cache to switch to
> another MMU table as far as the data is coherent before and after
> the switching. This patch relaxes the procedure.
>
> Signed-off-by: York Sun
> CC: Alexander Graf
On Thu, Jan 12, 2017 at 01:47:32PM +, Ryan Harkin wrote:
> On 12 January 2017 at 12:25, Mark Rutland wrote:
> > On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
> >> On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
> >> > Looking at t
On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> > simply adding new descriptions, so a DTB from a year ago should work
>
On Tue, Jan 10, 2017 at 05:17:07PM +, Ryan Harkin wrote:
> On 10 January 2017 at 16:58, Alexander Graf wrote:
> > On 01/10/2017 05:47 PM, Ryan Harkin wrote:
> >> I have a background task to refactor u-boot support for ARM Ltd
> >> boards. One of many options I was considering was to have a mi
On Fri, Oct 28, 2016 at 09:35:37PM +, york sun wrote:
> I am struggling on the dcache_disable() which implies all dcache is
> flushed. I don't have a reasonable way to flush all if I want to skip
> L3. I tried to benchmark flushing by VA to cover my entire 16GB memory.
> It took 30+ seconds.
On Fri, Oct 28, 2016 at 12:32:36PM -0600, Stephen Warren wrote:
> Related, consider the following from the Linux kernel's
> Documentation/arm64/booting.txt:
>
> >- Caches, MMUs
> > The MMU must be off.
> > Instruction cache may be on or off.
> > The address range corresponding to the loaded ker
Hi,
On Wed, Oct 26, 2016 at 02:10:24PM +0200, Antoine Tenart wrote:
> Implement three atomic functions to allow making an atomic operation
> that returns the value. Adds: atomic_add_return(), atomic_sub_return(),
> atomic_inc_return() and atomic_dec_return().
>
> Signed-off-by: Antoine Tenart
I
On Fri, Oct 21, 2016 at 07:31:52PM +, york sun wrote:
> On 10/20/2016 01:34 PM, Stephen Warren wrote:
> > On 10/19/2016 11:06 PM, york sun wrote:
> >> I understand the data in dirty cache is not lost when the dcache is
> >> disabled. It is just not accessible. In my case, after flushing L1/L2 b
> >+flush_dcache_all();
> > set_sctlr(sctlr & ~(CR_C|CR_M));
> >
> >-flush_dcache_all();
> > __asm_invalidate_tlb_all();
>
> I talked to Mark Rutland at ARM, and I believe the current code is
> correct.
Well, almost, but not quite. It's a long story... ;)
I
On Thu, Jun 30, 2016 at 04:51:48PM +0800, Gong Qianyu wrote:
> From: Mingkai Hu
>
> Data coherency is enabled only when the CPUECTLR.SMPEN bit is
> set. The SMPEN bit should be set before enabling the data cache.
> If not enabled, the cache is not coherent with other cores and
> data corruption c
On Fri, Jun 17, 2016 at 09:51:49PM +0900, Masahiro Yamada wrote:
> There are two enable methods supported by ARM64 Linux; psci and
> spin-table. The latter is simpler and easier to use for quick SoC
> bring-up.
>
> So, I used the spin-table for my first ARMv8 SoC porting, but I
> found its suppor
On Wed, May 18, 2016 at 05:10:24PM +0800, macro.wav...@gmail.com wrote:
> From: Wang Dongsheng
>
> According to PSCI specification v1.0, the PSCI functions should start from
> 0x8400 for SMC32, this patch changes this base value as well as other
> function offset values.
I agree that these a
On Wed, Feb 24, 2016 at 06:39:22PM +0100, Alexander Graf wrote:
> On 02/24/2016 02:37 PM, Mark Rutland wrote:
> >On Wed, Feb 24, 2016 at 01:11:35PM +0100, Alexander Graf wrote:
> >>+ /* Calculate the maximum physical (and thus virtual) address */
> >>+
Hi,
This is a good cleanup!
On Wed, Feb 24, 2016 at 01:11:36PM +0100, Alexander Graf wrote:
> The idea to generate our pages tables from an array of memory ranges
> is very sound. However, instead of hard coding the code to create up
> to 2 levels of 64k granule page tables, we really should just
On Wed, Feb 24, 2016 at 01:11:35PM +0100, Alexander Graf wrote:
> Based on the memory map we can determine a lot of hard coded fields of
> TCR, like the maximum VA and max PA we want to support. Calculate those
> dynamically to reduce the chance for pit falls.
>
> Signed-off-by: Alexander Graf
>
On Tue, Feb 02, 2016 at 03:45:01AM +0100, Alexander Graf wrote:
> EFI uses the PE binary format for its application images. Add support to EFI
> PE
> binaries as well as all necessary bits for the "EFI image loader" interfaces.
>
> Signed-off-by: Alexander Graf
>
> ---
>
> v1 -> v2:
>
> - m
On Tue, Feb 02, 2016 at 03:45:10AM +0100, Alexander Graf wrote:
> On arm64, boards can declare that they want to run with dcache disabled.
>
> However, uEFI guarantees to payloads that they're running with the dcache
> enabled which on arm64 means that they can do unaligned accesses.
>
> To not l
On Tue, Oct 27, 2015 at 02:52:43AM +, Huan Wang wrote:
> Hi, Mark and Alexander,
>
> Do you have any comment about this patch?
> Thanks.
The patch looks good to me. FWIW:
Acked-by: Mark Rutland
Mark.
___
U-Boot mailing
On Mon, Oct 19, 2015 at 02:57:22PM +0200, Linus Walleij wrote:
> Jon & Grant especially:
>
> On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass wrote:
> > Me
> >> I will go in and answer the comment on the DT mailing list so there is
> >> some push atleast.
> >
> > Perhaps if we could see some movement
On Mon, Aug 24, 2015 at 08:54:17AM +0100, Markus Niebel wrote:
> Hello,
>
> I'm not an expert in the low level details of this area. So please sorry if
> there are
> wrong assumptions in this post post.
>
> Hardware: i.MX6 Solo (TQMa6 on custom Mainboard)
> U-Boot: 2014.10
> gcc: 4.8.3
>
> We
On Fri, Jul 17, 2015 at 11:01:01AM +0100, 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 l
Hi,
Isn't this the same patch as a couple of days ago [2], which I replied
to [3]?
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 min
On Wed, Jul 08, 2015 at 08:31:47AM +0100, Sharma Bhupesh wrote:
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wang
> > Haikun
> > On 7/8/2015 3:13 PM, Bin Meng wrote:
> > > Hi,
> > >
> > > On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun
> > wrote:
>
On Sun, Jul 12, 2015 at 05:05:34AM +0100, Christopher Kilgour wrote:
> Fix LS102xa timer configuration to ensure timer compare value is set to
> all-ones as a 64-bit number rather than a 32-bit number.
>
> When the 32-bit all-ones was used, this could result in a timer compare value
> of 2^32-1, w
On Thu, Jun 11, 2015 at 08:17:15AM +0100, Siva Durga Prasad Paladugu wrote:
>
> Hi Mark,
>
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Thursday, May 28, 2015 3:10 PM
> > To: Siva Durga Prasad Paladugu
> >
Hi,
> +void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
> + enum dcache_option option)
> +{
> + u64 *page_table = arch_get_page_table();
> + u64 upto, end;
> +
> + if (page_table == NULL)
> + return;
> +
> + end = ALI
On Tue, May 12, 2015 at 04:46:49AM +0100, Siva Durga Prasad Paladugu wrote:
> Hi Mark,
>
>
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Wednesday, April 29, 2015 10:00 PM
> > To: Michal Simek
> > Cc: u-bo
On Tue, May 05, 2015 at 10:39:14AM +0100, Mark Rutland wrote:
> On Mon, May 04, 2015 at 10:36:43AM +0100, Ian Campbell wrote:
> > On Mon, 2015-05-04 at 10:51 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 02-05-15 15:21, Ian Campbell wrote:
> > >
On Mon, May 04, 2015 at 10:36:43AM +0100, Ian Campbell wrote:
> On Mon, 2015-05-04 at 10:51 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 02-05-15 15:21, Ian Campbell wrote:
> > > On Fri, 2015-04-24 at 20:39 +0200, Hans de Goede wrote:
> > >> Linux-4.0 as shipped has a bug causing it to not boot
incase of dcache off.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Fix patch subject (remove addional zzz from v1)
> - Remove armv8: caches: Disable dcache after flush patch from this
> series based on the
Hi Hans,
> So it seems that I'm not the only one seeing this, and I've been wrongly
> blaming it on the A33, instead it seems to be a kernel bug, triggered
> on my A33 due to the display resolution it has.
>
> For details see:
>
> http://www.spinics.net/lists/arm-kernel/msg413811.html
That's go
> > > Thanks for explanation.
> > > So in that case, the flushing of the required stack or any other data
> > > which needs to be flushed should be part of board specific. Am I
> > > correct?
> >
> > It could be done in generic code, assuming we know the bounds of memory
> > which will be used, bec
On Thu, Apr 16, 2015 at 08:12:31PM +0100, Hans de Goede wrote:
> Hi,
>
> On 16-04-15 19:35, Mark Rutland wrote:
> > On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 15-04-15 21:57, Ian Campbell wrote:
> >>>
> > > Now in the flush_dcache_all we are invoking the actual asm call to
> > > flush dcache which may wipeout the stored return value in stack with
> > > cahe contents(main memory). Hence the return from the flush_dcahe_all
> > > will fail.
> > >
> > > To confirm this I modified the dcache_disable
On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote:
> Hi,
>
> On 15-04-15 21:57, Ian Campbell wrote:
> > On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote:
> >> For unknown reasons the A33 needs the end of the memory we report to the
> >> kernel to be aligned to a multiple of 4 MiB
On Thu, Apr 16, 2015 at 06:17:59AM +0100, Siva Durga Prasad Paladugu wrote:
> Hi Mark.
>
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Wednesday, April 15, 2015 6:41 PM
> > To: Michal Simek
> > Cc: u-boot@lists.
On Wed, Apr 15, 2015 at 12:33:00PM +0100, Michal Simek wrote:
> From: Siva Durga Prasad Paladugu
>
> Always disable dcache after the flush operation
> The following sequence is advisable while disabling d-cache:
> 1. disable_dcache() - flushes and disables d-cache
> 2. invalidate_dcache_all() - i
On Fri, Mar 27, 2015 at 02:11:48PM +, Albert ARIBAUD wrote:
> Hello Mark,
>
> On Thu, 12 Feb 2015 15:56:52 +0000, Mark Rutland
> wrote:
> > On Sat, Jan 31, 2015 at 03:08:54AM +, feng...@phytium.com.cn wrote:
> > > From: David Feng
> > >
> > >
> >> > +/* SMP Spin Table Definitions */
> >> > +#ifdef CONFIG_BASE_FVP
> >> > +#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE +
> >> > 0x03f0)
> >> > +#else
> >> > +#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
> >> > +#endif
> >>
> >> Where are these
Hi,
> Maybe a dumb question, why do we need to have a 64-bit U-Boot for
> arm64? I don't see we ever created 64-bit U-Boot for ppc64.
In ARMv8 it's not possible to change the register width at an exception
level (i.e. you can't change 64->32 or vice-versa), and lower exception
levels cannot be wi
ry cntfrq variable? Can't you just have:
__real_cntfrq = COUNTER_FREQUENCY_REAL;
> + flush_dcache_range((unsigned long)&__real_cntfrq,
> +(unsigned long)&__real_cntfrq + 8);
This looks fine, as does the rest of the pat
> >> +int timer_init(void)
> >> +{
> >> + u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
> >> + u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
> >> +#ifdef COUNTER_FREQUENCY_REAL
> >> + unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
> >> +
> >> + /* Update with accurate clock
Hi,
On Thu, Mar 19, 2015 at 08:34:22PM +, York Sun wrote:
> The timer clock is system clock divided by 4, not fixed 12MHz. This is
> common to the SoC, not board specific.
>
> Signed-off-by: York Sun
>
> ---
>
> Changes in v2:
> Fix CNTFRQ for secondary cores when COUNTER_FREQUENCY_REAL
On Thu, Mar 19, 2015 at 07:52:30PM +, Scott Wood wrote:
> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote:
> > On Thu, Mar 19, 2015 at 04:45:48PM +, York Sun wrote:
> > > From: Scott Wood
> > >
> > > This lets us see the problems (close to) when
On Thu, Mar 19, 2015 at 06:24:10PM +, York Sun wrote:
> On 03/19/2015 11:17 AM, Mark Rutland wrote:
> > On Thu, Mar 19, 2015 at 06:16:25PM +, York Sun wrote:
> >> On 03/19/2015 11:08 AM, Mark Rutland wrote:
> >>>> +
> >>>> +int timer_init(vo
On Thu, Mar 19, 2015 at 06:16:25PM +, York Sun wrote:
> On 03/19/2015 11:08 AM, Mark Rutland wrote:
> >> +
> >> +int timer_init(void)
> >> +{
> >> + u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
> >> + u32 __iomem *cltbenr =
On Thu, Mar 19, 2015 at 04:45:48PM +, York Sun wrote:
> From: Scott Wood
>
> This lets us see the problems (close to) when they happen,
> rather than Linux hanging when it enables them prior to having a
> working console.
FYI, if the Linux driver for your UART supports earlycon, that should
On Thu, Mar 19, 2015 at 04:45:35PM +, York Sun wrote:
> The timer clock is system clock divided by 4, not fixed 12MHz. This is
> common to the SoC, not board specific.
>
> Signed-off-by: York Sun
> ---
> README |8
> arch/arm/cpu/armv8/fsl-lsch3/cpu.c
On Thu, Feb 26, 2015 at 03:06:10PM +, FengHua wrote:
>
> hi Mark,
Hi,
>You did very detailed analysis of the cache beheaviour. Yes, this
> patch is not perfect.
> But it did fix the actually existed bug. I will try to describe it more
> clearly in the following.
While this may app
On Thu, Feb 19, 2015 at 10:13:58AM +, Ian Campbell wrote:
> On Thu, 2015-02-19 at 10:25 +0100, Jan Kiszka wrote:
> > On 2015-02-19 10:19, Ian Campbell wrote:
> > > On Thu, 2015-02-19 at 09:28 +0100, Thierry Reding wrote:
> > >> On Tue, Feb 17, 2015 at 11:55:
On Thu, Feb 19, 2015 at 09:25:56AM +, Jan Kiszka wrote:
> On 2015-02-19 10:19, Ian Campbell wrote:
> > On Thu, 2015-02-19 at 09:28 +0100, Thierry Reding wrote:
> >> On Tue, Feb 17, 2015 at 11:55:24AM +, Mark Rutland wrote:
> >>> [...]
> >
[...]
> >> This is getting invasive:
> >>
> >> If I add carveouts via adjusting memory banks, I need to account for the
> >> case that an existing bank is split into two halves, creating additional
> >> banks this way. But then current fdt_fixup_memory_banks will no longer
> >> work due to its lim
On Tue, Feb 17, 2015 at 08:09:57AM +, Jan Kiszka wrote:
> On 2015-02-16 16:38, Jan Kiszka wrote:
> > On 2015-02-16 15:56, Mark Rutland wrote:
> >> On Mon, Feb 16, 2015 at 02:31:21PM +, Jan Kiszka wrote:
> >>> On 2015-02-16 15:25, Mark Rutland wrote:
> &
On Tue, Feb 17, 2015 at 07:01:57AM +, Jan Kiszka wrote:
> On 2015-02-16 15:02, Jan Kiszka wrote:
> > On 2015-02-16 14:51, Mark Rutland wrote:
> >> On Mon, Feb 16, 2015 at 01:44:36PM +, Jan Kiszka wrote:
> >>> On 2015-02-16 14:37, Mark Rutland wrote:
> &
On Mon, Feb 16, 2015 at 02:31:21PM +, Jan Kiszka wrote:
> On 2015-02-16 15:25, Mark Rutland wrote:
> > On Mon, Feb 16, 2015 at 01:51:37PM +, Jan Kiszka wrote:
> >> On 2015-02-16 14:42, Mark Rutland wrote:
> >>> On Mon, Feb 16, 2015 at 12:54:43PM +, Jan
On Mon, Feb 16, 2015 at 01:51:37PM +, Jan Kiszka wrote:
> On 2015-02-16 14:42, Mark Rutland wrote:
> > On Mon, Feb 16, 2015 at 12:54:43PM +, Jan Kiszka wrote:
> >> From: Ian Campbell
> >>
> >> In this case the secure code lives in RAM, and hence needs t
On Mon, Feb 16, 2015 at 01:44:36PM +, Jan Kiszka wrote:
> On 2015-02-16 14:37, Mark Rutland wrote:
> > On Mon, Feb 16, 2015 at 12:54:49PM +, Jan Kiszka wrote:
> >> We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to
> >> happen for all c
On Mon, Feb 16, 2015 at 12:54:48PM +, Jan Kiszka wrote:
> From: Ian Campbell
>
> These registers can be used to prevent non-secure world from accessing a
> megabyte aligned region of RAM, use them to protect the u-boot secure monitor
> code.
What happens if the CPU tried to read this memory
On Mon, Feb 16, 2015 at 12:54:43PM +, Jan Kiszka wrote:
> From: Ian Campbell
>
> In this case the secure code lives in RAM, and hence needs to be reserved, but
> it has been relocated, so the reservation of __secure_start does not apply.
>
> Add support for setting CONFIG_ARMV7_SECURE_RESERV
On Mon, Feb 16, 2015 at 12:54:49PM +, Jan Kiszka wrote:
> We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to
> happen for all cores.
>
> Fixing this resolves problems of KVM with emulating the generic
> timer/counter.
>
> Signed-off-by: Jan Kiszka
> ---
> arch/arm/cpu/a
On Sat, Jan 31, 2015 at 03:08:54AM +, feng...@phytium.com.cn wrote:
> From: David Feng
>
> Armv7 and Armv8 allow outer cache exist, it is outside of the architecture
> defined cache hierarchy and can not be manipulated by architecture defined
> instructions. It's processor specific.
> This pa
On Wed, Feb 11, 2015 at 03:26:06AM +, FengHua wrote:
>
> hi Mark,
> Thank you review this patch.
>
> > -Original Messages-----
> > From: "Mark Rutland"
> > Sent Time: 2015-02-09 19:05:54 (Monday)
> > To: "feng...@phytium.com.cn&qu
[...]
> > > The solution that was discussed internally would involve having the
> > > secure monitor (U-Boot's PSCI implementation in this case) program the
> > > flow controller appropriately, point the CPU reset vectors to a location
> > > containing a WFI instruction and power up the CPUs. That
On Mon, Feb 09, 2015 at 08:51:59AM +, feng...@phytium.com.cn wrote:
> From: David Feng
>
> The cache disable operation shoud be performed after flush_dcache_all().
> If cache disable operation is performed before
> flush_dcache_all(), flush_dcache_all() store data directly to memory
> and may
On Thu, Feb 05, 2015 at 11:44:25AM +, Thierry Reding wrote:
> On Fri, Jan 23, 2015 at 12:37:20PM +0000, Mark Rutland wrote:
> > On Fri, Jan 23, 2015 at 10:10:45AM +, Thierry Reding wrote:
> > > On Thu, Jan 22, 2015 at 07:20:15PM +, Mark Rutland wrote:
> > > &
[...]
> > > PSCI assumes that the FW is in full control of the registers it's
> > > poking. While a lock isn't necessarily bad, I suspect it's going to be
> > > very difficult to have that common across all users without the code
> > > becoming unmaintainable fast. I'd also hope that for arm64 we
On Fri, Jan 23, 2015 at 10:10:45AM +, Thierry Reding wrote:
> On Thu, Jan 22, 2015 at 07:20:15PM +0000, Mark Rutland wrote:
> > On Fri, Jan 16, 2015 at 09:12:59AM +, Thierry Reding wrote:
> > > On Thu, Jan 15, 2015 at 07:19:37PM +, Mark Rutland wrote:
> > > &
On Fri, Jan 16, 2015 at 09:12:59AM +, Thierry Reding wrote:
> On Thu, Jan 15, 2015 at 07:19:37PM +0000, Mark Rutland wrote:
> > On Wed, Jan 14, 2015 at 07:57:25AM +, Thierry Reding wrote:
> > > On Tue, Jan 13, 2015 at 07:44:50PM +, Ian Campbell wrote:
Hi,
On Mon, Jan 12, 2015 at 08:56:45PM +, Arnab Basu wrote:
> Implement core support for PSCI. As this is generic code, it doesn't
> implement anything really useful (all the functions are returning
> Not Implemented).
>
> This is largely ported from the similar code that exists for ARMv7
>
On Wed, Jan 14, 2015 at 07:57:25AM +, Thierry Reding wrote:
> On Tue, Jan 13, 2015 at 07:44:50PM +, Ian Campbell wrote:
> > Hi Thierry,
> >
> > I needed to boot my Jetson in NS mode (in order to boot Xen) and was
> > investigating the possibility of PSCI support when I discovered that you
On Thu, Jan 15, 2015 at 06:10:57AM +, bhupesh.sha...@freescale.com wrote:
> Hi York,
>
> > -Original Message-
> > From: Sun York-R58495
> > Sent: Wednesday, January 14, 2015 9:44 PM
> > On 01/14/2015 05:46 AM, Bhupesh Sharma wrote:
> > > This patch adds basic constructs in the ARMv8 u-
On Wed, Nov 26, 2014 at 12:52:11PM +, Jan Kiszka wrote:
> On 2014-08-27 22:29, Arnab Basu wrote:
> > This series of patches creates a generic PSCI v0.2 framework for ARMv8.
> >
> > The first 3 patches refactor existing code so that ARMv7 PSCI,
> > ARMv8 spin-table and ARMv8 PSCI can coexist.
>
[...]
> Other than this, are you really happy about granting the users full
> rights to allow booting the kernel in the secure mode via a simple
> environment variables tweak? Can't it potentially become a security
> breach in some scenarios?
U-Boot must be running in secure mode in order to boot
On Tue, Sep 02, 2014 at 04:21:24PM +0100, Stuart Yoder wrote:
> > > The idea here is that if there is no PSCI specific (most likely secure)
> > > memory allocated in the system, the macro "CONFIG_ARMV8_SECURE_BASE"
> > > will not be defined. In this case the PSCI vector table and its support
> > >
On Mon, Sep 01, 2014 at 07:43:18PM +0100, Mark Rutland wrote:
> Hi,
>
> > >> diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
> > >> index 9792bc0..c2c8fe7 100644
> > >> --- a/arch/arm/cpu/armv8/cpu-dt.c
> > >>
Hi,
> >> diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
> >> index 9792bc0..c2c8fe7 100644
> >> --- a/arch/arm/cpu/armv8/cpu-dt.c
> >> +++ b/arch/arm/cpu/armv8/cpu-dt.c
> >> @@ -9,7 +9,69 @@
> >> #include
> >>
> >> #ifdef CONFIG_MP
> >> +#ifdef CONFIG_ARMV8_PSCI
> >>
>
On Thu, Aug 28, 2014 at 11:51:08AM +0100, Arnab Basu wrote:
> Hi Mark
>
> On 08/28/2014 03:40 PM, Mark Rutland wrote:
> > Hi Arnab,
> >
> > On Wed, Aug 27, 2014 at 09:29:55PM +0100, Arnab Basu wrote:
> >> Both ARMv7 and ARMv8 need to patch the device tree b
Hi,
On Wed, Aug 27, 2014 at 09:29:59PM +0100, Arnab Basu wrote:
> Set the enable-method in the cpu node to psci, create the psci
> device tree node and also add a reserve section for the psci code
> that lives in in normal RAM, so that the kernel leaves it alone
>
> Signed-off-by: Arnab Basu
> R
Hi Arnab,
On Wed, Aug 27, 2014 at 09:29:58PM +0100, Arnab Basu wrote:
> Implement core support for PSCI. As this is generic code, it doesn't
> implement anything really useful (all the functions are returning
> Not Implemented).
This is really nice to see! Thanks for working on this.
Some functi
Hi Arnab,
On Wed, Aug 27, 2014 at 09:29:55PM +0100, Arnab Basu wrote:
> Both ARMv7 and ARMv8 need to patch the device tree but the kind
> of patching done is different. This creates a function that can be
> defined by each architecture to handle the differences
I have no problem with the patch, b
Hi York,
> >> - /*
> >> -* All processors will enter EL2 and optionally EL1.
> >> +slave_cpu:
> >> + wfe
> >> +#ifdef CONFIG_FSL_SMP_RELEASE_ALL
> >> + /* All cores are released from the address in the 1st spin table
> >> +* element
> >> */
> >> - b
Hi Bhupesh,
[...]
> > >> diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
> > >> b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
> > >> new file mode 100644
> > >> index 000..2dbcdcb
> > >> --- /dev/null
> > >> +++ b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
> > >> @@ -0,0 +1,56 @@
> > >> +/*
> > >> + * Copyrig
Hi Arnab,
[...]
> >>> Is there any reason to have the SWITCH_TO_EL1 option other than for
> >>> debugging?
> >>
> >> Good question. I will let Arnab to comment here.
> >>
> >>>
> >>> EL2 is the preferred EL to boot at for Linux and Xen (it gives far
> >>> more flexibility), and if dropping to EL1
Hi York,
I have mostly minor comments this time; this is looking pretty good.
On Tue, Aug 19, 2014 at 09:28:00PM +0100, York Sun wrote:
> Secondary cores need to be released from holdoff by boot release
> registers. With GPP bootrom, they can boot from main memory
> directly. Individual spin tabl
On Wed, Aug 20, 2014 at 03:39:37AM +0100, AlisonWang wrote:
> Hi, Mark,
>
> On Tue, Aug 19, 2014 at 03:54:50AM +0100, Alison Wang wrote:
>
> > +int timer_init(void)
> > +{
> > + struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR;
> > + unsigned long ctrl, val, freq;
> > +
Hi,
On Tue, Aug 19, 2014 at 03:54:50AM +0100, Alison Wang wrote:
> From: Wang Huan
>
> The QorIQ LS1 family is built on Layerscape architecture,
> the industry's first software-aware, core-agnostic networking
> architecture to offer unprecedented efficiency and scale.
>
> Freescale LS102xA is a s
On Thu, Aug 14, 2014 at 08:11:49PM +0100, Tom Rini wrote:
> On Thu, Aug 14, 2014 at 04:16:50PM +0100, Mark Rutland wrote:
> > Hi Tom,
> >
> > On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
> > > The default format for arm64 Linux kernels is the &quo
Hi Tom,
On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
> The default format for arm64 Linux kernels is the "Image" format,
> described in Documentation/arm64/booting.txt. This, along with an
> optional gzip compression on top is all that is generated by default.
> The Image format has
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.
>
> FWIW I agree.
>
> > If you want to go down the road of a single bootloader that
On Mon, Jul 14, 2014 at 09:21:26PM +0100, York Sun wrote:
> On 07/14/2014 07:03 AM, Mark Rutland wrote:
> > Unfortunately I don't have an answer to that; the arm64 Linux spin-table
> > documentation and code were all written before I was involved.
> >
> > The un
On Tue, Jul 08, 2014 at 04:48:00AM +0100, Scott Wood wrote:
> On Fri, 2014-07-04 at 10:29 +0100, Mark Rutland wrote:
> > Hi,
> >
> > Apologies for the late reply.
> >
> > On Fri, Jun 27, 2014 at 05:44:05PM +0100, Tom Rini wrote:
> > > On Fri, Jun 27
> > >> @@ -119,3 +107,94 @@ ENTRY(lowlevel_init)
> > >> mov lr, x29 /* Restore LR */
> > >> ret
> > >> ENDPROC(lowlevel_init)
> > >> +
> > >> + /* Keep literals not used by the secondary boot page outside
> > it */
> > >> + .ltorg
> > >> +
> > >> +
On Tue, Jul 08, 2014 at 06:56:26PM +0100, York Sun wrote:
> On 07/04/2014 05:31 AM, Mark Rutland wrote:
> > Hi York,
> >
> > I spotted a couple of generic issues below. Most of these are issues
> > with the existing code that you happen to be moving around, rather than
Hi York,
I spotted a couple of generic issues below. Most of these are issues
with the existing code that you happen to be moving around, rather than
with the new code this patch introduces.
There are a couple of gotchas around secondary startup that are painful
with the bootwrapper for arm64 at
1 - 100 of 113 matches
Mail list logo
