11th February ~~~~~~~~~~~~~ Port started - OpenBSD booted for the first time in history on PXA2xx based Palm device (Palm LifeDrive). Bootloader (Cocoboot) needed some heavier patching - basically because the OpenBSD kernel is an ELF binary on the contrary of Linux kernel, which is an executable self-relocating blob. Thus you need to tear the OpenBSD kernel apart and put all the pieces in it's place by hand, unlike Linux, where you just put the whole thing somewhere in the memory and jump to it's begining. 7th March ~~~~~~~~~ Further research began - OpenBSD actually hangs somewhere in the boot process, no idea why, but it does. 8th March ~~~~~~~~~ Still no progress. Maybe something related to clock is broken? 10th March ~~~~~~~~~~ Interrupts doesn't seem to fire, that can definitelly be the cause of the problem. 11th March ~~~~~~~~~~ Interrupts actually may fire, but the interrupt handler isn't called ... so what now? Fixed not-really-bug in pxa2x0_intr.c [patch 0002] 12th March ~~~~~~~~~~ Commenting out most of the code in pxa2x0_clock.c out of interest led to fixing the hang on PalmT3 (PXA261). This is obvious, since the code uses PXA OS Timers 4 and 5 which are not present on PXA CPU's before 27x series. So the pxa2x0_clock.c needs rewriting I guess to make it use OS Timer 0 or something. [patch 0003]. Current status of the boot process doesn't change though - it hangs in uvm_scheduler and doesn't go any further (doesn't hit the ramdisk). 14th March ~~~~~~~~~~ Dear diary. I can enter the irq_entry in arm/irq_dispatch.S (verified on Palm LifeDrive though turning on a LED hooked on a GPIO - write to a CPU register is an atomic operation) or at least if interrupt happens, it hits the begining of that function. The problem is it doesn't hit the pxa2x0_irq_handler(). Now why does this happen? It hangs exactly on PUSHFRAMEINSVC at line 97 there. What's best is, that if I comment it out, it hits the pxa2x0_irq_handler ... YAY! Ok, so the exact hangpoint is in arm/include/frame.h:270 (mov r2, sp; /* Save SVC up */). 15th March ~~~~~~~~~~ So it's fixed. Oh my goddess, the bug was where I never expected it to be. It was the kind that's really hard to find. Well enough blahs, it was at the end of palm_start.S. The problem was it was using an address range ending at 0xa3ffffff instead of 0xa1ffffff (it thought it had twice as much RAM as it actually has). So this is it, I can now boot into ramdisk. One more achievement followed not much later - NetBSD wasn't that hard to port to Palm hardware. The sources were really similar to OpenBSD's ones (which was pretty much expectable since OpenBSD took the ARM port from NetBSD some time ago). 16th March ~~~~~~~~~~ I added one more variable into pxammc_sc structure to allow configuration of MMC detect GPIO. Also, I fixed the pxa2x0_mmc.c driver to use this and added simple palmmmc.c driver to handle the card (power pin, supply insertion detection GPIO, configure the hardware properly) on Palm hardware. I still have issues with the card's capacity not being properly detected, but the card is recognised on insertion so I'm mostly there. 17th March ~~~~~~~~~~ The problem from yesterday was I missed the "option sd" in kernel config. The MMC card is now properly recognised on insertion. 8th April ~~~~~~~~~ The OpenBSD/Palm project was kind-of frozen for last three weeks because of the preparations for LinuxEXPO and all my energy being invested into the Linux4Palm project. Anyway, it's defrosted again and here are some nice news. The most important thing is, PalmTT5's USB port can be reconfigured to work as UHC (this is, USB Host Controller), but it isn't able to supply enough power for most USB devices. This can be solved easily by using powered USB hub though. Moreover it works with the standard Palm "HotSync" Cable. You only need to get USB gender converter from A to A which costs about 20CZK (1 USD or so) to get this working. (A - the port on the converted is the same and on your PC's mainboard - female). As I'm still having minor issues with this, the patch will be available later. The issues are mostly about the USB not being detected sometimes and also the OpenBSD pxa27x UHC probably having some GPIO misconfiguration. I already tested USB keyboard, USB thumbdrive and external USB harddrive and it appears to work properly.