**** BEGIN LOGGING AT Sat Apr 25 02:59:57 2009
Apr 25 03:02:38 <flyback> cool
Apr 25 03:22:48 <mpannen> heh i dont know squat
Apr 25 03:23:18 <mpannen> ive been paging through the pxa developers manual
Apr 25 03:23:41 <tmzt> you need to read the arm dev manuals as well
Apr 25 03:23:59 <tmzt> pxa will tell you about those processors but not much about arm itself
Apr 25 03:26:04 <mpannen> asm volatile ("mcr p15, 0, %0, c3, c3, 0" : : "r"(0xffffffff) );
Apr 25 03:26:19 <mpannen> is that second c3 a typo?
Apr 25 03:26:54 <mpannen> asm volatile ("mcr p15, 0, %0, c3, c0, 0" : : "r"(0xffffffff) );
Apr 25 03:27:02 <mpannen> whats the difference?
Apr 25 04:21:20 <mpannen> memory protection is not being disabled ugh :(
Apr 25 04:21:25 <mpannen> wtf
Apr 25 04:31:09 <mpannen> ok so i can at least dump memory from the usb console now
Apr 25 04:31:13 <mpannen> yay
Apr 25 05:57:56 <tmzt> usb console?
Apr 25 06:53:42 <Sleep_Walker> tmzt: probably cocoboot feature
Apr 25 07:36:48 <farcaller> hi all
Apr 25 12:21:38 <b3rz3rk3r> hey
Apr 25 12:22:11 <b3rz3rk3r> can i get help with psp hacks in here?
Apr 25 19:48:34 <Marex> mpannen: hi, sorry I wasn't here yesterday
Apr 25 19:48:39 <Marex> mpannen: how's it going ?
Apr 25 19:49:18 <Marex> bluelightning: hi ... I saw a few commits to opie recently, how's it going with it ?
Apr 25 19:49:37 <bluelightning> Marex: hey
Apr 25 19:50:01 <bluelightning> ok I guess, haven't been working on it as much as I probably should be
Apr 25 19:50:27 <bluelightning> datebook2 is almost finished though :)
Apr 25 19:50:56 <Marex> oh, so you are still working on it, that's good
Apr 25 19:51:08 <Marex> but it starts to seem like we are kind-of lonely warriors here :/
Apr 25 19:53:03 <Marex> bluelightning: is there anyone besides you working on opie ?
Apr 25 19:53:29 <bluelightning> Marex: no, haven't heard anything from anyone else lately
Apr 25 19:53:44 <Marex> hrm ... that sucks :/
Apr 25 19:53:54 <bluelightning> I'd love to have some help of course, but it seems nobody's interested in directly working on Opie
Apr 25 19:54:06 <Marex> HnD is hitting that stage too .. it's only me and sleepwalker recently hacking on Palms
Apr 25 19:54:42 <bluelightning> I guess everyone gets busy with other things after a while
Apr 25 19:54:57 <bluelightning> how are things with you? university going well?
Apr 25 19:55:41 <Marex> bluelightning: somehow yes ... examination period is near again and then two months of holiday
Apr 25 19:55:52 <Marex> of course that'll be dedicated mostly to HnD
Apr 25 19:56:05 <Marex> or maybe hacking on some other handhelds ... I have no other plans
Apr 25 19:57:12 <Marex> bluelightning: I still have FSC Loox N560 which needs some work to be properly supported
Apr 25 19:57:23 <Marex> also, there is HP hw6515d which isn't properly supported
Apr 25 19:58:18 <bluelightning> there's always another machine to support :)
Apr 25 19:58:19 <Marex> bluelightning: how's it going on your end ?
Apr 25 19:58:43 <Marex> bluelightning: yea ... that's why I keep wasting my time with this ... because there always is something to patch in kernel
Apr 25 19:59:22 <bluelightning> ok, keeping busy with work... been on a few trips since christmas although so far I haven't travelled as much as I had expected to
Apr 25 19:59:42 <Marex> bluelightning: when are you planning to visit us here in .cz ? ;D
Apr 25 19:59:57 <bluelightning> Marex: one day real soon now :)
Apr 25 20:00:30 <bluelightning> oh I managed to give away all those h3600s too :) hope it helps get them supported
Apr 25 20:00:44 <Marex> cool, be sure to let me know when you arrive :)
Apr 25 20:00:53 <bluelightning> will do :)
Apr 25 20:00:57 <Marex> hm, 3600s, those are pretty ancient
Apr 25 20:01:05 <bluelightning> indeed
Apr 25 20:01:16 <Marex> maybe I could get some too, but not now
Apr 25 20:01:19 <bluelightning> advantage is they are cheap and still easy to find on ebay though
Apr 25 20:02:33 <Marex> I use "aukro" here ... it's similar, but smaller, much smaller scale
Apr 25 20:02:54 <Marex> (and I use "kEdAR" - the Palm collector)
Apr 25 20:03:12 <Marex> hrm, maybe "use" isn't really appropriate word
Apr 25 20:03:22 <Marex> he just lent me some devices so I can hack on them :)
Apr 25 20:03:28 <Marex> *he = kedar
Apr 25 20:03:49 <Marex> he already has about 50 pcs of Palms ...
Apr 25 20:04:28 <bluelightning> wow, and I thought I had a few devices...
Apr 25 20:04:49 <Marex> well he has even the ancient once (b/w, m68k)
Apr 25 20:04:52 <Marex> s/once/ones/
Apr 25 20:04:58 <Marex> they can't run linux at all
Apr 25 20:05:11 <bluelightning> I had one of those, a palmpilot pro
Apr 25 20:05:17 <bluelightning> my first handheld :)
Apr 25 20:05:23 <bluelightning> back in 1997
Apr 25 20:05:27 <mpannen> hi marex, havent got anywhere with the phone lol
Apr 25 20:05:42 <Marex> bluelightning: yes, that's one of the first ones :)
Apr 25 20:06:04 <Marex> mpannen: you mean t755p ? hmm, can't you supply use with one unit ? it looks interesting
Apr 25 20:06:17 <mpannen> i can use the usb console to read parts of memory
Apr 25 20:06:40 <mpannen> heh wish i had an extra one
Apr 25 20:06:43 <Marex> the one in cocoboot ?
Apr 25 20:06:44 <Marex> good
Apr 25 20:06:49 <mpannen> yeah
Apr 25 20:07:01 <mpannen> no clue
Apr 25 20:07:04 <Marex> mpannen: does t755p have a led ?
Apr 25 20:07:08 <mpannen> i havev a question for u
Apr 25 20:07:12 <Marex> go ahead
Apr 25 20:07:23 <mpannen> yes it has an led
Apr 25 20:07:32 <mpannen> about an assembly instruction
Apr 25 20:07:44 <Marex> try finding out if you can switch it on/off through some GPIO
Apr 25 20:08:29 <Marex> if you can, you can try tracing where cocoboot hangs
Apr 25 20:08:54 <mpannen> asm volatile ("mcr p15, 0, %0, c3, c3, 0" : : "r"(0xffffffff) );
Apr 25 20:09:13 <mpannen> that is the memory unlock instruction right?
Apr 25 20:09:24 <mpannen> asm volatile ("mcr p15, 0, %0, c3, c1, 0" : : "r"(0xffffffff) );
Apr 25 20:09:35 <Marex> hang on
Apr 25 20:09:38 <mpannen> whats the difference between those two?
Apr 25 20:11:29 <mpannen> i mean, looking at the pxa devel manual it looks like the second one is the proper line, but ive seen a mixture of both in the source for cocoboot
Apr 25 20:12:46 <mpannen> so i would have the led blink different patterns for each part of the code that is being executed
Apr 25 20:13:22 <Marex> I have to check the book, hang on
Apr 25 20:13:37 <mpannen> ok no hurry i just wanted to bring that up
Apr 25 20:13:51 <Marex> mpannen: here's a better idea ... you said it resets when you hit boot, right ?
Apr 25 20:14:37 <mpannen> yes
Apr 25 20:14:46 <Marex> put "for(;;);" into the arm/boot.c:boot_linux()
Apr 25 20:14:52 <Marex> that's an endless loop
Apr 25 20:15:01 <Marex> if it hangs, push it further etc.
Apr 25 20:15:05 <mpannen> ahhhh
Apr 25 20:15:06 <mpannen> ok
Apr 25 20:15:40 <mpannen> ive seen someone else post something like that,,,i just wasnt sure where to put that in amongst all of the files
Apr 25 20:15:56 <mpannen> sweet ill give that a try
Apr 25 20:16:21 <Marex> try line 131 ... right before irq_off();
Apr 25 20:17:36 <mpannen> also, any idea why the git server isnt responding?
Apr 25 20:17:55 <mpannen> looks like a bunch of stuff has been taken down on the source code part of the web site?
Apr 25 20:18:13 <Marex> the domain is being moved
Apr 25 20:18:17 <Marex> farcaller: ping ^
Apr 25 20:19:08 <farcaller> currently only git.hackndev.com is moved. If there's anything alse inaccessible - that's abug
Apr 25 20:19:18 <mpannen> ahh'
Apr 25 20:19:31 <mpannen> is there a new name?
Apr 25 20:19:51 <mpannen> well just the git repositories were missing from the site
Apr 25 20:20:11 <farcaller> you can clone old repos from thor.hackndev.com via git:// until all of them are moved
Apr 25 20:20:24 <farcaller> (same url syntax as before)
Apr 25 20:21:10 <farcaller> Marex: do you know what linux trees are actually useful? we have three of them
Apr 25 20:21:29 <farcaller> ato/linux-2.6-arm, linux-2.6, linux-hnd
Apr 25 20:21:35 <Marex> farcaller: see RTFM.txt in the topic
Apr 25 20:21:37 <Marex> those are useful
Apr 25 20:22:08 <Marex> farcaller: but if you want to avoid CristianoP whining about his code, preserve them
Apr 25 20:22:14 <farcaller> even four - new hackndev/arm-linux is there on frigga
Apr 25 20:22:21 <Marex> XD
Apr 25 20:23:24 <farcaller> also there's cocoboot, tools and a bunch of old/* stuff
Apr 25 20:23:47 <Marex> cocoboot is active
Apr 25 20:23:52 <Marex> preserve that all
Apr 25 20:24:11 <Marex> ato/linux-2.6 contains some useful stuff iirc
Apr 25 20:24:17 <Marex> linux-hnd is needed by OE
Apr 25 20:24:31 <Marex> linux-2.6 ... who knows, isn't that your creation ?
Apr 25 20:24:46 <farcaller> definitely not mine
Apr 25 20:25:00 <Marex> farcaller: definitelly yours ;-)
Apr 25 20:25:36 <farcaller> if you say so :p
Apr 25 20:25:51 <Marex> I felt like arguing ... damn :/
Apr 25 20:28:49 * farcaller moved cocoboot over to frigga
Apr 25 20:36:48 <mpannen> marex:the pone reset with the loop just before irq_off in boot.c:boot_linux()
Apr 25 20:38:13 <Marex> that's very weird
Apr 25 20:39:09 <Marex> mpannen: well ... try putting the loop at line 109
Apr 25 20:40:23 <mpannen> ok'
Apr 25 20:40:32 <mpannen> it loooped at line 94 :)
Apr 25 20:40:35 <mpannen> heh
Apr 25 20:40:50 <Marex> mpannen: well ... try tracing it this way
Apr 25 20:40:59 <Marex> pinpoint where it resets
Apr 25 20:41:00 <mpannen> ill try 109 next
Apr 25 20:41:07 <Marex> yea, bisect it
Apr 25 20:42:18 <mpannen> i am assuming the only way to get out of the loop is to yank the battery :)
Apr 25 20:43:00 <Marex> yup
Apr 25 20:43:29 <Marex> you can set WDT, but that'd take longer than this way
Apr 25 20:45:14 <mpannen> a for loop at line 109 caused a reset
Apr 25 20:45:54 <Marex> maybe virt_to_phys is broken ?
Apr 25 20:46:10 <Marex> see line 103 ... try looping before that and after that
Apr 25 20:47:01 <mpannen> i will insert a loop after line 102 right now
Apr 25 20:51:12 <mpannen> it did not reset with a loop inserted after line 102
Apr 25 20:53:11 <Marex> mpannen: what about after line 103 ?
Apr 25 20:53:19 <Marex> (after kernel = (void *)... )
Apr 25 20:53:52 <mpannen> oh my line numbers are different ive been commenting out the for loops
Apr 25 20:53:53 <mpannen> hehe
Apr 25 20:54:20 <mpannen> i will put one there right now
Apr 25 20:54:21 <Marex> use "u" ;-)
Apr 25 20:54:24 <Marex> (undo in Vim)
Apr 25 20:57:05 <mpannen> it resets with a loop just after kernel=void
Apr 25 20:57:50 <Marex> damn
Apr 25 20:58:42 <Marex> mpannen: I think I have bad news for you ;-)
Apr 25 20:58:57 <mpannen> its still broken?
Apr 25 20:59:12 <mpannen> haha
Apr 25 20:59:35 <mpannen> no kernel for me!
Apr 25 20:59:50 <Marex> well see virt_to_phys() for yourself
Apr 25 21:00:00 <Marex> ok, try this (lemme think)
Apr 25 21:00:16 <mpannen> my pphone is completely virtual?
Apr 25 21:00:23 <Marex> put this at boot.c:90
Apr 25 21:00:42 <Marex> return virt_to_phys(g, 0x98000000);
Apr 25 21:01:54 <mpannen> ok, where does that result go back to?
Apr 25 21:02:03 <Marex> you'll see it in cocoboot
Apr 25 21:02:17 <Marex> iirc "Returned: <st.>" will appear
Apr 25 21:02:24 <mpannen> ahhh
Apr 25 21:02:53 <mpannen> i supopose u know what should be returned?
Apr 25 21:04:20 <Marex> not at all
Apr 25 21:04:34 <Marex> I just guess what it'll be
Apr 25 21:04:40 <Marex> does it work or does it just reset
Apr 25 21:04:40 <Marex> ?
Apr 25 21:05:08 <mpannen> one sec
Apr 25 21:05:26 <mpannen> big fat reset
Apr 25 21:05:47 <Marex> dang ...
Apr 25 21:06:00 <Marex> see boot/arm.c:257 ... good luck ;)
Apr 25 21:08:00 <mpannen> wtf is all of that?!?!
Apr 25 21:08:01 <mpannen> haha
Apr 25 21:08:25 <Marex> TTB resolver
Apr 25 21:09:03 <mpannen> should i just start adding loops?
Apr 25 21:09:17 <Marex> you should fix it ;)
Apr 25 21:09:21 <mpannen> haha
Apr 25 21:09:42 <mpannen> better grab an arm assembly book
Apr 25 21:10:04 <Marex> that's C
Apr 25 21:10:12 <mpannen> that too
Apr 25 21:10:17 <Marex> try one more thing
Apr 25 21:10:40 <Marex> boot.c:86, put there return (UInt32)(g->ttb);
Apr 25 21:11:57 <Marex> what does it return
Apr 25 21:11:57 <Marex> ?
Apr 25 21:12:03 <Marex> or errr ...
Apr 25 21:12:20 <mpannen> something else?
Apr 25 21:12:39 <Marex> yes
Apr 25 21:12:47 <Marex> I need to find some working Palm, hang on
Apr 25 21:15:28 <Marex> mpannen: so, run cocoboot, disable memory protection and then select "Memory" from menu
Apr 25 21:15:31 <Marex> send me it's content
Apr 25 21:15:44 <mpannen> ok
Apr 25 21:16:05 <mpannen> we modified the memory size so it will always say 64mb
Apr 25 21:16:09 <mpannen> one sec
Apr 25 21:17:10 <mpannen> RAM base: 0xa0000000
Apr 25 21:17:39 <mpannen> Size: 64mb (0x1b00000)
Apr 25 21:17:58 <mpannen> Phys TTB: 0xa1ffc000
Apr 25 21:18:13 <mpannen> Virt TTB: 0x1ffc000
Apr 25 21:18:15 <Marex> what?!
Apr 25 21:18:28 <Marex> well here's the problem
Apr 25 21:18:28 <mpannen> thats what it says
Apr 25 21:18:58 <mpannen> heh
Apr 25 21:19:04 <mpannen> i like your response
Apr 25 21:19:48 <Marex> well the problem is with TTB somewhere where it shouldn't be, but I dunno how to fix it yet
Apr 25 21:21:45 <mpannen> i think i need to google what a ttb does exactly, obviously it has to do with memory mapping?
Apr 25 21:22:16 <Marex> yes, memory translation table
Apr 25 21:24:16 <Marex> try arm.com -> documentation -> arm architecture -> reference manuals -> armv5 -> PDF version
Apr 25 21:27:29 <Marex> mpannen: does T755p by any chance have 64Mb of RAM ?
Apr 25 21:30:11 <mpannen> im back
Apr 25 21:30:58 <mpannen> the phone itself is reporting 62.8 mb
Apr 25 21:31:08 <mpannen> so i guess it is 64mb
Apr 25 21:31:25 <mpannen> free space 46.6mb of 62.8mb
Apr 25 21:36:20 <Marex> hm ... it's still weird
Apr 25 21:36:30 <Marex> are you sure that thing's xscale ?
Apr 25 21:37:52 <mpannen> the palm treo 755p is an xscale pxa something
Apr 25 21:39:04 <mpannen> Intel PXA272 312MHz
Apr 25 21:39:35 <Marex> hmm
Apr 25 21:39:42 <mpannen> Palm OS 5.4.9
Apr 25 21:40:05 <Marex> I see ... still, hmmm
Apr 25 21:43:25 <Marex> mpannen: well ... do you have armarm.pdf (or 14128.pdf) handy already ?
Apr 25 21:43:32 <Marex> (from the website above)
Apr 25 21:44:18 <mpannen> yes
Apr 25 21:44:28 <mpannen> it has a single ttb right?
Apr 25 21:44:33 <Marex> yes
Apr 25 21:44:49 <Marex> try dumping that address then
Apr 25 21:44:51 <mpannen> im looking at b.4.7.1
Apr 25 21:44:53 <Marex> see what it really contains
Apr 25 21:45:02 <Marex> that 0xa1ffc000
Apr 25 21:45:06 <mpannen> ok
Apr 25 21:45:18 <mpannen> ill fire up the usb console and dump it
Apr 25 21:48:12 <mpannen> 0xa1ff9001
Apr 25 21:48:53 <Marex> that's weird
Apr 25 21:48:58 <Marex> try dumping 0xa0004000
Apr 25 21:49:03 <mpannen> what does that mean?
Apr 25 21:49:04 <mpannen> ok
Apr 25 21:49:41 <mpannen> 0x00000000
Apr 25 21:50:03 <mpannen> all zeroes'
Apr 25 21:50:19 <Marex> well 0xa0004000 is TTB address on most palms (and most Xscale devices)
Apr 25 21:50:25 <Marex> hm ... something's wrong
Apr 25 21:51:23 <mpannen> should a try too dump those with haret? or will they be the same
Apr 25 21:51:37 <Marex> you can try
Apr 25 21:51:47 <Marex> I cant get T755p here
Apr 25 21:51:58 <Marex> it's CDMA and they dont sell it here at all
Apr 25 21:53:07 <mpannen> same results
Apr 25 21:53:24 <Marex> try dumping a bit further
Apr 25 21:53:29 <Marex> 0xa0004004
Apr 25 21:53:30 <Marex> 0xa0004008
Apr 25 21:53:31 <Marex> 0xa000400c
Apr 25 21:53:33 <Marex> 0xa0004010
Apr 25 21:53:35 <Marex> etc.
Apr 25 21:57:32 <mpannen> well when i got to 0xa0004018 it reset
Apr 25 21:57:42 <mpannen> all were zeroes
Apr 25 21:58:38 <Marex> um
Apr 25 21:58:47 <Marex> try doing the same at 0xa1ffc000
Apr 25 21:59:05 <Marex> but we're really deep in darkness here
Apr 25 22:00:13 <mpannen> a1ffc004=0
Apr 25 22:00:22 <mpannen> a1ffc008=0
Apr 25 22:00:32 <Marex> f*ck, da**it, sh*t
Apr 25 22:00:41 <mpannen> a1ffc00c=0
Apr 25 22:00:45 <Marex> that's enough
Apr 25 22:00:50 <Marex> something's wrong here
Apr 25 22:01:02 <Marex> mpannen: try one more thing ... try reading from 0x4000
Apr 25 22:01:27 <mpannen> these are virtual addresses that i can enter diredtly right?
Apr 25 22:01:39 <mpannen> i dont need to add something?
Apr 25 22:02:28 <mpannen> for instance, the lcd0 is 04000000, but really 94000000
Apr 25 22:02:28 <Marex> nope
Apr 25 22:02:41 <Marex> maybe RAM is mapped to 0x0
Apr 25 22:02:43 <Marex> that happens
Apr 25 22:02:47 <Marex> so TTB would be at 0x4000
Apr 25 22:02:50 <Marex> give it a go
Apr 25 22:03:57 <mpannen> dump 00004000: c76fb88a49d7b3d7
Apr 25 22:04:11 <Marex> haret you have sucks
Apr 25 22:04:16 <mpannen> o
Apr 25 22:04:19 <mpannen> one sec
Apr 25 22:04:23 <Marex> well it displays some garbage ;)
Apr 25 22:06:39 <mpannen> 00004000: c76fb88a
Apr 25 22:06:53 <mpannen> using cocoboot console mw command
Apr 25 22:08:04 <Marex> still, that's weird
Apr 25 22:08:13 <mpannen> what should it be?
Apr 25 22:08:28 <Marex> it should end with ...c1a or something
Apr 25 22:08:34 <Marex> try 0x01ffc000
Apr 25 22:08:42 <Marex> that's the last option
Apr 25 22:09:26 <mpannen> phone reset
Apr 25 22:10:12 <Marex> it actually makes sense that the TTB can be there
Apr 25 22:10:25 <Marex> retry it again, but disable memory protection first
Apr 25 22:10:31 <mpannen> if the co processor returns the address of the ttb why wouldnt it be right?
Apr 25 22:10:55 <Marex> the problem is we cant access it probably
Apr 25 22:10:57 <mpannen> shit i think i forgot that part
Apr 25 22:11:39 <Marex> it we can unblock access there, we're fine
Apr 25 22:12:08 <Marex> I'll be back in about 10 mins, gotta finish my prep for exam
Apr 25 22:12:48 <mpannen> even after disabling memory protection using the menu option, trying to read that address reset the device
Apr 25 22:12:54 <mpannen> ok
Apr 25 22:14:32 <mpannen> is the ttb read by normal memory access?
Apr 25 22:14:45 <Marex> yes, it's just normal piece of memory
Apr 25 22:15:00 <Marex> looks into ARMARM if there isnt some additional memory protection option
Apr 25 22:16:39 <Marex> also, see PXA27x devman (can still be found at gumstix.com somewhere iirc)
Apr 25 22:19:41 <Marex> http://pubs.gumstix.com/documents/ here you go
Apr 25 22:22:04 <mpannen> ive got em, i was reading up on the co processors in the dev manual
Apr 25 22:22:12 <Marex> good
Apr 25 22:22:14 <mpannen> interesting
Apr 25 22:22:53 <mpannen> i thought i found a typo in the memory protection code
Apr 25 22:22:59 <mpannen> not sure
Apr 25 22:23:44 <mpannen> sm volatile ("mcr p15, 0, %0, c3, c3, 0" : : "r"(0xffffffff) );
Apr 25 22:23:48 <mpannen> a
Apr 25 22:23:53 <mpannen> in arm.c
Apr 25 22:24:05 <mpannen> i thought the second c3 should be c0
Apr 25 22:24:13 <mpannen> but not sure if that mattered
Apr 25 22:24:52 <Marex> iirc it shouldnt matter what's the second argument in case of cp15:r3
Apr 25 22:24:57 <Marex> but give it a go
Apr 25 22:25:00 <mpannen> oh
Apr 25 22:25:01 <mpannen> ok
Apr 25 22:25:05 <mpannen> thats ok then
Apr 25 22:26:16 <mpannen> i see something about data access permissions in ARMARM, does that apply to memory reads?
Apr 25 22:26:33 <Marex> which page ?
Apr 25 22:27:24 <mpannen> 760
Apr 25 22:27:59 <mpannen> maybe the xscale doesnt impliment protected memory
Apr 25 22:28:30 <Marex> xscale is armv5, that should have it
Apr 25 22:28:49 <mpannen> ok
Apr 25 22:29:56 <mpannen> cp15 register 5 for memory access permissions?
Apr 25 22:31:25 <Marex> yes ... looks like so
Apr 25 22:31:30 <Marex> try it
Apr 25 22:32:02 <mpannen> wtf the pxa dev manual says cp15 reg 5 is a fault status register
Apr 25 22:35:06 <Marex> read about that protected memory system architecture
Apr 25 22:35:24 <mpannen> pg 775 of the ARMARM more about pre v6 memory protection
Apr 25 22:37:00 <Marex> mpannen: I'm still integrating using the spheric substitution method ... gimme a little more time ;)
Apr 25 22:37:32 <mpannen> ok, im gonna go integrate some food in my mouth
Apr 25 22:37:34 <mpannen> haha
Apr 25 22:37:50 <Marex> be sure to do it in three dimensions ;)
Apr 25 22:39:25 <mpannen> im gonna do 4d
Apr 25 22:58:23 <mpannen> i cant be looking at the right thing, i think the mpu applies to armv6, not armv5
Apr 25 23:06:32 <Marex> MPU should be v5 too (which is prePMSA6)
Apr 25 23:09:31 <mpannen> also, there is mention of vmsav6
Apr 25 23:10:13 <mpannen> VMSAv6, dont know what version of the virtual memory architecture the xscale uses
Apr 25 23:11:33 <Marex> v5 I think, see pxa manual
Apr 25 23:12:09 <mpannen> yeah must be v5 arm, with VMSAv6
Apr 25 23:12:45 <Marex> this goes beyond me (at least now, I'm still integrating)
Apr 25 23:40:11 <Marex> mpannen: ok, done ... any progress on your end ?
Apr 25 23:42:12 <Marex> mpannen: I think PXA doesn't have PMSA
Apr 25 23:42:46 <mpannen> just reading the armarm
Apr 25 23:46:17 <Marex> mpannen: see pg. 689
Apr 25 23:46:50 <Marex> try reading cp15 r0 with opcode2 = b100 (MPU type register)
Apr 25 23:50:14 <Marex> maybe see bit 8 and bit 9 of CP15 r1 with opcode2 = b000 ...
Apr 25 23:53:34 <mpannen> maybe have to flush the table as well to clear previous permissions?
Apr 25 23:56:21 <Marex> you can try it, but dunno
Apr 26 00:01:53 <Marex> mpannen: maybe you have to flush TLB
Apr 26 00:02:22 <Marex> (sorry, it's too late here, I'm braindead)
Apr 26 00:02:30 <mpannen> looks like there is a flush_caches() defined
Apr 26 00:02:33 <mpannen> for that
Apr 26 00:02:45 <Marex> yup, it's already there
Apr 26 00:05:15 <Marex> add those:
Apr 26 00:05:17 <Marex> asm volatile ("mcr p15, 0, r0, c7, c7, 0" : : : "r0");
Apr 26 00:05:24 <Marex> asm volatile ("mcr p15, 0, r0, c8, c7, 0" : : : "r0");
Apr 26 00:05:40 <Marex> to arm.c:82
Apr 26 00:05:51 <Marex> and try rereading the memory location that was unreadable
Apr 26 00:06:10 <Marex> err ... add also CPWAIT
Apr 26 00:14:55 <mpannen> flush cache?  should add access permission changes? or does the domain register modification take care of that?
Apr 26 00:16:36 <Marex> just append it at the end of the code that's there
Apr 26 00:17:11 <Marex>  81         case ARM_unlock_mem:
Apr 26 00:17:11 <Marex>  82                 asm volatile ("mcr p15, 0, %0, c3, c3, 0" : : "r"(0xffffffff) );
Apr 26 00:17:14 <Marex>  83                 asm volatile ("mcr p15, 0, r0, c7, c7, 0" : : : "r0");
Apr 26 00:17:17 <Marex>  84                 asm volatile ("mcr p15, 0, r0, c8, c7, 0" : : : "r0");
Apr 26 00:17:19 <Marex>  85                 CPWAIT
Apr 26 00:17:22 <Marex>  86
Apr 26 00:17:24 <Marex>  87                 ret = 0;
Apr 26 00:17:27 <Marex> like this
Apr 26 00:17:30 <mpannen> ok
Apr 26 00:17:58 <mpannen> "r0"
Apr 26 00:18:13 <mpannen> "r0" what does that do?
Apr 26 00:18:33 <Marex> asm volatile ("mov r0, #0" : : : "r0");
Apr 26 00:18:38 <Marex> this one is missing there ;)
Apr 26 00:18:54 <Marex> but be sure to backup r0 before doing it and then restore it
Apr 26 00:21:23 <mpannen> "mcr p15, 0, %0, c7, c7, 0" : : "r"(0x0)
Apr 26 00:21:29 <mpannen> would that work?
Apr 26 00:22:26 <Marex> I'm not sure if r0 doesnt have special meaning there
Apr 26 00:23:05 <Marex> just drop that mov r0 #0 before accessing c7 and see what happens
Apr 26 01:51:13 <Marex> http://marex.hackndev.com/status/ :-)
**** ENDING LOGGING AT Sun Apr 26 02:59:57 2009