IRC logs for #openrisc Saturday, 2017-01-07

--- Log opened Sat Jan 07 00:00:02 2017
shorne_wbx: olofk: are the de0 nano bitstreams timelocked?  I seem to have to rebuild every few months or the the stream doesnt load correct?01:11
shorne_Because I have a free internet license?01:11
shorne_wallento: sorry I didnt look into the using multicore by default question, I dont really know what it will impact or why we need one or not?  Which hardware/socs/fusesoc's support multicore openrisc right now?  I have only ever used single core.01:13
-!- shorne_ is now known as shorne01:15
wallentoshorne, mor1kx supports multicore by default, while not many may use it01:43
wallentothe impact is limited but there, in the exception handling and for reentranc01:43
wallentoits an extra lookup01:43
wallentobut as olofk said reentrancy in itself already has an impact01:44
wallentoso the extra two instructions are okay IMHO01:44
wallentoand long term we may deprecate the single core version then01:44
shornethe lwa/swa instructions?01:51
shornewallento: it seems ok to me, is there a way to check if my build uses multicore? I use the instructions on the newlib page.01:53
shorneand muls/cross01:53
shorneboth gccs generate the lwa/swa code01:54
shorneAnyway, I am working on testing the futex's but getting SEGV. in the test02:01
shorneI traced it via printfs to line 34702:01
shornewhich doesnt make sense pthread_join(waker, NULL);02:01
shorneIssue could be, linux, musl or something02:02
shornewill post more details if anyone is interested02:03
shorneI cant use gdb really because no gdb can debug openrisc linux processes yet02:03
wallentoshorne: the multicore instructions are separate02:41
wallentothe first frew instructions differ in crt0.S02:41
wallentomulticore does writes to 0x402:41
shorneor right, the shadow regs03:11
shornenon uni processor writes to 0x4 I believe03:11
shorneI mean uni processor writes to 0x4 address, instead of shadow03:12
shornemeaning re-entry not possible03:12
shornethen it seems multicore has some exception stack at 0x403:13
shorneno... thats wrong, it stored nesting level at _or1k_exception_level03:14
olofkshorne: Weird. I think the bitstreams shouldn't have any timelocking built in18:14
shornefinally, making some progress on this pthread/futex testing SEGV22:26
shorneI dont have a debugger, so I modified the linux kernel to return the offending PC when it hits SEGV22:27
shorneand got a line in pthread_join22:27
shornewhich is where my debug printf pointed me, so im on the right track, and I ahve the exact offending instruction in MUSL22:28
shorneon my machine "8d708:       d4 12 18 00     l.sw 0(r18),r3"22:28
shornewhat is r18, and why is is 0...22:29
shorneit looks like the 2nd arg to pthread_join which is NULL22:31
shorne  if (res)...22:35
shorneit should check for null, the **res delcairation looks strange22:35
shorneIll try to update musl, I see there are lots of patches related to futex in MUSL since the version I have22:43
--- Log closed Sun Jan 08 00:00:04 2017

Generated by 2.15.2 by Marius Gedminas - find it at!