From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 82E627EF28 for ; Fri, 26 Jun 2015 07:40:46 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.214.174 as permitted sender) identity=mailfrom; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f174.google.com) identity=helo; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnAgCX5IxVm67WVdFbg2VfBoMYqnKOWoIZhXgCgS8HTAEBAQEBARIBAQEBAQYLCwkhLoQiAQEBAwESER0BGxIMAwELBgULDQ0dAgIhAQERAQUBChIGCgkSEId3AQMKCA2rSz4xiz+Ba4J5iyEKGScDCleFHAEBAQcBAQEBARcBBQ6LPII7EoI1C4JogUMFhVoKjiKEWIUZgWGBOkKPJIM9ghESI4ENCREGghscgW4iMQGCRwEBAQ X-IPAS-Result: A0AnAgCX5IxVm67WVdFbg2VfBoMYqnKOWoIZhXgCgS8HTAEBAQEBARIBAQEBAQYLCwkhLoQiAQEBAwESER0BGxIMAwELBgULDQ0dAgIhAQERAQUBChIGCgkSEId3AQMKCA2rSz4xiz+Ba4J5iyEKGScDCleFHAEBAQcBAQEBARcBBQ6LPII7EoI1C4JogUMFhVoKjiKEWIUZgWGBOkKPJIM9ghESI4ENCREGghscgW4iMQGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,682,1427752800"; d="scan'208";a="137912718" Received: from mail-ob0-f174.google.com ([209.85.214.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Jun 2015 07:40:45 +0200 Received: by obctg8 with SMTP id tg8so60663638obc.3 for ; Thu, 25 Jun 2015 22:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=u5POCOGYp0897x+cY7o2cLhjer8HajKqaa6jv18R3eU=; b=AJ7uixR/eCkZn64lt/X3qJ3QQJU2aUEgSKXb+wUree3nZeAKKfDOpeYEKTW+xdcuFa Hsk7nbODT/DG3qPeoOD/azYiHrZZ70fBdLSr5/xS1aIFlAIzbT1swFDOBLV2AlZSe7Os pMWRFxhejg3uvlHGFY7K0ZSTp9V6UOXj7slLxcJEWhSj7AfHTVs01gykp7WF4XnobjxE J8RrlYZuowVpxPkTKYiR76a6/OQr4uZqKWY0j0jCbsazjZVqNiBvcqFwMx5L7W3ANlMJ nIMoOZlmMi5tOjOL4RGn5L0C9OqvpLWPu5Zf4FImQJKAEs6w1rEubkmaAtDcQLAiPdzl X+gw== MIME-Version: 1.0 X-Received: by 10.202.199.79 with SMTP id x76mr26559859oif.121.1435297244079; Thu, 25 Jun 2015 22:40:44 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Thu, 25 Jun 2015 22:40:44 -0700 (PDT) In-Reply-To: References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> Date: Fri, 26 Jun 2015 01:40:44 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a1134eb4c616ce80519652e11 Subject: Re: [Caml-list] OCaml embedded --001a1134eb4c616ce80519652e11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh yeah, you need a OCaml tool chain targeted to arm... whoops. Sorry about that, I missed that part. On Fri, Jun 26, 2015 at 1:40 AM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > It's easy to compile images that can be run in qemu with buildroot. I > don't know much about yocto, but you can use the crosstool-ng toolkit to > compile a tool chain for cross compiling. You can have multiple tool > chains, and have unique images for each of your respective targets, > possibly just running your ocaml code locally and recompiling it for arm > when you want to put it on the device :) > > On Thu, Jun 25, 2015 at 11:04 PM, Berke Durak > wrote: > >> On Tue, Jun 23, 2015 at 6:32 AM, Markus Wei=C3=9Fmann >> wrote: >> > >> > I can offer experience in the following cases: >> > 1) If your system is powerful enough (e.g. rasperry pi), you can just >> install the ocaml toolchain on your system and develop there on your tar= get >> system. >> >> Seconded. We did almost that for one of our projects and it works >> pretty well. The difference is that we didn't use QEmu, but two of >> our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM, >> see http://xiphos.com/products/q7-processor/ ). >> >> We use Yocto to generate two versions of a Linux system: the target >> system, and a much larger version that contains developer tools (C >> compiler, m4, etc.) The development system runs from microSD cards, >> and takes the better part of a gigabyte, while the target system has >> to run from < 64 megs of flash. The required run-time dependencies of >> the target system have to be manually configured in the Yocto recipes. >> >> We then manually install opam on the developer board, and use it to >> compile our OCaml code. The generated native ARM executables are then >> packaged into .ipks and transferred to the target Q7 board (connected >> to actual hardware: >> http://www.ghgsat.com/wp-content/uploads/2015/03/Payload-Selfie.jpg ) >> The packaging is done using a simple shell script that invokes ar and >> tar. >> >> We did try using QEmu but it's significantly slower, however it may >> come into play as automating the build process (using a virtual >> machine or dedicated hardware) is on our to do list, and build time >> isn't as important when it's a nightly automated build. >> >> Initially we looked into using a cross-compiler but we decided that >> being able to use Opam largely outweighs any possible benefit we could >> get from cross-compiling. And cross-compiling is often a source of >> headaches, even when compiling plain old C. We would have to write a >> lot of Yocto recipes to get it running. Note that Yocto is written in >> a progarmming language called Python and requires recipes to be >> expressed mostly the same language. >> >> To conclude, as powerful ARM systems are very cheap and plentiful >> these days, and since the convenience of Opam is immense, I'm not sure >> there is much incentive in using a cross-compiler. BTW, is there a >> maintained ARM cross-compiler? >> -- >> Berke Durak >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > --001a1134eb4c616ce80519652e11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh yeah, you need a OCaml tool chain targeted to arm... wh= oops. Sorry about that, I missed that part.

On Fri, Jun 26, 2015 at 1:40 AM, Kenneth Ad= am Miller <kennethadammiller@gmail.com> wrote:
=
It's easy to compile im= ages that can be run in qemu with buildroot. I don't know much about yo= cto, but you can use the crosstool-ng toolkit to compile a tool chain for c= ross compiling. You can have multiple tool chains, and have unique images f= or each of your respective targets, possibly just running your ocaml code l= ocally and recompiling it for arm when you want to put it on the device :)<= /div>
On Thu, Jun 25, 2015 at 11:04 PM, Berke Durak <= span dir=3D"ltr"><berke.durak@gmail.com> wrote:
On Tue, Jun 23, 2015 at 6:32 AM, Markus Wei=C3=9Fmann
<markus.= weissmann@in.tum.de> wrote:
>
> I can offer experience in the following cases:
> 1) If your system is powerful enough (e.g. rasperry pi), you can just = install the ocaml toolchain on your system and develop there on your target= system.

Seconded.=C2=A0 We did almost that for one of our projects and it wo= rks
pretty well.=C2=A0 The difference is that we didn't use QEmu, but two o= f
our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM,
see http://xiphos.com/products/q7-processor/ ).

We use Yocto to generate two versions of a Linux system: the target
system, and a much larger version that contains developer tools (C
compiler, m4, etc.)=C2=A0 The development system runs from microSD cards, and takes the better part of a gigabyte, while the target system has
to run from < 64 megs of flash.=C2=A0 The required run-time dependencies= of
the target system have to be manually configured in the Yocto recipes.

We then manually install opam on the developer board, and use it to
compile our OCaml code. The generated native ARM executables are then
packaged into .ipks and transferred to the target Q7 board (connected
to actual hardware:
http://www.ghgsat.com/wp-content/= uploads/2015/03/Payload-Selfie.jpg )
The packaging is done using a simple shell script that invokes ar and
tar.

We did try using QEmu but it's significantly slower, however it may
come into play as automating the build process (using a virtual
machine or dedicated hardware) is on our to do list, and build time
isn't as important when it's a nightly automated build.

Initially we looked into using a cross-compiler but we decided that
being able to use Opam largely outweighs any possible benefit we could
get from cross-compiling.=C2=A0 And cross-compiling is often a source of
headaches, even when compiling plain old C.=C2=A0 We would have to write a<= br> lot of Yocto recipes to get it running.=C2=A0 Note that Yocto is written in=
a progarmming language called Python and requires recipes to be
expressed mostly the same language.

To conclude, as powerful ARM systems are very cheap and plentiful
these days, and since the convenience of Opam is immense, I'm not sure<= br> there is much incentive in using a cross-compiler.=C2=A0 BTW, is there a
maintained ARM cross-compiler?
--
Berke Durak

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--001a1134eb4c616ce80519652e11--