Be sure to also check the FAQ at the main www.openpsion.org site. Also the old FAQS (archaic).
This HOWTO is written in SGML and processed to make the html pages. The processing in docbook automatically makes the page names (and all the links between them), which change as the document evolves. So linking to a page like: http://linux-7110.sourceforge.net/howtos/netbook_new/x196.htm will not generally work, since x196.htm may not be there next time, or perhaps worse will be a link to an old, perhaps erroneous, page. Set your bookmarks to http://linux-7110.sourceforge.net/howtos/netbook_new/index.htm and hit "refresh" frequently and you'll be o.k.
The all-important pipe character, "|", is <Ctrl><t>.
Large compactflash and microdrive drives are becoming more affordable all the time. There does not seem to be any size limit inherent in the netbook's hardware (and certainly not in the linux kernel). Disks of size 4 GB have been verified to work fine.
In terms of how these drives behave or interact with the linux kernel (or EPOC kernel) there is no difference. They are just IDE disks. Compactflash disks have a limited number of writes that they can make, although they are intelligent about how they write data. It would take extensive, repeated disk writes to come close to wearing out a compactflash drive. Microdrives have mini platters in them and don't have any writing limitations. Microdrives may be more suitable for using swap space than compactflash cards. However, microdrives are a mechanical drive, and hence will draw more power than compactflash cards - your netbook will run out of battery power a little sooner (how much sooner? dunno.) Microdrives make a very slight, barely noticeable, whirring sound, while compactflash cards are silent solid state devices..
The relative speeds of compactflash and microdrives is unknown, but likely to be highly variable depending on brand of compactflash and microdrive. Speed is largely irrelevant for the netbook at the moment because of the crude ("polling") PCMCIA support - everything is slow.
A system of generating OS.img files, similar to those from psion, has been put together; it is called bookboot. This will allow a kernel image and initrd.gz file to be stored in this file, to be directly loaded by the netBook's bootloader. This procedure works just fine; see the section on bookboot in this HOWTO.
Alternatively, you can define a plain text file called D:\System\Data\wsini.ini containing the following lines (modified from the default Z:\SYSTEM\DATA\WSINI.INI):
BASERGB 255,255,255 PALETTE 0,85,150,255 AUTOCLEAR 1 SHELLCMD \System\Apps\Shell\Shell.APP STARTUP D:\ARLO\ARLOSH.EXE WINDOWMODE COLOR256 SCR_WIDTH1 640 SCR_HEIGHT1 480 SCR_WIDTH2 480 SCR_HEIGHT2 640This will cause EPOC to startup ARLOSH.EXE at boot up first, giving the option of continuing to boot up EPOC or boot to linux. [This looks very much like the LILO prompt.]
My backup approach is to copy the contents of the entire C:\ drive, including the System directory, to a subdirectory on the compactfash D:\ drive before booting linux (select everything, then ^C to copy, ^V to paste). To restore the system on reboot, I first delete the entire contents of the C:\ drive (including the System directory - C:\ is completely empty; select everything, then ^D to delete), then copy the original contents of C:\ saved on compactflash back to the empty C:\ drive (^C to copy, ^V to paste). This has worked quite well for some time. The copy-paste between C: and D: drives puts things back exactly as they were, and doesn't take but a few minutes. The annoyances are that one has to stop (^E) all the applications that start at reboot (or you can't delete everything) and reset all the time, home city, sound, show hidden system directory, etc. preferences. I've started using Sysback recently which helped some. (And from time-to-time I'll burn a CD of all the EPOC contents!)
An honest serial mouse appears to work o.k. on the netBook's onboard serial port. See the section in this HOWTO on using a mouse. There was one report, perhaps using an older series 5 or 5MX, that the mouse would work for a while, but then the serial port was burned out. I had the following reply from the XTM people:
One thing we tried, and you must NOT try, was plugging a serial mouse into the RS232 port. Since the serial mouse draws power from the RS232 port, it pulls a LOT of current from the plug, and we burned out the serial port on a Psion [a series 5 or 5MX] playing with it... :-( The good news is, it actually worked, right up to the bit where it burned out!
This naturally raises the issue of whether this would work o.k. on a netBook, or one could use a mouse that draws less current, or that perhaps is powered by some external power source. I have used a Logitech serial mouse without apparent harm (so far...). However, trying out a mouse on the netBook may be risky. For more information on power and serial ports, see: www.hut.fi/Misc/Electronics/circuits/rspower.html
This is the specification for a standard (as supplied by Psion) serial cable, including the equivalent 25-pin D pinout in case you want that instead/as well. This has RX/TX and RTS/CTS 'swapped' as both devices expect to be 'in charge'. This is what's called a 'null modem' cable. Note that DTR and DSR seem to be straightthrough, but my working null modem adapter swaps these, in addition to swapping RX/TX and RTS/CTS. The pin assignments and wire colors have been verified by me, my multimeter, and a sacraficial Psion cable [which I made into a non-null-modem cable]. Whether there is or isn't a DCD signal out of the Psion itself (e.g., pin 15 is the likely candidate), I couldn't say, but there is not even a wire in the Psion cable for the DCD signal. The Psion connector type seems to be the same as that on a somewhat standard 15-Pin PCMCIA Modem Cable Dongle, although the two cables are "keyed" differently (the plastic notches don't match).
With the Psion's cable pins defined as: And the 9-pin D pins definedSee also: www.lammertbies.nl/comm/cable/RS-232.html for general information on serial pins.
Kernels that work on a netBook will work on a Malaysian netBook. They appear to have identical hardware to the netBook, but have some small software changes to their OS.img loader which is irrelevant for our purposes. I don't think we are faced with the problem of myriad hardware configurations, which would be a problem for kernel development.
Series 7 kernels work for the netBook. The hardware is essentially the same, except for the memory and perhaps the power supplied to PCMCIA. We've had no one report what happens when a netBook kernel (e.g., configured for 64 MB of RAM) is booted on a Series 7 (with 16 MB of RAM).
Kernels are now available that will recognize either 32 or 64 MB of RAM. If you have upgraded your netBook to have 64 MB of RAM, a linux kernel is available that will recognize this. If a Series 7 kernel is used, then only 16 MB of memory is available. At present, separate kernels are required to recognize these various memory configurations; please get the kernel appropriate to your netBook (the effect of a 64MB kernel on a 32MB netBook is unknown, and you probably don't want to find out).
Unfortunately, it appears that the netBook or kernel ramdisk has problems - attempting to transfer large amounts of data (10-15 MB) to the netBook (to a separate ramdisk, say) will gradually consume all the memory and cause the system to freeze up. I think this may be a bug in the ramdisk driver or netBook's memory patch. Using a ramfs or tmpfs (the preferred filesystem), rather than ramdisk, seems to work o.k.
There have never been any reports (www.psionplace.com/ search for X-ray - the discussion here is a paraphrase of the discussions there.) that netBook's sent through the carry-on security X-rays experience any problems because of it. I have sent my netBook through the X-rays many times. I'd never check any of my 'gadget' equipment in any case, because the threat of theft or damage outweighs everything else...
It is true, however, that bags checked at the airport go through very high intensity X-rays. Films and memory and CF are likely to be erased. One film cameraman told me that the Xray on checked luggages is 10 to 20 times more intense than on hand-carry items. He said that now all film cameramen have been advised to hand carry films and insist on visual inspection. The advisory came from the US authorities. I have two sticks of 512 Meg DRR ram which were placed in luggage. After travelling from Singapore to Boston via London, the rams were dead. Hand-carry laptops and PDAs were ok.
Technically, X-rays will hurt any type of electronic eqiupment, eventually. Chances are that nothing will happen, but every time you expose electronic equipment to radiation there is a small chance that electronics will be damaged, the more exposure the greater the chance of damage. People who work with all types of radiation in the medical field are required to change out many of the electronics (boards) at a regular interval because of damage due to exposure. However, there is a pretty significant difference between hardened application-specific equipment used in high-radiation environments (X-rays, gamma rays, etc.) with a specified change date to guarantee performance to standard and a PDA. The amount of radiation a PDA would be exposed to during an airport scan should not have any effect on the equipment. Even a frequent flyer need not worry.
In short, carry on your netBook?...O.K., but check your netBook?...NO!
Yes it is! See Rebuilding a netBook's Lithium-Ion Battery. Interestingly, you can rebuild it with batteries of a higher amp-hour rating (2200 mAh or larger) and get 12 or so hours of battery time.
These packages seem to be packed up in a few different ways. Within each package is a control.tar.gz tarball which describes the package and how it is to be configured and a data.tar.gz tarball which contains the actual binary and data files of the package. To unpack an ipk and get at the binaries (only the data.tar.gz file is needed for the binaries), try any of: "ar -x newpackage.ipk", or "tar xfz newpackage.ipk", or "tar xf newpackage.ipk". With the data.tar.gz file extracted, this can be installed with "tar xfz data.tar.gz -C /", where "-C /" extracts the file contents to the root directory. Sometimes only a single binary is needed, however, so a local unpacking will work fine, just "tar xfz data.tar.gz" and copy the binary file of interest to your favorite place. Manual unpack and installation of ipk files to a Debian system in this way frequently works without any problems (although there is no management of the installation).
You can do this a variety of ways, but perhaps the most straightforward is "ar -x packagename.deb". This will give two tarballs control.tar.gz and data.tar.gz. The first is the information dpkg needs to do a proper installation and configuration of the package, the second is contains the binaries and data files.