I just got myself a nice new Makita 18v drill. It’s really nice 🙂
On thing about my battery operated tools I’ve noticed is that I tend to have one battery in the device and another charging. Since I don’t used them very often they batteries tend to degrade after a while, so I was thinking I could use the battery in something that I would run often to keep the battery in a nicer condition. It occurred to me that I have a pair of old Roomba’s in the shed that are just sitting there because the batteries are dead. What if I could use a cordless drill battery instead? I got a Makita battery adapter on Ebay and sacrificed one of the dead Roomba batteries to allow me to connect the two up. Now the interesting thing is the Roomba batteries are 14.4v and the Makita battery is 18v so I was expecting a bang and some smoke, but the Roomba seems to like the new batteries! I’ve since done some reading and apparently there is a version of the Roomba called the Create that can be run on 12 AA batteries. That would be the equivilent of 18v so it looks like the Roomba is built to take these kinds of voltages. I’ve yet to let the Roomba run through a full cycle as it is kind of noisy, but maybe later…
As with most “computer” guys (and gals), I often get asked to look at computer problems. This latest one has been interesting. A friend overseas had their USB hard disk (WD My Passport Ultra) fail so she shipped it to me to take a look at. When I plugged it into a Mac I got nothing, however the device did show up in the system report. Next I plugged it into a Linux box and got some strange errors in the kernel log about not being able to set the device configuration. I looked on the WD web site and found there was a firmware update for the drive but it could only be applied from a Windows machine, so I booted up my Windows machine and ran the firmware update. Just before the update finished the drive suddenly popped into the explorer window. I followed the instructions in the firmware updater and shut down the machine, unplugged the device and booted up again. Unfortunately the device didn’t come up after doing this. I decided to have another go with the firmware updater and this time I did not shut down and so while the device is available I am madly copying as much data off as I can.
Initially I tried using the Windows explorer to copy the files, but since there were so many FS errors and timeouts this didn’t work so well. What I eventually ended up doing was writing a little C# app to copy the files and ignore as many errors as I can. So far it seems to be working. The drive appears to be running VERY slowly, but still actually reading the data. Strangely some files are copying at the expected speed. It’s very weird. My guess is this drive is very sick.
It’s amazing what you can find inside the RAM on embedded devices using a JTAG!
I’m currently dumping the RAM image of an energy usage monitor. So far I’ve seen OpenVPN keys and a few other interesting files still in memory.
With any luck I’ll get a copy of /etc/passwd 😉
It’s been quite a while since my last post. I’ve been really busy with my work and haven’t had much time for my many hobbies of late.
Over the last weekend I managed to dig out my 3D printer that I’d been working on for a while and finally managed to get it going. There were a couple of problems with it. The first was caused by corrupted settings in the EEPROM which once fixed started giving good prints almost straight away. The second problem was that unless I flexed the controller board in just the right way no data was transmitted over the USB. This made reflashing the device really tricky as I had to hold the board in just the right position during the flashing process and it was very easy to get it wrong resulting in a corrupted firmware.
Today on my lunch break I got out the oscilloscope and was able to see the serial data on the processor pin (Atmel Mega2560). I then looked up the datasheet for the USB chip (another Atmel processor) and found that there was serial data appearing there as well. A quick little go with the soldering iron on that pin (fortunately an easy one to get to as it was on a corner of the chip) and the data started appearing on the USB as expected 🙂
I’ve been playing around with my old DroboPro and in the process managed to frag the uBoot config rendering the unit basically useless as the vxWorks side didn’t boot the special disk applications required for correction function. Fortunately I have another Drobo, in this case a Drobo FS. I was able to disassemble that (I didn’t even break the waranty void sticker) and gain access to the serial ports on the main board. From there I was able to read the Drobo FS uBoot config and use that to guess what the values needed to be for the DroboPro. After doing this the vxWorks side started working again 🙂
I also figured out what is up with the Drobo dashboard app. It definitely uses the serial number reported by the Drobo to determine the type unit it is talking to. It turns out the device type is the 5th from last digit, so if your serial number is TDBxxx7xxxx you have a Drobo FS for example.
0 = "Drobo"
1 = "Drobo S"
2 = "Drobo 5D"
3 = "Drobo Mini"
4 = "DroboPro"
5 = "B800i"
6 = "DroboElite"
7 = "Drobo FS"
8 = "Drobo 5N"
9 = "B800fs"
A = "DroboPro FS"
B = "B1200i"
So, how do I go about changing the serial number reported by the firmware? After a bit of messing around in the uBoot environment I discovered the
printenv command. This shows all the environment variables. It is then possible to track down the variable containing the serial number and change it to the desired value. Using the
saveenv command is not enough however, it is necessary to call another custom command
updateFlashToken to have the vxWorks side of things take notice of the new value.
The thing I did wrong was try out another of the custom commands
tdsetup. Don’t make the same mistake I made as it will frag all of the custom set up and leave you with a boat anchor. I was just lucky enough to have another one to examine to get the config back 🙂 I think I need to see if I can find a way to reload the firmware again as it appears I may have damaged something else as it is still not showing up quite right in the Drobo dashboard, but at least it is back to running the file server and so on 🙂
After working through it a bit more it appears that the problem is actually in the Drobo Dashboard. For some reason it is refusing to show the “Drobo ProFS”. I loaded up the 1.8.4 version of the Drobo Dashboard and it sees the unit just fine but doesn’t allow much to be configured. Maybe I will need to write my own client to get at all the functionality….
I recently saw a post somewhere that showed the internals of one of the newer high end Drobo machines. It appeared to use the same motherboard as the Drobo Pro I have sitting here on my desk gathering dust so I decided to take another look at what I could do with the thing. I had previously opened the machine up to get around the rebooting problem by disconnecting all the batteries with some success and in the process discovered the on board serial ports. It turns out they have a dual core processor in them running completely different OS code on each. One running Linux and the other running VXWorks. The linux one gives a plain old shell with lots of interesting stuff running on it. The VXWorks one doesn’t give much though. From what I can see the VWWorks side handles the actual disk access, while the Linux side handles the “UI” side of things, such as iSCSI on the Drobo Pro or file sharing on the Drobo Pro FS.
To get to the meat of the matter, I downloaded the firmware for the Drobo Pro FS and tried loading it into the Drobo Pro, which of course it rejected as I was expecting. I then had a look at the firmware files and saw they both had a very similar header. After patching the firmware file with the correct header values (an exercise for the reader to find the correct 12 bytes to alter) I was able to load the Drobo Pro FS firmware successfully into my Drobo Pro.
At first it didn’t seem to boot, but after putting some fresh disks in and rebooting the unit, up it came. 🙂 At the moment the device doesn’t show up in the Drobo Dashboard, but it does present a public share, so it’s not a complete loss. I also took the opportunity while I had a serial cable plugged into the board to enable the telnet and ssh servers to allow me to poke around some more.
It looks like the control software on the unit is expecting there to be two ethernet ports while the physical hardware only has 1. I may need to patch the binary…
I’ve been thinking for a while that prototyping stuff with the DIP PIC32 parts should be easier, so I built something over the weekend to make that a reality.
Instead of this:
I can now start with this:
It is just the bare minimum to get a DIP PIC32 part up and running with USB support. I’m pretty happy with the results so far. Now all I need to do is get a USB boot loader that fits in under 3Kb and I can use the Chipkit32 stuff with these little guys 😉
I wanted to play Turrican 2 the other day so I fired up an Amiga emulator, but playing it via the keyboard really wasn’t cutting it, so I broke out a USB game pad I had floating around the place. That also didn’t feel quite right 🙁 What I needed was an old Atari style joystick to really get my Turrican 2 craving licked. I looked around and sure enough I had one, but how could I get it working with my Mac? I needed an Atari joystick adapter. A little googling and ebaying later I found that 1. they are pretty easy to make, and 2. those available online are too expensive. Time to break out the soldering iron and whip one up myself. The hardware is pretty simple, just a PIC32MX220F32B and a handful of other components.
I even found a nice box to put it into!
Once I’d removed the guts of the ADSL filter, it had just enough room to fit all the parts I needed 🙂
After coding up a simple HID based USB joystick (and forgetting yet again that the reason I couldn’t read some of the bits in PORTB was due to the analog inputs being enabled by default) I had a working USB joystick adapter. Time to play Turrican 2!
FRAK! Why can’t I jump?!? It turns out the plastic shaft inside the joystick has a crack in it which means that the UP direction doesn’t work reliably making Turrican 2 unplayable 🙁
I think I have another Atari style joystick about the place, but if not, it looks like ebay may be my only option 🙁
Ah well, I had fun anyway 🙂