Dr. H. Nikolaus Schaller schrieb: >> The only real bug I am aware of is the "illegal instruction" thing. I >> juts built a new version of the distribution with OpenEmbeded and it >> still suffers from the same issue - so it is probably not a glibc/gcc >> issue but really a kernel problem. But I habe no real idea how/where to >> find that one. > How does the bug show up?
Well, this is one of the mysteries, I cannot really pinpoint the point of failure yet. For now I know that especially more complex GUI applications tend to trigger it. What the exactly "complexity" is is yet unknown but e.g. a web-browser is pretty sure to sooner or later cause it. With my current OpenEmbedded Build almost every GTK+ application crashes directly at startup or soon afterwards. I found on old MIPS mailinglists about early kernel 2.6 some reports of a similar bug triggered by some kernel misimplementation of some ?ATOMIC? syscalls - presumably the ones used for userspace process/thread synchronisation. There were assembler codepaths that could break in certain situations causing a jump into falsely generated assembler code. But this was supposed to be fixed until 2.6.24. I also know that running the application in GDB causes the fault to *not* being triggered. > When cross-compiling my first code for the Openmoko Freerunner I had > also copied a new glibc to the device - and that immediately came with > an Illegal Instruction in every shell command... After some analysis it > turned out that my toolchain wasn't configured properly for the > Freerunner CPU (arm4t), i.e. the code did generate a handful of arm5 > instructions. What also could be is that some package ./configure may > think they know it better and pass a -mcpu or do other stange things... > > Although there are not as many different instruction set variants as for > ARM, there might also be variations. Could that be the same for the JZ? > > http://www.linux-mips.org/wiki/Instruction_Set_Architecture > > On the other hand the IS looks quite simple and straightforward > > http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html Well, I guess it is not exactly that easy, pitily. The MIPS family of CPUs is pretty big and many MIPS chip vendors add vendor specific instructions - like our JZ4730 has some SIMD instructions to boost image decoding (there is BTW a binary only libjpeg available at the Ingenic site which uses that). I fear that Ingenic also has some nifty changes in their core that could trigger this *or* their 2.6.24 kernel patch which adds the JZ4730 support in the first place simply has a bug. So my assumption currently is that we rather have to watch out for a kernel bug rather than compile options or system incompatibilities - and this is no fun... Finding this needs a lot of expertise with MIPS. I think I will have to subscribe to the MIPS kernel mailinglist and post my findings there. But fear that they will tell us that we should use a more recent kernel and that this SOC is not supported. > Nikolaus Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
