[haiku-development] Re: [RFC] ARM target support
- From: Ralf Schülke <ralf.schuelke@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 7 Sep 2014 20:27:19 +0200
I think the ARM world is little bit other then x86.
The ARMv7 CPU can we used for minimum, but i think ARMv8 are better
for the future. I see ARM developer board Juno look good.
http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
General i think it's better for Haiku we use two cpu arch AMD64 and ARMv8.
The most ARM will used as SOC, to its good we have a basicly arch eg
ARMv8 and can it used as "template", so can we do "arch_soc" by the
name of SOC.
eg: ARMv7
arch/arm/v7/*
arch/arm_v7/soc/omap/*
arch/arm_v7/soc/tegra/*
The booting process can used the arch_soc and the arch/arm/v7 can used
for arch_soc (arm_v7/soc/)
Its not too late for haiku :-) we need more focus on 64bit stuff, the
on of the best feature of beos has, " Less Hindered by Backward
Compatibility "
stargater
2014-09-07 19:50 GMT+02:00 Ithamar R. Adema <ithamar@xxxxxxxxxxxxxxxxxxx>:
> Hi all,
>
> With ARM slowly approaching user land, and me hanging on to a bunch of
> cleanup/FDT related patches currently, I am wondering if we could clean up
> the build system a little as well.
>
> First of all, I want to propose to deprecate all < ARMv6 support, meaning
> verdex and neo_freerunner, leaving us with overo, raspberry_pi, and beagle.
>
> Also, at the moment, we're "forced" to choose a board at configure time, and
> the full build is tailored to that device (at least there's #ifdefs in
> bootloader/kernel for board). So building for multiple devices is a real
> pain IMHO.
>
> My "end-game" is to be able to configure once, and build the kernel + user
> land pretty independently from the boards we're supporting. The only
> exception there is building the image and the boot loader, which could
> simply be done by a separate target per board (e.g. minimal-beagle).
> Code-wise, there should be no #ifdef's (or at least as minimal as possible).
>
> There's more issues with doing this, but they are all fixable. Just looking
> for a general agreement on where to go with ARM support in the long(er)
> run...
>
> Ithamar.
>
Other related posts:
