Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
dvdk has joined #qi-hardware
<qi-bot>
[commit] David K
<qi-bot>
[commit] David K
xiangfu has joined #qi-hardware
<whitequark>
wpwrak: if I understand anything about software development, then kicad is going to die pretty soon :/
<whitequark>
well, it may have an indefinitely long agony, of course
<wpwrak>
i 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.
rejon has joined #qi-hardware
wolfspraul has joined #qi-hardware
jurting has joined #qi-hardware
panda|x201 has joined #qi-hardware
LunaVorax has joined #qi-hardware
shevek has joined #qi-hardware
<shevek>
Not 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?
<shevek>
s/I see is openwrt xburst/In OpenWRT XBurst I see/
<qi-bot>
shevek meant: "Not long ago, I browsed the kernel source at http://projects.qi-hardware.com, but now I can't find it anymore. In OpenWRT XBurst I see some kernel stuff, but not the source itself. Is there something wrong with the site, or am I looking in the wrong place?"
<shevek>
Yeah, that. :-D
<shevek>
Cool feature. :-)
<xiangfu>
shevek, openwrt xburst keep the patch. not all source code.
<xiangfu>
shevek, if you want look the patch on nanonote. check out here:
<xiangfu>
if you have patch. please send them to mailing list or me :-)
<shevek>
I 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.
<shevek>
Still, if I see bugs while looking at the code, I'll let you know. :-)
<xiangfu>
shevek, great. are you 'Bas Wijnen'? (sorry I always can't remember the English name)
<shevek>
xiangfu: Yes, I am. Sorry about the nick. ;-)
<xiangfu>
shevek, nope. nick is good.
<mth>
shevek: on the Dingoo, power up is done by making the GPIO connected to the power button generate an interrupt, iirc
<mth>
not sure how it works on the NN, since it has a keyboard matrix rather than direct button to GPIO like the Dingoo
<mth>
but maybe the power button is not in the keyboard matrix
<shevek>
It 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. :-)
<shevek>
Actually 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. :-)
<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/9aeb2f9
<kyak>
xiangfu: a question: are we basing on uClibc 0.9.33?
<kyak>
i noticed i was still using 0.9.32 and (therefore?) can't reproduce building failure of some packages
<kyak>
is it the case that 0.9.33 is "unstable"?
<kyak>
if we really base on 0.9.33 and it is fixed, then i will switch
jivs has joined #qi-hardware
GNUtoo has joined #qi-hardware
<xiangfu>
kyak, the 2012-03-18 is using 0.9.33
<xiangfu>
kyak, "unstable" hmm... I don't know the detail.
<xiangfu>
kyak, since the openwrt have updated to 0.9.33 we better siwtch to 0.9.33
<xiangfu>
mirko, I will working on update kernel to 3.3 tomorrow. thanks for bring this up.
<wolfspraul>
xiangfu: we also need to know how/where to send patches, and to coordinate with larsc and mth, afaik
<wolfspraul>
otherwise it's a waste of time
<wolfspraul>
and like kyak said, if mirko meant the next openwrt major release, that's a good thing! it's been a few years I think :-)
<wolfspraul>
it seems a lot of people are using snapshots anyway, not sure how relevant the release are, maybe mostly to get some media attention
<xiangfu>
mirko, have you talk with lars about the n516 / n526 stuff?
<wolfspraul>
oh I think I start to get it
<wolfspraul>
the most recent kernel is in qi-kernel/git, but the one in openwrt/svn is quite old (2.6.37)
<xiangfu>
qi-kernel/git have 3.3
<wolfspraul>
so 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 :-)
<xiangfu>
openwrt-xburst.git have 3.2
<mth>
wolfspraul: qi-kernel is a clone of kernel.org with additional patches by larsc, me, Ayla and others
<mth>
patches are in the form of commits there
<mth>
in openwrt-xburst, patches are in the forms of diffs, I think
<xiangfu>
mth, part of them.
<xiangfu>
mth, only ben nanonote stuff.
<mth>
that's fine, we don't have any concrete plans for openwrt for the Dingoo
<mth>
we should be sending some more of the shared patches upstream though; I'll make another overview of the patches we have
<wolfspraul>
mth: which build system do you use for the Dingoo?
<mth>
buildroot
<wolfspraul>
so qi-kernel git is where the initial up-leveling and improvement action is happening
<mth>
yes
<wolfspraul>
then 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 upstream
<mth>
I think so
<wolfspraul>
alright, cool
<wolfspraul>
what's your experience with buildroot?
<wolfspraul>
have you considered/compared with openwrt, and why do you find you don't need openwrt?
<mth>
buildroot has fewer packages, but it has most of what we need
<mth>
OpenDingux is more of a base system than a full distro though
<mth>
we have lots of libs but very few apps
<mth>
another reason to stay with buildroot is compatibility with the original Dingux
<mth>
although we're not binary compatible anymore in all cases, because we enabled wchar
<wolfspraul>
I see. interesting.
<mth>
no wchar support was a historical mistake that we really had to correct because it was blocking several interesting packages
panda|x201 has joined #qi-hardware
zenlunatic has joined #qi-hardware
jurting has joined #qi-hardware
<mirko>
i didn't talk to lars for a long time - he's quite busy with other stuff currently
<mirko>
just send me the patchset - well tested please - so i will just apply and commit them
<mirko>
i won't have much time for testing
<jurting>
Can someone ping my name?
<Ayla>
jurting: pong
<jurting>
Thanks, it works (the program stopped blinking on messages/pings randomly yesterday)
wej has joined #qi-hardware
qi-bot has joined #qi-hardware
rejon has joined #qi-hardware
rejon has joined #qi-hardware
<mth>
viric: can your patch "MIPS: Enable vmlinuz for JZ4740" be submitted upstream?
<viric>
mth: Did I do a patch?
<viric>
mh
<viric>
I can't remember
<viric>
do whatever you want with it :)
<mth>
it lists author: Lluís Batlle i Rossell <viric@viric.name>
<viric>
yes yes, me
<viric>
do I have to do anything for that?
<mth>
well, you could submit it or I could
<viric>
I prefer you to do that
<mth>
ok, I will
<viric>
thank you!
emeb has joined #qi-hardware
valhalla has joined #qi-hardware
jow_lapt1p has joined #qi-hardware
jow_laptop has joined #qi-hardware
<mth>
shevek: how long are you holding the power button when you want to turn on the device?
<mth>
the default time needed is about 2 seconds
<mth>
this can be changed by writing a counter register
<shevek>
I know; I've set that time to be 0, but also I'm holding it 5 seconds.
<mth>
ok
<shevek>
In 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...
panda|x201 has joined #qi-hardware
<mth>
in the case of suspend the IRQ status of the power button matters, not sure if that is also the case for hibernation
<shevek>
I 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.
<mth>
I think you're right, both ICU and the GPIO systems should be powered down, so their state doesn't matter
<mth>
is it possible that the device does come out of hibernation but hangs while booting?
<shevek>
It 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.
<shevek>
The 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.
<shevek>
That'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.
<shevek>
But maybe the "boot sram" which is also used during usbboot is not. I could try to put my code there...
<mth>
is there a boot SRAM?
<mth>
I thought there is an internal EPROM and the contents of that are copied into the I-cache
<shevek>
Yes, 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.
<shevek>
I 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...
<mth>
indeed SRAM doesn't need refresh, but does need power to keep its contents
<mth>
but why wouldn't the address matter for the cache approach?
<shevek>
I don't know, but the programmer's manual says it does, and experiment confirms it.
<mth>
what happens with NAND booting, does that use the I-cache or the SRAM?
<shevek>
Actually 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.
<larsc>
the sram is the dcache/icache isn't it?
<shevek>
I thought so first as well, but I'm not sure anymore.
<shevek>
Because the cache should have no problem with other addresses.
<larsc>
i think it is the cache
<shevek>
On the other hand, they wouldn't be so wasteful to add a block of sram to be used only during boot.
<larsc>
if in doubt, just trash the sram, while the cache is active ;)
<mth>
a cache needs an address to cache line mapping; the boot code is larger than 1 cache line
<shevek>
larsc: By writing to a0000000 and further you mean? I can try that. :-)
<shevek>
mth: Sure, but there's no reason it should fit on one line.
<mirko>
larsc: do you still feel responsible for the xburst target within openwrt-upstream?
<qi-bot>
Fabricatorz: open source hardware for dance music made in China by westerners — Lucas Gonze's blog http://t.co/uk8q18w7 @milkymistvj @qihardware ( 185424678767169536@fabricatorz - 38s ago via Ping.fm )
<shevek>
overwriting 0xa0000000 and further during stage1 doesn't have any influence.
<larsc>
mirko: kind of, but well time is limited
<qi-bot>
RTC Milkymist: RT @fabricatorz: open source hardware for dance music made in China by westerners — Lucas Gonze's blog http://t.co/ryqG1W1G @qihardware ( 185425346596835328@milkymistvj - 58s ago via HootSuite )
<shevek>
I 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.
<qi-bot>
jackiegx6: @qihardware http://t.co/jx5Riawg ( 185439951289192448@jackiegx6 - 57s ago via web )
<kyak>
bartbes: btw, libphysfs is updated upstream :)
<kyak>
i didn't update the package, since i'm not sure if it would break nlove
LunaVorax has joined #qi-hardware
jekhor has joined #qi-hardware
<qi-bot>
Lyn Jeffery: @fabricatorz @milkymistvj @qihardware will u be in SZ next wkend for mini maker faire? Want to hear about milkymist smartphone experience! ( 185463371687145474@LynJ - 53s ago via web )
<bartbes>
kyak: updated in what way?
<bartbes>
and I really should update nlove sometime..
<qi-bot>
[commit] Werner Almesberger: bacon/case/: added smoothing pass for deburring; assorted other small changes (master) http://qi-hw.com/p/wernermisc/558e5da