hello, i am new on this list and somehow a newbee in all this deep kernel crosscompiling and toolchain stuff as well, but working for a longer time on a armnommu cpu based wireless accesspoint from good old intersil (which is now conexant). the device what i am talking about, is called isl3893 and is found somehow in the uclinux patched 2.4 kernel sources, what surprised me, but anyway, this way of bulding a new kernel fails.
the project homepage can be found under isl3893.sf.net. i need to update the status on the page, because many new things happend. so, as i told, this cpu has no mmu but a mpu mechanism in the kernel. at that time intersil started this device plattform, they took a 2.4.19 cvs checkout from the kerneltree, put a lot of stuff into the kernel, very dirty (many ifdevs) and did not updated the cvs back. based on my knowledge i am at the moment not able to patch newer kernel with the intersil changes. as i know jet, in between the linux kernel and the cpu a so called MVC is managing the net devices like wireless and ethernet. this is the reason why the kernel is so specific. my three questions now: first, does anybody know something about this device/cpu? second, is it possible to use pthread functions in software i want to compile/use in this enviroment? my old uclibc does not have this, and it is not easy to just take an other uclibc, because intersil changed some code there as well. as i know for example, to run programms in daemon mode is not possible under uclibc, so maybe it is the same with pthread. an other problem i figured out, is the dprintf syntax which is not known by the uclibc and is used in debug output funktions. my last questions is somehow based on a very strange behavior. my final goal is to use this device as an wireless mesh router. the routing daemon is olsr (http://olsr.org) or batman (http://open-mesh.net/batman).i dont know if you heard about freifunk and our meshnetwork with more then 500 nodes in berlin germany. at the time the net was very small, like 50 nodes the olsrd was running well on this device. now with this large number of routing entries, olsrd crashed because of running out of memory, and here is the problem about the nommu architecture and the software based mpu. under /proc i have a mpucount which is now counting up. my research for any solutions ends up on this document about how to allocate memory for special softwaresolutions like routing, here the link: http://www.cyberguard.info/snapgear/tb20020530.html i tried to change the way of malloc in uClibc/Config from malloc-simple to malloc-smart and i turnd on the MPU suff in the Kernel config, with no success. does anybody know if this MPU is only used in this special intersil device, or is it used on other nommu plattforms? if somebody is familiar with this plattform, or is willing to look into the code, i can send a clean kernel patch to 2.4.19-uc1 what i am using right now. it could also be, that routing stuff is not working in this way on this device anyway, so i have to quit with it. at the moment, i figured out, routing entries are made but can not delete, maybe of the difficult memory behavior. but i dont know jet, if this is a kernel or mvc bug. maybe someone has a goot idea, that would help me, regards ulf kypke _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
