Hi, > If you are interested I can attach a phyCORE-MCF548x board to > our remote lab.
This might be useful, as soon as some stable NFS Linux kernel bootable via NFS is available, and we start to do daily rebuild or full remote testing. We will get this phytec Board the next days, or so. So I will be able to do appropriate tests. > 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 got some similiar impression. But I planned to port U-Boot sooner or later. > I'd go the u-boot-v2 way if you start something new. Fully agree on this. And as the is only partial support for Coldfire in U-Boot V1 (and the config system is already at its limits), we can do it for V2 right from beginning. > > chain. > It's not only the configs but also the files in the repository itself. Sure, but you can always do a 'ptxconfig oldconfig' on such a config, which updates - at least - the timestamp in the file. Just commit the config, and the tools is scheduled for rebuild. That's the minimal work approach - otherwise somebody needs to maintain some more sophisticated dependancy system. I don't believe that it worth the effort. OTOH the simple approach gives you full control, when a chain is rebuild - just the config triggers, no side effects. > 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. I fully agree on simple, stupid and cron triggered :-) Everything else would be waste of time again. And status should be ASCII. But I will do also some tests with make - I made something similiar some months ago. > ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots > > 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'll do some tests on this issue. > Nobody said that it's easy :) But running the regression test > suites on a regular base would definitely be a good thing for PTXdist. Yepp:-) > Can be done here, at least for serveral ARM and PowerPC boards. So we should work this out later, when the toolchain build process is ready for remote-testing. Carsten ____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.396 from 28.08.2007 -- ptxdist mailing list [email protected]
