<DocScrutinizer>
whitequark: well, that's my job. Nah actually my vocation
<whitequark>
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
<whitequark>
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
<whitequark>
i.e. it's not a double error on both the motherboard and TFT board (same manufacturer)
<DocScrutinizer>
and it's not the video RAM, nor the bus from CPU to VRAM
<whitequark>
yeah
<DocScrutinizer>
so you say it's definitely your LCM board that messes it up?
<whitequark>
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)
<whitequark>
(mess up) either my TFT-to-LVDS board, or it's the LCD itself which is screwed up
<DocScrutinizer>
:nod:
<whitequark>
maybe they've missed two traces on the LCD and to cut manufacturing/fixing costs did the same on the notebook motherboard
<whitequark>
I don't know if this can really happen
<whitequark>
just maybe
<DocScrutinizer>
maybe you got a short from HSYNC to one of the data lines?
<whitequark>
hm
<DocScrutinizer>
(probably the RSB according to your prev observations and thoughts)
<DocScrutinizer>
s/RSB/R MSB/
<whitequark>
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)
<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)
<whitequark>
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
<DocScrutinizer>
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
<DocScrutinizer>
there's that very obvious break into 4 zones
<whitequark>
ah yes. I should then say that the quirk was first discovered on my site (http://whitequark.org)
<DocScrutinizer>
and both blue and red are behaving completely weird
<whitequark>
see that gray gradient behind the menu? Blog | Archives | Github
<whitequark>
the downmost part of it was almost red
<whitequark>
(blue) that's the crappy camera again. the blue stripe looks good on actual device
<DocScrutinizer>
but blue in that pink stripe freaks out
<DocScrutinizer>
just find that line that has a square wave of exactly 4 times the horizontal frequency
<DocScrutinizer>
or rather: "that has a completely messed up signal faintly resembling a square wave of..."
<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)
<whitequark>
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
<whitequark>
*to mess up my red channel on exactly the test stripe part borders
<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 frame
<whitequark>
well I'll check it of course (when I'll get to the device). but it is still quite mysterious for me
<DocScrutinizer>
I guess your LCM controller is defect then
<whitequark>
do you mean the one in CPU, the serializer or the chip on the LCD itself?
<whitequark>
i.e. what should I try to replace
<whitequark>
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
<DocScrutinizer>
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
<whitequark>
hm
<whitequark>
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
<whitequark>
that's still possible through
<DocScrutinizer>
of course this doesn't explain instantly how the one-pixel-off effect of your manga picture happened
<DocScrutinizer>
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
<whitequark>
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
<DocScrutinizer>
ahaaa
<whitequark>
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
<whitequark>
it still may be (the visible area)*2/*4
<whitequark>
e.g. it locks on a previous stripe somehow
<whitequark>
or maybe on the first line of red stripe
<DocScrutinizer>
make sure it's not just R4 short to R5 or sth
<Freemor>
anyone about?
<wpwrak>
each square is 50 x 50 pixels, the diagonals are 45 deg and meet exactly at the border, etc.
<wpwrak>
that way, you can see a lot of weird timing problems fairly quickly
<wpwrak>
it's not designed for detecting color problems, though. well, except for the most trivial ones, like an entire channel missing :)
<whitequark>
sure, thanks. I think it can be adapted a bit to do that
<DocScrutinizer>
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?)
<whitequark>
DocScrutinizer: 32
<whitequark>
and the LSB of R is grounded on the motherboard for some reason
<whitequark>
so this pattern is switching all the red bits present
<DocScrutinizer>
yep and M(-1)SB is switching 4 times
<DocScrutinizer>
short of M(-1)Sb to MSB would pretty much explain the efect
<whitequark>
well I've checked the board for shorts, but you can never know where you got one ...
<whitequark>
I'll check again tomorrow
<whitequark>
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
<Freemor>
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?
<kristianpaul>
Freemor: may be you need pam?
<wpwrak>
maybe the startup scripts just unconditionally fire up a shell ?
<Freemor>
Hmm.. or the login command which seems to be missing.. was hoping to keep the install as "stock" as possible
<kristianpaul>
ah yes there is a nanonote startup script too
<Freemor>
Hmmm... maybe bash instead of ash?
<Freemor>
let me check
<DocScrutinizer>
lrwxrwxrwx    1 root    root            7 Jun 11 11:18 /bin/login -> busybox  ???
<kristianpaul>
if you swap to 320x240 is actually common screen size for some smartphones
<kristianpaul>
ah, but may be a bit bigger display
<Freemor>
busybox looks like a good suggestion but "busybox login" in inittab just threw an error about missing the login applet
<whitequark>
DocScrutinizer: R bits are not shorted to each one or HSYNC
<DocScrutinizer>
pretty strange then. Does your LCD+controller have an integrated CLUT for gamma correction or whatever?
<DocScrutinizer>
Then it might be an initialization error for that
<wpwrak>
so the pixel timing is now good ?
<DocScrutinizer>
didn't you say the pixel timing / one-off issues were due to you overclocking the pixelclock?
<DocScrutinizer>
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
<whitequark>
yeah
<whitequark>
timing is nice now. it has some artifacts, but they're quite minor and I'm unable to describe them sensibly
<whitequark>
DocScrutinizer: no CLUT or gamma correction
<whitequark>
there's no postprocessing in LCDC at all
<wpwrak>
whitequark: so the pixel shift is gone now ?
<whitequark>
wpwrak: the one visible on that picture is indeed gone
<wpwrak>
kewl :)
<whitequark>
the image is not _perfect_, but it is quite good. anyway, the artifacts which are present now do not appear on the photos :D
<wpwrak>
(shift) did it remove itself on its own volition or did you have to persuade it ?
<whitequark>
wpwrak: the atmelfb code has rounded 65000000 (the max input frequency for LVDS serializer) to a larger value
<wpwrak>
phenomena that can be observed but not reported are called "ghosts" ;-)
<wpwrak>
aah, that was the overclocking then
<whitequark>
it's dynamic and quite minor. yes, I think it can be called a ghost
<whitequark>
2nd and 3rd red stripes from the right apparently have the same colour
<whitequark>
i.e. they appear to have the same colour.
<whitequark>
the stripes have their respective channel set to 08h, 18h, 38h, 78h, f8h
<whitequark>
not sure how should I interpret that, combined with the previous stripes image
<wpwrak>
maybe make stripes 0x01, 0x02, 0x04, 0x08, etc. and then the reverse. that should tell you if an individual bit fails or gets abducted
<whitequark>
wpwrak: I'll try
<LunaVorax>
Good evening everyone!
<wpwrak>
hmm, i wonder if DMA from GPIOs (in the ben) actually works. i'm experimenting with it, and i'm getting highly peculiar patterns
<LunaVorax>
What's going on?
<wpwrak>
fairly quiet day, i'd say
<wpwrak>
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