IRC logs for #openrisc Thursday, 2014-09-04

--- Log opened Thu Sep 04 00:00:37 2014
poke53281It's a pity. Either the games are too big, use opengl, need copyrighted data03:42
poke53281or are terrible maintained. The intersection which fulfill all my criteria is rather small.03:42
stekern"too big", memory-wise?04:44
stekernor storage-size?04:45
daliastoo big to put on jor1k image for clients to download :)04:47
poke53281storage. Can't put a game there which needs 30MB to download04:47
poke53281the memory is then a similar problem. But memory is solvable.04:48
poke53281a major limit is gone. But it should still be below 5MB.04:48
poke53281quake already takes 10MB compressed.04:49
daliasquake on jor1k is going to be way too slow anyway04:50
daliaseven doom is too slow04:50
daliasof course part of the problem is the resolution. isn't it set to 640x480 rather than the original 320x200 ?04:50
poke53281yes therefore it does not really matter. Big games want run anyhow.04:50
poke53281But prboom is actually playable on my computers04:51
poke53281descent maybe. Let's see04:51
poke53281Yes, it's 640x400 currently04:51
poke53281This is also solvable.04:51
stekernprboom actually expects the resolution to be at least 640x40004:53
poke53281There are so many good open source dune 2 clones . But all of them need the original data.04:54
poke53281Ok, who cares about it.04:55
stekernfrom where did you take the d1x-rebirth source?04:55
stekernI'm still fighting the __register_frame_info issue04:55
poke53281I found another program today which is in the Mesa-demos, called fire. Also this ends with an pc at zero.04:58
poke53281but dependencies are even worse04:58
poke53281the CFLAGS don't matter here04:59
poke53281this one is right. One line was not complete05:01
daliasstekern, i really doubt that; if so it's a "new"[ish] change05:02
daliasi always ran it at 320x24005:03
poke53281yes, prboom was changed to run everywhere.05:03
poke53281Believe it or not. They don't need assembler anymore in this port ;).05:04
daliaseven the original source release did not need any asm05:05
poke53281this is kind of unbelievable. Or they had one testing path in the source.05:05
poke53281one implementation of the renderer to test and one implementation for speed in asm.05:08
-!- rjo_ is now known as rjo05:10
poke53281What do you think is the problem?05:11
daliasi'm not sure if there even was significant asm in the original. it surely wasn't needed05:11
daliasthe key was the algorithms not asm05:12
daliaspoke53281, what problem?05:12
poke53281the mapping address 0x80000000 and 0x3000000005:13
daliasthe discrepency in mapping address is just because it happens to get mapped different places05:13
daliaswith ASLR it will be different each time05:13
daliasactually the kernel is mapping the dynamic linker at an utterly unreasonable address when you invoke it directly tho05:14
poke53281ASLR is not activated.05:14
daliasthis would badly interfere with large main programs05:14
daliasif the main program is >= ~128 megs, it would be impossible to load with this mapping05:15
daliasso i think there's a bug in how the kernel is doing the mapping05:15
poke53281Ok, so let's assume this is not a problem :)05:15
daliasit's idiotic that this logic is arch-specific anyway.....05:15
poke53281I am used to the fact ldd gives me the correct binary for the binary.05:16
daliasthis 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
daliaswhat is the actual problem you're experiencing?05:17
poke53281Well I had a bug and knew the pc where this bug occurred.05:17
poke53281Then the question what's at this position in ram?05:17
stekerndalias: yes, it's a pure prboom requirement, I haven't looked at the code why it needs that05:17
daliasstekern, oh, maybe i patched it out on my builds... i vaguely remember doing something like that05:18
poke53281The programs runs 1ms before it crashes. So can't look up the real /proc/id/maps mapping05:18
daliaswell what address is the crash at ?05:18
poke53281with uclibc it worked :)05:18
poke53281that doesn't matter. Soomewhere at the shared libs.05:19
daliaswell if you know the address you can find it05:19
poke53281If ldd does not give me the correct addresses the problem is hard to find.05:19
daliasjust look at the low bits of the address05:20
daliaspages are 8k, so bits 0-12 are fixed regardless of where gets mapped05:20
poke53281Ok, a more complicated example05:20
stekerndalias: ah, you were actually speaking specifically about prboom when you said "I always ran it at", I thought you meant doom in general05:20
daliasbut anyway it's likely to be 0x3000000005:21
daliasstekern, yes05:21
daliasmy prboom builds had a few local patches like allowing additional actions to be mouse-button-bindable05:21
daliasand i kinda remember something like the nonsensical 640x480 restriction which i probably patched out :)05:22
poke53281the mapping of libSDL is already wrong in this ldd output.05:22
poke53281At 0x30000000 libc starts and not libSDL.05:22
daliasjust offset them all by the size of mapping05:23
daliasand pester the kernel folks to fix this mapping bug05:23
poke53281Yes. but I am very lazy.05:23
daliasmapping ET_DYN main program (ldso) should behave identically to mmap(), starting from just below stack and working down, with additional gaps if ASLR is enabled05:23
daliasmapping at 0x8000000 is nonsense05:24
daliasanyway if you just add the total size of the mapping to the later ones, i think you'll get the right addresses05:24
daliasalternatively, strace it and look at where the mmaps go05:25
poke53281Yes, I did it in the end with strace.05:25
daliasdid you find where it's crashing?05:25
poke53281Yes, see the whole discussion the last 24 hours with stekern.05:26
daliasah :(05:29
daliasutterly broken alignment and aliasing violations? fun...05:29
poke53281But it took me 2-3 hours to find the correct position because I expected ldd is right.05:29
daliasldd is right for how it gets mapped when you run the program via explicitly invoking ldso, which _should_ match how the kernel maps it05:30
poke53281no, not this one. Before. This alignment stuff is another story not related to the problem.05:30
stekernI 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 ( 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 it05:30
daliasonly because the kernel is buggy with regard to how it maps ET_DYN elf files on or1k does it differ05:30
dalias*sigh* why is __register_frame_info even being used?05:31
daliasthis is old crap for the pre-init_array era...05:32
daliaswhich should not even be supported on new archs05:32
daliaserm, maybe not init_array, i think it's dl_iterate_phdr related05:32
daliasbut 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
poke53281stekern: Probably I have found a simple example:
poke53281I get at the position with strace a pc to zero05:34
stekerndalias: I don't think it's actually used, but the references comes from this:;a=blob;f=libgcc/crtstuff.c;h=9d5399acb5e005d6f041a13369a64468c8651f2c;hb=HEAD#l46305:35
daliasi think something is wrong with relocs but it's not clear to me whether it's musl's fault of ld's fault05:35
poke53281I get at the same position with strace a pc to zero05:35
daliasi don't think the weak reference to __register_frame_info making it into the main executable symbol table and PLT is right05:36
stekerndalias: 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 wrong05:36
stekernyeah, maybe not05:36
daliasif there's a weak reference, whether it resolves to null or not should be resolved at ld time05:37
daliasnot dynamic link time05:37
daliasthere is no way to give consistent results at dynamic link time, as far as i can tell05:37
daliasso i think this is a bug in ld...05:38
poke53281stekern: When I include the -lgcc_s the "fire" demo works. So maybe this is an easier starting point05:38
daliasare you using shared libgcc?05:39
poke53281For the moment it's a hack stekern suggested to get rid of the problem05:39
daliasobjdump -x libgcc.a |grep '__register_frame_info$'05:40
daliaswhat does that show?05:40
poke53281one minute05:41
poke53281the native one nothing05:45
poke53281the cross compiled libgcc.a also nothing05:46
daliasok, i guess this means it's undefined05:48
daliasand thus should resolve to null05:48
daliasthat seems correct -- the old method for registering eh_frame should not be needed05:48
daliaswhat seems wrong is that the weak reference is remaining05:48
daliaslet me try a similar test on x8605:48
daliasvoid foo() __attribute__((__weak__));05:50
daliasint main() { if (foo) foo(); }05:50
daliasfoo is resolved to null by ld05:51
daliasit's not left as a weak reference in the output executable05:51
daliasthis program only has one reloc05:51
dalias080494cc  00000407 R_386_JUMP_SLOT   00000000   __libc_start_main05:51
daliassee what it has if you compile it on or1k05:52
poke53281readelf -r a.out gives me only the __libc_start_main05:56
poke53281you can use the compile demo to test it.05:57
stekernyes, but if you compile with -fPIC, the reloc will be there05:57
dalias*sigh* your terminal emulator is broken05:58
daliasbackspace generates ^H05:58
daliasnot ^?05:58
daliasstekern, oh? let me check..05:58
stekern(for or1k that is)05:59
daliasstekern, ah, weird...05:59
daliashappens on x86 too and it seems semantically wrong06:00
stekernhappens on x86_64 too06:02
stekern...and arm06:03
daliasbut i get consistent results here from the dynamic linker06:03
daliaseven with a shared library that also has the weak reference06:03
poke53281dalias: 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
daliaspoke53281, the ^H thing should be fairly easy to fix06:04
daliasit's a pain because you can't edit input in canonical mode06:05
poke53281Ok, I will try to give the easiest example possible to reproduce the error.06:05
poke53281Yes, I know06:05
poke53281Isn't this normal ;)06:05
daliasso.. i think there may be a dynamic linker bug at work here06:05
daliasbecause it gives the right results on x8606:06
dalias(both the main program and shared lib see the address of foo as 0)06:06
daliasok this is also a gcc bug tho06:07
dalias__register_frame_info, if it exists, is a hidden function06:07
daliasbut the reference to it does not have a visibility attribute06:08
daliasthis is why the weak reference is allowed to persist06:08
daliasif it's properly marked hidden, the reference gets resolved to 0 at ld time, even with -fPIC06:08
poke53281Hmm, does musl has a libpthread?06:14
daliasit's an 8-byte .a file :)06:15
daliasbecause musl is not separated into gratuitous .so files that just add bugs and runtime bloat06:16
poke53281Ok, because I delete all .a files when I build my image06:16
daliasthat's a problem if you want to be able to build anything06:17
daliasthey 8-byte .a files exist for a reason06:17
daliasbecause -lm, -lpthread, etc. are required to be valid options for linking06:17
poke53281yes,  mhh... thinking06:18
daliasyou just want to omit libc.a, not *.a06:19
dalias(and you could do this more efficiently with --disable-static, i think)06:20
poke53281yes, probably.06:21
stekerndalias: I'm also not able to reproduce with a smaller test case (your test + a .so with the same weak sym)06:21
daliasstekern, i made a test .so that contains a global ctor that printf's (void*)foo06:22
daliasand i got 006:22
poke53281dalias, stekern:
poke53281I have a folder fire there06:23
poke53281./fire will give you the error06:23
poke53281interesting is now, if I compile it with jor1k it seems to work.06:24
poke53281at least, I have two binaries to compare06:24
stekernI've got debug prints in src/ldso/dynlink.c and I can see from them that foo get resolved to 006:24
stekernthat should be pretty equivalent to your test06:25
stekernbut that's not what happens with d1x-rebirth, so something more is at play here06:25
poke53281What 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
poke53281the crashing one has __register_frame as relocation, the working one not.06:37
poke53281bad: cross compiled, good : native compiled06:38
daliascompare the crt files from your native and cross toolchains06:41
dalias(crtstart/crtend from gcc)06:41
stekernso, the difference from the simple test seem to be that foo does not end up in .dynsym, while __register_frame_info does06:46
poke53281dalias, it's already late for me. Make it fast, what should I compare?06:50
poke53281this file contains both binaries. fire and firebackup06:54
poke53281fire was compiled with the command "./compile"06:54
poke53281firebackup cross compiled with configure && make06:55
daliasi can look...06:57
daliashmm i don't have a toolchain tho :/06:57
poke53281stekern send a link in your mailing list06:57
poke53281with a changed musl-cross.06:58
dalias     5: 00002778     0 FUNC    WEAK   DEFAULT  UND __register_frame_info@GLIBC_2.0 (2)06:59
daliasthat's telling06:59
daliassomehow glibc crap leaked in to your cross build..07:00
poke53281wow, how do you get the glibc text?07:02
poke53281which command?07:02
daliasreadelf -a firebackup07:02
daliasreadelf is the only tool i have that can do anything on an or1k binary without having explicit support for or1k07:03
stekernthat explains why that ends up in .dynsym and the simple 'foo' test didn't07:03
daliashmm weird07:05
daliasthe GLIBC_2.0 version comes from
daliasaccording to this07:05
daliasVersion 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:  Cnt: 107:05
dalias  0x0010:   Name: GLIBC_2.0  Flags: none  Version: 207:05
daliasno idea what that's about07:06
daliasbut it looks like the cross compiler did some nonsense with
poke53281Ok, I feel really weird now and tired. Something really strange is going on. And funny only07:10
poke53281for such special cases.07:10
stekernI'll do some more digging with this new-found info07:11
poke53281How can glibc stuff be in such a file. I mean there are a lot of asserts to prevent such things.07:11
poke53281in the end, I put in m own toolchain script some files in the wrong directory and it is all my fault.07:12
poke53281Ok, I am away for the next 8 hours. Land of dreams.07:15
stekernsleep tight07:15
stekernhmm... I don't get the 'glibc crap' when I try to cross-compile fire.c07:28
olofkI think that poke53281 visited some shady site that infected him with glibc via a browser toolbar07:30
olofkWhat's crt, btw? Like crtstart, crtend and crt0.S07:50
maxpalnso, what's the recommended way of adding modules to the initramfs?10:17
maxpalnHaving 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 start10:18
olofkmaxpaln: The easiest way is to compile stuff and put it in arch/openrisc/support/initramfs and run make afterwards10:26
olofkThe stuff in that directory is the initial file tree built into the kernel10:26
maxpalnI came to that conclusion too - good to have my suspicions confirmed :-)10:27
olofkSo is antone going to show up at FPGA world. I know I should have mentioned this sooner10:28
maxpalnI 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
olofkYes, once you're starting to have dependencies it gets more complicated. I haven't quite gotten there myself yet, so I'm no help10:31
olofkDuring my four years in the project I have barely run any applications other than a few simple test cases and booting linux for demonstrative purposes10:32
stekernmaxpaln: 'module' == a piece of software in this context?11:09
stekernif you're going to build a larger system it's probably better to move away from the initramfs11:13
_franck_maxpaln: I usually compile programs with --static so I don't need to install libraries in my initramfs11:30
-!- trevorman_ is now known as trevorman11:51
_franck_olofk: as per wikipedia "crt" stands for "C runtime"12:22
maxpalnthanks 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
maxpalnSo in this case I'll probably just be adding mtd-utils (and/or maybe the ubifs equivalent)12:30
maxpalnaaaargh, how about that - I had the format for mount wrong. I had:12:44
maxpaln% mount -t jffs2 /dev/mtd2 /mnt/spi12:45
maxpalnthe DEVICE shouldn't be a path - it is the name of the device. [slaps face]12:45
maxpalnso the actual command is:12:45
maxpaln% mount -t jffs2 mtd2 /mnt/spi12:45
maxpalnthe 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
maxpalnproblem solves - modification to initramfs postponed for another day!!12:46
olofkWeird. I always use /dev/sda? for my laptop12:47
maxpalnyeah, 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, maxpaln14:17
-!- heroux_ is now known as heroux14:17
-!- Netsplit over, joins: maxpaln14:17
maxpalnls -l14:36
maxpalnoops - wrong window :-)14:36
maxpalnhi, looking for advice on the linux device tree - not sure where to go for answers here.15:09
maxpalnThe board has a Micron 1Gb Nand SPI Flash15:09
maxpalnI 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
maxpalnThe 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
maxpalnI 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
maxpalnThe 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
maxpalnhmmm, curious - several references to the micron device in drivers/mtd/nand -15:32
maxpalnI'll try the generic nand and see what happens!!!15:33
poke53281stekern: You want to this say that this register_frame thingy is a problem of pop, a "problem of poke".16:40
poke53281olofk: The problem is, that I have to use slightly different options than the musl-cross builder.16:45
stekernpoke53281: not necessarily, when I cross-compiled, I did it by manually invoiking or1k-linux-musl-gcc, because the configure script in the .bz2 was corrupt17:01
heshamstekern: 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
stekernhesham: unless you pass something else, the default should be 128:
heshamNot sure what do you mean by "pass something else"17:25
heshamstekern: 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
stekernhesham: the link I pasted shows a gcc commandline option (-mredzone=), which defaults to 128 if not specified17:54
stekernI would assume that increasing the amount just hide some bug17:55
stekerndo you have the latest code that you are using now?17:55
stekernpoke53281: also, when I cross-compiled, I used the gcc built from your scripts17:56
heshamstekern: The latest code (without the account for red-zone is there), I will give you a link, one sec17:58
heshamThis corresponds to entry.S in linux
heshamAnd this file for exception handling (ISR_Handler called from start.S)
poke53281stekern: 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
poke53281I should do a readelf -a for all my binaries and grep for glibc.18:07
stekernmaybe olofk was right after all then ;)18:08
poke53281infected by glibc. dalias should program a musl-doctor based on Weizenbaum's Eliza.18:12
stekernhesham: where do you account for it in your local code?18:19
stekernnot that I can see any obvious bugs in the context save code18:19
heshamI do not have a clean local code for now, I will submit a patch and give you a link soon18:20
stekernok, no worries18:25
stekernpoke53281: time for some constructive criticism, 'make buildtools' tries to build or1k-src (and fails), shouldn't that be the binutils-gdb snapshot?18:31
poke53281Right, error 1/1000. Try "make binutils2".18:35
poke53281You will get an ice cream if we reach the 1000.18:35
poke53281I removed binutils and renamed binutils2 to binutils.18:36
stekernwhat flavour?18:37
poke53281to build the final image look at the script/filesystem.make file18:37
poke53281chocolate is Ok?18:37
poke53281Instead of having one sysroot I build packages. The I use patches/fs2xml to build my final filesystem out of those packages.18:38
poke53281scripts/image.make is no longer valid and can be removed.18:38
stekernnope, vanilla is better then ;)18:39
stekernyeah, I saw that in packages/, it's a nice touch that you just can untar them into the fs18:39
poke53281this 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
poke53281I try to fix libtool. But it's imposible to read the code.18:42
stekernI'm approaching my ice cream, you're missing a 'make xcb-proto' in the X build instructions ;)18:46
stekern...and libxcb I think18:47
poke53281xcb-proto should be there if I read my code correctly.18:48
poke53281But maybe at the wrong position.18:48
poke53281the problem with those fixes is, that I have to remove the whole sysroot to really test them.18:48
poke53281xcb-proto is the last in the PROTO_XLIBS variable.18:49
poke53281libxcb is also the one in the "make xlibs" part. Maybe that is wrong too.18:50
stekernI'm hitting this when I try to build libxcb:
poke53281Hmm, the packages should be much older than this bug report.19:00
poke53281From last year19:00
poke53281python problem? The famous python2 python3 problem19:00
poke53281so, this error is new for me19:01
stekerndon't know, but isn't xcb-proto_1.11 newer than that bug report?19:05
poke53281too lazy to look it up.19:10
poke53281But I compiled it and it works.19:10
stekernI'll cheat in the meantime and use your packages ;)19:10
poke53281But 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
poke53281Note, that I use a chrooted archlinux system to compile19:12
poke53281archlinux has always very very new software19:13
poke53281But I have also a Debian here somewhere.19:16
poke53281libxcb should be in libX11.tar.bz219:17
stekernok, let's see if I can build with that19:20
poke53281stekern: This is how the filesystem of jor1k is loaded:
poke53281After I did the .xml file I realized that I cannot interpret them in a worker thread in Javascript. :(19:30
poke53281So I had to write a tiny xml interpreter myself.19:30
stekernhmm, 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
poke53281this is my startx command19:41
poke53281so why not change the second line to: "-mouse evdev,,device=/dev/input/event0" ?19:42
stekernyes, but the keyboard doesn't work then19:43
stekernI'll figure it out, I just thought I'd ask in case you knew19:43
stekernin what package is
poke53281Why 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
stekernwell, 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
poke53281also in libX11fs19:45
poke53281Also in libX11.tar.bz219:46
poke53281I didn't want to have every libX library in a special package. X is already pretty huge.19:46
poke53281If you are in doubt, just look in script/filesystem.make and search for the library.19:46
stekernoh.. I thought I had already extracted that, but I hadn't19:47
poke53281Looks like you take the short/uncomplicated path. Just use my binaries.19:48
stekernyes, at least for now19:48
poke53281that makes sense19:48
stekernI mean, why duplicate efforts ;)19:49
poke53281Should work out of the box. Except mesa. This is compiled with -mhard-float19:49
poke53281duplicate efforts to fix the errors. There is almost no one who could build with those script a full working image right now.19:50
poke53281But no problem. I can compile mesa without this for now.19:50
poke53281Only if you want of course.19:50
poke53281twm and xinit are also important.19:51
stekernit's ok, I can rebuild that myself19:53
poke53281stekern: success?20:45
olofkstekern: 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 easier20:59
heshamstekern: Sorry for being late, this patch solves the problem of context switches (by accounting for red-zone) -
stekernolofk: I think it is pretty stand-alone21:09
stekernthere's just some 'hooks' into mor1kx21:09
olofkWould it make sense to provide these 'hooks' as external ports then?21:10
stekernpoke53281: 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 directory21:10
poke53281arghh, yes. The old problem.21:10
poke53281make a dummy drm.h file21:11
poke53281or better, patch dri_interface.h21:11
poke53281that it doesn't use drm. I think this bug is solved in newer version Mesa.21:12
poke53281This is one thing I still have to do manually. Too lazy to write a one-liner21:13
stekernolofk: I don't know... if there becomes several fpu implementations, perhaps21:14
stekernpoke53281: I had a vague recollection of doing that before21:15
poke53281yes, this bug is one year old :)21:15
olofkstekern: True. There is probably no idea doing that until we have at least two different impementations21:15
poke53281But I stubmel over it only one time every year.21:16
stekernwhen I try to build X, right? =)21:16
stekernbut, your X runs fine (with only mouse)21:17
stekernI need to build X to enable kdriver-mouse21:17
poke53281Yes, when you build X :)21:17
stekernthat way I can use /dev/input/mouse for the mouse and /dev/input/event0 for keyboard21:18
stekern...or that's what I hope at least21:18
poke53281a hack21:18
poke53281Ok, so I will add kdriver-mouse too. It would be nice if my packages also work on other openrisc devices.21:19
stekernI found this:
stekerna bit outdated, but compiles on my ws after removing -Wall and -Werror21:20
poke53281"--enable-kdrive-mouse" ?21:20
poke53281Thanks, I will take a look on freera21:21
poke53281any other configure switches which might be important?21:21
poke53281for others21:22
poke53281stekern: 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 fun22:20
poke53281stekern, you know that redalert.mix has a size of 25MB?22:34
poke53281the user would have to download 17MB22:46
poke5328113MB if I would switch to .xz files22:47
--- Log closed Fri Sep 05 00:00:38 2014

Generated by 2.15.2 by Marius Gedminas - find it at!