IRC logs for #openrisc Friday, 2014-08-01

--- Log opened Fri Aug 01 00:00:45 2014
poke53282stekern: I was able to comüpile sdldoom. But it will probably take a few days until I can try it.03:17
poke53282stekern: Thanks for the musl port. Let me think if I will switch :)03:24
stekernpoke53282: you'll need the atomic insns in jor1k though, but I don't think it should be very hard to add.03:42
stekernsdldoom - yes, I've been able to compile it too, but it crashed when I tried to run it03:42
stekernI don't know if this might be a better option to try:
-!- Netsplit *.net <-> *.split quits: LoneTech03:47
poke53282stekern: something like this?04:21
poke53282I already did it one month ago.04:23
stekernpoke53282: ah, then there's nothing stopping you from using it ;)04:29
stekernexcept... those are fake atomics, right?04:30
poke53282But I hope, they are enough for busybox or something.04:32
poke53282I followed the patches for qemu.04:33
poke53282maybe I should take or1ksim04:34
stekernI think blueCmd have added proper (or properer) support in qemu now04:36
poke53282I see04:37
stekernusing fake ones will probably work to some point, but when they fail, it might be in subtle ways04:37
poke53282I will fix them04:38
poke53282Do you have a tiny c code to test them?04:44
daliasstekern, dunno if you saw the announcement -- i released musl 1.1.4 a few hours ago (obviously with or1k support :)04:45
stekerndalias: I saw, and I also posted an announcement about it to the openrisc mls =P04:47
stekernblueCmd: yes, I do as told, but usually with a bit of latency (ask my wife, she will support that statement). I did send it now though.07:11
_franck_blueCmd: are you sure I wrote some code in or1k-gcc ?07:18
blueCmd_franck_: you did, but looking at what you added it can be submitted under 'small changes' and you don't need to do anything really08:26
_franck_ah ok, great08:27
blueCmdstekern: great ;)08:32
-!- Netsplit *.net <-> *.split quits: aburgess10:11
HeshamFor verilator model configured with mor1kx-generic, are there memory configurations (i.e, its size) that I can modify for my application? I always get bus error exception (elf program expects there is 128 MB of memory).11:17
blueCmdHesham: you had all your gcc papers in order right?11:22
HeshamblueCmd: Yes11:25
blueCmdHesham: awesome11:32
blueCmd2.24.51.20140727 - cool, new release with all the goodies for binutils and debian11:48
blueCmdstekern: I'm happy to announce that the libgcc crash is solved11:57
blueCmdpoke53282: switched to use 9p rootfs now in my test setup12:10
blueCmddamn smooth, thanks for doing the dirty research and debugging there12:11
maxpalnnot much time to spend on this today - but my simulations are now running cleanly, althoug with the removal of the invalid tests this suite is looking pretty modest. I'd prefer to have more tests to run!15:07
maxpalnhowever, something isn't right because my Linux kernel doesn't boot - are there any specific requirements on compiling the linux kernel to work with the mor1kx processor? things that must be included, can't be included etc. compiler version to use and so on?15:08
blueCmdmaxpaln: let's start simple, how do you know it doesn't boot?15:08
maxpalnwell, I have a terminal - that normally displays the UART output from the Linux kernel15:09
maxpalnwith my or1200 processor this works fine15:09
maxpalnonce I switch to the mor1kx processor - nothing appears on the terminal15:09
maxpalnIn reality, I need to include the logic analyser and see why it isn't booting. But that is probably a job for next week - but I also wanted to check that there any pre-requisites from the SW side15:10
blueCmdmaxpaln: the only think I know of is that it's a bit different with the interrupt things and that your DTS should be updated to match15:10
maxpalnupdated how? At the moment I am attempting to use exactly the same binary as for the or1200 -15:11
maxpalnit was, perhaps, a naive decision but I thought it was worth a go :-)15:12
blueCmdmaxpaln: compare your DTS with
maxpalnblueCmd: thanks15:16
maxpalnwell, the obvious difference are those virtio_block's - I haven't seen those before and they aren't in my DTS. the de0_nano version doesn't have those so maybe they are something specific to this DTS setup.15:21
maxpalnOtherwise, everything else is the same -15:21
maxpalnI think this is something for a clearer head on Monday - I am sure a bit of time with the logic analyser will show the problem.15:21
blueCmdmaxpaln: yeah virtio is not relevant15:22
maxpalnok, well I think this must be a HW problem then - and that's definitely something to debug after the weekend! I'm not about to launch into that at 1630 on a Friday :-)15:23
maxpalnhave a good weekend all -15:23
blueCmdmaxpaln: you too!15:26
stekernmaxpaln, the exact same lernel shpuld work on or1200 and mor1kx15:47
blueCmdsometimes I wonder why we let you program CPUs15:49
poke53282blueCmd: You are welcome. The /dev/root solution worked?15:51
poke53282You can also think of using the virtio network device if you think, that the ethoc has problems. Just to test if the driver is the problem or not.15:52
blueCmdpoke53282: yep15:52
blueCmdpoke53282: ooh15:52
blueCmdpoke53282: yes, I'll surely do that. thanks, I never considered doing that15:52
poke53282you can do the same with the console and hey, why not try some graphics devices over virtio-pci16:01
poke53282Maybe there is manual somewhere.16:01
poke53282Maybe this one:
blueCmdnot sure LE/BE would be superhappy there16:22
stekernblueCmd: I don't program CPUs from my crappy windows phone, I only IRC from it ;)16:25
stekernjust got back from 2 hours at assembly16:25
stekernI'm disappointed, I didn't see a single line of code16:26
stekernjust games16:26
stekernand I essentially walked by everyones computer there16:26
blueCmd much better :P16:27
stekernthe music fast compo was at the time I was there, there was some good tunes there though16:27
stekernyeah, but dreamhack has always been a "get together and play games" event, no?16:30
stekernwhile assembly was a cool demoparty in the mid-90's16:32
daliasbluecmd, what was the libgcc issue?17:06
daliashave you been able to verify that the symbols in the final libgcc.a are hidden?17:06
dalias(a simple check is to make sure that they don't appear in nm -D
stekerndalias: it works for him when he use my hack to remove the rel26 relocs17:15
stekernso it's only 'solved' in that sense that it's confirmed that that's the issue17:16
daliaswhat about just changing the calles to plt()17:16
stekernbut then we'll get GOT refs, which was what we wanted to avoid in the first place17:16
daliasi don't think so17:17
daliasplt() just generates a reloc that causes ld to generate a stub to call the real function if it doesn't resolve the address to a fixed 26-bit offset at ld-time17:17
stekernyeah, true17:17
stekernok, so that's actually worth a try17:18
daliasso if the actual definition is hidden, or if it's in the main program, or if you use -Bsymbolic, etc. no plt thunk will get generated17:18
daliasthis is just like the code in _dlstart17:18
daliasyou use plt() for the calls but obviously there is no working GOT at that point17:18
stekernmmm, that is indeed a valid point17:18
daliasbecause plt() doesn't really mean "use the plt"17:19
daliasit means "this is a relocation for a relative call to a function that might not be able to be resolved, or might not resolve to something within the 26-bit range, at ld-time"17:19
stekern...and if that doesn't work for some reason, we can at least make my hack less ugly by turning the main part of divsi3 into a .macro instead of the ugly #ifdefs17:20
daliasthe important information it's carrying vs a plain use of the symbol name and a non-plt-type relocation is that the symbol is a function and it's being used for making a call. you can't thunk symbol references like that in general because they might be data17:21
stekernit will still bloat the functions though17:21
stekern^ (speaking about ugly/slightly less ugly hacks)17:22
blueCmd     4: 00000000   252 FUNC    GLOBAL HIDDEN     1 __udivsi317:25
blueCmdthat is how I formated your patch19:06
blueCmdlet me know if you want to change it19:06
blueCmdstekern: I would also appriciate some help with going through and looking at the failures. especially those that also are on
stekernblueCmd: oh, I want to change it ;) I wanna find the proper fix for it, but feel free to keep it like that until then21:20
stekernand sure, I'll be happy to give a hand in trying to figure out the failing tests21:21
stekernI'm trying to get this dual-core to be stable on the sockit though, because I'd like to then run the regression tests against that21:23
stekernI just crushed one little bug...21:28
blueCmdstekern: SGTM, I will probably initiate the code review process before we have fixed all the quirks though. I'll do "bluecmd-lint --super-picky=9000" and reformat everything, so if you have patches you want to have in let me know21:31
blueCmdor you will be in merge conflict hell21:32
stekernwell, I'm pretty sure we don't want it like *that* at least21:34
stekernbut I think we can manage merging that single file at any point21:34
blueCmdyeah, that file itself is no problem21:35
blueCmdbut if you have a new dynamic linking patch or something that you have stashed somewhere, now would be the time to tell me :)21:35
stekernI don't have anything hidden away in any local branches here21:35
stekernat least none that I recall working on ;)21:36
stekernI've had a few of those "did *I* do these changes?" moments you were speaking about the other day21:37
blueCmdlooks like the effort put into atomics and refreshing glibcs paid off21:38
blueCmdfrom udev hanging on startup and debian being broken, first boot in months just "worked"21:38
blueCmdsome weird warnings, but nobody cares about warnings - right?21:39
blueCmdrun-parts: failed to open directory /etc/network/if-up.d: Value too large for defined data type21:41
blueCmdwe've seen that before21:41
daliasbluecmd, i think it means you're using 32-bit off_t/ino_t and stat() failed21:54
blueCmddalias: have I ever told you how much I appriciate that you're around? :P21:54
daliasshould not happen on musl but can easily happen with glibc21:54
daliascompiling with glibc, -D_FILE_OFFSET_BITS=64 is mandatory21:54
blueCmdyou're awesome, saving me hours upon hours on debugging :)21:54
daliaswithout it you'll experience random failures21:54
daliasthis is basically the kernel folks giving the finger to glibc's broken default :)21:55
blueCmddalias: ah right, that flag21:55
daliasonce they started implementing filesystems in ways such that ino_t sometimes doesn't fit in 32 bits, it was game-over for the old 32-bit-off_t/ino_t abi21:56
daliasand glibc is still lagging on fixing the default to be 64-bit21:56
stekernah, blueCmd, remember that we deduced that too a couple of months back?21:58
blueCmdstekern: yes21:58
blueCmdi didn't remember that the error was that flag though, but it came back to me when dalias said it21:58
blueCmdstekern: but that took a *slight* bit longer21:59
blueCmdfor us to figure that out :P21:59
daliasyeah i just know the string for EOVERFLOW and the few places it can arise in21:59
daliasand they mostly relate to off_t21:59
stekernheh, yes, it took us a day or two to dig us through glibc's macros to figure out what was actually being used22:01
blueCmd.NET programmer is all "OMG WE PATCHED SOMETHING" because they patched a binary :P22:32
--- Log closed Sat Aug 02 00:00:46 2014

Generated by 2.15.2 by Marius Gedminas - find it at!