You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(45) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(3) |
Feb
(5) |
Mar
(12) |
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(5) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Arnout E. <us...@bz...> - 2009-09-09 19:01:43
|
Hi, I just wanted to point out that the M-Audio 2x2 Anniversary Edition (http://www.m-audio.com/products/en_us/MIDISPORT2x2AnniversaryEdition.html) works out-of-the-box without the usb-midi-fw. It might be nice to mention that at the project webpage. Arnout |
From: ben b. <bo...@gm...> - 2008-06-14 12:28:51
|
Hi, This is not very related to the project and its goals, but it's the closest thing I found online for my need. I received a Fast Track USB unit, which seems physically ok, but after some testing, I came to believe the firmware was damaged. The device turns on when connected, and its headphone amp section works, but it cannot communicate properly with the PC. It shows up as having vendor id 0xffff and product id 0xfffe. I'm looking for someone who can dump the firmware of this device and send it to me. I have done a little bit of research on ICs that I had found on the PCB, and this device should support DFU. I also located what I believe is the EEPROM where the firmware is stored, so I'm even willing to try and flash it manually if DFU fails. My hope is that flashing the firmware will solve the problem. Thanks Ben |
From: Joakim L. G. <jg...@jg...> - 2008-05-29 18:23:35
|
I needed to use a Madfu Transit card under Solaris, so I ported madfuload to use libusb instead. This code of course also works in Linux. The sources are available at http://jgilje.net/div/madfuloader/ Regards, Joakim |
From: Aida M. <nce...@la...> - 2008-03-18 19:57:23
|
Hello. Dear client we are happy to offer you most best selling watches by famous brands. Today you have marvelous possibility to obtain watches by the lowest price. * Cheap prices * Big variety * Worldwide shipping * Perfect quality http://fetasfullrei.com |
From: Malcolm S. <ma...@vi...> - 2007-06-07 16:00:25
|
vertigo-lap madfuload-1.2 # lsusb Bus 003 Device 003: ID 0763:2006 Midiman Bus 003 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 Bus 002 Device 005: ID 0b97:7762 O2 Micro, Inc. Oz776 SmartCard Reader Bus 002 Device 002: ID 413c:a005 Dell Computer Corp. Bus 002 Device 001: ID 0000:0000 Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth Bus 002 Device 003: ID 0b97:7761 O2 Micro, Inc. vertigo-lap madfuload-1.2 # /usr/local/sbin/madfuload -D /proc/bus/usb/003/003 -f ma006100.bin -3 -v ma006100.bin: 5616 bytes read successfully reading device descriptor ... interface descriptor 0:0 DFU interface is 0 DFU descriptor found transfer size is 64 waiting 32 ms Segmentation fault >From /var/log/messages: Jun 7 08:58:42 vertigo-lap madfuload[12972]: segfault at 0000000005aef9dc rip 00002b0d05a357fc rsp 00007fffa51d2540 error 4 vertigo-lap madfuload-1.2 # uname -a Linux vertigo-lap 2.6.20-gentoo #2 SMP Sun Feb 25 21:20:00 PST 2007 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux Let me know if you need any more info. Malcolm |
From: Nikki n. <Nik...@SO...> - 2007-04-25 13:52:13
|
looking |
From: Satya L. <Le...@SO...> - 2007-04-25 13:30:36
|
can |
From: Leslie B. <For...@gm...> - 2006-10-31 12:01:09
|
continue mainland Up On the News - nasdaq:GSNH - GSNH Names Partners for LOMT #1 Sidetrack Well. tipperary HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: fanatic * Patterson-UTI (Nasdaq), Revenue: 2.23 billion, UP 63.30% interdict * Schlumberger (NYSE), Revenue: 17.90 billion, UP 34.00% paragon * Halliburton's (NYSE), Revenue: 22.90 billion, UP 13.40% porto Oct. 26, 2006 (BUSINESS WIRE) GSNH to Drill LOMT #1... mosque. http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029 Oct. 12, 2006 (BUSINESS WIRE) GSNH Reports Drilling Success... gallonage. http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb= Oct. 11, 2006 (BUSINESS WIRE) GSNH Announces the Anthony 33... teamwork. http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH Oct. 4, 2006 (BUSINESS WIRE) GSNH...285 million in Probable Reserves... icon. http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU doctrine dialup cooley |
From: Sung W. <Cap...@gm...> - 2006-10-30 18:02:26
|
stratum anthropomorphic Up On the News - GSNH closes Up Friday, After-Market News Release - Get GSNH Quote Here. sediment. http://moneycentral.msn.com/detail/stock_quote?Symbol=gsnh After weeks of speculation it's finally here, and the news is even bigger than we thought. arbitrage. We first knew something was up with GSNH when news came out Thursday regarding Drill LOMT #1. But GSNH really popped up on our radar with Friday's After-Market news. GSNH has announced its partners for the LOMT #1 sidetrack well and you are not going to believe who they are. donor. GSNH Names Partners for LOMT #1 Sidetrack Well countrywide. Friday October 27, 4:05 pm ET bridal. HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: rusk * Patterson-UTI (Nasdaq: PTEN), Revenue: 2.23 billion, UP 63.30% tahiti * Schlumberger (NYSE: SLB), Revenue: 17.90 billion, UP 34.00% vermont * Halliburton (NYSE: HAL), Revenue: 22.90 billion, UP 13.40% adaptive Oct. 27, 2006 (BUSINESS WIRE) - GSNH Names Partners for Sidetrack Well... alginate http://biz.yahoo.com/bw/061027/20061027005324.html?.v=1 GSNH has been releasing steady news worldwide, from Yahoo Finance, AOL, & MSN Money to Marketwatch & Bloomberg---even the NYSE & the NASDAQ have gotten in on the action. Exposure for GSNH is expansive. The increased frequency of news led us to believe that something big was coming for GSNH, and as usual, we were dead-on right. avon Oct. 26, 2006 (BUSINESS WIRE) GSNH to Drill LOMT #1... maternity. http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029 Oct. 12, 2006 (BUSINESS WIRE) GSNH Reports Drilling Success... classroom. http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb= Oct. 11, 2006 (BUSINESS WIRE) GSNH Announces the Anthony 33... autocorrelate. http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH Oct. 4, 2006 (BUSINESS WIRE) GSNH...285 million in Probable Reserves... consultant. http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU Friday's After-Market news on GSNH and its newfound partnership with these major corporations (over 43 billion in revenue combined) is just the beginning. We believe that there is even bigger news coming, and as always, we are bringing you the news ahead of time, ahead of everyone else, and ahead of a major spike in GSNH stock price. apron lab wapato |
From: Milton S. <Esc...@gm...> - 2006-10-27 19:44:45
|
decollimate marten Our attorneys have discovered a loop hole in the banking laws. edify. Using this discovery we have been successful at totally eliminating peoples CreditCardDebt with out them paying another dime. brimstone. We GuaranteeThat we can do this for you. wolfish. http://0x00000059.0000000150.0x000000070.0x0015 licensor indent footmen |
From: Clemens L. <cl...@la...> - 2006-10-06 09:01:47
|
Ilya Rusky wrote: > I'm wondering if I'll be able to use USB Midi UNO flashed with new > firmware back in Windows? Yes. The firmware isn't flashed, it's just loaded into the Uno's RAM. It's the same firmware that is loaded by the Windows driver. > On the other side, would USB MIDI Firmware Loader prevent any use > of USB Midi UNO on Windows once and for all? No. The firmware loader does exactly the same that the Windows driver does when Windows boots. HTH Clemens |
From: Ilya R. <pro...@gm...> - 2006-10-06 06:44:57
|
Hello, I'm wondering if I'll be able to use USB Midi UNO flashed with new firmware back in Windows? If so, would I have to reinstall Windows drivers for this device, or simply let Windows detect it's updated firmware? On the other side, would USB MIDI Firmware Loader prevent any use of USB Midi UNO on Windows once and for all? Regards, -- - Ilya |
From: robert l. <rob...@gm...> - 2006-09-06 09:10:27
|
On 9/6/06, Clemens Ladisch <cla...@fa...> wrote: > robert lazarski wrote: > > On 9/4/06, Clemens Ladisch <cla...@fa...> wrote: > > > Are there any files in /proc/bus/usb? > > > > Nope: > > Then the USB file system isn't mounted. > > (Re-)plugging the device should work after you've run "mount /proc/bus/usb", > but the init scripts should have done this automatically. > > > > If not, what are the contents of /etc/fstab? > > > > ... > > usbfs /proc/bus/usb usbfs noauto 0 0 > > Try replacing "noauto" with "auto". > > > HTH > Clemens > That worked!!! Thanks Clemens! Robert |
From: Clemens L. <cla...@fa...> - 2006-09-06 08:28:36
|
robert lazarski wrote: > On 9/4/06, Clemens Ladisch <cla...@fa...> wrote: > > Are there any files in /proc/bus/usb? > > Nope: Then the USB file system isn't mounted. (Re-)plugging the device should work after you've run "mount /proc/bus/usb", but the init scripts should have done this automatically. > > If not, what are the contents of /etc/fstab? > > ... > usbfs /proc/bus/usb usbfs noauto 0 0 Try replacing "noauto" with "auto". HTH Clemens |
From: robert l. <rob...@gm...> - 2006-09-06 00:21:49
|
On 9/4/06, Clemens Ladisch <cla...@fa...> wrote: > robert lazarski wrote: > > Hi all, I'm running opensuse 10.1 , and I ran all the updates. > > [...] > > What should happen upon firmware upload I believe is that the ID should > > change to 0763:1002 and then the led's on the midisport should light > > up. Yet I get nothing, nor any signs of life under /var/log or dmesg on > > reboot. > Thanks for the reply. > Are there any files in /proc/bus/usb? Nope: /home/iksrazal> ls -l /proc/bus/usb total 0 > If not, what are the contents of /etc/fstab? > /dev/hda6 / ext3 acl,user_xattr 1 1 /dev/hda3 /boot ext3 acl,user_xattr 1 2 /dev/hda2 /winblows ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0 /dev/hda5 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0 Here's what udevmonitor says on unplug / plug in case it helps: /root> udevmonitor udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1157501802.560049] remove@/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0 UEVENT[1157501802.560147] remove@/class/usb_device/usbdev1.8 UEVENT[1157501802.560163] remove@/devices/pci0000:00/0000:00:1f.2/usb1/1-1 UDEV [1157501802.586565] remove@/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0 UDEV [1157501802.590669] remove@/devices/pci0000:00/0000:00:1f.2/usb1/1-1 UDEV [1157501802.604066] remove@/class/usb_device/usbdev1.8 UEVENT[1157501807.989900] add@/devices/pci0000:00/0000:00:1f.2/usb1/1-1 UEVENT[1157501807.995580] add@/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0 UEVENT[1157501807.995631] add@/class/usb_device/usbdev1.9 UDEV [1157501808.181338] add@/devices/pci0000:00/0000:00:1f.2/usb1/1-1 UDEV [1157501808.713154] add@/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0 UDEV [1157501808.805141] add@/class/usb_device/usbdev1.9 Thanks! Robert > > Regards, > Clemens > |
From: Clemens L. <cla...@fa...> - 2006-09-04 11:48:54
|
robert lazarski wrote: > Hi all, I'm running opensuse 10.1 , and I ran all the updates. > [...] > What should happen upon firmware upload I believe is that the ID should > change to 0763:1002 and then the led's on the midisport should light > up. Yet I get nothing, nor any signs of life under /var/log or dmesg on > reboot. Are there any files in /proc/bus/usb? If not, what are the contents of /etc/fstab? Regards, Clemens |
From: robert l. <rob...@gm...> - 2006-09-03 10:38:50
|
Hi all, I'm running opensuse 10.1 , and I ran all the updates. After running 'make install' of usb-midi-fw I get the following line in /etc/udev/rules.d : 42-midisport-firmware.rules Editing /etc/udev/rules.d/42-midisport-firmware.rules shows me: # MidiSport 2x2 ACTION=="add", SUBSYSTEM=="usb", DEVPATH=="/*.0", ENV{PRODUCT}=="763/1001/*", RUN+="/sbin/fxload -s /usr/local/share/usb/maudio/MidiSportLoader.ihx -I /usr/local/share/usb/maudio/MidiSport2x2.ihx" The .ihx file does exist, /sbin/fxload -v shows ' May 1 2006 (development) ' and I can see the usb device via lsusb: Bus 001 Device 003: ID 0763:1001 Midiman Midisport 2x2 What should happen upon firmware upload I believe is that the ID should change to 0763:1002 and then the led's on the midisport should light up. Yet I get nothing, nor any signs of life under /var/log or dmesg on reboot. Not sure where else to look for debug info. Coincidently, my machine has a dual boot config , and after having no luck with opensuse 10.1 I tried with windows and all went well - just confirming the device does work. Any ideas ? Robert |
From: Pedro Lopez-C. <ped...@gm...> - 2006-03-04 11:40:32
|
This is a test. Sorry. I suspect that SF is losing messages. |
From: Pedro Lopez-C. <ped...@gm...> - 2006-03-01 23:09:33
|
On Wednesday 01 March 2006 18:45, Clemens Ladisch wrote: > Clemens Ladisch wrote: > > Pedro Lopez-Cabanillas wrote: > > > I guess that midisport-firmware-1.0 needs a newer udev than mine, and > > > obviously yours. > > > > I'm not sure what the problem is. Probably the GOTOs. > > I'll try to rewrite the rules to be more backwards compatible. > > OK, version 1.1 is out, using very simple rules that should work with > every udev version. It is a lot better now. Thanks. But I think that "every udev version" is an exaggeration. The "RUN" key was introduced in udev-057, as stated in changelogs and announcements: http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/1368.html It was released in May/2005, less than one year ago. Many users' distros are older than that. For instance, I'm using Mandriva 10.2, which comes with udev-054. Almost right, but not enough. By the way, I've found that we can get the udev version with this command: [~]$ udevinfo -V udevinfo, version 054 So, I've made a patch to give some more clues to the user at configure time. Please apply the attached patch and release again, if you agree. Regards, Pedro |
From: Clemens L. <cl...@la...> - 2006-03-01 17:45:09
|
Clemens Ladisch wrote: > Pedro Lopez-Cabanillas wrote: > > I guess that midisport-firmware-1.0 needs a newer udev than mine, and > > obviously yours. > > I'm not sure what the problem is. Probably the GOTOs. > I'll try to rewrite the rules to be more backwards compatible. OK, version 1.1 is out, using very simple rules that should work with every udev version. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2006-02-21 14:25:22
|
Pedro Lopez-Cabanillas wrote: > I'm using Mandrake 10.2 with udev-054 and it doesn't load the firmware, either > but it doesn't hang the system. It symply doesn't work. > > I guess that midisport-firmware-1.0 needs a newer udev than mine, and > obviously yours. I'm not sure what the problem is. Probably the GOTOs. I'll try to rewrite the rules to be more backwards compatible. > $ cat LICENSE > The firmware files (*.ihx) are copyrighted by Midiman, and can be used > and redistributed only as part of this package. > > So, it is not possible to make a rpm/deb/tgz package, and distribute it with > some commercial Linux distribution? When the rpm/dev/tgz is distributed with some distribution, the firmware files would still be inside the package, i.e., they would be "part of this package". Regards, Clemens |
From: Pedro Lopez-C. <ped...@gm...> - 2006-02-20 22:25:20
|
Serge: I'm glad that you have managed to fix the system, and have your UNO working now. Congratulations! On Monday 20 February 2006 19:38, serge bouc wrote: > > I want to know if there is really some UNO that doesn't > > require a firmware at all. > > I uninstalled ezusbmidi. And everything is still working ! Then, this UNO doesn't require a firmware loader. Nice. > > And please, I would like to know the results of > > > > # lsusb -v > > > > With, and without ezusbmidi installed, if it is different. > The output is the same with and without ezusbmidi. Here it is : Not only it doesn't require external firmware, but it is a class compliant USB MIDI device. Amazing, coming from M-Audio. Clemens, please update your database: 0x0763:0x0150 M-Audio (Midiman) UNO (new version) Works > Bus 002 Device 002: ID 0763:0150 Midiman > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0763 Midiman > idProduct 0x0150 > bcdDevice 1.25 > iManufacturer 1 > iProduct 2 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 101 > bNumInterfaces 2 > bConfigurationValue 1 > iConfiguration 3 > bmAttributes 0xc0 > Self Powered > MaxPower 0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 1 Audio > bInterfaceSubClass 1 Control Device > bInterfaceProtocol 0 > iInterface 0 > AudioControl Interface Descriptor: > bLength 9 > bDescriptorType 36 > bDescriptorSubtype 1 (HEADER) > bcdADC 1.00 > wTotalLength 9 > bInCollection 1 > baInterfaceNr( 0) 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 1 Audio > bInterfaceSubClass 3 MIDI Streaming > bInterfaceProtocol 0 > iInterface 0 > MIDIStreaming Interface Descriptor: > bLength 7 > bDescriptorType 36 > bDescriptorSubtype 1 (HEADER) > bcdADC 1.00 > wTotalLength 65 > MIDIStreaming Interface Descriptor: > bLength 6 > bDescriptorType 36 > bDescriptorSubtype 2 (MIDI_IN_JACK) > bJackType 1 Embedded > bJackID 1 > iJack 0 > MIDIStreaming Interface Descriptor: > bLength 6 > bDescriptorType 36 > bDescriptorSubtype 2 (MIDI_IN_JACK) > bJackType 2 External > bJackID 2 > iJack 0 > MIDIStreaming Interface Descriptor: > bLength 9 > bDescriptorType 36 > bDescriptorSubtype 3 (MIDI_OUT_JACK) > bJackType 1 Embedded > bJackID 3 > bNrInputPins 1 > baSourceID( 0) 2 > BaSourcePin( 0) 1 > iJack 0 > MIDIStreaming Interface Descriptor: > bLength 9 > bDescriptorType 36 > bDescriptorSubtype 3 (MIDI_OUT_JACK) > bJackType 2 External > bJackID 4 > bNrInputPins 1 > baSourceID( 0) 1 > BaSourcePin( 0) 1 > iJack 0 > Endpoint Descriptor: > bLength 9 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type none > wMaxPacketSize 64 > bInterval 0 > bRefresh 0 > bSynchAddress 0 > MIDIStreaming Endpoint Descriptor: > bLength 5 > bDescriptorType 37 > bDescriptorSubtype 1 (GENERAL) > bNumEmbMIDIJack 1 > baAssocJackID( 0) 3 > Endpoint Descriptor: > bLength 9 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type none > wMaxPacketSize 64 > bInterval 0 > bRefresh 0 > bSynchAddress 0 > MIDIStreaming Endpoint Descriptor: > bLength 5 > bDescriptorType 37 > bDescriptorSubtype 1 (GENERAL) > bNumEmbMIDIJack 1 > baAssocJackID( 0) 1 > Language IDs: (length=4) > 0409 English(US) > ____________________________________________________________________ > > >> Still, there is a remaining problem with this "midisport-firmware-1.0", > >> that > >> does not work, and freezes my machine at boot. But I am not sure I will > >> make another try with it... > > > > No idea. Which Windows DLL's are you using? which versions? can be > > downloaded from M-Audio? > > The buggy version (1.0) has its own drivers and firmwares included, > so there is nothing to do, except uncompressing the archive and then > "make install". The program changes the udev rules, adding a new > file "42-midisport-firmware.rules" in "rules.d". This file is probably > the cause of the problem, since "uninstall" essentially removes it, > plus the hex drivers files in some other folder. Here it is : > ********************************************************************* > # midisport-firmware.rules - udev rules for loading firmware into > MidiSport devices > > ACTION!="add", GOTO="midisport_firmware_end" > SUBSYSTEM!="usb", GOTO="midisport_firmware_end" > > # interface 0 only (some udev versions don't work with > SYSFS{bInterfaceNumber}) > DEVPATH!="/*.0", GOTO="midisport_firmware_end" > > # MidiSport 2x2 > ENV{PRODUCT}=="763/1001/*", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSport2x2.ihx" > # MidiSport 1x1 > ENV{PRODUCT}=="763/1010/*", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSport1x1.ihx" > # KeyStation > ENV{PRODUCT}=="763/1014/*", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSportKS.ihx" > # MidiSport 4x4 > ENV{PRODUCT}=="763/1020/*", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSport4x4.ihx" > # MidiSport 8x8 > ENV{PRODUCT}=="763/1031/110", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSport8x8-2.10.ihx" > ENV{PRODUCT}=="763/1031/121", RUN+="/usr/sbin/fxload -s > /usr/local/share/usb/maudio/MidiSportLoader.ihx -I > /usr/local/share/usb/maudio/MidiSport8x8-2.21.ihx" > > LABEL="midisport_firmware_end" > > # vim: ft=conf > *************************************************************************** I'm using Mandrake 10.2 with udev-054 and it doesn't load the firmware, either but it doesn't hang the system. It symply doesn't work. I guess that midisport-firmware-1.0 needs a newer udev than mine, and obviously yours. It should check for a sensible udev version before installing it, though. Final question: $ cat LICENSE The firmware files (*.ihx) are copyrighted by Midiman, and can be used and redistributed only as part of this package. [...] So, it is not possible to make a rpm/deb/tgz package, and distribute it with some commercial Linux distribution? Regards, Pedro |
From: Martin L. <mar...@gm...> - 2005-04-11 18:32:05
|
On Mon, Apr 11, 2005 at 02:53:18PM +0200, Clemens Ladisch wrote: > Martin Langer wrote: > > IMO the MIDI Hubble from Terratec [1] is also an EzUSB device. At least > > the content of the firmware file is full of typical ezusb details. > > It looks like i8051 code, but other USB interface chips have such a > CPU, too. Yes. But if you are disassembling it (I've choosen d52) you can see all these characteristic registers. Compare it with the ezusb manual, it's really obvious! Those registers aren't available in the original 8051. [..] X7f00 equ 7f00h X7f92 equ 7f92h X7f95 equ 7f95h X7f98 equ 7f98h X7f9c equ 7f9ch X7f9e equ 7f9eh X7fa1 equ 7fa1h X7fa5 equ 7fa5h X7fa6 equ 7fa6h X7fa9 equ 7fa9h X7faa equ 7faah X7fab equ 7fabh X7fac equ 7fach X7fad equ 7fadh X7fae equ 7faeh X7faf equ 7fafh X7fb4 equ 7fb4h X7fb5 equ 7fb5h X7fb7 equ 7fb7h X7fb9 equ 7fb9h X7fc5 equ 7fc5h X7fc7 equ 7fc7h X7fc9 equ 7fc9h X7fd4 equ 7fd4h X7fd7 equ 7fd7h X7fde equ 7fdeh X7fdf equ 7fdfh X7fe8 equ 7fe8h [..] > _Any_ file can be treated as a raw binary file, and converted into a > hexdump. I agree, but the disassembled code makes sense here! It differs from us122 code (AN2131QC), but there are many members in the ezusb family and it could be a next generation ezusb chip. But also you can see some typical ezusb code snippets from the manual: push acc push dph push dpl anl 91h,#0efh mov dptr,#X7fab mov a,#2 movx @dptr,a pop dpl pop dph pop acc reti But I can't guarantee anything here, that's true. > The driver doesn't look as if it actually would upload anything. I > guess Terratec aren't cheapskates like M-Audio and have put a proper > EEPROM into the thing. Somewhere I read about an ezusb command which burns the fw into the ezusb chip. After that the chip will not forget it after an unplug. Then you don't need a hotplug upload. But your EEPROM idea could be also possible. martin |
From: Clemens L. <cl...@la...> - 2005-04-11 12:53:29
|
Martin Langer wrote: > IMO the MIDI Hubble from Terratec [1] is also an EzUSB device. At least > the content of the firmware file is full of typical ezusb details. It looks like i8051 code, but other USB interface chips have such a CPU, too. > The firmware file [2] is in "bin" format but bin2intelhex [3] is able to > convert it into IntelHex format. _Any_ file can be treated as a raw binary file, and converted into a hexdump. > So, the upload should be possible with fxload, like always... The driver doesn't look as if it actually would upload anything. I guess Terratec aren't cheapskates like M-Audio and have put a proper EEPROM into the thing. Regards, Clemens |
From: Martin L. <mar...@gm...> - 2005-04-10 17:11:49
|
Hi, IMO the MIDI Hubble from Terratec [1] is also an EzUSB device. At least the content of the firmware file is full of typical ezusb details. Unfortunately I don't have a Hubble and can't confirm it. But meanwhile I've figured out a few things to be prepared: The firmware file [2] is in "bin" format but bin2intelhex [3] is able to convert it into IntelHex format. So, the upload should be possible with fxload, like always... bye, martin [1] http://audiode.terratec.net/modules.php?op=modload&name=News&file=article&sid=3 [2] http://supportde.terratec.net/modules.php?op=modload&name=Downloads&file=index&req=getit&lid=678 [3] http://www.rom-o-matic.net/5.0.4/contrib/bin2intelhex/ |