Hey there.
I bought a new MTCD 5.1 from Erisin for my Audi A3 8P. It took me a lot of time for research due to the lack of available noob's information. This is why i want to make a summary of my lessions learned. But before i still have some questions to ask:
1) There are 2 types of "firmware": MCU and MTC* (MTCB, MTCC or MTCD). Is this like ROM and Kernel?
2) Installing a new firmware: It is possible to flash a zip in Recovery OR just add a correctly named image file into the main directory and system will ask if it should update?
3) Is a Recovery plattform always preinstalled? (I'm used to having to flash TWRP or similar first)
4) What has to be backed up to be able to get in the original state? Can this be done in the Recovery?
5) Did anyone manage to use the original car microphone? (I read about a ROM which uses double Bluetooth connection for phone AND internal car handsfree system)
6) I understand that FUSE improves the overall performance because it uses the same space for ROM and RAM and therefore enhancing the RAM performance significantly?
7) Is it possible to install a Joying Software on a Erisin device and so on?
First of all just to clear things up. There is two moving pieces. "firmware" and the android software ROM installs which some also call "firmware" sometimes just to make it confusing. The firmware is very low level hardware code that is installed onto the MCU which is a separate very low level hardware controller on the systems and is totally separate from the processor which runs android, the MCU's are in different models/revisions called MTCB, MTCD, MTCC. Go to your settings->about and look at the MCU type it will have the letters MTCD, MTCB, or MTCB in the hardware version. You have to load the correct firmware for the correct hardware type. If you load MTCB firmware on MTCD hardware etc.. you will brick it. You must load MTCD firmware on MTCD hardware.
There is also different ANDROID installs available for the units. Those are generally built specifically for a) the MCU version, b) the screensize, and d) the processor. So there is a specific build of android for the head units that have an MTCB MCU processor, are 800x600, and have a RK3188. If you have a different MCU such as MTCD, or a different screen resolution you have to find the one that matches your system.
2) Recovery using a USB stick or SD card is the best way to go. Usually when installing different versions(stock vs malysk etc) of the android system install (ROMS) you have to first do the wipe/clear from inside recovery because they can't be installed 'on top' of each other. Sometimes a change will also require a wipe to be done when installing even a newer version of the same system.
3) The recovery is in the hardware itself on these units. No need to do anything other than know the magic incantation and keypress sequence etc to get to it on your device.
4) Most of us backup our APPS/App Data using Titanium Backup. Most people don't chase every update because often updating the ROM software android on these units is generally basically a full new install and you lose all your setups and apps and you have to do a re-setup like a brand new unit when you update and its a bit of a hassle. Titanium Backup of your apps can help make that time a little shorter but it still is a bit of effort, so personally I only update every so often and not every version.
5) Most of the newer models seem to have better mics. I had a MTCB and I had to do the 'mod' to get mine usable, but on the newer MTCD I have now, the mic worked fine as is.
6) The BIGGEST benefit of FUSE is that it makes the 'internal' space look like a full 16GB+. The stock roms., only have 2GB internal (OS) space, and 16GB looks like a 'SD Card", so you only have very little space to install apps and you have to do the whole 'move apps to SD' thing to be able to install apps on that space. Also doing the 'move apps to sd' thing messes up the icons on apps lots of times. With the FUSE mod, you have a huge amount of space to install apps 'internally' and it just works much much better.
7) Generally the 'sticker' on the front does not matter, its the system/MCU type such as "JY, RA, etc." But I would stick with either the stock rom for YOUR brand, or use Malysk's install.
Related
Question about ROM flashes.
I'm actually an IT professional in the work related field, so any basics need not be explained. I am still new to Windows Mobile devices and would like to know what this means for my phone.
The way I view a "ROM" is as a firmware, or static programming on a chip. Maybe even a CMOS imprint. In this field, such things are semi-permanent at a component level. For instance, you don't download a .cab file to upgrade your bios (as many "ROMS" seem to come in .cab files), you boot your system on a floppy and run an application that flashes your CMOS with the new image.
What would we assume the "ROM" is on Windows mobile phones? Is it a chip hidden inside of the phone, separate from the primary memory? Is it simply considered all that is in the \windows directory? I don't see why .cab files can flash the ROM.
This leads me to the question, if you do a hard-reset, I assume there's secondary memory on the phone with the \windows folder and all the factory defaults. The memory must serve no other purpose other than to harbor these defaults in the need of a hard-reset. Does flashing your "ROM" also apply changes to this chip containing the default OS image?
Hi, here a short description:
ROM:
The ROM is quite similar to a computers harddisk AND RAM (All-In-One), but the OS has to and additional software can be integrated via flashing and is therefor fixed. All data you flash will stay in the ROM after a Hard-Reset.
Some ROMs also contain a Bootloader-ROM and/or a Radio-ROM
Bootloader-ROM:
This is quite similar to a computer's BIOS
Radio-ROM:
The firmware to your PDA's built-in connection devices (e.g. GSM, Bluetooth, WLAN,...)
Hard-Reset:
A Hard-Reset is similar to a comlete reinstallation. Some computer vendors add a recovery CD/DVD to their products. On a Windows Mobile Device the Recovery-disc is integrated in the ROM and will be automatically installed during a hard reset.
And to complete this one ;-)...
Soft-Reset:
A Soft-Reset is similar to a cold restart of your computer. By the way, there's no possibility to "shutdown" Windows Mobile like you are used to with Windows XP or Vista.
Oh, and you cannot install a ROM using a cab-file. Cab-files are "executables" to install additional software. They can only be installed on the device. ROM's have to be installed from a connected computer (There's also a resolution to install a ROM from a Storage Card, but i am not used to it and cannot give you more information about this. But you'll find it, searching in the forum).
jon_k said:
Question about ROM flashes.
I'm actually an IT professional in the work related field, so any basics need not be explained. I am still new to Windows Mobile devices and would like to know what this means for my phone.
Click to expand...
Click to collapse
Me Too.
jon_k said:
The way I view a "ROM" is as a firmware, or static programming on a chip. Maybe even a CMOS imprint. In this field, such things are semi-permanent at a component level. For instance, you don't download a .cab file to upgrade your bios (as many "ROMS" seem to come in .cab files), you boot your system on a floppy and run an application that flashes your CMOS with the new image.
Click to expand...
Click to collapse
Yes, it is firmware on the chip, but like a BIOS, it exists after the phone is off, the battery removed, etc. The stuff in the cab files that you install doesn't. Well, let me retract that. The stuff in the cabs and your data stays there after a soft reset, and removing the battery (at least for a short while, YMMV), but my experience has not been that the data stays there after the battery is out for a while (again, YMMV).
jon_k said:
What would we assume the "ROM" is on Windows mobile phones? Is it a chip hidden inside of the phone, separate from the primary memory? Is it simply considered all that is in the \windows directory? I don't see why .cab files can flash the ROM.
Click to expand...
Click to collapse
Yes, it is a chip. Most of the time, they don't use discreet transistors for these time of things. They are prohibitively large and expensive to solder together to make the memory, not to mention power hungry.
To answer your second question, if you peruse the various ROMs here, you will see the following:
Base operating system: This is a common denominator. This is Windows CE/ Mobile edition, WM6, whatever you want to call it.
Additional CABs: This is the flavor the chef uses in his/her kitchen to make the ROM do what appeals to them (and their audience). These can techniclaly be split out and individually installed if the cook puts them as a cab file that you copy to the phone and install from that file downloaded.
jon_k said:
This leads me to the question, if you do a hard-reset, I assume there's secondary memory on the phone with the \windows folder and all the factory defaults. The memory must serve no other purpose other than to harbor these defaults in the need of a hard-reset. Does flashing your "ROM" also apply changes to this chip containing the default OS image?
Click to expand...
Click to collapse
What will happen when you hard reset is the ROM that was flashed to the phone will be as it was when you first burned it to the phone. Here's an example: You buy the Kaiser marketed as an AT&T Tilt on 1/1/08, use if for 6 months, and on 7/1/08, you hard reset it. It will be the same as when you turned it on for the first time.
Another case: You buy the phone on 1/1/08, and download a ROM from Dutty, or whomever, and you carefully follow the noob instructions (like I did), and flash it on 1/2/08. You do a hard reset on 7/1/08, and now the phone is the same as when it was last upgraded, so it will be the 1/2/08 version that it goes to.
Clear?
Hope this helps, and if there are others that want to correct me, please do so.
Fairly good explanations.
It makes a bit more sense now.
I'll post my new understanding of the control structure and functionality based on everyones post above. If you want to confirm, deny, or alter any of my perceived facts I'd appreciate it! I just like to know a basic understanding of the device functions internally so I can be educated when tinkering with things.
The radio ROM = ROM that controls the radio. Contains frequency ranges/broadcast tweaks for different locales, probably if tweaked can also allow illegal higher wattage transmission power. Some interesting (and surely FCC illegal) hacks are probably available here.
The device ROM - the upper level functions of the phone. Probably has support for the type of WIFI and bluetooth adapter you have. Has to have compatibility to interface with the radio ROM for phone functionality to be supported. Also is what interfaces with the GPS radio, probably the phone, links the keyboard to the OS, etc. Probably handles API between radio ROM and Windows mobile?
The Windows Mobile OS, which is the operating system itself. It communicates with the ROM, and is limited by what the ROM is limited by. Any .cab's or software retrieved here will enhance the OS, nothing more. A hard reset will bring the OS back to it's original state. (Though ROM upgrades remain.) Any cabs installed or changes to \windows in general made will be lost during a hard reset. It restores all content under \windows to it's default state.
Sounds about right with my new understanding. I think for now I'll avoid flashing the ROM. I'm pretty content with modifying the Windows registry hive since it can easily be restored with a hard reset if I bork up a registry key. Unlike the registry, a ROM if a member here misses something (I doubt they're working with much device documentation) a small coding mistake by them could ruin the phone.
Maybe I'll be more prone to start flashing ROM's if there's a way to extract the current ROM for my phone. Perhaps I can update the ROM through ATT or HTC, and use a packet sniffer to sniff the location (likely http URL) of the ROM file.
One further question though,
Until several minutes ago I thought the ROM simply contained device drivers, etc. Stumbled upon this post however.
rkorzuch said:
Tool worked perfect on my AT&T Tilt. Just installed the HTC ROM. Much nicer than the AT&T ROM.
Click to expand...
Click to collapse
I'm now assuming the ROM contains the OS that is flashed on to the internal storage card as well, with it's own custom branding on the OS, own default application set, etc. As well as it's normal functioning with device communication etc. Is this safe to say this is how it works?
jon_k said:
One further question though,
Until several minutes ago I thought the ROM simply contained device drivers, etc. Stumbled upon this post however.
I'm now assuming the ROM contains the OS that is flashed on to the internal storage card as well, with it's own custom branding on the OS, own default application set, etc. As well as it's normal functioning with device communication etc. Is this safe to say this is how it works?
Click to expand...
Click to collapse
Yes jon_k,
The ROM contains the WM OS. That is what the cooks are changing primarily (more specifically, most of them change/add/delete the bundled apps that come as part of the shipped OSes). Most now are also expanding the RAM/storage portion of the ROM to allow for more usable storage. More and more cooks are also ripping out some of the MS bloat .
You should do a hard reset and then force a soft reset before it does the device customization part. You will end up with a Tilt with none of the AT&T bloat (game demos and such). If you don't like it, hard reset again and let it finish.
If you get real adventurous you can install HardSPL and one of the cooked ROMs (or the HTC one).
Seeing all the work being done over in the dev section, I was reminded of something I did when modding my xbox. The boot img for the xbox is very small, it basically just looks for various executable files in order from different places and then fails if it doesn't find them..and that's all it does, so it is much smaller than an entire ROM, 256k to be exact. The thing is the chip it was contained on in earlier models of the xbox were 1MB, 4 times what was needed. By shorting out the board on the TSOP one could use a physical switch to toggle how much of the chip was visible to the CPU, and you could in essence split this chip into four banks, and flash 4 different boot images if you wanted (although you needed a 4 position switch and a hell of a lot of 32 gauge wire + patience). Since that was really overkill, what I did was split the TSOP into 2 banks and flashed 2 separate bootloaders, one could remain stable and near stock, as to maintain all the function of the xbox, while with a flick of the switch I could boot from and flash the other bank experimentally, if it failed to flash or got stuck in a bootloop then you could switch over and reflash from the working side, keeping it from being brickable.
Now, of course we have much more control over a rooted android device's hardware via software than the xbox has, and can dual boot without adding switches and soldering the board (at least in the case of ubuntu), I was wondering is there any way to get a Eee Pad dual-booting from two ANDROID partitions, so one could boot and flash developing roms (like the ICS rom coming along in the dev section) while maintaining a safe bootable img that works as a safeguard?
Or does hardware limit this function in our machines?
It may be possible to do so by installing one of the ROMs to the recovery partition like we can do with Ubuntu.
I'm sure something like Boot Manager, that stores ROMs on the SD card, could be put in place for dual booting.
Sent from my Transformer TF101 using XDA App
Does recovery boot from the internal SD card or does it flash to an internal EEPROM chip?
I know the ROM itself is on the SDcard internally like any OS, wondering if there might be a way of getting the bootloader to actually search for a file on the external SD card and if it doesn't find it search for the same sys file that the OS uses on the internal?
On the xbox, the OS file was initiated by launching a single file, named default.xbe (xbe=xbox executable files), and all autorun files on the discs were also named 'default.xbe'..is this an option to actually change the initialization of the bootloader to search for the OS on the external before trying to boot from the internal OR conversely simply partitioning the interanl (though I don't know how you would go about getting the bootloader to differentiate between one partition and the other, much less have control of which it chooses to load/flash, without perhaps an intermediate 'OS selection' option)
this is not an xbox.
EDIT: however there would be a way to boot 2 android partitions, it would just require a very different set up to what you are saying. you are stuck in the minimalist xbox approach that has a small microkernel which can only run one executable at a time
I know it isn't an xbox, but that is the only linux-based system I've got experience hardware modding, I assume the TF could assume a similar function without hardware modifications..?
On another note- I just found out that there is an Android PS3 emulator (WOW) wondering how far off an Xbox360 emulator is from being ported from PC to Android..that would give someone a reason to want to dual boot...would be a novel thing to turn on the TF and be greeted by a gaming console boot animation
luna_c666 said:
I know it isn't an xbox, but that is the only linux-based system I've got experience hardware modding, I assume the TF could assume a similar function without hardware modifications..?
On another note- I just found out that there is an Android PS3 emulator (WOW) wondering how far off an Xbox360 emulator is from being ported from PC to Android..that would give someone a reason to want to dual boot...would be a novel thing to turn on the TF and be greeted by a gaming console boot animation
Click to expand...
Click to collapse
lol, xbox is winnt based not linux based
I understood it was UNIX based, at least the EVOX and UNLEASHX dashboards were, I wrote code for them and had to study UNIX in order to do so..I'm sure the OEM xbox stuff was MS proprietary, but everyone went to UNIX based dashboards instead, even installing DSL (Damn Small Linux). I even got a ported version of Windows CT running in a Linux application on the OEM Xbox, but now we are getting way off topic- my knowledge (or lack thereof) of the xbox isn't what's in question, rather my desire to learn MORE about the TF..how about giving me some constructive information instead of simply trying to tell me I am wrong here?
ok yes, we are getting away from the point, as I said, yes it could be done but not quite in the way you propose, it is a fair bit of work.
Check out the ubuntu project for android,
It creates two partitions by using your recovery area.
But the end result is that you a boot android or b boot ubuntu arm. (Don't get excited with arm ubuntu 90% of what I wanted to do I couldn't since its arm.
But my point is, I bet that could be easily modified replacing the ubuntu image with another android image and maybe some other stuff to "dual boot" your tf101.
Course the more I think about it the more reasons I get to doubt it'd be that simple.
Idea 2, one word..... safestrap.
Sent from my XT862
Ok ignore half of what I said, coffee hasn't kicked in and I didn't the part where you mention the Ubuntu project.
So my vote is going to a safestrap. Its exactly what I do on my Droid 3. Non safe is my rooted debloated ROM. Reboot, enable safe mode and I get hashes ics ROM.
Although this use isn't what he designed it for, it's a useful side effect. Takes about 3 minutes to get from nonsafe to safe, for me.
Sent from my XT862
I will have to look up safestrap I've never heard of it, is it a hardware device?
luna_c666 said:
Seeing all the work being done over in the dev section, I was reminded of something I did when modding my xbox. The boot img for the xbox is very small, it basically just looks for various executable files in order from different places and then fails if it doesn't find them..and that's all it does, so it is much smaller than an entire ROM, 256k to be exact. The thing is the chip it was contained on in earlier models of the xbox were 1MB, 4 times what was needed. By shorting out the board on the TSOP one could use a physical switch to toggle how much of the chip was visible to the CPU, and you could in essence split this chip into four banks, and flash 4 different boot images if you wanted (although you needed a 4 position switch and a hell of a lot of 32 gauge wire + patience). Since that was really overkill, what I did was split the TSOP into 2 banks and flashed 2 separate bootloaders, one could remain stable and near stock, as to maintain all the function of the xbox, while with a flick of the switch I could boot from and flash the other bank experimentally, if it failed to flash or got stuck in a bootloop then you could switch over and reflash from the working side, keeping it from being brickable.
Now, of course we have much more control over a rooted android device's hardware via software than the xbox has, and can dual boot without adding switches and soldering the board (at least in the case of ubuntu), I was wondering is there any way to get a Eee Pad dual-booting from two ANDROID partitions, so one could boot and flash developing roms (like the ICS rom coming along in the dev section) while maintaining a safe bootable img that works as a safeguard?
Or does hardware limit this function in our machines?
Click to expand...
Click to collapse
Couldnt you mount the developing or experimental ROM's like ics as loop devices?
Im not sure how many loop devices you can have but i think its like 6 or something
Before little stevie brought out hes ubuntu system thats how i had linux for awhile it wasnt the fastest or most efficient but good enough for testing
Sent from my tf Enigmatic V2 beta 1.65Ghz Panda.test cust kernel settings
Hello,
Really Hopeful in having your support and ideas on quite few issues!
(I hope it is OK to post links) I bought above mentioned tablet ebay co.uk/itm/121228145297
and few accessories intending to use it as Traffic Recorder(Dash Cam) and (ideally iGO SatNav application) for my travels through Europe (mainly UK)
Main specs:
Specifications:
1General
2Operating System
3Android 4.1
4CPU
5ARM(Cortex-A7) MTK8377
6GPU
7PowerVR SGX 531
8Processor Speed
91.5GHz
10RAM
111G
12Hard Drive Capacity
138GB
14Extended Memory
15Support external TF card extend up to 32GB
16Gravity Sensor
17Yes
18Flash Player
19Yes, Support Flash Player 11.1
20Display Size
217 Inch
22Display Technology
23IPS Capacitive Touch Screen
24Multi-Touch
25Yes, 5 points
26Display Resolution
271024x 600 pixels
28Camera
29Front Camera
300.3MP
31Rear Camera
322.0MP
33Flashlight
34Yes
35Connections
36Wi-Fi
37Yes, Wi-Fi 802.11 b/g/n
383G
39Yes,Built in
40LAN
41Yes,Support external USB LAN modem.
42Bluetooth
43Yes, 4.0
44GPS
45Yes,Built in
46Telephone
47 Yes,built-in 2G GSM;850/900/1800/1900MHz
48 3G WCDMA:850/2100 MHz
Click to expand...
Click to collapse
In specs and images it was posted as (will insert image later)
(all is rather optimistic and NOT what it came like!)
it appeared as(will insert image later1)
and issues with me trying (and achieving some sort of control level) there from
(will insert image later)
varied degree of success working on it gets me to (will insert image later2)
So, I have managed to disable some apps, once managed to get mobile networking connections to the 1Mobile Market and get some apps to work, but not GooglePlayStore. Most of remaining (and new apps) are not in Chinese no more, so I am very hopefull, that with rooting I'll get rid of the rest of them gremlins.
Actual specs (will insert image later3)
The questions to you Gentleman (and) Ladies:
1- Do I have to (must) root the device, so that GooglePalyStore would work? as currently, it is installed, but majority of apps are kicking some or the the sort of errors(unsupported etc), and actual GoogleStore app- "works" via Browser...
2- If yes, how do I (step by step) root it in order to have better control? (what applications( with links please) I should install for such Odyssey and what order etc please!?
3- If rooting, is it possible to Get IE 4.4.0 ROM to install?(instead of 4.1.1)- what will happen to the features of IE analogTV receiver hardware management?
4- Would it matter at all, if device is not rooted, but intended to be installed iGo Primo is packaged somehow with GooglePlay app?- will it work? or will that "modified" app work with rooted device all together? (I already learned, that IE Traffic recorder apps are only available on Google)- meaning not available for me for now...
Very many thanks for the answers and ideas in advance!
Am I wrong in believing, that particular tablet is really just a different badge wearing JXD P1000 MTK8377 tablet?
Hardware specs seem to match, as well as appearance/hardware configuration seems ever so similar, is it that daft of an idea to consider rooting and replacing ROM with one, made for JDX device?
Sent from my blueing tablet A770 using Tapatalk 2
I only recently started looking into smartphones (got two android devices to play with just this winter), and some things seem surprising and strange to me, since I'm coming from a PC (GNU/Linux) background. So several technical questions come to mind when trying to learn more about this. One thing I'm curious about is the fimware layer, that is, the part that connects the hardware to the OS, on generic current smartphones, and how it differs from what we currently have on PCs.
On PCs, everything is relatively simple, the UEFI is the central firmware that handles hardware initialisation and starting a payload (bootloader or OS). One thing PC users come to expect is that UEFI allows booting from different media, be it several hard disks, external storage, DVD etc. And UEFI acts as a sort of bootloader itself, having the ability to list registered EFI files and boot from them (although vendor implementations vary here).
So the standard boot procedure on PCs is like this: UEFI starts the hardware, selects the first UEFI boot entry, loads a bootloader (typically GRUB), the bootloader presents the user with a list of OSs and loads the selected OS (GNU/Linux or Windows). There are variations of this (notably Coreboot that can skip all the middlemen and start the OS directly), but what I described is a typical modern dual-boot scenario.
It seems that a lot of these assumptions don't work for current smartphones. You usually have a "locked bootloader" (already raises a question: is this really a bootloader, or is that a part of the firmware? Where is it, in the internal memory – the "hard disk" – or on a separate reserved flash storage?). Often times you can unlock said "bootloader" (it seems that this was a major consumer victory at some point).
When it's "unlocked", then you can install something called a "recovery". (One of the two devices has TWRP installed and I know how to use it, but not exactly how it works.) Oddly enough, it seems that a "recovery" is even expected to be installed after "unlocking the bootloader" by the manufacturer itself (the service menu on my HTC device has an option literally called "Recovery"). From what I can tell, this recovery is something a bit similar to what the bootloader on PCs does (TWRP allows creating and switching between "ROM slots", which is pretty much boot entries), but it also has backup/restore functionality (from what I can tell, that means creating an image of all OS files and dumping it into a specified directory), partitioning functionality, and some tools for offline modification of the OS ("ZIP flashing" and such).
Tasks like that on PCs are usually done either from within the OS, or by booting from external media (which is safer). So here the question is, what prevents doing that on smartphones? Why doesn't the "recovery" act like a standard bootloader: allow selecting between OSs to boot, and if there is an SD card with recovery software on it inserted, boot from it?
Then the "ROMs" themselves. On PCs, you just insert installation media and install whatever you like (minding the partitions and dealing with OS driver support). What prevents doing that on smartphones? This probably follows from the last question, but why can't you insert an SD card with, say, a Gentoo ARM base system, then use it to bootstrap an installation on internal storage?
On a related note, I'm unpleasantly surprised with the whole Android "rooting" thing. On GNU/Linux, such a thing is unfathomable. You install the OS and you set the root password. In the current smartphone world it's like the manufacturer owns the smartphone, not you, and refuses to give the root password for some notorious reason... This also brings up a question: if users don't get the root password, what is the security system on Android like? On GNU/Linux you can't install any application without root rights, which is fair because that means you will think twice before installing applications, and viruses can't destroy your system or change any system configuration files because that requires a root password.
And then about the firmware itself. Does it work different from UEFI, and if so, how? Are there any standards, like UEFI is on x86? Can the firmware be replaced (like it is possible on x86 with Coreboot)?
Thanks for any information you can give me on all these questions
Hi there i have an EMtec Gembox. Arm cortex a-5 chip with mali 450 gpu (i think).
1gb ram, 16 rom Anyway looks like its running android 4.4 and not supported or patchable. It is basically a miracast.
I want to install a later or up to date operating system. I have searched for guides be able to patch into entech firmware or install a custom ROM but I found mostly misleading/outdated information, scams or something for a different type of device.
As for results I like to be able to use it for web browser video file occasionally games nothing too involved and keep the all the original motherboards capability.
Can anyone Point me a good place to start looking how to install new ROMs on this device. I dont think would have be device specific assuming the arm 32 motherboards would all have the command and file formats.
I do know is extremely old and dated but the device does perfectly well just nothing else works with it anymore.
Thank you in advance for any thoughts you might have.