Jivin ulf kypke lays it down ...
> 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
Did they start with a uClinux tree or a linux tree ?
> 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.
If they used linux there is a good chance the used fairly standard
driver models IMO.
> my three questions now:
> first, does anybody know something about this device/cpu?
Plenty of people on this list know about armnommu, and while it is not
exactly your specific device, I am sure they will be glad to help.
> second, is it possible to use pthread functions in software i want to
Yes, pthreads work under uClinux, why do you need them ?
> 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
It should not to that hard to move to a newer uClibc, you can probably
just ignore the changed from intersil and use a later uClibc.
> daemon mode is not possible under uclibc, so maybe it is the same with
> pthread.
daemon's are possible under uClinux, but the standard way of
daemonising is not. It's fairly easy to work around. Have a look at:
http://www.ucdot.org/article.pl?sid=04/08/04/1243240
> an other problem i figured out, is the dprintf syntax which is not
> known by the uclibc and is used in debug output funktions.
Perhaps something like
#define dprintf printf
> 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?
Without knowing the code it's hard to say what they are doing.
Most of the uCLinux/malloc issues relate to fragmentation. Have a look
at the ucdot FAQ's for more info:
http://www.ucdot.org/faq.pl
> 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,
If you are running 2.4.19-uc1 then updating to 2.4.31 should be easy
enough. If this is too much you may just want to get the latest 2.4.19
versions of the files in linux-2.4.x/mmnommu off uclinux.org.
The rest of your problems are most likely low memory/fragmentstion or
application bugs, of course that's some wild speculation based on
experience and not evidence ;-) ;-)
Cheers,
Davidm
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
