Running a windows 7 firmwre updater on RaspiOS

I'd like to try running a firmware updater for a USB hard drive enclosure.
Supposedly TRIM can be enabled via the updater, but it requires Windows 7.
The host is an 8GB Pi4 running 32bit RaspiOS. The updater is at
formatting link

It isn't entirely clear the updater is needed, but running it seems prudent.
I've tried WINE, but it reports BAD FORMAT, I gather the result of the
updater being written for i386 architechture.
Is there any other way to proceed? I don't own any modern i386 hardware,
nor a Win7 license and don't realy want to buy either. I do have an old
Xeon box, but it probably doesn't have enough RAM to install Windows 7.
The WINE version installed using apt reports
wine --version
wine-4.0 (Raspbian 4.0-2)
Might a later version of WINE help, if it can be found and made to run on
the Pi4?
Thanks for reading!
bob prohaska
Reply to
bob prohaska
Loading thread data ...
No because WINE isn't a CPU emulator - it's a compatibility layer that translates Windows API calls. If your program is compiled for x86, you'll need something that can execute x86 instructions.
formatting link

QEMU has some support for passing physical USB devices over to software running in emulation:
formatting link

Links for setting up x86 WINE on a Pi using QEMU are aplenty:
formatting link
(see bottom for what you presumably had in mind originally)
formatting link
formatting link
--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev
... and Windows may include an ARM-based Intel-64-bit emulator in a future release:
formatting link

Some way to go having it running on the RPi, of course.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
If the drive is USB I'd be looking at Qemu's USB passthrough at a minimum: I doubt WINE would support such access. However, given the risk of bricking the drive if the firmware upgrade goes wrong, I would much prefer to do this on a real Windows box. Much less chance of something breaking halfway through.
Theo
Reply to
Theo
Yes, the drive is USB. I agree completely that using a native Windows box is best, but I don't have one.
Apt search reports a bunch of qemu-related packages, one of which is called qemu-system-arm/stable 1:3.1+dfsg-8+deb10u8 armhf QEMU full system emulation binaries (arm)
Would that be the package to try? It's unclear to me if -arm refers to the host architecture or the emulated architechture....
Thanks for posting!
bob prohaska
Reply to
bob prohaska
If you do mind the risk of bricking the drive, please buy, beg or borrow a genuine Windows 7 box for the upgrade.
These hardware guys' Windows programs are particularly fussy about really running on Windows (and the version suggested).
--

-TV
Reply to
Tauno Voipio
Unless you've put other architectures in your /etc/apt/sources.list (or associated files), then you should only be seeing packages for ARM host architecture. That one presumably applies to running ARM emulation on ARM, "armhf" at the end indicates that it's an ARM package.
But I'd agree with others here that the odds of this all working are very much against you. WINE and QEMU are both extra layers that have pretty dodgy support for what you're doing. WINE's hardware USB support isn't clearly documented, but might be mainly geared at things like game controllers which are HID devices. HIDs work more simply than other USB devices like your HDD.
If you set up a real Windows installation in QEMU, that gives you a bit more likelihood of success, but I still wouldn't bet on it.
--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev
it is the emulated architecture
you would need the -x86 package on the rpi. Consider that then you have to install windows7 in the qemu. I have no idea how good it is supported. But if the drive is so important, given the risk that you can brick it and the time and work you will invest, wouldn't be it better to buy a used laptop with windows7 on it?
Reply to
Deloptes
My understanding of what's easy to do is clearly naive.
Thanks for bringing me down to earth 8-(
bob prohaska
Reply to
bob prohaska
In the past when WINE hasn't worked but I really needed to run Windows software on a current Windows release (the Australian government's tax return submission software - thankfully now implemented as a website), I used an "internet computer" at the local library. Since moving, I found that the local community centre offers a similar local service, though I haven't had to try that yet.
--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev
I doubt it is helpful in the case, because on such computers you can not execute code as administrator, which is mostly the case if you have to do a firmware upgrade.
Reply to
Deloptes
It seems more cost-effective to keep searching for a USB-SATA enclosure or adapter that correctly supports the Pi4's implementation of UASP. Even a rather expensive adapter will be cheaper than a second-hand laptop if a candidate can be identified.
It's a bit surprising that nobody has collected a list of suitable adapters. Perhaps one is out there, but I've not found it in considerable looking.
Then again, it may all be a wild goose chase. The drive and adapter I'm using now, a Sabrent EC-UASP, works in a subjectively acceptable way. The sticking points are a report that the firmware upgrade is needed to support TRIM and a poor performance report from the Pi's SD card speed test utility:
Raspberry Pi Diagnostics - version 0.5 Sun Dec 13 07:48:49 2020
Test : SD Card Speed Test Run 1 prepare-file;0;0;92174;180 seq-write;0;0;100979;197 rand-4k-write;0;0;1200;300 rand-4k-read;254;63;0;0 Sequential write speed 100979 KB/sec (target 10000) - PASS Random write speed 300 IOPS (target 500) - FAIL Random read speed 63 IOPS (target 1500) - FAIL Run 2 prepare-file;0;0;79245;154 seq-write;0;0;83912;163 rand-4k-write;0;0;1274;318 rand-4k-read;271;67;0;0 Sequential write speed 83912 KB/sec (target 10000) - PASS Random write speed 318 IOPS (target 500) - FAIL Random read speed 67 IOPS (target 1500) - FAIL Run 3 prepare-file;0;0;59959;117 seq-write;0;0;58671;114 rand-4k-write;0;0;677;169 rand-4k-read;366;91;0;0 Sequential write speed 58671 KB/sec (target 10000) - PASS Random write speed 169 IOPS (target 500) - FAIL Random read speed 91 IOPS (target 1500) - FAIL Test FAIL
This is with a 5400 RPM mechanical hard disk, so rotational latency precludes excellent random performance. Still, the subjective "feel" of the machine is reasonably good; it's fast enough to use as a chromium browser workstation.
It's unclear if the adapter supports trim as-is. One report on Amazon's review pages says the update is required. An examination of the system per the instructions at
formatting link
suggests the adapter and hard drive both support TRIM:
Maximum unmap LBA count: 65535 Maximum unmap block descriptor count: 8 Unmap command supported (LBPU): 1
In addition, the disk reports: Data Set Management TRIM supported (limit 8 blocks) suggesting it's an SMR drive.
I attribute the acceptable performance to the drive being new, with 1 TB capacity. Once it starts re-writing old sectors it'll likely slow much more.
Thanks for reading this far!
bob prohaska
Reply to
bob prohaska
AFAIK trim isn't supposed to do anything useful to a hard drive regardless of speed or capacity, but I know nothing about SMR, except that an article I just read says its really only suitable for large scale data storage with minimal updating, i.e. not something I'd use for the (main? only?) storage volume for a Linux or Windows system and definitely not for a journalled fling system.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
SMR means "keep hands off!" from what I know useful only in OEM equipment.
Reply to
Deloptes
Practically, SMR is not readily avoidable. It's denser and therefore cheaper than conventional perpendicular recording and has found its way, unbidden, to a wide range of sizes, speeds and brands. The drawback is that, like flash, data is written in relatively large blocks. Writes to an entirely unused block proceed without a delay. Changes to an already-written block require it be copied, edited and re-written in much the same fashion as flash, absent the write fatigue problems of flash. Trim functions on an SMR drive much as it does on a flash device, preemptively preparing new, empty blocks for prompt use by consolidating partly-used blocks accumulated during earlier writes.
When something triggers a long period of sustained writes, like reconstructing a raid array, this overwhelms the preparatory consolidation and slows writes to a crawl. It's not that it doesn't work, rather that it works badly. I should emphasize that this summary is my own interpretation of a random selection of Internet research, and is therefore entirely suspect......
Thanks for reading,
bob prohaska
Reply to
bob prohaska
I've drawn the same conclusions as you, from what I've read. With one small exception: I believe that, if you dig deeply enough into the manufacturer's specification, you can see whether a particular drive uses SMR, and therefore avoid it if you so wish.
David
Reply to
David Higton
Apparently that is a comparatively recent development. There were complaints that SMR was deployed without warning. In the case of my drive, specs at
formatting link
the drive is advertised as PMR but also supports TRIM. AFAIK there's little point in having both. There is also no spec for write speed, only read. The combination is at least a little suspicious.
Exactly what's going on is unclear. Certainly, it pays to check first.
Thanks for writing!
bob prohaska
Reply to
bob prohaska
WD SMR drives support TRIM.
---druck
Reply to
druck
Useful to know.
Next question: how to find out whether a WD hard drive is plain old disk SMR.
I bought a pair of 1GB WD Elements at the beginning of 2019 for use as weekly backups that are kept offline when not actually doing a backup.
I'm using rsync to back up 4 computers (3 running 64 bit Fedora, the fourth is an early 512MB Rpi B) so all other things being equal, I'd expect to see backup activity to be pretty consistent for each machine, which is what I'm seeing: in no case have I seen the sort of slowdown which is apparently noticeable with SMR disks.
So, my guess is that these are not SMR, but who knows: I haven't found any indication of drive technology in the so-called data sheet for for these drives on the WD website - just a not that WD feel free to mix and match drive type between production batches.
Is there any other site that would know/admit what type of drive is in these WD Elements sealed units?
-- Martin | martin at Gregorie | gregorie dot org
Reply to
Martin Gregorie
[snip]
It might help to check these:
formatting link
formatting link
formatting link

But, for my Seagate, I found two sources, both from Seagate, that seem to disagree. The first:
formatting link
implies all 2.5" Barracuda drives use SMR
The second
formatting link
reports "perpendicular magnetic recording", which implies not SMR.
I don't know which to believe.
If you find other references please post.
Thanks for reading,
bob prohaska
Reply to
bob prohaska

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.