Vacancy - Community Owner needed for QEMU support

Just checking in to let you know I am still chugging a long. I am following your recommendations.

Originally Posted by drmozes My guess is that -current's Kernel is too large

Is there some way to determine if the size is the issue other than recompiling with less configuration options enabled?

These are the file sizes I have:

$ ls -sah slackwarearm-14.2/kernels/armv7/zImage-armv7 slackwarearm-current/kernels/armv7/zImage-armv7  armhost/vexpress_defconfigured_kernel/zImage 
3.9M armhost/vexpress_defconfigured_kernel/zImage
3.9M slackwarearm-14.2/kernels/armv7/zImage-armv7
4.5M slackwarearm-current/kernels/armv7/zImage-armv7

Originally Posted by drmozes In -current's kernel config, CONFIG_ARCH_VEXPRESS is set, so that's a good start. Perhaps video or serial support is missing. It can happen at times when running 'make oldconfig' that things go missing (presumably because they were renamed or moved), and since I stopped testing QEMU support long ago, I never noticed.

I've been trying to compare the vexpress defconfig, 4.4.14 config, and 4.17.19 config to see what is different by using /usr/src/linux/scripts/diffconfig. I am making very little progress. All my attempts at building a kernel that displays text output in the qemu console have been a waste of time.

Originally Posted by drmozes You could build your own Kernel using the 'defconfig'. Once you get the Kernel booting, you can begin to look at what relevant options (e.g. video hardware, serial hardware, ARM specific stuff) is different; and note the options that are required and let me know so I can put them back into the armv7 kernel. You could also try taking 14.2's Kernel config for 4.4.14 and bringing it up to 4.17 and see whether that works. It'll be a massive 'make oldconfig' operation though.

Next I am going to try a "make defconfig" and add vexpress support. It will be interesting to see if it boots. I feel like "make oldconfig" will be just as confusing as comparing the diffs of the kernel configurations- so I will resort to that method last.

Let me know if you have any other suggestions. Thanks for your patience.

The installer is currently copying the d/ series. I got the kernel to boot by removing support for HVC_DCC (ARM JTAG DCC console). For those interested, my modifications can be found here: https://www.brentonearl.com/slackware/arm-dev/working/

I ran into an issue with the NFS service on my host machine. Sometimes when installing large packages like rust, kernel-firmware, kernel-source, the NFS service on my laptop closes the connection. I believe this happens only with large file transfers. I attempted to serve the Slackware ARM tree to the QEMU client over HTTP instead. A HTTP network installation takes quite a bit longer to parse/copy package information. I did not go through with the HTTP network installation and killed it after verifying it was a working alternative to using an NFS share.

There wasn't much output in the NFS logs other than:

[63788.225568] rpc-srv/tcp: nfsd: sent only 137560 when sending 1048708 bytes - shutting down socket

When researching the possible cause, I came across this server fault entry: https://serverfault.com/questions/88...ending-1048708

I originally used the rc.local-additions script to set up my ethernet bridge with a tap device. After a lot of fiddling around with the script, I decided to use rc.inet1.conf to configure the network bridge, since it works well on my Slackware-current host. I think I will document my rc.inet1.conf configuration changes in the SlackDoc and include the server fault work around. I do not entirely understand how to configure the txqueuelen setting or why it is necessary. I haven't made time to investigate any further because the installer works with the change. I added the following to the end of my /etc/rc.d/rc.local:

ip link set br0 txqueuelen 10000
ip link set eth0 txqueuelen 10000
ip link set tap0 txqueuelen 10000

I believe that this work around solves the "hang up" that stormtracknole mentions earlier in this thread. Basically, due to the high latency of the QEMU emulator, the NFS service on my laptop shuts down the network connection. So increasing the txqueuelen setting accommodates the slow speed of QEMU emulating ARM. In the end I successfully installed Slackwarearm-current after making that change to my network settings. I think that a higher grade NIC and network speed would not require a different configuration of txqueuelen. However, I am running a 1 Gbps LAN with Cat 6 cabling and I think this is roughly the standard for most home users. I understand that QEMU is communicating with the host over the virtual network, but some user may decide to use a real network to host NFS instead.

When I boot the fresh SlackARM installation, it cannot find the root partition. I think a new ram disk may solve this problem, but am not sure yet. Some help in creating a fresh RAM disk from the kernel I compiled would be great. The system I installed does not boot. I took a look at scripts in slackwarearm-current/source/k/ but have not made an effort to create a ram disk just yet.

[   15.575759] urandom_read: 2 callbacks suppressed
[   15.576047] random: vgchange: uninitialized urandom read (4 bytes read)
mount: mounting /dev/mmcblk0p2 on /mnt failed: No such file or directory
ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead.
        You can try to fix it. Type 'exit' when things are done.

/bin/sh: can't access tty; job control turned off
/ #

I began to document the process of installing Slackware ARM. I know the original post indicates you want a separate SlackDoc for each Slackware release. However, I do not think that is necessary because the process is mostly the same across all stable releases.
With that said, I have not had a chance to verify the 14.0, 14.1, or 14.2 documentation still works.

Originally Posted by mralk3 I ran into an issue with the NFS service on my host machine.

Aha. I ran in to this one as well but didn't debug it.
I'm building a new 4.17 Kernel without CONFIG_HVC_DCC set, and I'll try those interface tweaks and report back.

Originally Posted by mralk3 I began to document the process of installing Slackware ARM. I know the original post indicates you want a separate SlackDoc for each Slackware release. However, I do not think that is necessary because the process is mostly the same across all stable releases. With that said, I have not had a chance to verify the 14.0, 14.1, or 14.2 documentation still works.

The only reason for having a separate version for each release is that from a maintenance point of view, I find it easier to version them, since there are occasionally changes to U-boot and the Kernel that would complicate a single document, since it'd need to have exceptions for some releases.
For QEMU though, it makes sense what you're saying: unless the Slackware installation process changes substantially, the documentation is more tied to the version of QEMU and the Slackware x86 host. The '%SLACKTREE%' is actually a token that's substituted by the distribution processing scripts for each release. For the wiki version of the document you could set it a shell variable.

Thanks for all of your work on this! It looks like it'll be working again soon.
I'll have a look at 4.19 again soon as well.

Originally Posted by drmozes Aha. I ran in to this one as well but didn't debug it. I'm building a new 4.17 Kernel without CONFIG_HVC_DCC set, and I'll try those interface tweaks and report back. [..snip..] The only reason for having a separate version for each release is that from a maintenance point of view, I find it easier to version them, since there are occasionally changes to U-boot and the Kernel that would complicate a single document, since it'd need to have exceptions for some releases. For QEMU though, it makes sense what you're saying: unless the Slackware installation process changes substantially, the documentation is more tied to the version of QEMU and the Slackware x86 host. The '%SLACKTREE%' is actually a token that's substituted by the distribution processing scripts for each release. For the wiki version of the document you could set it a shell variable. Thanks for all of your work on this! It looks like it'll be working again soon. I'll have a look at 4.19 again soon as well.

You're very welcome! I will figure out a way to document the process in some way that includes/excludes what is necessary and link to the QEMU directions. I used QEMU 3.0.0 from Ponce's GitHub repository, maybe I will test with 2.12.0 from SBo. I may have to take an old laptop I have here and test the QEMU directions with 14.2 since my laptop is running -current. I will keep a close eye on the change log!

Originally Posted by mralk3 You're very welcome! I will figure out a way to document the process in some way that includes/excludes what is necessary and link to the QEMU directions. I used QEMU 3.0.0 from Ponce's GitHub repository, maybe I will test with 2.12.0 from SBo. I may have to take an old laptop I have here and test the QEMU directions with 14.2 since my laptop is running -current. I will keep a close eye on the change log!

You don't need to test 14.2 because it already works (or did when I tried it at release time).
Unless the scripts need the interface tweaks - that could be a possibility. If so let me know and I'll update them for the 14.2 documentation. You only need to support -current and the forthcoming stable releases going forward.

Originally Posted by drmozes You don't need to test 14.2 because it already works (or did when I tried it at release time). Unless the scripts need the interface tweaks - that could be a possibility. If so let me know and I'll update them for the 14.2 documentation. You only need to support -current and the forthcoming stable releases going forward.

I was in the #slackware irc channel the other day and someone mentioned that setting up a bridged NIC and tap device with rc.inet1.conf was much easier in Slackware-current than previously in 14.2 and earlier. Normally I use NetworkManager (for easy VPN access) on my laptop and I couldn't figure out for the life of me how to set up a network bridge for QEMU through the nm-applet GUI. The rc.inet.conf method was much more simple to configure.

Do you prefer I include the commands from the rc.local-additions script in the documentation?

Or should I just document how I am using rc.inet1.conf?

The only changes I made to rc.inet1.conf were:

IFNAME[0]="br0"
BRNICS[0]="eth0"
IPADDR[0]=""
NETMASK[0]=""
IPALIASES[0]=""
USE_DHCP[0]="yes"
DHCP_HOSTNAME[0]=""

..snip..

VIRTIFNAME[0]="tap0"
VIRTIFTYPE[0]="tap"
VIRTIFUSER[0]="root"
VIRTIFGROUP[0]="root"

After that I just had to modify the installer_launch script like this:

[bearl@mothership ~/slackwarearm/armhost]$ cat installer_launch | sed '/^#/d'

VISUALOUTPUT="-nographic"
KAPPEND="console=ttyAMA0,115200n8"
KEYBOARD="en-us"
NETTAP="-net nic${MACADDR} -net tap,ifname=tap0,script=qemu-network-tun.sh,downscript=qemu-network-tun-down.sh"

qemu-system-arm $VISUALOUTPUT $NETTAP \
   -m 1024 \
   -M vexpress-a9 \
   -k $KEYBOARD \
   -rtc base=localtime \
   -no-reboot \
   -sd sdcard.img \
   -append "TERM=xterm-256color vmalloc=256MB $KAPPEND nofont nic=auto:eth0:dhcp root=/dev/ram rw" \
   -kernel working/zImage \
   -dtb working/vexpress-v2p-ca9.dtb \
   -initrd stock/initrd-armv7.img

I changed the static IP in the BRIDGEIP variable referenced by qemu-network-tun.sh to match my network, 192.168.150.4. After that I created qemu-network-tun-down.sh:

[bearl@mothership ~/slackwarearm/armhost]$ cat qemu-network-tun.sh 
#!/bin/sh

# This is the IP of 'tap0' on the Slackware/x86 host:
BRIDGEIP=192.168.150.4

modprobe tun
/sbin/ifconfig $1 $BRIDGEIP netmask 255.255.255.0
/sbin/brctl addif br0 $1

[bearl@mothership ~/slackwarearm/armhost]$ cat qemu-network-tun-down.sh 
#!/bin/sh

/sbin/ifconfig $1 down
/sbin/brctl delif br0 $1

I was able to get a working bridge for QEMU using the rc.local-additions shell script, but it took a lot more time to figure it all out. The rc.inet1.conf method was FAR simpler to configure and all my network settings were automated after that point with only a few minutes of effort.

Originally Posted by mralk3 Do you prefer I include the commands from the rc.local-additions script in the documentation? Or should I just document how I am using rc.inet1.conf?

Both, preferably, since you're offered which mode of configuration you want in the final stages of the installer.
The thing is that this stuff probably won't change in the near future so it should be zero or low maintenance (at least the rc.inet1.conf approach - I can't comment for Network Manager though as that's not developed by Slackware).

I've got the OS booting under QEMU now. I'll upload the latest packages later, along with how I figured out which module was missing.
Thanks again!

I thought it might be useful to show how to figure out which modules are missing from the OS' initrd.

The Slackware ARM installer contains many more modules, so generally is able to support much of the regular hardware.
The OS initrd has to be just enough to be able to address the storage and file system, and bootstrap the OS from it. Occasionally the module support is moved to another module, or in this case, it's been renamed. In such situations, the easiest route I find is to boot the Slackware installer and use the tools to figure out what's going on!

The situation with QEMU was:-
Boot the OS initrd. It fails to find the OS since the driver for the MMC storage isn't present. We can tell since there's no entry for mmcblk0 in /dev (the boot message states that).

At the initrd's shell, generate a list of modules loaded in to the initrd:

mount: mounting /dev/mmcblk0p2 on /mnt failed: No such file or directory
ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead.
        You can try to fix it. Type 'exit' when things are done.

/bin/sh: can't access tty; job control turned off
/ # lsmod | awk '{print $1}' | sort

Copy that from the terminal clipboard in to a file on another machine.

Since the system is in a state where the run levels don't exist (as there's no proper 'init' loaded yet) we'll trigger the reboot directly:

/ # echo b > /proc/sysrq-trigger

Boot the Slackware installer in QEMU.


Within the installer, determine where the mmcblk stuff is:

root@slackware:~# ls -la /sys/dev/block/ | grep mmcblk0
lrwxrwxrwx 1 root root 0 Jan  1  1970 179:0 -> ../../devices/platform/smb\@4000000/smb\@4000000:motherboard/smb\@4000000:motherboard:iofpga\@7,00000000/10005000.mmci/mmc_host/mmc0/mmc0:4567/block/mmcblk0/
lrwxrwxrwx 1 root root 0 Jan  1  1970 179:1 -> ../../devices/platform/smb\@4000000/smb\@4000000:motherboard/smb\@4000000:motherboard:iofpga\@7,00000000/10005000.mmci/mmc_host/mmc0/mmc0:4567/block/mmcblk0/mmcblk$
lrwxrwxrwx 1 root root 0 Jan  1  1970 179:2 -> ../../devices/platform/smb\@4000000/smb\@4000000:motherboard/smb\@4000000:motherboard:iofpga\@7,00000000/10005000.mmci/mmc_host/mmc0/mmc0:4567/block/mmcblk0/mmcblk$

Which module does it use?

root@slackware:~# ls -la /sys/dev/block/179:0/device/driver
lrwxrwxrwx 1 root root 0 Nov  6 11:48 /sys/dev/block/179:0/device/driver -> ../../../../../../../../../bus/mmc/drivers/mmcblk/

What's it called when loaded, though?

root@slackware:~# lsmod | grep mmc
armmmci                24576  0
mmc_block              36864  0
mmc_core              102400  3 mvsdio,mmc_block,armmmci

Which of these is absent from the OS initrd's module list?

prisere [tmp] # egrep 'armmmci|mmc_' initrd-list
mmc_block
mmc_core
prisere [tmp] #

Check kernel.SlackBuild:

# For SDHC/MMC cards:
INITRDCARDS="mvsdio:mmci:mmc_block"

The "mmci" is present, but it appears to have been renamed to "armmmci"
Change it and rebuild the Kernel packages.

Reboot the installer, get to shell.

 # mkdir /disk /server
 # mount -onolock server:/ /server
 # mount /dev/mmcblk0p2 /disk
 # ROOT=/disk installpkg /server/devel/slackwarearm-current/slackware/a/kernel_arm*z
 # reboot

Copy the new zImage and initrd to the directory that contains the qemu loader script.
Start QEMU.

Starting gpm:  /usr/sbin/gpm -m /dev/mouse -t imps2


Welcome to Linux 4.17.19-armv7 armv7l (ttyAMA0)

mutley login:

"Boom"

Thanks for the run down. I went as far as creating a fresh ram disk but didn't think that that kernel module was renamed. It was very strange to see that the installer recognized the emulated sdcard, but the resulting installation did not recognize it. I am impressed with your Slack-fu! Of course, it all makes sense now that you explained it.

I've been a bit busy today so I was glad to see you had some time to take a look. With the refreshed kernel and ram disk I will run through the installer in the coming days just to be certain the SlackDoc will be accurate for -current.

Originally Posted by mralk3 Thanks for the run down. I went as far as creating a fresh ram disk but didn't think that that kernel module was renamed. It was very strange to see that the installer recognized the emulated sdcard, but the resulting installation did not recognize it. I am impressed with your Slack-fu! Of course, it all makes sense now that you explained it. I've been a bit busy today so I was glad to see you had some time to take a look. With the refreshed kernel and ram disk I will run through the installer in the coming days just to be certain the SlackDoc will be accurate for -current.

When you're done, I'll add the INSTALL_QEMU document back to the -current tree, with simple instructions to visit the wiki URL.

Ok great. I was abnormally busy the last few days. I will be working on it again this weekend.

Originally Posted by mralk3 Ok great. I was abnormally busy the last few days. I will be working on it again this weekend.

I'm pushing out Linux 4.19.1 today. I tested QEMU installation and OS booting and it works.
The OS takes ages to boot, but it gets there in the end.

If you were anticipating building any new kernels using the ARM source tree, you'd need to upgrade to the latest slackkit package, as there's a new function in there that the build scripts use.

Hi

I have re-organised https://docs.slackware.com/howtos:hardware:arm:start
The "release" page for -current has QEMU within the "officially supported" hardware (since the hardware support is), and the installation document links to your page there.
I will add a "pointer" document within -current in the next batch.

When you've tested everything with 4.19 please can you email me the new versions of the scripts and I'll upload them to the FTP site within a "-current" dir.
Upon release of 15.0, I'll cp -fa slackwarearm-current slackwarearm-15.0

Thanks!
s.

Originally Posted by drmozes I'm pushing out Linux 4.19.1 today. I tested QEMU installation and OS booting and it works. The OS takes ages to boot, but it gets there in the end. If you were anticipating building any new kernels using the ARM source tree, you'd need to upgrade to the latest slackkit package, as there's a new function in there that the build scripts use.

I am doing a fresh installation right now. I will let you know if I run into any trouble. I haven't used the slackkit package because my build system uses the SARPi kernel and firmware. I am sure there is a way I can do so. I typically manually build and copy the zImage, ram disk, and dtb to my laptop over NFS. I plan to buy an Orange Pi soon so that I can actually test any kernel I compile on real metal. I welcome any advice you have about useful hardware for testing.

Originally Posted by drmozes Hi I have re-organised https://docs.slackware.com/howtos:hardware:arm:start The "release" page for -current has QEMU within the "officially supported" hardware (since the hardware support is), and the installation document links to your page there. I will add a "pointer" document within -current in the next batch. When you've tested everything with 4.19 please can you email me the new versions of the scripts and I'll upload them to the FTP site within a "-current" dir. Upon release of 15.0, I'll cp -fa slackwarearm-current slackwarearm-15.0 Thanks! s.

I plan to flesh out the Installation section a bit more. I am aware that I need to add a short section discussing how to boot the installed system. There are minor changes to the scripts with just one additional script that brings down the tap NIC after QEMU shuts down. Thank's for your patience, on top of being a busy with other responsibilities, I have been sick with the flu too!