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 AA76A7EEF8 for ; Thu, 16 Jul 2015 12:06:10 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.4 as permitted sender) identity=mailfrom; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; 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@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGAQCxgKdVnAQP49Rag2dpvT+CQ4M0AoFDTAEBAQEBARIBAQEBAQYNCQkhLoQjAQEBAwEyAUsLCxgJJQ8FDRsrCYgYAQMKDAnJNR8rDYVAAQEIAgEfi0yCOxKBagRSgxeBFAWURoRuhUSBZYFERoYyDIkRg0aDYYIzHIFVbQGCSgEBAQ X-IPAS-Result: A0BGAQCxgKdVnAQP49Rag2dpvT+CQ4M0AoFDTAEBAQEBARIBAQEBAQYNCQkhLoQjAQEBAwEyAUsLCxgJJQ8FDRsrCYgYAQMKDAnJNR8rDYVAAQEIAgEfi0yCOxKBagRSgxeBFAWURoRuhUSBZYFERoYyDIkRg0aDYYIzHIFVbQGCSgEBAQ X-IronPort-AV: E=Sophos;i="5.15,487,1432591200"; d="scan'208";a="140210479" Received: from mout.web.de ([212.227.15.4]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2015 12:06:09 +0200 Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0M0yzv-1YyIUp3hkN-00v9Tq for ; Thu, 16 Jul 2015 12:06:08 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1ZFg3M-0000LF-1Q for caml-list@inria.fr; Thu, 16 Jul 2015 12:06:08 +0200 Date: Thu, 16 Jul 2015 12:06:07 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20150716100607.GB32592@frosties> References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:E41DD67ER90mAGdDehzrKSLPZfpMTk9B5Pim3wa7ZciSSfnwzU8 gC43u7fy4xq4F3ICWKYMZDgtyzm41A5lhWUmfo1bW1ZzFkrBxJkeolvzWEy83hbAIIATuv5 A/LzPNr3GSgql0EY1rxusBBzK+qS+9KDE0F6mXUZlP0+v6+THuOedceM/YiwhhXE4ONKtQI /Oih49OaftShwAnCft86g== X-UI-Out-Filterresults: notjunk:1;V01:K0:3x3XxQavxPk=:objVB0xeM6oOlSQ6cG0RBO QknttAAHKnxpYGBHS6ATNM9nJwGNUAviCvUEUsUru5gjMX+Z2z2c8QHHqSV6PX1EA9eCyTWkS ENS2I2Hniyd2R9Qo4sZVDLGKRS6/KWiQQcHTRfuMZEThjKzCssU3Z+a0B6NnkGJ4sTz0r277E a8RkmjbnE/jt/5+BZfuP7dA+leBjfS43iuUKYwR/vZBIgQSINK5v/gtVBmZyrkPqZzSsqpI9b GOdZzaCU47x/90bz4rqCz3aK4A1wDYzay+4ttvPDPVVIvwWRzjzEKwQ8XanxemRKvp80QsV1N NbpZSDFXaDJXH1FT5qw5cAvOtMT1jGmBDCXqKbIR+a5bOE2trM1atHo4z4HlppZcyHdGy6YBD M045Zp2zNEYNZiRMI/f92MWoQpltyM+rSMN2QEZk3ABW7T2XtozRfDxGJODhVS2+AV9PsApgw PZXTn9snuZH54oR7R9Mly9xQD5B4E1L1wPwaiZw1uMPvYlqeTD5rLuNOR+rb0iCeHzLtEX4U/ 3rhXMLI6G5jJfiG2ymhq0jozmOhK5kHnNc8aUi8i5QwuRyttGOEDF2MyYgoN2AQ8M10dBp0UX 7toxMMswj/Eoz8LDB4kkgGVGC6g5S4H2xmJM/ch7vu1YlNx6OCiIqBa3qyxPWfkjjoh8UKXUm SHuGBXi0Acnn+ELFJoC3r8nw5/42SEmK2huZPCkjAoK4lhA== Subject: Re: [Caml-list] OCaml embedded On Fri, Jun 26, 2015 at 11:57:07AM +0200, xavier deschuyteneer wrote: > When i say embedded system, i really mean embedded system running on a > minimal Linux with low power CPU, not so much flash, same for the RAM. > It's similar to think that a raspberry pi is a IOT. It's not, it's mini > computer on ARM platform. In my case, it's really an embedded system, low > cpu, not so much ram, neither flash. If you are running Linux you aren't really embedded anymore or the overhead of the kernel would already kill you. If you aren't running on a Raspberry Pi equivalent or better than maybe you want to drop linux too and go real embedded. > And btw i know exactly how yocto works because i build myself our OS. And > that's not exactly python, it's a mix between python and bash. > We build two different distributions: one ARM and one x86 (for emulation > purpose, valgrind, etc.). and all tools(chains) associated. > This ocaml software needs to be integrated in this workflow. > > Right now, we use plain C, and yes cross compilation is a specific setup, > but it's not difficult to achieve. > The advantage right now to use cross compilation are: > We can use all the power of a real computer to build/debug/code. > I can use all the interfaces that my computer have and not my end > (embedded) system: multiple ethernet cards, bluetooth, usb, etc. > I have multiple projects to manage and all of them are not embedded related. > > Thanks for your answer and the time spent for my question :-) > > TL;DR: i need to cross compile ocaml code to arm because my device is not > powerful enough and that's not possible in industrial purpose to change > that. > Xavier Deschuyteneer > > 2015-06-26 5:04 GMT+02:00 Berke Durak : > > > On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann > > 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. 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 I've used ocaml on a Raspberry Pi natively to compile ocaml code for ARM. I also used qemu-arm (not qemu-system-arm) on an Atom330 (also slow) to run an ARM chroot without much delay. Using the user level emulation is much faster than emulating a full system. And you can match and mix. E.g. use a native gcc cross-compiler for arm with an ARM ocaml binary so only ocaml is slow. You can also use distcc on an ARM board to offload C compile jobs to a cross compiler on a faster server. And then there is the Raspberry Pi 2 or any other ARMv7 multi-core boards. It's easy and cheap to scale up processing power to comfortable levels. MfG Goswin