(last updated: 08-Aug-2016)
Acquired new, still in original box, all items included
Upgraded RAM from 32MB to 128MB
Added 4GB Compact Flash 'disk' for mass storage
13-Oct-2008
I found this unit on auction from seller "visionmarketing.123" on eBay and was the only bidder!
I am now the proud owner of a brand new i-opener!
The unit arrived in an outer box, containing the original carton which included all factory items.
13-Oct-2008
Since this is a brand new system, still with the protective plastic on the screen, I want to proceed cautiously. In fact, I'd like to get into the unit to first make a copy of it's Flash disk before even turning it on the first time. That way, I can always return the system to its initial factory-shipped state.
First thing, though, was resources:
- http://www.netpliance.com/ [DEAD! Redirects to internet prescription site] - http://www.evernex.com/iopener/ - http://www.geocities.com/iopener_hack/prefect/ - http://www.mischiefbox.com/iopener/ - http://www.linux-hacker.net/ - http://fatsquirrel.org/veghead/wot/iopener.html - http://fastolfe.net/2006/iopener/faq
As far as I can tell, by peering inside the memory door opening, looks like my BIOS chip is:
SST MPF 39SF020 90-4c-NH 0007146-B
Using some information found on linux-hacker.net forums, I tried to enter the BIOS setup, but was completely stymied. I must have one of the later units that included some anti-hacker 'features', such as disabling the BIOS setup entry keys.
14-Oct-2008
After spending much time going through the forums at linux-hacker.net, which prompted me to confirm the shipping date on my unit (2000/08/29) by looking at the shipping carton, I conclude that I have a 'V5' system. According to what I read, this is good, but does require a BIOS chip replacement, since there is no longer any way to enter the BIOS setup using some combination of key presses, regardless of whether one is using the i-opener's factory keybard, or a standard PC keyboard. So, looks like I'm kind of stuck until I sort through all of the details on that aspect. Maybe I'll just keep the system as is, sort of as a relic of the past.
Also, I discovered that the mounting bar on the back of the unit uses the 'security' style torx screws (with a center pin) and I don't have a bit the fits inside the screw hole. So, I'll have to work through that somehow, before I can get inside the unit, whether to replace the BIOS, or to just nose around.
18-Oct-2008
I finally dug out my set of jeweler's screwdrivers to try to remove the 'security' torx (T8) screws holding the screen to the stand. Many posters on various lists have indicated good success using these small screwdrivers. By placing the narrow blade between the central pin and two notches, it will grip well enough to allow removal of the screw. Indeed, this is exactly correct and I easily removed the screws. I hope to replace them, though, with normal screws. As yet, I don't know the exact size except to say that they are ISO screws in mm's. For the screw under the silver 'Do Not Remove' sticker, I simply cut a slit with a narrow knife blade and worked through the slit. The sticker still looks fine, hardly noticable. Once the stand was free I was able to open the case.
After removing the six screws around the perimiter, and the two hex nuts on the parallel port, I tried to pry the case apart, but it also has some locking tabs in the plastic around the perimeter. I used a thinner-than-usual credit card, sliding it along the seam between the two halves until the tabs popped loose. No damage and no ugly screwdriver scars. It worked very, very well.
Once inside, I removed the RF shield and the heatsink. Here's what I found:
- Rise MP6 PR266 CPU (2.8V core, 3.3v I/O) - Analog Devices AD1881 audio chip - Trident CyberBlade i7 graphics chip - various date stickers showing 07/dd/2000
So, based on this, I can confirm that I really do have a 'V5' i-opener. That means several things. I can't use the original V1 BIOS, since it doesn't support the Rise CPU, and when I install some other type of OS, I'll have to track down the AD1881 audio drivers, since those are not in the Windows CD driver set.
First, though, I needed to get the modded BIOS that will allow me to enter the CMOS setup functions, and I caved in and ordered the V54a BIOS from badflash.com. While I was at it, I also ordered an IDE drive cable for just few dollars more.
Only after I had ordered the replacement BIOS chip from badflash.com did I at last run across an online download of the same. I could have just reprogrammed my old BIOS chip and saved some money! Well, that's the way it goes.
18-Oct-2008
I spent a little time with the i-opener's keyboard on a standard PC to try to determine what keys are mapped to what. Most keys are the usual, but the i-opener keyboard has many keys (particularly the function keys) inscribed with other functions:
i-opener standard -------- -------- [blank key] [Windows context menu] Pizza [Windows START] Prev Ch [INSERT] Next Ch [END] Help [HOME]Back <- F1 Forward -> F2 Web Guide F3 Shop F4
Address Book F5 Mail F6 Weather F7 News F8
Chat F9 Print F10 Hang Up F11 (?) Home F12 (?)
In addition to the lack of a numeric keypad, several keys are missing on the i-opener:
[ESC] [SCROLL] [NUM LOCK] [SYS REQ]
Note: I can generate ESC ASCII code with CTRL-[
The only reason that I mark F11 and F12 with (?) is that the old DOS application that I used to test the keyboard didn't respond to those key presses, but neither does it do so with a regular PC keybaord. So, I think these two keys map to F11 and F12, but I'll have to really test it with an application that uses those keys.
The bottom line, then, is that I think one could get away with using the i-opener keyboard, if the ESC key isn't needed, or the ESC keycode can be remapped to another key. In Linux or *BSD this shouldn't be hard to do, but with DOS and Windows, it might be hard to get away with since many applications were written to use the scancodes directly, not the resulting ASCII codes. But, maybe there are drivers that allow this. Some other users apparently just use a standard keyboard to avoid all of this. More research to do.
27-Oct-2008
Today I received a new BIOS and hard disk cable from Jack Rowland at badflash.com. I had already pulled the original BIOS so I just popped the new one in and fired up. I now see the normal boot up sequence and can press 'DEL' to enter the CMOS Setup. Looks good.
The old type '2032' CMOS battery was dead so I replaced it, but I used a '2012' instead, which I had on hand. It's thinner, but the same circumference, and should work, just won't last as long.
27-Oct-2008
With the new BIOS, using the auto-detect function, I set the hard disk parameters for the SanDisk Disk-on-Board. I did, however, *not* select the LBA option, rather I went for the NORMAL option, with C:490, H:2, S:32. With this setting, I attached my old Quantum Daytona AT256 laptop disk drive that already hat Debian 3.0 "Woody" installed, and connected it using the cable from Jack Rowland. I connected the end with the double connector to the motherboard, using the inner rows of holes that automagically reverse the pins, and then connected the drive to the normal end of the cable.
I powered the system, and let it boot from the hard disk, which it did without any difficulty. That done, I imaged the SanDisk flash disk with:
# dd if=/dev/hdb of=/i-opener_SanDisk.dsk bs=512 31360+0 records in 31360+0 records out #
I moved the disk back to a normal machine (Insync 486) and copied the disk image to Cthulhu for eventual burning to CD-ROM.
27-Oct-2008
With the disk image made, which relieves me from making a non-correctable mistake, I started fiddling with the system/CMOS configuration. All I really wanted to do was boot to the original disk image and see what happens, maybe figuring out how to reconfigure the ISP settings to dial out to my current ISP, sisna.com. Alas! I was never able to get the machine to boot to the SanDisk, even after setting the boot order to 'D,A,SCSI', which seems like it should work. Nope, nada. I fiddled with disk parameters, and the boot order until I had exhausted all the possibilities, still no go. Must be something to do with the disk image vs. the new BIOS. Ah well, I'll just go ahead and install a useful OS.
But first, just to be sure, I removed the new BIOS chip and re-installed the original. The system boots to the i-opener screen as it used to, so the problem definitely has something to do with the new BIOS chip. I pulled the original BIOS, again, and re-installed the new one.
27-Oct-2008
On a separate working machine, I snagged a copy of Jailbait from jailbait.sourceforge.net as Jailbait_Linux_v6_fullinstall.img.gz. It appears to be gzip'd, but it really isn't a gzip file. I just moved it to the laptop drive, and shutdown.
On the i-opener, I booted to the hard disk, and then copied the Jailbait image to the SanDisk with:
# dd if=Jailbait_Linux_v6_fullinstall.img of=/dev/hdb bs=512 31360+0 records in 31360+0 records out #
then rebooted. After setting the CMOS boot order to 'D,A,SCSI', I rebooted again. Jailbait came up! It asked a few initial setup questions and I was able to login. I figured out how to start the X-windows system with 'startx' and it comes up, but without a mouse, I'm sort of stuck. I shutdown and changed out the standard PC keyboard for the i-opener's own keyboard with the mouse disk and buttons. It works!
14-Nov-2008
Today, I received a couple of CompactFlash-to-IDE adapters with a 44-pin laptop-sized (2mm) connector, suitable for use on the end of the IDE cable I received from Jack at badflash.com. Using the adapter, I connected a 1GB CF card which already had a bootable DOS partition with Freesco 0.3.8 installed. I used that to test the connections, and all works just fine!
I'd like to get a larger CF card, in the 4GB to 8GB range, for my permanent mass storage device for this i-opener. I hope it will hold up for a while, and having a much bigger device than what I'll commonly use will allow the card's onboard load-leveler to do its job, and make the flash last longer. I'm planning to install both Windows 98, and Linux or NetBSD. This will allow me to use the i-opener as a basic workstation in my basement workspace, without having to worry about turning it off all the time. No fans, no spinning drives, should be good!
14-Nov-2008
With the CF mass storage in place, I netbooted NetBSD and installed v3.0 on the remaining portion of the CF 'drive'. All went smoothly, and NetBSD even knows about the 3Com Audrey's USB ethernet adapter that I borrowed for this testing, installing all the proper drivers and recognizing the device when I plug it in. Nice!
After getting the basic NetBSD setup going, I wanted to get the pkgsrc kit loaded somehow, but I already knew that it would take a very large amount of space, and it might be nice if I had a standard pkgsrc around so that I don't have to download it and wait hours for it to un-tar itself. So here's what I did:
I created a mount point directory on the i-opener, and mounted my disk from a Debian 3.0 "Woody" box ('cthulhu') that has lots of storage:
# mkdir /usr/pkgsrc # mount cthulhu:/home/jared/NetBSD-pkgsrc /usr/pkgsrc
With this configuration in place, I downloaded the 3.1 pkgsrc.tar.gz file and unpacked it into /usr/pkgsrc (on cthulhu). This way, now, I'll be able to allow any future installations of NetBSD/i386 use this without all the hassles of downloading.
To further simplify things, I created a small shell script that sets the environment variables for updating (with CVS) and using pkgsrc, called /usr/pkgsrc/pkgsrc-runprep. This expects to run under the /bin/sh shell, not the csh or ksh. I've notice that root logins to the main console device start /bin/sh, but if I login remotely as jared and then su to root, I'm still in the csh. Just something to be aware of.
I installed lynx and screen using pkgsrc:
# cd /usr/pkgsrc # ./pkgsrc-runprep # pkg_add lynx # pkg_add screen
In both cases, for lynx and screen, it alerted me to the fact that I would be installing v3.1 binaries on my v3.0 installation. I continued and they both work fine.
03-Dec-2008
After buying a 4GB Compact Flash card this past week I was ready to make some kind of solution for permanently mounting the CF card inside the i-opener. I wanted to preserve the original cosmetics and had no intention of hacking the case in any way. With the CF-to-IDE adapter, I shouln't have to. However...
I did have to make some mechanical changes inside the system. First, a corner of the CPU heatsink overlaps the IDE cable connector on the motherboard, and with the cable attached, the heatsink will not properly mount flush. So I removed a small corner of the heatsink with a hacksaw and deburred it with a file.
Also, I had hope that I could have access to the CF card from the memory access door on the rear panel. As it turned out, the badflash.com cable barely had enough reach to allow me to position the CF module on top of the SO-DIMM main memory module, but when I tried to replace the RF shield there was some interference from the turned up corners of the metal shild. I need room for the CF module to lay flush without pressure. So, I hacked a small section of the metal shield away around the memory access opening. I removed not just the turned-up portion, but a little bit extra. I hoped that this would allow the CF module to be shifted sideways slightly, allowing at least one side of the CF module to be lifted a bit. With these two changes, I reassembled the system.
Indeed, the extra cutout on the RF sheild allows me to orient the CF-to-IDE adapter module enough to get my fingers in far enough to grasp the CF card. I can just barely remove and replace the CF card. It works!
11-Dec-2008
I went to the local recycler (MAS Computers, now JPL Computers) and purchased a 128MB PC100 SO-DIMM module for $20 and replaced the factory 16MB module. The system has no trouble recognizing the larger module and it runs fine without any adjustments to the BIOS settings.
12-Dec-2008
While testing a SCSI drive on a P133 system (GlobalWIN) for possible use in my SGI Indigo2, I took the opportunity to install NetBSD 3.0 and use the kernel rebuilding procedure to exercise the drive.
I downloaded the sources and located the IOPENER configuration file that is already included in the NetBSD source tree. I made no changes, and just ran the build. No trouble. Turns out that the new kernel is about 2.6MB, which is quite a bit smaller than the default 8MB GENERIC kernel that I had installed already.
I copied the new kernel ('netbsd') over to the i-opener, renaming the old one ('netbsd.old') and rebooted. Came right up, no problems. Woohoo! It saves about 5MB of memory. With my new 128MB module, I don't really need the smaller kernel, but it's good to clean things up anyway.
13-Dec-2008
As an educational exercise, I continued to work with the NetBSD kernel configuration, seeing if I could make it even smaller and more usable. One usability issue has been awkward for me. The i-opener keyboard has no ESC key, and I've been using the CTRL-[ combination to get along, but it would be nice if the keyboard map would give me a single ESC key equivelent.
As it turns out, there is already an IOPENER configuration file in the source tree that remaps the top row of function keys to allow for an ESC key. Unfortunately, whoever set this up, chose to use the left-most function key, which is really F1, as the ESC key, and then use F2 as F1, and F3 as F3, and so on. That's even worse than my CTRL-[ using the standard keyboard map.
So, I snooped around and educated myself a bit. I found the reference to the keyboard mapping tables in the IOPENER config file, and then found the tables themselves in /usr/src/sys/dev/pckbport/wskbdmap_mfii.c itself. I added a new mapping called US_IOPENER_JB (to distinguish it from the already-present US_IOPENER map), where I only remap the blank key (which is really the Windows "MENU" key, scancode 221) to become the ESC key.
While I was in the new IOPENERJB config file, I also disabled the IPv6 and kernel debugger sections, and enabled the MSDOSFS file system support, thinking that I might want to read USB thumb drives at some point. I saved all of this work, and reran the config, the make depend, and the make.
Well, turns out that the make will fail! Obviously, there is yet another needed reference to my new US_IOPENER_JB definition, but I don't know what or where it is, so I just changed the old US_IOPENER definition. This builds now and comes in at just 2.4MB. It seems to run fine, with the blank "MENU" key serving as ESC while in text mode. In X Windows, the key seems to do whatever the application wants. For example, Opera uses it as a sort of shortcut to the normal File menu. Anyway, I'm happy and I'll just leave this kernel in place going forward.
09-Oct-2010
The kernels that I build nearly two years ago do not support USB thumb drives. Upon insertion, debug messages are produced that indicate that the umass (USB mass storage) support is not enabled for SCSI devices. Since thumb drives are treated as SCSI devices, I need to enable this.
Sadly, my kernel building box has been repurposed, so I was forced to re-learn how to build kernels and do all of the prep work of getting the sources onto this box. I'll do my own kernel building locally.
Using the instructions in chapters 30 and 32 found in "The NetBSD Guide" found at:
http://www.netbsd.org/docs/guide/en/index.htmlI gathered the source tarballs for v3.0 and unpacked the system source file:
% cd / % tar -xzvf /root/NetBSD_3.0_src/syssrc.tgz
This time around I want to try again to get add my own keyboard layout, rather than changing the included I-Opener keyboard layout.
I created a new configuration by coping the default IOPENER config file:
% cd /usr/src/arch/i368/conf % cp -p IOPENER IOPENER_JB % vi IOPENER_JB
and made these changes:
1) enabled 'scsibus*' option 2) added 'auvia*' audio device from GENERIC 3) disabled IOPENER keyboard layout 4) created line with new IOPENER_JB keyboard layout
Then I added a IOPENER_JB keyboard layout to the keyboard map source file just below the present 'iopener' definition:
% vi /usr/src/sys/dev/pckbport/wskbdmap_mfii.c
...(position and enter insert mode)...
static const keysym_t pckbd_keydesc_iopener_jb[] = {
/* pos command normal shifted */
KC(220), KS_Escape,
};
then I added this line to the '#ifndef WSKBD_USONLY' section:
KBD_MAP(KB_US | KB_IOPENER_JB, KB_US, pckbd_keydesc_iopener_jb),
Then I ran these commands to build the kenrnel:
% cd /usr/src/arch/i386/conf % config IOPENER_JB % cd ../compile/IOPENER_JB % make depend % make
Alas, I still haven't figured out how to properly add a new keyboard definition. The build went for some time, eventually erroring out with:
# compile IOPENER_JB/pckbd.o cc -ffreestanding -O2 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wno-sign-compare -fno-zero-initialized-in-bss -Di386 -I. -I../../../../arch -I../../../.. -nostdinc -DDIAGNOSTIC -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -I../../../../dist/ipf -c ../../../../dev/pckbport/pckbd.c ../../../../dev/pckbport/pckbd.c:161: error: `KB_IOPENER_JB' undeclared here (not in a function) ../../../../dev/pckbport/pckbd.c:161: error: initializer element is not constant ../../../../dev/pckbport/pckbd.c:161: error: (near initialization for `pckbd_keymapdata.layout') *** Error code 1Stop. make: stopped in /usr/src/sys/arch/i386/compile/IOPENER_JB
A little more snooping around shows that the trouble is with in /usr/src/sys/dev/wscons/wsksymdef.h which has a table of eight keyboard variations. Looks to me like there are only eight possible slots and they are all filled, so I'm going to just go back to changing the IOPENER definition in /usr/src/sys/dev/pckbport/wskbdmap_mfii.c like I did a couple of years ago. So be it.
I went back and fixed up everthing, using the modified IOPENER keyboard definition, along with my other configuration changes for VIA audio, SCSI mass storage support and MSDOS file system support.
I had to perform all three manual build commands:
% config IOPENER_JB (in conf dir) % make depend (in compile dir) % make (in compile dir)
The build was successful.
Drat! I still can't get the USB drive to work. The device seems to be recognized now, but still when I try to access it using /dev/sd0* it says the device is not configured. More to do.
10-Oct-2010
Well I figured out what to do. In addition to enabling the 'scsibus*' option, but I also need to enable the device name. I added this line immediately after the 'scsibus*' line:
and rebuilt the kernel. The system recognizes knows there's something at /dev/sd0 now, and I can fdisk it, but I con't mount!
19-Oct-2013
Removed the rear case, and released the electonic guts from the front bezel with four screws in order to re-engage the front panel's volume slider which I had not correctly engaged when I first hacked the system.
20-Oct-2013
Since the 'disk' is really just a Compact Flash card, it is a simple matter to swap the disk out for something else. Today, as a case in point, I removed the NetBSD 4GB CF and replaced it with a Windows98SE 1GB CF. This Windows98SE CF was previously used in one of my NeoWare i3000 units, so was already installed. All I had to do was allow the system to rediscover the different hardware subsystems and install drivers for them.
There were to subsystems that required extra drivers (other than those included on the Windows98SE distribution: Audio (PC'97 Asound Analog Devices AD1881) and Video (Trident Cyberblade-i7). After (much!) web searching I was able to locate and download appropriate drives. These I've saved on the CF and in my driver archive (\\Focalor\Keeper).
22-Oct-2013
Returning to the problem described in my October 2010 notes, at last it dawned on me that I would need to enable FAT (MSDOS) filesystem support in the kernel. Without that, it would explain why I was able to fdisk the device, but not mount it.
I rebuilt the kernel using the sources already in place, changing the configuration IOPENER_JB configuration, naming it IOPENER_JRB_2. I changed two things, 1) I enabled MSDOSFS support, and 2) I disabled INET6 support. The second I did just to minimize the 'junk' in the kernel. I don't use IPV6 facilities so I figured I'd take them out while I was rebuilding the kernel.
I followed the steps given in Chapter 32 of the NetBSD guide at:
http://www.netbsd.org/docs/guide/en/chap-kernel.html
doing basically these actions:
0- cd /usr/src/sys/arch/i386/conf 1- Edit config file (I copied my previous IOPENER_JB to IOPENER_JRB_2) 2- run 'config' 3- cd ../compile/IOPENER_JRB_2 4- run 'make depend' 5- run 'make' 6- copy resulting 'netbsd' to /netbsd_io_jrb_2 7- create soft link: ln -s netbsd_io_jrb_2 netbsd 8- reboot
It works!
09-Apr-2016
The sorry -- and thin! -- CR2012 that I installed back in 2008 has given up the ghost. I used a 2012 at the time because that was all I had on hand, but today I installed the correct replacement, a fresh CR2032. To do so I had to:
1. Remove the stand - Remove the four torx 'security' screws attaching the stand to the back of the unit. This was done with a small jeweller's screwdriver. The blade would just fit between the center pin and two side-notches giving the grip needed to rotate.
2. Remove the rear plastic cover - Remove six screws on the back of the unit, four across the top edge, and one in each of the lower corners. I used a thinner the usual credit card slippep into the seam of the front and back covers to release each of the four sides.
3. Remove the metal shield - Remove eight screws around the perimeter, four on the top edge, one on each side, two on the bottom edge. Then remove a ninth screw that penetrates the PCB at the lower-left quadrant, remove a tenth short screw next to the power socket. Then remove the five screws inside the brass barrels on the interior of the shield.
4. Remove the heat sink (only this time) - Remove the four screws holding the CPU heat sink to allow access to the RTC battery. Since I don't want to remove this heat sink every time I need to change the battery, using a hacksaw I removed the corner of the heatsink covering the battery. Then I reinstalled the heatsink.
Now the battery was replaced by sliding the (+) tab to release the old battery, then I installed the new battery, reversing the process with the (+) tab, and reassembled the system.
Then I made a few adjustments to the CMOS/NVRAM configuration. Back in business!
Copyright © 2006-2025 Jared Blaser. All rights reserved.