IRC logs for #openrisc Saturday, 2013-09-14

--- Log opened Sat Sep 14 00:00:55 2013
poke53282I managed to render the first OpenGL image. Used the off-screen rendering feature of the library Mesa.00:42
poke53282Nothing fancy00:42
poke53282Another big program/library which is working now.00:43
poke53282If anyone asks. It is software rendering.00:45
knzpoke53282: nice, thanks :)07:09
stekernpoke53282: 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 times07:31
stekern...and you have of course pinpointed a couple of issues on the way too, which is great07:31
hansfbaierpoke5328: What do you do?07:40
hansfbaierpoke53282: ^07:40
stekernolofk: regarding CDC in wb_intercon again, I think that's not just a good idea, but a "must have"08:37
stekernlet'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 too08:39
stekernand 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 possible08: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
stekernalmost got the fpga ddr3 working now12:30
stekernI just get the same data out of every four address12:31
stekernbut I think I know why12:31
stekernno... I don't know why13:25
poke53282I 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
poke53282reproducible with this specific linux image.15:42
poke53282Today is hiking day. Enough time to think about this problem. At the moment I have no clue how to find the error.15:47
olofkpoke53282: Cool that mesa runs. Is it through LLVMpipe or swrast?16:10
olofkstekern: Extending wb_intercon_gen should be quite easy. How hard would it be to rip out wb_port?16:12
olofkOr maybe not the whole wb_port. We don't really want the cache coherency parts I guess16:13
olofkWhich reminds me that I should write some tests to exercise that in wb_sdram_ctrl too16:13
stekernolofk: rip out - as in reuse it in wb_intercon? or to get rid of it?16:45
stekerneither case, when I wrote that, I split the controller and wb parts so that they should be pretty decoupled16:48
stekernthat is true for the sdram controller part, it should be simple to use that with your own interface (or just directly).16:49
stekernthe wb_port is perhaps more tightly coupled with the sdram controller16:50
olofkrip out as in reuse17:35
olofkI got your pull request now17:35
olofkI'm thinking of doing it right this time17:36
stekernok, I think my explanation covered both cases17:36
olofkYes. Just wanted to clarify my intents17:37
stekern(pull request): the build backends will end up in something similar as the simulator/ directory in the future i assume?17:38
olofkAnyway, about the pull request. Should I just run git pull for-openrisc on my local tree?17:38
olofkWhat the hell does that even mean?17:38
stekernI figured the way I did it now was the "right way" until then17:38
stekernyes, 'git pull for-openrisc' and then push it as you normally would if you're happy with it ;)17:39
olofkstekern: Yes. I should split out the build stuff soon, but for now, it's fine to just add it to build.py17:39
olofkAnd it wil become a build sub-package with a base class so that ISE and quartus can subclass it17:40
olofkJust like simulator17:40
stekernit's insane that quartus need more than 4GB RAM btw...17:40
olofkYou 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
olofkYes. It's not a large system by any means17:41
stekernit just wouldn't do my sockit design in 32-bit mode anymore17:41
stekernif 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 all17:42
olofkI 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 wait17:42
olofkAhh.. ok. So it just becomes what you wrote in your commit message. Sounds fine with me17:42
olofkHmm.. now emacs came up and asked for a merge message17:43
stekernyes, but if there are commits in between, it will open up your EDITOR17:43
olofkShould I just go with the default, or write some explanation17:43
olofkAhh crap. I just pushed a tiny update to the TODO file :(17:43
olofkIs 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
stekernnah, just leave the default merge message that git suggests17:44
olofkI closed emacs and thought it would abort, but looks like it went ahead. Oh well. Doesn't matter17:45
olofkShould be updated now17:45
stekernI mean, now you *did* do a merge, I'm fine with those merge messages17:46
stekernwhat annoys me with github is that it always put their merge messages in there17:46
olofkEven if it's just adding commits without actually merging, you mean?17:47
olofkLooks like _franck_'s openrisc patch for OpenOCD is one step further to being merged17:48
stekernI should clean up my opencores vga/lcd kernel driver and submit that17:49
olofkThat would be coo17:49
stekernI'm going to try using it together with the arm core on the sockit first17:49
stekernshould work fine, but might shake out some bug17:52
stekern...and I should make it compatible with double buffers too17:52
stekernI've got an idea of getting X running on the arm core, with an openrisc overlay in the framebuffer17:53
stekernthat'd be pretty cool I think17:53
olofkhaha. That would be awesome :)17:55
stekernfirst I need to get this 2nd DDR3 working though...17:56
stekernI just realised that I *don't* need a avalon CDC, that can be handled directly on the mem controller port17:58
stekernI just got lost in the pointy-clicky qsys gui...17:58
stekernwoho! it works!18:00
stekernat least reading and writing a single position with the debugger ;)18:02
stekernlooks like loading a program works too18:02
olofkAwesome! Sounds like it's actually useful quite soon18:03
olofkAny number on how fast you can clock mor1kx on the cyclone?18:03
stekernmy hello world doesn't print anything though...18:03
stekernon the cyclone v you mean?18:03
stekernI haven't tried pushing it yet, running on a 50MHz clock now18:04
stekernhmm... ledblinker doesn't work neither... but PC looks pretty sane when I break18:05
stekernhmm*2, if I enable the led outputs the led changes when I load the program18:08
olofkWhat the hell did you hook up those LEDs to? :)18:09
stekernI didn't, wb_intercon_gen did ;)18:10
stekernah, well, this should be easy to figure out... at least the DDR3 connection seems to work fine18:13
olofkstekern: 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 push18:18
stekernlooks fine to me18:35
stekernI think I've misunderstood what address is the fallback address if no match occurs18:48
stekernit's the first address (i.e. [31:0])18:49
stekernin wb_mux I mean18:49
stekernand I have gpio there18:49
stekernbigger question is why the address matching fails18:51
stekernI wonder if wb_mux really should fall back to something inexplicitly18:52
stekernyou will never get bus errors on stray accesses then18:53
stekernah... gpio doesn't care about wb_cyc_i...19:27
stekernI think I'll clean that up, make it 8-bit only and make a proper orpsoc-cores core of it19:28
stekernsince both me and _franck_ use it19:28
stekernsince with your address masking, you can just map several gpio modules if you need to19:32
_franck_I've started the clean up:
stekern <= what's that?19:39
stekernI've made some changes to my de0 that I have adapted in the sockit port too19:39
stekernmoving the tristate logic outside of the core19:40
_franck_oups, may be an old debug thing I added there19:40
stekernotherwise, seems like we agree ;)19:41
_franck_olofk: is that the right way to add patches ? :
stekernwb_adr_i can be a 1-bit signal btw19:42
_franck_olofk: it does not apply my patches19:43
_franck_olofk: it seems patch are applied only when cores are fetched from external repos.19:53
stekernI 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 pacthes20: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 patches20:16
stekernI think there should be a "website" or something like that option in the .core files, where you could put a link20:21
stekernfor instance, if the core comes from github, it's annoying to copy each of the words to get to the right place20:22
stekern(SRAM) so in the end, you don't want to apply patches to local files ;)20:23
_franck_no :)20:23
stekernthe leds are not acting strange anymore, but still no blinking when I try to run the led blinker from DDR3...20:29
stekernhaha, I just noticed I make a quick apparance in this:
stekernjuliusb 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 version21:33
stekern_franck_: where do you see spaces? ;)21:38
stekernI see a misplaced end now though...21:39
stekernbah, 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 2.15.2 by Marius Gedminas - find it at!