IRC logs for #openrisc Friday, 2015-05-15

--- Log opened Fri May 15 00:00:50 2015
olofkFuck it00:19
olofkIf I don't start Linux, I can set up the registers from OpenOCD and write to the memory where it fetches the frame buffer06:15
olofkSo the timing values should work06:15
olofkEither the Linux driver touches some registers that it shouldn't touch, or I got a bandwidth problem06:16
olofkThere's a whole lot of data that needs to be moved06:22
olofkHmm... it's flickering a lot when I switch to 16-bit mode06:26
olofkSo I guess it's a bandwidth problem06:27
olofkHmm.. how do I turn on grayscale? Seems like palette mode doesn't work06:40
olofkin the device tree I mean06:42
olofkha! Now I can cat /dev/urandom to /dev/fb008:00
olofkBut I had to force grayscale mode in the driver08:03
olofkMaybe I should fix my HW as well. It's currently outputting top 4 bits of each channel instead of passing them through a DDR FF. I assumed that would be ok for now08:04
olofkHmmm.. people seem to refer to some "console display driver support" in menuconfig. I don't have that one08:06
olofkHmm.. on my PC it's there08:07
olofkAha! I had to enable CONFIG_VT08:11
olofkoh for fuck sake. Now I can build the kernel08:11
olofk undefined reference to `screen_info' in vgacon_init08:12
olofkProblem solved. Be very afraid Linux. I'm smarter than you are08:19
olofkWell. That's about it. Shouldn't my terminal appear here as well?08:19
olofkLooks like the system is a bit too slow for 16-bit graphics. If I halt the CPU, I get a nice picture, but if it's running, it's just noise08:31
olofkWhy doesn't I get any text output in 8-bit mode?09:39
olofkand why doesn't palette mode work at all?09:44
olofkok, so fb_find_mode is responsible for parsing the string from the dts10:18
olofkCan't find an option to force grayscale there10:18
olofkHey... why does Linux stop outputting stuff on the screen after I have booted? Is it because bootconsole is disabled?10:56
olofkHa! 16-bit mode works too. Although it looks like crap10:58
olofkIn 640x480 that is11:01
olofkAlright. Palette mode seems to work now as well. The penguin still look like crap, but that could be due to my DDR FFs11:07
olofkHmm... is it busybox who is responsible for the console now?11:10
olofkAwesome. Inverting the DDR FFs give me a very pretty penguin11:13
olofk...for some definition of pretty11:28
olofkAha! I can echo stuff to /dev/tty0 to make them appear on the screen11:38
olofkSo I probably need to make busybox use that by default11:39
olofkAs a wise man once said, Fuck it!11:50
blueCmdolofk: do you know who just emailed me?12:28
blueCmdI sent a "Final attempt" to like everyone at the company our final contributor works at, apparently caught his attention12:29
blueCmdfingers crossed12:29
olofkblueCmd: That's fantastic news!12:31
olofkGreat job12:31
stekernolofk: you can set the console to tty0 instead of the serial in the kernel args, but then you don't get the console on the serial.15:13
olofkstekern: I got this in my dts bootargs = "console=tty0 console=uart,mmio,0x90000000,115200 video=ocfb:640x480-16@60";15:15
olofkWith that I get output on both serial and LCD during boot, but only serial after busybox has started15:16
stekernthe last console in the args is the one that get picked as the console15:16
olofkOh... interesting15:16
olofkI would have assumed the first if anything15:16
olofkGood thing you're here btw. I'm thinking of soldering a pin header to an SD card and use it as an SPI Flash15:17
stekernthat's my speciality ;)15:17
olofkI had hoped that I could just use the SPI Flash protocol to talk to it, but it doesn't seem to be the case. What are you using to read from it?15:17
olofkGot any written code?15:21
olofkDo you got a filesytem on your card btw, or do you use something like dd to put data on it?15:24
olofkok, so I send CMD0 and CMD1 to start things up. Then I just need CMD17 to read out blocks15:29
stekernolofk: since I used the minimig stuff, it's all fat3215:30
stekernI've used the fat fs from the page I linked to in an other project though15:31
stekernand here's the project I used it in:
olofkI think you're the only youtube star that I know :)15:33
stekernyoutube star?15:34
olofkYeah. I assume that you have become filthy rich from the thousands of people who watch your movies15:35
stekernah, yes, of course15:36
olofkhmm... my main problem is that I don't have any non-volatile memory, so in order to use an SDCard, I would have to implement a pretty big bootloader15:38
olofkAt least if I want FAT15:38
olofkI think that's more of a job for a second-stage bootloader15:38
olofkI asked them to put on an SPI Flash, but they didn't listen :(15:41
stekernbut you could of course steal the 4k minimig bootrom15:41
olofkoh, do they implement the SD loading in a boot ROM?15:42
olofkFucking awesome!15:44
stekernyou'll have to adapt it to the spi core we use of course15:47
olofkLooks like hardware.h contains the macros15:57
olofkI think I'll save that for another time, but it would be a great addition to the or1k_bootloaders repo15:59
olofkSo it just needs a file (DE1_BOOTBIN?) on a FAT-formatted SD Card, right?16:02
stekernde1_boot.bin, yes16:02
stekernif you want to try it without porting it to our spi controller, it might be simpler to just hook up their spi controller:
olofkWe should get the minimig guy(s?) to next orconf16:44
olofkstekern: I switched around the console arguments in bootargs now, but where do tty0 expect to find its input?17:54
olofkhmm... in 16-bit mode, every time I type run 'ls' on the serial terminal, the image on the monitor is shifted 160 pixels to the right... is that normal?18:03
olofkSo now the start of my frame buffer is somewhere in the middle of line 10 or something18:06
olofkIt's not data loss, because all pixels are there. It must be that the monitor resyncs for some reason.18:08
olofkMarek Czerski's spiced up SD Card controller passes regression tests under FuseSoC now18:26
bandvigstekern: I've got next question about cappuccino. I see that for pipelined MUL and for instruction executed on CTRL stage (loads & mf(t)spr) the padv_execute has got priority over flush_pipeline.18:38
bandvigstekern: The near pipelined MUL commentary stay that the reason: "The pipeline flush comes when the instruction that has caused an exception or the instruction that has been interrupted is in ctrl stage,18:39
bandvigstekern: so the padv_execute signal has to have higher prioity than the pipeline flush in order to not accidently kill a valid instruction coming in from execute stage."18:39
stekernolofk: tty0 is the keyboard18:39
bandvigstekern: I don't understand the reason clearly. If an CTRL-stage instruction generates exception or it is interrupted than the PC of the instruction is stored in EPCR. And exactly the instruction is re-run by l.rfe. So, I don't see a reason to continue proceess instruction on EXECUTE stage. Could you clarify?18:39
stekernhmm, could you point me to the places in the source (e.g. by linking to the lines in github). But I think the answer to what you are asking is that those instructions are advanced to far in the pipeline to be killed18:42
stekerneverything beyond and including ctrl/mem stages belong to such18:42
stekern(consider a started write, you can't abort that)18:42
bandvigI referenced the commentary in lines 247-251 of mor1kx_execute_ctrl_cappuccino18:46
bandvigAnd I see the same priorities in line 301 (mf(t)spr), 320 (msync), 335 (load/store/atomic).18:49
stekernyes, that comment is not related to the mul (alone)18:51
stekernthis is the commit where that comment originated from:
olofkstekern: So how do I bind the serial port stdin to tty0?18:53
stekernolofk: I don't know if you can18:53
stekernwhy do you want to do that though?18:53
stekernif you have a serial console, you get the console on the serial, no?18:54
olofkYeah, I still need to connect the serial port, but I thought it would be flashy to have the output shown on the monitor instead18:54
olofkMaybe some time in the future I'll connect the USB ports meant for mouse and keyboard to the FPGA instead. That would be the proper solution18:55
olofkUnfortunately the connection there is a bit weird.18:55
olofkGot 8 systems and 45 cores in orpsoc-cores now btw18:59
stekernbandvig: I agree that the comment there is a bit confusing (and probably not describing the situation correctly).19:01
olofkstekern: Maybe it's time to replace the minimig SPI controller with a flashy SD controller core instead?19:06
stekernolofk: yes, I want to do that, it ought to be a lot faster than SPI'ing19:07
stekernHD emulation would benefit from that a lot19:08
olofkThere just happens to be an SD Card controller in orpsoc-cores now :)19:09
olofkWith a bare-metal driver19:09
stekernwhat a coincidence ;)19:09
olofkAnd a sdCard simulation model19:09
olofkYeah. It's almost hard to believe that it's a coincidence :)19:10
bandvigstekern: I see (lines 155-160 of mor1kx_execute_ctrl_cappuccino) that for load/store/mf(t)spr the pipeline is stalled till lsu_valid/mfspr_ack.19:17
bandvigstekern: As far as I understand, we can get not only "valid" answers but additionally exception/inerrupt signals.19:17
bandvigstekern: So I don't see any reason to continue pushing insn from EXECUTE (but not from DECODE, btw) stage.19:17
stekernI agree, but I remember that there was some particular situation that needed the reversed logic for those19:24
stekernand it sucks that I didn't manage to document that situation better than I did19:24
bandvigstekern: Ok. One more note. Just to keep in mind. The result of interrupted/exception insn must not go to WB and than to RF. However, it looks like there isn't logic for that.19:44
stekernthe we signal of wb is gated by pipeline_flush, no?19:45
bandvigyou mean in mor1kx_rf_cappuccino?19:46
stekernno, in mor1kx_execute_ctrl_cappuccino.v19:47
bandvigisn't it 1 clock later than WB latches result and ctrl_rf_wb_o?19:51
bandvigI mean it is the same clock, but WB latches asserted ctrl_wb_o.19:53
stekernyes, but that's the instruction that's currently in ctrl stage19:54
stekernbut I'm getting more and more convinced that the reversed logic with padv and pipeline_flush is wrong19:54
stekernI bet it was a workaround for some bug, which might not exist anymore19:54
stekernwe should test to re-reverse that logic and confirm that it works properly19:55
stekernand if it *doesn't* work properly, more properly document why it doesn't work ;)19:57
bandvigyou are right about deassert wb_rf_wb by pipeline_flush. So, the result of interrupted/exception insn isn't go to RF. I missed it.19:58
--- Log closed Sat May 16 00:00:51 2015

Generated by 2.15.2 by Marius Gedminas - find it at!