<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>
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