As it turns out, I might get to use that setlogcons applet in IZ2S after all - on emulated zipit hardware. Somehow the light chatter on the zipit IRC channel recently turned to qemu. We dug up anarsoul's old post on it and he worked out a slightly different patch for the blob bootloader to allow it to run the stock kernel and a hacked version of the iz2jffs (with the wifi modules removed from the Zcovery startup script). Although nearly incapacitated by Thanksgiving turkey and stuffing sleepy syndrome (not to mention all the visiting relatives and pets) I did manage to find a few brief moments to tinker with this.
So far I've tweaked the qemu startup script to make use of all 3 zipit serial ports. After the boot messages display on the qemu console window, you can run a shell there by launching own-tty on the /dev/ttyS2 serial port to access the zipit from the host pc. I imagine setlogcons could be handy here if the kernel messages start to bother me. However the qemu launch scipt lets me access the other two zipit serial ports via telnet to ports 4000 and 4001 on the localhost. That should be all I need for an editor and compiler window for development. To access the other serial devices you have to create them first with mknod. It's all laid out here.
I tried a few things to test the serial telnet windows. Emacs, ttyclock, and text mode Links ran ok, so ncurses and the vt100 emulation is good. I also launched the graphics mode Links from the serial telnet and flipped through the vttys to make sure it was running along with gmenu2x. All looks good so far for development and testing on a virtual zipit. I'm planning to tinker some more with the jffs startup scripts to automatically create the serial devices on bootup. It's actually rather tricky to do it in the emulator window because it faithfully emulates the odd zipit keyboard layout.
You can see the extra shells running on the qemu zipit in this screenshot.
a small qemu patch to allow the zipit to run the kernel directly from qemu (without blob) and have it run in qemu with much more than zipit's paltry 32MB of RAM. I haven't tried this yet, but it might be handy for compiling. However, at this point the IRC discussion turned to qemu-user mode for a faster, bigger, better IZ2S development platform and tychoreg was off and running. He's already working on some serious miracles. At his current pace he should have some truly wonderous stuff by xmas. I can't wait.
I made some scripts to mount and unmount the jffs image in a loop so I could examine and modify it on my linux laptop. It all seemed to work, but when I ran it in qemu I discovered the laptop was using LZO compression whereas the zipit kernel only supports zlib compression for the jffs. Now, according to the internet there are some patches that allow you to specify "compr=zlib" in the mount command, but it's not available on my laptop. Darn it!
If I want to tinker with the jffs I'll probably have to modify it on a real zipit, dump it to the SD card with dd, and then transfer it the the laptop via sneakernet or scp. That's a whole lot more work, unless I figure out how to dump it from the fake zipit running in qemu directly to the laptop running the qemu session. I suppose it might be feasible to dump the jffs mtdblock to /tmp and then transfer it via zmodem, but alas, there's no zmodem on the jffs. Time to read some more of the qemu manual and see if there's a simple file transfer option that I might have missed...
Looks like I was wrong. The jffs zlib mount option does seem to work on my laptop. I just forgot the -o in "-o compr=zlib" to set it up. So now I can boot with qemu into a jffs with 3 shells immediately available, one on the qemu console window, and two more via telnet to localhost at ports 4000 and 4001. It's totally insecure, but could be really handy for rapid compile and test sessions. Now I just need to get an SD card image working in qemu so I have access to the compiler.
At first I followed some really crazy looking instructions for making an SD image for qemu. I don't know what that stuff is for - maybe if you need to emulate it down to the spi layer? Who knows. Turns out it's much easier to simply dd a pile of zeros into a file, make a vfat filesystem on that, loop mount it, and unzip IZ2S to get a working SD image suitable for qemu. Actually, I also had to dig back in the IRC archives before I remembered to comment out the zipit lid check in the z2start.sh script. I also added the serial tty setup from the jffs startup script. And now I can boot qemu into either the jffs or sd version of IZ2S.
I'll post all of the new qemu scripts real soon now...