Vacancy - Community Owner needed for QEMU support

Hello

The QEMU support in Slackware ARM is in need of one or more careful owners.
If you'd like to help maintain it, apply below! If more than one want to do it, you should set up a group between yourselves.



Role & Responsibilities

1. Testing the full OS installation using the Slackware installer:

• As frequently as possible (perhaps once every two months)
• At least two-three months in advance of a Slackware release (you will be notified when the tests should begin, so that there is time to feed any required changes back in to Slackware ARM)

2. Continuous testing

• Keeping an installation of -current up to date:
• Rebooting in to new kernels
• Testing Xorg (using a light weight window manager - not KDE!)

3. Maintaining documentation

Initially, you should take the QEMU installation instructions from the -current tree and copy it to docs.slackware.com.

There will be a document per release - e.g. one page for 14.2, 15.0, -current and so on.
This is because occasionally, the instructions need to change to accommodate changes in the Kernel parameters, installer and so on -- and it's cleaner to have only the information required on the page, rather than to be confronted with a list of rules for particular releases.

4. QEMU installer and OS boot script maintenance

The QEMU build should reference the one held on slackbuilds.org.
You will need to test and maintain the scripts used to boot the installer and the OS,
maintaining a change log within the scripts as to which versions of QEMU and Slackware they have been tested with.
Again, the scripts should be maintained for a particular Slackware release for the same reasons as the documentation. However, note that the scripts may need maintenance as newer releases of QEMU are released.

5. Feeding fixes upstream

You'll feed any required fixes for the QEMU support (for example, additional Kernel modules required in the installer or OS initrd) back upstream to the Slackware ARM maintainer (me).

Compensation

The salary is paid in satisfaction of doing something you like, and learning more about Linux and Slackware.

Application process
The QEMU support is currently non-functional in -current. Your application process is to fix it and report back with the changes needed.

Originally Posted by drmozes Hello The QEMU support in Slackware ARM is in need of one or more careful owners. If you'd like to help maintain it, apply below! If more than one want to do it, you should set up a group between yourselves. Role & Responsibilities 1. Testing the full OS installation using the Slackware installer: As frequently as possible (perhaps once every two months) At least two-three months in advance of a Slackware release (you will be notified when the tests should begin, so that there is time to feed any required changes back in to Slackware ARM) 2. Continuous testing Keeping an installation of -current up to date: Rebooting in to new kernels Testing Xorg (using a light weight window manager - not KDE!) 3. Maintaining documentation Initially, you should take the QEMU installation instructions from the -current tree and copy it to docs.slackware.com. There will be a document per release - e.g. one page for 14.2, 15.0, -current and so on. This is because occasionally, the instructions need to change to accommodate changes in the Kernel parameters, installer and so on -- and it's cleaner to have only the information required on the page, rather than to be confronted with a list of rules for particular releases. 4. QEMU installer and OS boot script maintenance The QEMU build should reference the one held on slackbuilds.org. You will need to test and maintain the scripts used to boot the installer and the OS, maintaining a change log within the scripts as to which versions of QEMU and Slackware they have been tested with. Again, the scripts should be maintained for a particular Slackware release for the same reasons as the documentation. However, note that the scripts may need maintenance as newer releases of QEMU are released. 5. Feeding fixes upstream You'll feed any required fixes for the QEMU support (for example, additional Kernel modules required in the installer or OS initrd) back upstream to the Slackware ARM maintainer (me). Compensation The salary is paid in satisfaction of doing something you like, and learning more about Linux and Slackware. Application process The QEMU support is currently non-functional in -current. Your application process is to fix it and report back with the changes needed.

Hello good Doctor! I can give this a try if you are still looking for people. I have quite a few powerful machines at home. If I understand correctly, do you want us to go through the instructions for -14.2 and see if I can get it to work on -current?

Originally Posted by stormtracknole If I understand correctly, do you want us to go through the instructions for -14.2 and see if I can get it to work on -current?

Basically, yes. -current has an updated version of the QEMU installation documentation, so you can start from there.

FYI, the qemu directory seems to be missing in the boardsupport section.

Originally Posted by stormtracknole FYI, the qemu directory seems to be missing in the boardsupport section.

Thanks - that was an easy one to fix :-)

Originally Posted by drmozes Thanks - that was an easy one to fix :-)

Thank you! Doing an install right now of -current. I had for gotten how sloooooooooooow arm emulation was on qemu.

Install is still going!!! That or it froze. I'll report back later.

Pretty sure the installer hung up. Last package it tried to install was:

libtool-2.4.6-arm-5: a generic library support script .................. [2.4M]

Originally Posted by stormtracknole Thank you! Doing an install right now of -current. I had for gotten how sloooooooooooow arm emulation was on qemu.

I am trying to pick up where you left off. I followed the documentation and am having problems getting the installer to boot. I get as far as executing "installer_launch" and end up at a black screen in qemu. top reports that one cpu core is running at 100%. I left qemu running for about 15 minutes now and it's still a black screen but no error output. I did significant research, tried many different boot options, qemu switches, and I get the same result.

I am running Slackware64-current with Qemu 2.12.0. I also tried with Qemu 3.0.0 without any change. I read online that a black screen and no output means the kernel crashed, or some other problem. The issue is that I have absolutely nothing to go on to troubleshoot this. Any and all ideas are welcome.

Originally Posted by mralk3 I am trying to pick up where you left off. I followed the documentation and am having problems getting the installer to boot. I get as far as executing "installer_launch" and end up at a black screen in qemu. top reports that one cpu core is running at 100%. I left qemu running for about 15 minutes now and it's still a black screen but no error output. I did significant research, tried many different boot options, qemu switches, and I get the same result. I am running Slackware64-current with Qemu 2.12.0. I also tried with Qemu 3.0.0 without any change. I read online that a black screen and no output means the kernel crashed, or some other problem. The issue is that I have absolutely nothing to go on to troubleshoot this. Any and all ideas are welcome.

Welcome to my world. It's amazing when that happens :-)
It might be that the Kernel is too large and so is truncated/corrupt, hence cannot boot and provide diagnostics.
I just tested the -current kernel and it provides no output. Simply switching to the the Linux Kernel ('zImage-armv7') v4.4.14 from Slackware ARM 14.2 boots -current's Slackware Installer.

My guess is that -current's Kernel is too large or perhaps has dropped support for some aspect of that device.
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.

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.

Originally Posted by drmozes Welcome to my world. It's amazing when that happens :-) It might be that the Kernel is too large and so is truncated/corrupt, hence cannot boot and provide diagnostics. I just tested the -current kernel and it provides no output. Simply switching to the the Linux Kernel ('zImage-armv7') v4.4.14 from Slackware ARM 14.2 boots -current's Slackware Installer. My guess is that -current's Kernel is too large or perhaps has dropped support for some aspect of that device. 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. 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.

Yes. Just about the only thing I haven't tried is compiling my own kernel. Most of the guides online suggest this should be done before even attempting to boot with vexpress-a9. I will have to use my spare Raspberry Pi 3 B to cross compile. I have never done this before. I apologize in advance for any future questions that might seem elementary.

Originally Posted by mralk3 Yes. Just about the only thing I haven't tried is compiling my own kernel. Most of the guides online suggest this should be done before even attempting to boot with vexpress-a9. I will have to use my spare Raspberry Pi 3 B to cross compile. I have never done this before. I apologize in advance for any future questions that might seem elementary.

I'm not really sure what you mean here. You are not crossing architectures, so there's no cross compiling.
gcc running on a RPi is running on an ARM host, building for an ARM target.

Originally Posted by drmozes I'm not really sure what you mean here. You are not crossing architectures, so there's no cross compiling. gcc running on a RPi is running on an ARM host, building for an ARM target.

I was reading something about cross compiling for arm by using my laptop, which is 64 bit, and I guess I typed the wrong thing. I came to the conclusion that I need to use my spare Pi instead. I edited what I wrote but what I meant to say was: "my spare Raspberry Pi 3 B to compile the kernel." I am installing Slackware-current on my Pi right now. I've compiled a custom kernel before, but its been a long time. I have never bothered doing it on an ARM device due to the lesser performance. Sorry for the confusion.

Originally Posted by mralk3 I was reading something about cross compiling for arm by using my laptop, which is 64 bit, and I guess I typed the wrong thing. I came to the conclusion that I need to use my spare Pi instead. I edited what I wrote but what I meant to say was: "my spare Raspberry Pi 3 B to compile the kernel." I am installing Slackware-current on my Pi right now. I've compiled a custom kernel before, but its been a long time. I have never bothered doing it on an ARM device due to the lesser performance. Sorry for the confusion.

The _Kernel_ alone won't take too long to compile, unless it's a huge monolith (without modules).
It's the modules that take the time, and you don't need those for this stage of the experiment: you just want to get the Kernel booting with some output.

Originally Posted by drmozes The _Kernel_ alone won't take too long to compile, unless it's a huge monolith (without modules). It's the modules that take the time, and you don't need those for this stage of the experiment: you just want to get the Kernel booting with some output.

I built a 4.17.19 kernel using "make vexpress_defconfig" as the kernel configuration. I also created the dtb. I used these (zImage and dtb) from the vexpress config with the existing initrd-armv7.img from stock Slackware ARM and I booted to the installer keyboard selection. A bit of a hack, but it worked. Tomorrow I will experiment with the kernel configurations to see what is missing from the stock Slackware config. Finally some progress!