Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp100034imm; Tue, 28 Aug 2018 17:11:06 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaQUF6qK+OOYL1kZJoZbqFwUEHY3Fx+/Bv/qa7ta3LQRVkJKtd2raOaShSZXM/m3O+2OGsn X-Received: by 2002:a63:2402:: with SMTP id k2-v6mr3483383pgk.352.1535501466600; Tue, 28 Aug 2018 17:11:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535501466; cv=none; d=google.com; s=arc-20160816; b=ai/cUHP7u1DZ+t4vDZHklPCYf9MQt+F49uJE5JnTw0oNHDZ3mVfJGsvosbNwuatWBs JV6RZmfQ4OuOc8xJLeLkUR9FFwQKKgzOQZ69mgbT3gPGKz0bm6yh8+wQZirhAuj9IGtn 6IcD7kMhoCqaC0hK6Gbz2ZjfpDGsHVHzl43Tsz5tSkXxEHanjhfk493KBVOfadgDxUE7 9cE2Q/rfKg2hQuij/1pHJ+fpSSEPZcywQs1wF+ADKTG/qr+xZZVvDDwTQADngUd2h4F3 +Md3hkeZbMV+NrpHYNdkbF4QYr01tMZASWgDunEZxCzbcpa8D+olKe7+zHTSZrKM+4rJ ITwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature :arc-authentication-results; bh=qfmDzD2PzYhUVNGYhzDe3ODRdlx8C58B7FMKXUpotgQ=; b=DgZV3KqL6SHZOno+qNwRKgZChdpwSMsIg1Rbvsa+u1bHFWye+RvQDta0pPZHhqjh4W T6+lmcgCeoqPWmXEwtvla9pEvgq9IJMWPMviWwE8ftXxYPMs8Rtd6qeoN7d2GYvOUxwq 4vfXmLHdjrskXcRxYe706qMfkodINz6lDWvCTs3KLkDOVap0WxKUTBWfFFs3R6I6gySX fpXOt1wsFXcrYwfUaKfXneaPeMTamyZFfV0Deya1BDKc3OTBI2ysqiQupdYT+uixigJS wE1MI3boUBB3HzEe8i5ls8UhA/5C7tfkjo/xVRxXKeJut84Rmgmoa+MDFzo5vCuf3v2j YlVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b="IjCbo/oz"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k190-v6si2328271pgd.80.2018.08.28.17.10.51; Tue, 28 Aug 2018 17:11:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b="IjCbo/oz"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727139AbeH2EDL (ORCPT + 99 others); Wed, 29 Aug 2018 00:03:11 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:36424 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbeH2EDL (ORCPT ); Wed, 29 Aug 2018 00:03:11 -0400 Received: by mail-pg1-f193.google.com with SMTP id d1-v6so1489242pgo.3 for ; Tue, 28 Aug 2018 17:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=qfmDzD2PzYhUVNGYhzDe3ODRdlx8C58B7FMKXUpotgQ=; b=IjCbo/ozNMbPMfj4oDwE4GXzpdT3uam9irZETd8U1OxpeRleoSpdyYPi/omCb9WkH0 sLugz1qi4u2SDpawhRBT26rp/JyMT6+5+c9GRZ1ZnFXG2ncGXlXoqRvFR/cIs1oeEY79 VV14h3Vpf5vBj50C1GUn8dJGJXSYk6a1tmY66lpz8+M2QSid3ZIV6leMITUkiKsY9r1F p6Rl2PIxMwxXKVTVuaGKqZoXFu1HTvdkaBgS/+Xn7H8zjg7yF5Nr2T09qadc3eThmKlX O9BMzWh5jU+uAj0jqVwMPgp0qsSeIArSeemdYWCXUxiYgGsyDbEDxsc2aIQullaEj9fw X3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=qfmDzD2PzYhUVNGYhzDe3ODRdlx8C58B7FMKXUpotgQ=; b=DL7748NZRrQi+lkjM73H2Rm2MdxIMkruq52pxQPnMbqF2v9KDS8bhkPHLb8XvkVyHJ e7rftwhs/gQAVQECzAZvo4v5puzdO5i1GTztla6Tbi2gAoHFag/IDbEzx5nrAasINw4P 3S7ftgxSjqnJGkuj0kM0klU/T2XwcpODzG4Q74ym4LuW/Q2bVKNCjDP6xRzL38SyGRv9 Zl8aURfrPcpKF8KM7TW2PrU98Jf5/Y1kJqhfru1mFCHpX0IL2dC/kR3RJEFSw+MvL29l zOoMRWP2AHQy+Ys0TcyJjT6D0YtxbWoBKpAZmdgpuJ+faPG0d2+K8dsfWQEId9mmVIVd afPA== X-Gm-Message-State: APzg51BZ+AtAq2ytz686Nswxi2hcXtbpWK2/xPEFhVzpEZhQBPeP3AH7 J2lc7kPpgRyeEj7DsmyIqsRdmQ== X-Received: by 2002:a62:c60e:: with SMTP id m14-v6mr3520650pfg.40.1535501345131; Tue, 28 Aug 2018 17:09:05 -0700 (PDT) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id m15-v6sm3419571pfj.171.2018.08.28.17.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 17:09:04 -0700 (PDT) Date: Tue, 28 Aug 2018 17:09:04 -0700 (PDT) X-Google-Original-Date: Tue, 28 Aug 2018 17:09:02 PDT (-0700) Subject: Re: [PATCH] riscv: Drop setup_initrd In-Reply-To: <20180828221238.GA6605@roeck-us.net> CC: schwab@linux-m68k.org, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org From: Palmer Dabbelt To: linux@roeck-us.net Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Aug 2018 15:12:38 PDT (-0700), linux@roeck-us.net wrote: > On Tue, Aug 28, 2018 at 03:03:00PM -0700, Palmer Dabbelt wrote: >> On Tue, 28 Aug 2018 14:59:59 PDT (-0700), linux@roeck-us.net wrote: >> >On Tue, Aug 28, 2018 at 11:46:09PM +0200, Andreas Schwab wrote: >> >>On Aug 28 2018, Guenter Roeck wrote: >> >> >> >>> On Tue, Aug 28, 2018 at 01:10:20PM -0700, Palmer Dabbelt wrote: >> >>>> On Thu, 09 Aug 2018 21:11:40 PDT (-0700), linux@roeck-us.net wrote: >> >>>> >setup_initrd() does not appear to serve a practical purpose other than >> >>>> >preventing qemu boots with "-initrd" parameter, so let's drop it. >> >>>> > >> >>>> >Signed-off-by: Guenter Roeck >> >>>> >--- >> >>>> > arch/riscv/kernel/setup.c | 39 --------------------------------------- >> >>>> > 1 file changed, 39 deletions(-) >> >>>> > >> >>>> >diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >> >>>> >index 2e56af3281f8..579f58a42974 100644 >> >>>> >--- a/arch/riscv/kernel/setup.c >> >>>> >+++ b/arch/riscv/kernel/setup.c >> >>>> >@@ -82,41 +82,6 @@ EXPORT_SYMBOL(empty_zero_page); >> >>>> > /* The lucky hart to first increment this variable will boot the other cores */ >> >>>> > atomic_t hart_lottery; >> >>>> > >> >>>> >-#ifdef CONFIG_BLK_DEV_INITRD >> >>>> >-static void __init setup_initrd(void) >> >>>> >-{ >> >>>> >- extern char __initramfs_start[]; >> >>>> >- extern unsigned long __initramfs_size; >> >>>> >- unsigned long size; >> >>>> >- >> >>>> >- if (__initramfs_size > 0) { >> >>>> >- initrd_start = (unsigned long)(&__initramfs_start); >> >>>> >- initrd_end = initrd_start + __initramfs_size; >> >>>> >- } >> >>> >> >>> The underlying problem is probably that __initramfs_size == 512 even >> >>> if there is no embedded initrd. Result is that initrd_start and initrd_end >> >>> are always overwritten, even if provided and even if there is no embedded >> >>> initrd. Result is that initrd_start and initrd_end are always overwritten, >> >>> and -initrd from the qemu command line is always ignored. >> >>> >> >>> A less invasive fix than mine would be >> >>> >> >>> - if (__initramfs_size > 0) { >> >>> + if (__initramfs_size > 0 && !initrd_start) { >> >>> >> >>> Any chance you can test that with your setup ? >> >> >> >>You should just delete the last four lines above. They serve no purpose. >> >> >> > >> >You mean the entire if() statement plus the variable declarations ? >> > >> >That works for me, for both embedded initrd and initrd specified with >> >-initrd option, but we still need someone to test if it works for >> >Palmer's use case, ie with vmlinux (and possibly initrd) embedded in >> >bbl. >> >> This still boots my Fedora images >> >> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >> index db20dc630e7e..aee603123030 100644 >> --- a/arch/riscv/kernel/setup.c >> +++ b/arch/riscv/kernel/setup.c >> @@ -85,15 +85,8 @@ atomic_t hart_lottery; >> #ifdef CONFIG_BLK_DEV_INITRD >> static void __init setup_initrd(void) >> { >> - extern char __initramfs_start[]; >> - extern unsigned long __initramfs_size; >> unsigned long size; >> - if (__initramfs_size > 0) { >> - initrd_start = (unsigned long)(&__initramfs_start); >> - initrd_end = initrd_start + __initramfs_size; >> - } >> - >> if (initrd_start >= initrd_end) { >> printk(KERN_INFO "initrd not found or empty"); >> goto disable; >> >> but I have not tried an integrated initramfs. > > I tested the above both with external initrd and with integrated > initramfs; both work for me. > > Should I resend my patch, using the above, or do you want to create > a patch yourself ? You should send one, then it'll go through my regular pre-PR testing flow to make sure it works on my end. I just never trust these inline patches to be exact, even if it's unlikely there's any confusion on a patch this simple (at least, mechanically simple -- I'm afraid I still don't understand why the logic is incorrect).