From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Linux MIPS Mailing List <linux-mips@linux-mips.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linus Walleij <linus.walleij@linaro.org>,
Will Deacon <will.deacon@arm.com>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Christoph Hellwig <hch@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Matt Turner <mattst88@gmail.com>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
"moderated list:H8/300 ARCHITECTURE"
<uclinux-h8-devel@lists.sourceforge.jp>,
Vladimir Murzin <vladimir.murzin@arm.com>,
adi-buildroot-devel@lists.sourceforge.net,
Nicholas Piggin <npiggin@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Henderson <rth@twiddle.net>, Cris <linux-cris-ke>
Subject: Re: [PATCH] Extract initrd free logic from arch-specific code.
Date: Thu, 29 Mar 2018 18:32:47 +0100 [thread overview]
Message-ID: <20180329173247.GF16141@n2100.armlinux.org.uk> (raw)
In-Reply-To: <86zi2qrfgl.wl-marc.zyngier@arm.com>
On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> On Thu, 29 Mar 2018 16:58:27 +0100,
> Russell King - ARM Linux wrote:
> >
> > On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > > >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> > > >> <linux@armlinux.org.uk> wrote:
> > > >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> > > >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > > >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> > > >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > > >> >> >>> Now only those architectures that have custom initrd free requirements
> > > >> >> >>> need to define free_initrd_mem.
> > > >> >> >> ...
> > > >> >> >>> --- a/arch/arc/mm/init.c
> > > >> >> >>> +++ b/arch/arc/mm/init.c
> > > >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > > >> >> >>> {
> > > >> >> >>> free_initmem_default(-1);
> > > >> >> >>> }
> > > >> >> >>> -
> > > >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> > > >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> > > >> >> >>> -{
> > > >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > > >> >> >>> -}
> > > >> >> >>> -#endif
> > > >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> > > >> >> >>> --- a/arch/arm/Kconfig
> > > >> >> >>> +++ b/arch/arm/Kconfig
> > > >> >> >>> @@ -47,6 +47,7 @@ config ARM
> > > >> >> >>> select HARDIRQS_SW_RESEND
> > > >> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > > >> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> > > >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> > > >> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> > > >> >> >>
> > > >> >> >> Isn't this why weak symbols were invented?
> > > >> >> >
> > > >> >> > Weak symbols means that we end up with both the weakly-referenced code
> > > >> >> > and the arch code in the kernel image. That's fine if the weak code
> > > >> >> > is small.
> > > >> >>
> > > >> >> The kernel's been able to build with link time garbage collection since 2016:
> > > >> >>
> > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> > > >> >>
> > > >> >> Wouldn't that remove the unused one?
> > > >> >
> > > >> > Probably, if anyone bothered to use that, which they don't.
> > > >> >
> > > >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > > >> > what I can see, nothing selects it. Therefore, the symbol is always
> > > >> > disabled, and so the feature never gets used in mainline kernels.
> > > >> >
> > > >> > Brings up the obvious question - why is it there if it's completely
> > > >> > unused? (Maybe to cause confusion, and allowing a justification
> > > >> > for __weak ?)
> > > >>
> > > >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> > > >> I'm not sure what happened to them though. I suspect it just fell down
> > > >> Nick's ever growing TODO list.
> > > >
> > > > I've given it a go on ARM, marking every linker-built table with KEEP()
> > > > and comparing the System.map files. The resulting kernel is around
> > > > 150k smaller, which seems good.
> > > >
> > > > However, it doesn't boot - and I don't know why. Booting the kernel
> > > > under kvmtool in a VM using virtio-console, I can find no way to get
> > > > any kernel messages out of it. Using lkvm debug, I can see that the
> > > > PC is stuck inside die(), and that's the only information I have.
> > > > It dies before bringing up the other CPUs, so it's a very early death.
> > > >
> > > > I don't think other console types are available under ARM64.
> > >
> > > earlycon?
> >
> > Through what - as I say above, I think the only thing that's present is
> > virtio-console, and the virtio stack only get initialised much later in
> > boot.
> >
> > Eg, there's the memory-based virtio driver which interfaces any virtio
> > driver to a memory-based ring structures for communication with the host
> > (drivers/virtio/virtio_mmio.c) which is initialised at module_init()
> > time, and so isn't available for earlycon.
> >
> > I don't think merely changing the module_init() calls in the appropriate
> > virtio bits will suffice - it's why I pointed out that it dies before
> > SMP initialisation, which also means that it dies before we start
> > running the initcalls for subsystems and drivers.
> >
> > I'm not aware of there being an emulated UART in the guest's address
> > space, so serial based stuff doesn't work.
>
> "earlycon=uart,mmio,0x3f8" is what you're looking for:
Does that also mean that we have a RTC at the standard PC IO addresses
as well, but in mmio space?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
next prev parent reply other threads:[~2018-03-29 17:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180325221853.10839-1-shea@shealevy.com>
2018-03-28 15:26 ` [PATCH] Extract initrd free logic from arch-specific code Shea Levy
2018-03-28 15:58 ` Rob Landley
2018-03-28 16:04 ` Shea Levy
2018-03-28 16:48 ` Russell King - ARM Linux
2018-03-28 19:04 ` Rob Landley
2018-03-28 22:14 ` Russell King - ARM Linux
2018-03-28 22:37 ` Oliver
2018-03-29 0:23 ` Nicholas Piggin
2018-03-29 15:27 ` Russell King - ARM Linux
2018-03-29 15:43 ` Geert Uytterhoeven
2018-03-29 15:58 ` Russell King - ARM Linux
2018-03-29 16:53 ` Marc Zyngier
2018-03-29 17:32 ` Russell King - ARM Linux [this message]
2018-03-29 17:53 ` Marc Zyngier
2018-03-29 17:43 ` Rob Landley
2018-03-29 16:39 ` Rob Landley
2018-03-29 17:31 ` Russell King - ARM Linux
2018-03-28 16:55 ` Kees Cook
2018-03-29 1:12 ` Wei Yang
2018-03-30 1:43 ` kbuild test robot
2018-03-30 3:16 ` kbuild test robot
2018-03-30 11:15 ` Ingo Molnar
2018-04-01 15:05 ` Shea Levy
2018-04-02 5:59 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180329173247.GF16141@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=adi-buildroot-devel@lists.sourceforge.net \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=jejb@parisc-linux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-sh@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=uclinux-h8-devel@lists.sourceforge.jp \
--cc=viro@zeniv.linux.org.uk \
--cc=vladimir.murzin@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).