Re: Adding or1k support to mkroot.

[Stafford Horne <shorne@gmail.com>]

Hi Rob,

It's been a while :)

On Tue, Dec 12, 2023 at 04:16:15AM -0600, Rob Landley wrote:
> Toybox has a tiny system builder in it, a ~300 line bash script that builds
> Linux for a dozen targets (using musl-cross-make toolchains) and boots the
> result to a shell prompt under QEMU:
> 
> https://github.com/landley/toybox/blob/master/mkroot/mkroot.sh
> https://landley.net/bin/mkroot/latest/
> 
> And since musl and qemu both support openrisc (and I need an or1k toolchain
> anyway for my orange pi 3b's power controller firmware, at least according to
> u-boot's board/sunxi/README.sunxi64), I thought I'd try to make that target work.

Great.

> I built an or1k musl+gcc toolchain with my wrapper script around Rich Felker's
> musl-cross-make project by adding "or1k::" to the TARGETS list in
> https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh#L34 and
> that seems to have worked-ish. (Well, the kernel headers didn't install because
> I have to add or1k->openrisc to musl-cross-make's TARGET_ARCH_MANGLED in
> litecross/Makefile, but eh, close enough for the moment.)
> 
> With the resulting toolchain, I can build an or1ksim_defconfig kernel (using
> v6.6 source) that "qemu-system-or1k -nographic -kernel vmlinux" gives boot
> messages for! Woo! (And then panics because no init, but that's standard for
> board bringup.)
> 
> Some immediately obvious problems are:
> 
> 1) qemu's -append is ignored, the "Kernel command line: earlycon" is hardwired
> into the device tree.
> 
> 2) Nothing I do seems to get qemu to exit instead of hanging,
> CONFIG_PANIC_TIMEOUT=1 makes it _try_ to reboot but adding the CONFIG_POWER
> symbols from arch/openrisc/configs/virt_defconfig doesn't seem to affect qemu,
> and none of the other targets mention power. (If I can't exit the emulator at
> the end then https://github.com/landley/toybox/blob/master/mkroot/testroot.sh
> can't report success for the architecture.)

I use the virt_defconfig for my testing.

> 3) If I feed qemu-system-or1k an -initrd the same kernel does NOT give me boot
> messages, it just hangs.

Maybe earlycon is not working?

This are my qemu arguments:

qemu-system-or1k -cpu or1200 -machine virt \
  -no-reboot -kernel /home/shorne/work/linux/vmlinux \
  -device virtio-net-pci,netdev=user \
  -netdev user,id=user,net=10.9.0.1/24,host=10.9.0.100,hostfwd=tcp::2222-:22 \
  -serial mon:stdio -nographic -device virtio-blk-device,drive=d0 \
  -drive file=/home/shorne/work/openrisc/or1k-utils/buildroot/output/qemu-fs-or1k.qcow2,id=d0,if=none,format=qcow2 \
  -gdb tcp::10001 \
  -accel tcg,thread=multi \
  -smp cpus=4 -m 768 \
  -append rootwait \
  -append boot=/dev/vda2

With this and the virt kernel and qemu virt machine I am able to shut down the
machine is setup with poweroff and reboot hardware (syscon-poweroff) from
SiFive MMIO.

If I remove the `-drive` argument I do get boot messages.

> Well, SORT OF. If I feed -initrd 2 megabytes copied from /dev/null by dd, I get
> boot messages. If I go "true | gz > blah.gz" to create the smallest (20 byte) gz
> file and feed it that, no boot messages. Feed it System.map: boot messages. Feed
> it vmlinux: no boot messages.

I use a root image I created with buildroot.  But you should be able to get boot
messages before initrd is picked up.  I am not sure why your invalid initrd's
are able to create boot messages or not.

Do you have a valid initrd that maybe I can try out?  I recently use qcow2
images to build, but I did used to use initrd images and it did work fine.

> Any idea what's going on here? That last one's kind of a blocker...

Have you tried to debug where it's getting hung up?  Gdb remote debug should
be working for or1k.

-Stafford