#qi-hardware IRC log for Thursday, 2012-03-29

qi-bot[commit] David Kühling: liballegro: fix keyboard readout deadlock triggered in some of the examples (master) http://qi-hw.com/p/openwrt-packages/2ee0f6e00:30
qi-bot[commit] David Kühling: alpy: fix (workaround) segfault caused by openwrt dynamic linker pecularities (master) http://qi-hw.com/p/openwrt-packages/caaecfd00:30
whitequarkwpwrak: if I understand anything about software development, then kicad is going to die pretty soon :/01:10
whitequarkwell, it may have an indefinitely long agony, of course01:11
wpwrakwhitequark: well, let's hope you're wrong :)05:32
wpwraki think what needs to happen is a generation change in the core development team. there doesn't seem to be a lack of people who'd be willing to do things. just need to get a bit more organized.05:36
shevekNot long ago, I browsed the kernel source at http://projects.qi-hardware.com, but now I can't find it anymore. I see is openwrt xburst some kernel stuff, but not the source itself. Is there something wrong with the site, or am I looking in the wrong place?07:33
sheveks/I see is openwrt xburst/In OpenWRT XBurst I see/07:34
shevekYeah, that. :-D07:34
shevekCool feature. :-)07:35
xiangfushevek, openwrt xburst keep the patch. not all source code.07:37
xiangfushevek, if you want look the patch on nanonote. check out here: 07:38
xiangfushevek, : http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/target/linux/xburst/patches-3.207:38
xiangfuthose patches are for v3.2.107:39
shevekxiangfu: Yes, I found those, but I remember I was browsing the full kernel source (not sure if it included all the patches).07:39
xiangfushevek, there is. but the browsing is not working any more. 07:39
xiangfu: http://projects.qi-hardware.com/p/qi-kernel/07:39
xiangfubut you can still 'git clone'07:39
shevekAh, that explains it.07:40
shevekI'll do that then.07:40
xiangfugit clone git://projects.qi-hardware.com/qi-kernel.git07:40
shevekThanks!07:41
xiangfuif you have patch. please send them to mailing list or me :-)07:41
shevekI won't, I'm just looking at how power down works so I can copy it in Iris. :-) Currently I can power down, but it doesn't power up again.07:42
shevekStill, if I see bugs while looking at the code, I'll let you know. :-)07:43
xiangfushevek, great. are you 'Bas Wijnen'? (sorry I always can't remember the English name)07:44
shevekxiangfu: Yes, I am. Sorry about the nick. ;-)07:45
xiangfushevek, nope.  nick is good. 07:46
mthshevek: on the Dingoo, power up is done by making the GPIO connected to the power button generate an interrupt, iirc08:07
mthnot sure how it works on the NN, since it has a keyboard matrix rather than direct button to GPIO like the Dingoo08:08
mthbut maybe the power button is not in the keyboard matrix08:08
shevekIt is not indeed, but that's not the problem I think. What we call power down is actually "hibernate", managed by the RTC (which remains powered). At wake up, the sdram is lost, but I'm not sure at which point it tries to continue executing. It probably starts running from sdram, so it does power up, but it immediately hangs. Well, that's my theory at the moment anyway. :-)08:10
shevekActually I'm sure the power button is not the problem. It's on GPIO D29, which is the wakeup pin. So the core is woken up when it is pressed. At least that's what the programmer's manual says, and even though it's not always right, I believe it in this case. :-)08:14
qi-bot[commit] Xiangfu: m1/patches/rtems: milkymist-audio-add-support-mic-boost.patch remove the mic boost ioctl (master) http://qi-hw.com/p/wernermisc/9aeb2f908:22
kyakxiangfu: a question: are we basing on uClibc 0.9.33?08:55
kyaki noticed i was still using 0.9.32 and (therefore?) can't reproduce building failure of some packages08:56
kyakis it the case that 0.9.33 is "unstable"?08:56
kyakif we really base on 0.9.33 and it is fixed, then i will switch08:57
xiangfukyak, the 2012-03-18 is using 0.9.3309:32
xiangfukyak, "unstable" hmm... I don't know the detail. 09:32
xiangfukyak, since the openwrt have updated to 0.9.33 we better siwtch to 0.9.33 09:33
xiangfukyak, just checked. 0.9.33 is a stable release : http://www.uclibc.org/09:34
xiangfukyak, interesting. they are using git commit as ChangeLog: http://uclibc.org/downloads/ChangeLog-0.9.32.1_0.9.3309:34
kyakah yeah, using git log as a Changelog is pretty common :)09:45
kyakso ok, i'll switch to 0.9.3309:45
Action: pabs3 uses git2cl for that09:45
mirkowolfspraul: larsc: ping211:26
mirkothe xburst target will get dropped in the next release if it doesn't get levelled up to kernel version 3.311:31
kyakthis is bad news. Good news is, that there will be the next release? :)11:34
wolfspraulmirko: thanks for the heads up12:12
wolfspraul3.2 is not thaaaat old, no? :-) well, up-leveling is good, if owrt pushes forward, great12:13
wolfspraulwith 'next release' you mean the next owrt release, I guess?12:13
xiangfumirko, I have send a lot of patch on xburst target. no one reply me :(12:17
wolfspraulxiangfu: can you point mirko to a mailing list url?12:18
xiangfumirko, I will update to 3.3 . but only ben nanonote :-) 12:18
xiangfuthere is 3.0 patches. 3.2 patches not send yet.12:18
wolfspraulI still don't understand the kernel workflow, oh well12:19
wolfspraulwe have qi-kernel, an openwrt git repo on qi, one upstream, larsc, mth, xiangfu, kernel.org, etc.12:19
wolfspraulmirko: let us know how to best maintain xburst in openwrt upstream12:20
xiangfumirko, : https://lists.openwrt.org/pipermail/openwrt-devel/2012-March/014379.html12:22
xiangfuhttps://lists.openwrt.org/pipermail/openwrt-devel/2011-September/012333.html12:22
xiangfuhttps://lists.openwrt.org/pipermail/openwrt-devel/2011-September/012334.html12:22
xiangfuhttps://lists.openwrt.org/pipermail/openwrt-devel/2011-September/012335.html12:22
xiangfumirko, I will working on update kernel to 3.3 tomorrow. thanks for bring this up. 12:23
wolfspraulxiangfu: we also need to know how/where to send patches, and to coordinate with larsc and mth, afaik12:24
wolfspraulotherwise it's a waste of time12:24
wolfsprauland like kyak said, if mirko meant the next openwrt major release, that's a good thing! it's been a few years I think :-)12:25
wolfspraulit seems a lot of people are using snapshots anyway, not sure how relevant the release are, maybe mostly to get some media attention12:25
xiangfumirko, have you talk with lars about the n516 / n526 stuff?12:35
wolfsprauloh I think I start to get it12:47
wolfspraulthe most recent kernel is in qi-kernel/git, but the one in openwrt/svn is quite old (2.6.37)12:48
xiangfuqi-kernel/git have 3.312:48
wolfspraulso it comes down to just extracting a set of svn patches and getting someone to commit them into svn. that's historically a tough nut to crack :-)12:48
xiangfuopenwrt-xburst.git have 3.212:48
mthwolfspraul: qi-kernel is a clone of kernel.org with additional patches by larsc, me, Ayla and others13:22
mthpatches are in the form of commits there13:22
mthin openwrt-xburst, patches are in the forms of diffs, I think13:23
xiangfumth, part of them.13:26
xiangfumth, only ben nanonote stuff. 13:26
mththat's fine, we don't have any concrete plans for openwrt for the Dingoo13:28
mthwe should be sending some more of the shared patches upstream though; I'll make another overview of the patches we have13:30
wolfspraulmth: which build system do you use for the Dingoo?13:34
mthbuildroot13:35
wolfspraulso qi-kernel git is where the initial up-leveling and improvement action is happening13:35
mthyes13:35
wolfspraulthen xiangfu can extract openwrt/svn-like patches from there into openwrt-xburst, and then needs to find someone to review and commit them in openwrt upstream13:35
mthI think so13:36
wolfspraulalright, cool13:36
wolfspraulwhat's your experience with buildroot?13:36
wolfspraulhave you considered/compared with openwrt, and why do you find you don't need openwrt?13:37
mthbuildroot has fewer packages, but it has most of what we need13:37
mthOpenDingux is more of a base system than a full distro though13:37
mthwe have lots of libs but very few apps13:38
mthanother reason to stay with buildroot is compatibility with the original Dingux13:38
mthalthough we're not binary compatible anymore in all cases, because we enabled wchar13:38
wolfspraulI see. interesting.13:39
mthno wchar support was a historical mistake that we really had to correct because it was blocking several interesting packages13:39
mthviric: can your patch "MIPS: Enable vmlinuz for JZ4740" be submitted upstream?15:15
viricmth: Did I do a patch?15:16
viricmh15:16
viricI can't remember15:16
viricdo whatever you want with it :)15:16
mthit lists author: Lluís Batlle i Rossell <viric@viric.name>15:16
viricyes yes, me15:16
viricdo I have to do anything for that?15:16
mthwell, you could submit it or I could15:17
viricI prefer you to do that15:17
mthok, I will15:17
viricthank you!15:17
mthshevek: how long are you holding the power button when you want to turn on the device?16:07
mththe default time needed is about 2 seconds16:07
mththis can be changed by writing a counter register16:08
shevekI know; I've set that time to be 0, but also I'm holding it 5 seconds.16:08
mthok16:08
shevekIn the kernel I don't see anything special. It also just does 'tell rtc to power down; while (1) asm("wait");', which is what I do...16:09
mthin the case of suspend the IRQ status of the power button matters, not sure if that is also the case for hibernation16:09
shevekI don't think it should. The interrupt controller is powered down, only the rtc is still working. But AFAIK I have the interrupt enabled, because I want to see the power button events while it's on and I don't touch them when powering off.16:10
mthI think you're right, both ICU and the GPIO systems should be powered down, so their state doesn't matter16:11
mthis it possible that the device does come out of hibernation but hangs while booting?16:12
shevekIt is, but only if it doesn't boot normally. I've tried with hardware usbboot enabled, but it doesn't show up, and without it, so it should boot from nand (where openwrt is installed) and that doesn't happen either.16:12
shevekThe thing is, I have the screen switched on first. When I tell it to power down, the screen goes black (backlight goes off). So it seems that it does indeed power down.16:14
shevekThat's why I was guessing that it didn't do a normal boot when returning from hybernation, but I wouldn't know what else it would be doing. It has no sdram anymore, and I think the cache is also lost.16:15
shevekBut maybe the "boot sram" which is also used during usbboot is not. I could try to put my code there...16:16
mthis there a boot SRAM?16:16
mthI thought there is an internal EPROM and the contents of that are copied into the I-cache16:17
shevekYes, there's sram from 80000000 to 80004000. The first stage of usb booting must be loaded in there, because the rest of the memory is not working yet. It's a bit strange, because I thought the stuff was injected in the cache and I would expect it not to matter at which address that happens. But other memory regions don't work, I checked.16:18
shevekI think sram doesn't need to be refreshed, but it does need power to retain its state. I don't know if it gets it during hybernation. I wouldn't expect it...16:19
mthindeed SRAM doesn't need refresh, but does need power to keep its contents16:19
mthbut why wouldn't the address matter for the cache approach?16:20
shevekI don't know, but the programmer's manual says it does, and experiment confirms it.16:20
mthwhat happens with NAND booting, does that use the I-cache or the SRAM?16:21
shevekActually it isn't so clear. It says in the "boot" section that code is loaded into sram and used to set up the sdram, then it can really boot. But then in the usb boot section it says it's going into d-cache, which is copied to i-cache, and then executed. I thought I needed to change the address of stage1, and so used a higher address, but that didn't work, so the SRAM story seemed to be true. But I have no idea why or how that works.16:23
larscthe sram is the dcache/icache isn't it?16:23
shevekI thought so first as well, but I'm not sure anymore.16:24
shevekBecause the cache should have no problem with other addresses.16:24
larsci think it is the cache16:25
shevekOn the other hand, they wouldn't be so wasteful to add a block of sram to be used only during boot.16:25
larscif in doubt, just trash the sram, while the cache is active ;)16:27
mtha cache needs an address to cache line mapping; the boot code is larger than 1 cache line16:28
sheveklarsc: By writing to a0000000 and further you mean? I can try that. :-)16:30
shevekmth: Sure, but there's no reason it should fit on one line.16:31
kyakhttp://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit (sorry if this is no news for you)16:32
qi-bot[commit] kyak: centerim: update to 4.22.10 and fix build (master) http://qi-hw.com/p/openwrt-packages/e24408016:35
mirkolarsc!16:53
larscmirko: !!!!17:12
mirkolarsc: do you still feel responsible for the xburst target within openwrt-upstream?17:38
shevekoverwriting 0xa0000000 and further during stage1 doesn't have any influence.17:57
larscmirko: kind of, but well time is limited17:57
shevekI think I understand why you need this region. It's probably pre-filled in the cache. So if you write elsewhere, cache lines are discarded if they're not in that region. Possibly it will discard important things and break stage1.17:58
qi-bot[commit] kyak: libphysfs: fix build (master) http://qi-hw.com/p/openwrt-packages/505ce6b19:05
kyakbartbes: btw, libphysfs is updated upstream :)19:08
kyaki didn't update the package, since i'm not sure if it would break nlove19:09
bartbeskyak: updated in what way?20:36
bartbesand I really should update nlove sometime..20:36
qi-botThe build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120328-1247 20:42
whitequarkhttp://www.phoronix.com/scan.php?page=article&item=qualcomm_kill_blobs&num=121:43
whitequarkjust what it says in the title21:43
whitequarkNOT what I would expect from qualcomm21:43
whitequarklooks like Atheros acquisition gone the right way21:43
qi-bot[commit] Werner Almesberger: spool: support jobs with more than one file (master) http://qi-hw.com/p/cae-tools/c422be521:45
qi-bot[commit] Werner Almesberger: cameo: new command "reverse" to reverse all paths (master) http://qi-hw.com/p/cae-tools/c59e39321:45
qi-bot[commit] Werner Almesberger: cameo/README: added warning that "area" still has bugs (master) http://qi-hw.com/p/cae-tools/479ae4121:45
qi-bot[commit] Werner Almesberger: bacon/case/: added smoothing pass for deburring; assorted other small changes (master) http://qi-hw.com/p/wernermisc/558e5da21:45
qi-bot[commit] Werner Almesberger: bacon/case/draft.fig: draft of the overall case design (master) http://qi-hw.com/p/wernermisc/6442e0821:45
qi-bot[commit] Werner Almesberger: bacon/case/case.fpd: added the middle part (untested) (master) http://qi-hw.com/p/wernermisc/845464021:45
qi-bot[commit] Werner Almesberger: bacon/case/case.fpd: added the bottom part (untested) (master) http://qi-hw.com/p/wernermisc/d00ccd821:45
qi-bot[commit] Werner Almesberger: bacon/case/Makefile: generalized build process for all parts (master) http://qi-hw.com/p/wernermisc/fff817721:45
qi-bot[commit] Werner Almesberger: bacon/case/case.fpd: rearranged model of middle part (master) http://qi-hw.com/p/wernermisc/24fdda021:45
qi-bot[commit] Werner Almesberger: bacon/case/: corrections of bottom part; updates for machining (master) http://qi-hw.com/p/wernermisc/ddc5e0e21:45
qi-bot[commit] Werner Almesberger: fakefile/: so far unsuccessful attempt at jailing Kicad (master) http://qi-hw.com/p/wernermisc/150674321:45
qi-bot[commit] Werner Almesberger: Merge branch 'master' of projects.qi-hardware.com:wernermisc (master) http://qi-hw.com/p/wernermisc/536413421:45
wpwrakwhitequark: wow. that's like thatcher calling for the end of capitalism and the ousting of the bourgeoisie21:49
whitequarkwpwrak: probably :)21:54
whitequarkI always thought atheros was good21:54
wpwrakatheros is/was a bit bipolar. at openmoko, we had quite a bit of experience with its less nice side.22:14
whitequarkname any company that isn't22:22
whitequarkeven openmoko is.22:23
whitequarkor was22:23
wolfspraulkyak: nlove is (currently) broken anyway, so we can uptick libphysfs first23:58
--- Fri Mar 30 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!