**** BEGIN LOGGING AT Mon Nov 10 03:00:00 2014
Nov 10 08:21:15 <lumag> Hello ant_work  blu
Nov 10 08:21:52 <ant_work> I have cooked up a present for jay7 to polish
Nov 10 08:21:55 <ant_work> https://github.com/andrea-adami/kexecboot/commits/master
Nov 10 08:23:20 <ant_work> there is always the problem you pointed...proper way is with lstat etc.
Nov 10 08:23:59 <ant_work> but I guess for a kernel symlink char buf[256] is enough
Nov 10 08:27:40 <ant_work> kexecboot digression finished...back to kernel testing...
Nov 10 12:39:54 <lumag> ant_work, one of my patches broke spi (mmc). Rolling back...
Nov 10 13:00:08 <lumag> ok, fixed :)
Nov 10 13:01:04 <lumag> [  166.799482] mmc0: new SD card on SPI
Nov 10 13:01:05 <lumag> [  166.814294] mmcblk0: mmc0:0000 SD01G 972 MiB
Nov 10 13:01:05 <lumag> [  166.883266]  mmcblk0: p1 p2
Nov 10 13:01:05 <lumag> [  176.186057] kjournald starting.  Commit interval 5 seconds
Nov 10 13:01:05 <lumag> [  176.393626] EXT3-fs (mmcblk0p2): using internal journal
Nov 10 13:01:07 <lumag> [  176.438288] EXT3-fs (mmcblk0p2): recovery complete
Nov 10 13:01:09 <lumag> [  176.443352] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
Nov 10 13:01:11 <lumag> [  176.753180] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Nov 10 13:01:16 <lumag> LABEL=My collie kernel
Nov 10 13:01:18 <lumag> KERNEL=/boot/zImage-my
Nov 10 13:06:12 <lumag> speed is about 200-220 kbytes/sec
Nov 10 13:06:30 <ant_work> tried the 32M mmc?
Nov 10 13:07:13 <lumag> Still 0 bytes length
Nov 10 13:07:38 <ant_work> RIP ?
Nov 10 13:08:00 <lumag> no.
Nov 10 13:08:18 <lumag> Maybe it does not implement the SPI protocol (it is permitted for MMC cards).
Nov 10 13:08:43 <lumag> I have another issue - 32M SD card also doesn't work.
Nov 10 13:09:25 <lumag> It is properly detected, but then reports error -38 to many-many commands
Nov 10 13:09:44 <lumag> [  669.596301] mmc0: new SD card on SPI
Nov 10 13:09:45 <lumag> [  669.623397] mmcblk0: mmc0:0000 S032B 29.6 MiB
Nov 10 13:09:45 <lumag> [  669.684828]  mmcblk0: p1
Nov 10 13:09:45 <lumag> [  669.877184] mmcblk0: error -38 sending status command, retrying
Nov 10 13:09:45 <lumag> [  669.883820] mmcblk0: error -38 sending status command, retrying
Nov 10 13:09:46 <lumag> [  669.890271] mmcblk0: error -38 sending status command, aborting
Nov 10 13:09:48 <lumag> [  669.896502] blk_update_request: I/O error, dev mmcblk0, sector 60792
Nov 10 13:09:50 <lumag> [  669.904607] mmcblk0: error -38 sending status command, retrying
Nov 10 13:09:54 <lumag> [  669.911057] mmcblk0: error -38 sending status command, retrying
Nov 10 13:09:56 <lumag> [  669.917694] mmcblk0: error -38 sending status command, aborting
Nov 10 13:10:12 <lumag> Works like a charm in a USB reader
Nov 10 13:10:40 <lumag> Another one:
Nov 10 13:10:49 <lumag> [  756.284061] mmc0: card lacks mandatory switch function, performance might suffer
Nov 10 13:10:50 <lumag> [  756.292868] mmc0: new SD card on SPI
Nov 10 13:10:50 <lumag> [  756.305030] mmcblk0: mmc0:0000 TWTTI 121 MiB
Nov 10 13:10:50 <lumag> [  756.384738]  mmcblk0: unknown partition table
Nov 10 13:10:50 <lumag> [  756.573936] mmcblk0: error -14 sending stop command, original cmd response 0x0, card status 0x0
Nov 10 13:11:44 <ant_work> hm..
Nov 10 13:11:58 <lumag> it works despite error -14.
Nov 10 13:12:33 <ant_work> is in mode0?
Nov 10 13:12:37 <lumag> Yes.
Nov 10 13:12:50 <ant_work> "For the MMC, it is not the SPI timing, both latch and shift actions are defined with rising edge of the SCLK, but it seems to work at mode 0 in the SPI mode"
Nov 10 13:13:08 <lumag> Another one failing with -38
Nov 10 13:13:25 <lumag> [  918.564377] mmcblk0: mmc0:0000 SD04G 3.69 GiB
Nov 10 13:13:25 <lumag> [  918.646450]  mmcblk0: p1 p2 p3
Nov 10 13:13:25 <lumag> [  918.843121] mmcblk0: error -38 sending status command, retrying
Nov 10 13:13:25 <lumag> [  918.849572] mmcblk0: error -38 sending status command, retrying
Nov 10 13:13:25 <lumag> [  918.856211] mmcblk0: error -38 sending status command, aborting
Nov 10 13:13:41 <lumag> Maybe it is a limitation of SPI protocol hidden somewhere.
Nov 10 13:13:46 <lumag> What is your source for ^^
Nov 10 13:13:53 <ant_work> plenty of info here: http://elm-chan.org/docs/mmc/mmc_e.html
Nov 10 13:15:00 <lumag> Another one works:
Nov 10 13:15:02 <lumag> [  997.759990] mmc0: new SD card on SPI
Nov 10 13:15:02 <lumag> [  997.783867] mmcblk0: mmc0:0000 00000 1.83 GiB
Nov 10 13:15:02 <lumag> [  997.845057]  mmcblk0: p1
Nov 10 13:15:02 <lumag> [  998.035253] mmcblk0: error -14 sending stop command, original cmd response 0x0, card status 0x0
Nov 10 13:15:02 <lumag> [ 1000.888217] mmcblk0: error -14 sending stop command, original cmd response 0x0, card status 0x0
Nov 10 13:16:02 <lumag> Thanks for the pointer
Nov 10 13:16:39 <ant_work> take a look at the benchmarks they give...
Nov 10 13:16:52 <ant_work> old cards prolly
Nov 10 13:29:27 <lumag> I have a theory about status commands.
Nov 10 13:30:45 <lumag>         cmd.opcode = MMC_SEND_STATUS;
Nov 10 13:30:45 <lumag>         if (!mmc_host_is_spi(card->host))
Nov 10 13:30:45 <lumag>                 cmd.arg = card->rca << 16;
Nov 10 13:30:45 <lumag>         cmd.flags = MMC_RSP_SPI_R2 | MMC_RSP_R1 | MMC_CMD_AC;
Nov 10 13:31:01 <lumag> So maybe we are missing an argument for SEND_STATUS command on SPI bus
Nov 10 13:32:39 <ant_work> I can't find anymore a site listing the locomo/spi regs
Nov 10 13:32:52 <ant_work> I found this in the meanwhile (2006)
Nov 10 13:32:58 <ant_work> http://lists.openmoko.org/pipermail/community/2006-December/000712.html
Nov 10 13:35:29 <lumag> https://github.com/lumag/sharp-kernel/blob/v2.4.20-c3200-1.01/include/asm-arm/arch-pxa/poodle.h
Nov 10 13:37:33 <lumag> From the kernel log:
Nov 10 13:37:35 <lumag>     The newest categories of cards supported by the MMC stack aren't expected
Nov 10 13:37:35 <lumag>     to work yet with SPI:  MMC or SD cards with over 4GB data, and SDIO.
Nov 10 13:37:35 <lumag>     All those cards support SPI mode, so eventually they should work too.
Nov 10 13:37:35 <lumag>     
Nov 10 13:38:12 <lumag> So some bits might be missing for mmc-spi
Nov 10 13:41:10 * lumag is in strong need of some SDIO cards to test.
Nov 10 13:54:31 <lumag> ant_work, I've sent you the most recent LoCoMo patchset that I have locally.
Nov 10 13:55:11 <lumag> I will need to reimplement the core (regmap instead of raw register writes), but I hope functionality won't change anymore.
Nov 10 14:04:55 <lumag> spi driver might receive a boost by switching to irqs (from busy looping). But that would be the next step
Nov 10 14:06:15 <ant_work> ok, I'll test
Nov 10 14:06:48 <ant_work> does SDIO really work on old hw?
Nov 10 14:06:57 <ant_work> I don't have any card...
Nov 10 14:07:05 <lumag> neither me.
Nov 10 14:07:13 <lumag> It should work iff the interrupt is routed.
Nov 10 14:10:57 <lumag> AFAIR it is routed on collie, tosa and spitz
Nov 10 14:12:33 <lumag> I think it should be routed on poodle and corgi
Nov 10 14:12:46 <lumag> At least poodle header names it and corgi has it commented.
Nov 10 14:13:09 <lumag> Ah, no
Nov 10 14:13:14 <lumag> corgi also has a pin.
Nov 10 14:13:30 <lumag> So (in theory) all Z should be SDIO -capable
Nov 10 14:17:18 <ant_work> found the link...
Nov 10 14:17:20 <ant_work> http://josejx.net/collie/
Nov 10 14:17:44 <ant_work> maybe there is smthg more
Nov 10 14:55:14 <lumag> ant_work, mostly nothing new.
Nov 10 14:55:47 <lumag> The only interesting part are the conditions in TX/RX for busyloops
Nov 10 14:56:14 <lumag> However I observe no timeouts on rx/tx, so this should not be the case.
Nov 10 14:56:16 <lumag> Hopefully.
Nov 10 14:56:33 <lumag> I will recheck.
Nov 10 15:02:11 <lumag> No, no timeouts
Nov 10 15:02:23 <lumag> So it's either some bug in card firmware, or bug in mmc_spi
Nov 10 15:04:28 <ant_work> ok
Nov 10 15:04:37 <ant_work> I noticed it says 2s from cold boot...
Nov 10 15:05:20 <ant_work> perhaps kexecboot will need some more delay
Nov 10 15:06:02 <lumag> ?
Nov 10 15:06:30 <ant_work> for the detection
Nov 10 15:06:43 <ant_work> but the cards I have were all detected by old 2.6.31
Nov 10 15:07:29 <lumag> I see the comment. Probably that is usecs (or msecs) and that is after powering the socket.
Nov 10 15:08:10 <lumag> Because I can hardly imagine the 2 seconds delay for mmc to work.
Nov 10 15:09:11 <lumag> BTW: I noticed that 'kernel' project was marked as private in asana. Marked it as public, so you should be able to see it.
Nov 10 15:09:32 <lumag> Is anybody else interested in tracking issues with PDAs?
Nov 10 15:09:34 <lumag> bluelightning, ^^
Nov 10 15:09:51 <bluelightning> in general, yes
Nov 10 15:21:34 <ant_work> lumag: we have delay 2 secs for all devices but spitz which needs 3
Nov 10 15:21:49 <lumag> Hmm?
Nov 10 15:21:53 <ant_work> this to detect some ancient CF
Nov 10 15:22:52 <ant_work> if you don't have any mtd image kexecboot would scan too quickly
Nov 10 15:23:02 <ant_work> so we added delay
Nov 10 15:24:35 <ant_work> (we should have checked for device presence, I know ;)
Nov 10 15:26:35 <lumag> maybe we should use udev notifications?
Nov 10 15:26:39 <lumag> somehow.
Nov 10 15:41:44 <ant_work> must be done from within kexecboot, no shell, no udev
Nov 10 15:41:58 <ant_work> ..no space...
Nov 10 15:42:28 <lumag> Receiving hotplug events directly from kernel?
Nov 10 15:43:37 <ant_work> maybe but still, how long should you wait? You don't know what  to expect
Nov 10 15:45:39 <lumag> yes.
Nov 10 15:46:27 <lumag> That is why receiving hotplug events from kernel might be better - kexecboot will be able to update 'kernels' screen as new devices are discovered.
Nov 10 15:46:37 <lumag> Or removed
Nov 10 15:46:59 <lumag> But that is probably huuge refactoring.
Nov 10 16:37:10 <ant_work> ok, heading home now
Nov 10 16:37:41 <ant_work> later I'll fix couple of malloc() in kexecboot (missing +1 after strlen...)
Nov 10 16:37:50 <ant_work> then I'll pass to SD test on collie
Nov 10 16:37:54 <ant_work> bbl
Nov 10 20:44:29 <lumag_> On e-bay tosa goes for 60 USD
Nov 10 23:06:51 <ant__> bluelightning, do you think we can upload some linux-kexecboot binaries on meta-hh?
Nov 10 23:10:31 <ant__> bluelightning, 2nd question is, should I point kexecboot SRC_URI to my github until Jay7 updates upstream? Or adding patches to the metadata?
Nov 10 23:19:30 <Jay7> night ppl
Nov 10 23:19:53 <Jay7> I've forgot to start my irc client about a week ago
Nov 10 23:19:53 * ant__ summoned Jay7
Nov 10 23:20:07 <Jay7> hehe )
Nov 10 23:20:27 <ant__> how are you doing?
Nov 10 23:20:38 <Jay7> very busy with strange things
Nov 10 23:20:51 <Jay7> I have coworking space now
Nov 10 23:21:10 <Jay7> working there as barista as well )
Nov 10 23:21:15 <bluelightning> ant__: I'm not sure we'd want to distribute binaries within the repo itself...
Nov 10 23:21:53 <ant__> today's problem is, main site is down and there isn't any copy of the installers around...
Nov 10 23:21:57 <Jay7> how are things in kexecboot-land? )
Nov 10 23:22:13 <Jay7> main site should go online this week
Nov 10 23:22:15 <Jay7> I hope
Nov 10 23:22:21 <ant__> just today I could finally fix the absolute symlink issue
Nov 10 23:22:28 <Jay7> anyway we should move to github pages
Nov 10 23:22:34 <ant__> need your help/debug ofc
Nov 10 23:22:46 <ant__> & valgrind
Nov 10 23:23:05 <ant__> https://github.com/andrea-adami/kexecboot/commits/master
Nov 10 23:23:41 <ant__> bluelightning, debugging right now zaurus installer: th einstallkits are missing the zImage :/
Nov 10 23:24:59 <Jay7> ant__: cool!
Nov 10 23:25:16 <Jay7> we should merge it almost as is
Nov 10 23:25:26 <Jay7> I dislike CONCAT name
Nov 10 23:25:39 <ant__> it compiles w/out warnings
Nov 10 23:25:46 <ant__> ah..yes..SQL ;)
Nov 10 23:25:58 <ant__> fix it as you like
Nov 10 23:26:08 <Jay7> it will be better to rename to something like APPEND_MOUNTPATH e.g.
Nov 10 23:26:20 <ant__> big doubt are the malloc
Nov 10 23:26:25 <ant__> ^_^
Nov 10 23:27:03 <Jay7> it's place for errors )
Nov 10 23:27:10 <ant__> they are too large
Nov 10 23:27:26 <ant__> should be defined for each branch of the if
Nov 10 23:27:33 <ant__> n
Nov 10 23:27:45 <Jay7> easy thing is to remove checks
Nov 10 23:27:57 <Jay7> with overcommit enabled there is no sense
Nov 10 23:28:25 <Jay7> malloc will return good value, but first write will fail
Nov 10 23:28:38 <Jay7> but I'm unsure about this
Nov 10 23:28:58 <ant__> I've tested right now all possible cases: file, rel symlink, absolute symlink
Nov 10 23:29:00 <Jay7> other way is to create wrapper around malloc with check and exit() e.g.
Nov 10 23:29:29 <Jay7> or may be assert()
Nov 10 23:30:41 <lumag_> Hello ant__ Jay7
Nov 10 23:30:49 <Jay7> hi lumag_
Nov 10 23:30:58 <ant__> hi lumag_
Nov 10 23:31:13 <ant__> Jay7 was evocated by my horror code of yesterday ;)
Nov 10 23:31:19 <lumag_> :)
Nov 10 23:31:29 <Jay7> ))
Nov 10 23:31:43 <Jay7> lumag_: have you any idea how to implement hotplug?
Nov 10 23:31:43 <lumag_> Regarding websites. It is possible to put a website on GitHub.
Nov 10 23:31:55 <Jay7> we should move to github
Nov 10 23:32:02 <Jay7> hosting is very unreliable now
Nov 10 23:32:03 <ant__> +1
Nov 10 23:32:24 <ant__> github should stay free for a while and is stable (today)
Nov 10 23:32:37 <lumag_> Jay7, not yet. I have an idea that kexecboot can hook into kernel using the same interface as udev/mdev do.
Nov 10 23:32:59 <lumag_> However that is completely gray area for me. I know several keywords and nothing more :(
Nov 10 23:33:03 <Jay7> yeah, that was in out todo for some years )
Nov 10 23:33:18 <ant__> anyway the mtd scanning takes >2s
Nov 10 23:33:29 <Jay7> afaik, it's netlink proto
Nov 10 23:34:01 <ant__> we already have that delay
Nov 10 23:34:17 <lumag_> ant__, theoretically all scanning can be made parallel.
Nov 10 23:34:23 <lumag_> reg. hosting on github.
Nov 10 23:35:10 <lumag_> For my side project I did that: https://github.com/GostCrypt/gostcrypt.github.io
Nov 10 23:35:59 <lumag_> They provide nice framework for building semi-static sites.
Nov 10 23:37:57 <lumag_> I don't know what is the policy regarding binary files though
Nov 10 23:41:55 <ant__> Jay7, btw the machine-kernel part is ugly
Nov 10 23:42:12 <ant__> I was tempted to remove all
Nov 10 23:42:18 <Jay7> may be it's time to drop it?
Nov 10 23:42:22 <ant__> +1
Nov 10 23:43:39 <ant__> we can use symlinks
Nov 10 23:55:14 * Jay7 -> sleep
Nov 10 23:55:18 <Jay7> see you
Nov 10 23:56:28 <lumag_> gn
Nov 10 23:56:36 * lumag_ should go to sleep too
Nov 10 23:56:47 <ant__> gn
**** ENDING LOGGING AT Tue Nov 11 03:00:00 2014