| --- Log opened Fri May 15 00:00:50 2015 | ||
| olofk | Fuck it | 00:19 |
|---|---|---|
| olofk | If I don't start Linux, I can set up the registers from OpenOCD and write to the memory where it fetches the frame buffer | 06:15 |
| olofk | So the timing values should work | 06:15 |
| olofk | Either the Linux driver touches some registers that it shouldn't touch, or I got a bandwidth problem | 06:16 |
| olofk | There's a whole lot of data that needs to be moved | 06:22 |
| olofk | Hmm... it's flickering a lot when I switch to 16-bit mode | 06:26 |
| olofk | So I guess it's a bandwidth problem | 06:27 |
| olofk | Hmm.. how do I turn on grayscale? Seems like palette mode doesn't work | 06:40 |
| olofk | in the device tree I mean | 06:42 |
| olofk | ha! Now I can cat /dev/urandom to /dev/fb0 | 08:00 |
| olofk | But I had to force grayscale mode in the driver | 08:03 |
| olofk | Maybe 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 now | 08:04 |
| olofk | Hmmm.. people seem to refer to some "console display driver support" in menuconfig. I don't have that one | 08:06 |
| olofk | Hmm.. on my PC it's there | 08:07 |
| olofk | Aha! I had to enable CONFIG_VT | 08:11 |
| olofk | oh for fuck sake. Now I can build the kernel | 08:11 |
| olofk | undefined reference to `screen_info' in vgacon_init | 08:12 |
| olofk | ahh... http://opencores.org/forum,OpenRISC,0,5444 | 08:14 |
| olofk | Problem solved. Be very afraid Linux. I'm smarter than you are | 08:19 |
| olofk | PENGUIN!!!!!!!! | 08:19 |
| olofk | Well. That's about it. Shouldn't my terminal appear here as well? | 08:19 |
| olofk | Looks 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 noise | 08:31 |
| olofk | hmm | 08:43 |
| olofk | Why doesn't I get any text output in 8-bit mode? | 09:39 |
| olofk | and why doesn't palette mode work at all? | 09:44 |
| olofk | ok, so fb_find_mode is responsible for parsing the string from the dts | 10:18 |
| olofk | Can't find an option to force grayscale there | 10:18 |
| olofk | Halle-fucking-lujah! | 10:56 |
| olofk | Hey... why does Linux stop outputting stuff on the screen after I have booted? Is it because bootconsole is disabled? | 10:56 |
| olofk | Ha! 16-bit mode works too. Although it looks like crap | 10:58 |
| olofk | In 640x480 that is | 11:01 |
| olofk | Alright. Palette mode seems to work now as well. The penguin still look like crap, but that could be due to my DDR FFs | 11:07 |
| olofk | Hmm... is it busybox who is responsible for the console now? | 11:10 |
| olofk | Awesome. Inverting the DDR FFs give me a very pretty penguin | 11:13 |
| olofk | ...for some definition of pretty | 11:28 |
| olofk | Aha! I can echo stuff to /dev/tty0 to make them appear on the screen | 11:38 |
| olofk | So I probably need to make busybox use that by default | 11:39 |
| olofk | As a wise man once said, Fuck it! | 11:50 |
| blueCmd | olofk: do you know who just emailed me? | 12:28 |
| blueCmd | I sent a "Final attempt" to like everyone at the company our final contributor works at, apparently caught his attention | 12:29 |
| blueCmd | fingers crossed | 12:29 |
| olofk | blueCmd: That's fantastic news! | 12:31 |
| olofk | Great job | 12:31 |
| stekern | olofk: 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 |
| olofk | stekern: I got this in my dts bootargs = "console=tty0 console=uart,mmio,0x90000000,115200 video=ocfb:640x480-16@60"; | 15:15 |
| olofk | With that I get output on both serial and LCD during boot, but only serial after busybox has started | 15:16 |
| stekern | the last console in the args is the one that get picked as the console | 15:16 |
| olofk | Oh... interesting | 15:16 |
| olofk | I would have assumed the first if anything | 15:16 |
| olofk | Good thing you're here btw. I'm thinking of soldering a pin header to an SD card and use it as an SPI Flash | 15:17 |
| stekern | that's my speciality ;) | 15:17 |
| olofk | I 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 |
| stekern | http://elm-chan.org/docs/mmc/mmc_e.html | 15:18 |
| olofk | Awesome | 15:20 |
| olofk | Got any written code? | 15:21 |
| olofk | Do you got a filesytem on your card btw, or do you use something like dd to put data on it? | 15:24 |
| olofk | ok, so I send CMD0 and CMD1 to start things up. Then I just need CMD17 to read out blocks | 15:29 |
| stekern | olofk: since I used the minimig stuff, it's all fat32 | 15:30 |
| stekern | I've used the fat fs from the page I linked to in an other project though | 15:31 |
| stekern | http://elm-chan.org/fsw/ff/00index_e.html | 15:31 |
| stekern | and here's the project I used it in: https://www.youtube.com/watch?v=qYdOhU_aUH0 | 15:32 |
| olofk | I think you're the only youtube star that I know :) | 15:33 |
| stekern | youtube star? | 15:34 |
| olofk | Yeah. I assume that you have become filthy rich from the thousands of people who watch your movies | 15:35 |
| stekern | ah, yes, of course | 15:36 |
| stekern | =P | 15:36 |
| olofk | hmm... 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 bootloader | 15:38 |
| olofk | At least if I want FAT | 15:38 |
| olofk | I think that's more of a job for a second-stage bootloader | 15:38 |
| stekern | yes | 15:40 |
| olofk | I asked them to put on an SPI Flash, but they didn't listen :( | 15:41 |
| stekern | but you could of course steal the 4k minimig bootrom | 15:41 |
| olofk | oh, do they implement the SD loading in a boot ROM? | 15:42 |
| stekern | yes | 15:43 |
| stekern | https://github.com/skristiansson/minimig-de1/tree/master/fw/ctrl_boot | 15:43 |
| olofk | Fucking awesome! | 15:44 |
| stekern | you'll have to adapt it to the spi core we use of course | 15:47 |
| olofk | Looks like hardware.h contains the macros | 15:57 |
| olofk | I think I'll save that for another time, but it would be a great addition to the or1k_bootloaders repo | 15:59 |
| olofk | So it just needs a file (DE1_BOOTBIN?) on a FAT-formatted SD Card, right? | 16:02 |
| stekern | de1_boot.bin, yes | 16:02 |
| stekern | if you want to try it without porting it to our spi controller, it might be simpler to just hook up their spi controller: https://github.com/skristiansson/minimig-de1/blob/master/rtl/ctrl/ctrl_regs.v#L319 | 16:08 |
| olofk | We should get the minimig guy(s?) to next orconf | 16:44 |
| olofk | stekern: I switched around the console arguments in bootargs now, but where do tty0 expect to find its input? | 17:54 |
| olofk | hmm... 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 |
| olofk | So now the start of my frame buffer is somewhere in the middle of line 10 or something | 18:06 |
| olofk | It's not data loss, because all pixels are there. It must be that the monitor resyncs for some reason. | 18:08 |
| olofk | Marek Czerski's spiced up SD Card controller passes regression tests under FuseSoC now | 18:26 |
| bandvig | stekern: 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 |
| bandvig | stekern: 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 |
| bandvig | stekern: 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 |
| stekern | olofk: tty0 is the keyboard | 18:39 |
| bandvig | stekern: 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 |
| stekern | hmm, 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 killed | 18:42 |
| stekern | everything beyond and including ctrl/mem stages belong to such | 18:42 |
| stekern | (consider a started write, you can't abort that) | 18:42 |
| stekern | s/write/store | 18:43 |
| bandvig | I referenced the commentary in lines 247-251 of mor1kx_execute_ctrl_cappuccino | 18:46 |
| bandvig | And I see the same priorities in line 301 (mf(t)spr), 320 (msync), 335 (load/store/atomic). | 18:49 |
| stekern | yes, that comment is not related to the mul (alone) | 18:51 |
| stekern | this is the commit where that comment originated from: https://github.com/openrisc/mor1kx/commit/e11294b50bd853bf2757bba862ea158e077653c2 | 18:51 |
| olofk | stekern: So how do I bind the serial port stdin to tty0? | 18:53 |
| stekern | olofk: I don't know if you can | 18:53 |
| stekern | why do you want to do that though? | 18:53 |
| stekern | if you have a serial console, you get the console on the serial, no? | 18:54 |
| olofk | Yeah, I still need to connect the serial port, but I thought it would be flashy to have the output shown on the monitor instead | 18:54 |
| olofk | Maybe 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 solution | 18:55 |
| olofk | Unfortunately the connection there is a bit weird. | 18:55 |
| olofk | Got 8 systems and 45 cores in orpsoc-cores now btw | 18:59 |
| stekern | bandvig: I agree that the comment there is a bit confusing (and probably not describing the situation correctly). | 19:01 |
| olofk | stekern: Maybe it's time to replace the minimig SPI controller with a flashy SD controller core instead? | 19:06 |
| stekern | olofk: yes, I want to do that, it ought to be a lot faster than SPI'ing | 19:07 |
| stekern | HD emulation would benefit from that a lot | 19:08 |
| olofk | There just happens to be an SD Card controller in orpsoc-cores now :) | 19:09 |
| olofk | With a bare-metal driver | 19:09 |
| stekern | what a coincidence ;) | 19:09 |
| olofk | And a sdCard simulation model | 19:09 |
| olofk | Yeah. It's almost hard to believe that it's a coincidence :) | 19:10 |
| bandvig | stekern: 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 |
| bandvig | stekern: As far as I understand, we can get not only "valid" answers but additionally exception/inerrupt signals. | 19:17 |
| bandvig | stekern: So I don't see any reason to continue pushing insn from EXECUTE (but not from DECODE, btw) stage. | 19:17 |
| stekern | I agree, but I remember that there was some particular situation that needed the reversed logic for those | 19:24 |
| stekern | and it sucks that I didn't manage to document that situation better than I did | 19:24 |
| bandvig | stekern: 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 |
| stekern | the we signal of wb is gated by pipeline_flush, no? | 19:45 |
| bandvig | you mean in mor1kx_rf_cappuccino? | 19:46 |
| stekern | no, in mor1kx_execute_ctrl_cappuccino.v | 19:47 |
| bandvig | isn't it 1 clock later than WB latches result and ctrl_rf_wb_o? | 19:51 |
| bandvig | I mean it is the same clock, but WB latches asserted ctrl_wb_o. | 19:53 |
| stekern | yes, but that's the instruction that's currently in ctrl stage | 19:54 |
| stekern | but I'm getting more and more convinced that the reversed logic with padv and pipeline_flush is wrong | 19:54 |
| stekern | I bet it was a workaround for some bug, which might not exist anymore | 19:54 |
| stekern | we should test to re-reverse that logic and confirm that it works properly | 19:55 |
| stekern | and if it *doesn't* work properly, more properly document why it doesn't work ;) | 19:57 |
| bandvig | you 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!