From: Nick Desaulniers <ndesaulniers@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Russell King <linux@armlinux.org.uk>,
Linus Walleij <linus.walleij@linaro.org>,
Nicolas Pitre <nico@fluxnic.net>, Stefan Agner <stefan@agner.ch>,
Peter Smith <Peter.Smith@arm.com>, Marc Zyngier <maz@kernel.org>,
Will Deacon <will@kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Jian Cai <jiancai@google.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references
Date: Fri, 18 Sep 2020 14:06:40 -0700 [thread overview]
Message-ID: <CAKwvOdnrKcvJpomHPt_SCjQSW3iBOLFE=7hf0L1H3X1rW6GkQQ@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXEM=bW6DdPDDeFOWi47O6JOu_czui9Y2BJfjiVdQ1CvOw@mail.gmail.com>
On Fri, Sep 18, 2020 at 1:44 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 18 Sep 2020 at 22:03, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Sep 16, 2020 at 11:01 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Thu, 17 Sep 2020 at 00:25, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > > > Also, it looks like the GCC build of milbeaut_m10v_defconfig fails to
> > > > boot for me in QEMU; so maybe not just a Clang bug (or maybe, more
> > > > than one bug). (or maybe one of my command line params to QEMU is
> > > > wrong).
> > > >
> > >
> > > I understand that this is actually an existing issue in -next, but in
> > > general, why would you expect to be able to boot
> > > milbeaut_m10v_defconfig on anything other than a Milbeaut MV10
> > > machine?
> >
> > We've been booting other configs in QEMU for a few years now, so I
> > don't see why yet another config would hurt. Maybe there's some
> > hardware dependency, but I guess we'd find that out trying to boot it
> > in QEMU. If it boots in QEMU, I guess not booting on metal wasn't so
> > bad? Maybe this is considered an antipattern, but you can see how if
> > we've been getting away with it for years then that would lead to such
> > expectations.
> >
> > > (whatever it is) Or does QEMU emulate a milbeaut machine?
> >
> > $ qemu-system-arm -machine help
> >
> > doesn't print anything that looks like it, on initial glance. Looks
> > like a socionext part:
> > https://www.socionext.com/en/pr/sn_pr20170105_01e.pdf
> >
> > > If
> > > not, better to stick with configs that are intended to boot on the
> > > QEMU machine emulation that you are using.
> >
> > I can see in our CI that we've been building+boot testing
> > multi_v5_defconfig, aspeed_g5_defconfig, and multi_v7_defconfig for a
> > while now without specifying any machine. Is there a preferred
> > machine we should be using for those? (It looks like qemu supports
> > ast2500-evb and ast2600-evb; is ARM1176 and ARMv6 core? Is that what
> > aspeed_g5 uses? Why is virt versioned? Ahhhh!!!!)
> >
>
> Milbeaut's serial output is on a "socionext,milbeaut-usio-uart" UART,
> and its defconfig does not include drivers for the PL011 or 8250/16550
> UARTs that you typically find on other boards. So how on earth would
> you expect to get any output at all if QEMU does not emulate this
> exact machine?
breakpoints in panic()/printk(), lx-dmesg in GDB via
CONFIG_GDB_SCRIPTS=y generally works. :^)
I guess one thing I don't understand is how to check what UART or what
the name of the tty device would be. I can grep for
"socionext,milbeaut-usio-uart" and see where it's defined, but I never
would have/still don't know how to find that. Please teach me how to
fish. I understand the point of DT, and see
arch/arm/boot/dts/milbeaut-m10v.dtsi
76: compatible = "socionext,milbeaut-usio-uart";
but the comment about ttyUSI0 is confusing to me; that identifier
doesn't appear anywhere else in the kernel sources.
I generally have the same problem trying to run Pixel kernels in QEMU;
I don't understand how to determine which serial driver is being used,
and what the tty device would be named. So I just enable the PLO11
driver.
Only last week I found that trying to use a shell as init without any
serial output can result in the shell exiting, panicking the kernel,
which doesn't print over serial...goose chase...
> In general, if you use QEMU/mach-virt, the only defconfigs you should
> reasonably be testing are the ones that contain CONFIG_ARCH_VIRT=y.
Looks like then that would only be multi_v7_defconfig. How do we
continue to verify we can boot ARMv6 or ARMv5 under virtualization?
There are such machines in QEMU, but then no defconfigs in the kernel.
--
Thanks,
~Nick Desaulniers
prev parent reply other threads:[~2020-09-18 21:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 9:56 [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Ard Biesheuvel
2020-09-14 9:56 ` [PATCH 01/12] ARM: assembler: introduce adr_l, ldr_l and str_l macros Ard Biesheuvel
2020-09-15 7:35 ` Ard Biesheuvel
2020-09-15 17:51 ` Nick Desaulniers
2020-09-14 9:56 ` [PATCH 02/12] ARM: efistub: replace adrl pseudo-op with adr_l macro invocation Ard Biesheuvel
2020-09-14 9:56 ` [PATCH 03/12] ARM: module: add support for place relative relocations Ard Biesheuvel
2020-09-14 13:35 ` Nicolas Pitre
2020-09-14 16:11 ` Russell King - ARM Linux admin
2020-09-14 9:56 ` [PATCH 04/12] ARM: head-common.S: use PC-relative insn sequence for __proc_info Ard Biesheuvel
2020-09-14 9:56 ` [PATCH 05/12] ARM: head-common.S: use PC-relative insn sequence for idmap creation Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 06/12] ARM: head.S: use PC-relative insn sequence for secondary_data Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 07/12] ARM: kernel: use relative references for UP/SMP alternatives Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 08/12] ARM: head: use PC-relative insn sequence for __smp_alt Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 09/12] ARM: sleep.S: use PC-relative insn sequence for sleep_save_sp/mpidr_hash Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 10/12] ARM: head.S: use PC-relative insn sequences for __fixup_pv_table Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 11/12] ARM: head.S: use PC relative insn sequence to calculate PHYS_OFFSET Ard Biesheuvel
2020-09-14 9:57 ` [PATCH 12/12] ARM: kvm: replace open coded VA->PA calculations with adr_l call Ard Biesheuvel
2020-09-14 14:06 ` [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Nicolas Pitre
2020-09-15 19:32 ` Nick Desaulniers
2020-09-15 21:29 ` Ard Biesheuvel
2020-09-15 23:31 ` Nick Desaulniers
2020-09-16 5:54 ` Ard Biesheuvel
2020-09-16 19:53 ` Nick Desaulniers
2020-09-16 20:45 ` Ard Biesheuvel
2020-09-16 21:25 ` Nick Desaulniers
2020-09-17 0:16 ` Nick Desaulniers
2020-09-17 5:19 ` Mike Rapoport
2020-09-17 6:01 ` Ard Biesheuvel
2020-09-18 20:03 ` Nick Desaulniers
2020-09-18 20:44 ` Ard Biesheuvel
2020-09-18 21:06 ` Nick Desaulniers [this message]
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='CAKwvOdnrKcvJpomHPt_SCjQSW3iBOLFE=7hf0L1H3X1rW6GkQQ@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=Peter.Smith@arm.com \
--cc=ardb@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=jiancai@google.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=masahiroy@kernel.org \
--cc=maz@kernel.org \
--cc=natechancellor@gmail.com \
--cc=nico@fluxnic.net \
--cc=stefan@agner.ch \
--cc=will@kernel.org \
/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 NNTP newsgroup(s).