infobot has quit [Read error: Connection reset by peer]
infobot has joined #qi-hardware
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined #qi-hardware
<DocScrutinizer05>
opbolt: HEY! cool
<DocScrutinizer05>
0.8mm BHA pitch though, sounds a tad on the gigantic size
dandon has quit [Ping timeout: 255 seconds]
dandon has joined #qi-hardware
MistahDarcy[m] has joined #qi-hardware
sb0 has quit [Quit: Leaving]
sb0 has joined #qi-hardware
usr_ has joined #qi-hardware
usr has quit [*.net *.split]
sb0 has quit [Ping timeout: 264 seconds]
eintopf has quit [Ping timeout: 252 seconds]
eintopf has joined #qi-hardware
<opbolt>
DocScrutinizer05, if ya mean lots of smaller pins. then i remmber him explaining why. it was something to do with cost i belive. pcbs costs lots more and the chip it self was a lot more exspensive cus its hard to stamp them and error rates or something like that, its all in the mailing list
<opbolt>
this team in india have gov funding of millions to make floss cpu for day to day devices and the alike
<opbolt>
lukes been chatting with them and helping them, it could be put in to eoma68 card to help ease transition to new risc arch.
<opbolt>
reuse that laptop for example into risc one by swaping that cpu card ;) which would other wise be years to make yet another laptop just for this soc.
<opbolt>
anyway, i don’t need to say all the pros, can know them
<paul_boddie>
A bit optimistic, but does anyone remember dealing with the LCD timings on the NanoNote?
<paul_boddie>
I get an effect where it is like the display lines are wrapped by 9 pixels, and it's driving me a bit crazy.
<mth>
could it be 8 pixels? that would happen if address lines are stuck for some reason
<mth>
I mean, wrapping usually happens on powers of two
<paul_boddie>
Yes, it's odd. But it really does look like 9 pixels.
<paul_boddie>
It's like the line buffer in the LCD controller takes the data at the wrong time.
<paul_boddie>
But it wraps around: it isn't short on data because I can see the first words/pixels appear at the end of the first display line.
<paul_boddie>
I suppose it could be something weird with the L4/Fiasco stuff but I'm writing to an address with the correct alignment.
<paul_boddie>
And I doubt that you could write to a page-aligned address through to a page-aligned physical address at an offset with some kind of 1280 byte wraparound.
<paul_boddie>
Still, I could have messed up some configuration detail, I suppose.
<mth>
sync polarity maybe? although I don't think it would manifest quite like that
<paul_boddie>
The odd thing is that in debugging the kernel, I reused the framebuffer just fine, and even changing the address worked.
<paul_boddie>
But in a user space task, whether I reinitialise the LCD controller or not, I get this alignment issue.
<paul_boddie>
But I can't see how any kind of memory mapping would cause it unless there is some exotic/stupid stuff going on.
<mth>
does the user space task use kms or fbdev?
<paul_boddie>
How do I find out? I'm not familiar with the terminology.
<mth>
running it under strace and see what device it opens and what ioctls it uses
<paul_boddie>
This is a task running on top of Fiasco.OC.
<mth>
ah, it's not Linux, then never mind
<paul_boddie>
No, I thought those were Linux things, but then considered that they might be generic.
<mth>
Fiasco probably has some kind of mode setting and frame buffer interface too, but I don't know anything about it other than the name
tavish has joined #qi-hardware
<paul_boddie>
Well, the interface I'm currently using is a straight view onto the video memory accessed by the SoC.
<mth>
since Linux has both fbdev (legacy) and kms (modern), a bug in one driver and not the other could have explained why some use cases work and some do not
<paul_boddie>
I guess you remember the whole DMA descriptor dance.
<paul_boddie>
Actually, I was in the process of trying to get the L4Re framebuffer driver to work when I actually noticed this current problem. :-/
<mth>
I implemented wait-for-vsync for JZ4740; had to do some trickery to make that work
<mth>
I assume it use one DMA descriptor per frame? or is it per line?
sb0 has quit [Quit: Leaving]
<paul_boddie>
One per frame. Lines have to be word-aligned, but that isn't a factor here since I'm using 32bpp.
<mth>
eh, actually it was the JZ4770 that wait-for-vsync was implemented for, but the LCD controller didn't change much
<paul_boddie>
No, the documentation is still as helpful as it always was. :-/
<mth>
does Fiasco have a proper interface for page flipping or does it use vertical panning like Linux fbdev does?
<mth>
because if you do panning, then the first display line does not always start at a page boundary
<paul_boddie>
The framebuffer driver? I don't think it has very much.
erichvk has quit [Remote host closed the connection]
erichvk has joined #qi-hardware
<paul_boddie>
Well, I'll inquire on the L4 mailing list and see if there's anything I've done wrong.
<paul_boddie>
Thanks for brainstorming with me, though. :-)
<DocScrutinizer05>
paul_boddie: wrong polarity (H/L) on some latch or clock?
<DocScrutinizer05>
prolly HSYNC?
<DocScrutinizer05>
e.h. HSYNC meant to go high with first pixel of a line, but in fact it goes low, and went high on last pixel of previous line already
<DocScrutinizer05>
makes sense?
<paul_boddie>
I did wonder about that. I thought that HSYNC might have been occurring at the wrong time, but I failed to change it sensibly.
<paul_boddie>
But two votes for sync polarity and maybe I have to check. ;-)
<DocScrutinizer05>
scope HSYNC
<paul_boddie>
Although I'm re-using code that works in other environments.
<DocScrutinizer05>
compare to LCD controller specs
<paul_boddie>
No scope! Yes, I should have one by now, really.
<DocScrutinizer05>
DVM will do, average voltage
<paul_boddie>
Indeed, the magic numbers in the sources I have started to make sense when reading the datasheet.
<DocScrutinizer05>
you either get 99% of H or of L
<DocScrutinizer05>
worst case use a LED with 50k series R
<paul_boddie>
Now you're talking about debugging at my technological level!
<DocScrutinizer05>
hehe, LED might not work, depending on level (1V8?)
<DocScrutinizer05>
I debugged a whole Z80 sytsem this way
<paul_boddie>
I'd have to open the thing up to do this, though, but really the issue is the LCM somehow getting incorrectly configured.
<DocScrutinizer05>
umm yep
<paul_boddie>
That is if the sync polarity is wrong.
<paul_boddie>
Every now and again, I suspect that the NanoNote would almost have been more popular as a bare single-board computer.
<paul_boddie>
And yet everyone now seems to want to duct-tape their Raspberry Pi to a screen to make pretend laptops.
<DocScrutinizer05>
that Z80 system ran the ROM monitor code but failed weirdly on code I write to RAM. By applying the LED probe to address and data lines, I found two lines that always had same level and tracked that down to a tiny solder blob between two chip pins
<paul_boddie>
A few years before my time. I had an Acorn Electron, although it might have been an Acorn Atom had I been slightly older.
<paul_boddie>
Although it's only recently that I've done any hardware stuff for it.
<paul_boddie>
Some people have done some neat bus analysis tricks with these machines. Such stuff is a lot easier now.
_whitelogger has joined #qi-hardware
erichvk has quit [Ping timeout: 256 seconds]
tavish has quit [Quit: Leaving]
jwhitmore has joined #qi-hardware
_whitelogger has joined #qi-hardware
jwhitmore has quit [Ping timeout: 264 seconds]
Ornotermes has quit [Ping timeout: 260 seconds]
Ornotermes has joined #qi-hardware
fdcx has joined #qi-hardware
<paul_boddie>
Well, I don't think it's the sync polarity. Reversing that just shifts the data by a cycle.
<paul_boddie>
On the Giantplus panel in the NanoNote, that changes the colours because of the colour filter layout.
<paul_boddie>
And interestingly, there's a grey pixel at the start, which seems to be what you get when the porches stray onto the picture.
<paul_boddie>
But the 10th pixel is still the first one, with the ones preceding it at the other side of the screen.
<paul_boddie>
I think you may have meant data enable, Doc, reading your description again.
<paul_boddie>
Hmm. Imminent facepalm moment here...
fdcx has quit [Ping timeout: 264 seconds]
<paul_boddie>
Yes, facepalm applied. Don't take shortcuts converting while loops to for loops. Sorry for the unnecessary brainstorming exercise everyone!
fdcx has joined #qi-hardware
<paul_boddie>
At least I learned a bit about the LCM, though. And I do still wonder about stray pixels.
<paul_boddie>
Now I can perhaps get on with trying to get the actual framebuffer driver working, which was what I had intended to be doing. :-/