| --- Log opened Thu Sep 04 00:00:37 2014 | ||
| poke53281 | It's a pity. Either the games are too big, use opengl, need copyrighted data | 03:42 |
|---|---|---|
| poke53281 | or are terrible maintained. The intersection which fulfill all my criteria is rather small. | 03:42 |
| stekern | :/ | 04:44 |
| stekern | "too big", memory-wise? | 04:44 |
| stekern | or storage-size? | 04:45 |
| dalias | too big to put on jor1k image for clients to download :) | 04:47 |
| poke53281 | storage. Can't put a game there which needs 30MB to download | 04:47 |
| poke53281 | the memory is then a similar problem. But memory is solvable. | 04:48 |
| poke53281 | a major limit is gone. But it should still be below 5MB. | 04:48 |
| poke53281 | quake already takes 10MB compressed. | 04:49 |
| dalias | heh | 04:50 |
| dalias | quake on jor1k is going to be way too slow anyway | 04:50 |
| dalias | even doom is too slow | 04:50 |
| dalias | of course part of the problem is the resolution. isn't it set to 640x480 rather than the original 320x200 ? | 04:50 |
| poke53281 | yes therefore it does not really matter. Big games want run anyhow. | 04:50 |
| poke53281 | But prboom is actually playable on my computers | 04:51 |
| poke53281 | descent maybe. Let's see | 04:51 |
| poke53281 | Yes, it's 640x400 currently | 04:51 |
| poke53281 | This is also solvable. | 04:51 |
| stekern | prboom actually expects the resolution to be at least 640x400 | 04:53 |
| poke53281 | There are so many good open source dune 2 clones . But all of them need the original data. | 04:54 |
| poke53281 | Ok, who cares about it. | 04:55 |
| stekern | from where did you take the d1x-rebirth source? | 04:55 |
| stekern | I'm still fighting the __register_frame_info issue | 04:55 |
| poke53281 | http://www.dxx-rebirth.com/ | 04:56 |
| stekern | thanks | 04:57 |
| poke53281 | http://pastie.org/9525815 | 04:58 |
| poke53281 | I found another program today which is in the Mesa-demos, called fire. Also this ends with an pc at zero. | 04:58 |
| poke53281 | but dependencies are even worse | 04:58 |
| poke53281 | the CFLAGS don't matter here | 04:59 |
| poke53281 | http://pastie.org/9525820 | 05:01 |
| poke53281 | this one is right. One line was not complete | 05:01 |
| dalias | stekern, i really doubt that; if so it's a "new"[ish] change | 05:02 |
| dalias | i always ran it at 320x240 | 05:03 |
| poke53281 | yes, prboom was changed to run everywhere. | 05:03 |
| poke53281 | Believe it or not. They don't need assembler anymore in this port ;). | 05:04 |
| dalias | even the original source release did not need any asm | 05:05 |
| poke53281 | this is kind of unbelievable. Or they had one testing path in the source. | 05:05 |
| dalias | ? | 05:07 |
| poke53281 | one implementation of the renderer to test and one implementation for speed in asm. | 05:08 |
| -!- rjo_ is now known as rjo | 05:10 | |
| poke53281 | dalias: http://jor1k.com/maps.png | 05:11 |
| poke53281 | What do you think is the problem? | 05:11 |
| dalias | i'm not sure if there even was significant asm in the original. it surely wasn't needed | 05:11 |
| dalias | the key was the algorithms not asm | 05:12 |
| dalias | poke53281, what problem? | 05:12 |
| poke53281 | the mapping address 0x80000000 and 0x30000000 | 05:13 |
| dalias | the discrepency in mapping address is just because it happens to get mapped different places | 05:13 |
| dalias | with ASLR it will be different each time | 05:13 |
| dalias | actually the kernel is mapping the dynamic linker at an utterly unreasonable address when you invoke it directly tho | 05:14 |
| poke53281 | ASLR is not activated. | 05:14 |
| dalias | this would badly interfere with large main programs | 05:14 |
| dalias | if the main program is >= ~128 megs, it would be impossible to load with this mapping | 05:15 |
| dalias | so i think there's a bug in how the kernel is doing the mapping | 05:15 |
| poke53281 | Ok, so let's assume this is not a problem :) | 05:15 |
| dalias | it's idiotic that this logic is arch-specific anyway..... | 05:15 |
| poke53281 | I am used to the fact ldd gives me the correct binary for the binary. | 05:16 |
| dalias | this is part of why linux is so bloated -- duplicating the same logic for each arch/driver/filesystem/... over and over again, with subtle bugs in various ones :( | 05:16 |
| dalias | anyway | 05:16 |
| poke53281 | s/binary/mapping/ | 05:16 |
| dalias | what is the actual problem you're experiencing? | 05:17 |
| poke53281 | Well I had a bug and knew the pc where this bug occurred. | 05:17 |
| poke53281 | Then the question what's at this position in ram? | 05:17 |
| stekern | dalias: yes, it's a pure prboom requirement, I haven't looked at the code why it needs that | 05:17 |
| dalias | stekern, oh, maybe i patched it out on my builds... i vaguely remember doing something like that | 05:18 |
| poke53281 | The programs runs 1ms before it crashes. So can't look up the real /proc/id/maps mapping | 05:18 |
| dalias | well what address is the crash at ? | 05:18 |
| poke53281 | with uclibc it worked :) | 05:18 |
| poke53281 | that doesn't matter. Soomewhere at the shared libs. | 05:19 |
| dalias | well if you know the address you can find it | 05:19 |
| poke53281 | If ldd does not give me the correct addresses the problem is hard to find. | 05:19 |
| dalias | no | 05:19 |
| dalias | just look at the low bits of the address | 05:20 |
| dalias | pages are 8k, so bits 0-12 are fixed regardless of where libc.so gets mapped | 05:20 |
| dalias | :) | 05:20 |
| poke53281 | Ok, a more complicated example | 05:20 |
| stekern | dalias: ah, you were actually speaking specifically about prboom when you said "I always ran it at", I thought you meant doom in general | 05:20 |
| dalias | but anyway it's likely to be 0x30000000 | 05:21 |
| dalias | stekern, yes | 05:21 |
| dalias | my prboom builds had a few local patches like allowing additional actions to be mouse-button-bindable | 05:21 |
| poke53281 | http://pastie.org/9525850 | 05:22 |
| dalias | and i kinda remember something like the nonsensical 640x480 restriction which i probably patched out :) | 05:22 |
| poke53281 | the mapping of libSDL is already wrong in this ldd output. | 05:22 |
| poke53281 | At 0x30000000 libc starts and not libSDL. | 05:22 |
| dalias | *nod* | 05:22 |
| dalias | just offset them all by the size of libc.so mapping | 05:23 |
| dalias | and pester the kernel folks to fix this mapping bug | 05:23 |
| poke53281 | Yes. but I am very lazy. | 05:23 |
| dalias | mapping ET_DYN main program (ldso) should behave identically to mmap(), starting from just below stack and working down, with additional gaps if ASLR is enabled | 05:23 |
| dalias | mapping at 0x8000000 is nonsense | 05:24 |
| dalias | anyway if you just add the total size of the libc.so mapping to the later ones, i think you'll get the right addresses | 05:24 |
| dalias | alternatively, strace it and look at where the mmaps go | 05:25 |
| poke53281 | Yes, I did it in the end with strace. | 05:25 |
| dalias | did you find where it's crashing? | 05:25 |
| poke53281 | Yes, see the whole discussion the last 24 hours with stekern. | 05:26 |
| dalias | ah :( | 05:29 |
| dalias | utterly broken alignment and aliasing violations? fun... | 05:29 |
| poke53281 | But it took me 2-3 hours to find the correct position because I expected ldd is right. | 05:29 |
| dalias | ldd is right for how it gets mapped when you run the program via explicitly invoking ldso, which _should_ match how the kernel maps it | 05:30 |
| poke53281 | no, not this one. Before. This alignment stuff is another story not related to the problem. | 05:30 |
| stekern | I think I'm starting to vaguely understand where things go wrong. the main executable (d1x-rebirth) has a (weak) reference to __register_frame_info, and thus have an entry in it's plt for it. now, when the dynamic library (libz.so) is relocated, it picks this up and put that into the R_OR1K_GLOB_DAT reloc, but for the R_OR1K_JMP_SLOT it does not use that, but directly put the 0 in it | 05:30 |
| dalias | only because the kernel is buggy with regard to how it maps ET_DYN elf files on or1k does it differ | 05:30 |
| dalias | *sigh* why is __register_frame_info even being used? | 05:31 |
| dalias | this is old crap for the pre-init_array era... | 05:32 |
| dalias | which should not even be supported on new archs | 05:32 |
| dalias | erm, maybe not init_array, i think it's dl_iterate_phdr related | 05:32 |
| dalias | but it probably means you have a toolchain that's treating musl as if it were old and crappy rather than more modern than anything else :) | 05:33 |
| poke53281 | stekern: Probably I have found a simple example: https://www.libsdl.org/projects/fire/ | 05:34 |
| poke53281 | I get at the position with strace a pc to zero | 05:34 |
| stekern | dalias: I don't think it's actually used, but the references comes from this: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/crtstuff.c;h=9d5399acb5e005d6f041a13369a64468c8651f2c;hb=HEAD#l463 | 05:35 |
| dalias | i think something is wrong with relocs but it's not clear to me whether it's musl's fault of ld's fault | 05:35 |
| poke53281 | I get at the same position with strace a pc to zero | 05:35 |
| dalias | i don't think the weak reference to __register_frame_info making it into the main executable symbol table and PLT is right | 05:36 |
| stekern | dalias: I'm at the same position, I see where things go wrong, but I'm not at the point where I can really tell what's wrong | 05:36 |
| stekern | yeah, maybe not | 05:36 |
| dalias | if there's a weak reference, whether it resolves to null or not should be resolved at ld time | 05:37 |
| dalias | not dynamic link time | 05:37 |
| dalias | there is no way to give consistent results at dynamic link time, as far as i can tell | 05:37 |
| dalias | so i think this is a bug in ld... | 05:38 |
| poke53281 | stekern: When I include the -lgcc_s the "fire" demo works. So maybe this is an easier starting point | 05:38 |
| dalias | are you using shared libgcc? | 05:39 |
| poke53281 | For the moment it's a hack stekern suggested to get rid of the problem | 05:39 |
| dalias | objdump -x libgcc.a |grep '__register_frame_info$' | 05:40 |
| dalias | what does that show? | 05:40 |
| poke53281 | one minute | 05:41 |
| poke53281 | the native one nothing | 05:45 |
| poke53281 | the cross compiled libgcc.a also nothing | 05:46 |
| dalias | ok, i guess this means it's undefined | 05:48 |
| dalias | and thus should resolve to null | 05:48 |
| dalias | that seems correct -- the old method for registering eh_frame should not be needed | 05:48 |
| dalias | what seems wrong is that the weak reference is remaining | 05:48 |
| dalias | let me try a similar test on x86 | 05:48 |
| dalias | void foo() __attribute__((__weak__)); | 05:50 |
| dalias | int main() { if (foo) foo(); } | 05:50 |
| dalias | foo is resolved to null by ld | 05:51 |
| dalias | it's not left as a weak reference in the output executable | 05:51 |
| dalias | this program only has one reloc | 05:51 |
| dalias | 080494cc 00000407 R_386_JUMP_SLOT 00000000 __libc_start_main | 05:51 |
| dalias | see what it has if you compile it on or1k | 05:52 |
| poke53281 | readelf -r a.out gives me only the __libc_start_main | 05:56 |
| poke53281 | you can use the compile demo to test it. | 05:57 |
| dalias | :) | 05:57 |
| stekern | yes, but if you compile with -fPIC, the reloc will be there | 05:57 |
| dalias | *sigh* your terminal emulator is broken | 05:58 |
| dalias | backspace generates ^H | 05:58 |
| dalias | not ^? | 05:58 |
| stekern | http://pastie.org/9525894 | 05:58 |
| dalias | stekern, oh? let me check.. | 05:58 |
| stekern | (for or1k that is) | 05:59 |
| dalias | stekern, ah, weird... | 05:59 |
| dalias | happens on x86 too and it seems semantically wrong | 06:00 |
| stekern | happens on x86_64 too | 06:02 |
| stekern | ...and arm | 06:03 |
| dalias | but i get consistent results here from the dynamic linker | 06:03 |
| dalias | even with a shared library that also has the weak reference | 06:03 |
| poke53281 | dalias: Yes, the terminal is partly broken. Thanks to no good documentation I could find. But I don't know any terminal which is not broken. | 06:04 |
| dalias | poke53281, the ^H thing should be fairly easy to fix | 06:04 |
| dalias | it's a pain because you can't edit input in canonical mode | 06:05 |
| poke53281 | Ok, I will try to give the easiest example possible to reproduce the error. | 06:05 |
| poke53281 | Yes, I know | 06:05 |
| poke53281 | Isn't this normal ;) | 06:05 |
| dalias | so.. i think there may be a dynamic linker bug at work here | 06:05 |
| dalias | because it gives the right results on x86 | 06:06 |
| dalias | (both the main program and shared lib see the address of foo as 0) | 06:06 |
| dalias | ok this is also a gcc bug tho | 06:07 |
| dalias | __register_frame_info, if it exists, is a hidden function | 06:07 |
| dalias | but the reference to it does not have a visibility attribute | 06:08 |
| dalias | this is why the weak reference is allowed to persist | 06:08 |
| dalias | if it's properly marked hidden, the reference gets resolved to 0 at ld time, even with -fPIC | 06:08 |
| poke53281 | Hmm, does musl has a libpthread? | 06:14 |
| dalias | yes | 06:15 |
| dalias | it's an 8-byte .a file :) | 06:15 |
| dalias | because musl is not separated into gratuitous .so files that just add bugs and runtime bloat | 06:16 |
| poke53281 | Ok, because I delete all .a files when I build my image | 06:16 |
| dalias | that's a problem if you want to be able to build anything | 06:17 |
| dalias | they 8-byte .a files exist for a reason | 06:17 |
| dalias | because -lm, -lpthread, etc. are required to be valid options for linking | 06:17 |
| poke53281 | yes, mhh... thinking | 06:18 |
| dalias | you just want to omit libc.a, not *.a | 06:19 |
| dalias | (and you could do this more efficiently with --disable-static, i think) | 06:20 |
| poke53281 | yes, probably. | 06:21 |
| stekern | dalias: I'm also not able to reproduce with a smaller test case (your test + a .so with the same weak sym) | 06:21 |
| dalias | stekern, i made a test .so that contains a global ctor that printf's (void*)foo | 06:22 |
| dalias | and i got 0 | 06:22 |
| poke53281 | dalias, stekern: http://jor1k.com/jor1k/ | 06:23 |
| poke53281 | I have a folder fire there | 06:23 |
| poke53281 | ./fire will give you the error | 06:23 |
| poke53281 | interesting is now, if I compile it with jor1k it seems to work. | 06:24 |
| poke53281 | at least, I have two binaries to compare | 06:24 |
| stekern | I've got debug prints in src/ldso/dynlink.c and I can see from them that foo get resolved to 0 | 06:24 |
| stekern | that should be pretty equivalent to your test | 06:25 |
| stekern | but that's not what happens with d1x-rebirth, so something more is at play here | 06:25 |
| poke53281 | What I want to say, that at the moment it looks like that I get the problem when I cross compile. I have two 11k binaries with the same ldd output and one works, the other one not. | 06:34 |
| dalias | :-p | 06:36 |
| poke53281 | the crashing one has __register_frame as relocation, the working one not. | 06:37 |
| poke53281 | bad: cross compiled, good : native compiled | 06:38 |
| dalias | compare the crt files from your native and cross toolchains | 06:41 |
| dalias | (crtstart/crtend from gcc) | 06:41 |
| stekern | so, the difference from the simple test seem to be that foo does not end up in .dynsym, while __register_frame_info does | 06:46 |
| poke53281 | dalias, it's already late for me. Make it fast, what should I compare? | 06:50 |
| poke53281 | http://jor1k.com/sync/tarballs/doM4HjyWc2.tar.bz2 | 06:54 |
| poke53281 | this file contains both binaries. fire and firebackup | 06:54 |
| poke53281 | fire was compiled with the command "./compile" | 06:54 |
| poke53281 | firebackup cross compiled with configure && make | 06:55 |
| dalias | i can look... | 06:57 |
| dalias | hmm i don't have a toolchain tho :/ | 06:57 |
| poke53281 | stekern send a link in your mailing list | 06:57 |
| poke53281 | with a changed musl-cross. | 06:58 |
| poke53281 | https://github.com/skristiansson/musl-cross | 06:59 |
| dalias | 5: 00002778 0 FUNC WEAK DEFAULT UND __register_frame_info@GLIBC_2.0 (2) | 06:59 |
| dalias | that's telling | 06:59 |
| dalias | somehow glibc crap leaked in to your cross build.. | 07:00 |
| poke53281 | wow, how do you get the glibc text? | 07:02 |
| poke53281 | which command? | 07:02 |
| dalias | readelf -a firebackup | 07:02 |
| dalias | readelf is the only tool i have that can do anything on an or1k binary without having explicit support for or1k | 07:03 |
| stekern | that explains why that ends up in .dynsym and the simple 'foo' test didn't | 07:03 |
| dalias | hmm weird | 07:05 |
| dalias | the GLIBC_2.0 version comes from libgcc_s.so.1 | 07:05 |
| dalias | according to this | 07:05 |
| dalias | Version needs section '.gnu.version_r' contains 1 entries: | 07:05 |
| dalias | Addr: 0x00000000000025d8 Offset: 0x0005d8 Link: 3 (.dynstr) | 07:05 |
| dalias | 000000: Version: 1 File: libgcc_s.so.1 Cnt: 1 | 07:05 |
| dalias | 0x0010: Name: GLIBC_2.0 Flags: none Version: 2 | 07:05 |
| dalias | no idea what that's about | 07:06 |
| dalias | but it looks like the cross compiler did some nonsense with libgcc_s.so.1... | 07:06 |
| poke53281 | Ok, I feel really weird now and tired. Something really strange is going on. And funny only | 07:10 |
| poke53281 | for such special cases. | 07:10 |
| stekern | I'll do some more digging with this new-found info | 07:11 |
| poke53281 | How can glibc stuff be in such a file. I mean there are a lot of asserts to prevent such things. | 07:11 |
| poke53281 | in the end, I put in m own toolchain script some files in the wrong directory and it is all my fault. | 07:12 |
| poke53281 | Ok, I am away for the next 8 hours. Land of dreams. | 07:15 |
| stekern | sleep tight | 07:15 |
| poke53281 | ... | 07:16 |
| dalias | goodnight | 07:16 |
| stekern | hmm... I don't get the 'glibc crap' when I try to cross-compile fire.c | 07:28 |
| olofk | I think that poke53281 visited some shady site that infected him with glibc via a browser toolbar | 07:30 |
| dalias | :) | 07:31 |
| stekern | heh | 07:33 |
| olofk | What's crt, btw? Like crtstart, crtend and crt0.S | 07:50 |
| maxpaln | so, what's the recommended way of adding modules to the initramfs? | 10:17 |
| maxpaln | Having never played around with Linux admin before this is a new area to me - I can see a module called initramfs-tools which would appear to offer the necessary functionality. But before I dive in and start tweaking I thought I would double check I wasn't heading in the wrong direction from the start | 10:18 |
| olofk | maxpaln: The easiest way is to compile stuff and put it in arch/openrisc/support/initramfs and run make afterwards | 10:26 |
| olofk | The stuff in that directory is the initial file tree built into the kernel | 10:26 |
| maxpaln | I came to that conclusion too - good to have my suspicions confirmed :-) | 10:27 |
| olofk | So is antone going to show up at FPGA world. I know I should have mentioned this sooner | 10:28 |
| maxpaln | I wasn't sure if it would be as easy as redirecting the installation of a package to that directory - that seemed a little easy (and I was convinced some dependancies or some part of the module would be missing if I did that). I'll use the old fashioned way of diving in and making mistakes to get there :-) | 10:28 |
| olofk | Yes, once you're starting to have dependencies it gets more complicated. I haven't quite gotten there myself yet, so I'm no help | 10:31 |
| olofk | During my four years in the project I have barely run any applications other than a few simple test cases and booting linux for demonstrative purposes | 10:32 |
| stekern | maxpaln: 'module' == a piece of software in this context? | 11:09 |
| stekern | if you're going to build a larger system it's probably better to move away from the initramfs | 11:13 |
| _franck_ | maxpaln: I usually compile programs with --static so I don't need to install libraries in my initramfs | 11:30 |
| -!- trevorman_ is now known as trevorman | 11:51 | |
| _franck_ | olofk: as per wikipedia "crt" stands for "C runtime" | 12:22 |
| maxpaln | thanks all - I am not planning on doing anything particularly exciting. But I do want/need to be able to demonstrate activity on each of the peripherals attached to the processor. The purpose of me adding to the initramfs is to provide the tools to mount the SPI flash so I can read/write to it. | 12:29 |
| maxpaln | So in this case I'll probably just be adding mtd-utils (and/or maybe the ubifs equivalent) | 12:30 |
| stekern | crunchtime | 12:33 |
| maxpaln | aaaargh, how about that - I had the format for mount wrong. I had: | 12:44 |
| maxpaln | % mount -t jffs2 /dev/mtd2 /mnt/spi | 12:45 |
| maxpaln | the DEVICE shouldn't be a path - it is the name of the device. [slaps face] | 12:45 |
| maxpaln | so the actual command is: | 12:45 |
| maxpaln | % mount -t jffs2 mtd2 /mnt/spi | 12:45 |
| maxpaln | the error message from mount could have been a LOT more helpful. I actually found my old notes, I knew there was a reason I was taught to make them :-) | 12:46 |
| maxpaln | problem solves - modification to initramfs postponed for another day!! | 12:46 |
| olofk | Weird. I always use /dev/sda? for my laptop | 12:47 |
| maxpaln | yeah, I would have thought mount would have been clever enough to distinguish (or modify) but maybe there is a reason otherwise. | 12:47 |
| -!- Netsplit *.net <-> *.split quits: tariq786, heroux, maxpaln | 14:17 | |
| -!- heroux_ is now known as heroux | 14:17 | |
| -!- Netsplit over, joins: maxpaln | 14:17 | |
| maxpaln | ls -l | 14:36 |
| maxpaln | oops - wrong window :-) | 14:36 |
| maxpaln | hi, looking for advice on the linux device tree - not sure where to go for answers here. | 15:09 |
| maxpaln | The board has a Micron 1Gb Nand SPI Flash | 15:09 |
| maxpaln | I am happy enough that the driver for the SPI peripheral will be the simple_spi, but does anyone know what 'compatible' setting would be appropriate for the mtd section of the device tree? | 15:10 |
| maxpaln | The Documentation/devicetree/bindings/mtd has several nand based entries but none seem to quite match up with a Nand SPI Flash - as far as I can see. | 15:11 |
| maxpaln | I am thinking there must be at least one Nand SPI flash driver available in the linux kernel - it may not be fully compatible with the micron flash but I can use it as a starting point. | 15:15 |
| maxpaln | The generic 'nand' entry seems to be expecting an 8-bit or 16-bit flash device rather than a Nand SPI device (although I may be misreading the nand-bus-width entry) | 15:18 |
| maxpaln | hmmm, curious - several references to the micron device in drivers/mtd/nand - | 15:32 |
| maxpaln | I'll try the generic nand and see what happens!!! | 15:33 |
| poke53281 | stekern: You want to this say that this register_frame thingy is a problem of pop, a "problem of poke". | 16:40 |
| poke53281 | olofk: The problem is, that I have to use slightly different options than the musl-cross builder. | 16:45 |
| stekern | poke53281: not necessarily, when I cross-compiled, I did it by manually invoiking or1k-linux-musl-gcc, because the configure script in the .bz2 was corrupt | 17:01 |
| hesham | stekern: I think red-zone is more than 128 bytes, because I was still getting some error with this 128 byte zone, but when I increased it to 200, the error went away. | 17:16 |
| stekern | hesham: unless you pass something else, the default should be 128: https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.opt#L95 | 17:22 |
| hesham | Not sure what do you mean by "pass something else" | 17:25 |
| hesham | stekern: Well this is very weird :) When I increased the minimum zone area to 200, the program crash after 3 context switches, when I increased it to 256, it works as expected. Any clues for that? | 17:35 |
| stekern | hesham: the link I pasted shows a gcc commandline option (-mredzone=), which defaults to 128 if not specified | 17:54 |
| stekern | I would assume that increasing the amount just hide some bug | 17:55 |
| stekern | do you have the latest code that you are using now? | 17:55 |
| stekern | poke53281: also, when I cross-compiled, I used the gcc built from your scripts | 17:56 |
| hesham | stekern: The latest code (without the account for red-zone is there), I will give you a link, one sec | 17:58 |
| hesham | This corresponds to entry.S in linux https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/or1k/or1ksim/start/start.S | 18:00 |
| hesham | And this file for exception handling (ISR_Handler called from start.S) https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/or1k/or1k-exception-handler-low.S | 18:01 |
| poke53281 | stekern: When I recompile prboom I get now the same error. Looks like I did something really really wrong last week and mixed something in my code which does not belong there. | 18:06 |
| poke53281 | I should do a readelf -a for all my binaries and grep for glibc. | 18:07 |
| stekern | maybe olofk was right after all then ;) | 18:08 |
| poke53281 | infected by glibc. dalias should program a musl-doctor based on Weizenbaum's Eliza. | 18:12 |
| stekern | hesham: where do you account for it in your local code? | 18:19 |
| stekern | not that I can see any obvious bugs in the context save code | 18:19 |
| hesham | I do not have a clean local code for now, I will submit a patch and give you a link soon | 18:20 |
| stekern | ok, no worries | 18:25 |
| stekern | poke53281: time for some constructive criticism, 'make buildtools' tries to build or1k-src (and fails), shouldn't that be the binutils-gdb snapshot? | 18:31 |
| poke53281 | Right, error 1/1000. Try "make binutils2". | 18:35 |
| poke53281 | You will get an ice cream if we reach the 1000. | 18:35 |
| poke53281 | I removed binutils and renamed binutils2 to binutils. | 18:36 |
| stekern | what flavour? | 18:37 |
| poke53281 | to build the final image look at the script/filesystem.make file | 18:37 |
| poke53281 | chocolate is Ok? | 18:37 |
| poke53281 | Instead of having one sysroot I build packages. The I use patches/fs2xml to build my final filesystem out of those packages. | 18:38 |
| poke53281 | scripts/image.make is no longer valid and can be removed. | 18:38 |
| stekern | nope, vanilla is better then ;) | 18:39 |
| stekern | yeah, I saw that in packages/, it's a nice touch that you just can untar them into the fs | 18:39 |
| poke53281 | this helps a lot and would also work flawless. But this $@%&() libtool makes problems. I would vote libtool to be the most terrible tool in the open source scene. | 18:42 |
| poke53281 | I try to fix libtool. But it's imposible to read the code. | 18:42 |
| stekern | I'm approaching my ice cream, you're missing a 'make xcb-proto' in the X build instructions ;) | 18:46 |
| stekern | ...and libxcb I think | 18:47 |
| poke53281 | xcb-proto should be there if I read my code correctly. | 18:48 |
| poke53281 | But maybe at the wrong position. | 18:48 |
| poke53281 | the problem with those fixes is, that I have to remove the whole sysroot to really test them. | 18:48 |
| poke53281 | xcb-proto is the last in the PROTO_XLIBS variable. | 18:49 |
| poke53281 | libxcb is also the one in the "make xlibs" part. Maybe that is wrong too. | 18:50 |
| stekern | I'm hitting this when I try to build libxcb: https://bugs.freedesktop.org/show_bug.cgi?id=76557 | 18:50 |
| poke53281 | Hmm, the packages should be much older than this bug report. | 19:00 |
| poke53281 | From last year | 19:00 |
| poke53281 | python problem? The famous python2 python3 problem | 19:00 |
| poke53281 | so, this error is new for me | 19:01 |
| stekern | don't know, but isn't xcb-proto_1.11 newer than that bug report? | 19:05 |
| poke53281 | too lazy to look it up. | 19:10 |
| poke53281 | But I compiled it and it works. | 19:10 |
| stekern | I'll cheat in the meantime and use your packages ;) | 19:10 |
| poke53281 | But of course not from scratch. If you say, "poke, please, can you try to run your scripts from scratch. I have severe problems here.", then I will do it. | 19:11 |
| poke53281 | Note, that I use a chrooted archlinux system to compile | 19:12 |
| poke53281 | archlinux has always very very new software | 19:13 |
| poke53281 | But I have also a Debian here somewhere. | 19:16 |
| poke53281 | libxcb should be in libX11.tar.bz2 | 19:17 |
| stekern | ok, let's see if I can build with that | 19:20 |
| poke53281 | stekern: This is how the filesystem of jor1k is loaded: https://github.com/s-macke/jor1k-sysroot/blob/master/fs.xml | 19:29 |
| poke53281 | After I did the .xml file I realized that I cannot interpret them in a worker thread in Javascript. :( | 19:30 |
| poke53281 | So I had to write a tiny xml interpreter myself. | 19:30 |
| stekern | :) | 19:37 |
| stekern | hmm, how should I change startx to use the same event device for both keyboard and mouse? | 19:39 |
| poke53281 | ? Didn't know that this is possible. | 19:41 |
| poke53281 | " /usr/bin/Xfbdev :0 -wr -ac \ | 19:41 |
| poke53281 | -mouse tslib,,device=/dev/input/event1 \ | 19:41 |
| poke53281 | -keybd evdev,,device=/dev/input/event0 " | 19:41 |
| poke53281 | this is my startx command | 19:41 |
| poke53281 | so why not change the second line to: "-mouse evdev,,device=/dev/input/event0" ? | 19:42 |
| stekern | yes, but the keyboard doesn't work then | 19:43 |
| stekern | I'll figure it out, I just thought I'd ask in case you knew | 19:43 |
| stekern | in what package is libfontconfig.so? | 19:44 |
| poke53281 | Why not use two input events. Maybe I am wrong, but I don't think that the way you use the events is right. | 19:44 |
| stekern | well, why wouldn't you be able to have a device that can generate all kinds of events, both mouse and kbd? | 19:45 |
| stekern | ...and scummvm can handle it fine at least ;) | 19:45 |
| poke53281 | also in libX11fs | 19:45 |
| poke53281 | Also in libX11.tar.bz2 | 19:46 |
| poke53281 | I didn't want to have every libX library in a special package. X is already pretty huge. | 19:46 |
| poke53281 | If you are in doubt, just look in script/filesystem.make and search for the library. | 19:46 |
| stekern | oh.. I thought I had already extracted that, but I hadn't | 19:47 |
| poke53281 | Looks like you take the short/uncomplicated path. Just use my binaries. | 19:48 |
| stekern | yes, at least for now | 19:48 |
| poke53281 | that makes sense | 19:48 |
| stekern | I mean, why duplicate efforts ;) | 19:49 |
| poke53281 | Should work out of the box. Except mesa. This is compiled with -mhard-float | 19:49 |
| poke53281 | duplicate efforts to fix the errors. There is almost no one who could build with those script a full working image right now. | 19:50 |
| poke53281 | But no problem. I can compile mesa without this for now. | 19:50 |
| poke53281 | Only if you want of course. | 19:50 |
| poke53281 | twm and xinit are also important. | 19:51 |
| stekern | it's ok, I can rebuild that myself | 19:53 |
| poke53281 | stekern: success? | 20:45 |
| olofk | stekern: I was thinking about the FPU in mor1kx. Would it be feasible to create an external interface for connecting the FPU or does it have to be deeply embedded? I'm just thinking that it would be easier to manage the FPU as a stand-alone component, and it could also be swapped easier | 20:59 |
| hesham | stekern: Sorry for being late, this patch solves the problem of context switches (by accounting for red-zone) - https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/0001-or1k-account-for-red-zone-and-fix-printf-bug.patch | 21:02 |
| stekern | olofk: I think it is pretty stand-alone | 21:09 |
| stekern | there's just some 'hooks' into mor1kx | 21:09 |
| olofk | Would it make sense to provide these 'hooks' as external ports then? | 21:10 |
| stekern | poke53281: making progress, but I get this when I try to build xorg-server: /home/stefan/openrisc/rootfs/build/or1k-toolchain/sysroot/usr/include/GL/internal/dri_interface.h:51:17: fatal error: drm.h: No such file or directory | 21:10 |
| poke53281 | arghh, yes. The old problem. | 21:10 |
| poke53281 | make a dummy drm.h file | 21:11 |
| poke53281 | or better, patch dri_interface.h | 21:11 |
| poke53281 | that it doesn't use drm. I think this bug is solved in newer version Mesa. | 21:12 |
| poke53281 | This is one thing I still have to do manually. Too lazy to write a one-liner | 21:13 |
| stekern | olofk: I don't know... if there becomes several fpu implementations, perhaps | 21:14 |
| stekern | poke53281: I had a vague recollection of doing that before | 21:15 |
| poke53281 | yes, this bug is one year old :) | 21:15 |
| olofk | stekern: True. There is probably no idea doing that until we have at least two different impementations | 21:15 |
| poke53281 | But I stubmel over it only one time every year. | 21:16 |
| poke53281 | stumble | 21:16 |
| stekern | when I try to build X, right? =) | 21:16 |
| stekern | but, your X runs fine (with only mouse) | 21:17 |
| stekern | I need to build X to enable kdriver-mouse | 21:17 |
| poke53281 | Yes, when you build X :) | 21:17 |
| stekern | that way I can use /dev/input/mouse for the mouse and /dev/input/event0 for keyboard | 21:18 |
| stekern | ...or that's what I hope at least | 21:18 |
| poke53281 | a hack | 21:18 |
| poke53281 | Ok, so I will add kdriver-mouse too. It would be nice if my packages also work on other openrisc devices. | 21:19 |
| stekern | I found this: http://freera.sourceforge.net/ | 21:19 |
| stekern | a bit outdated, but compiles on my ws after removing -Wall and -Werror | 21:20 |
| poke53281 | "--enable-kdrive-mouse" ? | 21:20 |
| stekern | yes | 21:20 |
| poke53281 | Thanks, I will take a look on freera | 21:21 |
| poke53281 | any other configure switches which might be important? | 21:21 |
| poke53281 | for others | 21:22 |
| poke53281 | stekern: the suggested way to cross compile with scons is to change the path variable and link to another gcc or g++. To change the name of the compiler is not possible. ... pure fun | 22:20 |
| poke53281 | stekern, you know that redalert.mix has a size of 25MB? | 22:34 |
| poke53281 | the user would have to download 17MB | 22:46 |
| poke53281 | 13MB if I would switch to .xz files | 22:47 |
| --- Log closed Fri Sep 05 00:00:38 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
