(Follow this link to go back to the main zaurus page, and this link to go back to the previous part.)
OpenBSD/zaurus: pocket-sized BSD
It was time to work on the real objective: the Zaurus port. Its early infancy can be seen in this teaser from Rahn on december 14th (still 2004):
<drahn> hi theo
<drahn> OpenBSD/pxaarm (zaurus) booting ...
<drahn> initarm: Configuring system ...
<drahn> physmemory: 16384 pages at 0xa0000000 -> 0xa3ffffff
<drahn> Allocating page tables
<drahn> freestart = 0xa0009000, free_pages = 503 (0x000001f7)
<drahn> IRQ stack: p0xa01d1000 v0xc01d1000
<drahn> ABT stack: p0xa01d0000 v0xc01d0000
<drahn> UND stack: p0xa01cf000 v0xc01cf000
<drahn> SVC stack: p0xa01cd000 v0xc01cd000
<drahn> Creating L1 page table at 0xa01fc000
<drahn> Mapping kernel
<drahn> Constructing L2 page tables
<drahn> freestart = 0xa05b4000, free_pages = 14924 (0x3a4c)
<drahn> switching to new L1 page table @0xa01fc000...bootstrap done.
<drahn> init subsystems: stacks vectors undefined page pmap [ bsd ELF symbol table not valid: bad magic ]
<drahn> [ no symbol table formats found ]
<drahn> Copyright (c) 1982, 1986, 1989, 1991, 1993
<drahn> The Regents of the University of California. All rights reserved.
<drahn> Copyright (c) 1995-2004 OpenBSD. All rights reserved. http://www.OpenBSD.org
<drahn> OpenBSD 3.6-current (RAMDISK) #122: Tue Dec 14 10:45:58 CST 2004
<drahn> drahn@poof:/usr/src/sys/arch/pxaarm/compile/RAMDISK
<drahn> real mem = 67108864 (65536K)
<drahn> avail mem = 53321728 (52072K)
<drahn> using 844 buffers containing 3457024 bytes (3376K) of memory
<drahn> mainbus0 (root)
<drahn> cpu0 at mainbus0: PXA250 rev 6 (XScale core)
<drahn> cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
<drahn> cpu0: 32KB/32B 32-way Instruction cache
<drahn> cpu0: 32KB/32B 32-way write-back-locking Data cache
<drahn> pxaip0 at mainbus0: PXA2x0 Onchip Peripheral Bus : CPU clock = -1005166764.000 MHz
<drahn> pxaintc0 at pxaip0 addr 0x40d00000: Interrupt Controller
<drahn> pxagpio0 at pxaip0 addr 0x40e00000: GPIO Controller
<drahn> back to slacking...
<martin> wow
<toby> nice
<miod> CPU clock = -1005166764.000 MHz
<miod> fun.
<martin> a portable 10THz machine, amazing :)
<drahn> also have to figure out what the problem with setting DTR|RTS in the
serial driver
<miod> what cereal chip is this?
<miod> martin, you missed the minus sign
<drahn> well, I had commented out the code that figures out bus clock because
it runs too damn slow on simulator
<drahn> 16550 'compatible'
<martin> plus it's only 1Thz
<miod> oh. you're in hell
<drahn> onboard pxa serial port
This did not go unnoticed.
<tdeval> hi
<tdeval> Dale, drop me an image, pleeeaase. :-)
<tdeval> I'm fed up with the last OpenZaurus dist.
<miod> you want OpenBeauZau instead?
<tdeval> Absolutely !
<jfb> hehehe
<drahn> you have to have a serial cable for the zaurus
<drahn> http://www.dalerahn.com/~drahn/zaurus/ zbsdmod.o.gz uncompress that
file and on the zaurus 'sudo insmod -f zbsdmod.o
<tdeval> Sh!t, I knew I had forgotten an accessory...
<drahn> '
<tdeval> btw, the serial cable is for console, isn't it ?
<miod> does this mean the serial connector needs a NiH cable?
<drahn> yes
<tdeval> an USB keyboard won't work like on the Cassiopeia?
<drahn> sorry, just managed to make serial console work a couple of hours ago,
not that far yet
<miod> slacker!
<miod> j/k
<tdeval> np
<drahn> the usb on the thing is usb slave only, and the display is not currently
configuring.
<tdeval> As long as I can play with it instead of being pissed of by the
unresponsive login I have now. ;-)
<miod> tdeval, but you can't play with it until it is in the tree!
<tdeval> So you tell me it will boot with a _beautiful_ *black* screen ? :D
<miod> no, blue
<tdeval> Ooh
<tdeval> I must try that
<drahn> no, it will keep up whatever screen linux had, no screen support working
yet.
<tdeval> Ok, ok, ordering the serial cable now...
<tdeval> So that when I get it, you'll have the display and keyboard
running... ;-)
<drahn> right now all that you could see is that the green mail light turns on.
<drahn> well, debugging will be much easier than the last two weeks, when all I
had was that green light.
<tdeval> yeah, obviously
One week later, Rahn shared his code.
<drahn> www.dalerahn.com/~drahn/zaurus/zdiffs.041221 for the impatient
<deraadt> +echo hello theo >/dev/ttyC0
<deraadt> oh you think you are funny
<drahn> put that in when i didn't realize that the display on the 860 was
external ;-)
<deraadt> +#if NRAID > 0
<deraadt> + { &raid_cd, "raid", 71 },
<deraadt> +#endif
<deraadt> optimist.
<drahn> copy/paste
<deraadt> I know :)
On Christmas day, Rahn addressed one of the most difficult problems in computing: naming things.
<drahn> Since i am getting clloser with the Zaurus port, should I actually name
my port OpenBSD/zaurus instead of OpenBSD/pxaarm (which is my current
scheme?)
<miod> are there any other pxaarm devices?
<miod> if not, naming it zaurus is much better imho.
<drahn> there are likely other xscale devices, however much of the shared code
is really in arm/xscale not pxaarm/...
<drahn> xscale -> pxa25x/pxa27x
<grange> pxa is much better than pxaarm imho
<drahn> Ok, no argument there...
<drahn> just should it be pxa or zaurus?
<miod> i vote zaurus. because people know what zaurus is, but they don't know
what pxa is.
<grange> me too
<grange> for such embedded shitz it's easier to make a port per board
The initial import of the Zaurus codebase took place on december 30th.
Port of OpenBSD to the Zaurus, currently running on C860, soon C3000.
It was followed, as usual, by many minor cleanups and adjustments.
<drahn> yea, still runs after it is in-tree <drahn> OpenBSD 3.6-current (RAMDISK) #34: Thu Dec 30 18:52:09 CST 2004 <drahn> drahn@poof:/usr/src/sys/arch/zaurus/compile/RAMDISK <drahn> real mem = 67108864 (65536K) <drahn> avail mem = 53231616 (51984K) <drahn> using 844 buffers containing 3457024 bytes (3376K) of memory <drahn> mainbus0 (root) <drahn> cpu0 at mainbus0: PXA250 rev 6 (XScale core) <drahn> cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled <drahn> cpu0: 32KB/32B 32-way Instruction cache <drahn> cpu0: 32KB/32B 32-way write-back-locking Data cache <drahn> pxaip0 at mainbus0: PXA2x0 Onchip Peripheral Bus CPU clock = 398.108 MHz <drahn> pxaintc0 at pxaip0 addr 0x40d00000: Interrupt Controller <drahn> pxagpio0 at pxaip0 addr 0x40e00000: GPIO Controller <drahn> saost0 at pxaip0 addr 0x40a00000 <drahn> saost0: SA-11x0 OS Timer <drahn> com0 at pxaip0 addr 0x40100000 intr 22: ns16550a, 16 byte fifo <drahn> com0: console <drahn> com1 at pxaip0 addr 0x40200000 intr 21: ns16550a, 16 byte fifo <drahn> pxapcic0 at pxaip0 <drahn> pcmcia0 at pxapcic0 <drahn> obio0 at pxaip0 intr 8 : baseboard=0 ((unknown)), expansion card=0, processor card=0 (Cotulla) <drahn> lcd_obio0 at obio0 <drahn> wsdisplay0 at lcd_obio0 <drahn> wsdisplay0: screen 0 added (bpp16, vt100 emulation) <drahn> clock: hz=100 stathz = 64 <drahn> rd0: fixed, 5120 blocks <drahn> wdc0 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6" port 0x0/16 <drahn> wd0 at wdc0 channel 0 drive 0: <SanDisk SDCFB-256> <drahn> wd0: 1-sector PIO, LBA, 244MB, 500400 sectors <drahn> wd0(wdc0:0:0): using BIOS timings <drahn> boot_file: '(null)' <drahn> rootdev=0x1200 rrootdev=0x1200 rawdev=0x1202 <drahn> wd0 detached <drahn> wdc0 detached <drahn> wi0 at pcmcia0 function 0 "BUFFALO, WLI2-CF-S11, " port 0x0/64 <drahn> wi0: PRISM2.5 ISL3873, Firmware 1.0.5 (primary), 1.3.4 (station), address 00:07:40:7c:45:1e <deraadt> neato. <pval> wi(4) works ? :) <deraadt> of course, that is what he did last week
There was however a problem: as long as it was using a serial console, the Zaurus would not be usable as a standalone device. We needed a proper display console to work, and this would not be easy.
The display controller found on PXA designs does not have dedicated video memory. It works by driving an LCD screen and performing DMA from system memory to the LCD enough times per second for the display to be comfortable to human eyes.
But in the early steps of the kernel initialization, where it matters to be able to display information, the kernel DMA layer was not usable yet, as it depends upon proper MMU initialization.
I started to work on improving the display support, with Rahn acting as a (often frustrated) tester. Across the month of january 2005, I sent him a lot of diffs to test...
Date: Mon, 3 Jan 2005 13:51:44 +0000 From: Miod Vallat To: Dale Rahn Subject: first set of zaurus lcd diffs Ok, I don't know who else I should harass with zaurus diffs I can't test beyond compilation. Dragos? Theo? Others? It is obvious that this code has been written with a very scarce knowledge of rasops and wscons; a significant part of it consists of simply killing redundant interfaces or code path. And I suppose the pxa lcd base code is used by several boards in NetBSD/evbarm, which does not help. Details: - kill the non-wscons code. really. - some KNF (more needed) and english fixes - do not handle WSDISPLAYIO_[GS]VIDEO in the driver - the uppper layer can do this, as long as we provide a burner operation, so write one. - handle failure in show_screen() when invoking the pxa show_screen() code. Granted, it always returns zero but it might change someday. - do not use our own set of emulops wrappers, simply point to the rasops one (this also makes the wsscreen_descr table much simpler - everything will be filled from rasops capabilities, as usual). - when setting the color palette in 8 or 4bpp modes, match the rasops color table (only affects the normal white value). If we keep this code (i.e. if we don't force 16bpp, period), I will further tweak it to directly convert rasops_cmap[] entries. I also had to revert you pxa2x0_intr_establish() change [chunk #3] - looks like you have uncommited changes in arch/arm/xscale and I did not want to touch the intr_establish at this point. Miod [...]
The next day (january 4th), I sent Rahn two updated diffs. On january 5th, another update.
I also misunderstood Rahn at some point and commited a diff which I thought he had tested, while he was in fact referring to a previous one. The damage was undone shortly after.
On the 6th, I sent him no more than seven diffs; at this point, we reached a state where the console would go to the serial port unless the display driver would attach, at which point it would take over.
Lazy man's display console on Zaurus: allow the display to be attached as a console when it is probed. Earlier boot messages are still being sent to the serial port for now. While there, swap blue and red in 16bpp mode to get the expected display colours. Tested and ok drahn@
With the display driver in a state I was reasonably happy with, the next step was to be able to run as console as early as possible. Doing this would require two weeks of work.
Date: Fri, 7 Jan 2005 10:34:24 +0000 From: Miod Vallat To: Dale Rahn Subject: zaurus early console, diff 1 This is a major shuffling of code, in order to be able to attach the glass console very early. Of course, this opens a can of worms, it might be too early to de funny things like DMA, etc. So I have added a variable to control whether we initialize early or not. Right now it will NOT attach console early. The first thing to know is if things still work with all those changes. If it works for you correctly (blue kernel messages, usb keyboard being ok, etc), then you can try to set glass_console is zaurus_machdep.c to 1, recompile your kernel, and hope for the best. Miod [...]
Date: Fri, 7 Jan 2005 20:04:47 +0000 From: Miod Vallat To: Dale Rahn Subject: Zaurus early console, take 2 More major shuffling and code factorizations. I am not kidding when I am telling you this driver is unrecognizable from the initial code... Oh, and more KNF too. And more code moved to the generic pxa2x0_lcd codebase, which now has all the console knowledge and code... everything is hidden from the upper driver (lcd@obio) point of view! Be sure to check that glass_console == 0 is not broken, then give it a try with glass_console == 1. Uncertain things: - I am not sure when interrupts are enabled for the LCD. Perhaps even not at all since lcdintr basically only acks it? The handler is not registered until real attachment, plus you configure with interrupts disabled, right? - Because of no ints, the screen might not refresh until you are probing wsdisplay for real. We'll see (well, you will, not I). I wish you luck with this one (can't hurt to wish...) Miod [...]
Of course, it would have been too easy for these first diffs to work. Rahn reported the machine did not hang with them, but, if glass console was enabled, the screen wouldn't display anything; however, the machine would still boot, blindly.
Around that time, ARM and OpenBSD enthusiast Uwe Stühler, who had been very interested in the Zaurus port and had started to contribute patches, got invited to join the OpenBSD crew.
[=Arrive=] uwe entered group <uwe> hi <uwe> i'm working on the zaurus :)
Some time later, Rahn confirmed that the Zaurus was running multiuser from disk.
[=Arrive=] dsr_zaurus entered group
<dsr_zaurus> la la
<deraadt> oh really? :-)
<dsr_zaurus> yes.
<deraadt> do tell what is new.
<dsr_zaurus> I am loggin in thru the zaurus. multiuser on the internal HD
<uwe> grats!
<deraadt> how did you layout the internal HD?
<deraadt> i have asked dragos to create us a linux script that would castrate
linux into the tiny flash
<dsr_zaurus> shrunk hdd3 to 200k and then partitioned it as one large partition
+ swap
<dsr_zaurus> not an ideal design, but works for now.
<deraadt> yeah.
<deraadt> screen is better, but still turned?
<dsr_zaurus> yes, I have it closed (inverted) and leaning up against somthing.
<dsr_zaurus> usb keyboard of course.
<deraadt> using new boot loader?
<dsr_zaurus> One rev out, but yes
<dsr_zaurus> zboot didn't work for me with hdc4 however.
<uwe> not after 'set device /dev/hdc4' ?
<deraadt> your kernel is in hdc4 would be...?
<drahn> Ah, just did /dev/hdc4:/bsd at the prmopt
<uwe> b /dev/hdc4:/bsd is broken
<drahn> ah
<djm> i'll have to grab a zaurus in akihabara now...
<dsr_zaurus> well, beating the shit out of the zaurus, network, and usb disk,
no problems running.
<deraadt> reliable?
<dsr_zaurus> yup
<deraadt> no cache, is it fast?
<dsr_zaurus> couple of time I wondered if the usb disk hang unexpectantly, but
^C killed the ap.
<dsr_zaurus> Oh, I am running th cache in the wrong mode, and no it is slow atm
<dsr_zaurus> according to people at work the memory bus on pxa270 absolutely
sucks, over 200 wait states for accesses at times.
<deraadt> of course. this is not a fast processor. that's ok
<dsr_zaurus> had thought it would be faster (or close depending on disk) than
cats
[...]
<deraadt> Ok, the zaurus is the coolest thing we've done in a while.
The next week, I resumed tinkering with the console.
Date: Mon, 10 Jan 2005 14:41:15 +0000 From: Miod Vallat To: Dale Rahn Subject: Zaurus Early Console #3 New diff to begin the week! If I remember correctly, previous diff ended up with: - proper operation (but serial console) with glass_console set to zero. - display frozen but machine not hung with glass_console set to one. This new diff is a minor change from the previous one, which will retrigger DMA when the real device is attached. If our problem is really caused by DMA not working (maybe because it requires some pin frobbing outside the lcd registers), the screen will come back to life when the kernel reaches the wsdisplay attachment during probe, and at this point you should see all the lines of dmesg preceding the wsdisplay attachment. Please let me know of your results. Miod [...]
Date: Tue, 11 Jan 2005 21:55:02 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: zaurus ec3b ec3 diff freezes. Probably panics but we don't have a console set up so we can't get the message. This diff is the same as ec3 diff, but does not start dma until we are attaching the display device. Which means you will not see the kernel boot messages until it attaches wsdisplay0 (don't forget to set glass_console to 1 after applying). Or it might die earlier; let me know... Miod
Date: Tue, 11 Jan 2005 22:14:03 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: zaurus ec3c More dma games. Be careful. Your screen might display utter garbarge until suddenly kernel messages appear. Get ready to unplug power just in case. Miod PS: You are not allowed to complain about these diffs yet, Todd has been forced to try much more hp300 SGC kernels over the last few days...
These diffs however didn't help, so I diverted my attention to other tasks, in order to come back to it later with a clear mind.
This helped, as one week later, I still did not have a working diff, but I had understood why the none of the previous diffs did work.
Date: Wed, 19 Jan 2005 08:33:04 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: early console progress I finally understand why the diff had zero chance to work with glass_console = 1. I found the bootstrap_bs_map() game for bus_space_map in zaurus/zaurus_machdep.c, and of course the bus_space_tag I want to use for lcd is not covered by this hack. So I'm working my way around this, and will add a hook after uvm is initialized to trigger the dma. I will need to move the boot -c section later as well, it's too early in the boot process to have a chance to work on a non-serial console. Expect a set of 3 diffs in about 12 to 14 hours from now. Miod
I started to work on this, but the more I worked on it, the ugly the code would become. After a while, it was clear that this was not the way to go, for I would end up with something too complex and too brittle.
After a night of sleep, I found a better way.
Date: Thu, 20 Jan 2005 12:29:57 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: Zaurus not so early console (ec4) Getting the display console to work immediately turns out to be a completely horrible and unmaintainable nightmare. So I looked at the problem from another angle, and came with something much, much better. We will still use the serial console at the very beginning of the kernels life. Then, after the vm system is initialized, we can replace the console with the lcd driver. This requires changes to consinit() to be split in two versions, one regular version which is invoked twice [once from initarm() because it is chatty, and once from main()], and a broader version which can do lcd_cnattach(), after uvm is initialized. The problem now is, where to invoke the second consinit()? I see different places: - in main() after uvm_init(). Maybe #ifdef __HAVE_EXTRA_CONSINIT so that only zaurus has to provide it. - in cpu_startup(). But on arm ports, cpu_startup() is shared, so it would need an md hook. I gave the second choice a try. Of course, I could not check this diff beyond a kernel compilation. I expect it to work, of course. No more class_console knob - it starts serial, then it goes lcd. Or panics. Or hangs. I dunno. Chances are, however, than if anything goes wrong you will be in ddb on serial, which will be better to debug this. [...]
Some more polishing was necessary, though.
Date: Thu, 20 Jan 2005 17:35:31 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: zaurus ec4b New diff for early console. Changes: - provide the cats chunk I left out in ec4 - do not use pxa2x0_clkman directly in pxa2x0_lcd, but use a function pointer, which will be pxa2x0_clkman during autoconf, and early_clkman() for cnattach. - in zaurus/zaurus_machdep.c turn all clkman code into early_clkman() calls. Also the #if 1 early_clkman() 10 lines before consinit() should be removed, after someone confirms it is not necessary anymore as consinit() and board_init() do the right thing. Miod [...]
Date: Thu, 20 Jan 2005 22:19:03 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: zaurus ec4c Hopefully the right one, after some debug with Dale. Miod [...]
This work was finally commited on the 21st.
Overhaul of the pxa2x0_lcd code, to allow early (before autoconf) attachment, and collateral changes. Because this driver requires us_dma (and as such, vm services) to work, it can not be selected in consinit(). Instead, add a hook to the arm cpu_startup() which will, on zaurus, switch console from serial (selected in consinit()) to lcd. This also makes the zaurus-specific early pxa2x0_clkman() substitute code cleaner. While there, move boot -c handling later, after the glass console is set up. Tested by drahn@ and uwe@
While I was torturing Rahn with these console diffs, the boot code, written as a Linux kernel module, was commited on january 10th.
(for now) on the linux side, do: zaurus# insmod -f stand/zbsdldr/obj.i386.zaurus/zbsdldr.o zaurus# mknod /dev/zboot c 99 0 zaurus# cp bsd.rd /dev/zboot
That
mknodstep looked to me like something which could be avoided or improved, and I shared my thought with the Zaurus gang.
Date: Mon, 10 Jan 2005 14:53:06 +0000 From: Miod Vallat To: Theo de Raadt, Dale Rahn, Uwe Stühler Subject: zbsdmod and device nodes Right now, setting up a Zaurus system to run OpenBSD requires creating a device node for use with the zbsdmod helper. I wonder if it would not be easier to change that /dev/foo node to a /proc entry. Code changes in the module would probably be minimal (since you'll need the same fileops after all), and this would make the mknod step unnecessary. Then you'd just have to cat bsd >> /proc/zbsd or whatever to make it do its magic. What do you guys think? Is this a good idea or am I on drugs? Miod
Stühler agreed it was a good idea and implemented it four days later.
Change the device node from /dev/zboot to /proc/zboot to make the mknod step unnecessary. Suggested by miod@
OpenBSD is known for always performing native system and package builds; this is an excellent way to exercize the system. Despite the limited memory and slow internal drive, Zaurus was no exception.
<deraadt> hah, my zaurus is swapping :) <mickey> to what ? (: <deraadt> the cf drive <mickey> ah. heh <mcbride> what, no swap to mfs?!? <mcbride> (that's a joke, for the humour impaired) <mickey> swap to the framebuffer memory! <drahn> framebuffer is main memory <mickey> bummer <otto> i always swap to cache <drahn> I need to stop swapping on /dev/null
Later in february, Stühler added support for suspend-to-memory.
Initial suspend/resume code with additional powerhooks. Enter/exit suspend mode with power button or zzz. May not work for everyone yet. ok drahn@ and deraadt@
One other important usability feature was, however, lacking: the display was setup in portrait mode, and needed to be rotated clockwise to be usable. But code to do that was lacking.
<drahn> now if my neck wasn't so stiff.
<deraadt> see, i told you that getting your keyboard working before miod got the
display turned
<deraadt> would be very very bad for you
[...]
<miod> well, sorry for z display, but I am late on my hp300 schedule, so it has
top priority at the moment. built over 60 kernels in the last 2 days.
<drahn> OpenBSD 3.6-current (GENERIC) #43: Thu Jan 13 15:42:53 CST 2005
<miod> and I need this out of my tree by the end of this week or it will miss
3.7
<drahn> ok, you have me beat, that is since going native
<miod> OpenBSD 3.6-current (GENERIC) #135: Thu Jan 13 22:24:15 GMT 2005
<miod> miod@bansat.gentiane.org:/usr/src/sys/arch/hp300/compile/GENERIC
<miod> that's 135 in the 2005 wscons tree. the 2003 wscons tree ended at about
80.
<deraadt> :-)
I nevertheless promised I would work on this; but the year 2005 turned out to be very challenging to me, lifewise; and not having a Zaurus machine myself, I was not in a hurry (I did not need a Zaurus to test, as I could do the work on any other machine with a frame buffer, and only require help from Zaurus users for finishing touches.) And thus, the strained neck complain became a recurring topic.
<espie> openbsd is dying, anyways.
<espie> I've got probably 10 patches floating around, with no-one looking at
them, all the developers are dead.
<espie> low attention span: give them a new toy, like a zaurus, and boom, they
don't look at anything else.
<henning> tell news
<espie> I should try slashdot.
<henning> getting the right ppl to okay shitz has been a problem for years
<espie> I'm pretty sure they would run anything.
<henning> and just throwing a mail at [private OpenBSD mailinglist] and waiting
for the magic to happen is not what works
<espie> we don't have nearly enough right ppl.
<henning> that I agree with
<henning> which is entirely clear, given that BSD is dying.
<miod> actually, the problem is not lack of people, it's people's lack of ime
<miod> err, time
<henning> yeah, that is a big part of the picture
<miod> of course playing with zaurus toys has an immediate impact on time.
<espie> and neck ! ;-)
<espie> or is this (-; ?
<miod> the impact on the neck is just me being evil.
Glancing through the chat logs for Zaurus discussions also unearthed the following funny exchange, on january 28th:
<kettenis> Looking for a paperclip I opened a drawer of the unused desk in my
office. Guess what I found:
<martin> a vax?
<kettenis> even a microvax isn't that small
<martin> :(
<martin> zaurus!
<kettenis> nah, a genuine 8087
<martin> eek.
<miod> a vlc would fit in a drawer. I ran sun4c lunchboxens in drawers for
years.
As I failed to deliver the promised rotation code, Christopher Pascoe took matters in his own hands and did the work. He shared his code with a few developers, including me, on april 15th.
This was much less ambitious that what I have planned, and introduced a lot of #ifdef __zaurus__ conditionals in machine-independent code, but it did the work and solved the immediate problem of sore necks.
I discussed the way I had intended to do the work.
Date: Fri, 15 Apr 2005 06:28:15 +0000 From: Miod Vallat To: Christopher Pascoe Cc: Theo de Raadt, Uwe Stühler, Dale Rahn, David Gwynne Subject: Re: zaurus (un)rotated console For the record, what I had in mind: - add an attribute "rasopsrotation" to drivers which will use rotation. - have all the rotation code fit in dev/rasops/rasopsrotation.c - #if NRASOPSROTATION > 0, all regular rasops functions get their name appended with "_internal", for the code in rasopsrotation.c to be able to invoke then once the coordinates have been translated. - a new field in struct rasops_info, int ri_rotation, would contain one of the following values: #define RR_NONE 0 /* no rotation */ #define RR_CW 1 /* quarter, clockwise */ #define RR_HALF 2 /* halfturn */ #define RR_CCW 3 /* quarter, counter-clockwise */ - rotating the wsfont in memory was what I intended to do as well. Plus now that wsfont_add() is available, it becomes pretty easy. The reasoning behind hiding as much as possible behind #if NRASOPSROTATION is to avoid growing installation media on architectures which use rasops but do not need text rotation. Apart from the extra field in struct rasops_info, there should be no change for them. I'll work on merging your code with my incomplete attempt, and share the diff... Miod
But as I ended up still not having enough time to make progress on that issue, I eventually told him not to wait for me.
Date: Sat, 30 Apr 2005 20:38:00 +0000 From: Miod Vallat To: Christopher Pascoe Cc: Theo de Raadt, Uwe Stühler, Dale Rahn, David Gwynne Subject: Re: zaurus (un)rotated console Since I am not moving as fast as I would like on this area (but slowly making progress...), I think you should commit your diff. Then when my framework is ready, it can replace your code... Miod
His code was commited moments later.
Temporary hack to (un)rotate the Zaurus console until a proper rasops rotation framework is ready.
I would eventually complete that work in september, and replace Pascoe's code on september 15th.
Stop compiling the texte console rotation code #ifdef __zaurus__, but use a flag in the rasops_info structure; drivers which may use it shall declare a specific attribute for the config(8) machinery, so that the necessary code is compiled in. In addition to this, rotated font computation is now done on-demand, and a list of unrotated-rotated font cookie pairs is kept, rather than rotating all built-in wsfonts at initialization time. No user-perceptible functional change. Tested matthieu@ uwe@, ok uwe@
That autumn, I also relocated across the country; my
machines were delivered back on october 19th, and I worked on setting up my machineroom anew.
On october 30th, I put the CATS board back in service, only to see it catch fire less than three hours later.
<miod> aha, found a machine which tree had no M, for a change. <drahn> slacker <drahn> :-) <miod> heh <miod> gonna setup the cats box now <miod> since neither dale nor uwe commeted my diffs... <miod> err, commented. <drahn> I probably lost them in my pile of email. <miod> that's _my_ convenient excuse! <drahn> well, I have a better. my email currently appears mostly down <miod> you win. [...] <miod> shit, smells of burning hardware around... <miod> that's the cats board. <miod> pci bridge. <miod> [all caps expletive deleted]
I suppose this was an unexpected consequence of the machine having run overclocked for too long in the very early days of the OpenBSD/cats port. Still, it was a very frustrating way to die, especially coming from hardware supposed to have a very small power consumption.
<deraadt> I just checked -- the zaurus draws 0.485 W
(Years later, while getting rid of old stuff, Todd Miller would use that event as a convenient excuse to get rid of his CATS board by sending it to me, so that the collector in me would no longer be sad not to have a working CATS board.)
On the same day, Rahn started to tinker with processor frequency scaling.
<drahn> heh, I can make the zaurus run at 208 MHz, wonder if that would make
the battery last longer.
<drahn> if I wasn't called away to carve pumkins, I would look at 91MHz, which
should be noticable
<miod> 91MHz would start to be an acceptable speed to me.
<drahn> 91MHz should be fine for airplanes and bars.
[...]
<drahn> I think I found two seconds of the 4-5 second time loss on zaurus in
suspend, lcd_enable/disable blocks interrupts for long periods.
<drahn> pxa2x0_lcd_suspend/resume
[...]
<drahn> oh, my at 91MHz zaurus scp runs less than half speed ~500KB/s -> 150KB/s
<drahn> damn, sigkid, gotta carve pumpkins
The early bits of frequency scaling were then commited between two sessions of halloween pumpkin carving.
On suspend/resume save the current time to the RTC earlier and restore it later so that the very long delay operations do not slow the clock unnecessarily. Add early support for hw.setperf and hw.cpuspeed for zaurus, it appears to be able to run at 91MHz and 209MHz as well as the std 416MHz with this change. Hopefully it is doing the speed changes correctly.
91MHz operation had to be disabled a few days later, though.
<drahn> jolan reported that his zaurus didn't work well at 91MHz or even after
it was swiched back from 91MHz
Stühler investigated the issue and noticed that one internal processor clock would be disabled when switching to the lowest frequency. It was thus decide to disable this speed until a better way to use the clocks would be found.
no 91Mhz mode for now, because the OSCR0 does not run in low-power mode; found after prodding by deraadt@
A few weeks later, Rahn shuffled the use of the various internal clocks in order to no longer depend on that particular clock; this allowed in turn the 91MHz mode to be reenabled on december 20th.
switch to using clock4 instead of clock0 so that we get clocks when running at 91MHz (clock4 is programmed to be based of the 32.768KHz clock.
Then Rahn also noticed that it was possible to overclock the Zaurus.
<millert> What speed does zaurus normally run at?
<niallo> millert: 416 Mhz
<drahn> would it make any sense to allow sysctl.hw to be > 100 ?
<grange> 100 means 100%
<drahn> for the overclockers. the pxa270 can run at 520 and 624, dunno if zaurus
can handle that however.
<millert> maybe reserve 10% cpu for root then we can really confuse people
<miod> hahahaha
<grange> don't forget to add to 39.html: ``hw.setperf sysctl was extended to
allow to overclock your cpu''
<miod> and if the user overclocks his cpu, we'll print a message saying that
the kernel is ``tainted''.
<drahn> fib(38) -> 13.31s at 416
<miod> but is the result correct?
<drahn> fib(38) -> 11.42 at 520
<drahn> fib 38 -> 63245986
<drahn> hmm, better improvement by just enabling -O2 than overclocking.
<kettenis> you mean -O2 actually optimizes the code instead of just increasing
compile time? ;-)
<drahn> removes a few redundant instructions.
<miod> inconceivable!
Of course, some people had to try it.
<deraadt> zaurus seems reliable at 520mhz, doing a build
<deraadt> as in, has been running for 8 hours...
<marco> is that overclocked?
<deraadt> yeah. there is a higher speed, but dale says it is not reliable.
[...]
<drahn> when I tried the higher speed (624MHz) my zaurus paniced as soon as the
screen scrolled.
<deraadt> that is amusing.
In november 2005, Stühler and Niall O'Higgins made two presentations about the Zaurus port: one named ``Porting OpenBSD'', at OpenCON 2005 in Venice, Italy, and another named ``Embedded OpenBSD'', at EuroBSDCon 2005 in Basel, Switzerland.
I recommend having a look at the EuroBSDCon presentation, for it gives a lot of information about the Zaurus without being too technical.
(Also, I'm in the eighth slide of the EuroBSDCon presentation. And the ninth slide contains a picture of my machineroom as it was at the time this presentation took place.)
In march 2006, Sharp released a new Zaurus model, the SL-C3200, with a larger internal microdrive.
From left to right, Zaurus SL-C3000, SL-C3100 and SL-C3200.
(Picture by Wim Vandeputte)
Unfortunately, other changes to the SL-C3200 prevented the ready-to-run OpenBSD installer package from working.
<uwe> zaurus ipk package does not work on the c3200. it has to make room in the
root filesystem, but in a new way.
This was fixed by Uwe Stühler a few days later.
Some hacks for the C3200. Files have to be moved and copied around to make room in the root filessystem and to avoid a known problem with zbsdmod.
With no further Sharp Zaurus systems, and the OpenBSD/zaurus port being mature, there was not much Zaurus work occurring after that.
After the OpenBSD 4.0 release cutoff, on october 1st, 2006, de Raadt decided to pull the plug of OpenBSD/cats.
<deraadt> I have removed the cats machine from the rack.
<kettenis> going to remove cats from the list of supported platforms?
<deraadt> Dale is going to.
<todd> that was a short lived arch.
<deraadt> Long.
<drahn> so are there two operable cats machines in developers hands? mine and
theo's?
<deraadt> miod may have one. anyways, let's kill it. i need the rack space
back, and cats was just a jumping-board
<drahn> I thought miod's died.
<deraadt> Well I can kill mine in the next 2 minutes if you want me to...
<kettenis> thecus is faster for doing arm package builds?
<deraadt> cats CRAWLS.
<drahn> 600Mhz vx 233MHz ?
<deraadt> cats is not reliable.
<deraadt> It does not hurt to kill it. We learned a lot. It was just a jumping
station to real arm platforms.
<drahn> yup.
<deraadt> Their hardware never passed prototype stage.
<millert> I have a cats machine I can send someone if they really want it...
<deraadt> cats must die.
<millert> So be it.
and three days later:
<miod> curiosity killed the cat. <mickey> or cats? <drahn> thought it spoiled the cheese <miod> cats boards do not need help to die <miod> at least all mine needed was to be powered on.
Despite the removal of the CATS port, Zaurus was still very well alive.
In september 2007, Art Grabowski worked on a change to the process context switching, which would benefit multiprocessor systems but also brought nice cleanups.
Unfortunately, while testing this diff, Zaurus users noticed that, with the diff in their kernels, their systems would always panic after being suspended, almost immediately upon resume.
Several people, including me, started to investigate the problem. At first, I suspected an incorrect alignment of some kernel data, as an indirect consequence of Grabowski's changes.
But this did not help. Matthieu Herrb lent me his Zaurus to help me investigate, and I started to lose hair on the problem.
Date: Tue, 9 Oct 2007 19:47:24 +0000 From: Miod Vallat To: Art Grabowski, Theo de Raadt, Mark Kettenis Subject: zaurus suspend with switchto This is completely unbelievable. What happens is that the apm0 kernel thread, in its infinite loop, sleeps on the lbolt [arch/arm/xscale/pxa2x0_apm.c!apm_thread()]. When tsleep gets invoked, it ends up sleeping in sleep_finish() (in kern_synch.c), where it invokes mi_switch() to run something else until this process is waken up. mi_switch() in turn will invoke cpu_switchto(). Since cpu_switchto() changes contexts, you can expect that, when it returns, this is because the process it left has been scheduled again, i.e. curproc on return of cpu_switchto() is the same as it was before. However, when the zaurus is suspended, then resumed, what happens is that the apm0 kernel thread context is restored, but curproc points to a different process!!! More precisely, every time this occurs, I see in mi_switch(): - p (which is curproc on entry to this function) is the apm0 kernel thread. - newproc (which is the process we switched to) is either apmd or ypbind. - curproc on return of cpu_switchto() is either ypbind or apmd (i.e. it is different from p and from newproc). I have been looking and looking again at cpu_switchto(), and I do not see how this can happen. This does not look like a compiler optimization interference (cpu_switchto() appears to correctly preserve callee-saved registers). I am currently out of ideas. If you could think of things to check or try, I am interested in them. Miod
At some point, when the processor behaviour does not match what the contents of the memory would dictate, you start losing faith in reality.
But there is something often overlooked between the processor and the memory: the cache memory.
The Zaurus suspend-to-memory code made sure to flush its data cache before halting the processor, for the contents of the cache would be lost on resume.
But on the PXA processor powering the Zaurus, which was based on a XScale core, the nominal cache flush sequence did not always work, and the kernel cache routines had a workaround for it:
#define XSCALE_CACHE_CLEAN_PROLOGUE \
XSCALE_CACHE_CLEAN_BLOCK ; \
ldr r2, .Lxscale_cache_clean_addr ; \
ldmia r2, {r0, r1} ; \
/* \
* BUG ALERT! \
* \
* The XScale core has a strange cache eviction bug, which \
* requires us to use 2x the cache size for the cache clean \
* and for that area to be aligned to 2 * cache size. \
* \
* The work-around is to use 2 areas for cache clean, and to \
* alternate between them whenever this is done. No one knows \
* why the work-around works (mmm!). \
*/ \
eor r0, r0, #(DCACHE_SIZE) ; \
str r0, [r2] ; \
add r0, r0, r1
but the Zaurus suspend code could not invoke these routines directly and had to contain an inline version of them. That inline version was lacking the workaround. Therefore, upon suspend, the contents of the cache were often not correctly propagated to the main memory. Upon resume, the processor would reload stale data, causing the kernel to misbehave.
The fix was trivial.
Date: Thu, 1 Nov 2007 22:34:53 +0000
From: Miod Vallat
To: Theo de Raadt, Felix Kronlage, Todd Fries, Dale Rahn, Uwe Stühler
Subject: zaurus suspend fix
Works for me. Please try this on your machines.
Index: pxa2x0_apm_asm.S
===================================================================
RCS file: /cvs/src/sys/arch/arm/xscale/pxa2x0_apm_asm.S,v
retrieving revision 1.3
diff -u -p -r1.3 pxa2x0_apm_asm.S
--- pxa2x0_apm_asm.S 2007/10/08 20:18:19 1.3
+++ pxa2x0_apm_asm.S 2007/11/01 22:33:44
@@ -25,6 +25,7 @@
/* XXX replace with values defined elsewhere. */
#define DCACHE_CACHELINECOUNT 1024
#define CACHELINESIZE 32
+#define DCACHE_SIZE (CACHELINESIZE * DCACHE_CACHELINECOUNT)
/* cp14 register 6 */
#define CLKCFG_T (1<<0) /* turbo */
@@ -195,10 +196,18 @@ ENTRY(pxa2x0_cpu_suspend)
/* At this point all critical registers have been saved. */
mov r0, #0
- mcr p15, 0, r0, c7, c10, 4 /* XXX does exactly what? */
+ mcr p15, 0, r0, c7, c10, 4 /* drain write buffer */
mov r1, #DCACHE_CACHELINECOUNT
- ldr r0, .Lxscale_cache_clean_addr
+ ldr r2, .Lxscale_cache_clean_addr
+ ldr r0, [r2]
+ /*
+ * For an explanation of the following two instructions, refer
+ * to the ``BUG ALERT'' section of the XSCALE_CACHE_CLEAN_PROLOGUE
+ * macro in arch/arm/arm/cpufunc_asm_xscale.S.
+ */
+ eor r0, r0, #(DCACHE_SIZE)
+ str r0, [r2]
cache_flush_loop:
mrs r2, cpsr
<deraadt> that zaurus patch is so subtle. bravo.
<kettenis> didn't see the zaurus patch yet :(
<deraadt> kettenis miod doesn't love you, but i will fwd it.
<miod> that's because you don't have a zaurus!
<pval> i do, send please! :)
<djm> metoo
<miod> sure
<djm> and i'm morbidly curious
<miod> you'd better apply the patch without looking at it
<miod> or your glasses will go dark
<miod> z^3
<djm> haha: /* XXX does exactly what? */
<deraadt> I absolutely think Miod found it.... sigh
[...]
<jdixon> dumb question, what does XXX really stand for (no jokes, please)
<djm> usually "to be fixed"
<jdixon> thx
<deraadt> or "this is harder than you think"
<jdixon> that would be for me
<deraadt> well, it could mean either.
<jdixon> ;)
[...]
<jsg> I'm curious as to what the fix actually is...
<deraadt> xscale cache bug. worked around somewhere else in the tree... but not
in the suspend code before putting the cpu to sleep
<jsg> ah
<deraadt> there's no reason for miod to leave that uncommited in his morning ;)
This diff was then commited the next morning.
Use the same cache cleaning address computation as done in cpufunc_asm_xscale, for there be dragons in xscale cache and it would not be cleaned correctly, leading to wrong pcb data being restored on resume and eventually causing panics.
In september 2016, after the release cutoff for OpenBSD 6.0, the Zaurus port was removed.
Its use as a pocket-size machine able to run ssh was long superseded by the smartphones, and upcoming changes to the ARM userland in OpenBSD, in order to conform to the ARM EABI, would have required two distinct set of binaries, one for the more recent ARMv7 systems, which have a per-processor thread register, and one for the earlier systems, including the Zaurus. Due to the lack of interested people and the effort required, it was simpler to drop the pre-ARMv7 platforms.
<matthieu> does someone also plan to remove zaurus bits in dev/wscons ?
<matthieu> X will need some patches then.
<guenther> dang it, I get distracted by www and matthieu steals most of my
xenocara commits
<guenther> I had them all lined up...
<phessler> one bullet, 4 heads?
<beck> my god, it's like you guys like shooting kittens or something
<guenther> phessler: archdeadpool
<guenther> bob, we would never shoot kittens
<phessler> of course we like shooting kittens. if you don't, they grow up to be
cats
<krw> shooting *at* kittens perhaps. I suspect there are few people here that
could hit a kitten.
<guenther> that's what *cat*apults are for
<beck> zauruses are the closest thing to cute kittens we run on
<phessler> I do like catapults
<beck> and they never grew up
<beck> s/are/were/
As is often the case, the retirement home for discontinued OpenBSD ports seems to be NetBSD, which has grown its own NetBSD/zaurus port by porting the OpenBSD code.
Of course, nowadays, OpenBSD runs on a large set of armv7 and aarch64 hardware.
Would it have, if some developers hadn't wanted to put a Zaurus in their pockets?