About Paul Sokolovsky
Contact
pmiscml at gmail com
Depending on the general topic interest/importance, feel free to post to kernel-discuss/familiar mailing lists too, I watch them.
About my involvement with Linux porting to handhelds
I had been watching Handhelds.org for a couple of years, considering idea to port Linux to be far-fetched at that time. But my interest finally has shaped up as I decided that I wouldn't be buying a new handheld in the near future - my h4150 is still very good device which has got all that I need in hardware - size, BlueTooth/WiFi. And the fact that it's no longer supported by hardware and software vendor is something which should be helped with by Linux.Some wiki pages I contribute to/started/maintain:
-
PowerManagementSupportMatrix (probably needs restructuring/deprecation)
I also try to help guys PaulEggleton like with overall wiki maintenance. So, don't be surprised if I edit "your" page ;-). Remember, wiki is collaborative documentation and everyone is welcome to help improve it!
Notes on putting Linux to flash
(These are just random notes, to not forget what was found out.)
It seems there two following options for generic, more or less device independent support for bootloading Linux out of flash:
-
To create a fake WinCE ROM which will actually contain at least kernel, maybe entire rootfs, and flash it instead of WinCE image, so standard 2nd stage bootloader will load it. Pros: original 2nd level bootloader remains intact, so, if it has diagnostic/repair capabilities, they will be still available (in particular, it will be easy to flash WinCE back). Cons: No WinCE boot support will be available.
-
To replace original 2nd stage with generic one like HH.org bootldr or u-boot. Assuming there's a free space in flash at least for a kernel, it will allow to preserve WinCE and support dual boot. Likely, this new 2nd stage bootloader will load 3rd stage, i.e. LAB, which will either boot real kernel/rootfs from flash/card/whatever.
Timeline
-
2005-11-13: Subscribed to the h4100-port mailing list.
-
2005-11-29: Confirmed by bisecting that PXA suspend/resume broke in 2.6.13 comparing to 2.6.12. Turned out ot was fixed in 2.6.15
-
2005-11-29: Subscribed to the kernel-discuss mailing list.
-
2006-02-03: Proposal for asic3_mmc cross-machine refactor.
-
2006-02-05: Faced strange issue with ASIC3 suspend/resume, took few months to resolve
-
2006-05-30: Posted patch for h4000 ASIC3 suspend/resume problem, turned out to be as "simple" as initializing MSCx PXA registers after resume, what Linux kernel doesn't do (leaving that to bootloader). Anyway, this was second big issue I solved, and after that I felt "force" ;-).
-
2006-06-03: Started to work on final version asic3_mmc cross-machine refactor, based on the previous experiments.
-
2006-06-19: Final version of asic3_mmc cross-machine refactor posted.
-
2006-06-21: Granted write access to HandHelds.org Kernel CVS repository.
-
2006-08-20: Posted RFC for common button map for all HH.org PDA-type machines.
-
2006-08-24: Granted write access to OpenEmbedded Monotone repository.
-
2006-09-20: Unofficial Familiar 0.8.4 release for h4000.
-
2006-10-03: Received donation of h3900 device to support elaboration of 2.6 kernel port for it and advance userspace/distrubutions support. Contributor: Mr. Alex Deucher. Thank you!
-
2006-10-11: Posted patch for common button map for all HH.org PDA-type machines.
-
2006-10-18: Received donation of hx4700 device to support elaboration of 2.6 kernel port for it and advance userspace/distrubutions support. Contributor: preferred to stay anonymous, but many thanks!
-
2006-11-09: Upgraded HH.org kernel CVS to 2.6.18.
-
2006-11-14: Finished implementation of asic3_keys driver and making sure it works well with gpio_keys.
-
2006-11-21: With having common linux-handhelds-2.6_*.bb and consistent names for all iPaq machines, first phase of cleaning up HH.orh-maintained machines in OE.dev is complete.
-
2006-12-02: Upgraded HH.org kernel CVS to 2.6.19.
-
2006-12-19: Angstrom upgraded to 2.6.16-hh8 kernel with common buttonmap support.
-
2006-12-22: h3900 reached full "C" status, with partial "B" status, in other words, basic PDA functionality works!
-
2006-12-28: h3900 2.6 port added to OE.dev, requested support by Angstrom.
-
2007-01-04: Initial release of
defconfigman
-
2007-01-10: Started to revamp OPIE support in OE.dev, starting with cleaning up qte patchset.
-
2007-01-18: Received new contribution: h3600 and palmtt2 devices. Thanks! Now I have access to PXA250, PXA255, PXA270, StrongArm, OMAP devices.
-
2007-01-20: asus620 port updated in CVS. Thanks to Vincent Benony, asus620 maintainer.
-
2007-01-21: defconfigman kernel's sound tested to work with GPE. Both h3900 and h4000 in OE.dev now have defconfigs generated by defconfigman. h4000 updated to use modules for sound.
-
2007-02-16: Upgraded HH.org kernel CVS to 2.6.20.
-
2007-03-05: Continuous Integration system for kernel tree set up, http://handhelds.org/~pfalcon/busyb/buildlogs/
-
2007-03-17: Proposal to use Defconfigman-generated configs for kernel CVS, to improve consistency and CI coverage.
-
2007-04-11: GPIODEV API RFC posted to LKML/LAKML
-
2007-04-26: All 30 ports in HH.org CVS are buildable now (for 2.6.20)!
-
2007-05-01: SoC base drivers RFC posted to LKML.
-
2007-05-07: Upgraded HH.org kernel CVS to 2.6.21.
-
2007-05-11: ipkg speedup patches committed to OE.dev
-
2007-05-15: Mystery of PCMCIA ACX is solved, first WiFi ping on h4000!
Spaces to watch
Monotone notes
Resolving merge conflicts using vimdiff.
export EDITOR=vimdiff mtn merge
Don't trust anything that mtn/vim tells. It's all lie, listen here.
There will be 3 windows (aka buffers in vim-talk). From left to right:
-
The merge buffer. Yes, you must merge changes here. Initially it is seeded with the parent revision.
-
One conflicting revision, supposed yours.
-
Another conflicting repo, supposedly repo's.
Buffers are numbered from 1. To move among buffers in round-robin, use Ctrl+W, then W. To merge the current (on which cursor is) hunk of changes to the current buffer from another buffer, do:
:diffget <# of another buffer>obviously, in our case <# of another buffer> will be 2 or 3.
diffget can also can accept line range in usual vim-talk, if you ever fall that low, e.g. :1,3diffget 3
Once done, ":wq" the merge buffer (i.e. leftmost), and just :q others.
Whoa!