[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Sparemint Coldfire



Hi,

On Thursday 07 January 2010, Mark Duckworth wrote:
> On 1/7/10 3:17 PM, Vincent Rivière wrote:
> > Eero Tamminen wrote:
> >> One possibility for bootstrapping a new architecture and
> >> cross-compiling stuff for it would be to use e.g. Scratchbox2 (or v1)
> >> + NFS or SSH-FS mount
> >> &  Scratchbox remote shell running on Aranym for transparently running
> >> the configure etc checks natively while doing the RPM building on
> >> fast host machine.
> >
> > Someone (maybe you ?) pointed at Scratchbox some time ago. I looked at
> > it, and I found the concept very nice. But it may be complicated to
> > setup for novice users. However you seem experienced on it, maybe you
> > could try it to see what is missing to use it on MiNT.

My free time goes to Hatari, but below's a list of things that would be
needed.


> Scratchbox is interesting but it doesn't help us with sparemint very
> much.  I'm a believer in sparemint and rpm and that's how I'm going to
> do it.  Didier showed me a method used to detect native 68k instructions
> being executed by cf68klib so I'll be able to build and verify cf
> packages on my coldfire eval board.  Because of the work Alan has put
> into gentoo mint I would be apt to go with that more than scratchbox.
> Scratchbox's primary benefit is crossbuilding the whole system and using
> ipkg for package management on the embedded device (our machines).

Scratchbox (v1 or v2) isn't tied to any particular distribution or packaging
manager.   It gives:

* A way to sandbox the builds to an environment that is the same as
   on the target environment (configure doesn't find stuff that's not
   on the target etc).

* Provides a controlled set of host tools inside that sandbox
  (to speed up the builds without messing it up).

* Facility to run the target environment binaries althought they would
  be using different CPU architecture, C-library etc. (so that configure
  checks work).

On top of this one can add "devkits" that support particular target
distributions (i.e. specific toolchain/C-library, package manager etc).
Currently such are available only for Debian & Maemo.  I know that
SB v1 has been used also for cross-compiling Slackware and Windows
software, but not with package management.


What is missing for MiNT, is support for Atari HW and a "devkit" for
sparemint (or Gentoo, if that's needed).  As doing this differs a lot
between SB v1 and v2, I'm only going to tell how to do it for v2.

It would require:

* Installing SB ("apt-get install scratchbox2" on Debian, or building
  it from sources).

* Telling SB where your cross-compilation toolchain is installed.

* Putting x86 (or e.g. PPC if your host machine is PPC) version
  of a minimal sparemint distribution to a directory and telling SB
  that the host tools are there.

* Possibly fine-tuning the SB "path-mapping" rules for these tools
  in case you find that the rules SB provides aren't sufficient (the
  configuration files are in Lua as that's the language with which
  SB v2 is scripted with).

* Tell SB to use above things for a sparemint target configuration.

This is "all" you need to cross-build sparemint RPM packages that don't
need to run any (target) binaries.


Then for software packages that want to run things compiled for the target
(like configure), you need also to:

* Have an Atari version of the sbrsh daemon.  Normally it uses chroot,
   bind- & NFS-mounts to export the cross-build environment from host
   to target for execution of target binaries.  I'm not sure how to get
   these working on MiNT (does MiNT even support chroot()?)

* TCP/IP connection between the target machine (or emulator) running sbrsh
   daemon and the cross-build host.

* Configuring SB to recognize Atari executables (which bytes are at
  the beginning of a these files) and run them with sbrsh when using
  the sparemint SB target (SB supports multiple targets).

Other alternative for sbrsh would be a "user-mode" Atari emulator like 
user-space Qemu, but I don't we have such a thing. :-)


There are probably some other details I didn't think of, but in principle
above should be all that's needed.


If you want to make Sparement disk images with SB, RPM package database
format could be an issue, if it's not portable.  Debian uses text files for
package database, so it can be easily created by host version and used
by target dpkg version.


	- Eero