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

Re: [MirageOS-devel] Fwd: Mirage ARM port

On Sat, Apr 19, 2014 at 6:09 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 19 Apr 2014, at 00:05, Andy Ray <andy.ray@xxxxxxxxxxx> wrote:
>>> I've been looking at the (rather slick) cross compiler tools for
>>> FreeBSD and (I think) I have compiled a RaspberryPi kernel and
>>> userland which I will now start to test.
>> So firstly I think I missed the "k" in discussions around kFreeBSD...I
>> didn't realise OCaml native code wasn't supported on FreeBSD ARM and I
>> suppose it is with a Debian userland.
> I should have mentioned that the prototype referred to an x86_64 FreeBSD
> kernel module backend, with the assumption that the hop to ARM would be
> relatively straightforward.  With x86_64, the major downside is the lack
> of soft floating point support (since the kernel doesn't save FP registers
> across kthread switches).  With ARM, we should be able to use soft-float
> and avoid this whole issue.

I believe hardfloat support is being worked on for freebsd as well,
but it sounds like softfloat is the better option here anyway.

>> Never mind, I pushed ahead and I have 4.01.0 native code compilers at
>> least somewhat working with FreeBSD on the Raspberry PI now.  I say
>> somewhat because I've barely tested them and had to make some (very
>> minor) patches to the OCaml configure system and ARM backend.  None
>> the less I haven't seen anything not work as yet.  I also haven't
>> tried building the ".opt" compilers but will do soon.
> Patches look good -- if you can cook up a trunk patch against
> https://github.com.ocaml/ocaml, I can also test it on OpenBSD/ARMv7
> on my Pandaboard (I almost have it booting on my Cubieboard there too).
> That should shake out any lurking EABI issues and also ensure that
> 4.02.0dev has the right patches moving forward.  I'm about to kick
> off some large-scale qemu-based ARM bulk builds on trunk, so that
> should give it some more testing in the next few months again the
> OPAM bulk repository.

I'm pretty close to having the 4.01.0+arvmv6-freebsd (or something)
opam compiler ready to go.

I'll grab the latest trunk and try compiling it next week.  If all
goes well then I can provide patch for that.  When I was digging
around a few days back I think I saw incoming cross compiler support
which might complicate things a bit to start with (then dramatically
change our lives for the better!).

>> I've been keeping notes and scripts at
>> https://github.com/andrewray/mirage-fpga.  I've just put a v0.1
>> release up in order to provide opam 1.1 binaries for FreeBSD 10.0
>> RELEASE on rPi.
>> It's not of much use right now but I intend to push a compiler up to
>> opam shortly which should get things going.  Fair play to my rPi which
>> has been compiling like a trooper all week to get this far!
> I have a bit of a cheeky hack for Travis to build a qemu-ARM chroot
> btw: https://github.com/avsm/ocaml/blob/travis/.travis-ci.sh
> Might come in handy if you want to use a faster host rather than
> the rPi for local builds on Linux.

Nice.  Faster builds would be incredibly helpful and benefit all of
the arm boards (which I think will basically all be running the same
userland code).

>> My intention is to also provide a binary compiler as per ocamlpro's
>> 4.01.0+bin-ocp which should make installing ocaml and opam a much
>> nicer experience on these embedded systems.
>> Now, one thing I have found and really like is with FreeBSD once
>> you've spent all day waiting for perl to compile so wget can use it
>> (probably for 1 liner in the makefile...grrrrr) you can:
>> $ pkg create [....]
>> and get installable binaries.  I have a few compiled and will no doubt
>> be generating some more.  If this is likely to be of use to other folk
>> then it would be good to share.
> Sounds great!  It may be worth investigating using 0install as an
> alternative to the 4.01.0+bin-ocp.  I'm a bit wary of distributing
> binaries via OPAM as it's not really designed for that use-case,
> whereas 0install does only that.  It would just install the compilers
> as the system one in that case, so OPAM would still work fine.

So I guess there are pros and cons with each approach.  Another one
which I am quite seriously considering is updating the ocaml port in
freebsd to 4.01.0 and including the patch for ARM support which could
then be binary packaged for pkgng.  It would be cleanest long term
solution I think.

Is there somewhere central I could put pkgng binaries and board images
for sharing?


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.