OpenWrt Forum Archive

Topic: RTAI on Kamikaze

The content of this topic has been archived on 16 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi everyone,

This is my first post on this forum, thus pardon if I do something wrong.

My issue is that I have to patch OpenWRT with RTAI (Hard Real Time patch) and since Im a novice at Linux, this raises a bundle of questions for me. Naturally I have already stuck my nose in to the problem, however I cant seem to find some general overview will it work, rather than specific issues.

First the concept: since my question is a rather specific one, I will try to provide some background situation (as I understand it). The way Linux system is patched with RTAI is that first a vanilla Linux kernel is patched, Then config file generated for specific system and kernel is build and installed. After that the configuration of RTAI takes place, building it and installing in to the system. The traditional approach is well documented and covered for x86 systems, however I dont really know how to put this in practice with OpenWRT. Can someone, who has good knowledge of OpenWRT advise me on the process and in general - possibility of success? 

Additionally, due to the restrictions imposed by RTAI and hardware (my AP is ASUS WL 500gP equipped with Broadcoms 4704 chip), I am forced to limit my choice to Linux kernel 2.4.22. As the only compatible option from OpenWRT I see kamikaze/7.06/brcm-2.4/ or are the any alternatives? And question about the kernel, used in OpenWRT - the ones that are included in tar balls in download section, are they customized or vanillas?

Thanx for help - much appreciated
t.A

Hi t.A
I'm really interested in RTAI on router
Afaik there is no more support for MIPS on RTAI (ASUS WL500gP is MIPS based)
Am I wrong?
I think it's better a ARM based device for RTAI

Ciao
Marco

Well lubimaer, things is that I have 12 ASUS WL500gP AP's and I need to make a system work, so rebuying a new set is not really an option hmm on the point of RTAI is no longer supporting MIPS, yes it is, howerver the RTAI 3.1 has limitted support, which I expect to avail for my goal.

So you can try to download complete kamikaze svn trunk
Then you should try to perform a complete build to make sure everything is ok (check openwrt docs for howto)

Then you can try to follow this approach I did for spca webcam driver for kernel 2.4
http://forum.openwrt.org/viewtopic.php?id=12414

It could work ....

Ciao
Marco

Well I have run into some different issues before trying to patch the OpenWRT. First of all latest RTAI does not support MIPS and the only versions that do, they are dedicated up to v2.4.22 kernel  and the as it seems the oldest kernel used in OpenWRT is v2.4.30. I have tried to compile development version with an external 2.4.22 kernel but the "make" stops with this kind of error:

error message wrote:

make -C ntfs modules
make[7]: Entering directory `/media/disk/OpenWRT/test_build/external_kernel_2.4.22/linux-2.4.22/fs/ntfs'
mipsel-linux-uclibc-gcc -D__KERNEL__ -I/media/disk/OpenWRT/test_build/external_kernel_2.4.22/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /media/disk/OpenWRT/test_build/external_kernel_2.4.22/linux-2.4.22/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe  -mabi=32  -finline-limit=100000 -mtune=r4600 -mips2 -Wa,--trap -DMODULE -mlong-calls -DNTFS_VERSION=\"1.1.22\"  -nostdinc -iwithprefix include -DKBUILD_BASENAME=fs  -c -o fs.o fs.c
fs.c: In function `ntfs_printcb':
fs.c:168: warning: integer constant is too large for "long" type
fs.c: In function `_ntfs_clear_inode':
fs.c:852: error: label at end of compound statement

maybe someone could advise how to compile OpenWRT with 2.4.22 kernel?

maybe someone could advise how to compile OpenWRT with 2.4.22 kernel?

Don't, or port the patches to 2.4.30.  2.4.22 was abandoned long ago with good reason, not the least of which is that it's just over a month away from being five years old in an arena where six months is positively ancient.  Bugs, bugs, bugs, and more bugs.  Linksys may standardize on 2.4.17, but that doesn't make them right.

This really is a case of the tail wagging the dog - you have a pile of [expensive] hardware all ready to go for an RTOS hack to a non-RTOS kernel on an unsupported (nay, abandoned) platform.

If you're really dedicated to the application and platform (why RT linux?  on MIPS???), you're going to need to produce (or get) the patch RTAI made against the 2.4.22.x (.3?) kernel tree and work through applying that to the latest 2.4 (2.4.30.y).  Then, you'll have a clean patch you can add to your target/linux/$arch/patches directory.  If you're lucky, you'll finish before OpenWRT officially abandons the 2.4 kernel, which I have a feeling will directly coincide with when there's good b43 wireless support in the 2.6 kernel.

The discussion might have continued from here.