--- Log opened Wed Oct 09 00:00:31 2013 | ||
-!- Netsplit *.net <-> *.split quits: larks | 03:22 | |
stekern | _franck_: odd, wonder what is so different in your setup | 06:13 |
---|---|---|
stekern | running a more recent busybox than one from 2011 is not a bad thing though ;) | 06:13 |
stekern | hansfbaier: nice | 06:34 |
hansfbaier | _franck_: stekern: https://github.com/hansfbaier/openrisc-sockit-tutorial/blob/master/openrisc-sockit-tutorial.pdf | 06:37 |
hansfbaier | stekern: still work in progress, but already quite a bit there, rest tomorrow I hope | 06:37 |
hansfbaier | got to do some paid work now | 06:38 |
hansfbaier | stekern: Tutorial has been tested in xubuntu 12.04 VM | 06:38 |
hansfbaier | stekern: You might want to get it now, just pushed a new version as I posted the link | 06:39 |
stekern | ok, I think I've already been helped by your DIP-switch explanation | 06:44 |
stekern | I think I've looked at the switch and not the board when I tried to setup fpga loading from SD-card | 06:44 |
hansfbaier | stekern: I would add the files you gave me to the tutorial repository, or do you think it would be better to use your links? | 06:47 |
stekern | no, just add them there | 06:52 |
stekern | I can add a header to the memloader first if you like ;) | 06:52 |
hansfbaier | stekern: Yes, that would be nice | 06:55 |
stekern | http://oompa.chokladfabriken.org/openrisc/sockit-tools/memload.c | 06:56 |
hansfbaier | stekern: Do you think it would be a good idea to include the ocfb in the HPS? Since the OpenRISC uses it too, I had a crash yesterday, when both tried to access it.... | 07:12 |
stekern | my motivation for trying it out was two-folded, 1) I counted that connecting it to a completely different system might weed out some bugs in the driver, which it did 2) I wanted to see if it worked | 07:16 |
stekern | but since there are some problems with endianness and the transfers from HPS DDR3, perhaps it's not strictly necessary as a step in the guide | 07:18 |
stekern | because that's what I guess you are getting at | 07:18 |
stekern | besides, you'd need my wip cleanup of ocfb.c version for it too | 07:19 |
hansfbaier | stekern: see you later, need rest | 07:23 |
stekern | me too... | 07:29 |
stekern | unfortunately it's not time for that now... | 07:29 |
stekern | I've been insanely tired after the weekend | 07:29 |
olofk_ | http://olofkindgren.blogspot.se/2013/10/orconf2013-reports-from-yearly-openrisc.html | 07:47 |
olofk_ | Please tell me if you find factual errors, bad language or any other fuck ups. It's been written piece by piece on the little spare time I could find, so it might be a bit messy | 07:50 |
xlro | great write-up olofk_ | 08:08 |
xlro | the other jeremy from the conference here, btw :) | 08:09 |
olofk_ | xlro: That answered the question I was just about to ask :) | 08:09 |
olofk_ | I never got around to explain in detail how test cases was fed into the simulator in ORPSoCv3. Sorry about that | 08:10 |
xlro | no worries, I will definitely have a closer look at that at some point - looks like switching to orpsocv3 makes also total sense for our work, especially regarding ease of configurability | 08:11 |
olofk_ | Please let me know how it goes. I'll be happy to answer questions and provide support | 08:12 |
xlro | atm its a bunch of randomly symlinked include files | 08:12 |
xlro | ok great | 08:12 |
xlro | what I started doing is hacking the testbench to accomodate for simulating on gate level a place&routed design, since this is important for us - at that stage the internal signal names are mainly gone though, which breaks the available monitor | 08:14 |
xlro | I'd love to do that in a proper form and feed that back | 08:14 |
olofk_ | I have related problems with timing constraints. The only way I can think about is making the synthesis tool spit out a list of renamed elements that can be used for other tools | 08:16 |
xlro | yes I thought about that too - after DC we also go through encounter though, which alters the names again | 08:18 |
olofk_ | Are the renamings predictable? Can you place syn_keep attributes on the signals that the monitor tries to probe? | 08:18 |
olofk_ | It would still be a problem though, since I guess that the internal tasks that we have for getting GPR contents will be removed after synthesis | 08:18 |
olofk_ | Ahh.. a two stage renaming. That can be pretty messy I guess :)= | 08:18 |
olofk_ | It's good to know these things, as the monitor is one of the things that might need an overhaul in the near future. Would be great to make it more resistent to these kind of problems | 08:19 |
xlro | getting the gpr contents is pretty hard indeed I think (in an automated fashion) - but I would totally be happy with just a testbecnh that runs cleanly and dedects when the processor is done, which is not hard (looking on instruction bus) | 08:20 |
olofk_ | I've already made some local changes so that the some of the signal names comes in as ports instead of being hardcoded in the monitor | 08:20 |
olofk_ | Exactly. That feature was what I aimed for first in my stripped down monitor | 08:20 |
xlro | atm what I do is get rid of ("uncomment" with a custom define) everything that references stuff that is not available anymore | 08:20 |
xlro | until it compiles | 08:21 |
xlro | :) | 08:21 |
xlro | works ok so far, but very ugly | 08:21 |
olofk_ | "Automated approach" <-----------------------------------------------------------------------X--> "Manual error-prone method" | 08:21 |
olofk_ | I put an X where you are atm | 08:21 |
xlro | oh definitely, although there is not much space for error anymore I think because I remove 90% of the monitor basically with this method ;) | 08:22 |
olofk_ | :) | 08:22 |
xlro | right now I'm still here in Cambridge at ARM, but I will continue on this when go back to EPFL end of november - probably one of first things I'll do | 08:24 |
olofk_ | xlro: Do you have something like this? http://git.opencores.org/?a=viewblob&p=orpsoc&h=5cbcddc39e767cb745e49ff0c1d08cfba8446b77&hb=674e00a7d99489d172c3753fd331e0826779d753&f=cores/or1k-monitor/verilog/monitor.v | 08:24 |
xlro | I think there is a little more left, but effectively not much more, I think it also has the NOP report still in. I never looked exactly at the code that is effectively left, I basically just have conditional "defines" blocks everywhere where signal names are mentioned that are inside the actual core | 08:26 |
xlro | since these are gone | 08:26 |
xlro | so the actual source fiel is actually bigger :P | 08:26 |
olofk_ | hahaha | 08:26 |
xlro | but the code is just not used | 08:26 |
xlro | that way I can use the same base for both simulations | 08:26 |
xlro | and just enable one define | 08:26 |
olofk_ | Yeah, that's a clear win | 08:27 |
-!- Powermaniac_ is now known as Powermaniac | 08:48 | |
olofk_ | Crap! I forgot to mention Saar Drimer's lightning talk | 08:56 |
olofk_ | Was that just after my orpsocv3 presentation? | 08:59 |
hansfbaier | olofk_: talks + slides already online ? | 09:08 |
hansfbaier | stekern: If I get it right, the linux-socfpga kernel does not need to be modified if used without the ocfb, right? What was the make argument to generate the default .config again? | 09:18 |
hansfbaier | ah got it, it's in the README | 09:19 |
hansfbaier | no, that was OpenRISC. | 09:20 |
hansfbaier | stekern: Well, actually, if we don't modify the kernel, the only reason to compile it is for USB OTG .... | 09:21 |
stekern | yes | 09:29 |
stekern | which isn't neither strictly necessary to get started with openrisc on sockit | 09:30 |
hansfbaier | stekern: How do I get a sane .config? | 09:37 |
hansfbaier | Supply yours? | 09:38 |
hansfbaier | I tried cp arch/arm/configs/socfpga_defconfig .config | 09:38 |
stekern | make socfpga_defconfig | 09:38 |
hansfbaier | But on make it started asking myriads of questions, so that defconfig seems to be out of date, or am I missing something here? | 09:38 |
hansfbaier | stekern: ah | 09:38 |
hansfbaier | thanks | 09:38 |
hansfbaier | stekern: still need to set CROSS_COMPILE, right? | 09:39 |
stekern | perhaps, or at least ARCH | 09:40 |
stekern | or then not... I can't remember | 09:40 |
hansfbaier | stekern: I get compile errors if I don't | 09:43 |
hansfbaier | stekern: it works when I do. | 09:43 |
hansfbaier | stekern: Where do I get the dts, now, (forgot) use the one from the kernel tree? | 09:46 |
hansfbaier | arch/arm/boot/dts/socfpga_cyclone5.dts | 09:47 |
hansfbaier | I probably could leave it as it is, since there was no further modification (as opposed to the ocfb...) | 09:47 |
hansfbaier | where I needed it | 09:48 |
stekern | yes, you just need to compile the dtb | 09:55 |
stekern | with make dtbs | 09:56 |
hansfbaier | stekern: Isn't that done automatically, when compiling the kernel? the dtbs are already there... | 10:12 |
hansfbaier | _franck_: pushed new version. Now you should come until sd card image with custom kernel | 10:35 |
hansfbaier | https://github.com/hansfbaier/openrisc-sockit-tutorial/blob/master/openrisc-sockit-tutorial.pdf | 10:36 |
hansfbaier | stekern: I'm not so shure about the last mkpimage, but it seems to work for me, that's what I grepped out of my history ^ | 10:38 |
Powermaniac | Anyone in here happen to know how to program in Python? | 10:50 |
olofk_ | Have you seen the Kickstarter campaign for an LGPL GPU? http://www.kickstarter.com/projects/725991125/open-source-graphics-processor-gpu | 11:13 |
olofk_ | Looks like they listened to my advice that they should provide a Wishbone interface. I didn't say that they should do it for $600000 though :) | 11:14 |
Powermaniac | olofk_: No I had not until now. Damn 200,000 goal, rewards better be nice. | 11:16 |
olofk_ | But I don't think they're gonna make it. Should have offered a dev board or something as a backer reward. You don't get a shit for the money unless you pay $5000 in which case you will get one of them to fly over and run their design in modelsim. Not very tempting | 11:18 |
olofk_ | Well, best of luck to them | 11:19 |
Powermaniac | Yeah... | 11:19 |
stekern | you get an usb stick though | 11:21 |
Powermaniac | Wow, I'm just frustrating myself by being stubborn and not giving in till I manage to do it (it being make a simple program that runs the Fibonacci sequence and gives you the result of the nth term the user input) | 11:28 |
stekern | but I agree with you olofk_, you only pay for it to be done. | 11:33 |
stekern | which in itself isn't so bad, but probably not enough for people to really get hooked | 11:34 |
Powermaniac | Exactly | 11:34 |
stekern | I think that was part of what made parallella successfull, even if you weren't sure how devoted you'd be to the actual epiphany cpu, you'd still get a pretty darn good devboard anyway | 11:36 |
olofk_ | stekern: Exactly. They asked for ideas on Phoronix a while ago, and I gave them Parallella as an example. People like to get something physical (other than a USB stick) | 11:40 |
olofk_ | They are basically selling the IP rights now | 11:41 |
stekern | mmm, so the only ones that will be mostly interested in that kind of deal is parties with commercial interest, not end users. And I get a feeling that a large amount of kickstart backers are exactly that, end users. | 11:43 |
olofk_ | Haha. I refreshed the backer page. It first said three backer/$325, and then it flashed and went back to 2 backers/$100 :) | 11:43 |
knz | I think the guy is not presenting very well | 11:44 |
knz | it looks more like a hobby project than a visionary project | 11:44 |
knz | (good afternoon all) | 11:44 |
stekern | afternoon knz | 11:45 |
Powermaniac | good afternoon | 11:45 |
olofk_ | They could at least have presented the option to get a off-the-shelf board with PCIX or something with a preprogrammed FPGA | 11:45 |
olofk_ | hi knz | 11:45 |
knz | btw I'm giving a talk on openrisc this afternoon | 11:45 |
knz | stekern tech check: the only difference between espresso and pronto espresso is the delay slot, right? | 11:45 |
olofk_ | knz: Wow. That's great. Can we see it, or the slides somewhere? Always interesting to see these kind of things | 11:46 |
knz | no prob | 11:46 |
knz | hold on | 11:46 |
knz | https://dl.dropboxusercontent.com/u/7199534/20131009-openrisc.pdf | 11:47 |
knz | I will provide a more "permanent" link later | 11:47 |
stekern | knz: yes, the only difference between espresso and pronto is the delay slot, as far as I know at least. | 11:48 |
knz | excellent thanks | 11:48 |
stekern | they are juliusb's babies, so he might want to fill in, but that's the main thing at least | 11:49 |
olofk_ | knz: oohh... I love your template. Haven't started reading though :) | 11:50 |
knz | thx | 11:50 |
knz | olofk_: standard keynote template | 11:50 |
olofk_ | We Linux guys are starved for eye candy :( | 11:51 |
stekern | my first thought too ;) | 11:51 |
knz | :) | 11:51 |
stekern | what's mgsim? | 11:52 |
knz | OSX in virtualbox / qemu | 11:52 |
knz | oh | 11:52 |
knz | no | 11:52 |
knz | I was answering olof's comment | 11:52 |
knz | for eye cand on linux, run osx and keynote in virtualbox :) | 11:52 |
knz | mgsim is our simulation framework | 11:52 |
stekern | ah, ok | 11:53 |
knz | it's for system design space exploiration of many-core systems and custom cache protocols for large shared memory systems | 11:53 |
knz | but the flagship item is our own custom core micro-arch :) | 11:53 |
knz | more news at orconf 2014 | 11:53 |
olofk_ | knz: That's a really nice introduction to OpenRISC. A few number that could be corrected (like mainline Linux was in 3.1, not 3.8), but no biggies | 11:55 |
knz | ah thx | 11:55 |
knz | will fix straight away | 11:55 |
olofk_ | knz: I love that you are already planning a presentation for orconf2014. That's the spirit! | 11:56 |
stekern | and we're not going mainline gcc for 4.9 | 11:56 |
knz | of course | 11:56 |
knz | stekern: I thought that's what joern was saying | 11:57 |
olofk_ | knz: We discussed it in more detail last year. The big issue is that FSF require us to give them ownership of the code, and there are many contributors that need to be tracked down for that | 11:58 |
stekern | hmm, maybe he was speaking about something else | 11:58 |
knz | aha | 11:58 |
knz | ok | 11:58 |
stekern | knz: I think poke53282 would prefer this link to his jor1k simulator: http://s-macke.github.io/jor1k/ | 11:58 |
olofk_ | And at least one of them might refuse which makes it complicated because we have to find out which parts to rewrite then | 11:58 |
knz | ok | 11:58 |
knz | stekern: thx | 11:59 |
knz | ok time for my talk | 11:59 |
knz | ttyl | 11:59 |
stekern | cya | 11:59 |
olofk_ | Break a leg | 11:59 |
Powermaniac | Is that to do with the non-sense about how the FSF has certain terms you have to abide with to get on there officially open source list or whatever the non-sense is? | 11:59 |
Powermaniac | Bye knz! | 11:59 |
Powermaniac | Sorry I was referring to this: "knz: We discussed it in more detail last year. The big issue is that FSF require us to give them ownership of the code, and there are many contributors that need to be tracked down for that" | 12:08 |
stekern | for FSF to accept code into mainline gcc, they require that copyrights are re-assigned to them | 12:12 |
Powermaniac | Yeah that is kind of ridiculous... | 12:12 |
stekern | so, you'll need permission from all copyright holders to do that | 12:13 |
Powermaniac | Well, I'm not bothered by the second part as much as I am the first. | 12:13 |
stekern | well, without the first, the second wouldn't be a problem :) | 12:14 |
Powermaniac | Seems rather silly, as like if the work is open source anyway they don't need the rights assigned to them... | 12:14 |
stekern | I tend to agree, projects seem to survive without enforcing such rules... | 12:15 |
stekern | https://www.gnu.org/licenses/why-assign.html | 12:20 |
stekern | lays out the reasoning behind it | 12:20 |
Powermaniac | Hmm | 12:29 |
ams | Powermaniac: the FSF has no open source list | 12:29 |
Powermaniac | ams: ? | 12:30 |
ams | Powermaniac: the FSF does free software, open source is something different. | 12:31 |
Powermaniac | ams: I'm pretty sure they mean free as in freedom not free as in it costs nothing... | 12:31 |
ams | Powermaniac: yes, and we call it "free software" | 12:32 |
ams | Powermaniac: open source is a different movement with different goals | 12:32 |
Powermaniac | ams: Hmm okay then | 12:32 |
ams | http://www.gnu.org/philosophy/free-sw.html | 12:32 |
ams | Powermaniac: the reason for copyright assignments is so one can enforce the license, if you have 1000 licenseors then you need to track them down when going to court or whatever | 12:33 |
Powermaniac | ams: Ahh right the free-sw defined by RMS | 12:33 |
ams | Powermaniac: no, free software as defined by the GNU project adn the FSF. | 12:33 |
stekern | ams: sure, I understand the reasoning behind it. but in practice, do projects that doesn't enforce this rule have this problem? | 12:36 |
ams | stekern: busybox had this problem, linux had it as well, and now requires something similar to copyright assignments | 12:36 |
stekern | you are referring to the signed-off? | 12:37 |
ams | yes | 12:38 |
stekern | yeah, but isn't that more of a protection the other way? | 12:38 |
ams | it is basically a "copyright assignment" where by "signing off" you agree to some terms | 12:38 |
ams | stekern: hm? | 12:39 |
ams | The sign-off is a simple line at the end of the explanation for the | 12:39 |
ams | patch, which certifies that you wrote it or otherwise have the right to | 12:39 |
ams | pass it on as an open-source patch. | 12:39 |
ams | blech ,sorry ... | 12:39 |
stekern | you promise that the code you submit (or at least it's on your neck if it's not) is entitled to be released under the license conditions the kernel rules under | 12:40 |
ams | stekern: yup, which is also what the fsf copyright assignment has in its terms... it is more of a contract as well. | 12:40 |
stekern | so no-one can come and say "that's our code, it wasn't intended to be released under GPL" | 12:41 |
ams | stekern: yeah, linus was short sigted as usual.. the signed off isn't as strong as what the FSF does, or mozilla, apache etc .. | 12:41 |
stekern | yes, but the point made in the link I posted was to ensure that if anyone takes the code from the FSF project, FSF can take legal actions against the offender. | 12:42 |
ams | stekern: it kinda protects linus/linux from idiots like SCO but nothing else | 12:42 |
stekern | I don't think it was out of short-sightnedness, but rather out of purpose | 12:43 |
ams | (it also allows linux&linus to in theory make the code non-free software ...) | 12:43 |
stekern | I don't think he cares about it being "strong" in that sense | 12:43 |
ams | shurg, linus doesn't care about freedom. | 12:44 |
ams | anyway ... sorry, offtopic i guess this is.. | 12:44 |
stekern | nah, I believe it's in scope of this channel :) | 12:45 |
Powermaniac | Ha, I see what you did there | 12:45 |
ams | i don't think that hunting down all the copyright holders should be to hard | 12:45 |
Powermaniac | Linux can make Linux non-free heh. News to me | 12:45 |
Powermaniac | Linus* | 12:45 |
Powermaniac | Although a lot of this stuff is news to me anyway... | 12:46 |
stekern | but freedom is always relative, personally I prefer to give away my code with the freedom for people to do whatever they want with it | 12:46 |
stekern | but that's just me, of course if I contribute to a project with another agenda, I follow their wishes | 12:47 |
Powermaniac | stekern: Just if you could actually make decent money doing that...=\ | 12:47 |
stekern | companies seem to contribute back to projects for other reasons than just the license nowadays anyway, they see the beneficial of having their code being co-maintained by the communities | 12:51 |
stekern | s/beneficial/benefits | 12:53 |
olofk_ | Gaisler is a prime example of this with their dual-licensed Leon core. Individuals and universities use the GPL version and feed back fixes, but they know that no commercial ASIC (or FPGA) wants to touched by GPL code, so they sell them a commercial license for a lot of money | 12:56 |
olofk_ | The price was raised quite recently (rumour alert!), which is one reason why the space industry is looking towards OpenRISC for example | 12:57 |
Powermaniac | Oh really | 12:57 |
Powermaniac | Hmm | 12:57 |
knz | well not only that | 13:01 |
knz | gaisler has changed management | 13:01 |
knz | and the new sales guys are long-toothed pricks | 13:01 |
Powermaniac | Hi again knz, how did it go/ | 13:01 |
Powermaniac | ?* | 13:01 |
knz | (I worked with gaisler on a previous EU-funded project) | 13:02 |
Powermaniac | knz: I feel even luckier now that I've heard that, as I found this community instead. | 13:02 |
knz | plus | 13:03 |
knz | the SPARC ISA | 13:03 |
knz | seriously, guy | 13:03 |
knz | guys | 13:03 |
knz | it can't get more 80s than that | 13:03 |
knz | sparc register windows, OMG how I hate them | 13:03 |
knz | and the double loads and stores | 13:03 |
Powermaniac | Do you mean like the OpenSPARC T1? | 13:04 |
olofk_ | :) | 13:06 |
olofk_ | Did you know that both the MicroBlaze and the Leon CPU are from Gothenburg, Sweden? | 13:07 |
olofk_ | There should be a lot of competent CPU guys here, but I haven't found any so far | 13:08 |
olofk_ | Or maybe they are still busy doing 80's CPU designs :) | 13:09 |
stekern | I didn't know microblaze (although now when you mention it, I think you've mentioned it before) | 13:10 |
olofk_ | stekern: I learned that myself quite recently from Elektroniikkalehti | 13:12 |
stekern | I think it says on the outdated page of Damjan Lampret that Xilinx considered openrisc before they went onto microblaze | 13:12 |
olofk_ | Ha. That's interesting | 13:13 |
stekern | I'm happy that they didn't | 13:13 |
stekern | make it happen | 13:13 |
olofk_ | I think Lattice was thinking about changing too, but with the renewed interest in lm32, I guess that they are happy to keep that | 13:13 |
stekern | was it really on elektroniikkalehti or on elektroniktidningen? | 13:15 |
olofk_ | stekern: Sorry. I should have changed the finnish of that sentence | 13:16 |
stekern | you are truly the master of puns ;) | 13:17 |
olofk_ | Happy to be of service :) | 13:17 |
stekern | I try and try, even in my presentation, but I'll never get to the high grounds you are at ;) | 13:17 |
olofk_ | I think you're a natural. | 13:18 |
ams | olofk_: competent people in gothenburg_ | 13:19 |
ams | you moved to the wrong town ... everyone is called Ada and Glenn and have bad jokes. | 13:19 |
olofk_ | Amen that | 13:20 |
stekern | http://www.etn.se/index.php?option=com_content&view=article&id=55605&via=s | 13:21 |
olofk_ | stekern: Yeah, Mr. Bilski didn't like my OpenRISC comment :) | 13:23 |
stekern | I heard the real master of puns on finnish-swedish radio though, they were discussing why paralympics wasn't more receiving more attention, then this guy burst out in finnish-swedsih accent "Ja, men det är ju para lympics" | 13:29 |
stekern | (sorry all non-swedish speakers about that) | 13:30 |
olofk_ | haha. Was that intentional? :) | 13:33 |
stekern | I believe so ;) | 13:34 |
stekern | there was a pause between the words | 13:35 |
knz | hi again | 13:40 |
knz | I got some interesting questions after my talk | 13:41 |
knz | one of which was: what protection is there against people accidentally implementing openrisc using patented micro-architectural features? | 13:41 |
ams | knz: First rule of fight^Wpatent club, do not talk about fight^Wpatent club. | 13:43 |
olofk_ | knz: Interesting question that indicates that people were awake during your talk :) . None, I would say. | 13:43 |
knz | :) | 13:43 |
olofk_ | We have been worried about threading on ARMs patents when we want to implement 16b operations | 13:43 |
knz | my answer was 1) not enough money in the pocket of openrisc users to invest in litigation and 2) openrisc contributors don't care about that | 13:44 |
olofk_ | One thing though, is that Flextronics (who invested heavily in OpenRISC up tto 2005) had lawyers that went through the license, and I guess that the code was analyzed too at that point | 13:44 |
knz | "the code" | 13:45 |
knz | which code? | 13:45 |
knz | or1200? | 13:45 |
olofk_ | yes | 13:45 |
olofk_ | And the peripherals they used. Which is mostly the same we use now | 13:45 |
knz | ok | 13:45 |
olofk_ | I don't think there is any trouble with the current or1200 since Samsung and Allwinner would have been easy targets in that case | 13:45 |
olofk_ | But it's uncharted territory | 13:46 |
knz | ok but the quesytion I received was more targeting mor1kx :) | 13:46 |
olofk_ | And the license/patent discussions have been more active recently. juliusb invented his own license for mor1kx | 13:46 |
knz | yeah I saw that | 13:46 |
olofk_ | license != patents, I know | 13:47 |
ams | i suspect it is as it is with software ... | 13:47 |
ams | "don't read patents, and hope for the best" | 13:47 |
olofk_ | But as you say, I don't think it's a problem in reality with individuals hacking together new stuff | 13:47 |
knz | ok | 13:48 |
knz | another thing I discussed with colleagues: the mmu spec is waaaay too complicated | 13:48 |
olofk_ | :) | 13:48 |
olofk_ | Something for or2k perhaps? :) | 13:48 |
knz | BUT, the idea to prefix virtual addresses with a CID is excellent | 13:48 |
knz | or2k won't have a mmu afaik | 13:49 |
knz | or so I've understood during the last orconf discussion | 13:49 |
stekern | ams: I think that summarize it pretty well, we try to avoid widely known patents, but we don't go out of our ways to find any we don't know about | 13:49 |
olofk_ | or2k is a floating target. It's vaporware right now, so I think it's unfair to say it won't include a mmu | 13:49 |
stekern | knz: the MMU chapter is a big mess in the spec... | 13:49 |
knz | stekern: yes :) | 13:49 |
olofk_ | stekern: Is that fixable with minor changes to the spec and code, or are we doomed? | 13:50 |
knz | olofk_: I think you could replace the part of the spec entirely | 13:50 |
knz | even if you were to redesign the ISA you could "bake in" backward compatibility via exceptions | 13:50 |
knz | the idea that exceptions disable MMU translation is also excellent by the way | 13:50 |
stekern | I really would want to clean it up and bring in changes concluded in this ML thread: http://lists.openrisc.net/pipermail/openrisc/2013-July/001810.html | 13:51 |
knz | it reads like a simplification but I'm no expert enough to judge | 13:53 |
stekern | olofk_: I think the changes are relatively modest, at least if you look at it with the attitude that it currently contains a lot of cruft that no-one use and likely no-one will ever use it | 13:55 |
knz | speaking about cruft... | 13:56 |
knz | ORVDX64: hmmm....? | 13:56 |
stekern | well, vector instructions could be interesting, but I don't think anyone reviewed them. I can certainly not comment if they make any sense at all | 13:59 |
stekern | compiler research seems to be directed toward that alot at the moment at least, so for that it could be useful. | 14:00 |
knz | I'm not sure how good it is to make a spec beffore anyone cares to think about an implementation | 14:01 |
olofk_ | knz: Got a spare student you can chain to computer and implement that part? | 14:01 |
stekern | perhaps that kind of researcher would have preferred it not been defined though... | 14:01 |
knz | yes :) | 14:02 |
olofk_ | knz: No, I think you're right, and I guess that's part of the agile movement. Don't invent things you're not going to use | 14:02 |
knz | precisely | 14:02 |
knz | th good part is to use the same registers in the ISA | 14:02 |
knz | but of course that precludes multi-word 32-bit and 64-bit FP | 14:02 |
knz | seriously the VDX right now seems specialized towards sound and graphics | 14:03 |
knz | oh well | 14:04 |
olofk_ | I'm off | 14:23 |
Amadiro | I haven't been following along very closely lately, has the ORPSoC or some other form of or1k made it into ASIC form that you can buy yet? | 14:46 |
Amadiro | Hm, wikipedia lists some instances, but nothing for general availability | 14:48 |
knz | Amadiro: the "AS" part of ASIC stands for application-specific. Chances are that commodity products you use daily contain some openrisc stuff in them but that you will never know, nor meant to know. | 15:14 |
Amadiro | knz, right. I was thinking something in the form of an eval board or somesuch, that the end-user can program. | 15:15 |
knz | what you probably mean is, is there any dedicated silicon for an openrisc-based processor | 15:15 |
knz | then the answer is, not for end-users I believe | 15:15 |
Amadiro | Allright. | 15:16 |
knz | but the reason is more that it's not the primary intended goal of the openrisc project, than that it is not possible | 15:16 |
knz | :) | 15:16 |
knz | custom silicon means10k upfront investment (at least), sometimes north of 50k | 15:17 |
knz | it's a bit tough investment for a platform that changes over time :) | 15:17 |
knz | but who know, with kickstarter nowadays anything is possible | 15:17 |
Amadiro | Yeah, I realize that. Thought someone may have done it anyway, for some sort of embedded SoC, maybe a high-end microcontroller, something like that. | 15:18 |
Amadiro | Something end-user programmable, at any rate | 15:18 |
knz | I think NXP or Allwinner have standalone chips | 15:18 |
knz | you can uy on catlogue | 15:18 |
knz | maybe not in small quantities though | 15:19 |
Amadiro | Can't find anything immediately, but I'll look around, thanks. | 15:21 |
--- Log closed Thu Oct 10 00:00:33 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!