2011-10-22 00:22 DocScrutinizer: thanks a lot for your commentary, I'll try everything out. That is really promising. 2011-10-22 00:23 I'd never figure out most of the things you said. 2011-10-22 00:24 (test pattern) I have another picture now: this (http://www.lagom.nl/lcd-test/img/colorbands.png) turns into this (http://rghost.ru/26551661.view) 2011-10-22 00:24 whitequark: well, that's my job. Nah actually my vocation 2011-10-22 00:26 as I don't currently have any physical access to the board (difficult story, but that's just so: I need to go to the other side of the city to test it), here is what I was able to think of: (this LCD has 6 color bits per channel) somehow two most significant bits for R got swapped 2011-10-22 00:27 I've verified the schematics, maybe, ten times, and got another pair of eyes over it: I'm pretty sure it is correct. Moreover, a TFT board designed to be placed instead of my one on the motherboard exists (vice versa actually), the colors on it, including this pattern, are correct, and the pinout on the connector is the same on my board and that one 2011-10-22 00:28 i.e. it's not a double error on both the motherboard and TFT board (same manufacturer) 2011-10-22 00:29 and it's not the video RAM, nor the bus from CPU to VRAM 2011-10-22 00:29 yeah 2011-10-22 00:29 so you say it's definitely your LCM board that messes it up? 2011-10-22 00:30 it doesn't have a separate VRAM btw, it's an AT91SAM9G45, and as other Atmel ARMs, the videobuffer is allocated from system RAM (external DDR2 in this case) 2011-10-22 00:30 (mess up) either my TFT-to-LVDS board, or it's the LCD itself which is screwed up 2011-10-22 00:30 :nod: 2011-10-22 00:31 maybe they've missed two traces on the LCD and to cut manufacturing/fixing costs did the same on the notebook motherboard 2011-10-22 00:31 I don't know if this can really happen 2011-10-22 00:31 just maybe 2011-10-22 00:31 maybe you got a short from HSYNC to one of the data lines? 2011-10-22 00:32 hm 2011-10-22 00:32 (probably the RSB according to your prev observations and thoughts) 2011-10-22 00:32 s/RSB/R MSB/ 2011-10-22 00:34 may I ask why do you think so? From my knowledge (probably incomplete or somewhat) the HSYNC is high for the entire line and goes low only on line start, so it will effectively make the R MSB always high, and in this case four separate sections may be observed (they really have different colors, it's just the photo which is bad) 2011-10-22 00:34 (I'm asking because that was also the first idea which my father said--he's an EE too--and I still do not quite understand how they can be related) 2011-10-22 00:37 regarding the actual short: any R traces and HS are placed (quite) far on the board. I'll still check, but IMO that's unlikely 2011-10-22 00:37 hmm, I dunno what is the exact signal shape of your "HSYNC" - for classical TV hsync you're of course right. But there's a significant lock of that error to line position and that's where you only can think of HSYNC to have that lock to line pos 2011-10-22 00:38 there's that very obvious break into 4 zones 2011-10-22 00:38 ah yes. I should then say that the quirk was first discovered on my site (http://whitequark.org) 2011-10-22 00:38 and both blue and red are behaving completely weird 2011-10-22 00:38 see that gray gradient behind the menu? Blog | Archives | Github 2011-10-22 00:38 the downmost part of it was almost red 2011-10-22 00:39 (blue) that's the crappy camera again. the blue stripe looks good on actual device 2011-10-22 00:40 but blue in that pink stripe freaks out 2011-10-22 00:40 here it is: http://rghost.ru/26550941.view 2011-10-22 00:40 well maybe not 2011-10-22 00:41 you got a scope? 2011-10-22 00:41 a 25MHz one 2011-10-22 00:41 suffices 2011-10-22 00:42 just find that line that has a square wave of exactly 4 times the horizontal frequency 2011-10-22 00:42 or rather: "that has a completely messed up signal faintly resembling a square wave of..." 2011-10-22 00:42 (the PLL inside the lvds serializer locks on frequences of 20-65MHz. the quirk on very first picture with Konata was caused by divider inaccuracy which provided input clock of more than 65M) 2011-10-22 00:42 hmm 2011-10-22 00:45 [commit] Werner Almesberger: labsw/ch12.sch: added BJT and diode current (master) http://qi-hw.com/p/wernermisc/db53a18 2011-10-22 00:45 [commit] Werner Almesberger: labsw/BOM: almost complete BOM (master) http://qi-hw.com/p/wernermisc/adb8d40 2011-10-22 00:45 do you think that I was so lucky to load the webpage with LCD test image and instantly get some rogue square wave signal to mess up my red channel? or, in other words: I'm too stupid to understand how the downmost part of that grayscale gradient may have happened in the case of square wave interference 2011-10-22 00:45 *to mess up my red channel on exactly the test stripe part borders 2011-10-22 00:49 (hsync & vsync) I've seen them on the scope: they work exactly this way, i.e. vsync is low on vblank and hsync is low on hblank. at least that corresponds with the timings in datasheet, i.e. I have only one hsync pulse per line and vsync pulse per frame 2011-10-22 00:50 well I'll check it of course (when I'll get to the device). but it is still quite mysterious for me 2011-10-22 00:51 I guess your LCM controller is defect then 2011-10-22 00:53 do you mean the one in CPU, the serializer or the chip on the LCD itself? 2011-10-22 00:53 i.e. what should I try to replace 2011-10-22 00:56 err, nevermind. I have another motherboard, another LVDS board and another LCD (which has exactly the same timings in the datasheet, but different manufacturer and partnumber on the PCB and was salvaged from a notebook of a completely different vendor. still does not guarantee it's different, through). I'll just build a second system from scratch 2011-10-22 00:57 I meant the logic after LVDS next to (or rather inside) the LCD, that for sure has some PLL or oscillator or whatever that syncs to HSYNC*2 and is creating that 4 zones 2011-10-22 00:58 hm 2011-10-22 00:59 I've seen the pixel clock (hs & vs are bound to it) for this LCD changed to different values in 20-65 mhz range. the picture was the same 2011-10-22 00:59 that's still possible through 2011-10-22 01:01 of course this doesn't explain instantly how the one-pixel-off effect of your manga picture happened 2011-10-22 01:03 though... If the hsync*2 internal oscillator got some interference to the R MSB, then quite possibly the R MSB would interfere with that osc as well, and could make it jiter and sometimes pick the pixel one-off 2011-10-22 01:03 the one-pixel-effect was very probably caused by PLL of LVDS serializer mislocking to a frequency higher than its acceptable range. the ARM, or, more precisely, the code in atmelfb rounded 65000000 Hz up to some larger value, which I've not noticed immediately. when the ARM pixel clock is within the range, the one-pixel-off effect disappears 2011-10-22 01:04 ahaaa 2011-10-22 01:09 also the test picture has wide black padding (it is not quite obvious from the photo, but it is displayed on actual LCD too), and the stripe is divided into four equal parts, so that's not HSYNC*2/HSYNC*4 2011-10-22 01:09 it still may be (the visible area)*2/*4 2011-10-22 01:09 e.g. it locks on a previous stripe somehow 2011-10-22 01:10 or maybe on the first line of red stripe 2011-10-22 01:14 maybe make a test image that looks like this ? http://downloads.qi-hardware.com/people/werner/ubb/vga/web/ubb-vga-pub-1024-medium.jpg 2011-10-22 01:15 make sure it's not just R4 short to R5 or sth 2011-10-22 01:15 anyone about? 2011-10-22 01:15 each square is 50 x 50 pixels, the diagonals are 45 deg and meet exactly at the border, etc. 2011-10-22 01:15 that way, you can see a lot of weird timing problems fairly quickly 2011-10-22 01:16 it's not designed for detecting color problems, though. well, except for the most trivial ones, like an entire channel missing :) 2011-10-22 01:17 sure, thanks. I think it can be adapted a bit to do that 2011-10-22 01:17 how many fields are in those ramp bars? might there be just a switching of R4 level 4 times across the bar (or R5 to R6?) 2011-10-22 01:17 DocScrutinizer: 32 2011-10-22 01:17 and the LSB of R is grounded on the motherboard for some reason 2011-10-22 01:18 so this pattern is switching all the red bits present 2011-10-22 01:18 yep and M(-1)SB is switching 4 times 2011-10-22 01:19 short of M(-1)Sb to MSB would pretty much explain the efect 2011-10-22 01:19 well I've checked the board for shorts, but you can never know where you got one ... 2011-10-22 01:20 I'll check again tomorrow 2011-10-22 01:22 ok it's 5AM here. that's bedtime I think :D thanks again for all the suggestions, this channel is always a great source for inspiration 2011-10-22 01:24 quick question ... trying to get BNN to require console login at boot.. Root paasswd set  gmenu2x is out of inittab and ash --login is in.. scoured the wiki but cant seem to find how to get it to require a password?!?  Could be I'm brain dead  ( almost 0 sleep last nght) any suggestions? 2011-10-22 01:29 Freemor: may be you need pam? 2011-10-22 01:33 maybe the startup scripts just unconditionally fire up a shell ? 2011-10-22 01:33 Hmm.. or the login command which seems to be missing.. was hoping to keep the install as "stock" as possible 2011-10-22 01:34 ah yes there is a nanonote startup script too 2011-10-22 01:35 Hmmm... maybe bash instead of ash? 2011-10-22 01:35 let me check 2011-10-22 01:48 lrwxrwxrwx    1 root     root             7 Jun 11 11:18 /bin/login -> busybox  ??? 2011-10-22 01:49 if you swap to 320x240 is actually common screen size for some smartphones 2011-10-22 01:51 ah, but may be a bit bigger display 2011-10-22 01:59 busybox looks like a good suggestion but "busybox login" in inittab just threw an error about missing the login applet 2011-10-22 01:59 I'll try playing with mgetty tomorrow 2011-10-22 01:59 need sleep 2011-10-22 02:00 Thanks for the suggestions 2011-10-22 05:57 The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-10212011-0109/ 2011-10-22 12:54 moo 2011-10-22 17:29 DocScrutinizer: R bits are not shorted to each one or HSYNC 2011-10-22 17:35 pretty strange then. Does your LCD+controller have an integrated CLUT for gamma correction or whatever? 2011-10-22 17:35 Then it might be an initialization error for that 2011-10-22 17:53 so the pixel timing is now good ? 2011-10-22 18:10 didn't you say the pixel timing / one-off issues were due to you overclocking the pixelclock? 2011-10-22 18:11 anyway the one-off error in your manga face picture was a completely different thing than what we've seen in that gradient bars testframe 2011-10-22 18:31 yeah 2011-10-22 18:32 timing is nice now. it has some artifacts, but they're quite minor and I'm unable to describe them sensibly 2011-10-22 18:33 DocScrutinizer: no CLUT or gamma correction 2011-10-22 18:33 there's no postprocessing in LCDC at all 2011-10-22 18:35 whitequark: so the pixel shift is gone now ? 2011-10-22 18:35 wpwrak: the one visible on that picture is indeed gone 2011-10-22 18:35 kewl :) 2011-10-22 18:36 the image is not _perfect_, but it is quite good. anyway, the artifacts which are present now do not appear on the photos :D 2011-10-22 18:36 (shift) did it remove itself on its own volition or did you have to persuade it ? 2011-10-22 18:36 wpwrak: the atmelfb code has rounded 65000000 (the max input frequency for LVDS serializer) to a larger value 2011-10-22 18:37 phenomena that can be observed but not reported are called "ghosts" ;-) 2011-10-22 18:37 aah, that was the overclocking then 2011-10-22 18:37 it's dynamic and quite minor. yes, I think it can be called a ghost 2011-10-22 18:37 yeah 2011-10-22 18:43 DocScrutinizer: I've drawn this pattern: http://rghost.ru/26573371.view 2011-10-22 18:43 2nd and 3rd red stripes from the right apparently have the same colour 2011-10-22 18:43 i.e. they appear to have the same colour. 2011-10-22 18:44 the stripes have their respective channel set to 08h, 18h, 38h, 78h, f8h 2011-10-22 18:47 not sure how should I interpret that, combined with the previous stripes image 2011-10-22 18:52 maybe make stripes 0x01, 0x02, 0x04, 0x08, etc. and then the reverse. that should tell you if an individual bit fails or gets abducted 2011-10-22 21:23 wpwrak: I'll try 2011-10-22 21:53 Good evening everyone! 2011-10-22 21:53 hmm, i wonder if DMA from GPIOs (in the ben) actually works. i'm experimenting with it, and i'm getting highly peculiar patterns 2011-10-22 21:54 What's going on? 2011-10-22 21:55 fairly quiet day, i'd say 2011-10-22 21:57 labsw is ticking away somewhere in its 40'000th cycle, with the relays still going strong, m1 NOR is behaving with the expected amount of badness again, whitequark is wresting with his circuit, and i'm doing one of my little mad science projects, so all is normal