On Fri, Sep 18, 2020 at 1:44 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Fri, 18 Sep 2020 at 22:03, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > > > On Wed, Sep 16, 2020 at 11:01 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Thu, 17 Sep 2020 at 00:25, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> 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
