--- Log opened Thu Apr 10 00:00:58 2014 | ||
Limb | well.. progress somewhat | 01:02 |
---|---|---|
Limb | now it times out halting the cpu | 01:02 |
Limb | https://github.com/Limb/orpsoc-cores/tree/nexys4/systems/nexys4 If anyone can find any faults | 01:10 |
stekern | olofk: 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 bootargs | 02:38 |
stekern | Limb: how did you configure/start openocd? | 02:38 |
Limb | stekern: sudo openocd -s ./tcl -f ./tcl/interface/ftdi/digilent-nexys4.cfg -f ./tcl/board/or1k_generic.cfg | 02:39 |
Limb | http://pastebin.com/ZdR32tbU those are the configs | 02:41 |
stekern | ok, that seems like something that should work (although I'm no openocd expert) | 02:46 |
Limb | !!! | 02:51 |
Limb | modified the files a bit and it says target ready \o/ | 02:51 |
stekern | nice! | 02:56 |
Limb | mightve spoken too soon :( | 02:57 |
stekern | my 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 reg | 03:33 |
stekern | ...next, see if clearing the lock works | 03:34 |
_franck_ | Limb: http://opencores.org/forum,OpenRISC,0,5351 | 05: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 |
blueCmd | stekern: nice! | 08:17 |
blueCmd | stekern: atomicity <3 | 08:18 |
olofk_ | Does anyone have experience with running FPGA design tools on Mac OS X? | 08:20 |
olofk_ | Are they even supported? | 08:20 |
blueCmd | olofk: only through VMw | 08:20 |
blueCmd | VMs* | 08:20 |
blueCmd | stekern: will you add support to GCC for the __atomic and __sync constructs? | 08:21 |
stekern | blueCmd: 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'as | 09:05 |
stekern | and then it'd be nice if we'd have at least one rtl implementation that support it before gcc | 09:06 |
stekern | and I think we should have it in the arch spec before adding it for real to the tools/simulators/rtl implementations | 09:09 |
stekern | actually adding it is of course not a big deal, it's just writing a bit of text ;) | 09:12 |
stekern | there are interesting discussions that could be had before that though, for instance, what should the granularity of the lock be? | 09:12 |
stekern | right 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 |
stekern | and 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 |
stekern | blueCmd: ...but if you're eager to add the __atomic and __sync constructs yourself, be my guest ;) | 09:20 |
stekern | I'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 |
stekern | http://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 |
stekern | no | 09:58 |
stekern | that was why it caused a bit of a headache in or1ksim | 09:58 |
stekern | but I think what I did to fix it was less a hack than fixing a defiency in the generator | 10:00 |
stekern | s/defiency/deficiency | 10:00 |
stekern | as 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 problematic | 10:02 |
olofk_ | ok. I was mostly worried about the RTL implementation. Sounded like it could be a really awkward special case | 10:41 |
olofk_ | Does anyone know what buses Intel uses internally. | 10:42 |
blueCmd | stekern: does it still need to be in kernelspace? surely no? | 10:44 |
blueCmd | stekern: I'm thinking of why you are setting up syscalls | 10:45 |
stekern | no, the syscall is just there because it's an convient way of inducing an exception in a controlled way | 10:48 |
stekern | the 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.rfe | 10:48 |
blueCmd | ah I see | 10:48 |
blueCmd | surely you have pasted some information on how the two instructions work - but I totally forgot | 10:49 |
blueCmd | mind pasting again? | 10:49 |
stekern | because, a reservation by a l.lwa should be cleared by context switches (exceptions), so that's what I'm testing | 10:49 |
stekern | hmm, http://en.wikipedia.org/wiki/Load-link/store-conditional tells most I think | 10:50 |
stekern | this was what was in an old version of the arch spec: http://pastebin.com/bv3DNJ8s | 10:51 |
stekern | there's a lot missing from that text though, I basically just took the instruction names from it | 10:52 |
blueCmd | I see, looks fine | 10:56 |
blueCmd | stekern: am I reading the code correctly if I say that memory 0 contains the locked address? | 11:03 |
blueCmd | i'm having trouble seeing how you know when swa fails | 11:04 |
stekern | yes, I use memory location 0x0 for the tests | 11:05 |
stekern | are you speaking about a particular test? | 11:06 |
blueCmd | test 5 | 11:07 |
blueCmd | if you get an context swicth between l.swa and l.lwz so that 0(r0) is clobbered | 11:08 |
blueCmd | what happens then? | 11:08 |
stekern | umm, there are no context switches in test 5 | 11:08 |
stekern | test 5 checks that the content in r5 (0xdeadbeef) doesn't get written to 0(r0) | 11:09 |
blueCmd | right, 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 break | 11:10 |
stekern | ah, 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 preemptied | 11:11 |
blueCmd | ok, fair enough | 11:11 |
stekern | the way to see if it succeeded is to check the destination register, so you still have a point | 11:12 |
stekern | you can of course be preemptied between the l.swa and that check, but that's OK | 11:13 |
blueCmd | as long as the result is in a register and not in memory that should be OK | 11:14 |
stekern | yes | 11:14 |
blueCmd | but 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), src | 11:15 |
stekern | s/destination register/source register ;) | 11:15 |
stekern | sorry | 11:16 |
blueCmd | right thanks | 11:16 |
blueCmd | so r5 in this case? | 11:16 |
stekern | right | 11:16 |
blueCmd | makes sense | 11:16 |
blueCmd | thanks | 11:16 |
blueCmd | ah, so that's what test 2 and 3 does. | 11:17 |
blueCmd | neat | 11:17 |
stekern | to 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 switch | 11:24 |
stekern | + of course stores in multiprocessor environments, but that's hard to test within or1ksim ;) | 11:25 |
stekern | that's at least my understanding of how things should work | 11:26 |
blueCmd | right | 11:27 |
blueCmd | this is all kept in an internal reg I guess? | 11:27 |
stekern | yes, https://github.com/skristiansson/or1ksim/blob/3afc310f4e6c7aa50dd823ab36e2fb365a1a0de7/cpu/common/execute.h#L57 | 11: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 multithread | 12:59 |
olofk_ | That's of coure a more common problem for us right now | 13:00 |
stekern | olofk_: I'm planning on putting together a mail in the evening and send to the ml | 13:26 |
Limb | _franck_: changing the irlen to 8 doesn't resolve the problem sadly :( | 14:32 |
_franck_web_ | too bad | 14: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#L105 | 14:39 |
_franck_web_ | and see if openocd can read/write from/to memory | 14:39 |
Limb | _franck_web_: still quits with error trying to halt processor with that config | 15:16 |
_franck_web_ | do you have `define ADBG_USE_HISPEED in adbg_defines.v ? | 15:20 |
Limb | I don't have a adbg_defines | 15:21 |
_franck_web_ | oups | 15:22 |
Limb | ?? | 15:23 |
_franck_web_ | Limb: are you using fusesoc ? | 15:24 |
Limb | ywa | 15:24 |
Limb | yes* | 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#L21 | 15:25 |
Limb | _franck_web_: do you mean I personally should have it in my system core? | 15:26 |
Limb | or its included with the adv_dbg core | 15:26 |
_franck_web_ | ("oups" is a french interjection :)) | 15:27 |
_franck_web_ | it is automatically included by adv_dbg core | 15:27 |
_franck_web_ | you should have it in build/$your_system/src/adv_dbg_core/rtl/verilog/ | 15:28 |
Limb | yes i see it | 15:29 |
olofk | Fucking debian. Some package update was interrupted and now I'm just getting strange errors | 15:30 |
olofk | _franck_web_: I have an idea | 15:31 |
olofk | You need wb_bfm and vlog_tb_utils to test wb_alter_ddr_ctrl, and want it to be usable outside of fusesoc | 15:32 |
_franck_web_ | true | 15:33 |
olofk | If 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-alone | 15:33 |
olofk | I 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 solution | 15:34 |
olofk | And IIRC you added local copies in jtag_vpi instead | 15:34 |
_franck_web_ | I have a local copy of adv_debug_sys in jtag_vpi | 15:35 |
olofk | ah yes. That was the one I was thinking of | 15:36 |
olofk | And in that case upstream is SVN | 15: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 anymore | 15:36 |
_franck_web_ | (at least for me) | 15:36 |
_franck_web_ | I meant to orpsoc-cores/cores | 15:38 |
Findeton | I want to run linux on openrisc, but I don't have a fpga | 17:48 |
Findeton | so what do I need? do I need to install the toolchain or the ork1sim, or both? | 17:49 |
Findeton | ok | 18:00 |
olofk | Findeton: There are a few different ways to run OpenRISC without hardware. or1ksim, qemu, jor1k | 18:00 |
Findeton | it looks like I need both | 18:00 |
Findeton | I mean with or1ksim | 18:00 |
olofk | ah ok | 18:01 |
olofk | You can get a pre-build linux image if you just want to try it out | 18:01 |
Findeton | yeah I did | 18:02 |
Findeton | but I couldn't get to connect it to the internet | 18:02 |
Findeton | so I'm doing it from scratch | 18:02 |
Findeton | which is a good learning experience anyway | 18:03 |
olofk | Ah yes. Was it you who was running the VirtualBox VM and was having problems ith the brstart/brend scripts? | 18:03 |
Findeton | yess | 18:09 |
Findeton | so now I'm doing my own virtualbox VM :p | 18:10 |
olofk | Too much going on in my head right now. That was only a few days ago we talked about this :) | 18:10 |
Findeton | don't worry hehe | 18:10 |
Findeton | btw where are you from? | 18:10 |
olofk | Sweden | 18:10 |
Findeton | oh | 18:11 |
Findeton | I'm from Spain but I work in Luxembourg | 18:12 |
Findeton | it must be a bit chilly in Sweden | 18:12 |
Findeton | ! | 18:12 |
olofk | Hell yeah. It's a fucking stupid place to live. Every winter I wonder what the hell I'm doing here | 18:12 |
Findeton | haha | 18:14 |
Findeton | I don't know, perhaps I'd like to live there | 18:14 |
olofk | It's not half bad otherwise, but I tend to be a bit grumpy in the winter :) | 18:15 |
Findeton | haha | 18:15 |
Findeton | well how is the job market there for developers? | 18:15 |
olofk | Quite good at the moment | 18:15 |
Findeton | also, I don't know swedish so.. | 18:15 |
Findeton | xd | 18:15 |
olofk | I still can't update my orpsoc-cores repo | 18:21 |
olofk | But I can pull the fresh clone that I did yesterday | 18:24 |
olofk | I tried git gc | 18:24 |
Limb | olofk: what error does it give | 18:36 |
olofk | Limb: It gets stuck somewhere in remote: Compressing objects | 18:38 |
olofk | http://d51ece4f650346f4.paste.se | 18:41 |
Limb | what version of got | 18:47 |
Limb | git* | 18:47 |
olofk | 1.8.3.2 | 18:55 |
olofk | I wonder if I have compiled it or any of the underlying libs with some strange flags | 18:55 |
Limb | Googlefu says network problems | 18:56 |
olofk | Yeah, but doing clone and pull from a fresh repo works fine | 18:56 |
Limb | though it might be worth upgrading to the latest version | 18:56 |
olofk | But that uses a different origin url | 18:56 |
olofk | Have to experiment with that | 18:56 |
Limb | try http instead of ssh? | 18:57 |
olofk | Yep. If I change url from git://github.com/openrisc/orpsoc-cores to [email protected]:openrisc/orpsoc-cores.git it stops working | 19:30 |
olofk | So... what the hell does that imply? | 19:30 |
olofk | Hmm... could it be that git over ssh is broken perhaps | 19:32 |
Limb | olofk: try it with http:// | 19:48 |
_franck_ | olofk: Limb is right, try: https://[email protected]/openrisc/orpsoc-cores.git | 19:50 |
Findeton | unknown command 'colophon' | 19:56 |
Findeton | unknown command 'cygnus' | 19:57 |
Findeton | this is while building the toolchain | 19:57 |
olofk | Is that URL R/W? | 19:57 |
Findeton | what do you mean by URL R/W? | 19:58 |
olofk | If I have that as my origin in .git/config, can I push to it? | 19:59 |
Findeton | oh sorry I do not know | 20:00 |
olofk | At least it works to pull from it | 20:01 |
olofk | Yep. Pushing works as well | 20:13 |
olofk | So git over ssh is broken, but it works over https | 20:13 |
olofk | Just when I thought I had become friends with this crazy VCS | 20:13 |
Findeton | lol | 20:18 |
Findeton | and how come git over ssh is broken? | 20:18 |
olofk | Haven't got a clue, and right now I don't give a damn either | 20:18 |
Findeton | haha ok | 20:19 |
Findeton | right now I'm trying to build the toolchain | 20:19 |
olofk | I don't recognize those errors | 20:20 |
Findeton | it looks like the uclibc toolchain is ok | 20:20 |
Findeton | but the newlib toolchain gives me problems | 20:21 |
Findeton | oh shit | 20:21 |
Findeton | nothing, I can build no toolchain | 20:25 |
_franck_ | could you paste your logs ? | 20:28 |
Findeton | yeah | 20:32 |
Findeton | one sec | 20:32 |
Findeton | if it compiles now I'm going to shoot myself | 20:36 |
Findeton | pastebin.com/h7qfu303 | 20:39 |
Findeton | ( _franck_ ) | 20:39 |
_franck_ | Findeton: you should follow this: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 20:40 |
Findeton | uhm | 20:42 |
Findeton | okay | 20:42 |
Findeton | but, when it says | 20:43 |
Findeton | See the following links for the appropriate development versions of the tools and libraries: binutils, gcc, newlib | 20:43 |
Findeton | does that mean that I need to install the development versions of those tools first? | 20:43 |
Findeton | or shall I proceed with the newlib toolchain | 20:43 |
_franck_ | start with the newlib toolchain | 20:44 |
_franck_ | I don't know if you saw it but you also have prebuilt versions of the toolchain | 20:45 |
simoncook | Findeton: 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 malformed | 20:45 |
simoncook | or build and install a texinfo4 that will work fine | 20:46 |
Findeton | so I can simply uninstall textinfo5 and install the version4 | 20:46 |
simoncook | im not sure if v4 will be in your standard repositories if it installed v5 | 20:47 |
Findeton | I'll try to comment it out | 20:49 |
simoncook | alternativey 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 |
Findeton | oh | 20:53 |
Findeton | I'll let you know if it works | 20:54 |
Findeton | simoncook it looks like there are three bfd.info in my system and only one of them had the @ already replaced with @@ | 20:57 |
Findeton | on gnu-stable/binutils and gnu-stable/gdb it had @ | 20:57 |
Findeton | on or1k-src it had @@ | 20:58 |
Findeton | it didn't work but apparently it's because there are other files with the same problem | 21:06 |
Findeton | for example ld.texinfo | 21:06 |
Limb | olofk: Have you finalized your wb_ram changes yet? | 21:40 |
Findeton | god it's compiling finally | 22:19 |
Findeton | it's taking a while to compile though | 22:19 |
Limb | Does clock speed affect the wishbone bus? | 22:25 |
Limb | could the fact that im driving everything off a 100 MHz signal be my problem? | 22:25 |
olofk | Limb: Haven't had time to test things enough yet to push it | 22:29 |
Limb | olofk: what exactly are the main differences with wb_ram and ram_wb? | 22:29 |
Limb | do they both do the same thing essentially? | 22:29 |
Limb | hrmmmm | 23:24 |
Limb | ram_wb seems to lockup my synth process | 23: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!