Whoops... this page is a big topsy-turvy mess: the old stuff is at the bottom and the new stuff is at the top! I'll attempt to clean it up, if I can find an editor that I can use (my vi knowledge is not sufficient to allow me to use it confidently).
This was getting serious: without a bootable system, my Tosa is just a pretty lump of silver/black plastic. Having recently tidied-up the approx. 11GB of stuff in the 'Zaurus' project directory, I looked through it for a usable SL-6000 system. Eventually I found a collection of 2.4 kernels for the Sharp ROM - and when I say 'ROM', I mean 'system', really. Alas, no Angstrom kernels were there, although I found a few backups of the filesystem.
All of my attempts at getting the Sharp system to boot failed with 'No bootable system found', or similar error. After much hair-pulling (fortunately, I have a lot of hair to pull) I found that kexecboot only searches ext2-format partitions and doesn't examine VFAT/MSDOS systems. I'm sure that this is different on other machines - how come I didn't notice it before? Strange..
I was happy when the Tosa finally booted a Sharp kernel. I'd formatted an SD card with two Linux partitions - both ext2-format. For modern Linux distros, you have to be careful to insure that a compatible filesystem is written. Using fdisk, partition the SD card - or possibly a CF card - and add a Linux partition (type 83). Format the card with:
mkfs.ext2 -b 1024 -I 128 -L [device]Replace [device] with the device that your SD card is on. BE CAREFUL HERE as it's easy to accidentally reformat your hard drive if you don't pay attention.
I'm going to skip a bit of the in-between steps here and assume that you know how to mount the SD card partition and copy files to it. You need to copy zImage and boot.cfg for kexecboot to recognise the system. boot.cfg might not be required as by default, kexecboot looks for the files /boot/zImage and /boot/cmdline and usually doesn't care about anything else - but boot.cfg is useful to set a name for the system and optionally, specify other bootable systems at the same time (otherwise, there can only be one).
Getting a bootable Angstrom system on the Tosa is an ongoing project, and as I type this, my machines are churning out packages like eggs from a chicken coop. I had a few issues - errors - initially, and I considered stopping the whole thing and trying an older distro - e.g. something on Handhelds.org (long-gone, so you'll have to try The Internet Wayback Machine). Fortunately, I stuck at it and was able to sort the problems. The first place to go is angstrom-manifest on github and follow the instructions there. Initially, you download the repo tool and that downloads the source code and - using bitbake - you choose a machine to build for. When it works, this seems to be a magical system that not only builds the house - if you think of a distro as being a house - but also makes the tools that build the house and in some cases, can make a bunch of different houses, one after the other. The drawback is that you need a lot of disk space, a lot of RAM and patience, in case bitbake aborts with the dreaded error message.
It is normal for bitbake to issue a number of yellow WARNING lines while it does its thing; these are often about a recipe that uses an outdated function or an instance of source code not being where it should be. You may need to edit a recipe ('.bb' file) or - in my case - edit a config file. I wrote a lot of blurb about this, although it's from my MOO and has a lot of muttering. You are welcome to read it and I hope that it helps. The MOO sets a line length of 80 and wraps text - it may look weird on your web browser. I've edited it to remove a few of these line breaks. Idoru and Winter are two machines on my subnet.
08-Sep-18: there is a full guide on the angstrom-manifest github site, but it's a bit technical. The following steps worked for me, but might not for you. I found that for some reason, different machines produced different results. For example, one machine seemed to constantly abort the build, whereas another machine completed it with few warnings. This may be due to the machine's software differing by version. The machine that was most-successful was the oldest, paradoxically - my dual-core Athlon X2 machine (idoru) was far better at building than my four-core Xeon machine (winter), with its 8GB RAM and bigger hard drive. Both machines are running Debian Linux: Idoru is running Debian 8.11 and Winter is running the newer 9.5.
In the following instructions, my comments are in italic script and everything that I type is in bold script.
First, choose a location to build the packages. You need at least 10GB of free space, and this varies, depending on how many packages you are going to build.
Make a 'bin' dir for the 'repo' tool.
Download the 'repo' utility and make it executable.
The instructions at angstrom-manifest say that you may need to edit 'repo' to explicitly use 'python2', since the default python interpreter can be 'python3' for newer machines. Do python --version to see the version number. If it is greater than 2, you'll need to do the following edit:
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > repo
chmod a+x repo
sed -i "s%/usr/bin/env python$%/usr/bin/env python2%" repoand - as it says - you might have to do this every time 'repo' is updated. Please continue by following the instructions on the angstrom-manifest page. When you do '. ./setup-environment', a dialog-based UI should appear, where you can choose machines to build for. If it does not appear, try installing the dialog package and ncurses-dev packages.
To be continued...
28-Nov-13: With nothing having happened - with my Tosa - for almost three years, I'm looking to do something with it. Its internal battery has died and in addition, its main battery has 'ballooned' in size, so it now looks rather 'bulgy'. Replacing the internal battery is a priority, but I don't want to break it. Better be careful. I received an email from someone interested in running Angstrom on theirs, and this has re-kindled my interest. Having said that, I am prone to ADHD, so it (the interest) may be extinguished again.
29-Jan-11: The kexecboot project has released a few new kernels, with a new UI. I'm currently running Kexecboot again, and I didn't stick with Guylhem for very long. I don't remember what my problem with it was, but I'm so fickle that I change distros every few weeks anyway.
With the new UI, the selected item is the light bar, not the dark one.
On the Tosa, the cursor keys are rotated, so the right-cursor is the 'up' key
and the left-cursor is the 'down' key. Press the OK key to select.
08-Nov-10: The Guylhem ROM is so much better than the buggy old Sharp ROM, and I really recommend it. I got my version from zaurus.org.uk, in the download/6000/guylhem/ area. Hi folks, and thanks for keeping the Zaurus scene alive!
31-Jul-10: I've replaced my Tosa's standard Opera web browser with the IBM-developed 'multimodal' Opera 7.30, which features speech synthesis and recognition. The quality of the speech is simply amazing, and the speech recognition is fast and accurate. See this MobileTechReview page for more information. You can get the multimodal package from IBM's FTP site (the IPK package is multimodal_arm.ipk (local copy: MD5SUM = 60b75b3169c43430b5950380a6e7f91a) and should work on the SL-C860 and SL-6000, and maybe others). Here's an MP3 (MD5 = fd953cda37fe2f5266a6d3dbce492efb) featuring me testing the speech recognition demonstration - be prepared for waffling, if you choose to download that.
27-Jul-10: Corrected an error regarding the name of the Japanese developer known as 'Tetsu' (I got his name wrong - embarrassed, am I! 'Tetsu' is his handle/nickname).
A few questions - and answers - about the above pictures:
Q. Why have I covered my Aurora clock in clingfilm?
A: It gets dusty in the kitchen, and the clock is made of a sort of tactile rubber that gets dirty very easily. The clingfilm is my attempt at fending off the dust.
Q: What is that unsightly blobby thing in the middle of that cable?
A: That's my Zaurus serial cable level convertor; it includes a small 'bird's nest' of components to invert the 3.3V of a standard RS232 level convertor (MAX3232). I'd run out of my favourite type of PVC insulating tape when I made it, so I used Sellotape.
Q: What's written on that bit of paper, under the Tosa?
# CONFIG_SHARPSL_BOOTLDR_PARAMS is not set
CONFIG_CMDLINE="console=ttyS0,115200n81 root=/dev/mtdblock2 mtdparts=sharpsl-nand:7168k@0k(smf),28672k@7168k(root),-(home) jffs2_orphaned_inodes=delete EQUIPMENT=2"
: # CONFIG_SHARPSL_BOOTLDR_PARAMS is not set
CONFIG_CMDLINE="console=ttyS0 root=/dev/mtdblock2 mtdparts=sharpsl-nand:7168k@0k(smf),54272k@7168k(root),-(home) jffs2_orphaned_inodes=delete LOGO=1 LAUNCH=q"
If you want to read the older stuff - which doesn't mention the Sharp kernel much - please scroll down to the next section (starting 'Useful links'), as I add new stuff from the top of the page.
Update (24th July 2010): I have changed the floating-point emulator from the default NWFPE (slow!) to FASTFPE (a lot faster, but possibly more imprecise). The Sharp system is noticeably faster now, with less 'bounces' on the touchscreen input, and a faster boot time. The bad news is that somewhere along the way, I managed to break Opera, and it no longer starts.
Step 1: if the standard Sharp system is not installed, install it such that it is the only bootable system: wipe the flash or restore from ROM backup - whatever is necessary to get a system with just the good ol' Sharp distro installed. This is important because the flash layout is so weird, with symlinks all over the place. Don't ask me why Sharp did it this way - I'm sure that it makes perfect sense, but I am not able to find or understand the Japanese-language references to this information. Google Translate does a very good job of this, though, and it was so much more difficult before it was available. Not to plug Google too much, but Google Chrome has on-the-fly translation, and this was invaluable to understanding the pages of Tetsu and the Sharp Corporation.
Step 2: Install the Angstrom kexecboot kernel. You'll need a CF or SD card formatted with FAT16 (partition ID type = 6). From the Angstrom kexecboot project site, download an install kit package, unpack it and install the files to the card, such that you have the following files present:
updater.sh zImageTo access the update menu, you need to reset the SL-6000 with the 'OK' button pressed; you can do this by pressing/holding OK and clicking the button inside the reset hole on the back of the unit, though I found that a bit difficult and I just chose 'Reboot' in the Sharp system and kept my finger on the 'OK' button until the menu appeared. Ensure that the AC adaptor is plugged in, or the next bit won't work. Choose the 'Update' option (4, I think) and then 'CF' or 'SD', depending on which type of media your files are on. I always put my files on a Compact Flash card, so I chose 'CF'.
After a few more prompts, the Tosa will reboot, load the Sharp kernel and perform a very fast installation process: just the kernel is replaced - the filesystem is left as it is. This is very important because if it were modified, it would be impossible to boot the Sharp system again.
Step 3: Prepare a card to boot Angstrom, and to hold the small boot partition for the Sharp system. You'll need a standard SD (not SDHC!) or CF card, formatted with one or more ext2 partitions; ext3 may work, but I am not sure whether kexecboot will 'see' ext3 partitions, so I just used ext2. I repartitioned a 2GB Kingston SD card into an approx. 1900MB partition for the main Angstrom system, with the rest as a small boot partition for the Sharp system (continues below at 'On my Angstrom SD card...').
http://tetsu.homelinux.org/zaurus/kernel/ Tetsu's replacement kernels http://repair4pda.org/disassembly_sharp.html Repair4PDA's pages - useful for seeing what's inside the SL-6000. http://www.linux-wlan.com/linux-wlan/ Linux-wlan-ng
Sharp's pageshttp://support.ezaurus.com/developer/source/source_dl_6000.asp SL-6000 source code download (main page) http://support.ezaurus.com/developer/source/6000/20040311/linux-sl6000-20040311-rom1_11.tar.bz2 SL-6000 (ROM version 1.11 JP) of the Linux kernel source code. http://support.ezaurus.com/developer/source/6000/20040311/linux-2.4.18-rmk7-pxa3-embedix-sl6000-20040311-rom1_11.bz2 SL-6000 kernel patch http://support.ezaurus.com/developer/source/6000/20040311/rootfs-sl6000-20040311.tar.bz2 SL-6000 root filesystem, without QTopia
MD5SUM Filename/download link bbf6b9fc9cf4f2707ec7eb24d25d9f81 config.240710-fastfpe kernel config (browser-readable link) 75530c2c1bca741bc39dff8e93d0221c modules.tar.gz Please note: I did not use these modules. 38d07d9b575bb8df06fe19cb5fa8d3ab System.map.240710-fastfpe System.map (browser-readable link) 742c67519c0300a8406b47dd4d5ae9bb zImage.240710-fastfpe Older files: e0c5d8f74ece7ae7ae47c865a74467e3 config 412c1dbfc33381246082d8fcfb3c11e5 Makefile b9d9486fd830a729c318f27fbaedae87 modules.tar.gz bb9a4db71f6ac5ea0a20b6ed4e207ddf System.map 1be917a8de759dc8daffeb5d2f3f34e4 zImage (kernel) 9f658097ef8aa92959f9d01deaf747a6 Angstrom /boot/boot.cfgIf you would prefer to read the ASCII files online instead of downloading them, I have added symlinks to persuade my webserver to declare these as text, not binary (the default):
configOn my Angstrom SD card (2GB Kingston), I made a small (50MB) ext2 partition and placed the following files in it:
boot/boot.cfg The elusive Angstrom boot.cfg.After a sync, I umounted the card partition and rebooted. The kexecboot loader showed a new 'Sharp' kernel and under that, my original Angstrom system.
boot/zImage The kernel.
boot/config The config, listed above.
This SL6000 kernel should be the same as the standard 'tosa-j' def-config, but with the additional 'EQUIPMENT=2' cmdline parameter (present on the original Sharp system), and 'PXA USB function support' (CONFIG_PXA_USB) enabled, as well as 'PXA USB network link function' (CONFIG_PXA_USB_NETLINK) and 'PXA USB character device emulation' (CONFIG_PXA_USB_CHAR). One or more of these choices was the key to getting the internal WLAN device (prism2_usb, using an ancient linux-wlan-ng distribution) working. I was able to compile version 0.2.0 of the wlan-ng tools, but have not included it here because I am trying to cause minimal changes to the installed Sharp system. For the same reason, I did not install the compiled kernel modules ('modules.tar.gz' in the above list) to the Sharp system, but left the modules from the original kernel intact.
If everything goes smoothly, the kernel should boot with a Sharp 'Please wait' screen, no warning messages and the QTopia countdown. After some moments, the screen will clear and you will be asked to wait a further 30 seconds. There will be a boot chime sequence and the time and date screen will appear. When you get to the main screen, the WLAN icon ('globe' with an X through it) should be at the bottom, showing that the WLAN device is available.
24-Jul-10: My second kernel was to have serial console support, as well as FASTFPE. FASTFPE is enabled, but I cannot get the serial console working - try as I might, it just can't open the serial device. I'm doing 'console=ttyS0,115200n8'. (26-Jul-10): Success! It worked when I specified 'console=ttyS0', and symlinked /dev/console to /dev/ttyS0. The rate was 9600bps.
It is probably worth me stressing that I did not install the kernel modules, but left the modules from the previous Sharp kernel intact. I wanted to disturb the Sharp system as little as possible so after restoring from the ROM backup, I installed the kexecboot loader (2.6.2x - the others didn't work) and I configured a small partition to boot my new kernel.
The standard 'tosa-j' def-config didn't work as is, because PXA USB is disabled and reading from the Sharp commandline partition is enabled, while it also has a minimal built-in commandline. Due to the standard Sharp kernel defaulting to reading from the cmdline partition - and ignoring any args passed to it by kexecboot - I have needed to override this behaviour in the kernel. This means that any supplied command line is ignored and to change it, you need to recompile - annoying, I know.
In addition, there are IRQ problems on some kernels. The 2.6 Tosa kernels are not yet stable, but you will probably find one kernel that works 'mostly okay' for you. I found that 2.6.29 was stable, apart from the IRQ timeout issue:
i2c-adapter i2c-0: i2c_pxa: timeout waiting for bus free i2c-adapter i2c-0: i2c_pxa: timeout waiting for bus free i2c-adapter i2c-0: i2c_pxa: timeout waiting for bus free i2c-adapter i2c-0: i2c_pxa: timeout waiting for bus free i2c-adapter i2c-0: i2c_pxa: timeout waiting for bus free i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: 0 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000004
dd if=/dev/mtdblock3 of=/mnt/card/sharp-kernel.img bs=1M count=1The Collie's /proc/mtd shows this:
dev: size erasesize name mtd0: 00020000 00020000 "Angel Monitor" mtd1: 00020000 00020000 "CF Updater" mtd2: 00080000 00020000 "Diagnostics" mtd3: 00100000 00020000 "kernel" mtd4: 00e20000 00020000 "jffs2" mtd5: 00020000 00020000 "angel stuff"... while on my Tosa's current 2.6 kernel, /proc/mtd shows these partitions:
root@tosa:~# cat /proc/mtd dev: size erasesize name mtd0: 006a0000 00800000 "Boot PROM Filesystem" mtd1: 00700000 00004000 "smf" # Maintenance menu, Angel boot monitor mtd2: 01c00000 00004000 "root" # Root of filesystem (JFFS2) mtd3: 01d00000 00004000 "home" # /home (JFFS2)The total NAND size should be 64MB (8MB ROM (NOR?), 64MB NAND, 64MB DRAM). .. but it isn't. Why? Maybe because I can't count.
Sizes, in decimal: mtd0: 6946816 bytes mtd1: 7340032 bytes mtd2: 29360128 bytes mtd3: 30408704 bytesmtd0 should definitely not be touched, since it contains the menus and boot monitor. If I do a string search of /dev/mtdblock1 with hexedit, I find two instances of the string 'Uncompressing Linux' at 0xAAE84 and 0x67F463.
Copy updater.sh and zImage to a FAT16-formatted (partition ID = 6) SD or CF card and reboot the Zaurus, keeping your finger on the 'OK' button. Make sure that the AC adaptor is plugged in, or the flashing process will not start. Choose 'Update from CF' and press the 'OK' button. The Zaurus will reboot, start the Sharp kernel update process, will write the small kexecboot kernel/initramfs and request that you reset the unit.
Some tutorials advise you to remove the battery to do a complete hard reset, before flashing. If you do this, remove the battery and leave it out for at least ten minutes, so the internal battery runs down.
After the kexecboot install, the Zaurus will power up and there will be delay of a few seconds before the menu appears. You can breathe a sigh of relief because no more flashing need occur to the Tosa, and everything will now be booted from CF or SD cards. Any bootable card systems will be shown upon bootup, which brings me to this bit:
This is the output of 'fdisk -l' on the Tosa's fdisk app, for a 2GB Kingston SD card:
root@tosa:/var/volatile/tmp# fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 2002 MB, 2002255872 bytes 4 heads, 16 sectors/track, 61104 cylinders Units = cylinders of 64 * 512 = 32768 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 33 1632 51200 6 FAT16 Partition 1 does not end on cylinder boundary /dev/mmcblk0p2 1633 61104 1903104 83 Linux Partition 2 does not end on cylinder boundaryThe 'cylinder boundary' warnings may be due to me disabling 'DOS mode' when formatting the partitions in Ubuntu. I do not know whether this will have any lasting effect.
Caution: be careful to remove all filesystem features when formatting the card partition, as my default system has a lot of incompatible options. In this example, /dev/sdc is the device that has been allocated to my card reader/writer; you will need to substitute a different device.
mkfs.vfat /dev/sdc1 mke2fs -j -O none -T small /dev/sdc2
The next step is to use Angstrom's Narcissus tool to generate a system to put on the card. Go to the Narcissus page, make your choice of options and click the 'Build me!' button.
This last one shows the huge amount of tabs that I usually have open:
The image type will default to '.tbz2' (bz2'd .tar), which is fine. Unpack this onto the card, as root (the tarball will unpack to the current directory).
cd /media/sd_card sudo tar xjf ~/tosa-170610-1.tar.bz2 syncThe card is almost ready to boot, but it needs a minor edit to mount the root filesystem read-write. Change dir to the card 'boot' dir and add a boot.cfg file, as shown below. Please perform the following operations as root.
cd /media/sd_card/boot mv kernel-cmdline kernel-cmdline.old ln -sf zImage-2.6.29 zImage cat >boot.cfg <<EOF # # kexecboot configuration file # Copyright (c) 2009 Yuri Bushmelev # Copyright (c) 2009 Omegamoon # # Show this label in kexecboot menu. LABEL=Angstrom # Specify full path to the kernel. KERNEL=/boot/zImage-2.6.29 # Append this tags to the kernel cmdline. APPEND=rw console=ttyS0,115200n8 debug # Specify full path to the custom icon # that will be shown in kexecboot menu. # [This is a 256-colour 32x32 image] #ICON=/boot/my-own-icon.xpm # Priority of item in kexecboot menu. # Items with highest priority will be shown at top of menu. # Default: 0 (lowest, ordered by device ordering) #PRIORITY=10 EOFDo a 'sync' (you can never do too many, in my opinion) and unmount the card. Try it in the Tosa and it should now boot, pause a bit, start its X server and prompt you to calibrate the screen, before showing an unreadable setup screen with all characters looking like little square blocks. I guessed that it is prompting for, in order from the top of the screen: root password, non-root username, non-root username password & password verification. Reinstalling gpe-dm fixed the font issue for me.
After all of this negativity, some positive news: thanks to the increase in storage space afforded by the 2GB SD, I've installed lots of software, including a full C/C++/X11 SDK, Perl, a web browser, media player (not much use without sound, I admit), tons of gpe applets (have a look at the package list), and the performance of the OS is very good, compared to the old 2.4 kernel.
To be continued...