**** BEGIN LOGGING AT Thu Nov 14 02:59:59 2013
Nov 14 09:41:33 <ant_work> bluelightning: gm  http://imgbin.org/index.php?page=image&id=15672
Nov 14 09:42:17 <ant_work> sweet & sour
Nov 14 09:43:18 <ant_work> is zaurusd behaving correctly?
Nov 14 09:43:55 <ant_work> and why irda on ttyS1? Is ttySA1
Nov 14 09:47:30 <bluelightning> ant_work: if /etc/sysconfig/irda doesn't exist then that's the default in the irda-utils initscript
Nov 14 09:48:45 <ant_work> anyway it is bizarre that the configs of zaurusd are on yoctoproject
Nov 14 09:49:17 <ant_work> seems lacking this collie patch http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg08440.html
Nov 14 09:54:39 <bluelightning> why bizarre?
Nov 14 09:55:06 <bluelightning> it was created & maintained by openedhand... pretty much all openedhand stuff got moved to yoctoproject.org
Nov 14 09:56:15 <ant_work> well, seems unmaintained. I know RP has plans to extend it
Nov 14 09:56:43 <ant_work> are you sur zaurusd doesn't predate OpenHand?
Nov 14 09:57:57 <bluelightning> I don't believe so
Nov 14 09:58:19 <ant_work> wasn't in Familiar?
Nov 14 09:58:55 <bluelightning> no, if you recall Familiar was much more of an iPAQ distribution until some of the later versions
Nov 14 09:59:15 <bluelightning> it's unmaintained at the moment; but FWIW I'm now the maintainer for the recipe in OE-Core
Nov 14 09:59:28 <ant_work> in 2006 it was in OE
Nov 14 09:59:46 <bluelightning> so that might give me some influence over zaurusd itself :)
Nov 14 10:00:02 <ant_work> there was a modern fork but unsuitable iirc
Nov 14 10:00:53 <ant_work> http://metan.lindevdoc.org/git/?p=zaurusd.git/.git;a=summary
Nov 14 10:01:14 <ant_work> stanislav wrote
Nov 14 10:01:15 <ant_work> RP zaurusd/switchevd:
Nov 14 10:01:15 <ant_work> Screen rotation in X
Nov 14 10:01:15 <ant_work> Audio plug insert/remove
Nov 14 10:01:15 <ant_work> Some ugly hacks to control backlight
Nov 14 10:01:15 <ant_work> Metan zaurusd:
Nov 14 10:01:16 <ant_work> LCD on/off
Nov 14 10:01:18 <ant_work> Backlight control
Nov 14 10:01:21 <ant_work> Suspend/resume control
Nov 14 10:01:23 <ant_work> Save time on power loss
Nov 14 10:01:29 <ant_work> "They are feature incompatible."
Nov 14 10:02:52 <bluelightning> right, i remember the analysis
Nov 14 10:04:08 <ant_work> rigth now on collie backlight doesn't resume
Nov 14 10:04:40 <ant_work> I have to test on one other model to verify
Nov 14 10:08:51 <bluelightning> could be that the backlight device changed
Nov 14 10:09:01 <bluelightning> I'm pretty sure I had to change code for that in Opie
Nov 14 10:09:57 <ant_work> hopefully is only userspace problem.. lumag?
Nov 14 10:11:34 <lumag>  Didn't test it yet.
Nov 14 10:11:50 <lumag> Just got to work today.
Nov 14 10:13:04 <ant_work> lumag: sorry again for the nightly "tour de force" last days;) Thenk you very much
Nov 14 10:23:07 <lumag> N/p, I'm mostly 'arithmic' these days.
Nov 14 10:24:32 <lumag> I've bought myself a gift - a 16Gb CF card.
Nov 14 10:24:45 <lumag> More space for OE rootfses
Nov 14 10:28:18 <lumag> ant_work, on sa1100 irda should not use /dev/ttyS* at all.
Nov 14 10:28:30 <lumag> use irda0 directly
Nov 14 10:29:11 <ant_work> hm.. it has been so long that I don't remember anymore that ppp and serial ports...
Nov 14 10:29:28 <lumag> :)
Nov 14 10:30:02 <ant_work> what creates the ir* devices? irda module or irattach?
Nov 14 10:32:40 <lumag> That depends.
Nov 14 10:32:48 <ant_work> ah, ok SIr vs. FIR
Nov 14 10:33:15 <ant_work> sa1100_ir
Nov 14 10:33:18 <lumag> If you have a SIR/FIR attached to serial port, you use irattach to bind dongle driver to that serial port (and thus to create irda0).
Nov 14 10:33:55 <lumag> If you have directly connected IrDA transceiver, you already have irda0 device and thus you use irattach only to up/down it and to control 'discoverable' properties.
Nov 14 10:34:25 <lumag> In theory one can control sa1100 irda transceiver even w/o irattach (using ifconfig and sysctls).
Nov 14 10:34:50 <lumag> But it is somewhat like reading webpages through telnet. Possible, but not user friendly.
Nov 14 10:35:20 <lumag> Got my kernel up and running on sa1100
Nov 14 10:36:27 <lumag> Now it's time to test OE's kernel
Nov 14 10:36:58 <lumag> (mine has an initramfs bundled, no command line arguments required, etc - perfect for low level debugging)
Nov 14 10:37:32 <ant_work> I had no time to strip away MD and other features...
Nov 14 10:38:23 <ant_work> is done by adding an extra cfg fragment with the "# CONFIG_BLAH is not set"
Nov 14 10:40:21 <lumag> n/p
Nov 14 10:40:54 <lumag> I won't touch 2.6.31 for some time, so size of contemporary kexecboot doesn't matter for me.
Nov 14 10:41:24 <lumag> Hmm. Tosa with two cf cards working in a raid. Redundant solution.
Nov 14 10:41:30 <ant_work> ok, fyi linux-yocto-tiny-kexecboot_3.10 for collie is today 990kb
Nov 14 10:43:06 <lumag> What is the space requirement? 1M?
Nov 14 10:43:12 <ant_work> 1024
Nov 14 10:43:20 <lumag> so it fits
Nov 14 10:43:30 <lumag> Blah. klibc failed
Nov 14 10:43:38 <ant_work> ?
Nov 14 10:44:26 <lumag> Concurrency issues. It uses header  before header gets built
Nov 14 10:45:12 <ant_work> hm.. strange, you should have linux-libc-headers(-dev) already staged
Nov 14 10:45:19 <lumag> http://pastebin.com/Lwp29L9K
Nov 14 10:46:04 <ant_work> ah, its own header?
Nov 14 10:46:07 <lumag> yeah.
Nov 14 10:46:21 <ant_work> you must have a rocket buildhost there ;)
Nov 14 10:47:01 <lumag> I asked colleagues to install icecc on their boxes.
Nov 14 10:47:11 <lumag> Thus I can steal their cpu cycles.
Nov 14 10:48:42 <ant_work> fix by hand or disable parallel build I'd say
Nov 14 10:49:04 <lumag> Just executed manual do_compile and it fixed
Nov 14 10:50:48 <ant_work> tehre is a nasty issue with klcc-cross but you shouldn't hit it
Nov 14 10:51:31 <ant_work> it could happen if you'd build for h3600 for example... the first klcc-cross built is hardcoding sysroot paths
Nov 14 10:51:44 <ant_work> so two builds for the same arch will fail :/
Nov 14 10:52:04 <ant_work> after kernel is my top priority...
Nov 14 11:03:34 <lumag> I remember few years ago I 'fixed' klibc/klcc by making them per-machine.
Nov 14 11:03:46 <lumag> per-machine packages, rather than per-arch.
Nov 14 11:03:53 <lumag> But I never submitted patches upstream.
Nov 14 11:04:11 <ant_work> the problem is difefrent nowadays
Nov 14 11:04:17 <lumag> Got nice backtraces after removing cf card about missing sysfs files.
Nov 14 11:04:42 <lumag> It looks like pcmcia will also need some small 'tend'
Nov 14 11:05:25 <ant_work> the problem we have today is the klibc headers are arch-specific but in oe the sysroot is now machine-specific
Nov 14 11:05:48 <ant_work> about pcmcia..booting from CF I've never removed the card purposedly...
Nov 14 11:08:14 <lumag> I booted from cf card, but I had initramfs, so cf was not mounterd
Nov 14 11:09:15 <lumag> ant_work, what is the difference between core-image-basic and core-image-base?
Nov 14 11:09:20 <lumag> Which one should I use?
Nov 14 11:10:35 <ant_work> good question...
Nov 14 11:10:41 <ant_work> I buid -base normally
Nov 14 11:10:53 <ant_work> it has most utils
Nov 14 11:12:01 <lumag> ok. kexecboot failed.
Nov 14 11:12:12 <ant_work> yes
Nov 14 11:12:14 <lumag> It shows blueish screen and nothing else
Nov 14 11:12:17 <ant_work> same
Nov 14 11:12:31 <ant_work> really need to refresh the defconfig
Nov 14 11:13:01 <lumag> And we should switch from LZMA for collie.
Nov 14 11:13:05 <lumag> It is painfully slow
Nov 14 11:13:18 <ant_work> yes, collie is very slow
Nov 14 11:13:28 <lumag> It is lzma.
Nov 14 11:13:33 <lumag> gzip is much faster I think
Nov 14 11:13:34 <ant_work> no, copy and decompress on pxa is much quicker
Nov 14 11:13:43 <ant_work> is just 1mb
Nov 14 11:13:56 <ant_work> maybe som ecache is disabled on boot?
Nov 14 11:14:07 <lumag> no display with collie kernel
Nov 14 11:14:12 <lumag> and no console
Nov 14 11:14:23 <ant_work> which one? 3.10 ?
Nov 14 11:14:43 <lumag> yes
Nov 14 11:16:07 <ant_work> the 'old' linux-kexecboot could launch core-image-base built yesterday
Nov 14 11:16:31 <ant_work> adn core-image-sato as well (a bit b0rked)
Nov 14 11:16:42 <ant_work> pull from yesterday evening
Nov 14 11:17:23 <ant_work> try a cold boot pls
Nov 14 11:17:59 <lumag> Strange. It finds sda & partitions and then hangs.
Nov 14 11:18:10 <ant_work> hm.. maybe the CF size?
Nov 14 11:18:40 <lumag> It should not matter.
Nov 14 11:19:52 <ant_work> brb
Nov 14 11:22:03 <lumag> ant_work, same issue: stall after sda being detected
Nov 14 11:25:01 <lumag> Hmm. Somehow it did not rebuild kernels.
Nov 14 11:50:22 <ant_work> try bitbake -c cleansstate linux-yocto
Nov 14 11:50:50 <ant_work> and rebuild
Nov 14 12:12:02 <lumag> yes, did that.
Nov 14 12:12:16 <lumag> BTW: issues I saw were related to scsi/ata, but not to pcmcia.
Nov 14 12:13:04 <lumag> I see logo
Nov 14 12:14:19 <lumag> But still no output after sda probing finished
Nov 14 12:14:23 <lumag> *finishes
Nov 14 12:15:16 <ant_work> afair I've tested the common fragments for SCSI/ATA on spitz/poodle/c7x0 and all was normal
Nov 14 12:15:29 <ant_work> but iirc I had issues with a 4GB unpartitioned card
Nov 14 12:15:41 <ant_work> I had to make a small partition
Nov 14 12:16:25 <ant_work> note that I've tested rather well 3.2 and just a bit 3.8
Nov 14 12:16:49 <ant_work> 3.10 is almost untested (I was waiting for vanilla 3.12 ;)
Nov 14 12:18:16 <ant_work> how is formatted the card?
Nov 14 12:18:41 <ant_work> you said kexecboot had no problems identifying
Nov 14 12:18:46 <lumag> multiple partitions.
Nov 14 12:19:19 <lumag> Don't bother about that issue. It tells that some attribute groups are not enabled for scsi 'host0' object - some issues in ata/scsi core.
Nov 14 12:19:38 <ant_work> ok, but you still don't boot...
Nov 14 12:19:59 <lumag> I think those are unrelated issues.
Nov 14 12:20:10 <ant_work> see, you could build a coreimage-base and flesh yje .jffs2 on mtd
Nov 14 12:20:16 <ant_work> argh
Nov 14 12:20:27 <ant_work> flash the .jffs2 on mtd2
Nov 14 12:21:57 <ant_work> you'll see a padded image righ to the exact partition size. Rename it initrd.bin and flash it with C+D + Reset
Nov 14 12:22:31 <ant_work> but core-image-base lack many utils
Nov 14 12:23:23 <lumag> I would think that is is a card problem (it is new 133x card), but 2.6.31 can read it w/o issues.
Nov 14 12:23:46 <ant_work> interesting then :p
Nov 14 12:24:17 <ant_work> maybe misconfigured kernel?
Nov 14 12:25:04 <ant_work> you can do bitbake -c menuconfig an see
Nov 14 12:26:37 <lumag> ok. I disabled mtd and looks like it will boot
Nov 14 12:26:59 <ant_work> ah, maybe is the jffs2 image you have on flash
Nov 14 12:27:56 <lumag> Maybe
Nov 14 12:28:05 <lumag> No. I have cramfs, not jffs2
Nov 14 12:28:21 <ant_work> ok, the extract that old kernel while there ;)
Nov 14 12:28:43 <lumag> kernel is not on cramfs, isn't it?
Nov 14 12:28:46 <ant_work> you can mount th eSharprom
Nov 14 12:28:55 <ant_work> yes, is enabled on purpose ;)
Nov 14 12:29:46 <ant_work> hm, I see what you mean kernel was on mtd1
Nov 14 12:29:56 <lumag> yes, I will extract it from Ospack
Nov 14 12:29:57 <ant_work> I've mounted that cramfs anyway
Nov 14 12:30:06 <ant_work> driver is compiled in
Nov 14 12:30:23 <lumag> OK. without sa1100-mtd it boots.
Nov 14 12:30:41 <ant_work> worth further mtd debugging on your device ;)
Nov 14 12:30:56 <lumag> step-by-step.
Nov 14 12:31:01 <ant_work> joking
Nov 14 12:31:04 <lumag> Current priority list:
Nov 14 12:31:28 <lumag> 1) merge irq/gpio stuff to mainline
Nov 14 12:31:35 <lumag> 2) merge clocks fixes
Nov 14 12:31:42 <lumag> 3) finish and merge locomo cleanup
Nov 14 12:32:14 <lumag> I will do mtd tests somewhere inbetween.
Nov 14 12:32:19 <ant_work> yes please do
Nov 14 12:32:28 <ant_work> then spi/mmc
Nov 14 12:32:39 <lumag> Hmm. You were right voltage now = 0
Nov 14 12:32:56 <lumag> But I am sure that battery is not completely dead.
Nov 14 12:33:50 <lumag> so 4) spi/mmc
Nov 14 12:33:53 <lumag> 5) battery
Nov 14 12:34:41 <ant_work> heh
Nov 14 12:34:51 <ant_work> and shutdown...
Nov 14 12:35:08 <ant_work> but maybe those like backlight are userspace issues
Nov 14 12:36:18 <lumag> Then without order: pcmcia cleanup, shutdown, clocks, audio, udc, backlight, scoop refactoring, device tree, conquer world, etc.
Nov 14 12:36:56 <ant_work> hehe
Nov 14 12:37:20 <ant_work> we can fix zaurusd/userland in short time
Nov 14 12:37:28 <ant_work> kernel is much harder work
Nov 14 12:38:00 <ant_work> now until we have SD I'd like to have an OPIE image for collie
Nov 14 12:38:04 <ant_work> for MTD
Nov 14 12:38:13 <lumag> ant_work, bluelightning while digging old hh.org wiki, I had a flash idea. Do we need a wiki, describing all our handhelds-related (little) efforts, statuses, hacks, hints, etc?
Nov 14 12:39:58 <ant_work> pls let me rule out defects on my chips, I don't think there are but you know..10yrs..used device...10Euro...
Nov 14 12:40:42 <lumag> ant_work, :)
Nov 14 12:40:45 <ant_work> lumag: once you reach console use flashcp
Nov 14 12:41:04 <lumag> ant_work, I have console.
Nov 14 12:41:18 <lumag> Let's agree for me to run mtd tests somewhere next week?
Nov 14 12:41:57 <ant_work> when you can. all what it needs is a   flashcp ./initrd,bin /dev/mtd2
Nov 14 12:42:02 <ant_work> never successfull here
Nov 14 12:42:16 <ant_work> add -v as well
Nov 14 12:42:21 <lumag> flashcp: command not found :(
Nov 14 12:42:28 <ant_work> core-image-base
Nov 14 12:42:35 <lumag> Heh, will do
Nov 14 12:42:51 <ant_work> collie login: root
Nov 14 12:42:52 <ant_work> root@collie:~# flashcp -v /dev/mtd2 /initrd.bin
Nov 14 12:42:52 <ant_work> This doesn't seem to be a valid MTD flash device!
Nov 14 12:42:52 <ant_work> root@collie:~# flashcp -v /initrd.bin /dev/mtd2
Nov 14 12:42:52 <ant_work> Erasing blocks: 112/112 (100%)
Nov 14 12:42:52 <ant_work> Writing data: 14336k/0k (100%)%)
Nov 14 12:42:54 <ant_work> Verifying data: 10500k/0k (14336%)File does not seem to match flash
Nov 14 12:42:56 <ant_work> data. First mismatch at 0x00a3e800-0x00a41000
Nov 14 12:42:58 <ant_work> root@collie:~#
Nov 14 12:45:38 <ant_work> and if you do a flash_erase (or the old flash_eraseall -j /dev/mtd2) your kernel will survive to boot, once wiped outthe old cramfs/cruft
Nov 14 12:46:00 <ant_work> I've had empty flash for long...
Nov 14 12:49:40 <lumag> Strnage. Now gzip is also painfully slow.
Nov 14 12:50:47 <ant_work> only collie is slow at copy to ram/decompress imho
Nov 14 13:09:57 <lumag> ant_work, I found how to solve a problem with backlight.
Nov 14 13:10:01 <lumag> At least I hope so.
Nov 14 13:10:18 <lumag> Revert 5a3778e2f57e5fb1f6e060586f5850dd87b5320f
Nov 14 13:10:36 <lumag> Locomo does not support dev_pm_ops
Nov 14 13:10:47 <lumag> Would like to kick somebody
Nov 14 13:12:04 <lumag> So suspend/resume methods are not called at all.
Nov 14 13:12:35 <lumag> I will send a better patch to you.
Nov 14 13:36:51 <ant_work> I see
Nov 14 13:36:53 <ant_work> thx
Nov 14 13:44:16 <ant_work> lumag: what do you think, should we remove the erase/suspend MTD patch?
Nov 14 13:46:57 <ant_work> instead of disabling, there are fixups
Nov 14 13:47:55 <ant_work> in cmdset_0002
Nov 14 13:51:47 <lumag> ant_work, I don't know :(
Nov 14 13:51:52 <lumag> gtg now
Nov 14 13:51:54 <lumag> bye
Nov 14 13:52:00 <ant_work> cu
Nov 14 13:53:16 <lumag> btw: you can check suspend/resume w/o apm
Nov 14 13:53:25 <lumag> echo mem > /sys/power/state
Nov 14 13:53:25 <lumag> :)
Nov 14 18:25:56 <ant_home> lumag: shoul I use the @mentor email for your patches in meta-hh ?
Nov 14 22:27:55 <ant_home> bluelightning: I have two new patches in queue on github. I hope to add a third for l-y-t-kexecboot in a while. Rebuild triggered...
Nov 14 22:28:24 <ant_home> I have to say that those day on each pull the toolchain is rebuilt
Nov 14 22:50:11 <bluelightning> ant_home: ok
Nov 14 22:50:39 <bluelightning> ant_home: well, you could try not pulling every day...
Nov 14 22:51:55 <bluelightning> the way signatures are built up, unfortunately changing some low-level functions forces just about everything to rebuild
Nov 14 23:18:21 <ant_home> heh | ERROR: This kernel (size=1058824 > 1048576)
Nov 14 23:29:13 <ant_home> I could earn 8kb uncompressed if we disable /proc/sys checks
Nov 14 23:29:17 <ant_home> Jay7: ^^
Nov 14 23:48:47 <ant_home> lumag: trying now to compress with xz
Nov 14 23:59:57 <ant_home> heh  *zImage          │1040520│Nov 15 00:58│
Nov 15 00:00:14 <ant_home> (disabled nand and jedec too)
Nov 15 00:05:48 <ant_home> hm.. still blue :/
Nov 15 00:05:56 <ant_home> will fix tomorrow
Nov 15 00:05:57 <ant_home> gn
**** ENDING LOGGING AT Fri Nov 15 02:59:58 2013