<kyak> 06:29:42 < xakh> for instance it's 2230 here <-- hehe
<shevek> urandom__: Having any luck compiling Iris?
<urandom__> shevek not yet but did not spend much time trying it, sory
<shevek> urandom__: No problem, I was just curious. :-)
<urandom__> shevek maybe more people would try it if they would not need this pypp stuff :P
<shevek> urandom__: Hm, perhaps.  I can put a generated tree of c++ source somewhere, but it gets outdated fast.
<shevek> urandom__: And currently the usb server is required for testing anyway, so libshevek is still needed.  That's a bigger problem than pypp, I expect.
<urandom__> so we need better docs about compiling it, you could start a wiki page about it so more people would become interested in it
<shevek> Good idea.
<mth> larsc: usbboot/src/Makefile.am sets prefix to /usr, overriding the value set by configure
<mth> should I report this as a bug somewhere?
<larsc> probably yes
<shevek> urandom__: I started http://en.qi-hardware.com/wiki/Iris.  If anything is unclear, please modify it. :-)
<mth> larsc: report it as a bug on the Ben NanoNote, or elsewher?
<mth> ah, I was scanning the page for the word "bug" and forgot to actually read the tabs...
<mth> I couldn't get it to dump the A320 NAND, by the way
<mth> oob and raw mode don't work at all, normal mode seems to work on some pages but not all
<mth> that might be because the first pages of A320 have a different size because the primarly boot loader expects 2K pages
<FrankBlues> waves
<larsc> mth... hm indeed, the doc says so. but the ingenic codes suggests that writing to the pending register clears the interrupt. i'll do some tests
<mth> is it a problem that Linux thinks it has 1 shadow register set and the xburst data book says there are none?
<mth> I accidentally found that difference when I was debugging the audio problem
<larsc> hm, looks like they are only important for vector interrupts
<larsc> which we don't use anyway
<larsc> the code looks like the number of shadow register sets is set to 1 if it's not supported
<mth> so it's the number of register sets then, shadow or non-shadow?
<mth> I mean, it's a confusing name if you count the main thing as shadow too
<larsc> that is at least of i understood it
<larsc> the code won't work if the value is 0
<larsc> and shadow registers are new in R2
<mth> do all interrupts go through the INTC or are there interrupts that go directly to the CPU or are even generated inside the CPU?
<mth> I'm wondering why enabling interrupts on the CPU would hang Linux
<mth> the hang must happen immediately, since directly after I put an instruction to disable backlight
<mth> and it is not disabled
<larsc> nope. all irqs go through intc. (execept the intc irq)
<mth> if the INTC would generate an interrupt and the CPU has interrupts disabled, then all interrupts are masked inside the INTC, would the CPU still consider the interrupt pending or not?
<larsc> not sure
<larsc> but i guess yes
<mth> however, jz4740_cascade does check for ffs() to return 0, so it should be robust against this situation
<larsc> i've seen intc where no bits where set in pending
<mth> hmm, jz4740_cascade is called, but intc_irq is not 0
<mth> let's apply binary search...
<mth> intc == 24
<mth> so that's actually bit 23 then, TCU0
<mth> according to the docs, the pending register will have bits set for interrupts that are both pending and not masked
<mth> if that is true, something must have unmasked TCU0
<mth> ah wait, that's interrupt 23, not INTC interrupt 23
<larsc> hm, 15 is gpio iirc?
<mth> JZ4740_IRQ_BASE is 8, so it would be INTC bit 15, the RTC
<larsc> ah
<mth> but can the RTC interrupt be enabled before the driver is?
<larsc> sure. if something else enables it ;)
<mth> ok, let me rephrase that :)
<mth> is it expected that an interrupt of a device is enabled outside the driver?
<larsc> no
<mth> and drivers are not initialized until the board-X.c code runs, correct?
<larsc> yes
<larsc> you could add debuging output to unmask
<larsc> or a BUG(); to get a stack trace
<mth> I don't have any debug facility except the backlight though
<larsc> ah
<larsc> :/
<mth> oh, I misinterpreted the code, it is TCU0 after all
<mth> since the timer does not use a platform driver, it might be inited earlier
<mth> if I disable all timers initially (0x100fc -> 0x100ff), the boot gets slightly further but still hangs (maybe because it has no timer)
<mth> is the timer configured before it is enabeld?
<mth> maybe if it is set at a ridiculously high frequency, it starves the CPU
<larsc> well, the timer should still be disabled. only the clock is not stoped
<mth> disabled in what way?
<mth> using the TER register?
<larsc> yes
<mth> got it to boot :)
<mth> by disabling the half irq for timer 0/1
<mth> (probably timer 0 was the essential one)
<larsc> uhm
<mth> not the right approach?
<larsc> no. jst uhm-ing about my own stupidity. i removed similar code when doing the refactroing for pwm
<mth> ah, that explains why earlier versions did boot through usb
<mth> unfortunately I nuked the git history when rebasing master several times, so I couldn't bisect
<xakh> hey, guys, I'm trying to follow these instructions
<xakh> and I got to "creating a package for OpenWRT"
<xakh> and got confused.
<rafa> hello
<rafa> somebody knows how to use mkfs.ubifs and ubinize (command line arguments for nn) to create a rootfs for nn?
<rafa> that is why there is wiki : http://en.qi-hardware.com/wiki/Ubifs :D
<rafa> sorry for the question before to read the answer ;)
<kristianpaul> :)
<kristianpaul> hola rafa
<qi-commits> Carlos Camargo: Fixing plasma files.. Now works :) http://qi-hw.com/p/nn-usb-fpga/01e672d
<qi-commits> Carlos Camargo: Adding ucf file to plasma demo http://qi-hw.com/p/nn-usb-fpga/c3ff3a3
<rafa> kristianpaul: hola
<rafa> como estas?
<rafa> wolfspraul: hey man.. we are starting to make our oe builds ;) (in jlime)
<wolfspraul> great!
<wolfspraul> rafa: please blog about it a bit
<wolfspraul> Jon is totally right we need to connect the culture of copyleft
<wolfspraul> for example when I think about you, I think about the drinks you mixed on Werner's rooftop :-)
<wolfspraul> he he
<wolfspraul> not about jlime (sorry)
<wolfspraul> rafa: do you have a blog (rss/atom) we can aggregate into the qi hardware planet?
<xakh> hey
<xakh> I noticed that my nanonote looks significantly different from Zear's
<xakh> the one he used for demoing quake
<wolfspraul> xakh: what is the difference?
<xakh> lemme take a picture
<xakh> it's easier just to show you guys
<wolfspraul> long ago we have several times of prototypes and stuff, but everything that was sold since the official launch should be exactly the same
<xakh> sorry, had to line up the shot
<rafa> wolfspraul: no sorry. I am old style :)
<rafa> wolfspraul: we often use our forum, but until we have something useful to show we would not create a new forum for this work.
<wolfspraul> he he
<wolfspraul> nP
<rafa> wolfspraul: we can let you know when things start to look useful though ;)
<wolfspraul> that's a start
<wolfspraul> rafa: which kernel are you using and how do you build the kernel?
<rafa> wolfspraul: I have built the jlime nanonote via oe. And, also, I did the minimal bootstrap rootfs. But no luck yet.
<rafa> It does not boot. Well, it does, but something inside does a reset. SO now, I need to talk with kristoffer to know how to kill the problem
<rafa> jlime nanonote kernel*
<rafa> wolfspraul: I also converted the rootfs jffs2/tar.gz rootfs to ubi format, so I tried to test it with current Qi kernel, but no luck either.
<rafa> wolfspraul: But well, it was my first day working on that.. we will go further surely ;)
<qi-commits> Xiangfu Liu: [gcal] cleanup Makefile http://qi-hw.com/p/openwrt-packages/7aa1d3a