OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - Arch Linux ARM support => Topic started by: TheWalt on December 07, 2015, 10:42:37 am
-
Ok so I thought this would be easy but I am (probably) one step in over my head so maybe someone can help.
QEMU has native support for the Zaurus line of product under ARM emulation. After a little google search it seemed running a debian install worked good so why not get ALARMZ going.
So the steps I have done so far is as follows.
I had to create a raw disk image to run from, so did this to make a 6gig image.
dd if=/dev/null of=alarm.img bs=1M seek=6114
Then I had to format the image.
mkfs.ext4 -F alarm.img
Then I mounted it and untar the file system just like you would on real hardware.
mkdir /mnt/alarm
mount -t ext4 -o loop alarm.img /mnt/alarm
bsdtar xvf alarm-zaurus-c3x00-minimal-rootfs-october2015.tar.xz -C /mnt/alarm/
Now I thought that would be it, start up the VM and watch the magic happen. Unfortunately no such luck.
qemu-system-arm -machine spitz alarm.img
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00800000
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00800000
PSR=400001d3 -Z-- A svc32
FPSCR: 00000000
Aborted
So I'm not sure where to go from here. Looking at other start-up strings it does seem like I might be missing -kernel and -initrd files but have no idea where to get them.
If anyone can point me in a direction I'll try to do the leg work
-
Ok, got the machine to boot at least using the zImage found in the file system. It now kernel panics though which is for sure over my head.
qemu-system-arm -M terrier alarm.img -m 64 -kernel zImage-4.2.3-c3x00 -append root=/dev/sda
-
Ok, got the machine to boot at least using the zImage found in the file system. It now kernel panics though which is for sure over my head.
qemu-system-arm -M terrier alarm.img -m 64 -kernel zImage-4.2.3-c3x00 -append root=/dev/sda
Hi TheWalt,
sorry I have been away for some time.
Try to append "root=/dev/sda1" and use "-M borzoi"
Cheers!
-
I get the same error, and then kernel panic.
Inconsistency detected by ld.so: dynamic-link.h: 190: elf_get_dynamic_info: Assertion `info[20]->d_un.d_val == 17 || info[20]->d_un.d_val == 7' failed!
UPDATE:
I forgot to edit the alarm.img fstab and boot.cfg. Now that I have modified that I get the following error.
/sbin/init: error while loading shared libraries: librt.so.1: cannot open shared object file
Will continue to hack away
-
Ok, so I made a new image file with a partition this time to match the default config. I am starting the VM with the following which makes it use the image as a SD card, and uses the same string as in boot.cfg minus the error reporting so I can see what is happening.
qemu-system-arm -M borzoi -sd alarm2.img -m 64 -kernel zImage-4.2.3-c3x00 -append 'root=/dev/mmcblk0p1 rootfstype=ext4 fbcon=rotate:1 noinitrd cpufreq-pxa2xx.pxa27x_maxfreq=624' -portrait
Unfortunately it still stops after mount. Any ideas would be appreciated.
[img]http://www.jevack.com/hosted/qemu_alarm1.png\" border=\"0\" class=\"linked-image\" /]
-
Ok, so I made a new image file with a partition this time to match the default config. I am starting the VM with the following which makes it use the image as a SD card, and uses the same string as in boot.cfg minus the error reporting so I can see what is happening.
qemu-system-arm -M borzoi -sd alarm2.img -m 64 -kernel zImage-4.2.3-c3x00 -append 'root=/dev/mmcblk0p1 rootfstype=ext4 fbcon=rotate:1 noinitrd cpufreq-pxa2xx.pxa27x_maxfreq=624' -portrait
Unfortunately it still stops after mount. Any ideas would be appreciated.
[img]http://www.jevack.com/hosted/qemu_alarm1.png\" border=\"0\" class=\"linked-image\" /]
Hi, what version of qemu are you using ?
I tested here with QEMU emulator version 2.4.0.1,
My alarm.img has ext4 and is actually recognized as "mmcblk0" but boots fine using same command you posted.
I suggest you try again and re-download all the files to make sure nothing is corrupt.
Cheers!
-
HA!
I was running from 2.0.0 and when I updated to 2.4.1 it worked!
Now to get networking and should be good to go. Thanks for the heads up on the QEMU version, considering how old the Z is I'd never thougth that would be the issue.
-
HA!
I was running from 2.0.0 and when I updated to 2.4.1 it worked!
Now to get networking and should be good to go. Thanks for the heads up on the QEMU version, considering how old the Z is I'd never thougth that would be the issue.
Great, good to know you got it going. For networking, qemu does a pass through mode by default, so setting your Z to dhcp and maybe editing resolv.conf should be enough.
If you want to be able to SSH to the Z you may need to look into "-net user,hostfwd=tcp::2222-:22" then you should be able to SSH to localhost:2222 and get into the Z.
-
Excellent progress, Walt!
-
Hello!
I'm trying to get qemu to work. No luck so far. I'm on windows 7 and did all the steps mentioned in this thread.
I've made a 1G image, formatted to ext4, extracted the minimal rootfs and copied the kernel to the root dir if it helps.
I always get the following error:
zImage-4.2.3-c3x00: No such file or directory
qemu: could not load kernel 'zImage-4.2.3-c3x00'
qemu version is 2.4.93
command line is
qemu-system-arm -M spitz -sd alarm3.img -m 64 -kernel /zImage-4.2.3-c3x00 -append "root=/dev/mmcblk0p1 rootfstype=ext4 fbcon=rotate:1 noinitrd cpufreq-pxa2xx.pxa27x_maxfreq=624" -portrait
Thank you in advance for any help.
-
I always get the following error:
zImage-4.2.3-c3x00: No such file or directory
qemu: could not load kernel 'zImage-4.2.3-c3x00'
command line is
qemu-system-arm -M spitz -sd alarm3.img -m 64 -kernel /zImage-4.2.3-c3x00 -append "root=/dev/mmcblk0p1 rootfstype=ext4 fbcon=rotate:1 noinitrd cpufreq-pxa2xx.pxa27x_maxfreq=624" -portrait
Sounds like it just can't find the file, assuming you extracted it to a folder try using the full path to the zimage IE c:\zaurusfiles\zImage-4.2.3-c3x00 or wherever it exist on your system.
-
I always get the following error:
zImage-4.2.3-c3x00: No such file or directory
qemu: could not load kernel 'zImage-4.2.3-c3x00'
command line is
qemu-system-arm -M spitz -sd alarm3.img -m 64 -kernel /zImage-4.2.3-c3x00 -append "root=/dev/mmcblk0p1 rootfstype=ext4 fbcon=rotate:1 noinitrd cpufreq-pxa2xx.pxa27x_maxfreq=624" -portrait
Sounds like it just can't find the file, assuming you extracted it to a folder try using the full path to the zimage IE c:\zaurusfiles\zImage-4.2.3-c3x00 or wherever it exist on your system.
It Works! Thank You so much!!!
I did not think the kernel is not loaded from the image file.
-
HA!
I was running from 2.0.0 and when I updated to 2.4.1 it worked!
Now to get networking and should be good to go. Thanks for the heads up on the QEMU version, considering how old the Z is I'd never thougth that would be the issue.
Hi TheWalt.
did you have any success with the network?
I realized the qemu-system-arm does not allow the use of the virtual pcnet driver (pcnet is included as kernel module in ALARMZ)
If you found a way to get it working let me know, I guess I there might be a limitation and additional kernel modules may be required.
Cheers!
-
Hi,
just as a note. ArchLinuxArm does not support qemu at all. I searched the alarm forums about qemu and the response is "not supported".
Saying that , there might be still a way to get networking going and I will put some effort in, but it is not my priority.
I only use qemu to test new build kernels boot process, not to test apps or network.
For testing apps etc, I recommend to use a SD card with alarm on it, so you test on SD first before going "production" on the CF card.
This way you can keep your main alarm on the CF "clean". I hope this makes sense, as there is no speed benefit from running qemu
and compiling applications under qemu is not recommended.
Cheers!
-
Hi,
just as a note. ArchLinuxArm does not support qemu at all. I searched the alarm forums about qemu and the response is "not supported".
Saying that , there might be still a way to get networking going and I will put some effort in, but it is not my priority.
I only use qemu to test new build kernels boot process, not to test apps or network.
For testing apps etc, I recommend to use a SD card with alarm on it, so you test on SD first before going "production" on the CF card.
This way you can keep your main alarm on the CF "clean". I hope this makes sense, as there is no speed benefit from running qemu
and compiling applications under qemu is not recommended.
Cheers!
I unfortunately came to the same realization with networking, only loopback and IR (irda0) seems supported / detected. I really only wanted to get this working so anyone who did not own physical hardware could still compile for the Z.
But I got to thinking, really all someone would need is a system that compiled against the armv5 right? I wonder what other low end system would be compatible that could be purchased.
-
Hi,
just as a note. ArchLinuxArm does not support qemu at all. I searched the alarm forums about qemu and the response is "not supported".
Saying that , there might be still a way to get networking going and I will put some effort in, but it is not my priority.
I only use qemu to test new build kernels boot process, not to test apps or network.
For testing apps etc, I recommend to use a SD card with alarm on it, so you test on SD first before going "production" on the CF card.
This way you can keep your main alarm on the CF "clean". I hope this makes sense, as there is no speed benefit from running qemu
and compiling applications under qemu is not recommended.
Cheers!
I unfortunately came to the same realization with networking, only loopback and IR (irda0) seems supported / detected. I really only wanted to get this working so anyone who did not own physical hardware could still compile for the Z.
But I got to thinking, really all someone would need is a system that compiled against the armv5 right? I wonder what other low end system would be compatible that could be purchased.
I guess any hardware that supports ALARM would be suitable. Preferably a faster ARM CPU , like armv6/7. You would be able to chroot into the ALARMZ rootfs and compile applications, as to my understanding all new ARM CPUs are backward compatible. However I do not own any other than Xscale armv5. Danboid did some compiling on a ARM board I think.