From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C62D640.6080304@domain.hid> Date: Wed, 11 Aug 2010 18:56:32 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1278943817.7023.18.camel@domain.hid> <4C3EF6D6.6040907@domain.hid> <1279210298.1995.38.camel@domain.hid> <1279623645.2187.35.camel@domain.hid> <4C469259.3000708@domain.hid> <1281538723.2246.120.camel@domain.hid> <1281540487.1730.20.camel@domain.hid> <1281543863.2246.149.camel@domain.hid> <1281544161.1730.23.camel@domain.hid> <1281545075.2246.167.camel@domain.hid> In-Reply-To: <1281545075.2246.167.camel@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Marvell sheeva support List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tim Cussins Cc: xenomai@xenomai.org Tim Cussins wrote: > On Wed, 2010-08-11 at 18:29 +0200, Philippe Gerum wrote: >> On Wed, 2010-08-11 at 17:24 +0100, Tim Cussins wrote: >>> On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote: >>>> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote: >>>>> Hi guys, >>>>> >>>>> Managed to get started on the Sheevaplug/xenomai stuff: >>>>> Used mkrootfs. Cool. >>>>> Massaged the mv88fxxxx patch so that it builds with 2.6.33. >>>>> Can't log into the device to run tests. Augh. >>>>> >>>>> Details below! :P >>>>> >>>>> On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote: >>>>>> Tim Cussins wrote: >>>>>>>>> We can also provide you with a root filesystem for validating this platform. >>>>>>> That would be brilliant. I imagine I'll be iterating though uImages on >>>>>>> an SD card loaded with your rootfs. Sound ok? Let me know how to obtain >>>>>>> the rootfs (or better, show me how you prefer to do it, so I learn >>>>>>> something! Ta.) >>>>>> You will find the rootfs for orion SOCs, here: >>>>>> http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2 >>>>>> >>>>>> Edit etc/inittab to modify the serial console it needs (if it is not >>>>>> /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by >>>>>> NFS with the kernel IP auto-configuration, so, if you want to boot it on >>>>>> an SD card, you will have to connect to the serial console once the >>>>>> board is booted, and run "udhcpc" to configure the network by DHCP, or >>>>>> use ifconfig to configure it by hand, then launch "telnetd" to be able >>>>>> to connect to that board through telnet (if the kernel booted by NFS, >>>>>> the telnet server will have been launched automatically) >>>>>> >>>>>> In a first telnet session, run: >>>>>> latency >>>>>> In a second telnet session, if you have FCSE disabled, run: >>>>>> dohell >>>>>> if you have FCSE enabled, run: >>>>>> noltp_hell 14400 >>>>>> (14400 means that you will generate some load during 14400s, that is 4 >>>>>> hours). >>>>>> When either noltp_hell or dohell displays the line: >>>>>> Listening on any address 5566 >>>>>> On the host, run: >>>>>> netcat 5566 > /dev/null >>>>>> >>>>>> Now you can return to the telnet session running latency. When the test >>>>>> is finished the latency program should stop. >>>>>> >>>>>> As for generating the root filesystem, it is not that it is really hard, >>>>>> but it is a bit tedious. So, we made a tool to build a root filesystem >>>>>> which suits our needs, that is testing Xenomai under load. I have just >>>>>> finished working on a version of this tool (called mkrootfs, but I think >>>>>> we should find a better name, as this one already exists) user-friendly >>>>>> enough to be published. Currently, it is still lacking a documentation. >>>>>> You will find it here: >>>>>> >>>>>> http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2 >>>>>> >>>>>> However, to use it, you will need a few explanations. It is based on >>>>>> Kbuild, the Linux kernel build system, so, it will build the same way. >>>>>> Create a build directory, cd to it, then run: >>>>>> >>>>>> make -C /path/to/mkrootfs O=`pwd` xconfig >>>>>> >>>>>> Tweak the configuration. Then run: >>>>>> make >>>>>> >>>>>> It should build everything. >>>>>> >>>>>> It does not download and patch the sources of the packages it uses, you >>>>>> have to do this yourself, then pass the path where to look for them to >>>>>> the configuration system. We use standard versions of the packages, >>>>>> except for LTP, which we modified a bit to run on low-end platforms, and >>>>>> which you can find here: >>>>>> >>>>>> http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2 >>>>> >>>>> I've had a good play with mkrootfs - nice. I had to make a couple of >>>>> changes to meet my needs (and system, ubuntu 10.04). Is there a git repo >>>>> for mkrootfs that I can base my patches on? They're very small btw. More >>>>> on that off-list if you want. >>>>> >>>>>>>> You can also use the patch below as a starting point for your port: >>>>>>>> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch >>>>>>> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't >>>>>>> apply cleanly (well, fails :P). Am I approaching this the wrong way? >>>>>>> Also tried chucking the patch into the xenomai tree and gettingdev.txt (from mkrootfs) would imply that it is 4,64. Without being able to log in, I can't confirm though :) Unless you know a cunning trick? :D >>>>>>> prepare_kernel.sh to try: still no joy. >>>>>> It probably does not apply to vanilla because vanilla has no support for >>>>>> the Sheevaplug board. Or am I missing something? >>>>> Well, I don't think so. Some hunks are expecting lines of context that >>>>> simply don't exist in 2.6.29 == fail. >>>>> >>>>> I took the mv88f6290 patch and bullied it into applying to vanilla >>>>> 2.6.29. Built ok, but was at home and no way to test, so I just got on >>>>> with migrating it to 2.6.33. That seems to be done - check the 2.6.33 >>>>> boot output: >>>>> >>>>> ... >>>>> I-pipe: Domain Xenomai registered. >>>>> Xenomai: hal/arm started. >>>>> Xenomai: scheduling class idle registered. >>>>> Xenomai: scheduling class rt registered. >>>>> Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded. >>>>> Xenomai: starting native API services. >>>>> Xenomai: starting POSIX services. >>>>> Xenomai: starting RTDM services. >>>>> ... >>>>> >>>>> Full boot output is attached FYI. >>>>> >>>>> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't >>>>> log in via console OR telnet. Once that's solved, I'll be able to run >>>>> the xenomai tests. (In case you've seen it before - /var/log/messages is >>>>> slowly filling with: >>>>> >>>>> Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty >>>>> 115200 ttyS0' >>>>> Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for >>>>> device >>>>> >>>>> ) >>>>> >>>> Does /dev/ttyS0 have major=4, minor=64 on your rootfs? >>> dev.txt (from mkrootfs) would imply that it is 4,64. Without being able >>> to log in, I can't confirm though :) Unless you know a cunning trick? :D >> Well, maybe. ls -l on the nfs server side exporting your rootfs :> > > Pfff :D All the nodes appear as regular files that way - I assumed that > was normal, and that some special magic was happening in busybox to > replace them with nodes... Is there something I'm not doing right? > > I've mounted a debian rootfs over nfs no problems - that tree has *real* > nodes in it, and the show up as such using the ls -l , uh, 'trick' :P It means we have an issue with fakeroot. Just run make clean, then make again to see if it fixes it. -- Gilles.