Re: [PATCH v4] ARM: boot: Obtain start of physical memory from DTB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ard,

On Tue, Apr 14, 2020 at 10:07 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> On Wed, 25 Mar 2020 at 17:40, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Fri, 20 Mar 2020 at 15:43, Geert Uytterhoeven
> > <geert+renesas@xxxxxxxxx> wrote:
> > > Currently, the start address of physical memory is obtained by masking
> > > the program counter with a fixed mask of 0xf8000000.  This mask value
> > > was chosen as a balance between the requirements of different platforms.
> > > However, this does require that the start address of physical memory is
> > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > requirement is not fulfilled.
> > >
> > > Fix this limitation by obtaining the start address from the DTB instead,
> > > if available (either explicitly passed, or appended to the kernel).
> > > Fall back to the traditional method when needed.
> > >
> > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > i.e. not at a multiple of 128 MiB.
> > >
> > > Suggested-by: Nicolas Pitre <nico@xxxxxxxxxxx>
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > > Reviewed-by: Nicolas Pitre <nico@xxxxxxxxxxx>
> > > Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > > ---
> > > v4:
> > >   - Fix stack location after commit 184bf653a7a452c1 ("ARM:
> > >     decompressor: factor out routine to obtain the inflated image
> > >     size"),
> > >
> >
> > Apologies for the breakage. I was aware of the existence of this
> > patch, but I didn't realize it was accessing LC0 early on to find the
> > stack pointer value.
> >
> > Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
>
> OK, so one thing I did notice when playing with this code is that the
> phys/virt patching code requires that 'PHYS_OFFSET - PAGE_OFFSET' is a
> multiple of 16 MB, and so this needs to be taken into account by this
> change as well, given that PHYS_OFFSET is based on the placement of
> the uncompressed kernel in the physical address space.

You mean fdt_get_mem_start() should round up the address to make sure
it is a multiple of 16 MiB (assumed PAGE_OFFSET is a multiple of 16 MiB,
too)?
Can PAGE_OFFSET actually be not a multiple of 16 MiB?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux