| 00:19.48 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 00:19.48 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 00:19.48 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 01:02.02 | *** join/#qi-hardware wpwrak (~werner@52-32-17-190.fibertel.com.ar) |
| 02:13.34 | DocScrutinizer05 | opbolt: HEY! cool |
| 02:14.30 | DocScrutinizer05 | 0.8mm BHA pitch though, sounds a tad on the gigantic size |
| 02:28.24 | *** join/#qi-hardware dandon (~dandon@88.151.75.166) |
| 02:49.12 | *** join/#qi-hardware MistahDarcy[m] (mistahdarc@gateway/shell/matrix.org/x-rgoihksvuundwxvq) |
| 05:04.48 | *** join/#qi-hardware sb0 (~lekernel@59.152.213.90) |
| 06:33.38 | *** join/#qi-hardware usr_ (~usr@2a01:4a0:27::c0f8:6a0a) |
| 09:46.04 | *** join/#qi-hardware eintopf (~eintopf@unaffiliated/eintopf) |
| 10:38.23 | 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 |
| 10:39.09 | opbolt | arm-netbook one |
| 10:41.35 | opbolt | looks like the mailing list thread starts here and goes on for the next months :) http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-November/thread.html |
| 10:42.09 | opbolt | gives ya back story |
| 10:45.19 | opbolt | this team in india have gov funding of millions to make floss cpu for day to day devices and the alike |
| 10:46.18 | 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. |
| 10:47.23 | 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. |
| 10:48.00 | opbolt | anyway, i donât need to say all the pros, can know them |
| 10:48.11 | opbolt | *ya |
| 11:24.57 | opbolt | Fosdem video: https://www.youtube.com/watch?v=8zF_qelGUgU |
| 11:33.17 | opbolt | https://video.fosdem.org/2018/H.2215%20(Ferrer)/designing_riscv64_soc.webm |
| 11:40.31 | *** join/#qi-hardware eintopf (~eintopf@unaffiliated/eintopf) |
| 11:53.17 | *** join/#qi-hardware luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 12:07.30 | *** join/#qi-hardware eintopf (~eintopf@unaffiliated/eintopf) |
| 12:14.57 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 12:20.37 | DocScrutinizer05 | opbolt: (0.8mm) means the chip must be like 30x30mm |
| 12:53.38 | *** join/#qi-hardware sb0 (~lekernel@138.19.142.177) |
| 13:22.51 | *** join/#qi-hardware erichvk (~esh@ppp14-2-124-244.lns21.adl6.internode.on.net) |
| 13:28.40 | opbolt | ok |
| 13:29.11 | opbolt | yea bigger and the tiny one in the nano note... |
| 13:29.16 | opbolt | or gta |
| 15:12.25 | *** join/#qi-hardware paul_boddie (~paul_bodd@host-37-191-186-243.lynet.no) |
| 15:12.43 | paul_boddie | About the RISC-V board mentioned before: https://www.crowdsupply.com/sifive/hifive-unleashed |
| 15:54.50 | paul_boddie | A bit optimistic, but does anyone remember dealing with the LCD timings on the NanoNote? |
| 15:55.39 | 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. |
| 16:04.46 | mth | could it be 8 pixels? that would happen if address lines are stuck for some reason |
| 16:05.10 | mth | I mean, wrapping usually happens on powers of two |
| 16:07.23 | paul_boddie | Yes, it's odd. But it really does look like 9 pixels. |
| 16:07.56 | paul_boddie | It's like the line buffer in the LCD controller takes the data at the wrong time. |
| 16:08.59 | 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. |
| 16:10.03 | 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. |
| 16:14.29 | 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. |
| 16:20.39 | paul_boddie | Still, I could have messed up some configuration detail, I suppose. |
| 16:22.21 | mth | sync polarity maybe? although I don't think it would manifest quite like that |
| 16:23.43 | paul_boddie | The odd thing is that in debugging the kernel, I reused the framebuffer just fine, and even changing the address worked. |
| 16:24.29 | paul_boddie | But in a user space task, whether I reinitialise the LCD controller or not, I get this alignment issue. |
| 16:25.12 | 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. |
| 16:28.48 | mth | does the user space task use kms or fbdev? |
| 16:30.10 | paul_boddie | How do I find out? I'm not familiar with the terminology. |
| 16:30.57 | mth | running it under strace and see what device it opens and what ioctls it uses |
| 16:31.34 | paul_boddie | This is a task running on top of Fiasco.OC. |
| 16:32.01 | mth | ah, it's not Linux, then never mind |
| 16:32.23 | paul_boddie | No, I thought those were Linux things, but then considered that they might be generic. |
| 16:33.00 | 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 |
| 16:33.38 | *** join/#qi-hardware tavish (~tavish@unaffiliated/tavish) |
| 16:33.45 | paul_boddie | Well, the interface I'm currently using is a straight view onto the video memory accessed by the SoC. |
| 16:33.49 | 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 |
| 16:33.56 | paul_boddie | I guess you remember the whole DMA descriptor dance. |
| 16:34.38 | 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. :-/ |
| 16:34.41 | mth | I implemented wait-for-vsync for JZ4740; had to do some trickery to make that work |
| 16:37.32 | mth | I assume it use one DMA descriptor per frame? or is it per line? |
| 16:39.25 | paul_boddie | One per frame. Lines have to be word-aligned, but that isn't a factor here since I'm using 32bpp. |
| 16:41.03 | mth | eh, actually it was the JZ4770 that wait-for-vsync was implemented for, but the LCD controller didn't change much |
| 16:42.02 | paul_boddie | No, the documentation is still as helpful as it always was. :-/ |
| 16:42.59 | mth | does Fiasco have a proper interface for page flipping or does it use vertical panning like Linux fbdev does? |
| 16:43.39 | mth | because if you do panning, then the first display line does not always start at a page boundary |
| 16:43.50 | paul_boddie | The framebuffer driver? I don't think it has very much. |
| 16:59.13 | *** join/#qi-hardware erichvk (~esh@ppp14-2-124-244.lns21.adl6.internode.on.net) |
| 17:29.23 | paul_boddie | Well, I'll inquire on the L4 mailing list and see if there's anything I've done wrong. |
| 17:29.38 | paul_boddie | Thanks for brainstorming with me, though. :-) |
| 17:55.57 | DocScrutinizer05 | paul_boddie: wrong polarity (H/L) on some latch or clock? |
| 17:56.34 | DocScrutinizer05 | prolly HSYNC? |
| 17:58.21 | 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 |
| 17:58.51 | DocScrutinizer05 | makes sense? |
| 17:59.35 | 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. |
| 18:00.17 | paul_boddie | But two votes for sync polarity and maybe I have to check. ;-) |
| 18:00.42 | DocScrutinizer05 | scope HSYNC |
| 18:00.45 | paul_boddie | Although I'm re-using code that works in other environments. |
| 18:00.54 | DocScrutinizer05 | compare to LCD controller specs |
| 18:01.07 | paul_boddie | No scope! Yes, I should have one by now, really. |
| 18:01.21 | DocScrutinizer05 | DVM will do, average voltage |
| 18:01.47 | paul_boddie | Indeed, the magic numbers in the sources I have started to make sense when reading the datasheet. |
| 18:01.48 | DocScrutinizer05 | you either get 99% of H or of L |
| 18:02.33 | DocScrutinizer05 | worst case use a LED with 50k series R |
| 18:02.52 | paul_boddie | Now you're talking about debugging at my technological level! |
| 18:03.41 | DocScrutinizer05 | hehe, LED might not work, depending on level (1V8?) |
| 18:04.05 | DocScrutinizer05 | I debugged a whole Z80 sytsem this way |
| 18:04.18 | 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. |
| 18:04.38 | DocScrutinizer05 | umm yep |
| 18:04.39 | paul_boddie | That is if the sync polarity is wrong. |
| 18:05.48 | paul_boddie | Every now and again, I suspect that the NanoNote would almost have been more popular as a bare single-board computer. |
| 18:07.29 | paul_boddie | And yet everyone now seems to want to duct-tape their Raspberry Pi to a screen to make pretend laptops. |
| 18:07.42 | 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 |
| 18:09.15 | DocScrutinizer05 | NASCOM-I |
| 18:09.51 | DocScrutinizer05 | https://en.wikipedia.org/wiki/Nascom_(computer_kit) |
| 18:10.31 | 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. |
| 18:10.57 | paul_boddie | Although it's only recently that I've done any hardware stuff for it. |
| 18:13.02 | paul_boddie | Some people have done some neat bus analysis tricks with these machines. Such stuff is a lot easier now. |
| 18:33.12 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 18:33.12 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 20:22.29 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.76.149.255) |
| 21:21.13 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 21:21.14 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 21:50.45 | *** join/#qi-hardware Ornotermes (~ornoterme@78-73-30-246-no180.tbcn.telia.com) |
| 22:34.36 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 22:49.05 | paul_boddie | Well, I don't think it's the sync polarity. Reversing that just shifts the data by a cycle. |
| 22:49.36 | paul_boddie | On the Giantplus panel in the NanoNote, that changes the colours because of the colour filter layout. |
| 22:50.14 | 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. |
| 22:51.10 | paul_boddie | But the 10th pixel is still the first one, with the ones preceding it at the other side of the screen. |
| 23:16.37 | paul_boddie | I think you may have meant data enable, Doc, reading your description again. |
| 23:34.32 | paul_boddie | Hmm. Imminent facepalm moment here... |
| 23:38.42 | paul_boddie | Yes, facepalm applied. Don't take shortcuts converting while loops to for loops. Sorry for the unnecessary brainstorming exercise everyone! |
| 23:38.59 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 23:39.15 | paul_boddie | At least I learned a bit about the LCM, though. And I do still wonder about stray pixels. |
| 23:39.40 | 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. :-/ |
| 23:51.11 | paul_boddie | needs some rest now! |
| 23:58.08 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |