[01:09:52] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[01:09:52] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[01:12:56] <[7]> user890104: does SDRAM init work on the nano4g already?
[01:15:27] <[7]> the LCD type on nano4g is queried from the LCD itself
[01:15:35] <[7]> not detected by GPIOs like on the 2g
[01:16:02] <[7]> i.e. it sends a command 4 and reads 3 data words. the low 2 bits of the 3rd word are the lcd type
[01:17:02] <[7]> these LCDs actually have types 0xb3, 0xc4, 0xd5 and 0xe6
[01:17:15] <[7]> as the low 2 bits of these are unique, I'm only looking at those
[01:17:31] <[7]> the code then processes lcd_sequence_<type>
[01:19:18] <[7]> these sequences are constructed of opcodes like this:
[01:19:45] <[7]> X<0x80: send next X bytes to the LCD, the first byte of which is a command, the other are data
[01:19:55] <[7]> X=0x80: end of sequence
[01:20:12] <[7]> X>0x80: sleep (X-0x80) milliseconds(?)
[01:20:47] <[7]> as you can see in the code, the full init sequence is enabled only for lcd type 0xc4
[01:21:42] <[7]> the other ones have that non-indented line at the top that sends cmd 0x11, sleeps, sends cmd 0x13, sends cmd 0x29 and terminates the sequence
[01:22:00] <[7]> I guess that's a basic sequence to bring the LCD back from sleep mode without really configuring it
[01:22:58] <[7]> yes, those are basically the init sequence for that type minus everything that configures the panel, leaving the controller at default settings
[01:23:17] <[7]> so I guess someone tested sequence c4 already but not the others
[02:09:42] *** Joins: MulX (~mulx@2a01:e34:ee29:12b0::10)
[02:10:29] *** Quits: APLU (~mulx@2a01:e34:ee29:12b0::10) (Ping timeout: 246 seconds)
[02:10:36] *** MulX is now known as APLU
[02:22:04] *** el3ctrik-away is now known as el3ctrik
[02:49:27] *** el3ctrik is now known as el3ctrik-away
[06:43:57] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Ping timeout: 255 seconds)
[06:49:47] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven)
[07:09:55] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[07:09:55] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[07:24:10] <user890104> TheSeven: emcore boots, so i guess sdram is initialized successfully
[07:37:38] <user890104> it fails to boot from within OF though
[11:12:42] *** Quits: APLU (~mulx@2a01:e34:ee29:12b0::10) (Quit: !sucide)
[11:32:47] *** Joins: APLU (~mulx@2a01:e34:ee29:12b0::10)
[11:47:40] *** Joins: n1s (~n1s@nl118-168-30.student.uu.se)
[11:47:45] *** Quits: n1s (~n1s@nl118-168-30.student.uu.se) (Changing host)
[11:47:45] *** Joins: n1s (~n1s@rockbox/developer/n1s)
[12:02:06] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 255 seconds)
[13:09:55] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[13:09:55] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[13:45:08] <TheSeven> user890104: so which LCD type do you have?
[13:46:05] <user890104> TheSeven: let me see
[14:31:36] <user890104> TheSeven: can you spot the error here? http://pastie.org/pastes/8923844/text
[14:32:56] <user890104> reset and hang are copied from emcore's crt0
[14:33:26] <user890104> bootstub/bootstub.S:40: Error: invalid constant (51c) after fixup
[14:34:20] <user890104> ah, found it. aligning
[14:44:43] <TheSeven> user890104: yes, that code is a bit annoying ;)
[14:45:01] <user890104> TheSeven: looks like it's also c4... :\
[14:45:13] <user890104> the source code i pasted reboots it
[14:45:27] <TheSeven> er, that code will always reboot it
[14:45:30] <TheSeven> you want cmp, not tst
[14:46:18] <TheSeven> how is your lcd behaving?
[14:46:39] <user890104> the apple logo stays on it all the time
[14:46:50] <user890104> no matter if i run umsboot or emcore
[14:47:07] <TheSeven> ok, so it's scanning the panel with somewhat correct settings at least
[14:47:52] <user890104> so, it's not c4
[14:48:01] <user890104> let's try d5
[14:51:11] <user890104> TheSeven: it's b3
[14:51:36] <TheSeven> ok, try removing the first line of that sequence then (the non-indented one=
[14:51:41] <user890104> cmp r0, #3 sets EQ
[14:53:04] <user890104> what about line 4 of the sequence? it has 0x80 at the end, won't this skip the rest of it?
[14:57:32] * user890104 would like to thank whoever disassembled the init sequence :)
[14:57:49] <user890104> but i miss some backlight at the moment
[14:58:37] <user890104> let's see how ibugger turns it on
[15:00:52] <user890104>       self.i2csend(0, 0xe6, 0x30, struct.pack("<B", int(brightness * 250)))
[15:00:52] <user890104>       self.i2csend(0, 0xe6, 0x31, struct.pack("<B", 3))
[15:04:21] <user890104> i'll need some help to translate this into assembly (calls to i2cwait/i2cwaitrdy i guess?)
[15:13:47] <user890104> sending the i2c packets using emcore seems to work fine
[15:19:37] <user890104> but the brightness doesn't change if i use a different value in the first command
[15:56:02] <TheSeven> only 0x80 as the first byte ends the sequence
[15:56:15] <TheSeven> the line breaks should be the command boundaries
[15:59:26] <user890104> yeah, i figured out that
[15:59:53] <user890104> where should we set the default brightness, and do you have an idea why i can't adjust its level?
[16:03:42] <TheSeven> add these lines before pmu_batch_5_end:
[16:03:57] <TheSeven> .byte 0x30, 250
[16:04:07] <TheSeven> .byte 0x31, 3
[16:05:51] <user890104> before or after?
[16:05:57] <user890104> ah, i see
[16:06:08] <user890104> there are two label, begin and end :)
[16:06:41] <TheSeven> not sure why setting the brightness wouldn't work
[17:19:19] <user890104> i'll try if it works using ibugger
[17:23:05] <user890104> TheSeven: this line of libemcore doesn't seem to be compatible with python3:
[17:23:12] <user890104> return self.lib.monitorcommand(struct.pack("<IBBBBII%ds" % size, 9, index, slaveaddr, startaddr, size, 0, 0, data), "III", (None, None, None))
[17:25:23] <user890104> struct.error: argument for 's' must be a bytes object
[19:09:53] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[19:09:53] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[19:26:03] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat)
[20:05:33] <user890104> TheSeven: how do i debug an emcore app, if i have the ELF file and the last know PC value (it crashed because of a null pointer jump)
[21:45:01] *** Quits: APLU (~mulx@2a01:e34:ee29:12b0::10) (Quit: !sucide)
[21:51:32] *** Joins: APLU (~mulx@2a01:e34:ee29:12b0::10)
[23:14:32] <TheSeven> user890104: you need the base address where it was loaded
[23:14:58] <user890104> is it available in getprocinfo?
[23:17:01] <TheSeven> hm... not sure
[23:17:15] <TheSeven> look at the memory allocations of that thread
[23:17:52] <TheSeven> if you can't run the allocation dumper on-target, you can just download a full sdram memory dump and analyze that offline