From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1522345407; cv=none; d=google.com; s=arc-20160816; b=xiqC22j/hStjdhXYLzGiu5tN5TbR4tGhwnGHwkIyM0Gk1g6t0RXpnppb0m04VbTRYs cCDC+gw1S4PcsF/0SYfrLzY1RZvWM2HLRz1XRJqqmVPGTyhXaVyoYMGWjBGRRAocUSoz Vojm7Lq1+1avsbqkr2gXGSc4Aj93RYpkB4kq++6ZJnGWaRaW/NzE5VBweexIOv8xD85V 745eKyMLmjJBRRC4/F0DtVcmX9SVrIEWZAANy5ADcDXr1JyK9nFUG3v/Yipvd5LT3uR/ r7oqFgcszO42SAl+tIDIjnrFlnB+dO9SJ2wacdIUN5kzVxvyLz5u4u9hgTusH+WhI/S2 PMig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=XYm81nFVNoG1ewXl1m2LzOEska8lq95mNWr4Z6VDGjw=; b=ablymCVIp7jnl09kJr16tpn//FxNLKAv/lDDCFMQsMoBviMGYPyCSddr7wHph/nItv EDrjLJQhj4VwVCyFCLBjcRix9E1Evg2nE0sGNOgk75cVXTbfNI73w60kg5bka3sU76Qh wPwdLlVGoaXEgzDjc1wSnf00xpgw5EjzkqDRwqVohD5ne2nNqgx9Aa5d3MtbuFGa1CAy jO7zgW6qL/zBpA2VYRluWpW8jiORLoaSVZGuTt9/ebHX10IOS8ZIOlpvM9QDBmkqE5Ev YpAvXs1bE/kCq9hTJ6+k4Cu/gcT24Vk2wvQEvG5Fm4lqBohxPNHwcFnaHKwIjOyqMLxk OPWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=y+2eclM0; spf=neutral (google.com: 209.85.220.65 is neither permitted nor denied by best guess record for domain of rob@landley.net) smtp.mailfrom=rob@landley.net Authentication-Results: mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=y+2eclM0; spf=neutral (google.com: 209.85.220.65 is neither permitted nor denied by best guess record for domain of rob@landley.net) smtp.mailfrom=rob@landley.net X-Google-Smtp-Source: AIpwx4/D5SaqcquKgLTJ8OpYd7ecPwYJ1tFPpBRY8cAZncQQJ2qAvCNG1dYv0b2H4YTTwO11OMmunA== Subject: Re: [PATCH] Extract initrd free logic from arch-specific code. To: Russell King - ARM Linux , Oliver Cc: Shea Levy , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Catalin Marinas , Will Deacon , Mark Salter , Aurelien Jacquiot , Mikael Starvik , Jesper Nilsson , Yoshinori Sato , Richard Kuo , Tony Luck , Fenghua Yu , Geert Uytterhoeven , James Hogan , Michal Simek , Ralf Baechle , David Howells , Ley Foon Tan , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Palmer Dabbelt , Albert Ou , Martin Schwidefsky , Heiko Carstens , Chen Liqin , Lennox Wu , Rich Felker , "David S. Miller" , Jeff Dike , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Chris Zankel , Max Filippov , Kate Stewart , Greg Kroah-Hartman , Philippe Ombredanne , Eugeniy Paltsev , Al Viro , Vladimir Murzin , Linus Walleij , Michal Hocko , Andrew Morton , Sudip Mukherjee , Marc Zyngier , Rob Herring , Kees Cook , Vlastimil Babka , Balbir Singh , Christophe Leroy , Joe Perches , Dan Williams , Wei Yang , =?UTF-8?Q?Christian_K=c3=b6nig?= , Arnd Bergmann , Deepa Dinamani , Daniel Thompson , Florian Fainelli , linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-c6x-dev@linux-c6x.org, linux-cris-kernel@axis.com, uclinux-h8-devel@lists.sourceforge.jp, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, nios2-dev@lists.rocketboards.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev , linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-xtensa@linux-xtensa.org, Nicholas Piggin References: <20180325221853.10839-1-shea@shealevy.com> <20180328152714.6103-1-shea@shealevy.com> <05620fee-e8b5-0668-77b8-da073dc78c40@landley.net> <20180328164813.GA3888@n2100.armlinux.org.uk> <20180328221401.GA14084@n2100.armlinux.org.uk> <20180329152749.GC16141@n2100.armlinux.org.uk> From: Rob Landley Message-ID: <1ec5d19a-d649-38bd-ab89-868e1ad9dd7f@landley.net> Date: Thu, 29 Mar 2018 12:43:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180329152749.GC16141@n2100.armlinux.org.uk> Content-Type: multipart/mixed; boundary="------------292EE39B94C5DBED4CD25C9B" Content-Language: en-US X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1596195734883590774?= X-GMAIL-MSGID: =?utf-8?q?1596294858029619861?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------292EE39B94C5DBED4CD25C9B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/29/2018 10:27 AM, Russell King - ARM Linux 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 >>> 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. qemu-system-arm's "-s" option lets you hook to the hardware with gdb, as if using one of those jtags that speaks gdbserver protocol. It stops waiting for you to attach with 'target remote' it, then 'file vmlinux' to load the symbols... The miniconfig and qemu invocation I use for arm64 are attached, tested with 2.11.0 on a 4.14 kernel. You should be able to just "qemu-aarch64.sh -s" and then probably "target remote 127.0.0.1:1234"? (Been a while since I've used it, don't have a cross-gdb for arm64 lying around...) Sigh, I just tried -s and qemu 2.11.0 is _not_ waiting for gdb to attach on arm64, despite what the docs say: $ qemu-system-aarch64 --help | grep gdb -gdb dev wait for gdb connection on 'dev' -s shorthand for -gdb tcp::1234 Another random regression in qemu, gee what a surprise. > 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. I've often found useful the two line version of: https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/ Which is generally some variant of: {char *XX = "blah"; while (*XX) {while (*SERIAL_STATUS_REGISTER & OUT_READY); *SERIAL_OUT = *XX++;}} (I.E. balu cheated not spinning checking the ready-for-next-byte bit, because qemu's always angry.) That trick lets you cut and paste a print statement into all sorts of early hardware nonsense, on most architectures. You just have to look up SERIAL_STATUS_REGISTER, OUT_OK_BIT, and SERIAL_OUT values for the serial port du jour. That said I've mostly used it in things like u-boot. I dunno at what point the kernel's done enough setup that direct banging on registers would stop working. (Works in the decompresion code, anyway.) And it assumes the port's set to the right speed (usually left there by the bootloader)... Rob --------------292EE39B94C5DBED4CD25C9B Content-Type: text/plain; charset=UTF-8; name="aarch64.miniconf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="aarch64.miniconf" IyBtYWtlIEFSQ0g9YXJtNjQgYWxsbm9jb25maWcgS0NPTkZJR19BTExDT05GSUc9YWFyY2g2 NC5taW5pY29uZgojIG1ha2UgQVJDSD1hcm02NCAtaiAkKG5wcm9jKQojIGJvb3QgYXJjaC9h cm02NC9ib290L0ltYWdlCgoKQ09ORklHX01NVT15CkNPTkZJR19BUkNIX01VTFRJX1Y3PXkK Q09ORklHX0FSQ0hfVklSVD15CkNPTkZJR19TT0NfRFJBN1hYPXkKQ09ORklHX0FSQ0hfT01B UDJQTFVTX1RZUElDQUw9eQpDT05GSUdfQVJDSF9BTFBJTkU9eQpDT05GSUdfQVJNX1RIVU1C PXkKQ09ORklHX1ZEU089eQpDT05GSUdfQ1BVX0lETEU9eQpDT05GSUdfQVJNX0NQVUlETEU9 eQpDT05GSUdfS0VSTkVMX01PREVfTkVPTj15CgpDT05GSUdfU0VSSUFMX0FNQkFfUEwwMTE9 eQpDT05GSUdfU0VSSUFMX0FNQkFfUEwwMTFfQ09OU09MRT15CgpDT05GSUdfUlRDX0NMQVNT PXkKQ09ORklHX1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19EUlZfUEwwMzE9eQoKQ09ORklH X05FVF9DT1JFPXkKQ09ORklHX1ZJUlRJT19ORVQ9eQoKQ09ORklHX1BDST15CkNPTkZJR19Q Q0lfSE9TVF9HRU5FUklDPXkKQ09ORklHX1ZJUlRJT19CTEs9eQpDT05GSUdfVklSVElPX1BD ST15CkNPTkZJR19WSVJUSU9fTU1JTz15CgpDT05GSUdfQVRBPXkKQ09ORklHX0FUQV9TRkY9 eQpDT05GSUdfQVRBX0JNRE1BPXkKQ09ORklHX0FUQV9QSUlYPXkKCkNPTkZJR19QQVRBX1BM QVRGT1JNPXkKQ09ORklHX1BBVEFfT0ZfUExBVEZPUk09eQpDT05GSUdfQVRBX0dFTkVSSUM9 eQoKCiMgQ09ORklHX0VNQkVEREVEIGlzIG5vdCBzZXQKQ09ORklHX0VBUkxZX1BSSU5USz15 CkNPTkZJR19CSU5GTVRfRUxGPXkKQ09ORklHX0JJTkZNVF9TQ1JJUFQ9eQpDT05GSUdfTk9f SFo9eQpDT05GSUdfSElHSF9SRVNfVElNRVJTPXkKCkNPTkZJR19CTEtfREVWPXkKQ09ORklH X0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX1JEX0daSVA9eQoKQ09ORklHX0JMS19ERVZfTE9P UD15CkNPTkZJR19FWFQ0X0ZTPXkKQ09ORklHX0VYVDRfVVNFX0ZPUl9FWFQyPXkKQ09ORklH X1ZGQVRfRlM9eQpDT05GSUdfRkFUX0RFRkFVTFRfVVRGOD15CkNPTkZJR19NSVNDX0ZJTEVT WVNURU1TPXkKQ09ORklHX1NRVUFTSEZTPXkKQ09ORklHX1NRVUFTSEZTX1hBVFRSPXkKQ09O RklHX1NRVUFTSEZTX1pMSUI9eQpDT05GSUdfREVWVE1QRlM9eQpDT05GSUdfREVWVE1QRlNf TU9VTlQ9eQpDT05GSUdfVE1QRlM9eQpDT05GSUdfVE1QRlNfUE9TSVhfQUNMPXkKCkNPTkZJ R19ORVQ9eQpDT05GSUdfUEFDS0VUPXkKQ09ORklHX1VOSVg9eQpDT05GSUdfSU5FVD15CkNP TkZJR19JUFY2PXkKQ09ORklHX05FVERFVklDRVM9eQojQ09ORklHX05FVF9DT1JFPXkKI0NP TkZJR19ORVRDT05TT0xFPXkKQ09ORklHX0VUSEVSTkVUPXkKCg== --------------292EE39B94C5DBED4CD25C9B Content-Type: application/x-shellscript; name="qemu-aarch64.sh" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="qemu-aarch64.sh" cWVtdS1zeXN0ZW0tYWFyY2g2NCAtcyAtTSB2aXJ0IC1jcHUgY29ydGV4LWE1NyAtbm9ncmFw aGljIC1uby1yZWJvb3QgLW0gMjU2IC1hcHBlbmQgInBhbmljPTEgSE9TVD1hYXJjaDY0IGNv bnNvbGU9dHR5QU1BMCIgLWtlcm5lbCBJbWFnZSAtaW5pdHJkIGFhcmNoNjQtbGludXgtbXVz bGVhYmktcm9vdC5jcGlvLmd6ICIkQCIK --------------292EE39B94C5DBED4CD25C9B--