![]() generic-usb 0003:08BB:2902.0001: timeout initializing reports Qemu system arm speed up driver#usbcore: registered new interface driver hiddev usb 1-1: configuration #1 chosen from 1 choice usb 1-1: Manufacturer: Burr-Brown from TI usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: New USB device found, idVendor=08bb, idProduct=2902 usb 1-1: new full speed USB device using ohci_hcd and address 2 usb usb1: configuration #1 chosen from 1 choice usb usb1: Manufacturer: Linux 2.6.32-5-versatile ohci_hcd usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usbcore: registered new device driver usb usbcore: registered new interface driver hub usbcore: registered new interface driver usbfs Added a normal user and added that user to the audio group. I did an apt-get for alsa-base, alsa-utils, linux-sound-base and mplayer. ![]() I checked QEMU ALSA driver was made with: qemu-system-arm -audio-help.) QEMU emulator version 1.0.50, Copyright (c) 2003-2008 Fabrice Bellard configure -target-list="arm-softmmu" -enable-sdl -audio-drv-list=alsa,oss I soon found you get USB errors unless you use the latest version of QEMU, which I compiled from source with this config. This allows me to ssh into the arm emulation. QEMU_AUDIO_DRV=alsa qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -redir tcp:5022::22 -usb -usbdevice host:08bb:2902 -nographic The final QEMU command I ended up using was: I've only just found this thread, and so have only previously followed this guide using the most recent kernel/initrd files: Qemu system arm speed up install#My host is 64bit aptosid install (based on debian unstable) which is configured to use ALSA. My own idea was to use my external USB DAC for audio playback. I am not ( a coder, or advanced Linux user). Qemu system arm speed up how to#I need an idiot's guide on how to get sound out of a QEMU arm emulation. but so what? How does that help? All we seem to be doing is wasting the CPU power of a high end PC by emulating a low end embedded CPU What actual value do these emulated ARM Debian/LXDE environments offer for working on application software for the Raspberry Pi ? They run (slowly). How are people actually using these ARM-under-qemu Debian/LXDE installations to do anything useful for Raspberry Pi development? You end up with an emulator that lacks all the fancy video and audio capabilities of the Raspberry Pi, and lacks all the GPIO stuff too. If I want ARM 1176 CPU emulation, I'll need to backport a newer qemu package, of course. Using Debian stable (squeeze) netinst works fine for me here, I wrote a scripted install process for doing that. I'd guess that you tried using a netinst image from Debian testing (wheezy)? I had that issue too when I tried that (qemu 0.12.3 under Ubuntu 10.04.3 amd64). You need to provide specifics on exactly what you tried - version of qemu, host OS, guest images. I've tried using qemu, but I keep getting an error in the Debian install, saying it can't detect any drives. ![]() Quote from yoonsikp on November 20, 2011, 21:39 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |