On Fri, Sep 18, 2020 at 1:44 PM Ard Biesheuvel [off-list ref] wrote:

On Fri, 18 Sep 2020 at 22:03, Nick Desaulniers [off-list ref] wrote:

quoted

On Wed, Sep 16, 2020 at 11:01 PM Ard Biesheuvel [off-list ref] wrote:

quoted

On Thu, 17 Sep 2020 at 00:25, Nick Desaulniers [off-list ref] wrote:

quoted

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.

quoted

(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

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel