Iomega ZIP drives!

I still have my old computer from back when I started at university in 1999! I keep thinking it is time to get rid off the machine, but then again it working just fine.  The only problems with it are that the CD-RW drive is broken and that the Pentium-III consumes a lot of power compared to modern machines. It is a great machine for FreeBSD, however, since all of the hardware is supported by FreeBSD now: wireless NIC, NVidia AGI card, etc.  It also has physical serial ports–two of them!  Last year I installed FreeBSD 10.2, and it has been powered down since. I just got too busy with school work. This morning I came across my stack of Iomega ZIP disks and thought I should see if I still have any data on them. Would my ZIP drive still function after all of this time?

The Iomega ZIP drive was a bid deal for me personally. All of the workstations in the university’s computer science and computer engineering labs had ZIP drives because often our work would not fit on a regular floppy disk. And at this time, there were no USB thumbdrives! I would frequently work in the lab, saving Visual C++ 6.0 projects  or Altera Max-Plus II FPGA projects to my zip disks. I used to carry two around just in case I filled up one disk. I would then continue working at home, taking advantage of the quieter environments to fix my C++ or VHDL code issues. The next day I would take the work I’d accomplished at home and move forward.

Looking back it was really a bit unnecessary though. The school should have prepared a better remote working environment.  The computer science department’s UNIX (Solaris 7 and 8!) network allowed for remote access, so for many of my computer science projects I just worked remotely via ssh on the Solaris machines. But the engineering department didn’t have any remote access capabilities, so I could not use FTP or SCP to transfer work between the engineering network and home. So thus it was the trusty Iomega ZIP disk technology that made my life just that much easier.

When you read about ZIP drives on the Internet, there are lots of complaints about the “click of death” and how unreliable the drives were. I must have been very lucky I suppose. I never had an issue with ZIP drives, and they were extremely reliable. I suppose that the issues was worse for external ZIP drives rather than internal drives. I used zip drives nearly day in and day out for 4 years. Amazingly, the Iomega ZIP drive in my old machine is still working today!

I went through all eight of my disks, and it was a worthwhile experience as I found some old documents and photos. Most of the disks were empty, but one had a bunch of academic papers I had been reading about computational electromagnetics, and another disk had many cover letters and resumes I had written back when I was trying to find a job. I also had some photos from my college days. I got rid of most of the data there, but decided to keep the photos.

In 2003 I purchased a 128 MB USB thumbdrive, and from that time forward I quite using the ZIP drives. The technology now is long dead, and rightly so, USB-based storage is clearly the way to go. But I will alwasy fondly recall the Iomega ZIP disk, much like those before me have memories of 5.25-inch floppy disks. I am going to hold on to these disks for awhile longer. I may keep it around to play around with, but that is about it. After all, I have no where else to transfer the disks to!

Advertisements

FreeBSD and USB Thumbdrives

USB thumbdrives are a convenient way of moving relatively small volumes of data around machines. FreeBSD fully supports such devices. Insert the thumbdrive into an open USB port and check to make sure FreeBSD detects its using the command below.

# dmesg | tail

USB drives are handled by the SCSI subsystem so look for output that would resemble the following:

ugen0.3: <vendor 0x0d7d> at usbus0
umass0: <vendor 0x0d7d USB DISK 2.0, class 0/0, rev 2.00/0.50, addr 3> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0xc180
umass0:2:0:-1: Attached to scbus2
da1 at umass-sim0 bus 0 scbus2 target 0 lun 0
da1: < USB DISK 2.0 1.16> Removable Direct Access SCSI device
da1: Serial Number 073A0C251C0B
da1: 1.000MB/s transfers
da1: 124MB (253952 512 byte sectors: 64H 32S/T 124C)
da1: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>

From the output above, we know the device is /dev/da1.  You can also query the SCSI system to see if the device is found. Note this output also shows “da1”.

root@bsdbox:~ # camcontrol devlist
<WDC WD400EB-00CPF0 06.04G06>      at scbus0 target 0 lun 0 (pass0,ada0)
<IOMEGA ZIP 100 12.A>              at scbus0 target 1 lun 0 (pass1,da0)
<LG CD-ROM CRD-8400B 1.03>         at scbus1 target 0 lun 0 (cd0,pass2)
<SONY CD-RW  CRX220E1 6YS1>        at scbus1 target 1 lun 0 (cd1,pass3)
< USB DISK 2.0 1.16>               at scbus2 target 0 lun 0 (da1,pass4)
Trying to mount just /dev/da1 is not going to succeed. We have to tell FreeBSD which partition to mount. Luckily, for most USB thumbdrives without any encryption (such as IronKeys), there is just one partition on the drive. As such, we can specify /dev/da1s1 to get slice #1, or the first partition. To mount the partition manually, we can use the mount(8) command while specifying the filesystem on the device. The USB thumbdrive I have is FAT formatted, so the “-t msdosfs” option to the mount command will tell FreeBSD to override the default format of UFS. Before running the mount command, however, make sure you have a place to mount the filesystem. I happened to choose /media/usb.
root@bsdbox:~ # mkdir /media/usb
root@bsdbox:~ # mount -t msdosfs /dev/da1s1 /media/usb
The mount command should complete silently, and you should be able to access /media/usb and copy files to and from the device. When you have finished with the device and want to remove it, use the umount command.
root@bsdbox:~ # umount /media/usb
It is safe to remove the device now without potentially damaging the filesystem on the device. After physically unplugging the device from the USB port, if you go back and look at the messages on the system (dmesg | tail), you will see something like the following:
ugen0.3: <vendor 0x0d7d> at usbus0 (disconnected)
umass0: at uhub0, port 2, addr 3 (disconnected)
da1 at umass-sim0 bus 0 scbus2 target 0 lun 0
da1: < USB DISK 2.0 1.16> s/n 073A0C251C0B detached
(da1:umass-sim0:0:0:0): Periph destroyed

New Year Resolution: Technical

Inspired by Professor Matt Might, I decided that in 2017 I am going to try to round out some of my technical abilities. Part of this is driven by the fact I am starting a new job in February that will focus more on software and less on hardware.  As such, I am going to try to focus on learning a new type of technology concept each month. What are my strengths? C++, bare-metal development, software-hardware interface, FPGAs, embedded, etc. What are my weaknesses? Databases! Virtualization! Web!

Update! It was a dumb idea to try to plan all of this…graduate school has been brutal and consuming my life…VLSI physical layout is a very time consuming and drawn out process!

I have made no progress with NoSQL, I could not keep up with the online MongoDB course while trying to keep up with the course load on my other grad school courses. As such, I’ve mostly just been learning RDBMS and SQL slowly during lunch breaks at work and some occasional late hours at night when I get the itch. I’ve also been messing around with iSCSI, which I have to admit I find more interesting that databases!

Anyway, I’m going to revisit all of this in May when I graduate and am done with my academics. I still think the below list is very valid, and I should be able to at least mark off the RDBMS and SQL aspects by May.

  1. January: NoSQL (via MongoDB)
  2. February: NoSQL clients (via Python, Pymongo, and MongoDB)
  3. March: RDBMS and SQL (via IBM DB2)
  4. April: ODBC for RDBMS (via IBM DB2, C++, Python)
  5. May: PKI and Authentication (via MongoDB and OpenSSL)
  6. June: Virtualization 1 (Linux KVM)
  7. July: Virtualization 2 (Linux+Xen)
  8. August: RESTful web services back-end (C++ and  Casablanca library, Python)
  9. September: RESTful web services clients (Node.js or Django)
  10. October: Web-based GUIs (Angular+Node.js or Django)
  11. November: GPU programming basics (Nvidia CUDA)
  12. December: GPU programming (more) (Nvidia CUDA)

I thought about adding DevOps tools into the mix, but I think I am sure I am going to pick up a lot on the job in that area, as well as it would probably help to get a better grasp of deploying virtualization beforehand.

Let’s see how it goes! So far I have MongoDB installed and I am working through the intro course with python at MongoDB University.

Synopsys NAS Stable!

I logged into my NAS yesterday and was informed that DSM 6.0.2-8451 Update 7 was available to install. I proceeded with the update, and the NAS started the install. As it neared the 100% mark, I realized that this would be the moment of truth. Will I still have these power management issues?  After some time, I heard that NAS beep, indicating that it had rebooted. I was pleased so far, I didn’t have to manually power cycle the system!  Within a couple of minutes the NAS was back up online and I was able to log in as admin.

Success! It looks like finally the power management issues are behind me. The Intel firmware appears to have fixed the problem.

NAS Firmware Update – M.616

Synology got back to me and said that my issue has a fix identified that will be released in DSM v6.1 bundle. The current baseline is DSM v6.0.2, and v6.1 is a beta version that is available. Since I’m trying to stabilize this system, I did not want to run a beta version of the DSM operating system. Instead Synology provided me an updated Intel firmware version M.616.

Installing the firmware seemed to help, the system installed the firmware and then rebooted without my needing to manually power cycle the system. Manual reboot and shutdown also worked. This time the system firmware also appears to have been updated:

m616

Fingers crossed now!  Hopefully this will be the end of the power management issues. The next test will be when there is an update to the DSM software and if the system can reboot after updating DSM.

More Synology hang-ups

I had some downtime this morning, so I logged into my DS216+ web UI to check on things. The device immediately woke up upon entering its IP address into my web browser which caused me to let out a sigh of relief, thing back to the last time I tried.  My spouse has been heavily using the device lately moving all sorts of photos onto the unit or to her PC. As a file store I really am happy with this NAS, it works seamlessly with her Windows computer and her iPhone. I mapped the photo directory as a share driver on her Windows computer and all has been well. Yet somehow I knew it was too early still to declare victory.

Sure enough there was a DSM operating system software update.  DSM 6.0.2-8451 Update 6 was available, so I went ahead and chose to update. Unfortunately, the NAS hung when trying to reboot! Again power management issues! The status and network LEDs were out, the HDD indicator lamps were solid, and the dreaded dual-blue LEDs by the power button were flashing, indicating an error state. Once again I had to go over to the device and physically remove power.

I verified that if I manually request a reboot or shutdown, the NAS does come back up. At this point the only issue seems to be with rebooting after updating the DSM operating system. It is a minor nuisance at this time, but I am going to put in a trouble ticket to see if there is a solution to this issue. Perhaps Intel firmware version M.615 that Synology seems to hesitant to offer to the user community? What do they know about M.615 that makes them so hesitant?

End of Semester – Still alive and kicking!

This week marked the end of a very intense semester in my graduate program. I had planned to just take Power Electronics and then a business or engineering management-type elective, but a course in advanced ASIC design topics was offered and I signed up. The course was split into two sections: SystemC modeling and then back-end physical design for ASICs. It turned out that both of courses were very intense, and trying to complete all of the course work on top of my full-time job was very challenging. I made it through it all though with solid grades. In the ASIC course, I learned a lot about ARM CPUs, especially the buses (AHB, AXB) that interface with peripheral devices, and I learned a lot about DDR memories too. SystemC was quite interesting, a very interesting way to model a system-on-chip (SoC). As a C++ programmer I really liked working with SystemC!  Most of all though, I thoroughly enjoyed the back-end design: placing standard cells, power/ground networks, clock-tree routing, and data signal wire routing. There are lots of algorithms going on in tools like Synopsys IC Compiler and Synopsys PrimeTime, the clustering and routing algorithms alone are fascinating for those interested in applications of algorithms.

Below is a screen capture of my clock-tree in an ARM CortexM0 design. It reminds me of a fractal in some ways! All in all it was a really useful course, and working with ASICs always makes me think about trying to find a job in the semiconductor industry…fascinating technology.

proj3_clock_tree

I plan to finish the program and “graduate” at the end of the next semester. I willl take a course in VLSI system design as well as a managerial accounting course. Yes, I am backing down and taking a business course! I learned my lesson this semester with two engineering courses, it was just so intense. VLSI will be a great course, and I think that an accounting course would at least be useful knowledge.