IRC logs for #openrisc Wednesday, 2012-02-29

axxlq1is there in your plans creation of dual core processor?10:30
jonibowhy stop at two cores?10:31
joniboi know some people having been looking into it...10:31
Lampus|2Seems I saw in adv_dbg_if support for two CPUs11:24
axxlq1Am I alone came up with this idea? Or the task extremely complex?11:30
jonibonot successfully11:31
joniboit's probably trickier than it sounds...11:31
jonibobut i'm not an expert11:31
axxlq1i'm too, unfortunately...11:47
Lampus|2stekern: preliminary version of my .gitignore file: . It removes some noise in git status output11:59
stekernLampus|2: looks good12:36
juliusbin 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 you13:12
juliusbinfrastructure (debug) and architectural shortcomings (lack of appropriate synchronisation hw for safe inter-CPU comms) shouldn't be that hard to overcome13:13
juliusbyou can solve debugability by just hacking on rudamentary multi-CPU support13:13
juliusb(into both debug RTL and proxy software)13:13
juliusbas far as what GDB can handle, I've no clue, but whatever, probably you could just attach two GDB sessions or something13:14
juliusbin terms of safe inter-CPU comms, you could just have some memory mapped hardware semaphore thing13:14
juliusbit's a hack, but it'd work13:14
juliusband is something that should be addressed in or2k13:14
juliusbbut, 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 going13:15
juliusbso, 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 software13:17
juliusboh, cache coherency, too, is something that I believe is not well covered by the or1k spec13:17
juliusbyou'd have to do it all in hardware, making implementation trickier13:17
juliusband to have any decent performance, you'll probably want an L2 cache13: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
juliusbit'd be a fun project, though13:19
juliusbI recall that wallento guy in #opencores was talking a bit about it13:19
juliusboh I've just realised that axxlq1 bloke isn't here anymore hehe13:20
Lampus|2stekern: Why do you use legacy_dbg_if instead adv_dbg_if?13:24
stekernbecause that is the standard debug sys in orpsocv213:25
Lampus|2What basic difference between them?13:26
stekernno one seems to get adv_dbg_if to work reliably on altera fpgas without commenting out the CRC checking code13:26
Lampus|2I have problems with CRC now13:27
Lampus|2And self-test looks very strange:
stekernthe difference is: the legacy debug if needs a seperate external jtag connection13:29
Lampus|2Bad =\13:30
Lampus|2I have only built-in Altera USB Blaster13:30
Lampus|2What I can do with this problem without external jtag?13:31
Lampus|2Hm. But seems that with minsoc adv_jtag_if works fine13:41
pgavinI didn't expect quite that response13:58
jonibopgavin: so, I spent some time looking at your work... since it's in git, it's easy to work with! ;)14:09
jonibocouple of things I'm not convinced about14:09
joniborenaming the openrisc arch to or1k in Linux is not the way to go14:09
jonibothe cpu family is openrisc, the specific cpu is or1k14:09
jonibothe Linux arch is more about the family than the specific implementation14:10
pgavinjonibo: ok14:10
pgavinI wasn't sure, and was trying to be consistent14:10
joniboyup, all good14:10
joniboi'd actually hoped we could do an ABI change and keep or32 for the old ABI and or1k for the new one...14:11 would have been nice to group call-clobbered and call-saved registers14:11
jonibobut, that's not so important14:12
pgavinI tried keeping it ABI compatible whenever I had to change something that might effect it14:12
pgavinbut I agree there are a few warts that this would be a good time to fix14:12
joniboyeah, if they could be fixed around the name change, then it would be possible to keep both arch ABI's around14:19
joniboit's still not too late, actually14:19
jonibosomething to consider14:20
juliusbjonibo: yeah, that sounds like a good idea actually14:58
juliusb(call clobbered thing)14:58
Lampus|2stekern: I have disabled CRC checking in adv_jtag_bridge, so now I can successfully load program. But I can't continue execution after breakpoint15:09
Lampus|2But seems that program works properly before breakpoint15:10
jonibopgavin: 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 repository15:40
pgavinjonibo: hmm15:40
pgavinwell I think we're going to redo the repo anyway15:41
jonibohow so?15:41
pgavinwe're talking about it in #opencores right now15:41
joniboisn't the toolchain an openrisc thing... should discuss in this channel???15:42
pgavinbut, I think I'm going to cvs checkout the repo and then version control the whole thing with git15:42
pgavinyes, probably it should be here15:43
pgavinsomehow it ended up in there lol15:43
jonibocvs checkout?15:43
pgavinyeah, because binutils/cgen/gdb are all under one cvs source tree15:44
joniboi'd be inclined to just follow some of the existing mirrors... redhat already mirrors binutils to git, e.g.15:46
jonibothat way you're less likely to lose history15:46
jonibobut it's all the same15:46
jonibogithub's the way to go, imo15:48
pgavinjonibo: the problem is that there's a lot of shared code15:48
pgavinlike, the cgen tree specifically15:49
pgavinand also getting changes put into the upstream will be easier if cvs is available15:49
jonibono, actually it doesn't matter15:49
joniboupstream wants a patch from you, not a cvs repository15:49
joniboit's actually easier to generate that patch with git15:49
joniboi don't buy the "same vcs" argument that some people spew15:50
pgavinhmm, good point15:51
pgavinbut keeping the whole src tree is a good idea imo15:52
jonibounified source, you mean?15:52
pgavinso the shared files don't have to be copied between repos15:52
jonibowhat shared files?15:52
pgavinthe cgen files15:52
joniboi thought the idea was that you checked out cgen into a subdirectory under binutils and then built???15:53
pgavinthe upstream keeps a repo that has cgen, binutils, gdb etc. subdirectories15:53
pgavinit's all one repo15:53
jonibothat they have to sync regularly from the subprojects...15:54
jonibo...because they are actually separate projects15:54
pgavinit's all one project15:54
jonibofair enough15:54
jonibothen I don't know what we're discussing. :)15:54
pgavinbfd is shared too15:54
jonibobfd is part of binutils15:54
pgavinit's also used by gdb15:55
jonibogdb just needs to be able to find libbfd when you build15:55
joniboI build those two components separately all the time15:55
pgavinright, but they're developed in the same tree15:55
joniboerr... gdb, too?15:56
pgavinapparently gcc used to be in there too15:56
pgavina long time ago15:56
joniboyeah, I know15:56
joniboit's not anymore15:56
pgavinthank god15:56
joniboanyway, just keep it sane15:59
jonibothe way it is in svn breaks just about every build system around15:59
jonibothink debian, openembedded, openwrt, etc....16:00
jonibosome of us actually try to do real work with the stuff and currently only the git repos are really usable for that16:00
jonibohope you can get that all straightened out16:00
juliusbyeah 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 sense16:05
juliusbjonibo: what do you mean by the way it is in svn breaks other build systems?16:06
juliusbpgavin: 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 sc16:12
juliusbthis is my approach now (hence i've started doing stuff with github)16:12
juliusbideally we release to opencores because it's probably the first place a lot of people look16:13
stekernyeah, I second that approach16:13
juliusbbut 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
juliusbbut again, it's up to you if you can find the time and effort to chuck it on opencores16:17
juliusbman speaking of releasing things16:18
juliusbwtf is going on with the CPU work i've been doing with stekern16:18
juliusbmy bloody company haven't said boo to me about it for a little while, I'll think I'll investigate16:18
jonibothe 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 svn16:19
joniboand then you're supposed to try to figure out how to sync that with the "other" work you've been doing...16:19
juliusbwhen things get pushed to svn you mean?16:19
juliusbyeah, that is annoying, but you could replay the patches into SVN too16:20
jonibothat would be better16:20
juliusbi think there's something that can do that16:20
juliusbgit-svn apparently16:21
jonibogit-svn does that16:21
stekernI think the "git-like" workflow that has started to build around orpsocv2 is almost acceptable16:21
joniboyeah... agreed.  that's what's needed for the toolchain16:21
jonibobut that requires discipline amongst the maintainers16:21
joniboand there's your issue in a nutshell16:21
juliusbyeah i've been pretty shit for a long while, but getting better hehe16:22
joniboi like rdiez's github suggestions... their svn support is pretty nice16:22
joniboshould make everybody happy16:22
jonibopush and pull from svn or git, whatever you fancy16:22
joniboand github has acceptable performance16:24
jonibo...for svn checkouts, I mean16:24
juliusbyeah why the opencores guys maintain their own public repo system is beyond me - they should have piggy-backed off sourceforge a long time ago16:24
joniboget them to buy github support16:24
joniboset up the opencores repos there16:24
joniboit's not even expensive16:26
juliusbyeah 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 core16:26
juliusbbecause apparently having those numbers is more important than providing stable, fast and easily accessible repositories16:26
juliusbbut anyway, we've all had this whinge before :)16:27
juliusblet's not scare off pgavin :)16:28
joniboi don't agree that that's relevant for toolchain16:40
jonibosure, for IP cores...16:40
jonibo...not for the openrisc software16:40
joniboit's all bullshit number now anyway because so many people are getting there stuff from github/
jonibocouple of bucks per month for a working system16:41
jonibocould almost pay it myself :)16:41
KeeWee1looks 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
KeeWee1from where comes the magic of the price of the RPi ? the SoC of broadcom which is out-of-date ? or the assembly ?20:40
KeeWee1if 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 2.15.2 by Marius Gedminas - find it at!