| --- Log opened Fri Aug 01 00:00:45 2014 | ||
| poke53282 | stekern: I was able to comüpile sdldoom. But it will probably take a few days until I can try it. | 03:17 |
|---|---|---|
| poke53282 | stekern: Thanks for the musl port. Let me think if I will switch :) | 03:24 |
| stekern | poke53282: you'll need the atomic insns in jor1k though, but I don't think it should be very hard to add. | 03:42 |
| stekern | sdldoom - yes, I've been able to compile it too, but it crashed when I tried to run it | 03:42 |
| stekern | I don't know if this might be a better option to try: http://prboom.sourceforge.net/ | 03:43 |
| -!- Netsplit *.net <-> *.split quits: LoneTech | 03:47 | |
| poke53282 | https://github.com/s-macke/jor1k/commit/b3beb982d9ceee4d80ccc734cffd39c73eb1a6c2 | 04:21 |
| poke53282 | stekern: something like this? | 04:21 |
| poke53282 | I already did it one month ago. | 04:23 |
| stekern | poke53282: ah, then there's nothing stopping you from using it ;) | 04:29 |
| stekern | except... those are fake atomics, right? | 04:30 |
| poke53282 | Yes | 04:31 |
| poke53282 | But I hope, they are enough for busybox or something. | 04:32 |
| poke53282 | I followed the patches for qemu. | 04:33 |
| poke53282 | maybe I should take or1ksim | 04:34 |
| stekern | I think blueCmd have added proper (or properer) support in qemu now | 04:36 |
| poke53282 | https://github.com/bluecmd/or1k-qemu/commit/7c2640d2ac321eb970250b389c77fe60c7e98834 | 04:37 |
| poke53282 | I see | 04:37 |
| stekern | using fake ones will probably work to some point, but when they fail, it might be in subtle ways | 04:37 |
| poke53282 | I will fix them | 04:38 |
| poke53282 | Do you have a tiny c code to test them? | 04:44 |
| dalias | stekern, dunno if you saw the announcement -- i released musl 1.1.4 a few hours ago (obviously with or1k support :) | 04:45 |
| stekern | poke53282: https://github.com/openrisc/or1ksim/blob/or1k-master/testsuite/test-code-or1k/atomic/atomic.S | 04:45 |
| poke53282 | thanks | 04:46 |
| stekern | dalias: I saw, and I also posted an announcement about it to the openrisc mls =P | 04:47 |
| stekern | http://lists.openrisc.net/pipermail/openrisc/2014-August/002266.html | 04:47 |
| dalias | great | 04:47 |
| stekern | blueCmd: 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 really | 08:26 |
| _franck_ | ah ok, great | 08:27 |
| blueCmd | _franck_: https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/ChangeLog.or1k#L1 | 08:29 |
| blueCmd | stekern: great ;) | 08:32 |
| -!- Netsplit *.net <-> *.split quits: aburgess | 10:11 | |
| Hesham | For 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 |
| blueCmd | Hesham: you had all your gcc papers in order right? | 11:22 |
| Hesham | blueCmd: Yes | 11:25 |
| blueCmd | Hesham: awesome | 11:32 |
| blueCmd | 2.24.51.20140727 - cool, new release with all the goodies for binutils and debian | 11:48 |
| blueCmd | stekern: I'm happy to announce that the libgcc crash is solved | 11:57 |
| blueCmd | poke53282: switched to use 9p rootfs now in my test setup | 12:10 |
| blueCmd | damn smooth, thanks for doing the dirty research and debugging there | 12:11 |
| maxpaln | not 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 |
| maxpaln | however, 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 |
| blueCmd | maxpaln: let's start simple, how do you know it doesn't boot? | 15:08 |
| maxpaln | well, I have a terminal - that normally displays the UART output from the Linux kernel | 15:09 |
| maxpaln | with my or1200 processor this works fine | 15:09 |
| maxpaln | once I switch to the mor1kx processor - nothing appears on the terminal | 15:09 |
| maxpaln | In 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 side | 15:10 |
| blueCmd | maxpaln: 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 match | 15:10 |
| maxpaln | updated how? At the moment I am attempting to use exactly the same binary as for the or1200 - | 15:11 |
| maxpaln | it was, perhaps, a naive decision but I thought it was worth a go :-) | 15:12 |
| blueCmd | maxpaln: compare your DTS with https://github.com/bluecmd/or1k-linux/blob/smp/arch/openrisc/boot/dts/or1ksim.dts | 15:15 |
| maxpaln | blueCmd: thanks | 15:16 |
| maxpaln | well, 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 |
| maxpaln | Otherwise, everything else is the same - | 15:21 |
| maxpaln | I 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 |
| blueCmd | maxpaln: yeah virtio is not relevant | 15:22 |
| maxpaln | ok, 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 |
| maxpaln | have a good weekend all - | 15:23 |
| blueCmd | maxpaln: you too! | 15:26 |
| stekern | maxpaln, the exact same lernel shpuld work on or1200 and mor1kx | 15:47 |
| blueCmd | lernel | 15:49 |
| blueCmd | sometimes I wonder why we let you program CPUs | 15:49 |
| blueCmd | ;) | 15:50 |
| poke53282 | blueCmd: You are welcome. The /dev/root solution worked? | 15:51 |
| poke53282 | You 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 |
| blueCmd | poke53282: yep | 15:52 |
| blueCmd | poke53282: ooh | 15:52 |
| blueCmd | poke53282: yes, I'll surely do that. thanks, I never considered doing that | 15:52 |
| poke53282 | you can do the same with the console and hey, why not try some graphics devices over virtio-pci | 16:01 |
| poke53282 | Maybe there is manual somewhere. | 16:01 |
| poke53282 | http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.html | 16:02 |
| poke53282 | Maybe this one: https://bbs.archlinux.org/viewtopic.php?id=162768 | 16:07 |
| blueCmd | haha | 16:21 |
| blueCmd | not sure LE/BE would be superhappy there | 16:22 |
| stekern | blueCmd: I don't program CPUs from my crappy windows phone, I only IRC from it ;) | 16:25 |
| stekern | just got back from 2 hours at assembly | 16:25 |
| stekern | I'm disappointed, I didn't see a single line of code | 16:26 |
| stekern | just games | 16:26 |
| stekern | and I essentially walked by everyones computer there | 16:26 |
| blueCmd | ah | 16:27 |
| blueCmd | https://www.youtube.com/watch?v=XN8KEjkVxP0 much better :P | 16:27 |
| stekern | the music fast compo was at the time I was there, there was some good tunes there though | 16:27 |
| stekern | yeah, but dreamhack has always been a "get together and play games" event, no? | 16:30 |
| stekern | while assembly was a cool demoparty in the mid-90's | 16:32 |
| dalias | bluecmd, what was the libgcc issue? | 17:06 |
| dalias | have 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 libc.so) | 17:06 |
| stekern | dalias: it works for him when he use my hack to remove the rel26 relocs | 17:15 |
| stekern | so it's only 'solved' in that sense that it's confirmed that that's the issue | 17:16 |
| dalias | :) | 17:16 |
| dalias | what about just changing the calles to plt() | 17:16 |
| dalias | calls* | 17:16 |
| stekern | but then we'll get GOT refs, which was what we wanted to avoid in the first place | 17:16 |
| dalias | i don't think so | 17:17 |
| dalias | plt() 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-time | 17:17 |
| stekern | yeah, true | 17:17 |
| stekern | ok, so that's actually worth a try | 17:18 |
| dalias | so 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 generated | 17:18 |
| dalias | this is just like the code in _dlstart | 17:18 |
| stekern | right | 17:18 |
| dalias | you use plt() for the calls but obviously there is no working GOT at that point | 17:18 |
| stekern | mmm, that is indeed a valid point | 17:18 |
| dalias | because plt() doesn't really mean "use the plt" | 17:19 |
| dalias | it 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 | yes | 17:20 |
| 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 #ifdefs | 17:20 |
| dalias | the 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 data | 17:21 |
| stekern | it will still bloat the functions though | 17:21 |
| stekern | ^ (speaking about ugly/slightly less ugly hacks) | 17:22 |
| blueCmd | dalias: | 17:25 |
| blueCmd | 4: 00000000 252 FUNC GLOBAL HIDDEN 1 __udivsi3 | 17:25 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-gcc/blob/409f9560dbca6bda73d75ec481a427356dba8121/libgcc/config/or1k/or1k.S | 19:06 |
| blueCmd | that is how I formated your patch | 19:06 |
| blueCmd | let me know if you want to change it | 19:06 |
| blueCmd | stekern: I would also appriciate some help with going through http://openrisc.debian.net/tmp/gcc-test-jul-25/gcc.fail and looking at the failures. especially those that also are on http://openrisc.debian.net/tmp/opencores/opencores.org/or1k/UClibc_tool_chain_test_results.html | 19:08 |
| stekern | blueCmd: oh, I want to change it ;) I wanna find the proper fix for it, but feel free to keep it like that until then | 21:20 |
| stekern | and sure, I'll be happy to give a hand in trying to figure out the failing tests | 21:21 |
| stekern | I'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 that | 21:23 |
| stekern | I just crushed one little bug... | 21:28 |
| blueCmd | stekern: 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 know | 21:31 |
| blueCmd | or you will be in merge conflict hell | 21:32 |
| stekern | well, I'm pretty sure we don't want it like *that* at least | 21:34 |
| stekern | but I think we can manage merging that single file at any point | 21:34 |
| blueCmd | yeah, that file itself is no problem | 21:35 |
| blueCmd | but 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 |
| stekern | I don't have anything hidden away in any local branches here | 21:35 |
| stekern | at least none that I recall working on ;) | 21:36 |
| stekern | I've had a few of those "did *I* do these changes?" moments you were speaking about the other day | 21:37 |
| blueCmd | haha | 21:37 |
| blueCmd | yes | 21:37 |
| blueCmd | looks like the effort put into atomics and refreshing glibcs paid off | 21:38 |
| blueCmd | from udev hanging on startup and debian being broken, first boot in months just "worked" | 21:38 |
| blueCmd | some weird warnings, but nobody cares about warnings - right? | 21:39 |
| blueCmd | run-parts: failed to open directory /etc/network/if-up.d: Value too large for defined data type | 21:41 |
| blueCmd | we've seen that before | 21:41 |
| stekern | nice | 21:52 |
| dalias | bluecmd, i think it means you're using 32-bit off_t/ino_t and stat() failed | 21:54 |
| blueCmd | dalias: have I ever told you how much I appriciate that you're around? :P | 21:54 |
| dalias | should not happen on musl but can easily happen with glibc | 21:54 |
| dalias | compiling with glibc, -D_FILE_OFFSET_BITS=64 is mandatory | 21:54 |
| blueCmd | you're awesome, saving me hours upon hours on debugging :) | 21:54 |
| dalias | without it you'll experience random failures | 21:54 |
| dalias | :) | 21:55 |
| dalias | this is basically the kernel folks giving the finger to glibc's broken default :) | 21:55 |
| blueCmd | dalias: ah right, that flag | 21:55 |
| dalias | once 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 abi | 21:56 |
| dalias | and glibc is still lagging on fixing the default to be 64-bit | 21:56 |
| stekern | ah, blueCmd, remember that we deduced that too a couple of months back? | 21:58 |
| blueCmd | stekern: yes | 21:58 |
| blueCmd | i didn't remember that the error was that flag though, but it came back to me when dalias said it | 21:58 |
| blueCmd | stekern: but that took a *slight* bit longer | 21:59 |
| blueCmd | for us to figure that out :P | 21:59 |
| dalias | yeah i just know the string for EOVERFLOW and the few places it can arise in | 21:59 |
| dalias | and they mostly relate to off_t | 21:59 |
| stekern | heh, yes, it took us a day or two to dig us through glibc's macros to figure out what was actually being used | 22:01 |
| blueCmd | http://blog.nullspace.io/clr-bug.html | 22:32 |
| blueCmd | cute | 22:32 |
| blueCmd | .NET programmer is all "OMG WE PATCHED SOMETHING" because they patched a binary :P | 22:32 |
| --- Log closed Sat Aug 02 00:00:46 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!