piCore in QEMU

[moB]

Haven't had much success booting piCore in QEMU.

Running QEMU 2.8.1 (from 2016?) on antiX host.

1. tc5
Had some success with bmarkus' tc5 version, but nothing to be very happy about.
Can have internet or persistence, but not both.
Had both by leaving boot options (home=  tce=  opt= )  out.
Obviously TC wasn't happy: could not run extensions...

No working browser makes this tc5 a poor example of this fine OS.
Ssl and ssh are essential :^\


2. tc9
With the example Béla Márkus gives for tc9 I can get to the boot screen, but CPU stalls.
Had only one core, too. m > 1024M causes black screen fail.

My versions have sd-card added "properly", but end results are the same.
I tried virt machine to get more ram.

Code: [Select]

#!/bin/bash

QEMU_AUDIO_DRV=none

qemu-system-arm \
 -M raspi2 -m 1G \
 -kernel  $HOME/piCore/tc9/kernel4922v7.img -initrd $HOME/piCore/tc9/9.0.3v7.gz \
 -append "elevator=deadline rootwait quiet nortc nozswap dwc_otg.lpm_enable=0 \
  root=/dev/ram0 home=/dev/mmcblk0p2 tce=/dev/mmcblk0p2 opt=/dev/mmcblk0p2" \
 -dtb $HOME/piCore/tc9/bcm2709-rpi-2-b.dtb \
 -drive file=$HOME/piCore/tc9/piCore-9.0.3.img,format=raw,if=none,id=os-img \
 -device sd-card,drive=os-img \
 -serial stdio \
 -smp 4

exit
My rapi2 machine script, after bmarkus.

piCore/tc9/bmarkus-picore-2.sh gives four berries and "endless" loop of CPU stall errors, "starved for jiffies" in resized QEMU window.

No errors on host sdout.

Code: [Select]

#!/bin/bash

QEMU_AUDIO_DRV=none

qemu-system-arm \
 -cpu cortex-a15 -m 2048 -M virt \
 -kernel $HOME/piCore/tc9/kernel4922v7.img \
 -initrd $HOME/piCore/tc9/9.0.3v7.gz \
 -append "root=/dev/ram0 elevator=deadline rootwait quiet nortc console=ttyAMA0" \
 -serial stdio \
 -device virtio-gpu-pci \
 -device sdhci-pci -device sd-card,drive=os-img \
 -drive file=$HOME/piCore/tc9/piCore-9.0.3.img,format=raw,if=none,id=os-img

exit
My virt machine, after QEMU manuals...

piCore/tc9/piCore-start-virt.sh gives small black screen and host CPU at ~50%.

No error messages.



Maybe it is time to try a more modern OS on this old laptop to get a newer QEMU?
AntiX is sytemd-free, so old libraries are the rule.

Anyone else have any luck with this? I would like to hear what worked, and that it does work.

Might be fun to try and compile the "Brave" browser for piCore :^D

[Juanito]

You might get a better result with a more recent version of qemu.

[moB]

Yeah, that's a fact Juanito
(Thanks for that April Fools' irony.)

One more point. If using virt machine as compile environment I'd add a swap drive.

Code: [Select]

 
...
 -device virtio-blk-device,drive=swp-img
 -drive file=$HOME/piCore/tc9/swap.qcow2,format=qcow2,if=none,id=swp-img
...
Here's virtio block device.


It will be likely called /dev/vda1 in guest (piCore). Add it to boot options or just do a swapon once loaded. You might setup hybrid swap with both zswap (speed) and qcow (size).

Running compile environment in virt allows as much RAM as your host can spare.
No reason not to add 4G or more, like a pi4+.


Thanks for you and TC/Core group's continued work.


Sorry I've been unable to maintain the few extensions I worked on.
Was not using TC/Core and life events is why, in case anyone wonders about that.

[moB]

>> Add it to boot options or j...

oops! TC enables all possible swaps on load by default, as I recall.

[moB]

You might get a better result with a more recent version of qemu.

I'll take that advice.

Made an upgrade to qemu 4.2.0 and a brand-new 5.6.3 GNU/Linux kernel.

Retested the piCore appliances.

1. TC5

Got full funtionality, except screen resize. No VESA (x86 only, ie xvesa )

Maybe someone can figure that out, as it is all too small on the screen.

Set tce-home from command line after mounting the usb drives.
Using boot parameters broke internet.

SSH works. Install from repo.
No ssl in browsers from repo. HTTP only.

Code: [Select]

#!/bin/sh
# bmarkus' machine
# added paths - convenience over portablity

# for alsa audio, feks
# QEMU_AUDIO_DRV=alsa
QEMU_AUDIO_DRV=none

qemu-system-arm \
 -cpu arm1176 -m 256 -M versatilepb \
 -kernel $HOME/piCore/tc5/piCore-140513-QEMU \
 -initrd $HOME/piCore/tc5/piCore-140519-QEMU.gz \
 -append "root=/dev/ram0 elevator=deadline rootwait quiet nortc vga=791" \
 -serial stdio \
 -hda $HOME/piCore/tc5/tcdisk.qcow2 \
 $@

exit

# $@ allows passing more options to qemu via command arguments

piCore TC5 after bmarkus


2. TC9

Both bmarkus' and modified give similar results.

Code: [Select]

#!/bin/bash

QEMU_AUDIO_DRV=none

qemu-system-arm \
 -M raspi2 -m 1G \
 -kernel  $HOME/piCore/tc9/kernel4922v7.img -initrd $HOME/piCore/tc9/9.0.3v7.gz \
 -append "elevator=deadline rootwait quiet nortc dwc_otg.lpm_enable=0 \
  root=/dev/ram0 fsck.repair=yes console=ttyAMA0i vga=791 SNPSID=0x45F42XXX" \
 -dtb $HOME/piCore/tc9/bcm2709-rpi-2-b.dtb \
 -drive file=$HOME/piCore/tc9/piCore-9.0.3.img,format=raw,if=sd,id=os-img \
 -serial stdio \
 -smp 4 \
 $@

exit

# these both vesions OK
 -drive file=$HOME/piCore/tc9/piCore-9.0.3.img,format=raw,if=sd,id=os-img \

 -device sd-card,drive=os-img \
 -drive file=$HOME/piCore/tc9/piCore-9.0.3.img,format=raw,if=none,id=os-img \

Modified piCore-qemu after bmarkus

Tried with -append nosmp removes msgs, but just hangs.
Got past errors with a fake SNPSID.

SNPSID register contents. The value
                          should be
                          * 0x45F42XXX, which corresponds to "OT2", as in "OTG
                          version 2.XX".

https://www.linuxquestions.org/questions/linux-hardware-18/


  Ethernet on the Pi 3 B+ is gigabit ethernet over USB 2.0

  The Pis 2 and 3 used the SMSC LAN9514 chip, a USB 2.0 and 10/100 ethernet chip,
  whereas the Pi 3 B+ uses a Microchip LAN7515 chip, theoretically capable of gigabit speeds,
  although limited by the speed of the USB 2.0 bus over which it runs to the SoC.

Adding SNPSID makes error messages go, but still no inet.

piCore/tc9/newtest-picore-2.sh
[    2.694584] dwc_otg 3f980000.usb: Bad value for SNPSID: 0x00000000
[    2.748919] bcm2835_vchiq 3f00b840.vchiq: failed to set channelbase
[    3.380396] bcm2835-clk 3f101000.cprman: plla: couldn't lock PLL
...
...
...

Qemu TC screen, see the usb failing at boot (dwc_otg).

It seems to be testing that it is connected to a real usb2.x controler.
Can this test not be removed from piCore?

I can boot archlinux arm64 for raspberry pi3/4. Persistence and internet works as expected. 
Perhaps qemu-system-aarm64 differs from 32 bit version?

Code: [Select]

Restoring backup files from /mnt/mmcblk0p2/tce/mydata.tgz \
Done.
Setting hostname to box Done.

piCore
box login: login[588]: root login on 'tty1'
tc
Password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@TestBox:~$ tce-load -iw TC
Downloading: TC.tcz
wget: bad address 'repo.tinycorelinux.net'
md5sum: TC.tcz.md5.txt: No such file or directory
Error on TC.tcz
tc@TestBox:~$ sudo poweroff

Syncing all filesystems.
Disabling swap space.
Killing  all processes.
Terminating  all processes.
Unmounting all filesystems.
Shutdown in progress.

The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system poweroff
[   68.643534] reboot: Power down
[   89.953266] INFO: rcu_sched detected stalls on CPUs/tasks:
[   89.956516]  1-O..: (2 GPs behind) idle=7a1/1/0 softirq=2411/2411 fqs=0
[   89.959486]  2-O..: (2 GPs behind) idle=79f/1/0 softirq=2421/2423 fqs=0
[   89.961929]  3-O..: (0 ticks this GP) idle=515/1/0 softirq=2398/2398 fqs=0
[   89.964134]  (detected by 0, t=2132 jiffies, g=1355, c=1354, q=0)
[   89.967486] rcu_sched kthread starved for 2132 jiffies! g1355 c1354 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1


Sample output

Persistence test: see hostname.

Had to "hard off" from qemu or host terminal.

Can only interact with exported tty, not via qemu TC window, just as with the arch appliance.




Much of this trouble seems to stem from wrong/non-standard usb drivers and handling.
The rpis run a chip "theoretically capable of gigabit speeds" through the usb2 bus to the Soc.
A bit of a choke point.





3. Unable to boot on raspi3 qemu machine. Suspect usb dwc_otg again.

[moB]

The Archlinux image ran in a virt2.8 qemu-system-aarm64 machine, not a raspi3.

Thus no device tree binaries were used.

Graphical environment loaded, but unresponsive,

Can login from exported tty and use internet, update OS etc.
Must extract new kernel after upgrade
Good to add -no-reboot to qemu args?

This Arch image also ran on an rpi3b when imaged to sdcard.