IRC logs for #openrisc Thursday, 2014-04-10

--- Log opened Thu Apr 10 00:00:58 2014
Limbwell.. progress somewhat01:02
Limbnow it times out halting the cpu01:02
Limbhttps://github.com/Limb/orpsoc-cores/tree/nexys4/systems/nexys4 If anyone can find any faults01:10
stekernolofk: perhaps, but that has it own set of problems. Now you depend on python, and need to got through the pain ensuring that it's compatible with several different python versions.02:34
stekern_franck_: you'll only get the prompt on the last console argument in your bootargs02:38
stekernLimb: how did you configure/start openocd?02:38
Limbstekern: sudo openocd -s ./tcl -f ./tcl/interface/ftdi/digilent-nexys4.cfg -f ./tcl/board/or1k_generic.cfg02:39
Limbhttp://pastebin.com/ZdR32tbU those are the configs02:41
stekernok, that seems like something that should work (although I'm no openocd expert)02:46
Limb!!!02:51
Limbmodified the files a bit and it says target ready \o/02:51
stekernnice!02:56
Limbmightve spoken too soon :(02:57
stekernmy l.lwa/l.swa additions to orksim at least seem to work so far, I can lock an address and the store succeeds with a result of a '1' in the source reg03:33
stekern...next, see if clearing the lock works03:34
_franck_Limb: http://opencores.org/forum,OpenRISC,0,535105:45
_franck_"Very strange but necessary is the IRLEN of 8 instead of 6 as described in "ise_14.6/14.6/ISE_DS/ISE/spartan6/data/xc6slx45_csg324.bds" boundary scan description file: "05:45
blueCmdstekern: nice!08:17
blueCmdstekern: atomicity <308:18
olofk_Does anyone have experience with running FPGA design tools on Mac OS X?08:20
olofk_Are they even supported?08:20
blueCmdolofk: only through VMw08:20
blueCmdVMs*08:20
blueCmdstekern: will you add support to GCC for the __atomic and __sync constructs?08:21
stekernblueCmd: eventually, yes I guess. still stuff to do before that though, like sending a mail to the mailing list with the suggestion of what I've implemented in or1ksim ;)09:04
stekern...then completing the binutils support, what I've put in there now works with the tools (as, bfd etc), but the cgen simulator will think they are normal l.sw/l.lwz'as09:05
stekernand then it'd be nice if we'd have at least one rtl implementation that support it before gcc09:06
stekernand I think we should have it in the arch spec before adding it for real to the tools/simulators/rtl implementations09:09
stekernactually adding it is of course not a big deal, it's just writing a bit of text ;)09:12
stekernthere are interesting discussions that could be had before that though, for instance, what should the granularity of the lock be?09:12
stekernright now, it's a word, but that's realtively easy to change. At least now, it might be more difficult when there are software that depends on that fact.09:14
stekernand another thing is the l.swa result, I took the mips approach and store it in the source reg. While that works, is it the best approach, all things considered?09:15
stekernblueCmd: ...but if you're eager to add the __atomic and __sync constructs yourself, be my guest ;)09:20
stekernI'm pretty confident that my or1ksim changes work now, it happily chews away at every test I can come up with for it.09:44
stekernhttp://pastie.org/9069988 <- that's the tests I currently have, something to add?09:44
olofk_Just curious, do we have any other instructions that stores result in it's source register?09:57
stekernno09:58
stekernthat was why it caused a bit of a headache in or1ksim09:58
stekernbut I think what I did to fix it was less a hack than fixing a defiency in the generator10:00
stekerns/defiency/deficiency10:00
stekernas for rtl implementations, taking the dest reg from an 'unexpected' field in the instruction is not a big problem. changing around source regs would be more problematic10:02
olofk_ok. I was mostly worried about the RTL implementation. Sounded like it could be a really awkward special case10:41
olofk_Does anyone know what buses Intel uses internally.10:42
blueCmdstekern: does it still need to be in kernelspace? surely no?10:44
blueCmdstekern: I'm thinking of why you are setting up syscalls10:45
stekernno, the syscall is just there because it's an convient way of inducing an exception in a controlled way10:48
stekernthe l.trap would work too, but it has the annoyance that you need to fiddle with the pc to skip the l.trap after l.rfe10:48
blueCmdah I see10:48
blueCmdsurely you have pasted some information on how the two instructions work - but I totally forgot10:49
blueCmdmind pasting again?10:49
stekernbecause, a reservation by a l.lwa should be cleared by context switches (exceptions), so that's what I'm testing10:49
stekernhmm, http://en.wikipedia.org/wiki/Load-link/store-conditional tells most I think10:50
stekernthis was what was in an old version of the arch spec: http://pastebin.com/bv3DNJ8s10:51
stekernthere's a lot missing from that text though, I basically just took the instruction names from it10:52
blueCmdI see, looks fine10:56
blueCmdstekern: am I reading the code correctly if I say that memory 0 contains the locked address?11:03
blueCmdi'm having trouble seeing how you know when swa fails11:04
stekernyes, I use memory location 0x0 for the tests11:05
stekernare you speaking about a particular test?11:06
blueCmdtest 511:07
blueCmdif you get an context swicth between l.swa and l.lwz so that 0(r0) is clobbered11:08
blueCmdwhat happens then?11:08
stekernumm, there are no context switches in test 511:08
stekerntest 5 checks that the content in r5 (0xdeadbeef) doesn't get written to 0(r0)11:09
blueCmdright, maybe that's part of the test fixture and not the implementation - I'm just thinking if I do an l.swa in user-space and the way to see if it succeeded is to read 0(r0) - that sounds like something that can break11:10
stekernah, no, that's just a test-property. I'm of course making assumptions that you can't do when there are a risk that you might be preemptied11:11
blueCmdok, fair enough11:11
stekernthe way to see if it succeeded is to check the destination register, so you still have a point11:12
stekernyou can of course be preemptied between the l.swa and that check, but that's OK11:13
blueCmdas long as the result is in a register and not in memory that should be OK11:14
stekernyes11:14
blueCmdbut you said destination reg. I'm having trouble seeing what is the destination and source in those. to me it would be l.swa I(dst), src11:15
stekerns/destination register/source register ;)11:15
stekernsorry11:16
blueCmdright thanks11:16
blueCmdso r5 in this case?11:16
stekernright11:16
blueCmdmakes sense11:16
blueCmdthanks11:16
blueCmdah, so that's what test 2 and 3 does.11:17
blueCmdneat11:17
stekernto sum it up, the things that can break a link is: a (normal) store to the linked address, a l.swa (to any arbitrary address), a second l.lwa (to another address) or a context switch11:24
stekern+ of course stores in multiprocessor environments, but that's hard to test within or1ksim ;)11:25
stekernthat's at least my understanding of how things should work11:26
blueCmdright11:27
blueCmdthis is all kept in an internal reg I guess?11:27
stekernyes, https://github.com/skristiansson/or1ksim/blob/3afc310f4e6c7aa50dd823ab36e2fb365a1a0de7/cpu/common/execute.h#L5711:36
olofk_stekern: Have you talked to Stefan Wallentowitz about this? Just thinking that he might have some real-world experience of multicore or1k with his OptimSoC.12:59
olofk_Because this is mainly for multicore, right?12:59
olofk_oh.. and multithread12:59
olofk_That's of coure a more common problem for us right now13:00
stekernolofk_: I'm planning on putting together a mail in the evening and send to the ml13:26
Limb_franck_: changing the irlen to 8 doesn't resolve the problem sadly :(14:32
_franck_web_too bad14:35
_franck_web_Limb: you could wire adv_dbg_if like this: https://github.com/fjullien/jtag_vpi/blob/master/bench/jtag_vpi_tb.v#L10514:39
_franck_web_and see if openocd can read/write from/to memory14:39
Limb_franck_web_:  still quits with error trying to halt processor with that config15:16
_franck_web_do you have `define ADBG_USE_HISPEED in adbg_defines.v ?15:20
LimbI don't have a adbg_defines15:21
_franck_web_oups15:22
Limb??15:23
_franck_web_Limb: are you using fusesoc ?15:24
Limbywa15:24
Limbyes*15:24
_franck_web_so you should have one: https://github.com/fjullien/orpsoc-cores/blob/master/cores/adv_debug_sys/adv_debug_sys.core#L2115:25
Limb_franck_web_: do you mean I personally should have it in my system core?15:26
Limbor its included with the adv_dbg core15:26
_franck_web_("oups" is a french interjection :))15:27
_franck_web_it is automatically included by adv_dbg core15:27
_franck_web_you should have it in build/$your_system/src/adv_dbg_core/rtl/verilog/15:28
Limbyes i see it15:29
olofkFucking debian. Some package update was interrupted and now I'm just getting strange errors15:30
olofk_franck_web_: I have an idea15:31
olofkYou need wb_bfm and vlog_tb_utils to test wb_alter_ddr_ctrl, and want it to be usable outside of fusesoc15:32
_franck_web_true15:33
olofkIf I move out wb_bfm and vlog_tb_utils to separate repos, then you could include them as git submodules if you want to run your test bench stand-alone15:33
olofkI realized a few days ago that we will come across this situation many times. In wb_sdram_ctrl I just added a README to tell the user that they need to download wb_bfm/vlog_tb_utils themselves, but that's not a really nice solution15:34
olofkAnd IIRC you added local copies in jtag_vpi instead15:34
_franck_web_I have a local copy of adv_debug_sys in jtag_vpi15:35
olofkah yes. That was the one I was thinking of15:36
olofkAnd in that case upstream is SVN15:36
_franck_web_but, wait a bit, I think I'll move my ddr wrapper to orpsoc-cores so there won't be any problem anymore15:36
_franck_web_(at least for me)15:36
_franck_web_I meant to orpsoc-cores/cores15:38
FindetonI want to run linux on openrisc, but I don't have a fpga17:48
Findetonso what do I need? do I need to install the toolchain or the ork1sim, or both?17:49
Findetonok18:00
olofkFindeton: There are a few different ways to run OpenRISC without hardware. or1ksim, qemu, jor1k18:00
Findetonit looks like I need both18:00
FindetonI mean with or1ksim18:00
olofkah ok18:01
olofkYou can get a pre-build linux image if you just want to try it out18:01
Findetonyeah I did18:02
Findetonbut I couldn't get to connect it to the internet18:02
Findetonso I'm doing it from scratch18:02
Findetonwhich is a good learning experience anyway18:03
olofkAh yes. Was it you who was running the VirtualBox VM and was having problems ith the brstart/brend scripts?18:03
Findetonyess18:09
Findetonso now I'm doing my own virtualbox VM :p18:10
olofkToo much going on in my head right now. That was only a few days ago we talked about this :)18:10
Findetondon't worry hehe18:10
Findetonbtw where are you from?18:10
olofkSweden18:10
Findetonoh18:11
FindetonI'm from Spain but I work in Luxembourg18:12
Findetonit must be a bit chilly in Sweden18:12
Findeton!18:12
olofkHell yeah. It's a fucking stupid place to live. Every winter I wonder what the hell I'm doing here18:12
Findetonhaha18:14
FindetonI don't know, perhaps I'd like to live there18:14
olofkIt's not half bad otherwise, but I tend to be a bit grumpy in the winter :)18:15
Findetonhaha18:15
Findetonwell how is the job market there for developers?18:15
olofkQuite good at the moment18:15
Findetonalso, I don't know swedish so..18:15
Findetonxd18:15
olofkI still can't update my orpsoc-cores repo18:21
olofkBut I can pull the fresh clone that I did yesterday18:24
olofkI tried git gc18:24
Limbolofk: what error does it give18:36
olofkLimb: It gets stuck somewhere in remote: Compressing objects18:38
olofkhttp://d51ece4f650346f4.paste.se18:41
Limbwhat version of got18:47
Limbgit*18:47
olofk1.8.3.218:55
olofkI wonder if I have compiled it or any of the underlying libs with some strange flags18:55
LimbGooglefu says network problems18:56
olofkYeah, but doing clone and pull from a fresh repo works fine18:56
Limbthough it might be worth upgrading to the latest version18:56
olofkBut that uses a different origin url18:56
olofkHave to experiment with that18:56
Limbtry http instead of ssh?18:57
olofkYep. If I change url from git://github.com/openrisc/orpsoc-cores to git@github.com:openrisc/orpsoc-cores.git it stops working19:30
olofkSo... what the hell does that imply?19:30
olofkHmm... could it be that git over ssh is broken perhaps19:32
Limbolofk: try it with http://19:48
_franck_olofk: Limb is right, try: https://olofk@github.com/openrisc/orpsoc-cores.git19:50
Findetonunknown command 'colophon'19:56
Findetonunknown command 'cygnus'19:57
Findetonthis is while building the toolchain19:57
olofkIs that URL R/W?19:57
Findetonwhat do you mean by URL R/W?19:58
olofkIf I have that as my origin in .git/config, can I push to it?19:59
Findetonoh sorry I do not know20:00
olofkAt least it works to pull from it20:01
olofkYep. Pushing works as well20:13
olofkSo git over ssh is broken, but it works over https20:13
olofkJust when I thought I had become friends with this crazy VCS20:13
Findetonlol20:18
Findetonand how come git over ssh is broken?20:18
olofkHaven't got a clue, and right now I don't give a damn either20:18
Findetonhaha ok20:19
Findetonright now I'm trying to build the toolchain20:19
olofkI don't recognize those errors20:20
Findetonit looks like the uclibc toolchain is ok20:20
Findetonbut the newlib toolchain gives me problems20:21
Findetonoh shit20:21
Findetonnothing, I can build no toolchain20:25
_franck_could you paste your logs ?20:28
Findetonyeah20:32
Findetonone sec20:32
Findetonif it compiles now I'm going to shoot myself20:36
Findetonpastebin.com/h7qfu30320:39
Findeton( _franck_ )20:39
_franck_Findeton: you should follow this: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.2920:40
Findetonuhm20:42
Findetonokay20:42
Findetonbut, when it says20:43
FindetonSee the following links for the appropriate development versions of the tools and libraries: binutils, gcc, newlib20:43
Findetondoes that mean that I need to install the development versions of those tools first?20:43
Findetonor shall I proceed with the newlib toolchain20:43
_franck_start with the newlib toolchain20:44
_franck_I don't know if you saw it but you also have prebuilt versions of the toolchain20:45
simoncookFindeton: it looks to me like the texinfo5 bug with parsing comments weirdly, just remove the lines in question that it complains about if you don't need the standard GNU documentation or care if its slightly malformed20:45
simoncookor build and install a texinfo4 that will work fine20:46
Findetonso I can simply uninstall textinfo5 and install the version420:46
simoncookim not sure if v4 will be in your standard repositories if it installed v520:47
FindetonI'll try to comment it out20:49
simoncookalternativey on those lines (I think theyre both email addresses), you can replace @ with @@ and it will build fine (but I thought the openrisc repositories were updated past this point that this was fixed upstream?)20:49
Findetonoh20:53
FindetonI'll let you know if it works20:54
Findetonsimoncook it looks like there are three bfd.info in my system and only one of them had the @ already replaced with @@20:57
Findetonon gnu-stable/binutils and gnu-stable/gdb it had @20:57
Findetonon or1k-src it had @@20:58
Findetonit didn't work but apparently it's because there are other files with the same problem21:06
Findetonfor example ld.texinfo21:06
Limbolofk: Have you finalized your wb_ram changes yet?21:40
Findetongod it's compiling finally22:19
Findetonit's taking a while to compile though22:19
LimbDoes clock speed affect the wishbone bus?22:25
Limbcould the fact that im driving everything off a 100 MHz signal be my problem?22:25
olofkLimb: Haven't had time to test things enough yet to push it22:29
Limbolofk: what exactly are the main differences with wb_ram and ram_wb?22:29
Limbdo they both do the same thing essentially?22:29
Limbhrmmmm23:24
Limbram_wb seems to lockup my synth process23:43
--- Log closed Fri Apr 11 00:00:00 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!