Greetings,
I maintain a couple of packages that currently don't build on ARM (both Lisp implementations, hmmmmm). I've got candidate fixes for both, but need to test them. I don't have ready access to any ARM hardware, so I thought I would try the qemu images at http://scotland.proximity.on.ca/arm-nightlies/. I downloaded f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img.xz and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-latest-armhfp-vex... (judging by the sha256sums, these are actually http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a... and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a...).
I unpacked both downloads, then did this: $ cd armhfp-vexpress-xfce-mmcblk0/boot $ ./boot-vexpress+x vmlinuz-3.6.0-0.rc3.git2.1.fc18.armv7hl initramfs-3.6.0-0.rc3.git2.1.fc18.armv7hl.img ../../f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img
The VM started up and got this far: [ 6.451319] rtc-pl031 mb:rtc: setting system clock to 2012-09-26 15:54:06 UTC (1348674846) [ 6.478256] md: Waiting for all devices to be available before autodetect [ 6.486172] md: If you don't use raid, use raid=noautodetect [ 6.530509] md: Autodetecting RAID arrays. [ 6.538233] md: Scanned 0 and added 0 devices. [ 6.545597] md: autorun ... [ 6.552480] md: ... autorun DONE. [ 6.567180] Waiting for root device /dev/mmcblk0p2...
... and there it sits. Did I start the VM incorrectly? If not, is this a known issue and is there a set of images I should download to make forward progress? FYI, the host machine is running x86_64 F17.
Thanks for answering my newbie questions. Regards,
On Wed, Sep 26, 2012 at 5:00 PM, Jerry James loganjerry@gmail.com wrote:
Greetings,
I maintain a couple of packages that currently don't build on ARM (both Lisp implementations, hmmmmm). I've got candidate fixes for both, but need to test them. I don't have ready access to any ARM hardware, so I thought I would try the qemu images at http://scotland.proximity.on.ca/arm-nightlies/. I downloaded f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img.xz and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-latest-armhfp-vex... (judging by the sha256sums, these are actually http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a... and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a...).
I unpacked both downloads, then did this: $ cd armhfp-vexpress-xfce-mmcblk0/boot $ ./boot-vexpress+x vmlinuz-3.6.0-0.rc3.git2.1.fc18.armv7hl initramfs-3.6.0-0.rc3.git2.1.fc18.armv7hl.img ../../f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img
The VM started up and got this far: [ 6.451319] rtc-pl031 mb:rtc: setting system clock to 2012-09-26 15:54:06 UTC (1348674846) [ 6.478256] md: Waiting for all devices to be available before autodetect [ 6.486172] md: If you don't use raid, use raid=noautodetect [ 6.530509] md: Autodetecting RAID arrays. [ 6.538233] md: Scanned 0 and added 0 devices. [ 6.545597] md: autorun ... [ 6.552480] md: ... autorun DONE. [ 6.567180] Waiting for root device /dev/mmcblk0p2...
... and there it sits. Did I start the VM incorrectly? If not, is this a known issue and is there a set of images I should download to make forward progress? FYI, the host machine is running x86_64 F17.
I would probably go with testing on the F-17 image at the moment, I think the F-18 one has issues.
Peter
... and there it sits. Did I start the VM incorrectly? If not, is this a known issue and is there a set of images I should download to make forward progress? FYI, the host machine is running x86_64 F17.
Hi Jerry, thanks for pointing this out. This is an issue with qemu, currently the hard coded loaded addresses for the initramfs and kernel overlap due to the increasing size of our kernel. I am just testing a patch to submit now. In the interim you may want to use the F17 GA image, there is no overlap.
https://fedoraproject.org/wiki/Architectures/ARM/Versatile_Express
Paul
Thanks for answering my newbie questions. Regards,
Jerry James http://www.jamezone.org/ _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
You may want to apply for one of Calxeda's TryStack instances, which would give you access to actual Cortex A9 armhfp hardware. http://www.calxeda.com/trystack/
--Mark Langsdorf Calxeda, Inc.
________________________________________ From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Jerry James [loganjerry@gmail.com] Sent: Wednesday, September 26, 2012 11:00 AM To: Fedora ARM Subject: [fedora-arm] ARM VM on an x86_64 host
Greetings,
I maintain a couple of packages that currently don't build on ARM (both Lisp implementations, hmmmmm). I've got candidate fixes for both, but need to test them. I don't have ready access to any ARM hardware, so I thought I would try the qemu images at http://scotland.proximity.on.ca/arm-nightlies/. I downloaded f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img.xz and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-latest-armhfp-vex... (judging by the sha256sums, these are actually http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a... and http://scotland.proximity.on.ca/arm-nightlies/vault/f18arm-20120918-002131-a...).
I unpacked both downloads, then did this: $ cd armhfp-vexpress-xfce-mmcblk0/boot $ ./boot-vexpress+x vmlinuz-3.6.0-0.rc3.git2.1.fc18.armv7hl initramfs-3.6.0-0.rc3.git2.1.fc18.armv7hl.img ../../f18arm-latest-armhfp-vexpress-xfce-mmcblk0.img
The VM started up and got this far: [ 6.451319] rtc-pl031 mb:rtc: setting system clock to 2012-09-26 15:54:06 UTC (1348674846) [ 6.478256] md: Waiting for all devices to be available before autodetect [ 6.486172] md: If you don't use raid, use raid=noautodetect [ 6.530509] md: Autodetecting RAID arrays. [ 6.538233] md: Scanned 0 and added 0 devices. [ 6.545597] md: autorun ... [ 6.552480] md: ... autorun DONE. [ 6.567180] Waiting for root device /dev/mmcblk0p2...
... and there it sits. Did I start the VM incorrectly? If not, is this a known issue and is there a set of images I should download to make forward progress? FYI, the host machine is running x86_64 F17.
Thanks for answering my newbie questions. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Wed, Sep 26, 2012 at 2:57 PM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
You may want to apply for one of Calxeda's TryStack instances, which would give you access to actual Cortex A9 armhfp hardware. http://www.calxeda.com/trystack/
Thanks for the responses, Peter, Paul, and Mark. Wow, just one letter away from 1960s nirvana....
I'll give the F17 image a try. If I seem to be doing a lot of ARM work, I'll apply for one of the TryStack instances. Thanks for the offer, Mark. Regards,
On Wed, Sep 26, 2012 at 3:57 PM, Jerry James loganjerry@gmail.com wrote:
I'll give the F17 image a try. If I seem to be doing a lot of ARM work, I'll apply for one of the TryStack instances. Thanks for the offer, Mark. Regards,
Wait, I remember now. I tried the F17 image a month or so ago, and got nowhere with it. That's why I tried the F18 image. When I boot the F17 image (hardfp, XFCE) from https://fedoraproject.org/wiki/Architectures/ARM/Versatile_Express, I see a bunch of systemd output, eventually culminating in this:
network[383]: Determining IP information for eth0... done. network[383]: [ OK ] [ 359.961519] RPC: Registered named UNIX socket transport module. [ 359.970705] RPC: Registered udp transport module. [ 359.976688] RPC: Registered tcp transport module. [ 359.982415] RPC: Registered tcp NFSv4.1 backchannel transport module.
... and that's it. The virtual terminals have been created, as I can switch between 6 of them, but 5 of them are empty black screens. The original VT shows only syslog output. I've let it sit for half an hour now, with no shell prompt and no X Windows showing up. Hitting enter does nothing on any of the 6 VTs. Perhaps I should try a later snapshot?
On Wed, Sep 26, 2012 at 11:49 PM, Jerry James loganjerry@gmail.com wrote:
On Wed, Sep 26, 2012 at 3:57 PM, Jerry James loganjerry@gmail.com wrote:
I'll give the F17 image a try. If I seem to be doing a lot of ARM work, I'll apply for one of the TryStack instances. Thanks for the offer, Mark. Regards,
Wait, I remember now. I tried the F17 image a month or so ago, and got nowhere with it. That's why I tried the F18 image. When I boot the F17 image (hardfp, XFCE) from https://fedoraproject.org/wiki/Architectures/ARM/Versatile_Express, I see a bunch of systemd output, eventually culminating in this:
network[383]: Determining IP information for eth0... done. network[383]: [ OK ] [ 359.961519] RPC: Registered named UNIX socket transport module. [ 359.970705] RPC: Registered udp transport module. [ 359.976688] RPC: Registered tcp transport module. [ 359.982415] RPC: Registered tcp NFSv4.1 backchannel transport module.
... and that's it. The virtual terminals have been created, as I can switch between 6 of them, but 5 of them are empty black screens. The original VT shows only syslog output. I've let it sit for half an hour now, with no shell prompt and no X Windows showing up. Hitting enter does nothing on any of the 6 VTs. Perhaps I should try a later snapshot?
What happens if you connect on a serial console? I've only ever got around to using the qemu image once or twice and it was all via a virtual serial console. That might at least give you more details of where it's getting to.
Peter
-
Jerry James -
Mark Langsdorf -
Paul Whalen -
Peter Robinson