Hello to all,
Sorry, my english isn't perfect, but I'll do my best
I ask for help, because Verbatim will or cannot help me out.
I buyed the NAS two years ago, but never used it. As I wanted to use it now, I realized, that I have to activate it by using a software that has to be installated on the PC and the activation is via a verbatim server. But... the server is down for years ( the NAS seems to be older, I bought it through a clearance sale. Shouldn't do that).
As I understand, the sense of the wrt-project is, to replace the original firmware from web based devices.
So my question is, whether it is possible to replace the original Verbatim Firmware and how this works.
Sorry for the long question, but I tried to be precise.
Unless we're talking about an x86 device[0], the firmware needs to be ported to every individual device[1] in order to work, which means if the device in questions isn't listed as supported in the Table of Hardware (it isn't), then it isn't supported[2].
--
[0] with a generic BIOS/ UEFI implementation that supports regular bootloaders (grub) and booting from external media, basically an ordinary PC in a NAS case.
[1] embedded devices need individual attention, there is nothing standardized about them, requiring special attention for each individual model.
[2] this doesn't necessarily mean that it can't be supported, but someone with the device on their desk would have to work on it.
Thank you for your fast response.
Sorry, that I reply that late, lot of work.
You're absolutely right, it isn't supported and I know, it couldn't be very easy to fool around with an embedded device. I have no idea, how firmware really works.
In my understanding it is similar to an OS. My only experiences start with MS-DOS over WIN 95 and so on. Never touched Linux. But am I right so far, that there has to be a small Computer in the NAS? Might it be possible that the Hardware of this could be recognized by the OS (think Linux should work) like this works normally with an PC when you install the OS?
Think I only need drivers for USB and LAN, should be standarizised material, hopefully, and of course OS and some kind of management software.
The biggest question for me would be, how I can get contact to the NAS. By the way.....when I can get contact to the NAS, maybe there would be a way to activate the original software.
Lot of questions, I know. Sorry for that and thank you very much for your help, so far.
@diizzy
you are absolutely right, it isn't worth it.
The point is: I'm a very strange person, It hurts me physically to throw away things that are working (I know it don't work, but you might know, what I mean)
And I love to repair things, especially when other people say: " you don't get it to work".
And the major thing is: When I have a brandnew (means never used) thing and the manufacturer say "sorry, we put our servers down, but you may use it as a expensive paperweight", than this pisses me of. Sorry that I say this so, but thats how I'm feeling. And I don't understand anyway, why a NAS has to be activated.
I bought a other NAS years ago, plugged it in and this was it. Still working.
Should always work like this
Hardware and software evolves and most consumer hardware have minimal margins to begin with and there's no gain for a manufacturer to contract someone or maintain a device way past it being EoL. At least knowning the SoC would help but it's extremely dated and possibly unsupported upstream. Also, by this time I wouldn't trust the HDD as it's more the likely beyond "best before date" so to say
Maybe you'll be find some information about that on the web, but given that this would be something very specific to the OEM firmware, this is the wrong venue for these issues.
Yes, the NAS is a small 'computer', but it might not be an x86/ x86_64 computer - in all likeliness it isn't (mips, arm, ppc would be options). Only very recent/ higher end NAS devices are using x86_64 boards underneath. I couldn't find any information about the hardware of this particular NAS off hand, but I didn't spend much time on searching either --> but this would be your very first job (possibly involving disassembling the device, identifying the uses chips, looking for a serial console pad, …).
This belief is incorrect, you need drivers for everything, down to the RAM initialization and CPU bring-up code. Linux supports lots of architectures and devices, but for embedded devices (routers, NAS, smartphones, …), vendors don't always (read that as basically never) provide their changes (even less submit them properly, so they can be included into mainline Linux), so you will be hunting for old GPL code drops from your vendor, to find the necessary changes there (which were written for an ancient, horribly butchered up and mutilated vendor kernel, so your task would likely be to make "a windows 10 driver" out of a half-broken "MS-DOS 4.11" 'example').
That is both correct and incorrect at the same time.
Yes, Linux (combined with its surrounding ecosystem) is an OS (and the OEM firmware is most likely linux based), similar to what the Windows NT branch of operating systems would be, but embedded hardware is very different from PC hardware.
On an x86 system, you do have an on-device firmware, the BIOS (these days UEFI, but for the discussion at hand this isn't much of a difference), which abstracts away the actual hardware differences and provides some (very basic) interfaces to the essential components of the computer. As a result you can take your DOS boot floppy, put it into a 30 year old x86 computer or in a modern computer (if you enable the legacy BIOS CSM and use a USB floppy drive) which rolled off the production lines just a few days ago and it will boot your floppy, despite the hardware being 25 years newer than your boot floppy. Yes, for advanced features like ethernet, wlan, sound, USB, … you will have to provide drivers (which aren't likely to exist for DOS), but the basics (RAM initialization, CPU bring-up, basic (slow, but functional) FDD/ HDD access) are set up by the BIOS and can be used by your 25 year old DOS boot floppy with generic drivers written 25, 30, 35 years ago. On embedded devices, this BIOS (Basic Input Output System) and its basic hardware abstraction layers do not exist, the SOC has 'some kind' of hardcoded way to load and execute the bootloader (often u-boot) from flash, the highly device specific bootloader does some minimal initialization of CPU and RAM, loads ${x} bytes (the linux kernel) from flash into memory address ${y} and jumps to that memory address and starts executing the code there. It's now up to the linux kernel and its embedded driver to initialize CPU (again), RAM (again), flash and use the correct drivers, loading- and hardware addresses, before handing over to the userland (and become actually functional). But there are further complications, contrary to x86 and its plug'n'play features (between hardware, BIOS and OS), most hardware buses, devices and functionality can't be autoprobed (detected automatically), the hardware doesn't provide any detection methods for this[1] - this means the kernel needs to know exactly on which hardware it is running on, which devices are present and how they're wired up (which is specific to each individual model and h/w revision of said model[2]), it's no longer 'generic' and can only run on this particular model. This also means that you as the system integrator wanting to port OpenWrt to this device also need to know all the fine details at (kernel- and image-) build time, before you can actually boot it. An additional hurdle is that you're basically always very much flash- and RAM constrained, with the SOC usually not being very fast either, so beyond the basic difficulties of getting your SOC running, you need to strip down your kernel and its drivers, just as well as your rootfs to the bare minimum, to make it fit. The kernel (and its modules under /lib/module/${uname -r}/) of a typical x86 desktop distribution weighs ~150 MB on-disk size, but the whole storage on most devices OpenWrt is targetting often provides between 4-8 MB, for everything (and not even all of that is usable, as ~128 KB are 'lost' to the bootloader (often u-boot) and its environment (settings/ uboot-env) and another 64 KB to the WLAN calibration data). So yes, while roughly similar - the actual situation is vastly different, once you leave the cozy, well-treaded paths of the x86 ecosystem and its generic hardware and generic OS support.
Mitsubishi Kagaku Media Co., Ltd.
4-1-23 Shiba
Mita NN Building
Minato-ku
Tokyo, 108-8415
Japan
--
[1] in DOS terms, welcome back to the year pre-1994, with your ISA bus and having to hardcode IRQ, DMA and memory addresses via jumpers on the hardware itself, and providing these addresses by hand to your soundcard driver in config.sys.
[2] from the basics, this is the architecture (mips, arm, ppc, …), to the very specifics - like you have this amount of RAM, but can't uses memory regions ${x}, ${y} and ${z} as they're reserved for ${foo}, this is the flash chip - use this hard coded partitioning map chosen by the vendor, your ethernet card is part of the SOC on address ${bar}, using IRQ ${baz} and DMA ${whatever}, its MAC address can be found at offset ${blablubb} in partition ${yetanotheraddress} of your flash, same for the wlan, ….
Mitsubishi have quite a complex company structure but it seems that Verbatim GmbH have little to do with MKM Japan as that mainly seems to be the "business branch" for the Japanese market. From what I can tell GmbH falls under the MCHC Group (Mitsubishi Chemicals Holdings (Corporation) Group) umbrella at least that's what the Freecom site says (https://www.freecom.com/article/privacy-statement) which also appears to be Verbatim GmbH. MCHC seems however to operate independently from MKM Japan doing some quick Googling. US branch however seems to be more closely related to MKM Japan. But then again, I might be wrong =)
Thank you again for your very fast replies.
Seems it is really a nearly unsolvable (does this word exist?) problem.
Think only chance would be that it is an widely spreaded SoC. Think I'll find time over the weekend, to open up the device and have a look what is written on the Hardware. @slh
Can't tell how grateful I am, for the work you did with this post.
Of course it's quite hard to me to understand everything in a foreign language, but I think I understood the most, cause you kept it quite simple. There were a few Linux things in it, that I didn't really understand, but I think I catched the sense.
Two more ideas: Might be possible that I can get the same device but activated on ebay or so. Is it possible to clone the Firmware from this to my device (remember, the major problem is, that I cannot use my device 'cause the missing activation)?
Other idea: when I find enough space in the device, could I take, for example, an Arduino thing ( think should be supported by openwrt)?
"Possibly", but as you noticed yourself, you'd somehow need access to the device first (bootloader, serial console, telnet/ ssh, etc.) which might or might not be easy.
Arduino will not be helpful, a serial console (most likely 3.3V!) would, but not as a solution in itself - only to help debugging.
Edit: Just be aware, whatever you do there depends solely on how the vendor has set up their OEM firmware, it has nothing to do with OpenWrt and what can be done is unclear/ OEM firmware dependent. So it's up to you to figure that out, to make educated guesses (Linux experience would come very handy for that), to experiment, without howtos or assistance. You'd need to find out how to get access to a console (or if that fails, at least how to manipulate the systems from the bootloader) - and how to go on from there; simple cloning from another device is not advisable (at least not without knowing what/ why), as that might also clone data that must remain unique (MAC addresses, UUIDs, etc.).
The challenges that slh describes can be anywhere from many days to solve to unsolvable (yes, a word in English) after weeks or months without access to the OEM's schematics and source code.
If you had ten of these, it might be worth the time to get them all running. Since it seems to be a single device that you have and perhaps very, very few other people have, it seems like a lot of work to me, especially for something that is close to 10 years old.
Unless you enjoyed it as a hobby and something to learn much more about how Linux (the kernel) and OSes (like OpenWrt) work on embedded devices, it is not something that I would recommend as your first "project". Even with hardware that is current, has a complete source-code distribution (most do not), and has good technical documentation (including that for the chips inside), it can take several weeks of nights to get a new device running, assuming that the chips inside are already fully supported by Linux and OpenWrt.
If you needed a NAS at a reasonable price, the ToH can show you all the devices that people have identified as "NAS" that OpenWrt supports, or once supported. Several are very old. I would not purchase anything with less than 16 MB of flash and 128 MB of RAM (256 MB is better). I think that a single-core, MIPS processor running at less than ~750 MHz is too slow for a NAS since I have read that Samba, the file-sharing system that works easily with Windows and macOS machines, consumes a lot of CPU power. If the "Package architecture" starts with "arm" the CPU is probably more powerful than one that starts with "mips" for the same speed and number of cores.
While I do not own any of these devices, if I were looking for myself, I would start by reading comments here about the Seagate, Western Digital, and ZyXEL units (there may be more specific models of NAS from those manufacturers than on that list -- check carefully). I chose those manufacturers because they have reasonable CPU and flash/RAM and I recall several posts here about them (so that they seem to have more than one or two users with them).
It is important to remember that people do not post unless they have a problem, so when reading I check for solutions in the thread.
What do I use for NAS? I prefer a solid x86_64 / AMD64 device either in a case or using USB 3 drives. This is often more expensive though, about US$125 for a PCEngines APU2C4 and then about US$10 each for USB 3 drive cases. There are other "mini PC" options out there too at similar prices, though I personally wouldn't trust a "no-name Chinese" unit with my data.
I have to say one very importent thing first:
I'm very impressed about this forum. Having an unimportant problem, thats's possibly not worth anything and in spite of that getting that much help and useful hints is amazing. And no trolls around posting unuseful replys like: forget it, or don't fool around with things you don't understand, like I would expect in Germany.
Don't know wheter this is a question of the intelligence of the people in the forum or just a behavior thing, but this is absolutly GREAT.
Sorry for this Off Topic, but I must say this. My words are possibly not all correct, but please try to catch the sense.
I realized meanwhile, that it would make no sense to fool around with this device. It's not easy for me, 'cause I try to repair things my whole life before I throw it away. But you have to know, when it's time to give up.
But nevertheless, I made some pictures from the Board, is it posible to post it in here? As a last chance, maybe it's a thing, that other manufacturers use too.
My question about using arduino or similar is, because I have the hard drive and the case. I only want to use it as a media share thing for at home. My thought is, that I can use XMBC (is that the right name?) or similar.
The background why I bought the NAS is, that my Receiver, which has an media player build in (which is not configurable, because the manufacturer pays a lot attention in security (It's a german manufacturer ) does not show my existing NAS (that I use rarely). I can get contact to my Fritz Box Router and all of my PC's but not to the NAS. But all my PC's can use the NAS.
The Verbatim has been recognized by my receiver. So I think the problem is, that my receiver can handle a media player, but not a "only NAS".
@jeff
you are absolutely right, when having more of this devices, it could make sense.
Your hints in terms of the NAS (Nasses or what is right to say more than one?)
are interesting. When I want to get a new one, I know now, what I have to note.
Like I say, I want to have a NAS just for getting access to recordings or so. It's not my intention to move big data packages from one point to another.
My wishes are low power consumption, security (like you say in terms of the no-name chinese.
An arduino is way underpowered (by several (dozens) orders of magnitude) for any of the tasks you envision, an RPi might do (but still very slow for anything I/O related, as everything needs to pass through its single USB host port, plus USB2SATA adaptor, etc., which doesn't make this an economically or even useful option either).
...in short, get a new X86 based NAS (which might be hackable) or at least decently powered board such as Espreossobin. In general I'd recommend Marvell SoCs if you want something NAS/Network related and avoid USB over SATA at all costs if possible.
There are plenty of pretty nice mITX x86_64 boards (with 2-6 SATA ports) on the market for rather little money (some Atom based, others using desktop CPUs), a bigger problem are affordable NAS-like cases.
Not really? Atom kinda sucks (and are quite dated by now) not to mention they're usually 3x+ more expensive in the end (RAM etc), in that case you're much better off getting a refurbished business computer.
