LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 02-28-2018, 06:27 AM   #1
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
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.

Last edited by drmozes; 02-28-2018 at 08:32 AM.
 
Old 03-05-2018, 02:33 PM   #2
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,080

Rep: Reputation: 156Reputation: 156
Quote:
Originally Posted by drmozes View Post
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?
 
Old 03-06-2018, 03:34 AM   #3
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Original Poster
Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
Quote:
Originally Posted by stormtracknole View Post
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.
 
Old 03-07-2018, 10:28 AM   #4
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,080

Rep: Reputation: 156Reputation: 156
FYI, the qemu directory seems to be missing in the boardsupport section.
 
Old 03-07-2018, 12:18 PM   #5
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Original Poster
Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
Quote:
Originally Posted by stormtracknole View Post
FYI, the qemu directory seems to be missing in the boardsupport section.
Thanks - that was an easy one to fix :-)
 
Old 03-07-2018, 02:45 PM   #6
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,080

Rep: Reputation: 156Reputation: 156
Quote:
Originally Posted by drmozes View Post
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.
 
Old 03-08-2018, 09:31 AM   #7
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,080

Rep: Reputation: 156Reputation: 156
Install is still going!!! That or it froze. I'll report back later.
 
Old 03-08-2018, 11:30 AM   #8
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,080

Rep: Reputation: 156Reputation: 156
Pretty sure the installer hung up. Last package it tried to install was:
Code:
libtool-2.4.6-arm-5: a generic library support script .................. [2.4M]
 
Old 10-28-2018, 01:18 AM   #9
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by stormtracknole View Post
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.
 
Old 10-28-2018, 12:05 PM   #10
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Original Poster
Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
Quote:
Originally Posted by mralk3 View Post
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.
 
Old 10-28-2018, 12:40 PM   #11
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by drmozes View Post
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.
 
Old 10-28-2018, 12:57 PM   #12
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Original Poster
Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
Quote:
Originally Posted by mralk3 View Post
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.

Last edited by drmozes; 10-28-2018 at 12:58 PM.
 
Old 10-28-2018, 01:30 PM   #13
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by drmozes View Post
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.
 
Old 10-28-2018, 02:55 PM   #14
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 739

Original Poster
Rep: Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562Reputation: 562
Quote:
Originally Posted by mralk3 View Post
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.
 
Old 10-28-2018, 07:20 PM   #15
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by drmozes View Post
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!
Attached Thumbnails
Click image for larger version

Name:	slackarm-current_qemu_vexpress_first_boot_2018-10-28_17-19-25.png
Views:	7
Size:	124.9 KB
ID:	28868  
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Help needed to boot arm image using qemu j_me Linux - Virtualization and Cloud 1 09-06-2015 01:34 AM
QEMU and Coreboot support bhussein Linux - Software 2 11-26-2013 08:38 PM
Does qemu/kvm support ovf? screwzm Linux - Virtualization and Cloud 3 04-10-2013 04:44 PM
Owner match support in kernel geovg Linux - Newbie 4 12-07-2010 02:05 PM
LXer: OpenLogic Launches Consolidated Enterprise Support Offering that Pays Qualified Community Experts to Support Open Source Software LXer Syndicated Linux News 0 05-08-2006 08:54 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 10:24 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration