| axxlq1 | is there in your plans creation of dual core processor? | 10:30 |
|---|---|---|
| jonibo | why stop at two cores? | 10:31 |
| jonibo | i know some people having been looking into it... | 10:31 |
| axxlq1 | successfully? | 10:33 |
| Lampus|2 | Seems I saw in adv_dbg_if support for two CPUs | 11:24 |
| axxlq1 | Am I alone came up with this idea? Or the task extremely complex? | 11:30 |
| jonibo | not successfully | 11:31 |
| jonibo | it's probably trickier than it sounds... | 11:31 |
| jonibo | but i'm not an expert | 11:31 |
| axxlq1 | i'm too, unfortunately... | 11:47 |
| Lampus|2 | stekern: preliminary version of my .gitignore file: https://raw.github.com/Lampus/orpsoc/de0_support/.gitignore . It removes some noise in git status output | 11:59 |
| Lampus|2 | *from | 11:59 |
| stekern | Lampus|2: looks good | 12:36 |
| juliusb | in RTL, you've not got many issues of laying down n OR1200 cores, the infrastructure on top of it plus architectural shortcomings are what would stop you | 13:12 |
| juliusb | infrastructure (debug) and architectural shortcomings (lack of appropriate synchronisation hw for safe inter-CPU comms) shouldn't be that hard to overcome | 13:13 |
| juliusb | you can solve debugability by just hacking on rudamentary multi-CPU support | 13:13 |
| juliusb | (into both debug RTL and proxy software) | 13:13 |
| juliusb | as far as what GDB can handle, I've no clue, but whatever, probably you could just attach two GDB sessions or something | 13:14 |
| juliusb | in terms of safe inter-CPU comms, you could just have some memory mapped hardware semaphore thing | 13:14 |
| juliusb | it's a hack, but it'd work | 13:14 |
| juliusb | and is something that should be addressed in or2k | 13:14 |
| juliusb | but, I'm talking through my hat a little bit here, as I've never done it, but those appear to me to be the things you'd need to do to get multiprocessor OR1200 going | 13:15 |
| juliusb | so, in summary it's doable, but until there's some nice way of doing inter-CPU comms, your implementations are going to be hacks and trying to get something like SMP Linux running will be a hassle - it'd be better suited for some sort of bare-metal multi-processor software | 13:17 |
| juliusb | oh, cache coherency, too, is something that I believe is not well covered by the or1k spec | 13:17 |
| juliusb | you'd have to do it all in hardware, making implementation trickier | 13:17 |
| juliusb | and to have any decent performance, you'll probably want an L2 cache | 13:18 |
| juliusb | (maybe scrap L1 and have L2 only - sidestep your cache coherency issues a little bit - sacrifice a bit of performance for ease of implementation) | 13:18 |
| juliusb | it'd be a fun project, though | 13:19 |
| juliusb | I recall that wallento guy in #opencores was talking a bit about it | 13:19 |
| juliusb | oh I've just realised that axxlq1 bloke isn't here anymore hehe | 13:20 |
| Lampus|2 | stekern: Why do you use legacy_dbg_if instead adv_dbg_if? | 13:24 |
| stekern | because that is the standard debug sys in orpsocv2 | 13:25 |
| Lampus|2 | Ok | 13:26 |
| Lampus|2 | What basic difference between them? | 13:26 |
| stekern | no one seems to get adv_dbg_if to work reliably on altera fpgas without commenting out the CRC checking code | 13:26 |
| Lampus|2 | =) | 13:27 |
| Lampus|2 | I have problems with CRC now | 13:27 |
| Lampus|2 | And self-test looks very strange: http://pastebin.com/tzPiFygx | 13:28 |
| stekern | the difference is: the legacy debug if needs a seperate external jtag connection | 13:29 |
| Lampus|2 | Bad =\ | 13:30 |
| Lampus|2 | I have only built-in Altera USB Blaster | 13:30 |
| Lampus|2 | What I can do with this problem without external jtag? | 13:31 |
| Lampus|2 | Hm. But seems that with minsoc adv_jtag_if works fine | 13:41 |
| pgavin | well | 13:58 |
| pgavin | I didn't expect quite that response | 13:58 |
| pgavin | lol | 13:58 |
| jonibo | :) | 14:07 |
| jonibo | pgavin: so, I spent some time looking at your work... since it's in git, it's easy to work with! ;) | 14:09 |
| jonibo | couple of things I'm not convinced about | 14:09 |
| jonibo | renaming the openrisc arch to or1k in Linux is not the way to go | 14:09 |
| jonibo | the cpu family is openrisc, the specific cpu is or1k | 14:09 |
| pgavin | jonibo: | 14:10 |
| jonibo | the Linux arch is more about the family than the specific implementation | 14:10 |
| pgavin | jonibo: ok | 14:10 |
| pgavin | I wasn't sure, and was trying to be consistent | 14:10 |
| jonibo | yup, all good | 14:10 |
| jonibo | i'd actually hoped we could do an ABI change and keep or32 for the old ABI and or1k for the new one... | 14:11 |
| jonibo | ...it would have been nice to group call-clobbered and call-saved registers | 14:11 |
| jonibo | but, that's not so important | 14:12 |
| pgavin | I tried keeping it ABI compatible whenever I had to change something that might effect it | 14:12 |
| pgavin | but I agree there are a few warts that this would be a good time to fix | 14:12 |
| jonibo | yeah, if they could be fixed around the name change, then it would be possible to keep both arch ABI's around | 14:19 |
| jonibo | it's still not too late, actually | 14:19 |
| jonibo | something to consider | 14:20 |
| juliusb | jonibo: yeah, that sounds like a good idea actually | 14:58 |
| juliusb | (call clobbered thing) | 14:58 |
| Lampus|2 | stekern: I have disabled CRC checking in adv_jtag_bridge, so now I can successfully load program. But I can't continue execution after breakpoint | 15:09 |
| Lampus|2 | But seems that program works properly before breakpoint | 15:10 |
| jonibo | pgavin: i was just looking into the svn compatibility of github and it seems that it requires that there be a 'master' branch in the git repository | 15:40 |
| pgavin | jonibo: hmm | 15:40 |
| pgavin | well I think we're going to redo the repo anyway | 15:41 |
| jonibo | how so? | 15:41 |
| pgavin | we're talking about it in #opencores right now | 15:41 |
| jonibo | oh | 15:41 |
| jonibo | isn't the toolchain an openrisc thing... should discuss in this channel??? | 15:42 |
| pgavin | but, I think I'm going to cvs checkout the sourceware.org/src repo and then version control the whole thing with git | 15:42 |
| pgavin | yes, probably it should be here | 15:43 |
| pgavin | somehow it ended up in there lol | 15:43 |
| jonibo | cvs checkout? | 15:43 |
| pgavin | yeah, because binutils/cgen/gdb are all under one cvs source tree | 15:44 |
| pgavin | :pserver:anoncvs@sourceware.org:/cvs/src | 15:44 |
| jonibo | i'd be inclined to just follow some of the existing mirrors... redhat already mirrors binutils to git, e.g. | 15:46 |
| jonibo | that way you're less likely to lose history | 15:46 |
| jonibo | but it's all the same | 15:46 |
| jonibo | github's the way to go, imo | 15:48 |
| pgavin | jonibo: the problem is that there's a lot of shared code | 15:48 |
| pgavin | like, the cgen tree specifically | 15:49 |
| pgavin | and also getting changes put into the upstream will be easier if cvs is available | 15:49 |
| jonibo | no, actually it doesn't matter | 15:49 |
| jonibo | upstream wants a patch from you, not a cvs repository | 15:49 |
| jonibo | it's actually easier to generate that patch with git | 15:49 |
| jonibo | i don't buy the "same vcs" argument that some people spew | 15:50 |
| pgavin | hmm, good point | 15:51 |
| pgavin | but keeping the whole src tree is a good idea imo | 15:52 |
| jonibo | unified source, you mean? | 15:52 |
| pgavin | so the shared files don't have to be copied between repos | 15:52 |
| jonibo | what shared files? | 15:52 |
| pgavin | the cgen files | 15:52 |
| jonibo | i thought the idea was that you checked out cgen into a subdirectory under binutils and then built??? | 15:53 |
| pgavin | the upstream keeps a repo that has cgen, binutils, gdb etc. subdirectories | 15:53 |
| pgavin | it's all one repo | 15:53 |
| jonibo | that they have to sync regularly from the subprojects... | 15:54 |
| pgavin | no | 15:54 |
| jonibo | ...because they are actually separate projects | 15:54 |
| jonibo | no? | 15:54 |
| pgavin | it's all one project | 15:54 |
| jonibo | ok | 15:54 |
| jonibo | fair enough | 15:54 |
| jonibo | then I don't know what we're discussing. :) | 15:54 |
| pgavin | bfd is shared too | 15:54 |
| jonibo | bfd is part of binutils | 15:54 |
| pgavin | http://sourceware.org/cgi-bin/cvsweb.cgi/src/?cvsroot=src | 15:55 |
| pgavin | it's also used by gdb | 15:55 |
| jonibo | gdb just needs to be able to find libbfd when you build | 15:55 |
| jonibo | I build those two components separately all the time | 15:55 |
| pgavin | right, but they're developed in the same tree | 15:55 |
| jonibo | yes | 15:56 |
| jonibo | err... gdb, too? | 15:56 |
| pgavin | yeah | 15:56 |
| jonibo | ok | 15:56 |
| pgavin | apparently gcc used to be in there too | 15:56 |
| pgavin | a long time ago | 15:56 |
| jonibo | yeah, I know | 15:56 |
| jonibo | it's not anymore | 15:56 |
| pgavin | thank god | 15:56 |
| jonibo | anyway, just keep it sane | 15:59 |
| jonibo | the way it is in svn breaks just about every build system around | 15:59 |
| jonibo | think debian, openembedded, openwrt, etc.... | 16:00 |
| jonibo | some of us actually try to do real work with the stuff and currently only the git repos are really usable for that | 16:00 |
| jonibo | hope you can get that all straightened out | 16:00 |
| juliusb | yeah there's a fair bit of crap that gets duplicated around the shop and is one of the reasons why our gdb port is a bit broken at the moment - it was using an older bfd than our binutils build and they got a bit out of step (someone fixing binutils bfd but not doing the same for gdb's and then ensuring gdb still built) so for that reason unified source tree makes sense | 16:05 |
| juliusb | jonibo: what do you mean by the way it is in svn breaks other build systems? | 16:06 |
| juliusb | pgavin: btw, welcome to the community haha - this was/is a bit of a sticking point for the community last year and you've successfully triggered another salvo from all sides hehe. I would just do whatever makes you most productive in your work and if one party gets their jollies having it in one repo or another and you have time then it's nice if you can help them out, otherwise I'd focus on doing the work and not on sc | 16:12 |
| juliusb | this is my approach now (hence i've started doing stuff with github) | 16:12 |
| juliusb | ideally we release to opencores because it's probably the first place a lot of people look | 16:13 |
| stekern | yeah, I second that approach | 16:13 |
| jonibo | thirded | 16:13 |
| juliusb | but other than releases, the dev tree could live anywhere imho. it's not that hard to post to the mailing list if a newcomer is confused about where the action is (although it would be nice to chuck it on wiki) | 16:16 |
| juliusb | but again, it's up to you if you can find the time and effort to chuck it on opencores | 16:17 |
| juliusb | man speaking of releasing things | 16:18 |
| juliusb | wtf is going on with the CPU work i've been doing with stekern | 16:18 |
| juliusb | my bloody company haven't said boo to me about it for a little while, I'll think I'll investigate | 16:18 |
| jonibo | the problem that I see with the way it's done today is that you take a nice series of patches that get squashed together into an unintelligible mess that toss out all authorship information and includes a boatload of irrelevant autoconf changes and that's what gets pushed to svn | 16:19 |
| jonibo | and then you're supposed to try to figure out how to sync that with the "other" work you've been doing... | 16:19 |
| juliusb | when things get pushed to svn you mean? | 16:19 |
| jonibo | yes | 16:19 |
| juliusb | yeah, that is annoying, but you could replay the patches into SVN too | 16:20 |
| jonibo | that would be better | 16:20 |
| juliusb | i think there's something that can do that | 16:20 |
| juliusb | git-svn apparently | 16:21 |
| jonibo | git-svn does that | 16:21 |
| stekern | I think the "git-like" workflow that has started to build around orpsocv2 is almost acceptable | 16:21 |
| jonibo | yeah... agreed. that's what's needed for the toolchain | 16:21 |
| jonibo | but that requires discipline amongst the maintainers | 16:21 |
| jonibo | and there's your issue in a nutshell | 16:21 |
| juliusb | yeah i've been pretty shit for a long while, but getting better hehe | 16:22 |
| jonibo | i like rdiez's github suggestions... their svn support is pretty nice | 16:22 |
| jonibo | should make everybody happy | 16:22 |
| jonibo | push and pull from svn or git, whatever you fancy | 16:22 |
| jonibo | and github has acceptable performance | 16:24 |
| jonibo | ...for svn checkouts, I mean | 16:24 |
| juliusb | yeah why the opencores guys maintain their own public repo system is beyond me - they should have piggy-backed off sourceforge a long time ago | 16:24 |
| jonibo | get them to buy github support | 16:24 |
| jonibo | set up the opencores repos there | 16:24 |
| jonibo | it's not even expensive | 16:26 |
| juliusb | yeah but it's a moot point because they'll say they want to be able to tell you which people of how many years experience in ASIC/FPGA have downloaded what core | 16:26 |
| juliusb | because apparently having those numbers is more important than providing stable, fast and easily accessible repositories | 16:26 |
| juliusb | but anyway, we've all had this whinge before :) | 16:27 |
| juliusb | let's not scare off pgavin :) | 16:28 |
| jonibo | i don't agree that that's relevant for toolchain | 16:40 |
| jonibo | sure, for IP cores... | 16:40 |
| jonibo | ...not for the openrisc software | 16:40 |
| jonibo | it's all bullshit number now anyway because so many people are getting there stuff from github/openrisc.net/aac/etc/etc | 16:40 |
| jonibo | https://github.com/plans | 16:41 |
| jonibo | couple of bucks per month for a working system | 16:41 |
| jonibo | could almost pay it myself :) | 16:41 |
| KeeWee1 | looks like the initial batch of 10,000 RPi has been sold out in less than 8 hours, do you think this could happen one day with an OpenRisc SoC ? | 20:39 |
| KeeWee1 | from where comes the magic of the price of the RPi ? the SoC of broadcom which is out-of-date ? or the assembly ? | 20:40 |
| KeeWee1 | if this is the assembly then I guess there is a viable option using TP-LINK who are very aggressive on price (such as the device WR703N at 20 euros MSRP very similar to an OpenRisc SOC or the RPi) | 20:41 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!