| 00:21.07 | Genesis | bonne nuit |
| 01:55.09 | *** join/#elinux noclouds (~mhfan@60.166.169.109) |
| 02:39.54 | *** join/#elinux TimRiker (~timr@c-24-1-105-52.hsd1.tx.comcast.net) |
| 02:39.54 | *** mode/#elinux [+o TimRiker] by ChanServ |
| 02:54.42 | *** join/#elinux hufnus (~slonsiki@m4a8336d0.tmodns.net) |
| 03:57.57 | *** join/#elinux cdm (~cdm@adsl-69-109-214-98.dsl.pltn13.pacbell.net) |
| 05:23.11 | *** join/#elinux Toi (~pleemans@d5152D12D.access.telenet.be) |
| 06:05.18 | *** join/#elinux [mYa]_KiD_Reles (~cd@p54A2E841.dip.t-dialin.net) |
| 07:48.58 | *** join/#elinux ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 07:48.58 | *** topic/#elinux is Embedded Linux || http://eLinux.org/ || cross compile, uClibc, busybox, tinylogin, handhelds, post-sale linux installs ;-), etc. || free embedded linux training at http://free-electrons.com/news/news.2004-09-28/en || see prpplague about custom holly-gates jtag dongles |
| 07:48.59 | *** mode/#elinux [+o ibot] by ChanServ |
| 10:31.24 | *** join/#elinux ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 10:31.24 | *** topic/#elinux is Embedded Linux || http://eLinux.org/ || cross compile, uClibc, busybox, tinylogin, handhelds, post-sale linux installs ;-), etc. || free embedded linux training at http://free-electrons.com/news/news.2004-09-28/en || see prpplague about custom holly-gates jtag dongles |
| 10:31.25 | *** mode/#elinux [+o ibot] by ChanServ |
| 10:45.20 | *** join/#elinux [g2] (~g2@g2.nslu2-linux) |
| 11:08.04 | *** join/#elinux pb_ (~pb@2002:5246:d929:1:20a:5eff:fe00:391e) |
| 12:19.45 | *** join/#elinux jamie (~jamie@softmodem.org) |
| 12:20.46 | *** join/#elinux jamie (~jamie@softmodem.org) |
| 12:24.35 | *** join/#elinux Crofton_|laptop (~balister@hc652c632.dhcp.vt.edu) |
| 13:00.36 | *** join/#elinux sorphin (sorphin@mewp.captainrock.com) |
| 13:41.41 | *** join/#elinux ytrewq (~ytrewq@eth13.com-link.com) |
| 13:43.44 | *** part/#elinux ade|desk (~adavey@194.200.143.249) |
| 13:45.39 | *** join/#elinux ade|desk (~adavey@194.200.143.249) |
| 14:13.59 | *** join/#elinux CosmicPenguin (~nobody@aus-ext-proxy02.amd.com) |
| 14:34.07 | CosmicPenguin | bah - compete with apple |
| 14:34.17 | CosmicPenguin | about the only competition linux desktops can beat these days is BeOS |
| 14:54.52 | THeli` | sorphin, it could be a PPC by intel though .. heh |
| 14:55.09 | sorphin | THeli`: taht's not likely tho |
| 14:55.17 | *** join/#elinux CP|Laptop (~nobody@aus-ext-proxy02.amd.com) |
| 14:55.53 | THeli` | but i was thinking apple will have to do way too much to port all their code to x86 |
| 14:56.02 | sorphin | TheCollector: the theory is, is since OSX alredy runs on on x86 (parallel builds), that's why they're doing it |
| 14:56.04 | THeli` | but who knows .. may be they were working on it for a while now |
| 14:56.04 | sorphin | grr |
| 14:56.20 | sorphin | Theli`: the theory is, is since OSX alredy runs on on x86 (parallel builds), that's why they're doing it |
| 14:56.25 | THeli` | dun worry.. it looks like we are the only two in active conv. now |
| 14:56.37 | sorphin | i just hate the stupid name matching |
| 14:56.42 | sorphin | anyways |
| 14:56.51 | THeli | i didnt know OSX ran on x86 |
| 14:56.58 | THeli | thought u need a VM like pearPC or VMware |
| 14:57.02 | THeli | err not VMware.. |
| 14:57.33 | ade|desk | aint it just darwin+ not gui ? |
| 14:57.54 | THeli | darwin yes i heard it has x86 port |
| 14:58.20 | sorphin | well |
| 14:58.27 | sorphin | publically, it's just darwin |
| 14:58.34 | sorphin | but if you look at the roots |
| 14:58.50 | sorphin | osx came from Rhapsody which camed from NeXtStep |
| 14:59.01 | sorphin | all of which had x86 versions |
| 14:59.11 | sorphin | they've just kept the parallel trees |
| 14:59.19 | ade|desk | useful |
| 14:59.35 | sorphin | now |
| 14:59.39 | sorphin | what would make sense |
| 14:59.46 | sorphin | is supporting x86 and ppc |
| 14:59.52 | sorphin | but not just ditching ppc |
| 15:00.11 | sorphin | the G5 is a better processor, imho, than what intel has out there |
| 15:00.20 | THeli | whats that whole altevec dependency for OSX which made it better.. if thats true intel should do something similar probably (which they might cuz apple is a big customer) |
| 15:00.26 | sorphin | AMD tho, is another animal entirely |
| 15:00.49 | sorphin | amd made a 64bit cpu that works |
| 15:01.01 | sorphin | intel had to revc engineer and copy it, because their own sucked |
| 15:01.07 | ade|desk | MIPS all the way :) |
| 15:01.11 | THeli | alpha |
| 15:01.15 | CosmicPenguin | hel yeah! |
| 15:01.17 | sorphin | oh, and how many PPCs do you know of that have MATH ERORRS? :P |
| 15:01.23 | sorphin | or had rather |
| 15:01.31 | CosmicPenguin | bah - so did the pentium for that matter |
| 15:01.43 | ade|desk | sorphin: that was years ago though surely |
| 15:01.48 | sorphin | CosmicPenguin: that's what i was talkign about |
| 15:01.59 | THeli | CosmicPenguin, i think he was being sarcastic :-) |
| 15:02.00 | sorphin | ade| aye, but intel has a way of braking stuff |
| 15:02.09 | sorphin | look how the Celeron was 'invented' |
| 15:02.17 | sorphin | P3s w/ defective cache |
| 15:02.22 | CosmicPenguin | with sorphin I can never tell if he is being sarcastic or not |
| 15:02.37 | sorphin | uhh |
| 15:02.41 | sorphin | wtf are you talking about? |
| 15:02.44 | THeli | sorphin, what its about the all eyes on me effect? intel just gets more attention when bugs are found? |
| 15:03.08 | sorphin | THeli: because their bugs seem to be more substantial |
| 15:03.13 | sorphin | think, F00F |
| 15:03.14 | sorphin | :P |
| 15:03.28 | sorphin | and a cpu that can't even add correctly? |
| 15:03.34 | sorphin | 2+2=1? |
| 15:03.37 | sorphin | :P |
| 15:03.40 | ade|desk | none of the chip makers are much cop, amd had heat problems, ibm die problems, intel maths etc etc .. |
| 15:03.57 | sorphin | CosmicPenguin: where was i being sarcastic? the math flaws i mentioned were strictly intel |
| 15:04.06 | CP|Laptop | I thought you were bad mouthing the PPC |
| 15:04.11 | sorphin | ade| well, if you have heat probs |
| 15:04.16 | CP|Laptop | see - like I said, I can never tell |
| 15:04.18 | sorphin | put on a bigger heatsink/fan |
| 15:04.19 | CP|Laptop | :) |
| 15:04.24 | sorphin | math |
| 15:04.33 | sorphin | is another story |
| 15:04.36 | sorphin | uh |
| 15:04.42 | sorphin | why would i be badmouthing the ppc? |
| 15:04.51 | sorphin | love the G4 |
| 15:04.52 | CP|Laptop | I told you I was confused |
| 15:04.53 | CP|Laptop | drop it |
| 15:04.59 | THeli | mac mini!! grrr |
| 15:05.02 | THeli | with linux i hope? |
| 15:05.04 | sorphin | disappointed the G5 won't go into a notebook :( |
| 15:05.10 | sorphin | uh |
| 15:05.11 | sorphin | no |
| 15:05.13 | sorphin | OSX |
| 15:05.17 | THeli | heh |
| 15:05.28 | THeli | did u see that /. article on debian on mac mini? |
| 15:05.32 | ade|desk | are you a mac lover cos its l337 or cos the technology is really better ? |
| 15:05.55 | sorphin | ade|desk: the tech |
| 15:06.24 | sorphin | do you really think i'd spend $500 to be l33t? |
| 15:06.31 | sorphin | not quite |
| 15:06.32 | ade|desk | .... |
| 15:06.35 | ade|desk | :) |
| 15:06.56 | ade|desk | ~lart sorphin |
| 15:07.32 | sorphin | can't go higher because my 1.24ghz G4 was apparently in a batch that couldn't spec higher |
| 15:07.35 | sorphin | anyways |
| 15:07.43 | sorphin | next topic |
| 15:07.50 | THeli | pr0n? |
| 15:07.50 | ade|desk | overclocking stuff seems like a bad idea to me |
| 15:08.05 | sorphin | ade|desk: only if the item in question can't handle it |
| 15:08.16 | ade|desk | fish ... once upon a time there were 3 little fish .... |
| 15:08.19 | sorphin | some things are speced at a speed, but undercloked |
| 15:08.24 | sorphin | underclocked |
| 15:08.50 | sorphin | THeli: at work, pr0n not an option |
| 15:09.14 | sorphin | CP|Laptop: so what's the scoop? looks like you're still safe at AMD then ? |
| 15:09.37 | THeli | sorphin, hehe |
| 15:11.38 | CP|Laptop | as far as I know |
| 15:11.58 | CP|Laptop | they're still letting me sit in on meetings - I figure thats a good sign |
| 15:13.24 | THeli | lol |
| 15:13.38 | THeli | u dont seem too interested in staying there cosmic |
| 15:16.42 | chouimat | morning |
| 15:16.48 | THeli | moin |
| 15:29.27 | *** join/#elinux prpplague (~billybob@72.22.142.204) |
| 15:36.58 | *** join/#elinux Crofton|laptop (~balister@h80ad94e8.dhcp.vt.edu) |
| 15:39.15 | CP|Laptop | anyone here ever played with ida? |
| 15:39.18 | CP|Laptop | http://www.datarescue.com/idabase/ |
| 15:39.21 | CP|Laptop | its a bad ass little app |
| 15:45.22 | sorphin | cp| yes |
| 15:45.25 | sorphin | i've used it |
| 15:45.36 | CP|Laptop | I've never seen it before yesterday |
| 15:45.48 | CP|Laptop | I was very impressed - it took gdb out behind the woodshed |
| 15:45.58 | sorphin | prpplague: well well, look what the hobo dragged in |
| 15:46.17 | sorphin | CP|Laptop: yeah, IDA is what all the software crackers use too, heh |
| 15:46.31 | sorphin | CP|Laptop: i used it for debugging some MIPS and PPC code |
| 15:46.48 | CP|Laptop | Yeah, we used it to debug a app on the SuSE liveCD |
| 15:47.13 | sorphin | prpplague: was watching Millionare last night and saw a David Anders, obviously wasn't you tho ;) |
| 15:47.24 | Crofton|laptop | prpplague, any luck with the LCD? |
| 15:47.51 | prpplague | sorphin: really? |
| 15:48.01 | sorphin | CP|Laptop: well, i hope they keep you around, i'm sure whatever it was you did, wasn't an intentional mistake |
| 15:48.03 | prpplague | Crofton|laptop: negative, back bunner now for a few days |
| 15:48.07 | sorphin | prpplague: yes, really |
| 15:48.10 | prpplague | wow |
| 15:48.16 | prpplague | not many anders around |
| 16:03.27 | *** join/#elinux Soopaman (~soopaman@67.71.84.91) |
| 16:24.50 | *** join/#elinux Sgt-Donan (~Loutre@lns-vlq-17f-81-56-167-49.adsl.proxad.net) |
| 16:40.48 | *** join/#elinux ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 16:40.48 | *** topic/#elinux is Embedded Linux || http://eLinux.org/ || cross compile, uClibc, busybox, tinylogin, handhelds, post-sale linux installs ;-), etc. || free embedded linux training at http://free-electrons.com/news/news.2004-09-28/en || see prpplague about custom holly-gates jtag dongles |
| 16:40.48 | *** mode/#elinux [+o ibot] by ChanServ |
| 16:44.48 | prpplague | kergoth: hey old sould |
| 16:44.50 | prpplague | soul |
| 16:44.55 | prpplague | kergoth: whats cooking? |
| 16:51.15 | pb_ | g'day plague, kergoth |
| 16:51.36 | prpplague | pb_: hey boss man |
| 17:01.23 | prpplague | pb_: i swear i've never had so much trouble getting a lcd working |
| 17:01.44 | pb_ | hell, you're still fighting with that? |
| 17:02.34 | *** join/#elinux Crofton|laptop (~balister@69-162-157-95.chvlva.adelphia.net) |
| 17:05.55 | prpplague | pb_: hell ya |
| 17:06.14 | prpplague | pb_: should have been a 2 day job and its been like 2 weeks and still nothing |
| 17:06.29 | prpplague | pb_: my best guess is that i've blown the lcd controler |
| 17:07.19 | prpplague | pb_: whats frustrating is everything "looks" correct |
| 17:09.01 | *** join/#elinux ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 17:09.01 | *** topic/#elinux is Embedded Linux || http://eLinux.org/ || cross compile, uClibc, busybox, tinylogin, handhelds, post-sale linux installs ;-), etc. || free embedded linux training at http://free-electrons.com/news/news.2004-09-28/en || see prpplague about custom holly-gates jtag dongles |
| 17:09.01 | *** mode/#elinux [+o ibot] by ChanServ |
| 17:10.10 | prpplague | is it too early to start drinking? |
| 17:10.59 | pb_ | prpplague: suck |
| 17:11.57 | prpplague | pb_: you know anyone that might have experience with the PL110? |
| 17:12.10 | pb_ | sorry, no |
| 17:12.16 | pb_ | could ask on the linux-arm mailing list, I guess |
| 17:16.16 | *** join/#elinux [g2] (~g2@g2.nslu2-linux) |
| 17:17.18 | jamie | prpplague: is that related to the pt110? |
| 17:20.39 | prpplague | jamie: negative, pl110 is a arm highspeed bus module for color/grayscale lcd controler |
| 17:21.12 | jamie | ok |
| 17:22.00 | jamie | does your kit not come with any example/demo program at all? |
| 17:22.11 | jamie | that's usually a good bet, if everything else fails. |
| 17:25.17 | prpplague | jamie: hehe, i'm doing board bringup on custom hardware |
| 17:26.24 | jamie | fair enough. sometimes you have a bit of working code to start with, sometimes you don't :) |
| 17:27.16 | prpplague | jamie: hehe, yea, i have a little from *cough*lineo*cough* but thats of little use |
| 17:27.39 | jamie | does lineo's code do _anything_ useful on your board? |
| 17:27.56 | CosmicPenguin | s/on your board/ |
| 17:29.51 | *** join/#elinux cdm (~cdm@17.255.212.165) |
| 17:30.28 | prpplague | jamie: hehe, yea, its a good base to start from, but they only had it coded for one specific lcd model |
| 17:30.48 | prpplague | jamie: so, i've been going in a making things a little more generic |
| 17:31.11 | prpplague | jamie: i suspect at the stage in the game that we've got some bad hardware |
| 17:32.29 | jamie | That'll teach you not to program your embedded kit outdoors during a thunderstorm :) |
| 17:33.01 | prpplague | jamie: hehe |
| 17:33.23 | prpplague | jamie: yea, i've got the ee looking over the layouts now |
| 17:34.03 | jamie | Could be something as trivial as stray solder or a broken track? Checked the connectivity? |
| 17:34.05 | prpplague | jamie: and whats bad is this lcd fb is the last item i need to push this out the door |
| 17:34.19 | prpplague | jamie: yea, did continuity checks first thing |
| 17:35.12 | prpplague | jamie: my guess is during initial testing the pl110 probably tried to init something that shouldn't have been and fried the controler |
| 17:36.15 | prpplague | jamie: i'm usually pretty good about spotting hardware problems, just my lack of experience with the pl110 is bitting my ass |
| 17:40.31 | CosmicPenguin | wow -that google stock price is out of control |
| 17:45.05 | prpplague | CosmicPenguin: soooooo when are you and the boss coming to visit? hehe, are ya gonna wait till its cold? |
| 17:45.48 | CosmicPenguin | I dunno |
| 17:45.54 | CosmicPenguin | we've spent just a boatload of money this year |
| 17:46.02 | CosmicPenguin | we probably need to tone it down a bit |
| 17:46.03 | prpplague | bummer |
| 17:47.05 | prpplague | hehe |
| 17:53.53 | prpplague | rain rain rain |
| 18:05.16 | *** join/#elinux hufnus (~slonsiki@m153f36d0.tmodns.net) |
| 18:16.52 | *** part/#elinux sorphin (sorphin@mewp.captainrock.com) |
| 18:21.49 | *** join/#elinux Crofton|laptop (~balister@hc652c632.dhcp.vt.edu) |
| 18:36.01 | CosmicPenguin | heh |
| 18:36.12 | CosmicPenguin | I thought use strict; was an iternal command in perl. |
| 18:36.13 | *** join/#elinux darkschneider (~gab@213-140-6-96.fastres.net) |
| 18:57.39 | *** join/#elinux andersee (~andersee@codepoet.org) |
| 18:57.40 | *** mode/#elinux [+o andersee] by ChanServ |
| 19:15.28 | prpplague | CosmicPenguin: lovely, beewoolie pointed me too a big long thread on lak about the pl110 driver |
| 19:15.44 | CosmicPenguin | excellent |
| 19:15.56 | prpplague | CosmicPenguin: not so excellent, lots of bugs |
| 19:19.28 | CosmicPenguin | you mean that you introduced, or just in general? |
| 19:20.15 | prpplague | CosmicPenguin: in general for mono lcd's |
| 19:21.35 | CosmicPenguin | heh |
| 19:22.36 | prpplague | CosmicPenguin: the reason i didn't find it original was it was listed as a problem with qt |
| 19:23.50 | *** join/#elinux markl_ (mark@dsl093-225-013.slc1.dsl.speakeasy.net) |
| 19:25.19 | CosmicPenguin | bah |
| 19:25.21 | CosmicPenguin | stupid people |
| 19:25.24 | CosmicPenguin | learn to write bugs |
| 20:01.44 | *** join/#elinux file[desk] (~jcolp@mctn1-1420.nb.aliant.net) |
| 20:13.26 | *** join/#elinux TimRiker (~timr@TimRiker.active.supporter.pdpc) |
| 20:13.26 | *** mode/#elinux [+o TimRiker] by ChanServ |
| 20:20.38 | *** join/#elinux T0mW (tom@24.229.11.125.res-cmts.sth.ptd.net) |
| 20:25.44 | prpplague | T0mW: thanks |
| 20:25.55 | prpplague | T0mW: i'm going nuts with this pl110 lcd issue |
| 20:26.44 | prpplague | T0mW: i can't seem to get my lcd to do a damm thing |
| 20:30.42 | T0mW | I may sound redundant, but this is exactly the type of situation in which an oscilloscope would simply things. |
| 20:31.22 | T0mW | I can think of a number of tests that I could setup, then observe with a scope to verify things are working as expected. |
| 20:34.23 | prpplague | T0mW: again, i've already checked with oscope |
| 20:34.40 | prpplague | T0mW: tell me then what you would do |
| 20:36.27 | T0mW | Assuming that you've verified that the clock, line strobe, etc periods have all been checked? |
| 20:36.32 | T0mW | right? |
| 20:37.05 | T0mW | you have control over those signals, change a register value then the clockrate to the lcd alters as expected? |
| 20:37.56 | T0mW | mathematics works out that if you put X into register_Y, you see Z-ns of signal? |
| 20:41.26 | T0mW | That would be the first thing that I'd do is to verify that I can exert control over the LCD registers themselves and see an expected change. |
| 20:47.35 | prpplague | T0mW: yea, all of the timming and control seem correct |
| 20:47.47 | prpplague | T0mW: but it doesn't seem to be getting any data |
| 20:48.00 | T0mW | Next step would be to setup the LCD registers to form the control signals shaping as per the LCD spec. e.g. LinePulse polarity, LinePulse period, DotClockPeriod, etc. |
| 20:48.03 | T0mW | ok |
| 20:48.16 | prpplague | T0mW: all of that appears correct |
| 20:48.55 | fishhead | guys |
| 20:48.57 | T0mW | now, don't clear the memory of the framebuffer, I would fill it with some galloping pattern, or just plain junk. |
| 20:48.59 | fishhead | don't mean to interrupt |
| 20:49.04 | fishhead | but did you see this t0wm |
| 20:49.05 | fishhead | http://money.cnn.com/2005/06/06/technology/personaltech/cvs_camera/ |
| 20:49.17 | T0mW | at that point, I would expect to see a bunch of garbage on the display. |
| 20:49.29 | prpplague | T0mW: i would as well, but i get nothing |
| 20:49.33 | T0mW | aha |
| 20:50.20 | T0mW | look at the data lines from the CPU --> the LCD itself, you should see something there: a stream of varying data. |
| 20:50.31 | T0mW | 100011100101010101 |
| 20:50.36 | T0mW | whatever |
| 20:50.51 | T0mW | it should be banging up/down |
| 20:51.35 | T0mW | s/it/they/ |
| 20:53.46 | T0mW | also, look at the rate of change of that data. If the DMA circuitry of the LCD controller is functioning properly, I would expect to see the datalines of the LCD changing at a rate approximating that of the dot clock. |
| 20:55.24 | T0mW | the LCD controller is nothing more than a fancy data pump |
| 20:56.26 | T0mW | It has some fancy features like palletizing color bits, or some such minor change in the value of the data, but it still is a data pumper |
| 20:57.03 | prpplague | one sec boss on phone |
| 20:58.31 | *** join/#elinux Crofton|laptop (~balister@hc652c632.dhcp.vt.edu) |
| 20:58.37 | T0mW | Typically, at the LCD side, there are hardware registers, shift registers n-bits wide, to accept the serialized data stream, then they assert the collected data to the driver array (parallel array: e.g. 800 bits wide, 1024 bits wide, etc) |
| 21:00.00 | prpplague | doesn't appear to be any data going out |
| 21:03.08 | prpplague | T0mW: yea no data |
| 21:03.16 | prpplague | T0mW: tried several things but got nothing |
| 21:05.02 | T0mW | brb |
| 21:05.34 | T0mW | ok |
| 21:06.03 | T0mW | now, I've found that many SDRAMs today will come up with the data cells initialized to ZEROs |
| 21:06.30 | T0mW | you may have to put some data into your frame buffer memory, initialize it with junk. |
| 21:06.54 | T0mW | write a small program or something to do that. |
| 21:07.23 | T0mW | it could also be that when you activate a frame buffer driver, that the driver could be zero-ing the memory. |
| 21:08.15 | T0mW | because of both of these issues, I would not jump ahead to the use of a frame buffer code until I did some user level proofing of the LCD controller operation. |
| 21:10.25 | T0mW | An idea might be to write your own code into the kernel source that will init those registers, fill the frame buffer DMA memory, then startup the LCD controller. Call that function someplace before init() and end the function with a for(;;) loop (forever). |
| 21:11.30 | prpplague | T0mW: should be able to just cat some files to /dev/fb |
| 21:11.59 | T0mW | IF, IF, the DMA address of the LCD controller is set properly, yes. |
| 21:12.19 | T0mW | what we need to do is verify that that address is set correctly. |
| 21:13.00 | T0mW | you may think that the LCD DMA is pointing at the /dev/fb buffer address, but it may be pointing at "air" (no ram at all). |
| 21:13.08 | prpplague | T0mW: right, so how do i double check the matching dma addresses? |
| 21:14.33 | T0mW | There is a disconnect, in the use of the MMU, where the linux sees the /dev/fb memory at one location while the hardware of the LCD controller sees it at another. Remember, the LCD controller is probably not affected by the MMU settings of the CPU. The MMU is there to virtualize the operation of the CPU, not the hardware. |
| 21:15.49 | prpplague | T0mW: correct |
| 21:15.57 | T0mW | ok |
| 21:16.13 | prpplague | T0mW: so how do i verify the address? hehe |
| 21:17.20 | T0mW | IIRC, ioremap would let you take a portion of the CPU's virtualized memory and map it to another virtual space? I'm not sure if ioremap has been deprecated in the 2.6 kernel or not, it was there in 2.4 |
| 21:17.21 | prpplague | T0mW: hmm, the dma controler doesn't appear to have any streams enabled |
| 21:17.38 | prpplague | T0mW: this is 2.4 |
| 21:17.42 | T0mW | good |
| 21:18.04 | prpplague | the odd question is why isn't the dma enabled |
| 21:18.07 | T0mW | that is how I accessed the IDE hardware of the TuxScreen |
| 21:19.14 | T0mW | I setup CS3 (Chip Select 3) for a hard address in the physical memory map, then I used ioremap to map that address over to a location within the virtual space so I could get at it. |
| 21:19.41 | T0mW | your MMU setup, head.S?, should do that mapping for you. |
| 21:20.15 | T0mW | you know the code I'm talking about, where the RAM, etc., gets mapped from real to virtual space? |
| 21:21.35 | prpplague | T0mW: yea, i know the code, but my question is why i have no dma streams being used |
| 21:21.54 | T0mW | even if that code is wrong, you should be able to change the LCD DMA register address to some eventual location and get junk coming out the LCD data lines. keep trying differnet locations, maybe write a program that switches that address every two seconds or so and walk it down through the memory space. |
| 21:22.30 | T0mW | prpplague: what do you mean by "no dma streams" ? |
| 21:22.42 | prpplague | T0mW: thats the word sharp uses |
| 21:22.48 | prpplague | T0mW: for their dma controler |
| 21:22.54 | T0mW | some error code? |
| 21:22.57 | prpplague | T0mW: the dma controler has 4 "streams" |
| 21:23.13 | prpplague | T0mW: no, doesn't even look like they've been initialized |
| 21:23.18 | T0mW | oh |
| 21:24.12 | T0mW | I would step away from /dev/fb and get back to basics. e.g. can I affect the LCD controller directly. PROVE what is right, not find what is wrong. |
| 21:24.55 | prpplague | T0mW: hmm, that is a problem as i'm not sure how to effect it directly |
| 21:25.36 | T0mW | all you really have to remember is that the LCD controller is a data pump |
| 21:25.59 | CosmicPenguin | prpplague: yeah - if you have the address wrong, that would explain a lot |
| 21:26.08 | T0mW | it sucks data from RAM, then spits it out the LCD interface. |
| 21:27.49 | T0mW | dot clock should be 90 degrees out of phase with the data. Line pulse is the latch for one line of dots and advances the internal Row Counter of the LCD display (horizontal sync), FRAME resets the Row Counter (vertical sync). |
| 21:28.07 | T0mW | prpplague: what type of display are you using? |
| 21:28.20 | T0mW | TFT, SDN, DSTN, ??? |
| 21:30.12 | T0mW | even if you have the dot clock, line pulse, frame timings all messed up, you should still see data coming out the LCD data lines. Provided you have properly setup the "pump" to actually run |
| 21:30.17 | prpplague | STN |
| 21:31.28 | T0mW | IIRC, there is a pin shift when interfacing to STN with that controller, it is a controller that will do high-end displays like TFT, but you can force it to also do STN + DSTN, but you have to play some tricks with the electrical hookup. |
| 21:31.42 | T0mW | be that as it may, you will still have something on the data lines. |
| 21:32.01 | T0mW | STN displays are nothing more than RASTER devices. |
| 21:32.48 | T0mW | shift dots, latch, shift dots, latch, frame sync (reset to top of display), then repeat |
| 21:33.19 | T0mW | works exactly like a CRT |
| 21:34.23 | T0mW | only differnce is how it behaves if you try to operate it at too high a frequency, it doesn't get diagonal lines. heh |
| 21:36.57 | T0mW | crap |
| 21:37.26 | T0mW | I thought I had a schematic for the D-STN hookup that I put together, but I can't find it. |
| 21:37.58 | T0mW | prpplague: whatever, your job is to get data pumping out those data lines. |
| 21:38.16 | T0mW | prpplague: doesn't have to be real data, just get them to wiggle |
| 21:41.44 | prpplague | T0mW: yea |
| 21:48.25 | prpplague | hmm, ok, i have an address now to see whats in it |
| 21:50.37 | T0mW | prpplague: I searched the web many times looking for any code that dealt with setting up that LCD controller. nada, nothing |
| 21:50.54 | T0mW | prpplague: not even a pdf |
| 21:51.09 | prpplague | T0mW: yea |
| 21:51.24 | T0mW | failure on Sharp's part |
| 21:51.39 | prpplague | T0mW: ok so when i write data to fb it shows up at the same address that the dma controler is set for |
| 21:55.29 | prpplague | sharps docs suck |
| 21:55.51 | prpplague | must be why they didn't even use their own chips in the zaurus line |
| 21:58.05 | T0mW | prpplague: right, good test |
| 21:58.55 | T0mW | CPU --> /dev/fb --> MMU --> physical address == LCD_DMA_ACCESS_ADR --> physical address |
| 22:00.54 | T0mW | of course, the frame buffer ram is at a fixed address. Otherwise, if you use a floating address for the buffer frame, the /dev/fb could do this by accessing the LCD_DMA_ADDRESS regs and setting it to the proper location. |
| 22:01.40 | T0mW | either way may be how it is done, I suspect that a chunk of memory is allocated, then the /dev/fb points the LCD controller to it's location |
| 22:02.19 | T0mW | but, it should have to unmap the virtual space over to physical when it assigns it to the LCD DMA regs |
| 22:26.08 | *** join/#elinux Sad^EYES (~sad@bzq-119-49.red.bezeqint.net) |
| 23:05.12 | *** join/#elinux CosmicPenguin (~nobody@aus-ext-proxy02.amd.com) |
| 23:09.35 | prpplague | T0mW: there is no way i can test the physical address, as its not posted |
| 23:23.56 | CosmicPenguin | Mmm... as if the Mt. St. Helens webcam wasn't fun enough |
| 23:23.58 | CosmicPenguin | http://www.nps.gov/yell/oldfaithfulcam.htm |
| 23:24.53 | T0mW | CosmicPenguin: cool! |
| 23:25.08 | T0mW | CosmicPenguin: I was out there last August |
| 23:27.31 | CosmicPenguin | Probably a tad warmer then it is right now |
| 23:27.39 | CosmicPenguin | The webcam is crappy, but I swear its snowing |
| 23:27.49 | CosmicPenguin | Maybe not, 7C is a bit toasty for snow |
| 23:27.51 | *** join/#elinux markl_ (mark@dsl093-225-013.slc1.dsl.speakeasy.net) |
| 23:56.49 | *** join/#elinux George__ (george@83.146.61.45) |