[02:09:01] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:09:02] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:19:33] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [02:20:44] *** Joins: [Saint] (~saint@rockbox/staff/saint) [06:13:09] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:13:22] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [06:35:59] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [06:39:01] *** Joins: [Saint] (~saint@rockbox/staff/saint) [08:09:03] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:09:04] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [11:05:49] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [11:52:30] *** Joins: [Saint] (~saint@rockbox/staff/saint) [12:22:07] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [12:23:57] *** Joins: [Saint] (~saint@rockbox/staff/saint) [13:29:05] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [13:30:22] *** Joins: [Saint] (~saint@rockbox/staff/saint) [14:09:04] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:09:04] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:15:38] [7]: emcore hangs shortly after leaving init thread, any hints how to debug it? (target is ipt2g) [16:13:34] <[7]> user890104: could possibly be a sign of the tick interrupt not working [16:13:53] <[7]> but that's just a wild guess [17:01:46] [7]: putting a reset() after the last boot message (cputs(CONSOLE_BOOT, nobootoptionsstr);), it doesn't work [17:02:22] if i comment out the cputs, put about 1-2 ms delay and another print, it works. if i increase the delay by .5 ms, it doesnt. [18:08:12] <[7]> user890104: did you use sleep or udelay? [18:08:22] udelay [18:08:37] <[7]> that's a pretty sure sign that it gets stuck in some IRQ handler then [18:08:43] <[7]> either the tick or USB or something [18:10:38] i tried a build without usb support, and it failed the same way [18:11:14] <[7]> try adding an enter_critical_section() before the udelay, and increasing the delay [18:13:43] that worked :) [18:13:58] <[7]> it definitely is an IRQ handler never returning then [18:15:27] <[7]> might be worth trying to check if you can successfully panicf() inside a critical section, and use that to determine which IRQ handler is trying to take control [18:15:28] what's more, udelay(10000000) sleeps for about 20~21 sec. [18:16:05] <[7]> interesting, seems to have a different clock setup then, shouldn't be critical for now. [18:16:31] <[7]> if panicf doesn't work, you can try adding reset() calls to some IRQ handlers until you find the culprit [18:17:07] <[7]> http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Femcore%2Ftrunk%2Ftarget%2Fipodtouch2g%2Fcrt0.S [18:17:20] <[7]> you'll probably have to adjust the division stuff at the end of read_usec_timer [18:18:21] <[7]> make the lsr#5 an lsr#4, the lsl#27 an lsl#28 [18:18:36] <[7]> that should fix the timing [18:21:16] the timer is fine now, thanks [18:46:22] [7]: it's prefetch_abort_handler [18:47:56] actually, no [18:49:31] <[7]> that one wouldn't be masked by a critical section [18:57:06] any idea which one to start with? [18:58:48] i'm not familiar with the kernel code [18:59:16] <[7]> might be easiest to print the IRQ number into a corner of the screen on every handler entry/exit [18:59:28] <[7]> but really the only thing that should be running at that point is the tick timer IRQ [19:05:01] experimenting with delays, i even got to a point where only like 4 or 5 lines of pixels were drawn, i.e. the text was missing 1-2 lines of pixels at the bottom [19:05:49] <[7]> my guess would be that you're ending up in the unhandled IRQ handler, which for some reason fails to print its message [19:06:01] <[7]> because there really shouldn't be any IRQ at that time [19:06:43] should i try putting reset() in the exception handlers? [19:06:59] <[7]> try the unhandled irq one [19:12:20] putting a reset() in unhandled_irq() didn't change anything [19:27:54] [7]: do i need something like that: http://pastie.org/pastes/8736695/text ? [19:34:39] <[7]> in theory yes [19:34:42] i put a puts() in scheduler_switch, it was entered exactly once [19:34:50] <[7]> however I'm not sure if cprintf will work from within an IRQ handler [19:35:18] <[7]> if you do that, avoid calling any console API from anywhere else [19:35:26] <[7]> attempting to lock a mutex in IRQ mode isn't a very good idea [19:36:09] <[7]> so it might be better, if it can be done easily, to directly draw to the framebuffer [19:38:30] i can draw directly to the framebuffer, IIRC [20:09:02] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:09:02] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [22:28:18] [7]: where should i put my debugging code, so i can catch every interrupt that's triggered? [22:31:40] <[7]> the place that you pasted seemed adequate [22:33:04] ah ok, i thought i'm looking at the wrong place [22:48:41] i put a reset() in irqhandler(), and it didn't get executed at all [22:54:58] actually, irq_handler() (in crt0) doesn't seem to be called at all [22:56:14] maybe interrupts aren't getting enabled at all? [23:07:05] <[7]> user890104: with or without enter_critical_section? [23:07:09] <[7]> that function disables them [23:08:19] aren't interrupts already disabled in the irq handler? [23:08:35] <[7]> they're temporarily disabled while an IRQ handler is active, yes [23:09:01] <[7]> but I mean if you still have that enter_critical_section + delay thing in the main thread, it would explain why you aren't getting IRQs [23:09:23] ah, i see [23:09:27] i don't have them [23:09:42] <[7]> if irq_handler isn't getting called, but enter_critical_section made a difference, then it's likely that there is a lower level misconfiguration [23:09:59] i just put a second call to cputs(), because it usually fails to get executed because of timing issues [23:10:12] (unless i wrap it inside a critical section) [23:10:18] ah, too bad [23:10:44] <[7]> such as vectored IRQs being enabled, or the high exception handler base address being selected, or some MMU mapping problem [23:10:46] i could try rolling back to the revision which kleemajo managed to run on that target [23:11:14] <[7]> I doubt much has changed since that [23:11:21] <[7]> but it could of course be worth a try [23:11:28] ok, let's see [23:11:57] <[7]> my guess is that we aren't properly initializing something, and kleemajo was executing it from an environment where that was already set up correctly by openiBoot or something [23:15:08] i am also using openiBoot :) [23:16:25] i'm embedding our binary into openiBoot using .incbin, then memcpy'ing it to 0x09000000, clearing caches, disabling interrupts and branching to that address [23:35:38] [7]: the previous revisons didn't work properly either [23:36:02] i guess that's a dead end