| --- Log opened Wed Jul 23 00:00:31 2014 | ||
| blueCmd | well, running Linux with atomics seems to work. Running a test program with a basic compare and swap seems to work just fine, adding a l.sw to polute the location also makes the atomic store fail, which is nice | 00:23 |
|---|---|---|
| blueCmd | the worrysome thing is that without the value-check this "works" for glibc | 00:23 |
| blueCmd | with the value-check busybox (init) freezes at boot | 00:23 |
| blueCmd | my hypothesis: since the atomics in gcc are one-shot, the loop gcc generates to acquire lock might store something to the memory location | 00:25 |
| blueCmd | seems very odd that it would be the case though | 00:25 |
| stekern | blueCmd: there's also this test you can try: https://github.com/openrisc/or1ksim/blob/or1k-master/testsuite/test-code-or1k/atomic/atomic.S | 02:47 |
| maxpaln | Overnight rethink - I was wondering why I didn't come across this problem when implementing Linux on our old silicon. I had disabled Cache'ing on that implementation (for another reason - lucky me!) - since performance isn't the prime aim of the first iteration of the design I am going to disable caches again and see if it allows linux to boot. I have my fingers crossed. If it works it will | 07:19 |
| maxpaln | be buy me plenty of time to implement mor1kx... | 07:19 |
| stekern | maxpaln: presumably just luck, the timing has to be right for the situation to happen | 07:41 |
| stekern | blueCmd: what's the point of this repo? https://github.com/openrisc/openrisc-docs | 07:41 |
| maxpaln | stekern: I agree, whether the situation happens or not is pure luck - but without caches a TLB miss can't happen (if I understand the mechanism correctly) so disabling caches should avoid the problem. That's my working theory anyway... | 07:43 |
| stekern | no, tlb misses can happen without caches | 07:43 |
| stekern | maybe that misconception comes from something I said earlier, that the TLBs *are* pagetable caches | 07:44 |
| maxpaln | ah, ok - so it is pure luck! | 07:45 |
| maxpaln | :-( | 07:46 |
| maxpaln | oh well - | 07:46 |
| stekern | but it's still a bit odd, it has to be a fairly odd situation, so just shifting code around a bit will probably remove it | 07:52 |
| stekern | and another thing that is even more odd, for that to happen, you'd need to have another exception taking precedence over the itlb miss in the first place, but there's no exceptions with higher priority than itlb-miss... | 07:56 |
| stekern | *and* rfeing into an itlb-miss can't be that uncommon | 08:00 |
| blueCmd | stekern: it's the openrisc SVN from opencores | 09:47 |
| stekern | blueCmd: yes I can see that, but I didn't ask "what does that repo contain" ;) | 09:55 |
| blueCmd | stekern: the point being to move to git and off opencores | 10:00 |
| blueCmd | I'm changing stuff quite aggressively hoping that people will bring up their concerns or silently follow. | 10:01 |
| stekern | ok, I don't think we want a repo full of mixed stuff without any history moved over from svn to github.com/openrisc | 10:02 |
| stekern | if we want to do continous development on the subprojects in the opencores/openrisc svn structure, I think the way forward is to move them over as standalone projects with their full history | 10:03 |
| stekern | (like we did with or1ksim) | 10:04 |
| stekern | btw, I already did this when opencores was down several days and I couldn't get to the arch spec on my laptop: https://github.com/openrisc/doc | 10:05 |
| blueCmd | stekern: oh, I didn't know that! well, openrisc-docs contains revision history | 10:07 |
| stekern | oh, yes it did... wonder why I got the impression that it didn't. | 10:11 |
| stekern | I still don't see the value of it though | 10:11 |
| blueCmd | stekern: you trust opencores more than github? | 10:12 |
| stekern | no, but there's just old cruft in that repo, so I don't care ;) | 10:13 |
| stekern | my point is just, if we want the stuff from that on github.com/openrisc, split it up into 'real' projects then | 10:17 |
| stekern | or call it something sensible, like 'old-cruft-backup-from-opencores-svn' | 10:18 |
| maxpaln | Well, for what its worth - disabling the caches has indeed allowed Linux to boot. I think I'll archive this project, send it to my customer and branch from there to switch OR1200 for mor1kx - at least this way the customer can get up and running and are not waiting for me :-) | 10:20 |
| stekern | maxpaln: sounds like a plan | 10:27 |
| blueCmd | stekern: I have an 'old-svn' branch on that project that is just that | 11:57 |
| stekern | the old-svn branch doesn't work btw | 12:01 |
| blueCmd | stekern: hm? | 12:02 |
| stekern | but the naming of that repo is confusing, and the mix of stuff in it so to. If I'm confused what its purpose is, how do you expect user to react on it? | 12:02 |
| stekern | *users | 12:03 |
| blueCmd | stekern: I'm all for splitting it into parts. I just wanted it off opencores ASAP. | 12:03 |
| blueCmd | I removed stuff in the master branch that I knew was out of date | 12:03 |
| blueCmd | I left what I wasn't certain of | 12:03 |
| stekern | ok, the 'old-svn' branch works now, it was broken this morning | 12:04 |
| blueCmd | ironic | 12:04 |
| stekern | I'd like that whole repo to be called openrisc-old-svn, that name can stick even after interesting stuff have been lifted out of it | 12:06 |
| blueCmd | stekern: SGTM | 12:06 |
| blueCmd | I propose lifting or1200 to a seperate repo | 12:07 |
| stekern | yes, and there's some rtos stuff that are of interest | 12:07 |
| stekern | some of the repos are just static, with no expected development, but it's still nice to have a backup of them if someone for some reason want to dig them up at some point | 12:08 |
| stekern | like orpmon and or_debug_proxy | 12:09 |
| olofk | I don't want to hurry this too much either. Carefully picking out projects is the way to got here | 12:09 |
| olofk | And openrisc-docs is very confusing | 12:09 |
| olofk | If you just want a backup I think it's better to put on your own github account for now | 12:09 |
| blueCmd | olofk: well, my evil master plan is not backup - that's just the initial step | 12:12 |
| maxpaln | WooHoo - Linux really does boot now: :-) | 12:43 |
| maxpaln | # uname -a | 12:43 |
| maxpaln | Linux openrisc 3.13.0-rc2-or1ksim-12436-g77ed213-dirty #117 Tue Jul 22 01:23:39 PDT 2014 openrisc GNU/Linux | 12:43 |
| olofk | maxpaln: Congratulations! | 12:43 |
| olofk | Now rinse and repeat with mor1kx :) | 12:44 |
| ysionneau | congratz maxpaln :) | 12:44 |
| maxpaln | olofk: thanks - debugging new silicon, PCBs, IP and a | 12:44 |
| maxpaln | Memory controller has taken its toll.... | 12:44 |
| olofk | Btw, will this work be published somewhere? Adding lattice support has been on my wishlist for a long time | 12:45 |
| ysionneau | you used bullet time to shoot on gateware bugs | 12:45 |
| olofk | I'm especially interested in the ice FPGAs that you acquired from siliconblue | 12:45 |
| olofk | Well, Lattice's reputation in low power is very interesting overall | 12:45 |
| maxpaln | ysionneau: exactly - I have really been at this for 3 years, it just seems like less to your mortals working in slow-time.... | 12:45 |
| maxpaln | olofk: Yes, there will be a published version | 12:46 |
| ysionneau | ahah :) | 12:46 |
| ysionneau | in your time base your worked crazy fast! | 12:46 |
| ysionneau | in our* | 12:46 |
| maxpaln | But I want to publish against the most up to date - and on one of our eval boards | 12:46 |
| maxpaln | the version I have at the moment is kinda custom for this project I have been working on. | 12:47 |
| olofk | maxpaln: For further work you should definitely move over to FuseSoC | 12:47 |
| maxpaln | yeah, exactly | 12:47 |
| olofk | Well, we're here to help :) | 12:47 |
| maxpaln | I think the best way is to start from scratch with a fresh checkout, create a processor that is targetted at our ECP5 eval board and use this as the initial publication. | 12:48 |
| olofk | Did you ever run my wishbone BFM poor-mans-constrained-random simulations against the Wishbone interface on your DDR controller btw? | 12:48 |
| maxpaln | olofk: it was the cornerstone of my development work, without it I would have really struggled to debug the controller as far as I did. :-) | 12:49 |
| olofk | maxpaln: Glad to hear this. I should definitely improve it to catch more bugs though | 12:50 |
| maxpaln | However, having found a few bugs that the simulations didn't highlight I would like to propose a couple of enhancements that would go a long way to catching all the bugs: | 12:50 |
| olofk | Super! | 12:50 |
| maxpaln | I need to look at the code to see if I can implement them - they should be straight forward. But in descriptive terms: | 12:51 |
| maxpaln | The code currently writes to memory then reads it back straight away and via the same burst access type. It would be better to do a bunch of writes, then a bunch of reads - mixing and matching the burst types. | 12:51 |
| olofk | That's a good idea. Might be easiest to just keep a separate array of expected values at all memory locations | 12:53 |
| maxpaln | Yeah, that was how I was planning on approaching it - | 12:53 |
| olofk | It will be a big f*in array though :) | 12:54 |
| maxpaln | :-) | 12:54 |
| maxpaln | you could make it manageable by running on 1K addresses or something | 12:54 |
| olofk | Yeah. And doing many runs instead to catch address-related bugs | 12:55 |
| maxpaln | exactly, have the testbench populate a 1K buffer with values, then perform a bunch of writes to the wishbone memory interface using random burst types, then read the values back using random burst types again - as long as the values match you have a win! | 12:56 |
| maxpaln | you could even parameterise the buffer size - DDRX memories use pages that wrap at column boundaries - having a buffer that is larger than the column address space is an interesting test that took me a while to implement. | 12:57 |
| olofk | Yes, having buffers larger than page size is probably a good idea | 12:59 |
| maxpaln | The other one is implementing some simple wait states - the simulation immmediately starts a new transaction after the previous one ends. In the real world there are usually some more idle cycles for the controller - this one is more implementation specific but the simulation never exercised the 'remain in idle' condition of my state machine. There happened to be a bug in that code!! | 12:59 |
| olofk | random back-off times is on my TODO list :) | 13:00 |
| maxpaln | :-) | 13:00 |
| olofk | Did you get my invitation btw? | 13:00 |
| olofk | (just checking to see that it reached you) | 13:00 |
| maxpaln | Yep, it got to me - thanks | 13:01 |
| maxpaln | I am looking forward to it :-) | 13:01 |
| olofk | Glad to hear | 13:01 |
| maxpaln | I still need to reply to you though - it's on my list, I assumed I had a few days :-) | 13:01 |
| olofk | No stress at all. It's just that some company mail servers are a bit picky about accepting mail from gmail/hotmail/yahoo addresses | 13:02 |
| maxpaln | it's all good! | 13:02 |
| maxpaln | but otherwise, the BFM simulations were very helpful. Glad they were there! | 13:03 |
| stekern | also, zero wait state read->write->read turnaround busaccesses should be tested | 13:06 |
| stekern | and back-to-back bursts | 13:07 |
| olofk | stekern: Totally agree | 13:07 |
| stekern | i.e. accesses where stb&cyc aren't de-asserted between bursts | 13:08 |
| olofk | stekern: Did we ever work out if that was allowed in the wishbone spec? | 13:08 |
| stekern | byte-selects without the lower bits in the address is another test | 13:09 |
| stekern | I have never had any doubts that it wouldn't be allowed | 13:09 |
| stekern | why would it be disallowed? | 13:09 |
| olofk | 0001, 0010, 0100, 1000, 0011, 1100 and 1111 should be the masks to test, right? | 13:09 |
| olofk | for 32 bit | 13:10 |
| stekern | yes, 1001 for instance isn't a valid mask | 13:10 |
| olofk | and 0020 isn't either :) | 13:10 |
| stekern | is that in dinary? | 13:14 |
| olofk | I'm thinking about implementing a change in FuseSoC btw, to allow multiple .core files in a single directory. That way we could pull in larger repositories (like milkymist) instead of doing like we're currently do for mmuart and minimac | 13:14 |
| olofk | :) | 13:14 |
| maxpaln | stekern: if stb and cyc are not deasserted what indicates the end of the cycle? | 13:15 |
| olofk | maxpaln: cti=111 | 13:15 |
| maxpaln | Ah, ok - does the spec allow this? | 13:15 |
| olofk | That's what we're discussing :) | 13:15 |
| maxpaln | :-) | 13:15 |
| maxpaln | I think one of CYC or STB and CYC need to deassert | 13:15 |
| maxpaln | if it just CYC then it is a BLOCK cycle (which is not tested in the simulation!) | 13:16 |
| maxpaln | (I think) | 13:16 |
| olofk | stb is more like a data valid, so that doesn't really indicate that the cycle is over | 13:16 |
| olofk | You can deassert that in the middle of a transaction if the sender needs to wait to produce more data | 13:16 |
| olofk | But they are generally just &-ed together | 13:17 |
| maxpaln | I believe you can also change from Write to Read by keeping CYC asserted and deasserting STB, toggling WE, then asserting STB again | 13:17 |
| maxpaln | I looked at this bit of the spec a LOT | 13:18 |
| maxpaln | I hope I understood it correctly :-) | 13:18 |
| olofk | It's a bit hard to decipher in some areas | 13:18 |
| maxpaln | :-) | 13:18 |
| maxpaln | ah, but I think stekern is right - it would appear to be valid to insert zero wait states - | 13:24 |
| maxpaln | The spec always describes deasserting STB and CYC at the end of a burst, but it never states it as a rule - at least not as far as I can see. | 13:25 |
| maxpaln | I wonder what my controller would do in this situation! :-) | 13:25 |
| stekern | no, it's not a rule. a cycle is always terminated by an ack, and a following cycle can immediately follow | 13:33 |
| maxpaln | yep, that is what I read too | 13:34 |
| maxpaln | or rather, how I understood it when i read it | 13:35 |
| maxpaln | so the random number of wait states should vary from 0 to n (where n is probably 6-10) | 13:35 |
| stekern | right, that'd make sense | 13:45 |
| olofk | yep | 13:51 |
| olofk | stekern: I have a project in the works where I probably want do DMA, kind of like your wb_fifo idea | 16:14 |
| olofk | An external device will push data into the FPGA, and I want to make a wb master that pushes this data to another peripheral or to RAM | 16:15 |
| olofk | I could do something like the buffer descriptors in ethmac to control this, but I'm thinking about something simpler | 16:17 |
| olofk | Just adding a wb slave interface where I have five registers. start address, end address, write pointer, read pointer and an overflow flag | 16:17 |
| olofk | and an enable flag | 16:17 |
| olofk | So I allocate a memory area and set up the start and end address accordingly | 16:18 |
| olofk | Then I just enable it, checks the write pointer to see if new data has come in and update the read pointer when I have read a data block | 16:19 |
| olofk | Overflow is set when the pointers overlap | 16:19 |
| olofk | If I can do this somewhat modular, I think it could be useful in other places as well. | 16:20 |
| olofk | So, I'm looking for some second opinion/brainstorming to see if this is general enough to be useful | 16:20 |
| olofk | Actually, it would be the opposite of the wb_fifo, come to think of it | 16:21 |
| olofk | This is for streaming data, so there will be no packet boundraries to think of | 16:21 |
| olofk | There are of course a lot of extra features that could be implemented, like configurable burst sizes to get a good bus utilization and so on | 16:27 |
| olofk | and it could probably be extended to support packets as well | 16:27 |
| stekern | yes, that sounds useful, only one question - so, is the idea that this core is completely stand-alone (with some well-defined interface) or is the idea that you embed it into your core instead of constantly rewriting a wb-master whenever you want DMA functionality? | 16:31 |
| olofk | The idea is to have a well-defined interface (basically a FIFO), and users can either put them side-by-side or drop them into their core | 16:42 |
| olofk | For my own project, I'll probably make a convenience wrapper module that instantiates the wb-master-thingie together with my peripheral driver | 16:43 |
| olofk | Got to run now. Going to play soccer with some friends, which is like the worst idea ever in this heat | 16:43 |
| blueCmd | olofk: stekern: https://github.com/openrisc/or1200 | 17:07 |
| juliusb | so, interesting discussion on the mailing list | 18:05 |
| juliusb | I had no idea that orsoc.se had disappeared into the ether | 18:05 |
| juliusb | and is Marcus really uncontactable these days? | 18:05 |
| juliusb | Anyway, I think the decoupling of repos from OpenCores was basically a foregone conclusion once people started committing most work to github | 18:07 |
| juliusb | There's practically no commits of code to OC SVN compared to github | 18:08 |
| juliusb | So that's certainly not an issue. The issues, as I see them, are mailing lists and website (wiki?) and that's it? | 18:09 |
| juliusb | The entry point has basically always been the opencores site, it's the second link on google after the wikipedia entry | 18:10 |
| juliusb | and blueCmd I agree completely that the main page there needs a good tidy | 18:10 |
| juliusb | I can't speak for the rest of the OpenCores projects, I agree with Jeremy, you might be biting off more than you can chew by taking what is on OpenCores lock stock and putting it up elsewhere. You could probably write a good script to scrape what little information also lives on the projects' pages and put that onto github in some form, too | 18:14 |
| juliusb | maybe that'll gain some traction, I don't know. Most hackers/hobbyists/enthusiasts now just put their cores on github anyway, there's probably a handful of active projects on OpenCores, and I suspect any alternative will be equivalently active. I can't say OpenCores is a hotbed of collaboratively developed IP cores anyway (aside from the flagship project, of course) | 18:16 |
| juliusb | most projects with more than a couple of people contributing either start their own thing, or as I mentioned, stick it on github and host their own domain with information on it. So I guess I'm saying, as crap as OpenCores is, I'm not convinced any alternative will make things much better (there's already ohwr.org and various other academia-based sites with stuff) | 18:20 |
| juliusb | I'd like to be proven wrong, though :) | 18:24 |
| olofk | I had no idea about the orsoc.se redirection either | 21:13 |
| olofk | hmm... what should I call my new core? It's not a full DMA implementation, so I want to avoid that | 21:22 |
| olofk | I settled for wb_streamer for now | 22:35 |
| blueCmd | juliusb: the opencores.org -> freecores github is mainly to replace opencores and let it die in peace. | 23:55 |
| blueCmd | juliusb: "foregone conclusion once": yes, that's a big point that I'm trying to make | 23:56 |
| blueCmd | my idea is that the big work is already done, but we're still having opencores in the critical path for a new user or for our "release" process | 23:57 |
| blueCmd | which I don't like | 23:57 |
| --- Log closed Thu Jul 24 00:00:33 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!