IRC logs for #openrisc Tuesday, 2014-07-22

--- Log opened Tue Jul 22 00:00:30 2014
stekernis ghdl still 'the shit' if you want a open source vhdl simulator?03:40
jeremy_bennettblueCmd: stekern: You should be basing your patch for upstream on the top of mainline branch.06:59
jeremy_bennettBTW are you changing anything generic, or is it purely an OR1K specific patch?07:00
stekernjeremy_bennett: there are no generic changes in our tree, only or1k specific ones07:01
jeremy_bennettstekern: That makes life a lot simpler.07:03
jeremy_bennettYou should make sure you can report good regression test results for OR1K. Ideally no failures. If there is anything not supported it should be marked to return UNREPORTED, or possibly XFAIL07:07
jeremy_bennettstekern: Don't know about GHDL. I've never come across anyone who has actually used it. I get the impression of a project that is incomplete and languishing a bit07:08
stekernyeah, support for later revisions of VHDL seems very lacking...07:09
stekernit worked for a simple design I tested it with now, but I doubt it's useful for more complex stuff07:09
stekernbut the question wasn't actually about ghdl, the question was if there are alternatives?07:10
jeremy_bennettstekern: The answer to that question is "no". There has been a project to put VHDL into Verilator, but it also languishes, and at a very early stage.08:41
jeremy_bennettThe problem is that VHDL seems to be reducing in popularity, and so the motivation to support it is also dropping.08:41
blueCmdjeremy_bennett: for the tests that will be hard since we do not have any single fully working libc09:00
blueCmdbut we can be as close as possible09:00
stekernI should probably test running it against musl09:16
stekernI could combine it with running it against multicore too09:18
stekernthe only problem is that I don't have a board with networking anymore :(09:18
stekernI need to build that mac<->mac adapter09:19
stekernwhich is dead simple, but still some effort is needed...09:19
blueCmdstekern: give me a script that builds musl and I'll mod my cloud testing and run it through qemu09:22
blueCmdhah, I need to change qemu to use real atomics I think, hopefully that will solve the random segfaults/timeouts09:24
maxpalnok, new approach today - I ran around in circles yesterday trying to track down the problem. The biggest issue is that the problem appears to occur in the middle of the recursive call to schedule() within kernel/sched/core.c - it's making triggering on the correct iteration difficult to manage. In addition, I found that the debug printk's affect how far through the code we get - which after09:27
maxpalnthinking about it overnight I have concluded that problem must manifest itself in some interaction between the instructions executed by printk and the rest of the code.09:27
maxpalnI can see that schedule_preempt_disabled() is entered and an l.jal to schedule() occurs but the return call never happens.09:27
maxpalnLooking through the processor manual I am trying to understand a little of how the memory is arranged -09:28
maxpalnSection 16.2.2 says of the Stack Frame: "In addition to registers, each function has a frame on the run-time stack."09:28
maxpalnSo I am wondering if somewhere along the line I am getting a write to an incorrect area of memory - tracking it down is proving frustratingly complex though....09:29
maxpaln[just sharing my thoughts - it seems to help :-)]09:29
stekernor in a shorter form:09:34
stekerngit clone git://
stekernmaxpaln: feel free to continue sharing thoughts, I do that all the time too ;)09:37
stekernI can give you a hint about the code you are debugging, schedule() does exactly that, schedule.09:40
stekernwhich means that the context will be switched inside that function09:40
maxpalnstekern: THAT's IT! If only I had that information yesterday :-P09:41
maxpalnah, sorry- I jumped in with my sarcasm too early09:41
maxpalnYeah, I am currently wondering if the return pointer to the original schedule_preempt_disable() is corrupted09:43
maxpalnI am crossing my fingers the corruption happens somewhere near the start or the end - the recursion happens some 180+ times - tracking things through that is tricky to say the least!!09:43
blueCmdstekern: thanks, I wanted the shorter form09:49
blueCmdnot the blog-post disquised as an email ;)09:50
stekernmaxpaln: where is that recursive call?09:50
maxpalnhmmm, trying to trace it through the source code now09:53
maxpalnI can see it happening in the execution of the assembler - but now you've asked I guess it is possible that it isn't supposed to be recursive and that is where the problem lies...09:54
maxpalnlet me see if I can trace it09:54
-!- Netsplit *.net <-> *.split quits: ysionneau, ams, blueCmd, arokux, rjo09:54
-!- Netsplit over, joins: ysionneau, arokux, rjo09:55
maxpalnOk, I am backing away from the idea of a recursive call - it doesn't pan out in the assembler. There is a repeated call though - from within kthreadd()10:34
maxpalnI haven't traced the entry point for this function yet - but I have been tracing the calls to schedule() and several of them originate from within kthreadd()10:35
maxpalnHmmm, back chasing my tail again....10:39
maxpalnOk, different approach - schedule() unconditionally calls __schedule() which has only one l.j r9 call - so I triggered on that and tracked all the places that this function returns to.11:59
maxpalnThey are here:11:59
maxpalnThere are a lot of timeouts but I am not sure if this is indicative of another issue or just likely to happen for a limited HW profile.12:00
maxpalnIn any case, the final return is to do_work_pending() - I am going to look closer here.12:00
maxpalnfinally a break - do_work_pending is called only once!!12:03
jeremy_bennettblueCmd: It will be hard to persuade the GCC community to accept a port without some credible regression test results. For GCC 4.5.1 we ran both ELF and uClibc tests against Or1ksim and the ELF tests also against a Verilator model12:07
jeremy_bennettThe speed of the model is not important - the tests are dominated by the time to compile.12:08
jeremy_bennettFor bare metal (ELF) a minimal newlib is sufficient. For Linux, you must have a reasonable libc, or you wouldn't be able to build Linux.12:08
blueCmdjeremy_bennett: we have ~200 failures for the GCC test suite12:22
maxpalnI am found the vicinity of the problem - but the symptoms are confusing me12:22
blueCmdjeremy_bennett: for uclibc I think this was 85 for 4.5.112:23
maxpaln__schedule() returns to do_work_pending(), which returns via l.jr r9 to _work_pending(), then immediately onto _restore_all()12:26
maxpalnvia l.bf12:26
maxpaln_restore_all appears to be proceeding on plan - then whilst starting to reload the registers from memory, EPCR changes to a seemingly random value.12:28
maxpaln_restore_all is at c000622c12:29
maxpalnEPCR changes to 0x001048a812:29
maxpalnexecution of the code continues until the end of _restore_all() when l.rfe takes us to _ret_from_exception()12:31
maxpalnthis is where things get confusing12:32
maxpalnthe first instruction of _ret_from_exception() isn't executed (although it is fetched from memory) instead PC jumps to 0xA0412:33
maxpalnwhen executing 0xA0C an attempt is made to read the databus from address 0x7fed3e8012:34
maxpalnwhich is where everything hangs12:35
maxpalnnothing physical is at address 0x7000000012:35
maxpalnI am confused by several things: EPCR getting assign 0x001048a8, the jump straight to 0xA04 instead of 0xA00, and the attempted read from the non-existent address 0x7fed3e8012:36
maxpalnInterestingly, 0x001048a8 is within __jffs2_flush_wbuf()12:37
maxpalnand the last output from the boot process is:12:37
maxpalndevtmpfs: initialized12:38
maxpalnSwitched to clocksource openrisc_timer12:38
maxpalnjffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.12:38
maxpalnBut I can't see any execution of this code for at least several hundred instructions before EPCR gets asserted.12:39
maxpaln0x7fed3e80 appears to originate via the penultimate instruction in _restore_all():12:42
maxpalnooops, copy paste issue-  here is the final instruction:12:42
maxpalnc00062c8:84 21 00 04 l.lwz r1,0x4(r1)12:42
maxpalnby tracking the registers I can see r1 retrieved as 0xc1219ef0 but written as 0x7fed3e8012:44
maxpalnThere is no memory access to retreive this value so it must be in cache somewhere!12:44
maxpalnI'll try triggering on 0x01219ef4 to see if this shows up anything interesting12:45
maxpaln[typing to yourself is strangely therapeutic!]12:46
blueCmdmaxpaln: stekern and I do it all the time12:53
stekernmaxpaln: EPCR is loaded from pt_regs in _restore_all13:07
stekerni.e., it is restored from memory and written to EPCR with an l.mtspr13:08
maxpalnaha - ok, that makes sense13:09
maxpalnat the point where EPCR gets set, this instruction is being executed:13:09
maxpalnc000624c:c0 00 18 40 l.mtspr r0,r3,0x4013:09
stekernexactly, that will write EPCR with the value in r313:10
maxpalnOk, so that explains EPCR13:10
stekernso, that value *should* be the value that was saved to the stack on exception entry13:10
maxpalnok, well it makes sense I suppose - it is in the __jffs2_flush_wbuf() function which is the last thing that appears to be executed during Linux boot13:11
stekernas for the 'strange' addresses, those look like userspace addresses13:11
stekernespecially the 0x7fed3e80 stackpointer value13:12
maxpalnwell, I just traced all accesses to address 0x01219ef4 (the one that returned the 0x7... value13:12
stekernso, you should start poking around in your busybox elf for those13:12
maxpalnwhoah - 'busybox elf'13:13
maxpalnI haven't come across that term before13:13
maxpalnAh, I see -13:13
maxpalnI wouldn't have gotten there, but that makes sense13:14
maxpalnwhat isn't clear - is why an OR1200 Data Bus access to that address 0x7.... just hangs13:14
maxpalnwell, actually - I say that but I can't confirm it hangs indefinitely, it definitely sits there with or1200 data bus stb asserted for several hundred clock cycles.13:16
stekernis that 0x7fed3e80 let out on the bus?13:21
stekernif so, then that's certainly not right13:21
maxpalnyes, the OR1200 data bus address is 0x7fed3e80 with or1200 STB asserted13:22
maxpalnI had just come to the same conclusion13:23
maxpalnAlso, at the same point, the instruction bus cycles through 0xA04, 0xA08 and eventually hangs on 0xA0c13:24
maxpalnbut these addresses make no sense - here's the assembler:13:24
maxpalnc0000a00:00 06 ed f0 l.j c01bc1c0 <boot_itlb_miss_handler>13:24
maxpalnc0000a04:15 00 00 00 l.nop 0x013:24
maxpalnc0000b00:d4 00 f8 84 l.sw 0x84(r0),r3113:24
maxpalnc0000b04:d4 00 50 7c l.sw 0x7c(r0),r1013:24
maxpalnso, after a day and a half I can confirm that something has gone wrong :-)13:25
maxpalnI'm a bit stuck for where to go now [puzzled look]13:26
ysionneauoff-topic, each time I look at your nickname I think about "max payne"13:28
mor1kx[mor1kx] skristiansson pushed 2 new commits to master:
mor1kxmor1kx/master e117375 Stefan Kristiansson: cfgrs: whitespace cleanup and switch to verilog2001 module declaration13:28
mor1kxmor1kx/master 17afdf2 Stefan Kristiansson: add support for shadow register files...13:28
maxpalnysionneau: that is not a coincidence13:29
stekernoff-topic*2 Remedy have their office next to where I work13:29
maxpalnI gained the tag after a very drunk night playing some multiplayer game at a friends house - I wanted to give myself the nick name maxpayne but could only type maxpaln - it kinda stuck...13:29
stekernhaha, that's one of the best 'how I got my nick' stories I've heard13:30
ysionneaunice :)13:31
maxpalnok, any clues about how to progress - I am guessing something should be translating the virtual 0x7FED... address to a physical location13:35
maxpalnI think I need a break - back in 10 mins!13:36
imphilAnnouncement: the OpTiMSoC guys created a new FIFO-based communication library to encapsulate the communication between a FPGA and a host PC. It's essentially refactored and reworked code from OpTiMSoC, in the hope to make it useful for others as well. See for code & documentation.13:42
blueCmdafter a few hours of dissecting, I found the commit that breaks ncurses, visit the bug associated with the request and find that this bug was filed:
blueCmd"r212638 breaks building ncurses"13:43
blueCmdso yeah, might be a point to look at bugzilla first13:43
maxpalnright - back in room13:50
stekernblueCmd: haha, been there done that...13:50
maxpalnso having traced all accesses to address 0x01219ef4 - there is an initial write of 0x0 in mem_set(), a write of 0x7FED3ed0 in start_thread(), a read of the same value within _syscall_resume_userspace() then 13 writes of various values and finally a read from within _ret_from_exception()13:54
maxpalnGiven that this address is appearing on the bus I am not sure it is worth diving into the contents of the busybox binary - apart from to see what was attempting to be accessed I guess,13:57
maxpalnalthough it is not clear how to translate the virtual address to an offset in the busybox hex dump.13:57
stekernmaxpaln: the translation should be 1:114:02
stekerni.e. the values in the hexdump is the virtual addresses (just like for the kernel)14:03
maxpalnHmm, that is what I was expecting - but the address range in the busybox is 0x0 to 0x13699c14:04
maxpalnit doesn't get anywhere near as high as 0x7FED3ED014:04
stekerncould of course that they are bogus14:05
stekernit was just a guess from my side, 0x7FED3ED0 looked like it could be a stackpointer14:11
maxpalnoh, hang-on - looking through the linux dump - there is a similar notation to the busybox dump. It is for the disassembly of sections:14:15
maxpalnDisassembly of section .comment:14:16
maxpaln00000000 <.comment>:14:16
maxpaln   0:47 43 43 3a l.jr r814:16
maxpaln   4:20 28 4f 70 .word 0x20284f7014:16
maxpaln   8:65 6e 52 49 .word 0x656e524914:16
maxpaln   c:53 43 20 33 .word 0x5343203314:16
maxpalnSo where is the offset for the start of the .comment section stored - I am guessing that the address in the busybox represents an offset from a base address14:17
maxpalnbut maybe you are right - maybe it isn't in the user space...14:19
stekernlet's rewind to one thing you said "instead PC jumps to 0xA04"14:21
maxpalnok, yep14:23
maxpalnjust retrieving the trace14:23
stekernimphil: nice, will have to take a closer look at that14:24
maxpalnok, so the PC loads the start of _ret_from_exception() at 0x62d014:25
maxpalnthen the PC sequence is: 0x62d0, 0xA04, 0xA08, 0xA0C14:25
stekernok, you want to catch the exception that you are returning from there14:26
maxpalnok - EPCR says this is at 0x1048a8 inside the jjfs2 function.14:27
maxpalnI#ll try and capture that.14:27
stekernisn't EPCR 0xa04?14:27
maxpalnsorry, confused us all - no, OR1200 Inst Bus address is 0xA0414:28
stekernisn't 0x62d0 a l.rfe?14:28
maxpalnnope, that's the instruction before - here is the section of the assembler:14:29
maxpalnc00062c4:87 e1 00 7c l.lwz r31,0x7c(r1)14:29
maxpalnc00062c8:84 21 00 04 l.lwz r1,0x4(r1)14:29
maxpalnc00062cc:24 00 00 00 l.rfe14:29
maxpalnc00062d0 <_ret_from_exception>:14:29
maxpalnc00062d0:84 81 00 00 l.lwz r4,0x0(r1)14:29
maxpalnc00062d4:a4 64 00 01 l.andi r3,r4,0x114:29
stekernok, but c00062d0 is never executed then (unless or1200 is buggy)14:30
stekernand epcr is 0xa0414:30
stekernso, you want to find if you've got an exception at 0xa04 somewhere14:30
stekernand if that's an userspace address or kernel address14:30
stekernyou should see that from SR and ESR14:31
maxpalnok - but one point to push onto the stack is that at 0x62d0, r1=0x7FED3E80 - so the execution of that instruction would tally up with the assertion of the OR1200 data asserting STB with the address set to 0x7FED3E80 (with the crucial point that the address should have been translated from virtual to physical memory space)14:32
jtdesousais it possible to use openocd with the Atlys port , or is that stil to be done?14:32
maxpalnbut we can come back to that - I'll try and track down exception at 0xA0414:32
stekernjtdesousa: that is possible14:33
maxpalnwell, EPCR never holds the value 0xA0414:34
stekernok, let's step back a bit. When the l.rfe at c00062cc is executed, what does epcr contain at that moment?14:35
jtdesousais there a wiki with how I shall configure openocd before compiling it to use the Xilinx JTAG I/F ?14:36
jtdesousaor some document14:36
maxpalnjust getting the trace back...14:38
maxpalnwhen the l.rfe is executed at c00062cc - EPCR=0x001048a814:40
stekernoh, ok... that's actually what you said before, I was just ignoring the facts14:41
jtdesousa_frank_: thanks14:42
stekernthat seems all strange14:42
stekernl.rfe should jump to the address in EPCR, and 0x001048a8 can't in any way translate to 0xa0414:43
stekernso that must mean that at the same time the l.rfe is executed, there is a tlb miss14:43
stekernand then or1200 bugs out and increases PC by 4 or something like that14:44
maxpalnhmmm, maybe14:45
stekernwhat's epcr when you hit 0xa04?14:47
maxpalnstill 0x001048a814:47
stekernjust to make sure, it's 0x001048a8 at c00062c8 too, right?14:48
maxpalnyeah, it's been that value for a while14:48
maxpalnsince 0x624c14:49
maxpalnor c0000624c14:49
maxpalnafter executing the l.rfe the instruction bus fetches the next four instructions as 0x62d0-0x62dc14:52
maxpalnthen where the execution of 0xA00 should be, the OR1200 address appears as 0x62d014:52
maxpalnprobably triggering the erroneous address value on the data bus address14:52
stekernyeah, sounds plausible14:53
maxpalnso somewhere in all that is a problem that prevented 0xA00 from being executed correctly.14:53
stekernyes, that's certainly a bug. but then there's also the question if 0x001048a8 is a valid address in the first place.14:54
maxpalnwell, 0x001048a8 is within __jffs2_flush_wbuf - this is definitely plausible14:54
stekernno, that should be a virtual address14:54
maxpalnah, really......14:55
maxpalnis there a map of the virtual addresses somewhere?14:57
stekernwhat do you mean?14:58
maxpalnwell, it would be good to look up the virtual address 0x001048a814:59
stekernI can answer 'yes, in the pagetables'14:59
stekernbut not sure if I understood your question14:59
maxpalnOK, I wanted to look at the instruction at address 0x001048a8 but I am not sure what binary to find it in15:00
stekernit's either in busybox or the kernel15:00
maxpalnah, ok15:00
stekernso, most likely not a valid address15:01
maxpalnit could be a busybox address:15:01
maxpaln  1048a4:e0 85 20 00 l.add r4,r5,r415:01
maxpaln  1048a8:d4 04 20 0c l.sw 0xc(r4),r415:01
maxpaln  1048ac:13 ff ff f9 0x10489015:01
stekernah, ok. I thought you said that address didn't exist in busybox, but perhaps that was another address15:01
maxpalnah, I meant the 0x7FED.... address15:02
maxpaln0x7FED3E80 is definitely not in the busybox15:02
stekernyeah, but that looks like a stack address15:02
maxpalnwhich one?15:03
maxpalnok - I'll take your lead on that one :-)15:03
stekernso, if we assume that 0x1048a8 is a legal address, then the or1200 bug seems to be the cause15:05
stekernit's easy to fix, switch over to mor1kx ;)15:05
maxpaln:-) - I will absolutely be doing that as soon as I have this working - I'd prefer to get a linux kernel booting first.15:05
maxpalnThis particular piece of work is for a customer in Denmark. Once I have it working I am switching to more general project to get the latest ORPSOC code running on our silicon. The lessons learned here will obviously help a lot - but I am expecting a bit of work to get the latest code running (I might be wrong) and I am currently on the critical path for this customer project!15:07
maxpalnSo rather than abandon everything I've learned on the OR1200 code I'd much prefer to get a Linux kernel booting. SO I have a couple of thoughts:15:08
stekernyeah, I get your standpoint. that said, mor1kx is drop-inable in your current SoC, so you could get away with pretty small changes15:09
blueCmdis there any reason not to use mor1kx?15:10
blueCmdis or1200 VHDL?15:10
maxpalnI guess my main concern is effort to get it in place.15:10
maxpalnif it really is drop-inable (nice word play :-) ) then I guess it should be pretty straight forward.15:11
blueCmdmy experience says that the module interface is the same, so it's only a matter of instansiating it and setting the paramaters to reasonable values15:11
maxpalnok, and the two are compatible with the OR32 tool flow I am using?15:12
stekernmaxpaln: you can take a look here for a top module that can be switched between or1200 and mor1kx:
stekern(or1200 is instantiated just above that)15:13
stekernyes, you can run the same software15:13
maxpalnok, that looks straight forward from the initial look -15:15
maxpalnMy heart is sinking a little though - I feel like I was just a few hours from having a working build.15:15
maxpalnexperience tells me things are never as easy as they seem :-)15:16
stekernmaybe you still are ;)15:17
maxpalnon the plus side, my memory controller appears to be holding up very well :-)15:17
maxpalnSo what's the easiest way to obtain the latest stable mor1kx?15:18
stekernbut, while I don't care so much on a personal level, it would of course be good to get that or1200 bug fixed...15:18
maxpalnwell, I have some time today - I am happy to continue to investigate if you like15:18
maxpalnI won't be starting anything with the mor1kx until tomorrow - that sort of thing requires a fresh mind!15:19
maxpalnbut guidance would definitely be needed - I wouldn't know where to start]15:22
stekernyeah, that's a bit of the problem, we don't really have anybody that is an expert on the or1200... so you're kind of on your own15:24
stekernbut given the bug, poking around the rfe and exception handling code would probably be a good starter15:25
stekernespecially looking for what would happen if an rfe and an exception happens at the same time15:26
maxpalnah, ok - I see. Well, I'll have a look and see if anything jumps out at me15:27
stekernwriting a small test case might help too, just turn on the immu in esr and rfe in an exception handler, that should cause a similar case as you're seeing15:28
fnunes__Hi all, I'm trying to connect openocd to a Digilent Atlys board. I configured openocd like this: .Then issued make and all went ok. Then executing openocd like this: .15:51
stekernso what does your ./tcl/interface/orsoc-jtag.cfg have at line 7?15:56
stekernthis is what mine looks like:
fnunes__I just copied and then tried to change the interface to ftdi, but again more errors. I'll try yours. Thanks.15:58
jtdesousastekern: to configure openocd is it enough like this: ./configure --enable-ftdi --enable-maintainer-mode16:05
stekernthink so16:06
stekernmy config.log says: ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode --no-create --no-recursion16:06
fnunes__stekern: Recompiling openocd with those flags now. Thanks.16:11
rahhow come the avalon-to-wb bridge is simple compared to the reverse?16:23
rahs/simple/so simple/16:24
blueCmdrah: 17:23 < rah> how come the avalon-to-wb bridge is simple compared to the reverse?16:24
rahblueCmd: I don't understand that sentence :-)16:26
imphilstekern, we also have a jtag backend in the works, but that will take a bit more polishing before it's ready to be committed16:27
blueCmdrah: it's the whole block there that describes it16:28
blueCmdand it's not complicated, it simply delays the stream so that it can find out which burst mode to use16:28
stekernimphil: cool, I'd like to hook that up to my this thingy:
stekern(among other use-cases)16:32
-!- fnunes__ is now known as fnunes_16:34
fnunes_stekern: The error now is: . lsusb: , orsoc-jtag-tmp.cfg: , my_or1k_generic.cfg: .16:36
stekernhastebin, for your quick pastes16:38
stekernfnunes_: the first link got screwed up ;)16:39
fnunes_stekern: Sorry for that.
stekernhaha, ok so it was right, I thought the hastebin was a typo16:48
stekerntried to run it as root?16:49
fnunes_Nop, trying now.16:49
fnunes_Same thing16:50
stekernyour lsusb doesn't show any ftdi device though16:51
fnunes_I installed digilent.adept.utilities_2.1.1-i686 and the driver for UART port (xr21v141x-lnx2.6.18-3.4.pak). All from the Atlys board page at Maybe I should other ?16:55
stekernto make clear, I have only used openocd together with the atlys board by using an external jtag adapter16:56
sb0any new mor1kx optimizations lately? my FPGA is full...16:56
fnunes_stekern: I don't have that.16:57
blueCmdsb0: xD16:57
stekernsb0: the PIPELINE multiplier shaves a couple of luts and flops, but it kills timing :/16:58
fnunes_stekern: Maybe thats the only way. I have only seem setups online with that or the Xilinx adapter.16:58
stekernsb0: I think it shouldn't need to though, but I have been busy with other stuff, so I haven't got to fully investigate it16:59
stekernfnunes_: yeah, I don't know... it would be cool if the digilent interface could be used. unfortunately, my atlys board has broke down, so your on your own there.17:00
stekernsb0: this is what I'm speaking about:
sb0"generating multiply overflows becomes cumbersome and has therefore been omitted." << you mean the overflow exception?17:04
sb0btw, lm32 already has such a multiplier mechanism, right?17:04
stekernyes, overflow exception17:06
stekernand yes, I think lm32 has that kind of multiplier mechanism17:06
sb0...does anyone use overflow exceptions?17:07
sb0it's an interesting feature though...17:08
stekernnot that I know of17:08
sb0oh, and shadow register files... interesting :)17:11
stekernyes, we'll need them for multicore17:11
sb0multicore? why?17:12
sb0what I can think of is low-overhead context switches and threads ...17:12
sb0ok. fpga is not totally full. 94%. so it'll still work for now *g*17:13
fnunes_stekern: Is it possible that openocd comunicates through the UART port ?17:13
stekernyes, that's their original purpose. the fast context switches are not completely supported in mor1kx yet though, but with the shadow register file it's a step in the direction of fully implementing them17:13
sb0is the register file in BRAMß17:14
stekernfor multicore, on exception entry we need scratch regs to obtain the kernel stack pointer, the problem is that there's no scratch regs defined in our ABI17:15
stekernso, the kernel have resorted to a hack where the regs are saved to addresses below 0x100, but that of course only works in the unicore case17:16
stekern(and it's ugly, so we'd like to get rid of that anyway)17:16
blueCmdunicorn case17:17
stekernso, instead we'll use the shadow register file (which can be accessed with SPRs) as a scratch reg area17:17
stekernthe benefit is that this is all within what the spec already defines17:18
stekernsb0: yes, it's in BRAM, so shadow regs are pretty low cost on FPGA targets17:18
stekernyou can of course force it into flops, but by default it's in bram17:19
sb0that multiplier does remove a bit of bloat. 94% -> 88% ...17:38
sb0still routing... and the timing score looks bad though...17:38
daliasstekern, below 0x100? so kernel still has page 0 mapped? :(17:55
daliasi'm pretty sure that escalates trivial kernel bugs into full kernelspace code execution bugs17:56
stekerndalias: no, it's with the mmu turned off18:03
blueCmdstekern: do you know if the part where 'l.swa' is cancelled if another (non-atomic) store instruction is executed is common in other arches?19:46
stekernumm, doesn't it have to be?19:49
stekernit's of course only stores to the same location that breaks the link19:50
daliasi don't think non-atomic loads/stores affect ll/sc link on other archs19:59
daliasbut i'm not 100% sure19:59
blueCmdstekern: I don't think it has to be, if you can say that you're only protected against other l.swa20:02
blueCmdwhat dalias said20:02
blueCmdthat's what I get from reading the qemu code for alpha and microblaze anyway20:02
blueCmdsorry, alpha and arm20:03
blueCmdarm might support it, it's hard to see what cases actually clear it - but alpha I'm pretty sure doesn't support non-atomic "poison"20:04
stekernhmm, to get to that other store, you'd have to do a context switch. so it's perhaps redundant. But the same would be valid for another l.swa then too, wouldn't it?20:05
stekernor are you speaking across multiple cores here?20:06
blueCmdstekern: I'm not speaking of it in practice - just what the arch says20:07
stekernyes, but what the arch says about within a single core or in the multicore case then? ;)20:08
blueCmdit can be a tad bit expensive to implement a compare on every store in qemu20:09
blueCmdstekern: the alpha or or1k?20:09
blueCmdnot sure20:10
blueCmdI mean, it says it uses bus snooping so that every single store to that memory violates it20:10
blueCmdso it's crystal clear that stores should poison the lock20:11
blueCmdwhich is very nice, but might be expensive to emulate20:11
stekernmmm, but maybe it's ok to cut some corners in qemu...20:18
daliasare you talking about stores from another core?20:20
blueCmddalias: stores in general20:20
daliasto the locked address, or to any address?20:20
blueCmddalias: locked address20:21
blueCmdI'm considering using cpu_watchpoint_insert20:21
blueCmdbut that might make it harder to implement gdb support later if we want that20:22
daliasfor qemu?20:22
daliascan't qemu tell that, unless an interrupt happens, there will be no accesses between the ll and sc?20:23
daliasjust by looking at the code it's dynrec'ing20:23
blueCmddalias: well, sure - but for the case when we have multiple cores that doesn't work20:24
daliasqemu does not emulate multicore does it?20:24
blueCmdIt doesn't?20:25
blueCmdI'm pretty sure it does20:25
daliasiirc not. it's really hard to do so20:25
blueCmd-smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,sockets=sockets] set the number of CPUs to 'n' [default=1]20:25
daliasbut does it use real threads on the host to implement them?20:26
daliasmaybe so20:26
blueCmdQEMU provides "-smp" option, but those virtual cpus are scheduled in20:26
blueCmdround-robin fashion. In other words, it's not real parallelism. I don't20:26
blueCmdknow if there is any difference with kvm enabled.20:26
daliasthat makes it pretty trivial20:26
stekernI get a flashback of me asking these question the other day ;)20:26
blueCmdstekern: pff20:26
blueCmdstekern: one person questioning this is nothing, two then I start to research ;)20:27
daliaswithout a lot of assumptions about the host's memory architecture and whatnot i don't think there's a clean way to actually emulate smp with multiple threads20:27
blueCmdright. so what Alpha does is that it actually loads the value and checks if the value is unchanged as well20:28
blueCmdI'm not sure if that is a hack or if the spec actually does that20:28
blueCmdbut it might be a compromise20:28
stekernthe qemu implementation you mean?20:29
daliasi don't think checking if the value is unchanges is a valid check20:29
daliasit's subject to ABA20:29
stekernyeah, me neither20:29
blueCmdno, but if it _has_ changed we know that another store was executed20:30
blueCmdit's a hack for us, sure - but it might be nice to lock down the errors20:30
blueCmdand it's pretty cheap20:30
stekernolofk: just a heads-up, I've pushed a couple of small cleanups to orpsoc-cores:
stekernwell, that's for anyone that's interested, not just olofk20:41
daliasthis is one reason a real CAS instruction is preferable :)20:41
stekernit's just not very nice implementation wise in a RISC-core20:44
blueCmdstekern: you will not believe this, but it seems to work better with real atomics20:54
blueCmdor whatever, "semi-fake"20:55
stekernI believe!20:57
stekerndo you have a gif for that proclamation?20:57
blueCmdstekern: haha you know me too well20:58
blueCmdI actually resisted, but if you crave it20:58
blueCmdstekern: <321:02
stekerntypos in Kconfig...21:03
blueCmdstekern: please please do a typo and write 'on a unicorn system'21:03
blueCmdalso, I think it's 'on a unicorn system *or* unsure'21:03
blueCmdI hate these guys: NETDEV WATCHDOG: eth0 (ethoc): transmit queue 0 timed out21:04
blueCmdand then my network dies21:04
stekernwell, the intent is *and*, but the description sucks (even without typos)21:04
blueCmdoh right21:05
blueCmdbecause if you're unsure about everything then you might be on multicore21:05
stekernif you are on a unicorn system and sure that you have the shadow file, you'll benefit from enabling that option21:05
blueCmd'Run Harry, run!'21:07
blueCmdoh, it jumped back to life (ethoc that is)21:07
blueCmd64 bytes from seq=12 ttl=64 time=1698.349 ms21:07
blueCmdsee my nice #ifdef there?21:10
blueCmdIt's there because my system doesn't boot with that enabled ;)21:11
stekernhmm, why?21:12
blueCmdI don't know, maybe my load is wrong in qemu21:14
stekernwe want shadowed register file in qemu too21:24
stekernyou can cheat and just make that area read/writeable spr21:24
stekern*over spr21:25
stekernamazing, I think I actually am done with everything I wanted to finish off today21:30
stekernnext on my todo list is to pull out the atomic insn related patches from my smp branch and see if I can attract Jonas attention with them...21:33
olofkstekern: Thanks for cleaning up that uart mess. I never got around to do that21:48
--- Log closed Wed Jul 23 00:00:31 2014

Generated by 2.15.2 by Marius Gedminas - find it at!