| 00:00.27 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 01:05.32 | *** join/#edev landley (~landley@69.38.217.222) |
| 01:05.47 | *** join/#edev Crofton (~balister@69.38.217.222) |
| 01:44.17 | *** join/#edev eephillip (~eephillip@pdpc/supporter/student/eephillip) |
| 02:08.56 | *** join/#edev unix (~fire@unaffiliated/security) |
| 02:27.57 | *** join/#edev _Lucretia__ (~munkee@5ac5603a.bb.sky.com) |
| 02:29.00 | *** join/#edev Crofton (~balister@69.38.217.2) |
| 03:09.17 | *** join/#edev Shinda_ (~Loup@unaffiliated/toroop) |
| 03:50.28 | *** join/#edev landley (~landley@199-116-73-136.PUBLIC.monkeybrains.net) |
| 04:20.12 | landley | So calculus is here, wmat is here, and prpplague is here. |
| 04:21.15 | landley | At about 5pm I hit the jetlag level of "I can't gearshift and socialize in person effectively with people I only know online! Brain not up to it!" |
| 04:35.56 | *** join/#edev Shinda (~Loup@136.28-136-217.adsl-dyn.isp.belgacom.be) |
| 04:35.56 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 04:44.44 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 05:44.01 | *** join/#edev mbuf (user@nat/redhat/x-lkrlhbehfasvqlvo) |
| 06:17.14 | *** join/#edev clio (~andrej@85.159.109.222) |
| 06:38.48 | *** join/#edev Shinda (~Loup@136.28-136-217.adsl-dyn.isp.belgacom.be) |
| 06:38.48 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 07:05.11 | *** join/#edev Shinda_ (~Loup@unaffiliated/toroop) |
| 07:55.12 | *** join/#edev Shinda_ (~Loup@unaffiliated/toroop) |
| 08:06.21 | *** join/#edev pvanhoof (~philip@codeminded.be) |
| 08:26.32 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:26.32 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:42.42 | *** join/#edev Shinda (~Loup@215.31-136-217.adsl-dyn.isp.belgacom.be) |
| 08:42.42 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 08:45.22 | *** join/#edev calculu5 (~calculus@gentoo/user/calculus) |
| 09:16.14 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 09:20.07 | *** join/#edev Shinda (~Loup@215.31-136-217.adsl-dyn.isp.belgacom.be) |
| 09:20.08 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 09:31.05 | *** join/#edev Shinda_ (~Loup@215.31-136-217.adsl-dyn.isp.belgacom.be) |
| 09:31.06 | *** join/#edev Shinda_ (~Loup@unaffiliated/toroop) |
| 09:40.36 | *** join/#edev Shinda (~Loup@215.31-136-217.adsl-dyn.isp.belgacom.be) |
| 09:40.36 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 09:47.59 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 09:52.34 | *** join/#edev Shinda (~Loup@215.31-136-217.adsl-dyn.isp.belgacom.be) |
| 09:52.34 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 10:51.09 | *** join/#edev mrcan (~mrcan@unaffiliated/mrcan) |
| 11:50.54 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 11:50.54 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 12:15.32 | *** join/#edev nollan (jgr@uuoc.org) |
| 12:17.26 | *** join/#edev Anaphaxeton (~george@ppp005054026153.access.hol.gr) |
| 12:53.04 | *** join/#edev T0mW (~Tom@75.97.101.235.res-cmts.t132.ptd.net) |
| 12:53.15 | T0mW | <sigh> |
| 12:53.26 | T0mW | This has really got me bugged. |
| 12:54.21 | T0mW | I've been working for a few days to get access to my framebuffer memory using mmap, and, googling like mad to find out why I cannot affect the contents of the screen buffer. |
| 12:55.21 | T0mW | This is code taken from an ARM project to open the console, put it into graphics mode, then mmap the filehandle over to get access to the info->screenbase. That code words on ARM. |
| 12:56.11 | T0mW | When I try the same thing on this ATOM board, I can put the video into graphics mode, mmap the frame buffer, but nothing happens when I write to it. |
| 12:57.31 | T0mW | I've verified that the info->screenbase ram is unaffected, mmap returns a valid address (no error), I can copy something into /dev/fb0 and it appears on the screen, but accessing the buffer at the address returned by mmap yields nothing. |
| 12:58.24 | T0mW | When I copy back from the buffer, memcpy (myBuffer, VideoFrame, nnnn), all I get is FF's. |
| 12:59.53 | T0mW | this is my mmap call: fbp = (unsigned char *)mmap(NULL, finfo.smem_len, PROT_WRITE, MAP_SHARED, fbfd, 0); |
| 13:00.16 | T0mW | anyone got any ideas as to how to resolve this? I'm out of ideas at this point. |
| 13:01.20 | chouimat | morning |
| 13:01.35 | T0mW | chouimat: good morning, cold up there? |
| 13:01.49 | chouimat | T0mW: not so bad only -15C |
| 13:02.18 | T0mW | goes to calculator to translate to Fahrenheit |
| 13:02.57 | T0mW | chouimat: -10 here |
| 13:03.39 | chouimat | T0mW: anything new and fun lately? |
| 13:04.12 | T0mW | chouimat: Got married last June, that is new. |
| 13:04.31 | chouimat | T0mW: congrats |
| 13:04.49 | T0mW | chouimat: thanks |
| 13:05.41 | T0mW | chouimat: we met through mutual friend, so, maybe that gives us a chance at this. |
| 13:06.35 | chouimat | T0mW: probably. Here nothing much just trying to put the final touch to a project from hell. and I had the chance to play with a prototype board with a nice zynq |
| 13:07.32 | T0mW | chouimat: yeah, I've got a March 1st deadline on this project. Been a bit of B!TCH to resolve some issues. |
| 13:07.59 | T0mW | chouimat: porting old code onto a radically new platform. |
| 13:08.44 | T0mW | chouimat: at least the o/s is now linux, the old one was proprietary. |
| 13:10.02 | chouimat | T0mW: this one started badly because the other guy took the wrong route and kind of pissed off the customer. I went to a completely new direction and got stuck for over a month with kernel problems. now it nearly finish, I just need to update the field upgrade but they decided to change the ECC so now I'm stuck to figure how to keep 1 for xloader/uboot/env and the other one for the rest |
| 13:10.54 | T0mW | chouimat: haven't any experience with ECC, yet. |
| 13:11.43 | chouimat | T0mW: same here |
| 13:11.47 | T0mW | chouimat: right now, I'm trying to resolve an issue with mmap of my custom screen buffer. |
| 13:12.31 | chouimat | T0mW: never touch frambebuffer. Just spend a month and half trying to get alsa working |
| 13:12.51 | T0mW | I can successfully (?) map the screen buffer ram, but nothing changes in the buffer when I do anything from the user side. |
| 13:13.02 | T0mW | LOL, alsa sux |
| 13:13.33 | T0mW | alsa and the printer are two areas I dread working with. |
| 13:15.01 | T0mW | chouimat: the other project, that I hope to get back onto soon, they want to implement some kind of VOIP for point-to-point. |
| 13:15.48 | T0mW | I've only got a 400MHz ARM9 on the board, so it might get "interesting". |
| 13:16.21 | av500 | T0mW: but the framebuffer works? |
| 13:16.31 | av500 | so the kernel can draw pixels into it? |
| 13:16.58 | T0mW | av500: yeah, works great. I can create a binary image and copy it to /dev/fb0, that works too. |
| 13:17.18 | av500 | dump the phys addr and use /dev/mem :) |
| 13:17.19 | chouimat | T0mW: this project is a ip speaker. the kind of system you will use in school or big companies |
| 13:17.41 | T0mW | av500: hmmm |
| 13:19.00 | T0mW | av500: never used dev/mem, should I open it as a file, fseek to the phys address? |
| 13:21.04 | T0mW | physical addr of the buffer is 0xf9814000, so I assume fd = fopen("/dev/mem", "r"); fseek (fd, 0xf9814000, SEEK_SET); ? |
| 13:22.55 | T0mW | googles |
| 13:25.19 | av500 | I never used /dev/mem |
| 13:25.29 | av500 | but that or mmap |
| 13:25.32 | T0mW | av500: the mmap seems to be doing something. I can write to it without SIGSEGV, so, maybe /dev/mem is the answer. Write a pattern into the mmap'ed area, then slide through /dev/mem to see where the fsck it went... |
| 13:25.36 | chouimat | would use dd, just because he can :) |
| 13:26.14 | av500 | I mean mmap on /dev/mem |
| 13:27.03 | av500 | http://forum.kernelnewbies.org/read.php?13,2316 |
| 13:27.13 | T0mW | mmap is the problem, I can map the file descriptor successfully, but reading / writing the newly mapped address gives incorrect results. Write a pattern into the mmap'ed region (memcpy) then copy it back out again and it comes up FF's. |
| 13:27.38 | T0mW | chouimat: LOL |
| 13:28.09 | T0mW | av500: AH |
| 13:28.18 | chouimat | ok time for another coffee, shave, shower and go to the office |
| 13:28.23 | chouimat | :( |
| 13:28.43 | T0mW | av500: I see what you're saying. If you cannot get to the buffer directly, then access it via /dev/mem using mmap. |
| 13:29.00 | T0mW | av500: interesting |
| 13:29.48 | T0mW | just wish that I could figure out why the "right" way doesn't work. It might be indicative of a basic problem with my video driver. |
| 13:29.58 | av500 | what hardware? |
| 13:30.29 | *** join/#edev arun (~arun@unaffiliated/sindian) |
| 13:30.31 | T0mW | nastly little proprietary interface to an Electro Luminesent display. |
| 13:31.00 | av500 | with its own framebuffer? |
| 13:31.55 | T0mW | really nothing more than an I/O port you shove bits into. I had to create a framebuffer with a ram field to lay out the dots (pixels), then shove the changed area(s) out to the hardware using I/O operations. |
| 13:32.29 | T0mW | My problem is accessing that ram field (info->screenbase) via mmap. |
| 13:32.57 | T0mW | it has a physical address, 0xf9814000, and a length, 0x2580. |
| 13:33.21 | av500 | ah ic |
| 13:33.21 | T0mW | it is contigous ram. |
| 13:34.08 | T0mW | they love this EL display because you can read it from 20ft away. I hate it because it is slow. |
| 13:34.23 | chouimat | hehe |
| 13:34.58 | T0mW | pissing data down an 800KHz bus into a set of latches (Address, mode, data). |
| 13:35.31 | T0mW | Ah well, it pays for my exhorbitant lifestyle... |
| 13:36.28 | T0mW | I can't figure this. The memcpy operation succeeds so the data is going somewhere, but when you copy back it gives FF's. |
| 13:38.40 | chouimat | T0mW: the "old" rootfs on the product I'm working on was 288MB, I managed to keep the same functionality in about 60-65MB |
| 13:39.18 | T0mW | chouimat: ouch |
| 13:40.55 | chouimat | T0mW: and the reason they gave me for that is lack of time. and I understand why: their marketing people, CFO and also the guy (Mitel owner) who invested in them are the type it need to be done yesterday |
| 13:42.39 | T0mW | chouimat: yeah. I got hired to do upgrade to one product and build a new product. In the two years I've been with them, they've conspired to heap all kinds of other work on me to the detriment of the project. |
| 13:43.04 | T0mW | chouimat: they now wonder why nothing has been done on the two projects... |
| 13:43.41 | T0mW | I keep telling them, if it's not in the weekly report then it ain't gettin' worked on. |
| 13:44.21 | T0mW | chouimat: hey, at least it is their money, not mine. |
| 13:44.22 | chouimat | T0mW: the thing I "like" about them is they somewhat listen to us, but all their developer are php/application developer. One of them as just enough understanding in embedded/microcontroller to be dangerous and they listen to him |
| 13:44.44 | T0mW | yup |
| 13:45.50 | chouimat | T0mW: like the requirement I have: can't touch uboot but we want BCH8 in linux. problem if I update the uboot env (HW 1bit) from linux (BCH8) guess what happens ... |
| 13:46.45 | T0mW | chouimat: the owner is the primary developer on this product that I'm upgrading. While I'm working at porting the thing, he is going full tilt changing his code. He wants me to "patch" his changes in later... HA! |
| 13:46.52 | chouimat | T0mW: and also they want to use NFS for the field upgrade ... over internet |
| 13:47.04 | T0mW | chouimat: yeah, right. |
| 13:47.05 | chouimat | T0mW: ouch |
| 13:47.47 | T0mW | chouimat: I keep telling this guy, CPU8 is not CPU7, it resembles CPU7 becuase that is what I started with. |
| 13:48.10 | T0mW | chouimat|away: have fun todaY! |
| 13:48.12 | chouimat|away | T0mW: :) |
| 13:48.34 | chouimat|away | T0mW: I will try. I know I will have a lot of free booze tonight |
| 13:49.15 | chouimat|away | so I have to get that done today :( |
| 13:49.18 | T0mW | goes back to looking at fb_mmap |
| 13:59.33 | *** join/#edev mnemoc (~amery@geeks.cl) |
| 14:02.10 | *** join/#edev ikona_ (~ikona@e181082117.adsl.alicedsl.de) |
| 14:05.03 | *** join/#edev unix (~fire@unaffiliated/security) |
| 14:13.39 | T0mW | This doesn't look right: vm_get_page_prot() is given the VM_IO and VM_RESERVED flags. This is RAM why is VM_IO set? |
| 14:53.39 | Kasreyn | anyone good with MMC/SD drivers? i have documented the init sequence here https://docs.google.com/spreadsheet/ccc?key=0Akk0RTOg87FcdFRwSnQ1bEY4RnVfaU9ON1NXV1luY3c&usp=sharing looks like it sends back the same data but the id gets filled with garbage characters.. "14.0 GiB" is wrong and it prints out a clear screen character somewhere.. :> |
| 14:53.49 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 14:53.49 | *** mode/#edev [+o GPSFan] by ChanServ |
| 14:57.41 | *** join/#edev sndcrb (~sndcrb@cs181245200.pp.htv.fi) |
| 15:27.43 | *** join/#edev sndcrb (~sndcrb@cs181245200.pp.htv.fi) |
| 16:33.33 | *** join/#edev blueness (~hnsctq40@cpe-67-252-134-33.buffalo.res.rr.com) |
| 16:33.33 | *** join/#edev blueness (~hnsctq40@gentoo/developer/blueness) |
| 16:59.32 | keesj | Kasreyn: in the 2.6.32 it sends a CMD5 . is you card a sdio card? |
| 17:00.19 | keesj | I am not clean what the flags field represents |
| 17:01.16 | *** join/#edev sndcrb (~sndcrb@cs181245200.pp.htv.fi) |
| 17:21.18 | *** join/#edev landley (~landley@69.38.217.222) |
| 17:21.25 | Kasreyn | keesj: CMD5 is wake from sleep yes?.. i'm not sure if it's supposed to do that.. |
| 17:22.02 | Kasreyn | it's an average Sandisk SD card though |
| 17:22.41 | Kasreyn | curious it's doing that when it didn't before.. |
| 17:24.19 | Kasreyn | also not sure why some of the flags differ |
| 17:25.06 | Kasreyn | havn't had time to dig out what the extra bit set is for |
| 17:58.39 | *** join/#edev florian (~fuchs@sign-4db60761.pool.mediaWays.net) |
| 17:58.39 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 17:59.39 | *** join/#edev balister_ (~balister@69.38.217.222) |
| 18:23.57 | *** join/#edev chouimat (~mathieu@206.191.34.211) |
| 18:23.57 | *** join/#edev chouimat (~mathieu@kde/developer/chouinard) |
| 18:26.35 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 18:53.15 | *** join/#edev landley (~landley@69.38.217.222) |
| 19:01.35 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 19:02.14 | *** join/#edev baba (~fire@unaffiliated/security) |
| 19:06.12 | *** join/#edev chouimat (~mathieu@kde/developer/chouinard) |
| 19:06.17 | chouimat | hi |
| 19:12.35 | *** join/#edev prpplague (~prpplague@69.38.217.222) |
| 19:12.36 | *** mode/#edev [+o prpplague] by ChanServ |
| 19:30.39 | *** join/#edev prp^2 (~prpplague@69.38.217.222) |
| 19:30.40 | *** mode/#edev [+o prp^2] by ChanServ |
| 19:35.15 | *** join/#edev gustavoz (~gustavoz@host36.190-138-230.telecom.net.ar) |
| 19:37.41 | *** join/#edev prpplague (~prpplague@66-87-67-161.pools.spcsdns.net) |
| 19:37.41 | *** mode/#edev [+o prpplague] by ChanServ |
| 19:42.30 | *** join/#edev sndcrb (~sndcrb@cs181245200.pp.htv.fi) |
| 19:45.53 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 19:50.05 | *** join/#edev landley (~landley@69.38.217.222) |
| 20:22.08 | *** join/#edev sndcrb (~sndcrb@cs181245200.pp.htv.fi) |
| 20:40.03 | *** join/#edev Crofton (~balister@69.38.217.2) |
| 20:52.34 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 20:52.34 | *** mode/#edev [+o GPSFan] by ChanServ |
| 21:29.57 | *** join/#edev Shinda (~Loup@4.56-136-217.adsl-dyn.isp.belgacom.be) |
| 21:29.57 | *** join/#edev Shinda (~Loup@unaffiliated/toroop) |
| 21:54.07 | *** join/#edev prpplague (~danders@69.38.217.2) |
| 22:54.33 | *** join/#edev lemonade` (~lemonade`@pool-71-178-51-174.washdc.fios.verizon.net) |
| 23:59.48 | *** join/#edev prpplague (~danders@69.38.217.222) |