Sp Flash Tool Ext Ram Exception
Keyona Vilven
When I run the USB series Flash Tool and hit "update" it says: Failed with error 90000004/3 (if I run it several times this number changes while it still failes). I have reinstalled the USB drivers and the Flash Tool several times (removed all installation files before as instructed in the forum) but the result is the same. I also tried different USB cables, turned the device + mac on and off etc.
Firewire should still work on a Mac Studio with Monterey and all the adapters. But it will be quite a hassle to setup and configure AND there's no future for this - macOS Ventura (in autumn) definitely will kill any FW support.
Did you consider using the new beta driver 4.04 (top entry in this sub-forum)? It avoids Apple's age-old driver system and uses the new DriverKit that will be the future and exclusive from Ventura onwards. That being said, I don't know if the beta driver is for the 802 at all. I bought a Babyface Pro FS recently, and for that one it works without any issues so far.
Somewhere in the threads around the new beta driver, MC mentioned that you HAVE to update your firmware BEFORE using the new driver. The flash tool doesn't seem to work with the newest Macs however. That's why I connected my Babyface to my old iMac first, updated the firmware and THEN installed it with the beta driver on the Mac studio. MAYBE that's your issue. However, if you don't consider the beta driver, you also won't need the firmware update, AFAIK. In the not too distant future, it might be necessary though because the old Kext driver won't be developed forever.
What happens when you boot up the mac, then switch on/connect the 802? AFAIR there were reports it doesn't work when booting connected. If it is detected (is the USB LED on the unit lit, is it shown in System Report?) you then need to give permission (the Security&Privacy Allow button game - you did not mention that at all. It would result in exactly what you describe).
- @Matthias: The USB LED is lit as soon as I plug in the cable so that's all good. Sorry for not mentioning that in the first place.
I tried rebooting (or completely turning off/on) the Mac before switching on the Fireface but that doesn't change the situation.
- @Christian: You were right: On my Mac Studio with Monterey 12.4. I was unable to update the firmware. But I succeeded with my old systems so the firmware is now up to date. (Completely Murphy's law here: The installer doesn't run on my previous machine - a Mac Pro with OSX 10.10. so I had to install everything on my Macbook Pro with 10.13. but then no Wifi downstairs in my Studio, the whole process took me over an hour :-)
Sofar so good, but I still can't get Reaper to run with the Fireface. Reaper recognizes the Fireface as the DAW's interface but as soon as I choose it Reaper becomes extremely "laggy", Playback doesn't work and there is now signal coming in or out. I'm on the latest Reaper version (these get updated nearly every week) and Reaper is running smoothly when set to the internal audio output of the Mac Studio or the Headphone output.
To troubleshoot my DAW I tried running the FF in Garage Band with the same result: Here Playback works but there is no signal coming in or out. At one time Garage Band even froze my whole machine completely which could only be fixed by holding the on/off button for 5 seconds..
I have another interface which is a small one channel IK Multimedia irig hd 2 and I am so frustrated to tell you that this shitty interface works just flawlessly in both Reaper and Garage band: Just plug and play, no updates needed..
Sorry, I'm at a loss here. Sounds as if it is a problem with the driver or (more probable) an interaction of the RME driver with something else, maybe? The machine itself is fast enough, the beta driver works flawlessly on other such systems etc.
Did you disconnect everything in hardware, incl. class compliant stuff, hubs, docks, external drives etc? Only Mac, screen, keyboard, mouse? Do you run any legacy software? Does Reaper accidentally run in Rosetta mode due to incompatible Plugins?
Thank you Christian. Yes I have disconnected everything. All I use right now is an active USB hub for Keyboard and Mouse and I have one Monitor connected via HDMI. The Fireface is plugged directly into the Mac as usual.
The Mac Studio is still pretty "naked". I have already installed all of my processing VSTs like Izotope, Waves etc. but not yet the instrument VSTs. But I do need to install these tomorrow as I have some urgent tracks to deliver.
I think you may still miss a step, after re-installing the v3.27 driver (before restarting) go to Apple System Preferences, Security & Privacy tab, unlock the padlock on the bottom left, and "Allow" the kernel extension to run.
Thanks Jeff! You're right, but that's what I (always) did.
I am still hoping for a simpe "user's fault" like this, but in this case I followed the exact same pattern that is shown on the RME website. Also the 3.27 driver didn't get me into "connected" mode in Total Mix, strangely only the beta 4.04 driver does. But I will re-try the 3.27 again several times. Thank you!
What is also strange is, that when I install the 327 driver the Apple System Preferences/Security&Privacy no longer shows an addiational RME tab to unlock. Also Total Mix appears as an icon in the dock but doesn't open when clicking.
Thermos4940
Hi, I'm a Fedora user too, but I used my work laptop with Windows 10 to install GOS on my Pixel 6a.
Theoretically Fedora should work, but I preferred to avoid potential problems since it is not officially supported in the prerequisites.
I also tried it from 2 different laptops (Fedora with Gnome and Fedora with KDE). And once also from a live operating system (Ubuntu). Somehow the common denominator seems to me to be the phone. Each time the same error message.
Okay, I've made progress. I have changed the USB connection mode to "File Transfer". Before it was set to " charge only". This allows Android Flash Tool to connect and the process actually starts. But, as soon as the device reboots it loses the connection. In the browser appears:
I also ran into this issue on Fedora. It seems that the Flash tool being able to work with the phone after it reboots into the bootloader is equivalent to fastboot devices working without sudo, which it doesn't by default.
Various places around the web point to 'udev rules' to fix similar issues. Fedora's android-tools package includes a set of udev rules in a doc folder, which you can symlink to /etc/udev/rules.d to make them take effect, but these rules only work for adb, they don't change anything for fastboot!
I followed these instructions to create a different kind of udev rule manually, plus a bit from this forum post to create a plugdev group and add my user to it. After rebooting my laptop, fastboot devices and the web flashing tool both worked.
Officially supported browsers for the web install method:
Chromium (outside Ubuntu, since they ship a broken Snap package without working WebUSB)
Vanadium (GrapheneOS)
Google Chrome
Microsoft Edge
Brave
You should avoid Flatpak and Snap versions of browsers, as they're known to cause issues during the installation process.
I found out that it was a necessary step to boot my Pixel 6a into fastboot and so install the Android driver by checking for updates and so clicking optional updates on the Windows machine to get the android driver.
[deleted] For my part, I installed GrapheneOS on Arch Linux with Sway and had no difficulties. It seems OP was able to install GrapheneOS with no difficulties, either (though they have not said this, it is implied); it's the Google Web Flashing tool they're having issues with. If Google released their flashing tool under a free license, it would be easier for developers to investigate why the tool was not working, but alas.
The GrapheneOS factory images flash a non-stock Android Verified Boot key which needs to be erased to fully revert back to a stock device state. Before flashing the stock factory images and before locking the bootloader, you should erase the custom Android Verified Boot key to untrust it
Caution: If you have Android Debug Bridge (adb) installed on your machine, stop the adb service with the command below before proceeding as the service interferes with the flashing process.
Equal2024 Edit: Ah, I see you're referring to whether they've used the Flatpak or Snap versions of the browsers; my bad. This might be the case, as they've used Fedora and Ubuntu. In addition to this, using a containerized version of a browser is not a good idea anyway, because it replaces the much more robust browser sandbox these browsers are using with the Flatpak or Snap sandbox; see some discussion here:
Equal2024 @Thermos4940 Though this is unlikely to be related to the issue you're facing, make sure you've removed the GrapheneOS key before using the flashing tool; text from GrapheneOS web installer:
Edit: Ah, I see you're referring to whether they've used the Flatpak or Snap versions of the browsers; my bad. This might be the case, as they've used Fedora and Ubuntu. In addition to this, using a containerized version of a browser is not a good idea anyway, because it replaces the much more robust browser sandbox these browsers are using with the Flatpak or Snap sandbox; see some discussion here:
This has resulted in me being able to start the process. However, I then had to install more drivers after my Pixel rebooted and lost connection to my PC. Unfortunately, I can't reconstruct exactly what that was, but I more or less followed the troubleshooting instructions on the screen. Sorry, it's been over a week now and I've been busy setting up my system in between.
e59dfda104