On Mon, Aug 27, 2007 at 01:39:39AM +0200, Carsten Schlote wrote: > > However, it'll be interesting to see how things turn out. If your > > experiments look promising, it might be worth to re-activate our old > > ColdFire boards. > > I hope to get an eval board soon. The next days we will know, if we go > for mcf548x - chances are good :-) I already spoke with the hardware > developer of the eval board, and he already got a linux terminal > running on it. So first steps seem to be done already for Linux, and > it sounds like a good starting point.
If you are interested I can attach a phyCORE-MCF548x board to our remote lab. What is your boot strategy? Last time I looked the Freescale method was prety brain damaged, with a two stage booting process, involving dbug. I'd go the u-boot-v2 way if you start something new. > Yes, that unfortunetely might be true. So this is -maybe- one of my > last chances to work on something different than i386 derivates or > ARM/MIPS stuff. But a good and performant Linux available for these > targets might change things. Things become "good" and "performant" if people spend significant ammounts of time/money on a platform. I doubt that this will happen for m68k. > I already made some thoughts about some kind of "nightly build/refresh > toplevel makefile", which checks deps on the ptxconfigs in the > toolchain - whenever a config updates, the makefile should rebuild the > chain. It's not only the configs but also the files in the repository itself. > All status info (compiled/compile-breakage) and logfiles should be > accessible via some html page created by this makefile. Of course, > something similiar can be done with a bash script as well. I'd write the script in bash - keep it simple and stupid. The result should be some easily parsable ASCII table; one can create a nice HTML page from it with a few lines of scripting. No need for active components, it can all be cron triggered. > Such toplevel makefile could 'svn export' the gcc trunk to some dummy > archive (e.g. gcc-svn-trunk.tar.bz2), whenever the revision changes (ok, > seems to happen every day anyway). I'd start with the officially released upstream snapshots. You don't want to follow each check-in, it takes too much time. ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots > A matching ptxconfig could be > executed on this snapshot gcc. Same could be done to capture glibc > changes. As soon as some patch starts to fail, we would be informed by > the script. I'd monitor the snapshots directory and trigger a script when something new appears. Then run the scripts and report the result via mail. > I never spent much time on these tests. I always got the impression, > that these tests work best on the target system. That's no easy task, > if you work on an embedded target with just a minimal root fs > installed. Nobody said that it's easy :) But running the regression test suites on a regular base would definitely be a good thing for PTXdist. > So we probably need some working eval platforms or emulators with some > NFS mounted root FS. Can be done here, at least for serveral ARM and PowerPC boards. Robert -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de -- ptxdist mailing list [email protected]
