| --- Log opened Sat Sep 14 00:00:55 2013 | ||
| poke53282 | I managed to render the first OpenGL image. Used the off-screen rendering feature of the library Mesa. | 00:42 |
|---|---|---|
| poke53282 | http://simulationcorner.net/osmesa.png | 00:42 |
| poke53282 | Nothing fancy | 00:42 |
| poke53282 | Another big program/library which is working now. | 00:43 |
| poke53282 | If anyone asks. It is software rendering. | 00:45 |
| knz | poke53282: nice, thanks :) | 07:09 |
| stekern | poke53282: cool! I've said it before, but I say it again, your cool stuff is really great stresstesting of our toolchains, I bet it's under your hands it has got it's hardest times | 07:31 |
| stekern | ...and you have of course pinpointed a couple of issues on the way too, which is great | 07:31 |
| hansfbaier | poke5328: What do you do? | 07:40 |
| hansfbaier | poke53282: ^ | 07:40 |
| stekern | olofk: regarding CDC in wb_intercon again, I think that's not just a good idea, but a "must have" | 08:37 |
| stekern | let's say we can clock mor1kx at ~100 MHz (we're not far from that now), it might not make sense to clock *all* peripherals at this rate too | 08:39 |
| stekern | and doing the CDC on the mor1kx bus interface was my first thought, but that's not such a good idea, because you want the wb interface to RAM to go as fast as possible | 08:41 |
| stekern | (besides, right now I have to add a avalon CDC in qsys to go 50MHz <-> 300 MHz for the DDR3 interface) | 09:15 |
| stekern | almost got the fpga ddr3 working now | 12:30 |
| stekern | I just get the same data out of every four address | 12:31 |
| stekern | but I think I know why | 12:31 |
| stekern | no... I don't know why | 13:25 |
| poke53282 | I think I have found a reproducible bug with the memory mapping. If I run a program from my rootfs (which should be tmpfs I think) the emulator stops with a unknown opcode error. If I copy the file and execute the copy everything is fine. If I am just moving the file (change the link but change the file position in memory) it crashes again. | 15:36 |
| poke53282 | ... but *dont* change the file position .... | 15:38 |
| poke53282 | reproducible with this specific linux image. | 15:42 |
| poke53282 | Today is hiking day. Enough time to think about this problem. At the moment I have no clue how to find the error. | 15:47 |
| olofk | poke53282: Cool that mesa runs. Is it through LLVMpipe or swrast? | 16:10 |
| olofk | stekern: Extending wb_intercon_gen should be quite easy. How hard would it be to rip out wb_port? | 16:12 |
| olofk | Or maybe not the whole wb_port. We don't really want the cache coherency parts I guess | 16:13 |
| olofk | Which reminds me that I should write some tests to exercise that in wb_sdram_ctrl too | 16:13 |
| stekern | olofk: rip out - as in reuse it in wb_intercon? or to get rid of it? | 16:45 |
| stekern | either case, when I wrote that, I split the controller and wb parts so that they should be pretty decoupled | 16:48 |
| stekern | that is true for the sdram controller part, it should be simple to use that with your own interface (or just directly). | 16:49 |
| stekern | the wb_port is perhaps more tightly coupled with the sdram controller | 16:50 |
| olofk | rip out as in reuse | 17:35 |
| olofk | I got your pull request now | 17:35 |
| olofk | I'm thinking of doing it right this time | 17:36 |
| stekern | ok, I think my explanation covered both cases | 17:36 |
| olofk | Yes. Just wanted to clarify my intents | 17:37 |
| stekern | (pull request): the build backends will end up in something similar as the simulator/ directory in the future i assume? | 17:38 |
| olofk | Anyway, about the pull request. Should I just run git pull https://github.com/skristiansson/orpsoc for-openrisc on my local tree? | 17:38 |
| olofk | What the hell does that even mean? | 17:38 |
| stekern | I figured the way I did it now was the "right way" until then | 17:38 |
| stekern | yes, 'git pull https://github.com/skristiansson/orpsoc for-openrisc' and then push it as you normally would if you're happy with it ;) | 17:39 |
| olofk | stekern: Yes. I should split out the build stuff soon, but for now, it's fine to just add it to build.py | 17:39 |
| olofk | And it wil become a build sub-package with a base class so that ISE and quartus can subclass it | 17:40 |
| olofk | Just like simulator | 17:40 |
| stekern | it's insane that quartus need more than 4GB RAM btw... | 17:40 |
| olofk | You said something about ugly commit messages if I did it with the GUI. At which point do I select what to put in the commit message if I do it the CLI way? | 17:41 |
| olofk | Yes. It's not a large system by any means | 17:41 |
| stekern | it just wouldn't do my sockit design in 32-bit mode anymore | 17:41 |
| stekern | if there are no merges (i.e. my commits just come in ontop of what's currently in master), then there will be no merge message at all | 17:42 |
| olofk | I would like to have things like that as command line options at some point too, to avoid putting it in the .core files, but that can wait | 17:42 |
| olofk | Ahh.. ok. So it just becomes what you wrote in your commit message. Sounds fine with me | 17:42 |
| olofk | Hmm.. now emacs came up and asked for a merge message | 17:43 |
| stekern | yes, but if there are commits in between, it will open up your EDITOR | 17:43 |
| olofk | Should I just go with the default, or write some explanation | 17:43 |
| olofk | Ahh crap. I just pushed a tiny update to the TODO file :( | 17:43 |
| olofk | Is it best if you rebase it? | 17:44 |
| olofk | (note that I'm using a fancy word that I somewhat know the meaning of) | 17:44 |
| stekern | nah, just leave the default merge message that git suggests | 17:44 |
| olofk | I closed emacs and thought it would abort, but looks like it went ahead. Oh well. Doesn't matter | 17:45 |
| olofk | Should be updated now | 17:45 |
| stekern | I mean, now you *did* do a merge, I'm fine with those merge messages | 17:46 |
| stekern | what annoys me with github is that it always put their merge messages in there | 17:46 |
| olofk | Even if it's just adding commits without actually merging, you mean? | 17:47 |
| stekern | yes | 17:47 |
| olofk | Looks like _franck_'s openrisc patch for OpenOCD is one step further to being merged | 17:48 |
| stekern | cool | 17:48 |
| stekern | I should clean up my opencores vga/lcd kernel driver and submit that | 17:49 |
| olofk | That would be coo | 17:49 |
| olofk | l | 17:49 |
| stekern | I'm going to try using it together with the arm core on the sockit first | 17:49 |
| stekern | should work fine, but might shake out some bug | 17:52 |
| stekern | ...and I should make it compatible with double buffers too | 17:52 |
| stekern | I've got an idea of getting X running on the arm core, with an openrisc overlay in the framebuffer | 17:53 |
| stekern | that'd be pretty cool I think | 17:53 |
| olofk | haha. That would be awesome :) | 17:55 |
| stekern | first I need to get this 2nd DDR3 working though... | 17:56 |
| stekern | I just realised that I *don't* need a avalon CDC, that can be handled directly on the mem controller port | 17:58 |
| stekern | I just got lost in the pointy-clicky qsys gui... | 17:58 |
| stekern | woho! it works! | 18:00 |
| stekern | at least reading and writing a single position with the debugger ;) | 18:02 |
| stekern | looks like loading a program works too | 18:02 |
| olofk | Awesome! Sounds like it's actually useful quite soon | 18:03 |
| olofk | Any number on how fast you can clock mor1kx on the cyclone? | 18:03 |
| stekern | my hello world doesn't print anything though... | 18:03 |
| stekern | on the cyclone v you mean? | 18:03 |
| olofk | yep | 18:04 |
| stekern | I haven't tried pushing it yet, running on a 50MHz clock now | 18:04 |
| stekern | hmm... ledblinker doesn't work neither... but PC looks pretty sane when I break | 18:05 |
| stekern | hmm*2, if I enable the led outputs the led changes when I load the program | 18:08 |
| olofk | What the hell did you hook up those LEDs to? :) | 18:09 |
| stekern | I didn't, wb_intercon_gen did ;) | 18:10 |
| olofk | :) | 18:10 |
| stekern | ah, well, this should be easy to figure out... at least the DDR3 connection seems to work fine | 18:13 |
| olofk | stekern: I'm about to push a first version of wb_intercon_gen now. Before that, could you take a quick glance at wb_intercon in or1200-generic. It has been generated with the version I intend to push | 18:18 |
| stekern | looks fine to me | 18:35 |
| stekern | I think I've misunderstood what address is the fallback address if no match occurs | 18:48 |
| stekern | it's the first address (i.e. [31:0]) | 18:49 |
| stekern | in wb_mux I mean | 18:49 |
| stekern | and I have gpio there | 18:49 |
| stekern | bigger question is why the address matching fails | 18:51 |
| stekern | I wonder if wb_mux really should fall back to something inexplicitly | 18:52 |
| stekern | you will never get bus errors on stray accesses then | 18:53 |
| stekern | ah... gpio doesn't care about wb_cyc_i... | 19:27 |
| stekern | I think I'll clean that up, make it 8-bit only and make a proper orpsoc-cores core of it | 19:28 |
| stekern | since both me and _franck_ use it | 19:28 |
| stekern | since with your address masking, you can just map several gpio modules if you need to | 19:32 |
| _franck_ | I've started the clean up: https://github.com/fjullien/orpsoc-cores/blob/master/systems/de1/rtl/verilog/gpio.v | 19:36 |
| stekern | ah | 19:39 |
| stekern | https://github.com/fjullien/orpsoc-cores/blob/master/systems/de1/rtl/verilog/gpio.v#L84 <= what's that? | 19:39 |
| stekern | I've made some changes to my de0 that I have adapted in the sockit port too | 19:39 |
| stekern | https://github.com/skristiansson/orpsoc-cores/blob/master/systems/sockit/rtl/verilog/gpio.v | 19:40 |
| stekern | moving the tristate logic outside of the core | 19:40 |
| _franck_ | oups, may be an old debug thing I added there | 19:40 |
| stekern | otherwise, seems like we agree ;) | 19:41 |
| _franck_ | olofk: is that the right way to add patches ? : http://pastie.org/8326092 | 19:42 |
| stekern | wb_adr_i can be a 1-bit signal btw | 19:42 |
| _franck_ | olofk: it does not apply my patches | 19:43 |
| _franck_ | olofk: it seems patch are applied only when cores are fetched from external repos. | 19:53 |
| stekern | I don't say you shouldn't be able to, but why do you need to have patches for the local files? | 20:10 |
| _franck_ | that's about the micron SDRAM model. I wanted to keep the original file as this and apply pacthes | 20:15 |
| _franck_ | I'm hacking orpsoc to be able to fetch files from a provider "url". So I could fetch the micron's zip file directly and apply patches | 20:16 |
| stekern | nice | 20:20 |
| stekern | I think there should be a "website" or something like that option in the .core files, where you could put a link | 20:21 |
| stekern | for instance, if the core comes from github, it's annoying to copy each of the words to get to the right place | 20:22 |
| _franck_ | http://pastie.org/8326168 | 20:23 |
| stekern | (SRAM) so in the end, you don't want to apply patches to local files ;) | 20:23 |
| _franck_ | no :) | 20:23 |
| stekern | the leds are not acting strange anymore, but still no blinking when I try to run the led blinker from DDR3... | 20:29 |
| stekern | haha, I just noticed I make a quick apparance in this: http://www.youtube.com/watch?v=5pG3FL_k6to | 20:47 |
| stekern | juliusb is accidently opening his irc window... | 20:48 |
| _franck_ | olofk: I sent you a pull request for orpsoc. I added a new provider type "url". Could you please review/test it ? | 21:32 |
| _franck_ | I tested it with zip and simple files and it weems to work. I'm using python 3.3 so you should test it with an older version | 21:33 |
| _franck_ | s/weems/seems | 21:33 |
| stekern | _franck_: where do you see spaces? ;) | 21:38 |
| stekern | https://github.com/skristiansson/orpsoc-cores/blob/03277939d200cd49aa1eb6dd598dd2bcb1fa7123/cores/gpio/gpio.v | 21:39 |
| stekern | I see a misplaced end now though... | 21:39 |
| stekern | bah, enough shotgun debugging, tomorrow I'll do some proper signal logging instead... | 22:09 |
| --- Log closed Sun Sep 15 00:00:57 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
