IRC logs for #openrisc Saturday, 2016-11-12

--- Log opened Sat Nov 12 00:00:39 2016
shornesorry, havving some connection issues02:55
shornestekern: Do you know why we selected the semctl patch for priority? "Apply transparent_union attribute to union semun  "02:57
shorneI was doing some testing and it seems with musl as least semctl works02:57
shornemusl will actually bas the semun data to linux, not a union (so no abi issues)02:57
shorneI was wonding if you know of a specific issue there02:59
shorneolofk: for the stdin in newlib, where would stdin come from? Usually with newlib there is no os, and just one process, usually stdin comes from another proc?02:59
shornebut I do know there is some linux support for newlib, but I dont think I ever compiled with that.02:59
stekernshorne: AFAIU, the problem is completely on the linux side03:01
stekernit could be that the underlying problem actually has gone away03:02
shornestekern: right, I think my explaination was a bit bad.  The issue is kernel expects to receive the union data in the function argument.07:08
shorneBut openrisc will pass references in the syscall arguments (if arguments were passed un changed)07:09
shorne1. I did some tests with musl userspace programs calling the sem api and I dont see any issues07:10
shorne2. When looking into it I found the itnerface is like (user program)->(musl)->(kernel)07:10
shornemusl has some logic to take the union (however its passed and ensure the data is passed to linux.  So it seem musl provides a pretty good compatibility layer07:11
shorneSo my question is, do you know who might have reported this as a problem?07:12
shornemaybe it was on uLibc07:12
shornei mean uClibc07:12
shornelooks ok to me in uclibc too:07:15
shornenotice they take a union but then the pas the arg.__pad07:15
shorneso linux abi would not have an issue with that07:16
shorneI dropped the patch from my set for now07:16
shorneI cant reproduce any issue as its explained in the commit07:17
@olofkshorne: stdout is hooked up to uart on most boards (for printf etc). The stdin side was however not hooked up correctly. Not sure if  that still is the case07:23
@olofkshorne: Regarding the patch, could it be glibc perhaps? blueCmd and mafm were involved with getting that running to support Debian07:24
shorneolofk: right, it could be glibc too. ill have a look at that code too.07:49
shorneregarding stdin what would it be connected to?07:49
ZipCPU|LaptopWhy not connect stdin to 1) the terminal the emulator is running from, or 2) a uart on the device?07:50
ZipCPU|LaptopAs an alternative, I suppose you could connect it to a TCP/IP port somewhere else.07:51
ZipCPU|LaptopThe wbuart32 core allows connecting the terminal emulator (using Verilator) to either a TCP/IP port or stdin.07:52
ZipCPU|LaptopFurther, it works based upon the UART wires to/from the core that would allow the core to work just as well in hardware with the same code.07:52
wbxshorne: where I can get your latest used kernel source? was the problem you had kernel related?07:57
wbxshorne: can you list all used versions to build a running musl based system booting in or1ksim?08:03
shorneZipCPU|Laptop: olofk: right I guess for uart you would want to receive uart input via stdin. doh08:12
shornewbx: the issue I had was kernel related.  but if you are using the latest from openrisc/linux you should be fine.  I am working on widdling down the kernel to minimum patchset needed to run upstream linux (curently running v4.9-rc4)08:14
shornebusybox: git://
shornemusl-cross: (or1k)08:18
shornemusl-cross I have updated `` to point to 5.4.008:18
wbxshorne: thx. i try08:54
wbxshorne: so latest is fine?08:56
wbxshorne: hash: acba10ee627d6fd7001d3617dc735ec1caa654f608:57
stekernshorne: I agree with your description after looking at it too, maybe there was an issue with uclibc at some point09:00
shornewbx: yes, that version of linux should be fine too09:04
shornewbx: I debugged my issue by running on or1ksim and turnning on tracing to see where the system got hung09:05
shorne1. start program that hangs09:05
shorne2. in sim do `ctrl-c`09:05
shorne3. in sim `t` to trace until you see what is going on09:05
shornethere might be better ways to do it09:06
shorneI patched the sim a bit to allow `unstall` to resume running and dump trace details09:06
wbxshorne: thanks for the hints, will try tracing09:07
shornestekern: yup, also as olofk mentioned the patch might be for glibc which some people were working on to get debian running.09:07
shorneit even looks like for glibc each arch can have its own wrapper
shornesorry that was shm, but example for sem09:19
stekernshorne: that was way before glibc work09:23
shornealright, didnt know that09:26
shornebut it looks to me like that compatibility could (and is) handled by libc layer09:26
shorneso should be ok09:27
wbxshorne: thx. with busybox ash i get a shell. so I have problem with my default shell mksh ..10:29
wbxshorne: does strace works for you?10:44
shornewbx: yes strace works the issue I was facing was missing patch "a966c95 openrisc: include l.swa in check for write data pagefault"16:49
shornewbx: actually with musl I coult not compile ash so i disabled it. (was failing due to missing glob support in musl, i think)16:51
shornewbx: what is mksh (miros bsd shell)?  So you build seperately and run it?16:54
--- Log closed Sun Nov 13 00:00:40 2016

Generated by 2.15.2 by Marius Gedminas - find it at!