#qi-hardware IRC log for Saturday, 2011-10-22

whitequarkDocScrutinizer: thanks a lot for your commentary, I'll try everything out. That is really promising.00:22
whitequarkI'd never figure out most of the things you said.00:23
whitequark(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)00:24
DocScrutinizerwhitequark: well, that's my job. Nah actually my vocation00:24
whitequarkas 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 swapped00:26
whitequarkI'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 one00:27
whitequarki.e. it's not a double error on both the motherboard and TFT board (same manufacturer)00:28
DocScrutinizerand it's not the video RAM, nor the bus from CPU to VRAM00:29
DocScrutinizerso you say it's definitely your LCM board that messes it up?00:29
whitequarkit 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)00:30
whitequark(mess up) either my TFT-to-LVDS board, or it's the LCD itself which is screwed up00:30
whitequarkmaybe they've missed two traces on the LCD and to cut manufacturing/fixing costs did the same on the notebook motherboard00:31
whitequarkI don't know if this can really happen00:31
whitequarkjust maybe00:31
DocScrutinizermaybe you got a short from HSYNC to one of the data lines?00:31
DocScrutinizer(probably the RSB according to your prev observations and thoughts)00:32
DocScrutinizers/RSB/R MSB/00:32
whitequarkmay 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)00:34
whitequark(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)00:34
whitequarkregarding the actual short: any R traces and HS are placed (quite) far on the board. I'll still check, but IMO that's unlikely00:37
DocScrutinizerhmm, 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 pos00:37
DocScrutinizerthere's that very obvious break into 4 zones00:38
whitequarkah yes. I should then say that the quirk was first discovered on my site (http://whitequark.org)00:38
DocScrutinizerand both blue and red are behaving completely weird00:38
whitequarksee that gray gradient behind the menu? Blog | Archives | Github00:38
whitequarkthe downmost part of it was almost red00:38
whitequark(blue) that's the crappy camera again. the blue stripe looks good on actual device00:39
DocScrutinizerbut blue in that pink stripe freaks out00:40
whitequarkhere it is: http://rghost.ru/26550941.view00:40
DocScrutinizerwell maybe not00:40
DocScrutinizeryou got a scope?00:41
whitequarka 25MHz one00:41
DocScrutinizerjust find that line that has a square wave of exactly 4 times the horizontal frequency00:42
DocScrutinizeror rather: "that has a completely messed up signal faintly resembling a square wave of..."00:42
whitequark(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)00:42
qi-bot[commit] Werner Almesberger: labsw/ch12.sch: added BJT and diode current (master) http://qi-hw.com/p/wernermisc/db53a1800:45
qi-bot[commit] Werner Almesberger: labsw/BOM: almost complete BOM (master) http://qi-hw.com/p/wernermisc/adb8d4000:45
whitequarkdo 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 interference00:45
whitequark*to mess up my red channel on exactly the test stripe part borders00:45
whitequark(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 frame00:49
whitequarkwell I'll check it of course (when I'll get to the device). but it is still quite mysterious for me00:50
DocScrutinizerI guess your LCM controller is defect then00:51
whitequarkdo you mean the one in CPU, the serializer or the chip on the LCD itself?00:53
whitequarki.e. what should I try to replace00:53
whitequarkerr, 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 scratch00:56
DocScrutinizerI 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 zones00:57
whitequarkI'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 same00:59
whitequarkthat's still possible through00:59
DocScrutinizerof course this doesn't explain instantly how the one-pixel-off effect of your manga picture happened01:01
DocScrutinizerthough... 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-off01:03
whitequarkthe 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 disappears01:03
whitequarkalso 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*401:09
whitequarkit still may be (the visible area)*2/*401:09
whitequarke.g. it locks on a previous stripe somehow01:09
whitequarkor maybe on the first line of red stripe01:10
wpwrakmaybe make a test image that looks like this ? http://downloads.qi-hardware.com/people/werner/ubb/vga/web/ubb-vga-pub-1024-medium.jpg01:14
DocScrutinizermake sure it's not just R4 short to R5 or sth01:15
Freemoranyone about?01:15
wpwrakeach square is 50 x 50 pixels, the diagonals are 45 deg and meet exactly at the border, etc.01:15
wpwrakthat way, you can see a lot of weird timing problems fairly quickly01:15
wpwrakit's not designed for detecting color problems, though. well, except for the most trivial ones, like an entire channel missing :)01:16
whitequarksure, thanks. I think it can be adapted a bit to do that01:17
DocScrutinizerhow 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?)01:17
whitequarkDocScrutinizer: 3201:17
whitequarkand the LSB of R is grounded on the motherboard for some reason01:17
whitequarkso this pattern is switching all the red bits present01:18
DocScrutinizeryep and M(-1)SB is switching 4 times01:18
DocScrutinizershort of M(-1)Sb to MSB would pretty much explain the efect01:19
whitequarkwell I've checked the board for shorts, but you can never know where you got one ...01:19
whitequarkI'll check again tomorrow01:20
whitequarkok it's 5AM here. that's bedtime I think :D thanks again for all the suggestions, this channel is always a great source for inspiration01:22
Freemorquick 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? 01:24
kristianpaulFreemor: may be you need pam?01:29
wpwrakmaybe the startup scripts just unconditionally fire up a shell ?01:33
FreemorHmm.. or the login command which seems to be missing.. was hoping to keep the install as "stock" as possible01:33
kristianpaulah yes there is a nanonote startup script too01:34
FreemorHmmm... maybe bash instead of ash?01:35
Freemorlet me check01:35
DocScrutinizerlrwxrwxrwx    1 root     root             7 Jun 11 11:18 /bin/login -> busybox  ???01:48
kristianpaulif you swap to 320x240 is actually common screen size for some smartphones01:49
kristianpaulah, but may be a bit bigger display01:51
Freemorbusybox looks like a good suggestion but "busybox login" in inittab just threw an error about missing the login applet01:59
FreemorI'll try playing with mgetty tomorrow01:59
Freemorneed sleep01:59
FreemorThanks for the suggestions02:00
qi-botThe build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-10212011-0109/05:57
whitequarkDocScrutinizer: R bits are not shorted to each one or HSYNC17:29
DocScrutinizerpretty strange then. Does your LCD+controller have an integrated CLUT for gamma correction or whatever?17:35
DocScrutinizerThen it might be an initialization error for that 17:35
wpwrakso the pixel timing is now good ?17:53
DocScrutinizerdidn't you say the pixel timing / one-off issues were due to you overclocking the pixelclock?18:10
DocScrutinizeranyway the one-off error in your manga face picture was a completely different thing than what we've seen in that gradient bars testframe18:11
whitequarktiming is nice now. it has some artifacts, but they're quite minor and I'm unable to describe them sensibly18:32
whitequarkDocScrutinizer: no CLUT or gamma correction18:33
whitequarkthere's no postprocessing in LCDC at all18:33
wpwrakwhitequark: so the pixel shift is gone now ?18:35
whitequarkwpwrak: the one visible on that picture is indeed gone18:35
wpwrakkewl :)18:35
whitequarkthe image is not _perfect_, but it is quite good. anyway, the artifacts which are present now do not appear on the photos :D18:36
wpwrak(shift) did it remove itself on its own volition or did you have to persuade it ?18:36
whitequarkwpwrak: the atmelfb code has rounded 65000000 (the max input frequency for LVDS serializer) to a larger value18:36
wpwrakphenomena that can be observed but not reported are called "ghosts" ;-)18:37
wpwrakaah, that was the overclocking then18:37
whitequarkit's dynamic and quite minor. yes, I think it can be called a ghost18:37
whitequarkDocScrutinizer: I've drawn this pattern: http://rghost.ru/26573371.view18:43
whitequark2nd and 3rd red stripes from the right apparently have the same colour18:43
whitequarki.e. they appear to have the same colour.18:43
whitequarkthe stripes have their respective channel set to 08h, 18h, 38h, 78h, f8h18:44
whitequarknot sure how should I interpret that, combined with the previous stripes image18:47
wpwrakmaybe make stripes 0x01, 0x02, 0x04, 0x08, etc. and then the reverse. that should tell you if an individual bit fails or gets abducted18:52
whitequarkwpwrak: I'll try21:23
LunaVoraxGood evening everyone!21:53
wpwrakhmm, i wonder if DMA from GPIOs (in the ben) actually works. i'm experimenting with it, and i'm getting highly peculiar patterns21:53
LunaVoraxWhat's going on?21:54
wpwrakfairly quiet day, i'd say21:55
wpwraklabsw 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 normal21:57
--- Sun Oct 23 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!