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

Re: [MiNT] Sparemint Coldfire



On Thu, Jan 7, 2010 at 4:09 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
> 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
>
Thanks for this Eero, I the process may only (seem to) be complicated
until you get a successfully compile and package.

I have a script (bash/shell) that does somethings similar, it is
possible that the only real thing missing is some documentation and a
download of working mint and cross tools.. (for SB)

I will hopefully get around to testing this soon and some of the other
bits and pieces, especially if they can provide alternate and
supplemental build environments, this wilokl help others, and any
speed improvements will be moire of an incentive to others to do some
things, even small pieces..

Paul